US20170004459A1

US20170004459A1 - Processing system and method

Info

Publication number: US20170004459A1
Application number: US15/059,745
Authority: US
Inventors: Peter Karsten; Alice Elisabet KARSTEN
Original assignee: ZERO360 Inc
Current assignee: ZERO360 Inc
Priority date: 2013-09-04
Filing date: 2016-03-03
Publication date: 2017-01-05
Also published as: WO2015033153A2; US20170003845A1; EP3042328A2; WO2015035098A3; US11564571B2; EP3042327A2; EP3042329A2; WO2015063449A1; WO2015033152A2; WO2015033153A3; WO2015035098A2; EP3042324A2; US20170031449A1; WO2015033151A3; US20170000348A1; EP3042363A1; WO2015033151A2; WO2015033152A3; US20170004685A1

Abstract

A system and method for managing a calendar, comprising means for determining parameters associated with existing appointments, means for receiving user data relating to a user of the calendar and means for scheduling a new activity for a user in dependence on said user data and said parameters.

Description

RELATED APPLICATIONS

This application is a continuation of PCT Patent Application No. PCT/US2014/054159 having International filing date of Sep. 4, 2014, which claims the benefit of priority of United Kingdom Patent Application Nos. 1400225.7 filed on Jan. 7, 2014, 1315764.9 filed on Sep. 4, 2013 and 1315765.6 filed on Sep. 4, 2013, and U.S. Provisional Patent Application Nos. 61/874,219 filed on Sep. 5, 2013 and 61/874,107 filed on Sep. 5, 2013. The contents of all of the above applications are incorporated by reference as if fully set forth herein.

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a system for managing a calendar. It further relates to a method of configuring a user account and co-ordinating user interfaces between first and second user devices.

SUMMARY OF THE INVENTION

According to one aspect of the invention, there is provided a system for managing a calendar, comprising means for determining parameters associated with existing appointments, means for receiving user data relating to a user of the calendar and means for scheduling a new activity for a user in dependence on said user data and said parameters.
Preferably, the user data is at least one of: biometric data; location data; online activity data; and mood data. Preferably, the user data is provided by at least one of a sensor, a linked remote processor, and/or a local processor.
Preferably, the user data comprises user settings, preferably including at least one of: user preferences; user travel preferences; user purchase information; and user activity preferences. Preferably, the system is further adapted to enable a user to create and/or modify user settings.
Preferably, biometric data comprises one or more of: a galvanic skin response, a blood pressure, a heart rate (pulse), a pedometer count, an optical skin and blood vessel dilation measurement, a skin hydration measurement, a blood glucose level, a blood oxygen level, a blood alcohol level, an electrocardiogram, an electroencephalogram, an electromyogram, a respiration rate, a skin temperature, a measure of stress, a number of steps taken, a measure of calories used, a measure of activity, a movement from an accelerometer, a movement from a gyroscope, a response to mechanical or electrical stimuli, an environment temperature, an ambient ultraviolet light level, and an ambient CO₂level.
Preferably, the system further comprises a sensor for providing biometric data. Preferably, the system further comprises a wearable device incorporating the sensor for providing biometric data.
Preferably, location data comprises one or more of: a location; location-dependent data; local weather data; local traffic data; local time; local services information; and local public transport data.
Preferably, the system further comprises a sensor for providing a location and/or a means for receiving location-dependent data, preferably the sensor being a GPS sensor.
Preferably, online activity data comprises one or more of: user calendar activity, user browser, email and social media use. Preferably, the system further comprises a means for receiving online activity data.
Preferably, the parameters associated with existing appointments comprises one or more of: an appointment start time, an appointment end time, an appointment duration, an appointment location, an appointment attendee, an appointment invitee, an appointment purpose, an appointment category, appointment circumstance information, and further appointment information.
Preferably, the system further comprises a means for receiving appointment parameters. Preferably, the means for receiving appointment parameters comprises a communication link to a remote processor and/or an input interface for a user.
Preferably, scheduling a new activity for a user comprises one or more of: determining a suitable appointment for a new activity; determining a requirement for a new activity; determining the priority of a new activity; creating a new appointment for a new activity; determining further information in relation to a new activity; providing activity alternatives for user selection;
determining an optimum activity alternative; executing an external booking for a new activity; executing a purchase for a new activity; seeking third-party approval for a new activity; providing third-party notification of a new activity; and providing information relating to the new activity.
Preferably, determining a suitable appointment for a new activity comprises determining an available time between a current time and a next appointment start time; and determining whether the available time is sufficient for an activity, preferably a wellbeing promoting activity.
Preferably, determining a suitable appointment for a new activity comprises determining if an available time is within an activity-free period. Preferably, the activity-free period is determined in dependence on the user data, and preferably biometric data. Preferably, an activity-free period can be entered into the user calendar through user interaction.
Preferably, determining a requirement for a new activity comprises determining a first appointment location of a first existing appointment, and a second appointment location of a second existing appointment subsequent to the first appointment, and determining that a travel activity is required from the first to the second appointment location.
Preferably, determining a requirement for a new activity comprises determining from an appointment parameter that an associated activity is required. Preferably, the appointment parameter is an appointment location and the associated activity is travel to the appointment location. Preferably, the appointment parameter is an appointment required item and the associated activity is procuring the required item.
Preferably, scheduling a new activity for a user comprises determining a user propensity for a new activity. Preferably, a user propensity for a new activity takes into account a combination of subjective factors and objective factors. Preferably, a subjective factor is specific to a particular user. Preferably, a subjective factor is estimated in dependence on the user data. Preferably, a subjective factor is estimated in dependence on a user preference input.
Preferably, providing activity alternatives for user selection comprises evaluation of user data; and determining suitable new activities in dependence on user data.
Preferably, determining an optimum activity alternative comprises evaluation of a control factor. Preferably, the control factor includes, individually or in combination, optionally weighted, one, some, or all of the following: a cost, a user wellbeing factor, a user stress level, a user mood, a user propensity, a maximum duration of the second appointment, and a user preference.
Preferably, providing information relating to the new activity comprises at least one of: providing a route or travel directions to the new activity location; providing address and/or contact information for the new activity venue; sending travel directions to a mobile device; and/or printing travel directions.
Preferably, scheduling a new activity for a user comprises evaluating whether the user has engaged a scheduled activity; and if not, then updating the scheduled activity to provide an alternative activity. Preferably, user location information can be used to provide the alternative activity at a location convenient to the user.
Preferably, the system further comprises providing access to the calendar associated with the user to an auxiliary user. Preferably, the system further comprises restricting the auxiliary user from and/or permitting the auxiliary user to adapt the calendar associated with the user. Preferably, the system further comprises applying a restriction and/or permission associated with a first auxiliary user to a second auxiliary user for delegation.
Preferably, the system further comprises a graphical user interface configured for user interaction with the system.
Preferably, the system further comprises payment means for performing a payment transaction associated with an appointment in a calendar. Preferably, the payment means is further adapted to provide evidence of a transaction to the user or to an auxiliary user and/or to a remote and/or local processor. Preferably, the remote and/or local processor is arranged to perform accounting functions. Preferably, the payment transaction relates to the user's contribution toward a group event.
According to another aspect of the invention, there is provided a system for managing a calendar, the system comprising means for determining parameters associated with existing appointments, means for receiving data relating to a user of the calendar, and means for performing a payment transaction as a result of an appointment in the calendar, wherein the payment transaction relates to the user's contribution toward a group event.
Preferably, the or a remote and/or local processor performs a payment transaction on behalf of a plurality of users.
Preferably, the appointment in the calendar comprises data relating to one or more of: cost sharing information; a total appointment cost; a maximum number of appointment participants; a fixed number of participants; a fixed cost per participant; a variable cost per participant, optionally dependent on a number of participants; a payment means; a payment deadline; a late payment consequence; a payment failure provision; a minimum event commitment requirement; and an oversubscription provision.
Preferably, performance of a payment transaction is deferred following acceptance of an invitation to an appointment in the calendar. Preferably, the appointment is cancelled if an insufficient number of users accept the invitation by a predetermined acceptance deadline, and optionally wherein no payment transaction is performed. Preferably, the appointment is cancelled if an insufficient level of funds is committed by users that accepted the invitation by a predetermined acceptance deadline, and optionally wherein no payment transaction is performed. Preferably, a payment transaction is refunded if the appointment is cancelled.
Preferably, a payment transaction for a deposit payment is performed at acceptance of an invitation, and optionally a further payment transaction is deferred following acceptance of the invitation. Preferably, in the case of the user failing to perform a further payment transaction a deposit payment is not refunded as a payment failure provision.
Preferably, the appointment in the calendar comprises an indicator of whether a minimum event commitment requirement is fulfilled or not, and preferably wherein the indicator is a colour of the appointment in the calendar. Preferably, the system comprises means for providing a reminder in relation to performing a payment transaction relating to an appointment in the calendar.
Preferably, the oversubscription provision relates to the remote and/or local processor performing a further payment transaction on behalf of the plurality of users. Preferably, the oversubscription provision relates to allocation of a cancellation to one or more of the users that accepted the invitation.
Preferably, the system further comprises means for prioritising users that accepted the invitation for allocation of a cancellation to one or more low-priority users, and preferably wherein the prioritising occurs in dependence on user data, including biometric data; location data; online activity data; and/or mood data. Preferably, the prioritising occurs in dependence on date of invitation acceptance; date of user performing a payment transaction; a random factor; and/or a user-selected priority.
According to another aspect of the invention there is provided a method of managing a calendar, the method comprising: determining parameters associated with existing appointments; receiving user data relating to a user of the calendar; and scheduling a new activity for a user in dependence on said user data and said parameters.
According to the present invention there is also provided a method of managing a calendar, the method comprising: determining parameters associated with existing appointments; receiving user data relating to a user of the calendar; and performing a payment transaction as a result of an appointment in the calendar, wherein the payment transaction relates to the user's contribution toward a group event.
According to a further aspect of the invention, there is provided a method of configuring a user account, comprising detecting when the user is arranging an event to be attended by selected participants, determining whether there is a pre-existing event arranged by one of the selected participants, determining whether there is a group and/or team associated with the pre-existing event and offering the user the option to become a member of the group and/or team, optionally to attend the pre-existing event.
Preferably, the method further comprises making the user a member of the team and/or group. Preferably, the method further comprises adding the members of the team to the user's list of contacts and/or list of teams and/or groups. Preferably, the method further comprises adding calendar entries for the team to the calendar of the user.
According to a still further aspect of the invention, there is provided a method of configuring a user account, comprising detecting when the user is adding a new contact, determining whether the new contact is a member of a pre-existing team and/or group and offering the user the option to become a member of the pre-existing team and/or group.
Preferably, the method further comprises making the user a member of the team and/or group. Preferably, the method further comprises adding the members of team to the user's list of contacts and/or adding the user to the team members' list of contacts. Preferably, the method further comprises adding calendar entries for the team to the calendar of the user.
According to the present invention there is also provided a method of co-ordinating user interfaces between first and second user devices, the method comprising: receiving a signal at a first device from a second device, the signal relating to the status of at least one application on the second device; and adjusting the status of a corresponding application on the user interface of the first device.
Preferably, the status of the application on the second device is at least one of: selected, pinned and popular. Preferably, adjusting the status comprises promoting the prominence of the corresponding application on the user interface of the first device, optionally activating the corresponding application on the first device. Preferably, adjusting the status comprises duplicating the status of the application on the second device on the corresponding application on the user interface of the first device.
According to the present invention there is also provided a method of configuring a user interface of a user device, the method comprising: determining a telemetry parameter related to the device; determining an item of biometric data relating to the user of the device; and adjusting the user interface in dependence on the telemetry and biometric parameters in order to promote a desired behaviour of the user.
Preferably, the telemetry parameters relates to at least one of: phone usage, tariff plan, and API system wide information or API system logs events. Preferably, the API system wide information comprises at least one of: battery state; MSISDN; network name; signal strength; network type; service area; roaming state; mobile network state; IMEI; IMEI SV; MAC address (Wi-Fi); Bluetooth address; uptime; activity name; network MCC; network MNC; phone model; OS version; firmware version; kernel version; build number; software version; device locale; list of installed applications; memory information; GPS last position; and display manufactured. Preferably, the API system logs events comprise at least one of: camera state; screen actions; alarm indications; Wi-Fi state; application crash log; camera usage; screen orientation; call start; call number; SMS sent; SMS number; email accounts information (sent, received and other); and browser history (visited sites).
Preferably, the biometric data relates to at least one of: a galvanic skin response, a blood pressure, a heart rate (pulse), a pedometer count, an optical skin and blood vessel dilation measurement, a skin hydration measurement, a blood glucose level, a blood oxygen level, a blood alcohol level, an electrocardiogram, an electroencephalogram, an electromyogram, a respiration rate, a skin temperature, a measure of stress, a number of steps taken, a measure of calories used, a measure of activity, a movement from an accelerometer, a movement from a gyroscope, a response to mechanical or electrical stimuli, an environment temperature, an ambient ultraviolet light level, and an ambient CO₂level.
Preferably, the method further comprises: determining a utility activity of the user; and adjusting the user interface in dependence also on the utility activity of the user. Preferably, the utility activity comprises at least one of: Calendar events, emails, Facebook activity, Twitter activity and Browsing activity.
According to another aspect of the invention, there is provided a method of facilitating use of a calendar comprising receiving user biometric data and user online activity data in relation to a user; and adapting a calendar associated with the user in response to the user biometric data and user online activity data.
Preferably, the method further comprises providing access to the calendar associated with the user to an auxiliary user. Preferably, the method further comprises restricting the auxiliary user from and/or permitting the auxiliary user to adapt the calendar associated with the user. Preferably, the method further comprises applying a restriction and/or permission associated with a first auxiliary user to a second auxiliary user for delegation.
Preferably, the method further comprises receiving user device information from a user device associated with the calendar, and adapting the calendar in response to the user device information. Preferably, the user device information is user location information from a user device location detector. Preferably, adapting the calendar in response to the user location information comprises setting a user local time. Preferably, adapting the calendar in response to the user device information comprises transferring calendar functionality from the user device to another device. Preferably, the transferred calendar functionality is maintenance of a to-do list and/or receiving user biometric data and/or user online activity data. Preferably, adapting the calendar in response to the user device information comprises adapting a display associated with the calendar.
Preferably, the method further comprises receiving user device information from a first user device associated with the calendar, and adapting a second user device associated with the calendar in response to the first user device information. Preferably, adapting a second user device comprises adapting the calendar display in the second user device in dependence on a user selection relating to the calendar display in the first user device.
Preferably, the user device information is a user device battery status information. Preferably, when a user device battery reaches a predetermined level of charge, an auxiliary user is alerted to the state of the battery level.
Preferably, the method further comprises receiving a calendar appointment with at least one invited user; determining that the invited user has a pre-existing calendar appointment that corresponds to the received calendar appointment; and synchronising the calendar appointment by adding the user as invitee to the pre-existing calendar appointment. Preferably, the method further comprises receiving user approval of a proposed synchronisation. Preferably, the method further comprises adding contact information of one or more further users associated with the pre-existing calendar appointment to the calendar.
According to another aspect of the present invention there is provided a method of processing information relating to a user state, the method comprising: determining a state of a user; and affecting one or more elements external to the user in dependence on the user state, wherein the user state is determined from user biometric data in combination with user online activity.
Preferably, the user state is further determined from telemetry data. Preferably, user state comprises a mood.
Preferably, wherein biometric data comprises one or more of: a galvanic skin response, a blood pressure, a heart rate (pulse), a pedometer count, an optical skin and blood vessel dilation measurement, a skin hydration measurement, a blood glucose level, a blood oxygen level, a blood alcohol level, an electrocardiogram, an electroencephalogram, an electromyogram, a respiration rate, a skin temperature, a measure of stress, a number of steps taken, a measure of calories used, a measure of activity, a movement from an accelerometer, a movement from a gyroscope, a response to mechanical or electrical stimuli, an environment temperature, an ambient ultraviolet light level, and an ambient CO₂level.
Preferably, user online activity comprises one or more of: user calendar activity, user browser, email and social media use. Preferably, the method further comprises the feedback of information regarding the user state to the user.
Preferably, the method further comprises adapting one or more aspects of the user environment in response to the user state. Preferably, the method further comprises adapting a computer user interface in dependence on the user state. Preferably, adapting a computer user interface comprises using a style sheet adapted in dependence on the state of the user.
Preferably, the method further comprises forwarding information regarding the user state to another user. Preferably, the method further comprises forwarding information regarding the user state to another user via a trusted third party.
Preferably, the method further comprises the issuance and transmission of a certificate associated with a user to establish the identity and state of the user. Preferably, the certificate is time-limited.
Preferably, the method further comprises forwarding the information regarding the user state to a set of users defined by role. Preferably, the method further comprises forwarding the information regarding the user state to a set of users of the same role as the user. Alternatively, the method may further comprise forwarding the information regarding the user state to a set of users of a different role to that of the user.
According to another aspect of the invention, there is provided a system for processing information relating to a user state, the system comprising: means for determining a state of a user; and means for affecting one or more elements external to the user in dependence on the user state; wherein the user state is determined from user biometric data in combination with user online activity.
Preferably, the user state is further determined from telemetry data. Preferably, user state comprises a mood.
Preferably, biometric data comprises one or more of: a galvanic skin response, a blood pressure, a heart rate (pulse), a pedometer count, an optical skin and blood vessel dilation measurement, a skin hydration measurement, a blood glucose level, a blood oxygen level, a blood alcohol level, an electrocardiogram, an electroencephalogram, an electromyogram, a respiration rate, a skin temperature, a measure of stress, a number of steps taken, a measure of calories used, a measure of activity, a movement from an accelerometer, a movement from a gyroscope, a response to mechanical or electrical stimuli, an environment temperature, an ambient ultraviolet light level, and an ambient CO₂level.
Preferably, user online activity comprises one or more of: user calendar activity, user browser, email and social media use. Preferably, the system further comprises means for providing the feedback of information regarding the user state to the user.
Preferably, the system further comprises means for adapting one or more aspects of the user environment in response to the user state. Preferably, the system further comprises means for adapting a computer user interface in dependence on the user state. Preferably, the means for adapting a computer user interface comprises means for providing a style sheet adapted in dependence on the state of the user.
Preferably, the system further comprises means for forwarding information regarding the user state to another user and/or creating sets of users with user states that correlate with each other. Preferably, the system further comprises means for forwarding information regarding the user state or set of users state to another user or set of users via a trusted third party and/or an untrusted third party.
Preferably, the system further comprises means for the issuance and transmission of a certificate associated with a user to establish the identity and state of the user or set of users. Preferably, the certificate is time-limited.
Preferably, the system further comprises means for forwarding the information regarding the user state to a set of users defined by role. Preferably, the system further comprises means for forwarding the information regarding the user state to a set of users of the same role as the user. Alternatively, the system may further comprise forwarding the information regarding the user state to a set of users of a different role to that of the user.
Further details relating to various aspects of the present invention are described in the following patent applications, the contents of which are hereby incorporated by reference in their entirety:
United Kingdom Patent Application No. 1315765.6, titled “Processing system and method”, filed Sep. 4, 2013;
United Kingdom Patent Application No. 1400225.7, titled “Processing system and method”, filed Jan. 7 2014;
United Kingdom Patent Application No. 1315764.9, titled “Device for providing alerts”, filed Sep. 4, 2013;
U.S. Provisional Patent Application No. 61/874,107, titled “Intelligent Wristband and Life Management Environment” filed on Sep. 5, 2013;
U.S. Provisional Patent Application No. 61/874,219, titled “Life Management System”, filed on Sep. 5, 2013; and
four PCT applications filed on the same day as the present application by the same applicant titled “Processing system and method” (two applications with agent reference P43674W0 and P41407W0-01), “Wearable device” (agent reference P43675W0), and “Device for providing alerts” (agent reference P41406W0) respectively.
Any feature in any of the abovementioned documents may be combined with any feature described herein in any appropriate combination.
The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.
Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.
It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.
Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

These and other aspects of the present invention will become apparent from the following exemplary embodiments that are described with reference to the following figures, in which:

FIG. 1 shows a schematic overview of a data management system;

FIG. 2 illustrates data aggregation and processing in the data management system;

FIG. 3 further illustrates data aggregation and processing;

FIGS. 4 and 5 show exemplary architectures of the data management system;

FIG. 6 displays an exemplary Graphical User Interface (GUI) relating to a calendar tool integrated into the data management system;

FIG. 7 shows a calendar tool scheduling a new activity for a user;

FIG. 8 shows an exemplary GUI with calendar and available activity alternatives;

FIG. 9 shows a flow diagram of an out-of-the-box experience (OOBE) for integrating events between users;

FIG. 10 shows a flow diagram of an out-of-the-box experience (OOBE) for integrating contacts between users;

FIG. 11 shows a cost splitting functionality of a data management system;

FIG. 12 shows an exemplary output from the data aggregation and processing system;

FIG. 13 shows the processing of a mood; and

FIG. 14 illustrates communication between users on the basis of a mood certificate, derived from a mood.

DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

FIG. 1 illustrates an overview of a data management system 1000. The system 1000 comprises data inputs 1010 from a variety of sources which relate to a user. A portion of the input data 1010 is obtained from a sensing device used by the user. The sensing device generates sensor data 1020 sent as biometric data relating to the user. External Information Systems (EIS) 1030 provide external data relating to the user and/or other users of the system 1000.
In one example, the data inputs are obtained from any of the following sources:

- Sensor data 1020 can include: pulse rate, pedometer, Galvanic Skin Response (GSR), accelerometer, gyroscope, optical skin and blood vessel dilation, calories used, activity, stress, hydration, skin temperature, environment temperature, blood pressure, blood oxygen level, blood glucose level, electrocardiogram, electroencephalogram, electromyogram, respiration, ambient ultraviolet light, ambient CO₂level, and blood alcohol level.
- External data 1040 can include calendar, email, and contact information for example from sources such as Google Apps, Microsoft Exchange, iCloud.
- External data 1040 can include wellness and fitness data for example from sources such as Fitbit, Jawbone, Nike+, Withings, BodyMedia, MapMyRun.
- External data 1040 can include travel data for example from sources such as Triplt, TripCase.
- External data 1040 can include contacts and current sentiments information for example from social media sources such as Facebook, Twitter, LinkedIn, as well as general browsing activity
- External services 1050 can include a weather information provider, travel, accommodation and/or restaurant booking services.

In a further example, data received by the data aggregator and processor 1060, includes:

- data from a user device, including system-wide information, such as: user phone usage; tariff plan; phone battery state; MSISDN; network name; signal strength; network type; service area; roaming state; mobile network state; IMEI; IMEI SV; MAC address (Wi-Fi); Bluetooth address; uptime; activity name (information about running applications and other user actions); network mobile country code; network mobile network code; phone model; operating system version; firmware version; kernel version; build number; software version; device locale; list of installed applications; memory information; global positioning system (GPS) last position; display manufacturer.
- data from a user device, including system logs events, such as: camera state; screen actions (in order to determine user actions, for example: clicking on an application icon to run an application, selecting a widget on a home screen, in order to determine the most useful options that a user runs when using a phone device); alarm indications; Wi-Fi state; application crash log; camera usage; screen orientation; call start; call number; SMS sent; SMS number; E-mail accounts information (sent, received and other); and browser history (visited sites).

The input data 1010 is received and collated by a data aggregator and processor 1060, comprising various interconnected servers (as illustrated in FIGS. 4 and 5), arranged to compile and analyse the input data 1010. In part, the role of the data aggregator and processor 1060 is to generate actions, triggers or prompts based on the analysed data for users, which are communicated to users via devices 1070, mobile applications 1080 and/or browsers 1090 (via an online web portal, to which users have access).
Different individuals can access and interact with a user's data in the data management system 1000. The different individuals are grouped according to the purpose of their interaction with the user and the user's data, which allows definition of permitted interactions for such an individual participating in a particular role. In an example, the individuals (also referred to as “Roles”) with access to user's data include:

- the user;
- the user's executive assistant;
- a customer relationship manager (CRM) assigned to the user by the system operator; and
- the user's personal trainer or lifestyle coach.

The individuals, including the user as well as auxiliary users (e.g. assistant, line manager, coach, etc.), have access to the system 1000 using any combination of interfaces including (web) browsers 1090, mobile apps 1080 and dedicated devices 1070.
FIG. 2 demonstrates a flow diagram 2000 showing the overall format of the data management system 1000. In a first step, multi-source data pertaining to a variety of types of information, including External Information Systems (EIS) 1030 and sensor data (such as biometric data) 1020, is recorded. The data from various sources is subsequently communicated to the data aggregator and processor 1060 for compilation and analysis of the data. The analysed data and/or actions generated by the data aggregator and processor 1060 are output to user devices 1070, mobile apps 1080 and/or browsers 1090.
FIG. 3 further illustrates the process of data aggregation and processing by a data management system 1000. Input data 1010, from various sources, which might include calendar, email, contacts and appointments; social networks and current user sentiment; biometric data; upcoming travel; and the user's activity, wellness and fitness, is input into the system 1000 via one or more application programming interface (API) 2020. The data is aggregated and subsequently processed 2030, thereby outputting processed data 2040. The user is able to control the extent to which the processed data 2040 is output, for example the degree to which data is shared amongst other users and/or commercial bodies.
FIG. 4 shows an overview of the architecture of a data management system 1000. In this example, sensor data 1010 is obtained by a personal monitoring device 3000, such as a bio-telemetric device for measuring and recording biological parameters including heart rate, blood pressure, glucose and oxygen levels. In addition, the personal monitoring device 3000 might also measure and record activity parameters, for example by using pedometers, accelerometers and/or a GPS system. The personal monitoring device 3000 is preferably a wearable device that incorporates a number or sensors and further functionality.
The data obtained by the personal monitoring device 3000 is communicated, preferably wirelessly (e.g. via Bluetooth), to a network-enabled computing device 3010, such as a personal computer or mobile smartphone. The computing device 3010 relays the data, via a network (for example, the internet or a local connection), from the personal monitoring device 3000 to the data aggregator and processor 1060. The sensor data 1010 is recorded and associated with the user from whom it originated. Data from the personal monitoring device 3000 may also be communicated directly to the data aggregator and processor 1060, if the personal monitoring device 3000 incorporates suitable data communication means.
External Information Systems (EIS) data 1030 is also received and/or collated by the data aggregator and processor 1060 and recorded. The EIS user data 1030 is obtained from multiple sources, including information derived from calendars, schedules (including travel details), email, contacts, exercise platforms, social media platforms, and/or publicly available information sources (such as a traffic report provider at the user's location).
The input EIS data 1030, sensor data 1010 and/or any miscellaneous data related to the user are aggregated and processed by a data analysis module in a distributed computing network or cloud-based computing system. The output of the data analysis module is recorded and associated with the user from which the input data originated. Furthermore, the data analysis module generates actions and outputs to the user. The output data is accessible by the user and/or auxiliary users (that are associated with the user) via an application or web portal, for example via a computing device 3010. For the data aggregator and processor 1060 and the user to interact with one another an online portal or browser provides an interface, or a dedicated device 3010, or software such as a mobile software application or a computer programme.
Miscellaneous user data includes for example any user-defined rules, data from auxiliary users and/or advertising targeted to the user.
Further functionality can be provided by the system. For example, an indication of low battery of a user's mobile phone is used to trigger an action to for an online browser application to poll for information more often instead of the mobile phone. At the same time the system can alert auxiliary users about the low battery of the mobile phone. In another example a “to do” list stored in a mobile phone is moved to cloud-based storage if the mobile phone's battery is running low.
FIG. 5 shows a further exemplary overview of the architecture of the data management system 1000.
A system for managing a calendar in the form of a calendar tool will now be described. Based on existing calendar entries (appointments) and associated appointment parameters in a user's calendar and user data, a calendar tool performs actions to schedule a new activity for a user. The new activity scheduled by the calendar tool is associated with a time, either before, after or during an existing appointment. The calendar tool thus populates a calendar.
Existing appointments are defined by appointment parameters including a time or timespan and further appointment information. Such further appointment information includes a number of different kinds of information, such as parties to the appointment (including invitees and attendees), appointment location, nature of the appointment, and circumstances of the appointment.
User data (based on which the calendar tool performs scheduling actions in order to schedule a new activity for a user) provides further information relating to the user of the calendar. User data can include for example user biometric data, user location data, user online activity data, user mood data, and user settings selected by the user. User settings might include (but are not limited to) user preferences, travel preferences, purchase information and activity preferences.
Appointment parameters and user data can be provided by user input (or by auxiliary user input), or by input from other sources, such as EIS data 1030.
The calendar tool can be implemented in the data aggregator and processor 1060, or it can be implemented locally on a user device in a local software application. Parts of the calendar tool can be distributed between the data aggregator and processor 1060 and a user device.
The calendar tool performs an action to do with scheduling a new activity for a user in response to one or more calendar entries and commences from within a calendar application. Some examples of possible actions to do with scheduling a new activity for a user are:

- suggesting routes to arrive at a location for an appointment, and providing maps
- suggesting activities to enhance the user's wellbeing in time available until the next appointment
- using an eCommerce service to purchase an airplane ticket
- listing flower shops in the vicinity of a host's home in preparation for an invitation to dinner

A wide variety of factors can be taken into account in scheduling the activity for the user. Some examples of such factors include:

- whether or not approval is required prior to execution of a purchase
- who can approve which actions
- user metrics (including historical metrics, current metrics, and predicted future metrics) such as a measure of the exercise a user has undertaken in the past five days according to sensor data
- user activity (including historical activity, current activity, and predicted future activity) such as a recent increase in visits to a particular theatre
- other user information, such as whether or not a user participates in a loyalty scheme for an airline, and if so what are the user's frequent flyer card details
- information relating to the user's location, such as a weather forecast or traffic congestion information

In FIG. 6, an exemplary Graphical User Interface (GUI) shows a three-day display of a user's calendar 4000 with various existing appointments, as extracted from the EIS 1030. The data aggregator and processor 1060 identifies a time slot 4010 in the calendar which has no appointments associated and determines that there is potential for a space 4050 to be added to the user's calendar for a new activity, at a time between the end of a first appointment 4020 and the start of a second appointment 4030.
In the context of the present invention, a “space” is a period to which the new activity for a user being scheduled by the calendar tool relates. For example, this period can be the time between two appointments, or the time until a later, subsequent appointment. A space can include a definition of some or all of the factors the calendar tool takes into account to schedule a new activity for a user.
In the exemplary GUI shown in FIG. 6, a first appointment 4020 blocks out a time space for a meeting in New York from 1:15 PM until 3:15 PM, and a second appointment 4030 blocks out a time space on the next day for an exhibition in San Francisco from 3:00 PM onwards. From these two appointments, the data aggregator and processor 1060 is able to:

- determine that between the end of a first appointment 4020 and the start of a second appointment 4030 travel from New York to San Francisco is necessary
- define desired travel details, such as by air, direct, departing after 4:30 PM New York local time and arriving before 2:00 PM San Francisco local time on the next day
- obtain a selection of suitable flights
- select the best flight (for example depending on price, or by user selection)
- book tickets (automatically and without further user engagement)
- complete check-in for the user prior to the flight (automatically and without further user engagement).

The data aggregator and processor 1060 collates information including length of the time-span between the first appointment 4020 and second appointment 4030, the current user location and relative location of the first appointment 4020 and second appointment 4030, as well as biometric data. The aggregated information is processed by the data aggregator and processor 1060 and a suitable space 4050 for the new travel activity is determined and output to the user's calendar 4000. In an example (not shown) a list of suitable spaces is provided for user selection in order to take user preference into account.
A space can depend on and include information such as the requesting party's identity, a time span, a magnitude, a model type, a price range, brand(s), a description, a material, a selection criteria, etc. For example, a space may be defined by:

- a calendar start-stop time, flight SFO-JFK, lowest price.
- now until an appointment for playing basketball; Nike shorts, white, L, men's
- now, blood pressure high, location NYC

An action to be performed by the calendar tool in order to schedule a new activity for a user can be defined in the absence of a space (for example for template scheduling actions or default scheduling actions). An action to be performed by the calendar tool can be defined specific to a particular space and/or as part of a calendar entry. Actions to be performed by the calendar tool can be defined before the space is defined, in parallel with the definition of the space, or after the space is created. An action may be defined as part of a particular space, or external to a particular space. The action may be automatic, automatic based on parameters or manual.
FIG. 7 shows, further to FIG. 6, the scheduling of a new activity for a user based on a determined space. In the example shown, the data aggregator and processor 1060 determines that a space 4050 is available and an action can be initiated. In the illustrated example, the new user activity is travel, and the scheduling actions relate to the necessary travel arrangements.
The data aggregator and processor 1060 determines that, given the timespan of the events either side of the space, their geographic separation (New York and San Francisco) and/or the GPS location of the user, air travel is needed between the two events. The data aggregator and processor 1060 identifies travel arrangement information 4060 in order to determine suitable flights for the space 4050.
Once a selection of alternative travel arrangements is found, an optimum is selected, for example based on biometric parameters. In one example, high stress levels observed in the user are used to select a travel alternative for maximum convenience instead of lowest cost.
The data aggregator and processor 1060 determines whether the calendar tool takes further actions. For example, in a determination step 4070, the flight can be scheduled in the user calendar and various scheduling actions, such as booking, check-in and notification can be performed automatically and without further user engagement.
The identification of travel arrangement information 4060 and the step 4070 of determining further scheduling actions is performed subject to the user's rules 4080 for handling automatic processes. Such exemplary rules include:

- Book features of flight depending on the users biometrics, e.g. if tired or stressed book business class.
- Commercial rules, such as upper and lower limits on cost or selecting lowest cost flights.
- Preference of flight times—if available, select early morning flights as opposed to late evening flights.
- Automatically book flights or otherwise, a user manually selects preferences, rules and/or approves the flight booking
- Identify auxiliary users with permission to approve flight bookings, or with permission to select a wellbeing promoting activity.

Scheduling actions are performed by the calendar tool using various External Information Systems (EIS) information and autofill functions. In one example, frequent flyer card details are automatically inserted into the flight booking process.
The data aggregator and processor 1060 can output a notification 4094 to the user and other auxiliary users, such as the user's executive assistant (EA). In another example, a user's personal trainer (PT) receives information about the time spent flying, and the user's partner receives notification that dinner in the vicinity of New York is not possible when the user is scheduled to fly to San Francisco.
In the example shown in FIG. 7, the data aggregator and processor 1060 automatically schedules a flight in the space from 8:00 AM to 3:00 PM, blocks out that space in the calendar 4000, and makes the flight booking.
A new activity that is scheduled by the calendar tool can have different states, such as high priority and low priority. The state of an activity can change as time progresses. In one example a user activity is to exercise, and the associated calendar tool action is to schedule an exercise. This action is inactive while the user's blood pressure is low, active when the blood pressure becomes high, and urgently active when the blood pressure becomes very high, in which case an additional calendar tool action is to generate an alert to the user's coach that the user's blood pressure is high.
A space can be ended by an action being performed by the calendar tool. For example, an automated on-line purchase being executed ends a space for making a purchase prior to an appointment.
In another example, the user has time in his or her calendar before the next appointment, and the calendar determines that the user has not taken many steps that day; the calendar determines a park near to the GPS location of the user's device, and suggests a walk in the park to the user and provides directions to the park. In another example, the user's surrounding temperature is detected to be high, in response to which the calendar tool suggests places where cold drinks are available.
Recommendations or suggestions are generated (and/or appointments are made) and provided by the system to the user according to a propensity factor that quantifies the benefit to the user from engaging or partaking in a possible activity. The propensity factor is based on an estimate of a user's desire to engage in the possible activity, and can take subjective factors (e.g.
likeliness of enjoyment, estimate of benefit to overall wellbeing) as well as objective factors (e.g. travel time, cost information) into account. Subjective factors are specific to that particular user, and may be different for different users. Subjective factors are indicative of the user's individual attitudes and preferences. Conversely objective factors are not specific to or dependent on that particular user, and in particular are not dependent on the user's individual attitudes and preferences.
Subjective factors may be estimated based on past user behaviour and activity decisions (e.g. user previously chose jogging rather than swimming), or based on user input (e.g. user prefers giving quirky gifts over conventional gifts), or based on analysis of user data associated with an activity (e.g. reduced stress indicator levels in 3-day period following a ski break). Parameters taken into account to estimate a propensity factor can include user data such as biometric data, location data, online activity data and mood data.
Examples of parameters taken into account to estimate a propensity factor include:

- calendar appointment density
- user blood pressure
- recent snowfall in a favoured ski resort
- travel distance required for the possible activity
- duration since last occurrence of similar activity
- user activity history
- other parameters

Many other parameters can be taken into account to estimate a propensity factor.
By blending objective and subjective factors a more meaningful propensity for an activity can be determined than if an objective factor alone, for example physical distance or cost, is considered.
For example, excellent weather conditions can outweigh the inconvenience of travelling to a ski resort for a day for a user that particularly enjoys skiing. In another example attendance at a comedy event the day after attendance at a funeral might be appropriate for a user with a propensity for distraction, but might be inappropriate for a user with a propensity for thoughtfulness.
In another example the system determines a propensity to invest effort into purchasing a gift prior to an invitation to dinner at a friend's house. Subjective factors that may affect the propensity can for example include: a level of effort the user previously invested on a similar occasion; the amount of time the user spent preparing for the appointment; whether the user cancelled a previous appointment; or whether a previous appointment was cancelled by the other party. Objective factors that may affect the propensity can for example include: physical distance, traffic conditions, and whether a particular retailer is a luxury or high-end retailer, and hence more expensive. Depending on the determined propensity, the suggested action may be to purchase a gift at a convenience store on the way, or may be to make a detour to a department store to purchase a gift.
For a given available timeslot, the benefit of an activity to the user can thereby be optimised with a high degree of sophistication. As a result of subjective factors being taken into account, the activity can be truly tailored to a specific user, and hence provide greater benefit to that user.
The system can also provide alerts for recommendations or suggestions according to user activity settings. For example, if a user defines an activity-free bed time' period as 10 pm to 8 am, then no alerts are generated during that period. The system can determine if the user is in an activity-free period in dependence on biometric data, for example by using motion, breathing and pulse data to determine if a user is still asleep (and not available for activities) or awake (and so available for activities) in the morning. Other activity-free periods may be defined, such as a ‘work time’ (which the system may determine if the user is in a particular location defined as his work place) or a ‘break’ where no activities are desired for a day.
The system can also update suggested activities as time progresses, for example suggesting a jog in favoured but distant park at first, and if the user's location has not changed to the suggested park after half an hour, then suggesting instead a jog in the local neighbourhood park instead.
FIG. 8 shows an exemplary graphical user interface (GUI) illustrating a user's calendar output 4000 generated by the data aggregator and processor 1060. A travel activity 5010 to Tokyo is scheduled into the calendar 4000. The calendar 4000 accounts for the travel time, time zone, daylight saving and crossing of the International Date Line when computing the time span of the scheduled travel activity 5010. Existing appointments following the travel activity 5010 are listed according to the local time of the user. In one example, the data aggregator and processor 1060 is arranged to adapt the calendar to local time according to the user's location as derived from a GPS instrument integrated in a user device.
A further exemplary graphical user interface (GUI) 4060 is also illustrated in FIG. 8, in which possible flight options are identified, as determined by the data aggregator and processor 1060, according to the time constraints of the travel activity 5010 being scheduled. A user can, if desired, book flights via this GUI 4060.
FIG. 9 shows an exemplary process executed by the data aggregator and processor 1060 to manage events and teams and/or groups in order to improve a user's out-of-the-box experience. In a first step 6010, a user creates a new event and selects a group of participants for the event.
The data aggregator and processor 1060 determines whether there is an overlapping event previously created by one of the selected participants 6030, by searching the user data of the selected participants 6020.
If the data aggregator and processor 1060 determines 6030 that there is no overlapping event, the event is created and the selected participants are notified 6040. If an overlapping event is identified by the data aggregator and processor 1060, then the user the user creating the new event is notified that there is a pre-existing overlapping event and a query is generated as to whether the user would like to join the team associated with the pre-existing event 6050. If the user declines, the new event is created 6040. Conversely, if the user wishes to join the pre-existing event, the user is added to the team associated with the pre-existing event and the team is added to a list of teams and/or groups associated with the user 6060, this thereby allows the user to access calendar events associated with the team in their own calendar 6070. The team members are also added to the user's list of contacts 6080.
Overlapping events are identified by the data aggregator and processor 1060 in dependence of the temporal and/or geographic coincidence of two or more events. In addition, two or more events are deemed to be overlapping due to the nature of the events, such as the intended activity. In one example, two events are determined to overlap if a baseball match is the intended activity of both the events.
FIG. 10 shows an a flow diagram of the process used to integrate contacts, teams and events in order to rapidly grow a new user's list of contacts, teams and events. In a further example, the data aggregator and processor 1060 is arranged to integrate new users with pre-existing teams and/or groups. A user creates and adds a new contact 7010, for example via an EIS interfaced system. The data aggregator and processor 1060 proceeds to identify whether the user is listed in any pre-existing teams and/or groups common to both the user and their new contact 7030, by searching user data associated with the new contact 7020. If such teams and/or groups are identified, then the data aggregator and processor 1060 adds the new user to the teams and/or groups 7040 and adds the events for these teams and/or groups to the user's calendar 7050. The members of the teams and/or groups with which the user is now associated, are added as new contacts for the user 7060 and the process repeats for the new contacts. In this viral manner the data aggregator and processor 1060 quickly assembles the teams, contacts and events for users and in particular new users.
Conversely, no further action is taken if the data aggregator and processor 1060 determines that the user is not associated with any teams 7070.
In order to facilitate organisation and management of events with a number of participants, the data management system 1000 can provide cost splitting functionality. To do so, cost sharing information is associated with the appointment for the event in question. An event may, in this context, include a group purchase, for example of a gift. Depending on the nature of the event, cost sharing information can include, for example:

- Total cost
- Maximum number of participants (attendees)
- Fixed number of participants
- Fixed cost per participant
- Variable cost per participant dependent on number of participants
- Variable cost per participant freely selectable by each individual participant
- Variable cost per participant selectable by each individual participant between an upper limit and a lower limit
- Payment means
- Payment deadline
- Late payment consequence
- Payment failure provisions
- Minimum event commitment (e.g. minimum payment requirement, minimum number of participants)
- Oversubscriptions provisions

FIG. 11 shows an exemplary process executed by the data aggregator and processor 1060 to schedule/manage events and teams and/or groups that are sharing the costs associated with an event. The event in this example is a ski break with a chalet rented for a group of participants. When the appointment for the event is created, the event organiser creating the appointment specifies that the event will cost £200 in total (for renting a chalet), and the estimated cost per participant is £20 (for occupancy of 10 in the chalet). A payment date of 7 January is set in the calendar for participation of an invitee. Payment options are specified to allow payment by PayPal, credit card, debit card, or cash payment. The minimum commitment for the event to take place is specified to be 5 participants (in which case the cost per participant is £40).
The event organiser invites a number of invitees that are potential event participants. The invitees that accept the invitation to the event complete the payment process and become committed participants. The payment process can be embedded in the calendar interface, or it can be performed in a linked external payment interface. In an alternative, the invitee can accept the invitation and defer payment. The event may have a payment window associated, and/or a payment deadline by which payments are to be made by the participants. In another example where the event is the group purchase of a gift, the participants may choose their payment contribution freely, or between a set upper and lower limit.
The appointment may disclose information regarding the different invitees and participants to all other invitees and participants, or only to the event organiser, or it may be fully anonymous with only the data management system 1000 collecting the group information. For example, for the purchase of a joint birthday gift the participants' contributions may be disclosed to all invitees, or only to the event organiser, or only the sum of the contributions may be disclosed to the event organiser. In another example, for the rental of a chalet the appointment can list participants that have committed to the event as well as invitees to the event, or the appointment can omit this information until after an invitee has committed to the event, or this information can be revealed to the organiser only.
If there is insufficient commitment to the event as time progresses, for example for a joint gift costing £100 only £50 has been committed, or for the chalet with minimum occupancy of 5 only 4 participants have committed, this may be indicated in the calendar entry (appointment) representing the event, for example by a colour of the calendar entry (appointment).
At specific times (e.g. a month before the event is scheduled) the data management system 1000 can provide reminders to invitees regarding the event, reminders to participants regarding under- or overpayment, and/or reminders to the event organiser regarding the event (e.g. minimum commitment not yet reached). As the pay by date approaches, additional reminders may be sent, for example to notify the event organiser of insufficient funds and/or to remind invitees that have accepted the invitation but not yet made a payment to do so.
In one example, the participants enter their payment details when they complete the payment process (or optionally pay a deposit), but payment (or optionally full payment) is only taken once the minimum commitment level is reached. For example for the rental of a chalet, payment is only taken on the payment deadline if the minimum commitment level of 5 participants is reached, and the total cost is divided between the number of participants (e.g. for 6 participants each pays £33.33). In this case, once the payment is taken, receipts are sent to the participants.
In one example, the event organiser can determine provisions in the case of a payment occurring late or failing for a particular would-be participant. For example the data management system 1000 can automatically provide a notification to the would-be participant, and the event organiser can be informed. A deposit may be retained and the would-be participant may be considered as non-participating. A surcharge may be added for late payment.
The data management system 1000 can automatically place a transaction, for example in order to book the chalet with the chalet owner with the funds from the participants' payments. In another example a case of wine as a joint gift is ordered with the funds from the participants' payments. Notification may be provided to the event organiser, and/or to the participants, that the booking has been made, and/or reminders may be provided to invitees that have not accepted the invitation.
In one example, the event organiser can determine provisions in the case of oversubscription to the event. For example, if £150 for a joint gift is raised by participants instead of the minimum of £100 for a case of wine, then an additional bottle of cognac may be purchased, or a more expensive case of wine may be purchased, depending on the provisions determined by the event organiser. In another example, if 18 participants commit to (e.g. accept and pay for) the rental of a chalet with maximum occupancy of 10, then a second chalet is booked, and the cost for the two chalets is divided between the participants. In another example, would-be participants are allocated a place in the event on a priority basis. A number of factors can be taken into account to determine priority, for example the time when an invitee committed to the event, whether a would-be participant has paid yet or not, an organiser-defined invitee priority level, and/or a random factor for a lottery of available places. Data relating to the would-be participant may be taken into account, for example biometric data; location data; online activity data; and/or mood data. For example somebody may be prioritised for a football tournament if they have a status of lop player'.
Refund of payment can be provided to participants that receive a cancellation and do not receive a place at the event.
FIG. 12 shows an exemplary output from the data aggregator and processor 1060 as viewed using via a web portal. The output shows upcoming calendar events (e.g. schedule, transport, agenda and reminder), biometric data (e.g. heart rate, GSR, hydration, output) and EIS data (e.g. blocks providing information). An action or alert may be generated by the data aggregator and processor 1060 advising the user to leave their current appointment soon on the basis of external service data relating to slow traffic conditions.
The data aggregator and processor 1060 is arranged to control multiple devices in the system 1000. In one example, a user, with a smart phone having installed on it a set of applications, such as Golf, Running, Cycling, Sailing and Tennis, pins an app to the home screen of the smart phone interface. The decision to pin an app to the home screen on the mobile phone causes the same app to be pinned to the home screen, or otherwise be made more prominent, on the user's other devices, such as a laptop or tablet device. In a further example, the user accesses a set of apps on a remote mobile device, such as a tablet, and chooses to use only some of this set of apps. On another device, such as the laptop, the icons shown to the user are selected to be the same as those used on the mobile device.
In another example, a GPS measurement tool in a user device drives the choice of image shown in a browser, a software application, or a device. For example, if the GPS determines the user's location to be in Paris, and the device time is near sunset, then an image of the sun setting behind the Eiffel Tower is shown in the device display.
Generally, embodiments of the invention may include one or more of the following features:

- A system as described (“Life Management”) that collates data related to a Role(s)
- A system that allows Role(s) to manage Role(s) collated data
- A system that allows the delegation of rights from a Role (e.g. Executive(s)) to a Role(s) (e.g. Executive Assistant(s)) for managing the Role(s) collated data
- A system that allows a Role (e.g. Executive Assistant) to create Space and Actions for Roles(s) (e.g. self and/or User).
- A system that allows a Role (e.g. Executive Assistant) to set Space and Action parameters for Role(s) (e.g. self and/or User).
  - For example, blocking out the time from 1 pm to 7 pm for air travel
- A system that uses data related to Role(s) to set Space and Action parameters for Role(s).
  - For example, using calendar and/or GPS locations to conclude that flights are needed, and blocking out the time from 1 pm to 7 pm for air travel
- A system that allows a Role to manually trigger steps in a process using Space and Actions (e.g. approve a flight booking).
  - For example, approving a flight that has been selected by a Role
- A system that automatically triggers steps in a process using Space and Actions (e.g. approve a flight booking).
  - For example, making a purchase that meets the criteria automatically
  - For example, automatically inserting frequent flyer card details into the booking
- A system that uses parameters in one part of the system to set parameters in another part of the system
  - For example, a GPS location collected from a phone can be used to set User(s) time parameters online and in an online watch
  - For example, high stress levels observed in an online watch can be used to change travel options for maximum convenience instead of lowest cost
  - For example, low battery indication in a phone can be used to set an online watch to poll for information more often, and alert fellow Role(s) about the phone's battery being low
- A system that uses parameters in one part of the system to shift tasks to another part of the system
  - For example, a TO DO list may reside in a phone, and be moved to an online watch if the phone's battery is running low
  - A GPS measurement in a phone can drive the choice of image shown online (sunrise in Seattle)
- Configuring the user interface on one device based on a combination of other device selections and external parameters.

Moods
In some embodiments, whether in combination with other features described herein or provided separately, there are presented apparatus for and methods of providing user state or mood related feedback to a user, more particularly to determining a state or “mood” of a user and in dependence on that state affecting one or more elements external to the user. This may allow a user's mood to drive how the world interacts with the user, in a basic example adapting all user interfaces (UI) in the user's life to the user's mood, and changing the colours of LEDs on a user's device in response to a mood.
User interfaces may be any user interface, including but not limited to any combination of an app, browsed page, smart watch, smart phone, computer screen, multi-room entertainment system, in-store media surroundings, night club bass-smoke dance entertainment system, in-car entertainment system or other user interfaces. A user may be an individual user or a group of users.
The invention may, for example, be used for such purposes as:

- to (passively) feedback mood information directly to the user, thereby informing the user of a mood they may not be aware they are experiencing, such as through choice of audio/visual entertainment;
- to (actively) seek to alter one or more aspects of the user's present or future behaviour and/or environment in response to the user mood, thereby acting to accommodate or change the mood of the user;
- to entertain a group of users based on another group's moods;
- to entertain a group of users based on the group's future moods, and
- to inform other parties of the mood of the user, including in some embodiments to allow the exchange between (preferably trusted) parties of information regarding the mood of the user.

This may in some instances be viewed as providing “Mood-as-a-Service”.
Generally, moods can be determined or calculated based on biometric data, such as Galvanic Skin Response (GSR), touch, taste, smell, movement from accelerometer(s) and gyro(s), optical skin and blood vessel dilation measurements, and responses to mechanical or electrical stimuli such as vibrations, electric shocks, “Vibras” and “eVibras” or age, weight, height, fitness level, body-mass index, appearance rating, demographic data or combinations thereof.
Moods may also be determined from other user data, such as calendar activity, email, app usage, social media and, ideally, other online activity data including but not limited to searches based on all names of individuals for a group of users, media setting preferences (such as loud sound), playlists and bright colours, location, proximity to places, systems and people, time of day, week and year, status of day such as holiday, and affiliations to external groups such as the Marilyn Monroe Fan Club. For example, the level of calendar population (densely populated or sparsely populated with appointments, and also how early and how late in a day appointments extend) can give an indication of a stress level.
The mood-related aspects described herein may be provided as part of a system with architecture as shown in FIGS. 1 to 5, for example implemented in data aggregator and processor 1060.
FIG. 13 shows in overview an example of the determination of and feedback arising from a user mood. User 8010 is shown generating via various interaction channels 8020 a plurality of output data (including biometric, social media and calendar data) which are processed by data processor 1060 and a user state or mood 8030 determined. The mood 8030 is used by mood processor 8040 to determine appropriate feedback 8050 which is relayed either directly to the user 8010 or via one of the various interaction channels 8020.
Optionally, the mood 8030 is made available via a sharing module 8060 to other parties 8070. Feedback from the other parties 8070 may then be relayed to the user 8010 as above, either directly to the user 8010 or via one of the various interaction channels 8020.
A mood can be calculated also when the user consists of several individuals, in which case an algorithm can use all available data, and possibly also weighting to favour individuals or groups within groups, and possibly also weighting to favour some aspects such as location or age.
Mood Availability/Sharing
User moods can be shared or otherwise made available between users on a peer-to-peer basis, through a trusted mood web or through a Trusted Third Party (“TTP”). Moods and user state each include all characteristics and data related to a user as listed above, both historically, currently, projected into the future and desired in the future. And as stated previously, a user can be a group or sub-group of individuals.
This may allow for enhanced communication between parties, as it will be known beforehand what mood the other party is in and therefore allow for the communication to be tailored appropriately. A known mood for one user can also allow tailoring of suggestions and actions, such as offering movie tickets, buying a share or making a bet, for the same user or another user.
Generally, a trusted third party is an entity which facilitates interactions between two parties who both trust the third party. Hence a trusted mood party (“TMP”) is an entity that facilitates the secure transfer of moods from one user or type of user or Role(s) to another. The TMP model therefore enables two parties to use such a trust in order to know each other's mood.
In some embodiments, this trust is based on the exchange of certificates; specifically, the TMP model allows the creation of a mood certificate (“MC”) to effectively “guarantee” a mood for a period of time and/or until conditions change. The certificate authority would act as a mood certificate authority (“MCA”) and issue a digital mood certificate to one of the two parties. The MCA then becomes the Trusted Mood Party in respect of that issued certificate.
Likewise interactions that need a third party recordation make use of a third-party repository service.
FIG. 14 shows an example of mood availability/sharing. Suppose users Alice (“A”) 9010 and Bob (“B”) 9020 wish to communicate, but only on the basis of knowing (preferably, securely) what the mood of the other party is. The TMP 9030 either knows Bob 9020 or is otherwise willing to vouch that Bob's mood 9034 (typically expressed in a mood certificate 9040) describes the person indicated in that certificate, in this case, Bob 9020.
In discussions, this third person (the TMP 9030) is often called Trent (“T”) 9030. Bob's mood 9034 and/or a mood certificate 9040 associated with Bob's mood 9034 is sent to Trent 9030. Trent 9030 gives the mood certificate 9040 to Alice 9010, who then uses it to send messages 9050 to Bob 9020 based on knowing Bob's mood 9034. Alice 9010 can trust this mood to be Bob's if she trusts Trent 9030. In such discussions, it is simply assumed that she has valid reasons to do so (of course there is the issue of Alice and Bob being able to identify Trent 9030 properly as Trent and not someone impersonating Trent).
In some embodiments, rather than relying on a dedicated mood certificate-issuing TMPs, users may themselves control the use of mood certificates. If users or Role(s) become TMPs, we have a trusted mood web where Role(s) digitally sign each other's mood certificates and do so only if they are confident the appropriate mood and the Role(s) belong together. A mood signing party is one way of combining a get-together with some certificate signing. Nonetheless, doubt and caution remain sensible as some users may have been careless in signing others' certificates.
Generally, embodiments of the invention may include one or more of the following features:

- Mood based user interface (UI)
  - Mood changes measured for one Role(s) causes user interface changes for the same Role(s) i.e. ensuring all users of a particular Role(s) are notified of a change of mood of one of their number
    - LEDs in a device's display change colour based on biometric indicators such as Galvanic Skin Response (GSR) measurements performed by a sensor (optionally built into the user device).
    - Notification messages, whether visual and/or audio e.g. “Check this out—she's happy today!”
  - Mood changes measured for one Role(s) causes user interface changes for other Role(s) or whole world facing website i.e. relaying mood changes to specific groups of users, making the mood information available or broadcast
    - “Check this out—the guys at Company X are happy today!”
    - “My assistant is in a really bad mood today!”
  - Mood changes measured in one system causes user interface changes (e.g. colour) in another user interface i.e. relaying mood information to a specific user
    - “Just opening the site with my browser shows me my mood.”
- Mood Style Sheet
  - Online resource that publishes a Role(s) mood for any user interface
    - For example to give a user a user interface, the user's current mood is identified by calling a web service to fetch the user's mood from a Trusted Third Party Mood Service. The Trusted Third Party Mood Service supplies XML+CSS+MIDI sound setting data with recommendations based on how the user is feeling right now. Based on that data the user interface is adapted. For example if the user is under pressure, then a user interface is created that speaks clearly with no nonsense to the user. This may allow a stressed user to focus on important information, whether by demoting less important information and/or digesting and presenting more simply the important information.
    - A style sheet may include CSS or audio-visual preferences.
- Trusted Mood Party, comprising elements such as:
  - Peer-to-peer
  - Third party architecture
  - Trusted mood web

The following are examples of uses of mood information:

- One might initiate a phone call, and see the mood of the person being called as the person answers.
  - mood data of communication participants may be supplied before, during setup, during, and/or after communicating with the person or group of persons.
  - communication settings (e.g. volume) may be adapted automatically based on communication participant moods.
- Mood dependent data (i.e. “mood data”) may be supplied only to users with certain moods indicated
  - Useful for targeted advertising or sales.
- Mood-dependent data may be supplied only to approved users and a pre-defined selection (or level) approved users (e.g. you and your best friends can see my mood).
- A group of people may walk into a restaurant, causing a change in the audio-visual entertainment as a result.
- A restaurant owner may be shown graphically the mood of his guests and a desired mood graph for his guests, and can thereby determine or set a time by which his guests should have the desired mood.
  - One or more user senses (e.g. audio-visual, smell, touch, temperature, and taste) may be stimulated or otherwise influenced to achieve a change of mood.
  - A mood may be described as a mood profile with dimensions of each parameter used.
  - A user sense (e.g. audio-visual, smell, touch, temperature, and taste) may be stimulated or otherwise influenced to achieve:
    - a mood change towards a given mood profile.
    - a mood change at a certain rate of mood change.
    - a mood change towards a given profile at a certain rate of mood change.
    - a mood change towards a given profile at a multiple rates of mood change for each mood dimension.

Home Entertainment
The following applies, in one example, to a multi-room entertainment system where users can interact with an entertainment system in each room separately. The term “home entertainment” also encompasses entertainment in a broader sense, such as in cars, on motorcycles, and in public places such as shops, offices and train stations.
A user state or mood may also be determined from the combination of online services used by a user, for example a web browser search combined with the use of previously unused social media/interaction apps. Moods may also be determined by adding data from an entertainment profile, which may include preferences such as:

- Media types
  - Sound preferences
  - Visual preferences
  - Touch, smell and taste differences
- Preferences driven by time (“only in the mornings”) and location
- Media settings
  - e.g. loud, bass, dark
- Preferences driven by participants
  - e.g. only play funk when I am alone

A user will also have associated characteristics, which may include:

- Digital footprint/status
  - Biometrics
  - Calendar items
  - Email
  - Social network activity
  - Time of day
  - Location (e.g. GPS)
  - Time of week (e.g. Sunday)
  - Time of year (e.g. holiday)
  - External conditions (e.g. Elvis Presley Revival Week)
  - 3rd party playlists
- Derivative data, calculated by analyzing digital footprint, such as
  - Physical strength
  - Psychological strength
  - Social strength
- Group adherence (e.g. has to be an Elvis fan)

Group moods can also drive the selection of home entertainment, wherein group moods are, ideally, the aggregate of individual moods:

- average of all individual moods
- weighted average of all individual moods,
  - e.g. following a given sub-group's moods when calculating moods
- historic moods
- projected future moods
- desired future moods, based on current Moods

This may allow the moods of a user or user group to influence / drive how the world interacts with the user or user group(s). A simple example might be adapting music played through a home entertainment system to the user's mood, and/or changing the colours of related displays. The media provided in a room can be any media that can be sensed by the user, such as sound.
A user's presence in a room can be detected using personal equipment such as an NFC antenna in a cell phone, or personal physical attributes such as weight or appearance detected by sensors in the room. A “room” refers to the room in which a user or user group is present—e.g. adjacent room(s) or remote rooms.
Ideally, a system will automatically detect that a user is present in a room, and adjust the media provided accordingly. A user's entertainment profile and/or characteristics could be used to select automatically the media provided in a room.
For a group of users, a weighting might be assigned to each user's entertainment profile and/or characteristics when selecting media provided in a room containing the group of users. For example, the entertainment profile and/or characteristics of the “host” user might be assigned a weighting of 30%, with the entertainment profiles and/or characteristics of the remaining users in the group having a collective weighting of 70%. A suitable algorithm can be used to adjust the weightings and aggregate the entertainment profiles and/or characteristics of the individual users.
Furthermore, a user's entertainment profile might be adjusted to complement another user's entertainment profile and/or characteristics. Ideally, the entertainment profile of another user can be used to drive the user's entertainment profile, such that media is selected as if that other user was present, even if they are not.
It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.
Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.
Reference numerals and/or subtitles appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A system for managing a calendar, the system comprising:

means for determining parameters associated with existing appointments;

means for receiving data relating to a user of the calendar; and

means for scheduling a new activity for a user in dependence on said user data and said parameters.

2. A system according to claim 1, wherein the user data is at least one of:

biometric data; location data; online activity data; and mood data.

3. A system according to claim 2, wherein the user data is provided by a sensor, a linked remote processor, and/or a local processor.

4. A system according to claim 2, wherein the data relating to a user further comprises user settings, and preferably wherein the user settings comprise at one or more of: user preferences; user travel preferences; user purchase information; and user activity preferences.

5. A system according to claim 4, further adapted to enable a user to create and/or modify user settings.

6. A system according to claim 2, wherein biometric data comprises one or more of: a galvanic skin response, a blood pressure, a heart rate (pulse), a pedometer count, an optical skin and blood vessel dilation measurement, a skin hydration measurement, a blood glucose level, a blood oxygen level, a blood alcohol level, an electrocardiogram, an electroencephalogram, an electromyogram, a respiration rate, a skin temperature, a measure of stress, a number of steps taken, a measure of calories used, a measure of activity, a movement from an accelerometer, a movement from a gyroscope, a response to mechanical or electrical stimuli, an environment temperature, an ambient ultraviolet light level, and an ambient CO2 level.

7. A system according to claim 2, further comprising a sensor for providing biometric data; preferably wherein said sensor is incorporated into a wearable device.

8. (canceled)

9. A system according to claim 2, wherein location data comprises one or more of: a location; location-dependent data; local weather data; local traffic data; local time; local services information; and local public transport data.

10. A system according to claim 9, further comprising a sensor for providing a location and/or a means for receiving location-dependent data, preferably the sensor being a GPS sensor.

11. A system according to claim 2, wherein online activity data comprises one or more of: user calendar activity, user browser, email and social media use.

12. (canceled)

13. A system according to claim 1, wherein the parameters associated with existing appointments comprises one or more of: an appointment start time, an appointment end time, an appointment duration, an appointment location, an appointment attendee, an appointment invitee, an appointment purpose, an appointment category, appointment circumstance information, and further appointment information.

14. A system according to claim 13, further comprising a means for receiving appointment parameters, preferably wherein the means for receiving appointment parameters comprises a communication link to a remote processor and/or an input interface for a user.

15. (canceled)

16. A system according to claim 1, wherein scheduling a new activity for a user comprises one or more of: determining a suitable appointment for a new activity; determining a requirement for a new activity; creating a new appointment for a new activity; determining further information in relation to a new activity; providing activity alternatives for user selection; determining an optimum activity alternative; executing an external booking for a new activity; executing a purchase for a new activity; seeking third-party approval for a new activity; providing third-party notification of a new activity; and providing information relating to the new activity.

17. A system according to claim 16, wherein determining a suitable appointment for a new activity comprises determining an available time between a current time and a next appointment start time; and determining whether the available time is sufficient for an activity, preferably a wellbeing promoting activity.

18. A system according to claim 17, wherein determining a suitable appointment for a new activity comprises determining if an available time is within an activity-free period, preferably wherein the user being in an activity-free period is determined in dependence on the user data, and preferably biometric data.

19. (canceled)

20. A system according to claim 18, wherein determining a requirement for a new activity comprises determining a first appointment location of a first existing appointment, and a second appointment location of a second existing appointment subsequent to the first appointment, and determining that a travel activity is required from the first to the second appointment location.

21. A system according to claim 18, wherein determining a requirement for a new activity comprises determining from an appointment parameter that an associated activity is required preferably wherein the appointment parameter is an appointment location and the associated activity is travel to the appointment location.

22-37. (canceled)

38. A system according to claim 1, further comprising means for performing a payment transaction as a result of an appointment in a calendar.

39. A system according to claim 38, wherein the means is further adapted to provide transaction evidence to the user or to an auxiliary user and/or to a remote and/or local processor preferably wherein the remote and/or local processor performs accounting functions.

40-56. (canceled)

57. A method of managing a calendar, the method comprising:

determining parameters associated with existing appointments;

receiving data relating to a user of the calendar; and

scheduling a new activity for a user in dependence on said user data and said parameters.

58-96. (canceled)