JP5606512B2 - サーバ装置及びプログラム - Google Patents

Description

この発明は、緊急時などに情報の共有を行うためのサーバ装置及びプログラムに関する。

緊急時の慌てているときや余裕がないときに、離れている相手（情報端末を含む）と円滑な情報共有を可能とする操作インタフェースが求められている。例えば、災害直後の知り合いとの安否確認、待ち合わせ時間間近の現在地確認、事故発生直後の１１９番通報時のオペレータとの状況確認などがある。

しかしながら、平常状態であれば、相手とのやり取りを繰り返しながら、お互いの情報を確認しあうことが可能となるが、緊急時においては、お互いの情報を確認しあう時間も気持ちの余裕もなく、各自がほしい情報の要求のみを行う傾向がある。その結果、返答するのに必要な要求してきた相手の自己ＰＲＯＦＩＬＥに関する情報が少ないため、要求された相手は返答できないという問題が生じる。

例えば、災害時に使用される安否確認システムにおいて、各自が知り合いの安否状況の返答をシステムに要求するが、各自が安否登録をしないため、安否確認システムを利用しても安否確認できないという問題があった（非特許文献１を参照）。

嵯峨田良江、朝井大介、大野健彦、浅野陽子、「大災害時にはどのような情報が必要か―被災者インタビューに基づく情報伝達の解明―」、情報処理学会研究報告、情報処理学会ヒューマンコンピュータインタラクション研究会

ところが、上記の問題に対して従来の安否確認システムでは入力作業に手間がかかり、かつユーザが自己安否を登録しない限り、安否システムに自分の安否が登録されない。同様に、お互いの現在地を確認する場合でも、相手に現在地を要求する一方で自分の現在地を送信しないため、お互いの現在地確認に何度も連絡することが必要となる。また、事故発生後の１１９番通報時に事故発生時の対策を要求するが、オペレータは事故状況を把握するために、繰り返しのコミュニケーションが必要となる。

この発明は上記事情に着目してなされたもので、その目的とするところは、簡易な操作により円滑な情報共有を可能とするサーバ装置及びプログラムを提供することにある。

上記目的を達成するためにこの発明の第１の態様は、要求元から要求先への要求と前記要求に該当する要求カテゴリと前記要求に関連する要求元ユーザの関連情報とを含む要求データを受信する受信手段と、前記要求データに含まれる関連情報を前記要求カテゴリに対応付けてデータベースに登録する登録手段と、前記要求を前記要求先に送信する送信手段とを具備し、前記送信手段は、前記要求先から前記要求元へすでに同一の要求カテゴリの要求がされている場合に、前記要求と前記データベースに登録された前記要求元ユーザの関連情報とを前記要求先へ送信し、前記要求先から前記要求元へ同じ要求がされていない場合は、前記要求のみを前記要求先へ送信するものである。

第１の態様によれば、例えば、お互いの現在地を確認する場合において、要求先への現在地確認要求と共に要求元ユーザの現在地等を自動的に要求先に送信することが可能となる。このようにすることで、何度も繰り返し連絡する必要がなくなるため、緊急時で余裕がない状況下において、情報共有するコミュニケーション時間を短縮することができる。また、要求先と要求元がお互いに同じ要求カテゴリの情報を要求した場合には、登録していた情報をお互いに開示してよい情報と判断し、それ以外の要求の場合は勝手に情報を開示しない。これにより、プライバシーを保護することができる。

本発明の第２の態様は、要求元から要求先への要求と前記要求に関連する要求元ユーザの関連情報とを含む要求データを受信する受信手段と、前記要求データに含まれる関連情報を前記要求に該当する要求カテゴリに対応付けてデータベースに登録する登録手段と、前記データベースに前記要求に該当する要求カテゴリに対応する前記要求先ユーザの関連情報が登録されているか否かに基づいて、前記要求に対する返答を前記要求元に行う返答手段とを具備するサーバ装置を提供する。

第２の態様によれば、例えば、お互いの安否を確認する場合において、要求先からすでに要求を受信している場合には、当該要求先は安否が確認できたものと要求元に返答することが可能となる。また、要求先から要求を受信した場合に、要求元に安否が確認できたものと通知することが可能となる。このようにすることで、何度も繰り返し連絡する必要がなくなるため、緊急時で余裕がない状況下において、所望の情報を短時間で共有することができる。

すなわちこの発明によれば、簡易な操作により円滑な情報共有を可能とするサーバ装置及びプログラムを提供することができる。

本発明の一実施形態に係る情報共有システムの構成例を示す図。 本発明の一実施形態に係る情報共有システムの他の構成例を示す図。 端末側の要求送信処理部の処理内容を示すフローチャート。 端末ＤＢの構成例を示す図。 合成したデータのフォーマットの一例を示す図。 クラウドサーバ側の処理内容を示すフローチャート。 クラウドサーバ側の処理内容の他の例を示すフローチャート。 クラウドＤＢの登録内容を示す図。 実施例１の安否確認システムを示す図。 実施例１のクラウドサーバ側の処理内容を示すフローチャート。 実施例２のクラウドサーバ側の開示要求処理を示すフローチャート。 実施例３のクラウドサーバ側の処理内容を示すフローチャート。 実施例４の端末側の要求送信処理部の処理内容を示すフローチャート。

以下、図面を参照してこの発明に係る実施形態を説明する。
図１は、本発明の一実施形態に係る情報共有システムの構成例を示す図である。この情報共有システム構成は、要求元の端末１−Ａと、端末１−Ａからの要求を受ける端末１−Ｂと、要求元の端末１−Ａと要求を受ける端末１−Ｂとの仲介となるクラウドサーバ２で構成される。端末１−Ａ，１−Ｂは、例えば、インターネットに接続可能なスマートフォン等で構成され、タッチスクリーンや操作ボタン等により要求を入力する入力処理部１１、入力処理部１１により入力された要求と当該要求に関連する自己ＰＲＯＦＩＬＥとを含む要求データをクラウドサーバ２へ送信する端末側の要求送信処理部１２、クラウドサーバ２から送られてくる要求に対する返答を受信する端末側の要求受信処理部１３、および受信した返答を画面に表示する表示処理部１４を有する。なお、自己ＰＲＯＦＩＬＥとは当該端末を所有するユーザに関連する情報群を指す。

クラウドサーバ２は、電子計算機（図示せず）とクラウドデータベース（クラウドＤＢ）２０を有し、端末から送られてくる要求データを受信するサーバ側の要求受信処理部２１、要求データに含まれる自己ＰＲＯＦＩＬＥをクラウドＤＢ２０に登録する自己ＰＲＯＦＩＬＥ処理部２２、要求に対する返答を端末に送信するサーバ側から要求送信端末への要求返答処理部２３、および上記受信した要求を要求相手先端末へ送信するサーバ側から要求相手先端末への要求送信処理部２４を有する。

なお、各処理部は、例えば、端末１−Ａ，１−Ｂおよびクラウドサーバ２でそれぞれ実行される制御プログラムで構成される。また、図２に示すように要求を受ける端末とクラウドサーバ２が同一の場合もある。これらの構成はアプリケーションに依存して任意に選択される。

図３は、端末側の要求送信処理部の処理内容を示すフローチャートである。要求元端末１−Ａの端末側の要求送信処理部１２は、利用者から送られてくる要求を受信するのを待つ（処理２００）。要求を受信した場合は、要求に関連する自己ＰＲＯＦＩＬＥを端末１−Ａ内から抽出する（処理２０１）。抽出する方法を以下に説明する。端末１−Ａは、図４に示すように、要求カテゴリに対応した自己ＰＲＯＦＩＬＥを格納した端末ＤＢを有する。例えば、要求カテゴリ“安否”に関連する自己ＰＲＯＦＩＬＥは“要求時刻、ＧＰＳで取得可能な位置情報”とする。端末側の要求送信処理部１２は、要求の内容から要求カテゴリを判別し、判別された要求カテゴリに対応する自己ＰＲＯＦＩＬＥを端末ＤＢから抽出する。要求カテゴリの判別方法は、例えば、端末１−Ａの画面上に表示されるボタンに前もって要求カテゴリを設定させておき、利用者がこのボタンを押下したときに、要求カテゴリを送信する方法がある。もしくは、要求の内容をテキストマイニングし、抽出された単語から要求カテゴリを判別する方法がある。

そして、処理２０２にて要求と要求カテゴリ（図４参照）と要求に対応する自己ＰＲＯＦＩＬＥを１つのデータとして合成する。合成するときには、図５に示すようなタグ形式で表される１組のデータとする。要求は<demand>タグに記述し、要求カテゴリは<dcategory>タグに記述し、自己ＰＲＯＦＩＬＥは<sprofile>タグに記述する。端末側の要求送信処理部１２は、合成されたデータをクラウドサーバ２に相手先（端末１−Ｂ）を特定する情報とともに送信する（処理２０３）。

次に、図６、７のフローチャートを用いて、クラウドサーバ側の処理内容について説明する。図６の処理３００において、クラウドサーバ２のサーバ側の要求受信処理部２１は、要求元から送られてくる要求データを受信したかどうかを判断する。要求データを受信した場合は、自己ＰＲＯＦＩＬＥ処理部２２は、要求データ内に自己ＰＲＯＦＩＬＥがあるかどうかを処理３０１にてチェックする。自己ＰＲＯＦＩＬＥの有無は<dcategory>の有無によって判断される。自己ＰＲＯＦＩＬＥがある場合は、処理３０２にて自己ＰＲＯＦＩＬＥを切り取り、処理３０３にて要求カテゴリと自己ＰＲＯＦＩＬＥデータを要求時刻、要求元の電話番号、要求先の電話番号に対応付けてクラウドＤＢ２０に登録する。図８に、クラウドＤＢ２０に登録される内容を示す。要求は、処理３０４において、クラウドサーバ２のサーバ側から要求相手先端末への要求送信処理部２４によって要求相手先（端末１−Ｂ）に送信される。なお、図２のように要求を受ける端末とクラウドサーバ２が同一の場合は、図７に示すように処理３１０にて、サーバ側から要求送信端末への要求返答処理部２３は、要求元（端末１−Ａ）に要求に対する返答を送信する。

このようにすることにより、要求先への要求の送信の際に、要求元ユーザによる追加の操作無しで自己ＰＲＯＦＩＬＥが送信がされるので、コミュニケーションに必要な情報がクラウドサーバに自動的に蓄積される。この蓄積された情報を利用してクラウドサーバが情報を提示する、もしくは蓄積された情報を開示することで緊急時のコミュニケーションを円滑にすることが可能となる。以下、上記情報共有システムを具体的なシステムに応用した各実施例について説明する。

（実施例１：安否確認システム）
実施例１の安否確認システムは、図２のシステム構成となる。実施例１では、図９に示すように、ユーザＡとユーザＢが知り合いでお互いに安否確認するシーンを想定する。災害の発生時間を１６時としたときに、１７時にユーザＡがユーザＢの安否状況の返答要求を行う。返答要求の送信方法はスマートフォン等に表示されたアドレス帳のユーザＣの項目に安否ボタンがあり、そのボタンを押下する。

安否ボタンが押下されると、ユーザＡの端末１−Ａでは上記図３の処理が動作する。処理２００にて要求の有無を確認し、要求があった場合は処理２０１に遷移する。処理２０１では要求を分析し、要求に関連する自己ＰＲＯＦＩＬＥ を抽出する。ここでは、安否要求の要求として「ユーザＣは無事ですか？」に対してユーザＡの要求カテゴリと自己ＰＲＯＦＩＬＥ（ここでは、要求時の現在位置と時刻）を抽出する。要求時の現在地はＧＰＳセンサなどで位置把握する。端末１−Ａは、処理２０２にて、要求と抽出された自己ＰＲＯＦＩＬＥを合成し、処理２０３にて安否確認用のクラウドサーバ２に送信する。

図１０は、実施例１のクラウドサーバ側の処理内容を示すフローチャートである。図１０は、図７の処理３１０の要求元端末への返答処理の詳細を処理３１１〜３１５に示したものである。図１０の処理３００において、クラウドサーバ２は要求データを受信すると、要求データ内に自己ＰＲＯＦＩＬＥがあるかどうかを処理３０１にてチェックする。自己ＰＲＯＦＩＬＥがある場合は、処理３０２にて要求に付加された自己ＰＲＯＦＩＬＥを切り取り、要求元の電話番号、要求先の電話番号に対応して自己ＰＲＯＦＩＬＥをクラウドＤＢ２０に登録する（処理３０３）。そして、処理３１１にてクラウドＤＢ２０に安否確認先（ユーザＣ）の自己ＰＲＯＦＩＬＥが登録されているか否に基づいて、要求元（ユーザＡ）に返答を送信する。この場合、ユーザＣの自己ＰＲＯＦＩＬＥはクラウドＤＢ２０に未だ登録されていないので、この場合の要求元（ユーザＡ）への返答メッセージは「ユーザＣの安否不明」となる（処理３１２）。

次に、時刻１８時にユーザＣがユーザＡの安否確認のメッセージをクラウドサーバ２に送信したとものする。クラウドサーバ２は、ユーザＡの場合と同様に、ユーザＣの要求カテゴリと要求データを要求元の電話番号、要求先の電話番号に対応させて登録する（処理３０３）。このとき、処理３１１において、クラウドサーバ２にはユーザＡがユーザＣに対して安否確認要求したときの情報が登録されているので、クラウドサーバはこの登録された情報に基づいてユーザＡの安否情報を作成し、ユーザＣには安否確認クラウドサーバ２から「ユーザＡは１７時に安否確認できました」というメッセージを送信する（処理３１３）。

さらに、図１０では、処理３１４，３１５にて、クラウドサーバ２がすでに安否確認先のユーザＡに対し、ユーザＣの安否状態を「安否不明」と送信していた場合は、ユーザＣの安否を確認できたことを通知するメッセージ「安否確認できました」を送信する機能を追加する。ユーザＡの安否要求時に安否確認の相手（ユーザＣ）がクラウドＤＢ２０に登録されているので、処理３１３でサーバ側から要求送信端末への要求返答処理部２３がユーザＣに返答すると共に、要求相手先端末への要求送信処理部２４は、ユーザＣからユーザＡへの安否確認時にクラウドＤＢ２０に登録した情報に基づいてユーザＣの安否情報を作成し、ユーザＡに安否確認がとれたことを通知することができる（処理３１５）。
以上のことから、実施例１によれば、安否確認システムとして機能する情報を各ユーザの手間なく収集し、各ユーザが短時間で安否確認する目的を達成できるシステムを実現できる。

（実施例２：避難所の人と遠方の医者との健康確認システム）
実施例２の健康確認システムは、図１のシステム構成を用いるもので、例えば、避難所の人が端末１−Ａを使用し、遠方の医者が端末１−Ｂを使用するものとする。災害時の避難所生活において、自身の健康状態を把握するためにセルフアセスメントシートがあり、日々セルフアセスメントシートを用いて健康状態を把握することができる。また、お薬手帳から医療機関や薬局にて調剤された薬の履歴をもとに病歴や病状を推測することができる。避難所の中で体調を崩した人が遠方の医者とコミュニケーションを取る際に、医者側は短時間で正確に対策を助言できることが好ましい。このとき、体調を崩した人から医者側への要求は、例えば「体調を崩しています。どのように対応すればよいですか？」となる。この要求に対して、端末１−Ａは日々の健康状態を記録したセルフアセスメントシートやお薬手帳など（以後、健康ライフログと呼ぶ）を要求と同時にクラウドサーバ２のクラウドＤＢ２０に登録する。医者側の端末１−Ｂからは、体調を崩した人に対してクラウドサーバ２内の健康ライフログの開示を求めることができ、体調を崩した人が開示を承認した場合にのみ、医者がそのクラウドＤＢ２０の情報を閲覧できるようになる。

図１１のフローチャートに、クラウドサーバ側の開示要求処理を示す。処理４００において、クラウドサーバ２は、例えば端末１−Ｂから開示要求が有ると、処理４０１にて開示要求先（端末１−Ａ）に開示の許可申請依頼を送信する。処理４０２にて端末１−Ａから開示許可の返答が有ると、処理４０３で開示許可の返答である場合には、開示要求先（端末１−Ｂ）にクラウドＤＢ２０に登録されたセルフアセスメントシートの情報を開示する（処理４０４）。一方、処理４０３で開示不許可の返答である場合には、開示要求先（端末１−Ｂ）に拒絶の返答を行う（処理４０５）。

（実施例３：待ち合わせ時間間近の現在位置確認システム）
実施例３の待ち合わせ時間間近の現在位置確認システムは、図１のシステム構成となる。ユーザＡとユーザＢが待ち合わせ時間間近にお互いの現在位置を確認するシーンを想定する。例えば、ユーザＡからユーザＢへの要求としては「ユーザＢはどこにいますか」となる。この要求に対する自己ＰＲＯＦＩＬＥとして、ユーザＡの要求時刻、現在位置を抽出し、要求と同時にクラウドサーバに送信する。

図１２のフローチャートに、実施例３のクラウドサーバ側の処理内容を示す。図１２の処理３００において、クラウドサーバ２は、処理３００においてユーザＡの端末１−Ａから上記要求データを受信すると、要求データに含まれる自己ＰＲＯＦＩＬＥ（要求時刻、現在位置）を切り取り（処理３０１，３０２）、ユーザＡの要求元の電話番号、要求先の電話番号に対応させて要求カテゴリ（ここでは、現在位置）に対応付けて要求時刻と現在位置をクラウドＤＢ２０に登録する（処理３０３）。このとき、要求先（ユーザＢ）の端末１−Ｂから要求元（ユーザＡ）へ同じ要求がされていないため、クラウドサーバ２は、要求先（ユーザＢ）の端末１−Ｂには要求のみを送信する（処理３２２）。

一方、この要求を受信したユーザＢが返答として、ユーザＡに同じ要求カテゴリの情報を要求した場合は、処理３２１にて、要求先（ユーザＡ）がすでに要求元（ユーザＢ）に同じ要求をしているため、要求先（ユーザＡ）に要求と要求に関連した情報（ユーザＢの現在位置）を送信する（処理３２３）。

すなわち、実施例３では、クラウドサーバはお互いに同じ要求カテゴリの情報を要求した場合には、登録していた情報をお互いに開示してよい情報と判断し、それ以外の要求の場合は勝手に情報を開示しない。これにより、プライバシーを保護することができる。

（実施例４：コンテナを用いた自己ＰＲＯＦＩＬＥ処理）
災害時に自端末の紛失、バッテリー切れ、持出忘れなどで自端末が利用できず、他人の端末を利用して上記実施形態のことを行いたいとき、自己ＰＲＯＦＩＬＥが登録されたカード等（コンテナ）を利用する。このカードはＮＦＣ（Near Field Communication）が搭載されており、カードを他人の端末にかざすことで、無線通信によりカードに登録された自己ＰＲＯＦＩＬＥを利用できるようにしたものである。この実施例４は、図２のシステム構成とする。なお、コンテナは、ＮＦＣカードに限らず、端末に着脱可能なメモリカードやＵＳＢメモリ等の可搬型の記憶媒体であればよい。

図１３は、実施例４の端末側の要求送信処理を示すフローチャートである。図１３は、図３のフローチャートに、処理２１１と処理２１２を追加したものである。処理２００にて利用者からの要求が有ると、処理２１１にてコンテナの有無を確認する。処理２１１にてコンテナが有る場合は、コンテナから要求に関連する自己ＰＲＯＦＩＬＥを抽出する（処理２１２）。そして、要求とコンテナから抽出した要求に関連する自己ＰＲＯＦＩＬＥを合成し（処理２０２）、合成したデータをクラウドサーバ２に送信する（処理２０３）。

なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１−Ａ，１−Ｂ…端末、２…クラウドサーバ、２０…クラウドＤＢ、１１…入力処理部、１２…端末側の要求送信処理部、１３…端末側の要求受信処理部、１４…表示処理部、２１…サーバ側の要求受信処理部、２２…自己ＰＲＯＦＩＬＥ処理部、２３…サーバ側から要求送信端末への要求返答処理部、２４…サーバ側から要求相手先端末への要求送信処理部。

Claims (3)

1. 要求元から要求先への要求と前記要求に該当する要求カテゴリと前記要求に関連する要求元ユーザの関連情報とを含む要求データを受信する受信手段と、
   前記要求データに含まれる関連情報を前記要求カテゴリに対応付けてデータベースに登録する登録手段と、
   前記要求を前記要求先に送信する送信手段と
   を具備し、
   前記送信手段は、前記要求先から前記要求元へすでに同一の要求カテゴリの要求がされている場合に、前記要求と前記データベースに登録された前記要求元ユーザの関連情報とを前記要求先へ送信し、前記要求先から前記要求元へ同じ要求がされていない場合は、前記要求のみを前記要求先へ送信する
   ことを特徴とするサーバ装置。
2. 要求元から要求先への要求と前記要求に関連する要求元ユーザの関連情報とを含む要求データを受信する受信手段と、
   前記要求データに含まれる関連情報を前記要求に該当する要求カテゴリに対応付けてデータベースに登録する登録手段と、
   前記データベースに前記要求に該当する要求カテゴリに対応する前記要求先ユーザの関連情報が登録されているか否かに基づいて、前記要求に対する返答を前記要求元に行う返答手段と
   を具備することを特徴とするサーバ装置。
3. 請求項１又は２に記載のサーバ装置を構成する各手段としてコンピュータを機能させるプログラム。

Images