System and method for utilizing search trees and tagging data items for data collection management tasks

Abstract

To provide a method and system for presenting a search tree session of a storage tree associated with a collection of data items to a user.SOLUTION: In the method, first, a computer accessing the storage tree receives a search query. The search query includes one or more verbal or non-verbal conditions for searching the storage tree. The method also creates a search tree 19200 including one or more search tree nodes based on the search query, creates one or more grouped search tree nodes each including a search tree node, node presentation parameters corresponding to how the node is to be displayed, and search query parameters corresponding to the search query, and then creates and causes a display to output a search tree representation incorporating at least one of the grouped search tree nodes for display to the user.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] This specification relates generally to the design of file management systems, and more specifically to using single-panel display interfaces, search trees, storage trees, grouping trees, and data tagging to create accessible and intuitive user interfaces for data collection management tasks. [Background technology]

[0002] Many computer systems use static hierarchical file managers or file browsers, which are computer programs that provide a user interface for managing files and folders. Many users rely on such file managers to store and retrieve their valuable data on their computers. While file managers and file browsers typically use a folder tree structure for storing, representing, and retrieving data, they often also provide search capabilities, allowing quick and direct access to files based on keyword or non-keyword criteria, or both.

[0003] Static hierarchical storage structures, or trees, allow users to store data in a manner similar to the way the physical world works, in that objects and items can be found in predictable locations that can be accessed by taking predictable steps. These structures often allow users to apply real-world intuition to the task of locating related data by considering natural relationships that may exist between data. Such structures are generally designed to enable new users to understand the relationships between folders and subfolders and navigate the structure to data of interest. In this way, static hierarchical structures create a path of folders and subfolders that can be used to uniquely identify the location of data within the structure.

[0004] However, file management and viewing interfaces have changed little since their early introduction. It is often difficult for users to locate and view all relevant data and effectively identify and navigate to desired data items, and many interfaces lack customization to create an accessible and familiar structure. Current interfaces can be confusing, unintuitive, complex, and difficult to access for users, and these problems are exacerbated as the amount and complexity of data increases. For both work and recreation, unintuitive and inaccessible interfaces waste time, frustrate users, and can cause users to overlook or be unable to retrieve relevant data.

[0005] Thus, there is a need for improvements in the art. Summary of the Invention

[0006] According to an aspect of the present invention, there is provided a computer-implemented method for presenting to a user a search tree session of a storage tree associated with a collection of data items, the method comprising, when executed on a processor, a computer configured to access the storage tree associated with the collection of data items and to be capable of accessing a display, the method comprising: receiving a search query from a user, the search query including one or more linguistic or non-linguistic criteria for searching the storage tree associated with the collection of data items; creating a search tree of the storage tree associated with the collection of data items based on the search query, the search tree including one or more search tree nodes; creating one or more grouped search tree nodes, each grouped search tree node comprising the search tree node, node presentation parameters corresponding to how the node is to be displayed to the user, and search query parameters corresponding to the user's search query; creating a search tree representation for display to the user incorporating at least one of the one or more grouped search tree nodes; and outputting the search tree representation to the display.

[0007] According to an aspect of the present invention, there is provided a non-transitory computer-readable medium comprising computer-readable instructions that, when executed by a computer processor, perform a method on a computer configured to access a storage tree associated with a collection of data items and capable of accessing a display: receiving a search query from a user, the search query including one or more linguistic or non-linguistic criteria for searching a storage tree associated with the collection of data items; creating a search tree of the storage tree associated with the collection of data items based on the search query, the search tree including one or more search tree nodes; creating one or more grouped search tree nodes, each grouped search tree node comprising the search tree node, node presentation parameters corresponding to how the node is to be displayed to a user, and search query parameters corresponding to the user's search query; creating a search tree representation for display to a user that incorporates at least one of the one or more grouped search tree nodes; and outputting the search tree representation to a display.

[0008] According to an aspect of the present invention, there is provided a computer system for presenting a search tree representation to a user on a display, the computer system comprising: non-transitory computer memory storing at least one storage tree and at least one associated collection of data items; at least one processor in communication with the non-transitory computer memory; and a display for presenting the search tree representation, the non-transitory computer memory being configured, when executed by the at least one processor, to access the storage tree associated with the collection of data items and to access the display, the computer system comprising: receiving a search query from a user, the search query being associated with the collection of data items; the search tree includes one or more linguistic or non-linguistic criteria for searching the storage tree associated with the collection of data items based on the search query; creating a search tree of the storage tree associated with the collection of data items based on the search query, the search tree including one or more search tree nodes; creating one or more grouped search tree nodes, each grouped search tree node comprising the search tree node, node presentation parameters corresponding to how the node is to be displayed to the user, and search query parameters corresponding to the user's search query; creating a search tree representation for display to the user that incorporates at least one of the one or more grouped search tree nodes; and outputting the search tree representation to a display.

[0009] In an embodiment of the present invention, there is a file management system that uses a single panel display interface, a search tree, a folder tree, a grouping tree, and data tagging.

[0010] In an embodiment of the present invention, the search tree is browsed using a position indicator for the current node and a single main content display panel. Browsing is facilitated by incorporating non-verbal conditions in the form of subnode toggle, search result toggle, selection, and open functions. According to a further embodiment, the subnode toggle, search result toggle, selection, and open functions are implemented, alone or in combination, as buttons, menu options, or other provisions provided by the operating system or application program.

[0011] In an embodiment of the present invention, there are different viewing modes for the storage tree, search tree, or grouped search tree nodes.

[0012] In an embodiment of the present invention, the display and file access controls are user customizable.

[0013] In an embodiment of the present invention, attributes and properties are displayed as file and folder details for use in identifying, distinguishing, accessing, or organizing the files or folders.

[0014] In an embodiment of the present invention, there is collection-based grouping and access of folders and search tree nodes across folder trees and different search trees. According to a further embodiment, folders and search tree nodes are grouped and accessed across storage folder trees and search trees by associating each folder and search tree node with a list of at least one folder or search tree node, each folder or search tree node in the list representing the same data collection as the folder or search tree node itself.

[0015] In an embodiment of the present invention, a request may be received that specifies a search node in a search tree structure and a data item associated with another search node that is in the same search tree structure and that discards an existing association of the data item with the first search node and simultaneously establishes a new association of the data item with the second search node.

[0016] In an embodiment of the present invention, a request may be received specifying a search node in the search tree structure and a data item associated with another search node that applies to the same collection as the first search node and establishes a new association between the data item and the second search node.

[0017] In an embodiment of the present invention, there is a grouping mode and means for creating and maintaining grouped search tree nodes within the search tree structure, and the presentation aspect of a search node is decoupled from its operational aspect by associating values ​​related to node presentation and values ​​representing the search query with a single node.

[0018] In an embodiment of the present invention, a request may be received to create a new grouping node with no search query specified and an empty search result set.

[0019] In an embodiment of the present invention, an Uncategorized group is automatically created to encompass all data items that are not logically included in the categorized groups of a grouped search tree node.

[0020] In an embodiment of the present invention, a request may be received to specify two or more items under the same search result set and create a new grouped search node under the current node where the search result items are the data items for the request.

[0021] In an embodiment of the present invention, a request may be received to specify a search node within a search tree structure and display a preview or overview of the search node.

[0022] In embodiments of the present invention, identification-only (ID-only) search tree nodes may be created, maintained, and attached below regular search nodes in the search tree structure to identify specific data items within a collection defined by a regular (parent) search node for any particular processing routine by association with the node's own node type indicator, operation identifier (operation ID), and search query.

[0023] In an embodiment of the present invention, a processing routine is present to customize the presentation of a search node based on a customized selection of data items within the collection defined by the search node.

[0024] In an embodiment of the present invention, a processing routine exists for providing direct access to a customized selection of data items within a collection defined by a search node.

[0025] In an embodiment of the present invention, tags are used in the form of name:value pairs, along with interfaces and routines for recognizing the name:value pairs and distinguishing between tag values ​​and tag group names when search queries are entered into and processed in the system. According to a further embodiment, tags can be grouped by tagging tags by adding a common group tag to tags that belong to a user-identified unifiable group.

[0026] In embodiments of the present invention, data items may be moved or copied by a drag and drop operation that detaches one or more tags corresponding to a current group and attaches one or more tags corresponding to a new group when moving at least one data item, or attaches one or more tags corresponding to a new group when copying at least one data item.

[0027] In an embodiment of the present invention, there is a means to present the storage folder structure of a parent folder, with the integrity of the folder's contents always maintained, and both subfolders and individual files can be displayed simultaneously in a variety of formats.

[0028] In an embodiment of the present invention, a search engine is provided that caches or stores customized data item selections not as a static list, but as a search query to the search engine, ensuring that the list resulting from the search query is always up to date, even if the data items have been moved or renamed since their creation.

[0029] In an embodiment of the present invention, there is a folder-aware mode for search request processing. According to a further embodiment, the search request processing system automatically projects search features downward from a parent folder to its subfolders and files for a positive identification search request, or automatically pulls matches upward from subfolders and files to their parent folder for a full or partial negation request. According to a further embodiment, the search request processing system maintains context and hierarchical information with consistency and completeness for positive identification and full or partial negation search requests. According to a further embodiment, the search request processing system returns a minimal set of folders and files from the folder structure as a representation of a complete result set for the search request represented by at least one of the search tree nodes after parent-child relationships within the storage folder tree are recognized and respected by the system.

[0030] Other aspects and features of the present application will become apparent to those skilled in the art upon review of the following description of embodiments of the invention in conjunction with the accompanying drawings.

[0031] The principles of the present invention may be better understood with reference to the accompanying drawings, which illustrate one or more exemplary embodiments incorporating the principles and aspects of the present invention. [Brief explanation of the drawings]

[0032] [Figure 1] 10 illustrates an embodiment in which a sub-panel has two or more user interfaces. [Figure 2a-2b] Portrait and top-bottom display layouts are shown. [Figure 3] 1 illustrates a display layout in which tree and data content are displayed and managed separately in different display panels within a multi-panel interface. [Figures 4a-4c] 1 illustrates an embodiment of a navigable single panel display. [Figure 5] An embodiment is shown in which, after visiting all tree nodes, the user is able to reach all of the data items in the tree below the root node. [Figures 6a-6n] 1 illustrates an embodiment of a single display panel having a subnode toggle button, a search result toggle button, a select button, and an open button. [Figures 7a-7d] 1 illustrates a content display embodiment for search groups and individual result items. [Figure 8] 13 shows an embodiment with button-style selection functionality and an auxiliary detail display sub-panel. [Figures 9a-9c] 1 illustrates an embodiment of a presentation of folders and search nodes with respect to their contents. [Figures 10a-10c] 10 illustrates an embodiment of a view option for a storage folder tree. [Figure 11] 1 illustrates a list embodiment of a collection representation, where the entries are lists of folder and node presentations. [Figure 12a-12b] 1 illustrates an embodiment in which image files may be tagged and then grouped by tag name. [Figure 13] 1 illustrates an embodiment with a classifiable data item before the searchable features are updated and the data item is moved from the unclassified group to one of the classified groups. [Figure 14] 1 illustrates an embodiment both during and after a data item is moved by a drag and drop operation. [Figure 15]13 shows an embodiment with a "Create a new group" button. [Figures 16a-16b] 1 shows an embodiment both before and after data items are manually distributed into unnamed categorized groups. [Figure 17] 13 illustrates an embodiment with a popup preview of group content. [Figure 18] 13 illustrates an embodiment with an editable text field for updating the face name of an unnamed group. [Figure 19] 1 illustrates an embodiment with different browsing modes for the folder tree, search tree, and grouping tree. [Figures 20a-20b] 1 illustrates an embodiment with intuitive group names and visual graphic previews of individual items within a search group. [Figure 21a-21b] 10 illustrates an embodiment with customizable group presentation and file access control using checkboxes or auxiliary display panels. [Figure 22] 1 illustrates an embodiment in which attributes and properties may be displayed as file and folder details for use in identifying, distinguishing, accessing, and organizing files and folders. [Figure 23] 1 shows a long list of possible attributes and properties that are provided to the user in an embodiment. [Figure 24a-24b] 10 illustrates an embodiment in which user-defined tags may be presented similarly to system-generated properties and displayed in columns alongside other detail groups in the interface for individual values. [Figure 25a-25b] 1 illustrates an embodiment in which tags can be grouped by tagging them through an interface and may have auto-completion or other operating system assistance in adding and using group name tags. [Figure 26] An embodiment is shown in which, after tags with similar characteristics have been grouped, additional file types may be added as options for classification and presentation. [Figure 27]An embodiment is shown in which a user can specify a keyword type when searching within a search interface to determine how tag group names are treated. [Figures 28a-28g] 1 illustrates an embodiment with customizable classification functionality and interface. [Figure 29] Illustrates an embodiment in which files are first grouped by one value and then classified by another value. [Figure 30] 1 illustrates an interface embodiment that allows for multi-level categorization and grouping. [Fig. 31a-31f] 1 shows an embodiment folder presentation with a child list toggle, an individual item toggle, a select button, and an open button. [Figures 32a-32d] 1 shows a sample storage folder structure and its search tree representation. [Figure 33] We present a problem that persists even when files have the same searchable characteristics and are listed under the same search node as their parent or containing folder. [Figure 34] Illustrate why it is problematic to expand folders listed under a search node so that the files within the folders appear under the same search node. [Figure 35] 1 illustrates an embodiment with a top-level match folder in a search result set when conventional search processing is used. [Figure 36] An embodiment is shown in which duplicate or conflicting folders and files do not appear in the results presentation, provided that the top-level folder appears only once in the search result set. [Figure 37a-37b] 1 illustrates an embodiment with a same level presentation of folders and individual files. [Fig. 38a-38b] 1 illustrates an embodiment that compares folder and search tree structures for folders and files both before and after reorganization. [Figures 39a-39d] 1 illustrates an embodiment of a folder structure in which files are separated first by date and then by location. [Figure 40] 1 illustrates an embodiment of a search request processing system. [Figure 41] 1 illustrates an embodiment in which a categorized search node can represent a partial negative search request when viewed by itself under an uncategorized node in the overall search tree structure. DETAILED DESCRIPTION OF THE INVENTION

[0033] The following description and the embodiments described herein are provided by way of illustrating one or more examples of particular embodiments of the principles of the present invention. These examples are provided for purposes of illustrating, not limiting, those principles and the present invention. In this description, like parts are designated with the same respective reference numerals throughout the specification and drawings. The drawings are not necessarily to scale, and in some cases, proportions may be exaggerated to more clearly show certain features of the present invention.

[0034] This description relates to the design of a file management system. In particular, this description relates to the use of single-panel display interfaces, search trees, folder trees, grouping trees, and data tagging to create an accessible and intuitive user interface for collection management tasks.

[0035] While data, data items, and data collections are often stored in static representations and retrieval structures, data retrieval and management can benefit from non-static representations and retrieval structures. Users may benefit from the incidental display of various files in an easy-to-read format that maximizes data visibility and control. A highly customizable file management system can increase the accessibility of data originally stored in non-intuitive locations and minimize the need for users to duplicate data storage solely for ease of access. Improved customization also overcomes challenges associated with handling pieces of data that may reasonably fit into multiple storage locations, especially when those storage locations appear to be mutually exclusive, enabling data to be quickly located when needed.

[0036] The search tree may further be constructed so that related search requests are collected and managed together, and data files on a computer may be dynamically divided into folder-style hierarchical groups as opposed to being statically stored in a data storage folder tree structure for collection management and data retrieval.

[0037] For example, a single photo collection stored in a folder can be sorted using different search trees at different times, or in parallel at the same time, e.g., by photo location or date. Within a search tree, one tree node represents a single search request, such as "list all items in the photos folder" for the first-level root node, or "list all items in the photos folder that match both the keywords Europe and 2002" for the third-level subnode "2002" under the second-level subnode "Europe."

[0038] By adding an additional layer between the user and the storage structure they are searching, a search tree can provide an additional logical representation of files and folders that are independent of the storage tree items, and sets or collections of data or data items or pieces associated with the storage tree. Thus, when properly implemented, a search tree can be dynamically built, modified, and erased without any impact on any part of the underlying data storage structure to provide an intuitive design that makes data more accessible.

[0039] Aspects of the present invention relate to a system and method for browsing a search tree using a location indicator for a current node and a single main content display panel. The location indicator is initially blank, and the root search node is initially displayed as a list of collapsed nodes in the content display panel. A search node in the content display panel can be selected and opened by pointing the location indicator to it and overwriting and filling the content display panel with one of two types of content for the search node: a list of its subnodes as a list of collapsed nodes if the node being opened is a parent node, or a list of search result items if the node being opened is a leaf node. Any visible search node in the content display panel may have additional controls attached that operate without updating the location indicator for the current node. These include toggle buttons for expanding and collapsing the display of the list of subnodes; the toggle is present if the target node is a parent node and the toggle is absent if the target node is a leaf node. These controls also include toggle buttons for expanding and collapsing the display of the list of search result items, and a selection button that is itself highlighted and associated with additional context menu options or other operations. Also, the open and expand operations can be merged into a single step, where if the node being opened is a parent node, its subnodes are listed as a list of collapsed nodes, and if the uncategorized subnode is a leaf node, the uncategorized subnode is expanded and displayed as a list of individual search result items.

[0040] Aspects of the present invention relate to a system and method for providing collection-based grouping and access of folders and search tree nodes across storage folder trees and different search trees. This can be done by associating, for each folder and search tree node managed in the system, a list of folders (if applicable) and one or more search tree nodes, including the folder or search tree node itself, where each folder or search tree node in the list represents the same collection of data as the folder or search tree node itself. When a folder or tree node is displayed and manipulated, a corresponding list of identical collection nodes is simultaneously made available, either by providing a handle, indicator, or toggle for displaying the list, or for accessing and displaying another node in the list, or by automatically triggering the display of all folders and nodes in the list.

[0041] Aspects of the invention relate to receiving a request specifying a search node in a search tree structure and a data item associated with another search node in the same search tree structure, which request discards an existing association between the data item and the first search node and simultaneously establishes a new association between the data item and the second search node. This is done by removing features and properties corresponding to the search query terms represented by the first search node and adding features and properties corresponding to the search query terms represented by the second search node. If one or more associations cannot be discarded or established, the user is alerted about one or more conflicts.

[0042] Aspects of the invention involve receiving a request specifying a search node in a search tree structure and a data item associated with another search node that applies to the same collection as the first search node and establishes a new association between the data item and the second search node by adding features and properties corresponding to the search query conditions represented by the second search node. If one or more associations cannot be established, the user is alerted to one or more conflicts.

[0043] Aspects of the present invention relate to a grouping mode and a system and method for creating and maintaining grouped search tree nodes in a search tree structure in which the presentation aspect of a search node is decoupled from the operational aspect by associating two pieces of information with a single node: a value for the node presentation and a value representing the search query. A regular search node that represents only the search query can be converted to a grouping node by duplicating the search query as the value for the node presentation so that they can be updated independently at different times.

[0044] Aspects of the present invention relate to systems and methods for receiving a request without a specified search query, creating a new grouping with empty search results by automatically generating a face name as a value for the note presentation and a globally unique search ID as a value representing the search query, and creating a new search tree presentation or modifying an existing search tree presentation by adding a new grouping node and associating the new node with the face name and the globally unique search ID.

[0045] Aspects of the present invention relate to a system and method that receives a request specifying two or more items under the same search node in the same search result set, and creates a new grouping search node under the current node where the search result items are the data items for the request. This can be achieved by tagging the data items with a system-generated globally unique search ID, adding a new grouping subnode, and modifying the existing search tree presentation for the current node by associating the new node with a face name and a globally unique search ID.

[0046] Aspects of the present invention relate to systems and methods for receiving a request specifying a search node within a search tree structure and displaying a preview or overview of the search node. Such a preview or overview may include a visualization of one or more data items within the node or a text description of one or more data items within the node. Such a request may be triggered by dragging a data item or items from another search node within the same search tree structure and moving the one or more items over the first search node, or by a hovering event (mouseover) over the first search node.

[0047] An embodiment of the present invention relates to a system and method for creating and maintaining ID-only search tree nodes attached under a regular (parent) search node in a search tree structure to identify specific data items within a collection defined by the regular (parent) search node for any particular processing routine by associating three pieces of information with the single node: The first piece of information is a node type indicator for excluding or isolating the node itself from regular operations and interactions with any other subnodes, including any other ID-only subnodes, using either an explicit indicator when the ID-only node is stored together in a regular subnode list under the parent search node or an implicit indicator when the ID-only node is stored in a separate, dedicated list under the parent search node for the "ID-only" subnode; The second piece of information is an operation ID for associating the node with a processing routine that retrieves data items within the collection via the ID-only subnode; and The last piece of information is a search query that includes a "grouping" node or an anonymous grouping node to identify data items within the collection.

[0048] Aspects of the present invention relate to systems and methods that use processing routines to customize the presentation of a search node based on a customized selection of data items within a collection defined by the search node. This may be accomplished by providing an interface for a user to select one or more data items from the search node, representing the selection using a search query, storing the selection, and presenting the search node. In particular, the selection may be represented as a grouping criterion or, if the selection is singular, as a system-generated, globally unique search ID. The selection may be stored by creating an ID-only subnode under the search node and attaching an operation ID that links the processing routine for customization and the search query for the user-defined selection. The search node may be presented by checking whether an ID-only subnode with the appropriate operation ID exists under the search node, evaluating the search query from the ID-only subnode against the collection, and returning a search result set. If the selection (search result set) exists and is not empty, the presentation may be customized using a visualization image or text description of the selected data item(s), or using other customized or default settings.

[0049] Aspects of the present invention relate to a special access mode that uses processing routines to provide direct access to customized data item selections within a collection defined by a search node. This can be done by following system steps that select, store, and present a search node by linking it to a processing routine for direct access and incorporating an operation ID that sends the data item selections to a default program for the selected item's corresponding data type(s) so that the data items are directly opened when an open operation is triggered at the search node. If a selection (search result set) exists and is not empty, the data item selections are linked to the default program for opening the items. Otherwise, the search node is opened normally.

[0050] Aspects of the present invention relate to systems and methods that use tags in the form of name:value pairs. In particular, an interface exists for specifying an additional field for the tag group name when entering new tags, editing or modifying existing tags, and deleting old tags. Name:value pairs may be conventionally stored as text tag entries, e.g., defining a separator and inserting it between the text for the "name" and the text for the "value." Routines may also exist for parsing, recognizing, and interpreting tag name:value pairs and consolidating the presentation of different tag values ​​under the same tag group name in a tabular (spreadsheet) format, where the value may be text, an indicator for presentation, or any type of data that can be handled by the system. Alternatively, in data management tasks, the routines may recognize tag group names as well as other property names generated and maintained by the system, and additionally recognize different tag values ​​under the same tag group name as well as other property values ​​generated and maintained by the system. Interfaces and routines also exist for recognizing name:value pairs and distinguishing tag group names from tag values ​​when search queries are entered into and processed by the system.

[0051] An aspect of the present invention relates to a method for presenting a storage folder structure for a parent folder in which both subfolders and individual files can be displayed simultaneously in various formats, while always maintaining the integrity of the folder's contents. A parent folder in a content display panel may have a control attached and operate without affecting the parent folder's position or placement in the overall presentation. A toggle function is incorporated to expand and collapse the display of a list of all subnodes and individual child files immediately under the target parent folder, if any; if the target folder has a list of subfolders, the toggle is present; and if the target folder does not have subfolders, the toggle is absent. A toggle function is incorporated to expand and collapse the display of the complete list of individual child files under the target parent folder without revealing any subfolders.

[0052] Aspects of the present invention relate to a folder-aware mode for processing search requests in which a minimal set of folders and files in a folder structure is returned as a representation of the complete result set for a search request represented by a search tree node after parent-child relationships in a storage folder tree are recognized and respected by the system. Only top-level parent folders matching the search request are returned in the result set for a search node in the search tree structure. The list of top-level folder tree representations is located directly under the search tree node in the search tree representation, or displayed separately from the corresponding search tree node in the same display area after the search node is opened, or displayed in a separate display area after the search node is selected. All subfolders or files matching the same search request are presented, as needed and upon request, under their respective top-level parent folders using a folder tree representation that ensures the completeness of folder contents in various formats. For all positive-identification search requests without a Boolean NOT operator, the result set is always the maximal set that a folder representation can represent, including the top-level folder and each subfolder and file within the top-level folder. For full or partial negation search requests with at least one Boolean NOT operator, the result set can be either the complete set or a subset that the folder presentation can represent. To present the subset, folders in the folder tree presentation, including the top-level folder or any subfolders, are distinguished and marked using a color or symbol scheme based on or derived from the match status of the content under the folder. If none of the content matches the same search request as the parent folder itself, the parent folder is marked as a logical mismatch and invalid or canceled. If all of the content matches the same search request as the parent folder itself, or if the parent folder is empty and has no content of its own, the parent folder is marked as a full match or presented normally. If only some, but not all, of the content matches the same search request as the parent folder itself, the parent folder is marked as a partial match.All subfolders and files directly under a partially matching parent folder are always visible when the parent folder is expanded, but they must be distinguished and marked using a color or symbol scheme. For folders, if the folder itself does not match the same negative requirements as the parent folder, it is distinguished or marked as a mismatch; if the folder itself matches the same negative requirements as the parent folder, it is distinguished or marked as a logical mismatch and invalid, exact match, or partial match; in this case, the folder's state is recursively set based on its contents. For files, mismatch or match, and typically, depends on whether the file itself matches the same negative requirements as the parent folder. Individual file items that match a search request are returned in the result set for a search node in the search tree structure only if they do not belong to any of the folders that match the same search request. A list of individual files may be located directly under the search tree node in the search tree presentation as part of the search result set, or may be displayed separately from the corresponding search tree node in the same display area after the search node is opened, or may be displayed in a separate display area after the search node is selected.

[0053] Viewing the traditional search tree

[0054] According to the present invention, when a (parent) search node is divided into subnodes or subgroups, uncategorized (sibling) subnodes or groups are automatically created and managed to represent the set of categorized items under this same parent node (to complement all explicitly specified subnodes or subgroups), respectively, so that no items in the collection are missing from the search tree representation. This maintains data integrity throughout the collection, and the search tree is qualified to manage a data collection. According to an embodiment, the root node is not a subnode of any parent node, and therefore does not have any uncategorized sibling nodes (at the root level).

[0055] According to the embodiment shown in FIG. 1 , a user interface 1000 with two or more sub-panels may be used to present and manage the search tree and content for a search tree node having a currently selected tree node component 1100, a navigation sub-panel for tree content 1200, and a results display sub-panel for data content 1300 having the search tree content and structure shown in the tree navigation sub-panel 1200 on the left side of FIG. 1 , and the data content of the current tree node (i.e., the search result items discovered for the selected search node in the navigation sub-panel) displayed in the results display sub-panel 1300 in the center of FIG. 1 .

[0056] According to an embodiment, a user may control and adjust the display of search tree nodes within the tree navigation sub-panel and then select a node for which search results are displayed within the control sub-panel 1200 after the search query represented by the node is evaluated against the underlying data collection.

[0057] While such an interface feels natural to users because clicking on a search tree node correlates quite well with issuing search results, it is not always easy to arrange multiple sub-panels within the available display area. For example, when the overall display area size switches from landscape to portrait orientation, the tree navigation sub-panel 2010, 2110 may require scrolling 2130 functionality to fully display the information, and the content sub-panel 2020, 2120 may be too small for details when the two panels are maintained side-by-side as in Figure 2(a) 2000 or when presented in a top-to-bottom layout as in Figure 2(b) 2100. Therefore, a single display panel configuration may be more appropriate for the display area in these instances.

[0058] According to an embodiment, data stored in a hierarchical tree structure can be displayed and managed in a single display configuration, with a fixed-position browsing mechanism where the contents of one current portion or node of the tree structure are displayed within a display panel. According to an embodiment, navigation and traversal of the tree is performed by changing the position of the current portion or node through some node release (and retract and restore) functions.

[0059] According to an embodiment, since all nodes in the tree have one clear path from the root node to their position in the tree structure, the contents of any node can be displayed by successively opening the root node, then all (parent) nodes, and finally the current node along the path. According to an embodiment, a "back" or "up" control is provided, so that the contents of parent nodes along the path leading up to the root node can be restored one by one in the reverse order that they were opened, before another node under the same root (or same parent) can be reached and opened following that path.

[0060] According to embodiments, additional data may be associated with the tree nodes. According to further embodiments, every node in the tree has tree content that includes information about whether the node is a parent node with a list of child subnodes hierarchically below it in a tree hierarchy navigation structure, or whether it is itself a leaf node. According to embodiments, every node in the tree has data content that includes any data associated with the tree node other than tree content. For example, in the case of an embodiment storage folder tree, every folder is a node within the folder that may include a list of subfolders (if any) as its tree content, or a list of individual files as its data content.

[0061] According to an embodiment, the tree and data content are independent of each other. According to a further embodiment, a tree node and its tree content are always in a logical parent-child relationship so that the hierarchical tree structure is properly maintained. In contrast, a tree node and its data content may have various kinds of relationships. According to a further embodiment, these relationships include parent-child relationships (such as a parent folder and a file within that folder), a different presentation format of the current node itself, or any other relationship that occurs with a node.

[0062] Typically, the current nodes of two different types of content are arranged separately in a single display configuration, generally resulting in a two-step tree presentation. Such a two-step procedure displays the tree content of the current node in the display area using the conventions described above, and the data content can then be arranged alongside the tree content in the display area if the application program's design allows. By separating the presentation of the tree content from the presentation of the data content, if a list of subnodes exists, this is always available first and is quickly opened one by one in the display area so that the tree structure can be navigated and browsed using the tree browsing conventions, regardless of how the data content is subsequently presented (if at all). In some cases, depending on the type of data content, the two steps can be combined. One example of such a combination is a file management system in which, when logically appropriate, both subfolders and files are presented together in the display area, as if the two lists were handled similarly (in one step) for the current folder.

[0063] In the case of a search tree, each node also typically represents two types of content: tree content, such as a list of child sub-search nodes immediately below the current node in a parent node's search tree structure further divided into subnodes and subgroups, and data content, such as a list of search result items returned by a query represented by the current node after the query has been evaluated against the underlying data collection. As shown in Figure 3, a sample node is illustrated showing the same current node position 3100 for "Photos," with tree content 3200 and data content 3300 displayed and managed separately in different display areas 3400 and 3500, respectively, in a multi-panel interface configuration 3000.

[0064] However, unlike the presentation in the case of a folder tree, where subfolders and files related to the current node or folder may be displayed together in a single panel configuration, the list of sub-search nodes and the list of search result items cannot be combined or merged because both of these lists represent the exact same set of data items that the current search node itself represents, and it would be confusing to have both lists displayed simultaneously under the same current search node.

[0065] In case of such a conflict, the presentation of tree content always takes precedence over the presentation of data content, in order to allow the list of subnodes, if any, to be displayed in the display area. Otherwise, navigation and traversal of the tree would fail if the subnodes were not always available. Only if the search node has not been further divided and grouped into subnodes will the data content of the current leaf node (the list of search result items) be displayed in the main display area.

[0066] According to the embodiment shown in FIG. 4(a), the root nodes of several search trees are initially listed together on a single-panel display 4000, with none of the tree structure details or search result items visible or obvious. Common to all of the main display areas is a designated area at the top for indicating or identifying the coordinates or location of the current node within the tree structure 4100; that is, a common path from the root to the current node, whose content 4200 is a subnode or search result item, is displayed in the main display area. This allows users to continue tracking their location and maintain orientation awareness, even when the tree structure is not always fully visible within the main display area. Additionally, "Back" 4300 and "Up" 4400 buttons are provided for returning the display area to a previous state or for moving up a node level, respectively.

[0067] According to a further embodiment shown in Figure 4(b), a search node or sub-node in the display area can be opened when the node or any context menu option on the node is clicked or tapped or double-clicked, depending on the design implementation, to display its content in the main display area and its position indicator 4100 is updated accordingly. That is, the content currently in the display is replaced with a list of new sub-nodes, each of which can be subsequently opened to display content, or a new list of search result items, depending on the type of node being opened.

[0068] According to a further embodiment, shown in Figure 4(c), a list of search result items is displayed only for leaf tree nodes that have no subnodes (i.e., no further traversal or browsing is required). Again, the position indicator 4100 is updated. According to a further embodiment, there is always a search result list for every search node, even though the list may be empty if the search query represented by the current node does not match any items in the data collection.

[0069] According to this general browsing mechanism, any node in the tree structure is reachable, and similarly for the folder tree. According to the embodiment shown in Figure 5, after visiting all tree nodes, the user can reach any data item in the tree 5000 below the root node, even if the data item 5100 is visible only at the leaf node (e.g., the leaf node at the second level 5200 or the third level 5300).

[0070] However, while such a provision makes the set of search result items in the search tree available to the user as a whole, it lacks important flexibility in search tree management. In particular, the user cannot know if a search node has been further divided until the node is opened and the current content list in the display area is lost. Also, the user cannot review the search result items of subnodes side by side because they are displayed separately on different screens. Therefore, additional controls for search tree presentation on a single display are needed to improve user visibility and accessibility.

[0071] Functions for single panel display

[0072] According to an embodiment, there are four functions for displaying search tree nodes so that both the tree content and data content of the nodes can be presented in a logical, meaningful, and accessible manner using a single main display panel. According to the embodiment shown in FIG. 6(a), the four functions can be implemented as buttons on the search tree nodes using a single main display panel 6000: subnode toggle button 6100, search result toggle button 6200, select button 6300, and open button 6400, along with display 6500 showing the location or coordinates of the current node and display 4200 showing the contents of the current node or location. According to a further embodiment, the four buttons include three content adjustment buttons and one dedicated highlight button. According to an alternative embodiment, the four functions can be implemented singly or in combination as menu options or any other conventions provided by the operating system or application program.

[0073] In an embodiment shown in FIG. 6(b), clicking or tapping 6100 expands 6110 or collapses 6120, revealing or hiding subnodes 6130 of the current node without changing the node's position. In an embodiment, 6100 doubles as an indicator to distinguish between parent and leaf nodes by not being present in leaf tree nodes. In an embodiment, the content below the expanded target node moves downward.

[0074] According to an embodiment shown in FIG. 6(c), clicking or tapping 6200 expands 6210 or collapses 6220, revealing or hiding a list of search result items 6230 for that node without changing the current node's position. According to an embodiment, 6200 is always visible, if appropriate for the interface design, so that requests corresponding to the search node are evaluated against the data collection. According to an embodiment, if the search result list is empty, the system relays that information to the user.

[0075] According to an embodiment, 6100 and 6200 are located simultaneously on a search node and are implemented such that the node's list of subnodes and list of search result items are mutually exclusive in that either list may be visible or one may be visible at different times, but not both at the same time for the same search node. According to a further embodiment shown in Figures 6(d) and 6(e), 6100 is absent or masked in leaf tree nodes and is always visible in parent tree nodes (in expanded state 6110 or collapsed state 6120), and 6200 is visible only when 6100 is absent and masked, or visible but collapsed.

[0076] According to an embodiment, if a user clicks on one button that is visible and collapsed while other buttons are expanded, the system will issue a warning message and not fulfill the request, or will automatically collapse the other buttons to give room for the user's request to expand.

[0077] According to an embodiment, the toggle functions of 6100 and 6200 are both merged into a three-state toggle that rotates between a collapsed state, a subnode list expanded state, and a search result list expanded state.

[0078] According to an embodiment, each node appearing in the search tree has its own set of controls (e.g., 6100 and 6200) so that both the list of subnodes of that node, if any, and the list of search result items can be collapsed or expanded one by one under the group header of the search node.

[0079] According to an embodiment, at most one of 6100 and 6200 for the same node may be expanded at a time. According to a further embodiment, 6100 and 6200 may be expanded simultaneously at different tree nodes within the same search tree structure. That is, any part of the tree structure can be expanded or collapsed independently, and existing content need only move to make room or take up space while another node is expanded or collapsed.

[0080] According to an embodiment, the nodes are presented as group headers in a line-by-line view in the display panel, so that 6100 and 6200 are more naturally positioned above the search tree nodes. According to an alternative embodiment, a different presentation format, such as a grid view for individual search result items, may be used, so that data files and folders are presented as individual items under their own search group headers in the display panel. According to a further embodiment, data files and folders may be presented as shown in Figures 6(f) and 6(g).

[0081] According to embodiments, using 6100 and 6200 available on the search node, the entire contents (a list of subnodes or a list of search result items) can be presented in various formats for any node in the display area. According to further embodiments, these formats include only the search result items (similar to the data content subpanel of 3500 in a multi-panel configuration), only the nodes and subnodes (at one or more hierarchical levels) (similar to the navigation subpanel of 3400 in a multi-display configuration), or search result items grouped by their corresponding subnodes. Embodiments of presentation formats are shown in Figures 6(e), 6(h), and 6(i), which respectively display all search result items in a flat list, the entire tree structure, and all search result items grouped by the tree structure.

[0082] According to an embodiment, when clicked or tapped, 6300 marks a node as selected by highlighting it. According to a further embodiment, shown in FIG. 6(j), the selected node is surrounded by a selection box 6310 for highlighting. According to alternative embodiments, the selected node may be highlighted by other visual identifiers, such as symbols or color-based schemes. According to an embodiment, 6300 allows for the display of additional information and options. According to a further embodiment, the additional information and options include a context menu 6320 option, as shown in FIG. 6(k), and an auxiliary display panel 6330, as shown in FIG. 6(l), for detailed content of the selected item. According to a further embodiment, the auxiliary display panel may show search nodes or individual data items. According to a further embodiment, the auxiliary display panel is displayed separately from the main display area.

[0083] According to an embodiment, clicking or tapping 6400 conventionally "opens" a node, completely clearing everything previously in the display, and then displaying a list of subnodes (if the node is a parent node) or a list of search result items (if the node is a leaf node) in main display area 4200. Clicking or tapping 6400 also updates location indicator 4100 to display a path relative to the current node. According to an embodiment, the current node is presented in two formats and in two places: its location is displayed as a location or coordinate indicator or header 4100 so that the user can track and maintain awareness of their location within the search tree structure, and its contents are displayed in main display area 4200 where details about the node are available. According to an embodiment, after a parent search node is opened using 6400 and its subnode list is displayed, if applicable, details about individual subnodes in the list may be manually displayed by the user on the node using 6100 and 6200 to display the details, for example, as shown in FIG. 6(g).

[0084] According to an embodiment, the search tree uses a single hierarchical structure to organize together both related search requests and their corresponding search result items, which can be presented and viewed in a single main display panel configuration using the controls and conventions discussed in this section.

[0085] According to embodiments, this functionality need not be implemented as a separate button. According to further embodiments, this functionality is triggered by various control gestures, such as, for example, a right-click, a double-click, a long press, or a screen swipe. According to further embodiments, 6300 and 6400 may use a single (i.e., the same) control area, but may be distinguished by a single click (e.g., to select) and a double-click (to open), or by a long press and a tap. According to further embodiments, 6100 and 6200 may be combined into a three-state toggle.

[0086] According to an embodiment, search result items of a parent search node (with subnodes) cannot be displayed in a plain list in the main display panel without the items being grouped by subnode, as shown in FIG. 6(n). According to an embodiment, when a parent node is opened, the list of subnodes always precedes the list of search result items. After a parent node is opened, it becomes the current node, but the current node, which is presented as a location indicator outside the main display panel, does not itself have 6200 available for manually displaying its list of search result items. According to an embodiment, according to the presentation convention, 6200 is only available in the subnodes of the current node in the main display panel, not in the current node itself.

[0087] According to an embodiment, an "Open Search Results" option is available on the selected parent node in addition to the default "Open Subnode List."

[0088] Presenting search tree nodes more like folders

[0089] According to an embodiment, a search tree structure may be viewed in an in-place single-display panel interface using several conventions. These conventions include a root node initially displayed as a list of collapsed groups with their contents hidden. These conventions also include a group or node (and recursively any subgroups or subnodes) that can be expanded to display its contents (after clearing the current contents in the display area) if the node is a parent node, or as a list of individual search result items if the node is a leaf node. These conventions further include, if additional controls are available, a collapsed group being manually "expanded" to display its contents, a list of subnodes (if any), or a list of search result items under the group header, with other node(s) and group(s) in the display area moving accordingly.

[0090] According to an embodiment, the open and "expand" functions may be combined to change the data presentation. According to a further embodiment, after the list of subnodes is displayed as a collapsed group, the uncategorized subnode may be expanded to be displayed as a list of individual search result items if it is a leaf node; otherwise, nothing is done.

[0091] According to embodiments, the resulting content presentation of the current node depends on the characteristics of the search query and the data collection. According to further embodiments, the content can be displayed as a mixed search group with individual result items, as shown in FIG. 7(a), where all categorized subnodes are presented as a list of collapsed groups 7100, and if the Uncategorized subnode is a leaf node with a non-empty search result set, the Uncategorized subnode is presented as a list of individual search result items 7200. According to embodiments, the content can be displayed only as a collapsed search group, as shown in FIG. 7(b), where all categorized subnodes are presented as a list of collapsed groups 7100, and if the Uncategorized subnode is a leaf node with an empty search result set, the Uncategorized subnode is displayed as an expanded but empty group 7300. A divider indicator 7400, which doubles as a header for the collapsed categorized group 7100, is between either the list of individual search results 7200 or the expanded Uncategorized group 7300 and the collapsed categorized group 7100 in the embodiments shown in FIG. 7(a) and FIG. 7(b), respectively. According to an embodiment, the content may be displayed only as collapsed search groups in another format as shown in Figure 7(c), where if an Uncategorized subnode is the parent node (having a list of subnodes), and if there is a dividing line or indicator 7600 between the Categorised and Uncategorized groups, all subnodes, including the Uncategorized subnode, are displayed as a list of collapsed groups (7100 for the Categorised group and 7500 for the Uncategorized group). According to an embodiment, the content may be displayed only as individual search result items as shown in Figure 7(d), where if the current node is a leaf node, all search results are presented as a list of individual data items 7700.

[0092] According to an embodiment, because the Uncategorized group is automatically created and maintained by the system and not specified by the user, presenting it in the same way as other user-defined categorized groups may surprise or confuse some users before they become accustomed to the concept. By always expanding the Uncategorized subnode and displaying its search result items individually, this node effectively ceases to be presented as a collapsed group, and all collapsed search nodes in the main display area become user-defined groups, making the presentation of the search tree more natural and adaptable for many users. According to the embodiment shown in FIG. 7(a), an optional dividing line 7400 as a group header or indicator with aggregation information can highlight search result items under the Uncategorized node.

[0093] According to an embodiment, after a parent search node is fully categorized into user-defined sub-search nodes, its uncategorized subnode becomes empty, and such empty subgroups visually disappear from the display area after the search group icon expands and is replaced by an empty set of icons for the individual items. According to the embodiment shown in Figure 7(b), the categorized group "Irregular" collects all items that do not fit into the other categorized groups "Triangle," "Square," and "Circle," emptying the uncategorized subgroup under the parent group "Shape." According to a further embodiment, an optional dividing line or indicator 7400 may be displayed as a header for empty uncategorized groups.

[0094] According to an embodiment, if the Uncategorized subnode is a parent node itself, whether its search result set is empty or not, the node is treated like any other categorized (collapsed) node or group, so that its subnode list can be reached and opened for viewing. In this case, the Uncategorized node (as a collapsed group) is also user-defined, i.e., the user understands the group and then further divides it according to their needs, so the user will not be surprised or confused among other collapsed categorized groups. According to an embodiment shown in FIG. 7(c), content related to "shapes" is displayed as a list of search groups, assuming that the Uncategorized subnode is further divided into subgroups such as "single," "double," etc. An optional dividing line or indicator 7600 different from 7400 makes it easier to distinguish the Uncategorized group from all other categorized groups.

[0095] According to embodiments, when a leaf classification node or group (which has no subnodes or groups of its own) is opened, the search result items may be displayed individually at that point, as shown in FIG. 7(d). After this, further browsing or exploration of the search tree structure is unnecessary, unnecessary, or impossible. According to embodiments, individual data items in the display may be opened similarly to opening individual files or file folders in existing file management systems. According to embodiments, because search groups and data have similar presentation formats, users do not need to distinguish between the two types and are prompted to select different open operations when interacting with a group or item icon in the interface for search tree management based on whether it is a search group or an individual data item (i.e., a file or file folder).

[0096] In accordance with embodiments, the presentation of a search node with an uncategorized subnode always expanded is visually similar to three presentation scenarios for storage folders in a file management system: a folder with only subfolders, a folder with only files, and a folder with both subfolders and files, especially when the optional dividing line indicator for the uncategorized group is turned off. In accordance with embodiments, the logical presentation of a search node with an uncategorized leaf subnode always expanded also conforms to these three scenarios. Specifically, there may be search nodes that are completely divided into user-defined subgroups, including an uncategorized subgroup that is either an already-empty leaf node with or without search results or a parent node with its own subgroups; search nodes that are not divided and only display a set of individual search result items; and search nodes that are divided into subgroups, but have some items that do not belong to any subgroup, similar to individual files in a parent folder that do not belong to any subfolder, and that are placed under the parent but outside of any categorized subgroups.

[0097] According to an embodiment, a search tree is constructed such that the data collection is divided into search groups for management and access tasks, with the Uncategorized group being similar to a "to-do" list for data items, only remaining temporarily until assigned to one or more categorized groups and "removed" from the list.

[0098] In embodiments, by always expanding the Uncategorized node and displaying its search result items individually, it is easy for a user to directly associate individual "to-do" list items with which they appear with all existing search groups, or to recognize that a particular item in the "to-do" list does not fit into any of the existing groups and that a new group needs to be created for it.

[0099] According to an embodiment, by maintaining the expanded state of the node with the individual items (if any), the user can also know as soon as all items in the collection (parent node) have been properly divided or grouped and the Uncategorized group is empty, so that the always-expanded Uncategorized node can double as a reminder or indicator when the grouping task for its parent is complete.

[0100] In some embodiments, when the system-generated and maintained uncategorized subnodes are no longer presented as collapsed groups among other user-defined groups, the presentation of search nodes becomes visually, logically, functionally, and operationally closer to the presentation of a folder tree. In a further embodiment, when individual data items are also presented in a similar manner to search groups, folders and search groups can be opened within the same interface, and the presentation after opening both is such that leaf uncategorized subgroups are always automatically expanded and their individual search result items are mixed with the collapsed categorized group presentation. This shortcut not only makes the search tree node presentation more intuitive for many users, providing convenience during tree management tasks, but also minimizes user impact because search tree browsing and management procedures can be merged with the existing folder tree presentation in a consistent, unified interface. In a further embodiment, a search results toggle button with 6200 functions is present on folders.

[0101] According to the embodiment shown in FIG. 8, a selection function or button 8100 and auxiliary detail view sub-panel 8200 allow the user to peek at detailed content or perform complex management tasks such as grouping without actually opening the search node.

[0102] Even though search tree nodes can be made logically, visually, and functionally similar to storage folders in a file management system, the two types of tree structures generally cannot be merged because they are different in almost every respect. Folders and search tree nodes can have something in common only if they represent the exact same set of data items and files under a file folder. Even in this case, however, the presentation of folders and search nodes must be different in terms of their contents if a folder is a parent folder with its own subfolders, or if a search node is a parent node with its own subnodes, as shown in the embodiments shown in Figures 9(a), 9(b), and 9(c). Similarly, different search tree nodes, such as those shown in Figures 9(b) and 9(c), cannot be merged. Thus, from a presentation perspective, different folder trees and different search trees exist side by side.

[0103] However, by keeping folders and search tree nodes that logically represent the same collection of data items or files and displaying them nearby, users benefit from being able to easily access and explore different groups on the same collection in one place. According to an embodiment, in a system with both a folder tree and a search tree, the storage folder tree can be viewed using a storage folder tree browsing mode 10100, a root folder 10200, and subfolders of the current folder 10300, as shown in FIGS. 10(a) and 10(b). According to a further embodiment, when alternatively grouped folders are opened and displayed using a search tree, additional buttons and indicators 10400 are accessible next to the current location indicator 10500. According to an embodiment, all alternative ways of grouping a collection, including storage folders, can be accessed by selecting their corresponding tabs and indicators within the interface 10400. According to a further embodiment, a user may decide to create additional search trees on this same collection group if no existing folder structure and search groups provide the desired organization. According to embodiments, folders and search groups may be listed as tabs, as in Figures 10(a) and 10(b). According to an alternative embodiment shown in Figure 10(c), folders and search groups may be listed as an option list or other format that allows easy access and switching between options using a control. According to embodiments, folders and search groups may be displayed and opened simultaneously using multiple display panels for user comparison.

[0104] According to an embodiment, a user may browse a collection using a search tree browsing mode 10600 and the root node of the search tree 10700, as shown in Figure 10(d). According to an embodiment, as shown in Figure 10(e) for a folder tree presentation 10910 and another group 10920 for the same collection, in addition to displaying the subnodes 10800 of the current search node, tabs or indicators of folders defining the collection boundaries, and other search trees on the same collection, if any, may be displayed alongside the location indicator of the current search node.

[0105] According to an embodiment, since a folder represents only the set of files within it, no two folders are the same and there can only be one intersection (collection), and if there is one between a folder and a search node, it is always the folder itself. That is, for a search node to represent the exact same data item or file collection as a folder, a search query for that node can only be as simple as "list all items in this folder X."

[0106] According to an embodiment, for different search nodes between different trees, e.g., "Folder[Photos]→2005→Japan" and "Folder[Photos]→Japan→2005", as long as the collections they logically refer to are the same, they may intersect each other multiple times, e.g., at the first or root level, then at the third level, etc. According to further embodiments, it is an individual application design decision to maintain and present such additional lists to the user.

[0107] According to an embodiment, different folders and search nodes across different tree structures are grouped around the data collections they represent and accessed collectively. According to a further embodiment, for each and every representation of a folder and search tree node managed by the system, it is associated with a list of folders (if applicable) and all search nodes (including the target folder or node itself) that logically represent the same data collection as the target folder or node itself. According to an embodiment, the list associated with a folder or node is presented by providing tabs or selections or other toggle controls, or by opening all folders or nodes in the list simultaneously.

[0108] According to the embodiment shown in FIG. 11, a list of collection representations 11100 can be created, with entries being a list 11200 of folder or node representations. According to a further embodiment, all search trees in the system can be traversed, with each node entering an entry in the collection representation list that matches the collection represented by the search node; if an existing entry cannot be found, a new entry is created. Search nodes and representations in the collection list can be doubly linked, allowing a collection list entry to be reached from a search node and vice versa. Finally, folder representations are placed at the top of entries in the collection list if the entry is a folder only. According to an embodiment, uncategorized nodes can be grouped using the same mechanism as shown in FIG. 11.

[0109] Tagging Data Items with Search Tree Nodes

[0110] According to an embodiment, the search tree allows a user to divide a file collection into different groups based on related search requirements, assuming that all data items in the collection have searchable or identifiable characteristics, such as a specific file type, file creation time, or keywords in the file name or text content, that allow the items to be recognized by a search engine. That is, the data collection (files in the storage tree) and the search tree are independent of each other and are connected or linked only if the properties of the data items can match the search requirements(s) represented and stored by the search tree nodes.

[0111] According to an embodiment, if the original filename and text content, if any, are not sufficiently clear, the system allows user-defined descriptive text to be attached to the file as a tag, so that the file can be identified and differentiated for file management tasks using the tag. According to a further embodiment shown in Figures 12(a) and 12(b), image files for different geometric shapes can be tagged and then grouped by tag names for their shape types. One file for an irregular shape 12100 is left in the uncategorized group in Figure 12(b) because it does not have a tag that matches the shape name.

[0112] According to an embodiment, a data item must possess characteristics recognized by a computer system to match one or more specific search groups. According to the embodiment shown in FIG. 13, "Item 7" clearly contains a triangle to a human user, but before the keyword "triangle" is tagged, the computer leaves it in the uncategorized group along with "Item 4," which is an irregular shape. Only after updating its searchable characteristics by tagging, renaming, content modification, or stamping can such an item be moved from the uncategorized group to one of the categorized groups. According to an embodiment, all search requests are reevaluated for all uncategorized and uncategorized groups before the updated search result list can be refetched and displayed accordingly.

[0113] The steps of renaming or updating content or attaching tags, and then refreshing search results, are technical details of some routine procedure that a user must understand, remember, and follow so that the data items are recognized by the computer system before the appropriate action can be taken with respect to the task. Thereafter, when the user wishes to reorganize the data collection by moving items from one group to another, the results can be presented and managed in the user interface.

[0114] According to an embodiment, the graphical user interface has routines available to move or copy files and folders between different locations within the file system, while all internal maintenance operations within the system remain transparent to the user. According to a further embodiment, such routines are also available to allow data items to be managed naturally within a search tree structure.

[0115] According to an embodiment shown in During Move 14100 and After Move 14200 in Figure 14, files and folders may be moved by drag 14300 and drop 14400 operations. According to an embodiment, moving files and folders is implemented as cut and paste operations and other context menu options presented by right-clicking an item or group. According to a further embodiment, moving is affected by any conventions provided by the operating system or application program.

[0116] According to embodiments, searchable or identifiable characteristics, such as file or folder names, file text content, or file and folder tags, are updated to move or copy data items between different nodes in the search tree. According to embodiments, the names or content of data items are not changed or updated solely for file management tasks; instead, tags are attached and detached from items for file management tasks. According to embodiments, tags are only allowed to be attached or detached during data item move or copy operations between search groups. According to alternative embodiments, other properties of data items, including names and content, are updated when items are moved or copied between search nodes based on the same principles but different application-level rules.

[0117] According to an embodiment, a move or copy operation requires that a data item, an existing search node with which the item is associated, and other search nodes from the same search tree structure be specified. According to a further embodiment, moving an item from a current search group to a new group involves removing one or more tags corresponding to the current group and then attaching one or more tags corresponding to the new group. According to an embodiment, copying an item from a current group to a new group involves attaching one or more tags corresponding to the new group to the item.

[0118] When a new tag is attached to a data item, duplicates may appear. According to an alternative embodiment, duplicate tags are removed. According to an embodiment, removing duplicate tags is not a requirement for the system to operate correctly. That is, when the question is "does this tag appear in this item?", there is no logical difference between "this tag appears in the item only once" and "this tag appears in the item multiple times."

[0119] According to embodiments, there are logical restrictions on moving or copying items between different search nodes if it is not logically feasible. For example, an item cannot be classified and uncategorized at the same time, so it is not possible to copy an item from a classified group to an uncategorized group under the same parent, or vice versa. According to embodiments, there are other logical constraints, including that at least the current search node and the new search node for a move operation must be different search nodes within the same search tree structure, because it is logically not possible to move an item outside of a data collection for data integrity reasons, since the root node of the search tree defines the boundary of the entire data collection and represents every item in the collection.

[0120] According to an embodiment, keywords present in names and textual content may prevent files and folders from being freely moved or copied between search nodes or groups. According to a further embodiment, the system implements additional evaluation routines to check for and indicate conflicts, for example, graying out illegal moves and rejecting requests upon finding conflicts.

[0121] According to an embodiment, after any searchable characteristic, such as a data item's tag, is changed, all related search requests are reevaluated and the group presentation in the interface's display panel is refreshed. According to a further embodiment, whether an operation is performed automatically after an item is moved or copied is left to the system design and logic to decide. According to a further embodiment, the original group and the new group are immediately evaluated and refreshed for drag-and-drop moves and moves from a categorized group to an uncategorized group, since in the latter case the system needs all other categorized groups to verify whether the operation is valid.

[0122] According to an embodiment, in addition to the move and copy operations, a tag editing interface is available to the user. According to a further embodiment, the move and copy operations provide an added benefit over manual tagging by allowing automatic tagging and detachment in an intuitive manner with mouse-only operations that ensure that the tag value being attached or detached matches the keyword(s) represented by the search node exactly by eliminating tedious and error-prone typing that can lead to improper tagging. This eliminates the need to hunt for errors or to carefully compare both the search request and all the names, text content, and tags of the data items to identify, for example, typos.

[0123] According to an embodiment, moving or copying multiple items can be performed by looping through a list of items and applying the same procedure to each and every one of them. According to a further embodiment, files and subfolders within a parent folder, and recursively any files and folders within it, can be moved or copied en masse, preserving the subfolder structure, when the parent folder is moved or copied as a whole. According to a further embodiment, such a batch operation can be accomplished by allowing a user to specify moving or copying the current search node, rather than only the current node being shown when a single data item is specified; if the current node is a parent node, duplicating the tree structure under the current node to a new location in the search tree; looping through all data items in the search result set for each node between the original and new nodes in the newly created structure; and clearing the current search node if the requested operation is a move. According to a further embodiment, during such a batch operation, the move or copy operation, as applied to a single item, is applied individually to each data item as well.

[0124] According to embodiments, after an item is moved or copied, certain details affect the result. These details include the calculation of searchable features and properties, such as sets of tags, corresponding to existing and new search tree nodes during the move or copy operation. These details also include how features and properties are attached to or detached from the target data item, and whether the operation actually establishes or severs an association between the data item and a search group. According to further embodiments, such details do not affect the success of the move or copy procedure itself. That is, even if the set of tags is calculated incorrectly or not properly added or detached, the move or copy procedure is considered complete and successful as long as the feature and property detachment or addition steps are performed; such improper implementation may not achieve the desired result itself.

[0125] According to an embodiment, general rules are incorporated into the calculation and modification of sets of tags corresponding to groups and nodes in the search tree. According to a further embodiment, the calculation of the set of one or more tags corresponding to a single search group or node is performed similarly to the search query represented by the search node and used by the search engine against the data collection to form the search result set. According to an embodiment, the calculation depends on the type of group or node. According to a further embodiment, for a categorized group or node, the set of positive normal tags is represented by the node alone, and for an uncategorized subgroup or subnode, the set of negative tags is represented by the union collection of all categorized sibling subnodes under the parent node.

[0126] According to an embodiment, the tag(s) corresponding to any node in the search tree is the union collection set of all positive and negative tags along the path from the root node to the current location.

[0127] According to embodiments, different types of tags are added and detached from data items differently. According to further embodiments, for positive tags, when the positive tag is added to a data item, the tag needs to be attached to the item, and when the positive tag is detached from the data item, the tag needs to be detached from the item. According to embodiments, for negative tags, when the negative tag is added to a data item, the tag needs to be detached from the item (i.e., a ban is placed on the data that prohibits and prevents the tag from being associated with the item), and when the negative tag is detached from a data item, no action is required, as the tag is no longer prohibited from association with the data item (i.e., the ban that prevents the negative tag from being associated with the data item is simply removed).

[0128] According to an embodiment, there are enforcement restrictions on add or remove operations. According to a further embodiment, the same tag value cannot be added to the same data as both a positive tag and a negative tag at the same time. That is, a keyword cannot appear in an item and be removed from the same item at the same time.

[0129] Creating and Managing Unnamed Search Tree Nodes

[0130] According to an embodiment, if the interface allows combining or linking data items into different search groups without explicit description by any keywords or search criteria, the search groups (i.e., the combinations or links between items and groups) may take a variety of forms, including those that are not human-intelligible, provided they can be processed by a computer system.

[0131] According to the embodiment shown in FIG. 15 , the “Create New Group” button 15100, when clicked or tapped, creates a new, empty search group 15200 as “New Group (1)” under the “Shapes” node and lists all “Shapes” items under the Uncategorized group 15300. According to the embodiment, the new search node is created with no name, and “New Group (1)” serves as placeholder text for the search node or group, rather than the actual search query criteria used to match the search node or group to items in the data collection. According to alternative embodiments, the “Create New Group” feature, alone or in combination, is implemented as a menu option or any other provision provided by the operating system or application program.

[0132] According to an embodiment, creating an unnamed categorized search node involves several steps. According to an embodiment, after a dedicated control or trigger (e.g., a button or menu option) is activated or clicked or tapped to receive a request without a user specifying an actual search query, a globally unique search ID is generated instead of the search query as received from the user along with the request, and a unique or non-unique face name is generated depending on the design implementation logic. According to an embodiment, when creating a new search tree presentation or modifying an existing search tree presentation for a new search node, a normal search query is received from the user, but the new search node does not store and present only the search query for a normal search node, but stores and presents two pieces of information simultaneously. According to a further embodiment, these two pieces of stored and presented information are an internal search ID as a normal search query (matched, joined, and linked with data items and evaluated against the underlying data collection) and a face name as a new field used to describe the node to the user in the user interface.

[0133] According to an embodiment, the face name and group search ID are separated and distinct within the anonymous search node. This is done because, for the anonymous grouping mechanism to work, newly created nodes need to be empty until a data item is manually dropped into them by the user, and a query such as "new group (1)" may unintentionally match a file with text content such as "Creating 'new group (1)' is the first step." Also, it is not practical to directly present the system-generated group ID for the user to see.

[0134] According to an embodiment, data items can be distributed, combined or linked to unnamed search nodes only by move and copy operations, since the node's search ID is not visible to the user and is only tagged or untagged to items transparently in the background by the system.

[0135] According to an embodiment, when a search request is evaluated against a data collection, a newly created node always has an empty search result set because no data items in the collection match the globally unique search ID. According to an embodiment, when a new node is created under a parent node, an uncategorized node is created or an existing uncategorized node is updated so that the data integrity of the search tree structure is automatically maintained. According to an embodiment, when a new node is created as a root node, the node is still empty with an empty search result item set and only becomes part of the search result set for the search node after the items are tagged with the node's search ID.

[0136] According to an embodiment, as many unnamed groups as needed are pre-created. According to a further embodiment shown in Figure 16(a), all items remain under the Uncategorized group 15300 until they are manually distributed to the unnamed categorized group 15200 after the items are attached as tags to the group's search ID as shown in Figure 16(b).

[0137] According to an embodiment, after scanning all existing categorized groups and finding that an item does not fit into any existing group and requires its own new group, a new unnamed group can be created whenever a user moves an item from the Uncategorized category into a categorized group. According to a further embodiment, the existing and uncategorized groups and the items therein remain unchanged before and after the new unnamed group is created. According to an embodiment, this procedure can be repeated as many times as necessary until the entire collection is properly categorized, as shown in Figure 16(b).

[0138] In embodiments, the uniqueness of the search group ID ensures that creating new unnamed groups and moving items into and out of them by attaching and detaching search IDs as tags to data items ensures that any existing search result sets for any other categorized groups are not affected by the fact that a particular search ID does not exist anywhere in the entire system.

[0139] According to an embodiment, an uncategorized item can be associated with an existing categorized group, and then if the uncategorized item is to remain visible to the user at all times along with all categorized groups, the item is moved into a group or a new group is created for the item, i.e., the categorized unnamed group is collapsed to allow as many categorized groups as possible to fit within the main display panel, along with at least the current target item in the uncategorized group.

[0140] According to an embodiment, a popup preview 17100 of the contents of a group, as shown in FIG. 17, helps identify and distinguish search groups when a user drags an item 14300 over a node or group and compares the item to the group. According to an embodiment, the preview need not be complete, as long as the visible portion allows the group to be clearly identified. According to a further embodiment, the preview may be in a form other than a graphic, such as a list of the names of the items.

[0141] According to embodiments, meaningful search group names can be assigned to encourage users to identify the grouping criteria for each group without requiring that the individual items within the group be visible at all times. According to embodiments, because the group name is separate from the actual search query (group ID), after the creation of an unnamed group, before or after any data items are linked to the group, the group's face name can be updated and customized to any value at any time without changing the face name affecting search results.

[0142] According to an embodiment, the controls for updating the face name of an unnamed group include optional file and folder renaming conventions, including allowing the use of an editable text field as shown in Figure 18 for the face name of the group 18100, a context menu command, or a slow double-click to change the name itself so that it is editable without the search ID portion being clearly displayed.

[0143] According to an embodiment, the tree structure for unnamed groups is not a regular search tree, but a grouping tree that allows grouping of data items without specifying a search query. According to a further embodiment, different icons for at least the nodes or groups are used to distinguish the two types of trees in the interface.

[0144] According to an embodiment, the implementation of the interface prevents different types of nodes from being mixed up or created together by implementing different browsing modes. According to the embodiment shown in Figure 19, these include different browsing modes for the folder tree 19100, the search tree 19200, and the grouping tree 19300, respectively.

[0145] According to an embodiment, a grouping tree is a type of search tree, where a single node simultaneously represents two separate pieces of information: the node's new representation value that makes the grouping tree distinct, and the node's search query that makes the grouping tree remain a search tree.

[0146] According to an embodiment, any regular search tree node can be transformed by inserting an additional node representation and initially setting its value the same as the search query. According to a further embodiment shown in FIG. 20(a), this value can be updated to a more natural group name 20100, such as "Collection of Singles," if the group's keyword is "single." According to an alternative embodiment, the group representation of the node is not in text form. According to a further embodiment shown in FIG. 20(b), the group representation can be a visual graphic preview 20200 of the individual items in the search group. According to a further embodiment, the group representation of the node between the user and the search query in the search tree enables additional functionality.

[0147] According to embodiments, the unnamed group is a type of application of a grouping tree, and the search query is a system-generated, globally unique search ID rather than a user-defined query term in a typical grouping tree. According to embodiments, because the unnamed group is a grouping tree rather than a typical search tree, even if a user accesses internal search IDs and enters them as a search query, the resulting search nodes are typical search nodes rather than grouping nodes. According to embodiments, the uniqueness of search IDs means that creating, modifying, or deleting unnamed group nodes, and tagging or untagging items in a data collection with unique search IDs, does not affect any other categorized search result sets in the search tree.

[0148] According to embodiments, anonymous search groups allow a user to focus on which items to group together and how to arrange the groups, without worrying about how to describe the grouping to a computer before the data items are actually grouped. According to further embodiments, items can be freely moved between different search groups, except when they simultaneously exist in a categorized group and an uncategorized group. According to embodiments, anonymous grouping allows files to be grouped arbitrarily without interference from existing keywords. According to embodiments, data items in an anonymous group can be tagged with one or more common keywords with respect to one or more other search trees.

[0149] Customizing search tree nodes and using ID-only subnodes

[0150] According to embodiments, the search tree can divide a file collection into different groups based on relevant search requirements when presenting a user with a tree structure for data management tasks. According to embodiments, items within a data collection can be generally identified and differentiated with respect to any routine or operation or procedure in a computer using a search query.

[0151] According to the embodiment shown in FIG. 21(a), an interface is provided that provides customizable group presentation and file access control in a search tree management system. In particular, FIG. 21 shows a node or group 21100 with a customized presentation alongside a group 21300 without a customized presentation in a bookshelf mode 21400, and corresponding checkboxes 21200 for group presentation selection, where if the direct play checkbox for the item is selected 21500, opening the group directly plays the selected item. According to a further embodiment, the checkboxes 21200 for group presentation selection are disabled for non-image files. According to the embodiment shown in FIG. 21(b), an interface is provided that provides customizable group presentation and file access control using an auxiliary display sub-panel 21600 showing an on-selection 21700 and an off-selection 21800.

[0152] According to an embodiment, the interface is designed to allow the user to select data items within a search group so that the group looks and acts like a single object rather than individual data items. According to a further embodiment, this is achieved by allowing the user to control the preview image of the group or any item using an image file, define the main functional portion of the content for the group, and directly open the selected file when an open operation is requested for the entire group.

[0153] According to embodiments, the interface is configured to help digitized content on a computer be presented and accessed as closely as possible to real-world objects. For example, various music albums can be represented by their cover art or poster images, and if both the cover art and music files are grouped under or within an album or with other files, a song within an album can be opened immediately when the user clicks on its cover image.

[0154] According to an embodiment, the file management system can accept any file of any type into its storage structure or handle collections using the same program.

[0155] According to embodiments, data items are treated by the search engine such that customized selections are cached or stored as search queries to the search engine, rather than as static lists by the application program. For example, in "list the three files from my working directory that have the most recent access times," the number "3" may be customized within the interface. According to embodiments, the results list is continually updated so that it is always up-to-date, even if files have been moved or renamed since their creation.

[0156] With respect to data items managed within a search tree, such collections are similar to subnodes under a parent search node, since all items in the collection originate from the same data set with respect to the parent node and have the same characteristics and properties that can be identified by the same search query. According to an embodiment, the collections are integrated into the search tree structure as subnodes of the parent node. According to a further embodiment, such ID-only subnodes are similar to all other search subnodes under their parent tree node in that each represents a search query and each represents a set of data items within the collection defined by the parent search node and identified by the subnode's search query.

[0157] However, according to a further embodiment, ID-only subnodes are not regular search subnodes for several reasons. ID-only subnodes should be separated and excluded or isolated from regular search subnodes using a processing indicator associated with their subnode type, either in the same subnode list as all other regular subnodes under the parent node, or in a separate list linked to the parent node so that each is treated in a separate workspace, is not presented to the user, does not affect the unclassified nodes under the parent (if any), and does not participate in any routines associated with regular search subnodes. According to a further embodiment, each ID-only subnode is associated with a specific processing routine by an operation ID that allows the ID-only subnode to be matched with the routine. Thus, each ID-only subnode stores a single item selection from a data collection for a single processing routine, each represented by the subnode's search query, parent search node, and subnode's operation ID.

[0158] According to an embodiment, the association or separation of a processing routine with a search group or node is controlled by attaching or detaching such ID-only subnodes to the node. According to a further embodiment, one search node may have multiple ID-only subnodes with different operation IDs to act on different customizable routines. According to an embodiment, the same processing routine is linked to different collections or search nodes in different ID-only subnodes using the same operation ID.

[0159] According to an embodiment, by attaching individual ID-only subnodes to the same operation ID value under different search nodes, the same customizable routine can operate on different data collections represented by different search nodes, using different selection criteria represented by different search queries in the individual ID-only subnodes. This may seem redundant if the selection is something like "list the first X files from the collection that have the most recent access time," as the same query is stored multiple times in different locations, but it is also possible to customize the value of "X" in the query for different collections, e.g., "2" for "Collection #2," "5" for "Collection #3," etc.

[0160] According to a further embodiment, there are cases where the search query always needs to be different for different collections, even for the same processing routine. According to a further embodiment, if the selection is a selection of any one of a list of any data items, a similar technique to that used for anonymous grouping can be applied in that one globally unique search ID is generated and stored in an ID-only subnode for the selection query, and the data items can be tagged and then identified using the globally unique search IF for the selection.

[0161] According to an embodiment, only by using different search IDs can data items belonging to different selection lists be identified for different collections. Such search IDs and their use as tags to data items do not interfere with any regular search functionality, since they are not only globally unique but also part of the ID-only subnode.

[0162] According to embodiments, such tags can be stored separately for different applications so that they can be removed when the application is uninstalled, or can be stored normally so that they are visible to everyone, including human users, to provide an additional communication mechanism between applications. According to further embodiments, a processing routine that operates on a search tree node and uses a customizable selection collection can perform several subsequent functions. These include determining whether the routine itself is configured to operate on a collection (i.e., a search group or node) and whether an ID-only subnode with its own operation ID exists under the search node. These functions also include returning a customized selection collection using the ID-only subnode by evaluating a corresponding search query containing regular keywords, other search criteria, or a globally unique search ID against the data collection. According to further embodiments, if no customization is defined (i.e., no corresponding ID-only subnode or search result set for the selection collection is returned empty), processing is redirected to a default routine. According to embodiments, using the ID-only subnode under the regular search node, items in the data collection are dynamically identified for processing routines within the search tree management system.

[0163] Tagging tags: customizable grouping without search trees

[0164] In addition to functional data that makes the content useful to human users, e.g., digitized text, images, video, etc., files in computer systems are also often associated with attributes and properties that are maintained and used solely for file management tasks. File and folder names are the most important and commonly used properties for the task, but there are also several other properties that are useful for file management, such as file type, size, creation time, etc.

[0165] According to the embodiment shown in Figure 22, attributes and properties may be displayed as details about files and folders for use in identifying, distinguishing, accessing, or organizing the files and folders. In particular, there is a header row 22100 for property names, property values ​​22200 are displayed in columns, and file lists can be sorted 22300 based on property values.

[0166] According to the embodiment shown in Figure 23, a long list of possible attributes and properties is provided to the user in order to cover as many options as possible and make the interface as flexible and comprehensive as possible for a variety of users. Nevertheless, there is a need for system-generated or maintained attributes and properties.

[0167] A property is data that describes other data in the form of a name:value pair. With respect to file properties in a file management system, the name is a text label that refers to a common aspect of all files across the collection, and the value is the actual data of any type associated with a particular file to describe the particular aspect indicated by the name.

[0168] According to an embodiment, customizable file properties are available to users. When user-defined tags are created, stored, and used in the same format as name:value pairs, they are presented similarly to system-generated properties. According to an embodiment, tag groups may be listed and displayed similarly to system-generated properties. According to an embodiment, the name "Seasons" for a user-defined tag group may be listed as option 24100 with other system-generated properties in FIG. 24(a), and a separate row 24200 may be placed in the interface so that individual values ​​of tags under the "Seasons" group (e.g., "Spring," "Summer," "Autumn," and "Winter") are displayed alongside all other detail groups, as shown in FIG. 24(b). According to an embodiment, different tag groups may be similarly listed under different rows.

[0169] According to an embodiment, tags may be grouped by tagging tags that belong to the same group by adding a common group tag to the tags. According to an embodiment shown in Figure 25(a), the interface can add or modify tags in one or more files that have a group name. According to a further embodiment shown in Figure 25(b), the operating system provides assistance, such as auto-completion, to facilitate reuse of the same group name within the interface.

[0170] In some embodiments, the name portion of a name:value pair is generally a text string that describes the group, while the property value may be any data capable of describing a particular aspect of that particular file. In further embodiments, the property value may be a number, a Boolean (true / false) statement, a text string, or other indicator or programming instruction. In a further embodiment shown in FIG. 26, after tags with similar characteristics are grouped together, additional field types (e.g., text, number, date, etc.) may be added for appropriate classification and presentation options. In the embodiment shown in FIGS. 22 and 24(b), a more advanced implementation may present user-defined values ​​in more complex ways, such as by defining "0-5 (integers represented by stars)" and then creating a "Score" user-defined value and tag column 22400 with a mapping between numeric values ​​and image presentation.

[0171] According to an embodiment, all tags are plain text managed by the file system so that they are always visible and accessible to all application programs. According to a further embodiment, there are additional conventions for storing and maintaining values ​​of various types so that tags can be properly presented or processed even when the values ​​are in a non-text format. According to an embodiment, there are additional conventions for storing and maintaining group-value pair relationships. According to a further embodiment, these conventions include using a separator between the group name and value portions of grouping tags.

[0172] According to an embodiment, tag group names and tag types are excluded as keywords by default when searching for file locations because they contain only additional data about the tag and not about the file being searched for within the collection. Thus, when they appear in queries, as with system-generated and maintained properties, the request typically specifies both the property name and value, such as "List files with a file size greater than 2GB," rather than a request related only to the property name, such as "Is the file size of a property available in a file?" Unlike system-generated properties, tags are user-defined, and when queried by tag group name alone, they may also be relevant to questions such as "Is season defined as a tag group?" According to an embodiment, tag group names and tag types are not excluded as keywords by default. According to a further embodiment, shown in FIG. 27, a user may specify a keyword type when searching within a search interface to determine how tag group names are treated.

[0173] According to embodiments, separate data structures or search indexes are built for additional queries on tag group names and types. According to further embodiments, separate data structures or search indexes are built depending on data collection characteristics and usage patterns. For example, it may be necessary for the system to keep track of all tag group names, but otherwise all data items in the collection would need to be scanned only for tag groups to be recognized and listed for additional options.

[0174] Another limitation on system properties and attributes is that a file or folder can typically only have one associated value. That is, a file cannot have multiple file names, multiple file types, or multiple modification times; in such cases, classification by value will fail because a file would have to appear multiple times in the classified list for the multiple values ​​it has in that field. According to an embodiment, for user-defined tags within a tag group, no care is needed to reliably enforce such rules, depending on system requirements and implementation. According to an embodiment, if multiple values ​​are allowed, such as "season=summer" and "season=fall" in a file originating at "the end of August," additional routines are implemented within the application to handle both presentation and manipulation.

[0175] File management systems typically allow files and folders to be listed in order by attribute or property values. According to embodiments, a group of user-defined tag values ​​as well as system-generated property values ​​are recognized and represented, and then the file list can be sorted by such values. According to the embodiment shown in FIG. 28(a), the file list can be sorted alphabetically by "season" value. According to the embodiment shown in FIG. 28(b), the interface may provide additional options, such as showing or hiding files by attribute or property value.

[0176] According to an embodiment, the interface may be adapted so that the order or sequence in which values ​​appear during sorting can be customized or specified. According to a further embodiment shown in FIG. 28(c), such an interface adaptation allows "Autumn" to be moved down to a slot between "Summer" and "Winter," as shown in FIG. 28(d), thereby sorting "Season" values ​​in the order in which they naturally occur in a calendar year. According to an embodiment shown in FIG. 28(e), after files are sorted by tag value, they may be grouped by adding a group name (using the tag value), a collapse or expand control, statistics, and a divider, and flagged with a "Grouped" indicator 28100. According to an embodiment shown in FIG. 28(f), an unspecified group is available for all items that do not have values ​​for attributes, properties, or tag groups. According to an embodiment shown in FIG. 28(g), groups are collapsible.

[0177] According to an embodiment, multi-level grouping is achieved by classification by multiple attributes. According to an embodiment shown in FIG. 29, files are first grouped 29100 by their "season" value, and then files within the "spring" group are classified 29200 by their "date" value. According to an embodiment, any classified group can then be grouped at any level. According to an embodiment, as shown in FIG. 30, an interface exists that allows multi-level classification and grouping, where "season" 30100 and "date" 30200 values ​​are selected to be grouped and classified simultaneously in the order specified for grouping and classification by numeric indicator 30300.

[0178] Integrated merging of search trees and folders using a single hierarchical structure

[0179] According to an embodiment, one purpose of constructing additional search trees is to provide alternative "access paths" to folders and files within the storage folder tree. According to a further embodiment, when both search nodes and folders are presented and managed together, it is beneficial or important that they be visually, logically, functionally, and operationally similar to one another. However, such presentation formats generally lack the flexibility required for search tree management.

[0180] According to an embodiment, the folder suggestions have similar functionality to 6100, 6200, 6300, and 6400. According to an alternative embodiment, the four functions may be implemented, alone or in combination, as menu options or any other provision provided by an operating system or application program.

[0181] According to an embodiment shown in FIG. 31( a), a button 31100 with functionality similar to 6100 is available and appears on a parent folder with subfolders as a child list toggle. According to an embodiment shown in FIG. 31( b), after expanding 31100, the subfolders appear under the parent folder along with the parent folder's immediate files (if any). This presentation differs slightly from two existing commonly used folder presentations shown in FIG. 31( c), which have an incomplete contents list 31110 or do not display the parent folder 31120. According to an embodiment, this presentation is such that the parent folder, which is the list of current subfolders, and the list of individual files under the parent folder are both merged together under the parent folder so that they can appear together in one place. According to an embodiment, 31100 differs from existing subfolder toggles in folder tree navigation because the parent folder's immediate child files are also visible, completing the tree structure view and content (child list) view for the parent folder in one place.

[0182] According to the embodiment shown in Figure 31(d), button 31200, with functionality similar to 6200, is available in all folders as an individual item toggle. According to the embodiment shown in Figure 31(e), after expansion of 31200, a complete list of all child files appears under the parent folder without a hierarchical tree structure of subfolders. According to the embodiment, the file list toggle of 31200 corresponds to file-only search results in the parent folder, making it easy to implement in systems where search functionality is readily available.

[0183] According to an embodiment, any file under a parent folder or under any subfolder of a parent can be accessed at any level within the folder tree structure, which is useful, for example, when files need to be presented in a customized folder at any level.

[0184] According to an embodiment, buttons 31100 and 31200 cooperate to provide a flexible and complete presentation that includes both the tree structure and individual file items, as shown in Figure 31(f). For displaying the detailed contents of a parent folder, the presentation is always complete using either button 31100 or button 31200, ensuring that presentations of parent folders using both buttons in different folders and subfolders are logically complete, whatever the presentation end format. Similar to buttons 6100 and 6200 in search tree nodes, buttons 31100 and 31200 also need to be coordinated to avoid being expanded simultaneously for the same folder.

[0185] According to an embodiment, a select button 31300 and an open button 31400 are incorporated, which have similar functionality to 6300 and 6400. According to a further embodiment, 31300 and 31400 are incorporated, as shown in Figure 31(d).

[0186] According to an alternative embodiment, using the presentation and controls of 31100, 31200, 31300, and 31400, search tree nodes and storage folders behave as if they were managed within the same system interface, although they are still separate tree structures. Existing search engines only handle the relationship between search requests and individual items in a data collection, and do not recognize anything (especially the relationship) between files and folders, so parent folders, subfolders, or individual files are all treated equally and intermixed in the search result set as separate, independent items. The logical and hierarchical (i.e., containment) relationships represented by the folder tree structure are completely lost after the collection has undergone the search process. Therefore, search tree nodes and folders are not logically merged with each other using a single hierarchical structure.

[0187] For example, with respect to the sample storage folder structure shown in Figure 32(a), the search tree presentation in Figure 32(b) looks good with folders (and only folders) grouped using some keywords. However, as soon as the folders actually contain individual files within them, as in Figure 32(c), problems arise. Because existing search engines do not recognize the containment relationship between folders and files, in the search tree, individual files are not considered to match the keywords, even though they are located within the corresponding parent folder. According to the embodiment shown in Figure 32(d), files that are not considered to match the exact keywords of the grouping are listed under the Uncategorized node.

[0188] The problem persists even if the files have the same searchable characteristics (e.g., after being manually tagged one by one with the same keywords as their parent folders) and are listed under the same search node as their parent folders. For example, in Figure 33, it can be difficult for a user to distinguish which "Photo Slides" were originally under "Hong Kong 2005" and which were originally under "Japan 2005" if the Uncategorized node is emptied and they are all separated from their parent folders in the search result list.

[0189] Also, as shown in Figure 34, there are cases where a particular file is already listed individually under a search node in parallel with its parent folder 34100, so it is also logically incorrect to expand a folder listed under a search node so that the files within the folder are displayed under the same search node.

[0190] Existing search engines are unaware of folder structure when a search request is evaluated against a stored collection, and therefore treat both folders and files within folders identically (independently and individually), so that both folders and files end up being listed identically in the simplified results list of data items returned in response to a search request.

[0191] According to embodiments, these problems are rectified if the data collection itself is stored in a simple list (like many photo collections on a cell phone), or if the user intentionally wishes to completely ignore the existing folder structure by building a direct access path to every individual file in the collection, making searchable features available in every single file, as with tagging. However, the existing folder structure can be very useful for accurately identifying and organizing the data collection and all the files in the collection.

[0192] According to an embodiment, the search request processing procedure is adjusted to recognize and respect the existing folder tree structure. According to a further embodiment, this is achieved by returning only the top-level (parent) folder as the initial search result set, rather than all folders discovered from the data collection that match the search request, and displaying all remaining search results below the top-level folder using a presentation format for the folder tree structure with 31100, 31200, 31300, and 31400. According to the embodiment shown in Figure 35, when traditional search processing is used, the top-level matching folder is in the search result set, so the initial search result display from the folder-aware search processing is similar to the embodiment described above, but with an empty Uncategorized node.

[0193] According to an embodiment, among all parent folders, and subfolders and individual files within the parent folders, that are positively identified by a search request, the containment relationships therebetween indicate that if a parent folder matches a search request, then logically speaking, all subfolders and files within the parent folder also match the same request, even if the required search result characteristics are not technically or explicitly available in the subfolders or individual files. In other words, both the parent folder and all of the content beneath it should be returned in the result set for the search request.

[0194] According to embodiments, by using controls 31100, 31200, 31300, and 31400, the complete contents of the entire tree under a parent folder can be displayed in various formats, with all of the individual files from any level appearing or hiding under either the parent folder or a subfolder at any level. According to further embodiments, the initial search result set can be reduced to only the top-level folder, but the remainder of the search result set can also be displayed under the parent folder, if desired, with their consistency and completeness always maintained. According to the embodiment shown in FIG. 36, a well-constructed and maintained folder structure ensures that folders never overlap, so as long as the top-level folder appears only once in the search result set, duplicate or conflicting folders and files will not appear in the result presentation.

[0195] According to an embodiment, after the search result processing and result presentation procedures become folder-aware as described in the above embodiments, the search tree and folder tree can be merged into the same hierarchical presentation, unifying the management system.

[0196] According to embodiments, when the top-level folder is first collapsed, the search result set is in its smallest form. According to embodiments, when a folder is expanded at any level, the search result details are presented with their hierarchical information preserved.

[0197] According to an embodiment, the searchable features of a parent folder are automatically inherited and projected to all subfolders and child files, regardless of whether such features and properties are explicitly present in the subfolders and child files, thereby consistently maximizing the size of the overall result set even while minimizing the size of the initial result set.

[0198] According to an embodiment, using a folder-aware search method, individual files appear directly under a search node only if they do not belong to any parent folder that matches the node. A further embodiment of individual files under a search node that do not belong to any parent folder that matches the node, where both the folder and the individual file are at the same level, is shown in Figure 37(a). According to a further embodiment shown in Figure 37(b), the file "Other 2002" is listed directly under the search node alongside the folder "Europe 2002" because it does not have its own parent folder that matches the search request.

[0199] In an embodiment, comparing the original folder structure shown in Figure 38(a) with the search tree structure shown in Figure 38(b), even though the folders and files are reorganized from Figure 38(a) to Figure 38(b) using the search tree, the folder structure for both the folders and files reorganized into the classified search nodes and the folders and files remaining in the uncategorized nodes remains intact during the classification operation.

[0200] According to an embodiment, the presentation of search nodes corresponds to a search request that positively identifies, and due to the containment relationship between a parent folder and its subfolders and child files, all subfolders and files in the matching parent folder can be included in the search result set even if they do not have searchable features explicitly configured. According to a further embodiment, in the search tree, these nodes are classified-only nodes whose corresponding search request contains only the Boolean operator AND, and, if present, does not contain the Boolean NOT.

[0201] According to embodiments, for Uncategorized nodes and classified nodes below Uncategorized nodes in the search tree, no such containment relationship can be indicated between parent folders and subfolders and child files below them if their corresponding search requests are fully or partially "negated" by at least the Boolean NOT operator. According to embodiments, all folders and files must specifically match the request to be valid items in the result set for these nodes.

[0202] According to an embodiment shown in FIG. 39(a), a folder structure may be constructed in which "Photo Slide" files are divided first by date and then by location. To reverse or reorganize the grouping of files, a search tree may be constructed on this collection so that files are divided first by location and then by date relative to the sample folder tree. According to an embodiment, top-level matching folders are also listed for such full or partial negation requests. According to an embodiment, by definition, all top-level folders that specifically match a search request must be listed in the result set for those search nodes. According to an embodiment, all folders and files that specifically match a search request may be either these top-level folders or subfolders and files within them, either the complete set or a subset of the folder tree under the top-level folders (since all folders and files outside match at least one categorized node, making it impossible to match a "negation" request). Thus, according to the embodiment shown in Figures 39(b) and 39(c), after the files and folders related to "Europe" and "Japan" are grouped together, folders "2002", "2005", "2007", and "2010" are listed under the Uncategorized node, and some of the top-level folders, for example "2002", "2007", and "2010", are cancelled or marked or disabled to reflect that none of the subfolders or files under them match the negation request, leaving only the top-level folder "2005" with actual content ("Hong Kong") to be further processed.

[0203] Logically speaking, it would be useless and even misleading to list folders for "2002," "2007," and "2010" in the result set if none of their actual contents matched the search request for uncategorized nodes. However, according to an embodiment, technically speaking, such top-level folders cannot be filtered out or omitted from the search result set because they themselves match the negative request.

[0204] According to an embodiment, the folder-aware search process checks the state of individual subfolders and files within a parent folder and then sets or updates the state of the parent folder based on the state of its contents, so that the top-level folder can be distinguished and marked as logically inconsistent, invalid, a partial match, or an exact match accordingly.

[0205] According to an embodiment, to maintain content integrity for partially matched parent folders, all subfolders and files directly below them are displayed together when the parent folder is expanded. According to a further embodiment, the subfolders and files in such cases are further differentiated and marked accordingly. According to an embodiment, these individual unmatched subfolders and files are actually duplicates because they must match some classified node before they can be considered unmatched for a negated node in the same tree structure.

[0206] Although the different types of requests, folders, files, duplicates, and the logic between them all may seem complex, in embodiments where "invalid" folders and duplicates are appropriately marked or presented, the resulting presentation is easy to understand. According to further embodiments, a user can use such presentation to associate uncategorized items with already categorized items within the same context under the same parent folder. Overall, these embodiments are an improvement over the result sets obtained with traditional search result processing, where matching subfolders and individual files are listed 39100 separately and independently from the top-level folder 39200, as shown in Figure 39(d), making the result set large and difficult to explore.

[0207] According to an embodiment, the folder-aware search request processing system automatically projects search features downward from a parent folder to subfolders and files within the parent folder for positively identifying search requests. According to a further embodiment, the folder-aware search request processing system automatically pulls match status upward from subfolders and files to their parent folder for full or partial negation search requests. According to an embodiment, the folder-aware search request processing system maintains the consistency and completeness of context and hierarchical information. According to a further embodiment, context and hierarchical information is maintained for all positively identifying and full or partial negation search requests. An embodiment of such a search request processing system is shown in FIG. 40, where duplicate records and unmatched folders under a partial match parent folder, such as an uncategorized folder for "Japan" with a date under the place name in the search tree, are recognized and marked or canceled.

[0208] According to an embodiment, a classified search node, when viewed by itself, may represent a partially negated search request when located under the Uncategorized node in the overall search tree structure, such as the "2005" search node under the Uncategorized node in Figure 41. According to a further embodiment, such a search node should be presented similarly to a fully negated Uncategorized node. According to the embodiment shown in Figure 41, the Uncategorized node under the Uncategorized node is marked as logically inconsistent or invalid.

[0209] According to an embodiment, the search request processing system can be used in combination with a conventional search request processing mode.

[0210] According to embodiments, the above-described methods and systems may be implemented in a computing device including a processor, a display, and a memory having access to the data items. The storage tree and associated collection of data items are not necessarily accessible to the user's computing device via, for example, a wired or wireless network connection, nor do they necessarily have to reside in the memory of the user's computing device, although often they are.

[0211] Various embodiments of the present invention have been described in detail. Since modifications and / or additions to the best mode described above may be made without departing from the essence, spirit, or scope of the present invention, the present invention is not limited to those details, but is limited only by the claims. The section headings herein are provided as organizational guides. These headings do not limit or characterize the invention as set forth in the claims.

Claims

1. A computer system for managing a collection of data items having both system-defined properties and user-defined properties, and providing the ability to treat the user-defined properties in the same way as the system-defined properties of the collection of data items within management tasks.

2. The computer system of claim 1 , wherein the user-defined properties are tagged with tags that are defined and stored with the collection of data items in the form of name:value pairs.

3. The computer system of claim 1 , wherein the management task is capable of displaying the collection of data items in a list.

4. 1. A computer search query processing system for searching a storage tree associated with a collection of data items and providing a search result set of data items, the search result set of data items being identified by a search query of one or more language or non-language terms, the search result set of data items being minimized when all sub-nodes and / or individual data items in the storage tree are hidden by a top-level node identified by the search query and omitted from the search result set of data items.

5. 1. A computer-implemented method for selecting one or more data items from a collection of data items and associating the one or more data items with a data management routine, wherein the association between the selected one or more data items and the data management routine is established using tags defined and stored with the one or more data items.

6. The method of claim 5 , wherein the data management routine is capable of visually representing the collection of data items.

7. The method of claim 5 , wherein the data management routine has access to data in the collection of data items.

8. 1. A computer-implemented method for managing one or more searchable properties of one or more data items by establishing or breaking associations between the one or more data items and one or more search tree nodes, each of the one or more search tree nodes corresponding to a search query of one or more language or non-language terms.

9. The method of claim 8 , wherein one or more searchable properties of the one or more data items are tagged with tags that are defined and stored with the one or more data items.

Images