特許 7606284 サーバのプログラム、情報処理方法、サーバ、および、端末のプログラム、情報処理方法、端末

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-17

(45)【発行日】2024-12-25

(54)【発明の名称】サーバのプログラム、情報処理方法、サーバ、および、端末のプログラム、情報処理方法、端末

(51)【国際特許分類】

   G16H 20/10 20180101AFI20241218BHJP

   G16H 40/00 20180101ALI20241218BHJP

【ＦＩ】

G16H20/10

G16H40/00

【請求項の数】 8

(21)【出願番号】P 2020082556

(22)【出願日】2020-05-08

(65)【公開番号】P2021177330

(43)【公開日】2021-11-11

【審査請求日】2023-04-24

(73)【特許権者】

【識別番号】500257300

【氏名又は名称】ＬＩＮＥヤフー株式会社

(74)【代理人】

【識別番号】110001759

【氏名又は名称】弁理士法人よつ葉国際特許事務所

(74)【代理人】

【識別番号】100093687

【弁理士】

【氏名又は名称】富崎 元成

(74)【代理人】

【識別番号】100168468

【弁理士】

【氏名又は名称】富崎 曜

(74)【代理人】

【識別番号】100166176

【弁理士】

【氏名又は名称】加美山 豊

(72)【発明者】

【氏名】濱窄 亮介

【審査官】吉田 誠

(56)【参考文献】

【文献】特開２０１９－００３５７０（ＪＰ，Ａ）

【文献】特開２０１９－１９３７９７（ＪＰ，Ａ）

【文献】特開２０１３－１１４３１５（ＪＰ，Ａ）

【文献】特開２００５－３０１７４１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００ － ８０／００

Ｇ０６Ｑ ３０／０２０７

(57)【特許請求の範囲】

【請求項1】

端末と通信するサーバによって実行されるプログラムであって、
前記端末から前記端末のユーザによる服薬に関する服薬情報を、前記サーバの通信部に よって受信することと、
前記服薬情報に基づいて、前記ユーザが所定条件を満たしたことを前記サーバの制御部によって特定することと、
前記ユーザが前記所定条件を満たしたことに基づいて、前記ユーザに対する対価に関する対価情報を前記通信部によって前記端末に送信することと、
前記端末から余った薬剤を示す残余情報を前記通信部によって受信することと、
前記残余情報に基づいて、薬剤の処分方法を前記制御部によって決定することと、
前記処分方法を示す第１情報を、前記通信部によって前記端末に送信することとが前記サーバによって実行される。

【請求項2】

請求項１に記載のプログラムであって、
前記服薬情報に基づいて、前記ユーザに対応するスコアを前記制御部によって決定することと、
前記スコアに基づいて、前記対価を前記制御部によって決定することと、
前記対価に基づく対価情報を前記通信部によって前記端末に送信することが前記サーバ によって実行される。

【請求項3】

請求項２に記載のプログラムであって、
前記服薬情報は、少なくとも、前記ユーザが服薬した薬剤を示す薬剤情報と、服薬した服薬量と、服薬したタイミングを示す服用タイミングのうちのいずれか一つを含む。

【請求項4】

請求項３に記載のプログラムであって、
前記スコアは、前記服薬情報に基づく薬剤と、薬剤の服薬量と、薬剤の服用タイミングとに基づいて決定される。

【請求項5】

請求項３または請求項４に記載のプログラムであって、
前記薬剤情報は、前記ユーザが服薬した薬剤の画像データ、前記ユーザが服薬した薬剤 を示す識別情報、薬剤に設けられる発信装置が前記薬剤を開封した際に発する電波信号の うちの、少なくともいずれか一つに基づく情報を含む。

【請求項6】

請求項１から請求項５のいずれか一項に記載のプログラムであって、
前記対価情報は、前記ユーザが加入する保険の料金を示す保険料、前記ユーザが利用する施設を利用するための料金を示す利用料、前記ユーザが購買する物品の料金を示す購買 料、のうちのいずれかに関する情報である。

【請求項7】

端末と通信するサーバの情報処理方法であって、
前記端末から前記端末のユーザによる服薬に関する服薬情報を、前記サーバの通信部に よって受信することと、
前記服薬情報に基づいて、前記ユーザが所定条件を満たしたことを前記サーバの制御部によって特定することと、
前記ユーザが前記所定条件を満たしたことに基づいて、前記ユーザに対する対価に関する対価情報を前記通信部によって前記端末に送信することと、
前記端末から余った薬剤を示す残余情報を前記通信部によって受信することと、
前記残余情報に基づいて、薬剤の処分方法を前記制御部によって決定することと、
前記処分方法を示す第１情報を、前記通信部によって前記端末に送信することとを含む。

【請求項8】

端末と通信するサーバであって、
前記端末から、前記端末のユーザによる服薬に関する服薬情報と、余った薬剤を示す残余情報とを受信する通信部と、
前記服薬情報に基づいて、前記ユーザが所定条件を満たしたことを特定し、前記ユーザが前記所定条件を満たしたことに基づいて、前記ユーザに対する対価に関する対価情報を前記通信部によって前記端末に送信する制御を行い、前記残余情報に基づいて、薬剤の処分方法を決定し、前記処分方法を示す第１情報を前記通信部によって前記端末に送信する制御を行う制御部とを備える。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、サーバのプログラム、情報処理方法、サーバおよび端末のプログラム、情報処理方法、端末に関する。

【背景技術】

【0002】

従来、傷病を負った患者には、規定の薬剤が処方される。処方された薬剤は、予め定められた用法・容量を守って服用されることが望まれる。特許文献１には、ユーザが処方された薬剤を服用したか否かを管理することができる服用管理装置が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１４－１７４７８６号公報

【発明の概要】

【0004】

本発明の第一の態様は、端末と通信するサーバによって実行されるプログラムであって、
端末から端末のユーザによる服薬に関する服薬情報を、サーバの通信部によって受信することと、服薬情報に基づいて、ユーザに対する対価に関する対価情報を通信部によって端末に送信することとがサーバによって実行される。
本発明の第二の態様は、サーバと通信する端末によって実行されるプログラムであって、端末のユーザによる服薬に関する服薬情報を、端末の通信部によってサーバに送信することと、サーバから、服薬情報に基づくユーザに対する対価に関する対価情報を、通信部によって受信することとが、端末によって実行される。
本発明の第三の態様は、端末と通信するサーバの情報処理方法であって、端末から端末のユーザによる服薬に関する服薬情報を、サーバの通信部によって受信することと、服薬情報に基づいて、ユーザに対する対価に関する対価情報を通信部によって端末に送信することとを含む。
本発明の第四の態様は、端末と通信するサーバであって、端末から端末のユーザによる服薬に関する服薬情報を受信する通信部と、服薬情報に基づいて、ユーザに対する対価に関する対価情報を通信部によって端末に送信する制御を行う制御部とを備える。
本発明の第５の態様は、端末と通信するサーバであって、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、端末から端末のユーザによる服薬に関する服薬情報を、サーバの通信部によって受信することと、服薬情報に基づいて、ユーザに対する対価に関する対価情報を通信部によって端末に送信することとを実行する。

【図面の簡単な説明】

【0005】

【図1】通信システムの構成例を示し、端末及びサーバの構成例を示すブロック図である。

【図2】実施形態に係る通信システムの概要を説明する概要図である。

【図3】ユーザの服薬情報のデータ構成例を示すデータ概念図である。

【図4】通信システムにおける各装置のやり取りの一例を示すシーケンス図である。

【図5】図４に関連する端末の動作例を示すフローチャートである。

【図6】図４に関連するサーバの動作例を示すフローチャートである。

【図7】端末の表示例を示す画面図である。

【図8】服薬情報を受信できないときのサーバの動作例を示すフローチャートである。

【図9】端末の動作例を示すフローチャートである。

【図10】端末の表示例を示す画面図である。

【図11】薬剤を誤飲したときの端末の動作例を示すフローチャートである。

【図12】端末の表示例を示す画面図である。

【図13】薬剤の処分方法に係る通信システムにおける各装置のやり取りの例を示すシーケンス図である。

【図14】薬剤処分方法を規定する処分情報のデータ構成例を示すデータ概念図である。

【図15】図１３に関連するサーバの動作例を示すフローチャートである。

【図16】図１３に関連する端末の動作例を示すフローチャートである。

【図17】端末の薬剤処分情報の表示例を示す画面図である。

【図18】通信システムにおける各装置のやり取りの一例を示すシーケンス図である

【図19】対応情報のデータ構成例を示すデータ概念図である。

【図20】図１８に関連するサーバの動作例を示すフローチャートである。

【図21】（ａ）、（ｂ）薬剤を服用するユーザに関連するユーザの端末の表示例を示す画面図である。

【図22】実施形態２に係る通信システムの構成例を示すブロック図である。

【図23】実施形態２に係る通信システムにおける各装置のやり取りの一例を示すシーケンス図である。

【図24】開封検出装置の動作例を示すフローチャートである。

【0006】

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

【0007】

本開示に係る端末による送信または受信に係る状況を確認できる表示方法等を実施するための実施形態について、図面を参照して説明する。なお、以下の実施形態は、限定ではなく例であり、本願に係る発明が以下の実施形態に限定されるものではない。

【0008】

＜システム構成＞

【0009】

図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）とが接続される。サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。

【0010】

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、端末２０がサーバ１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

【0011】

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定でなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

【0012】

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

【0013】

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザXが利用する端末を端末２０Xと表現し、ユーザXまたは端末２０Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

【0014】

サーバ１０は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定でなく例として、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

【0015】

＜ハードウェア（HW）構成＞

【0016】

図１を用いて、通信システム１に含まれる各装置のHW構成について説明する。

【0017】

（１）端末のHW構成

【0018】

端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、位置情報取得部２５を備える。端末２０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、端末２０のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２３２、カメラ２３４、位置情報取得部２５等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

【0019】

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

【0020】

入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

【0021】

入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル２３１、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ２３４（動画像を介した操作入力）、マイク２３２（音声による操作入力）を含む。

【0022】

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ２３３（音声出力）、レンズ（限定でなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

【0023】

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。

【0024】

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

【0025】

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

【0026】

制御部２１は、限定でなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

【0027】

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定でなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

【0028】

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

【0029】

マイク２３２は、音声データの入力に利用される。スピーカ２３３は、音声データの出力に利用される。カメラ２３４は、動画像データの取得に利用される。

【0030】

（２）サーバのHW構成

【0031】

サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、表示部１３を備える。サーバ１０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、サーバ１０のHWは、サーバ１０のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のHWは、表示部１３を取り外すような構成であってもよいし、そうでなくてもよい。

【0032】

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

【0033】

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

【0034】

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

【0035】

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０に送信する。また、通信Ｉ／Ｆ１４は、端末２０から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

【0036】

入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。

【0037】

表示部１３は、代表的にはモニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））で実現される。なお、表示部１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらの表示部１３は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部１３は、これらに限定されない。

【0038】

サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

【0039】

本開示の各実施形態においては、端末２０および／または、サーバ１０のＣＰＵがプログラムPを実行することにより、実現するものとして説明する。

【0040】

なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

【0041】

また、本開示の各実施形態のプログラムP(限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

【0042】

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

【0043】

サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

【0044】

また、本開示のプログラムＰＤＤは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定でなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

【0045】

また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

【0046】

サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。

【0047】

端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。

【0048】

サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。

【0049】

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

【0050】

なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。

【0051】

＜実施形態１＞
図２に示すように、本実施形態に係る通信システム１では、ユーザは自身のユーザ端末２０から、ユーザが薬剤２２０を服薬したことを示す服薬情報２２１を、サーバ１０に送信する。これによって、サーバ１０は、ユーザが実際に服薬したかどうかを管理することができる。ユーザ端末２０は、前述の通り、限定ではなく例として、ユーザの情報処理端末であるスマートフォン等により実現されてよいし、ヘッドマウントディスプレイなどで実現されてもよい。

【0052】

ここで服薬情報２２１は、ユーザ自身が打ち込んだテキスト情報であってもよいし、服用する薬剤に関する画像であってもよいし、服用する薬剤に関するコード情報であってもよい。また、服薬情報２２１は、薬包に設けられたセンサにより薬包が開封されたことを検知するセンサによるセンシングデータであってもよい。

【0053】

サーバ１０は、ユーザから服薬情報２２１を受信することで、ユーザが実際に服薬しているのか、正しい薬剤を服用しているのか、用法や容量を守っているのかを確認することができる。そして、サーバ１０は、ユーザが所定の基準を満たした場合に、ユーザに対して、対価を与える。即ち、サーバ１０は、対価の内容を示す対価情報２２２を、ユーザ端末２０に送信する。

【0054】

ここで、対価情報２２２は、ユーザが受領する対価の内容を示す情報であって、限定ではなく一例として、ユーザが加入している保険料の低減を示す情報であってもよいし、そうでなくてもよい。また、あるいは、対価情報２２２は、限定ではなく一例として、ユーザに対してユーザが利用する施設やサービス等を利用するための料金や物品を購入する際の料金を割り引くことを示す情報やクーポン情報であってもよいし、そうでなくてもよく、施設やサービスの優先的利用権を示す情報であってもよいし、そうでなくてもよい。また、対価情報２２２は、物品（限定ではなく一例として、サプリメント、健康飲料など）の贈与そのものであってもよいし、そうでなくてもよく、その物品はユーザが定期的に購入するものであってもよいし、そうでなくてもよい。また、対価情報２２２は、ユーザが加入している保険（健康保険やがん保険、生活習慣病保険など様々な保険）の適用を受けるにあたってユーザが服薬情報２２１を送信したことに伴って保険の適用を確約することを示す情報であってもよいし、そうでなくてもよい。また、対価情報２２２は、ユーザが所属する組織（限定ではなく一例として、勤務先の企業等）から受ける福利厚生の質の向上を示す情報であったり、福利厚生の適用の確約を示す情報であったりしてもよく、そうでなくてもよい。また、対価情報２２２は、限定ではなく一例として、何らかの物品そのものを送付したことを示す情報であってもよいし、そうでなくてもよい。また、対価情報２２２は、ユーザにとってマイナスになる情報であってもよい。即ち、ユーザが服薬情報を送らず薬剤を服用していないような場合にはユーザに対してペナルティとなるような内容の対価情報を送信することとしてもよい。限定ではなく一例として、対価情報２２２は、ユーザが加入している保険料が割り増し料金となったり、施設の利用料等のサービス料が通常よりも多くなったりするような内容の情報であってもよいし、そうでなくてもよい。
以下、詳細に説明する。

【0055】

（１）ユーザの端末の機能構成
図２に示すように、端末２０の制御部２１は、メッセージ処理部２１１と、表示処理部２１２と、判定部２１３と、を備える。

【0056】

メッセージ処理部２１１は、サーバ１０が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および／または通信Ｉ／Ｆ１２が受信したメッセージを含むコンテンツの入力を受け付けて、表示処理部２１２に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信Ｉ／Ｆ２２にサーバ１０に宛てて送信するように指示する。また、ここでメッセージ処理部２１１が処理する対象として、トークルームに対してユーザが入力したテキストメッセージに限らず、写真やスタンプなどを含む画像情報、音声ファイル、動画ファイル、データファイルなどを含んでよい。ここで、トークルームとは、限定ではなく一例として、サーバ１０が提供するメッセージングサービスにおいて、メッセージングサービスを利用するユーザ同士によって、送受信されたコンテンツをユーザの端末に表示可能にするユーザインターフェースである。トークルームは、チャットルームと呼称されてもよい。

【0057】

メッセージ処理部２１１は、ユーザから入力された服薬情報２２１を、通信部２２を介して、サーバ１０に送信する。端末２０から送信する服薬情報２２１には、服用した薬剤を特定可能な情報、服用した量や服用に係る用法（限定ではなく一例として、服用のタイミングや服用の方法など）を特定可能な情報のうち少なくともいずれかを含む。薬剤を特定可能な情報は、例えば、薬剤の名称や薬剤に固有の識別子である薬剤ＩＤ、薬剤を撮像した画像、薬剤に対応するコード情報（限定ではなく一例として二次元バーコード）などであってよい。服用のタイミングとは、薬剤毎に指定される服用の時期に合致するかを特定可能な情報であればよく、限定ではなく一例として、ユーザによる打ち込まれたテキスト情報が示す時刻であってもよいし、撮像画像にメタデータとして含まれる撮像時刻であってもよいし、端末２０から服薬情報２２１を送信する送信時刻あるいはサーバ１０で服薬情報２２１を受信する受信時刻で代替されてよい。また、服用のタイミングは、薬剤毎に指定される服用の時期に合致しているか否かの情報であってもよい。また、薬剤毎に指定される服用の時期とは、薬剤を服用するにあたって、服用するのに望ましいと医療従事者や薬機法等で定められる時期を示す情報であり、限定ではなく一例として、朝食後であったり、朝夕であったり、食間であったりしてもよいし、そうでなくてもよい。また、服用のタイミングは、他の服用時期からの差分を示す情報であってもよく、限定ではなく一例として、前回の服用から所定時間（限定ではなく一例として４時間）が経過していることを示す情報であってもよいし、そうでなくてもよい。また、服用の方法とは、薬剤を服用する際の服用方法を示す情報のことであり、限定ではなく一例として、飲料の要否であってもよいし、そうでなくてもよい。また、服用の方法は、限定ではなく一例として、飲料の指定（限定ではなく一例として水または白湯）であってもよいし、そうでなくてもよい。

【0058】

判定部２１３は、ユーザが服用しようとしている薬剤が正しいか否かを判定する。判定部２１３は、限定ではなく一例として、ユーザが服用しようとしている薬剤の撮像画像を取得する。そして、取得した撮像画像に対してパターンマッチングにより、何の薬剤を服用しようとしているかを特定する。そして、服用しようとしている薬剤が正しい薬剤であるかを判定する。この判定は、例えば、予め記憶部２８に、ユーザが服用する薬剤の服用タイミングを規定したスケジュール情報を保持することで判定することができる。そして、判定部２１３は、ユーザが服用しようとしているユーザが誤っている場合には、その旨を通知する。この通知は、音声による通知であってもよいし、画像や文字による通知であってもよい。判定部２１３は、ユーザが入力した薬剤のテキスト情報に基づいて、ユーザが服用しようとしている薬剤が正しいか否かを判定することとしてもよい。

【0059】

表示処理部２１２は、サーバ１０が提供するメッセージングサービスから提供されるメッセージングアプリケーションに従って、ユーザからの入力および／または通信Ｉ／Ｆ２２が受信したメッセージを含むコンテンツの入力を受け付けて、表示部２４の表示領域に表示するように指示する。表示処理部２１２は、対価情報２２２を表示する。
以上が、端末２０の機能構成である。

【0060】

（２）サーバの機能構成
図２に示すように、サーバ１０の制御部１１は、メッセージ処理部１１１と、更新部１１２と、算出部１１３と、生成部１１４と、を備える。

【0061】

メッセージ処理部１１１は、各ユーザ間のやり取りを行うためのトークルームを管理する機能を備える。メッセージ処理部１１１は、サーバ１０が提供するメッセージングサービスの提供を受ける端末間のコンテンツを含むコンテンツのやり取りを中継する。即ち、あるユーザからトークルームへのコンテンツが送信された場合に、そのトークルームを特定し、トークルームに属する他のユーザにコンテンツを送信する。また、ここでは、メッセージ処理部１１１は、ユーザとの間でやり取りするためのトークルームを介して、服薬情報を受信する。また、服薬情報に基づく対価情報を、トークルームに送信する。

【0062】

更新部１１２は、受信した服薬情報に基づいて、服薬管理情報を更新する。更新部１１２は、受信した服薬情報を送信した端末２０を特定し、特定した端末２０に対応するユーザの服薬管理情報を記憶部１５から取得する。そして、取得した服薬管理情報において受信した日付であって服薬管理情報に含まれる薬剤ＩＤに対応する服用履歴と服用タイミングとに情報を追加することで服薬管理方法を更新する。

【0063】

算出部１１３は、服薬情報に基づく、ユーザの服薬の履歴に基づいて、ユーザがどれだけ用法、用量を守って服薬をしているかを評価するためのスコアを算出する。算出部１１３は、限定ではなく一例として、服薬した薬剤が正しいものか否か、服薬した量を守っているか否か、服薬したタイミングが正しいか否かによって、スコアを算出する。算出部１１３は、限定ではなく一例として、所定期間（限定ではなく一例として、１ヶ月と固定の期間であってもよいし、処方された薬剤の日数分を所定期間としてもよい）における服用履歴に基づいてスコアを算出する。

【0064】

限定ではなく一例として、服用した薬剤が正しい場合に「１」、間違っている場合に「０」としてよい。また、服薬した量（錠剤や薬包であれば個数、薬液であればミリリットル数）が規定されている量と同一か、それに対して多寡があるか否かによって、第１係数を決定することとしてよい。例えば、規定されている量と同一である場合に第１係数を「１」とし、基準の量に対してずれが発生した場合に、基準量からの乖離率に応じた値を第１係数としてよい。例えば、３錠を服用しなければならないところ、２錠しか服用しなかった場合に、第１係数を０．６６（＝２／３）とすることができる。また、服用タイミングが規定されているタイミングからどれだけ乖離しているか否かによって、第２係数を決定することとしてよい。例えば、規定されている時間内の服用であれば、第２係数を１とし、規定されている時間から遠ざかるほど値が０に近づくように第２係数を決定するようにしてよい。そして、服用した薬剤が正しい場合の値「１」または間違っている場合の値「０」に第１係数と第２係数とを乗じることとしてよい。これによって、１回分の服用についての仮スコアが算出される。そして、所定期間分の服用履歴についての仮スコアを算出した後に、その仮スコアの平均値をスコアとして算出することとしてよい。したがって、スコアが１に近いほど、評価が高く、０に近いほど評価が低いことになる。算出部１１３は、算出したスコアを生成部１１４に送信する。

【0065】

なお、ここに示すスコアの算出方法は、一例に過ぎない。スコアの算出方法は、服薬が規定されている用法・容量に近ければ近いほど評価値が高く、規定されている用法・容量から離れるほど低くなるように算出されるスコアであれば、どのような手法により算出されてもよい。限定ではなく一例として、上述した算出方法の他、例えば、正しい薬剤の服薬を行えば「５点」、容量について正しい容量を服用している場合に「５点」として正しい容量から遠ざかるほどに減点し、タイミングについて、正しい時間帯内で服用している場合に「５点」としてその時間帯から１０分離れるほどに１点減点とすることとしてもよい。そして、１回の服薬についてのスコアを加算形式で算出するとともに、所定期間（限定ではなく一例として、１週間や１ヶ月）の合計値をユーザのスコアとして算出することとしてもよい。そして、算出したスコアが所定の閾値を上回った場合に、対価としての対価情報をユーザの端末２０に送信することとしてもよい。また、算出部１１３は、単純に、ユーザが、規定通りに薬剤を服用していなかった場合に、ユーザの評価が下がる方向で、スコアを加減算するようにしてもよいし、そうしなくてもよい。限定ではなく一例として、算出部１１３は、ユーザの所定期間のスコアの基準値を規定し、ユーザが規定通りに薬剤を服用しなかった場合に所定点（限定ではなく一例として１０点）減点することとしてもよいし、そうしなくてもよい。

【0066】

生成部１１４は、算出部１１３が算出したスコアが所定の基準を満たした場合に、ユーザに対する対価を決定し、決定した対価の内容を示す対価情報を、通信部Ｉ／Ｆ２２を介して、ユーザの端末２０に送信する。生成部１１４は、算出部１１３が算出したスコアが予め定められた閾値を超えている場合には、ユーザが一定以上正しく服薬を行ったものとして、対価として、ユーザにとって得となる対価情報を生成する。限定ではなく一例として、生成部１１４は、対価情報として、保険料の割引や免除、診察料の割引や施設利用料の軽減、物品の想定などを示す情報を生成することとしてよい。また、このときに、生成部は、スコアの値に応じて対価として額面や物品の良し悪しを定めてもよい。即ち、生成部は、スコアが高ければ高いほど、保険料等の割引率が高くなるようにして対価情報を決定してもよいし、対価が物品である場合には、スコアを複数の閾値で区分けを行い、どの区域になるかによって物品の内容を変更するようにして対価情報を決定してもよい。

【0067】

また、生成部１１４は、スコアが所定の閾値（前述の所定の閾値と同値であってもよいし、それよりも低い値であってもよい）よりも低かった場合には、ユーザは正しく服薬を行っていなかったということで、何らかのペナルティとなるような対価情報を生成することとしてもよい。サーバ１０が、ユーザの端末２０から服薬情報を受信できなかった場合にはスコアは低いものとなりペナルティが課される可能性が高くなる。

【0068】

以上が、サーバ１０の機能構成である。

【0069】

＜データ＞
図３は、服薬管理情報３００の構成例を示すデータ概念図である。図３に示す服薬管理情報３００は、一ユーザについての服薬の管理を行うための情報であり、サーバ１０の記憶部１４には、各ユーザについて、の服薬管理情報３００を保持する。

【0070】

図３に示すように服薬管理情報３００は、ユーザＩＤ３０１と、服用予定日３０２と、服用予定タイミング３０３と、薬剤ＩＤ３０４と、服用履歴３０５と、服用タイミング３０６とが対応付けられた情報である。

【0071】

ユーザＩＤ３０１は、通信システム１上で、各ユーザを一意に識別する識別情報である。即ち、ユーザＩＤ３０１は、その服薬管理情報３００が誰の服薬管理情報であるかを規定する情報である。

【0072】

服用予定日３０２は、ユーザが処方された薬剤を服用する予定の日時を示す情報である。

【0073】

服用予定タイミング３０３は、対応する日時において、ユーザが処方された薬剤を服用する予定の時間帯を示す情報である。服用予定タイミング３０３は、厳密な時間帯により定められてもよいし、午前中、昼食後というような抽象的な情報であってもよい。抽象的な情報により規定される場合には、サーバ１０は、予め、その概念として適切とされる時間帯の情報を予め保持する。

【0074】

薬剤ＩＤ３０４は、対応する服用予定日３０２、服用予定タイミング３０３において服用すべき薬剤を一意に特定するための薬剤の識別情報である。

【0075】

服用履歴３０５は、対応する服用予定日３０２、服用予定タイミング３０３に関する服薬情報として、ユーザの端末２０から送信された服薬情報２２１に基づく服薬の証拠となる情報を示す情報である。服用履歴３０５は、まだ、服用情報を受け付けていない場合には、空欄となる。

【0076】

服用タイミング３０６は、対応する服用履歴３０５で示される薬剤の服用を行ったタイミングを示す情報である。服用タイミング３０６は、まだ、服用情報を受け付けていない場合には、空欄となる。

【0077】

図３の例では、ユーザＩＤ「Ｕ０２０１５２４」で示されるユーザは、服用予定日「２０２０年４月１０日」の「朝食後」に、薬剤ＩＤ「Ｍ００９０８２」で示される薬剤を、「７時３０分」に服用しており、その証拠として、「Ｈ００９２０１．ｊｐｇ」という画像情報が保持されている例を示している。なお、図３に示す服薬管理情報３００には、図示していない服薬に関する情報であれば、他の情報も対応付けられてもよい。限定ではなく一例として、ユーザが服薬した薬剤の服薬量に関する情報や、服薬に用いた飲料、服薬の前後の食事内容などの情報が対応付けられてもよいし、対応付けられなくてもよい。

【0078】

＜動作＞
図４は、通信システム１における端末２０とサーバ１０との間のやり取りの例を示すシーケンス図である。図４に示すやり取りは、ユーザが端末２０を用いて服薬したことを示す情報を送信し、対価を得るためのやり取りである。

【0079】

図４に示すように、端末２０は、服薬情報の入力を受け付ける（ステップＳ４０１）。この服薬情報の入力は、ユーザによりタッチパネル２３１を用いて入力されたテキスト情報による入力であってもよいし、カメラ２３４により撮像された薬剤の撮像画像による入力であってもよいし、カメラ２３４により読みとられた薬剤に対応付けられたコード情報を読み取った情報の入力であってもよい。そして、端末２０は、サーバ１０に、受け付けた服薬情報を送信する（ステップＳ４０２）。

【0080】

サーバ１０は、受信した服薬情報に基づき、対応するユーザの服薬管理情報を更新する（ステップＳ４０３）。

【0081】

サーバ１０は、ユーザの服薬管理情報に基づき、ユーザが所定の基準を満たしたか否かを判断する。そして、ユーザが所定の基準を満たしている場合に、ユーザに送信する対価情報を生成する（ステップＳ４０４）。そして、サーバ１０は、生成した対価情報を、端末２０に送信する（ステップＳ４０５）。

【0082】

端末２０は、受信した対価情報を表示する（ステップＳ４０６）。

【0083】

図５は、図４に示すやり取りを実現するための端末２０の動作例を示すフローチャートである。

【0084】

図５に示すように、端末２０は、服薬情報の入力を受け付ける（ステップＳ５０１）。端末２０の入出力部２３は、服薬情報の入力を受け付けて、制御部２１に送信する。

【0085】

制御部２１のメッセージ処理部２１１は、服薬情報を、通信Ｉ／Ｆ１４を介して、サーバ１０に送信する（ステップＳ５０２）。

【0086】

メッセージ処理部２１１は、通信Ｉ／Ｆ１４を介して、対価情報を受信しているか否かを判定する（ステップＳ５０３）。対価情報を受信していない場合には（ステップＳ５０３のＮＯ）、ステップＳ５０１の処理に戻る。

【0087】

対価情報を受信している場合には（ステップＳ５０３のＹＥＳ）、表示処理部２１２は、表示部２４に表示し（ステップＳ５０４）、ステップＳ５０１の処理に戻る。
以上が、端末２０の動作である。

【0088】

図６は、図４に示すやり取りを実現するためのサーバ１０の動作例を示すフローチャートである。

【0089】

図６に示すように、通信Ｉ／Ｆ１４は、端末２０から送信された服薬情報を受信する（ステップＳ６０１）。通信Ｉ／Ｆ１４は、受信した服薬情報を制御部１１に送信する。

【0090】

制御部１１の更新部１１２は、受信した服薬情報を用いて、対応するユーザの服薬管理情報３００を更新する（ステップＳ６０２）。更新部１１２は、服薬情報を服用履歴３０５に登録し、服薬情報を受信した時刻を服用タイミング３０６に登録する。

【0091】

算出部１１３は、受信した服薬情報に対応するユーザのスコアを算出する（ステップＳ６０３）。算出部１１３は、算出したスコアを生成部１１４に送信する。そして、生成部１１４は、受信したスコアが所定の閾値を超えているか否かを判定する（ステップＳ６０４）。超えていないと判定した場合には（ステップＳ６０４のＮＯ）、処理を終了する。

【0092】

生成部１１４は、スコアが所定の閾値を超えていると判定した場合に（ステップＳ６０４のＹＥＳ）、対価情報を生成する（ステップＳ６０５）。そして、生成部１１４は、生成した対価情報を、通信Ｉ／Ｆ１４を介して、端末２０に送信し（ステップＳ６０６）、処理を終了する。生成部１１４は、サーバ１０と端末２０との間のトークルームを介して対価情報を送信してもよい。

【0093】

なお、図６では、算出部１１３は、ユーザから服薬情報を受信するごとにスコアを算出する構成を示しているが、算出部１１３によるスコアの算出は、服薬情報を受信するごとでなくてもよい。算出部１１３は、例えば、一定のタイミングでの算出を行うこととしてよく、限定ではなく一例として、一ヶ月の所定の日が到来するごとに算出することとしてもよい。

【0094】

図４から図６に示す処理の結果、端末２０の表示部２４には、図７に示すような情報が表示される。

【0095】

図７（ａ）は、対価情報として、施設の利用料が安くなることを示す情報を表示している例を示している。また、図７（ｂ）は、対価情報として、ユーザが加入している保険の保険料が安くなることを示す情報を表示している例を示している。このような対価情報で示される対価が得られることで、ユーザに服薬のモチベーションを持たせることができる。なお、図７では、端末２０とサーバ１０との間のトークルームに対価情報を表示する例を示しているが、これはその限りではない。対価情報は、限定ではなく一例として、メールにより送信されてもよく、メールアプリで表示されることとしてもよい。

【0096】

なお、実施形態１において、サーバ１０がユーザに対する対価情報を決定している構成を示したが、対価情報を生成するのは、サーバ１０とは異なるサーバ装置であってもよい。即ち、このサーバ装置は、ユーザの服薬情報を収集し、収集した服薬情報に基づいてスコアを算出し、算出したスコアに基づいて対価情報を生成する機能を有し、サーバ１０は、サーバ装置とユーザとの間のトークルーム上で、服薬情報と対価情報のやり取りを中継するという態様であってもよい。また、上記実施形態１では、スコアは対価情報を特定するために用いる例を示したが、算出部１１３が算出したスコアは、医療の診断における参照情報として利用されてもよいし、そうでなくてもよい。限定ではなく一例として、容体が改善されないユーザがいる場合に、スコアが高い場合にはユーザは薬剤を処方通りに服用していることがわかるので、他の薬剤の服用の提案をしたり、スコアが低い場合にはユーザが正しく薬剤を服用していないことがわかるので、正しい服用の方法を教示したりすることができる。

【0097】

＜実施形態１の効果＞
ユーザの端末２０は、サーバ１０に服薬を行ったことを示す服薬情報を送信する。そして、サーバ１０は、服薬情報に基づいて、ユーザに対して対価情報を送信する。
これにより、ユーザは、服薬を正しく行うことで対価を得られることが認識でき、服薬に対するモチベーションを高めることができる。その結果、ユーザは、適切に治療を行うことができる。

【0098】

また、サーバ１０は、服薬情報に基づいてスコアを算出する算出部と、算出したスコアに基づいて対価を示す対価情報を生成する生成部を備えることとしてもよい。
この構成により、サーバ１０は、各ユーザの服薬状況を定量的に評価し、対価情報を送信することができる。

【0099】

また、端末２０からサーバ１０に送信される服薬情報には、服薬した薬剤を示す情報、服薬量、服用タイミングのいずれかを一つを含むこととしてよい。
これにより、サーバ１０は、服薬情報に薬剤を示す情報が含まれていれば、ユーザが正しい薬剤を服用したかどうかを特定することができ、服薬量が含まれていれば、適量を服用したどうかを特定することができ、服用タイミングが含まれていれば、正しいタイミングで服用したかどうかを特定することができる。なお、服用タイミングは、服薬情報を受信したタイミングで代用することとしてもよい。

【0100】

また、算出部は、薬剤と、その服薬量、服用タイミングとの少なくともいずれかからスコアを算出することとしてもよい。即ち、薬剤が正しい場合に高く、服薬量が適切に近いほど高く、服用タイミングが適切な時間帯に近いほど高くなるように、算出部はスコアを算出することとしてもよい。
これにより生成部は、算出部が算出したスコアに応じて、傾斜を設けた対価情報を生成することができる。したがって、適切な用法、容量を守ることでよりよい対価を得ることができることから、ユーザに薬剤の用法・容量を守らせるためのモチベーションを向上させることができる。

【0101】

また、服薬情報は、薬剤の情報として、薬剤の画像データ、薬剤を示す識別情報、薬剤に設けられた発信装置が薬剤を開封した際に検出する電波信号のいずれかであってよい。
これにより、ユーザが服薬を行ったことのエビデンスとしての確度を向上させることができる。

【0102】

また、対価情報は、ユーザが加入する保険の保険料、ユーザが利用する施設の利用料、ユーザが購買する物品の購買料のいずれかに関するものであってよい。例えば、スコアが高い場合に、保険料が安くなったり、施設の利用料が安くなったり、物品の購買料が安くなったりする。
これにより、ユーザが薬剤の用法や容量を積極的にまもるモチベーションを提供することができる。

【0103】

また、対価情報は、ユーザに対して何らかの物品を送付することを示す情報であってもよい。
これにより、ユーザは、対価として物品を受領することができ、薬剤の用法や容量を守るためのモチベーションとすることができる。

【0104】

また、算出部は、ユーザが服薬情報を送信しなかった場合、即ち、サーバ１０が服薬情報を受信しなかった場合には、算出部により算出されるスコアは低くなるように算出することとしてもよい。そして、生成部は、スコアが低い場合には、ユーザに対してペナルティを課す対価情報を生成することとしてもよい。
これにより、ユーザは服薬の用法や容量を守らない場合にペナルティが課される可能性があることから、ユーザに服薬の用法や容量を守らせる可能性を高くすることができる。

【0105】

＜実施形態２＞
上記実施形態１では、ユーザが服薬情報を送信することを前提としているが、ユーザが服薬を忘れたり、ユーザが負っている傷病が自身で癒えたと判断したりして服薬しなかったりすることがある。薬剤は、基本的に、処方された全てが用法を守って服用されることが望ましい。そこで、サーバ１０は、ユーザに服薬を促すこととしてもよい。

【0106】

図８は、ユーザに服薬情報の送信を促すサーバ１０の動作例を示すフローチャートである。服薬情報の送信を催促することで、ユーザが服薬を忘れていた場合に服薬を促すことができる。

【0107】

図８に示すように、サーバ１０の制御部１１は、現在時刻を取得する（ステップＳ８０１）。これは、サーバ１０に設けられた計時部（図示せず）から取得することとしてもよいし、外部のサーバ等から現在時刻を取得することで実現してもよい。

【0108】

制御部１１は、現在時刻と、各ユーザの服薬管理情報で示される服用予定日３０２と服用予定タイミング３０３とに基づいて、服薬情報を送信していない（服用履歴３０５と服用タイミング３０６とが対応付けられていない）ユーザがいるか否かを判定する（ステップＳ８０２）。服薬情報を送信していないユーザがいない場合には（ステップＳ８０２のＮＯ）、処理を終了する。

【0109】

服薬情報を送信していないユーザがいる場合には（ステップＳ８０２のＹＥＳ）、制御部１１は通信Ｉ／Ｆ１４を介して、特定したユーザの端末２０に服薬情報を催促する催促情報を送信し（ステップＳ８０３）、処理を終了する。

【0110】

サーバ１０は、図８に示す処理を所定時間ごと（限定ではなく一例として１０分ごと）に実行することとしてもよいし、予め定められたタイミング（限定ではなく一例として、午前１０時と、午後１４時と、午後２０時など）において実行することとしてもよい。

【0111】

図９は、図８に対応する端末２０の動作例を示すフローチャートである。

【0112】

図９に示すように、端末２０の通信Ｉ／Ｆ２２は、催促情報を受信する（ステップＳ９０１）。通信Ｉ／Ｆ２２は、受信した催促情報を制御部２１に送信する。

【0113】

制御部２１の表示処理部２１２は、受信した催促情報を表示部２４に表示して（ステップＳ９０２）、処理を終了する。

【0114】

図１０は、この処理によって、端末２０の表示部２４に表示される催促情報の表示例を示している。図１０に示すように、端末２０は、催促情報を受信した場合には、ユーザに対して、服薬情報の送信、服薬を促すメッセージを表示する。なお、サーバ１０による図８に示す処理は、端末２０が、服薬管理情報に相当する情報を保持することでユーザの服薬のスケジュールを保持し、そのスケジュールに基づいて、服薬を行っていない（服薬情報を規定の時間までに送信していない）場合にユーザに服薬に関する通知を行うことで端末２０単体により同様の処理を実現することができる。

【0115】

＜実施形態２の効果＞
サーバ１０は、ユーザの端末２０から服薬に関する服薬情報を受信できない場合に、端末２０に対して、服薬情報を催促する催促情報を送信する。そして、端末２０は、受信した催促情報を受信する。
これにより、ユーザの服薬情報の送信忘れ、ユーザの服薬忘れを防止することができるので、ユーザに適切に服薬を行わせることができる。

【0116】

＜実施形態３＞
上記実施形態１、２においては、服薬情報の送信により、サーバ１０がユーザの服薬を確認できる例を示した。ところで、ユーザが服薬しようとする薬剤を間違える可能性がある。そこで、本実施形態３においては、薬剤の誤飲を防止する例について説明する。

【0117】

図１１は、端末２０による薬剤の誤飲防止の動作例を示すフローチャートである。

【0118】

図１１に示すように、端末２０は、ユーザが服用しようとしている薬剤の情報を取得する（ステップＳ１１０１）。端末２０は、ユーザからタッチパネル２３１を介してユーザがこれから服用しようとしている薬剤の情報の入力を受け付けることで薬剤の情報を取得することとしてもよいし、そうでなくてもよい。あるいは、端末２０は、ユーザの操作に基づいて、カメラ２３４を用いて撮像された薬剤の撮像情報を薬剤の情報として取得することとしてもよいし、そうでなくてもよい。また、このカメラ２３４は、ユーザが装着しているヘッドマウントディスプレイに設けられたカメラであってもよい。

【0119】

制御部２１は、取得した薬剤の情報に基づいて、ユーザが服用しようとしている薬剤が正しいか否かを判定する（ステップＳ１１０２）。制御部２１は、限定ではなく一例として、記憶部２８に記憶されるユーザが服用する薬剤のスケジュール情報（限定ではなく一例として、図３に示す服薬管理情報と同様の情報）を参照することで、この判定を行うことができる。

【0120】

服薬する薬剤が正しい場合には（ステップＳ１１０２のＹＥＳ）、処理を終了する。服薬する薬剤が正しくない場合には（ステップＳ１１０２のＮＯ）、制御部１１は、入出力部２３に服用対象の薬剤が異なることを示すことを通知させて処理を終了する。

【0121】

ユーザが服用すべきではない薬剤を服用しようとしている薬剤が間違っている場合には、図１２に示すように、ユーザに、服用しようとしている薬剤が間違っていることを示す情報を表示することで、注意喚起をすることができる。なお、図１２では、表示による注意喚起をする例を示しているが、これは、音声による出力であってもよいし、そうでなくてもよい。なお、図１２には、ユーザの端末２０として、スマートフォンに表示した例を示しているが、端末２０がヘッドマウントディスプレイ等の場合には、そのヘッドマウントディスプレイに適した態様で、同内容の情報が表示される。ヘッドマウントディスプレイを使用する場合には、スマートフォンを使用する場合に比して、ユーザが注意喚起を受けていることを気づきやすいといえる。

【0122】

なお、ここでは、端末２０が、ユーザが服用しようとしている薬剤が正しいかを検出する例を示しているが、これは、端末２０ではなくサーバ１０により判定するものであってもよい。即ち、ユーザが端末２０から服用情報を送信した場合に、サーバ１０は、その服用情報で示される薬剤が対応するユーザの服薬管理情報３００に登録されているか否かを判定する。そして、登録されていない（もしくはその時間に服薬すべきでない薬剤である）薬剤であった場合に、サーバ１０は、服用しようとしている（または服薬した）薬剤が間違っていることを、端末２０に通知する。そして、端末２０は、サーバ１０からの通知にしたがって、薬剤が誤っていることをユーザに通知する。このように、ユーザが服薬する薬剤の正誤の判断は、サーバ１０が行うこととしてもよい。

【0123】

＜実施形態３の効果＞
端末２０またはサーバ１０は、ユーザが使用しようとしている薬剤が正しいか否かを判定する。そして、正しくない場合には、端末２０を介してユーザに使用しようとしている薬剤が正しくないことを通知する。
これにより、ユーザによる薬剤の誤飲を防止することができる。

【0124】

＜実施形態４＞
上記実施形態１においては、薬剤を服用した場合に服用情報を送信し、その見返りとして対価情報を受け取る例を示した。ところで、薬剤は多めにユーザに処方されることから、ユーザによっては、薬剤を余らせてしまうことがある。しかし、ユーザは余った薬剤の処分方法を知らない可能性がある。そこで、サーバ１０は、ユーザに薬剤の処分方法を通知することとしてもよい。

【0125】

図１３は、サーバ１０が端末２０に薬剤の処分方法を通知する際のサーバ１０と端末２０との間のやり取りの例を示すシーケンス図である。

【0126】

図１３に示すように、端末２０は、ユーザから治療完了の入力を受け付ける（ステップＳ１３０１）。端末２０は、ユーザに処方された薬剤のうち、余っている薬剤がある場合に、余っている薬剤を示す残余薬剤情報をサーバ１０に送信する（ステップＳ１３０２）。

【0127】

サーバ１０は、残余薬剤情報を受信すると、残余薬剤情報に基づいて、薬剤の処分方法を特定する（ステップＳ１３０３）。そして、サーバ１０は特定した薬剤の処分方法を示す薬剤処分情報を端末２０に送信する（ステップＳ１３０４）。

【0128】

端末２０は、薬剤処分情報を受信すると、受信した薬剤処分情報を表示する（ステップＳ１３０５）。

【0129】

サーバ１０の記憶部１５は、図１３に示すやり取りを実現するために薬剤の処分方法を示す薬剤情報１４００を記憶する。

【0130】

図１４は、薬剤情報１４００の構成例を示すデータ概念図である。図１４に示すように、薬剤情報１４００は、薬剤ＩＤ１４０１と、処分方法１４０２とが対応付けられた情報である。

【0131】

薬剤ＩＤ１４０１は、薬剤を一意に特定することが可能な薬剤の識別情報である。

【0132】

処分方法１４０２は、対応する薬剤ＩＤ１４０１で示される薬剤を処分する際の処分方法を示す情報である。

【0133】

薬剤情報１４００により、サーバ１０は、ユーザの端末２０から受信した残余薬剤情報で示される薬剤ＩＤから薬剤の処分方法を特定することができる。

【0134】

図１５は、図１３に示すやり取りを実現するためのサーバ１０の動作例を示すフローチャートである。

【0135】

図１５に示すように、サーバ１０の通信Ｉ／Ｆ１４は、端末２０から残余薬剤情報を受信する（ステップＳ１５０１）。残余薬剤情報には、ユーザの手元に残っている薬剤を示す薬剤ＩＤが含まれる。通信Ｉ／Ｆ１４は、受信した残余薬剤情報を制御部１１に送信する。

【0136】

制御部１１は、受信した残余薬剤情報に含まれる薬剤ＩＤを特定する。そして、特定した薬剤ＩＤと、薬剤情報１４００を参照して、対応する処分方法１４０２を特定する（ステップＳ１５０２）。

【0137】

そして、制御部１１は、特定した処分方法を示す薬剤処分情報を、通信Ｉ／Ｆ１４を介して、端末２０に送信する（ステップＳ１５０３）。
以上がサーバ１０の動作である。

【0138】

次に、図１３に示すやり取りを実現するための端末２０の動作例を図１６に示すフローチャートを用いて説明する。

【0139】

図１６に示すように、端末２０の入出力部２３は、ユーザから治療完了の入力を受け付ける（ステップＳ１６０１）。

【0140】

そして、端末２０の入出力部２３は、ユーザから余っている場合に、残余の薬剤に関する情報の入力を受け付ける（ステップＳ１６０２）。残余の薬剤に関する情報の入力は、ユーザによる薬剤を示すテキストの入力であってもよいし、カメラ２３４により撮像された薬剤の撮像画像による入力であってもよい。入出力部２３は、受け付けた情報を制御部２１に送信する。

【0141】

制御部２１は、通信Ｉ／Ｆ２２を介して、サーバ１０に受信した残余薬剤情報を送信する（ステップＳ１６０３）。

【0142】

制御部２１は、通信Ｉ／Ｆ２２を介して、サーバ１０から薬剤処分情報を受信しているか否かを判定する（ステップＳ１６０４）。薬剤処分情報を受信していない場合には（ステップＳ１６０４のＮＯ）、制御部２１は、受信するまで、待機する。

【0143】

薬剤処分情報を受信すると（ステップＳ１６０４のＹＥＳ）、制御部２１の表示処理部２１２は、表示部２４に薬剤処分情報を表示させ（ステップＳ１６０５）、処理を終了する。

【0144】

図１７は、端末２０における薬剤処分情報の表示例を示す図である。図１７は、端末２０からサーバ１０に送信した残余薬剤情報と、サーバ１０から端末２０に送信した薬剤処分情報とを、サーバ１０と端末２０との間のトークルームを介して送受信した場合の表示例を示している。図１７に示されるように、端末２０から送信した残余薬剤情報に対応する薬剤の処分方法が、サーバ１０から通知されることにより、端末２０により表示される。

【0145】

＜実施形態４の効果＞
ユーザは、端末２０から薬剤が余っていることを示す残余薬剤情報をサーバ１０に送信する。そして、サーバ１０は、残余薬剤情報が示す薬剤に関する処分方法を示す処分情報を端末２０に送信し、端末２０は、受信した処分情報を表示する。
これにより、端末２０のユーザは、余っている薬剤の処分方法を認識することができ、認識した処分方法で適切に薬剤を処分することができる。薬剤によっては処分を誤るとなんらかの不具合を起こす（限定ではなく一例として、水道管に流してはいけない薬剤を流して有毒ガスを発生させたりなど）可能性を抑制することができるとともに、薬剤が残ることによって後日適切でない患者が残っている薬剤を服用することによって副作用が発生したりする可能性を抑制することができる。

【0146】

＜実施形態５＞
上記実施形態１においては、ユーザの端末２０からサーバ１０に服用情報を送信することで、サーバ１０が、ユーザが薬剤を服用したかどうかを確認できる例を示した。ところで、薬剤を服用したかどうかを確認したいのはサーバ１０に限定されない。即ち、ユーザの家族等が、ユーザが実際に薬剤を服用したかどうかを確認したい場合もありえる。そこで、ユーザ以外の他のユーザが、ユーザが実際に薬剤を服用したかどうかを確認できる態様を説明する。

【0147】

図１８は、実施形態４に係る通信システム１におけるサーバ１０と端末２０（２０Ａ、２０Ｂ）との間のやり取りの例を示すシーケンス図である。図１８に示すシーケンス図は、図４に示すシーケンス図と、ステップＳ１８０１～Ｓ１８０３に係る処理が実行される点において異なり、それ以外の処理については、図４に示すシーケンス図における処理と同様であるので、説明を省略する。

【0148】

図１８に示すようにサーバ１０は、服薬管理情報をユーザの端末２０から受信すると、服薬管理情報を受信したことを示す服薬確認情報を生成する（ステップＳ１８０１）。そして、サーバ１０は、服薬確認情報を、端末２０Ａのユーザが服薬したかを確認したいユーザの端末２０Ｂに送信する（ステップＳ１８０２）。

【0149】

サーバ１０からの服薬確認情報を受信した端末２０Ｂは、服薬確認情報を表示する（ステップＳ１８０３）。これにより、端末２０Ｂのユーザは、端末２０Ａのユーザが服薬を行ったかを確認できる。

【0150】

なお、ステップＳ１８０１、Ｓ１８０２の処理は、Ｓ４０４、Ｓ４０５の処理と同時に実行されてもよいし、Ｓ４０４、Ｓ４０５の処理の後に実行されてもよい。

【0151】

図１９は、図１８に示すやり取りを実現するためにサーバ１０の記憶部１５に記憶される対応情報１９００の構成例を示すデータ構成例である。

【0152】

図１９に示すように、対応情報１９００は、第１ユーザＩＤ１９０１と、第２ユーザＩＤ１９０２と、関係１９０３とが対応付けられた情報である。

【0153】

第１ユーザＩＤ１９０１は、ユーザを一意に特定可能な識別情報であり、服薬を行う必要があるユーザを示す情報である。

【0154】

第２ユーザＩＤ１９０２は、対応する第１ユーザＩＤ１９０１が示すユーザが服薬したかどうかを確認したいユーザを一意に識別可能な識別情報である。

【0155】

関係１９０３は、対応する第１ユーザＩＤ１９０１と第２ユーザＩＤ１９０２とが示すユーザ同士の関係を示す情報である。

【0156】

図１９に示す例では、第１ユーザＩＤ１９０１が「Ｕ０２０１５２４」で示されるユーザが、第２ユーザＩＤ１９０２が「Ｕ０３９００２０」で示されるユーザによる薬剤の服用の確認を受けることになっており、両ユーザの関係は、「親子」となっている。なお、対応情報１９００は、第１ユーザＩＤ１９０１と第２ユーザＩＤ１９０２とが対応付けられていればよく、関係１９０３は、必須の情報ではない。

【0157】

図２０は、図１８に示すやり取りを実現するためのサーバ１０の動作例を示すフローチャートである。図２０に示すフローチャートは、図６に示すフローチャートとで、ステップＳ２００１、Ｓ２００２の処理が行われることにおいて相違し、その他の処理については、図６と共通するので、共通する処理については、説明を省略する。

【0158】

図２０に示すように、サーバ１０の制御部１１は、服薬管理情報を更新すると、受信した服薬情報を送信した端末２０に対応するユーザが、対応情報１９００において対応付けられた第２ユーザがいるか否かを確認する（ステップＳ２００１）。いない場合には（ステップＳ２００１のＮＯ）、ステップＳ６０３の処理に移行する。

【0159】

対応するユーザがいる場合には（ステップＳ２００１のＹＥＳ）、制御部１１は、服薬情報を送信した端末２０のユーザに対応付けられている他のユーザの端末に、ユーザが服薬を行ったことを示す服薬確認情報を、通信Ｉ／Ｆ１４を介して、送信する（ステップＳ２００２）。なお、制御部１１は、服薬確認情報として、上記実施形態２において示したように、ユーザが服薬情報を送信していなかったことが確認できた場合に、服薬を行っていないことを示す服薬確認情報を他のユーザの端末に送信することとしてよい。

【0160】

図２１は、他のユーザの端末において表示される服薬確認情報の表示例を示す図である。図２１（ａ）は、他のユーザが服薬を確認したいＡというユーザが服薬を行ったことを示す服薬確認情報を受信した場合の表示例を示している。一方で、図２１（ｂ）は、ユーザＡが服薬情報を、規定時間にサーバ１０に送信しなかった場合に、他のユーザの端末に表示される例を示している。図２１（ｂ）では、他のユーザに対して、ユーザＡに服薬の確認を依頼する例を示している。なお、図２１では、サーバ１０と他のサーバとの間のトークルームに服薬確認情報を表示する例を示しているが、服薬確認情報は、トークルームを介した送信に限定するものではなく、限定ではなく一例としてメールによる送信であってもよい。

【0161】

＜実施形態５の効果＞
サーバ１０は、服薬するユーザに関連する他のユーザの情報を保持する。そして、サーバ１０は、ユーザから服薬を行ったことを示す服薬情報を受信した場合には、他のユーザの端末に、ユーザが服薬したことを示す情報を送信する。
この構成により、サーバ１０だけでなく、ユーザに関連する他のユーザに対しても、ユーザが服薬したかどうかを示す情報を送信する。したがって、他のユーザが服薬状態を確認することで、他のユーザがユーザに対して服薬を実行するよう通知することができるので、ユーザによる服薬忘れの可能性を低減することができる。

【0162】

＜実施形態６＞
上記実施の形態１から４においては、ユーザが端末２０を用いて服薬情報をサーバ１０に送信する例を示したが、服薬情報の送信方法はこれに限定するものではない。本実施形態５においては、服薬情報の他の例を示す。

【0163】

図２２は、実施形態５に係る通信システム１の構成例を示す図である。図２２に示すように、発信器が含まれていることが図１に示すシステム構成例と異なる。

【0164】

＜発信器の構成＞
発信器は、ユーザが服用する薬剤を開封されたことを検知するセンサである。発信器は、限定ではなく一例として、薬包の開封部に設けられた接触センサにより実現されてよく、接触状態が解除されたことを検出することで薬包が開封されたと検出することとしてよい。発信器は、薬包ごとに設けられてよい。

【0165】

発信器は、通信部４１と、検出部４２とを備える。

【0166】

通信部４１は、検出部４２から、薬包が開封されたことを示す開封情報を受信した場合に、サーバ１０に、薬包が開封されたことに基づく服薬情報を送信する。各発信器は、固有の識別情報（センサＩＤ）を保持し、服薬情報には、センサＩＤが含まれる。

【0167】

検出部４２は、薬包が開封されたことを検出し、開封情報を通信部４１に送信する。

【0168】

また、サーバ１０の記憶部１５は、各センサのセンサＩＤと、そのセンサＩＤに対応する薬剤がどの薬剤で、どのユーザに処方されたかを示す情報を保持する。この情報を保持していることで、サーバ１０の制御部１１は、服薬情報を受信した場合に、どのユーザが薬剤を服用したのかを特定できる。

【0169】

＜動作＞
図２３は、実施形態５に係る通信システム１に係る発信器と、サーバ１０と、端末２０とのやり取りの例を示すシーケンス図である。図２３に示すシーケンス図は、発信器がサーバ１０に服薬情報を送信する点においてのみ図４に示すシーケンス図と異なり、その他の動作については図４と共通する。よって、ここでは、図４と異なる構成についてのみ説明する。

【0170】

図２３に示すように、薬包に設けられた発信器は、ユーザにより薬包が開封されたことを検出する（ステップＳ２３０１）。そして、発信器は、服薬情報を、サーバ１０に送信する（ステップＳ２３０２）。サーバ１０は、発信器から服薬情報を受信して、その服薬情報に含まれるセンサＩＤから、どのユーザが何の薬剤を服薬したのかを特定し、ステップＳ４０３以降の処理を実行する。

【0171】

図２４は、発信器の動作例を示すフローチャートである。

【0172】

図２４に示すように、発信器の検出部４２は、ユーザにより薬包が開封されたか否かを判定する（ステップＳ２４０１）。薬包が開封されていない場合には（ステップＳ２４０１のＮＯ）、待機する。薬包が開封されたことを検出した場合には（ステップＳ２４０２）、検出部４２は、薬包が開封されたことを示す開封情報を通信部４１に送信する。

【0173】

通信部４１は、開封情報を受信すると、発信器の識別情報であるセンサＩＤを含む服薬情報をサーバ１０に送信する。

【0174】

なお、本実施形態５において、発信器は、直接サーバ１０に服薬情報を送信する構成としているが、発信器は、一端ユーザの端末２０に服薬情報を送信し、端末２０が、その服薬情報を中継してサーバ１０に送信する構成としてもよいし、そうしなくてもよい。

【0175】

＜実施形態６の効果＞
実施形態６によれば、薬包には発信器４０が設けられ、発信器４０がユーザにより薬包が開封されたことを検知して、サーバ１０に、薬包が開封されたことに基づく服薬情報を送信する。
この構成によれば、ユーザは、自身で服薬の都度、服薬情報をサーバ１０に送信しなくともよいので、ユーザにとってサーバ１０を利用するうえでの利便性が向上する。

【符号の説明】

【0176】

１ 通信システム
１０ サーバ
１１ 制御部
１１１ メッセージ処理部
１１２ 更新部
１１３ 算出部
１１４ 生成部
１２ 入出力部
１３ 表示部
１４ 通信Ｉ／Ｆ（通信部）
１５ 記憶部
２０ 端末
２１ 制御部
２１１ メッセージ処理部
２１２ 表示処理部
２１３ 判定部
２２ 通信Ｉ／Ｆ
２３ 入出力部
２３１ タッチパネル
２３２ マイク
２３３ スピーカ
２３４ カメラ
２４ 表示部（ディスプレイ）
２５ 位置情報取得部
２８ 記憶部
３０ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】