HK1186267B - System for filtering and organizing items based on common elements - Google Patents

Description

System for filtering and organizing items based on common elements

The patent application is a divisional application of the invention patent application with international application numbers PCT/US03/15720, international application date 5/15/2003, application number 03801850.0 (200910006767.4) entering the Chinese national phase, entitled "common element based system for filtering and organizing items".

Cross reference to related applications

This application is a continuation of part of U.S. patent application No.10/403, 341 filed 3/27/2003 and claims priority on that application date in accordance with the provisions of 35 u.s.c. § 120.

Field of the invention

The present invention relates to a system and method for viewing items stored in a memory of a computer, and more particularly, to a system and method for filtering and organizing items based on common elements.

Background of the invention

Present computer file systems have a number of inconvenient limitations. One limitation is that the user generally cannot control the displayed structure. That is, when organizing folders, the user must select a structure that is difficult to change thereafter. For example, for a specific example, for a "music" folder, the user may choose to organize in an artist/album format, where all of the album folders for each artist are grouped into that particular artist's folder and all of the songs in a particular album are grouped into that album's folder. Such artists/albums are not conducive to playing one type of music (e.g., playing jazz songs from two different artists), or to playing a selection of albums from different artists.

Yet another problem is that users may have a large number of files that are difficult to organize. Some users perform a rigid positioning of the layout of the files, thus creating an accurate hierarchy for them. As the number of active documents grows, the management of such files becomes more and more complex and difficult, making retrieval and extraction also difficult. This problem is further exacerbated when additional files are utilized from other locations, such as shared files and the like.

The user also has to deal with files at different locations, for example on different devices, on other PCs, or online. For example, a user can choose to listen to their music on a computer (as if a music program were accessible) or to go online to listen to music from a Web site, however there is a strict demarcation between the two sources. Music from different locations is organized differently and not saved in the same manner or in the same location. As another example, files stored in the enterprise communication network may be inherently separate from files that the user owns on the current machine.

What the user must track is not only what file data is stored, but where it is stored. For example, for music files, users are forced to keep copies in different systems and try to track which music file is where. This makes files difficult to locate, even when they are stored locally.

And sometimes it is difficult to find and return files owned by the user. A user may sometimes find it difficult to recall where he stored certain files. Given a set of folders and even a set of similar files, it is often difficult for users to quickly find the one they are looking for. Locating is further complicated by the fact that the file is stored in a difficult place to find. In addition, once a user has enough files in a folder, it is more difficult to quickly analyze the folder, especially if the contents are similar.

In addition, it is sometimes difficult for a user to find and return files on the network. Sharing and publishing files is often difficult to do and it is often more difficult to extract such files from the person who made them available. Users typically must remember or chart the various sites and names they need to use to find files on the network.

The namespaces may be different, which can lead to confusion for the user as to what is "correct". This is especially true on networks with different naming conventions, restrictions, etc. For example, some operating systems may require short names without gaps, perhaps for the names to be visible.

Programs also often save files to their own directory or other namespace, making it difficult for users to retrieve files. Programs often have default directories and places where they store documents. Users often have to search through their hard disks and guess where the files are stored.

Related items are also often stored in separate places. The related files owned by the user may be stored on different parts of the hard disk or the like. This problem becomes more prevalent with the development of digital media services with diverse content types (e.g., pictures, music, video).

It is an object of the present invention to provide a system and method that overcomes the above-referenced and other deficiencies. More particularly, the present invention relates to a system and method for filtering and organizing items based on common elements.

Summary of The Invention

A system and method for filtering and organizing items from computer memory based on common elements is provided. According to one aspect of the invention, a filter for manipulating an item is provided. A filter is essentially a tool that narrows down a set of items. In one embodiment, filters are dynamically generated based on the attributes of the separate items. For example, for a set of items, the filter mechanism may again view these properties, and if the items commonly have "authors" as the property, the filter may provide a list of authors. Then by clicking on a particular author, those items that do not have that author disappear. This enables the user to narrow down the content.

According to another aspect of the invention, a method for filtering items is provided in a computer system having a display and a memory for storing items having metadata attributes. Display objects are provided on the display screen, each of which represents one or more items. The metadata attributes of the items represented by the display objects are examined. Providing a filter term on the display corresponding to a metadata attribute shared by the plurality of items, wherein selection of the filter term reduces the items provided on the display to those items sharing the specified metadata attribute.

According to another aspect of the invention, items are provided on a display screen and filter criteria are dynamically generated based on metadata attributes of the items. When a filter term is selected, it reduces the items provided on the display screen to those having metadata attributes corresponding to the filter term.

According to another aspect of the invention, entries are provided on a display screen to provide a filter area where a user can enter filter criteria. When a user enters a filter term, the items provided on the display are reduced to those that contain the filter term. As the user types in the filter term, additional entries may be filtered as each new character is added to the filter term.

According to another aspect of the invention, a back button is provided that can be rolled back during the filtering process. For example, after the user has entered a filter term, the user may want to return to the set of items provided on the screen display prior to the application of the filter term. The back button enables the user to back to a desired point in the filtered navigation.

According to another aspect of the invention, quick links are provided. In one embodiment, a quick link is a set of predefined links (e.g., located on the left side of the display) that can be clicked on to generate a useful view of the set of items. These may be predefined by a program or set by a user. For example, clicking on "all authors" may return a view stacked by author. "all documents" may return a flat view of all documents across all storage areas. Users can also create their own quick links. For example, a user may filter out all documents that they modified in month 1 of 2003 and then save that as a quick link.

According to another aspect of the invention, a method of providing quick links in a computer system having a display and a memory for storing items is implemented. According to this method, the user first navigates to a view of the collection of desired items. A quick link corresponding to the desired set of items is saved and a name is provided. The name of the quick link is provided on the display so that by clicking on this quick link, the user can return to the view of the desired collection of items.

According to another aspect of the invention, a library is provided. Libraries are made up of a large number of groups of useful types that can be linked together. For example, photos may be one library, music may be another, and documents may be another. Libraries provide tools and behaviors that relate to particular types of items. For example, in photo libraries, there are tools and filters involved in manipulating photos, like creating a slide show or sharing photos.

According to another aspect of the invention, a method of creating a library in a computer system having a display and a memory for storing items is provided. The method begins by creating a library of items to include items having one or more specified metadata attributes. Then, items having one or more specified metadata attributes are automatically grouped into the library. Tools for manipulating entries in a library are also provided.

According to another aspect of the invention, items are presented to a user in a virtual folder. The virtual folders present items to the user in different views based on their metadata rather than the actual physical underlying file system structure on disk. Thus, the system can obtain an attribute stored in the database and represent it as a container such as a folder. By providing virtual folders in a similar manner, users may adapt to new systems more quickly, as users are already familiar with working with folders.

According to another aspect of the invention, the user can work with the virtual folder by direct operation. In other words, the mechanisms provided to manipulate the virtual folders are similar to those currently used to manipulate regular folders (e.g., click and drag, copy, paste, etc.).

According to another aspect of the invention, a wide range of items may be available. That is, the system can provide items from several physical locations (e.g., different hard disks, different computers, different network locations, etc.) so that all items appear to the user to be from one location. For example, a user may be provided with all of their music files on a single screen and manipulate all of the files from one view, although the files may be physically stored on different hard disks, different computers, or different network locations.

According to another aspect of the invention, non-file entries may be provided in the virtual folder. That is, the files stored in memory are located in physical memory. The virtual folders may be made to include entries that are not currently provided in physical storage. Examples of non-file entries are e-mail and contacts.

Brief description of the drawings

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a general-purpose computer system suitable for implementing the present invention;

FIG. 2 is a block diagram of a virtual folder system according to the present invention;

FIG. 3 is a flow diagram illustrative of a routine by which a user provides a query to retrieve selected files and folders;

FIG. 4 is a flow diagram illustrative of a routine by which virtual folders are created and displayed on a screen in accordance with a default query or a query from a user;

FIG. 5 is a tree diagram of a folder structure according to a physical folder arrangement on a hard disk;

FIG. 6 is a tree diagram of a virtual folder structure;

FIG. 7 is a tree diagram of the virtual folder structure of FIG. 6 in which the client heap is further filtered with contracts and year;

FIG. 8 is a tree diagram of the virtual folder structure of FIG. 7 in which contracts for the customer heap are further filtered by year;

FIG. 9 is a tree diagram of the virtual folder structure of FIG. 6, wherein the contract heap is further filtered by customer and year, wherein the customer is further filtered by year;

FIG. 10 is a screen display diagram illustrating a display of a heap of a document library;

FIG. 11 is a screen display diagram illustrating a document in the ABC corporation heap of FIG. 10;

FIG. 12 is a diagram illustrating a screen display in which a stacking function is selected for the document in FIG. 11;

FIG. 13 is a diagram illustrating a screen display in which a "stack by author" parameter has been selected for the stacking function of FIG. 12;

FIG. 14 is a diagram illustrating a screen display in which the files of FIG. 13 have been stacked by author;

FIG. 15 is a diagram illustrative of a screen display in which the stacking function is selected and the "stack by sort" option is further selected for re-stacking the files in FIG. 14;

FIG. 16 is a diagram illustrating a screen display in which the files of FIG. 14 have been restacked by category;

FIG. 17 is a diagram illustrating a screen display in which quick links have been selected for displaying physical folders;

FIG. 18 is a diagram illustrating a screen display in which physical folders are displayed which include files in the virtual folder heap of FIG. 17;

FIG. 19 is a flowchart illustrating a routine by which a user can directly manipulate virtual folders;

FIG. 20 is a diagram illustrating a screen display in which a new "west coast" heap has been added to the heap of FIG. 10;

FIG. 21 is a diagram illustrating a screen display in which direct operations are used for copying files from the "ABC" company heap to the "West coast" heap in FIG. 20;

FIG. 22 illustrates a flow diagram of a routine for the system dynamically generating new filter terms;

FIG. 23 is a flow diagram illustrative of a routine for the system to filter based on selected filter criteria;

FIG. 24 is a diagram illustrating a screen display in which the heap of FIG. 10 has been filtered by the condition "AB";

FIG. 25 is a diagram illustrating a screen display in which the heap of FIG. 10 has been filtered with the condition "ABC";

FIG. 26 is a diagram illustrating a screen display in which the filter condition "2002" has been selected for the heap of FIG. 10;

FIG. 27 is a diagram illustrating a screen display in which the heap of FIG. 10 has been filtered with the filter term "year 2002" and the filter term "month" has further been selected;

FIG. 28 is a diagram illustrating a screen display in which a list for selecting a month for filtering is presented;

FIG. 29 is a diagram illustrating a screen display in which the heap of FIG. 10 has been further filtered by the month of January, and further showing the filter condition "day";

FIG. 30 is a flow diagram illustrative of a routine for creating a new quick link;

FIG. 31 is a diagram illustrating a screen display for creating a new quick link called "January work" based on the filtering in FIG. 29;

fig. 32 is a diagram illustrating a screen display in which the quick link "all authors" is selected.

FIG. 33 is a diagram illustrating a screen display in which a list of all of the authors of FIG. 32 is presented;

FIG. 34 is a diagram illustrating a screen display in which "Author 1" has been selected from the list in FIG. 33, and documents of all Author 1's are displayed;

FIG. 35 is a flow diagram illustrative of a routine for creating a new library;

FIG. 36 illustrates a diagram of a screen display showing a collection of various active libraries;

FIG. 37 is a flow diagram illustrative of a routine for defining the scope of virtual folders;

FIG. 38 is a block diagram illustrating various sources that may form a range of virtual folder collections;

FIG. 39 is a flowchart illustrating an exemplary process for adding non-file entries in a virtual folder collection; and

fig. 40 is a diagram illustrating a screen display showing various non-file entries included in a virtual folder.

Description of The Preferred Embodiment

The invention relates to virtual folders. Virtual folders employ the same or similar user interfaces as are currently commonly used in file systems. Virtual folders present regular files and folders (also known as directories) to users in different views based on their metadata rather than the actual physical underlying file system structure on disk. Location-independent views are created that allow users to manipulate their files and folders with controls similar to those currently used to manage file systems. In general, this means that users can organize and rearrange their files based on the inherent characteristics of the files themselves, rather than management and organization as is done as a separate part of the system. Virtual folders may provide files or items from different physical locations, such as from multiple disk drives in the same computer, between multiple computers, or between different network locations, so that one view of a file or item may present files or items at different physical addresses. In one embodiment, different items or files are to be included, which need only be connected through one IP network.

The virtual folder model may also be used for traditional non-file entities. One application of this is to display traditional non-file entities with a set of user interfaces similar to files and folders (i.e., objects and containers). One example of such a non-file entity is email, while another example is contact information from a contact information repository. In this manner, the virtual folders provide a location-independent, metadata-based view system that works regardless of whether the displayed data is from a file or a non-file entity. In general, these features provide more flexibility in letting users manipulate their files and data, both using common user interface techniques (drag and drop, double-click, etc.), and supporting a rich set of various data types.

FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, characters, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a conventional personal computer 20, such computer 20 including a processing device 21, a system memory 22, and a system bus 23 that couples various system components including the system memory 22 to the processing device 21. The bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes Read Only Memory (ROM) 24 and Random Access Memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between elements within the personal computer 20, such as during start-up, is stored in ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk 39, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD-ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk 39, a removable magnetic disk 29, and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory, digital video disks, Bemoulli and magnetic tape, Random Access Memories (RAMs), Read Only Memories (ROMs), and the like, may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk 39, magnetic disk 29, optical disk 31, ROM24, or RAM25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing apparatus 21 through a serial port interface 46 that is coupled to the bus 23, but may be connected by other interfaces, such as a parallel port, game port or a Universal Serial Bus (USB). A display in the form of a monitor 47 is also connected to the system bus 23 via an interface 48, such as a video card or adapter. One or more speakers 57 may also be connected to the system bus 23 via an interface 56, such as an audio adapter. In addition to the display and speakers, personal computers typically include other peripheral output devices (not shown), such as printers.

The personal computer 20 may operate in a networked environment using logical connections to one or more personal computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20. The logical connections depicted in FIG. 1 include a Local Area Network (LAN) 51 and a Wide Area Network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link may be used.

As implemented on a system of the type shown in FIG. 1, in a new feature, the present invention employs virtual folders that make it easier for users to accomplish basic tasks regarding file manipulation and folder navigation (browsing), and provide support for a higher level of storage capability. Virtual folders present files and items to users in different views based on their metadata rather than the actual physical underlying file system structure on disk.

Fig. 2 is a block diagram of a virtual folder system 200 according to the present invention. As will be described in more detail below, the virtual folders allow the user to change the "primary element" that controls the way the data is displayed. As an example, a user may view their music as a flat list of all songs, which may be grouped by album. In other words, the user may switch views to show only genres or artists or years, etc. The user can crop the view to see only the objects that meet the requirements of the task at hand. This provides improved browsing skills without the need for further navigation (down and back) in the folder. The same skill and ability applies to other modeling of data types that are not stored as files. Contacts, for example, may be presented to the user in such a way as to give them common interface capabilities and a richer infrastructure than that provided by flat address books.

As shown in FIG. 2, the virtual folder system 200 includes a folder processor 210, a relational database 230, a virtual folder descriptions database 232, other shell folders component 234, folder handlers component 236, and a shell browser and view component 240. The folder processor 210 includes a native handling code component 212, a handler generator component 214, a property logger component 216, a rowset parser component 218, a query generator component 220, an enumerator component 222, and a property generator component 224.

Relational database 230 stores attributes for all files in the system. It also stores some entries like contacts (i.e. non-file entries) completely. Generally, it stores metadata about the types of files and entries it contains. The relational database 230 receives the SQL query from the query generator 220. The relational database 230 also sends the SQL rowset, listing the attributes of the items in a row per item, to the rowset parser component 218.

The virtual folder descriptions database 232 includes virtual folder descriptions. The virtual folder descriptions database 232 sends data to the query generator component 220 that includes a list of types to be displayed in the folder, the initial filter, and the physical location where the results from (the scope) are displayed.

With respect to the other shell folders component 234, the folder processor 210 authorizes existing shell folders from many types of entries, including all files for handlers or properties. The other shell folders component 234 sends properties from other folders to the property generator 224. The other shell folder components also send the handler to handler generation 214.

The folder handler component 236 provides code behavior for entries that exist only in the database, such as contacts. This is what makes non-file entries behave like files. The folder handler component 236 sends the handler to the handler generation 214.

To process the code component 212 locally, the folder processor 210 directly executes certain handlers that are based on the attributes of the items. The native handling code component 212 sends the handler to the handler generation 214. For the native handling code component 212 and the folder handlers component 236, the virtual folders have to provide a set of handlers (environment menus, icons, thumbnails, information tips, etc.) for their entries, like all namespaces. For most of these (information prompts, data objects, drag-and-drop handlers, background environment menus,..) the virtual folder provides all types of common (local) handlers for its saving. However, there are other handlers that programmers of that type must provide (context menu, writable property store in the entry itself). The default handler may also be overridden. The virtual folder reuses this for files and allows non-file entries as well.

Handler generator 214 loads the ID sequence and generates code behaviors that provide context menus, icons, etc. Generally, as described above with respect to the native handling code component 212, the other shell folders component 234, and the components 236 of the folder handlers, the folder handler 210 can use native handlers, external handlers, or authorize other shell folders to obtain handlers. When requested by a view, the handler generation component 214 sends the handler to the shell browser in the view 240. The handler generation component 214 sends an attribute handler to the attribute logger 216.

The property logger 216 translates the user's intentions like cut and paste, copy, paste into modifications to the properties of the file or item. The shell browser and view component 240 sends data to the property recorder 216, including direct manipulation (cut/copy/paste) or editing of metadata. In summary, since the virtual folders appear as an organization based on the properties of the items, operations like move and copy (drag and drop) become edits to the properties. For example, moving a document, in a view stacked by author, from author 1 to author 2, means changing the author. This functionality is implemented by the attribute recorder component 216.

Rowset parser 218 loads the rowset of the database and stores all entry attributes into the shell ID sequence structure. The row sets are loaded into the segment definitions of the virtual folder, creating an SQL row that Xian can issue to the database. The rowset parser component 218 sends the ID sequence to the enumerator component 222. As previously described, rowset parser component 218 also receives data from relational database 230, including SQL rowsets with one row per entry and one column for entry attributes.

The query generator component 220 builds its SQL query. The query generator component 220 receives data from the enumerator component 222, including new filters from navigation. The query generator component 220 also receives data from the virtual folder descriptions database 232, including a list of types displayed in the folder, initial filters, and physical locations where results from (scopes) are displayed. The query generator component 220 sends the SQL query to the relational database 230.

Typically, the query generator component 220 includes a set of rows (in other words, a table). This is what the running query produces. The row set parser component 218 loads each row and transforms the row into an ID sequence using the column name. The ID sequence is a well-known shell structure used to index entries in a namespace. Doing this makes the virtual folder just like the namespace of any other remaining shells. Furthermore, caching data helps keep, the cost can be high, and access to the database is minimal.

The enumerator component 222 operates in response to navigation of the virtual folders. As previously described, the enumerator component 222 takes over the ID sequence from the rowset parser component 218 and sends the new filter from the navigation to the query generator component 220. The enumerator component 222 also sends data to the shell browser and view component 240, which includes a sequence of IDs that are returned to be inserted into the view after a navigation.

The attribute generation component 224 takes the ID sequence and attribute identification number and returns its value for these attributes. The attribute generation component 224 receives data including the attribute handlers from the handler generation component 214. As previously described, the property generation component 224 also receives data from other shell folders component 234, which includes properties from other folders. The property generation component 224 also sends data, including properties of the items, to the shell browser and view component 240 at the time of the view request.

The shell navigation and view component 240 displays the contents of the folder in the window and handles all user interactions with the displayed file or item, such as clicking, dragging, and pointing. Thus, the shell browser and view component 240 receives the user's actions. The shell browser and view component 240 also obtains the data it needs about the code behavior from the folder, here from the folder processor 210.

As previously mentioned, virtual folders present regular files and folders (also known as directories) to users in different views based on their metadata, rather than the actual physical underlying file system structure on disk. Thus, the system can take an attribute stored in the database and represent it as a container such as a folder. By providing virtual folders in a similar manner, users may adapt to new systems more quickly as they are already familiar with working with folders.

FIG. 3 is a flow diagram illustrative of a routine 300 by which a user provides a query to retrieve selected items. At block 302, the folder processor obtains a query from the user. At block 304, the folder processor passes the query to the relational database. At block 306, the relational database returns the results to the folder processor. At block 308, the folder processor provides the results to the user in the form of virtual folders and entries.

Fig. 4 is a flow chart illustrating an exemplary process 320 by which virtual folders are created and displayed on a screen, either in accordance with a default query or a query from a user. At block 322, when the user first opens the virtual folder, a default query is used. This default query is taken from the record. For example, a default query for a music library may be to display all songs grouped by album. At block 324, the folder processor builds a query object for the query and passes the query to the relational database. At block 326, the relational database generates the results of the query and passes these back to the folder processor as rows and columns of the database.

At block 328, the folder processor takes these results and converts them from the row and column data into an enumerator structure, with the folder view populating the screen with it and the resultant virtual folders and entries for interaction with the user. At decision block 330, the user decides whether to change the view (by giving a different query or "primary element"). For example, the user may present a main element of "show all artists". If the user does not want to change the view, then the routine returns to block 324 where the folder processor passes the new query to the relational database and receives new rows and columns of results and builds a new enumerator structure. When the folder view is cleared and updated, processing continues as previously described using an enumerator to pull the "artist" object to the screen.

In one example, an album object is provided indicating that the user may enter the container. For example, double-clicking on a "Beatles" album may enter a view of a song that sees all Beatles. The folder processor issues a query to the relational database that returns data for all rows and columns for the songs, "show all songs. The folder processor creates an enumerator of all these songs that will later be pulled on the screen.

The user can also select a view at any point while browsing the virtual folders. In the above example, after narrowing down to show songs of just Beatles, the user may change the view to show only songs as albums. The process of changing the view of an item to another representation is called "stacking". This is because the entries are conceptually arranged into a "heap" based on that representation. In this case, the songs are rearranged into a heap for each different album. The user can then enter one of these heaps, seeing only the songs from that particular album. In addition, the user can rearrange the remaining songs into heaps based on one attribute (e.g., the listening rate). If the earnings rate attribute is selected, the vocals from the Beatles' albums are displayed in heaps of one, two or three stars of listening rates.

The result of each query depends on the physical location included in the scope. For example, the scope may be made to include only folders within the user's "my documents". In other words, this scope may include all folders on a computer, or even all folders on several network-connected computers. The user can view and change the scope through the scope property page. In one example, the scope property page can be presented by right-clicking on the virtual folder and selecting "properties". The user may add new folders to the scope or delete previously added folders.

Virtual folders will provide particular utility to a group of users who are brainworkers. Virtual folders allow a mental worker to easily switch between viewing files by file type, project, case number, author, and the like. As each mental worker tends to have a different method of organizing files, virtual folders can be used to accommodate these different preferences.

Fig. 5 is a tree diagram of a folder structure arranged in terms of physical files on a hard disk. This physical folder arrangement is based on a conventional folder tool that is based on NTFS or other existing file systems. Such folders are referred to as physical folders because their organization is based on the actual physical underlying file system structure on the disk. As will be explained in more detail below, this is in contrast to virtual folders, which create location-independent views that allow users to manipulate files in a manner similar to that now used to manipulate physical folders.

As shown in FIG. 5, folder 400 is a My documents folder. At a first level, folder 400 includes folders 410, 420, and 430, which correspond to customer 1, customer 2, and customer 3, respectively. At a second level, each of the folders 410, 420, and 430 contains a folder 411, 421, 431, respectively, corresponding to the contract of the selected customer. At the third level, each of the folders 411, 421, and 431 contains one folder 412, 422, 432, respectively, corresponding to year 2001. At this third level, each of the folders 411, 421, and 431 also contains a folder 413, 423, 433, respectively, corresponding to year 2002.

Clearly, this poses a number of obstacles to users who wish to navigate a physical folder structure such as that shown in FIG. 5. For example, if the user wants to work with all of the contracts he has done, he will first need to navigate to folder 411, work with the contracts for customer 1, then will have to navigate to folder 421 again to get the contracts for customer 2, and will again have to navigate to folder 431 for the contracts for customer 3. Such an arrangement makes it difficult for a user to access all of the contracts and generally prevents simultaneous viewing and manipulation of all of the contracts. Similarly, if the user wishes to view all of the contracts that were made in 2001, he would have to navigate and re-navigate to folders 412, 422, and 432, respectively. As will be described in greater detail below, the virtual folders of the present invention provide an improved file system structure.

FIG. 6 is a tree diagram of a virtual folder structure. As will be described in more detail below, the virtual folders create location-independent views that allow users to manipulate their files and folders in a more convenient manner. As shown in FIG. 6, the virtual folders are represented as heaps. The virtual folder 500 is an "all items" folder. At a first level, the virtual folder 500 includes virtual folders 510, 520, and 530 corresponding to customers, contracts, and year, respectively. As will be described in more detail below, this structure enables a user to access files according to desired parameters.

Fig. 7 is a tree diagram of the virtual folder structure in fig. 6, wherein at a second level, the virtual folder 510 further includes virtual folders 511 and 512 corresponding to contracts and years, respectively. In other words, the client heap of virtual folder 510 is further filtered by contracts and year. The process of determining which files and entries to include in each virtual folder will be described in more detail below.

Fig. 8 is a tree diagram of the virtual folder structure in fig. 7, in which, at the third level, the virtual folder 511 includes a virtual folder 513 corresponding to one year. In other words, the contract heap of virtual folder 511 is further filtered by year. While the virtual folders 510, 511, and 513 have been constructed by customer, contract, and year, it will be apparent that the virtual folders allow other construction sequences to occur, as will be described in more detail below with reference to FIG. 9.

Fig. 9 is a tree diagram of the virtual folder structure in fig. 6, wherein at a second level, the virtual folder 520 is further filtered to virtual folders 521 and 522 corresponding to clients and years. At the third level, virtual folder 521 is further filtered to correspond to a year's virtual folder 523. The contrast between the organizational structures in fig. 8 and 9 helps illustrate the flexibility of the virtual folder system. In other words, in contrast to the view associated with a location-dependent physical file structure as shown in FIG. 5, in a virtual folder system, a user is able to navigate to a virtual folder according to desired parameters.

FIG. 10 is a diagram illustrating a screen display 600 showing a pile of a document library. As previously described, a heap may be used to represent one type of virtual folder. As will be described in greater detail below, the screen display 600 includes a quick link unit 610-.

The quick link element includes a quick link 610 for "all classes", a quick link 611 for "all authors", a quick link 612 for "work of month" and an option 613 to display additional quick links. As will be described in greater detail below, the user may perform the desired navigation of the virtual folders by selecting a quick link. Quick links may be provided through the system, and the user may also create some quick links and save them.

The filter unit includes a "use. Filter "indicator 620 notices the user that the underlying items may be used to filter the virtual folders or items. The login field 621 provides an area where the user can enter new filter criteria as desired. The "with date" indicator 622 lets the user notice that by selecting a date from the "year" selector 623, the virtual folders or items may be filtered by the selected year. The "pick an author" selector 624 allows the user to filter according to a particular author. The "select one category" selector 625 allows the user to filter according to the selected category. The "more filters" selector 626 allows the user to pull additional filters on the display.

The behavior selectors include a "create one new classification" selector 630, behavior selectors 631 and 632, and a "more behavior" selector 633. As will be explained in more detail below, these provided behaviors may be for generally desired functions or may be more specifically specific to the type of virtual folder currently being displayed. For example, the user may select the "create a new category" selector 630 to create a new category to be represented by a new heap.

As previously described, the behavior selectors 631 and 632 may be more specifically dedicated to the type of virtual folder or item being displayed. For example, the current display is a document library for which the "behavior" selectors 631 and 632 may be behaviors specifically tailored for the document, such as editing or creating attachments. If the current library is a photo library, then the "action" selectors 631 and 632 may be actions specifically designated for photos, such as composing photo albums or sharing photos with other users.

The information and control element includes information lines 640 and 641, a control line 642, a back control 643, and information lines 644 and 645. The information lines 640 and 641 provide information in navigating about the current virtual folders and items. In this example, information line 640 shows that the current navigation is for a document library, while information line 641 shows a more complete navigation, showing that the document library is in a memory area. The control row 642 provides a number of standard controls, as well as a back button 643 that allows the user to navigate back. The information line 644 provides digital information about the content currently being navigated. In this example, the information line 644 shows that there are 41 entries in the heap of the document library that occupy 100 MB. The information line 645 may be used to provide additional information, such as additional information about the selected file.

The files of the document library include an "ABC company" file 651, a "backup file" 652, a "business plan" file 653, an "XYZ company" file 654, and a "market report" 655. The upper number of each heap indicates that there are several entries in each heap. For example, an "ABC corporation" heap 651 is shown to include 8 entries. The total number of entries of the heap adds up to the number of entries indicated in the information line 644, which in this example is 41 as described above. The selection box SB is used to let the user select a desired item. As will be described below with respect to FIG. 11, selecting the "ABC Corp" heap 651 will result in a view of the entries of that heap.

FIG. 11 is a diagram illustrating a screen display showing entries in the "ABC, Inc" heap 651 of FIG. 10. It should be noted that the information lines 640 and 641 now indicate that the current navigation is displaying the "ABC, Inc" heap. The "ABC corporation" heap 651 is shown to include 8 documents 751-. The information line 644 correspondingly indicates that there are 8 entries occupying 20MB of storage space. The document in FIG. 11 may be further arranged into a heap in ABC Corp heap 651. That is, as will be described below with respect to FIGS. 12-16, additional virtual folders may be grouped to save documents in the virtual folders represented by the ABC corporation heap 651.

FIG. 12 is a diagram illustrating a screen display in which the stacking function is selected for the document in FIG. 11. As shown in fig. 12, the user can pull out the function block 760. Function box 760 includes a "view" option 761, a "press.. to arrange icons" option 762, "stack" option 763, "refresh" option 764, "open included folder" option 765, a "cut" option 766, a "copy" option 767, an "undo" option 768, a "new" option 769, and an "properties" option 770. The selection box SB is displayed around the "stack by author" option 763.

Fig. 13 is a diagram illustrating a screen display in which a "stack by author" parameter is selected for the stacking function in fig. 12. As shown in FIG. 13, a box 780 is displayed which presents various stacking options. The stacking options include an "undo stack" option 781, a "stack by sort" option 782, a "stack by author" option 783, and a "stack by user" option 784. The selection box SB is displayed around the "stack by author" option 783.

Fig. 14 is a diagram illustrating a screen display in which the files in fig. 13 have been stacked by author. As shown in fig. 14, pairs 791 and 792 correspond to authors Bob and Lisa, respectively. Just as the numbers shown above each heap, Bob heap 791 includes two entries, while Lisa heap 792 includes five entries. Item 758 (corresponding to document 8) has no author and is therefore not included in an "author" heap. Stacks 791 and 792 illustrate that the stacks may be organized in multiple layers, as in "ABC company" stack 651. The virtual folders may thus form multiple layers, for example, the "Lisa" heap 792 is within the "ABC corporation" heap 651 within the document library.

Fig. 15 is a diagram illustrating a screen display in which a "stack by sort" option is further selected for re-stacking the files in fig. 14. As shown in fig. 15, the selection box SB is around the "stack by sort" option 782. Since some of these entries are already stacked in the heaps 791 and 792, selection of the "stack by sort" option 782 will re-stack the entries, as will be explained in more detail below with respect to FIG. 16.

Fig. 16 is a diagram illustrating a screen display in which the files in fig. 14 have been restacked by category. As shown in fig. 16, the heaps 793 and 794 correspond to the "XYZ company" and "market reports" categories, respectively. Entries 751 and 752, corresponding to documents 1 and 2, are not assigned any additional classification and therefore do not belong to the heap of any classification.

Fig. 17 is a diagram illustrating a screen display in which a quick link of a physical folder is selected. The selection box SB is displayed around the all folder quick link 616. As will be described in more detail below with respect to FIG. 18, an "all Folders" quick Link 616 is used for switching views of physical Folders.

Fig. 18 is a diagram illustrating a screen display showing physical folders. The physical folders that are shown include files in the virtual folder heap that encompasses FIG. 17. That is, the entries contained in heap 651-. These are shown in FIG. 18 as the My documents folder 851 located at the current computer, the desktop folder 852 located at the current computer, the hard disk C: a "Foo" folder 853 on the server, a "my files" folder 854 on the server, an "external drives" folder 855 on the external drive, a "my documents" folder 856 on another computer, and a "desktop" folder 857 on another computer.

As shown in fig. 18, the user can switch from the virtual file representation of fig. 17 to the physical file representation of fig. 18. This enables the user to toggle back and forth between the virtual file representation and the physical file representation as required by the current task. The different locations of the physical folders 851-857 also illustrate that the scope of the virtual file system is relatively broad, as will be described in more detail below.

FIG. 19 is a flowchart illustrating an exemplary process 880 by which a user can directly manipulate virtual folders. As will be described in greater detail below, the mechanisms used to manipulate virtual folders are similar to those currently used to manipulate conventional folders (e.g., click and drag, copy, paste, etc.). As shown in FIG. 19, at block 882, the system provides a prescribed action that the user can perform to directly manipulate the virtual folders that appear as display objects. At a block 884, the user performs a specified action. As previously described, one example may be a user clicking and dragging one virtual folder to copy its contents to another virtual folder. At a block 886, the virtual folders and/or content are manipulated as specified by the action performed by the user.

Fig. 20 is a diagram illustrating a screen display in which a new west coast pile 656 has been added to the pile of fig. 10. The west coast pile 656 is formed by the user creating a new "west coast" classification. At the time it is just created, the new west coast heap 656 will be empty, with zero entries. In the embodiment of fig. 20, two entries have been added to the west coast pile 656. One way to add an entry to the heap is to select a particular entry, either modify the metadata of that entry, or add another classification to its metadata, such as adding the classification "west coast" to both entries as is done in the embodiment of fig. 20. This process illustrates that classification data is a metadata attribute, an ad-hoc attribute, of an item. In other words, this type of attribute has no implicit meaning and can be assigned any value by the user. For example, the classification "attribute" may have any value, while the "author" attribute must be a person's name. As will be described in more detail below with respect to fig. 21, an item may also be clicked and dragged to be copied from the other heap into the west coast heap 656 (in which case the category of the item is automatically updated to include "west coast"). In this regard, FIG. 20 shows the selection box SB around the ABC corporation heap 651 in preparation for copying its contents.

FIG. 21 is a diagram illustrating a screen display in which a direct operation is used to copy files from the ABC company heap 651 to the west coast heap 656. That is, as shown in FIG. 20, the user selects the ABC Corp heap 651, and then, as shown in FIG. 21, the user has clicked and dragged this heap, copying it to the West coast heap 656. Thus, the west coast heap 656, having two entries in FIG. 20, is now shown to include a total of ten entries, including an additional eight entries from the ABC corporation heap 651. This is accomplished by modifying the classification specification of the eight entries to include the "west coast" classification in addition to the initial "ABC company" classification after the entries from the ABC company heap 651 have been copied to the west coast heap 656. A straightforward operation that can be performed is described herein.

Another example of a direct operation is right clicking on an entry and selecting delete. In one embodiment, after the user selects the delete function, the user is asked whether this entry is to be deleted completely or simply removed from the current virtual folder. As previously described, if this entry is only to be removed from the current virtual folder category heap, this may be done by removing the desired category from the metadata of the entry. That is, if one of these entries that has been copied from the ABC company heap 651 to the west coast heap 656 is later removed from the west coast heap 656, this may be accomplished by modifying the classification data of a particular file to no longer include the "west coast" classification.

FIG. 22 is a flow diagram illustrative of a routine 900 for dynamically generating new filter criteria for the system. The filter criteria are used to manipulate the virtual folders. The filter terms essentially serve as a set of tools to narrow down a set of items. In one embodiment, the filters include metadata categories and their values (provided to the user in the user interface as clickable links or as drop down menus). The user clicks on a filter term to filter the result set of items currently on the display.

FIG. 22 illustrates how filters are dynamically generated. As shown in FIG. 22, at block 902, the attributes (from the metadata) of the items in the collection on the current display screen are again viewed. At block 904, the proposed filter condition is dynamically generated based on the common attributes of the items. At block 906, the proposed filter criteria are provided to the user for possible selection of filter criteria. As an example of this process, the system may again look at the properties of a set of items, and if the items commonly contain "authors" as properties, the filter may provide a list of authors that are used as filter. Then, by clicking on a particular author, those items that do not have that author are removed from the group on the display. This filtering process provides the user with a mechanism to narrow down a set of items on the display.

FIG. 23 is a flow diagram illustrative of a routine 920 for a system for filtering based on a selected filter criteria. At block 922, the user either enters a new filter criteria or selects a filter criteria that is already provided by the system. As previously mentioned, the filter criteria may be dynamically generated by the system or may be preset. At block 924, items from the collection on the display screen are examined as to whether their selected attributes match the filter criteria. For example, if the filter term is an item authored by "Bob", then the investigation is made according to whether the author attribute of the item includes "Bob". At a block 926, those entries whose selected attributes do not match the filter criteria are removed from the collection on the display screen.

FIGS. 24-29 generally illustrate the filtering process presented on a screen display. As will be described below with respect to fig. 24-29, in one embodiment, filtering generally operates according to the following steps. Items that are outside the filter range are animated off-screen after the user clicks on a filter value. Design animations typically make it apparent that an item is being removed and no new item is being added. The back button 643 may be selected by a user to override the filtering operation. In one embodiment, a navigation heap is created that contains sequential filtering operations that can be used to undo each filtering action when the back button 643 is selected. Each time a filter value is selected, the information areas 640 and 641 are updated to indicate the current filter value. In one embodiment, upon selection of a filter value, the user is provided with an option to store a new quick link to the navigation of the current filter, as will be described in more detail below with respect to FIG. 30. Upon selection of the filter value, the filter control may be updated to fit the remaining entries in the view.

FIG. 24 is a diagram illustrating a screen display in which the heap of FIG. 10 has been filtered with the condition "AB". As shown, in the filter area 621, the user has typed the condition "AB". The information lines 640 and 641 indicate that the items on the display are those that have been filtered by the condition "AB". As shown, the ABC company heap 651 still includes eight entries, while the backup heap 652 now includes three entries, and XYZ company 654 also includes three entries. The information line 644 thus indicates that a total of 14 entries occupy a total of 35MB of memory space.

FIG. 25 is a diagram illustrating a screen display in which the heap of FIG. 10 has been filtered with the condition "ABC". With respect to the filter term "AB" in fig. 24, the user merely types in the additional letter "C" to obtain the complete filter term "ABC". As shown in FIG. 25, the information lines 640 and 641 now indicate that the items on the display are those containing the condition "ABC". The ABC corporation heap 651 still appears to include eight entries, while the backup heap 652 now includes only two entries. XYZ company 654 disappears because its contents do not match the "ABC" filter. The information line 644 thus indicates that a total of 10 entries occupy a total of 25MB of memory space. Thus, FIGS. 24 and 25 provide an example of how a user may enter new filter terms and how these filter terms may be later used to filter items provided on a display screen.

The user may utilize the back button 643 to back-off during the filtering process. As previously described with respect to fig. 10, the back button allows the user to back off in the navigation. With respect to the example in fig. 24 and 25, after filtering with the condition "ABC" in fig. 25, the user may select the back button 643 to go back one step of the filtering process, which returns to the state of fig. 24. In other words, in another embodiment, the back button 643 may clear all filter conditions, which may return to the state before filtering occurs. In this case, by pressing the back button 643 in fig. 25, the user can return to the state of fig. 10.

In one embodiment, in addition to the back button, an auxiliary means is provided for the user to rewind through the navigation, or modify the filtered navigation. This auxiliary means includes navigation that allows the user to directly access and modify the information line 641, changing the filtering accordingly. That is, by directly accessing and modifying the information line 641, the user can remove one or more used filters or modify the value of any used filters. This feature is described in great detail in U.S. patent application No.10/420,040, filed on month 4 and 17, 2003, the function of which is similarly designated and is hereby incorporated by reference in its entirety.

The timer may also be used in conjunction with a user typing in filter terms, such as those shown in fig. 24 and 25. A timer is used to monitor the intermittency of user entry. After a selected time interval without typing, the filter is applied. For example, in the state of FIG. 24, the user has typed the filter condition "AB" without a significant time lag between "A" and "B". After typing "AB", the user pauses, resulting in a state where the filter condition "AB" is applied as shown in fig. 24. After some time, the user adds the letter "C" to complete the filter term "ABC" and then pauses again, at which point the filter term "ABC" is applied, as illustrated in FIG. 25.

In one embodiment, after the user has typed a filter term in the filter area 621 and then selects another filter or navigation, the status of the navigation is updated and the filter term in the filter area 621 is again nulled. In addition, as will be described in greater detail below with reference to FIGS. 26-29, other filter controls may be updated based on the selection of certain filter conditions.

Fig. 26 is a diagram illustrating a screen display in which the filter condition "year 2002" provided by the system is selected. As previously described, under the used date indicator 622, the year selection 623 includes year 2000, 2001, or 2002. The selection box SB is shown around the year 2002 indicating that the user is selecting it as the desired filtering condition.

Fig. 27 is a diagram illustrating a screen display in which the filter condition "2002" has been applied. Further selection of the "select one month" selector 623A is also shown. As shown in FIG. 27, after the filter condition "2002" is applied, the number of entries in the heap has been reduced. More specifically, ABC, Inc. heap 651 now includes six entries, while backup heap 652 now includes 8 entries, business plan heap 653 now includes three entries, and XYZ, Inc. heap 654 now includes five entries. The information line 644 now indicates a total of 22 entries, occupying a total of 50MB of memory space. The information lines 640 and 641 now indicate that the items displayed on the display are those that have been filtered, including the filter term "2002".

Fig. 28 is a diagram illustrating a screen display in which a list for selecting a month for filtering appears. A box 950 is provided that includes a list of months. A box 950 has been provided on the display because the user selected the "select one month" selector 623A. The selection box SB is displayed around 1 month.

Fig. 29 is a diagram illustrating a screen display in which the heap of fig. 28 has been further filtered by the month of january, and further showing the filter condition "day". As shown in FIG. 29, the information lines 640 and 641 now indicate on the display that those that have been filtered with the condition "January". While backup heap 652 is now shown to include two entries and business plan heap 653 is also shown to include two entries. The information line 644 indicates that there are a total of four entries on the display, taking up a total of 10MB of memory. If the user wants to further filter the results for a particular day, a "select one day" selector 623B is provided.

As previously described with respect to fig. 24-29, the filter criteria may be provided by the system or may be entered by the user. Once a filter term is selected, the remainder filter terms that are presented may be updated (e.g., after year 2002 "is selected in FIG. 26, the option for selecting a year in FIG. 27 is no longer presented, instead the option of" select a month "is provided). As described above, the back button 643 may be selected by a user to back-off during the filtering process. For example, after month "January" has been selected in FIG. 29, the user may select the back button 643 to back the filtering process to year "2002" as shown in FIG. 27. The filter menu may also include a "pile by file" function that works similarly to the stacking function described above with respect to fig. 15 and 16, e.g., a "file type" filter may have selections for "Excel," PowerPoint, "" Word, "and also" pile by file type. Selecting "press.. to stack" the functional view changes the heap that displays the different file types.

In general, filters may be set to apply to different attributes of a file or item. In one embodiment, filters may be classified according to different types, for example: indexing by letters; a discrete value; a date; and numerical ranges. Typical attributes for an alphabetical index may include name, author, artist, intimate contact name, owner, author of the document, title of the document, subject matter of the document, and description. Typical attributes for discrete values may include location, file type (name of application), style, track, year (for music), listening rate (for music), bit rate, protected, document classification, document page count, document notes, camera model, size, product name, product model, image X, image Y, and time of document creation. Typical attributes about the date may include last access, last modification, creation, taking (about a picture). A typical attribute for a range of values may be file size.

It should be apparent that the filters described above with respect to fig. 24-29 allow a user to narrow down a list of items to find a particular item of interest. As a specific example, according to the process described above, a user may narrow down the current list of documents to display only the Microsoft Word files that were made by a particular person and edited the last week. This functionality enables a user to find a particular item in a list having many items, eliminating the need for the user to manually scan each item in the list.

FIG. 30 is a flow diagram illustrative of a routine 940 for creating a new quick link. As will be explained in more detail below, quick links are predefined links that a user can click on to create a view of the set of items that he has selected. In one embodiment, a quick link may be viewed as a type of primary element. Quick links provide a mechanism for retrieving virtual folders. Clicking on a quick link may take the user to a desired folder (in the same manner that clicking on a "favorites" takes the user to a Web site). The quick link may be predefined by the system or may be set by the user. Clicking on "all authors" for example, may result in a view stacked by author. Clicking on "all documents" may obtain a flat view of all documents on all storage areas. Users can also create their own quick links.

As shown in FIG. 30, at a block 942, the user makes a selection on the display screen to indicate whether the quick link should be formed from the current filter criteria or navigation. At block 944, the user provides a new name for the new quick link. At block 946, the new quick link is saved and the quick link section provides the name of the new quick link on the display.

Fig. 31 is a diagram illustrating a screen display for creating a new quick link called "january work" based on the filtering in fig. 29. As previously described, in FIG. 29, the heap has been filtered for January. In FIG. 31, the user has indicated that the filter in FIG. 29 should be stored as a new quick link, and has named the new quick link "January work". Thus, a new monthly job quick link 612 is displayed in the quick link portion of the display screen. As for forming new quick links, the user is typically provided with an option like "store this collection as a quick link".

Fig. 32 is a diagram illustrating a screen display in which the quick link "all authors" is selected. As shown in FIG. 32, the selection box SB is displayed around the "all authors" selection 611. Other examples of collections that may be accessed by quick links include "all authors", "recent documents", "all documents i have shared", "all i authored documents", "all not i authored documents", "desktop", and "all types".

Fig. 33 is a diagram illustrating a screen display in which authors of all items in fig. 32 are presented. As shown in fig. 33, an information line 950 is provided which indicates columns for displaying the name, author, modification date, type, size, and location of the item. A list of authors 951-954 are shown corresponding to authors 1-4, respectively.

Fig. 34 is a diagram illustrating a screen display in which "author 1" has been selected from the list in fig. 33. The author 1's documents include documents 951A and 951B, corresponding to document 1 and document 2, respectively. Document 951A is shown authored by author 1, modified at 11.7.2001, to be a Microsoft Excel file occupying 282Kb of storage space, derived from the location of \ \ server 1\ folder 2. Document 951B is shown authored by author 1, modified at 12 months and 22 days 2002, is a Microsoft Word file, occupies 206 kilobytes of storage, and is physically stored in my document \ folder 1 location. 951A and 951B locations also illustrate that virtual folders in the present invention may contain entries from different physical locations, as will be described in more detail below.

FIG. 35 is a flow chart illustrating a routine 960 for creating a new library. An example of a library is the document library described above with reference to fig. 10. Typically, libraries are made up of large groups of useful types of files that can be linked together. For example, photos may be one library, music may be another, and documents may be another. The library may provide tools and behaviors related to particular types of items. For example, in a photo library, there may be tools and filters involved in manipulating photos, such as creating a slide show or sharing photos. As shown in FIG. 35, at a block 962, a new library is created to include entries having the selected characteristics. At block 964, the selected entries are grouped into a library. At a block 966, selected personality tools and/or behaviors related to the item or other desired functionality are provided.

FIG. 36 illustrates a diagram of a screen display showing a collection of active libraries. As shown in fig. 36, these libraries include a documents library 971, a photos and videos library 972, a music library 973, a messages library 974, a contacts library 975, and a tv and movies library 976, as well as an all items library 977. The all entries store 977 is shown to include 275 entries, which is the total number of entries from all other stores in combination. The information line 644 indicates that a total of 275 entries occupy a total of 700MB of memory space. It should be noted that the document library 971 is the one previously described with respect to FIG. 10.

FIG. 37 is a flow diagram illustrative of a routine 990 for defining a set of virtual folders. As will be described in more detail below, the virtual folder system is able to present items from several physical locations (e.g., different hard disks, different computers, different network locations), so all of the items are easily accessible to the user. For example, music files from several physical locations may be provided to a user on a single display screen and all of the files may be manipulated at once.

As shown in FIG. 37, at block 992, a range of physical locations is defined for extracting the entry. At block 994, in response to the query, an entry is extracted from the physical addresses defined in this range. At block 996, all of the entries extracted by the query are presented on a single display.

FIG. 38 is a block diagram illustrating various sources that may form a scope of a virtual folder collection. As shown in FIG. 38, the system 1000 may include a current computer 1010, another computer 1020, external removable storage 1030, and a location 1040 on a network. The total range 1001 is depicted as including all the physical addresses from which the user's entries are extracted to create a collection. This range can be set and modified by the user. As previously mentioned, other figures have illustrated that the entries may come from different physical locations, for example FIG. 34 shows different documents from the "My documents" folder on one server and the current computer, while FIG. 18 shows physical folders that are physically stored in several locations.

FIG. 39 is a flowchart illustrating an exemplary program 1080 for adding non-file entries in a virtual folder collection. Non-file entries are in contrast to file entries typically located in physical file storage. Examples of non-file entries would be things like e-mail, contacts, etc. As shown in FIG. 39, at a block 1082, the database is used to contain non-file entries along with file entries that can be retrieved by the query. At block 1084, in response to the query, both non-file entries and file entries are extracted to match the query. At block 1086, both the non-file entries and the file entries matching the query are displayed on the display screen.

Fig. 40 is a diagram illustrating a screen display showing various non-file entries. As shown in FIG. 40, the entries have been filtered to include those of "John". These entries are shown to include a contact entry 1101, an email entry 1102, and file entries 1103 and 1104. The contact entry 1101 and the email entry 1102 are non-file entries. Current systems allow such non-file entries to be added with regular files so that they can be organized and manipulated as desired by the user. As previously described with respect to FIG. 2, such non-file entries may be included entirely in the relational database 230 that also includes file attribute information.

While the preferred embodiments of the present invention have been illustrated and described, various changes can be made without departing from the spirit and scope of the invention.

Claims (15)

1. In a computer system having a display and a memory for storing items, a method of viewing a selected item, the method comprising:

navigating to a view of a set of desired items, wherein the set of desired items includes one or more virtual folders configured to present items to a user in one or more different views based on a value of one of a plurality of metadata attributes of the items in the set of desired items and not based on an actual physical underlying file system structure of the items on the storage, wherein the items are physically stored in storage at different physical locations;

saving a link to the desired set of items;

providing a name for the link; and

the link is displayed on the display screen so that by clicking on the link, the user can return to the view of the desired set of items.

2. The method of claim 1, wherein navigating to a view of a collection of desired items comprises filtering a set of items.

3. The method of claim 1, wherein the name of the link is displayed on the display screen along with the names of a plurality of additional links that the user may also select to return to a view of the desired collection of items.

4. The method of claim 1, wherein the set of desired items comprises items stored at different physical locations.

5. The method of claim 4, wherein the different physical locations include a current computer and at least one of a different computer, a location on a network, and an external storage device.

6. The method of claim 1, wherein the set of desired items includes file items and non-file items.

7. The method of claim 6, wherein non-file entries include at least one of contacts and emails.

8. A method for viewing items, the method comprising:

navigating to a view of a set of desired items, wherein the set of desired items includes one or more virtual folders configured to present items to a user in one or more different views based on a value of one of a plurality of metadata attributes of the items in the set of desired items and not based on an actual physical underlying file system structure of the items on storage, wherein the items are physically stored in storage at different physical locations;

saving a link to the desired set of items;

providing a name for the link; and

the link is displayed on the display screen so that by clicking on the link, the user can return a view of the desired collection of items.

9. The method of claim 8, wherein navigating to a view of a collection of desired items comprises filtering a set of items.

10. The method of claim 8, wherein the set of desired entries includes entries stored in different physical locations.

11. The method of claim 8, wherein the set of desired items includes file items and non-file items.

12. A system for viewing a selected entry, comprising:

means for navigating to a view of a desired set of items;

means for maintaining a link to the desired set of items; and

means for displaying the link on a display screen such that by selecting the link, the user can return a view of the desired set of items;

the system further includes means for providing a virtual folder included in the set of intended items, the virtual folder configured to present the items to a user in different views based on a value of one of a plurality of metadata attributes of the items in the set of intended items, wherein the items are physically stored in memory at different physical locations, and not based on an actual physical underlying file system structure of the items on the memory.

13. The system of claim 12, further comprising means for filtering a set of items that are part of a set of navigated to desired items.

14. The system of claim 12, further comprising means for extracting items from different physical locations to be included in the desired set of items.

15. The system of claim 12, further comprising means for extracting file entries and non-file entries to be included in the set of desired entries.