JP6569471B2 - 情報処理方法、情報処理プログラム、および情報処理装置 - Google Patents

Description

本発明は、情報処理方法、情報処理プログラム、および情報処理装置に関する。

従来、医療機関の利用者は、診療を受けると当日に診療代などを支払う。先行技術としては、例えば、保険者に対して被保険者の資格情報を確認するとともに、被保険者がサービスの対象者として登録されているか否かを確認した結果に基づいて被保険者に対する医療保険自己負担分の支払いの立替えを請求するものがある。また、例えば、無線および有線の通信ネットワークの、定義された時間期間内、通常は月ごとに、加入者により累積された全体の使用量を格納することによって、後払い（ｐｏｓｔ−ｐａｉｄ）のネットワーク使用量サービスを提供する技術がある。また、例えば、１つの携帯端末から複数人のチケットの予約を行う技術がある。

特開２００４−２５２９５８号公報 特表２００９−５３８５８８号公報 特開２００２−３６６８１７号公報

例えば、家族で同じ医療機関を利用する場合に、所定の期間における家族それぞれの診療代などを、所定の支払い期限日までに家族の代表者が一括して支払うことができるようにして、医療機関の業務の効率化や利用者の利便性の向上を図ることが考えられる。しかしながら、家族それぞれの診療代などの支払いにかかる家族の代表者の負担が増大してしまう場合がある。例えば、家族の代表者は、支払い期限日までの間に自分が医療機関を利用する日がなくても医療機関を訪れて、所定の期間における家族それぞれの診療代などを一括して支払う場合がある。

１つの側面では、本発明は、複数の利用者の未払い代金の支払いにかかる負担の軽減化を図ることができる情報処理方法、情報処理プログラム、および情報処理装置を提供することを目的とする。

本発明の一側面によれば、所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、前記決済候補者に決定された前記利用者を示す情報を出力する情報処理方法、情報処理プログラム、および情報処理装置が提案される。

本発明の一態様によれば、複数の利用者の未払い代金の支払いにかかる負担の軽減化を図ることができるという効果を奏する。

図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。 図２は、まとめ支払いシステム２００の一例を示す説明図である。 図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。 図４は、クライアント装置２０１のハードウェア構成例を示すブロック図である。 図５は、端末装置２０２のハードウェア構成例を示すブロック図である。 図６は、グループ情報テーブル６００の記憶内容の一例を示す説明図である。 図７は、予定日情報テーブル７００の記憶内容の一例を示す説明図である。 図８は、支払い情報テーブル８００の記憶内容の一例を示す説明図である。 図９は、情報処理装置１００の機能的構成例を示すブロック図である。 図１０は、情報処理装置１００が各種テーブルを更新する一例を示す説明図である。 図１１は、情報処理装置１００が決済候補者を決定するパターン１の一例である。 図１２は、情報処理装置１００が決済候補者を決定するパターン２の一例である。 図１３は、情報処理装置１００が決済候補者を決定するパターン３の一例である。 図１４は、情報処理装置１００が決済候補者を決定するパターン４の一例である。 図１５は、情報処理装置１００が決済候補者を決定するパターン５の一例である。 図１６は、端末装置２０２に表示される問い合わせ画面１６００の一例を示す説明図である。 図１７は、端末装置２０２に表示される支払い要求画面１７００の一例を示す説明図である。 図１８は、決定処理手順の一例を示すフローチャートである。

以下に、図面を参照して、本発明にかかる情報処理方法、情報処理プログラム、および情報処理装置の実施の形態を詳細に説明する。

（実施の形態にかかる情報処理方法の一実施例）
図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。図１において、情報処理装置１００は、所定の施設を利用する複数の利用者のそれぞれが所定の施設を訪れる予定日を参照して、複数の利用者の未払い代金を支払う決済候補者を決定するコンピュータである。

所定の施設とは、所定の目的に用いられる場所である。所定の施設は、例えば、建物の一室、建物のフロア、建物、建物の集合体などである。所定の施設は、具体的には、薬局や病院などの医療施設である。所定の施設は、薬局や病院などの複数の医療施設が含まれるメディカルフロアや医療モールなどであってもよい。利用者とは、所定の施設を利用する者である。利用者は、例えば、医療施設を利用する患者などである。代金とは、所定の施設を利用した際に支払う金である。代金は、例えば、診療代や薬代である。複数の利用者とは、代金を一括して支払うことが可能な利用者のグループである。複数の利用者は、例えば、家族である。

ここで、従来では、家族が所定の施設を同日に利用した場合であっても、家族のそれぞれは、所定の施設の会計窓口などにおいて別々に代金を支払うことになり、所定の施設における家族の待ち時間の増大化を招いてしまう。また、利用者は、所定の施設を別日に利用した場合には、所定の施設を利用する都度、所定の施設の会計窓口などにおいて代金を支払うことになり、所定の施設の会計窓口における利用者の待ち時間の増大化を招いてしまう。

このため、所定の施設の業務の効率化を図ることにより、所定の施設を利用する利用者の待ち時間を短縮し、利用者の利便性の向上を図ることが望まれている。例えば、所定の期間における複数の利用者の代金の支払いを保留し、所定の支払い期限までに複数の利用者のうちの代表者が、複数の利用者の未払い代金を一括して支払うことができるようにすることが考えられる。

しかしながら、所定の施設にクレジットカードを用いた決済システムなどが導入されていなければ、複数の利用者のうちの代表者は所定の施設を訪れて未払い代金を支払うことになる。このため、複数の利用者のうちの代表者は、自分が所定の施設を利用しない日であっても所定の施設を訪れて、複数の利用者の未払い代金を一括して支払うことになる場合があり、未払い代金の支払いにかかる代表者の負担の増大化を招いてしまうことがある。そこで、本実施の形態では、複数の利用者のうち、複数の利用者の未払い代金を支払う決済候補者を決定することができる情報処理方法について説明する。

図１の例では、情報処理装置１００は、所定の施設を利用する複数の利用者と、複数の利用者のうちのいずれかの利用者が施設を訪れる予定日とを対応付けた予定日情報１０１を記憶する。予定日情報１０１は、例えば、医療施設を利用する家族である利用者１〜３と、家族のいずれかが医療施設を訪れる予定日とを対応付けた情報である。

（１−１）情報処理装置１００は、予定日情報１０１を参照して、複数の利用者のうち、複数の利用者の未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、未払い代金を支払う決済候補者に決定する。情報処理装置１００は、例えば、予定日情報１０１を参照して、家族である利用者１〜３のうち、ある月の家族の未払い代金についての支払い期限日になる当該月の末日以前であって、末日に最も近い予定日に医療施設を訪れる利用者２を、決済候補者に決定する。

（１−２）情報処理装置１００は、決済候補者に決定した利用者を示す情報を出力する。情報処理装置１００は、例えば、決済候補者に決定した利用者２が有する端末装置に、決済候補者に決定した旨の通知を送信する。これによれば、情報処理装置１００は、複数の利用者の未払い代金が増える可能性が低くなった月の末日に最も近い予定日に所定の施設を訪れ、未払い代金の支払いにかかる時間的な負担が相対的に少ない利用者を決済候補者に決定して出力することができる。

これにより、複数の利用者は、それぞれ、所定の施設を利用する都度、毎回代金を支払わなくてもよくなり、所定の施設の会計窓口における待ち時間を低減することができる。そして、決済候補者に決定された利用者は、支払い期限日に最も近い予定日に所定の施設に訪れたときに複数の利用者の未払い代金を一括して支払えばよく、時間的な負担の増大化を抑制することができる。このように、複数の利用者は、それぞれ、自分が所定の施設を利用する日以外には所定の施設を訪れなくてもよくなり、時間的な負担の増大化を抑制することができる。

また、所定の施設は、複数の利用者のそれぞれが所定の施設を利用する都度、毎回代金を受け取らなくてもよくなり、所定の施設の業務の効率化や利用者の利便性の向上を図ることができ、コストの低減化を図り、利用者の数の増大化を図ることができる。また、情報処理装置１００は、複数の利用者の未払い代金に関するデータの更新回数を低減化して、データ管理の効率化を図ることができる。

（まとめ支払いシステム２００のシステム構成例）
次に、図２を用いて、図１に示した情報処理装置１００を適用した、まとめ支払いシステム２００のシステム構成例について説明する。

図２は、まとめ支払いシステム２００の一例を示す説明図である。図２において、まとめ支払いシステム２００は、情報処理装置１００と、クライアント装置２０１と、端末装置２０２とを含む。まとめ支払いシステム２００において、情報処理装置１００とクライアント装置２０１とは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

ここで、まとめ支払いシステム２００は、例えば、薬局や病院などの複数の医療施設２０３〜２０５が含まれる医療モールに導入されるシステムである。まとめ支払いシステム２００は、複数の医療施設２０３〜２０５のそれぞれを利用者が訪れる予定日を管理し、複数の医療施設２０３〜２０５のそれぞれの利用者の未払い代金を管理する。

情報処理装置１００は、医療モールに設けられたコンピュータである。情報処理装置１００は、例えば、図６〜図８に後述する各種テーブルを有し、各種テーブルの情報を参照して決済候補者を決定する。情報処理装置１００は、決済候補者を示す情報を、クライアント装置２０１を介して端末装置２０２に送信する。各種テーブルは、例えば、図６〜図８に後述するグループ情報テーブル、予定日情報テーブル、支払い情報テーブルなどである。情報処理装置１００は、例えば、サーバ、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。

クライアント装置２０１は、医療モールに含まれる複数の医療施設２０３〜２０５のそれぞれに設けられたコンピュータである。クライアント装置２０１は、例えば、医療施設の利用者が有する診察券２０６を読み取り、利用者を示す情報を受け付ける。クライアント装置２０１は、受け付けた利用者の情報に対応付けて利用者が医療施設を訪れる予定日や利用者が支払いを保留した未払い代金などの情報を、情報処理装置１００に送信する。クライアント装置２０１は、決済候補者を示す情報を情報処理装置１００から受信し、端末装置２０２に転送する。クライアント装置２０１は、例えば、医療施設の医療従事者が使用するＰＣ、ノートＰＣ、タブレット型ＰＣ、スマートフォンなどである。

端末装置２０２は、医療施設の利用者が有するコンピュータである。端末装置２０２は、決済候補者を示す情報をクライアント装置２０１から受信し、図５に後述するタッチパネル５０４などに表示する。端末装置２０２は、例えば、ＰＣ、ノートＰＣ、タブレット端末、スマートフォン、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、ウェアラブル端末などである。

このように、図１に示した情報処理装置１００を適用したまとめ支払いシステム２００を医療モールに導入すれば、医療モールの利用者は、いずれかの医療施設を利用する都度、毎回代金を支払わなくてもよい。また、医療モールの利用者は、医療施設ごとに代金を支払わなくてもよく、いくつかの医療施設を利用した際の代金をいずれかの医療施設の会計窓口において一括して支払うことができる。

これにより、医療モールの利用者は、医療施設の会計窓口における待ち時間を低減することができる。そして、例えば、子供やお年寄りなどの利用者は、医療施設を訪れる際にお金を持たなくてもよくなり、利用者の安全性を向上して、利用者に安心感を与えることができる。また、医療施設は、利用者が訪れる都度、毎回代金を受け取らなくてもよく、業務の効率化や利用者の利便性の向上を図ることができる。そして、医療施設は、コストの低減化を図り、利用者の利便性の向上によって利用者の数の増大化を図ることができる。

ここでは、まとめ支払いシステム２００が、医療モールに導入される場合について説明したが、これに限らない。例えば、まとめ支払いシステム２００は、医療施設に導入される場合があってもよい。この場合、情報処理装置１００は、医療施設に設けられるコンピュータであり、医療施設に設けられたクライアント装置２０１と一体であってもよい。

（情報処理装置１００のハードウェア構成例）
次に、図３を用いて、図２に示したまとめ支払いシステム２００に含まれる情報処理装置１００のハードウェア構成例について説明する。

図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。図３において、情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、ディスクドライブ３０４と、ディスク３０５とを有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、情報処理装置１００の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。メモリ３０２は、図６〜図８に後述する各種テーブルを記憶する。

Ｉ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示したクライアント装置２０１）に接続される。そして、Ｉ／Ｆ３０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。Ｉ／Ｆ３０３は、例えば、モデムやＬＡＮアダプタである。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリード／ライトを制御する。ディスクドライブ３０４は、例えば、磁気ディスクドライブである。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発メモリである。ディスク３０５は、メモリ３０２の代わりに、図６〜図８に後述する各種テーブルを記憶してもよい。ディスク３０５は、例えば、磁気ディスク、光ディスクなどである。

情報処理装置１００は、上述した構成部のほか、例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、半導体メモリ、キーボード、マウス、ディスプレイなどを有することにしてもよい。また、情報処理装置１００は、ディスクドライブ３０４およびディスク３０５の代わりに、ＳＳＤおよび半導体メモリなどを有していてもよい。

（クライアント装置２０１のハードウェア構成例）
次に、図４を用いて、図２に示したまとめ支払いシステム２００に含まれるクライアント装置２０１のハードウェア構成例について説明する。

図４は、クライアント装置２０１のハードウェア構成例を示すブロック図である。図４において、クライアント装置２０１は、ＣＰＵ４０１と、メモリ４０２と、Ｉ／Ｆ４０３と、ディスクドライブ４０４と、ディスク４０５と、ディスプレイ４０６と、入力装置４０７と、リーダー４０８とを有する。また、各構成部はバス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、クライアント装置２０１の全体の制御を司る。メモリ４０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

Ｉ／Ｆ４０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示した情報処理装置１００）に接続される。そして、Ｉ／Ｆ４０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。Ｉ／Ｆ４０３は、例えば、モデムやＬＡＮアダプタである。

ディスクドライブ４０４は、ＣＰＵ４０１の制御に従ってディスク４０５に対するデータのリード／ライトを制御する。ディスクドライブ４０４は、例えば、磁気ディスクドライブである。ディスク４０５は、ディスクドライブ４０４の制御で書き込まれたデータを記憶する不揮発メモリである。ディスク４０５は、例えば、磁気ディスク、光ディスクなどである。

ディスプレイ４０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ４０６は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。

入力装置４０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置４０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。リーダー４０８は、磁気カードやＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カードなどからデータを読み取る。リーダー４０８は、バーコードや３次元コードからデータを読み取ってもよい。

クライアント装置２０１は、上述した構成部のうち、例えば、ディスクドライブ４０４、ディスク４０５などを有さないことにしてもよい。また、クライアント装置２０１は、上述した構成部のほか、例えば、ＳＳＤ、半導体メモリ、スキャナ、プリンタなどを有していてもよい。

ここでは、クライアント装置２０１が、リーダー４０８を有する場合について説明したが、これに限らない。例えば、リーダー４０８は、ネットワーク２１０を介して、情報処理装置１００やクライアント装置２０１と通信可能な状態で、情報処理装置１００やクライアント装置２０１とからは独立して存在してもよい。

（端末装置２０２のハードウェア構成例）
次に、図５を用いて、図２に示したまとめ支払いシステム２００に含まれる端末装置２０２のハードウェア構成例について説明する。

図５は、端末装置２０２のハードウェア構成例を示すブロック図である。図５において、端末装置２０２は、ＣＰＵ５０１と、メモリ５０２と、Ｉ／Ｆ５０３と、タッチパネル５０４とを有する。また、各構成部はバス５００によってそれぞれ接続される。

ここで、ＣＰＵ５０１は、端末装置２０２の全体の制御を司る。メモリ５０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ５０１のワークエリアとして使用される。メモリ５０２に記憶されるプログラムは、ＣＰＵ５０１にロードされることで、コーディングされている処理をＣＰＵ５０１に実行させる。

Ｉ／Ｆ５０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示したクライアント装置２０１）に接続される。そして、Ｉ／Ｆ５０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。Ｉ／Ｆ５０３は、例えば、モデムやＬＡＮアダプタである。

タッチパネル５０４は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示するとともに、ユーザの身体やタッチペンなどを用いた接触を感知することによりデータの入力を行う。タッチパネルは、例えば、静電容量方式のパネルである。端末装置２０２は、上述した構成部のほか、例えば、ディスクドライブ、ディスク、ＳＳＤ、半導体メモリ、スキャナ、プリンタなどを有することにしてもよい。端末装置２０２は、上述したタッチパネル５０４の代わりに、入力装置やディスプレイを有していてもよい。

（各種テーブルの記憶内容）
次に、図６〜図８を用いて、情報処理装置１００が有する各種テーブルの記憶内容について説明する。各種テーブルは、例えば、図３に示した情報処理装置１００のメモリ３０２、ディスク３０５などの記憶領域により実現される。

〈グループ情報テーブル６００の記憶内容〉
図６は、グループ情報テーブル６００の記憶内容の一例を示す説明図である。図６に示すように、グループ情報テーブル６００は、患者ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）、支払いグループＩＤ、患者情報、支払い適格フラグのフィールドを有する。患者情報のフィールドは、氏名、住所、メールアドレス、連絡先番号のフィールドの組み合わせである。グループ情報テーブル６００は、患者ごとに各フィールドに情報を設定することにより、グループ情報をレコード６００−ａとして記憶する。ａは、任意の整数である。

ここで、患者ＩＤとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループＩＤとは、複数の患者が所属するグループを一意に識別する識別情報であって、患者ＩＤによって識別される患者が所属するグループの識別情報である。支払いグループＩＤは、支払いグループＩＤによって識別されるグループに所属する複数の患者の未払い代金について一括して支払うことが可能であることを示す。

患者情報とは、患者ＩＤによって識別される患者に関する情報である。氏名とは、患者ＩＤによって識別される患者の氏名である。住所とは、患者ＩＤによって識別される患者の住所である。メールアドレスとは、患者ＩＤによって識別される患者が有する端末装置２０２のメールアドレスである。連絡先番号とは、患者ＩＤによって識別される患者が有する端末装置２０２の電話番号である。

支払い適格フラグとは、患者ＩＤによって識別される患者が、支払いグループＩＤによって識別されるグループに所属する複数の患者の未払い代金を一括して支払う決済候補者になりうるか否かを示す情報である。支払い適格フラグは、例えば、患者ＩＤによって識別される患者が、決済候補者に設定された代表者である場合には、「１」である。支払い適格フラグは、例えば、患者ＩＤによって識別される患者が、決済候補者を代表者から変更するときに変更先になりうる患者である場合には、「２〜」である。支払い適格フラグは、例えば、患者ＩＤによって識別される患者が、決済候補者にならない患者である場合には、「０」である。

例えば、レコード６００−１は、患者ＩＤ「１００００１」、支払いグループＩＤ「０００００１」、氏名「○○ 一郎」、住所「○○県××市△△」、メールアドレス「Ａｄｄ１」、連絡先番号「Ｔｅｌ１」、支払い適格フラグ「１」を対応付けた情報である。

〈予定日情報テーブル７００の記憶内容〉
図７は、予定日情報テーブル７００の記憶内容の一例を示す説明図である。図７に示すように、予定日情報テーブル７００は、患者ＩＤ、支払いグループＩＤ、施設名称、次回予定日のフィールドを有する。予定日情報テーブル７００は、患者ごとに各フィールドに情報を設定することにより、予定日情報をレコード７００−ｂとして記憶する。ｂは、任意の整数である。

ここで、患者ＩＤとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループＩＤは、複数の患者が所属するグループを一意に識別する識別情報であって、患者ＩＤによって識別される患者が所属するグループの識別情報である。施設名称とは、患者ＩＤによって識別される患者が訪れる薬局や病院などの医療施設の名称である。次回予定日とは、患者ＩＤによって識別される患者が、施設名称が示す医療施設を訪れる予定がある日付である。次回予定日は、未定である場合には「０」である。

例えば、レコード７００−１は、患者ＩＤ「１００００１」、支払いグループＩＤ「０００００１」、施設名称「内科△△」、次回予定日「０」を対応付けた予定日情報である。また、例えば、レコード７００−２は、患者ＩＤ「１００００１」、支払いグループＩＤ「０００００１」、施設名称「耳鼻科◇◇」、次回予定日「２０１５／３／２２」を対応付けた予定日情報である。

〈支払い情報テーブル８００の記憶内容〉
図８は、支払い情報テーブル８００の記憶内容の一例を示す説明図である。図８に示すように、支払い情報テーブル８００は、患者ＩＤ、支払いグループＩＤ、施設名称、診察日付、金額、決済フラグのフィールドを有する。支払い情報テーブル８００は、患者ごとに各フィールドに情報を設定することにより、支払い情報をレコード８００−ｃとして記憶する。ｃは、任意の整数である。

ここで、患者ＩＤとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループＩＤは、複数の患者が所属するグループを一意に識別する識別情報であって、患者ＩＤによって識別される患者が所属するグループの識別情報である。施設名称とは、患者ＩＤによって識別される患者が訪れる薬局や病院などの医療施設の名称である。

診察日付とは、患者ＩＤによって識別される患者が、施設名称が示す医療施設において診察された日付である。金額とは、診察日付が示す日時に患者が診察されたことにより発生した診療代の額である。決済フラグとは、診療代が未払いか否かのフラグである。決済フラグは、例えば、診療代が未払いであることを示す「未」である。また、決済フラグは、例えば、診療代が支払い済みであることを示す「済」である。

例えば、レコード８００−１は、患者ＩＤ「１００００１」、支払いグループＩＤ「０００００１」、施設名称「内科△△」、診察日付「２０１５／３／１」、金額「７５０」、決済フラグ「未」を対応付けた支払い情報である。

（情報処理装置１００の機能的構成例）
次に、図９を用いて、情報処理装置１００の機能的構成例について説明する。

図９は、情報処理装置１００の機能的構成例を示すブロック図である。図９において、情報処理装置１００は、記憶部９０１と、検出部９０２と、決定部９０３と、出力部９０４とを含む構成である。記憶部９０１は、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶領域によって実現される。検出部９０２〜出力部９０４は、制御部となる機能であり、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶領域に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶領域に記憶される。

記憶部９０１は、所定の施設を利用する複数の利用者のそれぞれに関する情報を記憶する。ここで、所定の施設は、例えば、薬局や病院などの医療施設、または、薬局や病院などの複数の医療施設２０３〜２０５が含まれるメディカルフロアや医療モールなどである。利用者は、例えば、医療施設を利用する患者などである。代金は、例えば、診療代や薬代である。複数の利用者は、代金を一括して支払うことが可能にされた家族である。記憶部９０１は、例えば、グループ化された家族のそれぞれに関する情報が含まれるグループ情報テーブル６００を記憶する。これにより、記憶部９０１は、どの複数の利用者の未払い代金を一括して支払うことが可能か否かを示す情報を記憶することができる。

記憶部９０１は、複数の利用者と、複数の利用者のうちのいずれかの利用者が施設を訪れる予定日とを対応付けた予定日情報を記憶する。複数の利用者のうちの第１の利用者は、決済候補者に設定されていてもよい。第１の利用者とは、複数の利用者のうちの代表者である。記憶部９０１は、例えば、家族のそれぞれと、家族のうちのいずれかが医療施設を訪れる予定日とを対応付けた予定日情報テーブル７００を記憶する。これにより、記憶部９０１は、どの利用者を、決済候補者を決定する指標となる情報を記憶することができる。

記憶部９０１は、複数の利用者の未払い代金を記憶する。記憶部９０１は、例えば、所定の期間における複数の利用者の未払い代金を含む支払い情報テーブル８００を記憶する。所定の期間とは、支払いが保留された未払い代金をまとめる期間であって、当該期間内に支払いが保留された未払い代金について一括して支払うことが可能になる期間である。所定の期間は、例えば、予め設定されたまとめ支払い期間である。所定の期間は、具体的には、月である。記憶部９０１は、例えば、一月の家族のそれぞれの未払い代金を含む支払い情報テーブル８００を記憶する。これにより、記憶部９０１は、一括して支払うことができる複数の利用者の未払い代金の額を記憶することができる。

検出部９０２は、記憶部９０１に記憶された予定日情報を参照して、第１の利用者の予定日になったことを検出する。検出部９０２は、例えば、記憶部９０１に記憶された予定日情報テーブル７００を参照して、現在の日が、複数の利用者のうちの代表者の予定日であることを検出して、検出した結果を決定部９０３に出力する。これにより、検出部９０２は、決定部９０３に処理を開始させるトリガーを検出することができる。

検出部９０２は、支払い期限日以前である所定の日になったことを検出する。ここで、支払い期限日とは、支払いを保留した未払い代金を支払う期限である。支払い期限日は、例えば、所定の期間の末日である。支払い期限日は、具体的には、月の末日である。検出部９０２は、例えば、月の初日になったことを検出する。また、検出部９０２は、月の２０日になったことを検出してもよい。これにより、検出部９０２は、決定部９０３に処理を開始させるトリガーを検出することができる。

決定部９０３は、記憶部９０１に記憶された予定日情報を参照して、複数の利用者の未払い代金を支払う決済候補者を決定する。決定部９０３は、例えば、記憶部９０１に記憶された予定日情報テーブル７００を参照して、複数の利用者のうち、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、決済候補者に決定する。以下の説明では、複数の利用者のうち、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を「最後の利用者」と表記する場合がある。

これにより、決定部９０３は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、決定部９０３は、複数の利用者のいずれかが複数の利用者の未払い代金を支払うためだけに所定の施設に来院しなくてもよくすることができる。

決定部９０３は、例えば、記憶部９０１に記憶されたグループ情報テーブル６００を参照して、複数の利用者のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を複数の利用者のうちの最後の利用者に決定する。これにより、決定部９０３は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。

決定部９０３は、例えば、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、より遅い時刻に訪れる利用者を決済候補者に決定する。これにより、決定部９０３は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。

決定部９０３は、複数の利用者のうちの第１の利用者が決済候補者に設定されている場合には、予定日情報を参照して、決済候補者を第１の利用者のままにするか、または、決済候補者を第１の利用者から他の利用者に変更するようにしてもよい。これにより、情報処理装置１００は、決済候補者を変更しない場合には、複数の利用者に決済候補者を通知しなくてもよく、複数の利用者の負担を軽減することができる。

決定部９０３は、例えば、記憶部９０１に記憶された予定日情報テーブル７００を参照して、複数の利用者のうち、代表者の予定日よりも、代表者とは異なる他の利用者の予定日の方が、支払い期限日以前であって支払い期限日に近いか否かを判定する。そして、決定部９０３は、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、決済候補者を代表者から、複数の利用者のうちの最後の利用者に変更する。これにより、決定部９０３は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。

決定部９０３は、例えば、記憶部９０１に記憶された予定日情報テーブル７００を参照して、代表者の予定日がない場合には、決済候補者を代表者から最後の利用者に変更する。これにより、決定部９０３は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。

決定部９０３は、例えば、さらに、最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を代表者から最後の利用者に変更する。これにより、決定部９０３は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。

決定部９０３は、例えば、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、決済候補者を、より遅い時刻に訪れる利用者に変更する。これにより、決定部９０３は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。

決定部９０３は、決済候補者の変更先にした最後の利用者が、未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信した結果に応じて、決済候補者を第１の利用者から他の利用者に変更するようにしてもよい。ここで、問い合わせは、例えば、最後の利用者を示す情報、最後の利用者の予定日、未払い代金に関する情報を含む。これにより、決定部９０３は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。

決定部９０３は、例えば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信する。そして、決定部９０３は、問い合わせを送信した結果、最後の利用者が未払い代金を支払うことを許可する応答を端末装置２０２から受信したことに応じて、決済候補者を代表者から最後の利用者に変更する。これにより、決定部９０３は、決済候補者を代表者から最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から最後の利用者に変更するか否かを判断することができる。

決定部９０３は、例えば、代表者の予定日がないと判定した場合には、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信する。そして、決定部９０３は、問い合わせを送信した結果、最後の利用者が未払い代金を支払うことを許可する応答を端末装置２０２から受信したことに応じて、決済候補者を代表者から最後の利用者に変更する。これにより、決定部９０３は、決済候補者を代表者から最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から最後の利用者に変更するか否かを判断することができる。

決定部９０３は、例えば、さらに、最後の利用者が未払い代金の支払い適格を満たしている場合に、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、第１の利用者に対応する端末装置２０２に送信してもよい。これにより、情報処理装置１００は、予め支払い適格を有さないと設定された利用者についての問い合わせに代表者が応対しなくてよいようにして、代表者の負担を軽減することができる。

決定部９０３は、例えば、さらに、検出部９０２が代表者の予定日になったことを検出した場合に、決済候補者を決定する。これにより、決定部９０３は、少なくとも代表者の予定日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。

決定部９０３は、さらに、支払い期限日以前である所定の日になった場合に、決済候補者を決定する。これにより、決定部９０３は、少なくとも所定の日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。

決定部９０３は、例えば、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、より遅い時刻に訪れる利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信する。これにより、決定部９０３は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者の変更先にすることができる。

出力部９０４は、決済候補者に決定した利用者を示す情報を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、Ｉ／Ｆ３０３による外部装置への送信、メモリ３０２、ディスク３０５などの記憶領域への記憶がある。

出力部９０４は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者に対応する端末装置２０２に未払い代金の支払い要求を送信する。ここで、支払い要求は、例えば、最後の利用者を示す情報、最後の利用者の予定日、未払い代金に関する情報を含む。これにより、出力部９０４は、決済候補者にした利用者に、自分が決済候補者になったことを把握させることができる。

出力部９０４は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者への連絡先情報を出力してもよい。連絡先情報は、例えば、メールアドレスである。出力部９０４は、具体的には、最後の利用者への連絡先情報を情報処理装置１００のディスプレイに表示する。これにより、出力部９０４は、決済候補者にした利用者に決済候補者になったことを連絡可能にすることができる。例えば、情報処理装置１００のユーザは、情報処理装置１００のディスプレイに表示された連絡先情報を参照して、決済候補者にされた利用者に決済候補者になったことを連絡することができる。

また、出力部９０４は、具体的には、最後の利用者への連絡先情報を、クライアント装置２０１に送信してクライアント装置２０１のディスプレイ４０６に表示させてもよい。これにより、出力部９０４は、決済候補者にした利用者に自分が決済候補者になったことを連絡可能にすることができる。例えば、クライアント装置２０１のユーザは、クライアント装置２０１のディスプレイ４０６に表示された連絡先情報を参照して、決済候補者にされた利用者に決済候補者になったことを連絡することができる。

出力部９０４は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者を示す情報や最後の利用者の予定日などを出力してもよい。出力部９０４は、具体的には、決済候補者にされた最後の利用者を示す情報や最後の利用者の予定日などを、クライアント装置２０１に送信してクライアント装置２０１のディスプレイ４０６に表示させてもよい。これにより、出力部９０４は、決済候補者にした利用者に自分が決済候補者になったことを連絡可能にすることができる。例えば、クライアント装置２０１のユーザは、決済候補者にされた最後の利用者を示す情報や最後の利用者の予定日などを参照して、最後の利用者が所定の施設を訪れた際に決済候補者になったことを連絡することができる。

（各種テーブルを更新する一例）
次に、図１０を用いて、情報処理装置１００が各種テーブルを更新する一例について説明する。各種テーブルは、例えば、図６〜図８に示したグループ情報テーブル６００、予定日情報テーブル７００、支払い情報テーブル８００などである。

図１０は、情報処理装置１００が各種テーブルを更新する一例を示す説明図である。図１０の例では、利用者が医療施設を訪れた際に、グループ情報テーブル６００の更新作業、予定日情報テーブル７００の更新作業、支払い情報テーブル８００の更新作業などが行われる。

〈グループ情報テーブル６００の更新作業〉
例えば、利用者は、医療モールに含まれる医療施設を訪れると、家族のそれぞれの患者情報や支払い適格の有無を記載した申込用紙を医療施設の医療従事者に渡したり、クライアント装置２０１のリーダー４０８に家族の診察券２０６などを読み取らせる。これにより、利用者は、自分を含む家族などの複数の利用者について、まとめ支払い期間内の未払い代金を一括して支払うことを可能にするために用いる情報を、情報処理装置１００に送信してもらう。

クライアント装置２０１は、申込用紙に基づく医療施設の医療従事者の操作入力を受け付けたり、リーダー４０８によって診察券２０６などを読み取ることにより、家族のそれぞれの患者情報や支払い適格の有無を取得する。クライアント装置２０１は、取得した患者情報や支払い適格の有無を含むグループ情報テーブル６００の更新要求を、情報処理装置１００に送信する。

情報処理装置１００は、グループ情報テーブル６００の更新要求を受信すると、グループ情報テーブル６００の更新要求から家族のそれぞれの患者情報を抽出する。情報処理装置１００は、抽出した家族のそれぞれの患者情報や支払い適格の有無に、患者ＩＤ、支払いグループＩＤを対応付けたレコードを生成して、グループ情報テーブル６００に追加する。

ここでは、利用者が医療施設を訪れた際に、グループ情報テーブル６００の更新作業が行われる場合について説明したが、これに限らない。例えば、利用者は、端末装置２０２を介して、クライアント装置２０１に、家族のそれぞれの患者情報や支払い適格の有無を送信してもよい。また、クライアント装置２０１がグループ情報テーブル６００の更新要求を情報処理装置１００に送信する場合について説明したが、これに限らない。例えば、端末装置２０２が、利用者の操作入力によって、患者情報や支払い適格の有無を含むグループ情報テーブル６００の更新要求を、情報処理装置１００に送信してもよい。

〈予定日情報テーブル７００の更新作業〉
また、例えば、利用者は、医療モールに含まれる医療施設を訪れると、医療施設の医療従事者と相談して次回予定日を医療施設の医療従事者に通知したり、医療施設に設けられたクライアント装置２０１のリーダー４０８に利用者の診察券２０６などを読み取らせる。医療施設の医療従事者が、空いている日を利用者に確認して、利用者の次回予定日を決定してもよい。

クライアント装置２０１は、医療施設の医療従事者の操作入力を受け付けたり、リーダー４０８によって診察券２０６などを読み取ることにより、利用者の患者情報や次回予定日を取得する。クライアント装置２０１は、取得した利用者の患者情報や次回予定日を含む予定日情報テーブル７００の更新要求を、情報処理装置１００に送信する。

情報処理装置１００は、予定日情報テーブル７００の更新要求を受信すると、予定日情報テーブル７００の更新要求から利用者の患者情報や次回予定日を抽出する。情報処理装置１００は、グループ情報テーブル６００を参照して、抽出した利用者の患者情報に対応する患者ＩＤと支払いグループＩＤとを特定する。情報処理装置１００は、抽出した利用者の患者情報や次回予定日に、特定した患者ＩＤと支払いグループＩＤとを対応付けたレコードを生成して、予定日情報テーブル７００に追加する。

ここでは、利用者が医療施設を訪れた際に、予定日情報テーブル７００の更新作業が行われる場合について説明したが、これに限らない。例えば、利用者は、端末装置２０２を介して、クライアント装置２０１に、利用者の患者情報や次回予定日を送信してもよい。利用者は、電話などによって、医療施設の医療従事者と相談して次回予定日を医療施設の医療従事者に通知してもよい。

〈支払い情報テーブル８００の更新作業〉
また、例えば、利用者は、医療モールに含まれる医療施設を訪れると、クライアント装置２０１のリーダー４０８に利用者の診察券２０６などを読み取らせたり、医療施設の会計窓口において利用者を含む家族の未払い代金を医療従事者に一括して支払う。

クライアント装置２０１は、医療施設の医療従事者の操作入力を受け付けたり、リーダー４０８によって診察券２０６などを読み取ることにより、家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付などを取得する。クライアント装置２０１は、取得した家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付を含む支払い情報テーブル８００の更新要求を、情報処理装置１００に送信する。

情報処理装置１００は、支払い情報テーブル８００の更新要求を受信すると、支払い情報テーブル８００の更新要求から家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付を抽出する。情報処理装置１００は、グループ情報テーブル６００を参照して、抽出した利用者の患者情報に対応する患者ＩＤと支払いグループＩＤとを特定する。情報処理装置１００は、支払い情報テーブル８００のうち、抽出した代金が支払われた診察が行われた医療施設名や診察日付に、特定した患者ＩＤと支払いグループＩＤとを対応付けたレコードの決済フラグを「済」に変更する。

（決済候補者を決定するパターンの一例）
次に、図１１〜図１５を用いて、情報処理装置１００が決済候補者を決定するパターンの一例について説明する。

図１１は、情報処理装置１００が決済候補者を決定するパターン１の一例である。図１１の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がある場合について、情報処理装置１００が決済候補者を決定するパターン１について説明する。また、図１１の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もあるとする。

図１１において、情報処理装置１００は、まとめ支払い期間の初日になったことを検出する。まとめ支払い期間は、例えば、月である。まとめ支払い期間の初日は、例えば、月初めである。情報処理装置１００は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル７００を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。情報処理装置１００は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるため、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日まで待機する。

そして、情報処理装置１００は、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日になったことを検出する。情報処理装置１００は、まとめ支払い期間内、かつ、代表者「○○ 一郎」の最も後ろの予定日以降に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置１００は、他の利用者の予定日がないため、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。

図１２は、情報処理装置１００が決済候補者を決定するパターン２の一例である。図１２の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がある場合について、情報処理装置１００が決済候補者を決定するパターン２について説明する。また、図１２の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もあるとする。

図１２において、情報処理装置１００は、まとめ支払い期間の初日になったことを検出する。情報処理装置１００は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル７００を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。情報処理装置１００は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるため、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日まで待機する。

そして、情報処理装置１００は、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日になったことを検出する。情報処理装置１００は、まとめ支払い期間内、かつ、代表者「○○ 一郎」の最も後ろの予定日以降に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置１００は、他の利用者「○○ 花子」や「○○ 太郎」の予定日があるため、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。

情報処理装置１００は、決済候補者の変更先を特定すると、グループ情報テーブル６００を参照して、代表者「○○ 一郎」のメールアドレスを取得する。情報処理装置１００は、取得したメールアドレスに基づいて、決済候補者の変更先として特定した利用者「○○ 花子」が未払い代金を決済することを許可するか否かの問い合わせを生成する。そして、情報処理装置１００は、生成した問い合わせを代表者「○○ 一郎」の端末装置２０２に送信し、端末装置２０２に問い合わせ画面１６００を表示させる。

問い合わせは、例えば、問い合わせ画面１６００の画面情報を含む。問い合わせ画面１６００の画面情報は、例えば、決済候補者の変更先として特定した利用者「○○ 花子」の情報などを含む。また、問い合わせ画面１６００の画面情報は、例えば、予定日情報テーブル７００に記憶された家族のそれぞれに対応する予定日情報、支払い情報テーブル８００に記憶された家族のそれぞれに対応する支払い情報などを含む。端末装置２０２に表示される問い合わせ画面１６００の内容については、図１６を用いて後述する。

ここでは、情報処理装置１００が、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する場合について説明したが、これに限らない。例えば、情報処理装置１００は、グループ情報テーブル６００を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」の支払い適格の有無を判定してもよい。

そして、情報処理装置１００は、支払い適格がある場合には、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。一方で、情報処理装置１００は、支払い適格がない場合には、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。

図１３は、情報処理装置１００が決済候補者を決定するパターン３の一例である。図１３の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がない場合について、情報処理装置１００が決済候補者を決定するパターン３について説明する。また、図１３の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日があるとする。

図１３において、情報処理装置１００は、まとめ支払い期間の初日になったことを検出する。情報処理装置１００は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル７００を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。

情報処理装置１００は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にないため、まとめ支払い期間内に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置１００は、他の利用者「○○ 花子」や「○○ 太郎」の予定日があるため、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。

情報処理装置１００は、決済候補者の変更先を特定すると、グループ情報テーブル６００を参照して、代表者「○○ 一郎」のメールアドレスを取得する。情報処理装置１００は、取得したメールアドレスに基づいて、決済候補者の変更先として特定した利用者「○○ 花子」が未払い代金を決済することを許可するか否かの問い合わせを生成する。そして、情報処理装置１００は、生成した問い合わせを、代表者「○○ 一郎」の端末装置２０２に送信し、端末装置２０２に問い合わせ画面１６００を表示させる。

ここでは、情報処理装置１００が、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する場合について説明したが、これに限らない。例えば、情報処理装置１００は、グループ情報テーブル６００を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」の支払い適格の有無を判定してもよい。

そして、情報処理装置１００は、支払い適格がある場合には、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。一方で、情報処理装置１００は、支払い適格がない場合には、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。

図１４は、情報処理装置１００が決済候補者を決定するパターン４の一例である。図１４の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がない場合について、情報処理装置１００が決済候補者を決定するパターン４について説明する。また、図１４の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もないとする。

図１４において、情報処理装置１００は、まとめ支払い期間の初日になったことを検出する。情報処理装置１００は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル７００を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。

情報処理装置１００は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にないため、まとめ支払い期間内に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置１００は、他の利用者の予定日がないため、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。

情報処理装置１００は、パターン１〜４のように決済候補者が決定された後、いずれかの利用者の予定日が新たに決まり、予定日情報テーブル７００に予定日情報が追加された場合には、改めて決済候補者を決定する。これにより、情報処理装置１００は、最新の予定日情報テーブル７００に基づいて、複数の利用者のうちの最後の利用者が決済候補者になるようにすることができる。

図１５は、情報処理装置１００が決済候補者を決定するパターン５の一例である。図１５の例では、予め決済候補者が設定されていない場合について、情報処理装置１００が決済候補者を決定するパターン５について説明する。

図１５において、情報処理装置１００は、まとめ支払い期間の初日になったことを検出する。情報処理装置１００は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル７００を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者に決定する。

情報処理装置１００は、決済候補者を決定すると、グループ情報テーブル６００を参照して、決済候補者に決定した利用者「○○ 花子」のメールアドレスを取得する。情報処理装置１００は、取得したメールアドレスに基づいて、未払い代金に関する情報を、決済候補者に決定した利用者「○○ 花子」の端末装置２０２に送信し、端末装置２０２に表示させる。

（端末装置２０２に表示される問い合わせ画面１６００の一例）
次に、図１６を用いて、端末装置２０２に表示される問い合わせ画面１６００の一例について説明する。

図１６は、端末装置２０２に表示される問い合わせ画面１６００の一例を示す説明図である。端末装置２０２は、問い合わせを受信すると、問い合わせに含まれる問い合わせ画面１６００の画面情報に基づいて問い合わせ画面１６００を表示する。問い合わせ画面１６００は、代表者の予定日に関する表示欄１６０１と、過去の未払い代金に関する表示欄１６０２と、未来の支払いに関する表示欄１６０３と、承認ボタン１６０４と、却下ボタン１６０５とを含む画面である。

代表者「○○ 一郎」は、端末装置２０２の表示内容を参照して、利用者「○○ 花子」が未払い代金を決済することを許可する場合には、端末装置２０２を操作して承認ボタン１６０４をクリックする。端末装置２０２は、承認ボタン１６０４がクリックされた場合、利用者「○○ 花子」が未払い代金を決済することを許可する応答を、情報処理装置１００に送信する。

一方で、代表者「○○ 一郎」は、端末装置２０２の表示内容を参照して、利用者「○○ 花子」が未払い代金を決済することを許可しない場合には、端末装置２０２を操作して却下ボタン１６０５をクリックする。端末装置２０２は、却下ボタン１６０５がクリックされた場合、利用者「○○ 花子」が未払い代金を決済することを許可しない応答を、情報処理装置１００に送信する。

情報処理装置１００は、問い合わせを送信した結果、利用者「○○ 花子」が未払い代金を決済することを許可する応答を代表者「○○ 一郎」の端末装置２０２から受信した場合には、決済候補者を「○○ 花子」に変更する。情報処理装置１００は、決済候補者を変更すると、グループ情報テーブル６００を参照して、決済候補者にした利用者「○○ 花子」のメールアドレスを取得する。情報処理装置１００は、取得したメールアドレスに基づいて、家族のそれぞれの未払い代金の支払い要求を、決済候補者にした利用者「○○ 花子」の端末装置２０２に送信し、端末装置２０２に支払い要求画面１７００を表示させる。

支払い要求は、例えば、支払い要求画面１７００の画面情報を含む。支払い要求画面１７００の画面情報は、例えば、決済候補者にした利用者「○○ 花子」の情報などを含む。また、支払い要求画面１７００の画面情報は、例えば、予定日情報テーブル７００に記憶された家族のそれぞれに対応する予定日情報、支払い情報テーブル８００に記憶された家族のそれぞれに対応する支払い情報などを含む。端末装置２０２に表示される支払い要求画面１７００の内容については、図１７を用いて後述する。

一方で、情報処理装置１００は、問い合わせを送信した結果、利用者「○○ 花子」が未払い代金を決済することを許可しない応答を代表者「○○ 一郎」の端末装置２０２から受信した場合には、決済候補者を代表者「○○ 一郎」のままにしておく。これにより、代表者「○○ 一郎」は、利用者「○○ 花子」に未払い代金の支払いを委任しても問題がないか否かを判断して、情報処理装置１００に応答を返すことができる。

このため、情報処理装置１００は、利用者「○○ 花子」に未払い代金の支払いを委任して問題がある場合に、利用者「○○ 花子」を決済候補者に決定してしまうことを防止することができる。例えば、情報処理装置１００は、利用者「○○ 花子」が子供であって、代表者「○○ 一郎」が利用者「○○ 花子」にお金を預けることに不安がある場合に、利用者「○○ 花子」を決済候補者に決定してしまうことを防止することができる。

（端末装置２０２に表示される支払い要求画面１７００の一例）
次に、図１７を用いて、端末装置２０２に表示される支払い要求画面１７００の一例について説明する。

図１７は、端末装置２０２に表示される支払い要求画面１７００の一例を示す説明図である。端末装置２０２は、問い合わせを受信すると、問い合わせに含まれる支払い要求画面１７００の画面情報に基づいて支払い要求画面１７００を表示する。支払い要求画面１７００は、決済候補者にした利用者の予定日に関する表示欄１７０１と、過去の未払い代金に関する表示欄１７０２と、未来の支払いに関する表示欄１７０３とを含む画面である。

利用者「○○ 花子」は、端末装置２０２の表示内容を参照して、次回予定日に医療施設を訪れた際に併せて、家族のそれぞれの未払い代金を一括して支払う。これにより、代表者「○○ 一郎」は、家族のそれぞれの未払い代金を支払うために、自分が医療施設を利用しない日に、医療施設を訪れなくてもよく、時間的な負担を軽減することができる。また、利用者「○○ 花子」は、自分が医療施設を訪れた日に併せて、家族のそれぞれの未払い代金を支払えばよく、家族のそれぞれの未払い代金を支払う際にかかる負担の増大化を抑制することができる。

（決定処理手順の一例）
次に、図１８を用いて、情報処理装置１００によって実行される決定処理手順の一例について説明する。

図１８は、決定処理手順の一例を示すフローチャートである。図１８において、情報処理装置１００は、現在の日が、まとめ支払い期間の初日であるか否かを判定する（ステップＳ１８０１）。ここで、初日ではない場合（ステップＳ１８０１：Ｎｏ）、情報処理装置１００は、予定日情報テーブル７００に記憶された予定日情報が更新されたか否かを判定する（ステップＳ１８０２）。

ここで、予定日情報が更新されていない場合（ステップＳ１８０２：Ｎｏ）、情報処理装置１００は、ステップＳ１８０１の処理に戻る。一方で、初日である場合（ステップＳ１８０１：Ｙｅｓ）、または、予定日情報が更新された場合（ステップＳ１８０２：Ｙｅｓ）、情報処理装置１００は、ステップＳ１８０３の処理に移行する。

ステップＳ１８０３では、情報処理装置１００は、予定日情報テーブル７００を参照して、代表者の予定日が、現在の日以降のまとめ支払い期間内にあるか否かを判定する（ステップＳ１８０３）。ここで、代表者の予定日が、現在の日以降のまとめ支払い期間内にある場合（ステップＳ１８０３：Ｙｅｓ）、情報処理装置１００は、ステップＳ１８０４の処理に移行する。

ステップＳ１８０４では、情報処理装置１００は、グループに所属する、代表者とは異なる他の利用者の予定日が、代表者の予定日より後ろであって、かつ、現在の日以降のまとめ支払い期間内にあるか否かを判定する（ステップＳ１８０４）。ここで、他の利用者の予定日が、代表者の予定日より後ろであって、かつ、現在の日以降のまとめ支払い期間内にある場合（ステップＳ１８０４：Ｙｅｓ）、情報処理装置１００は、ステップＳ１８０５の処理に移行する。

ステップＳ１８０５では、情報処理装置１００は、決済候補者を、代表者から、グループに所属する複数の利用者のうち、まとめ支払い期間内であって最も後ろにある予定日に施設を訪れる利用者に変更する（ステップＳ１８０５）。このとき、情報処理装置１００は、代表者に対応する端末装置に問い合わせを送信し、端末装置からの応答に応じて決済候補者を変更してもよい。そして、情報処理装置１００は、決定処理を終了する。

一方で、他の利用者の予定日が、代表者の予定日より前であるか、または、現在の日以降のまとめ支払い期間内にない場合（ステップＳ１８０４：Ｎｏ）、情報処理装置１００は、決済候補者を代表者から変更せずに、決定処理を終了する。

一方で、ステップＳ１８０３において、代表者の予定日が、現在の日以降のまとめ支払い期間内にない場合（ステップＳ１８０３：Ｎｏ）、情報処理装置１００は、ステップＳ１８０６の処理に移行する。

ステップＳ１８０６では、情報処理装置１００は、グループに所属する、代表者とは異なる他の利用者の予定日が、現在の日以降のまとめ支払い期間内にあるか否かを判定する（ステップＳ１８０６）。ここで、他の利用者の予定日が、現在の日以降のまとめ支払い期間内にある場合（ステップＳ１８０６：Ｙｅｓ）、情報処理装置１００は、ステップＳ１８０７の処理に移行する。

ステップＳ１８０７では、情報処理装置１００は、決済候補者を、代表者から、グループに所属する複数の利用者のうち、まとめ支払い期間内であって最も後ろにある予定日に施設を訪れる利用者に変更する（ステップＳ１８０７）。このとき、情報処理装置１００は、代表者に対応する端末装置に問い合わせを送信し、端末装置からの応答に応じて決済候補者を変更してもよい。そして、情報処理装置１００は、決定処理を終了する。

一方で、他の利用者の予定日が、現在の日以降のまとめ支払い期間内にない場合（ステップＳ１８０６：Ｎｏ）、情報処理装置１００は、決済候補者を代表者から変更せずに、決定処理を終了する。これにより、情報処理装置１００は、決済候補者を変更することができる。

以上説明したように、情報処理装置１００によれば、家族のうち、家族の未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、未払い代金を支払う決済候補者に決定することができる。これにより、情報処理装置１００は、家族の誰かが、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。また、所定の施設は、利用者が来院する都度、利用者から代金を受け取らなくてもよくなり、会計窓口の業務を効率化することができる。

また、情報処理装置１００によれば、家族のうちの代表者が、決済候補者に設定されている場合には、代表者の予定日よりも、家族のうちの他の利用者の予定日の方が、支払い期限日以前であって支払い期限日に近いか否かを判定することができる。そして、情報処理装置１００によれば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、決済候補者を代表者から、家族のうちで、支払い期限日以前、かつ、支払い期限日に最も近い予定日に施設を訪れる最後の利用者に変更することができる。

これにより、情報処理装置１００は、支払い期限日以前であって、かつ、新たに家族の誰かが診察を受ける可能性が低く、家族の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、代表者は、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。

また、決済候補者は、所定の施設に来院したついでに家族の未払い代金を一括して支払うことができ、決済候補者が家族全体の未払い代金を支払う際にかかる負担の増大化を抑制することができる。また、決済候補者が家族全体の未払い代金を一括して支払った後に、家族の誰かが診察を受けてしまう可能性を低減することができ、支払い期限日までの家族全体の未払い代金が一度で支払われる可能性を向上することができる。

また、情報処理装置１００は、家族の代表者の方が、家族のうちの他の利用者の予定日よりも、支払い期限日に近いと判定した場合には、決済候補者を変更せず、代表者のままにすることができる。このため、情報処理装置１００は、決済候補者を変更しない場合には、家族の代表者に決済候補者を通知しなくてもよく、家族の代表者の負担を軽減することができる。

また、情報処理装置１００によれば、支払い期限日以前に代表者の予定日がないと判定した場合には、決済候補者を代表者から、家族のうちの最後の利用者に変更することができる。これにより、情報処理装置１００は、支払い期限日以前であって、かつ、新たに家族の誰かが診察を受ける可能性が低く、家族の未払い代金の増減が起こりにくくなった日に、所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、代表者は、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。

また、決済候補者は、所定の施設に来院したついでに家族の未払い代金を一括して支払うことができ、決済候補者が家族全体の未払い代金を支払う際にかかる負担の増大化を抑制することができる。また、決済候補者が家族全体の未払い代金を一括して支払った後に、家族の誰かが診察を受けてしまう可能性を低減することができ、支払い期限日までの家族全体の未払い代金が一度で支払われる可能性を向上することができる。

また、情報処理装置１００は、家族の代表者の方が、家族のうちの他の利用者の予定日よりも、支払い期限日に近いと判定した場合には、決済候補者を変更せず、代表者のままにすることができる。このため、情報処理装置１００は、決済候補者を変更しない場合には、家族の代表者に決済候補者を通知しなくてもよく、家族の代表者の負担を軽減することができる。

また、情報処理装置１００によれば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、家族のうちの最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信することができる。そして、情報処理装置１００によれば、問い合わせを送信した結果、家族のうちの最後の利用者が未払い代金を支払うことを許可する応答を端末装置２０２から受信したことに応じて、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。

これにより、情報処理装置１００は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。

また、情報処理装置１００によれば、代表者の予定日がないと判定した場合には、家族のうちの最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置２０２に送信することができる。そして、情報処理装置１００によれば、問い合わせを送信した結果、家族のうちの最後の利用者が未払い代金を支払うことを許可する応答を端末装置２０２から受信したことに応じて、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。

これにより、情報処理装置１００は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。

また、情報処理装置１００によれば、問い合わせに、家族のうちの最後の利用者を示す情報を含むことができる。これにより、情報処理装置１００は、家族の代表者に、家族のうちの誰が、決済候補者の変更先になったかを把握させることができる。このため、代表者は、決済候補者の変更先になった家族のうちの最後の利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者が子供である場合には、決済候補者を変更することを許可しないことができる。

また、情報処理装置１００によれば、問い合わせに、家族のうちの最後の利用者の予定日を含むことができる。これにより、情報処理装置１００は、家族の代表者に、決済候補者の変更先になった利用者が、いつ所定の施設を訪れるかを把握させることができる。このため、代表者は、決済候補者の変更先になった利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者の予定日に、最後の利用者に付き添って所定の施設を訪れる場合には、決済候補者を変更することを許可しないことができる。また、代表者は、決済候補者の変更先になった利用者が、家族の未払い代金分のお金をいつ持っていけばよいかを把握することができ、お金を管理する際に役立てることができる。

また、情報処理装置１００によれば、問い合わせに、未払い代金に関する情報を含むことができる。これにより、情報処理装置１００は、家族の代表者に、家族の未払い代金がいくらであるかを把握させることができる。このため、代表者は、決済候補者の変更先になった利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者が子供であっても、家族の未払い代金が比較的に少額である場合には、決済候補者を変更することを許可することができる。また、代表者は、お金を管理する際に役立てることができる。

また、情報処理装置１００によれば、さらに、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、問い合わせを代表者に対応する端末装置２０２に送信することができる。これにより、情報処理装置１００は、予め支払い適格を有さないと設定された利用者についての問い合わせに代表者が応対しなくてよいようにして、代表者の負担を軽減することができる。

また、情報処理装置１００によれば、決済候補者を代表者から家族のうちの最後の利用者に変更した場合に、家族のうちの最後の利用者に対応する端末装置２０２に未払い代金の支払い要求を送信することができる。これにより、情報処理装置１００は、家族のうちの最後の利用者に、家族の未払い代金の支払いを請求することができる。

また、情報処理装置１００によれば、支払い要求に、家族のうちの最後の利用者を示す情報を含むことができる。これにより、情報処理装置１００は、家族のうちの最後の利用者が、自分が決済候補者になったことを把握しやすくすることができる。

また、情報処理装置１００によれば、支払い要求に、家族のうちの最後の利用者の予定日を含むことができる。これにより、情報処理装置１００は、家族のうちの最後の利用者に、家族の未払い代金分のお金を、所定の施設にいつ持っていけばよいかを把握させることができる。

また、情報処理装置１００によれば、支払い要求に、未払い代金に関する情報を含むことができる。これにより、情報処理装置１００は、家族のうちの最後の利用者に、家族の未払い代金がいくらであるかを把握させ、所定の施設にいくらのお金を持っていけばよいかを把握させることができる。

また、情報処理装置１００によれば、さらに、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。これにより、情報処理装置１００は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。情報処理装置１００は、例えば、家族のうちの子供を決済候補者にしてしまって問題が生じる可能性を低減することができる。

また、情報処理装置１００によれば、さらに、予定日情報を参照して、代表者の予定日になった場合に、決済候補者を決定することができる。例えば、情報処理装置１００によれば、支払い期限日以前の代表者の最後の予定日になってから、決済候補者を決定する。これにより、情報処理装置１００は、少なくとも代表者の予定日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。また、情報処理装置１００は、決済候補者を何度も変更してしまうことによる処理量の増大化を抑制することができる。

また、情報処理装置１００によれば、さらに、予定日情報を参照して、支払い期限日以前である所定の日になった場合に、決済候補者を決定することができる。これにより、情報処理装置１００は、少なくとも所定の日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。また、情報処理装置１００は、決済候補者を何度も変更してしまうことによる処理量の増大化を抑制することができる。

また、情報処理装置１００によれば、家族のうちの代表者が、決済候補者に設定されておらず、かつ、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合には、決済候補者を家族のうちの最後の利用者に決定することができる。これにより、情報処理装置１００は、決済候補者が設定されていなくても、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。

また、情報処理装置１００によれば、家族のそれぞれの次回予定日や家族の未払い代金をまとめて管理することができる。これにより、情報処理装置１００は、家族の未払い代金の管理効率を向上させることができる。また、情報処理装置１００は、家族の未払い代金が一括して支払われやすいため、家族のそれぞれが所定の施設を訪れる都度、代金が支払われたか否かを記憶しなくてもよくなる。

なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報処理プログラムは、コンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。記録媒体は、例えば、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などである。また本情報処理プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータが、
所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
処理を実行することを特徴とする情報処理方法。

（付記２）前記複数の利用者のうちの第１の利用者は、前記決済候補者に設定されており、
前記コンピュータが、
前記予定日情報を参照して、前記第１の利用者の予定日よりも、前記第１の利用者とは異なる他の利用者の予定日の方が、前記支払い期限日以前の予定日であって前記支払い期限日に近い予定日であるか否かを判定する、処理を実行し、
前記決定する処理は、
前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合には、前記決済候補者を前記第１の利用者から、前記複数の利用者のうちで前記第１の利用者とは異なり、前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた第２の利用者に変更する、ことを特徴とする付記１に記載の情報処理方法。

（付記３）前記コンピュータが、
前記予定日情報を参照して、前記支払い期限日以前に、前記第１の利用者の予定日があるか否かを判定する、処理を実行し、
前記決定する処理は、
前記第１の利用者の予定日がないと判定した場合には、前記決済候補者を前記第１の利用者から前記第２の利用者に変更する、ことを特徴とする付記２に記載の情報処理方法。

（付記４）前記コンピュータが、
前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合、または前記第１の利用者の予定日がないと判定した場合には、前記第２の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第１の利用者に対応する端末装置に送信する、処理を実行し、
前記決定する処理は、
前記問い合わせを送信した結果、前記第２の利用者が前記未払い代金を支払うことを許可する応答を前記端末装置から受信したことに応じて、前記決済候補者を前記第１の利用者から前記第２の利用者に変更する、処理を実行することを特徴とする付記３に記載の情報処理方法。

（付記５）前記問い合わせは、前記第２の利用者を示す情報を含む、ことを特徴とする付記４に記載の情報処理方法。

（付記６）前記問い合わせは、前記第２の利用者の予定日を含む、ことを特徴とする付記４または５に記載の情報処理方法。

（付記７）前記問い合わせは、前記未払い代金に関する情報を含む、ことを特徴とする付記４〜６のいずれか一つに記載の情報処理方法。

（付記８）前記送信する処理は、
さらに、前記第２の利用者が前記未払い代金の支払い適格を満たしている場合に、前記第２の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第１の利用者に対応する端末装置に送信する、ことを特徴とする付記４〜７のいずれか一つに記載の情報処理方法。

（付記９）前記出力する処理は、
前記決済候補者を前記第１の利用者から前記第２の利用者に変更した場合に、前記第２の利用者に対応する端末装置に前記未払い代金の支払い要求を送信する、ことを特徴とする付記２〜８のいずれか一つに記載の情報処理方法。

（付記１０）前記支払い要求は、前記第２の利用者を示す情報を含む、ことを特徴とする付記９に記載の情報処理方法。

（付記１１）前記支払い要求は、前記第２の利用者の予定日を含む、ことを特徴とする付記９または１０に記載の情報処理方法。

（付記１２）前記支払い要求は、前記未払い代金に関する情報を含む、ことを特徴とする付記９〜１１のいずれか一つに記載の情報処理方法。

（付記１３）前記決定する処理は、
さらに、前記第２の利用者が前記未払い代金の支払い適格を満たしている場合に、前記決済候補者を前記第１の利用者から前記第２の利用者に変更する、ことを特徴とする付記２〜１２のいずれか一つに記載の情報処理方法。

（付記１４）前記決定する処理は、
さらに、前記予定日情報を参照して、前記第１の利用者の予定日になった場合に、前記決済候補者を決定する、ことを特徴とする付記２〜１３のいずれか一つに記載の情報処理方法。

（付記１５）前記決定する処理は、
さらに、前記支払い期限日以前である所定の日になった場合に、前記決済候補者を決定する、ことを特徴とする付記１〜１４のいずれか一つに記載の情報処理方法。

（付記１６）前記決定する処理は、
前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者が前記未払い代金の支払い適格を満たしている場合に、前記決済候補者を前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者に決定する、ことを特徴とする付記１に記載の情報処理方法。

（付記１７）コンピュータに、
所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
処理を実行させることを特徴とする情報処理プログラム。

（付記１８）所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
制御部を有することを特徴とする情報処理装置。

１００ 情報処理装置
２００ まとめ支払いシステム
２０１ クライアント装置
２０２ 端末装置
２０３〜２０５ 医療施設
２１０ ネットワーク
３００，４００，５００ バス
３０１，４０１，５０１ ＣＰＵ
３０２，４０２，５０２ メモリ
３０３，４０３，５０３ Ｉ／Ｆ
３０４，４０４ ディスクドライブ
３０５，４０５ ディスク
４０６ ディスプレイ
４０７ 入力装置
４０８ リーダー
５０４ タッチパネル
６００ グループ情報テーブル
７００ 予定日情報テーブル
８００ 支払い情報テーブル
９０１ 記憶部
９０２ 検出部
９０３ 決定部
９０４ 出力部
１６００ 問い合わせ画面
１７００ 支払い要求画面

Claims (9)

1. コンピュータが、
   所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記複数の利用者の未払い代金を支払う決済候補者に設定された、前記複数の利用者のうちの第１の利用者の予定日よりも、前記第１の利用者とは異なる他の利用者の予定日の方が、前記未払い代金についての支払い期限日以前の予定日であって前記支払い期限日に近い予定日であるか否かを判定し、
   前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合には、前記決済候補者を前記第１の利用者から、前記複数の利用者のうちで前記第１の利用者とは異なり、前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた第２の利用者に変更し、
   前記決済候補者に変更された前記第２の利用者を示す情報を出力する、
   処理を実行することを特徴とする情報処理方法。
2. 前記コンピュータが、
   前記予定日情報を参照して、前記支払い期限日以前に、前記第１の利用者の予定日があるか否かを判定する、処理を実行し、
   前記変更する処理は、
   前記第１の利用者の予定日がないと判定した場合には、前記決済候補者を前記第１の利用者から前記第２の利用者に変更する、ことを特徴とする請求項１に記載の情報処理方法。
3. 前記コンピュータが、
   前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合、または前記第１の利用者の予定日がないと判定した場合には、前記第２の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第１の利用者に対応する端末装置に送信する、処理を実行し、
   前記変更する処理は、
   前記問い合わせを送信した結果、前記第２の利用者が前記未払い代金を支払うことを許可する応答を前記端末装置から受信したことに応じて、前記決済候補者を前記第１の利用者から前記第２の利用者に変更する、処理を実行することを特徴とする請求項２に記載の情報処理方法。
4. 前記送信する処理は、
   さらに、前記第２の利用者が前記未払い代金の支払い適格を満たしている場合に、前記第２の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第１の利用者に対応する端末装置に送信する、ことを特徴とする請求項３に記載の情報処理方法。
5. 前記出力する処理は、
   前記決済候補者を前記第１の利用者から前記第２の利用者に変更した場合に、前記第２の利用者に対応する端末装置に前記未払い代金の支払い要求を送信する、ことを特徴とする請求項１〜４のいずれか一つに記載の情報処理方法。
6. 前記変更する処理は、
   さらに、前記予定日情報を参照して、前記第１の利用者の予定日になった場合に、前記決済候補者を変更する、ことを特徴とする請求項１〜５のいずれか一つに記載の情報処理方法。
7. 前記変更する処理は、
   さらに、前記支払い期限日以前である所定の日になった場合に、前記決済候補者を変更する、ことを特徴とする請求項１〜６のいずれか一つに記載の情報処理方法。
8. コンピュータに、
   所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記複数の利用者の未払い代金を支払う決済候補者に設定された、前記複数の利用者のうちの第１の利用者の予定日よりも、前記第１の利用者とは異なる他の利用者の予定日の方が、前記未払い代金についての支払い期限日以前の予定日であって前記支払い期限日に近い予定日であるか否かを判定し、
   前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合には、前記決済候補者を前記第１の利用者から、前記複数の利用者のうちで前記第１の利用者とは異なり、前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた第２の利用者に変更し、
   前記決済候補者に変更された前記第２の利用者を示す情報を出力する、
   処理を実行させることを特徴とする情報処理プログラム。
9. 所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記複数の利用者の未払い代金を支払う決済候補者に設定された、前記複数の利用者のうちの第１の利用者の予定日よりも、前記第１の利用者とは異なる他の利用者の予定日の方が、前記未払い代金についての支払い期限日以前の予定日であって前記支払い期限日に近い予定日であるか否かを判定し、
   前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合には、前記決済候補者を前記第１の利用者から、前記複数の利用者のうちで前記第１の利用者とは異なり、前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた第２の利用者に変更し、
   前記決済候補者に変更された前記第２の利用者を示す情報を出力する、
   制御部を有することを特徴とする情報処理装置。

Images