Patent Application
20070078803
At least one embodiment of the present invention pertains to computer-implemented information search and sharing technology, and more particularly, to searchcasting, the integration of desktop search technology with enterprise or Web search technology.
With the development of computer technology, especially network technology, information search has become a hot area of scientific research as well as industrial competition. Today, Web search and enterprise search have become the most popular ways through which people find information.
For example, a Web search may be conducted through a Web based search engine or portal (i.e., google.com, msn.com, etc.). A Web based search server provides a search portal through which a user may submit his search request (query) from his computer via a network (i.e., LAN, WAN, the Internet, etc.). In most cases, a Web based search server maintains and periodically updates its index of all information published by all computers on the Internet so that when a search request is received, the result will be quickly available. Thus, much of the information published on the Internet is made searchable and accessible through these various search portals.
Information stored on a computer may be classified into three categories: published information (e.g., Web pages that are assessable by the public via the Internet), limited access information (e.g., information stored in an organization's database), and private information (e.g., email, personal data, confidential information, etc.). For a Web search, such as a Google Web search, only published information, however, is searchable and accessible. Limited access information and private information, however, can not be reached by such a Web search.
To access limited access information, such as information in a corporate database, a search server is usually configured in a way such that a user is authenticated before his search may be processed. Similar to a Web search, the search server provides a portal through which an authenticated user (e.g., authenticated by a login process) submits a search request from his computer. The search server then distributes the search request to a database server, so that limited access information may be pulled out from a database by a search engine. The search server may also distribute the search request to a plurality of database servers. In that case, a so called “federated search” is conducted. A “federated search” may be defined as simultaneous search and retrieval from different databases and electronic resources.
Microsoft, Yahoo, Google, and others have recently introduced “desktop search” software that can be downloaded by users on their personal computers (PCs) to allow them to index and rapidly locate information of any kind on their PCs. For example, a desktop search engine can index and search all categories of information, including published information, limited access information, and private information. Through the enormous popularity of desktop search technology, the entire base of information on PCs throughout the world is rapidly becoming indexed and separately searchable to the users of those PCs, but not to anyone else. The reason is obvious: users consider their PCs to be personal and are unwilling to simply allow access to their hard disks for searching by others.
In a business enterprise, this creates a significant missed opportunity. If the background indexing of user PCs could be harnessed for the purposes of the overall organization, for example, information technology (IT) managers would embrace and support desktop search technology, and the enterprise could benefit in the form of dramatically expanded sharing of information and better collaboration, because, for the first time, all content on any user's PC in the enterprise potentially would be available for sharing. Enterprises could also simplify their IT strategies and reduce expenses by eliminating many technologies and processes designed to “manage” content. In place of these strategies, content could simply be left where it is and accessed on user PCs.
Thus, a system is needed to accomplish the enterprise or Web integration of desktop search and to solve the privacy issues as well.
The present invention includes a method and processing system for searchcasting. The method comprises sending a user initiated query for information to a plurality of computers distributed on a network, receiving a first message in response to the query from at least one of the computers, and in response to the first message or messages, sending a second message to at least one of the computers to cause the computer to prompt a user of the computer to indicate permission or denial of permission to send a response to the query.
Another aspect of the present invention includes receiving, at a first computer, from a server, a user initiated query for information, which is also being received from the server by at least a second computer, and upon detecting a match of the query at the first computer, prompting a user of the computer to indicate permission or denial of permission to send a response to the query.
Other aspects of the invention will be apparent from the accompanying figures and from the detailed description which follows.
One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
A method, system and apparatus for searchcasting are described. References in this specification to “an embodiment”, “one embodiment”, or the like, mean that the particular feature, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment.
The technique introduced here integrates desktop search with enterprise or Web search by combining federated search with a privacy control mechanism. First, a user initiated query for information is distributed, from a server, to a plurality of target computers via a network. The query is then processed individually on each computer. At least one computer is chosen for matched information stored on it, i.e., the selection may be based on relevancy of the matched information, relationship between the querying user and the user who controls the matched information, the user's knowledge base with respect to the subject matter of the query, and/or other criteria. Each of the selected computer(s) then alerts the user of the match and prompts the user to indicate whether he is willing to respond to the query, i.e., authorize the release of the matched information to the querying user, contact the querying user for further communication with respect to the query, etc. Before the user chooses to respond to the query (i.e., authorizing the release of the matched information sought), all communications, if any, from the computer to the server are anonymous such that they cannot be used to identify the identity of the user. No private information leaves the computer until the user of that computer (i.e., the “owner” of that information) allows it. Thus, the privacy issue is also addressed in this searchcasting system. Note that the term “match” in this specification means either a process of measuring the correspondence between two things or a result that the degree of the correspondence between two things satisfies a condition. Which meaning of the term applies will be self evident within the particular context.
Note that the clients or target “computers” are described herein as being conventional PCs to facilitate description. However, they could instead be or include essentially any one or more other types of processing or communication devices. For example, one or more of the clients or target “computers” might be personal digital assistants (PDAs), mobile (e.g., cellular) telephones, two-way pagers, and other similar devices. Hence, the term “computer” is used broadly herein to mean any type of processing or communication device that can receive, transmit, store and process information and otherwise perform the processes described herein.
“Searchcasting” is a term used herein to describe the process by which users initiate federated search for “unpublished” information on multiple target computers via a network. The term “searchcasting” is used in this document without derogation of any trademark rights of Tacit Software, Inc. which may exist in this term. In an embodiment of the invention, searchcasting is implemented on an architecture such as illustrated in
Searchcasting with Client Side Step-down Auction
In an embodiment of the invention, the searchcasting process begins when a user 203 (hereinafter “the querying user”) of a client computer 202-I initiates a query to search for content, knowledge, relationships, answers or other information stored on other client computers 202 (hereinafter “target computers”) and controlled by users of those computers (hereinafter target users). The querying user can do this by using a traditional search input field on a corporate portal, Web page, or a desktop search bar. The querying user may then be asked to identify a target group he wants to search (e.g., the entire company, just the engineering department, all computers which subscribe to the searchcasting server 200, etc.), a deadline for an answer, and the types of content sought, etc. This query is then sent to the searchcasting server 200 from the querying user's computer 200-I via the network 11. In some embodiments of the invention, the querying user must be authenticated first by logging-in to the searchcasting system. The system, however, may allow anonymous users to conduct a search in limited ways. Such limitations will be addressed in the following discussion.
At block 803 of
Referring again to
After the iteration finishes at block 808, the searchcasting server 200 sends a request message to each responding target computer 202 via the network 201 at block 809. Alternatively, the request message may be sent to each responding target computer immediately upon the receipt of each of the target computers' response. The request message will cause the responding target computer to display a dialog box or other form of I/O interface, prompting the user of the target computer to authorize (or deny) the release of the information which was found to match the query on that user's computer. The dialog box will also inform the user of the identity of the target computer who is seeking the information, thus enabling the user of the target computer to make an informed decision whether to authorize or deny the release of the information.
The above describes an example of the server side process, i.e., the process on the searchcasting server 200. A corresponding client side process is also implemented on each target computer 202 to coordinate with the server side process to accomplish the overall searchcasting process.
If the responding deadline has not yet passed, then at blocks 603-605, the CSACL calculates the three measures of match, namely, 1) how well the user of this target computer (the target user) knows the querying user, 2) how well the content on the target computer matches what the querying user is looking for, and 3) how well the overall knowledge base of the target user matches the subject matter of the search. A detailed calculating process is discussed below. Note that a target computer may have documents having different levels of content match strength. In this case, only the document (or content) with the highest matching strength would be concerned for searchcasting.
Then, after the three measures are obtained, they are compared with the minimum match level at block 606. The minimum and desired match levels may be implemented, for example, as three-dimensional vectors, each vector containing the minimum/desired requirement for the three matching measures. Thus, the comparison of each measure with the minimum/desired match level is to compare each measure with the value of the corresponding vector dimension. There are, however, other ways of implementing the minimum and desired match levels, i.e., a single value obtained by combining the three measures in accordance with a function or formula. As it is well within the knowledge of an ordinary skilled in the relevant art, further discussion with respect to this feature is not necessary to understand the present invention. Back to the discussion of block 606, if the three measures do not meet the minimum match level, the search is ignored directly at block 607, and no response is sent to the searchcasting server from the target computer. Otherwise, they are compared with the desired match level at block 608. If the desired match level is met, the CSACL 302 displays a dialog box to alert the target user that information on his computer has been matched through searchcasting and asks the user to either authorize the release of the information to the querying user or to deny the release before the responding deadline (at block 609). At the same time, the CSACL 302 sends the searchcasting server 200 an anonymous response message, providing the searchcasting server 200 a basis to decide whether or not to reduce the desired match level. As illustrated in
On the other hand, if the three measures fall between the desired level and the minimum level, the target computer saves the search and waits until the next time the desired match level is reduced by the searchcasting server 200 (at block 610). After receiving the newly reduced desired match level (at block 611), if there is still enough time left before the responding deadline of the search, the process loops back to block 608 to check whether the three measures meet the newly adjusted desired match level; otherwise, the target computer ignores the query at block 607.
Note that, alternatively, a query object may be sent as an email to a target user if the user's computer is temporarily turned off. When the user turns on the computer and checks his email, the query object is detached from the email and processed by the CSACL 302.
In an alternative embodiment, the task of periodically reducing the desired match level may be totally performed at the target computer. According to this embodiment, the data structure of a query object is adapted to include a detailed schedule and a formula to reduce the desired match level. Each target computer assumes the task of periodically reducing the desired match level according to the schedule and the formula. In case the searchcasting server has already received enough responses from target computers, the server informs all target computers that have not responded yet to ignore the query.
This alternative embodiment does not require communication between the searchcasting server and the target computers during the process of auction; thus, this embodiment ensures that no information leaves a target computer until the user of that computer allows it.
In an embodiment of the invention, a user may specify one or more personalized match measures for a query and desired match level for each measure. If the personalized measure(s) of a query received at his computer meets the level(s), he will be alerted immediately by the computer. For example, the user may specify that as long as the subject matter of a query is about “fruit”, he should be alerted immediately. Upon such alert, he may choose to respond to the querying user by allowing the computer to send a message, for example, saying “I am interested in this topic, too; would you mind if I contact you with respect to this topic?” Thus, a user in the searchcasting community may keep track of some topics he is interested in even without submitting a query with respect to the topics.
Calculation of the Three Measures
1) Strength of Content Match
The strength of content match between information stored on a target computer and a query may be handled by calling the desktop search engine to search the entire data stored on the computer. Most desktop search engines provide some form of a confidence score for the search, and the confidence score may be a proxy for the strength of content match.
However, different desktop search engines have different relevance metrics and some do not even expose the relevance metrics at all. Thus, the following algorithm may be used as an alternative.
To understand the algorithm, the following concepts need to be introduced first:
(a) Clause
Search expressions can be broken down into pieces, or clauses. Each clause is either a keyword or a phrase. The search expression “oracle database” timeout jdbc “sql db repository” can be decomposed into the following clauses (see Table 1):
(b) Phrases are Better than Keywords
It is much more significant to match a phrase than an individual keyword. Matching a longer phrase is better than matching a shorter phrase. Clauses need to be weighted according to their intrinsic value. To express the better value of phrases and length in formulae, the following parameters are defined:
PHRASE—FACTOR=2
WEIGHT(keyword)=1
WEIGHT(phrase)=PHRASE_FACTOR*length
The clauses in our example would be ranked by weighed as follows (see Table 2):
(c) Title Matches are Significant
One crucial piece of information all desktop search engines provide is the title (i.e., the filename) of matching documents. If each clause is matched to the title, it may be determined whether any of the clauses are in the title. Title matches are significant. For example, a document matching 3 clauses and the title is probably better than a document matching 4 clauses but not the title. That is, a title match may marginally make up for missing a small number of clauses.
(d) Breadth is Key
The higher the number of clauses are matched with a document, the higher the matching strength is. For example, a document that only matches one clause may have a lower matching strength than a document that matchs three clauses. Thus, the formula should take breadth into account, that is, the number of matching clauses is significant in terms of determining the strength of a match. Match score is divided in bands. For example, with 4 clauses, scores may be divided into 4 different bands. But bands may not be all equal. Using the clause weights described above, the relative size of each band may be calculated:
TOTAL_WEIGHT=SUM(WEIGHT(clause))
BAND_WEIGHT(clause)=WEIGHT(clause)/TOTAL_WEIGHT
Note that in Table 3, clause jdbc has a band weight of 8%. This means that matching only the keyword jdbc can only result in a very low match: at most an 8% score.
(e) Minimum Specificity Required
Experience with desktop search engines shows that one keyword searches result in poor document matches. The algorithm will work in this case, but work best when several clauses (in phrase) are provided. Thus, the searchcasting portal may warn a querying user that a single keyword search is too little for searchcasting purposes. Additionally, if the user types a disconnected set of keywords, they may be proactively turned into a set of clauses. For example, if a querying user submits a query for “oracle database systems”, it may be breaken up into a few clauses:
These clauses will provide much more granular results than the original.
(f) Break Ties Using Native Relevance
Some desktop engines do provide a notion of relevance. Microsoft desktop search engine returns a relevance score. Google's desktop search engine only returns rank information. When all things are equal, boost strength using rank or native relevance score. For example, if 4 documents all match the 4 clauses in one case, and none of the clauses is in the title, then do not return the same score for them. Instead, boost the top documents within the range using the native relevance measure.
Then, at block 1802, the process prepares clause combinations and ranks them by breadth and max possible strength. For each combination, the base score is the sum of the clause weights of the clause combination divided by the total clause weight sum of the query (see Table 4 for example).
Next, at block 1803, the process calls a desktop search engine on the target computer to conduct a document search (or content search) with each one of the clause combinations in the order of descending base score. For example, in table 4, the first clause combination used for a search will be clause “oralce database” timeout jdbc “sql db repository”, which has a base score of 100%; and the second one will be either “oracle database” timeout “sql db repository” or “oracle database” jdbc “sql db repository”, both having a base score of 92%. For those documents (or results) returned for a particular clause combination, the matching score may be the clause combination's base score. If enough results have been returned, then the search may be terminated immediately before all of the clause combinations are evaluated.
Then, at block 1804, tied matching scores are adjusted by using relevance metrics or ranks returned from desktop engines. For example, the algoritm first searches for the clause combination with the 100% base score. If it gets results, all those files start with a 100% matching score. In order to further differentiate them appart, their matching scores are adjusted by the native relevance metric as follows:
At block 1805, scores are further adjusted by title matches. As mentioned earlier, title matches are significant, and matching phrase clauses in the title even more so. In this step, the process checkes the clauses against the title string of a document to see if there's a match. If there is, the matching score of the particular document may be significantly raised. This operation may cause a result to transcend its original base score (but may be capped at 100%).
Finally, at block 1806, a set of documents (results) with matching scores with regard to a query is returned. Note that, as discussed above, for searchcasting purpose, only the document (or result) with the highest matching score may be concerned. Thus, for effeciency reasons, as soon as the match with highest score is found, the above algorithm may terminate right away.
2) Relationship Strength
Relationship strength between a user of a target computer and a querying user may be calculated with the help of the desktop search engine. For example, the CSACL on a target computer calls the desktop search engine to do a query on a database of all of the emails to and/or from the user, to try to find out whether the user has directly communicated with the querying user before (i.e., emails have been sent to or received from each other). If so, there is a direct relationship. Depending on how frequent and recent these email communications were, a strength score may be given to the relationship.
If, however, there is no direct communication, then the two users have no direct relationship. They may, however, have exchanged emails by “cc” to each other, or mentioned each other's name in the body of the email, thus, establishing an indirect relationship. Of course, the strength of an indirect relationship is less than the strength of a direct relationship.
3) Knowledge Base Strength
Strength of the user's knowledge base=(w1*M/N+w2*R+w3*D)/(M/N+R+D), wherein w1, w2 and w3 are weights assigned to the three different factors M/N, R and D. The first factor M/N roughly represents how much attention the particular user has devoted to the subject matter of the query during the past. The second factor R roughly represents how long the user devoted his attention to the subject matter during the past. The third factor D roughly represents how recently the user was devoting his attention to the subject matter. Thus, based on the three factors, the strength of the user's knowledge base with respect to the particular subject matter can be estimated. The principle is that the longer, more recently, and more frequently a user has worked on a particular subject matter, the stronger his knowledge base with respect to the subject matter should be.
Note that there are many possible ways to obtain the three measures described above. The above discussion only illustrates one such way.
Searchcasting with Robust User Privacy Protection
In certain embodiments of the invention, in order to address the issue of users' privacy concerns, no information (even the fact that a searchcasting match has taken place) will be sent to the searchcasting server from a target computer until a user of the target computer authorizes it. In addition, the number of users who are to be alerted of a searchcasting match of a query generally should be limited as much as possible.
In an embodiment, the searchcasting server starts out by looking for responses at a high desired match level. To avoid the possibility of bothering a lot of computer users who all match a query at a high level, only a small number of target computers are allowed to alert their users immediately upon a match satisfying the current desired match level at first. If the searchcasting server does not receive any responses within a short period of time, it expands the-group of eligible target computers. As time passes without any response at a high desired match level, the size of the group of eligible target computers expands exponentially. This is called the “expansion” process. If there are no responses and the group of eligible computers includes the entire target group that is currently online, the server knows there is no one who is going to respond at the current strength level. The next step is for the searchcasting server to lower the desired match level (“decay”) and start a new cycle again. The new cycle repeats the expansion process again with a lower desired match level. If the eligible target computers expands to once again include entire target group currently online and no one (or too few) responds within the allotted time, the desired match level is decayed and the expansion process begins anew.
If the query request is not ignored at block 902, the target computer will calculate the three measures (strength of content match, strength of relationship and strength of knowledge base) at blocks 903-905. At block 906, the three measures are compared with the query's minimum match level. If they satisfy the match level, the match is considered as a candidate; otherwise, the query is ignored immediately. Then, at block 907, the three measures are compared with the current desired match level. If they do not satisfy the current desired match level, the process goes to block 908, where the query and the three calculated measures are saved and put to a waiting status until the current desired match level is decayed and a new expansion process starts. When the time comes, still at block 908, the target computer calls the searchcasting server to get the newly reduced desired match level. Then, at block 909, the process determines whether the query has been closed or the responding deadline has passed. If so, the query is immediately ignored; otherwise, the process goes back to block 907, where the three measures are compared with the newly reduced desired match level. A query may be closed for any of the following reasons:
Note that the above list is not an exhaustive list. There may be other reasons the query may be closed by the searchcasting server.
On the other hand, at block 907, if the three measures satisfy the current desired match level, then the process goes to block 910, where it is determined whether the target computer is allowed to alert its user immediately. Whether a target computer is allowed to alert its user immediately upon a match satisfying the desired match level is controlled by the searchcasting server's expansion process. When a query object is downloaded by a group of target computers, the searchcasting server decides, for each target computer, how long it needs to wait before it can alert its user of a match satisfying the current desired match level during this decay cycle. For example, the first few target computers to download the query are allowed to immediately alert their users if they have such a match. Later target computers are given a longer waiting time to avoid having a lot of target computers alerting their users at the same time. As discussed earlier, the number of target computers allowed to alert their users at any one time may increase exponentially. Let's say the first 5 target computers are allowed to immediately raise an alert. The next 15 target computers might have to wait two minutes and check back with the searchcasting server before raising any alert. If the searchcasting server already received enough responses from the first 5 target computers, maybe there is no need to have the additional target computers raise alerts any more. The next 60 target computers might be told to check back in 4 minutes instead of 2 minutes. The next 240 target computers might be told to check back in 6 minutes, and so on. Suppose there are still 60 minutes before the responding deadline, each decay cycle takes 10 minutes, and a user should be given two minutes to respond to an alert. This means that there will be 10/2=5 expansions of the size of the eligible group. The formula for determining the number of eligible target computers in each expansion may be 5*22i−1 where i is the iteration number of the expansion. This means the first batch has 5 eligible target computers. In two minutes, there will be 20 eligible target computers. In another two minutes the number jumps to 80, then to 320, and finally to 1280 (or the whole group, if there are more than 1280 online target computers).
Back to
In an embodiment, the desired match level of a query may be periodically reduced by the searchcasting server. It starts at a high value and decays in increments if the searchcasting server doesn't get any responses from users at a high level. The decay step size may be determined by dividing the total range of acceptable values (initial desired match level—minimum match level) into equally sized buckets. The number of buckets may be determined by dividing the total amount of time left before the responding deadline by the amount of time needed for a decay cycle. The amount of time needed for a decay cycle may be a predetermined value (i.e., 10 minutes), or it may be determined based on other factors such as the network speed, number of computers in the target group, etc. Suppose 10 minutes is to be used for each decay cycle for the particular query. This means that within 10 minutes, every available target computer will get a chance to raise an alert to its user if there is a match satisfying the current desired match level. If the total amount of time left before the responding deadline is one hour (60 minutes), there are 6 available buckets of ten minutes each. If the minimum match level is 30 and the initial desired match level is 100, the total range of acceptable values is 70. In this example, each time the desired match level is decayed, it drops by 70/6 points.
As discussed above, if the match at a target computer does not meet the current desired match level, the target computer put the query into waiting status until the desired match level is decayed, and then the target computer calls the searchcasting server to update the query status, including the reduced desired match level.
Searchcasting with Server Side Auction
In another embodiment of the invention, an auction process is implemented on the searchcasting server 200 to identify the N-best matches of the query.
At block 1403, the searchcasting server receives such responses from the target computers until there are enough responses or until a certain amount of time has elapsed. Then, the auction process logic will process all of the bids received and determine which bid(s) is (are) the winning bid(s) (at block 1404). At block 1405, the searchcasting server sends a request message to each target computer which has a winning bid. The request message will cause the target computer to alert its user to the searchcasting match and ask the user to either authorize the release of the information to the querying user or deny it. As discussed above, the searchcasting server may alternatively send an email to the target user for the same purpose.
Searchcasting with Server Side User Knowledge Profile Filtering
The embodiments discussed above broadcast the query object to all of the target computers that a querying user identified, i.e., to the target group (which may include all of the computers that subscribe to the searchcasting server 200). However, there are some cases when the search volume is high (for example, within an enterprise), so that some individual target computers will be burdened to just process all of the search requests on the background. Thus, in these situations, it would be desirable to send the query to only a limited number of target computers which are likely to yield highly responsive results.
In an embodiment of the invention, as illustrated in
In
Then, at block 1603, for each target user selected, the target computer associated with the target user is identified. This task may be handled by the user filtering logic, or any other logic control within or outside the searchcasting server. The mapping between a user and a computer associated with the user may be stored in the user profile system or another database. Because it is well within the knowledge of a skilled in the relevant art, it is not necessary to discuss the detailed implementations of the mapping mechanism here.
After the target computers are selected at block 1603, the searchcasting server encapsulates the search in a query object and sends the query object to all of the selected target computers for content match (at block 1604). After sending the query object to all selected computers, the searchcasting server starts waiting for responses from these computers at block 1605. If a response to the search is received (at block 1606), the searchcasting server sends the responding computer a request (at block 1607). Upon receiving the request from the searchcasting server, the target computer alerts the user that searchcasting has matched information on his computer. Similar to other embodiments, a dialog box is display to the user to inform the user of the match, the querying user's identity, the information sought, the deadline to respond, and options to authorize or deny the release of the information. Alternatively, email may be used if the user is temporarily off the computer. If a response is not received at 1606, the searchcasting server checks, at block 1608, whether there is enough time left before the responding deadline. If so, the process loops back to 1605 to wait for new responses; otherwise, the process ends.
On the target computer side, the process is illustrated in
Note that after a target user authorizes the release of the information sought by a querying user, the information (i.e., a Word document, an answer to a question, etc.) may be sent directly to the email account of the querying user, or sent to the searchcasting server, from which the querying user may access them. Further, as mentioned in the beginning, a target user may choose to respond to a query by ways other than releasing matched information. For example, the user may choose to send a message asking the querying user to contact him. Especially, when content match is not a match measure for a query (i.e., the match is based on whether the target user is interested in the subject matter of the query), the target user has no matched information to release or not to release. In that situation, the user will choose to respond to the query in other ways if he still desires to. In addition, a user may have an option to forward the information to a repository, such that it would be available to a group in the future without having to have its owner participate in a repetitive searchcast. It might be possible to have such a repository participate in a searchcast group as if it were a user. In other words, this simulated user, which would actually be a server computer, would receive queries, process them, and immediately respond with the content, as if its user had approved doing so.
In addition, before a target user authorizes the release of the information sought, all communications from the target computer to the searchcasting server are anonymous such that they cannot be used to identify the identity of the target user. No private information leaves the target computer until the user of that computer (i.e., the “owner” of that information) allows it. Thus, the privacy issue is also addressed in this searchcasting system.
Thus, a method, system and apparatus for searchcasting have been described.
Software to implement the technique introduced here may be stored on a machine-readable medium. A “machine-accessible medium”, as the term is used herein, includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant (PDA), manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
“Logic”, as is used herein, may include, for example, software, hardware and/or combinations of hardware and software.
Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
