PROVIDING RECOMMENDATIONS BASED ON PREDICTED CONTEXT
The invention relates to a method of providing a recommendation to a user of a user device, comprising: receiving a prediction of a context of the user; in dependence on the predicted context identifying context data for the prediction; providing one or more recommendations to the user in dependence on the predicted context data.
The invention relates to providing recommendations to a user device based on a prediction of the context of the user device. The user device preferably receives the prediction of context from an external source. The user device preferably derives a prediction of context data from the predicted context. The user device preferably requests additional context data based on the predicted context.
Description of the Related ArtIt is known to provide recommendations of content to a user device, based on a known context of a user device. This allows, for example, recommendations to be provided to a user device based on the actual location of a user device or the actual time of day.
It is an aim to provide a modified technique for the provision of recommendations to a user device.
SUMMARY OF THE INVENTIONThe invention provides a method of providing a recommendation to a user of a user device, comprising: receiving a prediction of a context of the user; in dependence on the predicted context identifying context data for the prediction; providing one or more recommendations to the user in dependence on the predicted context data.
The method may further comprise deriving context data from the prediction.
The method may further comprise identifying desirable context data from the context, and requesting said context data if it is not derivable from the prediction. The context data may be requested from an external source.
The method may further comprise receiving the prediction of the context of the user from an external source, which external source additionally provides context data for the prediction.
The context may be associated with a time period and/or at least one location. The context data may indicate a location at one or more time instances within the time period.
The method may further comprise, for at least one context data, identifying a time instance associated with that context data, and presenting recommendations based on the context data and its associated time instance. The method may further comprise presenting recommendations based on the context data and its associated time instance at a recommendation time in advance of the time instance associated with the data context. The method may further comprise presenting recommendations based on the context data and its associated time instance at a recommendation time corresponding to the time instance associated with the data context. Multiple context data may be associated with a time instance. A recommendation may be based on the multiple context data.
The method may further comprise accessing a user profile, and providing the one or more recommendations based on the accessed user profile.
The method may further comprise: receiving an identification of actual context data for the user device; comparing the actual context data to the predicted context data; and adjusting one or more recommendations thereon. The prediction of context data and the identification of actual context data are received from the same source.
The external source may be a navigation application. The external source may be a transport application.
The invention also provides a recommendation engine comprising: an interface for receiving a prediction of a context of a user; a processor configured to: predict context data for the context prediction; provide one or more recommendations for the user in dependence on the predicted context data, wherein the interface is further configured to transmit the one or more recommendation to a user device of the user.
The processor may be further configured to identify desirable context data for the context. The desirable context data is not retrievable from the context, then the processor may be configured to request the desirable context data via the interface.
The interface may be configured to receive the prediction of the context of a user from the user device.
The processor may be further configured, for at least one context data, to identify a time instance associated with that context data, and determine recommendations associated with the context data at the associated time instance.
Multiple context data may be associated with the time instance, the processor further being configured to determine recommendations for the time instance based on the multiple context data.
The processor is configured to generate recommendations based on the context data and its associated time instance at a recommendation time in advance of the time instance associated with the data context.
The processor may be configured to generate recommendations based on the context data and its associated time instance at a recommendation time corresponding to the time instance associated with the data context.
The processor may be configured to present a recommendation based on the multiple context data.
The processor may be configured to access a user profile, and provide the one or more recommendations based on the accessed user profile.
The processor may be configured to receive an identification of actual context data for the user device; compare the actual context data to the predicted context data; and adjust one or more recommendations thereon.
The interface may be configured to receive the prediction of context data and the identification of actual context data from the same source. The source may be a navigation application or a transport application.
There is described a method of providing recommendations to a user, comprising: predicting a time duration associated with a location of a user device; receiving, from at least one third party source, information associated with the location of the user device; and providing recommendations to the user for the time duration in dependence on the received information.
The method may further comprise receiving, from the at least one third party source or from a further third party source, the predicted time duration.
The method may further comprise identifying the location of the user device within the predicted time duration. The third party application provides additional information associated with the location of the device within the predicted time period. The location of the user device varies within the predicted time duration. The third party application provides additional information associated with one or more locations of the device within the predicted time period.
The method may further comprise receiving, from sensors associated with the use device, information associated with the location of the user device.
The method may further comprise receiving information indicating the quality of the connectivity of the user device during the predicted time duration, wherein the recommendations are varied in dependence on such. The location of the user device may vary during the predicted time duration, wherein there is received information indicating the quality of the connectivity of the user device at different time intervals during the predicted time duration in dependence on the locations of the user device during the predicted time duration, wherein the recommendations are varied in dependence on such.
A recommendation to a user may be dependent on a place or location of the user device within the predetermined time duration. The recommendation may be provided when the user device is located within a time or distance of the place or location within the predicted time duration.
The recommendations may be additionally dependent on the profile and/or preferences of the user.
The recommendations may include recommended destinations along the journey.
The recommendations may include content to be viewed within the predicted time duration. The recommendations include a catalog of items which can be viewed within the predicted time duration.
The method may comprise generating an enquiry to the user as to whether they are interested in recommendations of a certain type, and in dependence on a response, generating recommendations of that type.
The recommendations may be user-configured.
The method may further comprise providing a recommendation in dependence on a location, and in dependence on acceptance of that recommendation adjusting a route.
The method may further comprise providing a recommendation in dependence on a specific location, the recommendation being associated with reducing a cost, and in dependence on acceptance of that recommendation adjusting the cost. The recommendation may be associated with a third party, and in dependence on acceptance of the recommendation the third party accepts responsibility for at least part of the cost.
Examples provide recommendations to a user, comprising: predicting a time duration associated with a journey of a user device; receiving, from at least one third party source, information associated with the journey of the user device; and providing recommendations to the user for the time duration in dependence on the received information.
Examples provide recommendations to a user, comprising: predicting a time duration associated with a journey of a user device; receiving, from at least one third party source, information associated with the journey of the user device; and providing recommendations to the user in dependence on user device being within a certain distance of a location as the journey elapses.
Examples provide recommendations to a user comprising: predicting a time duration associated with a journey of a user device; receiving, from at least one third party source, information associated with the journey of the user device; providing a recommendation, associated with a further third party, to the user in dependence on the identified location; and in dependence on acceptance of the recommendation, associating at least a portion of the cost of the journey to the further third party.
Examples provide recommendations to a user comprising: receiving recommendation for a time duration in dependence on received information from at least one third party source; engaging with content in dependence on the recommendations; and offsetting a cost associated with the journey in dependence on the content engaged with.
Examples provide recommendations to a user, comprising: predicting a time duration associated with a location of a user device; receiving, from at least one third party source, information associated with the connectivity of the user device for the time duration; and providing recommendations to the user for that time period in dependence on the identified connectivity.
A recommendation is preferably a recommendation of a content item.
The described technique makes reference to leveraging your taxi Trip which is facilitated using a transport app.
A second app may very much take advantage of the information available in a transport app, such as a transport app associated with a taxi service. In all use cases, the app has to be started up by the user and would ping the transport app to see if a transport app engagement is actually happening. The app would be promoted and marketed so that people would start using them.
First and foremost, the length of the cab ride is of interest in that it allows understanding the available time window for a possible engagement. Secondarily, the destination is of interest as it provides context to the future needs of the app user. There are two major use cases.
A first use case is that the destination is indicative of an extended offline situation in the future of the app user. Examples of such destinations include airport or train stations for destinations, wilderness trips etc. It might be preferable to get even smarter by comparing the destinations coordinates with the cellphone providers coverage map. It could then offer to download entertainment content during the cab ride or afterwards perhaps after the app user is being asked about the departure time. This will allow an estimate of the connection quality and potential download time and then offer entertainment content from a “Voyage VoD” store which could be enhanced to include games, magazines and other entertaining options sorted by required download time etc. A critically important aspect to this would be to allow preparing the download function of the desired content and initiating the download while continuing on with other smartphone apps. In other words, the download must take place in the background so as not to monopolize the phone. However, if the “other” app is taking up too much bandwidth to a point where the download cannot be completed in time, the user needs to be presented with the option to prioritize the app services.
While this use case can be imagined nicely as a companion app to a transport app associated with a taxi service, this could be tied in with any car. In other words, using any (assumed to be modern and connected) car, you may plug in your destination address and a “Voyage app” detects the anticipated offline window and goes from there to make recommendations based upon the available driving time and the available memory in the targeted device to download to.
A second use case is offering a service to reduce the cost of the cab ride. In this use case it is assumed that the cab ride has been initiated and the transport app user is inside the car and the ride has started. The Voyage app has taken notice will notify the rider that the ride is expected to take 15 minutes and it can offer the rider the option to watch multiple personalized commercials during that time which would lower the fare from $x to $y.
Aside from other mandatory features to make this app work well and seamlessly, a sophisticated “recommendation process” is very important for a successful monetization process. The passenger should not have to click on the software App and have to leave it open, but ideally the feature of watching advertising in return for a reduced rate would present itself as soon as the ride has started triggered by the transport app. While initially thought of as a revenue share scenario between advertising server, rider and service provider, a monetary incentive for the transport app provider might convince them to initiate the “Voyage app” start. A window would ask if the passenger wants to be entertained or would be amenable to watching commercials in return for a lower fare. If yes, it would, say, offer you the remaining length of the trip and say you can watch 5 commercials and the trip price will go down from $ x.00 to $y.00. Additionally, content should not be limited to downloadable movies or video content, but also games and books, magazines and of course video commercials and or surveys that would allow people to make money while being on the phone. Also, in regards to being a seamless experience, the app or app extensions (if it is integrated into a transportation app) should be smart enough to recognize an incoming phone call or text message and interrupt the video/game or commercial. It might go further and introduce a listening function that detects a verbal interaction that might be in conflict with the passenger processing ad videos. Furthermore, in order to increase the monetization capability any commercials sent should be consumed by way of an interactive process. This is to say ways to extract questions and possible answers from the commercial stream and engage the viewer into a Q&A session are needed, and only provide a positive reward if the viewer has truly “worked” through the commercial. The technique could go one step further and build in “gamification” so as to create a fun experience. It should be driven actively by the user to ensure a certain level of attention. Profile information as well as histories on former engagement/content consumption are used in addition to drive the recommendation process.
A third use case is creating a market place for a traveler. Assuming that the person has ordered the transport app or started a journey having put a destination into the car's GPS system, the Voyage app should find out what businesses are at the destination address. If it is a restaurant, the app could ask he the user is interested in looking to see if any of the restaurants close to the destination would like to pick up the cab ride as an incentive to bring the traveler to said restaurant. Restaurants could be invited possibly thru a link with “Open Table”. The app could cancel the reservation at the original restaurant.
Other considerations may be needed.
Peer to Peer connection may be used to use the phone as a downloading, but not necessarily viewing, device.
The download could be directly to the phone or possibly even using the peer-to-peer to download to both the phone and an iPad if that is within range but not running the transportation app. Likewise the peer-to-peer wireless could be used inside a plane during times of no connectivity to use the better ipad screen, while feeding the video from the phone.
Downloading commercials for consumption and processing by the rider after the cab ride may be used. If the process described here is taken further, the commercial viewing in return for being paid can be extended to times during which there is no connectivity. In other words, while we can all anticipate the opportunity to use the airport ride as a last chance to download entertainment content, of course we can also extend the commercial viewing opportunity to viewers. This scenario will offer the difficulty of having to record the quality of the viewer interaction on the device and then dump the data for further analysis or ultimate payment once connectivity is restored.
As stated above, the app can either be integrated into the transportation app with the distinct advantage of knowing the destination or as a standalone app that only knows that the phone owner is riding in a car and can then approach the phone owner about his/her needs or desires. As all other apps that might deter a driver, it would be fantastic to start the app up with audio that says: “hey you are on the road, if you are the driver, should we interact by Siri, if not, use the screen”.
It can use all the information and details of the trip itself to show related content/ads. That means the trip details are used to drive recommendation and consequently targeted ads (time, duration, location, etc.).
Information about the destination is used for showing related ads to increase attention of the user and to make the ad more effective.
Information about the user profile and the user preferences in relation to places and events across the driven route can be used to reveal a targeted advertisement/promotion during the trip. A user that likes opera will show up an increased level of attention when getting information about upcoming events and performances while driving along the opera building. Consequently places/location while driving can be nucleus of for targeted interest and therefore for targeted advertisement.
Information about the user and the time to which the trip is done can be used to drive advertisement. A user that makes a trip during lunchtime might be interested in restaurants that are alongside the route and which offers special promotions. Moreover, if the ride goes to a specific restaurant, one can envision to use that information and text it to five other restaurants nearby and offer them a potential patron in return for a free cab ride or a reduced meal price.
Inferred information from time/location/etc. can be used to drive content recommendation and consequently targeted advertisement. A user that starts a cab ride at the airport to a hotel might be interested in events in the evening or promotions for dinner.
All this is possible as the application has knowledge about the user from profile information and historical behavior. The device in use can provide information of time, place and from other available external applications (like the information from calendar etc., although the user will have to permit exchange of data and information between the applications). In addition the software Application knows the planned route which the cab will take. Therefore by applying a certain radius along the route, possible points of interests can be inferred and used for further information/advertisements that are related to such points of interests. It might be possible that the Software App can proactively suggest places to visit as they may represent a good match for the user.
Potential other applications/use cases of the software App may be as follow.
“What is my trip?” This is essentially part of the application in which the user gives information in advance of the cab trip to set the level of interaction with the app. It uses this information to provide info that is relevant to the destination, restaurant and transportation choices, weather, events etc.
A user might order a cab by using the software App. In addition to time, and destination, the purpose and restrictions are retrieved:
“Host my trip”. The goal of “host my trip” is to generate offers and suggestions that are well-aligned with the details of the trip. The details of the trip are known—time of day, duration, route, destination etc. are all known. This information is used to offer and show content and further details around the trip accompanied by related ads or promotions.
The duration of the trip is calculated to be approximately 15 minutes—a respective sequence of content is inferred which matches to the duration. The knowledge about route and destination is used to provide related information alongside to advertisement and promotions.
“Pay my trip”. The ride is specifically intended for shopping tours, dinners, events, etc. A specific purpose or destination can be entered into the app. This information is used to promote and show up with matching advertisement of “partners” of the platform. As an obvious example, restaurants were mentioned above, but in the case of a shopping trip, one could imagine that all the businesses in the mall extend an offer to pay the ride if you end up buying merchandise of a certain amount. That means e.g. a shopping mall in downtown can be visited and the user of the app gets information on products, services, etc. during the ride to the mall. Slightly different to the use case “Host my trip” partners of the platform can fund the trip proactively (slightly similar to the refund of parking costs when you buy something in a shop). The user of the software App can register his trip as e.g. a “shopping trip” to xyz and the trip will be used to survey the user about what he would like to buy, to see, etc. and will do promotions around this. Similarly this could be done when going out for dinner, etc. In addition to the pure advertisement that is shown to the user, purchasing products or having a dinner in a promoted restaurant can be a further fund of the trip. A combined payment mechanism of the trip and the e.g. dinner that is paid or the product that is purchased ensures that all this is aligned and can be managed.
“Use your trip”. This is one step further with respect to “Host my trip” and “Pay my trip”. Here the user is trying to use the time during the trip for something that he would like to do in any case. For instance someone is interested in certain product and would like to inform himself and do some research etc. This can be additionally motivated by the software App, as by doing so during the trip the respective advertisement can be used to fund the trip. On top of that purchasing a product online in a timely close fashion can give another add-on to the fund. A partnership with a site or an app that already provides this type of information would allow for a jumpstart here.
Examples of details are as follows:
-
- Interrupting the app for a phone call.
- Using the travel time estimate to make recommendations for downloadable content.
- Using the phone as a download device while using peer-to-peer wireless to display or store and display elsewhere.
- Automatically generating Q&A sessions from available commercial inventory and randomizing the question patterns such that the quality of the viewing can be demonstrated measured.
- Using a link between the car's GPS system and extracting destination information or extracting the same destination information from one of the phone's apps (i.e. Maps, Google Maps or Waze) and creating the uses cases above.
- This one is for combining streaming with downloading content. Using GPS route+real-time cellular coverage map to intelligently/predictively manage the download speed/buffering/video quality/content available. Say you are starting a multi hour trip to the grandparents with your daughter in the back seat of the car. Using her iPad, she starts the streaming process, as soon as she is strapped in and while the connectivity is still great, the mapping process indicates that one hour from the start of the journey, the connectivity will be bad if not zero, so Voyage starts buffering in an intelligent fashion by downloading the next relevant sections of the movie in the background while allowing for the streaming in the foreground and all the while managing the device memory.
- In parallel and addition to the above, we should offer/identify a smart wirelessly connected hard drive that folks can buy in the after market and might use that device to buffer the anticipated loss of connectivity. Naturally, we have to deal with the rights issues here, but self-destruction of content should be sufficient. If the app could also connect to your streaming subscriptions and pick up what you have been watching lately, it could offer to download a sufficient amount of a TV series of you wish to use the time for binge watching (always provided that you have sufficient amount of memory).
- Using the hard drive above which would utilize the same smarts that the Voyage App brings to the phone, while parked at home (where it might even be able to tie into the wireless connection at the house), we could also pick up the most recent viewing history and download the content in anticipation of a road trip but utilizing the significant memory in the smart hard drive in the car.
- Alternatively—imagine a greyhound bus or the Chinatown express—it should maximize download/buffer when network is being stressed the least by the people around you. In other words, it somehow looks for others using the voyage app around you and sees what they are doing at any given moment or into the future based on what they are currently doing. This also helps with the peer-to-peer thing in the case that data downloaded can be shared by people who do or don't know each other.
- Given that memory storage on a device maybe the limiting factor, what if you were to adjust the route based upon mapping of cell coverage and destination, such that you have maximized connectivity . . . and give the driver the choice by saying you can spend an extra 15 minutes in the car but your daughter will see the show without interruption.
The invention is now described by way of reference to the accompanying Figures, in which:
The invention is now described by way of reference to particular examples and embodiments. The invention is not limited to any particular example or embodiment given. In particular the invention is described with reference to providing recommendations in a journey, such as a journey conducted in a vehicle, but it would be understood that this scenario is exemplary and does not limit the scope of the invention.
With reference to
Illustrated in
The server 30 is configured to provide recommendations to the user device, for display to the user of the user device, in order to select the content to be transferred to the user device for or during the journey.
A preferable operation will now be described with reference in addition to the process flow of
An example is given of a journey to be conducted by a vehicle in which the user device 2 will be. The navigation module 16 of the user device 2 may provide a route for that journey, based on a start and end location. The route provided by the navigational module 16, and selected by a user of the user device 2, is transmitted by the interface 4 to the interface 32 of the server 30. As denoted by step 60 of
In the described example the external source may be an application that is not part of the content delivery system. In this example the external source, being the user device, is part of the content delivery system. However in general the external source may be external to the content delivery system, and therefore not the user device itself. For example the external source may be a navigation device in the car.
The prediction of context is the prediction of the route which the user device 2 will take.
The server 30 then operates to drive a predicted context from the prediction of context provided by the external source.
In a step 64 the server 30 determines desirable context data based on the predicted context. This may be determined by the module 40 of
In a step 66, the server 30 retrieves context data from the prediction of content, which may be obtained by the module 40 from the module 38.
In a step 68, the server makes a determination as to whether or not additional context data is desirable, given the context of the user device.
If it is determined that additional context data is desirable, then in a step 70 the server 30 transmits a request for further context data for the context. In a step 72 the server 30 receives the further context data based on the request.
After step 72, and if in step 68 it is determined that no additional context data is desirable, the process moves on to step 74.
In step 74, each predicted context data for the predicted context is associated with a time instant of the predicted context.
In step 76, a user profile for the user of the user device 2 is accessed.
In step 78, the server 30 prepares recommendations for the user. The recommendations are prepared based on the access user profile, and the context data at the time instance.
In step 80, at a given time instant, the prepared recommendations are transmitted to the user device. It should be noted that the recommendations are transmitted at a recommendation time instant, which may not be the same as the time instant with which the context data itself is associated.
For example, if a user is conducting a journey and the predicted context data indicates that they will pass the Opera House at 12:05, a piece of content which could be recommended to the user is a video presentation about the opera. In general, therefore, the recommendation engine may recommend this piece of video content at the point in which the user will pass the Opera House, at 12:05.
However based on the access of the user profile, the recommendation may determine that the user is particularly interested in opera. As such, the recommendation engine will recommend this video at a period of time so that it is completed before the user passes the Opera House. Therefore the recommendation engine may recommend the video at 11:45. If the user accepts the recommendation and watches the video, then the video may be completed before 12:05, at which point the user may be able to stop at the Opera House and buy tickets.
Thus it will be understood that context data is associated with a time instance, but the recommendation of an item based on context data is not limited to a recommendation at that time instance. The recommendation, which may be made at a recommendation time, may be based on context data which is associated with a future instance in time. The recommendation time and the time instance associated with context data do not have to be the same.
This description discloses a content delivery system that interacts with an external application such as a transportation application.
There are many applications for smart devices that control or support a passenger travelling from one location to another.
The most prominent example of this type of application are navigation systems that run on a smart device or within the car on a separate potentially dedicated device. As a special case, it is also possible to envisage a navigation system that runs on the processor of the car itself and is therefore an integral part of a “connected car” operating system.
Another slightly different candidate are those platforms that offer the transportation itself—a good example of this is a cab hailing App which may generally be referred to as a transportation App.
The common characteristic of these applications is that for all of them a person intends to go from one place to the other within a car, or some other type of transportation system. In that respect the application can predict where a passenger will be at approximately what time during the extent of the journey.
In addition to this it is acknowledged that the passenger would like to get some sort of entertainment from their smart devices during the journey. That means the person would like to watch videos, hear music, play games or even read articles. Other types of engagement might be applied as well such as bite-sized educational packages of content or condensed books.
In general therefore, we can see that there are situations in which certain aspects of a user's environment are constrained for an estimated period of time, which in turn provides cues for improvements to the way in which content is recommended for them.
Examples of constraints on the user's environment include, but are not limited to, location, access to other media outlets, access to power sources etc. Furthermore, examples of time periods during which constraints might be in effect include, but again are not limited to, journeys taken within vehicles or other modes of transportation; waiting in a queue for another service; etc.
The user may have limited opportunity to affect the time period for which the constraints are in effect—for example: they may give new or explicit directions to the cab driver such that the journey time changes; they may leave the queue; they may defer an activity such that the time is curtailed; etc. However in general, the time period is determined by the environment.
The idea here therefore deals with the opportunity to infer content recommendation preferences based on a knowledge of the way in which a user's environment is constrained over time.
It is to mention that the idea is not limited to a scenario in which the user is moving from one place to another. It can be also applied to a scenario where the user is at a fixed location but for a known time and duration.
It is known that many kinds of content delivery system, e.g. video-on-demand systems, work on the basis of recommendation systems. Those systems use information about the person inferred from the profile of the user to drive respective recommendations. The context of a user may be taken to drive a better recommendation. Examples here are the mood of a user, the time of a day or the knowledge of who is joining the person.
The techniques described here however go further as it actively takes into account information that is determined by an external system. In a first approach separated application and/or requests from this separate application further inferred information to drive recommendation as well as offer an extended way of engaging with a content delivery system. Again, the content delivery system is a candidate of a software Application on which the idea can be applied to, there might be also different Apps that can be envisioned.
The following sets out some use cases of this technique.
The user requests a cab ride by using a transportation App. This information is used by the content delivery system to manage and propose a content selection which is presented to the user during the trip.
Different from just using actual GPS information and the current time known from the smart device itself, the technique here offers much more as it knows and can infer the time, duration, destination and location of a user in advance. That information can then be used to present appropriate content accordingly.
Examples are special places and locations which the user will pass along during the ride. Knowing what the user will pass in a few moments, the content delivery system can provide information like: “You will pass the opera building on the left side in 200 m. Would you like to see the information about today's evening show?”
Another example of such announcement would be: “You will pass the local shopping center on the right side in 500 m. They have some offers in the sports department today”.
Information about the user profile and the user preferences in relation to places and events across the driven route can be used to reveal a targeted content recommendation like targeted advertisement/promotion during the trip.
The content delivery system with its known user profile and preferences in combination with the external inferred information about places/location while driving can be nucleus for targeted interest and therefore for targeted advertisement.
Moreover if applying a certain radius along the planned route, possible points of interests can be inferred and used for further information and content recommendation that are related to such points of interests.
If the user of the content delivery system is engaging with such items the content delivery system can proactively suggest places to visit as they may represent a good match for the user and once acknowledged by the user send this request back to the transportation App to change the route accordingly.
The point is that the content delivery system gets inferred information from the transportation app which cannot be inferred by the content delivery system alone or just by sensors of the smart device in advance, and the content delivery system can present or even recommend assets and items corresponding to those information in a most aligned way.
In addition to the information of where the user will be within e.g. the next minutes, the information about the duration in which the user can engage with the content delivery system can be used beneficially by the recommendation process as well.
As an example one could envision the ride with the cab, and the transportation App provides the expected time of arrival. This duration then can be used to look for content to watch that fits into that time period as well as—in addition—to schedule a certain catalog of content items that can be watched during that time.
Again, it is not only the duration of the ride that is used as an input to the content delivery system to propose respective content. Together with the time the transportation App might also be used to send additional characteristics, which the content delivery system can consider for recommendation to the user. It may even be preferential to have the vehicle (e.g. a car, but also perhaps a train, plane etc.) be an intermediary between the consumer device and the media server so that existing consumer device apps may have their requests for recommendations modified or the responses cached, shaped or reordered by the constraining environment.
With this interaction of content delivery system and “external application” one can build up a widely configurable level of external input data to the recommendation process. Campaigns can be seen as an example where the external application can propose selected content to watch for promotional purposes—the external app can work similar to an agency together with the content delivery system. The external App knows certain campaigns and—if in line with the preferences of the user—the content delivery system can access and recommend such content items originated by the campaign. Any kind of reward system on top of this considering the external app provider, the content delivery system provider and the user can be applied to. Particularly the external App can uniquely fetch together data for a recommendation process that the content delivery system is generally not providing or has no access to.
An example includes but is not limited to a content delivery system knowing from the user's profile that the user likes Chinese food, the transportation App currently supporting a campaign of a Chinese restaurant chain. The transportation App does know in parallel that one of the restaurants is located close to the user's destination, so it recommends content items like a commercial spot together with a note that such restaurant is nearby and offers xyz.
If the campaign would not match with the preferences of the user, the information would not be shown or proposed.
Again, it is the additional information that comes with the external App, e.g. the transportation App in this use case that is considered as an additional information for recommendation process within a content delivery system that is highly aligned to the actual and current state in which the user is.
Another use case of how the external App and the content delivery system can work together is when assuming that the person has ordered the transportation App or started a journey having put a destination into the car's GPS system. Based on the additional information about the destination, the content delivery system can find out what businesses are at this location. If it is a restaurant, the App could ask if the user is interested in looking to see if any of the restaurants close to the destination would be an alternative to the original restaurant and ask whether the destination of the transportation App or the GPS system should change the destination accordingly. Any kind of post-processing if the alternative proposal is chosen, could be seen as an additional functionality of the recommendation process. That includes but is not limited to the way how the recommendation system learns from the successful proposal. Alternatively there could be concrete incentives for the user if he follows the recommendation, e.g. the restaurant can pick up the cab ride as an incentive to bring the traveler to said restaurant. Restaurants could be invited possibly through a link with “Open Table”. The App could cancel the reservation at the original restaurant.
The interaction between the content delivery system and the external application can be exemplarily described further by separating the process into three sequences. This type of interaction is exemplarily and may not fit to all kinds of content delivery system/external App collaboration. Here the interaction sequence is described by the integration of the content delivery system and a transportation App.
The first sequence is “What is my trip?” Essentially this could be integral part of the external application. The user gives information in advance of the cab trip and sets the level of interaction with the content delivery system. This can be also a default setting or individually configurable. Here the information about destination, time, duration is given, inferred information about weather, campaigns related to the route and destination as well as potential events matching to the trip can be gathered. In another embodiment the user can also enter purpose and/or restrictions of the trip: “Don't give me any route related information”; “show restaurants along the destination”, etc.
The second sequence is “Host my trip”. The goal of “host my trip” is to generate offers and suggestions that are well-aligned with the details of the trip. The details collated within “What is my trip?” are used as an input for the content delivery system to offer and show content and further details around the trip accompanied by related ads or promotions as outlined above. For instance the duration of the trip is calculated to be approximately 15 minutes—a respective sequence of content is inferred which matches to the duration. The knowledge about route and destination is used to provide related information alongside to advertisement and promotions. It is the information package of duration, time, location from the external App together with the known user preferences and profile information that can be used to infer a very specific align package of content items that the user can consume.
The third sequence is “Leverage from the trip”. This part of the technique deals with the opportunity that the engagement with recommendation and offers provided by the content delivery system can also be used to incentivize the user. If the ride is specifically intended for shopping tours, dinners, events, as entered within the “What is my trip?” sequence, this information is used to promote and show up with matching advertisement of “partners” of the platform. One example above mentions restaurants that pick up the cab ride. In the case of a shopping trip, one could imagine that all the businesses in the shopping center extend an offer to pay the ride if you end up buying merchandise of a certain amount. That means e.g. a shopping mall in downtown can be visited and the user of the app gets information on products, services, etc. during the ride to the mall. Slightly different to the use case “Host my trip”, partners of the platform can fund the trip proactively (slightly similar to the refund of parking costs when you buy something in a shop). The user enter e.g. a “shopping trip” to xyz and the trip will be used to survey the user about what he would like to buy, to see, etc. and will do promotions around this or just recommend concrete stores. Similarly this could be done when going out for dinner, etc. A combined payment mechanism of the trip and the partner that funds the trip could complete the whole offering.
Another example of this sequence is that the content delivery system offers a bundle of content items with which the user is asked to engage with. If the user does engage with those items by e.g. performing surveys, answering questions etc., then the fare is reduced by a certain amount accordingly. This kind of incentive might be in particular effective as the information about the trip allows the content delivery system to offer very personalized content items that match the duration and in addition the location of the trip.
Considering both the purposes of “Host my trip” and “Leverage from the trip” the technique also incorporates “gamification” aspects. The knowledge of the route with places along side can be used to provide extended entertainment around puzzles, quiz games etc. related to those places. A combination of commercials related to the places to pass with quiz around those locations and incentives for the user's engagement is one embodiment of the described invention that links external applications and their processes with a content delivery system that can offer recommended content items.
The processes as described are preferably implemented on a remote component such as a server or central system, rather than a user device or a vehicle transporting a user device.
The processes may be implemented on software of a central system or server. The software may be executed by a computer of a central system or server.
The software may be provided on a memory of the central system or server. The software may be provided on a product, such as a USB memory stick, which is accessible to a central system or server.
In general the invention has been described by way of reference to particular examples, embodiments and use cases. One skilled in the art will understand that the invention is not limited to any particular example, embodiment or use case set out hereinabove. In particular one skilled in the art will appreciate that various aspects of the examples given may be combined, and may be implemented either alone or in any combination.
Claims
1. A method of providing a recommendation to a user of a user device, comprising:
- receiving a prediction of a context of the user;
- in dependence on the predicted context identifying context data for the prediction;
- providing one or more recommendations to the user in dependence on the predicted context data.
2. The method of claim 1 further comprising deriving context data from the prediction.
3. The method of claim 1 or claim 2 further comprising identifying desirable context data from the context, and requesting said context data if it is not derivable from the prediction.
4. The method of claim 3 wherein the context data is requested from an external source.
5. The method of any one of claims 1 to 4 further comprising receiving the prediction of the context of the user from an external source, which external source additionally provides context data for the prediction.
6. The method of any preceding claim wherein the context is associated with a time period and/or at least one location.
7. The method of claim 6 wherein the context data indicates a location at one or more time instances within the time period.
8. The method of any preceding claim further comprising, for at least one context data, identifying a time instance associated with that context data, and presenting recommendations based on the context data and its associated time instance.
9. The method of claim 8 further comprising presenting recommendations based on the context data and its associated time instance at a recommendation time in advance of the time instance associated with the data context.
10. The method of claim 8 further comprising presenting recommendations based on the context data and its associated time instance at a recommendation time corresponding to the time instance associated with the data context.
11. The method of any one of claims 8 to 10 wherein multiple context data are associated with a time instance.
12. The method of any one of claims 8 to 11 further comprising presenting a recommendation based on the multiple context data.
13. The method according to any one preceding claim further comprising accessing a user profile, and providing the one or more recommendations based on the accessed user profile.
14. The method of any preceding claims, further comprising:
- receiving an identification of actual context data for the user device;
- comparing the actual context data to the predicted context data; and
- adjusting one or more recommendations thereon.
15. The method of claim 14 wherein the prediction of context data and the identification of actual context data are received from the same source.
16. The method of any one of claims 4 to 11 wherein the source is a navigation application.
17. A computer program which, when executed on a computer, performs the method of any one of claims 1 to 16.
18. A computer program product for storing a computer program according to claim 17.
19. A recommendation engine comprising:
- an interface for receiving a prediction of a context of a user;
- a processor configured to: predict context data for the context prediction; provide one or more recommendations for the user in dependence on the predicted context data,
- wherein the interface is further configured to transmit the one or more recommendation to a user device of the user.
20. The recommendation engine of claim 19 wherein the processor is further configured to identify desirable context data for the context.
21. The recommendation engine of claim 20, wherein if the desirable context data is not retrievable from the context, then the processor is configured to request the desirable context data via the interface.
22. The recommendation engine of any one of claims 19 to 21 wherein the interface is configured to receive the prediction of the context of a user from the user device.
23. The recommendation engine of any one of claims 19 to 22 in which the processor is further configured, for at least one context data, to identify a time instance associated with that context data, and determine recommendations associated with the context data at the associated time instance.
24. The recommendation engine of any one of claims 19 to 23 wherein multiple context data are associated with the time instance, the processor further being configured to determine recommendations for the time instance based on the multiple context data.
25. The recommendation engine of claim 23 wherein the processor is configured to generate recommendations based on the context data and its associated time instance at a recommendation time in advance of the time instance associated with the data context.
26. The recommendation engine of claim 23 wherein the processor is configured to generate recommendations based on the context data and its associated time instance at a recommendation time corresponding to the time instance associated with the data context.
27. The recommendation engine of any one of claims 23 to 26 wherein multiple context data are associated with a time instance.
28. The recommendation engine of any one of claims 8 to 11 wherein the processor is configured to present a recommendation based on the multiple context data.
29. The recommendation engine according to any one preceding claim wherein the processor is configured to access a user profile, and provide the one or more recommendations based on the accessed user profile.
30. The recommendation engine of any preceding claims, wherein the processor is configured to:
- receive an identification of actual context data for the user device;
- compare the actual context data to the predicted context data; and
- adjust one or more recommendations thereon.
31. The recommendation engine of claim 10 wherein the interface is configured to receive the prediction of context data and the identification of actual context data from the same source.
32. The recommendation engine of any one of claims 4 to 11 wherein the interface is configured to receive prediction of context data and actual context data from a navigation application.
Type: Application
Filed: Feb 1, 2017
Publication Date: Feb 28, 2019
Inventors: Philip Shaw (York), Peter Heiland (Dover, MA), Hans-Jurgen Maas (Mainz), Sean Everett (New York, NY), Ralf Tillmann (Mannheim)
Application Number: 16/074,622
