Patent Application
20170316064
Computers and smartphones have become ubiquitous in today's society. These devices are designed to run software applications, which interact with computer hardware to perform desired functions. For instance, software applications may perform business applications, provide entertainment, facilitate turn-by-turn navigation, and perform many other types of tasks. In some cases, software applications may be designed to interact with other computing systems. Such communications can occur over different types of radios which are integrated into devices such as smartphones. Using such communications, computers and other devices can access vast stores of information. This information may be used in a variety of contexts including machine learning, analytics and big data applications.
Embodiments described herein are directed to providing event context assistance. In one embodiment, a computer system detects the occurrence of a specified event that has an associated level of priority. The computer system determines that the level of priority for the specified event is sufficient to trigger retrieval of data from one or multiple data stores, and further evaluates the specified event using the retrieved data to create an event data structure that provides relevant contextual information related to the specified event. The computer system then provides the created event data structure to a user or other entity.
In another embodiment, a graphical user interface is provided on a computer system. The graphical user interface (GUI) includes the following: an event context investigation overview that allows users to view and evaluate contextual information related to an event, a first event element representing the event, where the first event element has information identifying the event, and a second event element that includes various interactive elements that allow a user to drill down into contextual information displayed in the event element to identify additional contextual information related to the event. The computer system providing the GUI tracks inputs provided by the user to determine which event elements are selected by the user and which contextual information is determined to be relevant to the user. This allows future event elements to be custom generated and/or custom sorted or arranged for the user based on the tracked inputs.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Additional features and advantages will be set forth in the description which follows, and in part will be apparent to one of ordinary skill in the art from the description, or may be learned by the practice of the teachings herein. Features and advantages of embodiments described herein may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the embodiments described herein will become more fully apparent from the following description and appended claims.
To further clarify the above and other features of the embodiments described herein, a more particular description will be rendered by reference to the appended drawings. It is appreciated that these drawings depict only examples of the embodiments described herein and are therefore not to be considered limiting of its scope. The embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Embodiments described herein are directed to providing event context assistance. In one embodiment, a computer system detects the occurrence of a specified event that has an associated level of priority. The computer system determines that the level of priority for the specified event is sufficient to trigger retrieval of data from one or multiple data stores, and further evaluates the specified event using the retrieved data to create an event data structure that provides relevant contextual information related to the specified event. The computer system then provides the created event data structure to a user or other entity.
In another embodiment, a graphical user interface is provided on a computer system. The graphical user interface (GUI) includes the following: an event context investigation overview that allows users to view and evaluate contextual information related to an event, a first event element representing the event, where the first event element has information identifying the event, and a second event element that includes various interactive elements that allow a user to drill down into contextual information displayed in the event element to identify additional contextual information related to the event. The computer system providing the GUI tracks inputs provided by the user to determine which event elements are selected by the user and which contextual information is determined to be relevant to the user. This allows future event elements to be custom generated for the user based on the tracked inputs.
Embodiments described herein may implement various types of computing systems. These computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be mobile phones, electronic appliances, laptop computers, tablet computers, wearable devices, desktop computers, mainframes, vehicle-based computers, head units, tracking devices, and the like. As used herein, the term “computing system” includes any device, system, or combination thereof that includes at least one processor, and a physical and tangible computer-readable memory capable of having thereon computer-executable instructions that are executable by the processor. A computing system may be distributed over a network environment and may include multiple constituent computing systems.
A computing system typically includes at least one processing unit and memory. The memory may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media or physical storage devices. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well. Embodiments described herein may be implemented on single computing devices, networked computing devices, or distributed computing devices such as cloud computing devices.
As used herein, the term “executable module” or “executable component” can refer to software objects, routines, methods, or similar computer-executable instructions that may be executed on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).
As described herein, a computing system may also contain communication channels that allow the computing system to communicate with other message processors over a wired or wireless network. Such communication channels may include hardware-based receivers, transmitters or transceivers, which are configured to receive data, transmit data or perform both.
Embodiments described herein also include physical computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available physical media that can be accessed by a general-purpose or special-purpose computing system.
Computer storage media are physical hardware storage media that store computer-executable instructions and/or data structures. Physical hardware storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computing system to implement the disclosed functionality of the embodiments described herein. The data structures may include primitive types (e.g. character, double, floating-point), composite types (e.g. array, record, union, etc.), abstract data types (e.g. container, list, set, stack, tree, etc.), hashes, graphs or other any other types of data structures.
As used herein, computer-executable instructions comprise instructions and data which, when executed at one or more processors, cause a general-purpose computing system, special-purpose computing system, or special-purpose processing device to perform a certain function or group of functions. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
Those skilled in the art will appreciate that the principles described herein may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, vehicle-based computers, head units, tracking devices,and the like. The embodiments herein may also be practiced in distributed system environments where local and remote computing systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. As such, in a distributed system environment, a computing system may include a plurality of constituent computing systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Those skilled in the art will also appreciate that the embodiments herein may be practiced in a cloud computing environment. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations. In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.
Still further, system architectures described herein can include a plurality of independent components that each contribute to the functionality of the system as a whole. This modularity allows for increased flexibility when approaching issues of platform scalability and, to this end, provides a variety of advantages. System complexity and growth can be managed more easily through the use of smaller-scale parts with limited functional scope. Platform fault tolerance is enhanced through the use of these loosely coupled modules. Individual components can be grown incrementally as business needs dictate. Modular development also translates to decreased time to market for new functionality. New functionality can be added or subtracted without impacting the core system.
Referring to the figures,
For example, the computer system 101 may be configured to interact with user 113 and/or mobile device 114. In some embodiments, the user 113 interacts with computer system 101 using mouse, keyboard, touch gestures, or other forms of input. In such cases, the computer system 101 may be, for example, a desktop computer and the user 113 may be a driver, administrator, or fleet manager. Still further, the user 113 could be an insurer, third party clearing house or any other type of user. In some cases, the user 113 may interact with the computer system 101 through the mobile device 114 (e.g. a smart phone, tablet, laptop, wearable device or other computer system). The mobile device 114 may be an extension of the computer system 101, or may itself be the computer system 101.
In some embodiments, the computer system 101 includes a communications module 104 with a hardware transceiver, as well as an event detector 105 configured to detect the occurrence of specified events (e.g. 116). These specified events may have an associated level of priority 117. As used herein, the terms “event” or “specified event” refer to something that has happened and can be quantified as an event. An event may occur in different contexts, and within those contexts the event may have a different priority level.
For instance, in the field of vehicle traffic, an event may be a wreck, a traffic jam, a departure, an arrival or other event. Each wreck, traffic jam, departure or arrival may include its own priority level. For example, in some cases, a fleet manager may note the arrival and departure times of semi-trucks or company vehicles. Other information associated with the event, such as the time 118 the event occurred, or the location 119 of the event 116, may be noted in addition to the event. This additional information may be stored in a data store (e.g. stored data 121) such as database 120.
The database 120 may be a single database, or multiple databases, each of which may be local or remote, and can include a cloud database. In some cases, for example, the computer system 101 may communicate with a weather database and a separate traffic database. Each database may use its own data format or storage schema. When receiving and implementing this data (e.g. in the creation of an event report), the computer system 101 may change data formats and/or schemas to combine the data into a data type understood by the computer system 101 and/or the database 120.
It will be understood that many different events and different types of events may be documented and stored using system 100 of
In the embodiments herein, traffic data 122 or traffic flow data may refer to information indicating how the traffic was flowing prior to the event, or exactly at the time of the event, or at any period prior to the event. If the event occurs at an intersection, the traffic flow data 122 may indicate the flow of traffic through that intersection, it may indicate the volume of traffic at the time of the event or it may indicate unusual patterns associated with traffic flow at that intersection. The historical data 123 may indicate which events have occurred in the past at a particular location, or at a particular time or with a particular vehicle or driver. The historical data may provide insight on whether similar types of events have occurred before at that location or at other locations such as nearby intersections. The weather data 124 may indicate the status of the weather in the location of the event at the time of the event. The weather data 124 may include actual weather readings (such as temperature, wind speed, precipitation, humidity, visibility conditions, etc.) as well as forecasted weather information or historical weather information.
Analytics data 125 may represent analytical analysis of the current event and/or past events. The analytics data 125 (as well as any of the other data) may be provided by a third party such as a company or government entity. The analytics may provide statistical or other analyses of the event or similar events, and may be used to show patterns or anomalies. The logistics data 126 may include, for traffic events, vehicle information including vehicle type (e.g. year, make and model), vehicle service records (e.g. indicating whether brakes and tires are operating within expectations), indications of whether the vehicle was towing a trailer, indications of passengers on board, cell phone use, speed and direction of the vehicle, and other factors. The live feed data 127 may include video data from an intersection camera or smart phone, video data from an in-vehicle camera or smart phone, audio feed data from a cell phone or other device with a microphone, satellite data or other types of live feed data. Each type of data may provide information that may be useful to different users in reviewing the event.
This information, however, may have different levels of importance or priority to different users. As such, the priority verification system 106 of computer system 101 is configured to determine the priority level for any given event. In some cases, the priority level 117 is specific to a given user, indicating which types of information that user believes are important in conjunction with that event. The priority verification system 106 may be set up so that information associated with the event is not retrieved at the occurrence of each event. Rather, the priority verification system 106 may determine whether the level of priority for a given event 116 is sufficient to trigger retrieval of data from the database 120.
For instance, using historical inputs 115 from user 113, the priority verification system 106 may assess whether the user has viewed similar events in the past, or whether the user has skipped or ignored those events. If the priority verification system 106 determines that the user has historically been interested in events such as event 116, it may determine that the priority level is high enough to retrieve stored data 121 from the database 120. The user's historical inputs may also be used to determine which types of stored data 121 to retrieve. Absolute settings may be used to override the priority verification system and may allow default mandatory events to be defined and may allow related information to be retrieved.
For example, if the user 113 is typically interested in live feed data 127 and analytics data 125, those portions of data will be retrieved, and other data will not. This leads to increased efficiencies in data transfer and processor cycles in the database 120, as less data will be accessed and less data will be transferred. Various events, inputs, or contextual elements may act as triggers for data retrieval. Once a trigger has occurred, and the priority verification system 106 has determined that the appropriate level of priority exists, the data is retrieved. Thus, the priority verification system 106 can act as a gatekeeper, determining when the priority level 117 is high enough for event 116 to warrant retrieval of stored data 121 in the database 120.
The data evaluation system 107 of computer system 101 is configured to evaluate the event 116 using the retrieved data. Thus, in cases where the priority level 117 for the event 116 is high enough to warrant the retrieval of associated data 121, the event data structure generator 108 of the data evaluation system 107 evaluates the event 116 to create an event data structure 109. The event data structure 109 provides one or more portions of relevant contextual information 110 associated with the specified event. The relevant contextual information 110 is a subset of the stored data 121. Thus, the data evaluation system 107, in conjunction with the data relevance evaluator 111, may determine which contextual information 110 is important to the user 113 and which is most relevant to the user. The data evaluation system 107 may then access that subset of data to be included in the event data structure 109.
Accordingly, in some cases, based on the determined level of relevancy 112, the relevant contextual information 110 may include portions of weather data 124, logistics data 126 and live feed data 127, while in other cases, the relevant contextual information 110 may include traffic data 122 and historical data 123. Indeed, it will be understood that the relevant contextual information 110 may include substantially any subset (or all) of the stored data 121. This data may be combined and displayed in various ways, as will be shown in
For example, the event data structure 109 with its corresponding relevant contextual information 110 may be electronically sent to the provisioning module 128 of computing system 101. The provisioning module 128 may be configured to provide the created event data structure 109 to at least one entity such as user 113 (i.e. to the user's mobile device 114 or to another computer system associated with the user), or to a company or governmental entity. The event data structure 109 may be displayed on the display of the mobile device 114, or may be combined with other data structures to form a larger data structure that is usable by other applications to present or incorporate the relevant contextual information 110 of the event. In some cases, as will be described further below in
In some embodiments, a configurable baseline portion of data may be associated with each event. This baseline data may include the time 118 of the event or the time span of the event, and the location 119 of the event, or any other information that may be associated with the event. The time and location data may represent information that is associated with the occurrence of each event, although they do not need to be noted if such is desirable. As mentioned above, other contextual data associated with the event 116 may be stored in a data store such as database 120. Some of that data may be retrieved for each event that has a sufficient threshold level of priority 117 (i.e. is determined to be of sufficient importance to the user 113). The retrieved data is the relevant contextual information 110. That information may itself have a determined level of relevancy, and may be presented to the user 113 according to the level of relevancy 112. Indeed, when events occur, each event may be filtered by its determined level of relevancy. Various relevancy classifications may be established into which events are categorized. In one example, the relevancy classifications may include graded levels such as “low relevancy,” “medium relevancy,” and “high relevancy.” Many other relevancy classifications may be used.
As shown in
Additionally or alternatively, the data may be retrieved from an internal source 302 such as a telematics service 305. Such data may include analytics (e.g. 125), reports, historic data (e.g. 123), etc. Still further, the data may be from external sources 303 and may include corporate data 306 such as user internal data (e.g. human resources information), vehicle and training records, business intelligence and logistics systems (e.g. 126), etc., or may be from third party services 307 including third party web services, third party surveillance devices such as intersection cameras, etc. Thus, it can be seen that the type and/or source of data for the stored data 121 of
For instance, user 211 may provide one or more inputs 212 indicating that the user would like to view certain portions of contextual information related to an event. The event context investigation overview 202 may present many different portions of information (e.g. stored data 122 from
Each of the event elements may have its own interactive elements. For instance, the GUI 201 may include a first event element 204 that represents a certain event such as a traffic accident. The first event element 204 has information identifying the event (i.e. event identification information 205), as well as an interactive element 206 that allows user interaction. For example, the interactive element 206 may be a button, a check box, a data entry field or any other selectable element that allows user interaction. The GUI 201 may further include a second event element 207 that includes interactive elements such as interactive element 208. The interactive element 208 allows the user 211 (e.g. a fleet manager) to drill down into contextual information displayed in the event element to identify additional contextual information related to the event.
Thus, at least in some embodiments, the interactive elements (e.g. 206 and 208) may allow further interaction with other elements. For instance, as will be described in greater detail with regard to
At a high level, the weather may simply indicate the type of weather that was being experienced in the city where the event took place. Drilling down may provide more detailed information including wind speed, humidity, precipitation levels, or even live-feed data showing the weather of the actual location where the event occurred at the time of the event. The detailed information may allow for specialists to model or analyze the event situation in a post-event analysis in a similar manner. This analysis may be based on the same or even more accurate data (e.g. because weather samples are taken closer to the time of the event) than is normally used in pre-situation predictions and modeling (e.g. forecast and prediction modeling of black ice, fog, rain or other weather situations).
Similarly, other event elements may provide different types of data (e.g. any of stored data 121 available in database 120 or available through third parties), and different levels of granularity for that data. Thus, the user 211 can interact with the GUI 201 to drill down into the lower layers of data when interested in that data.
Over time, the computer system tracks inputs 212 provided by the user 211 to determine which event elements (e.g. 204) are selected by the user and which contextual information 203 is determined to be relevant to the user. This allows future event elements to be custom generated for the user based on the tracked inputs. For instance, as shown in
In some embodiments, one or more of the event elements representing the event may be a reviewable card. As shown in
Thus, at least in some cases, the first, second, third (or whatever number of event elements have been created (e.g. event elements 204, 207 and 209 of
Many different reviewable cards may be presented to the user in the user interface. Reviewable card 402, for example, provides weather information, as indicated by the rain, cloud and sunshine graphics. Reviewable card 403 provides speed limit information and/or vehicle speed information, as indicated by the speed limit sign. Reviewable card 404 provides traffic data, as indicated by the picture of the three vehicles. Each of these pictures, graphics and text may be customized by the user to their liking. In some cases, the interactive elements on the reviewable cards may include a forward button that allows users to forward the reviewable card to one or more other users, or send or select the card to be embedded in any form of report. For instance, user 211 may think that a specific reviewable card is noteworthy, especially for a given event. The user may, in such cases, forward the reviewable card to another user via email, text message or some other information transfer means.
Additionally or alternatively, the interactive elements of the reviewable cards may include a save button that allows users to save the reviewable card in a data store. For instance, a user may wish to save one or more of reviewable cards 401-404, in relation to a particular event. Those reviewable cards may be saved in the database 120 or in some other data store. The reviewable cards may be saved in a manner that links the cards to a specific event or group of events. As such, the user may build up a collection of reviewable cards related to different events, which can be accessed later when needed.
As the user builds their collection of reviewable cards, the computer system 101 (or the mobile device of the user 114) may keep track of which cards have been saved by the user, and may learn which types of information the user prefers to view and store. Over time, the user's preferences and interactions with the system may be stored in a data structure. The stored data structure may be referenced when determining whether to present data and which data to present. In some cases, one or more preset settings may be implemented for a user regarding preferences, relevancy levels, etc. As user inputs are received over time, the preset settings may be modified according to learned user preferences.
These learned preferences may also provide a level of relevancy (e.g. 112 of
As the user selects different cards, an event report 405 may be generated based on which reviewable cards are selected. The event report 405 may include a pre-defined report template which is populated with information from the selected reviewable cards (e.g. 401-404). The event report 405 shown in
This initial event report 505A may be displayed to the user with little to no learning of the user's preferences. Over time, the computer systems and embodiments described herein are capable of learning the user's preferences (510). As such, after time has passed, a different event report may be generated, even though the same event type has occurred. Indeed,
In view of the systems and architectures described above, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow chart of
Method 600 includes detecting the occurrence of at least one specified event, wherein the specified event has an associated level of priority (610). For example, the event detector 105 may detect that event 116 has occurred. The event 116 has an associated priority level 117 and potentially other information including the time 118 of the event and the location 119 of the event. The priority verification system 106 determines that the level of priority 117 for the specified event 116 is sufficient to trigger retrieval of data 121 from one or more data stores (e.g. 120) (620). If the priority level 117 is at least a threshold minimum amount, the computer system 101 will request the transfer of data from the database 120. If the priority level does not meet this threshold minimum, then data will not be retrieved. This can save processing resources as well as bandwidth resources between the database 120 and the computer system 101.
Method 600 further includes evaluating the specified event 116 using the retrieved data to create an event data structure 109 that provides one or more portions of relevant contextual information 110 related to the specified event (630). The event data structure generator 108 may generate the event data structure 109 once the data evaluation system has evaluated the data retrieved from the database 120. The event data structure 109 includes contextual information 110 that is relevant to the event 116. A data relevance evaluator 111 may be used to determine the level of relevancy 112 for a given event. The level of relevancy 112 may be specific to a given user, as each user may assign different weigh to different types of contextual information. This level of relevancy 112 may be refined and honed over time as the user provides inputs to the system, selecting different types of information for different events.
Method 600 also includes providing the created event data structure 109 to at least one entity (640). The provisioning module 128 of computer system 101 may provide the event data structure 109 to user 113 via the mobile device or via some other computer system. The event data structure may be transferred to other computer systems via a wired or wireless computer network, and may be displayed on a monitor or touchscreen, allowing user interaction therewith.
As mentioned above, the contextual information 110 may include substantially any type of information that is useful to the user 113 and is in any way related to the event. The contextual information 110 may be a subset of the entire set of information stored in the database or in external or third party databases. The contextual information 110 may include historical data 123 including driver behavior, vehicle utilization, driver license status, driving history (e.g. number of past tickets), driver education status (e.g. whether the driver has taken advanced educational or practical driving courses), weather data 124, traffic data 122, analytics data 125, logistics data 126, live feed data 127 (e.g. camera surveillance video, traffic light status, on-board telematics data from vehicles, etc.), corporate data (e.g. from a fleet of vehicles), data from third party services, or other types of data which may be useful in providing context for an event.
In some cases, the provisioning module 128 may provide the generated data structure 109 to at least one entity by presenting the data structure on a display (e.g. display 501A of
The data relevance evaluator 111 of the computer system 101 may determine a level of relevancy 112 for the contextual information 110 related to the specified event. The level of relevancy 112 may be based on which information the user has viewed in the past, which information the user has saved in the past, which information the user has forwarded or shared with other users in the past, or based on other interactions with the stored data 121. In some cases, the level of relevancy 112 for the contextual information 110 may be determined using indications of which contextual information was relevant to prior events. For example, if the weather was bring and sunny during an event, the weather may not be relevant, whereas if the weather was foggy or snowy, weather may be highly relevant if the event is an automobile accident. Accordingly, the level of relevancy may be based on factors other than user interaction. Indeed, the level of relevancy may be based on the data itself and how objectively relevant it is to the event.
In one embodiment, at least one indication of which contextual information 110 was relevant to a prior event includes an indication of user behavior at a prior event. The system may show representations of what the user has actually selected in the past. The relevancy is thus not determined by the user's position or role or which keywords the user has chosen to receive information about, but rather what the user's behavior has been relative to a given event or type of event in the past. The database 120 may thus keep a record of direct customer preferences based on their selections, as well as inferred customer preferences that are learned over time. The database 120 may store these preferences for a variety of different users, and may apply user preferences to each individual as they use the system to discover contextual information related to an event.
It should be noted that the user's behavior may include all types of interaction with the computer system 101 and/or with their mobile device 114. For example, identifying user behavior related to an event may include identifying which email messages the user looked at, which databases the user accessed, which websites they viewed, which reports the user read, etc. Over time, the system may learn that, for instance, user 113 only cares about drastic changes in weather that cause vehicles not to arrive on time. As such, the relevancy level for weather information, and specifically weather changes that cause vehicles not to arrive on time, is increased. This level of relevancy 112 for that portion of contextual information 110 may be continually refined over time. As such, different event data structures may be provided to the user 113 according to the refined level of relevancy for the contextual information 110.
Continuing this example, when reports are generated, the user 113 would receive a report that emphasized the weather data (or included solely weather data). In this manner, each of a plurality of users may receive a different customized report regarding the same event. Each user will receive a customized report based on their user-specific level of relevancy for each portion of the contextual information. These personalized reports will help the user to quickly and easily view those types of contextual information that are most helpful to that user for that event.
In the embodiment shown in
In some cases, the user may be able to specify a user-defined event. In such cases, the user receives relevant contextual information related to the user-defined event. Such event types may include accident events, delivery events, doctor check-up events, traffic law violation events, non-traditional weather events, or other types of events as specified by the user. If the user is only interested in where the event occurred, that is all the user will see on the reviewable card(s). If the user is solely interested in the event only if video footage is available, the user will not be notified of the event unless video footage is available. Regardless of what the event is, the systems described herein will determine which information to show to the user and how best to show it. If the user is interested in further information, they may simply interact with a reviewable event card or other interactive user interface element to learn more about that event.
Accordingly, methods, systems and computer program products are provided which provide event context assistance. The methods, systems and computer program products learn a user's preferences over time and intelligently provide relevant contextual information to the user in easily readable forms that also allow the user to dig deeper if desired.
The concepts and features described herein may be embodied in other specific forms without departing from their spirit or descriptive characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the disclosure is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
