WO2022084454A1

WO2022084454A1 - Searching using electronic devices

Info

Publication number: WO2022084454A1
Application number: PCT/EP2021/079226
Authority: WO
Inventors: Christopher Iain Johnston; Krzysztof GOLYZNIAK
Original assignee: Liberty Labs Ltd
Priority date: 2020-10-23
Filing date: 2021-10-21
Publication date: 2022-04-28
Also published as: GB202016895D0; EP4232920A1; GB2601473A

Abstract

A method of presenting search results on a user's device comprises: determining that a trigger event has occurred; generating a query based on the trigger event; sending the query to a first suggestion engine; receiving from the first suggestion engine a first plurality of search term suggestions generated responsive to the query; sending a first search term suggestion to a first search engine; receiving from the first search engine a plurality of search results generated based on the first search term suggestion; displaying a selected search result on the user's device; sending the query to a second suggestion engine; receiving from the second suggestion engine a second plurality of search term suggestions generated responsive to the query; and displaying a selected search term suggestion on the user's device.

Description

SEARCHING USING ELECTRONIC DEVICES

Web searching is a very common way to navigate the internet. In known methods of performing a search, the user enters a search term (a search word or search phrase) into a search bar. As the user enters the search term, a list of auto-completed search suggestions may be displayed to the user. The user then either selects one of the auto-completed search suggestions, or sticks with their own text and initiates the search (for example, by pressing a “search” button). The search term is then sent to the search engine, which generates a list of search results. These search results are then displayed on a search engine results page (SERP) to the user. The main component of the SERP is the listing of results that are returned by the search engine in response to the search query. The user then selects the link corresponding to their desired website, and the desired website is displayed to the user. Known search engines therefore take users on journeys, and these are used to monetize the user or harvest their data.

The following example illustrates a conventional search process. In the example, the user wants to visit the Nike website. They tap in “NIK”. This search text is sent to an autosuggest application programming interface (API) which returns a list of an auto-completed search suggestions including “Nike”. The search suggestions may for example be based on statistical data, individual user’s profiling data, previous queries in particular, or historical data of visited websites. The user taps “Nike” in the list of auto-completed search suggestions. They are then taken to a search engine results page. As well as non-sponsored links, the SERP includes sponsored links i.e. pay per click (PPG) or cost per click (CPC) links. For example, the SERP returned for “Nike” includes sponsored links for companies that are willing to sponsor the word “Nike” in the search engine. This list will include Nike, but also potentially stockists or competitors, such as Adidas, NB, JD Sports etc. The user then taps on “Nike” for the second time or chooses a Nike stockist or competitor. The user then ends up at the chosen website. When the user taps a sponsored link a PPG or CPC fee is levied against the ad sponsor; the amount of the fee will depend on an auction process based on the digital profile of the user. The user is taken to the search engine results page to allow time to conduct a behind-the-scenes auction of the prospective advertising results based on the user’s perceived interests and spending potential inferred from the available profile data of the user, and to increase the digital real estate to push sponsored links or ads. This journey is a detour purely for monetization, and unnecessarily delays the user reaching non-commercial links. A more efficient journey would be to go from search term to website in one tap.

The current approach is therefore not necessarily favourable to the user. This is particularly evident when the user is conducting a search on a mobile device, due to limitations in screen display size, and device power capacity. Moreover, this multi-stage journey is often unjustified considering the fact that user profile data, including real-time activity data, as well as algorithmic methods are readily available that allow to determine, with high probability, which search result the user is going to select.

It is desirable to provide augmented search functionality which reduces the number of screens that a user is faced with, in order to streamline the search process. It is desirable to provide augmented search functionality which reduces the number of screen changes, clicks or taps the user needs to undertake to make a search in a browser, app, computer program etc. It is also desirable to provide augmented search functionality which allows the user the option of their data not being monetized.

It is also desirable to provide augmented search functionality which can work alongside a user’s preferred search engine.

It is also desirable to provide augmented search functionality which is more appropriate for use within a mobile device environment, for example. Users of mobile devices generally are more accustomed to navigating with icons, rather than with long-form text links. Navigation via long-form text links can be made more difficult when using the mobile device on the move, as is common. The problem stems from the fact that browsers and search apps have been placed onto mobile devices by simply porting across the functionality which was originally designed to be used from desktop PCs for example, without any contextualisation around the new environment of the mobile device.

It is also desirable to provide a user with a search result as soon as possible, with minimal input from the user.

A first aspect of the invention provides a method of presenting search results on a user’s device, comprising: determining that a trigger event has occurred; generating a query based on the trigger event; sending the query to a first suggestion engine; receiving from the first suggestion engine a first plurality of search term suggestions generated responsive to the query; sending a first search term suggestion (or plurality thereof) selected from the first plurality of search term suggestions to a first search engine; receiving from the first search engine a plurality of search results generated based on the first search term suggestion; selecting a search result (or plurality thereof) from the plurality of search results for display on the user device; sending the search result for display on the user device; sending the query generated on the basis of the trigger event to a second suggestion engine; receiving from the second suggestion engine a second plurality of search term suggestions generated responsive to the query; and sending a search term suggestion of the second plurality of search term suggestions for display on the user device. A plurality of search results may be displayed on the user device. A plurality of search term suggestions may be displayed on the user device.

Some of the foregoing method steps may be carried out in parallel. For example, sending the query generated on the basis of the trigger event to the first suggestion engine and sending the query generated on the basis of the trigger event to the second suggestion engine may be carried out in parallel, with the subsequent steps following each of those steps also being carried out in parallel. Thus, the ordering of the steps set out above does not necessarily imply the exact time-ordering that the steps are carried out in.

The search result(s) displayed on the user device may link directly to the relevant resource. Therefore, if the user selects (for example, by tapping or clicking) a search result displayed on the user device, the user is taken directly to the relevant resource which the search result links to, without the user seeing a SERP. Embodiments of the invention therefore provide the user with a quicker and more intuitive search process. Embodiments of the invention can reduce the number of taps or clicks the user must perform in order to get to the resource they wish to view.

The search suggestion(s) displayed on the user device may link to a SERP generated on the basis of that search suggestion, the SERP being provided by a second search engine. The second search engine may be associated with the second suggestion engine.

From the foregoing, it will be clear that embodiments of the invention allow for selected search results (which give the user direct access to the target resource) to be displayed alongside classic autosuggest entries (search suggestions) which lead to SERP pages from a search engine.

The steps taken to arrive at the search results to be displayed can be thought of as steps that are taken to anticipate a user’s intent (i.e. to forecast the resource that they are trying to reach), and react to the intent by providing a direct link which has a high probability of being the user’s intended target resource. For this reason, the software configured to carry out the foregoing steps is referred to herein as an “Intent Engine”, and the search results which are displayed to the user are referred to as “intent-based” search results.

The concept behind Intent Engine is that it kicks in to gauge intent from the user in advance and gives them a limited number of search results (which are preferably the most relevant results) which, in the classic approach to searching, would be found within a SERP. Advantageously, the results may be presented as early as possible, for example without waiting for extensive input.

Since the intent-based results are provided alongside classic search suggestions, a dual-search offering is provided, corresponding to a traditional search engine and a search augmentation which offers the user a way to get to their intended resource in fewer clicks or taps, without the marketing noise associated with SERPs. The Intent Engine provides search results to the user alongside the search suggestions which would usually be provided to the user in a typical search utility or app; thus the Intent Engine is intended to work alongside the user’s preferred search engine, rather than replacing it.

In such an dual-search environment, the user has the option to:

1. Go straight to a resource represented in the search results from the first search engine; or

2. Go to a search engine results page based on one of the plurality of second query suggestions from the second search engine.

Where the trigger event is input of a search query into a search field by the user, a third option is possible, namely the user can go to a search engine results page based on the user- entered search term (for example, by selecting “search”/”enter” or similar).

In each of the following steps, the Intent Engine may use knowledge of the user (user information) to inform the process to more precisely determine the user’s target resource. determining that a trigger event has occurred and generating a query based on the trigger event

The trigger event may be an explicit trigger or an implicit trigger. Here, an explicit trigger is a user-generated trigger, i.e. generated by an action of the user indicating that a search should be performed. An implicit trigger is one which is not user-generated as such, and instead may be inferred from the user’s environment and present activity or inactivity, or from user profiling data including for example the user’s past activity or circumstances. Implicit triggers may also be inferred from the past activity of other users. Triggers may be characterised as events which allow to gauge a user’s intent. sending the query to a first suggestion engine

The method may include the step of determining a suitable first suggestion engine to send the query to, on the basis of known information concerning the user. The query may be sent to a plurality of suggestion engines, each being labelled a “first” suggestion engine. sending a first search term suggestion selected from the first plurality of search term suggestions to a first search engine

The selection of a first search term suggestion to send to the first search engine (selected from the first plurality of search term suggestions) may be on the basis of known information concerning the user.

A plurality of selected first search term suggestions may be sent to the search engine.

The method may also include the step of sending a further search suggestion to the first search engine, wherein the further search suggestion is not one of those returned by the first suggestion engine, but rather is identified as a suitable search suggestion on the basis of knowledge concerning the user (user information). selecting a search result from the plurality of search results for display on the user device

The selection of a search result from the plurality of search results to display on the user device may be on the basis of known information concerning the user.

The method may comprise storing the search results and search suggestions. The search results and search suggestions may be stored associated with a description of the trigger event. The method may comprise flagging any search result or search suggestion which the user selected as a particularly relevant search result or search suggestion.

The trigger event may be receipt of a search string input by the user (for example by typing or by voice). As more of the search string is received (for example, more characters are typed or more words are spoken), the user’s intent may be re-evaluated. The method may therefore comprise the steps of: sending an updated query to the first suggestion engine; receiving from the first suggestion engine a plurality of updated search term suggestions based on the updated query; selecting and sending an updated search term suggestion (or a plurality thereof) to the first search engine.

The method may then comprise receiving from the first search engine a plurality of updated search results; selecting an updated search result (or a plurality thereof) for display on the user’s device; and sending the updated search result for display on the user’s device.

In particular, a displayed search result may be withdrawn once it becomes probable that it is less relevant for the narrower context of the updated search string. This is to maximise the user’s confidence that on subsequent occasions, the presented results will be in line with the user’s actual intent.

The first search engine and second search engine may be different search engines. The first suggestion engine may be associated with the first search engine (i.e. both may be from the same provider), and the second suggestion engine may be associated with the second search engine. Alternatively, one or more suggestion engines not associated with either the first or second search engine may be used.

The second suggestion engine may be the user’s preferred search engine, for example Google, Bing, Yahoo, Ask.com, AOL.com, Baidu, DuckDuckGo, Internet Archive, Yandex.ru, etc.

Any of the suggestion engines or search engines may be existing solutions, or they may be custom-built solutions. Any of the suggestion engines or search engines may be general- purpose, or they may be specialised (domain-specific).

The first search engine may comprise a plurality of search engines. The suggestion engine(s) may include user-profile data and statistical data relating to all users. The suggestion engine(s) may apply heuristics and/or machine learning algorithms to large data sets.

The search engine(s) may include user-profile data and statistical data relating to all users. The search engine(s) may apply heuristics and/or machine learning algorithms to large data sets.

The suggestion engine(s) and search engine(s) may use common or separate user profile data, as well as data from external sources. External sources may include commercially available consumer information databases, or credit rating databases, for example. External sources may include data exported from social media platforms (for example, Facebook), with the user’s permission, based on GDPR rights.

The Intent Engine may feed user-profile related data or data derived from it to/from the suggestion engine(s), and/or search engine(s), and/or external sources.

Communication between the user device and the search engine(s) and/or the suggestion engine(s) may be facilitated by an application server or may be direct.

Each trigger event may result in display of search results linking to a variety of resources - for example: webpages, deep links, apps, images, audio data. The search results may have been found by one or more general purpose first search engine(s), and/or by one or more specialised first search engine(s).

The user information may comprise: temporal data and/or location data relating to the geographical location and/or movement history of the user; the user’s browsing history; the user’s search history; the user’s purchase history; the user’s email activity; the user’s instant messaging activity; the user’s social media activity; the device type of the user’s device; the user’s socio-demographics; whether the user is at work, at home, travelling or at leisure; data relating to the user’s known interests; data relating to identified user habits; date relating to the way the user interacts with their device (for example, typing speed); data relating to the user’s vital signs and/or health history; the number of times the user has visited a resource previously.

The user information may also comprise statistical data relating to other users, for example, the popularity of a resource (for example, a website) among the general population, and/or amongst users in a similar socio-demographic sector as the user.

Where the trigger event is input of a search term, then the user information may comprise previous choices of search results for the same or similar search term by the user, or by a plurality of users.

By building up a user profile comprising the foregoing user information, and the search results and search suggestions associated with trigger events, then the Intent Engine is able to forecast the user’s intent with increasing accuracy as time goes on. For example, consider a trigger event where the user inputs the partial search query “holiday s”. Search results could be returned relating to holidays in Spain, ski holidays, and holidays in South America. From the user’s subsequent searches, data is acquired indicating that the user intends to holiday in Spain. If the user then inputs the partial search “holiday s” again, search results relating to Spanish holidays only can be provided. If subsequent data reveals that the user always travels to Barcelona in July, and always stays in 5* hotels, then subsequent searches for “holiday” could return search results for 5* hotels in Barcelona with availability in July.

As a further example, consider a trigger event where the user inputs the search query “loan”. Absent data concerning the user, search results for high-street or high-end banks might be returned as well as search results for pay-day lenders. As data on the user is gathered, the most appropriate search result to display can be selected, depending on the user’s sociodemographics.

Each piece of data relating to the user or the trigger event may be associated with an importance weighting. A higher weighting associated with a given piece of data may mean that this piece of data will be have more of an effect on the generation of the search results than a piece of data with a smaller weighting.

The Intent Engine may comprise rule-based algorithms. Alternatively, the Intent Engine may comprise a machine learning algorithm, for example a neural network. The machine learning algorithm may learn the user preferences through behavioural patterns, for example by tracking past user interactions with the software, and/or based on information known about the user.

The following data types may influence the search results that are returned to the user: device type - phone, tablet, PC, smart TV, smart wearable, home appliance, connected car life context - work, home, travel, leisure geography - latitude, longitude, custom-defined geo-fencing area and history of movement temporal - time of day, time of week, time of month, time of year socio-demographics - age, sex, salary, education, address health and vitals - heart rate, body temperature, blood pressure, respiratory rate, health history purchase history - including products, services and content search history execution of data portability rights - including email, instant messaging and social networking data interests and habits feedback from previous choices of the user and other users.

The data may be real time data or legacy data. The data can come from GDPR data portability (GDPR allows legacy data to be obtained through the principles of ‘data portability’, such that data can be obtained from Facebook, Google, Amazon etc.) or it could come from situational data based around the user such as GPS for online and offline activity, search history, purchasing patterns, search terms, use of applications and other data sources such as open banking etc.

The first and second suggestion engines and first and second search engines may have their own user profile date relating to the user which enables them to provide more relevant suggestions and search results.

The whole or a part of the software of the Intent Engine may reside on the user device, and/or the whole or parts of the software may reside on an application server.

The user can select the displayed search results by means of any interaction facilities supported by their device.

The display of the search results may start at any time. For example, it may be as a reaction to entering the first letter of a search query, upon simply opening a search facility of the user device, or even without such explicit input, if the available data implies that it is desirable.

Presentation of the search results and search suggestion(s) may use any presentation facilities supported by the user’s device.

Optionally, the search result(s) may be presented by displaying a plurality of icons representative of each search result.

The icon may generally comprise a symbol or graphical representation. For example, the icon may be an image. The icons may for example show a logo associated with the resource linked to by the search result. These are readily recognizable to the user.

The user may be taken to their chosen resource by selecting (for example by tapping) the respective icon.

An icon may have no text associated with it, or only very limited text associated with it.

Optionally, any of the icons may be displayed a plurality of times, with each accompanied by a portion of text identifying a specific sub-section of the location that the user may wish to go directly to. For example, a first “settings” icon may be displayed with text reading “Wi-Fi settings”, and selecting that icon then takes the user directly to the Wi-Fi section of the settings widget. A second “settings” icon may be displayed with text reading “power settings”, and selecting that icon then takes the user directly to the power section of the settings widget.

The icons may be returned in an ordered list with icons deemed to be more likely to correspond to the user’s targeted resource being provided more prominently. For example, icons deemed to be more likely to correspond to the user’s targeted resource may be provided in a more prominent position. In a vertically-displayed list, the search result deemed most likely to correspond to the user’s targeted resource may be displayed at the top. In a horizontally-displayed list, the search result deemed most likely to correspond to the user’s targeted resource may be displayed on the side from which the user begins reading (for example, if the user’s language has left-to-right script, then the most-likely search result will be displayed on the left, whereas if the user’s language has right-to-left script, then the most-likely search result will be displayed on the right.

Additionally or alternatively, icons deemed to be more likely to correspond to the user’s targeted resource may be provided in a more prominent size, i.e. they may be larger than icons deemed to be less likely to correspond to the user’s targeted resource.

Additionally or alternatively, icons deemed to be more likely to correspond to the user’s targeted resource may be provided in a more prominent way by surrounding them by a coloured outline, or by providing the icon with a shadowed outline, for example, in order to make them stand out more to the user.

The prominence of an icon may be determined by factors such as: Popularity of the resource among the general population;

The number of times the user has visited the resource previously;

Whether or not the resource has some relationship to search terms searched recently by the user;

User habits; for example, the user may habitually visit the same resource at roughly the same time each day, or may habitually visit the same sequence of resources. Applications user has installed on the same device

Popularity of the resource in the user’s area or area user is currently at (geolocation)

Any number of icons may be returned to the user. For ease of identifying the relevant icon, optionally less than 20 icons are returned, for example less than 10 icons. To increase the chance that the user is presented with an icon that takes them to their targeted resource, optionally more than one icon is returned. Optionally, between 3 and 8 icons are returned, for example 4, 5 or 6 icons.

Alternatively or additionally, the search results may be presented by displaying: a text label and/or description; a standardised or custom advertisement format; a preview of the target resource.

The search results may comprise commercial search results (i.e. sponsored CPC/PPC results). Alternatively or additionally, the search results may comprise non-commercial results. In general, the search results may comprise any Uniform Resource Identifier (URI - a string of characters that unambiguously identifies a particular resource). More generally, any identifier applicable to a specific search engine or a device that unambiguously identifies a relevant resource can be used. The search results may comprise links to any data file contained within the device or in removable storage or based on a remote server, for example in the cloud. The data file may be a public-access data file, or it may have restricted access (for example, only the user may be able to access the data file). The search results may comprise: a website, an app, a user contact (wherein a user contact for example provides a contact telephone number and/or address etc. associated with an individual or organisation), an operating system widget, or a media file (for example, a photo, image, video or sound file).

Optionally, the displayed search result(s) may persist on the user’s screen, after the user has taken action to move to other content (e.g., after a user has selected a search result, or after the user has arrived at a search engine results page) or after the user has dismissed the list of results and suggestions (for example, by means of standard mechanisms depending on the device such as by clicking “cancel”, tapping “x”, tapping away from the results display, etc.). The user is thereby given another chance to interact with the displayed search results and reach the referred targets, which may be desirable if the user is not satisfied with the other content. The form and number of the persisting search results may be the same or different than the originally displayed search results. The persisting search results may subsequently disappear with or without the user’s direct interaction. The persisting search results may be displayed next to the other content or obscure it, optionally changing the layout or form of the other content, if necessary. The persisting search results may be selectable, for example by clicking or tapping. The persisting search results may disappear after a predetermined time period. The predetermined time period may be between 5 and 20 seconds, for example. The predetermined time period may be chosen by the user. The predetermined time period may be an adaptive time period, meaning that it may be set to an appropriate time period depending on the user’s previous interactions with such persisting search results.

As mentioned above, a dual-search environment may be provided, in which as well as the displayed search results from a first search engine (intent-based search results), one or more auto-suggested search terms from a second search engine may be presented to the user.

The second search engine is designated as the superordinate (primary, or dominant) search engine, and this is the engine which provides a search engine results page in the event that the user selects “enter”/”search” in order to receive classic search results, or in the event that the user selects an auto-suggested search term. The first search engine is designated as the subordinate (secondary) search engine, and it is used to return only the intent-based search results, instead of a search engine results page. Optionally, the user may choose the search engine designated as the superordinate search engine (either when setting up the search environment, with a setting that persists for subsequent use of the environment, or each time the search environment is used).

Practical implementation of a robust Intent Engine may require employing certain optimisations or trade-offs to satify real-world limitations of Internet infrastructure availability and quality, prices of data transfer, storage, processing power, provider services and computational power of server as well as client devices.

A number of example optimisations that can be applied to address some critical factors, such as:

- data transmission rate and frequency, including number of requests involved in communication between services as well as between services and client devices,

- user experience and responsiveness vs costs for provider and end user, including energy saving,

- performance indices of PPC content and its delivery.

Essentially, the optimisations aim at gauging the user’s intent quickly and accurately (in order to provide a good user experience) whilst minimising network traffic, which is driven by the rate of sending requests to the suggestion engine(s) and search engine(s). Optimisation parameters may be determined by machine learning, for example.

Possible optimisations with a particular focus on reducing the rate of sending requests to the suggestion engine(s) and search engine(s) include but are not limited to:

- Requesting intent-based results based on word and phrase completion ratios rather than continuously, with every sampled context change.

- Using of white space, for example when the user hits the space bar, as an indication or a clue that it is time to evaluate or re-evaluate user intent (for example, by sending updated information to the suggestion engine(s).

- Applying adaptive time delays before requesting new search results and/or query suggestions. New search results and/or query suggestions may be requested in response to increased context regarding the user’s intent (for example, more characters of a search term have been entered). The delays are adaptive in that they are set to an appropriate value depending on the trigger event circumstances. For example, where the trigger event is entry of a search query by a user, the delay may depend on the means of entry of the search query (e.g. typed on a keyboard, or input by voice command), and on the speed of entry of the search query. As an example, the delay between requests may be longer for a user who is typing a query slowly, compared to someone who is typing more quickly. The adaptive time delay may also be set by employing analysis of the user’s reactions to previously presented search results, for example by registering after how many input letters the user decided to take action by selecting a search result.

- Utilising the fact that alternative methods of machine data input such as voice searching may be more efficient and limiting request rate (to the suggestion engine(s) and/or to the search engine(s)) as a result. For example, a request may not be sent to the suggestion engine(s) until the user has finished or paused speaking, as the user may not expect to receive any results earlier and could even consider them a confusing interruption.

- Applying language-aware algorithms to all of the above. Where the trigger event is input of a search query, knowledge of the language that a search query is formulated in is helpful to enable the other optimisation methods listed here. Language detection may be based on simple indicators, such as device settings but additionally or alternatively may be based on analysis of words and phrases.

Possible optimisations with a particular focus on improving the accuracy and speed of gauging user intent include:

- Using pre-existing search and suggestion engines, along with their user profiling data, including commercial ones.

- Using 3^rd party user profile databases, for example credit rating databases.

- Using industry standard user identifiers within ecosystems to help profile users. An ecosystem may for example be an operating system, such as iOS, Android, Windows, all of which keep a unique ID of a user or a device that is available to apps and can be matched against a real person, for example Google Advertising ID. It can also be a more generally understood as a platform which offers multiple services to registered, and often unregistered users, such as Google or Facebook. The above two may overlap, for example, the Android ecosystem belongs to the wider Google ecosystem.

- Introducing custom statistics, heuristics and machine learning algorithms to improve the performance and quality of processing of user data, including geographical, temporal and behavioural data.

Optionally, data regarding the user’s activity is collected and for example is transferred to a remote server for storage in a database.

Optionally, the data is pseudonymised, such that personally identifiable information fields within a data record are replaced by one or more artificial identifiers, or pseudonyms. For example, no data that allows the user to be personally identified is stored; instead, these fields are filled by a pseudonym. In such a case, a “privacy-by-design” search facility is provided.

The user information may be pseudonymised by replacing all credential identifiers (for example, user name, address, postcode, credit card number etc.) with an pseudonym based on an identifier of a secure element of the device on which the search facility is run. The secure element may for example be a SIM, a virtual SIM, SIM software, TPM (Trusted Platform Module), TEE (trusted execution environment), Micro SD, NFC smart object, USB key, memory card, or Smartcard.

A “secure element” is an element which is not readily accessible, i.e. access to the element is protectable in some way. The phrase “secure element” is a generic term for various types of secure chips, devices or software solutions capable of securely storing and/or processing data (for example, keys, algorithms, applets, credentials, etc.).

The user may have the option to choose how much data they are willing to share. For example, the user may share one or more of their browsing history, shopping history, search history, email history, social media activity, use of applications, and location (e.g. GPS).

The user may have a “wallet” (software wallet) identified by the pseudonym. Rewards may be sent to the user’s wallet, depending on how much data the user shares. Rewards may be sent when the user performs an online activity, such as online shopping, viewing an ad, clicking an ad, using the search facility, downloading an app, etc.

The wallet may be associated with the search application, the browser or the user device.

In a second aspect, the invention provides a computer program comprising instructions which, when the program is executed by a processor, causes the processor to carry out the method of the first aspect, optionally including any of the optional features set out above.

The computer program may be a browser add-in (also referred to as an add-on, plug-in, extension or the like), an add-on to a search application, a standalone application, or a browser. The computer program may be integrated into the operating system of the user device.

The invention further extends to a computer-readable medium having stored thereon the computer program of the second aspect of the invention.

In a third aspect, the invention provides a data processing apparatus comprising a processor configured to perform the method of the first aspect, optionally including any of the optional features set out above.

The data processor may comprise a memory.

The data processor may be provided on a server, remote from the user device.

The data processor may comprise a communications interface configured to connect to the internet or other network.

The invention further extends to a system comprising a user device and the data processing apparatus according to the third aspect. The user device may be a mobile device (for example a mobile communications device), but the invention is not limited thereto. The invention is particularly useful, but not exclusively applicable, to devices where user input is limited or inconvenient, such that shortening the user journey and simplifying input are particularly advantageous.

The user device may comprise a screen for displaying the search results. The screen may provide a touch-screen interface.

The user device may comprise an interface enabling the user to input a search string. The interface may comprise a keyboard (for example, a touch-screen keyboard). The interface may comprise a voice command interface.

The user device may comprise a communications interface configured to connect to the internet or other network.

The user device may for example be a telephone (mobile or fixed, for example, a smartphone), a mobile tablet device, an e-reader, a laptop computer, a personal computer (a desktop computer), a wireless PDA, a media player (such as an MP3 player, hi-fi or radio) a gaming console (hand-held or otherwise), a virtual reality device, an augmented reality device, a smart television, an entertainment system, a set top box, a streaming media adapter (including, for example Amazon Fire TV Stick, Roku Streaming Stick, Chromecast), a smart meter (e.g. for measuring electricity, gas or water consumption at a building), a camera, smart binoculars, a travel card, a bank card, an ATM machine. The user device may also be a wearable device, such as a smart watch, smart glasses, smart clothing, or smart jewellery. The user device may be a vehicle such as a car, plane, a train, a bike, a boat or a bus. The user device may also be any Internet-of-Things (loT) device.

The user device may be any device that is capable of connecting to the internet via a wireless or wired connection.

The user device may be any device capable of presenting search results to a user, or causing such search results to be displayed on another device.

The user device may be any device capable of receiving and displaying a search result.

Certain preferred embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

Figure 1 shows a schematic of a prior art method for determining and displaying search results on a user device;

Figure 2 is a flowchart showing a method as disclosed herein for determining and displaying search results on a user device;

Figure 3 is a flowchart showing a method as disclosed herein for determining and displaying search results on a user device;

Figure 4 shows an example client-server architecture;

Figure 5 is a flowchart illustrating a method carried out by the client and server; and Figure 6 shows a schematic of a method as disclosed herein for determining and displaying search results on a user device, based on a text-input user query and demonstrating a dual-search engine environment.

Figure 1 shows a schematic of a prior art method for determining and displaying search results on a user device based on a text-input trigger event. The user enters a search string (a search word or search phrase) into a search bar. As the user enters the search string, a list of auto-completed search suggestions may be displayed to the user. The user then either selects one of the auto-completed search suggestions, or sticks with their own text and initiates the search (for example, by pressing a “search” button). The search term is then sent to the search engine, which generates a list of search results. These search results are then displayed on a search engine results page (SERP) to the user. The user then selects their desired search result.

Methods disclosed herein do not require the explicit input of a search query in order to return search results. Rather, return of search results can be in response to determining that a general trigger event has occurred.

Figure 2 shows a flowchart of a method of returning search results based on any general trigger event. The method begins with receipt of a user-centric trigger i.e. an occurrence that is somehow related to a user. The trigger may be an explicit or implicit trigger. Here, an explicit trigger is a user-generated trigger. Examples of explicit (user-generated) triggers are as follows:

- The user opened the search element of their device’s interface;

- The user picked up their device;

- The user initiated a text-based search query;

- The user completed a word as part of text-based search query;

- The user initiated a voice-based search query;

- The user expressed interest in a product while a smart appliance was listening.

An implicit trigger is one which is not user-generated as such, and instead may be inferred from the user’s environment and present activity, or from user profiling data including for example the user’s past activity or circumstances. Implicit triggers may also be inferred from the past activity of other users. Examples of implicit (non-user-generated) triggers are as follows:

- The user stopped interacting with device while looking at it for a prolonged period;

- The user changed location;

- The user’s device interacted with a wireless beacon;

- The user’s past actions involved searching the Web for specific content;

- The user’s past actions involved searching their device’s contents for specific elements; - The user previously bought a specific product at a specific time of day/week/year or at a specific location;

- Other users often buy a product at a specific time and location;

- The user previously expressed interest in a product that is currently on offer;

- Other users’ past actions at a specific time and/or location suggest they are interested in specific web content, device content, apps, products or offers;

- Other users of socio-demographic traits similar to subject user are interested in specific product at specific circumstances.

On receipt of an explicit or implicit trigger, the trigger information is sent to an API which interfaces with a suggestion engine. The suggestion engine may return suggestions whose type is dependent on the nature of the requested data. For example, the suggestion may be:

- A completed text query based on a partial text query;

- A name or identifier of previously viewed product based on a partial text query;

- An identifier of a product based on image recognition of an object the user is looking at;

- An application store URI of an app that is relevant to the current location;

- An URI from a nearby wireless beacon (for example, in a shopping centre, a gallery or a museum a beacon could be used to inform the user device of a store offer or give a description of an exhibit based on close proximity. This information can be used as a suggestion source).

The suggestions are received from the autosuggest API, and Intent Engine selects the most relevant suggestions (those most likely to reflect the user’s intent) based at least partially on user information. The most relevant suggestions are then sent to a search engine (or a plurality of search engines).

The suggestion engine(s) and search engine(s) may be general purpose or specialised (domain specific). Examples of specialised suggestion engines/search engines are those associated with WolframAlpha (which focuses on computational knowledge), tineye.com (which searches for image data), SoundHound (which indexes music and receives audio data as input) etc. Other examples are newspaper archives, indexes of scientific publications, and price comparison services. Each of these has specific requirements as to their input and output data.

On receipt of the search results from the search engine(s), Intent Engine selects the most relevant search results (those most likely to reflect the user’s intent) based at least partially on user information. The most relevant search results are displayed on the user device as soon as possible. The displayed results may include one or more of:

Commercial links/deep links to a webpage (a deep link is any link that directs the user past the homepage of a website to content inside of it);

Non-commercial links/deep links to a webpage; Links to an application store page associated with a relevant application;

Custom URI types, including deep links to application content.

Presentation of the search results may use any presentation facilities supported by the user’s device. For example, the results may be displayed as one or more of:

Icons;

- A text label and/or description;

Standardised or custom advertisement format;

Target resource preview.

Selecting a particular search results takes the user directly to the relevant resource. The user can select one of the presented results by means of any interaction facilities supported by their device, for example by tapping on a displayed search result.

The foregoing method is illustrated by the following two non-limiting examples.

As an example of an explicit trigger, consider the case where the user types the text “do” into a search facility on their device. On receipt of this trigger, these characters are then sent to an API which interfaces with a suggestion engine. The suggestion engine returns a number of suggestions, of which the following suggestions are identified by Intent Engine (based on user information) as the most relevant (i.e. most likely to reflect the user’s intent):

Donald Trump;

Dog food;

Doc Martin Season 10.

Three requests are then sent to a search engine for these suggestions. The search engine returns with three sets of search results, from which Intent Engine respectively identifies titles and URLs of Donald Trump’s twitter feed, a PPG link directing to Amazon’s dog food shopping category, and a BBC news article about renewal of the TV series Doc Martin as the most relevant (i.e. most likely to reflect the user’s intent). Those three entries are used as intent-based results. Icons corresponding to the three links are displayed on the user’s device.

Consider the case where the user is driving and the user’s device detects that it has entered the radius of 10 miles from the user’s home. This results in the generation of an implicit trigger. The current location of the device is then sent to an autosuggest API associated with a mapping application. Based on the user’s past searches, specifically “grocery store”, and “123 High Street”, the autosuggest API returns the URL of the map position of 123 High Street and the URL of the map positions of the nearest five grocery stores. Six requests are then sent to a mapping application for directions to these six locations. URLs for directions to the six locations are then displayed on the user’s device, and clicking on any of the displayed links opens the mapping application to begin directions to the chosen location. Figure 3 shows a simplified method which omits any interaction with an API which interfaces with a suggestion engine. In this method, the information derived from the trigger event itself is sent to the search engine, rather than sending the data derived from the trigger event to a suggestion engine to generate a query to be sent to the search engine.

The foregoing method is illustrated by the following non-limiting example. It may be determined that the user searched for “blue running shoes” three times in a particular week at around 7pm. This is an implicit trigger, generated based on past user activity. At 7pm the next day, a request may be sent to a search engine for “blue running shoes”. The search engine returns search results to the Intent Engine, and the cheapest sale offering is displayed on the user’s device as a search result.

Other results may also be displayed, for example other pages regularly visited at this time from this location. This unprompted list will then change as the user begins a search or surf routine, based on visit sequences or page popularity with the user.

Figure 4 illustrates an example client-server architecture. Shown in the figure are a user device 100, an Intent Engine Core server 200 and an external search engine 300. The Intent Engine Core comprises a main program running on a processor 210. The main program interfaces with a Intent Engine suggestion engine 230 and Intent Engine search engine 240, and also with the external search engine 300. The server may comprise storage 220 for storing suggestions and search results, which buffers suggestions and search results on a per-user basis. That is, suggestions and search results may be cached. Such a buffer, which for example might take the form of an indexed dataset, applies user identification (optionally pseudonymised, as set out above) to at least some of the data it stores in order to return personalised results. This optimises data delivery, avoids redundant requests and maintains response personalisation. Search results may be retained for a limited time only, in order to keep the data up to date. Here, “up to date” relative and depends on the data type and source. For example, data on currency exchange rates will likely need more frequent updates than data from Wikipedia.

In its simplest form, Intent Engine could store the verbatim content it receives from a suggestion engine or search engine. The key (used for indexing) consists of a partial query (for the suggestion engine cache) or a full query (for the search engine cache) as well as some user-identifying data (optionally pseudonymised). The cached value could be the entire verbatim response from the suggestion engine or search engine.

However, at some point Intent Engine will have to interpret the cached content in order to correctly present it to the user, for example to retrieve search results’ URLs, titles and images from a SERP page or understand what currencies are involved and what the exchange rate is when querying a currency exchange engine. Therefore, in some cases the interpretation of the results will be done before caching them. This is advantageous because storing only the relevant data takes less space, and if cached results will statistically be read (retrieved) more often than written (stored) then it is inefficient to do the data processing upon every read. In such cases, the values in the index will be more precisely defined, for example, “list of URLs and their labels” or “exchange rate of EUR to GBP”.

Caching results within the Intent Engine allows to limit interactions with suggestion engines and search engines - this may be particularly advantageous where third party suggestion engines and search engines are used by Intent Engine to arrive at “intent-based” results.

The storage 220 may also be configured to store information about the user, the user’s activities, and the suggestions and search results generated responsive to queries generated following the user’s trigger events.

Figure 5 illustrates a method in accordance with an embodiment of the invention. The method begins at step 500 with receipt of user-entered characters as a trigger. In this example, the user-entered characters are the characters of a search term. On expiration of an adaptive delay, these characters are sent to the server, which receives and stores the characters in step 502. The adaptive delay at the user device, (client-side) is utilised in order to limit the number of sever queries per unit time. The focus is on maintaining the best user-experience.

As well as receiving and storing the characters, the server also receives and stores contextual information such as the time and user’s location. From this step, two parallel processes begin.

The first parallel process begins with the server determining whether cached search results are available for these characters (step 504), and if so, these are sent to the user’s device and displayed on the user’s device (step 506). The search results are preferably displayed as icons (optionally with accompanying text), rather than a long-form text link. Such search results link directly to the relevant resource. Therefore, if the user selects (for example, by tapping or clicking) a search result displayed on the user device, the user is taken directly to the relevant resource which the search result links to, without the user seeing a SERP. If cached search results are displayed, then in step 508 the device determines what the user selects and sends the user selection to the server. In step 510, the server stores the user selection. If the user does not select any of the search results, this is also relevant information which is passed back to the server.

Whether or not cached search results are available (as determined in step 504), the server sends the characters (following an adaptive delay) to a first suggestion engine, which receives the characters and determines autosuggest suggestions (step 512). These autosuggest suggestions are returned to the main program running on the server, which, utilising the data known about the user, chooses the best autosuggest suggestions (i.e. the autosuggest suggestions most likely to reflect the user’s intent), and stores them (step 514). To determine the best autosuggest suggestions, the program makes use of user information (knowledge of the user and other users).

The server then sends these chosen suggestions to a search engine, denoted here the Intent Engine search engine (following an adaptive delay). In step 516, the Intent Engine search engine receives the chosen suggestions, performs searches for the chosen suggestions, and then returns to search results for each search suggestion. In step 518 the main program, utilising the data known about the user, chooses the best search results (i.e. the search results most likely to reflect the user’s intent), and stores them. To determine the best search results, the program makes use of user information (knowledge of the user and other users).

The chosen search results are then sent to the user device and displayed (step 520). Such search results link directly to the relevant resource. Therefore, if the user selects (for example, by tapping or clicking) a search result displayed on the user device, the user is taken directly to the relevant resource which the search result links to, without the user seeing a SERP. Following step 520, in step 508 the device determines what the user selects and sends the user selection to the server. In step 510, the server stores the user selection.

Returning to the second of the parallel processes which begins following step 502, following an adaptive delay, the characters are sent to a second suggestion engine, which is a suggestion engine associated with an external search engine (e.g. Google). In step 522, the second suggestion engine receives the characters, and determines autosuggest suggestions for the external search engine based on those characters. These suggestions are sent back to the server, and are stored in step 524. The server sends the suggestions on to the user device, where they are displayed (step 526). If the user clicks on one of these autosuggest suggestions, a search request is sent to the external search engine (e.g. Google), and the user is taken to the SERP generated by the external search engine.

The process outlined above may be repeated multiple times as additional information is received at the server (for example, the process may be carried out once when the user enters a word as a search term, and then may be carried out again after the user enters a second word of the search term).

This method allows to retrieve search results as early as possible (based on initial suggestions) and update these results based on updated suggestions, once it becomes evident to the suggestion engine that the suggestion should change as the user continues typing. The frequency with which the user’s input is re-evaluated may depend on the user profile.

A number of modifications to the foregoing method are possible. Whilst step 512 shows characters being received by only one suggestion engine, the server may send the characters to a plurality of suggestion engines, and accordingly receive autosuggest suggestions from the plurality of suggestion engines. Moreover, whilst the figure shows the suggestion engine running on the Intent Engine Core server, one or more suggestion engines may be external suggestion engines not running on the Intent Engine Core server. In some embodiments, the suggestion engine can be accessed by the user device, rather than by the Intent Engine server. This may be desirable as it could maximise the amount of data the suggestion engine already has about the user from their device. In such embodiments, the suggestion(s) can be then forwarded to the Intent Engine server along with the characters of the query, for example.

Both search and suggestion engines may utilise their own knowledge of the user to help make their output more relevant.

Whilst step 516 shows characters being received by only one search engine, the server may send the characters to a plurality of search engines, which perform searches and generate search results, and accordingly the server may receive search results from the plurality of search engines. Moreover, whilst the figure shows the search engine running on the Intent Engine Core server, one or more search engines may be external search engines not running on the Intent Engine Core server.

Whilst the method begins at step 500 with receipt of user-entered characters, instead it may begin with receipt of a query in voice form (i.e. a spoken query). The spoken query may be passed to the server for speech recognition (as part of step 502), and the method may include the step of waiting until the user has finished speaking before proceeding beyond step 502 of the method.

As will be clear from the foregoing, and as shown in Figure 6, the following elements can be displayed on the user device:

1. Cached search results; such search results link directly to the relevant resource such that if the user selects one of those search results, the user is taken directly to the relevant resource which the search result links to, without the user seeing a SERP;

2. Search results chosen by the Intent Engine in response to the trigger; such search results link directly to the relevant resource such that if the user selects one of those search results, the user is taken directly to the relevant resource which the search result links to, without the user seeing a SERP;

3. Autosuggest suggestions for the external search engine; if the user clicks on one of these autosuggest suggestions, a search request is sent to the external search engine, and the user is taken to the SERP generated by the external search engine. Intent Engine, in its simplest form, may be thought of as an aggregator of autosuggest engines and search engines that directly presents the most relevant search links, alongside classic auto-suggest suggestions. In a sophisticated form, Intent Engine takes the decision process of what, when and to whom to present to a new level by applying its own knowledge of users. The Intent Engine collects user information, including search and autosuggest data, as well as user device and behaviour data to improve on personalising its selection process.

Claims

23 CLAIMS

1. A method of presenting search results on a user’s device, comprising: determining that a trigger event has occurred; generating a query based on the trigger event; sending the query to a first suggestion engine; receiving from the first suggestion engine a first plurality of search term suggestions generated responsive to the query; sending a first search term suggestion selected from the first plurality of search term suggestions to a first search engine; receiving from the first search engine a plurality of search results generated based on the first search term suggestion; selecting a search result from the plurality of search results to be displayed on the user device; sending the search result for display on the user device; sending the query generated on the basis of the trigger event to a second suggestion engine; receiving from the second suggestion engine a second plurality of search term suggestions generated responsive to the query; and sending a search term suggestion of the second plurality of search term suggestions for display on the user device.

2. A method as claimed in claim 1 , wherein the search result displayed on the user device links directly to the corresponding resource.

3. A method as claimed in claim 1 or 2, wherein the search suggestion displayed on the user device links to a search engine results page generated on the basis of that search suggestion, wherein the search engine results page is provided by a second search engine.

4. A method as claimed in any preceding claim, comprising determining, at least partially on the basis of user information, a suitable first suggestion engine to send the query to, optionally wherein the determination is made using rule-based algorithms or a machine learning algorithm.

5. A method as claimed in any preceding claim, wherein the selection of the first search term suggestion to send to the first search engine is made at least partially on the basis of user information, and optionally wherein the selection is made using rule-based algorithms or a machine learning algorithm.

6. A method as claimed in any preceding claim, comprising sending a further search suggestion to the first search engine, wherein the further search suggestion is not one of those returned by the first suggestion engine, but rather is identified as a suitable search suggestion at least partially on the basis of user information.

7. A method as claimed in any preceding claim, wherein the selection of a search result from the plurality of search results to display on the user device is made at least partially on the basis of user information, and optionally wherein the selection is made using rule-based algorithms or a machine learning algorithm.

8. A method as claimed in any of claims 4 to 7, wherein the user information comprises one or more of: temporal data and/or location data relating to the geographical location and/or movement history of the user; the user’s browsing history; the user’s search history; the user’s purchase history; the user’s email activity; the user’s instant messaging activity; the user’s social media activity; the device type of the user’s device; the user’s socio-demographics; whether the user is at work, at home, travelling or at leisure; data relating to the user’s known interests; data relating to identified user habits; date relating to the way the user interacts with their device (for example, typing speed); data relating to the user’s vital signs and/or health history; the number of times the user has visited a resource previously.

9. A method according to claim 8, wherein the user information is pseudonymised, such that personally identifiable information fields within a data record are replaced by a pseudonym, optionally wherein the pseudonym is based on an identifier of secure element of the user’s device, and wherein the secure element comprises a hardware SIM, a virtual SIM, SIM software, TPM, TEE, Micro SD, NFC smart object, USB key, memory card, or Smartcard.

10. A method as claimed in any of claims 4 to 9, wherein the user information comprises statistical data relating to other users including the popularity of a resource amongst the general population, and/or amongst users in a similar socio-demographic sector as the user.

11. A method as claimed in any of claims 4 to 10, wherein where the trigger event is input of a search term, then the user information comprises previous choices of search results for the same or similar search term by the user, or by a plurality of users.

12. A method as claimed in any of claims 4 to 11, wherein the user information is used to generate an implicit trigger as the trigger event, without the user entering a search term or even a single keystroke.

13. A method as claimed in any preceding claim, comprising storing, associated with a description of the trigger event, one or more of: the first plurality of search term suggestions, the plurality of search results, and the second plurality of search term suggestions, optionally comprising flagging any search result or search suggestion which the user selected as a particularly relevant search result or search suggestion.

14. A method as claimed in any preceding claim, comprising the steps of: sending an updated query to the first suggestion engine; receiving from the first suggestion engine a plurality of updated search term suggestions based on the updated query; sending an updated search term suggestion to the first search engine, receiving from the first search engine a plurality of updated search results; selecting an updated search result for display on the user’s device; and sending the updated search results for display on the user’s device.

15. A method as claimed in any preceding claim, wherein the first search engine and second search engine are different search engines, and/or wherein the first search engine comprises a plurality of search engines.

16. A method as claimed in any preceding claim, wherein the search results link to one or more of: webpages, deep links, apps, an operating system widget, images, video data, audio data, or any data file contained within the device or in removable storage or held on a remote server, and/or wherein the search results are found by one or more general purpose first search engine(s), and/or by one or more specialised first search engine(s). 26

17. A method as claimed in any preceding claim, wherein the search result is presented by displaying a plurality of icons representative of the search result, optionally wherein a plurality of search results are presented as a corresponding plurality of icons, and the icons are displayed in an ordered list with icons deemed to be more likely to correspond to the user’s targeted resource being provided more prominently.

18. A method as claimed in any preceding claim, wherein the displayed search result persists on the user’s screen for a predetermined time period, after the user has taken action to move to other content.

19. A method as claimed in any preceding claim, wherein one or more of the following steps is executed only after expiration of an adaptive delay which is personalised to the user, or when a predetermined condition is met: sending the query to the first suggestion engine; sending the first search term suggestion selected from the first plurality of search term suggestions to the first search engine; displaying the search result on the user device; sending the query generated on the basis of the trigger event to the second suggestion engine; displaying the search term suggestion of the second plurality of search term suggestions on the user device.

20. A method according to claim 19, wherein the predetermined condition may be at least one of: entry of the space character by the user; the user pausing or stopping speaking; the user entering a certain number of words.

21. A computer program comprising instructions which, when the program is executed by a computer, causes the computer to carry out the method of any preceding claim.

22. A computer program according to claim 21, wherein the computer program is a browser add-in, an add-on to a search application, a standalone application, or a browser, or part of a device operating system.

23. A computer-readable medium having stored thereon the computer program of claim 21 or 22. 27

24. A data processing apparatus comprising a processor configured to perform the method of any of claims 1 to 20, optionally wherein the data processing apparatus is on a server remote from the user device.

25. A system comprising a user device and the data processing apparatus according to claim 24, wherein the user device is configured to display the search results and search term suggestions.