Patent Description:
Terminal intelligence is an inevitable development trend. Rule matching is an intelligent method. An application can define a lot of rules, and then match an event according to a rule, to provide a recommendation result. However, each application defines rules, performs rule-based matching, and recommends a result on its own. Consequently, a same system resource may be repeatedly invoked by a plurality of applications, causing additional power consumption. For example, various sensor data is obtained.

Document <CIT> Aldescribes an information processing system that can secure anonymity of personal information sent from a terminal to a server from the terminal side. The information processing system is provided with: a means for storing information recommendation rules indicating the level of recommendation priority of each unit of recommendation information presented to a user; a means for generating feedback information for updating the personal information of the user with respect to the information recommendation rules, generating anonymized feedback information by anonymizing the feedback information, and outputting the result; and a means for updating the information recommendation rules using the anonymized feedback information.

Document <CIT> describes a method and an electronic device for video recommendation. The method for video recommendation includes: collecting a device usage habit and interesting contents of a user, and acquiring video information associated with the device usage habit and the interesting contents; dividing the video information into multiple classes of video recommendation information according to a preset classification rule, the video recommendation information comprising an introduction, a name and/or a poster of a video; and pushing a video recommendation information prompt containing the multiple classes of video recommendation information to a user, and displaying the video recommendation information prompt at a preset position on the screen of a mobile phone of the user. According to the present invention, videos with personalized preferences can be automatically recommended to different users according to personal preferences of usage habits, interesting contents and the like of the users.

Embodiments of this application provide a recommendation method and a terminal, to save system resources and remind a user of a recommendation result. The recommendation result may be some functions of an application, or may be an activity reminder, making the terminal more intelligent. The present invention is defined by the attached set of claims.

With development of intelligent services, some intelligent reminders or services can be provided on a terminal based on historical behavior habits of a user or based on some rules or models, so that the user can use the terminal more conveniently, that is, making the user feel that the terminal is getting increasingly intelligent.

The terminal can implement various intelligent services by itself or by combining with a cloud. Specifically, the terminal may include a rule platform, an algorithm platform, and a user portrait platform. The terminal can implement, by using one or more of the three platforms and other resources, various intelligent services, for example: <NUM>. service recommendation; <NUM>. reminder service; and <NUM>. notification filtering service.

The following embodiments of this application mainly detail the foregoing second service, that is, the reminder service. The following descriptions of the rule platform, the user portrait platform, and the graphical user interface focus on functions related to the reminder service. The rule platform, the user portrait platform, and the graphical user interface included in the terminal are not limited to the functions described below.

A technical solution of this application provides a rule platform that is included in a terminal. The rule platform is a system-level service, and can obtain data of a system-level application and a non-system-level application on the terminal. The rule platform may provide a unified rule base and a unified personal knowledge base. The rule base implements unified rule matching and life cycle management functions, and implements simplified and easy-to-use rule matching and life cycle management solutions to reduce application development costs. The personal knowledge base provides a unified mobile phone status and user information management mechanism, supports proactive monitoring of system events and passive monitoring of application events, performs rule matching, makes rule matching more reasonable, and reduces system resource consumption. Rules can be updated through a server. After the rule matching is successful, an application is allowed to proactively obtain a recommendation result, and a rule engine is allowed to proactively activate a recommendation result. The recommendation result may be displayed by the terminal, in other words, the terminal reminds a user of the recommendation result, that is, the reminder service.

<FIG> is a system architecture diagram applied to an embodiment of this application. A rule platform <NUM> is included in a terminal, and is a system-level application. The rule platform <NUM> provides an ability to manage and match rules for a plurality of APPs in the terminal. A user portrait platform <NUM>, an application <NUM>, and a graphical user interface <NUM> are also included in the terminal.

Any one or more applications <NUM> in the terminal may register a rule with the rule platform <NUM>, and the rule platform <NUM> stores the rule registered by the application. The rule platform <NUM> may be further connected to a cloud server <NUM>, and can periodically query the cloud server <NUM> for whether any rule is updated, and if a rule is updated, the rule platform <NUM> downloads the updated rule to update the related rule. The rule platform <NUM> may be further connected to the user portrait platform <NUM> in the terminal. The rule platform <NUM> may obtain a user portrait from the user portrait platform <NUM> and store the obtained user portrait. In addition, the rule platform <NUM> may send a detected event to the user portrait platform <NUM>, so that the user portrait platform <NUM> can update the user portrait.

Further, the rule platform <NUM> may include: an interface layer <NUM> and a rule engine <NUM>.

The rule platform <NUM> may request a user portrait from the user portrait platform <NUM>, and then store the obtained user portrait in the personal knowledge base <NUM>. After detecting an event, the rule platform <NUM> may send the detected event to the user portrait platform <NUM>, and the user portrait platform <NUM> may update the user portrait based on the newly received event, and send an updated user portrait to the rule platform <NUM>.

The interface layer <NUM> may further send the event to the rule status unit <NUM>. The personal knowledge base <NUM> may further record a condition matching status. After the rule status unit <NUM> matches the obtained event with a condition of the related rule, if the matching is successful, a successful matching state is recorded in the personal knowledge base <NUM>, that is, the condition matching status is stored in the personal knowledge base <NUM>. In other words, a recommendation result is output only after a rule meets one or more conditions. For example, when one or more detected events are matched with one or more conditions of a rule, a status of the condition or conditions can be recorded as "matched". Then, other events are received to determine whether other conditions of the rule are matched. If all the conditions are matched, a state of the rule in the rule status unit <NUM> is "matched", and a recommendation result can be output to the application <NUM>.

The personal knowledge base <NUM> may further record a period status of a rule related to the event, obtained from the rule status unit <NUM>. After a rule is matched, a period status of the rule may be recorded correspondingly. For example, a recommendation result is output once every five days after the rule is matched. In this case, after the rule is matched, the rule enters a sleep period, and enters an active state again five days later. It should be understood that, during the five days, even if a detected event matches the rule, no recommendation result is output because the rule is still in a sleep state.

(<NUM>) The rule status unit <NUM> is configured to receive an event sent from the interface layer <NUM>. The rule status unit <NUM> may obtain a rule related to the event from the rule base <NUM> to update a status. If states of all conditions of a rule in the personal knowledge base <NUM> are "matched", the rule status unit <NUM> records a state of this rule as "matched", and the rule status unit <NUM> may output a recommendation result corresponding to the rule to any one or more applications <NUM>.

(<NUM>) The recommendation result candidate set <NUM> may store a corresponding recommendation result after a rule is matched, and the application <NUM> may obtain one or more recommendation results from the recommendation result candidate set <NUM> for display.

In an embodiment of this application, <FIG> is a schematic diagram of an embodiment of a terminal. The terminal includes a rule platform <NUM> and a graphical user interface <NUM>. The rule platform <NUM> includes an interface layer <NUM> and a rule engine <NUM>. The rule engine <NUM> includes a rule base <NUM>, a personal knowledge base <NUM>, and a rule status unit <NUM>.

The rule base <NUM> includes at least one rule, and each rule includes at least one condition.

The interface layer <NUM> is configured to obtain a first event.

The rule status unit <NUM> is configured to: obtain at least one rule related to the first event from the rule base <NUM>, update a matching status of a first condition corresponding to the first event in the at least one rule related to the first event, and record the matching status in the personal knowledge base <NUM>; and is further configured to: when a matching status of each condition in a first rule indicates that matching is successful, output a recommendation result corresponding to the first rule.

The personal knowledge base <NUM> is configured to store the first event, and the matching status of the first condition in the at least one rule related to the first event.

The graphical user interface <NUM> is configured to display the recommendation result.

Optionally, in some embodiments of this application, the interface layer <NUM> is further configured to receive the first rule sent by a first application, and store the first rule in the rule base <NUM>.

Optionally, in some embodiments of this application, that the rule status unit <NUM> outputs a recommendation result corresponding to the first rule includes: the rule status unit <NUM> sends the recommendation result to a second application.

The graphical user interface <NUM> is specifically configured to display the recommendation result by the second application, where the second application is the same as or different from the first application.

Optionally, in some embodiments of this application, <FIG> is a schematic diagram of another embodiment of a terminal. The rule engine <NUM> further includes a recommendation result candidate set <NUM>. That the rule status unit <NUM> outputs a recommendation result corresponding to the first rule includes: the rule status unit <NUM> outputs the recommendation result to the recommendation result candidate set <NUM>. The graphical user interface <NUM> is specifically configured to display the recommendation result obtained by the second application from the recommendation result candidate set <NUM>, where the second application is the same as or different from the first application.

Optionally, in some embodiments of this application, <FIG> is a schematic diagram of another embodiment of a terminal. The terminal further includes a user portrait platform <NUM>, and the first rule includes a second condition related to a user portrait <NUM>. The personal knowledge base <NUM> is further configured to obtain a current user portrait from the user portrait platform <NUM> of the terminal; and update a matching status of the second condition based on the current user portrait.

Optionally, in some embodiments of this application, the rule base <NUM> is further configured to receive, through the interface layer <NUM>, an updated rule sent by a server, and update a rule related to the updated rule in the rule base <NUM>.

In this application file, the rule platform <NUM>, the user portrait platform <NUM>, and the like may all be implemented on the terminal. The terminal may include: a mobile phone, a tablet computer (tablet personal computer), a laptop computer (laptop computer), a digital camera, a personal digital assistant (personal digital assistant, PDA for short), a navigation apparatus, a mobile internet device (mobile internet device, MID), a wearable device (wearable device), and the like.

The following embodiments further describe the technical solutions in this application. <FIG> is a schematic diagram of an embodiment of a recommendation method according to an embodiment of this application. The recommendation method includes the following steps.

Step <NUM>. An application <NUM> registers a rule with a rule platform <NUM>.

Any one or more applications, or all applications on a terminal may register a rule with the rule platform <NUM>, and a function engine <NUM> in the rule platform <NUM> may store the rule registered by the application to a rule base <NUM> for centralized management. To be specific, the APPs may register respective rules with the rule engine <NUM> by using an Android interface definition language (Android Interface Definition Language, AIDL) interface provided by the rule engine <NUM>, and the rule engine <NUM> stores the rules registered by the APPs to the rule base <NUM>. Each application may register one or more rules with the rule platform <NUM>.

Rules included in the rule base <NUM> may be classified into a rule defined in an application and a user-defined rule. The user-defined rule is also actually implemented on the application, and this application may be referred to as a custom application. To be specific, a plurality of match conditions and recommendation results may be defined in the custom application, where the plurality of match conditions and recommendation results may be displayed on a display interface of the terminal; and then a user may select a target match condition and a corresponding target recommendation result based on a requirement of the user, so as to generate a customized rule. It should be understood that, the rule base <NUM> includes at least one rule, and each rule includes at least one condition.

Further, the plurality of match conditions and recommendation results may be classified by type. For example, <FIG> and <FIG> are a schematic diagram of displaying a plurality of match conditions in a display interface on a terminal. Match condition types may include time, location, weather, temperature, work, life, study, and the like, and each match condition type may further include a plurality of match conditions. For example, <FIG> and <FIG> are a schematic diagram of displaying a plurality of recommendation results in a display interface on a terminal. Recommendation result types may include food, hotel, entertainment, take-out, travel, study, and the like, and each recommendation result type may further include a plurality of recommendation results. The plurality of match conditions and the plurality of recommendation results are available for the user to select, so as to generate a user-defined rule.

For example, <FIG>, <FIG>, and <FIG> are a schematic diagram of selecting a target match condition and a target recommendation result by a user. When selecting a target match condition and a target recommendation result of a rule, the user may drag to display the target match condition and the target recommendation result on a display interface, and then tap an icon such as OK or Generate Rule to generate the user-defined rule.

Alternatively, <FIG>, <FIG>, and <FIG> are a schematic diagram of selecting a target match condition and a target recommendation result by a user. The user selects a target match condition or a target recommendation result, and the target match condition/target recommendation result is added into a thumbnail icon. After the thumbnail icon is tapped, the target match condition and the target recommendation result of the rule are displayed. A display position of the thumbnail icon on the display interface is not limited, and the thumbnail icon may rotate, be added with a text prompt, be highlighted, or have its frame flashing, to remind the user.

It should be noted that, the rules stored in the rule base <NUM> may be updated. The terminal may send a query request to a server <NUM>, where the query request is used to query whether any rule is updated; the terminal receives an updated rule sent by the server <NUM>; and the terminal updates a rule related to the updated rule in the rule base <NUM>. Optionally, after any one or more applications <NUM> are upgraded, the upgraded application registers a rule with the rule platform <NUM>, where the rule may include an updated rule; and updates all rules related to the updated rule in the rule base <NUM>. Alternatively, the application is not upgraded, but the application sends an updated rule to the server <NUM>; the server <NUM> may store the updated rule; and the interface layer <NUM> in the rule platform <NUM> may periodically query the server <NUM> whether any rule is updated, and if a rule is updated, downloads the updated rule from the server <NUM>, and updates all rules related to the updated rule in the rule base <NUM>.

It should be understood that, each application does not need to monitor an event; instead, the interface layer <NUM> of the rule platform <NUM> performs centralized management and monitoring. The rule platform <NUM> has system-level permission, can proactively monitor various system events, and can also passively monitor various application events. The application may set various rules. Even if the application does not have system-level permission, the application can write a system parameter as a match condition into a rule, so as to implement corresponding function recommendation. A rule may be any combination of different conditions.

The following uses examples to describe how an application registers rules and manages the rules together to save system resources. It is assumed that a first application registers a rule with the rule engine <NUM> through the interface layer <NUM>, where match conditions of the rule are condition A, condition B, and condition C, and a corresponding recommendation result is performing a first operation; that a second application registers a rule with the rule engine <NUM> through the interface layer <NUM>, where match conditions of the rule are condition A, condition B, and condition D, and a corresponding recommendation result is performing a second operation; and that a third application registers a rule with the rule engine <NUM> through the interface layer <NUM>, where match conditions of the rule are condition B, condition C, and condition E, and a corresponding recommendation result is performing a third operation.

In the prior art, for example, for condition B, all the three applications need to monitor corresponding events. In this case, a system resource for condition B is repeatedly invoked, causing additional power consumption. In this embodiment of this application, if an event detected by the interface layer <NUM> matches condition B, the event may be recorded and invoked repeatedly. The event may match condition B in rules of the three applications. There is no need to monitor the event for three times, thereby saving system resources.

It should be understood that, obtaining, by the rule platform <NUM>, an event may include: monitoring, by the interface layer <NUM> of the rule platform <NUM>, the event; and sending, by the interface layer <NUM>, the event to a personal knowledge base <NUM>, a rule status unit <NUM>, and a user portrait platform <NUM>.

Step <NUM>. The interface layer <NUM> of the rule platform <NUM> monitors an event.

In this embodiment of this application, each application does not need to monitor an event; instead, the interface layer <NUM> can monitor the event. The event may be any event occurring on the terminal; and the event may include a system event and/or an application event. A plurality of events may be detected by the interface layer <NUM> at the same time. The interface layer <NUM> may proactively monitor a system event, and the rule engine <NUM> needs to proactively register monitoring with a corresponding system module through the interface layer <NUM>. The interface layer <NUM> may also passively monitor an event. For example, some application events are monitored passively by the interface layer <NUM>. Specifically, the rule platform <NUM> may send a registration request to an application, so that the application sends some specific events to the interface layer <NUM> when the specific events occur. When these specific events occur on the application, the application proactively sends the specific events to the interface layer <NUM>, that is, the interface layer <NUM> passively monitors the events.

For example, the events may include inserting headphones, removing headphones, walking, running, cycling, driving/riding a car, power volume, screen on, black screen, weather, temperature, geographical fence, light intensity, a network status, wireless fidelity (wireless fidelity, Wi-Fi) on/off, mobile data on/off, vibration on/off, flight mode on/off, disturbance free on/off, eye protection mode on/off, date, time, camera on/off, and the like. As shown in <FIG>, an event that can be detected by the terminal is: the weather is thundershower. As shown in <FIG>, an event that can be detected by the terminal is: enabling a flight mode. As shown in <FIG>, an event that can be detected by the terminal is: making a call. As shown in <FIG>, an event that can be detected by the terminal is: being in a photographing mode.

Step <NUM>. The interface layer <NUM> of the rule platform <NUM> sends the event to the personal knowledge base <NUM>, the rule status unit <NUM>, and the user portrait platform <NUM>.

In this embodiment of this application, after the interface layer <NUM> monitors the event, the personal knowledge base <NUM> receives the event sent by the interface layer <NUM>, and the personal knowledge base <NUM> may record and store the event, and specifically, may record information such as an occurrence quantity, time, a location of the event, and other information. The interface layer <NUM> may further send the event to the rule status unit <NUM>.

For example, a historical user portrait may be stored in the personal knowledge base <NUM>. The interface layer <NUM> may further send the event to the user portrait platform <NUM>, and the user portrait platform <NUM> performs user tag analysis on the event to determine whether a user portrait changes. If the user portrait changes, an updated user portrait may be fed back to the personal knowledge base <NUM>. If the user portrait does not change, the original user portrait may be fed back or not fed back. After receiving the updated user portrait, the personal knowledge base <NUM> may update the stored historical user portrait.

It should be understood that, the user portrait can be used as a condition to match with the match condition in the rule. Conditions in some rules include the user portrait, and conditions in some rules do not include the user portrait. The rules without the user portrait have no effect on rule matching. The rules with the user portrait are considered to be matched successfully only when one or more detected events and the user portrait all meet a match condition in a specific rule. Then a recommendation result can be output to the application <NUM>. Alternatively, a recommendation result may be stored in a recommendation result candidate set <NUM>, and the application <NUM> proactively obtains the recommendation result from the recommendation result candidate set <NUM>.

Step <NUM>. The rule status unit <NUM> queries the rule base <NUM> for a rule related to the event, and if there is no such rule, ends the process; or if there is such a rule, performs step <NUM>.

It should be understood that if no rule related to the event is found in the rule base <NUM>, it indicates that the event is not written into a rule of the application, is useless, and can be discarded.

Step <NUM>. The rule status unit <NUM> may obtain at least one rule related to the event from the rule base <NUM>.

That the rule status unit <NUM> of the rule platform <NUM> obtains at least one rule related to the event from the rule base <NUM> may be obtaining all rules related to the event. The at least one rule related to this event may be registered by a plurality of applications, or may be registered by one application.

It should be understood that after receiving the event, the rule status unit <NUM> may query and obtain at least one rule or all rules related to the event from the rule base <NUM> to perform status update. The personal knowledge base <NUM> may further record a condition matching status of the rule related to the event, and the condition matching status may be "matched", "satisfied", or other indication information. The personal knowledge base <NUM> may store a condition of the rule related to the event, and record the condition matching status; or the personal knowledge base <NUM> may record only the condition matching status (a condition identifier is unique); or another manner may be used. This is not specifically limited.

For example, a first event monitored by the interface layer <NUM> is <NUM>:<NUM> a. , and two rules related to <NUM>:<NUM> a. are found in the rule base <NUM> through query. In this case, the rule status unit <NUM> may obtain the two rules for status update. Further, condition matching statuses corresponding to the two rules are recorded in the personal knowledge base <NUM>; or match conditions of the two rules may be stored in the personal knowledge base <NUM>, and condition matching statuses are recorded correspondingly. It is assumed that a first rule A is "<NUM>:<NUM> a. to <NUM>:<NUM> a. in workdays (Monday to Friday) + poor air quality (an air pollution index is greater than <NUM>), a recommendation result is 'wear a mask'"; and that a second rule B is "commuting hours (<NUM>:<NUM> a. to <NUM>:<NUM> a. , or <NUM>:<NUM> p. to <NUM>:<NUM> p. + headphones inserted + in-vehicle state, a recommendation result is 'play music using music software'". Match conditions of the first rule A are: condition <NUM> = workday (Monday to Friday), condition <NUM> = in the morning (<NUM>:<NUM> a. to <NUM>:<NUM> a. ), and condition <NUM> = air pollution index greater than <NUM>.

Match conditions of the second rule B are: condition <NUM> = commuting hours (<NUM>:<NUM> a. -<NUM>:<NUM> a. , or <NUM>:<NUM> p. -<NUM>:<NUM> p. ), condition <NUM> = headphones inserted, and condition <NUM> = in-vehicle state.

Step <NUM>. The personal knowledge base <NUM> records a condition matching status corresponding to the at least one rule related to the event.

Following step <NUM>, the personal knowledge base <NUM> may obtain the match condition corresponding to the at least one rule or all rules related to the event from the rule status unit <NUM>, and the condition matching status may be recorded in the personal knowledge base <NUM>.

For example, a condition matching status for the first rule A may be: condition <NUM> = workday (Monday to Friday), and a state is "none"; condition <NUM> = <NUM>:<NUM> a. to <NUM>:<NUM> a. , and a state is "matched/satisfied"; and condition <NUM> = air pollution index greater than <NUM>, and a state is "none".

A condition matching status for the second rule B may be: condition <NUM> = commuting hours (<NUM>:<NUM> a. -<NUM>:<NUM> a. , or <NUM>:<NUM> p. m-<NUM>:<NUM> p. ), a state is "matched/satisfied"; condition <NUM> = headphones inserted, and a state is "none"; and condition <NUM> = in-vehicle state, and a state is "none".

Alternatively, each rule has a unique identifier, and correspondingly, the rule identifier and the condition matching status may be directly recorded. For example, the status of condition <NUM> of the rule A is "matched/satisfied". It should be understood that the condition matching status of the rule may be recorded in various ways, which is not specifically limited.

For example, when a second event detected by the interface layer <NUM> is Tuesday, the interface layer <NUM> sends the event Tuesday to the rule status unit <NUM>, and the rule status unit <NUM> queries the rule base <NUM> for all rules related to the event Tuesday. For example, all the rules related to Tuesday are as follows: A first rule A is "<NUM>:<NUM> a. m-<NUM>:<NUM> a. workday (Monday to Friday) + poor air quality (an air pollution index is greater than <NUM>), a recommendation result is 'wear a mask'"; and a second rule C is "the third week of each month + Tuesday, a recommendation result is '<NUM>% off in McDonald's'".

Then, the personal knowledge base <NUM> records the condition matching status for Tuesday. For the first rule A, condition <NUM> = workday (Monday to Friday), a state is "matched/satisfied"; condition <NUM> = <NUM>:<NUM> a. to <NUM>:<NUM> a. , a state is "matched/satisfied"; and condition <NUM> = air pollution index greater than <NUM>, a state is "none". For the second rule C, condition <NUM>= January to December, a state is "none"; condition <NUM> = the third week of each month, a state is "none"; and condition <NUM> = Tuesday, a state is "matched/satisfied".

For example, when a third event detected by the interface layer <NUM> is a pollution index of <NUM>, the interface layer <NUM> sends the event of a pollution index of <NUM> to the rule status unit <NUM>, and the rule status unit <NUM> queries the rule base <NUM> for all rules related to the event of a pollution index of <NUM>. For example, all the rules related to the pollution index of <NUM> are: the first rule A "<NUM>:<NUM> a. to <NUM>:<NUM> a. in workday (Monday to Friday) + poor air quality (an air pollution index is greater than <NUM>), a recommendation result is 'wear a mask'".

Then, the personal knowledge base <NUM> records a condition matching status of the pollution index of <NUM>. For the rule A, "condition <NUM> = workday (Monday to Friday), a state is 'matched/satisfied'; condition <NUM> = <NUM>:<NUM> a. to <NUM>:<NUM> a. , a state is 'matched/satisfied'; and condition <NUM> = air pollution index greater than <NUM>, a state is 'matched/satisfied'".

Step <NUM>. If condition matching statuses of all rules in the personal knowledge base <NUM> indicate that matching is successful, the rule status unit <NUM> outputs a recommendation result.

Following step <NUM>, when a matching status of each condition in the first rule indicates that matching is successful, the terminal displays the recommendation result corresponding to the first rule. Optionally, the first rule may further include a second condition related to a user portrait; and the rule platform <NUM> obtains a current user portrait from the user portrait platform <NUM> of the terminal, and updates a match status of the second condition based on the current user portrait.

Optionally, when matching statuses of all conditions in the first rule and a second rule indicate that the matching is successful, and a priority of the first rule is higher than that of the second rule, the terminal displays a recommendation result corresponding to the first rule, where the second rule is one of the at least one rule related to the first event.

It should be understood that if there are at least two rules with a same priority, the terminal may randomly display a recommendation result corresponding to one of the at least two rules. If priorities are different, the terminal may display a recommendation result corresponding to a rule with a highest priority, or may display recommendation results corresponding to the first N (N is an integer greater than or equal to <NUM>) rules with a highest priority.

For example, when the condition matching status of one or more rules related to the event is "matched/satisfied" or other information indicating that the matching is successful, the event is considered to be matched with the one or more rules, and the rule status unit <NUM> outputs the recommendation result corresponding to the one or more rules. The rule status unit <NUM> may proactively activate the recommendation result, and display the recommendation result on the application <NUM> through the interface layer <NUM>. Alternatively, the recommendation result may be stored in the recommendation result candidate set <NUM>, the application <NUM> obtains the one or more recommendation results from the recommendation result candidate set <NUM> through the interface layer <NUM>, and the application <NUM> may display the recommendation result based on a priority of the rule.

It should be understood that each time the rule status unit <NUM> proactively activates a recommendation result, the activated recommendation result is displayed on the application <NUM>. When obtaining the recommendation result from the recommendation result candidate set <NUM>, the application <NUM> may obtain one or all recommendation results. After obtaining the recommendation result, the application <NUM> may control how to display the recommendation result. For example, the application <NUM> obtains a plurality of recommendation results. However, if the plurality of recommendation results are displayed at a time, interference may be caused to the user, and a crash may occur. In addition, the recommendation results may not be displayed on a same application. Optionally, the application <NUM> may set the rule priority. When a plurality of recommendation results are obtained, a recommendation result to be displayed on the application <NUM> may be determined based on recommendation results corresponding to the rule priorities, or another display manner may be used, which is not specifically limited.

For example, if the condition matching status of the first rule is: condition <NUM> = workday (Monday to Friday), a state is "matched"; condition <NUM> = <NUM>:<NUM> a. to <NUM>:<NUM> a. , a state is "matched"; and condition <NUM> = air pollution index greater than <NUM>, a state is "matched", the detected event is considered to be matched with the rule, and the rule status unit <NUM> outputs the recommendation result.

If the condition matching status of the second rule is: condition <NUM> = commuting hours (<NUM>:<NUM> a. -<NUM>:<NUM> a. , or <NUM>:<NUM> p. -<NUM>:<NUM> p. ), a state is "satisfied"; condition <NUM> = headphones inserted, a state is "satisfied"; condition <NUM> = in-vehicle state, a state is "satisfied", the detected event is considered to be matched with the rule, and the rule status unit <NUM> outputs the recommendation result.

For example, the server may collect usage habits of a plurality of users, and update rules based on the usage habits of the plurality of users. For example, there are two rules, and the server sends a first rule to <NUM> mobile phones: during commuting time (<NUM>:<NUM> a. -<NUM>:<NUM> a. ), prompting to listen to music, and sends a second rule to the other <NUM> mobile phones: during commuting time (<NUM>:<NUM> a. -<NUM>:<NUM> a. ), prompting to view hot news. Then, the server may count a click rate of the <NUM> mobile phone users during the time period of <NUM>:<NUM> a. -<NUM>:<NUM> a. If a click rate of listening to music is much higher than that of viewing hot news, the server may update the second rule to the first rule, or vice versa.

Step <NUM>. The terminal displays the recommendation result.

In this embodiment of this application, that the terminal displays the recommendation result corresponding to the first rule may include: (<NUM>) sending, by the rule platform <NUM>, the recommendation result to the second application; and displaying, by the second application, the recommendation result, where the second application is the same as or different from the first application; or
(<NUM>) storing, by the rule platform <NUM>, the recommendation result; and obtaining, by the second application, the recommendation result from the rule platform <NUM>, and displaying the recommendation result, where the second application is the same as or different from the first application.

In other words, the application of the terminal receives and displays the recommendation result activated by the rule status unit <NUM>, or the application of the terminal obtains one or more recommendation results from the recommendation result candidate set <NUM>, and controls to display the one or more recommendation results. It should be noted that, the application of the event and the application that finally displays the recommendation result are not necessarily a same application.

For example, if the detected event is "the weather is thundershower", and the user-defined rule specifies that the match condition is "thundershower" and the recommendation result is "There are thundershowers today, do not forget to bring your rain gear", when the rule matching is successful, the terminal displays the recommendation result, as shown in <FIG>. If the event detected is "enabling a flight mode", and a rule in the rule base <NUM> specifies that the match condition is "flight mode enabled" and the recommendation result is "during the flight, you can select the following pastimes: video, music, reading, and others", when the rule matching is successful, the terminal displays the recommendation result, as shown in <FIG>.

If the detected event is "making a call", and a rule in the rule base <NUM> specifies that the match condition is "voice call" and the recommendation result is "Enable the recording function/allowed to use the recording permission?", when the rule matching is successful, the terminal displays the recommendation result, as shown in <FIG>. If the detected event is "camera on", and a rule in the rule base <NUM> specifies that the match condition is "photographing mode" and the recommendation result is "You can use a wide aperture mode", the terminal displays the recommendation result, as shown in <FIG>.

For example, if the first rule is successfully matched, the terminal displays "wear a mask". <FIG> is a schematic diagram of the recommendation result displayed on the terminal. If the second rule is successfully matched, the terminal displays "play music using music software". <FIG> is a schematic diagram of the recommendation result displayed on the terminal. If both the first rule and the second rule are successfully matched, a display order of the recommendation results may be determined based on priorities of the rules.

The first application or the second application described in the embodiments of this application may be, for example, a setting application. <FIG> is a schematic diagram of a display interface of a setting application. After the setting application is started, the display interface may display suggested setting options, such as adding other fingerprints (using other fingerprints to unlock). The setting application may send some rules to the rule base of the rule platform <NUM> in advance. For example, one of the rules is: rejecting three incoming calls during <NUM>:<NUM> p. to <NUM> a. , and a recommendation result is: Set "do not disturb" time (mute the device during a specific time). When the event detected by the interface layer <NUM> is that incoming calls at <NUM> p. , and <NUM> a. are rejected, the rule is successfully matched, and the rule platform <NUM> returns the recommendation result to the setting application. As shown in <FIG>, an updated recommendation result is displayed on the display interface of the setting application, that is, "Set 'do not disturb' time (mute the device during a specific time)". The setting suggestion may be updated along with the recommendation results for rule matching.

The terminal provided in the embodiments of this application includes a rule platform with system-level permission, and the rule platform manages rules required by a plurality of applications of the terminal together. Therefore, when the rules required by the plurality of applications include the same conditions, the rule platform only needs to obtain the event of the terminal and match the obtained event with the condition, thereby saving system resources and preventing the system resources from being invoked repeatedly. The system-level permission means that all resources of a system can be used. Moreover, the terminal provides a unified rule management system, which may be a rule base and may implement unified rule matching and life cycle management functions. The terminal provides a unified context awareness system, which may be a personal knowledge base and may support user-defined rules. The rules stored in the rule base can be registered and updated through a cloud, and hot update of the rules is supported. The interface layer can proactively monitor a system event and passively monitor an application event, to trigger rule matching. The application can proactively obtain the recommendation result, and the engine can proactively activate the recommendation result. Unified rule management on the cloud, a rule definition template, a modular rule match condition, and a life cycle condition are supported. A rule status may be updated by updating a rule condition.

For example, the rule base may further include the following rules:.

It may also be that the user selects the match condition and the corresponding recommendation result to generate a customized rule, for example: workday (Monday to Friday) morning (<NUM>:<NUM> a. to <NUM>:<NUM> a. ) + poor air quality (an air pollution index is greater than <NUM>), prompting "wear a mask"; or, on the first day of each month, prompting "make credit card repayment, pay gas, electricity, and water bills, and top up the mobile phone"; or, every Friday afternoon (<NUM>:<NUM>-<NUM>:<NUM>) + rain/snow, prompting "Fresh Hema"; or, in-vehicle Bluetooth connected, automatically enabling "Gao De Navigation"; or other events. It should be noted that options in the user-defined rules may be preset in the mobile phone, and the user may select a desired option based on an actual requirement.

The rules may also be rules for recommending an APP (a third-party APP may be allowed) for a specified scenario. For example: commuting hours (<NUM>:<NUM> a. -<NUM>:<NUM> a. , or <NUM>:<NUM> p. -<NUM>:<NUM> p. ) + headphones inserted + in-vehicle state, music software can be recommended; overtime period (<NUM>:<NUM> p. -<NUM>:<NUM> p. ) + walk + company + rain/snow, a taxi hailing software can be recommended; and weekend (Saturday and Sunday) + not at home or work + dinner time (<NUM>:<NUM> p. -<NUM>:<NUM> p. ) + static + movie fan, movie ticketing software can be recommended.

The rules may also be rules for targetedly recommending some functions of an APP (a third-party APP may be allowed). For example: using Alipay + stock software, Alipay's Ant Financial can be recommended; in-vehicle state + navigation + manual input, voice assistant can be recommended; too many pictures/documents, cloud backup can be recommended.

<FIG> is a block diagram of a partial structure of a mobile phone related to a terminal according to an embodiment of this application. As shown in <FIG>, the mobile phone includes components such as a radio frequency (Radio Frequency, RF) circuit <NUM>, a memory <NUM>, an input unit <NUM>, a display unit <NUM>, a sensor <NUM>, an audio circuit <NUM>, a wireless fidelity (wireless fidelity, Wi-Fi) module <NUM>, a processor <NUM>, and a power supply <NUM>. A person skilled in the art may understand that the mobile phone structure shown in <FIG> does not constitute any limitation on the mobile phone, and the mobile phone may include components more or fewer than those shown in the figure, or a combination of some parts, or parts disposed differently.

The following specifically describes each component in the mobile phone with reference to <FIG>.

The RF circuit <NUM> may be configured to receive and send signals in an information sending and receiving process or a call process, and particularly, receive downlink information from a base station, and then send the downlink information to the processor <NUM> for processing. In addition, the RF circuit <NUM> sends related uplink data to the base station. Generally, the RF circuit <NUM> includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, and the like. In addition, the RF circuit <NUM> may communicate with a network and another device through wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to global system for mobile communications (Global System of Mobile communication, GSM), general packet radio service (General Packet Radio Service, GPRS), code division multiple access (Code Division Multiple Access, CDMA), wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA), long term evolution (Long Term Evolution, LTE), email, short message service (Short Messaging Service, SMS), and the like.

The memory <NUM> may be configured to store a software program and a module. The processor <NUM> executes various function applications of the mobile phone and processes data by running the software program and the module stored in the memory <NUM>. The memory <NUM> may mainly include a program storage area and a data storage area. The program storage area may store an operating system, an application program required by at least one function (such as an audio play function or an image play function), and the like; and the data storage area may store data (such as audio data and a phone book) created based on use of the mobile phone, and the like. In addition, the memory <NUM> may include a high-speed random access memory, and may further include a non-volatile memory such as at least one disk storage device, a flash memory device, or another volatile solid-state storage device.

The input unit <NUM> may be configured to receive input digital or character information, and generate a key signal input related to user settings and function control of the mobile phone. Specifically, the input unit <NUM> may include a touch panel <NUM> and other input devices <NUM>. The touch panel <NUM>, also referred to as a touchscreen, may collect a touch operation performed by a user on or near the touch panel <NUM> (for example, an operation performed by the user on or near the touch panel <NUM> by using any proper object or accessory such as a finger or a stylus), and drive a corresponding connection apparatus according to a preset program. Optionally, the touch panel <NUM> may include two parts: a touch detection apparatus and a touch controller. The touch detection device detects a touch orientation of the user, detects a signal brought by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection apparatus, converts the touch information into contact coordinates, and sends the contact coordinates to the processor <NUM>, and can receive a command sent by the processor <NUM> and execute the command. In addition, the touch panel <NUM> may be implemented in various types, such as a resistive type, a capacitive type, an infrared type, and a surface acoustic wave type. In addition to the touch panel <NUM>, the input unit <NUM> may include the other input devices <NUM>. Specifically, the other input devices <NUM> may further include but are not limited to one or more of a physical keyboard, a function key (such as a volume control key or an on/off key), a trackball, a mouse, and a joystick.

The display unit <NUM> may be configured to display information input by the user, or information provided for the user, and various menus of the mobile phone. The display unit <NUM> may include a display panel <NUM>. Optionally, the display panel <NUM> may be configured in a form of a liquid crystal display (Liquid Crystal Display, LCD), an organic light-emitting diode (Organic Light-Emitting Diode, OLED), or the like. Further, the touch panel <NUM> may cover the display panel <NUM>. After detecting a touch operation on or near the touch panel <NUM>, the touch panel <NUM> transmits a touch event to the processor <NUM> to determine a touch event type. Then, the processor <NUM> provides a corresponding visual output on the display panel <NUM> based on the touch event type. Although in <FIG>, the touch panel <NUM> and the display panel <NUM> are used as two independent components to implement input and output functions of the mobile phone. However, in some embodiments, the touch panel <NUM> and the display panel <NUM> may be integrated to implement the input and output functions of the mobile phone.

The mobile phone may further include at least a type of sensor <NUM>, such as a light sensor, a motion sensor, or another sensor. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor may adjust luminance of the display panel <NUM> based on brightness of ambient light. The proximity sensor may turn off the display panel <NUM> and/or backlight when the mobile phone moves to the ear. As a type of motion sensor, an accelerometer sensor may detect magnitudes of acceleration in various directions (usually three axes), detect, in a static state, a magnitude and a direction of gravity, and may be used for an application that recognizes a posture of the mobile phone (for example, screen switching between a portrait mode and a landscape mode, a related game, and magnetometer posture calibration), a vibration identification-related function (for example, a pedometer or tapping), and the like. For another sensor that may be further disposed in the mobile phone, such as a gyroscope, a barometer, a hygrometer, a thermometer, or an infrared sensor, details are not described herein.

The audio circuit <NUM>, a loudspeaker <NUM>, and a microphone <NUM> may provide an audio interface between the user and the mobile phone. The audio circuit <NUM> may transmit an electrical signal converted from received audio data to the loudspeaker <NUM>, and the loudspeaker <NUM> converts the electrical signal into a sound signal for output. In addition, the microphone <NUM> converts a received sound signal into an electrical signal, the audio circuit <NUM> receives the electrical signal and converts the electrical signal into audio data, and outputs the audio data to the processor <NUM> for processing; and processed audio data is sent to, for example, another mobile phone through the RF circuit <NUM>, or the audio data is output to the memory <NUM> for further processing.

Wi-Fi is a short-range wireless transmission technology. The mobile phone can help, by using the Wi-Fi module <NUM>, the user to receive and send emails, browse a web page, access streaming media, and the like, to provide wireless broadband internet access for the user. Although <FIG> shows the Wi-Fi module <NUM>, it can be understood that the Wi-Fi module <NUM> is not a mandatory part of the mobile phone, and may be omitted based on a requirement without changing the essence scope of the present invention.

The processor <NUM> is a control center of the mobile phone, is connected to all parts of the entire mobile phone by using various interfaces and lines, and by running or executing the software program and/or module stored in the memory <NUM>, and invoking data stored in the memory <NUM>, performs various functions of the mobile phone and processes data, to perform overall monitoring on the mobile phone. Optionally, the processor <NUM> may include one or more processing units. Preferably, an application processor and a modem processor may be integrated into the processor <NUM>. The application processor mainly processes an operating system, a user interface, an application, and the like. The modem processor mainly processes wireless communication. It can be understood that the foregoing modem processor may not be integrated into the processor <NUM>.

The mobile phone further includes the power supply <NUM> (such as a battery) that supplies power to the components. Preferably, the power supply may be logically connected to the processor <NUM> through a power management system, to implement functions such as charging management, discharging management, and power consumption management through the power management system.

Although not shown, the mobile phone may further include a camera, a Bluetooth module, and the like, and details are not described herein.

In the embodiments of this application, the terminal in the foregoing embodiment may be based on the terminal structure shown in <FIG>, and the processor <NUM> may execute a program instruction stored in the memory <NUM> to implement the method shown in the foregoing embodiment, and details are not described herein again.

All or some of the foregoing embodiments may be implemented by software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, the embodiments may be implemented completely or partially in a form of a computer program product.

The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the procedure or functions according to the embodiments of this application are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, or microwave) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid-state drive Solid State Disk (SSD)), or the like.

Claim 1:
A recommendation method, applied to a terminal, wherein the method comprises:
when a first event is monitored, and a condition of a first rule corresponding to the first event is met, displaying a first recommendation result of the first rule;
updating the first rule to a second rule, wherein a condition of the second rule is the same as the condition of the first rule, and a second recommendation result of the second rule is different from the first recommendation result of the first rule;
when the first event is monitored again after the first rule is updated to the second rule, and the condition of the second rule corresponding to the first event is met, displaying the second recommendation result of the second rule,
wherein the updating the first rule to a second rule comprises: updating the first rule to the second rule according to behavior data of using the terminal by a user in a period of time, wherein the second recommendation result is based on a model and the model is obtained by training historical data and feature data, wherein the historical data are the behavior data and the feature data include a user portrait or a current user behavior data.