WO2007059284A1

WO2007059284A1 - Method and apparatus to support context based search of stored data

Info

Publication number: WO2007059284A1
Application number: PCT/US2006/044507
Authority: WO
Inventors: Mahesh Kallahalla; Lawrence Brakmo
Original assignee: Ntt Docomo, Inc.
Priority date: 2005-11-15
Filing date: 2006-11-15
Publication date: 2007-05-24

Abstract

A method and apparatus is disclosed herein for context-based searching of stored data. In one embodiment, the method comprises receiving a query for one or more data objects, the query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects; and performing a search, in response to the query, based on the one or more keywords specifying the contextual information regarding one or more data operations performed previously on the one or more data objects.

Description

METHOD AND APPARATUS TO SUPPORT CONTEXT BASED SEARCH

OF STORED DATA

PRIORITY

[0001] The present patent application claims priority to and incorporates by reference the corresponding provisional patent application serial no. 60/737,158, titled, "Method and Apparatus to Support Context Based Search of Stored Data," filed on November 15, 2005.

FIELD OF THE INVENTION

[0002] The present invention relates to the field of data searching; more particularly, the present invention relates to content based searching of stored data.

BACKGROUND OF THE INVENTION

[0003] Mobile phones are evolving to become much more than just communication devices. These terminals, which are initially used solely for communication (voice calls and then messaging and email), are quickly taking on the functionality of other devices commonly carried by people such as information managers, music players, video players, mapping devices, cameras, and gaming consoles. The market for such integrated devices is driven both by the users' desire to carry only one mobile device and wireless service providers' desire to provide new services, beyond plain email. Such modern phones are currently called "smart phones", and are already in the market from most of the major phone manufacturers, and the trend is only expected to accelerate.

[0004] Technological and usage trends indicate that the amount of data that cell phones handle is increasing dramatically. The ability to generate and consume rich multi-media on cell phones is fueled by many technological innovations that can manipulate such data; these include multi-mega pixel cameras, the ability to generate and view full motion video, the high data rate available to cell phones, and multi-gigabyte storage devices available at small form factors. From a usage perspective, there is a convergence of devices, which indicates that the cell phone will be the terminal to access various kinds of media (e.g., photos, music, and movies). These trends indicate that the amount of data generated and consumed by such mobile terminal users is going to increase dramatically. [0005] However, current interfaces to access data on these devices, and other computing device for that matter, are very primitive. A widely used mechanism to locate and name data on most computer systems, including mobile devices, is by browsing through a hierarchical name-space - a hierarchy based on folders and files.

[0006] Figure 7(a) is an illustration of a hierarchical namespace. Alternate mechanisms include querying for data based on parts of the data (such as in databases), and content-based searches using queries on indexes generated from data objects.

[0007] Figure 7(b) is an illustration of a mechanism for storing a data object by decomposing it into multiple attribute-value pairs and storing each pair as a row in the corresponding attribute table. AU these mechanisms have limitations in that none of the mechanism is both efficient for the system and intuitive for users. The directory names in a hierarchical naming system can be viewed as attributes assigned to a file belonging in the folder. However, the hierarchical naming scheme has two main problems: a) it imposes an inflexible binding of the attributes to the files - a file cannot easily have different set of attributes, and b) it also imposes a strict ordering on the attributes that need to be followed to locate or name a file. These inflexibilities prevent such naming schemes from being intuitive for users, hi contrast, databases divide data objects into constituent pieces, and support the ability to query objects based on the components. However, databases are typically heavyweight systems and are inefficient in terms of resource usage.

SUMMARY QF THE INVENTION

[0008] A method and apparatus is disclosed herein for context-based searching of stored data. In one embodiment, the method comprises receiving a query for one or more data objects, the query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects; and performing a search, in response to the query, based on the one or more keywords specifying the contextual information regarding one or more data operations performed previously on the one or more data objects.

BRIEF DESCRIPTION QF THE DRAWINGS

[0009] The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

Figure 1 is a flow diagram of one embodiment of a context-aware searching process.

Figure 2 is a block diagram of a context-aware search and retrieval mechanism.

Figure 3 illustrates one embodiment the structure of a data object.

Figures 4A and 4B illustrate buffers used for storing information obtained from sensors.

Figure 5 is a more detailed flow diagram of one embodiment of a context- aware searching process.

Figure 6 is a block diagram of one embodiment of a computer system.

Figures 7A and 7B illustrate a typical hierarchical name-space and a representation of records in a database, respectively.

DETAILED DESCRIPTION QF THE PRESENT INVENTION

[0010] A method and apparatus for searching data using contextual information is disclosed. In general, it may be difficult for users to either describe the contents of a data object they are looking at, or describe it in a form that is conducive to efficient automated processing. However, it is common for people to relate operations they perform on data objects to other activities they were performing around the same time. Embodiments of the present invention allow users to use this more natural querying method to access data. [0011] A method and apparatus for creating, associating, and managing rich attributes with stored data is also disclosed. In one embodiment, typed and variable sized attributes are stored and associated flexibly with data. These data attributes a retrieved using a variety of interfaces (including, but not limited to, a file-system interface, a database interface, and an object based interface). The actual definition and values of the attributes may be flexible; thus, the system can handle attributes that are based on content of the data itself, as well as attributes that are derived from the environment in which operations were performed on the data objects. [0012] In one embodiment, data is efficiently located or searched by referring to a subset of attributes. In one embodiment, the queries are posed by specifying approximate values or ranges of values for the attributes. In another embodiment, the queries are posed by specifying conditions of the environment that existed when operations were performed on the data. In yet another embodiment, the queries are posed by specifying other events that occurred around the time that (or location where) the object was last operated on. The actual language for specifying the query is flexible.

[0013] In one embodiment, sensors track events and associate these events with data operations. Data objects are located by using references to events. In one embodiment, multiple sensors provide information about events. [0014] Mechanisms are described below for storing and retrieving data on computer systems, including file and data base systems. Also described below are interfaces to name and locate data objects in a computer system. [0015] In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.

[0016] Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [0017] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. [0018] The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

[0019] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

[0020] A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.

Overview

[0021] hi one embodiment, users are able to perform context based searches to locate data objects, hi one embodiment, contextual information is information about the context in which data objects were created, accessed, modified, or deleted, hi one embodiment, this includes information about actions the user or the device performed, the state of the environment in which those actions are performed, and any user specified tags that describe the context. For purposes herein, each instance of contextual information is referred to as an event. Also for purposes herein, the term "data operation" is used to refer to any operation on the data object, including, but not limited to, data creation, read, write, truncation, or deletion. [0022] hi one embodiment, users locate data objects by relating different actions they performed on the data objects to other actions they performed on the mobile device, and/or the environment in which those actions were performed. Mobile devices, such as cell phones, are becoming the center of many actions that the user performs and are practically always with the user. As a result, the user can intuitively remember data objects much better by linking their use (or creation) of the data object with the time and location of other actions they performed and the state of the environment at that time; examples of such linkages include "Song I heard after calling my friend Bob", "Report I read in San Francisco last week", and "Email I sent after buying tea at Tea Store last month". [0023] Though applicable to use in mobile device, the techniques described herein are applicable to any computing devices. Users of other computation devices, including personal computers (PCs) and workstations, face the same data location and management problem having accumulated large amounts of data. In one embodiment, the user of multiple computational devices can gather the contextual information from all the devices and aggregate the information for subsequent search and retrieval.

[0024] hi order to support such a data naming and location mechanism, we also present a mechanism to store and associate rich attributes with data objects. The mechanism includes a method for storing and associating typed and variable sized attributes flexibly to data and methods to retrieve such data-attributes objects using a variety of interfaces (including file-system, database, and object based). The actual definition of the attributes is flexible and can be based both on the system context when the data object was operated on, and on the content of the data itself.

[0025] Techniques for collecting contextual information and associating them with stored objects are described below. Using this stored information, a user can locate data objects by using references to other actions the user performed and the environment in which the actions were performed. A variety of "sensors" may be added to provide contextual information. In addition to the attributes that can be gathered from the system environment, embodiments of the present invention also allow applications to provide additional information that can be used to tag objects. In one embodiment, data can then be requested by referring to a subset of attributes. In one embodiment, the queries are posed by specifying approximate values or ranges of values for the attributes.

[0026] Figure 1 is a data flow diagram of one embodiment of a process for context based searching of stored data. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.

[0027] Referring to Figure 1, the process begins by processing logic receiving a query for one or more data objects, where the query has one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects (processing block 101). In one embodiment, the one or more data operations includes at least one selected from a group consisting of data object creation, data object reading, data object writing, data object truncation, and data object deletion. In one embodiment, the contextual information indicates at least one operation performed by a device or by an individual. In one embodiment, the contextual information includes environmental information characterizing an environmental in which the one or more data operations were performed. In one embodiment, the contextual information includes user specified tags that describe a context upon which the search is based. In one embodiment, the contextual information comprises one or more keywords describing at least one of the one or more data objects. [0028] In response to receiving the query, processing logic performs a search based on the one or more keywords specifying the contextual information regarding one or more data operations performed previously on the one or more data objects (processing block 102). In one embodiment, performing the search comprises searching based on one or more attributes of related events specified in the contextual information.

[0029] In one embodiment, the search mechanism also comprises a content attribute extractor to extract one or more attributes from the content. In one embodiment, the search mechanism also comprises one or more sensors to collect information corresponding to at least a portion of the events. In one embodiment, the search mechanism also includes an interface to enable an individual to specify attributes of the contextual information.

[0030] In one embodiment, the search mechanism comprises a query engine

(or processor), a data server and an attribute manager. The query engine performs a search for one or more data objects, in response to a query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects. The context information is described in terms of one or more attribute values associated with a related event. In one embodiment, the query engine evaluates the query by evaluating an intersection between which sets of contextual events satisfy the query and which data objects satisfy attribute values specified in the query. In one embodiment, the query engine uses timestamps for the contextual events and the data objects to determine the intersection.

[0031] The data server handles data objects and to pass attribute related operations to the query engine, while the attribute manager manages attributes extracted from content. In one embodiment, the attribute manager also manages contextual information gathered from sensors.

[0032] Figure 2 is a block diagram of a mechanism for performing context- aware search and retrieval. Each of the blocks may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.

[0033] Referring to Figure 2, a data server 201 handles input/output (I/O) operations on the opaque portions of stored data. In one embodiment, each data object has two portions: a) an opaque portion, which is stored as-is in the storage system, and b) a number of attributes (with associated values), which is stored in attribute manager 203. In one embodiment, the structure of the data object is as illustrated in Figure 3. In one embodiment, each object has an associated object identifier (OID), which is globally unique. As shown there are six values corresponding to six attributes. In other embodiments, the number of attribute values may be greater than 6 (e.g., 7, 8, 9, etc.) or less than six (e.g., 1, 2, 3, 4, 5). Optionally, the content of the opaque portions may be analyzed to extract keywords that describe the data object, which in turn are also managed by the attribute manager.

[0034] Data server 201 also passes requests related to data attribute and queries to the appropriate systems. An attribute manager 203 manages all the metadata (including attributes and their values) in the system. Attribute manager 203 also interacts with a number of sensors 206 to collect information about various events and logs them. A query processor (e.g., engine) 202 performs queries on the meta-data and responds with appropriate data object Ids and/or attributes and values.

One Embodiment of a Data Server [0035] In one embodiment, data server 201 interacts with applications, such as, for example, applications 220 and 221. If the operation issued by an application is an FO access to the opaque portion of the data object, data server 201 directly performs the operation and responds to the application. If the operation is related to the object's attributes, then data server 201 passes the operation to query processor 202. In one embodiment even when data server 201 directly performs the operation on the opaque portion of the data object, data server 201 issues a message to query processor 202 to note that the operation has been performed.

One Embodiment of an Attribute Manager

[0036] In one embodiment, attribute manager 203 is responsible for managing two types of information: 1) the attributes (and the associated values) of data objects, and 2) the contextual information that it gathers from sensors 206. The data stored by attribute manager 203 is used by query processor 202 to respond to queries. In one embodiment, attribute manager 203 extracts or causes the extraction of attributes from content or acquires them from sensors 206 and updates the attributes when requested to do so by query processor 202.

[0037] In one embodiment, the data gathered and reported by sensors 206 is stored in two ways: 1) the data from one of sensors 206 can be stored in its own table, including the time at which the sensor data was acquired, and 2) the data from one of sensors 206 can be integrated with the attributes stored for a data object and stored along with all the object related attributes. In one embodiment, the first type of data is about events that can occur at any time and whose values need to be noted independent of the occurrence of a data operation. Examples of this type of event include calls made on the phone and purchases made with the phone. The second type of data is about events whose values are important only in conjunction with a particular data operation. Examples of this type of event include a location at which a data object (e.g. photograph) was created and time at which a data object was last accessed.

[0038] In one embodiment, apart from sensors 206, attribute manager 203 stores content based attributes about data objects. These may be keywords describing the data object that are extracted from the opaque potion of the object. When a data object is created or modified, data server 201 sends a message to content attribute extractor 205, informing it about the data object. Content attribute extractor 205 then parses the data object, extracts appropriate keywords and stores them in attribute manager 203.

[0039] In one embodiment, attribute manger 203 stores arbitrary user assigned attributes to data objects. These can be tags that help the user retrieve the object later.

One Embodiment of a Query Processor

[0040] Query processor 202 updates the data stored in attribute manager 203 and performs queries on the data, when an application (e.g., application 220, application 221, etc.) issues a query to the system. In one embodiment, as part of performing a query, query processor 202 creates temporary structures to hold results while the application parses the results. The resources held by these temporary structures may be periodically reclaimed to prevent excessive resource usage. [0041] In one embodiment, the querying system supports multiple kinds of queries, including a) directly querying objects based on object attributes, or b) querying for objects by specifying the attributes of a related event. In one embodiment, directly querying objects based on object attributes allows for approximate queries where the attribute values are only approximately specified. For the first type of queries, when the query specifies values for object attributes, the query processor 202 finds all objects whose attribute values satisfy the query. In one embodiment, this query is sped up by maintaining indices of attribute values. The list of all such objects is stored and an identifier is returned to track the objects. In one embodiment, the list of objects is stored in a temporary table, and an * identifier corresponding to the table is returned. Any searching algorithm can be used to find the matching objects, including, but not limited to, using a linear search through all objects or using a pre-generated index on attribute values, using binary search on a balanced binary tree, or using a hash-based search mechanism. For the second type of queries, where attributes of related events are specified, the querying system uses time as the common thread linking the different events and data operations. In such a case, query processor 202 determines the set of events that match the description specified in the query, and using this set, query processor 202 then derives the set of time ranges in which data operations need to be searched. Based on these time ranges, and using the table that specifies the time at which data objects were operated on, query processor 202 determines the set of potential data objects and then further prunes this set using any object attributes that may be specified in the query. This sequence of operations is illustrated in Figure 5. [0042] The process in Figure 5 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. Referring to Figure 5, the process begins by processing logic receiving a query (processing block 501). In one embodiment, query 501 is received from an application (e.g., applications 220, 221) and is received by data server 201 via API 208. Next, processing logic determines matching events (processing block 502). In one embodiment, the processing logic in query processor 202 determines the events (504) that match the specified event attributes 503, which are stored and controlled by attribute manager 203.

[0043] After the events matching the specified event attributes (504) have been identified, processing logic derives the time ranges for the query (processing block 505). In one embodiment, processing logic in query processor 202 performs this operation and produces a list of event specified time ranges (506). Using the events matching the specified event attributes and the event specified time ranges, along with object attributes (508), processing logic determines the matching object(s) (processing block 507). In one embodiment, processing logic in query processor 202 identifies the matching object(s).

[0044] Thereafter, data objects matching the query are returned by query processor 202 to the requesting application, via data server 201.

An Example of a User Interface

[0045] The user interface (UI) for users to issue queries to the system is motivated by the underlying query processing strategy, hi the preferred embodiment, the user interface allows users to specify queries in two parts: a) the first part allows users to select attributes that they want to query on, and b) the second part allows the user to specify attributes of events and the relation between the events and the data object they are searching for. The user interface may display only those choices for attributes values that are appropriate, given other choices for attributes, to simplify the attribute value selection process.

[0046] As an illustrative example, consider the options such a user interface may provide to issue the query: "Song I last heard in San Francisco after calling mom". The user first selects "Music" for the "data type" attribute. This may then display attributes that are related to the "audio" data types, and attributes for all other kinds of events. Then the user may select "Last played at" attribute, and choose "San Francisco" for its value. Then the user may select "Around the time of" attribute, indicating intent to select the time the data object was accessed based on a related event. This could display a set of events types that the user could narrow the list down by. Finally, the user then may select "Call" as the type of event, and then choose "Mom" from contacts list for the value of the attribute "To" (which is an attribute of "Call").

[0047] While the user is choosing the options for attributes, values, and related events, in one embodiment, the interface displays a continually updated list of songs matching the currently chosen set of options. Thus, when the user chooses all the options, there is a small list of songs displayed, from which the user can pick the song for which the user was searching.

Sensors

[0048] hi one embodiment, contextual information includes information about actions the user or a device performed, the state of the environment in which those actions are performed, and any user specified tags that describe the context.

This information is collected may be collected a variety of ways dependent on the actual type of contextual information.

[0049] hi one embodiment, information about data operations is directly inferred from the messages passed from data server 201 when data operations occur.

Thus, data server 201 gathers this information and sends it to attribute manager 203.

This provides information on the time and nature of the data operation (such as, for example, object creation, deletion, modification, access, and size of data transferred, and offset).

[0050] In one embodiment, all other kind of contextual information is gathered by sensors 206. Thus, sensors 206 are responsible for gathering contextual information and relaying them to attribute manager 203. In one embodiment, sensors 206 assign a timestamp to every event they report to attribute manager 203. [0051] In one embodiment, there types of sensors are used. The first type of sensor records events at the time of a data operation. In one embodiment, the first type of sensors uses a structure capable of holding one data entry to share data with attribute manager 203. In this case, whenever there is a data operation, attribute manager 203 polls the data from the shared structure and records it. In one embodiment, attribute manager 203 polls the data from the shared structure and records it in the table corresponding to the sensor. In one embodiment, if the polled event has not changed from the last time the structure was polled, no data may be logged.

[0052] The second type of sensor always records events (such as, for example, calls, email send and receive). The second type of sensors generates events less frequently than the first type of sensors. In one embodiment, the second type of sensor uses a shared buffer in which they report data to attribute manager 203. In such a case, attribute manager 203 polls the shared structure for any data and logs them. In one embodiment, attribute manager 203 polls the shared structure for any data at a fixed frequency and logs them in a table corresponding to that sensor. A ring buffer (shared between the sensor and the event logger) is an example of such a shared buffer.

[0053] Figure 4A and 4B illustrate data transfer mechanism from one of sensors 206 to attribute manager 203. Referring to Figure 4A, a ring buffer 401 is shown with a continuous sensor 402 inserting data into ring buffer 401 (shown as an arrow 404). Attribute manager 203 is shown access data from ring buffer 401 (shown as arrow 403). Referring to Figure 4B, buffer 450 is shown receiving, for storage, data from event sensor 451. Attribute manager 203 is shown accessing buffer 450 (shown as arrow 460). [0054] In one embodiment, one of sensors 206 collects information that a user inputs. For example, one of sensors 206 may record a user's mood, which is input by the user periodically using a graphical user interface. In one embodiment, such a sensor(s) appends a timestamp to the user input and reports it to attribute manager 203.

[0055] When one of sensors 206 has an event to report, in one embodiment, such a sensor refers to other databases to get more information about the event. In one embodiment, a sensor periodically obtains the current location information using a GPS receiver and refers to an additional database to determine the current weather conditions at that location. After collecting information from related databases, the sensor report one event (or a series of events) to attribute manager 203.

An Example of a Sequence of Application Operations and Corresponding Internal Operations

[0056] In one embodiment, when the application wants to operate on a data object, the application first issues an open call to the system with a pointer to the data object being opened. In one embodiment, this pointer is a path to the object (in a directory hierarchy). In another embodiment, the pointer is an object identifier. In an alternative embodiment, the open call also includes other parameters that specify constraints on the object access, such as, for example, whether the object is to be opened read-only or read- write, and whether the object is to be created if one does not exist. The open call returns an identifier that is to be used in future accesses to that object.

[0057] When the open call is received by data server 201 , via API 208, data server 201 first locates the data object on the storage media/system 204, and then initializes internal (in memory) data structures that help keep track of accesses to the object. If the pointer to the object is an object identifier, then data server 201 looks up the object identifier in the system's naming database to determine the location of the data object. If the pointer is a path, then data server 201 traverses the path as in a regular file system to locate the data object. [0058] The open call also triggers an event to be generated. This event is reported to the attribute manager 203, which records that the file was opened at that particular time.

[0059] When the application has no more accesses to the object, it issues a close call, which declares that the application does not plan to issue any more accesses to the object. This causes data server 201 to purge the internal data- structures and pass a message to attribute manager 203 to update information related to attributes of the data object. This information may include statistics of attributes of the data object or other information such as, for example, but not limited to, the time of the last access of the data object's attributes.

[0060] In one embodiment, applications 220 and 221 can also request a mapping of path names to objects identifiers and vice-versa. When data server 201 gets this operation, the data server queries the attribute manger for the relevant information, and passes result back to the application.

[0061] Read and write operations on the opaque portion of a data object proceed normally as they would in a regular file system. That is, the data passed by the application (e.g., application 220, 221) is read/written from/to the particular offset provided in the operation. In these situations, data server 221 also passes the information over to attribute manager 203 to update any statistics or information related to the object's attributes. In one embodiment, in the case of a write operation, data server 201 also notifies content attribute extractor 205 that the object's opaque data could have changed. In response thereto, content attribute extractor 205 updates any keywords related to the data object. [0062] In one embodiment, applications 220 and 221 use the writeattr and readattr calls to write and read, respectively, attributes associated with a data object. These calls take the identifier of the data object (either one returned by the open call, or its raw object identifier). These operations also specify the name of the attribute which needs to be accessed and an optional offset into the attribute's value. [0063] To find a list of data objects matching an application's query, the application first issues the query to data server 201, using API 208. Using this query, query processor 202 creates a temporary list of object identifiers. The application can then issue independent calls to either get one or a subset of entries from this list. In one embodiment, in order to limit the resources used by the temporary lists, lists are purged after a certain amount of time. In one embodiment, the time is a configurable parameter. In an alternative embodiment, query processor 202 assigns a fixed amount of buffer for temporary lists, possibly reclaiming buffer space from older lists to accommodate new lists. In one embodiment, if the application desires to retain the contents of the list, the application issues a call to make the temporary list permanent. In this case, the application needs to ensure that the list is deleted after it is done with it.

An Example of a Computer System

[0064] Figure 6 is a block diagram of an exemplary computer system that may perform one or more of the operations described herein. Referring to Figure 6, computer system 600 may comprise an exemplary client or server computer system. Computer system 600 comprises a communication mechanism or bus 611 for communicating information, and a processor 612 coupled with bus 611 for processing information. Processor 612 includes a microprocessor, but is not limited to a microprocessor, such as, for example, Pentium™, PowerPC™, Alpha™, etc. [0065] System 600 further comprises a random access memory (RAM), or other dynamic storage device 604 (referred to as main memory) coupled to bus 611 for storing information and instructions to be executed by processor 612. Main memory 604 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 612. [0066] Computer system 600 also comprises a read only memory (ROM) and/or other static storage device 606 coupled to bus 611 for storing static information and instructions for processor 612, and a data storage device 607, such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 607 is coupled to bus 611 for storing information and instructions. [0067] Computer system 600 may further be coupled to a display device

621, such as a cathode ray tube (CRT) or liquid crystal display (LCD), coupled to bus 611 for displaying information to a computer user. An alphanumeric input device 622, including alphanumeric and other keys, may also be coupled to bus 611 for communicating information and command selections to processor 612. An additional user input device is cursor control 623, such as a mouse, trackball, trackpad, stylus, or cursor direction keys, coupled to bus 611 for communicating direction information and command selections to processor 612, and for controlling cursor movement on display 621.

[0068] Another device that may be coupled to bus 611 is hard copy device

624, which may be used for marking information on a medium such as paper, film, or similar types of media. Another device that may be coupled to bus 611 is a wired/wireless communication capability 625 to communication to a phone or handheld palm device.

[0069] Note that any or all of the components of system 600 and associated hardware may be used in the present invention. However, it can be appreciated that other configurations of the computer system may include some or all of the devices. [0070] Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Claims

CLAIMSWe claim:

1. A method for context based searching of stored data, the method comprising: receiving a query for one or more data objects, the query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects; and performing a search, in response to the query, based on the one or more keywords specifying the contextual information regarding one or more data operations performed previously on the one or more data objects.

2. An article of manufacture having one or more computer readable media storing instructions thereon which, when executed by a system, cause the system to perform a method comprising: receiving a query for one or more data objects, the query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects; and performing a search, in response to the query, based on the one or more keywords specifying the contextual information regarding one or more data operations performed previously on the one or more data objects.

3. An apparatus comprising: a query engine to perform a search for one or more data objects, in response to a query having one or more keywords specifying contextual information regarding one or more data operations performed previously on the one or more data objects, wherein the context information is described in terms of one or more attribute values associated with a related event; a data server to handle data objects and to pass attribute related operations to the query engine; and an attribute manager to manage attributes extracted from content.