特開2024-97579 | 知財ポータル「IP Force」

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

▶ 株式会社メルスの特許一覧

特開2024-97579通信システムおよび通信方法

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024097579

(43)【公開日】2024-07-19

(54)【発明の名称】通信システムおよび通信方法

(51)【国際特許分類】

G06Q 50/22 20240101AFI20240711BHJP

【ＦＩ】

G06Q50/22

【審査請求】有

【請求項の数】18

【出願形態】ＯＬ

(21)【出願番号】P 2023001125

(22)【出願日】2023-01-06

(11)【特許番号】

(45)【特許公報発行日】2024-06-17

(71)【出願人】

【識別番号】523007650

【氏名又は名称】株式会社メルス

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】西畑幹大

(72)【発明者】

【氏名】角畑真也

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA02

(57)【要約】

【課題】病院内のネットワークのセキュリティを向上させる通信システムを提供する。
【解決手段】通信システム１００は、病院内の院内ネットワーク９１０に接続された通知サーバ４と、院内ネットワーク９１０用のファイアウォール１１を介して、通知サーバ４と通信可能な連携サーバ３とを備える。通知サーバ４は、ソーシャルネットワーキングサービスを提供するＳＮＳサーバ２を介して、ソーシャルネットワーキングサービスを利用可能な患者の端末装置１宛に患者宛の通知を送信可能である。連携サーバ３は、ＳＮＳサーバ２を介して端末装置１からデータを取得した場合、通知サーバ４から予め定められた信号を受信したことを条件に、当該データを通知サーバ４に送信する。
【選択図】図２

【特許請求の範囲】

【請求項1】

病院内のネットワークに接続された第１のサーバと、
前記ネットワーク用のファイアウォールを介して、前記第１のサーバと通信可能な第２のサーバとを備え、
前記第１のサーバは、ソーシャルネットワーキングサービスを提供する外部サーバを介して、前記ソーシャルネットワーキングサービスを利用可能な患者の端末装置宛に前記患者宛の第１の通知を送信可能であり、
前記第２のサーバは、前記外部サーバを介して前記端末装置から第１のデータを取得した場合、前記第１のサーバから予め定められた信号を受信したことを条件に、前記第１のデータを前記第１のサーバに送信する、通信システム。

【請求項2】

前記第１のデータは、前記ソーシャルネットワーキングサービスによって前記患者に付与された第１の識別情報を含む、請求項１に記載の通信システム。

【請求項3】

前記第１のデータは、前記病院によって前記患者に付与された第２の識別情報をさらに含み、
前記第１のサーバは、前記第１のデータを前記第２のサーバから取得すると、前記第１の識別情報と前記第２の識別情報とを紐付けて記憶する、請求項２に記載の通信システム。

【請求項4】

前記第２のサーバは、前記端末装置によって前記第２の識別情報を含む２次元バーコードが読み取られたことに基づき、前記外部サーバを介して前記端末装置から前記第２の識別情報を取得する、請求項３に記載の通信システム。

【請求項5】

前記第１のデータは、前記病院によって前記患者に一時的に付与された第３の識別情報をさらに含み、
前記第１のサーバは、
前記第１のデータを前記第２のサーバから取得すると、前記第３の識別情報に基づき、前記ネットワークを介して第３のサーバから前記病院によって前記患者に付与された第２の識別情報を取得し、
前記第１の識別情報と前記第２の識別情報とを紐付けて記憶する、請求項２に記載の通信システム。

【請求項6】

前記第２のサーバは、
メモリを有し、かつ、前記第１のデータを前記メモリに格納し、
前記予め定められた信号の受信に応じて前記第１のデータを前記第１のサーバに送信したことに基づき、前記メモリから前記第１のデータを削除する、請求項１に記載の通信システム。

【請求項7】

前記第２のサーバは、前記第１のデータを暗号化した状態で前記メモリに格納する、請求項６に記載の通信システム。

【請求項8】

前記第１のサーバは、前記第１の通知を暗号化し、かつ、前記外部サーバを介して、前記暗号化された第１の通知を前記端末装置に送信し、
前記端末装置は、前記暗号化された第１の通知を前記第２のサーバに送信し、
前記第２のサーバは、前記暗号化された第１の通知を復号化し、かつ、前記復号化された第１の通知を前記端末装置のウェブブラウザで表示させるための第２のデータを、前記外部サーバを介さずに前記端末装置に送信する、請求項１に記載の通信システム。

【請求項9】

前記第１のサーバは、前記第２のサーバおよび前記外部サーバのうち前記外部サーバのみを介して、前記第１の通知を前記端末装置宛に送信する、請求項１に記載の通信システム。

【請求項10】

前記第１のサーバは、前記第２のサーバと前記外部サーバとを介して、前記第１の通知を前記端末装置宛に送信する、請求項１に記載の通信システム。

【請求項11】

前記第１のサーバは、前記第２のサーバのインターネットプロトコルアドレス宛に、前記第１の通知を送信し、
前記第２のサーバは、前記第１の通知を前記第１のサーバから受信したことに基づき、前記外部サーバのドメイン宛に前記第１の通知を転送し、
前記第１の通知は、前記外部サーバによって前記端末装置に転送される、請求項１０に記載の通信システム。

【請求項12】

前記第１の通知は、前記患者の診察の予約情報である、請求項１から１１のいずれか１項に記載の通信システム。

【請求項13】

前記第１のサーバは、前記ネットワークを介して第３のサーバから前記診察の会計の計算が完了したことを示す第２の通知を受信したことに基づき、前記外部サーバを介して、前記端末装置宛に、前記第１の通知として前記完了を示す通知を送信する、請求項１から１１のいずれか１項に記載の通信システム。

【請求項14】

前記第１のサーバは、前記ネットワークを介して第３のサーバから前記診察に基づく薬の調合が完了したことを示す第３の通知を受信したことに基づき、前記外部サーバを介して、前記端末装置宛に、前記第１の通知として前記完了を示す通知を送信する、請求項１から１１のいずれか１項に記載の通信システム。

【請求項15】

前記予め定められた信号は、前記第１のサーバからのポーリングによる問い合わせである、請求項１に記載の通信システム。

【請求項16】

前記第１のサーバと前記第２のサーバとの間の前記ファイアウォールを介した通信のプロコルは、ＳＦＴＰ（ＳＳＨＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）またはＨＴＴＰＳ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌＳｅｃｕｒｅ）である、請求項１５に記載の通信システム。

【請求項17】

前記第１のサーバと前記第２のサーバとの間の前記ファイアウォールを介した通信のプロコルは、ＷｅｂＳｏｃｋｅｔまたはＳｏｃｋｅｔである、請求項１に記載の通信システム。

【請求項18】

病院内のネットワークに接続された第１のサーバが、ソーシャルネットワーキングサービスを提供する外部サーバを介して、前記ソーシャルネットワーキングサービスを利用可能な患者の端末装置宛に前記患者宛の通知を送信するステップと、
前記ネットワーク用のファイアウォールを介して前記第１のサーバと通信可能な第２のサーバが、前記外部サーバを介して前記端末装置からデータを取得するステップと、
前記第２のサーバが、前記第１のサーバから予め定められた信号を受信したことを条件に、前記データを前記第１のサーバに送信するステップとを備える、通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、通信システムおよび通信方法に関する。

【背景技術】

【0002】

従来、患者が所有する携帯端末を、病院の案内システムの案内端末として機能させることが知られている。たとえば、特開２０１９－７４８７０号公報（特許文献１）には、病院がメッセージアプリユーザＩＤと患者ＩＤとを関連付けることにより、メッセージアプリを用いて外来患者を案内する案内システムが開示されている。詳しくは、特許文献１の案内システムは、患者の携帯端末と、窓口の登録機と、病院内サーバと、メッセージアプリ連携サーバと、メッセージアプリサーバとを含む。

【先行技術文献】

【特許文献】

【0003】

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

【特許文献2】特開２０１０－２０６４９号公報

【特許文献3】特許第６９６３３３１号

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１のようなシステムでは、メッセージアプリ連携サーバは、患者の携帯端末からメッセージアプリサーバを介してメッセージ等のデータを受信すると、当該データを病院内サーバに転送する。

【0005】

このような患者をメッセージアプリを用いて案内するシステムでは、病院側のサーバは、メッセージアプリ連携サーバに対して病院側のサーバ宛てのデータの送信を求めていないにもかかわらず、メッセージアプリ連携サーバを介して外部のデータを取得することになる。このため、病院側にとっては、セキュリティが十分に確保されているとは言えない。

【0006】

本開示は、上記の問題点に鑑みなされたものであって、その目的は、病院内のネットワークのセキュリティを向上させることにある。

【課題を解決するための手段】

【0007】

本開示のある局面に従うと、通信システムは、病院内のネットワークに接続された第１のサーバと、ネットワーク用のファイアウォールを介して、第１のサーバと通信可能な第２のサーバとを備える。第１のサーバは、ソーシャルネットワーキングサービスを提供する外部サーバを介して、ソーシャルネットワーキングサービスを利用可能な患者の端末装置宛に患者宛の第１の通知を送信可能である。第２のサーバは、外部サーバを介して端末装置から第１のデータを取得した場合、第１のサーバから予め定められた信号を受信したことを条件に、第１のデータを第１のサーバに送信する。

【0008】

本開示の他の局面に従うと、通信方法は、病院内のネットワークに接続された第１のサーバが、ソーシャルネットワーキングサービスを提供する外部サーバを介して、ソーシャルネットワーキングサービスを利用可能な患者の端末装置宛に患者宛の通知を送信するステップと、ネットワーク用のファイアウォールを介して第１のサーバと通信可能な第２のサーバが、外部サーバを介して端末装置からデータを取得するステップと、第２のサーバが、第１のサーバから予め定められた信号を受信したことを条件に、データを第１のサーバに送信するステップとを備える。

【発明の効果】

【0009】

上記の開示によれば、病院内のネットワークのセキュリティを向上させることが可能となる。

【図面の簡単な説明】

【0010】

【図1】ネットワークシステムの構成例を示した図である。

【図2】ネットワークシステムにおける処理の概要を説明するための図である。

【図3】連携サーバのハードウェア構成の典型例を表した図である。

【図4】端末装置のハードウェア構成の典型例を表した図である。

【図5】各サーバの機能的構成を説明するための図である。

【図6】患者の事前登録を説明するためのシーケンス図である。

【図7】患者の事前登録の変形例を説明するためのシーケンス図である。

【図8】診察の受付処理の前半部分を説明するためのシーケンス図である。

【図9】診察の受付処理の後半部分を説明するためのシーケンス図である。

【図10】図９および図１０のシーケンスに基づく端末装置の画面遷移を説明するための図である。

【図11】診察の受付処理の前半部分を説明するためのシーケンス図である。

【図12】診察の受付処理の後半部分を説明するためのシーケンス図である。

【図13】図１１および図１２のシーケンスに基づく端末装置の画面遷移を説明するための図である。

【図14】診察が間近に迫っていることを患者に通知する処理を示したシーケンス図である。

【図15】図１４のシーケンスＳＱ９４の処理により表示される画面を示した図である。

【図16】図１５に示した通知処理の変形例を示したシーケンス図である。

【図17】現在の診察状況を患者に通知する処理を示したシーケンス図である。

【図18】図１７のシーケンスに基づく端末装置の画面遷移を説明するための図である。

【図19】図１８に示した通知処理の変形例を示したシーケンス図である。

【図20】図１９のシーケンスに基づく端末装置の画面遷移を説明するための図である。

【図21】上位サーバ５からユーザの操作に基づき端末装置にメッセージを送る際の処理を示したシーケンス図である。

【図22】図２１のシーケンスＳＱ１４４の処理により表示される画面を示した図である。

【図23】診察の前日であることを患者に通知する処理を示したシーケンス図である。

【図24】図２３のシーケンスＳＱ１５４の処理により表示される画面を示した図である。

【図25】診察の開始時刻の目安を患者に通知する処理を示したシーケンス図である。

【図26】図２５のシーケンスＳＱ１６６の処理により表示される画面を示した図である。

【図27】診察についての会計が完了したことを患者に通知する処理を示したシーケンス図である。

【図28】図２７のシーケンスＳＱ１７３の処理により表示される画面を示した図である。

【図29】薬の調合が完了したことを患者に通知する処理を示したシーケンス図である。

【図30】図２９のシーケンスＳＱ１８３の処理により表示される画面を示した図である。

【図31】上述したデータテーブルにおいて互いに紐づけられた患者ＩＤと患者のＳＮＳのＩＤとの削除処理を示したシーケンス図である。

【図32】図３１のシーケンスに基づく端末装置の画面遷移を説明するための図である。

【発明を実施するための形態】

【0011】

以下、図面を参照しつつ、本発明に従う実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらについての詳細な説明は繰り返さない。なお、以下で説明される各処理例および各変形例は、適宜選択的に組み合わされてもよい。

【0012】

＜Ａ．システム構成＞
図１は、ネットワークシステムの構成例を示した図である。図１に示されるように、ネットワークシステム９００は、病院内のネットワークである院内ネットワーク９１０と、院内ネットワーク９１０に対して外部のネットワークとなる院外ネットワーク９２０とを含む。院内ネットワーク９１０は、ファイアウォール１１を介して院外ネットワーク９２０と接続されている。

【0013】

ネットワークシステム９００は、典型的には、複数の端末装置１と、ＳＮＳ（Social networking service）サーバ２と、連携サーバ３と、通知サーバ４と、上位サーバ５と、ディスプレイ用ＰＣ（Personal Computer）６と、ディスプレイ７と、情報処理端末８と、再来受付機９とを備える。なお、図１では、１つの端末装置１のみを示している。端末装置１は、典型的には、スマートフォン、タブレット端末等の可搬性のある通信機器である。

【0014】

本例では、通知サーバ４は、呼出サーバ４１と、案内表示サーバ４２とで構成される。上位サーバ５は、本例では、少なくとも、電子カルテサーバ５１と、会計用サーバ５２と、薬用サーバ５３とを含む。連携サーバ３は、ＳＮＳサーバ２と連携する。

【0015】

詳しくは、複数の端末装置１と、ＳＮＳサーバ２と、連携サーバ３とは、院外ネットワーク９２０に含まれている。通知サーバ４と、上位サーバ５と、ディスプレイ用ＰＣ６と、ディスプレイ７と、情報処理端末８と、再来受付機９とは、院内ネットワーク９１０に含まれている。

【0016】

さらに詳しくは、院内ネットワーク９１０は、呼出システム２１と、表示システム２２と、上位システム２３とを備える。呼出システム２１は、呼出サーバ４１を含んで構成される。表示システム２２は、上述した、案内表示サーバ４２と、ディスプレイ用ＰＣ６と、ディスプレイ７と、情報処理端末８とを含んで構成される。上位システム２３は、上述した、上位サーバ５と、再来受付機９とを含んで構成される。

【0017】

院内ネットワーク９１０においては、呼出サーバ４１と、案内表示サーバ４２と、電子カルテサーバ５１と、会計用サーバ５２と、薬用サーバ５３と、ディスプレイ用ＰＣ６と、ディスプレイ７と、情報処理端末８と、再来受付機９とが、ＬＡＮケーブル１０等によって、互いに通信可能に接続されている。

【0018】

案内表示サーバ４２は、ディスプレイ用ＰＣ６に案内表示のためのデータを送信する。ディスプレイ用ＰＣ６は、案内表示サーバ４２からのデータに基づき、ディスプレイ７に各種の案内を表示する。ディスプレイ用ＰＣ６は、たとえば、ディスプレイ７に現在の診察状況を表示する。

【0019】

再来受付機９は、患者の再来院時の受付処理を行う。再来受付機９は、患者によって診察券９１が投入口から投入されると、受付票９２を発行する。受付票９２には、受付番号と、２次元バーコード９２１とが印字されている。２次元バーコードとしては、たとえば、ＱＲコード（登録商標）が用いられる。

【0020】

端末装置１は、基地局装置１３とインターネット１２とを介して、ＳＮＳサーバ２と通信可能である。ＳＮＳサーバ２と、連携サーバ３と、呼出サーバ４１とは、インターネット１２に接続されている。

【0021】

呼出サーバ４１は、経路Ｐ１を介することにより、インターネット１２を介さずに、連携サーバ３と通信可能である。さらに、呼出サーバ４１は、経路Ｐ２を介することにより、連携サーバ３を介さずに、ＳＮＳサーバ２と通信可能である。この場合、呼出サーバ４１は、インターネット１２を介して、ＳＮＳサーバ２と通信する。

【0022】

ＳＮＳサーバ２は、ソーシャルネットワーキングサービスを提供する。ＳＮＳサーバ２によって提供されるＳＮＳのアプリケーションとしては、典型的には、ＬＩＮＥ（登録商標）を用いることができる。ただし、当該アプリケーションは、ＬＩＮＥに限定されるものではない。なお、ＳＮＳサーバは、メッセージアプリサーバとも称される。連携サーバは、メッセージアプリ連携サーバとも称される。

【0023】

なお、以下では、連携サーバ３と通知サーバ４とで構成される通信システムを、「通信システム１００」とも称する。通信システム１００は、本発明における「通信システム」の一例である。

【0024】

＜Ｂ．処理の概要＞
図２は、ネットワークシステム９００における処理の概要を説明するための図である。図１および図２に示されるように、ネットワークシステム９００のうちの通信システム１００は、院内ネットワーク９１０に接続された通知サーバ４と、院内ネットワーク９１０用のファイアウォール１１を介して通知サーバ４と通信可能な連携サーバ３とを備える。

【0025】

図２に示されるように、通知サーバ４は、ＳＮＳサーバ２を介して、ＳＮＳサーバ２によって提供されるソーシャルネットワーキングサービスを利用可能な患者の端末装置１宛に当該患者宛の通知（たとえば、患者の診察の予約情報）を送信可能である。

【0026】

このようなシステム構成において、端末装置１において患者によって入力されたデータは、ＳＮＳサーバ２に送られる（図中の処理（i））。その後、ＳＮＳサーバ２は、当該データを、連携サーバ３に転送する（処理（ii））。連携サーバ３は、通知サーバ４から予め定められた信号（たとえば、ポーリングによる問い合わせ）を受信（処理（iii））すると、当該データを通知サーバ４に送信する（処理（iv））。

【0027】

以上のように、連携サーバ３は、ＳＮＳサーバ２を介して端末装置１からデータを取得した場合、通知サーバ４から予め定められた信号を受信したことを条件に、当該データを通知サーバ４に送信する。

【0028】

このような構成によれば、通知サーバ４が連携サーバ３に対してデータの送信要求を行なわない限り、連携サーバ３が通知サーバ４に対してデータを送信してくることはない。それゆえ、このような通信システム１００によれば、データの送信要求を行っていないにもかかわらず外部のデータを通知サーバ４が受信してしまうような構成に比べて、院内ネットワーク９１０のセキュリティを確保することができる。

【0029】

より詳しくは、連携サーバ３は、通知サーバ４から予め定められた信号を受信したことを条件に、上記データを通知サーバ４に送信する。予め定められた信号は、上記の例では、通知サーバ４からのポーリングによる問い合わせである。

【0030】

なお、ＳＮＳサーバ２と、連携サーバ３と、通知サーバ４とは、この順に、それぞれ、本発明における、「外部サーバ」、「第２のサーバ」、「第１のサーバ」の一例である。上述した患者宛の通知は、本発明における「第１の通知」の一例である。患者への通知の他の例については、適宜、後述する。

【0031】

＜Ｃ．ハードウェア構成＞
図３は、連携サーバ３のハードウェア構成の典型例を表した図である。図３を参照して、連携サーバ３は、主たる構成要素として、プログラムを実行するＣＰＵ３５１と、データを不揮発的に格納するＲＯＭ３５２と、ＣＰＵ３５１によるプログラムの実行により生成されたデータ、又は入力装置を介して入力されたデータを揮発的に格納するＲＡＭ３５３と、データを不揮発的に格納するＨＤＤ３５４と、通信ＩＦ（Interface）３５５と、電源回路３５６と、ディスプレイ３５７と、操作キー３５８とを含む。各構成要素は、相互にデータバスによって接続されている。

【0032】

電源回路３５６は、コンセントを介して受信した商用電源の電圧を降圧し、連携サーバ３の各部に電源供給を行なう回路である。ディスプレイ３５７は、各種のデータを表示するためのデバイスである。通信ＩＦ３５５は、他の機器との間の通信を行なためのインターフェイスである。操作キー３６０は、連携サーバ３の管理者が連携サーバ３へデータを入力するために用いるキー（キーボード）である。

【0033】

連携サーバ３における処理は、各ハードウェアおよびＣＰＵ３５１により実行されるソフトウェアによって実現される。このようなソフトウェアは、ＨＤＤ３５４に予め記憶されている場合がある。また、ソフトウェアは、その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合もある。このようなソフトウェアは、読取装置によりその記憶媒体から読み取られて、あるいは、通信ＩＦ３５５等を介してダウンロードされた後、ＨＤＤ３５４に一旦格納される。そのソフトウェアは、ＣＰＵ３５１によってＨＤＤ３５４から読み出され、ＲＡＭ３５３に実行可能なプログラムの形式で格納される。ＣＰＵ３５１は、そのプログラムを実行する。

【0034】

同図に示される連携サーバ３を構成する各構成要素は、一般的なものである。したがって、本発明の本質的な部分は、ＲＡＭ３５３、ＨＤＤ３５４、記憶媒体に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。なお、連携サーバ３の各ハードウェアの動作は周知であるので、詳細な説明は繰り返さない。

【0035】

なお、記録媒体としては、ＤＶＤ－ＲＡＭ、ＤＶＤ-ＲＯＭ、ＣＤ－ＲＯＭ、ＦＤ、ハードディスク、磁気テープ、カセットテープ、光ディスク、ＥＥＰＲＯＭ、フラッシュＲＯＭなどの半導体メモリ等の固定的にプログラムを担持する媒体が挙げられる。また、記録媒体は、当該プログラム等をコンピュータが読取可能な一時的でない媒体である。また、ここでいうプログラムとは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソースプログラム形式のプログラム、圧縮処理されたプログラム、暗号化されたプログラム等を含む。

【0036】

なお、通知サーバ４（詳しくは、呼出サーバ４１および案内表示サーバ４２）、ＳＮＳサーバ２、上位サーバ５（詳しくは、電子カルテサーバ５１、会計用サーバ５２、および薬用サーバ５３）の各々は、連携サーバ３と同様なハードウェア構成を有するため、ここでは、これらのサーバについてのハードウェア構成については繰り返し説明を行わない。

【0037】

図４は、端末装置１のハードウェア構成の典型例を表した図である。図４を参照して、端末装置１は、主たる構成要素として、プログラムを実行するＣＰＵ１５１と、データを不揮発的に格納するＲＯＭ１５２と、ＣＰＵ１５１によるプログラムの実行により生成されたデータ、又は入力装置を介して入力されたデータを揮発的に格納するＲＡＭ１５３と、データを不揮発的に格納するフラッシュメモリ１５４と、カメラ１５５と、操作キー１５６と、ＧＰＳ（Global Positioning System）受信機１５７と、通信ＩＦ１５８と、電源回路１５９と、タッチスクリーン１６０と、マイク１６１と、スピーカ１６２と、アンテナ１５７１，１５８１とを含む。各構成要素は、相互にデータバスによって接続されている。

【0038】

フラッシュメモリ１５４には、オペレーティングシステム、各種のアプリケーションプログラムが格納されている。フラッシュメモリ１５４には、ウェブサイト（詳しくは、ウェブページ）を表示するためのウェブブラウザがインストールされている。

【0039】

タッチスクリーン１６０は、ディスプレイ１６０１と、タッチパネル１６０２により構成される。アンテナ１５７１は、ＧＰＳ受信機１５７用のアンテナである。アンテナ１５８１は、通信ＩＦ１５８用のアンテナである。

【0040】

操作キー１５６は、端末装置１のユーザが主電源のオンまたはオフ等するためのキー（操作ボタン）である。ＧＰＳ受信機１５７は、ＧＰＳ衛星からの電波に基づき、端末装置１の現在位置の位置情報を取得する。通信ＩＦ１５８は、たとえば、ＳＮＳサーバ２に対するデータの送信処理と、ＳＮＳサーバ２から送信されたデータの受信処理を行なう。

【0041】

電源回路１５９は、端末装置１の各部に電源供給を行なう回路である。タッチスクリーン１６０は、各種のデータを表示し、かつ操作入力を受け付けるためのデバイスである。マイク１６１は、端末装置１のユーザの発話に基づく音声を集音する。スピーカ１６２は、音声を出力する。カメラ１５５は、端末装置１の周囲の被写体を撮像するための撮像装置である。本例では、カメラ１５５は、２次元バーコード９２１（図１）を撮像するために利用される。

【0042】

端末装置１における処理は、各ハードウェアおよびＣＰＵ１５１により実行されるソフトウェアによって実現される。このようなソフトウェアは、フラッシュメモリ１５４に予め記憶されている場合がある。また、ソフトウェアは、その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合もある。このようなソフトウェアは、読取装置によりその記憶媒体から読み取られて、あるいは、通信ＩＦ１５８等を介してダウンロードされた後、フラッシュメモリ１５４に一旦格納される。そのソフトウェアは、ＣＰＵ１５１によってフラッシュメモリ１５４から読み出され、ＲＡＭ１５３に実行可能なプログラムの形式で格納される。ＣＰＵ１５１は、そのプログラムを実行する。

【0043】

同図に示される端末装置１を構成する各構成要素は、一般的なものである。したがって、本発明の本質的な部分は、ＲＡＭ１５３、フラッシュメモリ１５４、記憶媒体に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。なお、端末装置１の各ハードウェアの動作は周知であるので、詳細な説明は繰り返さない。

【0044】

＜Ｄ．機能的構成＞
図５は、各サーバの機能的構成を説明するための図である。図５に示されるように、端末装置１は、制御部１１０と、操作部１２０と、表示部１３０と、通信ＩＦ部１４０とを備える。

【0045】

制御部１１０は、端末装置１の全体的な動作を制御する。制御部１１０は、ＣＰＵ１５５１がフラッシュメモリ１５４に格納された各種のプログラムを実行することにより実現される機能ブロックである。

【0046】

操作部１２０は、端末装置１のユーザ（患者）からの操作を受け付ける。操作部１２００は、タッチパネル１６０２と、操作キー１５６とに対応する。表示部１３０は、制御部１１０によって各種の画面を表示する。表示部１３０は、ディスプレイ１６０１に対応する。通信ＩＦ部１４０は、たとえばＳＮＳサーバ２との間で通信を行うためのインターフェイスである。

【0047】

連携サーバ３は、制御部３１０と、記憶部３２０と、通信ＩＦ部３３０とを備える。制御部３１０は、通信制御部３１１と、データ消去部３１２と、暗号化部３１３と、復号化部３１４とを含む。

【0048】

制御部３１０は、連携サーバ３の全体的な動作を制御する。制御部３１０は、ＣＰＵ３５１がＨＤＤ３５４に格納された各種のプログラムを実行することにより実現される機能ブロックである。通信制御部３１１は、他の機器（ＳＮＳサーバ２、通知サーバ４等）との間の通信を制御する。記憶部３２０は、オペレーティングシステム、各種のアプリケーションプログラム、および各種のデータを記憶している。通信ＩＦ部３３０は、たとえば、ＳＮＳサーバ２との間の通信と、通知サーバ４との間の通信とを行うためのインターフェイスである。なお、制御部３１０内の各機能ブロックの処理については後述する。

【0049】

通知サーバ４は、制御部４１０と、記憶部４２０と、通信ＩＦ部４３０とを備える。制御部４１０は、通信制御部４１１と、紐付部４１２と、暗号化部４１３と、復号化部４１４とを含む。

【0050】

制御部４１０は、通知サーバ４の全体的な動作を制御する。制御部４１０は、ＣＰＵが各種のプログラムを実行することにより実現される機能ブロックである。通信制御部４１１は、他の機器（ＳＮＳサーバ２、連携サーバ３等）との間の通信を制御する。記憶部４２０は、オペレーティングシステム、各種のアプリケーションプログラム、および各種のデータを記憶している。通信ＩＦ部４３０は、たとえば、ＳＮＳサーバ２との間の通信と、連携サーバ３との間の通信と、上位サーバ５との間の通信とを行うためのインターフェイスである。なお、制御部４１０内の各機能ブロックの処理については後述する。

【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】

シーケンスＳＱ１９２において、ＳＮＳサーバ２は、複数の連携サーバから、予め紐付けされた連携サーバ（本例では、連携サーバ３）を特定する。その後、シーケンスＳＱ１９３において、ＳＮＳサーバ２は、端末装置１から受信した患者のＳＮＳのＩＤを、連携サーバ３に送信する。

【0177】

シーケンスＳＱ１９４において、連携サーバ３は、暗号化部３１３によって患者のＳＮＳのＩＤを暗号化し、かつ、当該暗号化されたＳＮＳのＩＤを記憶部３２０に一時的に記憶する。その後、通知サーバ４は、ポーリングに基づき、暗号化された患者のＳＮＳのＩＤを連携サーバ３から取得する。通知サーバ４は、暗号化された患者のＳＮＳのＩＤを取得すると、復号化部４１４によって、患者のＳＮＳのＩＤを復号化する。なお、連携サーバ３は、通知サーバ４に暗号化された患者のＳＮＳのＩＤを送信すると、暗号化された患者のＳＮＳのＩＤを記憶部３２０から削除する。

【0178】

シーケンスＳＱ１９５において、通知サーバ４は、上述したデータテーブルにおいて、当該患者のＳＮＳのＩＤに紐付けられた患者ＩＤを特定し、当該患者のＳＮＳのＩＤと当該患者ＩＤとを上記データテーブルから削除する。シーケンスＳＱ１９６において、通知サーバ４は、別の領域に保存しておいた当該患者のＳＮＳのＩＤ（データテーブルから削除されたＳＮＳのＩＤと同じＩＤ）を利用して、ＳＮＳサーバ２を介して端末装置１に対して、ＳＮＳのＩＤ登録を削除したことを示すメッセージを、当該患者の端末装置１宛（詳しくは、ＳＮＳのＩＤ宛）に送信する。詳しくは、通知サーバ４は、連携サーバ３を介さずに、ＳＮＳのＩＤ登録を削除したことを示すメッセージを送信する。

【0179】

シーケンスＳＱ１９７において、端末装置１は、受信したメッセージを表示部１３０に表示する。具体的には、端末装置は、図３２の状態（Ｂ）に示すように、ＳＮＳのＩＤ登録を削除したことを示すメッセージ１０２９を表示部１３０に表示する。このような構成によれば、端末装置１のユーザである患者は、ＳＮＳ登録が削除されたことを、端末装置１によって確認することができる。

【0180】

＜Ｇ．変形例＞
（ｇ１．送信経路）
上記の実施の形態では、たとえば図２に示したように、通知サーバ４からの患者宛の通知は、連携サーバ３を介さずに、ＳＮＳサーバ２に送られる。図１の例では、当該通知は、経路Ｐ２（図１）を介してＳＮＳサーバ２に送られる。その後、ＳＮＳサーバ２が当該通知を端末装置１に送る。

【0181】

しかしながら、患者宛の通知の送信経路は、これに限定されるものではない。通知サーバ４からの患者宛の通知は、連携サーバ３を介してＳＮＳサーバ２に送られてもよい。図１の例では、当該通知は、経路Ｐ１（図１）を介してＳＮＳサーバ２に送られてもよい。すなわち、通知サーバ４は、連携サーバ３とＳＮＳサーバ２とを介して、上述した各種の通知（第１の通知）を端末装置１宛に送信するように、ネットワークシステム９００（詳しくは、通信システム１００）を構成してもよい。

【0182】

通知サーバ４は、連携サーバ３とＳＮＳサーバ２とを介して、上述した各種の患者宛の通知（たとえば、予約情報）を端末装置１宛に送信する構成の場合、院内ネットワーク９１０からの外部への通信がＩＰアドレスを用いた通信しか許可されていないこともある。一方で、ＳＮＳサーバ２との間の通信は、通常、ＩＰ（インターネットプロトコル）アドレスを用いた通信ではなく、ドメインを用いた通信（ＨＴＴＰ通信、ＨＴＴＰＳ通信）である。

【0183】

そこで、このような場合には、院内の通知サーバ４とはＩＰアドレスを用いて通信し、院外のＳＮＳサーバ２とはドメインを用いて通信するように、連携サーバ３を構成する。たとえば、通知サーバ４から端末装置１への通知は、以下のように行われる。

【0184】

通知サーバ４は、連携サーバ３のＩＰアドレス宛に、患者宛の通知を送信する。連携サーバ３は、患者宛の通知を通知サーバ４から受信したことに基づき、ＳＮＳサーバ２のドメイン宛に当該患者宛の通知を転送する。当該患者宛の通知は、ＳＮＳサーバ２によって端末装置１に転送される。

【0185】

このような構成によれば、院内ネットワーク９１０においてＩＰアドレスを用いた通信しか行えない場合であっても、通知サーバ４は、連携サーバ３を介することにより、ＳＮＳサーバ２に対して患者宛の通知を送ることが可能となる。

【0186】

（ｇ２．サーバ）
案内表示サーバ４２に呼出サーバ４１の機能を含めることにより、２つのサーバ（案内表示サーバ４２およびに呼出サーバ４１）を１つのサーバ装置（機器）として構成してもよい。すなわち、通知サーバ４を１つのサーバ装置で構成してもよい。通知サーバ４を３つ以上のサーバ装置によって構成してもよい。同様に、連携サーバ３を２つ以上のサーバ装置で構成してもよい。

【0187】

今回開示された実施の形態は例示であって、上記内容のみに制限されるものではない。本発明の範囲は特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

【0188】

＜Ｈ．付記＞
〔項目１〕
病院内のネットワークに接続された第１のサーバと、
前記ネットワーク用のファイアウォールを介して、前記第１のサーバと通信可能な第２のサーバとを備え、
前記第１のサーバは、ソーシャルネットワーキングサービスを提供する外部サーバを介して、前記ソーシャルネットワーキングサービスを利用可能な患者の端末装置宛に前記患者宛の第１の通知を送信可能であり、
前記第２のサーバは、前記外部サーバを介して前記端末装置から第１のデータを取得した場合、前記第１のサーバから予め定められた信号を受信したことを条件に、前記第１のデータを前記第１のサーバに送信する、通信システム。

【0189】

〔項目２〕
前記第１のデータは、前記ソーシャルネットワーキングサービスによって前記患者に付与された第１の識別情報を含む、項目１に記載の通信システム。

【0190】

〔項目３〕
前記第１のデータは、前記病院によって前記患者に付与された第２の識別情報をさらに含み、
前記第１のサーバは、前記第１のデータを前記第２のサーバから取得すると、前記第１の識別情報と前記第２の識別情報とを紐付けて記憶する、項目２に記載の通信システム。

【0191】

〔項目４〕
前記第２のサーバは、前記端末装置によって前記第２の識別情報を含む２次元バーコードが読み取られたことに基づき、前記外部サーバを介して前記端末装置から前記第２の識別情報を取得する、項目３に記載の通信システム。

【0192】

〔項目５〕
前記第１のデータは、前記病院によって前記患者に一時的に付与された第３の識別情報をさらに含み、
前記第１のサーバは、
前記第１のデータを前記第２のサーバから取得すると、前記第３の識別情報に基づき、前記ネットワークを介して第３のサーバから前記病院によって前記患者に付与された第２の識別情報を取得し、
前記第１の識別情報と前記第２の識別情報とを紐付けて記憶する、項目２から４のいずれか１項に記載の通信システム。

【0193】

〔項目６〕
前記第２のサーバは、
メモリを有し、かつ、前記第１のデータを前記メモリに格納し、
前記予め定められた信号の受信に応じて前記第１のデータを前記第１のサーバに送信したことに基づき、前記メモリから前記第１のデータを削除する、項目１から５のいずれか１項に記載の通信システム。

【0194】

〔項目７〕
前記第２のサーバは、前記第１のデータを暗号化した状態で前記メモリに格納する、項目６に記載の通信システム。

【0195】

〔項目８〕
前記第１のサーバは、前記第１の通知を暗号化し、かつ、前記外部サーバを介して、前記暗号化された第１の通知を前記端末装置に送信し、
前記端末装置は、前記暗号化された第１の通知を前記第２のサーバに送信し、
前記第２のサーバは、前記暗号化された第１の通知を復号化し、かつ、前記復号化された第１の通知を前記端末装置のウェブブラウザで表示させるための第２のデータを、前記外部サーバを介さずに前記端末装置に送信する、項目１から７のいずれか１項に記載の通信システム。

【0196】

〔項目９〕
前記第１のサーバは、前記第２のサーバおよび前記外部サーバのうち前記外部サーバのみを介して、前記第１の通知を前記端末装置宛に送信する、項目１から８のいずれか１項に記載の通信システム。

【0197】

〔項目１０〕
前記第１のサーバは、前記第２のサーバと前記外部サーバとを介して、前記第１の通知を前記端末装置宛に送信する、項目１から８のいずれか１項に記載の通信システム。

【0198】

〔項目１１〕
前記第１のサーバは、前記第２のサーバのインターネットプロトコルアドレス宛に、前記第１の通知を送信し、
前記第２のサーバは、前記第１の通知を前記第１のサーバから受信したことに基づき、前記外部サーバのドメイン宛に前記第１の通知を転送し、
前記第１の通知は、前記外部サーバによって前記端末装置に転送される、項目１０に記載の通信システム。

【0199】

〔項目１２〕
前記第１の通知は、前記患者の診察の予約情報である、項目１から１１のいずれか１項に記載の通信システム。

【0200】

〔項目１３〕
前記第１のサーバは、前記ネットワークを介して第３のサーバから前記診察の会計の計算が完了したことを示す第２の通知を受信したことに基づき、前記外部サーバを介して、前記端末装置宛に、前記第１の通知として前記完了を示す通知を送信する、項目１から１１のいずれか１項に記載の通信システム。

【0201】

〔項目１４〕
前記第１のサーバは、前記ネットワークを介して第３のサーバから前記診察に基づく薬の調合が完了したことを示す第３の通知を受信したことに基づき、前記外部サーバを介して、前記端末装置宛に、前記第１の通知として前記完了を示す通知を送信する、項目１から１１のいずれか１項に記載の通信システム。

【0202】

〔項目１５〕
前記予め定められた信号は、前記第１のサーバからのポーリングによる問い合わせである、項目１から１４のいずれか１項に記載の通信システム。

【0203】

〔項目１６〕
前記第１のサーバと前記第２のサーバとの間の前記ファイアウォールを介した通信のプロコルは、ＳＦＴＰ（ＳＳＨＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）またはＨＴＴＰＳ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌＳｅｃｕｒｅ）である、項目１５に記載の通信システム。

【0204】

〔項目１７〕
前記第１のサーバと前記第２のサーバとの間の前記ファイアウォールを介した通信のプロコルは、ＷｅｂＳｏｃｋｅｔまたはＳｏｃｋｅｔである、項目１から１４のいずれか１項に記載の通信システム。

【符号の説明】

【0205】

１端末装置、２ＳＮＳサーバ、３連携サーバ、４通知サーバ、５上位サーバ、６ディスプレイ用ＰＣ、７，３５７，１６０１ディスプレイ、８情報処理端末、９再来受付機、１１ファイアウォール、１２インターネット、１３基地局装置、２１呼出システム、４１呼出サーバ、４２案内表示サーバ、５１電子カルテサーバ、５２会計用サーバ、５３薬用サーバ、９１診察券、９２受付票、１００通信システム、１３０表示部、９００ネットワークシステム、９１０院内ネットワーク、９２０院外ネットワーク、９２１２次元バーコード、１００１受付ボタン、１００２確認ボタン、１００３削除ボタン、Ｐ１，Ｐ２経路。

【図1】