HK1098848B - System and a method for presenting related items to a user - Google Patents

Description

System and method for submitting related items to a user

Technical Field

The present invention relates generally to the field of computer software, and more particularly to a system and method for displaying items stored on a computer to a user.

Background

Providing computer users with the ability to quickly locate and display a piece of information regardless of the format or location of the information has been a challenge that has been struggled for many years by the computer industry. Today, the above problems become more pronounced as the number of people using computers in their daily routine and the types of information stored on computers increase.

Typically, as in Microsoft corporation98^TMThe storage information is maintained in the computer database in a hierarchical structure organized by files of the information or media stored in the folders. Although this data storage approach has been widely used for many years, it has limitations in that some data resides outside of the file hierarchy and is limited in format and location when the user searches for the desired information. Accordingly, computer software vendors are currently seeking data storage methods that can replace the traditional file hierarchy.

An example OF such a data storage alternative is disclosed in commonly owned co-pending U.S. patent application (No. assigned, attorney docket No. MSFT-1784) "SYSTEM AND METHOD FOR resetting UNITS OF information management BY A HARDWARE/SOFTWARE suite INTERFACE SYSTEM partitioned OF PHYSICAL reset". This copending application was filed on 8/21/2003 and discloses a data store that unifies the stores into a single database. The database is a place where all data is stored; there is only one way to submit data to the database and there is only one way to query the data. By replacing the ancient file system with this modern database technology, the data store may become easier to search, more reliable, more accessible, and more flexible.

Once this unified data store is in place, appropriate tools and capabilities need to be provided to the user to interact with the stored data. Conventional operating systems, e.g. Microsoft corporation2000^TMIncluding a shell application that provides a user interface for viewing different information about the computer. The shell typically includes a file system browser that enables a user to navigate through the file system and to find and open files and folders. For example, Microsoft corporationResource manager^TMIs included in the window2000^TMThe file system browser utility of (1).

The shell also enables a user to view non-file items such as printers or fonts. This navigation is possible because a typical shell is programmed with specific functionality to display these particular items as if they were located in the file system. For example, in2000^TMThe user may open a "printer" folder in the settings option on the start menu. Since the printer is a hardware part and not a file, the graphical representation of the printer is accomplished through the use of custom codes, with the goal of displaying the printer as if it were a file residing in a "printer" folder. However, implementations using custom code and custom drawing exceptions are complex for developer implementations, may be unreliable, and may reduce the resiliency of the shell browser. Furthermore, if there is no custom code of this typeAnd custom drawing exceptions, the shell will not be able to display this type of item. Thus, conventional enclosures are limited in their ability and flexibility to display particular items to a user.

Another limitation of conventional shell browsers is the limited ability to display items in a relational manner. Typically, a shell browser is operable to display items only in a hierarchical manner in which they are stored — organized within files stored in folders. For example, if a user wants to view all picture files stored in a computer, the user first has to place all such picture files in the same folder. Because the shell has limited ability to determine relationships between items, it is difficult for a user to view files in a relationship driven environment.

Furthermore, conventional shell browsers are limited in their ability to display a set of items in an environment customization environment that pairs relevant information and tasks with the set of displayed items. By providing such pairings, developers can provide users with the appropriate information and tools needed to navigate between items while facilitating the performance of common tasks associated with the items. However, the prior art does not allow developers to provide such an experience without using custom code.

An example of a file presented in an enhanced environment through the use of custom code is that included in Microsoft corporationXP^TMMy photos (My Pictures) folder in the operating system. When the image files are stored in the my photos folder, the user can view the images in different sizes, rotate the images, view in a slide show, print the images, or copy the images to a CD.XP^TMThe shell in (a) has incorporated these image-related tasks into the display of this folder with custom codes, so that when the user chooses to store a photograph in that particular folder, it can be easily accessedNavigate through the photos and perform the usual tasks related to the files. However, only the files stored in my photos folder are displayed in this environment, and custom code is used to create this functionality. While my photo folder is an improvement over traditional item submissions, the ability of developers to define such content rich environments without the use of custom code remains limited.

Accordingly, there is a need for an improved shell that is capable of displaying each item in a universal data store, and an improved shell that is configured to render items in a universal data store in a relationship driven environment. There is also a need for improved capabilities within the shell for developers to create custom environments that do not require custom code to display items with appropriate environment information and related tasks.

Disclosure of Invention

The present invention meets the above-identified needs and overcomes one or more deficiencies in the prior art by providing a system configured to submit related items stored in a data store to a user. In one aspect of the invention, a system for submitting related items to a user is provided. Including a universal data store containing a plurality of items. At least some of the items in the data store contain relevant information. The shell uses the related information to submit the related items.

Another aspect of the invention is a computer-implemented method for submitting related items to a user. The method accesses data in a universal data store that contains items that include information that allows relationships between items in the data store to be determined. This relationship information is used to determine relationships between items and the related items are displayed to the user.

Drawings

The invention is described in detail below with reference to the attached drawing figures, wherein:

FIG. 1 is a block diagram of a computing system environment suitable for use in implementing the present invention;

FIG. 2A is a block diagram illustrating a computer system divided into 3 component groups: a hardware component, a hardware/software interface system component, and an application component;

FIG. 2B illustrates a conventional tree-based hierarchy of files grouped within directories in a file-based operating system;

FIG. 3 is a block diagram illustrating a storage platform according to the present invention;

FIG. 4 illustrates structural relationships between items, item Folders, and Categories in embodiments of the present invention;

FIG. 5 is a diagram of data contained within an item, according to one embodiment of the invention;

FIG. 6 is a flow diagram illustrating a method for submitting one or more items to a user in accordance with one embodiment of the present invention;

FIG. 7 is a flow diagram illustrating a method for submitting one or more items to a user in accordance with one embodiment of the present invention;

FIG. 8 is a schematic diagram illustrating a view schema hierarchy in accordance with an embodiment of the present invention;

FIG. 9 is a diagram illustrating a view schema hierarchy including an explorer view schema, according to one embodiment of the present invention;

FIG. 10 is a flow diagram illustrating a method for submitting items to a user in accordance with one embodiment of the present invention; and

FIG. 11 is a flow diagram illustrating a method for submitting related items to a user, according to one embodiment of the present invention.

Detailed Description

I. Introduction to the theory

The subject matter of the present invention is described with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the term "step" may be used herein to connote different elements of methods employed, the term should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

The present invention provides improved systems and methods for displaying items stored in a computer to a user. The following modes illustrate an exemplary operating environment for the present invention.

A. Exemplary operating Environment

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

As shown in FIG. 1, an exemplary general purpose computing system includes a conventional personal computer 20 or the like, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes Read Only Memory (ROM)24 and Random Access Memory (RAM) 25. A basic input/output system 26(BIOS is stored in ROM 24), containing the basic routines that help to transfer information between elements within the personal computer 20, such as during start-up, the personal computer 20 may also include a hard disk drive 27 (not shown) for reading from or writing to a hard disk, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31, such as a CD ROM or other optical media, the hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively A removable magnetic disk 29 and a removable optical disk 31, although one skilled in the art will appreciate that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, Random Access Memories (RAMs), Read Only Memories (ROMs), and the like, may also be used in the exemplary operating environment. Similarly, an exemplary environment may include various types of monitoring devices, such as heat sensitive elements and security or fire alarm systems, as well as other sources of information.

A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37 and program data 38. A user may enter commands or information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a Universal Serial Bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 may also include a host adapter 55, Small Computer System Interface (SCSI) bus 56, and an external storage device 62 connected to the SCSI bus 56.

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

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

As shown in the block diagram of FIG. 2A, the computer system 200 may be broadly divided into three component groups: a hardware component 202, a hardware/software interface system component 204, and an application component 206 (also referred to herein in some circumstances as a "user component" or a "software component").

In various embodiments of the computer system 200, and referring again to FIG. 1, the hardware components 202 may include a Central Processing Unit (CPU)21, memory (ROM 24 and RAM 25), a basic input/output system (BIOS)26, and various input/output (I/O) devices, such as a keyboard 40, a mouse 42, a monitor 47, and/or a printer (not shown), among others. The hardware component 202 contains the basic physical architecture for the computer system 200.

The application programs component 206 comprises various software programs including, but not limited to, compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for different users (machines, other computer systems, and/or end users).

The hardware/software interface system component 204 includes (and in some embodiments may only include) an operating system that itself comprises, in most cases, a shell and a kernel. An "operating system" (OS) is a specialized program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component 204 may also include a Virtual Machine Manager (VMM), a Common Language Runtime (CLR) or its equivalent, a Java Virtual Machine (JVM) or its equivalent, or other such software components, in place of or in addition to an operating system in the computer system. The purpose of the hardware/software interface system is to provide an environment in which a user can execute applications. The goal of any hardware/software interface system is to make the computer system convenient to use and to make efficient use of the computer hardware.

The hardware/software interface system is typically loaded into the computer system at startup and thereafter manages all of the applications in the computer system. An application interacts with a hardware/software interface system by requesting services through an Application Program Interface (API). Some applications enable end users to interact with the hardware/software interface system through a user interface, such as a common language or a Graphical User Interface (GUI).

In general, a hardware/software interface system performs a variety of application services. In a multitasking hardware/software interface system where multiple programs may be running simultaneously, the hardware/software interface system determines which application should be running in what order and how much time is allowed for each application before switching to another application in turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications and handles input and output to additional hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends information to each application (and in some cases to the end-user) regarding the operational status and any errors that may have occurred. The hardware/software interface system may also offload the management of batch jobs (e.g., printing) so that the initial application is not bound by the job and it may resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system can also manage dividing a program so that it runs on more than one processor at a time.

The hardware/software interface system shell (referred to herein simply as the "shell") is the interactive end-user interface to the hardware/software interface system. (A shell may also be referred to as a "common interpreter" or in an operating system as an "operating system shell"). A shell is the outer layer of a hardware/software interface system that is directly accessible by applications and/or end users. A "shell browser" provides a user interface that enables a user to view and interact with the hardware/software interface. In contrast to shells, a kernel is the innermost layer of a hardware/software interface system that interacts directly with hardware components.

While it is envisioned that numerous embodiments of the present invention are particularly well-suited for computerized systems, nothing in this document is intended to limit the invention to such embodiments. Rather, as used herein, the term "computer system" is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.

B. Traditional file-based storage

In most computer systems today, a "file" is a unit of storable information that may include a hardware/software interface system as well as applications, data sets, and the like. In all advanced hardware/software interface systems (windows systems, Unix, Linux, Mac OS, virtual machine systems, etc.), files are essentially discrete (storable and retrievable) units of information (e.g., data, programs, etc.) that can be manipulated by a hardware/software interface system. All file groups are typically organized in "folders". In Microsoft Windows, Macintosh operating systems, and other hardware/software interface systems, a folder is a collection of files that can be retrieved, moved, or otherwise manipulated as a single unit of information. These folders are organized in a tree-based hierarchical arrangement called a "directory" (described in more detail below). In certain other hardware/software interface systems, such as DOS, z/DOS, and most Unix-based operating systems, the terms "directory" and/or "folder" are interchangeable, while earlier apple computer systems (e.g., apple IIe) used the term "directory" rather than "directory"; however, as used herein, all of these terms are considered synonymous and interchangeable, and are also intended to include all other equivalent terms used for or directed to the hierarchical information storage structure and its folder and file components. Generally, directories (also known as folder directories) are tree-based hierarchical structures in which files are grouped into folders, and folders are arranged according to relative node locations that comprise the directory tree. For example, as shown in FIG. 2B, a base folder (or "root directory") 212 of a DOS-based file system may include a plurality of folders 214, each folder 214 may further include additional folders (e.g., "subfolders" of a particular folder) 216, and each subfolder 216 may also include an additional folder 218 without limitation. Each of these folders may have one or more files 220, although at the hardware/software interface system level the individual files in a folder are not identical except for their location in the tree hierarchy. It is not surprising that this approach of organizing files into a folder hierarchy indirectly reflects the physical organization of typical storage media (e.g., hard disks, floppy disks, CD-ROMs, etc.) used to store these files.

In addition to the foregoing, each folder is a container of subfolders and its files, i.e., each folder owns its subfolders and files. For example, when a folder is deleted by the hardware/software interface system, the subfolders and files of that folder are also deleted (in the case of each subfolder, its own subfolders and files are also recursively included). Likewise, each file is typically owned by only one folder, and although a file may be copied while the copy is located in a different folder, the file copy itself is a distinct, stand-alone unit that is not directly associated with the original file (e.g., changes to the original file are not reflected in the copy file at the hardware/software interface system level). Thus, files and folders are inherently "physical" in that folders are considered physical containers, and files are considered discrete and separate physical elements within these containers.

General data memory

The storage platform utilized by the present invention extends and broadens the data platform beyond the existing file system types described above and is designed to be the storage of all types of data. A data store designed to hold all types of data may be referred to as a universal data store. An example OF a universal data store suitable FOR use with the present invention is described in commonly owned, co-pending application "SYSTEM AND METHODS FOR reproducing information and management BY A HARDWARE/SOFTWARE implementation OF interactive program BUT not yet specified" (attorney docket number. MSFT-1748), filed on 21/8/2003, which is hereby incorporated BY reference.

A. Overview

Referring to FIG. 3, a storage platform 300 according to the present invention comprises a general data store 302 implemented on a database engine 314. In one embodiment, database engine 314 comprises a relational database engine with object-relational extensions. In one embodiment, the relational database engine 314 comprises a Microsoft SQL Server relational database engine.

The general database memory 302 implements a data model 304 that supports the organization, searching, sharing, synchronization, and security of data. Certain types of data are described in schemas, such as schemas 340, and the storage platform 300 provides tools 346 for adopting and extending those schemas, as explained more fully below.

The change tracking mechanism 306 implemented in the universal data store 302 provides the ability to track data store changes. The universal data store 302 also provides security capabilities 308 and promotion/demotion capabilities 310. The universal data store 302 also provides a set of application programming interfaces 312 to expose the capabilities of the universal data store 302 to other storage platform components and applications (e.g., applications 350A, 350B, and 350C) that utilize the storage platform.

The storage platform of the present invention also contains an Application Programming Interface (API)322 that enables applications, such as applications 350A, 350B, and 350C, to access all of the aforementioned capabilities of the storage platform and to access data described in schema form. The storage platform API 322 may be used by applications in conjunction with other APIs, such as the OLE DB API 324 and the Microsoft Windows Win32API 326.

The storage platform 300 of the present invention may provide a variety of services 328 to applications, including a synchronization service 330 that facilitates data sharing between users or systems. For example, the synchronization service 330 may allow interoperability with data stores 340 having the same format as the data store 302, as well as access to data stores 342 having other formats. The storage platform 300 also provides file system capabilities that allow interoperability of the universal data store 302 with existing file systems, such as windows NTFS file system 318.

In at least some embodiments, storage platform 320 can also provide applications with additional capabilities for enabling work on data and for enabling interaction with other systems. These capabilities may be embodied in the form of additional services 328, such as an information agent service 334 and a notification service 332, and in the form of other utilities 336.

In at least some embodiments, the storage platform is included in, or forms an integral part of, the hardware/software interface system of the computer system. For example, and without limitation, the storage platform of the present invention may be included in, or form an integral part of, an operating system, a Virtual Machine Manager (VMM), a Common Language Runtime (CLR), or an equivalent entity, or a Java Virtual Machine (JVM), or an equivalent entity.

Through its common storage function and schematized data, the storage platform of the present invention enables more efficient application development for consumers, technicians, and enterprises. It provides a rich and extensible programming plane area that not only makes available the capabilities inherent in its data model, but also encompasses and extends existing file system and database access methods.

B. Data model

The universal data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, searching, sharing, synchronization, and security of data residing in the store. In the data model of the present invention, the basic units of stored information may be referred to as items. The data model provides a mechanism for declaring items and item extensions, and for establishing relationships between items and for organizing items into folders and categories.

In one embodiment of the invention, the data model relies on two basic mechanisms, Type (Type) and Relationship (Relationship). A type is a structure that provides a format for managing the form of an instance of the type. The format is expressed as an ordered set of properties (Property). An attribute is a set of values of a given type or the name of a value. For example, a USPostalAddress type may have attributes street, city, zip code, state. Attributes may be required or optional.

Relationships can be declared and represent a mapping between the two sets of instances. For example, there may be a relationship declared between a Person (Person) type and a Location (Location) called LivesAt that defines which people live in which places. The relationship has a name, two endpoints called a source endpoint and a destination endpoint. Relationships may also have an ordered set of attributes. Both the source endpoint and the destination endpoint have a name and a type. For example, the LivesAt relationship has a source of type person called Occupant (Occupant) and a target of type place called residence (Dwelling), and has attributes, StartDate and EndDate, indicating periods of time during which occupants live in the residence. Note that a person may live in multiple dwellings for a period of time, and a dwelling may have multiple occupants, so the most likely place to place the StartDate and EndDate information is on the relationship itself.

Each relationship defines a mapping between instances that is limited by type (given as an endpoint type). For example, when a car (Automobile) is the occupant, the LivesAt relationship is not a relationship because the car is not a person.

1. Item(s)

As described above, the basic unit of information stored in a universal data store according to the present invention may be referred to as an item. An item is a unit of storable information that, unlike a simple file, is an object that has a basic set of properties that are commonly supported across all objects exposed to an end user or application by the storage platform. Those skilled in the art will appreciate that the versatility of the universal data store is possible in part because each item in the data store includes data indicative of those basic attributes stored according to a data schema that is constant for each item.

The generic data schema provides a generic basis for building a conceptual framework for creating and organizing items and properties. The generic data schema defines certain specific classes of items and properties, and those specific base types of features from which subclasses can be further derived. The use of this universal data schema enables programmers to conceptually distinguish items (and their corresponding types) from properties (and their corresponding types). Further, the generic data schema presents a basic property group in which all items can hold all items (and their corresponding item types) derived from the basic items (and their corresponding item types) in the generic data schema. By storing each item according to the generic data schema, the shell browser can interpret and present each item in the data store and its basic properties to the user. Examples of common data patterns suitable for use in the present invention are described in U.S. patent application Ser. No. (not yet assigned) (attorney docket number MSFT-1748), co-pending application for Presenting Units of information management by a Hardware/Software Interface System but Independent of physical reproduction, 2003, 21.8.2003, which is incorporated herein by reference.

Items also have properties and relationships that are commonly supported across all item types that include features (enabling new properties and relationships to be introduced). Those skilled in the art will appreciate that the present attribute and relationship data may be referred to as metadata associated with the item. As described below, metadata may be stored according to an item decoration schema. The item decoration schema may indicate an appropriate manner of presenting the item to the user.

An item is an object for general-purpose operations such as copy, delete, move, open, print, backup, restore, copy, and the like. Items are units that can be stored and retrieved, and all forms of storable information manipulated by the storage platform exist as items, properties of items, or relationships between items, each of which will be described in greater detail hereinafter.

Items are intended to represent real-world, easily understood units of data like contacts, people, services, places, documents (of all various types), and so forth.

Items are independent objects; thus, if you delete an item, all of the item's properties are also deleted. Similarly, when an item is retrieved, what is received is the item and all of its properties contained in the item's metadata. Some embodiments of the invention may enable a person to request a subset of attributes when retrieving a particular item; however, the default of many such embodiments is to provide the item with all of its immediate and inherited properties at the time of retrieval. In addition, the properties of an item can also be extended by adding new properties to existing properties of the item type. These "extensions" are then the proper properties of the item, and subtypes of the item type may automatically include the extended properties. The extension is also referred to as metadata associated with the file.

2. Item folder and category

The various sets of items are organized into specific items called item Folders (not to be confused with file folders). However, unlike most file systems, an item may belong to more than one item folder, so that when an item is accessed and fixed in one item folder, the fixed item may be subsequently accessed directly from another item folder. In fact, although access to an item may occur from different item Folders, what is actually being accessed is in fact the same item. However, an item folder need not own all of its member items, or may simply co-own items with other folders, so that deletion of an item folder does not necessarily result in deletion of the item.

Items may also belong to various categories based on common descriptive characteristics, such as (a) item type (or types), (b) a particular direct or inherited property (or properties), or (c) a particular value (or values) corresponding to an item property. For example, an item that includes a personal Contact information specific attribute may automatically belong to the Contact (Contact) category, and any item having a Contact information attribute may similarly automatically belong to that category. Similarly, any item whose place property has a value of "New York City" may automatically belong to the NewYorkCity Category.

Categories are conceptually different from item Folders in that item Folders may include items that are not related (i.e., do not have a common descriptive characteristic), while each item in a Category has a common type, property, or value ("commonality") that describes the Category, and it is this commonality that forms the basis for its relationship to other items in the Category. Moreover, while membership of items in a particular folder is not required based on any particular aspect of the item, for some embodiments all items that have commonality in a category with respect to a category may automatically become members of a category at the hardware/software interface system level. Conceptually, a category can also be viewed as a virtual item folder whose membership is based on the results of a particular query (such as in a database context), and items that meet the query criteria (defined by the commonality of the category) will include the membership of the item.

FIG. 4 illustrates the structural relationships between items, item Folders, and Categories in various embodiments of the present invention. The plurality of items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of respective item Folders 422, 424, 426, 428, and 430. Some items may belong to more than one item folder, e.g., item 402 belongs to item folders 422 and 424. For example, some items 402, 404, 406, 408, 410, and 412 may also be members of one or more of the categories 432, 434, and 436, while at other times, for example, items 414, 416, 418, and 420 may not belong to any category (although this is unlikely in some embodiments, where possession of any attribute may automatically imply membership in a category, and thus items must be completely featureless so as not to be members of any category in such embodiments). In contrast to the hierarchical structure of folders, both categories and item folders have a structure that is closer to the directed graph shown. In any event, items, item Folders, and Categories are all items (albeit of different item types).

In contrast to files, folders, and directories, the items, item Folders, and Categories of the present invention are not characteristically "physical" in nature, in that they do not have the conceptual equivalent of a physical container, and thus an item may exist in more than one such location. The ability for items to exist in more than one item folder location, and the ability for items to be organized into categories, provides enhanced and enhanced data manipulation and storage structure capabilities at the hardware/software interface level, beyond that of the prior art.

3. Relationships between

An item may also contain relationship information that may determine a relationship between two or more items. A relationship is a binary relationship in which one item is referred to as a source and another item is referred to as a target. The source item and the target item are related according to the relationship. Relationships can be classified as: containment and reference relationships. Containment relationships control the lifetime of the target item, while reference relationships do not provide any lifetime management semantics.

Containment relationship types are also classified into Holding (Holding) and Embedding (Embedding) relationships. The holding relationship controls the lifetime of the target through a reference counting mechanism. A holding relationship does not contain its target, but controls the lifetime of the target. When all holding relationships of an item are removed, the item is deleted. Embedding relationships enables modeling of compound items and can be viewed as proprietary holding relationships. An item may be the target of one or more holding relationships, but an item is simply the target of an embedding relationship. An item that is a target of an embedding relationship may not be a target of any other holding or embedding relationship. The embedded relationships contain their targets and control the lifetime of each target. Those skilled in the art will appreciate that a single target may be in at most one embedded relationship, while a single target may be in multiple holding relationships.

The reference relationship does not control the lifetime of the target item. They may be dangling-the target item may not exist. Reference relationships can be used to model references to items anywhere in the entire item namespace (i.e., including the remote data store).

The get items do not automatically get their relationships. The application or shell must explicitly request the relationships of the items. Furthermore, changing the relationship does not change the source or target item; similarly, adding a relationship does not affect the source/target item. The relationship between two items may be declared and stored in the item, or shell, or application, and the two items may be determined to be related through the use of relationship information.

A reference relationship does not control the lifetime of the item it references. Even though reference relationships do not ensure the existence of a target, they do not ensure that the target type is as specified in the relationship declaration. This means that the reference relationship may be dangling. Also, reference relationships may reference items in other data stores. Reference relationships can be viewed as concepts similar to web page links.

In at least one embodiment, the storage platform of the present invention supports ordering of relationships. Sorting is accomplished by a property named "Order". There is no unique restriction on the sequence field. The order of relationships with the same "order" attribute values is not guaranteed, however it is guaranteed that they are arranged after relationships with lower "order" values and before relationships with higher "order" field values. It should be noted that the attribute "order" is not in the basic relationship definition. Instead, this is a foreign attribute that is stored as part of the relationship between the source and target.

As previously described, an item may be a member of an item folder. According to the relationship, an item can have a relationship with an item folder. In several embodiments of the invention, certain relationships are represented by relationships that exist between items.

4. Extensibility

Referring to FIG. 3, a storage platform is provided with an initial set of patterns 340 as described above. However, in at least some embodiments, the storage platform also enables customers, including Independent Software Vendors (ISVs), to create new schemas 344.

C. Database engine

As described above, the data store is implemented on a database engine. In one embodiment, the database engine comprises a relational database engine implementing the SQL query language, such as the Microsoft SQL Server engine with object relational extensions. However, it is understood that different database engines may be employed. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, it may be implemented on other types of databases, such as object-oriented and XML databases.

Presenting items to a user

Items in the universal data store may be presented to a user through a shell browser. Such browsers are well known in the art, and as mentioned above, shell browsers provide a user interface that enables users to view and interact with hardware/software interfaces.

A. Default display view

As described above, each item in the universal data store is stored according to a universal data schema. The schema includes a mechanism for describing items called type associations. Each type association has a base representation in the shell; by storing an item according to a type association, the shell is able to display the item according to at least one basic or default display view.

Type associations are attributes associated with an item; when data is placed into a universal data store, one or more attributes associated with the data must be declared in order to determine what type of item it is. These attributes may be included as metadata associated with the data. The shell has a set of default type associations that represent the most basic and least attributes that must be declared for an item.

FIG. 5 displays an item 500. The item 500 is stored according to a common data schema and includes a set of item data 502 and a set of metadata 504 that includes attribute declarations. Item data 502 can be any set of data suitable for inclusion in a data store. For example, the term data 502 can be associated with a word processing document. The attribute declaration metadata 504 includes at least one basic type declaration for the item 500. For example, the default type association may be a document type and the metadata 504 may suggest that the item 500 is a document type item. Because the shell includes a default display view associated with each default type, the shell may display the items 500 according to the default display view of the document type. The default display view for a document type may, for example, include icons that are used only in document type items. By presenting the word processing item with the icon, the user can quickly recognize that item 500 is a document. Those skilled in the art will appreciate that any of a variety of default type associations and default display attributes are acceptable for the present invention.

B. Item decoration View

In addition to property declarations, metadata associated with an item may include data indicating how the shell should decorate the presentation of the item. The adornment can in this case be considered as a "clue" on how to present the item to the user. The metadata may be stored according to an item decoration schema. The item decoration schema defines an item decoration view that the shell may utilize to present items. For example, the item decoration data may describe the most important declared properties of the item. These "high value" attributes may be most desirable in the shell for presentation.

Item 500 may optionally include item decoration data 506 stored according to an item decoration schema. To present the item 500, the item decoration data 506 may indicate a set of view fields suitable for presenting the item 500. The view field is a projection of the declared property, and the common view field may include "title", "author", "creation date", or "last modified date". The shell includes a set of standard view fields, and independent software developers (ISVs) may define view fields suitable for presenting their data. When developing new item types, ISVs may map their defined item properties to the view fields of the shell, or they may provide their own view fields.

For example, the item data 502 may contain song data. The set of declared properties 506 may include properties such as song title, artist, date recorded, album, song length, and other declarations appropriate for such song items. The item decoration data 506 may indicate view fields "title", "artist", and "album" that should be displayed to the user when the item 500 is presented in the shell.

The item decoration data 506 may describe more appropriate decoration items on the item data 502, such as text presented by a declared property. For example, one of the attribute declarations 504 may indicate a bit rate value to describe the recording quality. This attribute may be stored as the integer BITRATE. The item decoration data 506 may request that the bit rate be displayed and may decorate the field as "[ bit rate ] kB/s". In this method, the bit rate field is appropriately decorated so that the user can easily understand the meaning of the bit rate value in the view field.

Those skilled in the art will appreciate that the item decoration data 506 and its corresponding item decoration view may indicate a wide variety of presentation properties. The item decoration may be any aspect of the display supported by the shell. For example, some common other item decorations are data formatting, default ordering, and default icon size. Further, item decoration data 506 may describe common controls to use when displaying a given item. For example, the level field may use a level control that represents the level as a series of asterisks. The item decoration data 506 may describe tasks or verbs appropriate for use with the item. Those skilled in the art will appreciate that the terms "task" and "verb" describe some action to be taken with respect to an item and that these terms are used interchangeably. For example, "edit" or "preview" may be appropriate tasks/verbs associated with an item. The shell may also be configured to launch applications supporting these tasks upon user selection to perform actions with respect to the item.

Those skilled in the art will appreciate that item decorations will change and grow over time. The present invention contemplates that when new item decorations are implemented, the new items may utilize these decorations, while older items will continue to be displayed normally by utilizing the older display properties provided by the shell.

FIG. 6 illustrates a flow diagram of a method 600 for presenting items to a user in accordance with the present invention. At 602, the method 600 accesses a universal data store in response to a request to present one or more items to a user. At 604, the method considers one or more items selected for presentation. Items containing metadata stored according to an item decoration schema are presented to the user according to an item decoration view shown at 606. Items that do not contain such metadata are presented according to a default display view as shown at 608. Those skilled in the art will appreciate that, as described above, these schemas and presentation views may include various display attributes used in presenting each item in the data store.

C. View of the housing

As described above, the item decoration view is sufficient to present a given item in its entirety or to include a homogeneous set of items with similar item decoration views. To display items with different item decoration schemas, the shell provides a shell view schema that presents the items according to the shell decoration view. The shell view schema enables a shell or ISV to declare the appropriate view given a heterogeneous set of data.

Items selected for presentation in the shell decoration view may include a common feature. Those skilled in the art will appreciate that a wide variety of common features are acceptable for the shell decoration view. For example, the shell view mode may define a "picture" view for displaying common and appropriate fields and metadata for all known picture types (e.g.,. GIF,. JPEG,. BMP,. GIFF, etc.). The shell view schema overrides the conflicting display properties of a given item decoration view and renders each picture item according to the shell view schema. As another example, a shell may provide a "document" shell view that is optimized around the appropriate columns, as well as metadata for items produced by typical productivity applications such as word processing documents, spreadsheets, or databases, although the item decorations for each of these items may vary greatly from one another. Such a view has a value by providing common attributes between each of these documents. Those skilled in the art will appreciate that when installing later document types, the shell view will be able to present these new items according to a consistent shell view, even if the new types are not accounted for when the view is first created.

In addition to forming view fields that are tailored to a given different set of items, the shell view schema may define display properties. For example, the view state, including the icon properties, the size of the preview pane, and the default sort order, may be defined by the shell view mode. The view schema also contains property decorations to be applied to the various columns, such as data formatting.

In the event that the shell view schema and the item decoration schema conflict, the shell view schema takes precedence. In the event that a display element is missing from the shell view schema, the shell view will fall back to the item decoration view for proper display. In this way, the shell view can make an appropriate view when displaying data that was not originally intended. Further, in an embodiment of the present invention, the shell view may follow the item decoration view to provide a non-conflicting decoration element. For example, the shell view may use "high value" metadata from its containing set of items to build an appropriate set of columns and metadata to display the items.

Those skilled in the art will appreciate that the shell view schema may provide a wide variety of display attributes, and that an ISV may want to provide such a shell view. Display attributes may include, without limitation: the size of the preview pane, the metadata to be displayed in the preview pane, the custom controls to be used, and the tasks and verbs appropriate for the rendered items.

FIG. 7 illustrates a flow diagram of a method 700 for presenting items to a user in accordance with the present invention. At 702, the method 700 accesses a data store in response to a request to present one or more items to a user. At 704, a determination is made as to whether each item selected for presentation includes the same item decoration schema. If all items have a common schema, the items are presented according to the schema, as shown at 706. If the presented items include items with different display modes or no display modes, the set of items are presented according to the shell decoration view at 708. As described above, such a shell view may be adapted to present different sets of items. An optional step of presenting one or more selected items with display elements from an item decoration view is included at 710. These display elements may enhance the presentation of items through the shell when the elements do not conflict with the shell decoration view.

Referring to FIG. 8, a view of an exemplary view schema hierarchy 800 is presented. The bottom layer of the hierarchy is an item view schema 802. The item view schema 802 provides the basic display required to represent an item or, if no view schema is provided, it provides a default display. Schemas above the item view schema 802 can defer or fall back to their display elements when needed.

The shell view schema 804 resides above the item view schema 802. As described above, a shell view schema can be utilized to display a set of items having different item views. The shell view schema defines tasks 806, preview pane characteristics 808, columns 810, and decorations 812 used to display items according to the shell view 804. The shell view may revert back to item view mode 802 to provide non-conflicting item decorations for shell view 804. Additionally, user view settings 814 may exist in the shell view. These settings represent the user-desired presentation format of the shell item. Those skilled in the art will appreciate that any number of display properties may be defined in a display mode and that a user may be presented with a number of options and controls related to display settings.

D. Explorer display views

The shell may also be configured to present items according to the explorer display view. A "resource manager" may be referred to as a storage application and may be provided by a shell or ISV. In one embodiment of the invention, a resource manager may be created to provide an overall experience that helps users manage a large group of items. For example, the explorer may enable a user to view, query, navigate, enter tasks, or organize selected items in the data store. The term "resource manager" should not imply that the displayed items are in place, and terms such as "activity center," "viewer," and "library" may be used interchangeably with "resource manager" to describe the storage application.

FIG. 9 illustrates an exemplary explorer schema hierarchy 900. The bottom layer of the hierarchy is an item view schema 902. The item view schema 902 provides the basic display required to render an item, while the explorer view schema 904 may defer or reuse display elements as needed.

The explorer view schema includes a shell view schema 906 and an explorer adornment 908. The explorer decorations 908 decorate the explorer as a whole and provide display elements such as unique colors and print elements. These explorer decorations 908 are persistent across the views provided by the explorer. Those skilled in the art will appreciate that a wide variety of display attributes are suitable for the explorer decorations 908. For example, data queries or tasks/verbs associated with an explorer item are adapted for display with the explorer. The displayed task will be better coupled with an application capable of performing the task.

The explorer view schema may optionally include a shell view schema 906 or multiple shell view schemas. The shell view schema 906 can be configured to provide a shell view of a subset of explorer items. For example, the explorer may be configured to display song items to a user. A first shell view mode may be included that provides a display of a set of albums and a second shell view mode that provides a display of song tracks. Thus, both types of items will have the appropriate view in the explorer. As described above, utilization of a shell view is related to presentation of a set of items that optionally share a common characteristic.

The explorer may also rely on shell views included in the shell. If the item selected for presentation in the explorer is not supported by any shell views included in the explorer, the shell may provide an appropriate shell view for use in the explorer. Similarly, as described above, the explorer may also fall back to the item display view or default display view provided by the shell. This function ensures that any item that can be displayed by the shell can be displayed in the explorer. The resource manager may be configured to follow the display mode provided by these shells, or may rely on them to provide, for example, display of unexpected data.

FIG. 10 illustrates a method 1000 for presenting items in an explorer display in accordance with the present invention. At 1002, the method 1000 accesses a data store and at 1004 selects an item to be displayed in an explorer. The selection of a resource manager entry may depend on consideration of the entry declaration (also referred to as a field entry). As described above, items in the data store may contain attribute information. This information is declared when the item is placed in the data store and can be updated throughout the life of the item. Such a declaration may be considered to correspond to a field entry of a property field group. For example, an item in the attribute field "author" may contain authorship information for a given item.

It may be desirable to present items that share one or more field items. For example, an explorer may be required that includes each item produced by a particular person. By considering the field entries of the author field, the explorer is able to select such browser items from the data store that are authored by a particular person. Those skilled in the art will appreciate that the mechanisms of such database queries are well known.

At 1006, it is determined whether the explorer includes a shell view suitable for presenting the explorer items. If such an appropriate shell view is not found in the explorer, method 1000 utilizes the views contained in the shell, as shown at 1008. If the appropriate shell view is included in the explorer, method 1000 presents the item using the shell view at 1010. At 1012, an optional step of utilizing the decorative element from the item display schema is performed. As described above, the explorer may use non-conflicting decorations from the item view schema to enhance the presentation of the items. At 1014, the explorer items are presented to the user according to the shell and item views. The explorer decorative properties are presented at 1016. These properties can be a wide variety of display properties and include data queries or tasks associated with the explorer item.

E. Resource manager development

Resource managers can be created for a wide variety of item types. In one embodiment of the invention, the resource manager may be defined with little to no programming. By allowing resource managers to be created in a data-driven manner, ease of development is increased while providing a consistent look and feel across resource managers.

In some embodiments, the explorer allows restrictions on the types of items they can present (including item extensions and file extensions), or the explorer may choose to allow all types of items. The resource manager may also select to allow item types with specific extended groups of items. For example, the legal item resource manager may display all items that have "LegalItemExtension" attached. The explorer may choose to allow items of a certain type and any file extensions that map to that type. For example, a music item explorer may display all music file extensions, such as mp3 or wma. In addition, the explorer may select items that only allow a certain set of file extensions. If the resource manager is restricted to a certain set of types, other types of items cannot be stored or placed into the resource manager. The resource manager may redefine the type associations for the types they allow, and the resource manager may selectively choose not to allow revocation, or may choose not to allow addition of new commands. Furthermore the resource managers can decide whether they let the end user revoke the type federation in the resource manager.

In view of the above, those skilled in the art will appreciate that by providing data driven development techniques for creating a resource manager for use in an item type environment, the resource manager can be defined in a declarative manner and without the use of custom code.

FIG. 11 shows a method 1100 for presenting items according to an explorer display schema. At 1102, method 1100 selects a desired field entry. As described above, the required field entry may correspond to a declared property associated with the entry. For example, a "photo album" explorer may have required field entries that require inclusion of an entry containing picture data.

At 1104, an explorer display mode is defined. The display mode may include a shell view mode and an explorer decoration. The explorer decorations decorate the explorer as a whole and provide display elements such as unique colors and print elements. These explorer decorations are persistent across the views provided by the explorer. A wide variety of display attributes may be suitable for explorer decorations. For example, data queries or tasks/verbs associated with an explorer item are adapted for display with the explorer. The displayed task will be better coupled with an application capable of performing the task. The explorer view schema may include a shell view schema or a plurality of shell view schemas. The shell view schema can be configured to provide a shell view of a subset of explorer items.

At 1106, method 1100 accesses the data store to select a resource manager item. The resource manager entry is associated with the required field entry. Those skilled in the art will appreciate that the selection of such items in the database is well known in the art. Those skilled in the art will also appreciate that a developer may create a resource manager configured for such interaction. The present invention contemplates the development of a resource manager capable of accessing data stores.

At 1108, the explorer item is displayed according to the explorer display mode. The explorer display mode is as described above, and the display may also include interaction with a shell browser. For example, the housing may provide one or more housing views. In addition, the presentation of the explorer item may be enhanced with item decoration elements from the item decoration schema.

As will be appreciated by those skilled in the art, the explorer storage application may be viewed as an application and/or extension to a shell browser. The foregoing therefore applies to both statements of the invention. As an application, the explorer program may include a shell interaction module configured to interact with a shell browser. This interaction enables the program to communicate information with the shell and enables the software to work together to present the items. The shell interaction module may facilitate access to the data store and may provide display attributes. Such interactions between applications and shells are well known in the art.

F. Presentation of related items

The invention may also display the relevant items in the data store to the user. As described above, items in a data store can include items having one or more declared properties. Items may have declared relationships that set forth other items in the data store that share relationships. For example, an item containing an email address may declare a relationship with an item containing other contact information for the owner of the email address. The shell may utilize this declared relationship to present other contact information upon request by the user. The shell may also determine relationships by considering the declared properties of the items. For example, if a group of documents share a common attribute, they are related; if the common value is stored as part of an extension, an item with the extension "LegalItemExtension" is relevant. Such relationships may be determined by data queries as are well known in the art.

FIG. 12 illustrates a method 1200 for presenting related items in accordance with the present invention. At 1202, method 1200 accesses a data store and, at 1204, determines relationships between items in the data store. As described above, this determination utilizes declared properties included in the item. The determination may be in response to a user input. For example, an item having a set of declared item characteristics may be displayed to a user. The item characteristics and relationship information may be displayed with the item. The user may select one of the features and enter a request to view other items sharing the feature of the item. At 1206, method 1200 presents the related items to the user. Such presentation may include any display mode as is well known in the art.

Alternative embodiments and implementations of the present invention will become apparent to those skilled in the art from a review of this specification, including the drawings. Accordingly, the scope of the invention is defined by the appended claims rather than the foregoing description.

Claims (12)

1. A computer system for presenting related items in a universal data store to a user, the system comprising: a universal data store comprising a plurality of items stored according to a universal data schema, wherein an item is a unit of stored information that is an object having a set of attributes and relationship information corresponding to at least a portion of the plurality of items, wherein the attributes are a value or a set of names of values of a given type of the item, and the relationship information enables a relationship to be determined between two or more of the plurality of items; and a shell for presenting the plurality of items to a user, wherein the shell is configured to present a selected item to the user and is further configured to utilize the relationship information to present one or more items in the data store that are related to the selected item.

2. The computer system of claim 1, wherein the relationship information corresponding to one or more of the plurality of items comprises a set of item characteristics.

3. The computer system of claim 2, wherein the shell is configured to submit one or more of the set of item features to a user.

4. The computer system of claim 2, wherein the shell is configured to accept a user input representing a selection to view one or more items in the data store having one of the item features.

5. The computer system of claim 2, wherein the shell is configured to submit one or more items in a data store that share one of the item features.

6. The computer system of claim 1, wherein the shell is configured to submit at least a portion of the relationship information.

7. The computer system of claim 1, wherein the shell is configured to accept a user input indicating a selection to view an item in the data store that is related to the selected item.

8. The computer system of claim 7, wherein the relationship information corresponding to the selected item includes a set of item characteristics associated with the selected item, and wherein the user input represents a selection to view one or more items in the data store that share one of the set of item characteristics with the selected item.

9. A computer-implemented method for presenting relevant items in a universal data store to a user, the method comprising: accessing data in said universal data store, wherein said universal data store stores a plurality of items according to a universal data schema, wherein said items are units of stored information, which are objects having a set of attributes and relationship information that allows relationships between said plurality of items to be determined, said attributes being a value of a given type of said item or a name of a set of values; determining a relationship between the selected item and one or more items in the data store containing the relationship information using the relationship information; and displaying the selected item and one or more related items to a user.

10. The method of claim 9, wherein the display of the selected item and one or more related items includes displaying at least a portion of the relationship information to a user.

11. The method of claim 9, further comprising receiving a user input indicating a selection to view one or more items in the data store related to the selected item.

12. The method of claim 11, wherein the display of the selected item and one or more related items is responsive to the input.