GB2597241A - Computer search system - Google Patents

Abstract

A computer search system having a user interface (UI) which displays three panels in a single view (search query panel 311, results panel 312, and associated content panel 313). In this way, a user does not have to move back and forth between different screens which may add to the time the user is willing to spend and the processing resources the computer may have to use. In this way, the delay the user experiences in receiving a search result is reduced. The UI may include a scrolling facility for scrolling through the search results displayed in the results panel. The search system may also include a database that uses precomputed lookup tables in the database search (such as a bitmap lookup structure or index). This feature may provide for faster retrieval of the search results. The search system may also be generating the UI using a graphics engine that uses textured triangles and directly accesses the graphics card via an API that bypasses the operating system (OS)-e.g. by using an OpenGL API. This may allow for faster graphics which may make the UI more responsive to the user.

Description

COMPUTER SEARCH SYSTEM

Field of the Invention

The present application relates to a computer search system.

Background

Computers are widely used for storing information and can accommodate very large amounts of data. Users have various tools available for working with this stored data, for example, to identify data of interest for retrieval. One well-known type of computer storage system is a relational database, in which the data is held in a set of tables, each table having an arrangement of rows and columns. The database can be interrogated using a formalised structured query language (SQL) to search for and access selected rows of the database.

It is also desirable to search data sets which, unlike a relational database, do not have a formal, structured configuration -the Internet is an example of such an unstructured data set.

The most common approach for searching the Internet is to use a search engine such as Google based on one or more keywords. More particularly, Google and other similar services provide a search screen including a box for a user to enter one or more keywords to define a search query. After the user hits the search button (or enters Return), a results screen is presented which contains the search results, i.e. a list of hits or matches for the search. Each hit or match corresponds to the uniform resource locator (URL) of a web page that is considered to be relevant to some or all of the entered keywords (typically because the web page includes the keywords).

The search results are generally presented on the results screen in a list ordered by perceived relevance -for example, a URUweb page having the keywords in the title or having the keywords occur multiple times will generally be considered as having increased relevance, and hence located nearer the top of the list. For some queries, the number of hits may be very large, and accordingly the list of results is spread across multiple pages (screens), with a user having to click a forward button and a back button to navigate through the full list.

Each search result may include a brief extract of the content from a matching URL/web page to help a user assess the relevance of the match. For example, the brief extract might typically provide a short portion of the web page containing one or more of the keywords for the search. Once the user has selected a particular search result as being of interest, the user clicks on that search result and is transferred to the page identified by the search result.

This type of keyword searching is widespread on the Internet and performs well when both the search engine and the user are able to make a good assessment of the relevance of the search results. This allows the best result(s) to be presented on the first screen of search results and then quickly selected by a user. However, in other circumstances, the performance of such search engines is less satisfactory -for example, keywords may have low specificity, the user may be less certain of what they are looking for, the number of potential hits may intrinsically be large, and so on. This can lead to the user having to navigate through many screens of search results to find and review hits of interest. A user may select a particular search result and go to the corresponding page, only to find that the page is not as helpful as expected, so the user then has to return back to the search results screen.

This type of navigation involving travelling back and forth between different screens of search results and/or between a screen of search results and web pages corresponding to selected hits on that screen can become very time-consuming for the user. It may take a relatively long time for the user to find search results that are most suited to his/her requirements -and in some cases the user may stop looking before finding the best search results, settling instead for a sub-optimal result, or perhaps no result at all (of course, the user may not realise that a given result is sub-optimal if only some of the search results have been reviewed in detail). Moreover, such repeated iterations between different screens of search results and/or between screens of search results and the web pages for selected search hits consume additional processing and communications resources, both for the server system running the search engine, and also for the client system of the user performing the search.

Summary

The invention is defined in the appended claims.

An example of a computer search system such as described herein is configured to perform a search query to generate search results and to provide a user interface. The computer search system includes a first panel configured to receive as user input a search query and to display the received search query in the first panel; a second panel configured to display search results obtained by performing the search query input to the first panel and to receive as user input a selection of a search result from the search results displayed in the second panel; and a third panel configured to display content associated with the selected search result. The user interface is configured to display the first, second and third panels together in a single view.

An example of a computer search system such as described herein comprises a search engine configured to generate search results in response to a search query using precomputed lookup tables which are retained in memory during operation of the computer search system.

The computer search system further comprises a graphics engine for generating a user interface for receiving a search query and displaying search results in response to the search query, wherein the graphics engine is configured to use textured triangles for generating the user interface, and wherein the graphics engine is configured to directly access a graphics card via a graphics application programming interface (API) for displaying the user interface, bypassing an operating system of the computer search system.

An example of a computer search system such as described herein comprises a search engine configured to provide for real-time generation and display of search results in response to a search query, and for real-time display of content associated with a selected search result. Typically, such real-time performance implies no perceptible delay for the user between receiving a user command (such as a search query or the selection of a particular search result). For example, a delay may not be perceptible to a user if it is of the order of 0.1 seconds or less; similarly, a delay may not be perceptible to a user if it is less than say 2 times the refresh period of a typical display device.

Brief Description of the Drawings

Various implementations of the claimed invention are disclosed herein with reference to 10 the accompanying drawings by way of example only: Figure 1 is a high-level schematic diagram of an example of a computer search system as disclosed herein.

Figure 2 is a high-level schematic flowchart showing an example of processing performed by a computer search system such as shown in Figure 1.

Figures 3A-3C are high-level schematic diagrams of examples of a user interface for a computer search system such as shown in Figure 1 and represent a potential sequence of user operations or interactions with the computer search system.

Figures 4 and 4A-4C are examples of a more complex user interface for a computer search system such as shown in Figure 1, but retaining the same high-level configuration as the user interface shown in Figures 3A-3C. In particular, Figure 4 shows an overview of the primary user interface screen containing three panels (panes), while Figures 4A, 4B and 4C provide detailed views respectively of the left-hand panel showing the search, the central panel showing the search results, and the right-hand panel showing content of the search results.

Figures 5A and 5B show examples of collapsible bars relating to a unit cell and bibliography respectively; these bars are shown in compressed (collapsed) form in the search pane of Figure 4A but are in expanded form for Figures 5A and 5B.

Figure 6A shows an example of another potential arrangement of the results pane which a user may select as an alternative to the arrangement of Figure 48. In particular, whereas Figure 4B shows a list view, Figure 6A shows a 3-D graph view. Figures 6B and 6C show examples of other potential arrangements of the contents pane which a user may select as an alternative to the arrangement of Figure 40. In particular, whereas Figure 40 shows a details view, Figure 6B shows a coordinate view and Figure 60 shows powder pattern view.

Figure 7 is a high-level schematic diagram of a computer search system, such as shown in Figure 1, but incorporating the system platform on which the computer search system is 35 implemented.

Detailed Description

Figure 1 is a high-level schematic diagram of an example of a computer search system 100 as disclosed herein for use by one or more users 50. The computer search system 100 comprises a user interface 110, a graphics engine 120, a search engine 130, and stored data 140, which can be considered to provide or represent the search domain comprising data items for search. The user interface 110 is a two-way (input/output) graphical user interface (GUI) which is used both for receiving control inputs (commands) from the user 50, for example to instruct the search engine 130 to perform a particular search, and also for displaying the results from these commands on some appropriate display device, e.g. a screen, monitor, etc. The user 50 may enter the commands to the user interface 110 using a suitable input device, such as a mouse, keypad, keyboard, touchscreen, and so on.

The user commands are passed from the user interface 110 to the search engine 130 which is then responsible for implementing each user command to generate search results for display back to the user 50. This involves the search engine 130 performing one or more operations with respect to stored data 140, such as locating the data, accessing the data, selecting the data, retrieving the data, processing the data, filtering the data, transforming the data, aggregating the data, summarising the data, configuring the data, and so on. As a simple example, if the user command represents a search query, the operations of the search engine 130 may include identifying the data on which the search is to be performed (the search domain), retrieving and processing the data to select data items which satisfy the search query, and outputting a list of the selected data items to the graphics engine 120. The graphics engine 120 is then responsible for updating the user interface 110 to display the list of selected data items received from the search engine 130 to the user 50. The graphics engine 120 is able to render the user interface at different resolutions to allow for compatibility with various display devices having different resolutions.

Figure 2 is a high-level schematic flowchart showing an example of processing performed by a computer search system 100 such as shown in Figure 1. Commencing at operation 210, a user 50 initially enters a user interface (UI) command into the user interface 110. In this context, a Ul command represents a command that is entered into (received by) the user interface 110 relating to the operation of the computer search system 100, although the Ul command may not be directed specifically at the user interface 110 itself. For example, in some cases the user might enter one or more keywords for the query (analogous to conventional web searching) or a formal SQL query (analogous to accessing a relational database). In other cases, the Ul command may relate to how (and/or which) search results are displayed by the user interface 110.

In general, the user input may be textual and/or graphical in nature. The particular form of Ul command for operation 210 is not restricted, but rather any suitable format may be used, as supported by the particular computer search system 100 and appropriate for the search domain.

The Ul command entered by the user at operation 210 is passed to the search engine 130, which then performs (or updates) a search on data 140 at operation 220 in accordance with the entered command. Note that in some cases, the Ul command entered by the user may represent some manipulation of an existing search, for example, filtering results from the existing search, scrolling down a list of search hits from the existing search, selecting to access content for a particular hit from the existing search, and so on. Thus updating the search at operation 220 should be understood as encompassing various forms of user interaction with the existing search results, including modifying how (and/or what) existing search results are displayed to the user, as well as identifying the search results themselves and their associated content (as described below).

The updated search results from operation 220 are passed from the search engine 130 to the graphics engine 120, which at operation 230 updates the user interface 110 to reflect the updated search results. As shown in Figure 2, processing may now return to operation 210 to receive a further Ul command from the user 50. The computer search system 100 described herein is particularly suited (although not limited to) such iterative or cyclic searching, in effect allowing a user to explore the data set 140 by performing repeated updates to the search. For example, at different passes through operation 210, a user may try various search queries or variations or modifications of a given search query to investigate how this impacts the search results produced at operation 220; alternatively or additionally, for such different passes through operation 210, the user 50 may also select to review various search hits to assess their relevance or interest to the user.

Computer search system 100 is able to support such iterative or cyclic operation in a real-time manner -i.e. after entering a Ul command at operation 210, a user has little or no perceivable wait (low latency) for the search update to be performed at operation 220 and for the Ul display to be updated accordingly at operation 230. In this context, real-time implies that the time for each iteration, i.e. from a Ul command being entered at operation 210 until the resulting Ul display update is completed at operation 230, is less than a predetermined value, for example, less than 1 second, or less than 0.5 second, or less than 0.25 seconds, or less than 0.10 seconds, or less than 0.05 seconds, or less than 0.025 seconds, and so on.

It is also possible to express the real-time operation by way of an update frequency for looping around the cycle of operations shown in Figure 2 (discounting any wait for the user input at operation 210). It will be appreciated that the update frequency represents the reciprocal of the time for each iteration or loop. In this case, real-time implies that the update frequency is above a predetermined value, for example, above 1 Hz, or above 2 Hz, or above 5 Hz, or above 10 Hz, or above 20 Hz, or above 50 Hz, or above 60 Hz, and so on. (It will be appreciated that these frequency values, and also the above time values, are provided by way of example only and other values might be used instead).

In some cases, the update frequency for cycling through the operations of Figure 2 may be expressed in terms of the refresh rate for the screen on which the user interface 110 is being displayed. For example, the update frequency may be at least 50%, or at least 75%, or at least 100%, or at least 150%, or at least 200% of the screen refresh rate. A typical refresh rate for a laptop screen, monitor, etc., is 60 or 120 Hz, although some higher end graphics devices may have faster refresh rates. In general, if the update frequency is comparable with the screen refresh rate, then the output of each update cycle will be displayed at the next screen refresh (or potentially at the next screen refresh but one), thereby providing the user with a real-time, highly responsive experience.

Figures 3A-3C are high-level schematic examples of a user interface 110 for a computer search system 100 such as shown in Figure 1. The user interface 110 provides a display screen 301A, 301B and 301C as shown respectively in Figures 3A-3C, whereby the term display screen is used here to denote the visual content provided to a user 50 at a given time (rather than the hardware display or screen per se). In particular, display screens 301A, 301B and 3010, as further detailed below, illustrate an example of a potential sequence of visual content provided to a user 50 who is using (interacting with) the computer search system 100.

The display screen 301A comprises three panes or panels, 311, 312, 313 (the terms pane and panel are used interchangeably herein). The panes are generally rectangular in shape, with all three panes being approximately the same size and shape as one another. In some implementations, a user may be able to configure the size, shape and/or screen location of each individual pane. For example, a user may choose to expand the area of a selected pane (typically at the expense of the other panes) if the selected pane is currently presenting information which is of particular interest to the user and/or which is more extensive than the information presented by the other panes.

In the display screen 301A, each pane extends downwards to occupy most or all of the available height of the display screen 301A. The three panes are configured as a left-hand query pane 311 for entering a search query, a central results pane 312 for displaying hits from the search entered in the query pane 311, and a right-hand contents pane 313 for displaying content from one or more selected hits in the results pane 312.

By way of example, query pane 311 contains a box 315 for entering a search query in free text form and a set of filters 316 for setting binary attributes for refining the search query. For example, the attributes 316 may be used to filter out (remove) data items that do not possess the specified (set) attributes. For example, if the search relates to hotels, attribute A might indicate that the hotel has a swimming pool, attribute B might indicate that children are welcome, and so on. In Figure 3A, attributes A, B and E have been set, as indicated by the associated crosses, but attributes C and D have not been set. Search results based on the keywords entered in box 315 are therefore filtered (refined) to discard hits not having attributes A, B and E. The entry box 315 and attributes 316 shown in Figure 3A represent just one way of specifying and/or refining a search query, and computer search system 100 can be implemented to support any desired form for entering a query. For example, in some cases it may be feasible for a search query to be entered just on the basis of attributes 316, without requiring any keywords to be entered in query box 315. The particular form of query used in any given computer search system may be dependent on the properties of the search domain, such as the structure, nature and/or volume of the data 140 to be searched. For example, if the data 140 is held within a relational database, then entry box 315 might accept an SQL query as input to specify a desired search. Another possibility is for the query (search) pane 311 to provide fields and/or various graphical elements to facilitate a user entering such an SQL query (so the user does not have to know specific SQL syntax for the query). In some implementations, one or more attributes might allow the entry of a numerical range, for example to specify a price range and/or a date range of interest. In some implementations, the search pane 311 may present some form of image to the user, and the search query is specified at least in part by selecting a location of the image -for example, the image may represent a map, and clicking (selecting) a particular location on the map may provide results relating to or available from that location. The search panel may also support multiple different facilities to be used in combination for entering a search query, such as the combination of search box 315 and the list of attributes 316 shown in Figure 3A. The skilled person will therefore be aware of a wide range of possibilities for how the user interface 110 may define and display the query pane 311 according to the particular requirements of any given implementation.

When a query has been submitted via the query pane 311, as per operation 210 of Figure 2, this is query is passed to the search engine 130, which performs the search across the data 140 as per operation 220, and the results of the search are then passed to the graphics engine 120 for display on the user interface 110.

As shown in Figure 3A, the results pane 312 comprises a listing of search hits (search results) that satisfy or match the query currently entered into the query pane 311 (and as calculated by the search engine 130). The search hits are labelled schematically in Figure 3A as Search result A, Search result B, and so on, which is intended to indicate that the search results are displayed in some logical order in results pane 312. This ordering may be alphabetical, as shown in Figure 3A, but in many cases one or more other criteria might be used to determine the form of ordering for displaying the results. For example, this ordering might be based on factors such as perceived relevance of the hit, date of the hit, author of the hit, and so on. In some implementations, the user may be able to configure the basis for determining the ordering of the search hits (including whether the order goes from low to high or vice versa).

In the implementation of Figure 3A, the search results are presented in the results pane 312 as a single list. In other words, there is no need to click between different screens of search results to investigate the full set of search results, rather the user 50 is able to scroll up and down the complete list (full set) of search results in a continuous operation using a scroll facility.

The scroll facility in results pane 312 is part of the user interface 110 and is generally configured in known fashion and comprises a scroll bar extending vertically to the immediate right of the search results. Up and down arrow buttons are located at the top and bottom of the scroll bar respectively, while a scroll box is located somewhere along the scroll bar, between the up and down arrows. The scroll box is used to determine which subset of the list of search hits is currently visible within the results pane 312. In particular, the location within the overall list of the subset of search hits displayed in results pane 312 directly corresponds to (matches) the location of the scroll box within the scroll bar. For example, assuming that the list is longer (potentially much longer) than the available space in results pane 312, locating the scroll box at the top of the scroll bar, i.e. adjacent to the up arrow, causes the search hits in the top (initial) portion of the list to be displayed in results pane 312, while locating the scroll box in the middle of the scroll bar causes the search hits in the middle portion of the list to be displayed in the results pane 312, and so on. This movement through the list of search hits may be used to locate a specific hit (and associated content) of interest within the overall list of search results and/or more generally to review or browse the full set of search results.

The user interface 110 typically provides various techniques for moving the scroll box up and down the scroll bar, thereby scrolling the subset of search hits visible in results pane 312 up and down through the full list of search hits. One technique is to press the up or down arrow, which causes the scroll box to move along the scroll bar in the direction indicated by the arrow. For a touch screen, such pressing may be performed by touching and maintaining contact with the up or down arrow as appropriate, e.g. using a finger. If a mouse is being used, such pressing is generally performed by locating the cursor over the desired button and then holding down the (left) mouse button. The scroll box then moves in the direction indicated by the pressed arrow until either the user stops pressing, or the limit of the scroll bar is reached, i.e. the scroll box would then be at the top or bottom of the scroll bar as desired, adjacent the respective arrow button, and the top or bottom of the list of search results is correspondingly displayed. Another technique is to press a selected location on the scroll bar itself; this is generally similar to pressing an up or down arrow, except that the scroll box moves towards the selected location (rather than the top or bottom of the scroll bar), and movement then stops when the scroll box arrives at this location (or when the user stops pressing on the scroll bar, whichever is sooner).

A further technique for moving the scroll box is referred to as a drag operation, in which the scroll box itself is moved directly by the user to a location corresponding to a position of interest within the list of search hits. For example, with a touch screen device, the drag operation may be performed by touching the scroll box with a finger, and then dragging the scroll box by moving the finger in the desired direction of movement for the scroll box while maintaining contact between the finger and the search box. In the case of a system having a mouse as the input device, such a drag operation may be performed by moving the mouse to position the cursor over the scroll box. The mouse button (typically the left button) is then pressed (activated) and maintained in this state while the mouse is moved in the desired direction of travel for the scroll box. Accordingly, the finger or the mouse in effect is used to drag the scroll box up or down the scroll bar as desired.

It is also known for a mouse or other user input device to include a scroll wheel (often located between the left and right mouse buttons). Rotating this scroll wheel in effect moves the scroll box up and down the scroll bar (according to the direction of rotation of the mouse wheel), analogous to a drag operation on the scroll box, and thereby scrolling the results displayed in pane 312.

The skilled person is also aware of other potential implementations for the scroll facility of user interface 110. For example, the scroll facility may comprise just a scroll box which is dragged up or down as appropriate, but without having any scroll arrows top or bottom, and potentially without having any scroll bar. In addition, the scroll facility, such as a scroll box (and also a scroll bar, if provided) may be fully or partially hidden during general operation of the system to provide more visible display area. When the cursor is moved to the (right-hand) edge of the screen (or upon some other suitable prompt), the scroll facility may become fully displayed to support operation of the scroll facility. Furthermore, although it is expected that all panes have an analogous scroll facility for consistency of user experience, if desired a scroll facility might be varied from one pane to another, e.g. to take into account the nature of the data to be displayed in each particular pane.

A further approach for changing the subset of search hits which is displayed in results pane 312 from the overall list of search hits is to manipulate the list itself directly. There are various ways in which this can be accomplished, for example, if the computer search system includes a keypad, a user may be able to move up and down through the list by pressing the page up and page down buttons on a keypad, or by pressing the up arrow or the down arrow on the keypad (rather than on the scroll bar). A further possibility is in effect to drag the list upwards or downwards as desired, by positioning the cursor over the list, pressing the (left) mouse button, and while keeping this button pressed, moving the cursor to just outside the top or bottom of the results pane 312. When the list of search results is directly moved in such a manner, the user interface 110 moves the scroll box up or down the scroll bar as appropriate in order to maintain the correspondence between the position of the scroll box within the scroll bar vis-à-vis the position of the subset of search results displayed in the results pane with respect to the full set of search hits.

Figure 3A shows the situation in which a user 50 has selected a hit (search result) of interest in the results pane 312. The user can select this hit in a conventional manner, for example by touching the hit on a touch screen, or by positioning a cursor over the hit and pressing the (left) mouse button. In the case shown in Figure 3A, Search result C has been selected by the user 50, and is high-lighted to confirm this selection and to distinguish from the other hits which have not been selected. It will be appreciated that the high-lighting can be performed using any suitable technique, such as by making the selected hit bold, or larger, or underlined, or changing the colour of the hit and/or of the background of the hit (or by a combination of any such techniques).

In response to a user selecting a search hit in the results pane 312, content corresponding to this selected hit is shown in the content pane 313. In the example of Figure 3A, it is assumed that the search results relate to different compounds or materials, and the contents pane shows a structure diagram for the compound specified in the selected search result. It will be appreciated that the content displayed in the contents pane 313 can be of any suitable form, e.g. text, graphics, images, maps (and any combination thereof) according to the properties of the search results, and more generally of the search domain and the data items therein. Note also that although the content pane 313 is not shown in Figure 3A as having a scroll facility, such a scroll facility may be provided as appropriate in the content pane -typically if the content extends beyond the space which is currently available (visible to the user) in the results pane.

(The same may also be the case for the query pane 311 if the tools or elements for entering the query likewise extend beyond the available space).

Displaying the contents associated with the selected hit in the contents pane 313 of display screen 301A as shown in Figure 3A while also retaining the results pane 312 visible in the display screen 301A avoids a user having to transition back and forth between a search results screen and a screen associated with a selected search hit. Instead, as shown in Figure 3A, the display screen 301A provides a user with a good overview of a search, including the search query itself as specified in the query pane 311 (such as via the query box 315 and the attributes 316), the listing of search results which satisfy the query in the results pane 312, including an indication of any currently selected search result, and the content corresponding to the currently selected search result in the content pane 313.

A user may change the selected search result by selecting (e.g. by touching or clicking on) another search hit displayed in the results pane 312, for example, search result G. In this case, the update search operation 220 retrieves the content associated with newly selected search result G to display in the content pane 313 (in place of the content currently shown for search result C in Figure 3A). In some implementations, selecting a search result that is already selected may de-select that search result (so the selection operation in effect toggles between selecting and unselecting). For example, in Figure 3A, selecting search result C again may deselect this search result, thereby causing the user interface 110 to remove the high-lighting, so that search result C is no longer distinguished from the other search results, and also to empty content pane 313 of the content associated with search result C. It will be appreciated that direct selection of a(nother) search result is feasible if the other search result is already visible in the results pane 312. However, if the user wishes to select (or consider selecting) a search result which is not currently visible in the results pane (because the portion of the listing of search hits which contains this search result does not correspond to the portion of the search hits currently displayed in results pane 312), then the user 50 may scroll up and down the list as described above to locate a desired search result.

The user interface 110 is configured so that a scroll operation performed directly using the scroll bar on the right of the results pane (whether by using the up/down arrows, dragging the scroll box, and so on) not only changes the portion of the search results visible in results pane 312 (as for conventional scrolling), but also changes the selected search result. In particular, as the scroll box moves up or down (according to the user operation), the selected search result keeps approximate pace with the scroll box. For example, if the scroll box is moved down through (say) approximately 35% of the overall search results, the selected search result likewise moves down through approximately 35% of the overall search results, one hit at a time.

Figures 3A and 3B show an example of this operation, whereby the transition from the display screen 301A of Figure 3A to screen 301B of Figure 3B may be achieved by dragging the search box down and stopping when the selected search result is Search Result P. Note that Search Result P is not visible in Figure 3A because the relevant portion of the overall listing of search results (i.e. the portion containing Search Result P) is not shown in Figure 3A, however, by operating the scroll bar, such as by dragging the search box downwards or pressing the down arrow, the relevant portion of the overall listing of search results (i.e. the portion containing Search Result P) becomes visible in the results pane as per Figure 3B.

As can be seen in Figure 3B, the contents pane 313 is automatically updated to reflect the newly selected search hit -i.e. the contents pane of Figure 3B shows a structure corresponding to the compound of Search Result P (this is assumed to be different from the compound of Search Result C and the structure shown in Figure 3A). In this context, automatic updating implies that once the scroll box has been moved to select Search Result P, the user interface 110 is configured to provide, without further user input, the content associated with Search Result P in the contents pane 313.

In some implementations, two different modes of scrolling may be supported for use with the results pane 312. In a first mode of scrolling, the selected search hit tracks the scrolling operation as above. In other words, as the scrolling moves downwards (say) through the list of search results, the selected hit likewise moves successively downwards through the list of search results (typically at the same pace as the scrolling). In addition, the display of content for the selected hit in contents pane 313 is updated to reflect this changing of the selected hit -i.e. the content for each selected hit is displayed in turn in the contents pane 313 as the scrolling is performed. In the second mode of scrolling however, when the scrolling moves downwards through the list of search results, the selected hit remains unchanged (and so there is no updating of the content displayed in the contents pane 313).

There are various ways in which a user might choose to select between the first and second mode of scrolling. For example, operating a scroll wheel might invoke the first mode, while dragging a scroll box by moving a mouse with a button pressed might invoke the second mode. Whichever mode of operation is supported and/or invoked, the scroll facility of the use interface 110 allows a user to rapidly review the search results, which may number hundreds or potentially thousands.

With reference to Figure 2, the movement of the scroll box represents operation 210 (receive Ul command), and the selection via the scrolling operation of Search Result P causes the updated search of operation 220. Note that updating the search as per operation 220 does not necessarily imply that a new or modified search query is run, rather, as here, the system determines different results and/or content from the existing search to be made available to the user at operation 220. This then allows the user interface 110 to be updated as shown in Figure 33 to reflect the different search results to be displayed to the user in results pane 312.

Note that scrolling from Search Result C down to Search Result P may cause each intermediate search result (hit) to be selected in turn en route -i.e, first Search Result D is selected, then Search Result E, and so on, until the scrolling operation stops at Search Result P. As each intermediate search result is (briefly) selected, the contents pane 313 is updated automatically to reflect this current selection. In this sense, the transition from display screen 301A to display screen 3013 represents multiple iterations around the processing loop of Figure 2, namely one iteration for each intermediate search result that is scrolled through, and then a final iteration on arrival at Search Box P. In particular, when the scroll box comes to a halt in a position corresponding to Search Result P, this then remains the currently selected search result, as shown in Figure 33.

Figure 3C shows the result of a further cycle or iteration of the flowchart of Figure 2 with respect to the display screen of Figures 3A and 3B. In particular, it is assumed that the starting point is the display screen 301B of Figure 38, and the received Ul command at operation 210 is to uncheck the attribute B from the filters 316 (compared to the checked state in Figures 3A and 3B). In general, a filter that is unchecked is not applied to the search, so the results of the search are broader than with the filter checked, i.e. the search criteria are satisfied irrespective of whether or not attribute B is present.

This Ul command entered at operation 210 to uncheck attribute B therefore updates or modifies the previous search query to obtain (usually) a new set of search hits. This is in contrast to the Ul command used to scroll from Figure 3A to Figure 33, which does not change the set of search hits, but rather changes how the existing set is displayed. It will be appreciated that the new search results may be obtained by running a completely new search, or by narrowing, modifying, or supplementing the existing set of search results. For example, in the present case, the search results for Figure 3C would typically be generated by running the previous search query but without using attribute B as a filter in order to update the search results as per operation 220. (Other query strategies are possible, for example the previous query might be repeated, except looking for the absence rather than the presence of attribute B; the results from the previous query and this new query could then be combined to give the full set of search results which are satisfied irrespective of whether or not attribute B is present).

In operation 230, the user interface 110 is updated with the results of the new search. As noted above, the new search of Figure 3C is generally a broadening of the previous search, in other words, the previous search results shown in Figures 3A and 33 remain, but are supplemented by additional search hits. Thus Figure 3C shows previous search hits L, M, N, 0, P and Q joined by new search hits L1, P1 and P2 as displayed in Figure 3C. It can therefore be assumed that attribute B is not present for new search hits Li, P1 and P2.

Note that these new search hits are displayed directly in response to unchecking attribute B. In other words, once a user interface command has been received at operation 210, the remaining processing of Figure 2 is performed automatically -i.e. the search results are updated by the search engine at operation 220 and the updated search results are displayed by the user interface 110 at operation 230 to give the display screen 301C of Figure 3C without further input from the user. This updating of the display screen from screen 301B of Figure 33 to screen 301C of Figure 3C is generally achieved in real-time, typically on a time-scale of a fraction of a second, so that the user 50 is not aware of any delay or latency.

Updating the display screen as per operation 230 includes any consequential changes to the user interface 110 as a result of the updated search. For example, in the context of Figure 3C, search result P is still indicated as selected (as for Figure 33), however, the position of the scroll box has shifted slightly upwards for Figure 3C compared to Figure 38. The position of the scroll box remains associated with the position of the selected search result P with respect to the overall listing of search results, hence this upward moving of the scroll box implies that the new results (those without attribute B) are slightly biased towards the lower portions of the listing of results below search result P (according to the ordering applied to the list).

In some cases, updating the search results at operation 220 might narrow or change the search criteria such that the currently selected search result (search result P in Figure 33) no longer represents a search hit, and hence is removed from the search results provided in results pane 312, along with the corresponding content for search result P from the contents pane 313.

One option in this case is that no selected result is now present, in which case the content pane 313 remains empty until the user explicitly selects a search result from results pane 312. Alternatively, various default options could be used to determine a newly selected search result, such as the first result in the overall listing, whereby this default newly selected search result would be suitably highlighted in the results pane (as for search result C in display screen 301A) and the corresponding content shown in the contents pane 313. (Some implementations might also provide such a default selection of a search result for the initial search, prior to any user selection).

The computer search system 100 described herein offers a number of benefits in comparison with known search systems. Thus the user interface 110 shown in Figures 3A-3C avoids conventional screen transitions between different sets of search results, and also between search results and associated content. For example, in display screens 301A-301C, a user is able to see both a search hit (in results pane 312) and also the associated content (in contents pane 313) without the need for any screen transition between the two. In addition, scrolling is used (rather than screen transitions) if the hits in the results pane 312 extend beyond the space available in display screen 301A. This facilitates a quicker review and selection of relevant search hits by a user 50.

The user interface 110 of the computer search system 100 may also help a user to obtain better search results by making more information immediately available to the user. For example, the user interface 110 of the computer search system 100 makes it feasible to review content for more search hits in a reasonable time (by comparison with a conventional search system), such as by scrolling through successive search hits in the results pane 312 and having the corresponding content directly available to view in the content pane 313, as described above in relation to Figures 3A and 3B.

In addition, the parallel configuration of the three different panes, in which the search results and selected content are displayed in parallel to (in conjunction with) the original search query, allows a user to maintain context across the overall search process. This can help a user to perform a more direct comparison between search results both within a query and also between queries. The former possibility is exemplified by the scrolling operation described above in relation to Figures 3A and 3B, which provides a rapid review of content associated with different search results for a given query. The latter possibility is exemplified by the query modification described above in relation to Figure 3C, whereby a user is able to explore the search domain by modifying the query and getting immediate, direct feedback on any changes to the search results and their associated content. Accordingly, the computer search system 100 provides user 50 with a search facility that not only helps to provide a quicker outcome from a search, but also supports a better outcome from the search based on the increased ability of the user to explore and understand the search domain.

Figures 4 and 4A-4C are examples of a more complex user interface for a computer search system 100 such as shown in Figure 1. The user interface of Figure 4 retains the same high-level configuration as the user interface shown in Figures 3A-3C. In particular, Figure 4 shows an overview of the primary user interface screen containing three panels (panes). Figures 4A, 4B and 4C then provide detailed views of these three panes from Figure 4, the left-hand pane (Figure 4A) showing the search query as per pane 311, the central pane (Figure 4B) showing the search results as per pane 312, and the right-hand pane (Figure 4C) showing content of a selected search result as per pane 313. The three panes are approximately the same size and shape as one another, with each pane extending from substantially the top of the screen to the bottom of the screen (as noted above, in some implementations, a user may be able to configure the size, shape and/or location of each pane as appropriate). Note that the scale of some of the detail in the overview of Figure 4 may be too small to be readily discerned, however this detail can be seen more easily in the enlarged views of Figures 4A-4C as appropriate.

Accordingly, Figure 4 provides a user interface 110 for a computer search system 100 which shares various features with the user interface of Figures 3A-3C. Thus the user interface 110 in Figure 4 comprises three panes which in combination provide an overview of the entire search in progress -from the specified query in the left-hand panel, to a listing of the search results for the specified query in the centre panel (which also includes a scroll facility for reviewing the listing of search results), to a display of content for a selected search result in the right-hand panel. The user interface of Figure 4 also performs automatic updating of the search results and associated display, as described above in relation to Figures 3A-3C.

The computer search system 100 of Figures 4 and 4A-4C is configured to support searching for (inorganic) compounds as previously discussed. Some of the components of the user interface 110 shown in Figure 4 are specifically developed for this particular search domain, which is relatively structured in nature. It will be appreciated that other components can be developed as appropriate for a user interface 110 for use with different search domains.

As shown in Figure 4, a navigation bar is located at the bottom of the screen (generally beneath the results pane). This navigation bar has four buttons. The first (leftmost) button is used to obtain the three-panel (three-pane) view shown in Figure 4; the second, third and fourth panels are used to select a full-screen mode for the query pane, the results pane, or the content pane respectively. In the configuration shown in Figure 4, clicking on (or otherwise activating) the first button has no effect, since the screen is already in the three-panel mode, however, it can be used to return to the three-panel view if a user has previously selected to have one of the individual panes in full-screen mode. If a user does select such a full-screen mode for a given pane, then the arrangement of the information displayed therein may vary from that of given pane when displayed in the three-panel view in order to best utilise the additional display space which is available. Accordingly, Figures 4A-4C should be understood to represent enlarged representations of the configuration of the panes (panels) in the three-panel view, rather than representing an individual pane in full screen mode.

(The full-screen mode for an individual pane will not be further described herein, since a main focus of the present application is a computer search system that supports the three-panel view. Likewise, the navigation bar may also allow access to other views, for example, comprising two panes, or containing additional elements beyond the three panes, however, these will also not be described further).

In the implementation of Figure 4, the second button in the navigation bar is labelled "search" to indicate it provides access to the search pane), while the third and fourth buttons are also used to provide information (in addition to providing access to full-screen for the results and navigation panes). In particular, the third button in Figure 4, corresponding to the results pane, is used to indicate the number of search results arising from the current search -in the case of Figure 4, this is 643 Results. This indicates the number of hits in the overall listing that can be accessed by scrolling the results pane.

The fourth button corresponding to the content pane is used to indicate an identifier of the currently selected search result -in the case of Figure 4, this is Compound 504242 (which is a database identifier for this search result). The content corresponding to Compound 504242 is displayed in the content pane. It will be appreciated that other implementations may provide different (or no) information in such a navigation bar.

Figure 4A shows an enlargement of the search query pane (corresponding to pane 311 in Figures 3A-3C). At the top of this pane is a query box, generally analogous to the query box 315 in Figures 3A-3C. In the example shown in Figure 4A, this box contains the query "Zr and 19752016 and Coordinates" (where the "AND" comprises the standard Boolean operator such that all input/search conditions must be satisfied to produce a positive output). A query can be entered directly as a search string into the query box, and/or the computer search system 100 may provide additional support or facilities for forming and entering queries using the query pane. For example, the top portion of the search pane includes a diagram of the periodic table.

The element Zr in the query box has been selected by clicking on this element in the periodic table, which is then shown in highlighted form in the periodic table. Clicking again on the same element can then be used to de-select that element -i.e. clicking on an element toggles between selecting and deselecting the element. Clicking on the "only selected elements" button filters out materials that contain additional elements (beyond those specified for the query).

(It will be appreciated that "clicking on" represents an appropriate action for a laptop or desktop system provided with a mouse having at least one button, which will be assumed for the discussion of Figure 4; however, as known to the person skilled in the art, other computing platforms may use a different action as appropriate to select an element -for example, touching a displayed element if the device being used has a touch screen).

Note that when elements are selected from the periodic table in this manner, the query box auto-populates with the selected elements (the same auto-population applies when using any other facilities in the search pane to enter some or all of a query). Underneath the period table is a row comprising four standard Boolean operators, namely AND, OR, XOR and NOT. These operators can be used to formulate more complex (and precise) queries. For example, by specifying "Cl AND Zr" it is indicated that both of these elements (zirconium and chlorine) must be present to produce a positive search result (whereas the search "Cl OR Zr" would only need one of these elements to be present to produce a positive search result).

The Boolean operators in this row are associated with a cursor which can then be used to select elements for entry into the query box on the basis of the specified Boolean operator. Thus if the user selects the AND cursor, and then selects an element (such as Mg) from the periodic table, the condition AND Mg is appended to the query. Similarly, if the user had selected the OR cursor instead, the condition OR Mg would have been appended to the query. Again, it will be appreciated that a user may also enter a desired Boolean operator directly into the search string in the query box at the top of the search pane.

Four additional search collapsible bars (drop-down boxes) are located below the row of Boolean operators and may be used for entering further parameters for the search, in particular relating to the structure of the material, the unit cell, diffraction patterns, and bibliography. These collapsible bars therefore act as potential filters on the search results (somewhat akin to the attributes filters of Figures 3A-3C, although the filters of Figure 4A may support more complex query formulations than the binary attribute filters shown in Figures 3A-3C). These collapsible bars have not been activated in the example screen of Figure 4A (except for the selection of the bibliographic year range).

Figures 5A and 5B show examples of the collapsible bars relating to a unit cell and bibliography respectively in expanded form (compared with the compressed or collapsed version of Figure 4A). The Unit Cell parameter search bar shown in Figure 5A enables the user 50 to search and select database entries based on their unit cell parameters by entering the three lattice constants (a, b and c in Angstrom units) into three text boxes at the top of the search bar, and the three lattice angles (alpha, beta and gamma) in three text boxes below, along with a specified tolerance. The lattice type is specified by clicking on the relevant lattice type letter: P, A, B, C, I, F and R. The Bibliography search bar of Figure 5B enables the user 50 to include bibliographic information in the search expression. The author name can be entered into the Author text box and the journal can be selected by entering the relevant 6-character code into the CODEN box (a box may also be provided for searching for the complete journal name). A range of years can be selected in the slider bar at the bottom of the collapsible bar to specify a range for the publication year, or alternatively the publication year (or year range) can be entered directly into a text box.

As noted above, the search parameters entered into the collapsible bars shown in Figures 5A and 5B may then auto-populate the query box at the top of the query pane. Alternatively, some or all of these search parameters may be directly entered into the query box (as has occurred for the date range specified in Figure 4A).

At the bottom of the search pane is a tick-box to indicate that coordinates are required (when the box is ticked, as shown in Figure 4A). Note that this tick-box operates in a similar manner to the attributes of Figures 3A-3C, and requires coordinates to be available for a positive search result (the coordinates relate to information regarding the locations of atoms in the relevant material or compound).

Figure 4B shows an enlargement of the results pane of Figure 4 and corresponds in general terms to pane 312 in Figures 3A-3C (the navigation bar shown in Figure 4 below the results pane is omitted from Figure 4B). A search may produce 0,1 or multiple results (hits). The list of results is shown in the middle (results) pane of the user interface 110. An export button located at the bottom right of the results pane allows the list to be exported, for example as a csv (comma-separated variable) file.

Accordingly, the results pane displays the items (hits) in the search domain that satisfy the query currently entered in the query pane. In the example of Figure 4B, each hit corresponds to a material or compound. For the particular search of Figure 4A, there are 643 hits (as noted at the top of the results pane), which is too many to be visible in the results pane of Figure 4B all at the same time. Accordingly, the results pane is provided with a scroll facility to move up and down the list. In the example of Figure 4B, this scroll facility comprises a scroll bar and associated scroll box which are located along the right-hand edge of the results pane. By operating the scroll facility in an appropriate manner (such as described above in relation to Figures 3A and 3B), the user is able to scroll up and down through the listing of hits that has been output by the search engine 130 in response to the input query. The results pane therefore represents a list or sequence of hits. The ordering of the list may be configurable by the user, for example, to reflect the relevance or date of the hit; likewise, the direction of the ordering may be configurable by the user, for example, whether the oldest hits are first or last in a list ordered by date.

As shown in Figure 4B, each hit in the results pane may be represented by a standard set of information or parameters relating to the material of compound of that particular hit. In Figure 4B, each hit is summarised by three components presented together in a row, such that the list comprises multiple rows, each row corresponding to one hit. The first component in the row is a small structure diagram for the compound (e.g. a thumbnail image). The second component in the row is a set of information relating directly to the hit, including an identifier for the compound On the database being searched), the formula of the compound, information about the structure type of the compound, information about the space group of the compound (see har,,,plfen orikipgdia or/wild/Space group), and information about the Pearson symbol of the compound (see httositertwikioeda,orglwiki/Pearson symbo). The third component in the row relates to a paper cited for the compound, and provides a journal code, the year of publication, and the authors of the paper.

It will be appreciated that the information available for (and/or relevant to) the hits is dependent on the search domain which is being searched, and will therefore be configured accordingly for any given implementation of the computer search system 100. Furthermore, in some implementations, a user may be able to configure the information and parameters provided in the results pane and/or the arrangement of this information.

Figure 6A provides an example of such an alternative arrangement. The results pane is therefore considered to be a multi-appearance panel, since different arrangements or views are available. A user can switch between these different views by selecting (e.g. clicking on) a corresponding one of the view buttons provided at the bottom left of the results pane (these view buttons are not shown in Figure 4B). In the example implementation, the leftmost button is used to select a list view such as shown in Figure 4B, the left and right middle buttons are used to select a 2-dimensional and 3-dimensional graph view respectively (the latter being depicted in Figure 6A), and the rightmost button is used to select a spreadsheet view.

Accordingly, the buttons at the bottom left of the results pane can be used to transition between different views of the search results. For example, the list view of Figure 4B contains various pieces of information for each hit in the results pane. In contrast, the spreadsheet view may be used to provide a shorter but more compact set of parameters, for example, with one line per hit (thereby allowing more search hits to be visible at the same time in the results pane).

Note that both the list view and the spreadsheet view show a listing, i.e. a one-dimensional ordering of the search results. In contrast, the 2-0 and 3-D views provide a multi-dimensional representation of the search results. It will be appreciated that the user is able to select a view which is best-suited for the particular task at hand.

As discussed above in relation to Figures 3A-3C, a search hit in the results pane can be selected and the corresponding detailed content is then displayed in the content pane. In some implementations, if no search hit has been selected, the content pane may be empty, or may (for example) display the content associated with the first search hit in the list view of the results pane. A selected search hit may be visibly distinguished from the remaining search hits, for example by highlighting or changing the background.

Figure 4C shows detailed content for search item 504242, which is the first hit in the list of search results provided by the results pane of Figure 4B (the content for the first hit in a list of search results may show by default in the content pane of Figure 4C if no search result has yet been explicitly selected by the user in the results pane). As described above in relation to the results pane, the content pane provides a multi-appearance panel, in which different views such as shown in Figures 6B and 60 can be obtained by selecting (e.g. clicking on) different view buttons located in a row at the bottom left of the content pane (as above, the view buttons are omitted from Figure 40 but are visible in Figures 68 and 60). The view of Figure 40 corresponds to the details button to the left of the row of view buttons. In addition, and again similar to the results pane, an export button is located at the bottom right of the contents pane.

This export button allows the content for the selected search result to be exported (the export button is also omitted from Figure 4C, but visible in Figures 6B and 6C).

The content pane of Figure 40 and Figures 6B and 60 may include a scroll facility (such as discussed above in relation to Figures 3A-3B for the results pane 312) for use if there is space to only show some of the content for the selected search result in the contents pane at any given time. This scroll facility is shown in Figure 6C where it is used for navigating the X-ray diffraction pattern (no such scroll facility is shown for Figures 4C and GB).

As shown in Figure 4C, the information in the content pane typically expands upon the more concise information available in the results pane for the selected search result. In particular, the content of Figure 4C includes firstly a set of information about the search result (similar to that provided in the results pane as the second component of each hit). In particular, this information includes an identifier for the compound On the database being searched), the formula of the compound, information about the structure type of the compound, information about the space group of the compound, and information about the Pearson symbol of the compound. The next item in the content of Figure 4C is a structural diagram of the search result (similar to that provided in the results pane as the first component of each hit, but more detailed and larger). In some implementations, the content pane may support manipulations of this structural diagram, such as enlargement (zoom), rotation, and so on. Below the structural diagram is information on the cell dimensions for the compound of the selected search result, some general remarks about this compound, followed by details concerning publications and authors relevant to the material. Overall, the material provided by the content view can have a mixed format, for example, a combination of two or more of the following: text, 2D and 3D diagrams, images, graphics, etc. Apart from the Details view as shown in Figure 4C, the view buttons in this implementation provide access to the following views: *Coordinates -this displays a table with the columns having various information for the selected compound (material), such as Atom, Wyckoff symbol, site symmetry, and X, Y, Z positions.

Figure 6B shows an example of the Coordinates view.

"Geometry -this details the environment of different atom types within the structure in relation to one another.

*Visualisation -this allows a user to customise a 3D visualisation of a compound, including choosing viewpoints, zoom and so on.

*Powder Pattern -this plots a powder diffraction pattern for the selected compound. Figure 6C shows an example of the Powder Pattern view (as discussed in more detail below).

"Missym -this displays higher level structure symmetry in the selected compound.

(It will be appreciated that this set of views represents an example for this particular implementation -other implementations may provide different views appropriate to the particular search domain of a given implementation).

The Powder Patterns view of Figure 6C plots a powder diffraction pattern for the selected compound. At the top of the view the selected compound ID is displayed (504242), which corresponds again to the selected search result from the results pane. Above the diffraction pattern plot, the user can select the radiation source from a drop-down menu list (e.g. Cu, Mo, Fe, Cr, Co, Ag, Neutron and Synchrotron) that is used to derive the powder diffraction pattern. Selecting Cu, Mo, Fe, Cr, Co and Ag will auto-populate the wavelength text box as appropriate.

In the middle of the view is a plot of the resulting diffraction pattern. A combined zoom and panning bar below the plot allows the user to zoom in/out on the x-axis of the plot and pan along the axis. Clicking on and dragging either end of the bar to make the bar shorter increases the zoom magnification. Clicking on and dragging the centre of the bar allows the user to select which zoomed in portion of the x-axis is displayed. (The y-axis scale remains unchanged when zooming and panning on the x-axis). The centre position of each peak is marked below the plot. If a user clicks on a peak, the 2-theta value, intensity value and the peak hkl Miller index are displayed. An export button allows the user to export the plot, for examples as a png graphics file. The lower section of the Powder Pattern view displays a table of peak details. The columns displayed are Peak number, hid Miller indices, 2-theta value, d spacing value and the peak intensity value (max peak = 100). Below the table is another export button that allows the user to export the table data as a csv file.

As described herein, the user interface 110 of computer search system 100 therefore provides a three-panel design that allows multiple user interface panes to be presented alongside each other simultaneously. This has the benefit that the user does not have to navigate through multiple screens to perform common tasks. For example, when searching for a compound, the search terms, the list of the results and the detailed content for the selected item are shown in vertical panes or columns which are displayed side-by-side, such as illustrated in Figure 4. As a result, when changing search terms (i.e. updating the query), or retrieving detailed information (content) about a compound, the user 50 does not have to navigate between different screens.

Figure 7 is a high-level schematic diagram of a computer search system 100 as described herein. Figure 7 incorporates the components of the computer search system of Figure 1 (for clarity, user 50 is omitted), but also includes various components of the computer platform on which the computer search system 100 is implemented. Although these components of the computer platform are known per se and are provided by many conventional computers such as laptops, desktop machines, etc., the approach for implementing the computer search system 100 on the computer platform as described herein is believed to depart from known systems.

The computing device includes a processor 710 which executes software (program) instructions to perform the processing described herein. The processor 710 may include multiple processing cores which support parallel lines of execution. It is also possible for the computing device to have and utilise multiple processors.

The computing device further includes memory 720 (also referred to as main memory), which is generally provided as random access memory (RAM). Program instructions to be performed by the processor 710 are stored in the memory 720, likewise data that is being operated on by such program instructions. The computing device will generally include at least one cache. A cache is an additional piece of memory that is smaller but faster than memory 720 and is used to provide the processor with a local copy of a subset of the data in memory (the data being cached may include both operands and operators). The processor 710 can access this local copy more quickly than memory 720 itself, and so the use of the cache helps to improve performance. Various caching algorithms are utilised to control which subset of the data from memory 720 is located in the cache -typically the cached data comprises data which is being most frequently used by the program executing on processor 710. For present purposes, for data which is described as being held within memory, it will be understood that such data may also be held within the cache (and the cache may potentially have a more up-to-date version). The computing device further includes storage 730, which is typically implemented as a hard disk drive and/or solid state (e.g. flash) memory. Storage 730 is also used, like memory 720, for holding data. However, whereas memory 720 is generally volatile (it does not maintain state in the absence of power), storage 730 by contrast is non-volatile (it does maintain state in the absence of power). In addition, memory 720 is accessed by the processor 710 directly using the address space of the processor 710 (subject to any virtual memory implementation), whereas the processor 710 cannot directly address storage 730. Accordingly, in functional terms, the memory 720 can be regarded as providing a working memory for holding data in a short-term fashion to support the current operations of processor 710, whereas storage 730 provides longer-term storage of data irrespective of when or whether such data will be used again by processor 710. Indeed, if the processor wants to utilise data from storage 730, this data must generally be loaded first into memory 720 before it can be accessed by the processor 710. The above functional differences are reflected in storage 730 usually having a much larger capacity than memory 720 but with a slower access time (much slower for a hard disk drive).

The computing device further includes a graphics card 740. Higher end machines, or machines aimed at graphics applications, have a separate graphics cards, such as GeForce cards from NVIDIA (www.nvidia..com). The graphics card 740 is usually provided with a set of graphical processing units (CPUs) and other associated hardware and software to support rapid rendering of graphics, e.g. for computer gaming, thereby achieving much higher graphical performance than could be achieved using processor 710 by itself. In lower end machines, the graphics card may be integrated onto the main processor board in order to reduce cost, albeit with sometimes lower performance. The computing search system 100 described herein is generally intended for use in a computing device including a separate graphics card 740, however, an integrated graphics facility can also provide a viable implementation (see the examples in Table 1 below).

The computing device further includes a display device 760 and at least one input device 770. The display device 760 is typically an LED or LCD screen which may be integrated into the computing device (such as for a laptop or tablet) or included as a separate component (sometimes termed a monitor). The input device(s) 770 may include a touch screen, a mouse with buttons, a trackpad, a joystick, a keyboard, a microphone for voice control, and so on.

The computing device further includes at least one network interface 750 which allows the computer search system 100 to communicate with external systems over one or more communication networks. For example, the network interface may provide connectivity over a wired or wireless local area network (LAN), over a telephone network (such as 4G or 5G), and so on, thereby supporting data communications, e.g. with Internet locations or other remote systems. The network interface 750 may be used for example to update as appropriate the data 140 in the computer search system 100 (manually and/or automatically).

The computing device further includes software components including the operating system 780 and a graphics API 790. The operating system 780 provides a platform for applications running (executing) on the computer system, for example allocating resources between different applications and maintaining security of data between applications. The graphics API 790 provides an interface to the graphics card 740. Commercially the two most commons graphics APIs are DirectX (from Microsoft) and OpenGL (httpsitopengl.orql).

A current implementation of a computer search system as described herein has been run on a number of different computing devices, including two detailed in Table 1 below: Machine HP Pavilion Desktop -TP01-0125xt MacBook Pro (13-inch, 2018) Operating System Processor Graphics Card Windows 10 (64 bit) Intel Core i5-9400 Integrated: Intel UHD Graphics 630 Bootcamp running Windows 10 2.3 GHz Intel Core i5 Intel Iris Plus Graphics 655 1536 MB Memory 8 GB DDR4-2666 SDRAM Memory 8 GB 2133 MHz LPDDR3 Storage Disk: 1 TB 7200 rpm SATA Solid state: 256 GB PCIe NVMe M.2 Macintosh HD

Table 1

It will be appreciated that these two computing devices are identified merely as an illustration of potential implementations for the computer search system of Figure 7, and the skilled person will be aware of many other computing devices that could also be used.

The components of Figure 1, in particular the user interface 110, the graphics engine 120 and the search engine 130, are provided as components of a computer search application running on such a computer device or platform as described above. In one particular implementation, the components are generally written in the C++ programming language and utilise OpenGL as the graphics API 790, however other implementations may use other programming languages and/or another graphics facility as appropriate. Moreover, it will be appreciated that the above description of a computing device as shown in Figure 7 is given by way of example only, and without limitation for the specific platform on which the computer search system 10018 implemented. In particular, the skilled person will be aware of many variations and potential modifications of such computer devices (both current and future) that could be used as a platform for the computer search system 100 described herein.

As mentioned above, an important aspect of the computer search system 100 is real-time operation and response for a user 50, such that there is little or no apparent delay (latency) between a user entering a search command into the user interface and the user interface display being updated in accordance with the search command. This real-time operation is supported by various features of the computer search system 100.

One such feature is the use of lookup tables containing pre-computed search results. In one implementation of these lookup tables, for each available search criterion we define a corresponding bit map, where each bit of the bit map is associated with a respective data item in the search domain, and denotes whether or not that data item satisfies the search criterion. For the example database shown in Figures 4-6 of inorganic compounds, each element can be considered as a search criterion and therefore has its own bit map. In other words, a lookup table has a bit map for hydrogen (say) in which the nth bit in the bit map is set to 1 if the nth compound contains hydrogen and 0 if the nth compound does not contain hydrogen. (This implies some ordering of the data items, however this can easily be provided by allocating each data item a unique identifier, such as has already been done for the database of compounds shown in Figure 46). Likewise, there is also a bit map for iron (say), where the nth bit in the bit map may be set to 1 if the nth compound contains iron and 0 if the nth compound does not contain iron#, and so on for other elements.

This use of bit maps directly supports looking for combinations of elements. For example, if the search query is for compounds that contain both hydrogen and iron, but not oxygen, this can be readily determined by negating (inverting) the bit map for oxygen, and then performing a bitwise three-way AND operation between the hydrogen, iron and negated oxygen bit maps. The resulting bit map will then have 1s for those compounds that satisfy the three criteria (hydrogen, iron, and not oxygen). For example, if the first bytes of the relevant bit maps are hydrogen (00111000...), iron (11011010...) and oxygen (00101010...), the first byte of the resulting bit map is (0001000...). Thus only the fourth compound (out of the first eight in the set of compounds) satisfies all three specified search conditions.

This approach can be readily extended to searching for other attributes or parameters of database items, such as crystal size, crystal structure, optical properties and so on. In some cases, these search criteria can be readily expressed as a binary (yes/no) option and so directly represented in a bit map. In other cases, a search criterion might have a different format -for, example, a date range of publication. It may be feasible for some of these ranges to be broken down into a sequence of binary parameters -e.g. for a date range, a bit map might be provided for each year, so that looking for publication between 1992 and 1995 could be implemented as (1992 OR 1993 OR 1994 OR 1995).

For some search criteria, the bit maps may be very sparse (mainly Os). For example, in the compound database, which has approximately a million entries (compounds), there may be a set of authors associated with each entry, however, any given author might typically be associated with at most a few compounds -so only a few bits in the bit map would be non-zero.

One way of handling such a sparse criterion is to compress the bit maps for such authors, for example using some form of run-length encoding, which would significantly reduce the size of the bit map. A compressed bit map could then be expanded (decompressed) only in response to the user entering a query including the author corresponding to that bit map. (Some implementations may compress all bit maps, but the reduction in size is generally greatest for sparse bit maps).

Another approach for handling authors (or other sparse search criteria) is to provide a lookup table in the form of an index that maps from the search value to the identities of compounds (or other data items) that satisfy this search value. The index (analogous to a conventional index) is ordered for easy access based on the search value, and each entry in the index then identifies the database items that have that search value. For example, if the search criterion is for the authors name "Crane", an index which is alphabetically ordered might be accessed to locate the entry for Crane, thereby allowing the corresponding data items (e.g. compounds) that are associated with this author to be identified and retrieved.

This index approach can also be used to handle numerical ranges. For example, the index may be ordered based on increasing density. To find compounds that have a density which falls in a specified range between a lower and an upper threshold, the index can be accessed to locate the lower and upper thresholds, and the data items falling into the range between the lower and upper thresholds can be identified and retrieved.

An implementation of a computer search system 100 may use lookup tables comprising bit maps, or indices or a combination of both (and/or any other suitable form of lookup table). For example, bit maps may be used to identify a list of search items that satisfy one part of a query, an index may be used to identify a list of search items that satisfy another part of a query, and then the lists are filtered such that only search items which are present on both lists are output as satisfying the query.

One such implementation of searching with the computer search system 100 might involve keyword searching being performed using a bit map as described above for each keyword, whereby the bit map stores a positive bit (1) for each search item that contains the relevant keyword. An index or some other form of lookup table might then be used if it is also desired to record the number of times that a given keyword appears in a given data item (such as to assist in ordering the search results in the results pane 312 by relevance).

The skilled person will be aware of other possible approaches using pre-computed lookup tables to enhance the speed of search processing. In this context, pre-computed implies calculated from the data set 140 prior to receiving user search queries. (The pre-computed lookup tables would generally need to be updated as appropriate if the data 140 in the search domain is subsequently updated).

The computer search system 100 maintains the above lookup tables in memory 720. This is referred to as an in-memory implementation, and benefits from fast access by the processor 710 to memory 720 (compared, for example, with the access time to disk-implemented storage 730). Although in-memory database systems are known, they are generally used in the context of server systems, rather than an individual user system running on a single machine as described herein.

A typical laptop or desktop provides 4 or 8 GBytes of RAM (memory 720). In comparison, for a database (data 140) which contains a million (-220) items for searching, such as the compound database illustrated in Figures 4-6, a bit map as described above would comprise -220 bits or 128 kBytes. This allows 8k (8192) such bit maps to be stored in 1 GByte of RAM. If the compound database has a bit map for each chemical element, this involves about 100 bit maps (one for each element), and only requires -13 Mbytes. This is a very small portion of available memory, and hence an in-memory implementation can be readily supported.

Another aspect of the computer search system 100 to help provide a real-time response concerns the operation of the graphics engine 120, which interacts directly with the graphics card 740 (via graphics API 790) using textured triangles to rapidly display (and update) the user interface 110. Textured triangles display content using a set of triangles, each triangle being defined by a texture, representing an image (e.g. bit map) that is applied to the surface of the triangle, and three vertices (also termed indices) representing the corners of triangle, which can be converted to an on-screen location, size and orientation for the triangle. In other words, the vertices determine the portion of the screen occupied by the triangle, and the texture determines what is visible at this portion of the screen. Each graphical element may be stored at multiple different resolutions, and can be used to generate different size textures.

Textured triangles are commonly used in computer gaming for rendering 3-D objects, with the surface of such objects being defined in terms of textured triangles. In contrast, although the content of the computer search system 100 described herein may include some 3-D objects to be rendered, such as a representation of a chemical structure, much of the user interface is displayed by "flat" content which can be positioned directly on the screen -for example, text, graphical data, 2-D images, graphical user interface constructs such as boxes, buttons, and so on for use with input devices 770. In most applications, such content is normally provided directly to the operating system 780 which is then responsible for displaying the content on an output device 760. In contrast, the graphics engine 120 described herein bypasses the operating system, and creates textured triangles for this content, even for content which would not usually be regarded as graphical output, such as text or mixed format content comprising a combination of text, 2D and 3D diagrams, images, graphics, and so on. It will be appreciated that in this approach many textured triangles can be defined in advance, such as for textual characters, standard elements of a user interface 110 (e.g. check boxes), and so on, thereby reducing the real-time burden on the graphics engine 120. The textured triangles generated by the graphics engine 120 are passed directly to the graphics API 790 (OpenGL in a current implementation), without going through the operating system 780. The graphics API 790 then provides the textured triangles to the graphics card 740 to output the user interface 110 to the display 760 (a process known as rasterizafion, which graphics cards are able to perform very quickly).

This manner of providing an updated user interface on the display 760 (including display of the listing of search results and the content of a selected search result as appropriate) can support real-time output with little or no apparent lag. Bypassing the operating system 780 helps to avoids potential delays that may occur therein and also enables the computer search system to retain tighter and more direct control of the output process. In addition, the use of textured triangles, even for textual output and other such screen components, achieves very high performance from the graphics card 740, which is typically designed to use textured triangles to provide very rapid graphics (primarily in the context of computer gaming).

Accordingly, the use of lookup tables helps the computer search system 100 to achieve highly responsive searching, while the use of textured triangles helps the computer search system 100 to update the display output in a highly responsive manner. In combination, these two facilities allow the processing (update) loop of Figure 2 to be performed very quickly, typically within less than one frame period, so the user perceives the updated search results to be displayed in effect immediately after the user updates the search parameters (or search display parameters). This level of responsiveness provides a very different feel (user experience) compared with most current search systems which are not designed (or able) to provide such a real-time update loop.

The responsiveness of a computer search system 100 as disclosed herein is further supported by an architecture which is notably different from many modern search facilities that are based on a client-server configuration, e.g. over the Internet. In such existing systems, the user device (the client) includes a browser or similar software tool. The user enters a search query via the browser which is then passed to the server for implementation. In particular, the server performs the searching of a database associated with the server and returns a set of results. If a user wants the full content for a particular search result, the client must send a further request to the server, with the server then retrieving the requested content and returning this content to the client.

In contrast, the present approach is primarily based on a user interacting with a single (standalone) computing device, such as a laptop, desktop computer or tablet. Most (typically all) of the searching and graphics output for the computer search system 100 is performed on this local computing device (as described above), likewise most (typically all) of the data 140 for the computer search system 100 is maintained on this local computing device. (As noted above, this locally held data 140 may be updated as appropriate using the network interface 150, e.g. using the Internet).

In general, we can consider data 140 as containing three sets of information. The first set comprises the database content, in other words, the full content for each data item in the database, and thus the source of the content as displayed in the content pane 313 for a selected search result. The first set is therefore generally the largest of the three sets of information. The second set of information comprises the lookup tables as described above to support rapid searching. The third set of information comprises a summary of key information for each item in the database, such as shown in the results pane 312. This third set generally comprises key textual parameters and typically one (although possibly more) thumbnail images for each search item. The third set of information is therefore smaller than the first set of information to allow quicker display of the search results in the results pane (prior to the display of the associated content). In some cases, for example for a relatively small database, the third set of information may not be utilised, rather the information for the results pane could be derived directly from the first set of information.

Some or all of the three sets of information may be stored in compressed form, with decompression typically then being performed immediately prior to performing a search. The use of compression/decompression in this manner helps to reduce demands on storage 730 (and potentially saves space in main memory 720), however there is some extra overhead for processor 710 in performing the compression/decompression. Accordingly, the use of compression/decompression (if any) can be tailored to the particular circumstances of any given implementation, e.g. based inter alia on the available processor and storage resources.

The computer search system 100 can have a variety of configurations. In one configuration, the first and second sets of information (and also the third set of information if utilised) are held in-memory. This full in-memory configuration generally provides the best performance, but may not be feasible for larger databases -for example, it may not be possible to accommodate all of a large database in main memory 720. In another configuration, the second set of information is again held in main memory 720, but the first (full) set of information is primarily maintained in storage 730 (the processor may then access portions of this full set of information from storage 730 via memory 720 as per conventional access for a file in storage).

The third set of information, if provided, is also held in main memory. In another configuration, the second set of information is again held in main memory 720, likewise the third set of information, but the first (full) set of information is maintained in part or in full on an external system and is accessed using the network interface 750. Such an external system might be a file server on a local network, or a web server accessible over the Internet, and so on.

In the above configurations, the lookup tables are provided (and retained) in memory 720 in order to ensure rapid searching. The material for presenting the listing of search results is also retained in memory 720 where possible to allow for rapid display of these search results. In some implementations, the content is also stored in memory, however this content may be stored instead on a disk (or other form of local storage 730), or possibly remotely, since although the overall set of content across the full database is large, only content for a single item in the search domain (i.e. the currently selected search result) has to be retrieved and displayed at any given time.

Accordingly, a computer search system 100 uses a local processor to perform a search, and retains the data (input and output) associated with the search as close to the processor as possible. The user interface 110 described herein has been designed to work with and exploit this architecture, with a focus on usefulness (utility), accuracy, usability, speed, clarity and functionality. The user interface 110 helps to ease navigation around the software so that search tasks are intuitive and performed efficiently and effectively. Search actions and their associated display may be performed in real-time, in effect instantaneously from a user perspective, without lag or delay, thereby providing a fast and productive work environment.

Accordingly, the local implementation of the computer search system 100 helps to provide improved responsiveness, such as by avoiding network delays, and also through careful control of various aspects of the search and user interface as described herein. A further benefit of such a local implementation is that the computer search system can be used even in the absence of a network connection, for example, potentially when travelling, or at an on-site (field) location, which may be remote or underground, and so on.

In a current implementation of the computer search system 100, the data 140 which is being searched, i.e. the data items in the search domain, is read only. In other words, the computer search system 100 is used for retrieving, but not updating or deleting data. It will be appreciated that this maintains the integrity of the data set 140 and also helps to simplify the operation of the computer search system 100 -for example, if data items are modified or deleted, then corresponding updates may be required to the lookup tables. Note that even for a read only data set 140, there might still be updates applied in a centralised manner, e.g. by a supplier rather than by individual users. With this approach, the changes can be accumulated into a set of updates, and the lookup tables modified accordingly when such a set of updates is installed. Nevertheless, in some other implementations, the user 50 may be able to modify and/or delete data items in the data set 140.

As illustrated in Figure 4C, the content associated with the searched data items may be heterogeneous in nature, comprising a mixture of different formats or types of data, such as text, 2D and 3D diagrams, images, graphics, and so on. The computer search system 100 described herein is able to quickly display such relatively complex data (such as by using textured triangles as described above). Note that the three-panel display such as shown in Figure 4 is generic in nature, and hence can readily accommodate a wide range of different data types.

It will be appreciated that a computer search system 100 as described herein can be utilised in many different fields, with the search domain defined accordingly. For example, the implementation shown in Figures 4-6 relating to inorganic compounds might be used by chemists, material scientists, and so on. The following represent potential domains of use by way of illustration only, without being limiting or comprehensive: "the data set 140 might be used as part of a mapping application, for example to identify buildings, shops, metro stations, etc., that are in the vicinity of a user. In this context, the current location, such as provided by GPS, might form part of the search query provided to the search engine.

"the data set 140 may relate to the medical field, for example, pharmaceuticals or diseases and illnesses. Clinicians might use the former to search for drugs appropriate to a given condition, or the latter to help diagnosis and development of a treatment plan.

"the data set 140 may relate to an engineering field, for example, detailing components and structures in a major engineering work, such as a large building (or complex of buildings), bridge, railway, ship, aeroplane, and so on. In this context, the computer search system 100 might be used by architects, maintenance staff, engineers, crew, and so on.

"the data set 140 may represent a product, and the computer search system 100 might be used, for example, to demonstrate and locate particular products of interest to distributors, resellers, franchisees, major customers, and so on.

"the data set 140 might represent a heritage/culture application, such as to allow a user to search an archaeological site or museum collection -for example, a user may be provided with a list of objects or buildings visible from the current location of the user (which might be determined by GPS or in any other suitable manner).

It will be appreciated that various aspects of a computer search system 100 as described herein will be of advantage in many of the above example domains. For example, the ability to use a standalone (and typically portable) computing device without requiring a network connection allows the computer search system to be deployed in the field, e.g. onsite at a civil engineering location. In addition, in the medical field, the high responsiveness may help to support a quicker diagnosis and identification of a potential treatment.

An implementation of a computer search system 100 as described herein may be configured to perform a search query to generate search results and to provide a user interface including a first panel configured to receive as user input a search query and to display the received search query in the first panel. The user interface may further include a second panel configured to display search results obtained by performing the search query input to the first panel and to receive as user input a selection of a search result from the search results displayed in the second panel. The user interface may further include a third panel configured to display content associated with the selected search result. The user interface is configured to display the first, second and third panels together in a single view.

Utilising a single view in this fashion directly allows a user to perform faster searches by avoiding transitions between different screens as a user analyses the search results. Moreover, providing a single overview that includes the search query, search results and also selected content helps a user to better comprehend the search domain, thereby supporting the identification of results which are more relevant to the user (whereas without such an overview, a user may take longer to locate relevant results, or may struggle to find them at all).

In some implementations, the first, second and third panels have a sequential arrangement in the single view, with the second panel being located between the first and third panels. Such a sequential arrangement reflects the workflow sequence of entering the search query (first pane), receiving the search results and selecting a search result (second pane), and displaying the content for the selected search result (third pane), thereby providing a more intuitive configuration for the user. However, other implementations might adopt a different arrangement if so desired, such as having the first panel top left, the second panel top right, and the third panel across the bottom.

In some implementations, the first panel is displayed to the left of the second panel and the third panel is displayed to the right of the second panel. This reflects a natural direction for the sequential flow mentioned above, especially for users who are familiar with reading from left to right. However, other users who are familiar with reading in the opposite direction might prefer the positions of the first and third panels to be reversed. Furthermore, if a (hardware) display screen is provided in a portrait orientation, then it might perhaps be appropriate to have the panels in a top-down arrangement, with the first panel on top, the second panel in the middle, and the third panel at the bottom. Other arrangements may be adopted according to the circumstances of any given implementation.

In some implementations, the first, second and third panels are rectangular in shape. Note that such panels can abut one another (tesselate) to avoid gaps and make the best (most efficient) use of available screen space. However, other implementations may prefer to adopt a different shape for one or more of the panels.

In some implementations, the single view generally occupies substantially all of a hardware display screen. (For a computer search system running in a windowed environment, it is assumed here that the relevant window for the computer search system is maximised). It will be appreciated that some other components may still be available (visible), such as a task bar, tool bar, ribbon, and so on. However, it can seen from Figure 4 that the single view depicted therein occupies a large majority (more than 75%, typically more than 90%) of the available screen space.

In some implementations, at least one of the results panel and the content panel is a multi-view panel, whereby the user interface supports switching between different material associated with the search results (for the results panel) and/or between different content material for a selected search result (for the content panel). Although such switching between views might be seen as a form of screen transition, it will be appreciated that in many cases the user may select a view from the results panel and/or the content panel that is most relevant to the current search (and the purpose thereof), and then generally maintain this view while analysing the search results. In this context, the multi-view panel may act less as a navigation tool but more as a facility to configure the output parameters. It will be appreciated that in some implementations, the query pane may directly support a user selecting the output information from a query -i.e. what information to include for the search results displayed in the results panel, and/or what information to include for content displayed in the content panel for a selected search result.

In some implementations, the second panel may include a scrolling facility for scrolling through the search results, the scrolling facility being distinct from the search results. Thus the number of search results may be too large to be all shown together in the second panel, and the scrolling facility therefore provides a mechanism to view different results within the overall set of search results (without having to transition between different screens). The scrolling facility is additional to the search results per se in that the scrolling facility is provided as a user interface component (rather than simply navigating while inside a given document or list). For example, the scrolling facility may be a scroll bar with a scroll box and arrow buttons located along the right-hand edge of the panel, clearly distinct from the search results per se.

In some implementations, the user interface is further configured such that using the scrolling facility to scroll through the search results at the same time scrolls which result is selected. In other words, a given search result may be initially selected, and typically high-lighted in some suitable manner (e.g. by changing the background or making bold). When the scrolling is performed using the scrolling facility such as to review down through the list of search results, the selection of a search result also changes with this scrolling, i.e. the selected search result moves down the list of search results in corresponding fashion to the scrolling moving down this list (as shown in the transition from Figure 3A to 3B).

In response to such scrolling of which search result has been selected in the second panel, the user interface is configured to update automatically the corresponding content displayed in the third panel. This allows the user to browse not only up and down the list of search results in the second panel, but also through the content associated with such search results in the third panel. This can help a user to identify a search result and associated content of interest more quickly and efficiently (compared with just browsing/scrolling the search results per se, without having updated access to the corresponding content).

In some implementations, the computer search system is further configured to update, as appropriate, search results displayed in the second panel and content displayed in the third panel in response to user input to the first panel to update the search query. This updating generally occurs automatically and in real-time, thereby providing a highly responsive system. The updating can be seen as going through a processing loop of updating the search by a search engine to obtain updated search results and then updating the user interface by a graphics engine to show the updated search results. The cycle rate (frequency) for this loop is arranged to be comparable with the refresh rate for the display device on which the user interface is being displayed -for example, the cycle rate is at least 25%, typically at least 50%, sometimes at least 100% of the refresh rate of the display device.

In some implementations, the computer search system includes a search engine such as described above for generating the search results in response to the search query. The search engine is also able to update the search results in response to further input from the use. Such an update may change the identity of the search results (i.e. so that a different set of hits or matches is obtained), and/or change how the search results are displayed, for example, by changing the ordering of the search results, or the particular material displayed for each search result.

In some implementations, the computer search system includes precomputed lookup tables for use in determining search results in response to a search query. Such lookup tables help to provide a rapid determination of the search results (including of updated search results) and so support the real-time responsiveness of the computer search system. By way of example, the precomputed lookup tables may comprise bit maps and/or indices containing information that assist in the quick determination of search results. The precomputed lookup tables may be retained in memory during operation of the computer search system. This helps to ensure rapid access by the search engine to the precomputed lookup tables, which further helps to support the real-time responsiveness of the computer search system.

In some implementations, the computer search system further includes a graphics engine such as described above for generating the single view for display by the user interface. The graphics engine may be configured to use textured triangles for generating the single view. This generally involves defining all elements for display on the user interface as triangles, with each triangle being defined by the vertices of the triangle and a texture (image) to be applied to the surface of the triangle. Textured triangles are supported by graphics cards, especially in the context of computer gaming, and so help provide very rapid display (even though search results have not traditionally been seen as the type of content for which such rapid real-time display might be provided). Furthermore, the graphics engine may be configured to directly access a graphics card via a graphics application programming interface (API), bypassing an operating system of the computer search system. This direct interaction between the graphics engine and the graphics card again helps to ensure very rapid display of the search results and associated content (especially in conjunction with the use of textured triangles as described above). Also disclosed herein is a computer search system comprising a search engine configured to generate search results in response to a search query using precomputed lookup tables which are retained in memory during operation of the computer search system. The computer search system further comprises a graphics engine for generating a user interface for receiving a query and displaying results in response to the query. The graphics engine is configured to use textured triangles for generating the user interface. The graphics engine is further configured to directly access a graphics card via a graphics application programming interface (API) for displaying the user interface, bypassing an operating system of the computer search system.

Such a computer search system is generally capable of providing a rapid, real-time response, which allows a user to perform searching in a highly efficient and effective manner (compared with many conventional search systems). This computer search system may also utilise the three-panel user interface described above to further facilitate search operations by providing a dynamic and responsive overview of the search operation.

In some implementations, during operation of the computer search system, data for displaying search results generated by performing the search query is maintained in memory. In addition (or alternatively), during operation of the computer search system, content associated with items to be searched is maintained in memory or in local storage of the computer search system. Maintaining data and/or content in memory supports rapid access by the processor to this data/content, and so further helps responsiveness of the computer search system. (This is generally also the case for holding content in local storage, such as flash memory or a hard disk drive, rather than having to retrieve the content from a remote server over some form of network). As a measure of responsiveness, the computer search system is generally provided with a display device having a refresh period (typically 1/60 Hz or 1/120Hz). The time taken by the search engine to perform an updated query and for the graphics engine to display updated search results for the updated search query in a computer search system described herein is less than 2 times the refresh period for the display device, preferably less than 1.5 times the refresh period for the display device, preferably less than the refresh period for the display device. In these circumstances, the user is not aware of any perceptible delay between the user specifying an updated search, and the computer search system updating the user interface to display updated search results corresponding to the updated search. (Such performance may be achieved, for example, using the machines specified in Table 1 and the compound database such as shown in Figures 4-6).

The present disclosure further provides a method of operating a computer search system as described above (according to any of the suggested implementations or variations thereof).

Also provided is a computer program comprising program instructions that when executed on a computing device cause the computing device to perform such a method. The computer program may be provided on a suitable storage medium such as described below. The computer search system described herein may therefore be implemented using a combination of hardware and software. The hardware (machine) may comprise a standard, general-purpose computing device, or in some implementations, the hardware (computing device or system) may include more specialised components, such as a graphics card, graphical processing units (CPUs) and so on to facilitate operation of the computer search system. The software generally comprises one or more computer programs, e.g. a computer search application, to run on the hardware.

These computer programs comprise program instructions which are typically loaded into memory of the computing device for execution by one or more processors to cause the computing device to operate as a computer search system as described herein. The computer program may be stored in a non-transitory medium prior to loading into memory, for example, on flash memory, a hard disk drive, etc. The operations of the computer search system may be performed sequentially and/or in parallel as appropriate for any given implementation.

Various implementations and examples have been disclosed herein. It will be appreciated that these implementations and examples are not intended to be exhaustive, and the skilled person will be aware of many potential variations and modifications of these implementations and examples that fall within the scope of the present disclosure. For example, certain implementations may comprise any appropriate combination of the features disclosed herein without limitation to the particular combinations provided by the claims. It will also be understood that features of particular implementations and examples can typically be incorporated into other implementations and examples (unless the context clearly indicates to the contrary). In summary, the various implementations and examples herein are disclosed by way of illustration rather than by way of limitation on the scope of the appended claims.

Claims (25)

1. Claims 1. A computer search system configured to perform a search query to generate search results and to provide a user interface, the computer search system including: a first panel configured to receive as user input a search query and to display the received search query in the first panel; a second panel configured to display search results obtained by performing the search query input to the first panel and to receive as user input a selection of a search result from the search results displayed in the second panel; and a third panel configured to display content associated with the selected search result; wherein the user interface is configured to display the first, second and third panels together in a single view.
2. 2. The computer search system of claim 1, wherein the first, second and third panels have a sequential arrangement in the single view, with the second panel being located between the first and third panels, and optionally wherein the first panel is displayed to the left of the second panel and the third panel is displayed to the right of the second panel.
3. 3. The computer search system of any preceding claim, wherein the first, second and third panels are rectangular in shape and/or abut against one another.
4. 4. The computer search system of any preceding claim, wherein the single view is configurable to occupy substantially all of an application display window. 25
5. 5. The computer search system of any preceding claim, wherein at least one of the results panel and the content panel is a multi-view panel, the user interface being configured to support switching between different material associated with the search results for the results panel or between different material associated with the content for a selected search result for the content panel.
6. 6. The computer search system of any preceding claim, wherein the user interface includes a scrolling facility for scrolling through the search results displayed in the second panel.
7. 7. The computer search system of claim 6, wherein the user interface is further configured such that using the scrolling facility to scroll through the search results at the same time scrolls through which search result is currently selected, and optionally wherein the user interface is configured to update automatically the content displayed in the third panel to correspond to the search result which is currently selected in the second panel.
8. 8. The computer search system of any preceding claim, wherein the computer search system is further configured to update as appropriate the search results displayed in the second panel and the content displayed in the third panel in response to user input to the first panel to update the search query.
9. 9. The computer search system of any preceding claim, further including a search engine for generating the search results in response to the search query.
10. 10. The computer search system of claim 9, further comprising precomputed lookup tables for use in determining search results in response to a search query, and optionally wherein the precomputed lookup tables comprise bit maps or indices.
11. 11. The computer search system of claim 10, wherein the precomputed lookup tables are retained in memory during operation of the computer search system
12. 12. The computer search system of any preceding claim, further including a graphics engine for generating the single view for display by the user interface, and optionally wherein the graphics engine is configured to use textured triangles for generating the single view.
13. 13. The computer search system of claim 12, wherein the graphics engine is configured to directly access a graphics card via a graphics application programming interface (API), bypassing an operating system of the computer search system.
14. 14. The computer search system of any preceding claim, wherein data for displaying search results obtained by performing the search query input to the first panel is maintained in memory during operation of the computer search system.
15. 15. The computer search system of any preceding claim, wherein content associated with items to be searched is maintained in memory or in local storage during operation of the computer search system.
16. 16. The computer search system of any preceding claim, wherein content associated with an item to be searched is read only and/or mixed format.
17. 17. A computer search system comprising: a search engine configured to generate search results in response to a search query using precomputed lookup tables which are retained in memory during operation of the computer search system; a graphics engine for generating a user interface for receiving a search query and displaying search results in response to the search query, wherein the graphics engine is configured to use textured triangles for generating the user interface, and wherein the graphics engine is configured to directly access a graphics card via a graphics application programming interface (API) for displaying the user interface, bypassing an operating system of the computer search system.
18. 18. The computer search system of claim 17, wherein during operation of the computer search system, data for displaying search results generated by performing the search query is maintained in memory and/or content associated with items to be searched is maintained in memory or in local storage of the computer search system.
19. 19. The computer search system of claim 17 or 18, further including a display device having a refresh period, wherein the time taken by the search engine to perform an updated query and for the graphics engine to display updated search results for the updated search query is less than 2 times the refresh period for the display device, preferably less than 1.5 times the refresh period for the display device, preferably less than the refresh period for the display device.
20. 20. The computer search system of any of claims 17 to 19, wherein the user interface includes a scrolling facility for scrolling through the displayed search results.
21. 21. The computer search system of claim 20, wherein the user interface is further configured such that using the scrolling facility to scroll through the search results at the same time scrolls through which search result is currently selected.
22. 22. The computer search system of claim 21, wherein the user interface is configured to update automatically the displayed content corresponding to the search result which is currently selected in the second panel.
23. 23. A computer search system as defined in any of claims 1 to 8 and as further defined in any of claims 17 to 22.
24. 24. A method of operating a computer search system configured to perform a search query to generate search results and to provide a user interface, the method including: receiving as user input a search query into a first panel of the user interface; displaying the received search query in the first panel; displaying in a second panel search results obtained by performing the search query received into the first panel; receive as user input a selection of a search result from the search results displayed in the second panel; and displaying in a third panel content associated with the selected search result; wherein the user interface is configured to display the first, second and third panels together in a single view.
25. 25. A computer program comprising program instructions that when executed on a computing device cause the computing device to perform the method of claim 24.