Report:QPAT/Search History Interface/Managing Search Histories
|Report||Patent Coverage Map||Ratings||Comments|
|This search system report was created by the Intellogist Team and is available for viewing only. If you'd like to share your knowledge on Intellogist, please visit the Best Practices, Glossary, or Community Reports pages. Registered users may be notified of any substantial changes to this report by placing a "watch" on the Revisions page, which is the last page listed in the table of contents. To learn more about using the Intellogist "watchlist," see the Watchlist Help page.|| |
|As of January 1, 2013, both QPAT and PatentExaminer have been discontinued, and they have been replaced by the Orbit.com portal.|
Managing Search Histories
QPAT’s approach to recording search activity treats one active session record as a “session history.” While the session is active, queries are saved in a temporary “session history,” where they can be viewed, edited, permanently saved, or stacked.
This history collects search actions during the session, and will remain “active” for two hours after log off. If the user wishes to add to this history, he or she can resume the active session for up to 2 hours after log-off by checking “continue last session” upon logging in.
Note that on this page, the keyword query is displayed, along with the hit count, but no record of the data collections searched is shown. This is because all queries listed here were run in the same files: the session history for an active session is immediately deleted if the user switches files. In other words, suppose a user runs three keyword searches in FamPat, which are saved to the session history. The user then decides to switch files and run a search in the full text file. In this situation, upon returning to the search history page, the only visible query will be the very last one that was performed. All previous search strings will have been erased. To view the files in which a specific query was conducted, users must hover the cursor over a keyword query will cause those files to pop up in a temporary text box.
To prevent accidental loss of query data, queries can be saved permanently at any point from the session history page. Once saved, the search string migrates to the “my saved searches” page, where it can stay indefinitely, once named by the user. The saved searches page is shown in the figure below, prompting the user to enter a name for the newest addition to the list.
In QPAT version 5, the permanently-saved strings on this page could not be organized or grouped in any way, by subject matter or sub-account number, and were permanently fixed in the order which they were saved. In version 6, the saved items are still frozen in order; however, there is a new feature that allows users to save an entire search history at once. At this point, the entire history (including all strings) is compressed into a single script, which can be saved and re-run from the saved search management page. An example of one such saved script is visible in the figure above.
Before a saved script is re-performed, users have the option to edit it (possibly deleting one or more of the steps), and also to select which databases the search should be run in (in other words, the script is not confined to the original file that it was performed in). The figure below shows the editing screen, which includes a collections menu where users must choose their database selection before the strategy is re-performed.
Individual search strings can be saved permanently by user command; in contrast, entire session histories are saved automatically, but this is only temporary storage. Once a session has ended (and the two hour grace period expires), session logs are automatically moved into a temporary storage page, the “my saved sessions” page, where they will be stored for 1 month before they expire.
In sum, assuming queries weren’t automatically wiped out during an in-session file change, the content of these queries will live on for another month in the saved sessions file. Once a query is moved into the “saved session” file, however, it is no longer really a search query. Instead, it is a record of the search results that were returned at the time the query was run; these records are only named by the query text that produced them. For example, when “view” is selected for one of the queries above, the page that is generated is a record of the hit list itself, stars still included. The figure below shows an example of a saved session record.
There is no way that a search can be re-run from the saved sessions page; it is just a frozen-in-time record of the search string and what it returned.
QPAT’s search history function is woefully inadequate for searchers who need to keep a detailed record of their search activities. Searching is an iterative process, and it is important to save a record of all queries that were used during the search, so that others can follow the steps taken during the project. Saving strings is cumbersome: it must be done one-at-a-time, and there is no way to organize strings by project. Thus, saving a record of the step-by-step logic taken to refine a search is very difficult.
The fact that QPAT’s session history is wiped out every time the user switches collections searched is a design flaw; users could easily lose the history record for hours of work this way.
The search history tool can also be considered inadequate because the system does not record/display a record of the files searched, even in the saved session page. Users can only see the files searched when the cursor is hovered over the query text. Accurate search history reporting can be hindered due to this obstacle, since this means a simple copy and paste is not possible: users must manually enter a record of the files searched into a report. QPAT developers probably envisioned users selecting the “printer friendly” option to print and save search histories, but even that function does not display the files searched as text.
Finally, the saved session logs also have their limitations. Many search engines allow users to view a resulting hit list from a query over a set period before the list expires. In MicroPatent, for example, this period is about 18 hours, whereas in QPAT, session records like this are saved for one month. QPAT’s functionality in this regard is a bit different than MicroPatent’s however, because when the hit list is loaded it is presented as a static page. There is no way to load a patent from a saved session log, nor is there any way to export or order documents from this kind of hit list record (note that the customary check boxes enabling those features do not appear in the saved session page). Therefore, the applications of the session logs are quite limited: users can only review and print the displayed information.