JP2024020631A - 心理状態計測システム及び心理状態計測方法 - Google Patents

Abstract

【課題】働き方に対する評価スコアを算出し提示しただけでは、評価スコア計測の持続モチベーション低下に課題がある。
【解決手段】処理部と、記録部と、を有する心理状態計測システムであって、記録部は、ユーザが使用する端末装置によって計測された加速度データを保持し、処理部は、加速度データに基づいて、ユーザの心理状態を示す評価スコアを計算し、所定の期間に計測された加速度データに基づいて計算された評価スコアを、所定の期間より前に計測された加速度データに基づいて計算された評価スコアと比較することによって、ユーザの心理状態の変化量を計算し、ユーザの心理状態の変化量に基づいて、ユーザの心理状態の向上に寄与する行動に対応する点数を計算し、計算した点数を出力する。
【選択図】図１

Description

本発明は、人間の身体の動きを計測するデバイスで取得されるデータから心理状態を計測する技術に関する。

近年、企業等での労働に関する問題が注目されており、企業の価値として会計上の健全性のみでなく、従業員が心身共に健康な状態で経営がなされていることも企業の価値として社会から評価されるようになりつつある。そのため、企業の従業員など人間の健全性を評価することが求められている。例えば、個人の人間あるいはある集団に属する人間はストレスが溜まっている状態であるか否か、仕事に集中できる状態であるか否かといった個人又は集団の健全性の評価にはアンケートが利用されるのが一般的であり、アンケートへの回答に基づいて評価が行われている。しかし、アンケートは恣意的に回答することが可能であるため、アンケートへの回答に基づく評価は客観性が不十分となる可能性がある。

これに対し、人間の健全性に関する状態は、ウェアラブルデバイスなど身体に装着可能なデバイスによって測定できることが知られている。例えば、ストレスが溜まっているか否か、仕事に集中できているか否かといった人間の状態は身体の動きに表れるので、身体に装着した加速度センサによって取得したデータから人間の状態を評価した評価スコアを算出することが可能である。人間が長期間にわたり自身の身体を意図的にコントロールし続けることは困難であるため、身体の動きに基づく評価スコアは客観性が高い。また、身体の動きに基づく評価スコアは客観性が高いので、複数の人間あるいは複数の集団の評価スコアを相互に比較することも可能であるという利点である。

例えば、特許文献１には、「端末は、身体の動きの加速度を測定する加速度センサと、加速度の時系列データおよび閾値を記憶する記憶部と、時系列データに含まれるそれぞれの値が閾値以上の第１の状態（活性状態）であるか閾値未満の第２の状態（非活性状態）であるかを判定する処理、第１の状態が連続する時間である持続時間を判別する処理、および、持続時間に基づいて人物の心理状態を数値化する処理を行う処理部と、を有する」と記載されている。

国際公開第２０１６／１２５２６０号

働き方に対する評価スコアを算出し提示しただけでは、そのユーザを評価することができるが、どのような働き方が相応しいかを評価することができない。また、これを常時行っていく際には、評価スコア計測の持続モチベーション低下に課題がある。

本発明の目的は、ユーザは働き方に対する施策を選択又は投稿し、評価スコアを測定することで、当該施策の効果を算出することで良し悪しを振り返ること、および、ユーザの施策投稿や評価スコア計測の持続モチベーション維持することを可能にする技術を提供することである。

本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、処理部と、記録部と、を有する心理状態計測システムであって、前記記録部は、ユーザが使用する端末装置によって計測された加速度データを保持し、前記処理部は、前記加速度データに基づいて、前記ユーザの心理状態を示す評価スコアを計算し、所定の期間に計測された前記加速度データに基づいて計算された前記評価スコアを、前記所定の期間より前に計測された前記加速度データに基づいて計算された前記評価スコアと比較することによって、前記ユーザの心理状態の変化量を計算し、前記ユーザの心理状態の変化量に基づいて、前記ユーザの心理状態の向上に寄与する行動に対応する点数を計算し、前記計算した点数を出力することを特徴とする。

本発明の一態様によれば、働き方に対する評価スコアから、ユーザの働き方を見直すことができる。また、評価スコアに基づいて、ユーザにリワードを付与することで、ユーザの評価スコア計測の持続モチベーションを維持することができる。

上記した以外の課題、構成、及び効果は、以下の実施形態の説明によって明らかにされる。

本発明の実施例の評価スコア計測、管理、効果算出及び交換を行う処理システムの全体構成を示すブロック図である。 本発明の実施例のサーバ、クライアント及び報酬連携サーバの構成を示すブロック図である。 本発明の実施例のクライアントが保持するユーザ情報テーブルの説明図である。 本発明の実施例のクライアントが保持する加速度センサテーブルの説明図である。 本発明の実施例のクライアントが保持するＧＰＳセンサテーブルの説明図である。 本発明の実施例のクライアントが保持する温度・照度・気圧・音量センサテーブルの説明図である。 本発明の実施例のクライアントが保持する操作履歴テーブルの説明図である。 本発明の実施例のクライアントが保持する特徴量テーブルの説明図である。 本発明の実施例のクライアントが保持する行動量モデルテーブルの説明図である。 本発明の実施例のクライアントが保持する分析対象判定処理結果テーブルの説明図である。 本発明の実施例のサーバが保持するユーザ情報テーブルの説明図である。 本発明の実施例のサーバが保持するチーム情報テーブルの説明図である。 本発明の実施例のサーバが保持する組織情報テーブルの説明図である。 本発明の実施例のサーバが保持するアクセスログテーブルの説明図である。 本発明の実施例のサーバが保持する加速度センサテーブルの説明図である。 本発明の実施例のサーバが保持する分析対象判定処理結果テーブルの説明図である。 本発明の実施例のサーバが保持する個人評価スコアテーブルの説明図である。 本発明の実施例のサーバが保持するチーム評価スコアテーブルの説明図である。 本発明の実施例のサーバが保持する組織評価スコアテーブルの説明図である。 本発明の実施例のサーバが保持する施策テーブルの説明図である。 本発明の実施例のサーバが保持する施策登録者テーブルの説明図である。 本発明の実施例のサーバが保持する施策利用テーブルの説明図である。 本発明の実施例のサーバが保持する報酬テーブルの説明図である。 本発明の実施例のサーバが保持する報酬登録者テーブルの説明図である。 本発明の実施例のサーバが保持する報酬利用テーブルの説明図である。 本発明の実施例のクライアントの画面に表示されるアプリケーションのトップページの説明図である。 本発明の実施例のクライアントの画面に表示されるセンサ計測のアプリケーション画面の説明図である。 本発明の実施例の処理システムが実行する計測開始及び計測終了の処理を示すシーケンス図である。 本発明の実施例のクライアントが実行するセンサ取得および分析対象判定処理を示すフローチャートである。 本発明の実施例のクライアントの画面に表示される評価スコアのアプリケーション画面の説明図である。 本発明の実施例のサーバが実行する個人評価スコア処理を示すフローチャートである。 本発明の実施例のサーバが実行するチーム／組織評価スコア処理を示すフローチャートである。 本発明の実施例のサーバが実行する評価スコアポイント処理を示すフローチャートである。 クライアントの画面に表示される施策選択のアプリケーション画面の説明図である。 本発明の実施例のユーザがクライアントを介してサーバのデータベースにアクセスする処理の流れを示すシーケンス図である。 本発明の実施例のサーバが個人評価スコア効果を計算する処理を示すフローチャートである。 本発明の実施例のサーバが施策評価スコア効果を計算する処理を示すフローチャートである。 本発明の実施例のクライアントの画面に表示される新規施策登録のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される施策利用状況（施策）のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される施策利用状況（登録者）のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される報酬選択のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される報酬利用のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される新規報酬登録のアプリケーション画面の説明図である。 本発明の実施例のクライアントの画面に表示される報酬利用状況のアプリケーション画面の説明図である。

以下、本発明の実施例を、図面を用いて説明する。

本発明の実施形態について図面を用いて詳細に説明するが、本発明は以下の実施形態に限定されることなく、本発明の技術的な概念の中で種々の変形例や応用例をもその範囲に含むものである。以下、本発明に係る一実施形態を、図１を用いて説明する。

図１は、本発明の実施例の評価スコア計測、管理、効果算出及び交換を行う処理システムの全体構成を示すブロック図である。

本実施例の処理システムを構成するサーバ（ＳＳ）、クライアント（ＣＬ）及び報酬連携サーバ（ＣＳ）は、ｏｐｅｎ又はｃｌｏｓｅのネットワーク（ＮＷ）に接続されている。ユーザ（ＵＳ）はクライアント（ＣＬ）を身に着けている。クライアント（ＣＬ）には、行動を計測するためのセンサ（ＣＬＩＳ）及び閲覧するための画面（ＣＬＯＤ）が付いている。

図１には、さらにユーザ（ＵＳ２）が図示される。これは、ユーザ（ＵＳ）とは別のユーザの例であり、クライアント（ＣＬ）とは異なるクライアント（ＣＬ２）を身につけている。実際にはそれぞれがクライアントを身に付けた多数のユーザがいてもよい。以下のユーザ（ＵＳ）及びクライアント（ＣＬ）に関する説明は、特記しない限り、ユーザ（ＵＳ２）及びクライアント（ＣＬ２）にも共通し、さらには、図示しない他のユーザ及びクライアントにも共通する。

図２は、本発明の実施例のサーバ（ＳＳ）、クライアント（ＣＬ）及び報酬連携サーバ（ＣＳ）の構成を示すブロック図である。

クライアント（ＣＬ）は、表示部（ＣＬ０１）、センサ部（ＣＬ０２）、処理部（ＣＬ０３）、記録部（ＣＬ０４）及び入出力部（ＣＬ０５）で構成されている。表示部（ＣＬ０１）は、ユーザ（ＵＳ）に対して情報を表示する。表示部（ＣＬ０１）は、例えば、液晶表示装置又はＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）表示装置等であってもよい。

センサ部（ＣＬ０２）は、人間の行動及び周囲の環境の計測を行う。センサ部（ＣＬ０２）は、例えば、加速度センサ、ジャイロセンサ、温度センサ、湿度センサ、気圧センサ及び照度センサ等の少なくともいずれかを含んでもよい。

処理部（ＣＬ０３）は、データを用いた分析を行う。記録部（ＣＬ０４）は、センサ部（ＣＬ０２）及び処理部（ＣＬ０３）から送られてくる結果を保存する。また、記録部（ＣＬ０４）は、処理部（ＣＬ０３）によって実行されるプログラムを保存してもよい。処理部（ＣＬ０３）は、記録部（ＣＬ０４）に格納されたプログラムを実行することによって、以下に説明するクライアント（ＣＬ）の種々の機能を実現する。例えば、記録部（ＣＬ０４）はＤＲＡＭ、フラッシュメモリ又はそれらの組み合わせ等の記憶装置であってもよく、処理部（ＣＬ０３）はそれらに格納されたプログラムを実行するプロセッサであってもよい。

入出力部（ＣＬ０５）は、ユーザからの入力の受け付け、並びに、ネットワーク（ＮＷ）を介したサーバ（ＳＳ）及び報酬連携サーバ（ＣＳ）とのやり取りを行う。例えば、入出力部（ＣＬ０５）は、入力のためのタッチパネル又はハードウェアキー等を含んでもよいし、サーバ（ＳＳ）等とのやり取りのための通信装置を含んでもよい。

サーバ（ＳＳ）は、計測部（ＳＳ０１）、施策部（ＳＳ０２）、報酬部（ＳＳ０３）、表示部（ＳＳ０４）、処理部（ＳＳ０５）、記録部（ＳＳ０６）及び入出力部（ＳＳ０７）で構成されている。

計測部（ＳＳ０１）は、クライアント（ＣＬ）から送られてくるセンサデータ（すなわちセンサ部（ＣＬ０２）による計測結果を含むデータ）から評価スコアに関する処理を行う。施策部（ＳＳ０２）は、施策に関する処理を行う。報酬部（ＳＳ０３）は、報酬に関する処理を行う。表示部（ＳＳ０４）は、サーバ（ＳＳ）の管理者にサーバ（ＳＳ）の状態に関する情報を表示する。

ここで、評価スコアとは、ユーザ（ＵＳ）の心理状態を示す指標であり、例えば、ユーザ（ＵＳ）の幸福感の高さ又はストレスの低さ等を示すものであってもよい。評価スコアの計測方法については後述する。

処理部（ＳＳ０５）は、計測部（ＳＳ０１）、施策部（ＳＳ０２）及び報酬部（ＳＳ０３）から送られてくるデータを処理する。記録部（ＳＳ０６）は、他の部から送られてくる結果を保存する。また、記録部（ＳＳ０６）は、処理部（ＳＳ０５）によって実行されるプログラムを保存してもよい。処理部（ＳＳ０５）は、記録部（ＳＳ０６）に格納されたプログラムを実行することによって、以下に説明するサーバ（ＳＳ）の種々の機能を実現する。例えば、記録部（ＳＳ０６）はＤＲＡＭ、フラッシュメモリ、ハードディスク装置又はそれらの組み合わせ等の記憶装置であってもよく、処理部（ＳＳ０５）はそれらに格納されたプログラムを実行するプロセッサであってもよい。

また、計測部（ＳＳ０１）、施策部（ＳＳ０２）及び報酬部（ＳＳ０３）の機能は、専用のハードウェアによって実現されてもよいし、処理部（ＳＳ０５）が記録部（ＳＳ０６）に格納されたプログラムを実行することによって実現されてもよい。

入出力部（ＳＳ０７）は、サーバ（ＳＳ）の管理者からの入力、並びに、ネットワーク（ＮＷ）を介したクライアント（ＣＬ）及び報酬連携サーバ（ＣＳ）とのやり取りを行う。例えば、入出力部（ＳＳ０７）は、入力のためのタッチパネル、キーボード及びマウス等のいずれかを含んでもよいし、クライアント（ＣＬ）等とのやり取りのための通信装置を含んでもよい。

図３は、本発明の実施例のクライアント（ＣＬ）が保持するユーザ情報テーブルの説明図である。

図３のユーザ情報テーブルはユーザ（ＵＳ）の情報を管理しているテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図３は一例であり、ユーザ（ＵＳ）の情報を管理していく上で必要な情報があれば、追加することが好ましい。

図３に例示するユーザ情報テーブル３００は、ユーザＩＤ３０１、氏名３０２、会社名３０３、所属３０４、チーム３０５、組織３０６及びイベント３０７を含む。ユーザＩＤ３０１及び氏名３０２は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。会社名３０３及び所属３０４は、ユーザ（ＵＳ）が所属する会社及び部署等を識別する情報である。

チーム３０５は、ユーザ（ＵＳ）が所属するチームを識別する情報である。チームの構成は任意であり、例えば会社内のいずれかの部署が一つのチームであってもよいし、同じプロジェクトに参加している社員が一つのチームを作ってもよいし、友人のグループを一つのチームとしてもよい。

組織３０６は、ユーザ（ＵＳ）が所属する組織を識別する情報である。例えば、会社全体、会社内の部又は課等が一つの組織として登録されてもよい。イベント３０７は、ユーザ（ＵＳ）が参加しているイベントを識別する情報である。ここでイベントとは、後述する評価スコアを上げるために企画されるものであり、ユーザ（ＵＳ）が参加することができる。ユーザ（ＵＳ）が複数のイベントに参加している場合には、複数のイベントを識別する情報がイベント３０７に登録される。

図４は、本発明の実施例のクライアント（ＣＬ）が保持する加速度センサテーブルの説明図である。

図４の加速度センサテーブル４００は、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した、センサ部（ＣＬ０２）に含まれる加速度センサ等の計測結果を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図４は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した加速度センサ等の計測結果を格納していく上で必要な情報があれば、追加することが好ましい。

図４に例示する加速度センサテーブル４００は、ユーザＩＤ４０１、日付４０２、時刻４０３、Ｘ軸４０４、Ｙ軸４０５、Ｚ軸４０６、ローリング４０７、ピッチング４０８及びヨーイング４０９を含む。ユーザＩＤ４０１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付４０２及び時刻４０３は、加速度センサ等の計測時点を示す日付及び時刻を示す。

Ｘ軸４０４、Ｙ軸４０５及びＺ軸４０６は、それぞれ、３軸加速度センサによって計測されたＸ軸方向、Ｙ軸方向及びＺ軸方向の加速度を示す。ローリング４０７、ピッチング４０８及びヨーイング４０９は、それぞれ、３軸ジャイロセンサによって計測されたローリング、ピッチング及びヨーイング（すなわち、互いに直交する３方向を軸とする角速度）の値を示す。

センサ部（ＣＬ０２）がジャイロセンサを含まない場合、加速度センサテーブル４００はローリング４０７、ピッチング４０８及びヨーイング４０９を含まなくてもよい。所定の間隔で（図４の例では１秒ごとに）加速度及び角速度が計測され、その結果が加速度センサテーブル４００に格納される。

図５は、本発明の実施例のクライアント（ＣＬ）が保持するＧＰＳセンサテーブルの説明図である。

図５のＧＰＳセンサテーブル５００は、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した、センサ部（ＣＬ０２）に含まれるＧＰＳセンサの計測結果を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図５は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得したＧＰＳセンサの計測結果を格納していく上で必要な情報があれば、追加することが好ましい。

図５に例示するＧＰＳセンサテーブル５００は、ユーザＩＤ５０１、日付５０２、時刻５０３、緯度５０４及び経度５０５を含む。ユーザＩＤ５０１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付５０２、時刻５０３、緯度５０４及び経度５０５は、それぞれ、計測が行われた日付、時刻、計測された緯度及び経度を示す。所定の間隔で（図５の例では１秒ごとに）緯度及び経度が計測され、その結果がＧＰＳセンサテーブル５００に格納される。

なお、上記の位置情報のクライアント（ＣＬ）への記録及びサーバ（ＳＳ）への送信は、ユーザ（ＵＳ）の同意が得られた場合に行うことが望ましい。

図６は、本発明の実施例のクライアント（ＣＬ）が保持する温度・照度・気圧・音量センサテーブルの説明図である。

図６の温度・照度・気圧・音量センサテーブル６００は、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した、センサ部（ＣＬ０２）に含まれる温度・照度・気圧・音量センサの計測結果を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図６は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した温度、照度、気圧及び音量又はそれ以外のセンサ計測結果を格納していく上で必要な情報があれば、追加することが好ましい。

図６に例示する温度・照度・気圧・音量センサテーブル６００は、ユーザＩＤ６０１、日付６０２、時刻６０３、温度６０４、照度６０５、気圧６０６及び音量６０７を含む。ユーザＩＤ６０１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付６０２、時刻６０３、温度６０４、照度６０５、気圧６０６及び音量６０７は、それぞれ、計測が行われた日付、時刻、計測された温度、照度、気圧及び音量を示す。所定の間隔で（図５の例では１秒ごとに）温度等が計測され、その結果が温度・照度・気圧・音量センサテーブル６００に格納される。

図７は、本発明の実施例のクライアント（ＣＬ）が保持する操作履歴テーブルの説明図である。

図７の操作履歴テーブル７００は、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した操作履歴を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図７は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した操作履歴を格納していく上で必要な情報があれば、追加することが好ましい。

図７に例示する操作履歴テーブル７００は、ユーザＩＤ７０１、日付７０２、時刻７０３、端末名７０４、ＯＳ７０５及び操作７０６を含む。ユーザＩＤ７０１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付７０２、時刻７０３、端末名７０４、ＯＳ７０５及び操作７０６は、それぞれ、ユーザ（ＵＳ）によるクライアント（ＣＬ）に対する操作が行われた日付、時刻、当該クライアント（ＣＬ）の名称（例えば機種名又は識別情報等）、当該クライアント（ＣＬ）で稼働しているＯＳの識別情報（例えばバージョン番号等）、及び、行った操作の内容を示す。ユーザ（ＵＳ）がクライアント（ＣＬ）を操作するたびに、その操作に関する情報が操作履歴テーブル７００に格納される。

なお、上記の操作履歴のクライアント（ＣＬ）への記録及びサーバ（ＳＳ）への送信は、ユーザ（ＵＳ）の同意が得られた場合に行うことが望ましい。

図８は、本発明の実施例のクライアント（ＣＬ）が保持する特徴量テーブルの説明図である。

図８の特徴量テーブル８００は、図２９のセンサ取得および分析対象判定処理フローに示す処理によって生成された加速度特徴量、ＧＰＳ特徴量、その他センサ特徴量、及び操作特徴量等の特徴量を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図８は一例であり、加速度特徴量、ＧＰＳ特徴量、その他センサ特徴量及び操作特徴量等の特徴量を格納していく上で必要な情報があれば、追加することが好ましい。

図８に例示する特徴量テーブル８００は、ユーザＩＤ８０１、日付８０２、時刻８０３、加速度特徴量８０４、ＧＰＳ特徴量８０５、気温特徴量８０６、音量特徴量８０７及び操作特徴量８０８を含む。ユーザＩＤ８０１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付８０２及び時刻８０３は、それぞれの特徴量の計算のもとになったデータが取得された日付及び時刻を示す。すなわち、日付８０２及び時刻８０３によって特定される時刻に計測されたセンサデータに基づいて計算された特徴量が加速度特徴量８０４～操作特徴量８０８に格納される。

加速度特徴量８０４は、対応する時刻に計測された加速度（例えばＸ軸４０４、Ｙ軸４０５及びＺ軸４０６の値）の特徴量である。この特徴量の計算にさらにローリング４０７、ピッチング４０８及びヨーイング４０９の値が用いられてもよい。ＧＰＳ特徴量８０５は、対応する時刻に計測されたＧＰＳ情報（例えば緯度５０４及び経度５０５の値）の特徴量である。

気温特徴量８０６及び音量特徴量８０７は、それぞれ、対応する時刻に計測された気温及び音量（例えば温度６０４及び音量６０７の値）の特徴量である。図８では省略されているが、同様に、照度６０５の特徴量及び気圧６０６の特徴量が特徴量テーブル８００に含まれてもよい。操作特徴量８０８は、対応する時刻に行われた操作（例えば操作７０６の値）の特徴量である。

図９は、本発明の実施例のクライアント（ＣＬ）が保持する行動量モデルテーブルの説明図である。

図９の行動モデルテーブルは、図２９のセンサ取得および分析対象判定処理フローの行動モデル判定及び他センサ行動モデル判定に使用するモデルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図９は一例であり、行動モデル判定及び他センサ行動モデル判定をしていく上で必要な情報があれば、追加することが好ましい。

図９に例示する行動モデルテーブル９００は、行動モデルＩＤ９０１、行動内容９０２、使用センサデータ９０３及びモデル９０４を含む。行動モデルＩＤ９０１は、それぞれの行動モデルを識別する情報である。行動内容９０２は、それぞれの行動モデルによって判定されるユーザ（ＵＳ）の行動内容を示す。使用センサデータ９０３は、それぞれの行動モデルにおいて使用されるセンサデータの種類を示す。モデル９０４は、生成されたそれぞれの行動モデルである。

例えば、行動内容９０２が「歩行」、使用センサデータ９０３が「加速度」であるモデル９０４には、加速度データに基づいてユーザ（ＵＳ）が歩行したかどうかを判定するためのモデルが格納される。このモデルは、例えば加速度データの特徴量であってもよい。その場合、取得されたユーザ（ＵＳ）の加速度データの特徴量が歩行モデルとして格納された特徴量と比較され、両者が類似する場合に当該ユーザ（ＵＳ）が歩行したと判定されてもよい。

行動内容９０２の他の例として、ユーザ（ＵＳ）が他のユーザと会話する行動、乗り物に乗って移動する行動、クライアント（ＣＬ）を操作する行動、及び、クライアント（ＣＬ）を身につけずに放置する行動などが挙げられる。それぞれの行動に対応して、適切な種類のセンサデータ（例えば「会話」の場合は「音量」など）を使用したモデルが行動モデルテーブル９００に格納される。一つの行動内容を判定するためのモデルに複数種類のセンサデータが使用されてもよい。

図１０は、本発明の実施例のクライアント（ＣＬ）が保持する分析対象判定処理結果テーブルの説明図である。

図１０の分析対象判定処理結果テーブル１０００は、図２９のセンサ取得および分析対象判定処理フローの行動モデル判定、他センサ行動モデル判定、及び分析対象判定によって判定した結果を格納するテーブルであり、クライアント（ＣＬ）の記録部（ＣＬ０４）に格納されている。図１０は一例であり、行動モデル判定、他センサ行動モデル判定、及び分析対象判定によって判定された結果を格納していく上で必要な情報があれば、追加することが好ましい。

図１０に例示する分析対象判定処理結果テーブル１０００は、ユーザＩＤ１００１、日付１００２、時刻１００３、行動モデル判定結果１００４、他センサ判定結果１００５及び分析対象判定結果１００６を含む。ユーザＩＤ１００１は、クライアント（ＣＬ）を使用するユーザ（ＵＳ）を識別する情報である。日付１００２及び時刻１００３は、それぞれの行動の判定の対象になったデータが取得された日付及び時刻を示す。すなわち、日付１００２及び時刻１００３によって特定される時刻に計測されたセンサデータに基づいて判定されたユーザ（ＵＳ）の行動に関する情報が行動モデル判定結果１００４～分析対象判定結果１００６に格納される。

行動モデル判定結果１００４は、計測されたセンサデータの特徴量と行動モデルとに基づいて判定されたユーザ（ＵＳ）の行動を示す。例えば、行動モデル判定結果１００４は「放置」「歩行」等であってもよいし、いずれの行動にも該当しないと判定された場合には「該当なし」であってもよい。

他センサ判定結果１００５は、行動モデルに基づく行動の判定に用いられるもの以外のセンサデータに基づくユーザ（ＵＳ）の行動の判定結果を示す。例えば、ＧＰＳデータに基づいて、ユーザ（ＵＳ）の単位時間当たりの移動距離が所定の基準より大きい場合には、そのことを示す情報が格納されてもよい。その場合、ユーザ（ＵＳ）が自動車又は電車等の乗り物に乗って移動していることが推定される。

分析対象判定結果１００６は、取得されたセンサデータが、ユーザ（ＵＳ）の分析の対象として適しているか否かの判定結果を示す。例えば、後述するユーザ（ＵＳ）の状態を分析するための評価スコアが、ユーザ（ＵＳ）の勤務中の状態を分析することを目的とするものである場合、ユーザ（ＵＳ）が勤務中でないと推定される時間帯に取得されたセンサデータは分析対象に適さない（すなわち「異常」）と判定される。図１０の例では、ユーザ（ＵＳ）が自動車又は電車等の乗り物に乗って移動していると推定される場合には、ユーザ（ＵＳ）が勤務中でないため、分析対象に適さないと判定されている。

図１１は、本発明の実施例のサーバ（ＳＳ）が保持するユーザ情報テーブルの説明図である。

図１１のユーザ情報テーブル１１００は、ユーザの情報を管理しているテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１１は一例であり、ユーザの情報を管理していく上で必要な情報があれば、追加することが好ましい。

図１１に例示するユーザ情報テーブル１１００は、ユーザＩＤ１１０１、氏名１１０２、会社名１１０３、所属１１０４、チーム１１０５、組織１１０６及びイベント１１０７を含む。これらは、それぞれ、ユーザ情報テーブル３００（図３参照）のユーザＩＤ３０１、氏名３０２、会社名３０３、所属３０４、チーム３０５、組織３０６及びイベント３０７に対応する。各ユーザ（例えばユーザ（ＵＳ）及びユーザ（ＵＳ２）等）のクライアント（例えばクライアント（ＣＬ）及びクライアント（ＣＬ２）等）のユーザ情報テーブル３００に保持された情報が収集され、ユーザ情報テーブル１１００に格納される。

図１２は、本発明の実施例のサーバ（ＳＳ）が保持するチーム情報テーブルの説明図である。

図１２のチーム情報テーブル１２００は、チームの情報を管理しているテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１２は一例であり、チームの情報を管理していく上で必要な情報があれば、追加することが好ましい。

図１２に例示するチーム情報テーブル１２００は、チームＩＤ１２０１、チーム名１２０２、リーダ１２０３及びメンバ１２０４を含む。チームＩＤ１２０１及びチーム名１２０２は、各チームを識別する情報である。リーダ１２０３には各チームのリーダのＩＤ又は氏名等が登録され、メンバ１２０４には各チームのメンバのＩＤ又は氏名等のリストが登録される。

図１３は、本発明の実施例のサーバ（ＳＳ）が保持する組織情報テーブルの説明図である。

図１３の組織情報テーブル１３００は、組織の情報を管理しているテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１３は一例であり、組織の情報を管理していく上で必要な情報があれば、追加することが好ましい。

図１３に例示する組織情報テーブル１３００は、組織ＩＤ１３０１、組織名１３０２、リーダ１３０３及びメンバ１３０４を含む。組織ＩＤ１３０１及び組織名１３０２は、各組織を識別する情報である。リーダ１３０３には各組織のリーダのＩＤ又は氏名等が登録され、メンバ１３０４には各組織のメンバのＩＤ又は氏名等のリストが登録される。

図１４は、本発明の実施例のサーバ（ＳＳ）が保持するアクセスログテーブルの説明図である。

図１４のアクセスログテーブル１４００は、ユーザ（ＵＳ）のクライアント（ＣＬ）がサーバ（ＳＳ）にアクセスしたことに関する情報を管理しているテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納させている。図１４は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）がサーバ（ＳＳ）にアクセスしたことに関する情報を管理していく上で必要な情報があれば、追加することが好ましい。

図１４に例示するアクセスログテーブル１４００は、ユーザＩＤ１４０１、日付１４０２、時刻１４０３及びアクセス内容１４０４を含む。ユーザＩＤ１４０１は、クライアント（ＣＬ）を使用してサーバ（ＳＳ）にアクセスしたユーザ（ＵＳ）を識別する情報である。日付１４０２及び時刻１４０３は、アクセスが行われた日付及び時刻を示す。アクセス内容１４０４は、行われたアクセスの内容を示す。アクセスの内容の例をいくつか挙げるとすれば、クライアント（ＣＬ）が保持するデータをサーバ（ＳＳ）に転送して格納する「データ格納」、後述する施策のいずれかを選択する「施策選択」、作成した施策を投稿する「施策投稿」、及び、施策を行った結果を報告する「報告」等である。

図１５は、本発明の実施例のサーバ（ＳＳ）が保持する加速度センサテーブルの説明図である。

図１５の加速度センサテーブル１５００は、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した加速度センサの計測結果を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１５は一例であり、ユーザ（ＵＳ）のクライアント（ＣＬ）から取得した加速度センサの計測結果を格納していく上で必要な情報があれば、追加することが好ましい。

図１５に例示する加速度センサテーブル１５００は、ユーザＩＤ１５０１、日付１５０２、時刻１５０３、Ｘ軸１５０４、Ｙ軸１５０５、Ｚ軸１５０６、ローリング１５０７、ピッチング１５０８及びヨーイング１５０９を含む。これらは、それぞれ、加速度センサテーブル４００（図４）のユーザＩＤ４０１、日付４０２、時刻４０３、Ｘ軸４０４、Ｙ軸４０５、Ｚ軸４０６、ローリング４０７、ピッチング４０８及びヨーイング４０９に対応する。各ユーザ（例えばユーザ（ＵＳ）及びユーザ（ＵＳ２）等）のクライアント（例えばクライアント（ＣＬ）及びクライアント（ＣＬ２）等）の加速度センサテーブル４００に保持された情報が収集され、加速度センサテーブル１５００に格納される。

図１６は、本発明の実施例のサーバ（ＳＳ）が保持する分析対象判定処理結果テーブルの説明図である。

図１６の分析対象判定処理結果テーブル１６００は、図２９のセンサ取得および分析対象判定処理フローの行動モデル判定、他センサ行動モデル判定、及び分析対象判定によって判定した結果を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１６は一例であり、行動モデル判定、他センサ行動モデル判定、及び分析対象判定によって判定された結果を格納していく上で必要な情報があれば、追加することが好ましい。

図１６に例示する分析対象判定処理結果テーブル１６００は、ユーザＩＤ１６０１、日付１６０２、時刻１６０３、行動モデル判定結果１６０４、他センサ判定結果１６０５及び分析対象判定結果１６０６を含む。これらは、それぞれ、分析対象判定処理結果テーブル１０００（図１０）のユーザＩＤ１００１、日付１００２、時刻１００３、行動モデル判定結果１００４、他センサ判定結果１００５及び分析対象判定結果１００６に対応する。各ユーザ（例えばユーザ（ＵＳ）及びユーザ（ＵＳ２）等）のクライアント（例えばクライアント（ＣＬ）及びクライアント（ＣＬ２）等）の加分析対象判定処理結果テーブル１０００に保持された情報が収集され、分析対象判定処理結果テーブル１６００に格納される。

図１７は、本発明の実施例のサーバ（ＳＳ）が保持する個人評価スコアテーブルの説明図である。

図１７の個人評価スコアテーブル１７００は、図３１の個人評価スコア処理フローによって判定した個人の評価スコアを格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１７は一例であり、図３１の個人評価スコア処理フローによって判定した個人の評価スコアを格納していく上で必要な情報があれば、追加することが好ましい。

図１７に例示する個人評価スコアテーブル１７００は、ユーザＩＤ１７０１、日付１７０２及び評価スコア１７０３を含む。ユーザＩＤ１７０１は、各ユーザを識別する情報である。評価スコア１７０３には、日付１７０２が示す日について計算された各ユーザのスコアが格納される。

図１８は、本発明の実施例のサーバ（ＳＳ）が保持するチーム評価スコアテーブルの説明図である。

図１８のチーム評価スコアテーブル１８００は、図３２のチーム／組織評価スコア処理フローによって判定したチームの評価スコアを格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１８は一例であり、図３２のチーム／組織評価スコア処理フローによって判定したチームの評価スコアを格納していく上で必要な情報があれば、追加することが好ましい。

図１８に例示するチーム評価スコアテーブル１８００は、チームＩＤ１８０１、日付１８０２及び評価スコア１８０３を含む。チームＩＤ１８０１は、各チームを識別する情報である。評価スコア１８０３には、日付１８０２が示す日について計算された各チームの評価スコアが格納される。

図１９は、本発明の実施例のサーバ（ＳＳ）が保持する組織評価スコアテーブルの説明図である。

図１９の組織評価スコアテーブル１９００は、図３２のチーム／組織評価スコア処理フローによって判定した組織の評価スコアを格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図１９は一例であり、図３２のチーム／組織評価スコア処理フローによって判定した組織の評価スコアを格納していく上で必要な情報があれば、追加することが好ましい。

図１９に例示する組織評価スコアテーブル１９００は、組織ＩＤ１９０１、日付１９０２及び評価スコア１９０３を含む。組織ＩＤ１９０１は、各組織を識別する情報である。評価スコア１９０３には、日付１９０２が示す日について計算された各組織の評価スコアが格納される。

図２０は、本発明の実施例のサーバ（ＳＳ）が保持する施策テーブルの説明図である。

図２０の施策テーブル２０００は、施策を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２０は一例であり、施策を格納していく上で必要な情報があれば、追加することが好ましい。

図２０に例示する施策テーブル２０００は、施策ＩＤ２００１、施策名２００２、施策内容２００３、施策登録者名２００４、評価スコア効果２００５及び評価スコア効果ヒストグラム２００６を含む。施策ＩＤ２００１及び施策名２００２は、登録された施策を識別する情報である。施策内容２００３は、登録された施策の内容を示す情報であり、例えば、その施策を選択したユーザ（ＵＳ）が実行すべき行動の内容等を含んでもよい。

施策登録者名２００４は、施策を登録した者を識別する情報である。施策は、システムの運営者等があらかじめ用意してもよいが、ユーザ（ＵＳ）自身が作成してシステムに投稿してもよい。例えば、いずれかのユーザ（ＵＳ）が作成して投稿した施策の場合、そのユーザ（ＵＳ）のＩＤ又は名前が施策登録者名２００４に登録される。評価スコア効果２００５は、登録された施策を実行することによる評価スコアの改善の効果の程度（言い換えると、心理状態の変化量）を示す指標である。評価スコア効果ヒストグラム２００６は、評価スコア効果の値の分布を示す。

図２１は、本発明の実施例のサーバ（ＳＳ）が保持する施策登録者テーブルの説明図である。

図２１の施策登録者テーブル２１００は、施策を登録した人に関する情報を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２１は一例であり、施策を登録した人を格納していく上で必要な情報があれば、追加することが好ましい。

図２１に例示する施策登録者テーブル２１００は、施策登録者ＩＤ２１０１、登録者名２１０２、ユーザＩＤ２１０３、施策ＩＤ２１０４及び登録日時２１０５を含む。施策登録者ＩＤ２１０１及び登録者名２１０２は、施策を登録した者（施策登録者）を識別する情報である。ユーザＩＤ２１０３は、施策登録者がユーザ（ＵＳ）である場合に、そのユーザ（ＵＳ）を識別する情報である。施策ＩＤ２１０４は登録された施策を識別する情報であり、登録日時２１０５はその施策が登録された日時を示す。

図２２は、本発明の実施例のサーバ（ＳＳ）が保持する施策利用テーブルの説明図である。

図２２の施策利用テーブル２２００は、施策を利用した人の情報を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２２は一例であり、施策を利用した人の情報を格納していく上で必要な情報があれば、追加することが好ましい。

図２２に例示する施策利用テーブル２２００は、ユーザＩＤ２２０１、日付２２０２、時刻２２０３、施策ＩＤ２２０４、施策実施有無２２０５、施策宣言２２０６及び実施後コメント２２０７を含む。ユーザＩＤ２２０１は、各ユーザを識別する情報である。日付２２０２及び時刻２２０３は、各ユーザが施策を選択した日付及び時刻を示す。施策ＩＤ２２０４は、各ユーザが選択した施策を識別する情報である。施策実施有無２２０５は、各ユーザが選択した施策を実際に実施したか否かを示す。施策宣言２２０６は、施策を選択したユーザが任意に入力する宣言である。実施後コメント２２０７は、施策を実施したユーザが任意に入力するコメントである。

図２３は、本発明の実施例のサーバ（ＳＳ）が保持する報酬テーブルの説明図である。

図２３の報酬テーブル２３００は、報酬を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２３は一例であり、報酬を格納していく上で必要な情報があれば、追加することが好ましい。

ここで、報酬とは、評価スコア等（例えば評価スコアそのもの又は評価スコアに基づいて算出される指標）に応じてユーザ（ＵＳ）又は施策登録者等に提供されるものであり、例えば、報酬登録者が提供する物品又はサービス等である。報酬は、物品又はサービス等と交換可能なクーポンとして提供されてもよい。

図２３に例示する報酬テーブル２３００は、報酬ＩＤ２３０１、報酬名２３０２、報酬内容２３０３、報酬登録者名２３０４及び変換レート２３０５を含む。報酬ＩＤ２３０１及び報酬名２３０２は、報酬を識別する情報である。報酬内容２３０３は、その報酬がどのようなものであるかを示す。報酬登録者名２３０４は、その報酬を登録した者を識別する情報である。変換レート２３０５は、評価スコア等と報酬との間の変換レートを示す。

図２４は、本発明の実施例のサーバ（ＳＳ）が保持する報酬登録者テーブルの説明図である。

図２４の報酬登録者テーブル２４００は、報酬を登録した人に関する情報を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２４は一例であり、報酬を登録した人に関する情報を格納していく上で必要な情報があれば、追加することが好ましい。

図２４に例示する報酬登録者テーブル２４００は、報酬登録者ＩＤ２４０１、登録者名２４０２、ユーザＩＤ２４０３、報酬ＩＤ２４０４及び登録日時２４０５を含む。報酬登録者ＩＤ２４０１及び登録者名２４０２は、報酬を登録した者（報酬登録者）を識別する情報である。ユーザＩＤ２４０３は、報酬登録者がユーザ（ＵＳ）である場合に、そのユーザ（ＵＳ）を識別する情報である。報酬ＩＤ２４０４は登録された報酬を識別する情報であり、登録日時２４０５はその報酬が登録された日時を示す。

図２５は、本発明の実施例のサーバ（ＳＳ）が保持する報酬利用テーブルの説明図である。

図２５の報酬利用テーブル２５００は、報酬を利用した人の情報を格納するテーブルであり、サーバ（ＳＳ）の記録部（ＳＳ０６）に格納されている。図２５は一例であり、報酬を利用した人の情報を格納していく上で必要な情報があれば、追加することが好ましい。

図２５に例示する報酬利用テーブル２５００は、ユーザＩＤ２５０１、日付２５０２、時刻２５０３、報酬ＩＤ２５０４、ポイント２５０５及び利用日時２５０６を含む。ユーザＩＤ２５０１は、各ユーザを識別する情報である。日付２５０２及び時刻２５０３は、各ユーザが報酬を選択した日付及び時刻を示す。報酬ＩＤ２５０４は、各ユーザが選択した報酬を識別する情報である。ポイント２５０５は、各ユーザが選択した報酬に対応するポイントの数（例えば交換されるクーポンの点数等）を示す。利用日時２５０６は、各ユーザが選択した報酬を利用した日時を示す。

図２６は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示されるアプリケーションのトップページの説明図である。

具体的には、図２６は、アプリを起動すると最初に表示させる画面を示す。この画面でユーザ（ＵＳ）がそれぞれの項目をタッチすることで、それぞれの項目の処理に進むことができる。

このアプリケーションはクライアント（ＣＬ）の記録部に格納されており、処理部を経由して表示部に送られる。画面（ＣＬＯＤ）はタッチパネルになっており、入出力部が反応する仕組みになっている。ただし、画面（ＣＬＯＤ）は、その上で項目の選択等の操作ができればよく、タッチパネル以外でも同様な操作ができれば、それを採用してもよい。

図２６に示すトップページ画面２６００には、センサ計測２６０１、評価スコア２６０２、施策選択２６０３、新規施策登録２６０４、施策状況（施策）２６０５、施策状況（登録者）２６０６、報酬選択２６０７、新規報酬登録２６０８及び報酬状況２６０９等のボタンが表示され、それらのいずれかを操作する（例えばタッチパネル上でタッチする）とそれぞれの画面に移行する。

図２７は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示されるセンサ計測のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にあるセンサ計測２６０１のボタンを押すと図２７に示すセンサ計測のアプリケーション画面２７００に遷移する。この画面２７００の構成は以下の様になっている。

ユーザ２７０１には、計測対象となっているユーザ名が表示されている。

ステータス２７０２には、現在の状態が表示されている。例えば、センサが計測していない時は「未計測」、センサが計測している時は「計測」と表示するなど、現状はどのような状態になっているかを、このステータス２７０２を見ることで確認できる。

計測開始２７０３は、センサの計測を開始するボタンである。この計測開始２７０３を押すと、図２８のシーケンス図の「計測開始ボタンを押す」（ステップ２８０１）以降の処理が実行される。本実施例では、計測開始ボタン２７０３を操作すると上記の処理が起動することになっているが、タイマーなどを設定しておくことで、自動的に処理が起動してもよい。

計測終了２７０４は、センサの計測を終了するボタンである。この計測終了２７０４を押すと、図２８のシーケンス図の「計測終了ボタンを押す」（ステップ２８０５）以降の処理が実行される。本実施例では、計測終了ボタン２７０４を操作すると上記の処理が実行され、センサの計測が終了することになっているが、タイマーなどを設定しておくことで、自動的に終了してもよい。

戻る２７０５は、図２６のアプリケーションのトップページに戻るために操作されるボタンである。センサの計測が開始されてから終了する前に戻るボタン２７０５を押したとしても、センサ計測の動作は継続する。

図２８は、本発明の実施例の処理システムが実行する計測開始及び計測終了の処理を示すシーケンス図である。

このシーケンス図は、クライアント（ＣＬ）の画面（ＣＬＯＤ）に表示されるセンサ計測のアプリケーション画面２７００において、計測開始ボタン２７０３を押した時と、計測終了ボタン２７０４を押した時の処理の流れを示す。

具体的には、このシーケンス図は、ユーザ（ＵＳ）、クライアント（ＣＬ）、サーバ（ＳＳ）、及びサーバ（ＳＳ）内のデータベースの４つのやり取りを示したものである。時系列としては、下に進むにつれて時間が進んだ状態となっている。

「計測開始ボタンを押す」（ステップ２８０１）は、センサ計測のアプリケーション画面２７００においてユーザ（ＵＳ）が計測開始ボタン２７０３を押す動作を示している。押した場合には、クライアント（ＣＬ）に対してリクエストが送信される（ステップ２８０２）。

「センサ取得および分析対象判定処理」（ステップ２８０３）は、実際にセンサ計測（すなわちセンサ部（ＣＬ０２）に含まれる加速度センサ等による計測）が開始される処理である。センサ取得および分析対象判定処理（ステップ２８０３）の流れの詳細は図２９に示す。

「計測画面表示」（ステップ２８０４）は、センサ取得および分析対象判定処理（ステップ２８０３）が動作している最中に、センサ計測のアプリケーション画面２７００のステータス２７０２に「計測中」と表示させる処理である。このようにして、計測開始ボタン２７０３を押すことで、クライアント（ＣＬ）のセンサ取得が起動することができる。

「計測終了ボタンを押す」（ステップ２８０５）は、センサ計測のアプリケーション画面２７００においてユーザ（ＵＳ）が計測終了ボタン２７０４を押す動作を示している。押した場合には、クライアント（ＣＬ）に対してリクエストが送信される（ステップ２８０６）。

「計測完了」（ステップ２８０７）は、クライアント（ＣＬ）が、これまでセンサ取得および分析対象判定処理（ステップ２８０３）によってセンサ計測を行っていたことを停止する処理である。

「データ登録」（ステップ２８０８）は、クライアント（ＣＬ）が、センサ取得および分析対象判定処理（ステップ２８０３）によってクライアント（ＣＬ）に記録していたセンサデータなどをサーバ（ＳＳ）のデータベースに登録する作業を開始することを示している。

データ登録中に、センサ計測のアプリケーション画面２７００のステータス２７０２が「データ登録中」と表示される。

データ登録（ステップ２８０８）によって、サーバ（ＳＳ）にはリクエストと計測データが送信される（ステップ２８０９）。クライアント（ＣＬ）は、これらをサーバ（ＳＳ）に送信する際に、データ量が大きくなる場合には、圧縮などの処理を施してもよい。

「データベース登録」（ステップ２８１０）は、サーバ（ＳＳ）がクライアント（ＣＬ）から取得した計測データをデータベースに登録する処理である。データはサーバ（ＳＳ）の記録部（ＳＳ０６）内にあるそれぞれのデータベースに格納される。

また、クライアント（ＣＬ）からサーバ（ＳＳ）にアクセスした際にはサーバ（ＳＳ）内のアクセスログに何時、誰が、どのような処理を行ったかを記録する。

また、アクセスする際には、クライアント（ＣＬ）とサーバ（ＳＳ）との接続が正しい接続であることを確認するために、パスワードなどの認証、および、ＳＳＨ又はＶＰＮなどセキュリティレベルが高いネットワークを用いてもよい。

「データベース登録」（ステップ２８１０）では、サーバ（ＳＳ）は、送られてきたリクエスト及び計測データをデータベースに登録するためのクエリに変換する。そして、変換したクエリをデータベースに登録する（ステップ２８１１、２８１２）。データベースへの登録が終わると、データベースは登録を完了したことを示すデータをサーバに送信する（ステップ２８１３）。

データ保存（ステップ２８１２）は、送信されてきたクエリをサーバ（ＳＳ）にあるデータベースに格納する処理である。リクエスト及び計測データは、それぞれに該当するデータベースのテーブルに格納する。例えば、計測データに加速度データが含まれる場合、その加速度データがデータベース内の加速度センサテーブル１５００に格納される。

「センサデータ登録完了」（ステップ２８１４）は、データベースから登録完了データが送られてきたら（ステップ２８１３）、サーバ（ＳＳ）側でセンサデータの登録が完了したということを受け取る処理である。そして、サーバ（ＳＳ）は、登録が完了したら、クライアント（ＣＬ）に対して、登録が完了したことを通知する（ステップ２８１５）。

もし、データが登録できなかった場合には、サーバ（ＳＳ）は、登録完了データの内容を解析し、データベースにクエリを再送信するのか、クライアント（ＣＬ）から計測データを入手するのかなどの動作を行う。

「センサデータ登録表示」（ステップ２８１６、２８１７）は、サーバ（ＳＳ）からネットワーク（ＮＷ）を通じてセンサデータ登録完了が通知されたら、クライアント（ＣＬ）が、センサ計測のアプリケーション画面２７００のステータス２７０２にデータ登録完了と表示する処理である。

「センサデータ登録データ確認」（ステップ２８１８）は、ユーザ（ＵＳ）がクライアント（ＣＬ）のセンサ計測のアプリケーション画面２７００のステータス２７０２がデータ登録完了であると確認することで、センサデータ登録が完了したことを確認する処理である。このようにして、計測終了ボタン２７０４を押すことで、クライアント（ＣＬ）のセンサ取得を停止することができる。

このシーケンス図では、計測終了ボタン２７０４を押すことで、サーバ（ＳＳ）にデータをアップロードしているが、対象となるデータがサーバ（ＳＳ）に上がっていれば、それ以外の方法を採用してもよい。例えば、計測中にデータをサーバにアップロードしてもよい。

さらに、上記のシーケンス図では、クライアント（ＣＬ）で計測したデータをネットワーク（ＮＷ）を通じてサーバ（ＳＳ）側に送信しているが、他の媒体（ＵＳＢメモリ、ＳＤカードなど）を使用してもよい。

図２９は、本発明の実施例のクライアント（ＣＬ）が実行するセンサ取得および分析対象判定処理を示すフローチャートである。

これは、図２８のシーケンス図におけるセンサ取得および分析対象判定処理（ステップ２８０３）を詳細に説明するものである。

センサ取得および分析対象判定処理（ステップ２８０３）では、実際にクライアント（ＣＬ）のセンサ部（ＣＬ０２）からセンサデータを取得し、そのデータから、分析に適しているデータであるかを判定する処理を行っている。クライアント（ＣＬ）は、センサデータ、その判定に用いた特徴量、及び判定結果をクライアント（ＣＬ）の記録部ＣＬ０４内にあるデータベースの各テーブルに格納する。

次に従来技術を述べる。特開２０１５－１４７０５３号公報では、加速度センサデータを用いて、アスレチック活動（運動量、歩数等）を測定する際、加速度データの外れ値を除外して解析している。この場合の課題としては、加速度データそのものをみて、外れ値としているため、端末放置及び乗り物への乗車時等、ユーザの評価スコア測定に適さないシーンの加速度データを除外できず、正確な評価スコア測定は困難である。

また、名札型センサなど専用デバイスを用いた場合として、加速度データを用いて、ユーザの評価スコアを計測する。従来は、名札型センサであり、ユーザがデバイスを装着するシーンが限られていたため、デバイス未装着等の加速度データを考慮する必要がなかった。この場合の課題としては、クライアント（ＣＬ）がスマートフォンのようなデバイスである場合には、シーンによっては評価スコア測定に利用すべきでない加速度データが含まれていることがある。

例えば、評価スコアが、ユーザの勤務中におけるストレスの低さ、満足感の高さ等を示す指標である場合、クライアント（ＣＬ）が勤務中にのみユーザ（ＵＳ）に装着される名札型センサなどの専用デバイスであれば、装着中に計測された全てのデータを評価スコア測定に利用してもよい。しかし、クライアント（ＣＬ）がユーザ（ＵＳ）の所持するスマートフォンである場合など、ユーザ（ＵＳ）が勤務中以外にも身につけるものであり、また、ときにはユーザ（ＵＳ）の身体から離れて放置されるものであれば、計測されたデータが評価スコア測定に利用すべきでない加速度データ等を含んでいると考えられる。

上記の課題を解決するための構成として、
ユーザの加速度データを受け付ける受付処理と、加速度データに基づいて、ユーザの複数種の行動がモデルとして格納されている行動データベースと、前記ユーザの加速度データと前記モデルとを比較して、前記ユーザの心理状態測定に利用する加速度データを抽出し、前記抽出した加速度データを用いて、前記ユーザの心理状態を算出することを特徴とする評価スコア計測・管理・効果算出・交換処理システム。さらに、加速度センサと異なる第二のセンサ（音、位置等）で取得したセンサデータを用いて、前記ユーザの心理状態測定に利用する加速度データを抽出する、という構成があげられる。

そして、その効果としては、より正確なユーザの評価スコア測定が可能となる。

次に、図２９のフローのそれぞれのステップを説明する。センサデータ取得（ステップ２９０１）は、クライアント（ＣＬ）に内蔵されたセンサ、および、クライアントに接続された外部センサによって計測されたデータをクライアント（ＣＬ）が取得する処理である。また、センサデータ取得（ステップ２９０１）は、クライアント（ＣＬ）が、クライアント（ＣＬ）内のＣＰＵ（すなわち処理部（ＣＬ０３））内のプロセスから、メール及びＷｅｂブラウザなどの動作記録を取得する処理を含んでもよい。クライアント（ＣＬ）は、これらのデータのそれぞれを周期的に、又は、非周期的にセンサデータの特性に合わせて、クライアント（ＣＬ）の記録部（ＣＬ０４）内にあるデータベースに格納する。クライアント（ＣＬ）は、データベースに格納されたセンサデータから、加速度特徴量、ＧＰＳ特徴量、その他センサ特徴量、及び操作履歴特徴量を計算する（ステップ２９０２～２９０５）。

ステップ２９０２で計算される加速度特徴量は、クライアント（ＣＬ）が取得した加速度データから求めた特徴量である。クライアント（ＣＬ）は、ある区間（例えば数秒又は数分等、所定の長さの時間帯）分の加速度データから基本統計量を用いることで特徴量を生成する。特徴量は人の動作を識別するために用いるものであり、より識別に適した特徴量があればそれを用いてもよい。

ステップ２９０３で計算されるＧＰＳ特徴量は、クライアント（ＣＬ）が取得したＧＰＳデータから求めた特徴量である。クライアント（ＣＬ）は、ある区間分のＧＰＳデータから基本統計量を用いることで特徴量を生成する。特徴量は人の動作を識別するために用いるものであり、より識別に適した特徴量があればそれを用いてもよい。

ステップ２９０４で計算されるその他センサ特徴量は、クライアント（ＣＬ）が上記の加速度センサ及びＧＰＳセンサ以外のセンサを内蔵している（又はそのようなセンサに接続されている）場合に、それによって取得したセンサデータから求めた特徴量である。クライアント（ＣＬ）は、ある区間分のセンサデータから基本統計量を用いることで特徴量を生成する。特徴量は人の動作を識別するために用いるものであり、より識別に適した特徴量があればそれを用いてもよい。

ステップ２９０５で計算される操作履歴特徴量は、スマートフォン（すなわちクライアント（ＣＬ））内のＣＰＵ（すなわち処理部（ＣＬ０３））内のプロセスから、メール又はＷｅｂブラウザなどの動作記録から求めた特徴量である。クライアント（ＣＬ）は、ある区間分の操作履歴から操作内容毎に基本統計量を用いることで特徴量を生成する。特徴量は人の動作を識別するために用いるものであり、より識別に適した特徴量があればそれを用いてもよい。

クライアント（ＣＬ）は、ステップ２９０２で計算された加速度特徴量とあらかじめ格納してある行動モデル２９０６とを比較することで、ユーザ（ＵＳ）がどのような行動をしているかを判定する（行動モデル判定、ステップ２９０７）。行動モデル２９０６は、例えば、行動モデルテーブル９００に格納されている種々の行動内容９０２に対応するモデル９０４のうち、使用センサデータ９０３の値「加速度」に対応するものである。加速度特徴量がいずれの行動に該当するとも判定できなかった場合、及び、加速度特徴量が複数の行動のいずれにも該当すると判定してしまった場合には、クライアント（ＣＬ）は、判定不能と判定することができる。

クライアント（ＣＬ）は、ステップ２９０３～２９０５で計算されたＧＰＳ特徴量、その他センサ特徴量、及び操作履歴特徴量と、あらかじめ格納してある他センサ行動判定モデル２９０８とを比較することで、ユーザ（ＵＳ）がどのような行動をしているかを判定する（他センサ行動モデル判定、ステップ２９０９）。他センサ行動判定モデル２９０８は、例えば、行動モデルテーブル９００に格納されている種々の行動内容９０２に対応するモデル９０４のうち、使用センサデータ９０３の「加速度」以外の値に対応するものである。特徴量がいずれの行動に該当するとも判定できなかった場合、及び、特徴量が複数の行動のいずれにも該当する判定してしまった場合には、クライアント（ＣＬ）は、判定不能と判定することができる。

行動モデル判定（ステップ２９０７）と他センサ行動モデル判定（ステップ２９０９）の処理順序は逆にしてもよい。

クライアント（ＣＬ）は、センサデータが分析対象としてふさわしいかの判定をする（分析対象判定、ステップ２９１０）。この判定は、行動モデル判定と他センサ行動モデル判定との結果に基づいて、区間毎に行われる。

クライアント（ＣＬ）は、分析対象判定（ステップ２９１０）の結果、及び、それまでに用いた特徴量などをクライアント（ＣＬ）の記録部（ＣＬ０４）のデータベースに格納する（分析対象結果テーブル記録、ステップ２９１１）。

上記のフローが実施されるタイミングは、例えば、１日に一回、又は、１時間に一回など、あらかじめ指定をすることで、任意に設定することができる。

本実施例では、クライアント（ＣＬ）の種類によって取得できるセンサデータ及び操作履歴の内容が異なることが想定できる。上記のフローは、その一例を示したものであり、センサデータ取得と、分析対象を判定する仕組みがあれば、取得できるデータに基づいて他の方法を用いて構わない。

図３０は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される評価スコアのアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある評価スコア２６０２のボタンを押すと図３０に示す評価スコアのアプリケーション画面３０００に遷移する。この画面３０００の構成は以下の様になっている。

ユーザ３００１には、計測対象となっているユーザ名が表示されている。

個人３００３には、個人の評価スコアが表示されている。矢印は先日に比べての増減を示している。例えば上向きの矢印は増加、下向きの矢印は減少、右向きの矢印は変化なしを示している。後述するチームの評価スコア及び組織の評価スコアについても同様である。個人の評価スコアの計測方法については図３１に記載する。

チーム３００４には、チームの評価スコアが表示されている。矢印は先日に比べての増減を示している。複数人の評価スコアの計測方法については図３２に記載する。

組織３００５には、組織の評価スコアが表示されている。矢印は先日に比べての増減を示している。複数人の評価スコアの計測方法については図３２に記載する。これはチームの求め方と同じである。

評価スコアポイント３００６には、評価スコアから導いたポイントが表示されている。このポイントは、報酬などに使用するポイントである。評価スコアポイントの計算方法については図３３に記載する。

ステータス３００２には、評価スコアから導いた値が表示されている。順位はある期間に対する評価スコアの和を参加者ごとに計算し、それを大きい順に並べた時の順位である。メダルはある期間の評価スコアの和から事前に定義していた値を超えた場合にその超えた分の大きさを示すものであり、例えば、大きさに応じて金、銀、銅という表示を行う。

戻る３００７は、図２６のアプリケーションのトップページに戻るために操作されるボタンである。戻るボタン３００７を押したとしても、センサ計測で行っている動作は継続している。

図３１は、本発明の実施例のサーバ（ＳＳ）が実行する個人評価スコア処理を示すフローチャートである。

この図には、個人のセンサデータから個人の評価スコアを求めるためのステップを示している。

センサ取得（ステップ３１０１）は、サーバ（ＳＳ）が、サーバのデータベースに格納されたセンサデータの中から対象のユーザ及び日時のデータを取得する処理である。

分析対象抽出（ステップ３１０２）は、サーバ（ＳＳ）が、センサデータの中から、分析対象であると判定されたデータを抽出する処理である。

特徴量抽出（ステップ３１０３）は、サーバ（ＳＳ）が、分析対象抽出（ステップ３１０２）によって抽出されたデータから、評価スコアを求めるために必要な特徴量を抽出する処理である。

評価スコア計算（ステップ３１０４）は、サーバ（ＳＳ）が、特徴量抽出（ステップ３１０３）で求めた特徴量を用いて評価スコアを計算する処理である。

評価スコア登録（ステップ３１０５）は、サーバ（ＳＳ）が、評価スコア計算（ステップ３１０４）によって求めた評価スコアをデータベースに登録する処理である。

この処理は１日１回など、定期的に計算を行うことが望ましい。また、この処理を逐次的に行ってもよい。

ここで、ステップ３１０４で行われる評価スコア計算の一例を説明する。評価スコアは、クライアント（ＣＬ）のセンサ部（ＣＬ０２）によって計測されたセンサデータに基づいて計算された、ユーザ（ＵＳ）の心理状態を示す指標である限り、どのようなものであってもよい。その一例を示せば、国際公開第２０１６／１２５２６０号（特許文献１）に記載されているように、ユーザ（ＵＳ）の状態を、加速度データの値が所定の閾値以上である活性状態と、それ以外の不活性状態とに分類し、活性状態の持続時間の出現頻度に基づいて、評価スコアを計算してもよい。例えば、活性状態の持続時間の出現頻度分布が所定の分布モデルに近いほど高くなるように評価スコアを計算してもよい。

図３２は、本発明の実施例のサーバ（ＳＳ）が実行するチーム／組織評価スコア処理を示すフローチャートである。

この図は、チーム又は組織のメンバのセンサデータからチーム又は組織の評価スコアを求めるためのステップを示している。

メンバ情報取得（ステップ３２０１）は、サーバ（ＳＳ）が、そのチーム又は組織に属しているメンバをリストアップする処理である。

特徴量取得（ステップ３２０２）は、サーバ（ＳＳ）が、メンバ情報取得（ステップ３２０１）によってリストアップされたユーザからセンサデータを求め、そこから評価スコアを求めるための特徴量を抽出する処理である。その求め方は、図３１の個人評価スコア処理フローで示したセンサ取得、分析対象抽出及び特徴量抽出と同じである。

評価スコア計算（ステップ３２０３）は、サーバ（ＳＳ）が、特徴量抽出（ステップ３２０２）で求めた特徴量を用いて評価スコアを計算する処理である。

評価スコア登録（ステップ３２０４）は、サーバ（ＳＳ）が、評価スコア計算（ステップ３２０３）によって求めた評価スコアをデータベースに登録する処理である。

この処理は１日１回など、定期的に計算を行うことが望ましい。また、この処理を逐次的に行ってもよい。

図３３は、本発明の実施例のサーバ（ＳＳ）が実行する評価スコアポイント処理を示すフローチャートである。

この図は、個人の評価スコアから個人の評価スコアポイントを求める処理である。個人の評価スコアポイントとは、ユーザ（ＵＳ）の評価スコアの変化に応じて当該ユーザ（ＵＳ）に付与されるポイントである。

評価スコア取得（ステップ３３０１）は、サーバ（ＳＳ）が、個人の評価スコアを取得する処理である。対象のユーザと日時の評価スコアを取得する。

評価スコアポイント計算（ステップ３３０２）は、サーバ（ＳＳ）が、評価スコア取得（ステップ３３０１）によって求めた評価スコアをベースで評価スコアポイントを算出する処理である。例えば、過去の一週間の平均の評価スコアと当日の評価スコアと差を、評価スコアポイントとして計算してもよい。この場合、差が負の値になった場合には評価スコアポイントを０とする。

さらに、他の算出方法として、評価スコアに所定の値を掛け合わせたものを評価スコアポイントとしてもよい。これらの算出方法は一例であり、毎日、評価スコアを高める活動を行った方が多くの評価スコアポイントが与えられるようになればよい。

評価スコアポイント登録（ステップ３３０３）は、サーバ（ＳＳ）が、評価スコア計算（ステップ３３０２）によって求めた評価スコアポイントをデータベースに登録する処理である。

この処理は１日１回など、定期的に計算を行うことが望ましい。事前に、図３１の個人の評価スコアを求めた方がよい。

図３４は、クライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される施策選択のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある施策選択２６０３のボタンを押すと図３４の画面に遷移する。この画面の構成は以下の様になっている。

ユーザ３４０１には、計測対象となっているユーザ名が表示されている。

ステータス３４０２は、施策選択におけるステータスを示している。

施策取得３４０３はサーバ（ＳＳ）に登録されている施策のリストを取得する処理を実行するために操作されるボタンである。施策取得のフローは図３５を参照して説明する。

施策登録３４０４は、選択した施策をサーバ（ＳＳ）に登録する処理を実行するために操作されるボタンである。施策登録のフローは図３５を参照して説明する。

施策リスト３４０５には、施策取得によって取得したリスト（すなわち施策リスト）が表示されている。施策リスト３４０５には、施策名と施策を行った時の数字とが記載されている。この例では評価スコア効果が記載されている。評価スコア効果を求めるフローは図３６及び図３７に示す。

施策リスト３４０５に含まれるいずれかの施策をタッチすることで、施策を選択することができる。施策実施の有無３４０６は、施策登録によって取得した施策を、実際に行ったかを申告するために操作されるボタンである。施策実施の有無を登録する処理のフローは図３５を参照して説明する。

戻る３４０７は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタンを押したとしても、センサ計測で行っている動作は継続している。

図３５は、本発明の実施例のユーザ（ＵＳ）がクライアント（ＣＬ）を介してサーバ（ＳＳ）のデータベースにアクセスする処理の流れを示すシーケンス図である。

これは、ユーザ（ＵＳ）、クライアント（ＣＬ）、サーバ（ＳＳ）、及びサーバ（ＳＳ）内のデータベースの４つの間のデータのやり取りを示したものである。時系列としては、下に進むにつれて時間が進んだ状態となっている。この処理は、後述するように、例えばユーザ（ＵＳ）が所望のデータをデータベースから取得したり、所望のデータをデータベースに登録したりするなど、種々の目的で行われる。

ユーザ（ＵＳ）がユーザ処理を行い（ステップ３５０１）、データをクライアント（ＣＬ）に入力する（ステップ３５０２）。これは、例えば、クライアント（ＣＬ）の入出力部ＣＬ０５の操作である。クライアント（ＣＬ）は、クライアント処理を行い（ステップ３５０３）、データをサーバ（ＳＳ）に送信する（ステップ３５０４）。サーバ（ＳＳ）は、サーバ処理を行い（ステップ３５０６）、データをデータベースに入力する（ステップ３５０７）。データベースは、データベース処理を行い（ステップ３５０７）、データをサーバ（ＳＳ）に出力する（ステップ３５０８）。サーバ（ＳＳ）は、サーバ処理を行い（ステップ３５０９）、データをクライアント（ＣＬ）に送信する（ステップ３５１０）。クライアント（ＣＬ）は、クライアント処理を行い（ステップ３５１１）、データをユーザ（ＵＳ）に出力する（ステップ３５１２）。ユーザ（ＵＳ）は、出力されたデータを参照して、ユーザ処理を行う（ステップ３５１３）。

ここで、図３５を参照して、ユーザ（ＵＳ）が施策を取得する処理を説明する。

ユーザ（ＵＳ）は、図３４の施策選択画面３４００の施策取得ボタン３４０３を押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対して、施策を取得するためのリクエストが入力される（ステップ３５０２）。

クライアント（ＣＬ）は、登録施策リスト一覧要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して現在登録されている施策の一覧のリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、登録施策テーブル検索要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在登録されている施策を検索するようにクエリを入力する（ステップ３５０６）。

データベースは、施策テーブル検索を行う（ステップ３５０７）。具体的には、データベースは、クエリに基づきテーブルを検索する。データベースは、検索の結果を施策リストとして、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、登録施策リスト一覧送信を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースから入手した施策リストを、クライアント（ＣＬ）に送信する（ステップ３５１０）。サーバ（ＳＳ）からクライアント（ＣＬ）に送信する際に、データ量が大きくなる場合には、圧縮などの処理を施してもよい。

クライアント（ＣＬ）は、登録施策リスト一覧表示を行う（ステップ３５１１）これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られてきた施策リストを施策選択画面３４００に表示する（ステップ３５１２）。

ユーザ（ＵＳ）は、登録施策リスト一覧確認を行う。これによって、ユーザ（ＵＳ）は、表示された施策選択画面を確認することで、施策リストの取得を完了したことを確認する。

次に、図３５を参照して、ユーザ（ＵＳ）が施策を登録する処理を説明する。

この処理は、上記の施策選択の処理が終了している時点で行われる。ユーザ（ＵＳ）は、図３４の施策選択画面３４００の施策登録ボタン３４０４を押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対して、施策を登録するためのリクエストが入力される（ステップ３５０２）。

クライアント（ＣＬ）は、選択施策登録を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して選択された施策を登録するためのリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、施策利用テーブル登録要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在選択されている施策を登録するようにクエリを入力する（ステップ３５０６）。

データベースは、施策利用テーブル登録を行う（ステップ３５０７）。これによって、クエリに基づき施策がテーブルに登録される。データベースは、その結果を示す登録完了のメッセージをサーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、施策利用テーブル登録確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの登録完了のメッセージをクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、登録済施策表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた登録結果を施策選択画面３４００に表示する（ステップ３５１２）。具体的には、ステータス３４０２に「登録中」と表示される。

ユーザ（ＵＳ）は、登録施策確認を行う（ステップ３５１３）。これによって、ユーザ（ＵＳ）は、施策選択画面３４００を確認することで、実際に施策の登録が完了したことを確認する。

次に、図３５を参照して、ユーザ（ＵＳ）が施策実施の有無を登録する処理を説明する。

この処理は、上記の施策選択の処理が終了している時点で行われる。ユーザ（ＵＳ）は、図３４の施策選択画面３４００の施策実施の有無ボタン３４０６を押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対して、施策実施の有無を登録するためのリクエストが入力される（ステップ３５０２）。

具体的には、ユーザ（ＵＳ）は、選択した施策を実施した場合には実施ボタン３４０６Ａを、実施していない場合には未実施ボタン３４０６Ｂを押す。前者の場合は施策が実施されたこと（すなわち施策実施有）を登録するためのリクエストが、後者の場合は施策が実施されていないこと（すなわち施策実施無）を登録するためのリクエストが、入力される。

クライアント（ＣＬ）は、施策実施の有無の登録を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して選択された施策実施の有無を登録するためのリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、施策実施の有無の登録要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在選択されている施策実施の有無を登録するようにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づき施策の利用の有無をテーブルに登録する（ステップ３５０７）。データベースは、その結果を示す登録完了のメッセージを、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、施策利用テーブル登録確認を行う。これによって、サーバ（ＳＳ）は、データベースからの登録完了のメッセージをクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、施策実施の有無の登録表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた登録結果を施策選択画面３４００に表示する（ステップ３５１２）。具体的には、例えば施策が実施された場合には、ステータス３４０２に「実施済」と表示される。

ユーザ（ＵＳ）は、施策選択画面３４００を確認することで、実際に施策実施の有無の登録が完了したことを確認する（ステップ３５１３）。

次に、図３６及び図３７を参照して、評価スコア効果を求める処理を説明する。評価スコア効果は２段階の処理によって求められる。

図３６は、本発明の実施例のサーバ（ＳＳ）が個人評価スコア効果を計算する処理を示すフローチャートである。

これは、施策を実施した個人単位での評価スコア効果を求める処理である。その値を用いて、図３７に示す施策単位での評価スコア効果を求める処理が実行される。

施策実施確認（ステップ３６０１）は、ユーザが登録した施策を実施したかをサーバ（ＳＳ）が確認する処理である。評価スコアを求める際のデータは、施策を実施したユーザが選択してもよい。

４日分の評価スコア取得（ステップ３６０２）は、サーバ（ＳＳ）が、過去４日分の評価スコアを取得する処理である。

評価スコア効果計算（ステップ３６０３）は、サーバ（ＳＳ）が、評価スコア効果を求める処理である。例えば、サーバ（ＳＳ）は、取得した４日分の評価スコアのうち、今日の評価スコアと過去三日分の平均値との差分を評価スコア効果として計算してもよい。例えば、今日の評価スコアは７．５で、過去三日分の評価スコアの平均値が４の場合、評価スコア効果は３．５になる。

この計算方法は一例であり、実施した施策の効果が明らかになる手法があればそれを用いてもよい。

評価スコア効果登録（ステップ３６０４）は、サーバ（ＳＳ）が、評価スコア効果計算によって求めた評価スコア効果をデータベースに（例えば施策テーブル２０００の評価スコア効果２００５として）登録する処理である。

図３７は、本発明の実施例のサーバ（ＳＳ）が施策評価スコア効果を計算する処理を示すフローチャートである。

これは、図３６で求めた個人の評価スコア効果を施策単位にまとめるための処理である。

評価スコア効果取得（ステップ３７０１）は、サーバ（ＳＳ）が、ある期間内で評価対象の施策を行った各個人（すなわち各ユーザ（ＵＳ））の評価スコア効果を取得する処理である。

評価スコア効果計算（ステップ３７０２）は、サーバ（ＳＳ）が、評価スコア効果取得（ステップ３７０１）によって求めた評価スコア効果から、施策の評価スコアを計算する処理である。

例えば、サーバ（ＳＳ）は、取得した各個人の評価スコア効果の平均を、評価対象の施策の評価スコア効果として計算してもよい。これは一例であり、施策の評価スコア効果が正確に求められれば、他の計算手法を用いてもよい。

評価スコア効果登録（ステップ３７０３）は、サーバ（ＳＳ）が、評価スコア効果計算によって求めた評価スコア効果をデータベースに登録する処理である。

図３６の処理の結果、あるユーザ（ＵＳ）がある施策を行った時の評価スコア効果が高ければ、その施策はそのユーザ（ＵＳ）の評価スコアを高めるために有効であったと言える。しかし、同じ施策が他のユーザにも有効であるとは限らない。一方、図３７の処理で計算される施策の評価スコアは、複数のユーザが同じ施策を行った時の評価スコアに基づくものである。このため、ある施策に関する評価スコア効果が高ければ、多くのユーザに当該施策が有効である可能性が高いと言える。

図３８は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される新規施策登録のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある新規施策登録２６０４のボタンを押すと図３８に示す新規施策登録画面３８００に遷移する。この画面３８００の構成は以下の様になっている。

施策登録ユーザ３８０１には、施策を登録した（すなわち投稿した）ユーザが表示されている。

ステータス３８０２には、新規施策登録におけるステータス（例えば登録が終了したか否か）が表示されている。

施策登録内容３８０３には、実際に登録する施策内容が記入される。図３８の例では、ユーザ（ＵＳ）が通常より１時間早く出社する、すなわち、朝早く起きて早く帰宅するという施策内容が記入されている。

登録３８０４は、施策登録内容をサーバに登録する処理を実行するために操作されるボタンである。

戻る３８０５は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン３８０５を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、新規施策登録の処理の流れを説明する。

ユーザは、施策登録内容３８０３を記入し、登録ボタン３８０４を押す（ステップ３５０１）。これによって、クライアント（ＣＬ）に登録内容が入力される（ステップ３５０２）。

クライアント（ＣＬ）は、施策登録要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して施策を登録するために登録情報及びリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、施策テーブル登録要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、新規の施策をテーブルに登録するようにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づき、新規の施策をテーブルに登録し（ステップ３５０７）、その結果を登録完了として、サーバ（ＳＳ）に送信する（ステップ３５０８）。

サーバ（ＳＳ）は、施策テーブル登録確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの登録結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、施策表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を施策選択画面３４００に表示する（ステップ３５１２）。具体的には、ステータス画面に登録済が表示される。

ユーザ（ＵＳ）は、新規施策登録画面を確認することで、実際に施策の登録が完了したことを確認する（ステップ３５１３）。

図３９は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される施策利用状況（施策）のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある施策状況（施策）２６０５のボタンを押すと、図３９の施策利用状況（施策）のアプリケーション画面３９００に遷移する。

これは、施策の利用状況を示している。この画面の構成は以下の様になっている。

施策３９０１には、指定した施策が表示されている。

施策登録ユーザ３９０２には、施策を登録した（すなわち投稿した）ユーザが表示されている。

施策利用状況内容３９０３には、その施策を利用させたエビデンスが表示されている。施策利用状況内容に含まれる選択数はその施策を選択した回数、達成数はその施策を実施した回数、評価スコア効果はその施策の評価スコア効果、評価スコア効果分布は評価スコア効果をヒストグラムで示したものである。

戻る３９０４は、図２５のアプリケーションのトップページに戻るために操作されるボタンである。戻るボタン３９０４を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、施策利用状況（施策）の処理の流れを説明する。

ユーザ（ＵＳ）は、施策状況（施策）ボタン２６０５を押す（ステップ３５０１）。これによって、施策に関して利用状況の要求がクライアント（ＣＬ）に入力される（ステップ３５０２）。

クライアント（ＣＬ）は、施策利用状況要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して施策の利用状況の要求を送信する（ステップ３５０４）。

サーバ（ＳＳ）は、施策利用テーブル検索要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、施策の利用状況のクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルを検索し（ステップ３５０７）、その結果を検索完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、施策利用テーブル確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの検索結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、利用状況表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を施策利用状況（施策）画面３９００に表示する（ステップ３５１２）。

ユーザ（ＵＳ）は、施策利用状況（施策）画面３９００を確認することで、実際に施策が利用されている現状を確認する（ステップ３５１３）。

図４０は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される施策利用状況（登録者）のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある施策状況（登録者）２６０６のボタンを押すと図４０の施策利用状況（登録者）のアプリケーション画面４０００に遷移する。

これは登録者が登録した施策の活用状況を示している。この画面の構成は以下の様になっている。

施策登録ユーザ４００１は、施策を登録した（すなわち投稿した）ユーザ（ＵＳ）を表示している。

順位４００２は、ある期間に当該ユーザ（ＵＳ）が登録した施策を実施したユーザの評価スコア効果の和を計算し、他の施策の登録者についても同様の和を計算して、大きい順に並べた時の順位である。

メダル４００３は、ある期間の評価スコア効果の和から事前に定義していた値を超えた場合に、金、銀、銅という表示を行う。

メダル４００３は、順位は施策を登録した人の中で、どのくらい実施されたかを示すものであり、多く実施された順に記載されている。

施策登録内容４００５には、当該ユーザ（ＵＳ）が実際に登録した施策のリストが表示されている。施策リストには、施策名と施策を行った時の数字を記載されている。これは施策を実施したユーザの評価スコア効果の平均である。

戻る４００６は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン４００６を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、施策利用状況（登録者）の処理の流れを説明する。

ユーザ（ＵＳ）は、施策状況（登録者）ボタン２６０６を押す（ステップ３５０１）。これによって、当該ユーザ（ＵＳ）が登録した施策に関して利用状況の要求がクライアント（ＣＬ）に入力される（ステップ３５０２）。

クライアント（ＣＬ）は、施策利用状況要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して施策の利用状況の要求を送信する（ステップ３５０４）。

サーバ（ＳＳ）は、施策利用テーブル検索要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、施策の利用状況のクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルを検索し（ステップ３５０７）、その結果を検索完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、施策利用テーブル確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの検索結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、利用状況表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を施策利用状況（登録者）画面４０００に表示する（ステップ３５１２）。

ユーザ（ＵＳ）は、施策利用状況（登録者）画面４０００を確認することで、実際に施策が利用されている現状を確認する（ステップ３５１３）。

図４１は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される報酬選択のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある報酬選択２６０７のボタンを押すと、図４１の報酬選択のアプリケーション画面４１００に遷移する。この画面の構成は以下の様になっている。

ユーザ４１０１には、報酬を利用するユーザ名が表示されている。

ステータス４１０２は、報酬選択におけるステータスを示している。

報酬取得４１０３は、サーバ（ＳＳ）に登録されている報酬のリストを取得する処理を実行するために操作されるボタンである。報酬取得のフローは後述する。

報酬登録４１０４は、選択した施策をサーバ（ＳＳ）に登録する処理を実行するために操作されるボタンである。報酬登録のフローは後述する。

報酬リスト４１０５には、報酬取得によって取得したリストが表示されている。報酬リストには、報酬名とその利用金額のリストが記載されている。

利用金額に関しては、自分が取得した評価スコアポイントによって利用できる金額が変わってくる。報酬リスト４１０５に表示された報酬の中から、自分が利用できる金額の範囲内の報酬をタッチすることで、報酬を選択することができる。

報酬利用４１０６は、報酬登録によって取得した報酬を、実際に利用する時に操作されるボタンである。報酬利用のフローは後述する。

戻る４１０７は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン４１０７を押したとしても、センサ計測で行っている動作は継続している。

図４２は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される報酬利用のアプリケーション画面の説明図である。

図４１の報酬選択画面４１００の報酬利用ボタン４１０６を押すと図４２の報酬利用のアプリケーション画面４２００に遷移する。この画面の構成は以下の様になっている。

ユーザ４２０１には、報酬を利用するユーザ名が表示されている。

報酬４２０２は、報酬登録によって登録した報酬である。ここには、報酬選択画面４１００の報酬リスト４１０５から選択された報酬に対応するクーポンが掲載されており、これを店員に見せることで、報酬を利用することができる。図４２の例ではクーポンとして二次元バーコードが表示されている。

戻る４２０３は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン４２０３を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、報酬選択の処理の流れを説明する。

ユーザ（ＵＳ）は、報酬選択画面４１００の報酬取得ボタン４１０３を押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対してリクエストが入力される（ステップ３５０２）。

クライアント（ＣＬ）は、登録報酬リスト一覧要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して現在登録されている報酬の一覧のリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、登録報酬テーブル検索要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在登録されている報酬を検索するようにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルを検索し（ステップ３５０７）、その結果を報酬リストとして、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、登録報酬リスト一覧送信を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースから入手した報酬リストをクライアント（ＣＬ）に送信する（ステップ３５１０）。クライアント（ＣＬ）からサーバ（ＳＳ）に送信する際に、データ量が大きくなる場合には、圧縮などの処理を施してもよい。

クライアント（ＣＬ）は、登録報酬リスト一覧表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られてきた報酬リストを報酬選択画面４１００に表示する（ステップ３５１２）。報酬金額は現在保持している評価スコアポイント又はメダルなどによって変更することができる。

ユーザ（ＵＳ）は、登録報酬リスト一覧表示によって表示させた報酬選択画面４１００を確認することで、報酬リストの取得を完了したことを確認する（ステップ３５１３）。

次に、図３５を参照して、報酬登録の処理の流れを説明する。

ユーザ（ＵＳ）は、報酬選択画面４１００の報酬登録ボタン４１０４を押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対してリクエストが入力される（ステップ３５０２）。

クライアント（ＣＬ）は、選択報酬登録を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して選択された施策を登録するためのリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、報酬利用テーブル登録要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在選択された報酬を登録するようにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルに登録し（ステップ３５０７）、その結果を登録完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、報酬利用テーブル登録確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの登録結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、登録済報酬表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を報酬選択画面４１００に表示する（ステップ３５１２）。具体的には、ステータス４１０２に登録中が表示される。

ユーザ（ＵＳ）は、報酬選択画面４１００を確認することで、実際に報酬の登録が完了したことを確認する。

次に、図３５を参照して、報酬利用の処理の流れを説明する。

ユーザ（ＵＳ）は、報酬選択の報酬利用ボタンを押す（ステップ３５０１）。押した場合には、クライアント（ＣＬ）に対してリクエストが送信される（ステップ３５０２）。

クライアント（ＣＬ）は、バーコード画面表示を行う（ステップ３５０３）。これによって、図４２に示した報酬利用画面４２００が表示される。

以下、実際に、報酬を利用した後に、利用確認をする処理のフローを述べる。ユーザ（ＵＳ）が報酬の利用先（例えば報酬のクーポンを利用できる店舗等）に例えば図４２に示すようなバーコードを見せることで、利用先のシステムに利用履歴が登録される。例えば、サーバ（ＳＳ）は、報酬連携サーバ（ＣＳ）からデータを入手する。その利用履歴はネットワーク（ＮＷ）を経由し、サーバ（ＳＳ）のデータベースに格納される。

クライアント（ＣＬ）は、サーバ（ＳＳ）に対して選択された報酬利用確認するためにリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、報酬利用確認要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、現在選択された報酬が実際に利用されたかを調べるためにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルを検索し（ステップ３５０７）、その結果を検索完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、報酬利用テーブル利用確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの検索結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、報酬利用表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を報酬選択画面４１００に表示する（ステップ３５１２）。具体的には、ステータス４１０２に利用済が表示される。

ユーザ（ＵＳ）は、報酬選択画面４１００を確認することで、実際に報酬の利用が完了したことを確認する（ステップ３５１３）。

なお、サーバ（ＳＳ）は、ユーザ（ＵＳ）が報酬を利用した場合に、そのユーザ（ＵＳ）に関する情報を、当該報酬の提供者（例えば報酬である物品又はサービスを提供した企業等）に送信してもよい。送信される情報は、例えば、当該ユーザ（ＵＳ）についてサーバ（ＳＳ）内のデータベースに格納されているデータの少なくとも一部であってもよい。この送信は、当該ユーザ（ＵＳ）の同意が得られた場合に行うことが望ましい。

このようなデータを受信することによって、報酬の提供者は、自らが提供した報酬がどのようなユーザ（ＵＳ）に好まれるかを知ることができる。その情報を報酬の提供者の企業活動に活用できることに加えて、その情報に基づいてよりユーザ（ＵＳ）に好まれる報酬を提供できれば、ユーザ（ＵＳ）のモチベーションの維持にも資することとなる。

図４３は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される新規報酬登録のアプリケーション画面の説明図である。

図２６のアプリケーションのトップページ画面２６００にある新規報酬登録２６０８のボタンを押すと、図４３の新規報酬登録のアプリケーション画面４３００に遷移する。この画面の構成は以下の様になっている。

報酬登録ユーザ４３０１は、施策を登録したユーザを表示している。

ステータス４３０２は、新規報酬登録におけるステータスを表示している。

報酬登録内容４３０３は、実際に登録する施策内容である。

登録４３０４は、報酬登録内容をサーバに登録する処理を実行するために操作されるボタンである。

戻る４３０５は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン４３０５を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、新規報酬登録の処理の流れを説明する。

ユーザ（ＵＳ）は、報酬登録内容を記入し、その後、登録ボタン４３０４を押す（ステップ３５０１）。これによって、クライアント（ＣＬ）に対して報酬登録内容が入力される（ステップ３５０２）。

クライアント（ＣＬ）は、報酬登録要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して報酬を登録するために登録情報とリクエストを送信する（ステップ３５０４）。

サーバ（ＳＳ）は、報酬テーブル登録要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、新規の報酬をテーブルに登録するようにクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルに登録し（ステップ３５０７）、その結果を登録完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、報酬テーブル登録確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの登録結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、報酬表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られてきた結果を報酬登録画面４３００に表示する（ステップ３５１２）。具体的には、ステータス４３０２に登録済が表示される。

ユーザ（ＵＳ）は、新規報酬登録画面４３００を確認することで、実際に報酬の登録が完了したことを確認する（ステップ３５１３）。

図４４は、本発明の実施例のクライアント（ＣＬ）の画面（ＣＬＯＤ）に表示される報酬利用状況のアプリケーション画面の説明図である。

図２５のアプリケーションのトップページ画面２６００にある報酬状況２６０９のボタンを押すとこの画面に遷移する。

これは登録者が登録した報酬の活用状況を示している。この画面の構成は以下の様になっている。

報酬４４０１は、指定した報酬である。

報酬登録ユーザ４４０２は、報酬を登録しているユーザを表示している。

報酬利用状況内容４４０３は、その報酬を利用させたエビデンスが表示させている。例えば、報酬利用状況内容４４０３は、報酬を利用させたエビデンスとして、発行数、利用数、評価スコアポイント分布、及び施策選択を含んでいる。

発行数はその報酬を選択した回数、利用数はその報酬を利用した回数、評価スコアポイント分布はその報酬を利用した人の評価スコアポイントの分布、施策選択はその報酬を選択した人が選んでいる施策を示したものと、その選択数である。

戻る４４０４は、図２６のアプリケーションのトップページ画面２６００に戻るために操作されるボタンである。戻るボタン４４０４を押したとしても、センサ計測で行っている動作は継続している。

ここで、図３５を参照して、報酬利用状況の処理の流れを説明する。

ユーザ（ＵＳ）は、報酬利用状況ボタン２６０９を押す（ステップ３５０１）。これによって、報酬に関して利用状況の要求がクライアント（ＣＬ）に入力される。

クライアント（ＣＬ）は、報酬利用状況要求を行う（ステップ３５０３）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）に対して報酬の利用状況の要求を送信する（ステップ３５０４）。

サーバ（ＳＳ）は、報酬利用テーブル検索要求を行う（ステップ３５０５）。これによって、サーバ（ＳＳ）は、データベースに対して、報酬の利用状況のクエリを入力する（ステップ３５０６）。

データベースは、クエリに基づきテーブルを検索し（ステップ３５０７）、その結果を検索完了として、サーバ（ＳＳ）に出力する（ステップ３５０８）。

サーバ（ＳＳ）は、報酬利用テーブル確認を行う（ステップ３５０９）。これによって、サーバ（ＳＳ）は、データベースからの検索結果をクライアント（ＣＬ）に送信する（ステップ３５１０）。

クライアント（ＣＬ）は、利用状況表示を行う（ステップ３５１１）。これによって、クライアント（ＣＬ）は、サーバ（ＳＳ）から送られたてきた結果を報酬利用状況画面４４００に表示する（ステップ３５１２）。

ユーザ（ＵＳ）は、報酬利用状況画面を確認することで、実際に報酬が利用されている現状を確認する（ステップ３５１３）。

このように、ユーザ（ＵＳ）が、働き方に対する施策を選択又は投稿し、評価スコアを測定することで、当該施策の効果を算出することで良し悪しを振り返ること、および、ユーザ（ＵＳ）の施策投稿及び評価スコア計測の持続モチベーション維持することを可能にする技術を提供することが可能となる。

以上の本発明の代表的な例をいくつか列挙すれば、次の通りである。

（１）心理状態計測システムは、処理部（例えば処理部ＳＳ０５又は処理部ＣＬ０３）と、記録部（例えば記録部ＳＳ０６又は記録部ＣＬ０４）と、を有する。記録部は、ユーザが使用する端末装置（例えばユーザ（ＵＳ）が使用するクライアント（ＣＬ））によって計測された加速度データ（例えば加速度センサテーブル１５００）を保持する。処理部は、加速度データに基づいて、前記ユーザの心理状態を示す評価スコアを計算し、所定の期間に計測された加速度データに基づいて計算された評価スコアを、所定の期間より前に計測された加速度データに基づいて計算された評価スコアと比較することによって、ユーザの心理状態の変化量（例えば評価スコア効果）を計算し、ユーザの心理状態の変化量に基づいて、ユーザの心理状態の向上に寄与する行動に対応する点数（例えば評価スコアポイント）を計算し、計算した点数を出力する。

これによって、ユーザの働き方を見直すことができる。また、ユーザの評価スコア計測の持続モチベーションを維持することができる。

（２）このとき、記録部は、ユーザが選択した、心理状態を向上させるための施策をさらに保持してもよい（例えば施策利用テーブル２２００）。そして、処理部は、施策を選択したユーザについて所定の期間に計測された加速度データに基づいて計算された評価スコアを、所定の期間より前に計測された加速度データに基づいて計算された評価スコアと比較することによって、ユーザの心理状態の変化量を計算し、ユーザの心理状態の変化量に基づいて、ユーザの心理状態の向上に対する施策の効果（例えば評価スコア効果２００５）を計算し、施策の効果に基づいて点数を計算し、計算された点数を、施策の提案者（例えば施策の投稿者等、施策を登録した人物）に付与される点数として出力してもよい。

これによって、心理状態の向上に効果のある施策を投稿するといった、心理状態の向上に寄与する行動に対して点数（ポイント）が与えられ、ユーザの施策投稿の持続モチベーションを維持することができる。

（３）さらに、処理部は、同一の施策を選択した複数のユーザの各々について、心理状態の変化量を計算し、複数のユーザの心理状態の変化量の統計値（例えば評価スコア効果２００５、図３９の施策利用状況内容に含まれる評価スコア効果、又は、図４０の平均評価スコア効果４００４）に基づいて、施策の効果を計算してもよい。

これによって、より多くのユーザの心理状態を向上させるのに効果がある施策を投稿するという、心理状態の向上に寄与する行動に対して点数（ポイント）が与えられ、ユーザの施策投稿の持続モチベーションを維持することができる。

（４）また、処理部は、ユーザの心理状態の変化量に基づいて点数を計算し、計算された点数を、ユーザに付与される点数（例えば評価スコアポイント３００６）として出力してもよい。

これによって、ユーザが評価スコアを計測するという心理状態の向上に寄与する行動の持続モチベーションを維持することができる。

（５）このとき、記録部は、ユーザが選択した、心理状態を向上させるための施策をさらに保持してもよい。そして、処理部は、施策を選択したユーザについて所定の期間に計測された加速度データに基づいて計算された評価スコアを、所定の期間より前に計測された加速度データに基づいて計算された評価スコアと比較することによって、ユーザの心理状態の変化量を計算し、ユーザの心理状態の変化量に基づいて点数を計算してもよい。

これによって、ユーザが、心理状態を向上させるのに効果がある施策を選択して実施し、評価スコアを計測するという、心理状態の向上に寄与する行動の持続モチベーションを維持することができる。

（６）また、記録部は、１以上の行動の各々に対応する加速度データの特徴量を行動モデル（例えば行動モデルテーブル９００のモデル９０４）として保持してもよい。そして、処理部は、記録部に格納された加速度データと行動モデルとを比較することによって、評価スコアの計算に利用する加速度データを抽出し（例えば図２９のステップ２９０７、２９１０）、抽出された加速度データに基づいて評価スコアを計算してもよい。

これによって、例えばユーザ（ＵＳ）が勤務中以外にもクライアント（ＣＬ）を持ち歩いている場合において、勤務中の評価スコアを算出するなどの場合に、評価の対象として適さないデータ（例えばクライアント（ＣＬ）が放置されているときのデータ等）を評価の対象から除外して、より公平で精度の高い評価が可能になる。

（７）このとき、記録部は、ユーザが使用する端末装置によって計測された、加速度以外のセンサデータをさらに保持し、１以上の行動の各々に対応する前記加速度データの特徴量を行動モデル（例えば行動モデルテーブル９００のモデル９０４）として保持してもよい。そして、処理部は、記録部に格納されたセンサデータと行動モデルとを比較することによって推定されるユーザの行動が所定の条件を満たすときの加速度データを、評価スコアの計算に利用する加速度データとして抽出し（例えば図２９のステップ２９０９、２９１０）、抽出された加速度データに基づいて評価スコアを計算してもよい。

（８）さらに、このとき、加速度以外のセンサデータは、位置、温度、照度、気圧及び音の少なくともいずれかを計測したデータ（例えばＧＰＳセンサテーブル５００及び温度、照度、気圧、音量センサテーブル６００）を含んでもよい。

これによって、例えばユーザ（ＵＳ）が勤務中以外にもクライアント（ＣＬ）を持ち歩いている場合において、ユーザ（ＵＳ）の位置情報の変化から、乗り物で移動中のデータを評価の対象から除外するなど、より公平で精度の高い評価が可能になる。

（９）また、記録部は、点数と、ユーザの心理状態の向上に寄与する行動に対する報酬である１以上の種類の物品又はサービスと、の間の変換レートをさらに保持し（例えば報酬テーブル２３００）、処理部は、ユーザに付与された点数と、１以上の種類の物品又はサービスと、変換レートとを出力してもよい（例えば報酬リスト４１０５）。

これによって、ユーザの評価スコア計測及び施策投稿の持続モチベーションを維持することができる。

（１０）このとき、変換レートは、前記報酬の提供者によって設定されてもよい。

これによって、報酬の提供者にとって適切なレートを設定することができる。

（１１）あるいは、変換レートは、選択された施策の実行の難易度に応じて設定されてもよい。

これによって、実行が難しい施策に対するユーザのモチベーションを維持することができる。

（１２）さらに、処理部は、ユーザに付与された点数が報酬のいずれかに変換された場合、ユーザに関して記録部に保持されている情報の少なくとも一部を、ユーザの同意に基づいて、報酬の提供者に送信してもよい。

これによって、ユーザにとって魅力のある報酬を提供する動機が生じ、ユーザの評価スコア計測及び施策投稿の持続モチベーションを維持することができる。

（１３）また、処理部は、ユーザの心理状態の向上の程度が大きいほど（例えば計算された評価スコア効果が大きいほど）多くの点数が与えられるように、点数を計算してもよい。

これによって、ユーザが心理状態をより向上させる行動をすることのモチベーションを維持することができる。

（１４）また、処理部は、加速度データに基づいて、ユーザの状態を、加速度データの値が所定の閾値以上である活性状態と、それ以外の不活性状態とに分類し、活性状態の持続時間の出現頻度に基づいて、評価スコアを計算してもよい。

これによって、客観的にユーザの心理状態を評価することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

サーバ・・・ＳＳ
クライアント・・・ＣＬ
報酬連携サーバ・・・ＣＳ
ネットワーク・・・ＮＷ
ユーザ・・・ＵＳ

Claims (1)

1. 処理部と、記録部と、を有する心理状態計測システムであって、
   前記記録部は、ユーザが使用する端末装置によって計測された加速度データを保持し、
   前記処理部は、
   前記加速度データに基づいて、前記ユーザの心理状態を示す評価スコアを計算し、
   所定の期間に計測された前記加速度データに基づいて計算された前記評価スコアを、前記所定の期間より前に計測された前記加速度データに基づいて計算された前記評価スコアと比較することによって、前記ユーザの心理状態の変化量を計算し、
   前記ユーザの心理状態の変化量に基づいて、前記ユーザの心理状態の向上に寄与する行動に対応する点数を計算し、
   前記計算した点数を出力することを特徴とする心理状態計測システム。

Images