JP7157486B2 - データ管理サーバ、データ管理方法及びデータ管理プログラム - Google Patents

Description

本開示は、測定装置から測定データを受信して生体データへ演算を行うデータ管理サーバ、データ管理方法及びデータ管理プログラムに関する。

生体データを測定する測定装置を利用してユーザの生体データを連続的に測定し、その変化から病気の早期発見や病状変化の検出を行うことは、健康管理を行う上で有効である。そのためには、生体データを測定するだけではなく、複数の生体データから様々な健康状態を把握するため、数多くの測定データと、それに基づく数理モデルを利用したソフトウェアを作成して各種演算を行う必要がある。

例えば、ユーザの測定データに基づいて各種演算が行われた数理モデルを提供する開発支援サーバが知られている（例えば、特許文献１参照。）。特許文献１に開示されている開発支援サーバは、測定データから生体情報データへ演算を行うための因果関係である数理モデルを生成し、数理モデルを利用可能に提供する。これにより、ソフトウェア開発者が、ユーザの測定データに基づく数理モデルを容易に利用し、アプリケーションソフトウェアを作成することを可能としている。

特許第６２５７０１５号公報

ところで、このようなアプリケーションソフトウェア（以下、「アプリ」という。）では、アプリごとにデータストレージが設けられ、それぞれ必要な測定データを含む各種データを記憶しているため、各種データを重複して記憶している場合がある。また、このようなアプリを利用するためには、アプリごとにユーザのアカウントを作成する必要があり、ユーザにとっても煩わしい作業が必要となっている。

このような各種データを共用することで、新たな価値を創出することが期待されているが、そのためにはアプリごとにＡＰＩ（Application Programming Interface）を作成し、各アプリがデータストレージのデータへアクセスできるようにする必要があり、ソフトウェア開発者にとっても余計な作業が必要となっている。

そこで、本開示では、アプリが測定データにアクセスするためのインタフェースを提供するデータ管理サーバ、データ管理方法及びデータ管理プログラムについて説明する。

本開示の一態様におけるデータ管理サーバは、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理サーバであって、測定装置ごとにデータレイヤを生成するデータレイヤ管理部と、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理部と、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成部と、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供部と、を備え、インタフェース提供部は、アプリケーションソフトウェアが利用する１または複数のデータレイヤへアクセスさせ、１または複数のアカウントごとの測定データへアクセスさせる。

本開示の一態様におけるデータ管理方法は、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理方法であって、データレイヤ管理部が行う、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、データ管理部が行う、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、アプリ生成部が行う、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成ステップと、インタフェース提供部が行う、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、を備え、インタフェース提供ステップは、アプリケーションソフトウェアが利用する１または複数のデータレイヤへアクセスさせ、１または複数のアカウントごとの測定データへアクセスさせる。

また、本開示の一態様におけるデータ管理プログラムは、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理プログラムであって、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成ステップと、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、を電子計算機に実行させ、インタフェース提供ステップは、アプリケーションソフトウェアが利用する１または複数のデータレイヤへアクセスさせ、１または複数のアカウントごとの測定データへアクセスさせる。

本開示によれば、アプリが測定データにアクセスするためのインタフェースを備え、測定装置ごとに区分けされ、ユーザのアカウントごとに記憶されている測定データにアクセスさせる。これにより、測定データから生体データへ演算を行うアプリが容易に測定データにアクセスすることが可能になる。

本開示の一実施形態に係るデータ管理システムを示すブロック構成図である。 図１の測定データＤＢ１２１におけるデータレイヤの構造を示すブロック構成図である。 図１の測定データＤＢ１２１に関連付けされるタグ情報の例を示す模式図である。 図１の測定データＤＢ１２１におけるデータ補正の例を示す模式図である。 図１の測定装置３００で測定される心電波形及び脈波の例について説明するための図である。 図１のデータ管理システム１の処理の例を示すフローチャートである。 本開示の一実施形態に係るデータ管理システムを示すブロック構成図である。 本開示の一実施形態に係るコンピュータ６００の構成の例を示す機能ブロック構成図である。

以下、本開示の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。

（実施形態１）
＜構成＞
図１は、本開示の実施形態１に係るデータ管理システム１を示すブロック構成図である。このデータ管理システム１は、例えば、ユーザの生体データを測定する測定装置から測定データを受信し、ネットワークを介して測定データを受信して生体データへ演算を行うためのシステムである。

データ管理システム１は、データ管理サーバ１００と、ユーザ端末装置２００と、測定装置３００と、データレイヤ作成者端末４００と、アプリ提供者端末５００と、ネットワークＮＷと、を有している。データ管理サーバ１００と、ユーザ端末装置２００と、データレイヤ作成者端末４００と、アプリ提供者端末５００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等により構成される。

データ管理サーバ１００は、例えば、ネットワークを介して測定装置３００からユーザの測定データを、ユーザ端末装置２００を経由して受信して測定データから生体データへ演算を行う装置であり、各種Ｗｅｂサービスを提供するサーバ装置により構成されている。

ユーザ端末装置２００は、ユーザが所持する、例えばパーソナルコンピュータやタブレット端末、スマートフォン、スマートウォッチ、携帯電話、ＰＨＳ、ＰＤＡ等の情報処理装置であり、例えば、データ管理サーバ１００で演算を行った生体データを波形グラフ等により表示させるために利用される。ユーザ端末装置２００には、予めユーザの生年月日、性別、身長、体重、歩幅等の情報が登録されており、生年月日から算出した年齢等のユーザ情報を測定データに関連付けてネットワークＮＷを介してデータ管理サーバ１００へ送信する。

また、ユーザ端末装置２００は、ユーザが測定装置３００によりデータを取得する状態を、タッチパネル等を用いて入力することができる。ユーザ端末装置２００は、「データを取得する状態」を、例えば、走っている場合には「＃ランニング中」、食事中である場合には「＃食事中」など、ハッシュタグ情報として入力することができる。ユーザ端末装置２００は、測定装置３００から受信した測定データを、ハッシュタグ情報と関連付けてネットワークＮＷを介してデータ管理サーバ１００へ送信する。

測定装置３００は、ユーザの生体データを測定する装置であり、ユーザが自己の腕等の身体に装着して利用される、例えばウェアラブル装置である。この測定装置３００は、例えばユーザの心電、脈波、温度（体温）、加速度のデータを測定するための複数種類の装置である。

測定装置３００の具体的な構成の例としては、２つの電極を皮膚に接触させ、検出電位の差の時間変化より心電を心電波形のデータとして取得する装置で構成しても良く、心電波形は、ガルバニック皮膚反応により取得されたデータでも良い。また、緑、赤、赤外の発光を行うＬＥＤから各光を皮膚に照射し、フォトダイオードで受光した光の強度の時間変化により、ユーザの心臓の心拍により生ずる血管の容積変化により脈波を脈波形のデータとして取得する装置で構成しても良く、この方式で検出を行うことができる脈波形は光電式容積脈波形である。また、ユーザの皮膚に接触させる温度センサによりユーザの皮膚温度をデータとして取得する装置で構成しても良い。さらに、直交するＸＹＺ軸それぞれの変異状態を検出する３軸加速度センサにより構成しても良く、ユーザの動作を加速度データとして取得し、例えば測定装置３００がユーザの腕に装着されている場合、測定装置３００は、腕の振りと、全身の動きが合成された加速度として加速度データの取得をする。

ユーザ端末装置２００と測定装置３００との間は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（Near Field radio Communication＝ＮＦＣ）、Ａｆｅｒｏ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、Ｚ－Ｗａｖｅ（登録商標）、又は無線ＬＡＮ等を用いて接続されている。なお、このような無線接続の代わりに有線で接続を行っても良い。また、ユーザ端末装置２００と測定装置３００とは一体の機器であっても良く、例えば測定装置３００に通信機能を持たせてデータ管理サーバ１００と直接通信可能に構成しても良い。

ユーザ端末装置２００は、１または複数台あり、測定装置３００を利用するユーザ数分ネットワークＮＷに接続されている。測定装置３００は、１または複数台あり、１人のユーザが利用する台数分ユーザ端末装置２００に接続されている。１人のユーザが複数の測定装置３００を利用している場合は、１つのユーザ端末装置２００に複数の測定装置３００が接続されている。

データレイヤ作成者端末４００は、測定データを記憶させる、後述するデータレイヤを管理するデータレイヤ作成者の端末であり、データレイヤへのアクセス管理を行うための装置である。アプリ提供者端末５００は、生体データを利用する、後述するアプリ（アプリケーションソフトウェア）のダウンロード等を管理するための装置である。データレイヤ作成者端末４００及びアプリ提供者端末５００は、例えば、パーソナルコンピュータ等により構成される。

データ管理サーバ１００は、通信部１１０と、記憶部１２０と、データレイヤ管理部１３０と、データ管理部１４０と、アプリ生成部１５０と、インタフェース提供部１６０と、演算部１７０とを備える。

通信部１１０は、ユーザ端末装置２００、データレイヤ作成者端末４００、及びアプリ提供者端末５００と通信を行うための通信インタフェースであり、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等の通信規約により通信が行われる。

記憶部１２０は、各種制御処理やデータレイヤ管理部１３０、データ管理部１４０、アプリ生成部１５０、インタフェース提供部１６０、及び演算部１７０の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等から構成される。また、記憶部１２０は、測定装置３００による測定データを記憶する測定データＤＢ１２１と、測定データから演算されて生成される生体データを記憶する生体情報データＤＢ１２２と、測定データＤＢ１２１に記憶されている測定データにアクセスするためのインタフェースを記憶するインタフェースＤＢ１２３と、例えば生体データを利用してユーザの健康管理情報を通知するアプリＤＢ１２４とを記憶する。さらに、記憶部１２０は、ユーザ端末装置２００、データレイヤ作成者端末４００、及びアプリ提供者端末５００と通信を行ったデータを一時的に記憶する。

データレイヤ管理部１３０は、記憶部１２０の測定データＤＢ１２１内に、測定装置３００の種類ごとにデータレイヤを生成し、データレイヤへのアクセスを管理する。

ここで、記憶部１２０の測定データＤＢ１２１内に生成されるデータレイヤについて説明する。図２は、図１の測定データＤＢ１２１におけるデータレイヤの構造を示すブロック構成図である。図２に示すように、測定データＤＢ１２１には、複数のデータレイヤ１２１ａ，１２１ｂ，１２１ｃにより区分けされている。

データレイヤ１２１ａ，１２１ｂ，１２１ｃは、測定装置３００の種類ごとに設けられるデータ記憶空間（データストレージ）であり、例えば、測定装置３００の一種類であるデバイスＡ，Ｂ，Ｃごとに、データレイヤ１２１ａ，１２１ｂ，１２１ｃがそれぞれ設けられている。このデータレイヤ１２１ａ，１２１ｂ，１２１ｃは、例えば、データレイヤを管理する業者であるデータレイヤ作成者によりデータレイヤ作成者端末４００が操作されて生成される。

デバイスＡ，Ｂ，Ｃは、ユーザがアカウント登録を行うことにより測定データがデータ管理サーバ１００へ送信されて生体データが演算される装置であり、データレイヤ１２１ａ，１２１ｂ，１２１ｃには、ユーザごとにアカウントが生成されている。図２に示す例では、ユーザＸのアカウントＸがデータレイヤ１２１ａ，１２１ｂに生成され、ユーザＹのアカウントＹがデータレイヤ１２１ａ，１２１ｃに生成されている。これは、ユーザＸがデバイスＡ，Ｂを利用しており、ユーザＹがデバイスＡ，Ｃを利用しているためである。ユーザＸのデバイスＡによる測定データは、データレイヤ１２１ａのアカウントＸに記憶され、ユーザＸのデバイスＢによる測定データは、データレイヤ１２１ｂのアカウントＸに記憶される。また、ユーザＹのデバイスＡによる測定データは、データレイヤ１２１ａのアカウントＹに記憶され、ユーザＹのデバイスＣによる測定データは、データレイヤ１２１ｃのアカウントＹに記憶される。

また、後述するアプリ生成部１５０により生成されるアプリＡＰ１，ＡＰ２は、測定データＤＢ１２１にアクセスして測定データを読み取り、生体データを生成したり、ユーザ端末装置２００に表示させたりする。このアプリＡＰ１，ＡＰ２は、ソフトウェア開発者がアプリを開発するとき、その種類や目的に応じて測定データＤＢ１２１の希望のデータレイヤを参照するためのプログラムである。図２に示す例では、アプリＡＰ１がデータレイヤ１２１ａ，１２１ｂにアクセスし、アプリＡＰ２がデータレイヤ１２１ｂ，１２１ｃにアクセスするように設定されている。

このように、測定装置３００の種類ごとにデバイスＡ，Ｂ，Ｃに対応するようにデータレイヤ１２１ａ，１２１ｂ，１２１ｃに区分けされ、データレイヤ１２１ａ，１２１ｂ，１２１ｃにユーザＸ，Ｙが利用するデバイスＡ，Ｂ，Ｃに対応させてアカウントＸ，Ｙが生成されているのは、このように測定データを統合することにより、ソフトウェア開発者（アプリケーションソフトウェア提供者）はアプリの種類や目的に応じて測定データＤＢ１２１の希望のデータレイヤを参照することが容易であり、ＡＰＩを作成する手間が削減されるからである。また、データレイヤ管理部１３０がデータレイヤを生成し、後述するデータ管理部１４０がアカウントの作成及び測定データを一元管理することにより、データの重複がなくなるので、無駄な資源の利用を削減することが可能である。

データ管理部１４０は、測定装置３００を利用するユーザごとに、所定のデータレイヤ内にアカウントを生成する。このアカウント生成は、測定装置３００を利用するユーザがユーザ端末装置２００でアカウントを登録すると行われる。また、データ管理部１４０は、測定装置３００に対応するデータレイヤ内のアカウントごとに、測定データを記憶させる。そのため、データ管理部１４０は、アプリＡＰ１，ＡＰ２に対してデータレイヤごとにアクセスの可否を制御し、ユーザのユーザ端末装置２００に対してアカウントごとにアクセスの可否の制御を行う。また、このとき、データ管理部１４０は、測定データに所定のタグ情報の関連付けを行って記憶させることが可能である。

図３は、図１の測定データＤＢ１２１に関連付けされるタグ情報の例を示す模式図である。図３に示すデータＤ１は、測定装置３００の測定データである。タグＴ１は、データＤ１に関連付けされたタグ情報であり、例えば、測定装置３００がデータＤ１を測定した時刻情報、またはデータＤ１が測定装置３００からユーザ端末装置２００へ送信された時刻情報が時系列データとして記憶される。もしくは、測定した時刻情報と送信された時刻情報との両方について関連付けを行っても良い。例えば、図３に示すタグＴ１の１行目では、「20180620120746144」が格納されているが、２０１８年０６月２０日１２時０７分４６秒１４４ミリ秒を示している。このような時刻情報は通信ログより取得可能である。これにより、測定データがどの時間帯のものか把握することが可能である。

なお、このようなタグ情報による測定データの関連付けは、時刻情報に限られず、ユーザの身体状態や活動状態を示す身体情報や活動情報を自由記載で記入させてタグ情報として記憶しても良く、所定の選択肢から選択させ（例えば、「現在の体調は如何ですか？」という質問に対して、「１：良い、２：普通、３：悪い」のいずれかを選択させる、等）、その選択した回答を記憶するようにしても良い。

また、例えばデータ管理部１４０は、図３に示すように、データＤ１をタグＴ１の時刻順に並べ替え（ソート）を行うことが可能である。このような構成にしたのは、測定データはユーザの生体データに基づいて時系列に取得したものであるから時系列に並んでいる方が処理しやすいからであるが、ユーザ端末装置２００及び通信部１１０を経由して受信する際に通信状況の変化等により受信データの逆転（後で送信された送信データが先に送信された送信データより先に受信されること）等が起こる場合があり、そのときの測定データの不整合を防止するためである。これにより、測定データの不整合を防止することが可能である。

さらに、データ管理部１４０は、通信エラー等による測定データの欠損を補正することが可能である。図４は、図１の測定データＤＢ１２１におけるデータ補正の例を示す模式図である。図４に示すデータＤ２は、図３のデータＤ１と同様の測定装置３００の測定データであり、タグＴ２は、データＤ１に関連付けされたタグ情報である。

測定装置３００による測定データは、心電や脈波のように周期的な信号であったり、温度（体温）のようにある程度ゆっくり変化する時系列データであったりするため、所定の範囲内で予測が可能である。そのため、図４のデータＤ２に示すように所定の時刻の測定データが欠損している場合、例えば、当該時刻の直前に受信した測定データと、当該時刻の直後に受信した測定データとに基づいて推定することが可能である。この欠損データの推定は、例えば、当該時刻の直前に受信した測定データと当該時刻の直後に受信した測定データとの平均値や、時系列データにおける時間推移からの推定値を使用しても良い。また、直前及び直後のデータに限られず、所定範囲の前後のデータ（例えば、前後５つのデータ）から推定しても良い。このような場合に、データ管理部１４０は、他の時刻の測定データを当該時刻の測定データと推定してタグ情報の関連付けを行う。

アプリ生成部１５０は、測定データＤＢ１２１に記憶された測定データから生体データを演算して算出したり、算出された生体データを利用したり、といった生体データに関する所定の演算を行い、例えば、ユーザの健康管理情報を通知するためにデータ管理サーバ１００またはユーザ端末装置２００で実行可能なアプリを生成する。この生体データは、例えばユーザの血圧情報、心拍情報、血中酸素量情報、心電情報、呼吸数、体温情報、歩幅情報、重心の位置情報のデータであり、このようなデータを算出または利用するためのアプリが生成される。演算により生成された生体データは、生体情報データＤＢ１２２に記憶される。また、生成されたアプリは、アプリＤＢ１２４に記憶される。さらに、このアプリは、ユーザの希望によりユーザ端末装置２００が操作されると、ユーザ端末装置２００へ配信される。

ここで、アプリ生成部１５０により生成されるアプリの例として、測定データから生体情報データである最大血圧と最小血圧を算出する方法を説明する。図５は、図１の測定装置３００で測定される心電波形及び脈波の例について説明するための図であり、測定装置３００が測定し、記憶部１２０に記憶されたユーザの心電波形及び光電式容積脈波形と、アプリが光電式容積脈波形を時間で１階微分した速度脈波形及び、光電式容積脈波形を時間で２階微分した加速度脈波形を示している。図５は上から順に、心電波形、光電式容積脈波形、速度脈波形及び加速度脈波形となる。縦軸は、各波形の強度を示しており、心電波形及び光電式容積脈波形は電位を示すｍＶで表される。横軸は時間経過を示し、左から右へ時間経過を示している。

心電波形は、人の心臓の拍動を引き起こす電気的信号の周期的変化を示す波形である。心電波形は、その形状の変曲点にそれぞれＰ波，Ｑ波，Ｒ波，Ｓ波，Ｔ波の名称が割り当てられ、心拍の１サイクルを示している。Ｐ波は心房収縮を表し、Ｑ波Ｒ波Ｓ波は心室収縮の状態を表し、Ｔ波は心室拡張の開始を表す。

光電式容積脈波形は、人の心臓の拍動に伴う末梢血管系内の血圧・体積の変化を示す波形である。光電式容積脈波形は、その形状の変曲点にそれぞれＡ波、Ｐ波、Ｖ波、Ｄ波の名称が割り当てられ、心拍の１サイクルを示している。Ａ波を動脈脈波が生じた時点の基準点として、Ｐ波が左心室駆出によって生じるPercussion波（衝撃波）、Ｖ波が大動脈弁の閉鎖時に生じるValley波（重複隆起による波）、Ｄ波が反射振動波であるDicrotic波（重複波）を示している。

速度脈波形は、光電式容積脈波形を時間で１階微分をしたものである。加速度脈波形は、速度脈波形を時間で１階微分したもの、すなわち光電式容積脈波形を２階微分したものである。加速度脈波形は、図５で示すように、その波形の各ピークにａ波（収縮初期陽性波）、ｂ波（収縮初期陰性波）、ｃ波（収縮中期再上昇波）、ｄ波（収縮後期再下降波）、ｅ波（拡張初期陽性波）、ｆ波（拡張初期陰性波）の名称が割り当てられている。

ｂ波の強度とａ波の強度の比、及びｆ波の強度とｅ波の強度の比はそれぞれ血管の伸縮性すなわち弾性を示すパラメータである。主な血管の成分は、血管内皮（Endothelium）、弾性線維（Elastin）、タンパク質（Collagen）、平滑筋（Smooth Muscle）である。これらの成分は、それぞれ異なった性質があり、最大血圧、最小血圧時の血管の弾性はそれぞれCollagen、Elastinが強い影響力を担っている。そのため、血圧値によって異なる弾性をｂ波の強度とａ波の強度の比である（ｂ／ａ），ｆ波の強度とｅ波の強度の比である（ｆ／ｅ）のパラメータで示すことができ、年齢・性別・環境変数の影響によってもこれらの値は変動する。そのため、（ｂ／ａ），（ｆ／ｅ）の値は、加速度脈波形の特性情報として算出することができる。

図５で示すように、Ｒ波の生じた時間ＴｒとＰ波の生じた時間Ｔｐの差分の時間が心室収縮期脈波伝搬時間ＰＴＴ＿ＳＹＳとなる。Ｔ波の生じた時間ＴｔとＤ波の生じた時間Ｔｄの差分の時間が心室拡張期脈波伝搬時間ＰＴＴ＿ＤＩＡとなる。すなわち、心電波形のＲ波の時間Ｔｒ及びＴ波の時間Ｔｔと、光電式容積脈波形のＴ波の時間ＴｐとＤ波の時間Ｔｄから、心室収縮期脈波伝搬時間ＰＴＴ＿ＳＹＳ及び心室拡張期脈波伝搬時間ＰＴＴ＿ＤＩＡを算出することができる。

また、脈波伝播速度と動脈壁の縦弾性係数との関係が所定の式で示される相関関係にあることが知られており、縦弾性係数と血圧値との関係も所定の式で示される相関関係にあることが知られている。そのため、最大血圧を心室収縮期脈波伝搬時間ＰＴＴ＿ＳＹＳの所定の式で求めることが可能であり、最小血圧を心室拡張期脈波伝搬時間ＰＴＴ＿ＤＩＡの所定の式で求めることが可能である。これにより、最大血圧と最小血圧を算出することが可能である。

インタフェース提供部１６０は、アプリが測定データにアクセスするため、インタフェースＤＢ１２３に記憶されているインタフェースを提供する。このインタフェースは、ＡＰＩのようにデータストレージのデータへアクセスするためにソフトウェア開発者が作成するものとは異なり、例えば、データレイヤへのアクセスを一元管理するデータレイヤ作成者により提供されるものであり、データレイヤごとに提供されるものである。これにより、ソフトウェア開発者がＡＰＩを作成する必要がなくなり、その種類や目的に応じて測定データＤＢ１２１の希望のデータレイヤを容易に参照することが可能になる。

演算部１７０は、アプリ生成部１５０により生成されたアプリを実行することにより、データ管理サーバ１００の全体の動作を制御するものであり、ＣＰＵ（Central Processing Unit）等から構成される。

ソフトウェア開発者は、アプリ提供者端末５００において、データ管理サーバ１００から取得したインタフェースを用いて、測定データから生体情報データを生成し、測定者の状態を検知するアプリを作成することができる。また、ソフトウェア開発者は、作成したアプリを、アプリ提供者端末５００からデータ管理サーバ１００のアプリＤＢ１２４へアップロードすることができる。

アプリを利用したいと希望するユーザは、ユーザ端末装置２００からネットワークＮＷを介してデータ管理サーバ１００へアクセスし、希望するアプリをユーザ端末装置２００へダウンロードする。ユーザは、データ管理サーバ１００へアクセスして自己のアカウントを作成することで、アプリを利用することが可能になる。

＜処理の流れ＞
図６を参照しながら、データ管理システム１が実行するデータ管理方法の処理の流れについて説明する。図６は、図１のデータ管理システム１の処理の例を示すフローチャートである。

ステップＳ１０１の処理として、データレイヤ管理部１３０では、データレイヤ作成者の指示により、測定装置３００の種類ごとにデータレイヤが記憶部１２０の測定データＤＢ１２１内に生成される。これ以降、データレイヤ管理部１３０によってデータレイヤごとのアクセスが管理される。

ステップＳ１０２の処理として、データ管理部１４０では、測定装置３００を利用するユーザごとに、記憶部１２０の測定データＤＢ１２１内における測定装置３００に対応する所定のデータレイヤ内にアカウントが生成される。ステップＳ１０１及びステップＳ１０２の処理は、ユーザが測定装置３００を利用するための前処理として行われる。

ステップＳ１０３の処理として、ユーザが測定装置３００を利用すると、測定データが測定装置３００からユーザ端末装置２００を介してデータ管理サーバ１００へ送信され、通信部１１０を介して受信される。データ管理部１４０では、記憶部１２０の測定データＤＢ１２１内における測定装置３００に対応するデータレイヤ内のアカウントごとに測定データが記憶される。

ステップＳ１０４の処理として、アプリ生成部１５０では、測定データＤＢ１２１に記憶された測定データから、データ管理サーバ１００またはユーザ端末装置２００で実行可能なアプリが生成される。生成されたアプリは、アプリＤＢ１２４に記憶される。

ステップＳ１０５の処理として、インタフェース提供部１６０では、ステップＳ１０４で生成されたアプリに対して、所定のデータレイヤにアクセスするためのインタフェースＤＢ１２３に記憶されているインタフェースが提供される。これにより、アプリから所定のデータレイヤ内の測定データにアクセスすることが可能になる。

ステップＳ１０６の処理として、演算部１７０では、ステップＳ１０４で生成されたアプリが利用されると、測定データＤＢ１２１の所定のデータレイヤにアクセスされて測定データが読み取られ、生体データの算出等の所定の演算が行われる。演算により算出された生体データは、生体情報データＤＢ１２２に記憶され、当該アプリや他のアプリでも利用可能になる。

＜効果＞
以上のように、本実施形態に係るデータ管理システムは、データレイヤ管理部により、測定装置の種類に対応するようにデータレイヤが生成され、データ管理部により、各データレイヤにユーザごとにアカウントが生成され、ユーザの測定データがユーザのアカウントごとに記憶されている。これにより、測定データが一元管理されるので、データの重複がなくなり、無駄な資源の利用を削減することが可能である。

また、インタフェース提供部により、アプリが所定のデータレイヤにアクセスするためのインタフェースが提供され、ソフトウェア開発者はアプリの種類や目的に応じて希望のデータレイヤの測定データを参照することが可能である。これにより、ＡＰＩを作成する手間が省けるので、容易にアプリの開発が可能である。

さらに、データ管理部により、測定データに関連付けされてタグ情報が記憶されることにより、測定データを測定した時刻やユーザの測定状態を記憶することができるので、測定データをより精度高く利用することが可能になる。

（実施形態２）
図７は、本開示の実施形態２に係るデータ管理システム１Ａを示すブロック構成図である。このデータ管理システム１Ａは、ユーザの生体データを測定する測定装置から測定データを受信し、ネットワークを介して測定データを受信して生体データへ演算を行うためのシステムである点において実施形態１と同様であるが、図７に示すように、データ管理サーバ１００Ａには、支払情報算出部１８０を備えている点において、実施形態１と異なる。

支払情報算出部１８０は、データ管理サーバ１００Ａを利用するための、ユーザ、データレイヤ作成者、及びソフトウェア開発者（アプリケーションソフトウェア提供者）の支払情報を算出する。具体的には、測定装置３００を利用するユーザがデータ管理サーバ１００Ａを利用するための利用料を算出するための支払情報を算出し、データレイヤ作成者へ当該データレイヤのデータ参照料を算出するための支払情報を算出し、ソフトウェア開発者へ測定データのデータ使用料を算出するための支払情報を算出する。その他の構成については、実施形態１と同様である。

ここで、ユーザ、ソフトウェア開発者、及びデータレイヤ作成者の支払関係について説明する。なお、ソフトウェア開発者はアプリを提供している者（アプリケーションソフトウェア提供者）であるが、アプリを購入等してネットワークＮＷ上で配信を行う者であっても良い。また、データレイヤ作成者はデータ管理サーバ１００Ａにデータレイヤを作成した者であるが、データ管理サーバ１００Ａにおけるデータストレージの管理者等でも良い。まず、測定装置３００を利用するユーザは、データ管理サーバ１００Ａの運営者へ利用料を支払う。この利用料には、ソフトウェア開発者に対するアプリを利用するための利用料と、データレイヤ作成者に対するデータレイヤを利用するための利用料とが含まれる。この利用料は、例えばユーザの利用時間や使用したデータ量に応じて算出される。

データレイヤ作成者は、データ管理サーバ１００Ａの運営者へデータ管理サーバ１００Ａの運用費を支払う。この運用費は、例えば記憶部１２０内に確保した空きデータ容量に応じて算出される。そして、データ管理サーバ１００Ａの運営者は、データレイヤ作成者へデータの参照料を支払う。この参照料は、例えば当該データレイヤのアクセス数や参照されたデータ量（参照データ量）に応じて算出される。

ソフトウェア開発者は、データ管理サーバ１００Ａの運営者へ、ユーザに対するアプリ提供の課金ツールの利用料を支払う。この利用料は、例えばユーザのダウンロード数に応じて算出される。そして、データ管理サーバ１００Ａの運営者は、ソフトウェア開発者へアプリの利用料を支払う。この利用料は、例えばアプリのダウンロード数やユーザによるアプリの利用回数に応じて算出される。

支払情報算出部１８０は、このような各支払情報の基になる、ユーザの利用時間や使用したデータ量、データレイヤのアクセス数や参照されたデータ量、アプリのダウンロード数やユーザによるアプリの利用回数等をカウントし、支払情報を算出する。

なお、この各支払は電子マネーやクレジットカードによる支払を可能にしても良く、データ管理サーバ１００Ａは、電子マネーやクレジットカードのサービスを提供するサーバにアクセスして決済を行う機能を備えていても良い。

本実施形態によれば、上記実施形態１の効果に加え、支払情報算出部を備えたことにより、複雑なユーザのデータ管理サーバの運営者に対する支払情報、データレイヤ作成者とデータ管理サーバの運営者との間の支払情報、ソフトウェア開発者とデータ管理サーバの運営者との間の支払情報を適切に管理することが可能になる。

（実施形態３（プログラム））
図８は、コンピュータ（電子計算機）６００の構成の例を示す機能ブロック構成図である。コンピュータ６００は、ＣＰＵ６０１、主記憶装置６０２、補助記憶装置６０３、インタフェース６０４を備える。

ここで、実施形態１及び２に係るデータレイヤ管理部１３０、データ管理部１４０、アプリ生成部１５０、インタフェース提供部１６０、及び支払情報算出部１８０を構成する各機能を実現するための制御プログラムの詳細について説明する。これらの機能ブロックは、コンピュータ６００に実装される。そして、これらの各構成要素の動作は、プログラムの形式で補助記憶装置６０３に記憶されている。ＣＰＵ６０１は、プログラムを補助記憶装置６０３から読み出して主記憶装置６０２に展開し、当該プログラムに従って上記処理を実行する。また、ＣＰＵ６０１は、プログラムに従って、上述した記憶部に対応する記憶領域を主記憶装置６０２に確保する。

当該プログラムは、具体的には、コンピュータ６００において、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、測定データから生体データへ演算を行う演算ステップと、ユーザの状態を検知し、測定データから生体データへの演算結果に基づく生体データを利用するアプリケーションソフトウェアを生成するアプリ生成ステップと、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、をコンピュータによって実現する制御プログラムである。

なお、補助記憶装置６０３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、インタフェース６０４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムがネットワークを介してコンピュータ６００に配信される場合、配信を受けたコンピュータ６００が当該プログラムを主記憶装置６０２に展開し、上記処理を実行してもよい。

また、当該プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、当該プログラムは、前述した機能を補助記憶装置６０３に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）
であってもよい。

以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。

１，１Ａ データ管理システム、１００，１００Ａ データ管理サーバ、１１０ 通信部、１２０ 記憶部、１２１ 測定データＤＢ、１２２ 生体情報データＤＢ、１２３ インタフェースＤＢ、１２４ アプリＤＢ、１３０ データレイヤ管理部、１４０ データ管理部、１５０ アプリ生成部、１６０ インタフェース提供部、１７０ 演算部、１８０ 支払情報算出部、２００ 端末装置、３００ 測定装置、４００ データレイヤ作成者端末、５００ アプリ提供者端末、ＮＷ ネットワーク

Claims (1)

1. ネットワークを介して測定装置から測定データを受信し、前記測定データから生体データへ演算を行うデータ管理サーバであって、
   前記測定装置ごとにデータレイヤを生成するデータレイヤ管理部と、
   前記測定装置を利用するユーザごとにアカウントを生成し、前記測定装置に対応する前記データレイヤに区分けされて、前記アカウントごとに前記測定データを記憶させるデータ管理部と、
   前記測定データにアクセスするためのインタフェースを提供するインタフェース提供部と、を備え、
   前記インタフェース提供部は、１または複数の前記データレイヤへアクセスさせ、１または複数の前記アカウントごとの前記測定データへアクセスさせる、データ管理サーバ。
   

Images