JP6751804B2 - 通信システム - Google Patents

Description

本発明は、通信システムに関するものであり、特にサーバ上のデータに複数のユーザがアクセスすることを可能とする通信システムに関する。

ネットワークを介した通信システムにおいて、複数の箇所に設置されたセンサユニットが、そのセンサユニットの周囲環境の温度などの環境情報をセンサデータとして検出し、ネットワークを介してそのセンサデータをサーバに送信するという方式が採られることがある。この方式の通信システムでは、ユーザがネットワークを介してサーバと通信することにより、センサユニットから送信されたセンサデータをユーザが閲覧することが可能である。

このような通信システムによれば、ユーザは、センサユニットの設置箇所を実際に訪れることなくセンサユニット設置箇所の環境情報を知ることができる。またセンサユニットが複数の箇所に設置されていることにより、ユーザは、一箇所に留まったままで、移動することなく複数の箇所における環境情報を知ることができる。

しかしながら、こうした通信システムにおいて、どのようなユーザであってもサーバ上のデータにアクセスすることが可能になっていると、セキュリティ上の問題が生じることがある。

例えばセンサユニットの所有者が自宅にそのセンサユニットを設置し、自身の生活環境情報を家族へ知らせるために上述の通信システムを利用する場合、家族以外の第三者がセンサユニットのセンサデータにアクセスできてしまうと、センサユニット所有者のプライバシーが第三者へ漏洩してしまうこととなる。そこで本発明は、信用できるユーザのみがセンサデータを閲覧することが可能な通信システムを提供することを課題とする。

この課題を解決するため、本発明に係る通信システムは、サーバ上のデータに複数のユーザがアクセスすることを可能とする通信システムであって、前記サーバは、複数のセンサユニットの情報を管理するセンサユニット管理部と、前記ユーザのそれぞれに対応するユーザアカウントを管理するユーザ管理部と、を備え、前記センサユニットは、自身の設置されている周囲環境から検出したセンサデータを前記サーバへ送信し、前記センサユニット管理部は、前記センサユニットのそれぞれから受信した前記センサデータを、各前記センサユニットごとに分類して記録し、前記ユーザ管理部は、前記センサユニットのそれぞれに個別に割り当てられているセンサ管理符号を前記サーバへ送信したユーザのユーザアカウントを、当該センサ管理符号に対応する前記センサユニットの管理アカウントとして登録し、また、前記管理アカウントから招待を受けたユーザアカウントを、その管理アカウントに対応する前記センサユニットの被招待アカウントとして登録し、前記サーバは、特定の被要求センサユニットのセンサデータを閲覧することを要求するデータ要求を特定の要求ユーザアカウントから受信した場合には、前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントまたは前記被招待アカウントであるかどうかを前記ユーザ管理部によって確認し、前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントまたは前記被招待アカウントである場合には、前記センサユニットに記録されている前記被要求センサユニットの前記センサデータを前記要求ユーザアカウントへ送信し、前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントではない非管理アカウント、かつ前記被招待アカウントではない未招待アカウントである場合には、前記データ要求を拒否し、前記被招待アカウントは自分自身を未招待アカウントへと変更可能であり、前記管理アカウントは前記被招待アカウントを未招待アカウントへと変更可能であり、また前記管理アカウントは自分自身を非管理アカウントへと変更可能であり、前記管理アカウントが非管理アカウントに変更された場合には、当該管理アカウントから招待を受けていた被招待アカウントは全て未招待アカウントへと変更されることを特徴とする。

また好ましくは、本発明の通信システムにおいて、前記センサユニットのそれぞれは、定期的に現時点における前記センサデータを前記サーバへ送信し、前記サーバの前記センサユニット管理部は、前記センサユニットのそれぞれから受信した前記センサデータを、前記センサユニットごとに分類かつ時系列順に整理して蓄積するとよい。

また好ましくは、本発明の通信システムにおいて、前記サーバは、蓄積した前記センサデータに基づいて統計処理を行うことで算出した統計データを前記センサユニットごとに記録するとよい。

また好ましくは、本発明の通信システムにおいて、前記サーバは、前記センサデータに基づいて、いずれかの前記センサユニットに異常が発生しているか否かの判断を行い、異常が発生している前記センサユニットに対応する前記管理アカウントおよび／または前記被招待アカウントに対して、異常発生の通知が前記サーバから行われるとよい。

また好ましくは、本発明の通信システムにおいて、前記被招待アカウントは、前記サーバからの通知の受信形態を複数の形態から選択可能であるとよい。

本発明によれば、特定のセンサユニットのセンサデータを閲覧できるのは、そのセンサユニットのセンサ管理符号をサーバへ送信した管理アカウントと、その管理アカウントから招待を受けた被招待アカウントのみであるため、センサユニット所有者の家族などの、センサ管理符号を入手できる立場のユーザと、招待を受けたユーザという信頼できるユーザのみがセンサデータを閲覧できることとなり、通信システムのセキュリティが強固なものとなる。

本発明に係る通信システムの実施形態の一例における各種機器の配置例。 同実施形態における通信システムのブロック図。 同実施形態におけるセンサユニットを示す図であり、上側の図が正面図、下側の図が背面図。 同実施形態におけるデータ構造の概念図。 同実施形態における通信の手順を示すフローチャート。 同実施形態におけるアカウント識別の手順をフローチャート。 同実施形態における招待の手順を示すフローチャート。 同実施形態におけるアカウント種別変更の手順を示すフローチャート。

以下、図面を参照しながら本発明に係る通信システムの実施形態の一例について説明する。本実施形態の通信システムにおけるサーバやセンサユニット、ユーザ端末といった各種機器の配置例を図１に示す。図１に示す通信システム１０においてはセンサユニット３０が検出対象者ＴＵの自宅に設置される。検出対象者ＴＵは例えば高齢者や要介護者であり、その高齢者の家族や要介護者の担当介護者が、検出対象者ＴＵの生活環境を確認するためにセンサユニット３０を設置する。センサユニット３０の設置を行った人物を以下設置ユーザＰＵと呼ぶ。

設置ユーザＰＵは多数存在し、それぞれが別々の検出対象者ＴＵの自宅にセンサユニット３０を設置する。これにより、センサユニット３０は複数の箇所に設置される。なお、一人のユーザが複数の検出対象者ＴＵの自宅にそれぞれセンサユニット３０を設置することもある。つまり、一人の設置ユーザＰＵが複数のセンサユニット３０を設置することもある。

センサユニット３０には温度センサ、照度センサ、人感センサ（赤外線などにより特定箇所における人間の動きを検出するセンサ）が組み込まれており、設置箇所における温度、照度、検出対象者ＴＵの動きといった周囲環境のデータをセンサデータとして検出する。こうして検出されたセンサデータは、無線通信、あるいは有線通信により、ネットワークＮＷを介して別の箇所（都心部のデータセンタなど）に存在するサーバ２０へと送信される。

サーバ２０により、複数のユーザが参加できるネットワークサービスが運用されており、設置ユーザＰＵはそれぞれこのネットワークサービスに参加し、自身に固有のユーザアカウントをサーバ２０へ登録する。また、設置ユーザＰＵの親類など、設置ユーザ以外にも検出対象者の生活環境を知りたい人物（以下サブユーザＳＵと呼ぶ）がいる場合には、そうしたサブユーザＳＵもユーザアカウントをサーバ２０へ登録してネットワークサービスに参加する。

なお、ネットワークサービスへの参加方法としては例えば以下の方法がある。ユーザ（設置ユーザＰＵおよびサブユーザＳＵ）がそれぞれ所有する携帯電話やタブレットといったユーザ端末４０にネットワークサービス用のアプリケーションを導入した上で、そのアプリケーションを介して、各ユーザが自身に固有のユーザＩＤとパスワードをサーバ２０へ送信することにより、そのユーザＩＤとパスワードの組み合わせがユーザアカウントの情報としてサーバ２０へ登録される。それ以後は、各ユーザは登録したときとは異なるユーザ端末４０を使用していても、登録されたユーザＩＤとパスワードの組み合わせをサーバ２０へ送信することにより、登録したときと同一のユーザアカウントとしてネットワークサービスを利用できる。

設置ユーザＰＵは自身が設置したセンサユニット３０について、自分がそのセンサユニット３０の管理者であることをサーバ２０へ登録することにより、設置ユーザＰＵはそのセンサユニット３０のセンサデータを、サーバ２０を介して閲覧できる。一方、そのセンサユニット３０の管理者となっていない他の設置ユーザＰＵがセンサデータを閲覧することはできない。また、サブユーザＳＵは、ネットワークサービスに参加しただけではいずれのセンサユニット３０のセンサデータも閲覧することができない。

ここで、ネットワークサービスには他のユーザアカウントに対して設置ユーザＰＵが特定のセンサユニット３０のセンサデータの閲覧を許可するように招待を行う機能があり、設置ユーザＰＵが、サブユーザＳＵ、あるいは他の設置ユーザＰＵを招待すると、招待を受けたユーザは、招待を行った設置ユーザＰＵが許可したセンサユニット３０のセンサデータを閲覧することが可能となる。このように、本実施形態においては特定の条件を満たすことにより複数のユーザがサーバ上のセンサデータへとアクセスすることが可能となっている。

本実施形態における通信についてより詳しく説明する。図２に、本実施形態の通信システム１０におけるブロック図を示す。サーバ２０は、各センサユニット３０の情報を管理するセンサユニット管理部２２と、各ユーザのユーザアカウントを管理するユーザ管理部２４と、センサユニット３０やユーザ端末４０とのデータ送受信（通信）を行うサーバ送受信部２６を備えている。

センサユニット３０は、温度センサ、照度センサ、人感センサなどの、周囲環境から環境情報をセンサデータとして検出するセンサ部３２と、サーバ２０とのデータ送受信を行うセンサ送受信部３６を備えている。なお、センサユニット３０のそれぞれには、個別にセンサ管理符号３８が割り当てられている。

ユーザ端末４０は、ネットワークサービス用のアプリケーションを導入することにより、サーバ２０との通信を行うためのいくつかの機能を発揮するようになる。アプリケーション導入後のユーザ端末４０は、サーバ２０から受信したセンサデータなどの各種情報を表示する表示部４１と、ユーザからの操作を受け付ける操作入力部４５と、サーバ２０とのデータ送受信を行うユーザ送受信部４６と、センサ管理符号保持具３９からセンサ管理符号３８を取得するためのセンサ管理符号取得部４９を備える。またユーザが自身のユーザアカウントを用いてサーバ２０と通信を行っている間、サーバ２０はそのユーザアカウントのユーザＩＤを通信中のユーザ端末４０に付与する。

図３にセンサユニット３０の一例を示す。このセンサユニット３０は検出対象者の自宅、つまり家屋の室内に設置されることが想定されている。図３に示すセンサユニット３０においては、設置箇所の温度（室温）を検出するための温度センサ３２ａと、設置箇所の照度（室内の明るさ）を検出するための照度センサ３２ｂと、設置箇所の周囲（室内）における人間の動きを検出する人感センサ３２ｃがセンサ部３２を構成している。また、このセンサユニット３０には、センサ部３２の他に、ＬＥＤインジケータなどによりセンサユニット３０の動作状態を示す動作状態表示部３３と、外部からの（検出対象者などによる）手動操作を受け付ける手動操作部３５（ここでは小型のボタン）と、外部の電源と接続するための電源ケーブル３７が設けられている。なお、図３には現れていないが、センサユニット３０の筐体内には、無線ＬＡＮや携帯電話回線網などを介した無線通信によりサーバ２０とデータの送受信を行うセンサ送受信部３６が設けられている。

先述の通り、センサユニット３０のそれぞれには、個別にセンサ管理符号３８が割り当てられている。このセンサ管理符号３８は、各センサユニット３０に固有のセンサＩＤを基に生成される情報であり、後述するように、ユーザが、このセンサ管理符号３８の情報をサーバ２０へ送ることにより、そのユーザのユーザアカウントがセンサ管理符号３８に対応するセンサユニット３０の管理アカウントとしてサーバ２０のユーザ管理部２４に登録される。センサユニット３０を実際に所有するユーザであればセンサ管理符号３８を取得することができるように、センサ管理符号３８は、センサユニット３０に設けられたセンサ管理符号保持具３９に保持されている。例えば図３下側の図に示すように、センサ管理符号３８の情報を表す二次元コードを記載したシールが、センサ管理符号保持具３９としてセンサユニット３０の背面に貼り付けられている。なおセンサユニット３０の背面には壁掛け孔３１ａや台座取付窪み３１ｂが設けられており、設置ユーザＰＵは壁面に釘やネジに壁掛け孔を取り付け、その釘やネジに壁掛け孔３１ａを引っ掛けることでセンサユニット３０を壁面に取り付けたり、台座取付窪み３１ｂに台座を取り付けて、台座を用いて机などの家具の上面にセンサユニットを載置するなどしてセンサユニット３０の設置を行うことができる。

図４に、本実施形態の各種機器間で送受信されるデータについて、データ構造の概念図を示す。センサユニット３０は定期的（例えば１０分ごと）に、現時点におけるセンサデータをサーバ２０へ送信する。センサユニット３０から送信されるセンサデータには、センサユニット３０の設置箇所の周囲環境からセンサ部３２によって検出された環境情報、すなわち温度値、照度値、人感値（０：人間の動きなし、１：人間の動きあり）といった各センサの検出値が含まれる。また、図４に示すように、センサデータには検出値のほか、検出を行ったセンサユニット３０のセンサＩＤが含まれる。一方、サーバ２０のセンサユニット管理部２２はセンサデータが送信された時刻も記録しており、サーバ２０のセンサユニット管理部２２に記録されるセンサデータは、センサデータに含まれるセンサＩＤに基づいてセンサユニット３０ごとに分類して記録されるとともに、送信時刻順に並べられて時系列順に整理して蓄積される。

各ユーザがネットワークサービスを利用する際には、アプリケーション導入済みのユーザ端末４０を介してサーバ２０へユーザＩＤとパスワードの組み合わせを登録することで各ユーザに対応するユーザアカウントを作成する。ここで、登録されるユーザＩＤとパスワードはユーザが自分で作成してもよいし、サーバが作成してもよいが、ユーザＩＤはユーザごとに固有のものとなっており、同一のユーザＩＤを持つユーザアカウントが複数存在することはない。したがって、ユーザＩＤをユーザが自分で作成してサーバ２０へ送信する場合、そのユーザＩＤが既に登録済みのユーザアカウントのいずれかのユーザＩＤと同一である場合には、そのユーザＩＤは新規登録できないことがユーザへ通知される。

ユーザ管理部２４で管理されるユーザアカウントの情報は、図４に示すように、ユーザ別に分類して記録されている。ユーザアカウントの情報にはユーザに固有のユーザＩＤ４８と、そのユーザＩＤ４８に対応するパスワードＰＷが含まれるほか、そのユーザアカウントの種別を示す情報が含まれる。ユーザアカウントの種別とは、そのユーザアカウントがいずれかのセンサユニット３０のセンサデータへのアクセス権を有するか否か（センサデータを閲覧できるかどうか）に関わる情報であり、ユーザアカウントが後述の管理アカウント（ＭＡ）または被招待アカウント（ＣＡ）である場合には、どのセンサユニット３０に対する管理アカウントまたは被招待アカウントであるのかについても記録される。また、管理アカウントについてはその管理アカウントから招待を受けた被招待アカウント（招待客）の情報が記録され、被招待アカウントについてはその被招待アカウントを招待した管理アカウント（招待主）の情報が記録される。なお、１人のユーザが特定のセンサユニット３０に対する管理アカウントであると同時に他のセンサユニット３０に対する被招待アカウントでもあったり、複数のセンサユニット３０に対する管理アカウントを兼任していたり、複数のセンサユニット３０に対して被招待アカウントになっていたりすることもある。

図５に、本実施形態において各種機器間で行われる通信の一例についてフローチャートを示す。説明の便宜上、各ステップが完了してから次のステップに進むものとしているが、いくつかのステップは並行して実行可能であり、また順番が前後することもある。２度目以降の通信においては飛ばすことが可能なステップ（「アカウント登録」ステップなど）もある。

ユーザ（図２の設置ユーザＰＵおよびサブユーザＳＵ）がセンサユニット３０のセンサデータにアクセスしようとする場合には、まずサーバ２０によって運用されているネットワークサービスにユーザアカウントを登録する作業が必要である。ユーザは自身の所有するユーザ端末４０にネットワークサービス用のアプリケーションを導入し、そのユーザ端末４０を介して各ユーザに固有のユーザＩＤおよびそのユーザＩＤに対応するパスワードをサーバ２０へ送信する。ユーザＩＤとパスワードの組み合わせを受信したサーバ２０は、ユーザＩＤが既に登録済みのユーザアカウントのユーザＩＤと重複していないかどうかを確認し、重複がなければ受信した組み合わせを含むユーザアカウントの情報をユーザ管理部２４に登録する。あるいは、ユーザがネットワークサービスへの加入申請をサーバ２０へ送信し、加入申請を受信したサーバ２０は既存のユーザＩＤと重複しないように自動生成されたユーザＩＤとパスワードの組み合わせをユーザへ通知するとともに、生成されたその組み合わせをユーザ管理部２４に登録する。こうした作業が複数のユーザに関して行われ、サーバ２０は複数のユーザのそれぞれに対応するユーザアカウントをユーザ管理部２４へ登録する（図５の「アカウント登録」ステップＳ５１）。

一方、検出対象者ＴＵの自宅に設置された複数のセンサユニット３０はそれぞれ、自身の設置されている周囲環境から検出した各種検出値と、自身のセンサＩＤを含むセンサデータをサーバ２０へ送信する（図５の「センサデータ送信」ステップＳ５２）。センサユニット３０からセンサデータを受信したサーバ２０は、センサデータに含まれるセンサＩＤを基に、センサデータをセンサユニット３０ごとに分類し、センサデータの送信された時刻も含めてセンサユニット管理部２２に記録する（図５の「センサデータ記録」ステップＳ５３）。

ユーザアカウントを持つユーザがセンサユニット３０のセンサデータにアクセスするためには、管理アカウントまたは被招待アカウントになる必要がある。ここでは図２の設置ユーザＰＵが管理アカウントになるための手順を説明する。センサユニット３０の設置を行った設置ユーザＰＵは、そのセンサユニット３０の実物に接触できる立場にあるため、図３に示されているような、センサユニット３０に直に貼り付けられた（設けられた）センサ管理符号保持具３９を確認することが可能である。よって設置ユーザＰＵは、このセンサ管理符号保持具３９に保持されているセンサ管理符号３８を、ユーザ端末４０のセンサ管理符号取得部４９を用いて取得することができる。例えばセンサ管理符号保持具３９が二次元コードの記載されたシールである場合には、設置ユーザＰＵはユーザ端末４０に搭載されている光学的入力手段（カメラなど）をセンサ管理符号取得部４９として二次元コードにかざす、などの操作を行ってユーザ端末４０の二次元コード読み取り機能を使用し、二次元コードに表されているセンサ管理符号３８を取得する。そして、取得したセンサ管理符号３８を、設置ユーザＰＵのユーザアカウントを使用してサーバ２０へ送信する（図５の「センサ管理符号送信」ステップＳ５４）。

センサ管理符号３８は、各センサユニット３０に固有のセンサＩＤを基に（暗号化やデータ圧縮などにより）生成される情報であるため、サーバ２０は、受信したセンサ管理符号３８がどのセンサユニット３０に対応するものであるかを（復号化やデータ解凍などにより）確認することができる。受信したセンサ管理符号３８がどのセンサユニット３０に対応するものであるかを確認したサーバ２０が、そのセンサ管理符号３８を送信したユーザアカウントの情報について、そのユーザアカウントは特定のセンサユニット３０の管理アカウントであるという情報をユーザ管理部２４に書き込むことにより、センサ管理符号３８を送信したユーザアカウントが管理アカウントとして登録される（図５の「管理アカウント登録」ステップＳ５５）。

次に、図２のサブユーザＳＵが被招待アカウントになるための手順を説明する。サブユーザＳＵは、管理アカウントとして登録されたユーザ（ここでは設置ユーザＰＵ）に対し、直接会って話したり、ネットワークサービス上で連絡を取ったりして、自身をネットワークサービス上で招待するように依頼する。管理アカウントとなっている設置ユーザＰＵは、信用できる（センサデータを閲覧させてもよいと判断した）サブユーザＳＵから依頼を受けた場合、あるいは依頼がなくとも自主的に特定のサブユーザＳＵを招待したいと考えた場合、ユーザ端末４０を操作して、自身の管理アカウントに対応するセンサユニット３０の被招待アカウントとしてサブユーザＳＵを招待する（図５の「招待」ステップＳ５６）。

管理アカウントを持つユーザのユーザ端末４０からサブユーザＳＵを招待する操作が行われると、サーバ２０はそのサブユーザＳＵのユーザアカウントを、操作を行った設置ユーザＰＵの管理アカウントに対応するセンサユニット３０の被招待アカウントとしてユーザ管理部２４へ登録する（図５の「被招待アカウント登録」ステップＳ５７）。

以上のようにして管理アカウント、または被招待アカウントとなったユーザは、自身のユーザアカウントに対応するセンサユニット３０のセンサデータを閲覧することが可能になる。いずれかのユーザが特定のセンサユニット３０のセンサデータを閲覧しようとする場合には、ユーザ端末４０を操作して、そのセンサユニット３０のセンサデータを閲覧することをサーバ２０へ要求する（図５の「データ要求」ステップＳ５８）。以下においては、センサデータの閲覧を要求するユーザのユーザアカウントを「要求ユーザアカウント」、センサデータの閲覧を要求されるセンサユニット３０を「被要求センサユニット」と呼ぶ。

要求ユーザアカウントからセンサデータの閲覧要求を受けたサーバ２０は、その要求ユーザアカウントのアカウント種別を識別し、要求ユーザアカウントによる被要求センサユニットのセンサデータへのアクセスが許可されるかどうかを確認する（図５の「アカウント識別」ステップＳ５９）。

図６に、「アカウント識別」ステップＳ５９についてより詳しく説明するためのフローチャートを示す。図５と同じく、いくつかのステップは並行して実行可能であり、また順番が前後することもある。まずサーバ２０は、要求ユーザアカウントのユーザＩＤをユーザ管理部２４に記録されているユーザアカウント情報の中から検索する（図６のステップＳ６１）。ユーザ管理部２４内で要求ユーザアカウントの情報を発見したら、要求ユーザアカウントのアカウント種別を確認する（図６のステップＳ６２）。

そして、サーバ２０は、被要求センサユニットのセンサＩＤと、要求ユーザアカウントがアクセス可能となっているセンサユニット３０のセンサＩＤとを照合し、要求ユーザアカウントが被要求センサユニットへのアクセス権を有するかどうかを確認する（図６のステップＳ６３）。要求ユーザアカウントが被要求センサユニットに対応する管理アカウント、または被招待アカウントである場合には、要求ユーザアカウントは被要求センサユニットのセンサデータに対するアクセス権を有していると判断し、データ要求を許可する（図６のステップＳ６４）。その後、要求ユーザアカウントのユーザ端末４０に被要求センサユニットのセンサデータを送信する（図６のステップＳ６５）。

一方、要求ユーザアカウントが管理アカウントでも被招待アカウントでもない場合、すなわち要求ユーザアカウントが管理アカウント以外のユーザアカウント（非管理アカウント）であり、かつ被招待アカウント以外のユーザアカウント（未招待アカウント）である場合には、要求ユーザアカウントは被要求センサユニットのセンサデータに対するアクセス権を有していないと判断し、データ要求を拒否する（図６のステップＳ６６）。その後、要求ユーザアカウントのユーザ端末４０にデータ要求が拒否された旨を通知する（図６のステップＳ６７）。なおステップＳ６７を省略し、要求ユーザアカウントが管理アカウントでも被招待アカウントでもないと判明した時点で要求ユーザアカウントとの通信を終了してもよい。

なお、ステップＳ６４でデータ要求を許可されてステップＳ６５で送信されたセンサデータを受信したユーザ端末４０の表示部４１には、センサユニット３０のセンサデータが表示される（図６のステップＳ６８）。ネットワークサービス用のアプリケーションを介したサーバ２０とユーザ端末４０との通信においては、ユーザ端末４０の表示部４１に表示される画面データがサーバ２０から送信される。データ要求を許可された場合、この画面データにはセンサデータが含まれることとなり、画面データに応じて、表示部４１においてセンサデータは検出値の数値をそのまま数字で示す表形式で表示されたり、時系列に沿ってプロットされた折れ線グラフなどの視覚的効果を加えた形式で表示されたりする。こうした表示形式のどれを用いるかはアプリケーション上で（操作入力部４５を介して）変更可能である。

以上の処理により、特定のセンサユニット３０が検出したセンサデータを閲覧できるユーザは、そのセンサユニット３０を実際に手に取ってセンサ管理符号保持具３９からセンサ管理符号３８を取得することが可能な立場の、管理アカウントとなれるユーザ（ここでは設置ユーザＰＵ）と、その管理アカウントを持つユーザがセンサデータを閲覧させてもよいと判断した被招待アカウントを持つユーザ（ここではサブユーザＳＵ）に限られることになる。一方、管理アカウントでも被招待アカウントでもないユーザは、センサユニット３０のセンサデータを閲覧することができないので、管理アカウントが把握していない全くの第三者がセンサユニット３０のセンサデータにアクセスして、検出対象者ＴＵのプライバシーが第三者に漏洩してしまうというセキュリティ上の問題が防がれる。

こうしたアカウントの管理について、図７に、招待の手順に関するフローチャートを示す。以下においては各ユーザのユーザアカウント登録が完了しており、またセンサユニット３０について管理アカウントが登録されているものとして説明する。

ネットワークサービス用のアプリケーションは、サーバ２０との通信により、表示部４１に表示させる画面データを受信し、画面データを基に表示部４１にセンサユニット３０のセンサデータや操作メニューを表示する。ユーザは操作入力部４５を介して表示部４１に表示される操作メニューを操作する。アプリケーションには他のユーザを招待する機能が備わっており、管理アカウントでログインしているユーザ端末４０であれば他のユーザを招待するための招待メニューが表示部４１に表示される。

管理アカウントのユーザが特定のユーザ（サブユーザＳＵなど）を招待したいと考えた場合、招待メニューから目的のユーザのアカウント宛てに（サーバ２０を介して）招待メッセージを送信する（図７のステップＳ７１）。

招待メッセージを受信したユーザは、管理アカウントからの招待を承認するか、拒否するかを選択することが可能である。ユーザが招待メッセージを承認する場合は承認メッセージが、拒否する場合は拒否メッセージがサーバ２０へ送信される（図７のステップＳ７２）。

サーバ２０は受信したメッセージが承認メッセージか拒否メッセージかを確認し（図７のステップＳ７３）、受信したメッセージが承認メッセージであるならば、その承認メッセージを送信したユーザを、被招待アカウントとして登録する（図７のステップＳ７４）。つまり、承認メッセージを送信したユーザについて、招待メッセージを送信した管理アカウントに対応するセンサユニット３０の被招待アカウントとして、ユーザ管理部２４に記録されているユーザアカウントの情報を更新する。このとき、被招待アカウントの情報には管理アカウントが招待主であることが記録されるとともに、管理アカウントにとっては被招待アカウントが招待客であることが記録される。また、管理アカウントには招待が承認されたことを知らせる通知が送られる。

一方、サーバ２０が受信したメッセージが拒否メッセージであった場合は、管理アカウントには招待が拒否されたことを知らせる通知が送られ（図７のステップＳ７５）、招待メッセージを受信していたユーザは未招待アカウントのままとされる。

なお、特定のユーザが被招待アカウントとなった後でも、その被招待アカウント自身、および招待主の管理アカウントは被招待アカウントを未招待アカウントに変更することが可能である。図８に、こうしたアカウント種別変更の手順に関するフローチャートを示す。被招待アカウントおよびその招待主の管理アカウントは操作メニューの中から招待解除メニューを利用可能になっている。被招待アカウントおよびその招待主の管理アカウントのユーザが、この招待解除メニューを操作して、特定の被招待アカウントの招待を解除する（図８のステップＳ８１）と、ユーザ管理部２４に記録されているアカウント情報において、被招待アカウントは未招待アカウントに変更されて、センサユニット３０のセンサデータを閲覧することができなくなる（図８のステップＳ８２）。

また管理アカウントは自分自身を非管理アカウントに変更することが可能である。設置ユーザＰＵがセンサユニット３０を撤去する場合など、ユーザがセンサユニット３０の管理アカウントである必要がなくなる場合にこの機能が利用される。管理アカウントは操作メニューの中から管理辞退メニューを利用可能になっている。この管理辞退メニューを管理アカウントが操作する（図８のステップＳ８３）と、管理アカウントは非管理アカウントに変更される（図８のステップＳ８４）。そして、管理アカウントが非管理アカウントに変更されると、サーバ２０はユーザ管理部２４の中から、その管理アカウントが招待主となっていた被招待アカウント（管理アカウントの招待客）を検索し、それらの被招待アカウントを全て未招待アカウントに変更する（図８のステップＳ８５）。これにより、管理アカウントを辞退したユーザ、およびそのユーザが招待していた被招待アカウントは全てセンサユニット３０のセンサデータを閲覧することができなくなるため、そのセンサユニット３０に新しく管理アカウントが設定されるときに、新しい管理アカウントが把握していない被招待アカウントは存在しないことになる。そのため、「知らない人物がセンサユニット３０のセンサデータにアクセス可能なっている」といったセキュリティ上の問題が防がれる。

なお、上記の実施形態においては、設置ユーザＰＵが管理アカウントになる場合について説明したが、設置ユーザＰＵでなくとも、例えば検出対象者ＴＵと同居している家族などが管理アカウントになることもできる。センサユニット３０に機械的に取り付けられているセンサ管理符号保持具３９からセンサ管理符号３８を取得できるユーザ、すなわち検出対象者ＴＵの自宅に出入りできてセンサユニット３０に直接接触できる立場のユーザであれば管理アカウントになることができる。ただし、セキュリティ上の観点から、管理アカウントは排他的（１つのセンサユニット３０につき１人）であることが好ましく、既に管理アカウントが登録されているセンサユニット３０については、他のユーザアカウントがセンサ管理符号３８をサーバ２０へ送信しても管理アカウントにはなれないようになっているとよい。

また、上記の実施形態においては、センサユニット３０が検出したセンサデータは定期的にサーバ２０へ送信されるものとしたが、これとは別に、図３に示す手動操作部３５が操作された場合には、センサユニット３０はその時点でのセンサデータをサーバ２０へ送信するようになっているとよい。このとき、サーバ２０へ送信される情報にはセンサデータの他に、手動操作が行われたことを示す手動操作符号（手動操作フラグ）が含まれており、この手動操作符号と共にセンサデータを受信したサーバ２０は、そのセンサユニット３０に対応する管理アカウントや被招待アカウントのユーザに対し、手動操作が発生したことを示す通知を行う。例えば検出対象者ＴＵが体調不良の場合や、災害が発生した場合など、早急に設置ユーザＰＵやサブユーザＳＵに危機を知らせたい場合には、手動操作部３５のボタンを押すことで即座に設置ユーザＰＵやサブユーザＳＵへの通知を行うことができる。また設置ユーザＰＵは検出対象者ＴＵと同居しているとは限らず、設置ユーザＰＵは検出対象者ＴＵの住居にセンサユニット３０を設置する場合、設置ユーザＰＵのユーザ端末４０で正常にセンサデータが表示されるかどうかの動作確認を即座に行いたいことが多々ある。このような場合にも手動操作は有益であり、手動操作を行えば即座の動作確認が可能となる。なお普段の生活において偶発的に手動操作部３５が操作されてしまうことがないように、手動操作部３５は、狭く深い窪みの底に配置されていて細長い棒を使用しなければ押せないボタンなどの、意図的でなければ操作できない形態になっているのが好ましい。

また、上記の実施形態においては、サーバ２０はセンサユニット３０から受信したセンサデータを特に加工せず時系列順に整理して蓄積するのみとしているが、この蓄積されたセンサデータについて統計処理が行われてもよい。例えばセンサユニット３０ごとに日中の温度の平均値を算出したり、人感センサの反応頻度を時間帯ごとに集計したりして統計データを算出し、その統計データをセンサユニット３０ごとに記録しておく。そしてこの統計データについてもユーザが閲覧できるようにしておくことで、ユーザは検出対象者ＴＵの生活パターンをより把握しやすくなる。また、統計データの算出が行われる場合、センサユニット３０から受信した最新のセンサデータが普段の統計データからかけ離れている場合には異常が発生しているとサーバ２０が判断するようにしてもよい。例えば、あるセンサユニット３０について、過去一週間の正午の温度の平均値が２０℃である場合に、８０℃を示すセンサデータを受信したときには、検出対象者ＴＵの自宅に火事などの高熱を伴う異常事態が発生していると考えられるので、そのセンサユニット３０に対応する管理アカウントや被招待アカウントのユーザに対して異常発生の通知を行う。なお、統計処理を行わない場合でも、センサデータに基づいてサーバ２０が異常発生の判断を行うことは可能である。例えば各種検出値に閾値（例えば温度について５０℃、など）が設定されており、その閾値をまたぐ検出値を示すセンサデータがセンサユニット３０から送信された場合にはサーバ２０が無条件で異常発生と判断するように設計されていれば、統計データの算出とは独立して異常発生の判断が行われる。この閾値は、管理アカウントや被招待アカウントがアプリケーションを介して設定できるようになっていてもよい。

また、サーバ２０は各センサユニット３０の管理アカウントや被招待アカウントに対して、上述の手動操作発生や異常発生の通知のほか、センサユニット３０の状態について様々な通知を行うことができる。例えば、定期的なセンサデータの送信が行われたことを管理アカウント、被招待アカウントへ通知することもできる。ただしこうした通知は重要性が低いものもある。また被招待アカウントのユーザは検出対象者ＴＵとそれほど関わりが深くない場合もあるので、異常発生の通知であっても、被招待アカウントに対しては直ちに知らせるべきというほどに緊急性が高くないこともある。そこで、各ユーザアカウント、特に被招待アカウントについては、サーバ２０からの通知について、どのような形態で受信するかを選択することができる。例えばユーザ端末４０が携帯電話である場合には、サーバ２０からの通知をプッシュ通知で受け取るか、電子メールで受け取るか、（機械音声の）電話で受け取るか、といった複数の受信形態から選択可能になっているとよい。またこの選択は通知の種類別に設定可能とし、異常発生の通知のみ電子メールで受け取り、他の通知はプッシュ通知で受け取る、といった使い分けが可能になっているとよい。

なお上記の実施形態においては、図１では１人の検出対象者ＴＵの自宅にはセンサユニット３０が１つのみ設置されている様子を示しているが、センサユニット３０は一軒の家屋に複数設置されてもよい。例えば人感センサ３６ｃを有するセンサユニット３０が寝室だけでなく台所にも設置されていると、ユーザは検出対象者ＴＵの就寝・起床時間だけでなく、食事時間も知ることが可能となる。この場合、設置ユーザＰＵは寝室のセンサユニット３０と台所のセンサユニット３０の両方のセンサ管理符号３８を取得して、両センサユニット３０の管理アカウントになるとよい。また、１人の設置ユーザＰＵが複数人の検出対象者ＴＵの自宅にそれぞれセンサユニット３０を設置し、１人の設置ユーザＰＵがそれらすべてのセンサユニット３０の管理アカウントになってもよい。

また上記の実施形態においては高齢者や要介護者といった検出対象者ＴＵの自宅にセンサユニット３０が設置されることを想定したが、センサユニット３０の設置箇所はこれに限るものではなく、例えば工場、事務所といった建物内に設置することで、その建物内で時間帯によって変動する温度、照度、人感を遠方から確認することが可能になる。またセンサユニット３０の設置箇所は建物内に限られず、電源が確保できるのであれば野外であっても設置可能である。またセンサユニット３０が備える各種センサは、温度センサ３２ａ、照度センサ３２ｂ、人感センサ３２ｃに限られるものではなく、センサユニット３０は周囲環境から検出すべきデータに応じて、例えば湿度センサ、気圧センサ、音響センサ、光学センサあるいは監視カメラなど、様々なセンサを有することができる。

また上記の実施形態においてはセンサ管理符号保持具３９を二次元コードとしているが、センサ管理符号保持具３９の形態は二次元コードに限られるものではなく、センサ管理符号３８の情報を保持可能で、センサユニット３０に取り付け可能であり、センサユニット３０の実物に接近できる立場の人間のみがそのセンサ管理符号３８を取得できるものであればよい。例えばセンサ管理符号保持具３９はセンサ管理符号３８を表すバーコードを記載したプレートであったり、電子的にセンサ管理符号３８のデータを保持し、接近した読み取り器によってセンサ管理符号３８のデータを読み取り可能な非接触ＩＣタグ（ＲＦＩＤチップが埋め込まれたカードなど）であったりしてもよい。

１０ 通信システム
２０ サーバ
２２ センサユニット管理部
２４ ユーザ管理部
２６ サーバ送受信部
３０ センサユニット
３２ センサ部
３３ 動作状態表示部
３５ 手動操作部
３６ センサ送受信部
３７ 電源ケーブル
３８ センサ管理符号
３９ センサ管理符号保持具
４０ ユーザ端末
４１ 表示部
４５ 操作入力部
４６ ユーザ送受信部
４８ ユーザＩＤ
４９ センサ管理符号取得部
ＴＵ 検出対象者
ＰＵ 設置ユーザ
ＳＵ サブユーザ

Claims (5)

1. サーバ上のデータに複数のユーザがアクセスすることを可能とする通信システムであって、
   前記サーバは、複数のセンサユニットの情報を管理するセンサユニット管理部と、前記ユーザのそれぞれに対応するユーザアカウントを管理するユーザ管理部と、を備え、
   前記センサユニットは、自身の設置されている周囲環境から検出したセンサデータを前記サーバへ送信し、
   前記センサユニット管理部は、前記センサユニットのそれぞれから受信した前記センサデータを、各前記センサユニットごとに分類して記録し、
   前記ユーザ管理部は、前記センサユニットのそれぞれに個別に割り当てられているセンサ管理符号を前記サーバへ送信したユーザのユーザアカウントを、当該センサ管理符号に対応する前記センサユニットの管理アカウントとして登録し、また、前記管理アカウントから招待を受けたユーザアカウントを、その管理アカウントに対応する前記センサユニットの被招待アカウントとして登録し、
   前記サーバは、
   特定の被要求センサユニットのセンサデータを閲覧することを要求するデータ要求を特定の要求ユーザアカウントから受信した場合には、前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントまたは前記被招待アカウントであるかどうかを前記ユーザ管理部によって確認し、
   前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントまたは前記被招待アカウントである場合には、前記センサユニットに記録されている前記被要求センサユニットの前記センサデータを前記要求ユーザアカウントへ送信し、
   前記要求ユーザアカウントが、前記被要求センサユニットの前記管理アカウントではない非管理アカウント、かつ前記被招待アカウントではない未招待アカウントである場合には、前記データ要求を拒否し、
   前記被招待アカウントは自分自身を未招待アカウントへと変更可能であり、
   前記管理アカウントは前記被招待アカウントを未招待アカウントへと変更可能であり、また前記管理アカウントは自分自身を非管理アカウントへと変更可能であり、前記管理アカウントが非管理アカウントに変更された場合には、当該管理アカウントから招待を受けていた被招待アカウントは全て未招待アカウントへと変更されること
   を特徴とする通信システム。
2. 前記センサユニットのそれぞれは、定期的に現時点における前記センサデータを前記サーバへ送信し、
   前記サーバの前記センサユニット管理部は、前記センサユニットのそれぞれから受信した前記センサデータを、前記センサユニットごとに分類かつ時系列順に整理して蓄積すること
   を特徴とする請求項１に記載の通信システム。
3. 前記サーバは、蓄積した前記センサデータに基づいて統計処理を行うことで算出した統計データを前記センサユニットごとに記録すること
   を特徴とする請求項１または請求項２に記載の通信システム。
4. 前記サーバは、前記センサデータに基づいて、いずれかの前記センサユニットに異常が発生しているか否かの判断を行い、異常が発生している前記センサユニットに対応する前記管理アカウントおよび／または前記被招待アカウントに対して、異常発生の通知が前記サーバから行われること
   を特徴とする請求項１ないし請求項３のいずれか１項に記載の通信システム。
5. 前記被招待アカウントは、前記サーバからの通知の受信形態を複数の形態から選択可能であること
   を特徴とする請求項１ないし請求項４のいずれか１項に記載の通信システム。
   

Images