The Health Avatar platform [10] is a personalized healthcare service platform that provides an interaction channel between users and service providers. The Health Avatar platform handles easy-to-use, on-demand or match-making, and secure communication processes. The Health Avatar platform comprises three components: the health agent, health avatar, and broker. The health agent is a service provider application that tracks, summarizes, and analyzes the user's personal data, such as medical records, genomic sequencing, and lifelog data. The health avatar is a user-side application that provides some useful information provided by health agents. Note that the health avatar keeps all medical and genomic data related to the user and sends them when an authorized health agent requires them. The broker, positioned between the health avatar and health agent, supervises the registrations of health avatars and health agents, the establishment of interaction channels between them, and all data that is sent or received. Figure 1 shows the architecture of the Health Avatar platform.

For agent developers, the Health Avatar platform provides application programming interfaces (APIs), such as read and write CCR records. Health agents can use these APIs to load the user's data and to send summaries or analysis results. Our lifelog agent also exploits the APIs to cooperate with the Health Avatar platform. Unlike other agents, however, lifelog agents differ in an important aspect. Since Health Avatar does not keep lifelog data, the agents should generate lifelog data at the user side. In general, the size of lifelog data is too large; therefore, it is necessary to reduce their size by summarizing. Then, the lifelog agents use the summaries to provide services.

Figure 2 illustrates the interaction between our lifelog agent and the Health Avatar platform. The lifelog agent comprises two components: the lifelogging application and lifelog server. When the lifelogging application is executed, both an accelerometer and a gyroscope in the smartphone are activated, and the lifelogging application begins recording the sensor values at a 50-Hz rate. In an ideal situation, the number of lifelog records in a day reaches more than 4 million and the size of records becomes more that 300 MB. Although the smartphone is a well-developed device, it is still difficult to keep and interpret such a large amount of data. Hence, in our implementation, lifelog records are transferred to the lifelog server, which has the capability of keeping the private information securely and of interpreting an enormous number of records.

During the conveyance of a huge amount of lifelog data, it is very important to keep the data secure, because they contain very sensitive and private information. For security, we adopt the safe and reliable protocol of the personal lifelog upstreaming system (PLUS) [12]. The protocol consists of four phases: security establishment, user authentication, preparation, and upstreaming. In the security establishment phase, PLUS first establishes a safe communication channel for secure message exchange between a smartphone and the server. They share the same encryption key for exchanging confidential messages or data with the aid of superb algorithms, such as RSA [13] or AES [14] algorithms. The user authentication phase is to validate the user that holds the smartphone. In this case, the user ID is thought of as the avatar ID. The server checks whether the avatar ID is a valid one. In the next phase, the preparation phase, some necessary actions are performed before the lifelog data is transferred. In this phase, the server checks a list of logs written in previous transmissions for recovery and preparation process. The smartphone checks its own lifelog database to check the extent to which data will be sent. Finally, in the upstreaming phase, the smartphone encrypts each piece of lifelog data to be transferred to the server.

After the lifelog transmission, the second component, lifelog server, stores the lifelog data in a database in a regularized form. At some time, the server begins to identify the user's activity with the collected lifelog. To recognize the user's activity, we first need to compute a set of feature vectors for each day. Each feature vector is composed of 24 distinct features, which are generated from a fixed-width window of 64 consecutive sensor values with a 50% overlap between successive windows. For each window, 12 features are generated by the computation of averages and standard deviations with respect to each axis. The other 12 features come from the frequency domain after a fast Fourier transform [15]. They are also generated by the computation of averages and standard deviations in the frequency domain. After feature extraction, each feature vector is considered as a basic unit of activity recognition.

In our agent, we chose five basic activities: walking, running, sitting, standing, and lying down. They are what most people frequently do in their daily lives. To recognize the activities, we first collect a training dataset. We collect as a training dataset sensor data for ten minutes for each activity at a 50-Hz rate before deploying the agent. We use a support vector machine (SVM)-based activity recognition method to identify which activity is performed at each time. Other activity recognition algorithms can be applied instead of SVM, such as swarm-based optimization methods [16,17]. Figure 3 shows the process of activity recognition.

Since the results of activity recognition are a list of activities at each moment, it is difficult to show or use them. We need to carry out an additional step, lifelog summarization. The results can be aggregated by hours. For instance, the summary may indicate that the user walks for ten minutes, runs for one minute, sits for forty-two minutes, and stands for seven minutes from 4 pm to 5 pm. The summaries are sent to the broker in the Health Avatar platform and finally are sent to the avatar in the CCR format.

Although the summary of lifelog is itself useful for analyzing the user's lifestyle, it can be used for various services. For instance, it can be used as a reference for healthcare services or used in third-party applications. One of the applications with lifelog summaries is to compute calorie burned. In our application, calorie burned is calculated as follows [18]: For MET, assuming that the activities are performed in a general sense, we refer to [18] to choose the following values.

In our implementation, the summary is of the form <ID, date, hour, activity, time, unit>. For instance, a summary <20130805, 07, "sitting", 1427106, ms> indicates that the user sits for 1427106 milliseconds from 7 am to 8 am for August 5, 2013. The summaries are inserted into the "FunctionalStatus" attribute in the CCR format. The "FunctionalStatus" indicates the ability of a patient to manage daily activities, for example, ambulatory ability, activities of daily living, mental status, ability to care for self, etc. The summarized lifelog data are regarded as a type of "Activities of Daily Living". Figure 4 shows an example of lifelog data in the CCR form.

Figure 5 shows screenshots of our application displaying the results of lifelog summarization and calories burned calculation, based on the Health Avatar platform. In this experiment, a user has lifelogged for 7 days in August. In the calendar in our application, the days on the which the user collected lifelog data are highlighted in color. If one of those days is clicked, then a graph of the activity patterns of the user is displayed on the screen. Each bar indicates the proportions of five activities and the middle line shows the calorie burned during each hour. Thus, this graph shows the user's activity patterns and lifestyle in a day. There is an option to display a graph that shows the patterns for each day, thus showing the user's activity patterns and lifestyle during a week.