Patent Grant
9122748
The amount of content being created on the Internet is constantly increasing. Sources such as news articles, blog postings, Facebook postings, and Twitter postings contribute to the increasing amount of content. For example, Twitter alone currently produces more than 300 million pieces of content per day.
Sometimes, users want to be notified when a particular word or phrase is mentioned or discussed on the Internet. For example, a user may want to receive a notification when new content is generated that mentions a specific sports team that the user is following, or that mentions a specific company that the user is interested in (e.g., discusses a specific new product that the company is selling). Due to the huge amount of content that is being created on the Internet on a daily basis, it is a challenge to watch the content and perform such notifications.
Traditional search systems can provide for notifications when new content matches specific queries. For example, a traditional search system could index a day's worth of content (e.g., 300 million pieces of content) at the end of the day into a search engine. The traditional search system could then query the indexed content using users' queries to obtain matches. This solution using a traditional search system suffers from a number of limitations. For example, there may be a long lag time (e.g., a day) between creation of the content and when it is indexed and available for searching. In addition, maintaining an up-to-date index can be difficult due to the frequency of new content begin created (e.g., continuously indexing, re-indexing, or updating the index may not be practical). Furthermore, indexing a huge amount of content on a regular basis can be very time and computing resource intensive.
Because indexing documents can take a substantial amount of time (especially if the number of documents to index is large), it can be difficult to maintain an index that represents frequently changing activity. Furthermore, if an index is not maintained on a real-time (or near-real-time) basis, then results from the index will not reflect the current state of the content.
Furthermore, there are often many users, each of which may have a number of queries, and it may not be practical to check all the queries for all the users against an updated index of documents for new matches. For example, there could be thousands or millions (or more) queries, and to obtain up-to-date results, and each query would need to be sent to a search engine for processing each time the index is updated with new documents.
Therefore, there exists ample opportunity for improvement in technologies related to matching documents against queries.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Techniques and tools are described for matching documents against monitors. For example, an index of monitors can be generated and stored (e.g., the index representing query logic of the monitors). The index can be searched using documents as input (e.g., using the documents as the search queries). The searching can comprise matching documents against monitors stored in the index using the query logic associated with the monitors.
As another example, a method is provided for matching documents against monitors. The method comprises receiving a plurality of monitors, generating an index from the plurality of monitors (the index representing full query logic for the plurality of monitors), and storing the index for the plurality of monitors. The index is searchable using documents as queries (as search queries or search strings) to perform matching against the monitors stored in the index.
The method can further comprise receiving a plurality of documents, searching the index using the plurality of documents to determine matches between the plurality of documents and the plurality of monitors using the full query logic represented by the index, and outputting results of the searching. For example, results can comprise indications of which monitors matched which documents. Additional operations can be performed based on the results. For example, counts of matches can be saved (e.g., a count of matching documents for each monitor), and notifications of matches can be sent (e.g., sent to users associated with the monitors).
As another example, a search system is provided for matching documents against monitors. The search system comprises a processing unit, memory, and one or more computer-readable storage media storing computer-executable instructions for causing the search system to perform operations. The operations comprise receiving a plurality of monitors, generating an index from the plurality of monitors, the index representing full query logic for the plurality of monitors, and storing the index for the plurality of monitors, where the index is searchable using documents as queries to perform matching against the plurality of monitors.
As another example, a method is provided for matching documents against monitors (e.g., in a distributed environment). The method comprises storing an index at each of a plurality of computing devices, where the index is generated from a plurality of monitors, and where the index represents full query logic for the plurality of monitors. The method also comprises obtaining a set of documents, dividing the set of documents into a plurality of groups of documents corresponding to the plurality of computing devices, and sending each group of documents to its respective computing device for searching the index using the groups of documents as queries to perform matching against the plurality of monitors.
As another example, a method is provided for matching documents against monitors (e.g., in a distributed environment). The method comprises providing an index for storage at each of a plurality of computing devices, where the index is generated from a plurality of monitors, and where the index represents full query logic for the plurality of monitors, and receiving results of searching the index from each of the plurality of computing devices, where each computing device of the plurality of computing devices searches the index using a subset of a plurality of documents, and where each computing device of the plurality of computing devices searches a different subset of the plurality of documents.
The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.
The following description is directed to techniques and solutions for matching documents against monitors. For example, an index can be generated, where the index represents query logic (e.g., full query logic) for a set of monitors. The index can be searched using documents as input (using the documents as the search queries or search strings). The result of the search can comprise an indication of which monitors match which documents.
The traditional search engine approach is to create an index of all the documents (e.g., web pages, blog postings, instant messages, etc.) at a specific time (e.g., at the end of the day). Once the index is created, the index can be searched using the monitors as queries against the index. While the traditional approach may be feasible with a smaller amount of content (e.g., a smaller number of documents), the traditional approach suffers from a number of limitations, particularly as the amount of content (e.g., the number and/or size of the documents) increases. For example, the traditional approach can require substantial time and computing resources to index a huge number of documents on a periodic basis (e.g., on a daily basis). In addition, the traditional approach can suffer from significant lag time between the time the content is created and the time the content is indexed and searched. Furthermore, due to the size of the index of documents, searching the index can be inefficient.
Instead of indexing the documents and searching the index using monitors as queries, an approach can be used in which monitors are indexed and the index is searched using documents as input (using the documents as the search queries). This approach can provide a number of benefits. For example, because monitors typically change infrequently, the index can be updated infrequently while still maintaining the current state of the monitors. Furthermore, an index of monitors is typically much smaller than an index of documents, and thus requires less storage. In some implementations, the index of monitors is maintained in RAM (or other cache facility) for quick and efficient access and processing. In addition, an index of monitors, due to its smaller size, can be more easily replicated between different machines (e.g., distributed to multiple servers). Such replication can allow for the index to be searched in parallel (e.g., by searching the full index at each machine, where each machine searches the full index using a subset of a set of documents).
The monitor engine 220 can be a custom developed application or a modified search engine. For example, a custom developed application can be programed to search an index of monitors, taking into account full query logic of the monitors when performing the search. Furthermore, a custom developed application can be programed to receive documents as input and use the documents as the search queries (e.g., after processing the documents to put them into a query format). A modified search engine can also perform these operations. For example, a search engine can be modified to take into account full query logic when searching the index. The search engine can also be modified to receive documents as input and use the documents as the search queries (e.g., after processing the documents to put them into a query format).
By generating an index of monitors with full query logic and searching the index using documents as queries, a large volume of documents can be processed efficiently. For example, an experimental distributed/parallel architecture of six servers processed 60,000 incoming documents per second using a monitor index of 5,000 monitors with full query logic of the monitors represented in the index.
In the techniques and solutions described herein, a monitor refers to one or more terms in the format of a query. Content that satisfies the monitor (satisfies the query associated with the monitor) matches the monitor. Some examples of monitors are: “brown AND fox,” “yellow AND cow,” “brown AND fox AND NOT red,” and “fox AND (brown OR white).”
A monitor can be used to search for content (e.g., documents) that match the monitor. For example, a user may want to watch for (e.g., be notified of) specific content on the Internet (e.g., new or modified web pages, news articles, blog postings, Twitter postings, Facebook posts, etc.). The user may want to watch (or monitor) specific content for a variety of reasons. For example, the user may be interested in the specific content (e.g., interested in new video game releases), or the user may want to monitor a specific company, brand, or product (e.g., track sentiment or opinion regarding a specific company, brand, and/or product).
Monitors can be associated with users or other types of entities (e.g., a business or organization). A user (or other type of entity) can create a number of different monitors, and the user can edit, change, and delete monitors. In some implementations, a monitor is an instance of a query search string associated with a specific entity.
Monitors can be indexed. For example, index information can be generated for a monitor. The index information can indicate terms (e.g., text or non-text terms) that are present in the monitor, and can further indicate operators (e.g., Boolean operators such as AND, OR, and NOT) that are present in the monitor as well as other query information (e.g., nesting, phrases, proximity (e.g., same sentence or paragraph, within a specific number of words), etc.). Monitor index information can be stored using, at least in part, an inverted index.
In the techniques and solutions described herein, documents refer to electronic information or content (e.g., available on the Internet). For example, documents can include word processing files, text files, blog posts, web pages, news articles, Twitter posts, Facebook posts, instant messages, or any other type of electronic information. Documents can be received. For example, new content from popular Internet sites or services can be received on a real-time, near real-time, and/or periodic basis (e.g., Twitter posts, blog posts, etc. can be received when, or soon after, they are created).
Documents can be provided as input (as queries) to a search engine (e.g., a monitor engine). For example, the individual terms (e.g., words and/or other text or non-text terms) of a set of documents can be provided as input to a search engine to match against monitors in an index.
Documents can be processed into a format suitable for use as a query. For example, common terms (e.g., “a,” “and,” and “the”) can be removed, and the remaining terms (e.g., words) of a document can be formatted by placing “OR” operators between the terms. For example, the following document content:
A quick brown fox jumped over the fence. can be transformed into the following query format:
quick OR brown OR fox OR jumped OR over OR fence
Documents can be stored at a single location (e.g., a single database) or they can be distributed and stored at different locations (e.g., as distributed blocks of content). For example, a set of documents can be segmented and each subset of documents can be stored (and processed) by a different server.
In the techniques and solutions described herein, monitors can be indexed. Indexing a monitor can comprise creating index information for the monitor (e.g., in the format of an inverted index or posting list). An index generated from a monitor also represents query logic for the monitor.
In some implementations, the full query logic of a monitor is represented by the index. For example, the index can store the full query logic for each monitor or the index can comprise a pointer to the full query logic for each monitor.
Consider the following example of two monitors:
Monitor 1: quick AND brown
Monitor 2: quick AND yellow
When these two monitors are indexed, the index can comprise an inverted index storing the monitors and query logic in the following format:
<word>: (list <monitor identifier: full query, . . . >)
Using the above example monitors (Monitor 1 and Monitor 2), the following inverted index would be generated using this inverted index format:
quick: (1: quick AND brown, 2: quick AND yellow)
brown: (1: quick AND brown)
yellow: (2: quick AND yellow)
As illustrated in the above example index, each word is listed along with its monitor identifier (e.g., a unique identifier for the monitor) and the full query logic associated with the monitor. Specifically, as shown in the above example index, the word “quick” is present in monitor identifier “1” and is associated with the full query logic “quick AND brown” (the full query of Monitor 1). In addition, the word “quick” is also present in monitor identifier “2” and is associated with the full query logic “quick AND yellow” (the full query of Monitor 2).
As another example, consider the same example of two monitors:
Monitor 1: quick AND brown
Monitor 2: quick AND yellow
When these two monitors are indexed, the index can comprise an inverted index storing the monitors and references (e.g., pointers) to the query logic in the following format:
<word>: (list <monitor identifier: reference to query, . . . >)
Using the above example monitors (Monitor 1 and Monitor 2), the following inverted index would be generated using this inverted index format:
quick: (1: ref1, 2: ref2)
brown: (1: ref1)
yellow: (2: ref2)
In addition, the following list of query logic would be stored (e.g., in a separate database or other type of data store):
ref1->quick AND brown
ref2->quick AND yellow
As illustrated in the above example index, each word is listed along with its monitor identifier (e.g., a unique identifier for the monitor) and a reference (e.g., pointer) to the full query logic associated with the monitor (e.g., using unique reference identifiers). For example, the full query logic could be stored in a separate database, file, or other type of data store. Storing the full query logic separately can reduce the total amount of storage required for the index (e.g., by only storing one copy of the full query logic for each monitor instead of storing the full query logic for each entry of the monitor in the index) and can increase lookup efficiency (e.g., by maintaining a cache of the full query logic), in certain processing scenarios.
As shown in the above example index, the word “quick” is present in monitor identifier “1” and is associated with the reference “ref1” to the full query logic associated with the monitor (ref1 is a reference or pointer to the full query logic “quick AND brown”). In addition, the word “quick” is also present in monitor identifier “2” and is associated with the reference “ref2” to the full query logic associated with the monitor (ref2 is a reference or pointer to the full query logic “quick AND yellow”).
In a specific implementation, the index is stored in a payload area in the inverted index. The payload area provides unstructured data storage in the inverted index that can be used to store custom information in a search index. Depending on the implementation details, the payload area can store the full query logic or a reference (e.g., pointer) to the full query logic.
Monitors can have a complex query structure. For example, monitors can use query operators including: phrases, AND, OR, NOT, nested structures, proximity information, etc. Regardless of the complexity of the query structure for a specific monitor, the fully query logic can be stored in the index (e.g., stored directly or referenced).
In the techniques and solutions described herein, an index of monitors can be searched using documents as input (e.g., using documents as the search query). In general, searching the index of monitors comprises processing each document to determine which monitors are satisfied by the document using the query logic associated with each monitor.
Consider the following example document:
A quick brown fox jumped over the fence.
Also consider the following two example monitors:
Monitor 1: quick AND brown
Monitor 2: quick AND yellow
that generate the following inverted index:
quick: (1: quick AND brown, 2: quick AND yellow)
brown: (1: quick AND brown)
yellow: (2: quick AND yellow).
An example of searching the above example index using the above example document as the query can proceed as follows. First, the example document can be processed to remove common words, such as “a” and “the.” Second, the result can be processed to create the query, “quick OR brown OR fox OR jumped OR over OR fence.” Third, the document (in the query format) can be used to search the index. The first term of the document query, “quick,” has a match in the index. Specifically, “quick” is found in Monitor 1 and Monitor 2 (the first entry in the inverted index above). An indication that “quick” has been found can be saved (e.g., in a cache or other data storage). Because the full query logic is accessible (either directly or via a reference or pointer) from the index, a determination can also be made of whether the full query logic for the monitor has been satisfied. In this example, because only the term “quick” has been found so far, the full query logic has not been satisfied for either Monitor 1 or Monitor 2. Next the second term of the document query, “brown,” is searched and a match is found in the index (the second entry in the inverted index above). Specifically, “brown” is found in Monitor 1. From the full query logic for Monitor 1 (“quick AND brown”), and from the saved indication that “quick” has been previously found for Monitor 1, a determination can be made that the full query logic for Monitor 1 has now been satisfied (e.g., the result that Monitor 1 has been satisfied can be saved, e.g., in the cache). Next, the remaining terms of the document query (fox, jumped, over, and fence) are checked, and are not found in the index.
As a next step, the saved indications can be examined to determine which Monitors have been satisfied. In this example, Monitor 1 has been satisfied and Monitor 2 has not been satisfied. Results of the searching can be saved (e.g., an indication of which monitors matched which documents, or a count of the number of documents that matched each monitor) and other processing can be performed. For example, notifications can be made based on the results (e.g., a user associated with Monitor 1 can be notified that a document has been found that matches the monitor).
When searching an index of monitors, various techniques can be used to determine which monitors have been satisfied by an input document. For example, a list of monitors can be maintained, along with a list of found terms for each monitor and an indication of whether each monitor has been satisfied by the input document. In a first example implementation, a cache list is maintained with the following format:
Monitor ID: {list of found terms}, {Boolean—monitor query satisfied?}, {Boolean—monitor has NOT term(s)}
The first example implementation is a simplified example in which the monitors do not have any NOT terms.
The following procedure can be used to process documents using the cache list of the first example implementation:
Consider the following example document:
A quick brown fox jumped over the fence.
Also consider the following three example monitors:
Monitor 1: quick AND brown
Monitor 2: quick AND yellow
that generate the following inverted index:
quick: (1: quick AND brown, 2: quick AND yellow)
brown: (1: quick AND brown)
yellow: (2: quick AND yellow)
Using the above example document, monitors, and index, the following cache list can be generated using the cache list of the first example implementation. Upon processing the first input term “quick”, two cache list entries are created:
Monitor ID 1: {quick}, {false}, {false}
Monitor ID 2: {quick}, {false}, {false}
Upon processing the second input term “brown,” the cache list entry for Monitor 1 is updated (Monitor 1 is satisfied because the full query has been satisfied and there are no NOT terms), as follows:
Monitor ID 1: {quick, brown}, {true}, {false}
Monitor ID 2: {quick}, {false}, {false}
Processing the remaining terms from the input document do not have any effect on the cache list, as the remaining terms are not present in the index. The result of searching the index using the document as input (as the query), is that Monitor 1 has been satisfied (the full query logic of Monitor 1 has been matched by the input document) and Monitor 2 has not been satisfied. Therefore, Monitor 1 is a match for the input document, while Monitor 2 is not a match. Searching can be performed for one or more additional input documents in a similar manner.
In a second example implementation, a cache list is maintained with the following format:
The following procedure can be used to process documents using the cache list of the second example implementation:
Consider the following example document:
A quick brown fox jumped over the fence.
Also consider the following three example monitors:
Monitor 1: quick AND brown
Monitor 2: quick AND yellow
Monitor 3: brown AND fox AND NOT green
that generate the following inverted index:
quick: (1: quick AND brown, 2: quick AND yellow)
brown: (1: quick AND brown, 3: brown AND fox AND NOT green)
yellow: (2: quick AND yellow)
fox: (3: brown AND fox AND NOT green)
green: (3: brown AND fox AND NOT green)
Using the above example document, monitors, and index, the following cache list can be generated using the cache list of the first example implementation. Upon processing the first input term “quick”, two cache list entries are created:
Monitor ID 1: {quick}, {false}, {false}, {false}
Monitor ID 2: {quick}, {false}, {false}, {false}
Upon processing the second input term “brown,” the cache list entry for Monitor 1 is updated (Monitor 1 is satisfied because the full query has been satisfied and there are no NOT terms), and a cache list entry for Monitor 3 is created, as follows:
Monitor ID 1: {quick, brown}, {true}, {false}, {false}
Monitor ID 2: {quick}, {false}, {false}, {false}
Monitor ID 3: {brown}, {false}, {true}, {false}
Upon processing the third input term “fox,” the cache list entry for Monitor 3 is updated as follows:
Monitor ID 1: {quick, brown}, {true}, {false}, {false}
Monitor ID 2: {quick}, {false}, {false}, {false}
Monitor ID 3: {brown, fox}, {false}, {true}, {false}
Processing the remaining terms from the input document do not have any effect on the cache list, as the remaining terms are not present in the index. The result of searching the index using the document as input (as the query), is that Monitor 1 has been satisfied (the full query logic of Monitor 1 has been matched by the input document), Monitor 2 has not been satisfied, and Monitor 3 has not been satisfied. A remaining step (e.g., a post-processing step) is to check for NOT terms for those monitors that have a NOT term in their query. In this example, Monitor 3 has a NOT term, which was not present in the input document (the “found NOT terms therefore exclude” Boolean for Monitor 3 is false), and thus Monitor 3 is satisfied. Therefore, Monitors 1 and 3 are matches for the input document, while Monitor 2 is not a match. Searching can be performed for one or more additional input documents in a similar manner.
The cache lists in the above first and second example implementations can be examples of a lazy loaded fast checking data structure.
Optimizations can be made to the above processing procedures to increase performance. For example, for a given input document, the number of required terms (any term that is an AND) can be counted. If the input document does not have enough terms matching, then it can be skipped. In addition, upon finding that a “NOT” term has been identified for a monitor (e.g., “Boolean—found NOT therefore exclude” in the cache list example above), subsequent processing of the current document can skip that monitor as it has been excluded.
In addition to determining which monitors match which documents, scoring can be performed. For example, standard search engine scoring techniques can be applied to indicate how closely a monitor matches a document. In a specific implementation, scores are calculated when a match is found between a monitor and a document.
In the techniques and solutions described herein, an index of monitors can be searched using documents as input (using the documents as the search queries). The index of monitors is searched by matching terms in the input documents against the monitors using the query logic of the monitors.
At 320, an index is generated from the received plurality of monitors 310. The index of the monitors represents the full query logic of the monitors. For example, if the monitor is “brown AND fox,” then the index represents the full query logic (i.e., the terms “brown” and “fox” as well as the operator “AND”). The full query logic can be stored in the index. For example, an index entry for a monitor term can also store the full query logic for the monitor (e.g., as additional or meta data). The full query logic can be associated with the index. For example, an index entry for a monitor term can comprise a reference or pointer to the full query logic (e.g., the full query logic can be stored in another location from the index, such as a separate database).
At 330, the index for the plurality of monitors is stored. The stored index can be searched (e.g., searched using a monitor search engine). For example, the index can be searched using documents as queries to perform matching against the plurality of monitors stored in the index. The matching can utilize the full query logic of the monitors.
In some implementations, the index is stored locally (e.g., on the same computing device that generated the index). In some implementations, the index is stored (or sent) to one or more other computing devices (e.g., to a number of other computer servers for use in a distributed and/or parallel processing architecture).
At 420, an index of monitors is searched using the plurality of documents 410 as input (as the search queries). The index is searched to determine matches between the plurality of documents 410 and the monitors. The searching uses the full query logic of the monitors as represented in the index (e.g., where the full query logic of the monitors is stored directly in the index or referenced in the index). The searching can be performed by maintaining a cache list of monitors. For example, the cache list can comprise a unique identifier of the monitor, a list of found terms for that monitor, and an indication of whether the full query logic for the monitor has been satisfied. The cache list can also comprise other, or different, information, such as indications of whether NOT terms are present or have been found, scoring information, etc.
At 430, results of the searching are returned. For example, the results can comprise indications of which monitors were matched by which documents, counts of matches, etc. The results can also comprise notifications to users associated with the matched monitors. For example, if a user is associated with a monitor, the user can receive a notification (e.g., email or other type of alert) with a list of documents (e.g., referenced via uniform resource locator (URL)) that match the notification.
In the techniques and solutions described herein, an index of monitors can be searched using documents as input using a distributed and/or parallel processing environment. For example, a set of documents can be segregated and stored at various locations (e.g., using a distributed file system). An index of monitors (e.g., a full index) can be searched at each of the various locations (e.g., searched in parallel). Results from the various locations can be combined (e.g., aggregated at a central location).
In a specific implementation, a MapReduce framework (e.g., using the Apache™ Hadoop™ implementation of the MapReduce framework) is used to process subsets of a full set of documents using a collection of computer servers, where each server processes its subset using a full monitor index. Results can then be combined at a central location.
At 520, results of searching the index are received from a plurality of computing devices. Each of the plurality of computing devices searches the index (e.g., the full index) using a subset of a plurality of documents, each computing device searches a different subset of the plurality of documents, and the searching can be performed in parallel. For example, a set of documents can be stored using a distributed file system such that each computing device accesses a different subset of the stored documents (e.g., different blocks of the set of stored documents).
At 530, results of the searching are output. For example, results such as indications of which monitors match which documents can be stored, or notifications can be sent based on the matches.
The techniques and solutions described herein can be performed by software and/or hardware of a computing environment, such as a computing device. For example, computing devices include server computers, desktop computers, laptop computers, notebook computers, netbooks, tablet devices, mobile devices, and other types of computing devices. The techniques and solutions described herein can be performed in a cloud computing environment (e.g., comprising virtual machines and underlying infrastructure resources).
With reference to
The storage 640 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other tangible storage medium which can be used to store information and which can be accessed within the computing environment 600. The storage 640 stores instructions for the software 680, which can implement technologies described herein.
The input device(s) 650 may be a touch input device, such as a keyboard, keypad, mouse, pen, or trackball, a voice input device, a scanning device, or another device, that provides input to the computing environment 600. For audio, the input device(s) 650 may be a sound card or similar device that accepts audio input in analog or digital form, or a CD-ROM reader that provides audio samples to the computing environment 600. The output device(s) 660 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 600.
The communication connection(s) 670 enable communication over a communication medium (e.g., a connecting network) to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed graphics information, or other data in a modulated data signal.
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.
Any of the disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media (e.g., non-transitory computer-readable media, such as one or more optical media discs such as DVD or CD, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as flash memory or hard drives)) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). By way of example and with reference to
Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable storage media (e.g., non-transitory computer-readable media). The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.
For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.
The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and non-obvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub-combinations with one another. The disclosed methods, devices, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved. In view of the many possible embodiments to which the principles of the disclosed invention may be applied, it should be recognized that the illustrated embodiments are only preferred examples of the invention and should not be taken as limiting the scope of the invention. Rather, the scope of the invention is defined by the following claims. I therefore claim as my invention all that comes within the scope of these claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5915249 | Spencer | Jun 1999 | A |
| 6411950 | Moricz et al. | Jun 2002 | B1 |
| 6799199 | Segal et al. | Sep 2004 | B1 |
| 20010049675 | Mandler et al. | Dec 2001 | A1 |
| 20090319508 | Yih et al. | Dec 2009 | A1 |
| 20100005108 | Fiebig et al. | Jan 2010 | A1 |
| 20110066620 | Redfern et al. | Mar 2011 | A1 |
| Entry |
|---|
| Wikipedia, “Google Alerts,” <en.wikipedia.org/wiki/Google—Alerts> 2 pages (accessed Mar. 10, 2012). |
| Wikipedia, MapReduce, <http://en.wikipedia.org/wiki/Mapreduce> 8 pages (accessed Mar. 10, 2012). |
| GigaAlert, “Frequently Asked Questions,” <http://www.gigaalert.com/faqs.php#often> 4 pages (accessed Mar. 10, 2012). |
| Apache, “Welcome to Apache™ Hadoop™ !,” <http://hadoop.apache.org/index.pdf> 4 pages (accessed Mar. 11, 2012). |
| Number | Date | Country | |
|---|---|---|---|
| 20130254211 A1 | Sep 2013 | US |
