IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社Arbletの特許一覧

特許7157486データ管理サーバ、データ管理方法及びデータ管理プログラム
<>
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図1
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図2
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図3
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図4
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図5
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図6
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図7
  • 特許-データ管理サーバ、データ管理方法及びデータ管理プログラム 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-12
(45)【発行日】2022-10-20
(54)【発明の名称】データ管理サーバ、データ管理方法及びデータ管理プログラム
(51)【国際特許分類】
   G16H 10/00 20180101AFI20221013BHJP
   G16H 20/00 20180101ALI20221013BHJP
【FI】
G16H10/00
G16H20/00
【請求項の数】 1
(21)【出願番号】P 2021130318
(22)【出願日】2021-08-06
(62)【分割の表示】P 2018132665の分割
【原出願日】2018-07-12
(65)【公開番号】P2021170422
(43)【公開日】2021-10-28
【審査請求日】2021-08-30
(73)【特許権者】
【識別番号】516377348
【氏名又は名称】株式会社Arblet
(72)【発明者】
【氏名】清水 滉允
【審査官】梅岡 信幸
(56)【参考文献】
【文献】特許第6257015(JP,B1)
【文献】特開2010-154881(JP,A)
【文献】特表2009-504223(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G16H 10/00-80/00
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
ネットワークを介して測定装置から測定データを受信し、前記測定データから生体データへ演算を行うデータ管理サーバであって、
前記測定装置ごとにデータレイヤを生成するデータレイヤ管理部と、
前記測定装置を利用するユーザごとにアカウントを生成し、前記測定装置に対応する前記データレイヤに区分けされて、前記アカウントごとに前記測定データを記憶させるデータ管理部と、
前記測定データにアクセスするためのインタフェースを提供するインタフェース提供部と、を備え、
前記インタフェース提供部は、1または複数の前記データレイヤへアクセスさせ、1または複数の前記アカウントごとの前記測定データへアクセスさせる、データ管理サーバ。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、測定装置から測定データを受信して生体データへ演算を行うデータ管理サーバ、データ管理方法及びデータ管理プログラムに関する。
【背景技術】
【0002】
生体データを測定する測定装置を利用してユーザの生体データを連続的に測定し、その変化から病気の早期発見や病状変化の検出を行うことは、健康管理を行う上で有効である。そのためには、生体データを測定するだけではなく、複数の生体データから様々な健康状態を把握するため、数多くの測定データと、それに基づく数理モデルを利用したソフトウェアを作成して各種演算を行う必要がある。
【0003】
例えば、ユーザの測定データに基づいて各種演算が行われた数理モデルを提供する開発支援サーバが知られている(例えば、特許文献1参照。)。特許文献1に開示されている開発支援サーバは、測定データから生体情報データへ演算を行うための因果関係である数理モデルを生成し、数理モデルを利用可能に提供する。これにより、ソフトウェア開発者が、ユーザの測定データに基づく数理モデルを容易に利用し、アプリケーションソフトウェアを作成することを可能としている。
【先行技術文献】
【特許文献】
【0004】
【文献】特許第6257015号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、このようなアプリケーションソフトウェア(以下、「アプリ」という。)では、アプリごとにデータストレージが設けられ、それぞれ必要な測定データを含む各種データを記憶しているため、各種データを重複して記憶している場合がある。また、このようなアプリを利用するためには、アプリごとにユーザのアカウントを作成する必要があり、ユーザにとっても煩わしい作業が必要となっている。
【0006】
このような各種データを共用することで、新たな価値を創出することが期待されているが、そのためにはアプリごとにAPI(Application Programming Interface)を作成し、各アプリがデータストレージのデータへアクセスできるようにする必要があり、ソフトウェア開発者にとっても余計な作業が必要となっている。
【0007】
そこで、本開示では、アプリが測定データにアクセスするためのインタフェースを提供するデータ管理サーバ、データ管理方法及びデータ管理プログラムについて説明する。
【課題を解決するための手段】
【0008】
本開示の一態様におけるデータ管理サーバは、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理サーバであって、測定装置ごとにデータレイヤを生成するデータレイヤ管理部と、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理部と、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成部と、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供部と、を備え、インタフェース提供部は、アプリケーションソフトウェアが利用する1または複数のデータレイヤへアクセスさせ、1または複数のアカウントごとの測定データへアクセスさせる。
【0009】
本開示の一態様におけるデータ管理方法は、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理方法であって、データレイヤ管理部が行う、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、データ管理部が行う、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、アプリ生成部が行う、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成ステップと、インタフェース提供部が行う、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、を備え、インタフェース提供ステップは、アプリケーションソフトウェアが利用する1または複数のデータレイヤへアクセスさせ、1または複数のアカウントごとの測定データへアクセスさせる。
【0010】
また、本開示の一態様におけるデータ管理プログラムは、ネットワークを介して測定装置から測定データを受信し、測定データから生体データへ演算を行うデータ管理プログラムであって、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、ユーザの状態を検知し、測定データから生体データに関する所定の演算を行うアプリケーションソフトウェアを生成するアプリ生成ステップと、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、を電子計算機に実行させ、インタフェース提供ステップは、アプリケーションソフトウェアが利用する1または複数のデータレイヤへアクセスさせ、1または複数のアカウントごとの測定データへアクセスさせる。
【発明の効果】
【0011】
本開示によれば、アプリが測定データにアクセスするためのインタフェースを備え、測定装置ごとに区分けされ、ユーザのアカウントごとに記憶されている測定データにアクセスさせる。これにより、測定データから生体データへ演算を行うアプリが容易に測定データにアクセスすることが可能になる。
【図面の簡単な説明】
【0012】
図1】本開示の一実施形態に係るデータ管理システムを示すブロック構成図である。
図2図1の測定データDB121におけるデータレイヤの構造を示すブロック構成図である。
図3図1の測定データDB121に関連付けされるタグ情報の例を示す模式図である。
図4図1の測定データDB121におけるデータ補正の例を示す模式図である。
図5図1の測定装置300で測定される心電波形及び脈波の例について説明するための図である。
図6図1のデータ管理システム1の処理の例を示すフローチャートである。
図7】本開示の一実施形態に係るデータ管理システムを示すブロック構成図である。
図8】本開示の一実施形態に係るコンピュータ600の構成の例を示す機能ブロック構成図である。
【発明を実施するための形態】
【0013】
以下、本開示の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。
【0014】
(実施形態1)
<構成>
図1は、本開示の実施形態1に係るデータ管理システム1を示すブロック構成図である。このデータ管理システム1は、例えば、ユーザの生体データを測定する測定装置から測定データを受信し、ネットワークを介して測定データを受信して生体データへ演算を行うためのシステムである。
【0015】
データ管理システム1は、データ管理サーバ100と、ユーザ端末装置200と、測定装置300と、データレイヤ作成者端末400と、アプリ提供者端末500と、ネットワークNWと、を有している。データ管理サーバ100と、ユーザ端末装置200と、データレイヤ作成者端末400と、アプリ提供者端末500とは、ネットワークNWを介して接続される。ネットワークNWは、インターネット、イントラネット、無線LAN(Local Area Network)やWAN(Wide Area Network)等により構成される。
【0016】
データ管理サーバ100は、例えば、ネットワークを介して測定装置300からユーザの測定データを、ユーザ端末装置200を経由して受信して測定データから生体データへ演算を行う装置であり、各種Webサービスを提供するサーバ装置により構成されている。
【0017】
ユーザ端末装置200は、ユーザが所持する、例えばパーソナルコンピュータやタブレット端末、スマートフォン、スマートウォッチ、携帯電話、PHS、PDA等の情報処理装置であり、例えば、データ管理サーバ100で演算を行った生体データを波形グラフ等により表示させるために利用される。ユーザ端末装置200には、予めユーザの生年月日、性別、身長、体重、歩幅等の情報が登録されており、生年月日から算出した年齢等のユーザ情報を測定データに関連付けてネットワークNWを介してデータ管理サーバ100へ送信する。
【0018】
また、ユーザ端末装置200は、ユーザが測定装置300によりデータを取得する状態を、タッチパネル等を用いて入力することができる。ユーザ端末装置200は、「データを取得する状態」を、例えば、走っている場合には「#ランニング中」、食事中である場合には「#食事中」など、ハッシュタグ情報として入力することができる。ユーザ端末装置200は、測定装置300から受信した測定データを、ハッシュタグ情報と関連付けてネットワークNWを介してデータ管理サーバ100へ送信する。
【0019】
測定装置300は、ユーザの生体データを測定する装置であり、ユーザが自己の腕等の身体に装着して利用される、例えばウェアラブル装置である。この測定装置300は、例えばユーザの心電、脈波、温度(体温)、加速度のデータを測定するための複数種類の装置である。
【0020】
測定装置300の具体的な構成の例としては、2つの電極を皮膚に接触させ、検出電位の差の時間変化より心電を心電波形のデータとして取得する装置で構成しても良く、心電波形は、ガルバニック皮膚反応により取得されたデータでも良い。また、緑、赤、赤外の発光を行うLEDから各光を皮膚に照射し、フォトダイオードで受光した光の強度の時間変化により、ユーザの心臓の心拍により生ずる血管の容積変化により脈波を脈波形のデータとして取得する装置で構成しても良く、この方式で検出を行うことができる脈波形は光電式容積脈波形である。また、ユーザの皮膚に接触させる温度センサによりユーザの皮膚温度をデータとして取得する装置で構成しても良い。さらに、直交するXYZ軸それぞれの変異状態を検出する3軸加速度センサにより構成しても良く、ユーザの動作を加速度データとして取得し、例えば測定装置300がユーザの腕に装着されている場合、測定装置300は、腕の振りと、全身の動きが合成された加速度として加速度データの取得をする。
【0021】
ユーザ端末装置200と測定装置300との間は、Bluetooth(登録商標)、近距離無線通信(Near Field radio Communication=NFC)、Afero(登録商標)、Zigbee(登録商標)、Z-Wave(登録商標)、又は無線LAN等を用いて接続されている。なお、このような無線接続の代わりに有線で接続を行っても良い。また、ユーザ端末装置200と測定装置300とは一体の機器であっても良く、例えば測定装置300に通信機能を持たせてデータ管理サーバ100と直接通信可能に構成しても良い。
【0022】
ユーザ端末装置200は、1または複数台あり、測定装置300を利用するユーザ数分ネットワークNWに接続されている。測定装置300は、1または複数台あり、1人のユーザが利用する台数分ユーザ端末装置200に接続されている。1人のユーザが複数の測定装置300を利用している場合は、1つのユーザ端末装置200に複数の測定装置300が接続されている。
【0023】
データレイヤ作成者端末400は、測定データを記憶させる、後述するデータレイヤを管理するデータレイヤ作成者の端末であり、データレイヤへのアクセス管理を行うための装置である。アプリ提供者端末500は、生体データを利用する、後述するアプリ(アプリケーションソフトウェア)のダウンロード等を管理するための装置である。データレイヤ作成者端末400及びアプリ提供者端末500は、例えば、パーソナルコンピュータ等により構成される。
【0024】
データ管理サーバ100は、通信部110と、記憶部120と、データレイヤ管理部130と、データ管理部140と、アプリ生成部150と、インタフェース提供部160と、演算部170とを備える。
【0025】
通信部110は、ユーザ端末装置200、データレイヤ作成者端末400、及びアプリ提供者端末500と通信を行うための通信インタフェースであり、例えばTCP/IP(Transmission Control Protocol/Internet Protocol)等の通信規約により通信が行われる。
【0026】
記憶部120は、各種制御処理やデータレイヤ管理部130、データ管理部140、アプリ生成部150、インタフェース提供部160、及び演算部170の各機能を実行するためのプログラム、入力データ等を記憶するものであり、RAM(Random Access Memory)、ROM(Read Only Memory)等から構成される。また、記憶部120は、測定装置300による測定データを記憶する測定データDB121と、測定データから演算されて生成される生体データを記憶する生体情報データDB122と、測定データDB121に記憶されている測定データにアクセスするためのインタフェースを記憶するインタフェースDB123と、例えば生体データを利用してユーザの健康管理情報を通知するアプリDB124とを記憶する。さらに、記憶部120は、ユーザ端末装置200、データレイヤ作成者端末400、及びアプリ提供者端末500と通信を行ったデータを一時的に記憶する。
【0027】
データレイヤ管理部130は、記憶部120の測定データDB121内に、測定装置300の種類ごとにデータレイヤを生成し、データレイヤへのアクセスを管理する。
【0028】
ここで、記憶部120の測定データDB121内に生成されるデータレイヤについて説明する。図2は、図1の測定データDB121におけるデータレイヤの構造を示すブロック構成図である。図2に示すように、測定データDB121には、複数のデータレイヤ121a,121b,121cにより区分けされている。
【0029】
データレイヤ121a,121b,121cは、測定装置300の種類ごとに設けられるデータ記憶空間(データストレージ)であり、例えば、測定装置300の一種類であるデバイスA,B,Cごとに、データレイヤ121a,121b,121cがそれぞれ設けられている。このデータレイヤ121a,121b,121cは、例えば、データレイヤを管理する業者であるデータレイヤ作成者によりデータレイヤ作成者端末400が操作されて生成される。
【0030】
デバイスA,B,Cは、ユーザがアカウント登録を行うことにより測定データがデータ管理サーバ100へ送信されて生体データが演算される装置であり、データレイヤ121a,121b,121cには、ユーザごとにアカウントが生成されている。図2に示す例では、ユーザXのアカウントXがデータレイヤ121a,121bに生成され、ユーザYのアカウントYがデータレイヤ121a,121cに生成されている。これは、ユーザXがデバイスA,Bを利用しており、ユーザYがデバイスA,Cを利用しているためである。ユーザXのデバイスAによる測定データは、データレイヤ121aのアカウントXに記憶され、ユーザXのデバイスBによる測定データは、データレイヤ121bのアカウントXに記憶される。また、ユーザYのデバイスAによる測定データは、データレイヤ121aのアカウントYに記憶され、ユーザYのデバイスCによる測定データは、データレイヤ121cのアカウントYに記憶される。
【0031】
また、後述するアプリ生成部150により生成されるアプリAP1,AP2は、測定データDB121にアクセスして測定データを読み取り、生体データを生成したり、ユーザ端末装置200に表示させたりする。このアプリAP1,AP2は、ソフトウェア開発者がアプリを開発するとき、その種類や目的に応じて測定データDB121の希望のデータレイヤを参照するためのプログラムである。図2に示す例では、アプリAP1がデータレイヤ121a,121bにアクセスし、アプリAP2がデータレイヤ121b,121cにアクセスするように設定されている。
【0032】
このように、測定装置300の種類ごとにデバイスA,B,Cに対応するようにデータレイヤ121a,121b,121cに区分けされ、データレイヤ121a,121b,121cにユーザX,Yが利用するデバイスA,B,Cに対応させてアカウントX,Yが生成されているのは、このように測定データを統合することにより、ソフトウェア開発者(アプリケーションソフトウェア提供者)はアプリの種類や目的に応じて測定データDB121の希望のデータレイヤを参照することが容易であり、APIを作成する手間が削減されるからである。また、データレイヤ管理部130がデータレイヤを生成し、後述するデータ管理部140がアカウントの作成及び測定データを一元管理することにより、データの重複がなくなるので、無駄な資源の利用を削減することが可能である。
【0033】
データ管理部140は、測定装置300を利用するユーザごとに、所定のデータレイヤ内にアカウントを生成する。このアカウント生成は、測定装置300を利用するユーザがユーザ端末装置200でアカウントを登録すると行われる。また、データ管理部140は、測定装置300に対応するデータレイヤ内のアカウントごとに、測定データを記憶させる。そのため、データ管理部140は、アプリAP1,AP2に対してデータレイヤごとにアクセスの可否を制御し、ユーザのユーザ端末装置200に対してアカウントごとにアクセスの可否の制御を行う。また、このとき、データ管理部140は、測定データに所定のタグ情報の関連付けを行って記憶させることが可能である。
【0034】
図3は、図1の測定データDB121に関連付けされるタグ情報の例を示す模式図である。図3に示すデータD1は、測定装置300の測定データである。タグT1は、データD1に関連付けされたタグ情報であり、例えば、測定装置300がデータD1を測定した時刻情報、またはデータD1が測定装置300からユーザ端末装置200へ送信された時刻情報が時系列データとして記憶される。もしくは、測定した時刻情報と送信された時刻情報との両方について関連付けを行っても良い。例えば、図3に示すタグT1の1行目では、「20180620120746144」が格納されているが、2018年06月20日12時07分46秒144ミリ秒を示している。このような時刻情報は通信ログより取得可能である。これにより、測定データがどの時間帯のものか把握することが可能である。
【0035】
なお、このようなタグ情報による測定データの関連付けは、時刻情報に限られず、ユーザの身体状態や活動状態を示す身体情報や活動情報を自由記載で記入させてタグ情報として記憶しても良く、所定の選択肢から選択させ(例えば、「現在の体調は如何ですか?」という質問に対して、「1:良い、2:普通、3:悪い」のいずれかを選択させる、等)、その選択した回答を記憶するようにしても良い。
【0036】
また、例えばデータ管理部140は、図3に示すように、データD1をタグT1の時刻順に並べ替え(ソート)を行うことが可能である。このような構成にしたのは、測定データはユーザの生体データに基づいて時系列に取得したものであるから時系列に並んでいる方が処理しやすいからであるが、ユーザ端末装置200及び通信部110を経由して受信する際に通信状況の変化等により受信データの逆転(後で送信された送信データが先に送信された送信データより先に受信されること)等が起こる場合があり、そのときの測定データの不整合を防止するためである。これにより、測定データの不整合を防止することが可能である。
【0037】
さらに、データ管理部140は、通信エラー等による測定データの欠損を補正することが可能である。図4は、図1の測定データDB121におけるデータ補正の例を示す模式図である。図4に示すデータD2は、図3のデータD1と同様の測定装置300の測定データであり、タグT2は、データD1に関連付けされたタグ情報である。
【0038】
測定装置300による測定データは、心電や脈波のように周期的な信号であったり、温度(体温)のようにある程度ゆっくり変化する時系列データであったりするため、所定の範囲内で予測が可能である。そのため、図4のデータD2に示すように所定の時刻の測定データが欠損している場合、例えば、当該時刻の直前に受信した測定データと、当該時刻の直後に受信した測定データとに基づいて推定することが可能である。この欠損データの推定は、例えば、当該時刻の直前に受信した測定データと当該時刻の直後に受信した測定データとの平均値や、時系列データにおける時間推移からの推定値を使用しても良い。また、直前及び直後のデータに限られず、所定範囲の前後のデータ(例えば、前後5つのデータ)から推定しても良い。このような場合に、データ管理部140は、他の時刻の測定データを当該時刻の測定データと推定してタグ情報の関連付けを行う。
【0039】
アプリ生成部150は、測定データDB121に記憶された測定データから生体データを演算して算出したり、算出された生体データを利用したり、といった生体データに関する所定の演算を行い、例えば、ユーザの健康管理情報を通知するためにデータ管理サーバ100またはユーザ端末装置200で実行可能なアプリを生成する。この生体データは、例えばユーザの血圧情報、心拍情報、血中酸素量情報、心電情報、呼吸数、体温情報、歩幅情報、重心の位置情報のデータであり、このようなデータを算出または利用するためのアプリが生成される。演算により生成された生体データは、生体情報データDB122に記憶される。また、生成されたアプリは、アプリDB124に記憶される。さらに、このアプリは、ユーザの希望によりユーザ端末装置200が操作されると、ユーザ端末装置200へ配信される。
【0040】
ここで、アプリ生成部150により生成されるアプリの例として、測定データから生体情報データである最大血圧と最小血圧を算出する方法を説明する。図5は、図1の測定装置300で測定される心電波形及び脈波の例について説明するための図であり、測定装置300が測定し、記憶部120に記憶されたユーザの心電波形及び光電式容積脈波形と、アプリが光電式容積脈波形を時間で1階微分した速度脈波形及び、光電式容積脈波形を時間で2階微分した加速度脈波形を示している。図5は上から順に、心電波形、光電式容積脈波形、速度脈波形及び加速度脈波形となる。縦軸は、各波形の強度を示しており、心電波形及び光電式容積脈波形は電位を示すmVで表される。横軸は時間経過を示し、左から右へ時間経過を示している。
【0041】
心電波形は、人の心臓の拍動を引き起こす電気的信号の周期的変化を示す波形である。心電波形は、その形状の変曲点にそれぞれP波,Q波,R波,S波,T波の名称が割り当てられ、心拍の1サイクルを示している。P波は心房収縮を表し、Q波R波S波は心室収縮の状態を表し、T波は心室拡張の開始を表す。
【0042】
光電式容積脈波形は、人の心臓の拍動に伴う末梢血管系内の血圧・体積の変化を示す波形である。光電式容積脈波形は、その形状の変曲点にそれぞれA波、P波、V波、D波の名称が割り当てられ、心拍の1サイクルを示している。A波を動脈脈波が生じた時点の基準点として、P波が左心室駆出によって生じるPercussion波(衝撃波)、V波が大動脈弁の閉鎖時に生じるValley波(重複隆起による波)、D波が反射振動波であるDicrotic波(重複波)を示している。
【0043】
速度脈波形は、光電式容積脈波形を時間で1階微分をしたものである。加速度脈波形は、速度脈波形を時間で1階微分したもの、すなわち光電式容積脈波形を2階微分したものである。加速度脈波形は、図5で示すように、その波形の各ピークにa波(収縮初期陽性波)、b波(収縮初期陰性波)、c波(収縮中期再上昇波)、d波(収縮後期再下降波)、e波(拡張初期陽性波)、f波(拡張初期陰性波)の名称が割り当てられている。
【0044】
b波の強度とa波の強度の比、及びf波の強度とe波の強度の比はそれぞれ血管の伸縮性すなわち弾性を示すパラメータである。主な血管の成分は、血管内皮(Endothelium)、弾性線維(Elastin)、タンパク質(Collagen)、平滑筋(Smooth Muscle)である。これらの成分は、それぞれ異なった性質があり、最大血圧、最小血圧時の血管の弾性はそれぞれCollagen、Elastinが強い影響力を担っている。そのため、血圧値によって異なる弾性をb波の強度とa波の強度の比である(b/a),f波の強度とe波の強度の比である(f/e)のパラメータで示すことができ、年齢・性別・環境変数の影響によってもこれらの値は変動する。そのため、(b/a),(f/e)の値は、加速度脈波形の特性情報として算出することができる。
【0045】
図5で示すように、R波の生じた時間TrとP波の生じた時間Tpの差分の時間が心室収縮期脈波伝搬時間PTT_SYSとなる。T波の生じた時間TtとD波の生じた時間Tdの差分の時間が心室拡張期脈波伝搬時間PTT_DIAとなる。すなわち、心電波形のR波の時間Tr及びT波の時間Ttと、光電式容積脈波形のT波の時間TpとD波の時間Tdから、心室収縮期脈波伝搬時間PTT_SYS及び心室拡張期脈波伝搬時間PTT_DIAを算出することができる。
【0046】
また、脈波伝播速度と動脈壁の縦弾性係数との関係が所定の式で示される相関関係にあることが知られており、縦弾性係数と血圧値との関係も所定の式で示される相関関係にあることが知られている。そのため、最大血圧を心室収縮期脈波伝搬時間PTT_SYSの所定の式で求めることが可能であり、最小血圧を心室拡張期脈波伝搬時間PTT_DIAの所定の式で求めることが可能である。これにより、最大血圧と最小血圧を算出することが可能である。
【0047】
インタフェース提供部160は、アプリが測定データにアクセスするため、インタフェースDB123に記憶されているインタフェースを提供する。このインタフェースは、APIのようにデータストレージのデータへアクセスするためにソフトウェア開発者が作成するものとは異なり、例えば、データレイヤへのアクセスを一元管理するデータレイヤ作成者により提供されるものであり、データレイヤごとに提供されるものである。これにより、ソフトウェア開発者がAPIを作成する必要がなくなり、その種類や目的に応じて測定データDB121の希望のデータレイヤを容易に参照することが可能になる。
【0048】
演算部170は、アプリ生成部150により生成されたアプリを実行することにより、データ管理サーバ100の全体の動作を制御するものであり、CPU(Central Processing Unit)等から構成される。
【0049】
ソフトウェア開発者は、アプリ提供者端末500において、データ管理サーバ100から取得したインタフェースを用いて、測定データから生体情報データを生成し、測定者の状態を検知するアプリを作成することができる。また、ソフトウェア開発者は、作成したアプリを、アプリ提供者端末500からデータ管理サーバ100のアプリDB124へアップロードすることができる。
【0050】
アプリを利用したいと希望するユーザは、ユーザ端末装置200からネットワークNWを介してデータ管理サーバ100へアクセスし、希望するアプリをユーザ端末装置200へダウンロードする。ユーザは、データ管理サーバ100へアクセスして自己のアカウントを作成することで、アプリを利用することが可能になる。
【0051】
<処理の流れ>
図6を参照しながら、データ管理システム1が実行するデータ管理方法の処理の流れについて説明する。図6は、図1のデータ管理システム1の処理の例を示すフローチャートである。
【0052】
ステップS101の処理として、データレイヤ管理部130では、データレイヤ作成者の指示により、測定装置300の種類ごとにデータレイヤが記憶部120の測定データDB121内に生成される。これ以降、データレイヤ管理部130によってデータレイヤごとのアクセスが管理される。
【0053】
ステップS102の処理として、データ管理部140では、測定装置300を利用するユーザごとに、記憶部120の測定データDB121内における測定装置300に対応する所定のデータレイヤ内にアカウントが生成される。ステップS101及びステップS102の処理は、ユーザが測定装置300を利用するための前処理として行われる。
【0054】
ステップS103の処理として、ユーザが測定装置300を利用すると、測定データが測定装置300からユーザ端末装置200を介してデータ管理サーバ100へ送信され、通信部110を介して受信される。データ管理部140では、記憶部120の測定データDB121内における測定装置300に対応するデータレイヤ内のアカウントごとに測定データが記憶される。
【0055】
ステップS104の処理として、アプリ生成部150では、測定データDB121に記憶された測定データから、データ管理サーバ100またはユーザ端末装置200で実行可能なアプリが生成される。生成されたアプリは、アプリDB124に記憶される。
【0056】
ステップS105の処理として、インタフェース提供部160では、ステップS104で生成されたアプリに対して、所定のデータレイヤにアクセスするためのインタフェースDB123に記憶されているインタフェースが提供される。これにより、アプリから所定のデータレイヤ内の測定データにアクセスすることが可能になる。
【0057】
ステップS106の処理として、演算部170では、ステップS104で生成されたアプリが利用されると、測定データDB121の所定のデータレイヤにアクセスされて測定データが読み取られ、生体データの算出等の所定の演算が行われる。演算により算出された生体データは、生体情報データDB122に記憶され、当該アプリや他のアプリでも利用可能になる。
【0058】
<効果>
以上のように、本実施形態に係るデータ管理システムは、データレイヤ管理部により、測定装置の種類に対応するようにデータレイヤが生成され、データ管理部により、各データレイヤにユーザごとにアカウントが生成され、ユーザの測定データがユーザのアカウントごとに記憶されている。これにより、測定データが一元管理されるので、データの重複がなくなり、無駄な資源の利用を削減することが可能である。
【0059】
また、インタフェース提供部により、アプリが所定のデータレイヤにアクセスするためのインタフェースが提供され、ソフトウェア開発者はアプリの種類や目的に応じて希望のデータレイヤの測定データを参照することが可能である。これにより、APIを作成する手間が省けるので、容易にアプリの開発が可能である。
【0060】
さらに、データ管理部により、測定データに関連付けされてタグ情報が記憶されることにより、測定データを測定した時刻やユーザの測定状態を記憶することができるので、測定データをより精度高く利用することが可能になる。
【0061】
(実施形態2)
図7は、本開示の実施形態2に係るデータ管理システム1Aを示すブロック構成図である。このデータ管理システム1Aは、ユーザの生体データを測定する測定装置から測定データを受信し、ネットワークを介して測定データを受信して生体データへ演算を行うためのシステムである点において実施形態1と同様であるが、図7に示すように、データ管理サーバ100Aには、支払情報算出部180を備えている点において、実施形態1と異なる。
【0062】
支払情報算出部180は、データ管理サーバ100Aを利用するための、ユーザ、データレイヤ作成者、及びソフトウェア開発者(アプリケーションソフトウェア提供者)の支払情報を算出する。具体的には、測定装置300を利用するユーザがデータ管理サーバ100Aを利用するための利用料を算出するための支払情報を算出し、データレイヤ作成者へ当該データレイヤのデータ参照料を算出するための支払情報を算出し、ソフトウェア開発者へ測定データのデータ使用料を算出するための支払情報を算出する。その他の構成については、実施形態1と同様である。
【0063】
ここで、ユーザ、ソフトウェア開発者、及びデータレイヤ作成者の支払関係について説明する。なお、ソフトウェア開発者はアプリを提供している者(アプリケーションソフトウェア提供者)であるが、アプリを購入等してネットワークNW上で配信を行う者であっても良い。また、データレイヤ作成者はデータ管理サーバ100Aにデータレイヤを作成した者であるが、データ管理サーバ100Aにおけるデータストレージの管理者等でも良い。まず、測定装置300を利用するユーザは、データ管理サーバ100Aの運営者へ利用料を支払う。この利用料には、ソフトウェア開発者に対するアプリを利用するための利用料と、データレイヤ作成者に対するデータレイヤを利用するための利用料とが含まれる。この利用料は、例えばユーザの利用時間や使用したデータ量に応じて算出される。
【0064】
データレイヤ作成者は、データ管理サーバ100Aの運営者へデータ管理サーバ100Aの運用費を支払う。この運用費は、例えば記憶部120内に確保した空きデータ容量に応じて算出される。そして、データ管理サーバ100Aの運営者は、データレイヤ作成者へデータの参照料を支払う。この参照料は、例えば当該データレイヤのアクセス数や参照されたデータ量(参照データ量)に応じて算出される。
【0065】
ソフトウェア開発者は、データ管理サーバ100Aの運営者へ、ユーザに対するアプリ提供の課金ツールの利用料を支払う。この利用料は、例えばユーザのダウンロード数に応じて算出される。そして、データ管理サーバ100Aの運営者は、ソフトウェア開発者へアプリの利用料を支払う。この利用料は、例えばアプリのダウンロード数やユーザによるアプリの利用回数に応じて算出される。
【0066】
支払情報算出部180は、このような各支払情報の基になる、ユーザの利用時間や使用したデータ量、データレイヤのアクセス数や参照されたデータ量、アプリのダウンロード数やユーザによるアプリの利用回数等をカウントし、支払情報を算出する。
【0067】
なお、この各支払は電子マネーやクレジットカードによる支払を可能にしても良く、データ管理サーバ100Aは、電子マネーやクレジットカードのサービスを提供するサーバにアクセスして決済を行う機能を備えていても良い。
【0068】
本実施形態によれば、上記実施形態1の効果に加え、支払情報算出部を備えたことにより、複雑なユーザのデータ管理サーバの運営者に対する支払情報、データレイヤ作成者とデータ管理サーバの運営者との間の支払情報、ソフトウェア開発者とデータ管理サーバの運営者との間の支払情報を適切に管理することが可能になる。
【0069】
(実施形態3(プログラム))
図8は、コンピュータ(電子計算機)600の構成の例を示す機能ブロック構成図である。コンピュータ600は、CPU601、主記憶装置602、補助記憶装置603、インタフェース604を備える。
【0070】
ここで、実施形態1及び2に係るデータレイヤ管理部130、データ管理部140、アプリ生成部150、インタフェース提供部160、及び支払情報算出部180を構成する各機能を実現するための制御プログラムの詳細について説明する。これらの機能ブロックは、コンピュータ600に実装される。そして、これらの各構成要素の動作は、プログラムの形式で補助記憶装置603に記憶されている。CPU601は、プログラムを補助記憶装置603から読み出して主記憶装置602に展開し、当該プログラムに従って上記処理を実行する。また、CPU601は、プログラムに従って、上述した記憶部に対応する記憶領域を主記憶装置602に確保する。
【0071】
当該プログラムは、具体的には、コンピュータ600において、測定装置ごとにデータレイヤを生成するデータレイヤ管理ステップと、測定装置を利用するユーザごとにアカウントを生成し、測定装置に対応するデータレイヤに区分けされて、アカウントごとに測定データを記憶させるデータ管理ステップと、測定データから生体データへ演算を行う演算ステップと、ユーザの状態を検知し、測定データから生体データへの演算結果に基づく生体データを利用するアプリケーションソフトウェアを生成するアプリ生成ステップと、アプリケーションソフトウェアが測定データにアクセスするためのインタフェースを提供するインタフェース提供ステップと、をコンピュータによって実現する制御プログラムである。
【0072】
なお、補助記憶装置603は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、インタフェース604を介して接続される磁気ディスク、光磁気ディスク、CD-ROM、DVD-ROM、半導体メモリ等が挙げられる。また、このプログラムがネットワークを介してコンピュータ600に配信される場合、配信を受けたコンピュータ600が当該プログラムを主記憶装置602に展開し、上記処理を実行してもよい。
【0073】
また、当該プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、当該プログラムは、前述した機能を補助記憶装置603に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル(差分プログラム)
であってもよい。
【0074】
以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。
【符号の説明】
【0075】
1,1A データ管理システム、100,100A データ管理サーバ、110 通信部、120 記憶部、121 測定データDB、122 生体情報データDB、123 インタフェースDB、124 アプリDB、130 データレイヤ管理部、140 データ管理部、150 アプリ生成部、160 インタフェース提供部、170 演算部、180 支払情報算出部、200 端末装置、300 測定装置、400 データレイヤ作成者端末、500 アプリ提供者端末、NW ネットワーク
図1
図2
図3
図4
図5
図6
図7
図8