以下に、図面を参照して、本発明にかかる情報処理方法、情報処理プログラム、および情報処理装置の実施の形態を詳細に説明する。
(実施の形態にかかる情報処理方法の一実施例)
図1は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。図1において、情報処理装置100は、所定の施設を利用する複数の利用者のそれぞれが所定の施設を訪れる予定日を参照して、複数の利用者の未払い代金を支払う決済候補者を決定するコンピュータである。
所定の施設とは、所定の目的に用いられる場所である。所定の施設は、例えば、建物の一室、建物のフロア、建物、建物の集合体などである。所定の施設は、具体的には、薬局や病院などの医療施設である。所定の施設は、薬局や病院などの複数の医療施設が含まれるメディカルフロアや医療モールなどであってもよい。利用者とは、所定の施設を利用する者である。利用者は、例えば、医療施設を利用する患者などである。代金とは、所定の施設を利用した際に支払う金である。代金は、例えば、診療代や薬代である。複数の利用者とは、代金を一括して支払うことが可能な利用者のグループである。複数の利用者は、例えば、家族である。
ここで、従来では、家族が所定の施設を同日に利用した場合であっても、家族のそれぞれは、所定の施設の会計窓口などにおいて別々に代金を支払うことになり、所定の施設における家族の待ち時間の増大化を招いてしまう。また、利用者は、所定の施設を別日に利用した場合には、所定の施設を利用する都度、所定の施設の会計窓口などにおいて代金を支払うことになり、所定の施設の会計窓口における利用者の待ち時間の増大化を招いてしまう。
このため、所定の施設の業務の効率化を図ることにより、所定の施設を利用する利用者の待ち時間を短縮し、利用者の利便性の向上を図ることが望まれている。例えば、所定の期間における複数の利用者の代金の支払いを保留し、所定の支払い期限までに複数の利用者のうちの代表者が、複数の利用者の未払い代金を一括して支払うことができるようにすることが考えられる。
しかしながら、所定の施設にクレジットカードを用いた決済システムなどが導入されていなければ、複数の利用者のうちの代表者は所定の施設を訪れて未払い代金を支払うことになる。このため、複数の利用者のうちの代表者は、自分が所定の施設を利用しない日であっても所定の施設を訪れて、複数の利用者の未払い代金を一括して支払うことになる場合があり、未払い代金の支払いにかかる代表者の負担の増大化を招いてしまうことがある。そこで、本実施の形態では、複数の利用者のうち、複数の利用者の未払い代金を支払う決済候補者を決定することができる情報処理方法について説明する。
図1の例では、情報処理装置100は、所定の施設を利用する複数の利用者と、複数の利用者のうちのいずれかの利用者が施設を訪れる予定日とを対応付けた予定日情報101を記憶する。予定日情報101は、例えば、医療施設を利用する家族である利用者1〜3と、家族のいずれかが医療施設を訪れる予定日とを対応付けた情報である。
(1−1)情報処理装置100は、予定日情報101を参照して、複数の利用者のうち、複数の利用者の未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、未払い代金を支払う決済候補者に決定する。情報処理装置100は、例えば、予定日情報101を参照して、家族である利用者1〜3のうち、ある月の家族の未払い代金についての支払い期限日になる当該月の末日以前であって、末日に最も近い予定日に医療施設を訪れる利用者2を、決済候補者に決定する。
(1−2)情報処理装置100は、決済候補者に決定した利用者を示す情報を出力する。情報処理装置100は、例えば、決済候補者に決定した利用者2が有する端末装置に、決済候補者に決定した旨の通知を送信する。これによれば、情報処理装置100は、複数の利用者の未払い代金が増える可能性が低くなった月の末日に最も近い予定日に所定の施設を訪れ、未払い代金の支払いにかかる時間的な負担が相対的に少ない利用者を決済候補者に決定して出力することができる。
これにより、複数の利用者は、それぞれ、所定の施設を利用する都度、毎回代金を支払わなくてもよくなり、所定の施設の会計窓口における待ち時間を低減することができる。そして、決済候補者に決定された利用者は、支払い期限日に最も近い予定日に所定の施設に訪れたときに複数の利用者の未払い代金を一括して支払えばよく、時間的な負担の増大化を抑制することができる。このように、複数の利用者は、それぞれ、自分が所定の施設を利用する日以外には所定の施設を訪れなくてもよくなり、時間的な負担の増大化を抑制することができる。
また、所定の施設は、複数の利用者のそれぞれが所定の施設を利用する都度、毎回代金を受け取らなくてもよくなり、所定の施設の業務の効率化や利用者の利便性の向上を図ることができ、コストの低減化を図り、利用者の数の増大化を図ることができる。また、情報処理装置100は、複数の利用者の未払い代金に関するデータの更新回数を低減化して、データ管理の効率化を図ることができる。
(まとめ支払いシステム200のシステム構成例)
次に、図2を用いて、図1に示した情報処理装置100を適用した、まとめ支払いシステム200のシステム構成例について説明する。
図2は、まとめ支払いシステム200の一例を示す説明図である。図2において、まとめ支払いシステム200は、情報処理装置100と、クライアント装置201と、端末装置202とを含む。まとめ支払いシステム200において、情報処理装置100とクライアント装置201とは、有線または無線のネットワーク210を介して接続される。ネットワーク210は、例えば、LAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどである。
ここで、まとめ支払いシステム200は、例えば、薬局や病院などの複数の医療施設203〜205が含まれる医療モールに導入されるシステムである。まとめ支払いシステム200は、複数の医療施設203〜205のそれぞれを利用者が訪れる予定日を管理し、複数の医療施設203〜205のそれぞれの利用者の未払い代金を管理する。
情報処理装置100は、医療モールに設けられたコンピュータである。情報処理装置100は、例えば、図6〜図8に後述する各種テーブルを有し、各種テーブルの情報を参照して決済候補者を決定する。情報処理装置100は、決済候補者を示す情報を、クライアント装置201を介して端末装置202に送信する。各種テーブルは、例えば、図6〜図8に後述するグループ情報テーブル、予定日情報テーブル、支払い情報テーブルなどである。情報処理装置100は、例えば、サーバ、PC(Personal Computer)などである。
クライアント装置201は、医療モールに含まれる複数の医療施設203〜205のそれぞれに設けられたコンピュータである。クライアント装置201は、例えば、医療施設の利用者が有する診察券206を読み取り、利用者を示す情報を受け付ける。クライアント装置201は、受け付けた利用者の情報に対応付けて利用者が医療施設を訪れる予定日や利用者が支払いを保留した未払い代金などの情報を、情報処理装置100に送信する。クライアント装置201は、決済候補者を示す情報を情報処理装置100から受信し、端末装置202に転送する。クライアント装置201は、例えば、医療施設の医療従事者が使用するPC、ノートPC、タブレット型PC、スマートフォンなどである。
端末装置202は、医療施設の利用者が有するコンピュータである。端末装置202は、決済候補者を示す情報をクライアント装置201から受信し、図5に後述するタッチパネル504などに表示する。端末装置202は、例えば、PC、ノートPC、タブレット端末、スマートフォン、PDA(Personal Digital Assistants)、ウェアラブル端末などである。
このように、図1に示した情報処理装置100を適用したまとめ支払いシステム200を医療モールに導入すれば、医療モールの利用者は、いずれかの医療施設を利用する都度、毎回代金を支払わなくてもよい。また、医療モールの利用者は、医療施設ごとに代金を支払わなくてもよく、いくつかの医療施設を利用した際の代金をいずれかの医療施設の会計窓口において一括して支払うことができる。
これにより、医療モールの利用者は、医療施設の会計窓口における待ち時間を低減することができる。そして、例えば、子供やお年寄りなどの利用者は、医療施設を訪れる際にお金を持たなくてもよくなり、利用者の安全性を向上して、利用者に安心感を与えることができる。また、医療施設は、利用者が訪れる都度、毎回代金を受け取らなくてもよく、業務の効率化や利用者の利便性の向上を図ることができる。そして、医療施設は、コストの低減化を図り、利用者の利便性の向上によって利用者の数の増大化を図ることができる。
ここでは、まとめ支払いシステム200が、医療モールに導入される場合について説明したが、これに限らない。例えば、まとめ支払いシステム200は、医療施設に導入される場合があってもよい。この場合、情報処理装置100は、医療施設に設けられるコンピュータであり、医療施設に設けられたクライアント装置201と一体であってもよい。
(情報処理装置100のハードウェア構成例)
次に、図3を用いて、図2に示したまとめ支払いシステム200に含まれる情報処理装置100のハードウェア構成例について説明する。
図3は、情報処理装置100のハードウェア構成例を示すブロック図である。図3において、情報処理装置100は、CPU(Central Processing Unit)301と、メモリ302と、I/F(Interface)303と、ディスクドライブ304と、ディスク305とを有する。また、各構成部は、バス300によってそれぞれ接続される。
ここで、CPU301は、情報処理装置100の全体の制御を司る。メモリ302は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)およびフラッシュROMなどを有する。具体的には、例えば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU301のワークエリアとして使用される。メモリ302に記憶されるプログラムは、CPU301にロードされることで、コーディングされている処理をCPU301に実行させる。メモリ302は、図6〜図8に後述する各種テーブルを記憶する。
I/F303は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して他のコンピュータ(例えば、図2に示したクライアント装置201)に接続される。そして、I/F303は、ネットワーク210と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。I/F303は、例えば、モデムやLANアダプタである。
ディスクドライブ304は、CPU301の制御に従ってディスク305に対するデータのリード/ライトを制御する。ディスクドライブ304は、例えば、磁気ディスクドライブである。ディスク305は、ディスクドライブ304の制御で書き込まれたデータを記憶する不揮発メモリである。ディスク305は、メモリ302の代わりに、図6〜図8に後述する各種テーブルを記憶してもよい。ディスク305は、例えば、磁気ディスク、光ディスクなどである。
情報処理装置100は、上述した構成部のほか、例えば、SSD(Solid State Drive)、半導体メモリ、キーボード、マウス、ディスプレイなどを有することにしてもよい。また、情報処理装置100は、ディスクドライブ304およびディスク305の代わりに、SSDおよび半導体メモリなどを有していてもよい。
(クライアント装置201のハードウェア構成例)
次に、図4を用いて、図2に示したまとめ支払いシステム200に含まれるクライアント装置201のハードウェア構成例について説明する。
図4は、クライアント装置201のハードウェア構成例を示すブロック図である。図4において、クライアント装置201は、CPU401と、メモリ402と、I/F403と、ディスクドライブ404と、ディスク405と、ディスプレイ406と、入力装置407と、リーダー408とを有する。また、各構成部はバス400によってそれぞれ接続される。
ここで、CPU401は、クライアント装置201の全体の制御を司る。メモリ402は、例えば、ROM、RAMおよびフラッシュROMなどを有する。具体的には、例えば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU401のワークエリアとして使用される。メモリ402に記憶されるプログラムは、CPU401にロードされることで、コーディングされている処理をCPU401に実行させる。
I/F403は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して他のコンピュータ(例えば、図2に示した情報処理装置100)に接続される。そして、I/F403は、ネットワーク210と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。I/F403は、例えば、モデムやLANアダプタである。
ディスクドライブ404は、CPU401の制御に従ってディスク405に対するデータのリード/ライトを制御する。ディスクドライブ404は、例えば、磁気ディスクドライブである。ディスク405は、ディスクドライブ404の制御で書き込まれたデータを記憶する不揮発メモリである。ディスク405は、例えば、磁気ディスク、光ディスクなどである。
ディスプレイ406は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ406は、例えば、CRT(Cathode Ray Tube)、液晶ディスプレイ、有機EL(Electroluminescence)ディスプレイなどである。
入力装置407は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置407は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。リーダー408は、磁気カードやIC(Integrated Circuit)カードなどからデータを読み取る。リーダー408は、バーコードや3次元コードからデータを読み取ってもよい。
クライアント装置201は、上述した構成部のうち、例えば、ディスクドライブ404、ディスク405などを有さないことにしてもよい。また、クライアント装置201は、上述した構成部のほか、例えば、SSD、半導体メモリ、スキャナ、プリンタなどを有していてもよい。
ここでは、クライアント装置201が、リーダー408を有する場合について説明したが、これに限らない。例えば、リーダー408は、ネットワーク210を介して、情報処理装置100やクライアント装置201と通信可能な状態で、情報処理装置100やクライアント装置201とからは独立して存在してもよい。
(端末装置202のハードウェア構成例)
次に、図5を用いて、図2に示したまとめ支払いシステム200に含まれる端末装置202のハードウェア構成例について説明する。
図5は、端末装置202のハードウェア構成例を示すブロック図である。図5において、端末装置202は、CPU501と、メモリ502と、I/F503と、タッチパネル504とを有する。また、各構成部はバス500によってそれぞれ接続される。
ここで、CPU501は、端末装置202の全体の制御を司る。メモリ502は、例えば、ROM、RAMおよびフラッシュROMなどを有する。具体的には、例えば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU501のワークエリアとして使用される。メモリ502に記憶されるプログラムは、CPU501にロードされることで、コーディングされている処理をCPU501に実行させる。
I/F503は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して他のコンピュータ(例えば、図2に示したクライアント装置201)に接続される。そして、I/F503は、ネットワーク210と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。I/F503は、例えば、モデムやLANアダプタである。
タッチパネル504は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示するとともに、ユーザの身体やタッチペンなどを用いた接触を感知することによりデータの入力を行う。タッチパネルは、例えば、静電容量方式のパネルである。端末装置202は、上述した構成部のほか、例えば、ディスクドライブ、ディスク、SSD、半導体メモリ、スキャナ、プリンタなどを有することにしてもよい。端末装置202は、上述したタッチパネル504の代わりに、入力装置やディスプレイを有していてもよい。
(各種テーブルの記憶内容)
次に、図6〜図8を用いて、情報処理装置100が有する各種テーブルの記憶内容について説明する。各種テーブルは、例えば、図3に示した情報処理装置100のメモリ302、ディスク305などの記憶領域により実現される。
〈グループ情報テーブル600の記憶内容〉
図6は、グループ情報テーブル600の記憶内容の一例を示す説明図である。図6に示すように、グループ情報テーブル600は、患者ID(IDentification)、支払いグループID、患者情報、支払い適格フラグのフィールドを有する。患者情報のフィールドは、氏名、住所、メールアドレス、連絡先番号のフィールドの組み合わせである。グループ情報テーブル600は、患者ごとに各フィールドに情報を設定することにより、グループ情報をレコード600−aとして記憶する。aは、任意の整数である。
ここで、患者IDとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループIDとは、複数の患者が所属するグループを一意に識別する識別情報であって、患者IDによって識別される患者が所属するグループの識別情報である。支払いグループIDは、支払いグループIDによって識別されるグループに所属する複数の患者の未払い代金について一括して支払うことが可能であることを示す。
患者情報とは、患者IDによって識別される患者に関する情報である。氏名とは、患者IDによって識別される患者の氏名である。住所とは、患者IDによって識別される患者の住所である。メールアドレスとは、患者IDによって識別される患者が有する端末装置202のメールアドレスである。連絡先番号とは、患者IDによって識別される患者が有する端末装置202の電話番号である。
支払い適格フラグとは、患者IDによって識別される患者が、支払いグループIDによって識別されるグループに所属する複数の患者の未払い代金を一括して支払う決済候補者になりうるか否かを示す情報である。支払い適格フラグは、例えば、患者IDによって識別される患者が、決済候補者に設定された代表者である場合には、「1」である。支払い適格フラグは、例えば、患者IDによって識別される患者が、決済候補者を代表者から変更するときに変更先になりうる患者である場合には、「2〜」である。支払い適格フラグは、例えば、患者IDによって識別される患者が、決済候補者にならない患者である場合には、「0」である。
例えば、レコード600−1は、患者ID「100001」、支払いグループID「000001」、氏名「○○ 一郎」、住所「○○県××市△△」、メールアドレス「Add1」、連絡先番号「Tel1」、支払い適格フラグ「1」を対応付けた情報である。
〈予定日情報テーブル700の記憶内容〉
図7は、予定日情報テーブル700の記憶内容の一例を示す説明図である。図7に示すように、予定日情報テーブル700は、患者ID、支払いグループID、施設名称、次回予定日のフィールドを有する。予定日情報テーブル700は、患者ごとに各フィールドに情報を設定することにより、予定日情報をレコード700−bとして記憶する。bは、任意の整数である。
ここで、患者IDとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループIDは、複数の患者が所属するグループを一意に識別する識別情報であって、患者IDによって識別される患者が所属するグループの識別情報である。施設名称とは、患者IDによって識別される患者が訪れる薬局や病院などの医療施設の名称である。次回予定日とは、患者IDによって識別される患者が、施設名称が示す医療施設を訪れる予定がある日付である。次回予定日は、未定である場合には「0」である。
例えば、レコード700−1は、患者ID「100001」、支払いグループID「000001」、施設名称「内科△△」、次回予定日「0」を対応付けた予定日情報である。また、例えば、レコード700−2は、患者ID「100001」、支払いグループID「000001」、施設名称「耳鼻科◇◇」、次回予定日「2015/3/22」を対応付けた予定日情報である。
〈支払い情報テーブル800の記憶内容〉
図8は、支払い情報テーブル800の記憶内容の一例を示す説明図である。図8に示すように、支払い情報テーブル800は、患者ID、支払いグループID、施設名称、診察日付、金額、決済フラグのフィールドを有する。支払い情報テーブル800は、患者ごとに各フィールドに情報を設定することにより、支払い情報をレコード800−cとして記憶する。cは、任意の整数である。
ここで、患者IDとは、医療施設を利用する患者を一意に識別する識別情報である。支払いグループIDは、複数の患者が所属するグループを一意に識別する識別情報であって、患者IDによって識別される患者が所属するグループの識別情報である。施設名称とは、患者IDによって識別される患者が訪れる薬局や病院などの医療施設の名称である。
診察日付とは、患者IDによって識別される患者が、施設名称が示す医療施設において診察された日付である。金額とは、診察日付が示す日時に患者が診察されたことにより発生した診療代の額である。決済フラグとは、診療代が未払いか否かのフラグである。決済フラグは、例えば、診療代が未払いであることを示す「未」である。また、決済フラグは、例えば、診療代が支払い済みであることを示す「済」である。
例えば、レコード800−1は、患者ID「100001」、支払いグループID「000001」、施設名称「内科△△」、診察日付「2015/3/1」、金額「750」、決済フラグ「未」を対応付けた支払い情報である。
(情報処理装置100の機能的構成例)
次に、図9を用いて、情報処理装置100の機能的構成例について説明する。
図9は、情報処理装置100の機能的構成例を示すブロック図である。図9において、情報処理装置100は、記憶部901と、検出部902と、決定部903と、出力部904とを含む構成である。記憶部901は、例えば、図3に示したメモリ302、ディスク305などの記憶領域によって実現される。検出部902〜出力部904は、制御部となる機能であり、例えば、図3に示したメモリ302、ディスク305などの記憶領域に記憶されたプログラムをCPU301に実行させることにより、または、I/F303により、その機能を実現する。各機能部の処理結果は、例えば、図3に示したメモリ302、ディスク305などの記憶領域に記憶される。
記憶部901は、所定の施設を利用する複数の利用者のそれぞれに関する情報を記憶する。ここで、所定の施設は、例えば、薬局や病院などの医療施設、または、薬局や病院などの複数の医療施設203〜205が含まれるメディカルフロアや医療モールなどである。利用者は、例えば、医療施設を利用する患者などである。代金は、例えば、診療代や薬代である。複数の利用者は、代金を一括して支払うことが可能にされた家族である。記憶部901は、例えば、グループ化された家族のそれぞれに関する情報が含まれるグループ情報テーブル600を記憶する。これにより、記憶部901は、どの複数の利用者の未払い代金を一括して支払うことが可能か否かを示す情報を記憶することができる。
記憶部901は、複数の利用者と、複数の利用者のうちのいずれかの利用者が施設を訪れる予定日とを対応付けた予定日情報を記憶する。複数の利用者のうちの第1の利用者は、決済候補者に設定されていてもよい。第1の利用者とは、複数の利用者のうちの代表者である。記憶部901は、例えば、家族のそれぞれと、家族のうちのいずれかが医療施設を訪れる予定日とを対応付けた予定日情報テーブル700を記憶する。これにより、記憶部901は、どの利用者を、決済候補者を決定する指標となる情報を記憶することができる。
記憶部901は、複数の利用者の未払い代金を記憶する。記憶部901は、例えば、所定の期間における複数の利用者の未払い代金を含む支払い情報テーブル800を記憶する。所定の期間とは、支払いが保留された未払い代金をまとめる期間であって、当該期間内に支払いが保留された未払い代金について一括して支払うことが可能になる期間である。所定の期間は、例えば、予め設定されたまとめ支払い期間である。所定の期間は、具体的には、月である。記憶部901は、例えば、一月の家族のそれぞれの未払い代金を含む支払い情報テーブル800を記憶する。これにより、記憶部901は、一括して支払うことができる複数の利用者の未払い代金の額を記憶することができる。
検出部902は、記憶部901に記憶された予定日情報を参照して、第1の利用者の予定日になったことを検出する。検出部902は、例えば、記憶部901に記憶された予定日情報テーブル700を参照して、現在の日が、複数の利用者のうちの代表者の予定日であることを検出して、検出した結果を決定部903に出力する。これにより、検出部902は、決定部903に処理を開始させるトリガーを検出することができる。
検出部902は、支払い期限日以前である所定の日になったことを検出する。ここで、支払い期限日とは、支払いを保留した未払い代金を支払う期限である。支払い期限日は、例えば、所定の期間の末日である。支払い期限日は、具体的には、月の末日である。検出部902は、例えば、月の初日になったことを検出する。また、検出部902は、月の20日になったことを検出してもよい。これにより、検出部902は、決定部903に処理を開始させるトリガーを検出することができる。
決定部903は、記憶部901に記憶された予定日情報を参照して、複数の利用者の未払い代金を支払う決済候補者を決定する。決定部903は、例えば、記憶部901に記憶された予定日情報テーブル700を参照して、複数の利用者のうち、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、決済候補者に決定する。以下の説明では、複数の利用者のうち、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を「最後の利用者」と表記する場合がある。
これにより、決定部903は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、決定部903は、複数の利用者のいずれかが複数の利用者の未払い代金を支払うためだけに所定の施設に来院しなくてもよくすることができる。
決定部903は、例えば、記憶部901に記憶されたグループ情報テーブル600を参照して、複数の利用者のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を複数の利用者のうちの最後の利用者に決定する。これにより、決定部903は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。
決定部903は、例えば、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、より遅い時刻に訪れる利用者を決済候補者に決定する。これにより、決定部903は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。
決定部903は、複数の利用者のうちの第1の利用者が決済候補者に設定されている場合には、予定日情報を参照して、決済候補者を第1の利用者のままにするか、または、決済候補者を第1の利用者から他の利用者に変更するようにしてもよい。これにより、情報処理装置100は、決済候補者を変更しない場合には、複数の利用者に決済候補者を通知しなくてもよく、複数の利用者の負担を軽減することができる。
決定部903は、例えば、記憶部901に記憶された予定日情報テーブル700を参照して、複数の利用者のうち、代表者の予定日よりも、代表者とは異なる他の利用者の予定日の方が、支払い期限日以前であって支払い期限日に近いか否かを判定する。そして、決定部903は、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、決済候補者を代表者から、複数の利用者のうちの最後の利用者に変更する。これにより、決定部903は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。
決定部903は、例えば、記憶部901に記憶された予定日情報テーブル700を参照して、代表者の予定日がない場合には、決済候補者を代表者から最後の利用者に変更する。これにより、決定部903は、新たに複数の利用者のいずれかが所定の施設を利用する可能性が低く、複数の利用者の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。
決定部903は、例えば、さらに、最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を代表者から最後の利用者に変更する。これにより、決定部903は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。
決定部903は、例えば、未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、決済候補者を、より遅い時刻に訪れる利用者に変更する。これにより、決定部903は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。
決定部903は、決済候補者の変更先にした最後の利用者が、未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信した結果に応じて、決済候補者を第1の利用者から他の利用者に変更するようにしてもよい。ここで、問い合わせは、例えば、最後の利用者を示す情報、最後の利用者の予定日、未払い代金に関する情報を含む。これにより、決定部903は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。
決定部903は、例えば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信する。そして、決定部903は、問い合わせを送信した結果、最後の利用者が未払い代金を支払うことを許可する応答を端末装置202から受信したことに応じて、決済候補者を代表者から最後の利用者に変更する。これにより、決定部903は、決済候補者を代表者から最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から最後の利用者に変更するか否かを判断することができる。
決定部903は、例えば、代表者の予定日がないと判定した場合には、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信する。そして、決定部903は、問い合わせを送信した結果、最後の利用者が未払い代金を支払うことを許可する応答を端末装置202から受信したことに応じて、決済候補者を代表者から最後の利用者に変更する。これにより、決定部903は、決済候補者を代表者から最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から最後の利用者に変更するか否かを判断することができる。
決定部903は、例えば、さらに、最後の利用者が未払い代金の支払い適格を満たしている場合に、最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、第1の利用者に対応する端末装置202に送信してもよい。これにより、情報処理装置100は、予め支払い適格を有さないと設定された利用者についての問い合わせに代表者が応対しなくてよいようにして、代表者の負担を軽減することができる。
決定部903は、例えば、さらに、検出部902が代表者の予定日になったことを検出した場合に、決済候補者を決定する。これにより、決定部903は、少なくとも代表者の予定日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。
決定部903は、さらに、支払い期限日以前である所定の日になった場合に、決済候補者を決定する。これにより、決定部903は、少なくとも所定の日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。
決定部903は、例えば、支払い期限日に最も近い予定日に施設を訪れる利用者が複数存在する場合には、より遅い時刻に訪れる利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信する。これにより、決定部903は、複数の利用者の未払い代金の増減が起こりにくくなった日時に所定の施設を訪れる最後の利用者を、決済候補者の変更先にすることができる。
出力部904は、決済候補者に決定した利用者を示す情報を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、I/F303による外部装置への送信、メモリ302、ディスク305などの記憶領域への記憶がある。
出力部904は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者に対応する端末装置202に未払い代金の支払い要求を送信する。ここで、支払い要求は、例えば、最後の利用者を示す情報、最後の利用者の予定日、未払い代金に関する情報を含む。これにより、出力部904は、決済候補者にした利用者に、自分が決済候補者になったことを把握させることができる。
出力部904は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者への連絡先情報を出力してもよい。連絡先情報は、例えば、メールアドレスである。出力部904は、具体的には、最後の利用者への連絡先情報を情報処理装置100のディスプレイに表示する。これにより、出力部904は、決済候補者にした利用者に決済候補者になったことを連絡可能にすることができる。例えば、情報処理装置100のユーザは、情報処理装置100のディスプレイに表示された連絡先情報を参照して、決済候補者にされた利用者に決済候補者になったことを連絡することができる。
また、出力部904は、具体的には、最後の利用者への連絡先情報を、クライアント装置201に送信してクライアント装置201のディスプレイ406に表示させてもよい。これにより、出力部904は、決済候補者にした利用者に自分が決済候補者になったことを連絡可能にすることができる。例えば、クライアント装置201のユーザは、クライアント装置201のディスプレイ406に表示された連絡先情報を参照して、決済候補者にされた利用者に決済候補者になったことを連絡することができる。
出力部904は、例えば、決済候補者を代表者から最後の利用者に変更した場合に、最後の利用者を示す情報や最後の利用者の予定日などを出力してもよい。出力部904は、具体的には、決済候補者にされた最後の利用者を示す情報や最後の利用者の予定日などを、クライアント装置201に送信してクライアント装置201のディスプレイ406に表示させてもよい。これにより、出力部904は、決済候補者にした利用者に自分が決済候補者になったことを連絡可能にすることができる。例えば、クライアント装置201のユーザは、決済候補者にされた最後の利用者を示す情報や最後の利用者の予定日などを参照して、最後の利用者が所定の施設を訪れた際に決済候補者になったことを連絡することができる。
(各種テーブルを更新する一例)
次に、図10を用いて、情報処理装置100が各種テーブルを更新する一例について説明する。各種テーブルは、例えば、図6〜図8に示したグループ情報テーブル600、予定日情報テーブル700、支払い情報テーブル800などである。
図10は、情報処理装置100が各種テーブルを更新する一例を示す説明図である。図10の例では、利用者が医療施設を訪れた際に、グループ情報テーブル600の更新作業、予定日情報テーブル700の更新作業、支払い情報テーブル800の更新作業などが行われる。
〈グループ情報テーブル600の更新作業〉
例えば、利用者は、医療モールに含まれる医療施設を訪れると、家族のそれぞれの患者情報や支払い適格の有無を記載した申込用紙を医療施設の医療従事者に渡したり、クライアント装置201のリーダー408に家族の診察券206などを読み取らせる。これにより、利用者は、自分を含む家族などの複数の利用者について、まとめ支払い期間内の未払い代金を一括して支払うことを可能にするために用いる情報を、情報処理装置100に送信してもらう。
クライアント装置201は、申込用紙に基づく医療施設の医療従事者の操作入力を受け付けたり、リーダー408によって診察券206などを読み取ることにより、家族のそれぞれの患者情報や支払い適格の有無を取得する。クライアント装置201は、取得した患者情報や支払い適格の有無を含むグループ情報テーブル600の更新要求を、情報処理装置100に送信する。
情報処理装置100は、グループ情報テーブル600の更新要求を受信すると、グループ情報テーブル600の更新要求から家族のそれぞれの患者情報を抽出する。情報処理装置100は、抽出した家族のそれぞれの患者情報や支払い適格の有無に、患者ID、支払いグループIDを対応付けたレコードを生成して、グループ情報テーブル600に追加する。
ここでは、利用者が医療施設を訪れた際に、グループ情報テーブル600の更新作業が行われる場合について説明したが、これに限らない。例えば、利用者は、端末装置202を介して、クライアント装置201に、家族のそれぞれの患者情報や支払い適格の有無を送信してもよい。また、クライアント装置201がグループ情報テーブル600の更新要求を情報処理装置100に送信する場合について説明したが、これに限らない。例えば、端末装置202が、利用者の操作入力によって、患者情報や支払い適格の有無を含むグループ情報テーブル600の更新要求を、情報処理装置100に送信してもよい。
〈予定日情報テーブル700の更新作業〉
また、例えば、利用者は、医療モールに含まれる医療施設を訪れると、医療施設の医療従事者と相談して次回予定日を医療施設の医療従事者に通知したり、医療施設に設けられたクライアント装置201のリーダー408に利用者の診察券206などを読み取らせる。医療施設の医療従事者が、空いている日を利用者に確認して、利用者の次回予定日を決定してもよい。
クライアント装置201は、医療施設の医療従事者の操作入力を受け付けたり、リーダー408によって診察券206などを読み取ることにより、利用者の患者情報や次回予定日を取得する。クライアント装置201は、取得した利用者の患者情報や次回予定日を含む予定日情報テーブル700の更新要求を、情報処理装置100に送信する。
情報処理装置100は、予定日情報テーブル700の更新要求を受信すると、予定日情報テーブル700の更新要求から利用者の患者情報や次回予定日を抽出する。情報処理装置100は、グループ情報テーブル600を参照して、抽出した利用者の患者情報に対応する患者IDと支払いグループIDとを特定する。情報処理装置100は、抽出した利用者の患者情報や次回予定日に、特定した患者IDと支払いグループIDとを対応付けたレコードを生成して、予定日情報テーブル700に追加する。
ここでは、利用者が医療施設を訪れた際に、予定日情報テーブル700の更新作業が行われる場合について説明したが、これに限らない。例えば、利用者は、端末装置202を介して、クライアント装置201に、利用者の患者情報や次回予定日を送信してもよい。利用者は、電話などによって、医療施設の医療従事者と相談して次回予定日を医療施設の医療従事者に通知してもよい。
〈支払い情報テーブル800の更新作業〉
また、例えば、利用者は、医療モールに含まれる医療施設を訪れると、クライアント装置201のリーダー408に利用者の診察券206などを読み取らせたり、医療施設の会計窓口において利用者を含む家族の未払い代金を医療従事者に一括して支払う。
クライアント装置201は、医療施設の医療従事者の操作入力を受け付けたり、リーダー408によって診察券206などを読み取ることにより、家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付などを取得する。クライアント装置201は、取得した家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付を含む支払い情報テーブル800の更新要求を、情報処理装置100に送信する。
情報処理装置100は、支払い情報テーブル800の更新要求を受信すると、支払い情報テーブル800の更新要求から家族のそれぞれの患者情報、代金が支払われた診察が行われた医療施設名や診察日付を抽出する。情報処理装置100は、グループ情報テーブル600を参照して、抽出した利用者の患者情報に対応する患者IDと支払いグループIDとを特定する。情報処理装置100は、支払い情報テーブル800のうち、抽出した代金が支払われた診察が行われた医療施設名や診察日付に、特定した患者IDと支払いグループIDとを対応付けたレコードの決済フラグを「済」に変更する。
(決済候補者を決定するパターンの一例)
次に、図11〜図15を用いて、情報処理装置100が決済候補者を決定するパターンの一例について説明する。
図11は、情報処理装置100が決済候補者を決定するパターン1の一例である。図11の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がある場合について、情報処理装置100が決済候補者を決定するパターン1について説明する。また、図11の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もあるとする。
図11において、情報処理装置100は、まとめ支払い期間の初日になったことを検出する。まとめ支払い期間は、例えば、月である。まとめ支払い期間の初日は、例えば、月初めである。情報処理装置100は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル700を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。情報処理装置100は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるため、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日まで待機する。
そして、情報処理装置100は、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日になったことを検出する。情報処理装置100は、まとめ支払い期間内、かつ、代表者「○○ 一郎」の最も後ろの予定日以降に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置100は、他の利用者の予定日がないため、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。
図12は、情報処理装置100が決済候補者を決定するパターン2の一例である。図12の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がある場合について、情報処理装置100が決済候補者を決定するパターン2について説明する。また、図12の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もあるとする。
図12において、情報処理装置100は、まとめ支払い期間の初日になったことを検出する。情報処理装置100は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル700を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。情報処理装置100は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるため、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日まで待機する。
そして、情報処理装置100は、代表者「○○ 一郎」の予定日のうち、まとめ支払い期間内の最も後ろの予定日になったことを検出する。情報処理装置100は、まとめ支払い期間内、かつ、代表者「○○ 一郎」の最も後ろの予定日以降に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置100は、他の利用者「○○ 花子」や「○○ 太郎」の予定日があるため、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。
情報処理装置100は、決済候補者の変更先を特定すると、グループ情報テーブル600を参照して、代表者「○○ 一郎」のメールアドレスを取得する。情報処理装置100は、取得したメールアドレスに基づいて、決済候補者の変更先として特定した利用者「○○ 花子」が未払い代金を決済することを許可するか否かの問い合わせを生成する。そして、情報処理装置100は、生成した問い合わせを代表者「○○ 一郎」の端末装置202に送信し、端末装置202に問い合わせ画面1600を表示させる。
問い合わせは、例えば、問い合わせ画面1600の画面情報を含む。問い合わせ画面1600の画面情報は、例えば、決済候補者の変更先として特定した利用者「○○ 花子」の情報などを含む。また、問い合わせ画面1600の画面情報は、例えば、予定日情報テーブル700に記憶された家族のそれぞれに対応する予定日情報、支払い情報テーブル800に記憶された家族のそれぞれに対応する支払い情報などを含む。端末装置202に表示される問い合わせ画面1600の内容については、図16を用いて後述する。
ここでは、情報処理装置100が、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する場合について説明したが、これに限らない。例えば、情報処理装置100は、グループ情報テーブル600を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」の支払い適格の有無を判定してもよい。
そして、情報処理装置100は、支払い適格がある場合には、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。一方で、情報処理装置100は、支払い適格がない場合には、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。
図13は、情報処理装置100が決済候補者を決定するパターン3の一例である。図13の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がない場合について、情報処理装置100が決済候補者を決定するパターン3について説明する。また、図13の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日があるとする。
図13において、情報処理装置100は、まとめ支払い期間の初日になったことを検出する。情報処理装置100は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル700を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。
情報処理装置100は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にないため、まとめ支払い期間内に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置100は、他の利用者「○○ 花子」や「○○ 太郎」の予定日があるため、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。
情報処理装置100は、決済候補者の変更先を特定すると、グループ情報テーブル600を参照して、代表者「○○ 一郎」のメールアドレスを取得する。情報処理装置100は、取得したメールアドレスに基づいて、決済候補者の変更先として特定した利用者「○○ 花子」が未払い代金を決済することを許可するか否かの問い合わせを生成する。そして、情報処理装置100は、生成した問い合わせを、代表者「○○ 一郎」の端末装置202に送信し、端末装置202に問い合わせ画面1600を表示させる。
ここでは、情報処理装置100が、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する場合について説明したが、これに限らない。例えば、情報処理装置100は、グループ情報テーブル600を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」の支払い適格の有無を判定してもよい。
そして、情報処理装置100は、支払い適格がある場合には、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者の変更先として特定する。一方で、情報処理装置100は、支払い適格がない場合には、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。
図14は、情報処理装置100が決済候補者を決定するパターン4の一例である。図14の例では、予め決済候補者として家族のうちの代表者「○○ 一郎」が設定されており、まとめ支払い期間内に代表者「○○ 一郎」の予定日がない場合について、情報処理装置100が決済候補者を決定するパターン4について説明する。また、図14の例では、まとめ支払い期間内に、利用者「○○ 花子」や利用者「○○ 太郎」の予定日もないとする。
図14において、情報処理装置100は、まとめ支払い期間の初日になったことを検出する。情報処理装置100は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル700を参照して、代表者「○○ 一郎」の予定日がまとめ支払い期間内にあるか否かを判定する。
情報処理装置100は、代表者「○○ 一郎」の予定日がまとめ支払い期間内にないため、まとめ支払い期間内に、代表者「○○ 一郎」とは異なる他の利用者の予定日があるか否かを判定する。情報処理装置100は、他の利用者の予定日がないため、決済候補者を変更せず、決済候補者を代表者「○○ 一郎」のままにしておく。
情報処理装置100は、パターン1〜4のように決済候補者が決定された後、いずれかの利用者の予定日が新たに決まり、予定日情報テーブル700に予定日情報が追加された場合には、改めて決済候補者を決定する。これにより、情報処理装置100は、最新の予定日情報テーブル700に基づいて、複数の利用者のうちの最後の利用者が決済候補者になるようにすることができる。
図15は、情報処理装置100が決済候補者を決定するパターン5の一例である。図15の例では、予め決済候補者が設定されていない場合について、情報処理装置100が決済候補者を決定するパターン5について説明する。
図15において、情報処理装置100は、まとめ支払い期間の初日になったことを検出する。情報処理装置100は、まとめ支払い期間の初日になったことが検出されると、予定日情報テーブル700を参照して、まとめ支払い期間内の最も後ろに予定日がある利用者「○○ 花子」を決済候補者に決定する。
情報処理装置100は、決済候補者を決定すると、グループ情報テーブル600を参照して、決済候補者に決定した利用者「○○ 花子」のメールアドレスを取得する。情報処理装置100は、取得したメールアドレスに基づいて、未払い代金に関する情報を、決済候補者に決定した利用者「○○ 花子」の端末装置202に送信し、端末装置202に表示させる。
(端末装置202に表示される問い合わせ画面1600の一例)
次に、図16を用いて、端末装置202に表示される問い合わせ画面1600の一例について説明する。
図16は、端末装置202に表示される問い合わせ画面1600の一例を示す説明図である。端末装置202は、問い合わせを受信すると、問い合わせに含まれる問い合わせ画面1600の画面情報に基づいて問い合わせ画面1600を表示する。問い合わせ画面1600は、代表者の予定日に関する表示欄1601と、過去の未払い代金に関する表示欄1602と、未来の支払いに関する表示欄1603と、承認ボタン1604と、却下ボタン1605とを含む画面である。
代表者「○○ 一郎」は、端末装置202の表示内容を参照して、利用者「○○ 花子」が未払い代金を決済することを許可する場合には、端末装置202を操作して承認ボタン1604をクリックする。端末装置202は、承認ボタン1604がクリックされた場合、利用者「○○ 花子」が未払い代金を決済することを許可する応答を、情報処理装置100に送信する。
一方で、代表者「○○ 一郎」は、端末装置202の表示内容を参照して、利用者「○○ 花子」が未払い代金を決済することを許可しない場合には、端末装置202を操作して却下ボタン1605をクリックする。端末装置202は、却下ボタン1605がクリックされた場合、利用者「○○ 花子」が未払い代金を決済することを許可しない応答を、情報処理装置100に送信する。
情報処理装置100は、問い合わせを送信した結果、利用者「○○ 花子」が未払い代金を決済することを許可する応答を代表者「○○ 一郎」の端末装置202から受信した場合には、決済候補者を「○○ 花子」に変更する。情報処理装置100は、決済候補者を変更すると、グループ情報テーブル600を参照して、決済候補者にした利用者「○○ 花子」のメールアドレスを取得する。情報処理装置100は、取得したメールアドレスに基づいて、家族のそれぞれの未払い代金の支払い要求を、決済候補者にした利用者「○○ 花子」の端末装置202に送信し、端末装置202に支払い要求画面1700を表示させる。
支払い要求は、例えば、支払い要求画面1700の画面情報を含む。支払い要求画面1700の画面情報は、例えば、決済候補者にした利用者「○○ 花子」の情報などを含む。また、支払い要求画面1700の画面情報は、例えば、予定日情報テーブル700に記憶された家族のそれぞれに対応する予定日情報、支払い情報テーブル800に記憶された家族のそれぞれに対応する支払い情報などを含む。端末装置202に表示される支払い要求画面1700の内容については、図17を用いて後述する。
一方で、情報処理装置100は、問い合わせを送信した結果、利用者「○○ 花子」が未払い代金を決済することを許可しない応答を代表者「○○ 一郎」の端末装置202から受信した場合には、決済候補者を代表者「○○ 一郎」のままにしておく。これにより、代表者「○○ 一郎」は、利用者「○○ 花子」に未払い代金の支払いを委任しても問題がないか否かを判断して、情報処理装置100に応答を返すことができる。
このため、情報処理装置100は、利用者「○○ 花子」に未払い代金の支払いを委任して問題がある場合に、利用者「○○ 花子」を決済候補者に決定してしまうことを防止することができる。例えば、情報処理装置100は、利用者「○○ 花子」が子供であって、代表者「○○ 一郎」が利用者「○○ 花子」にお金を預けることに不安がある場合に、利用者「○○ 花子」を決済候補者に決定してしまうことを防止することができる。
(端末装置202に表示される支払い要求画面1700の一例)
次に、図17を用いて、端末装置202に表示される支払い要求画面1700の一例について説明する。
図17は、端末装置202に表示される支払い要求画面1700の一例を示す説明図である。端末装置202は、問い合わせを受信すると、問い合わせに含まれる支払い要求画面1700の画面情報に基づいて支払い要求画面1700を表示する。支払い要求画面1700は、決済候補者にした利用者の予定日に関する表示欄1701と、過去の未払い代金に関する表示欄1702と、未来の支払いに関する表示欄1703とを含む画面である。
利用者「○○ 花子」は、端末装置202の表示内容を参照して、次回予定日に医療施設を訪れた際に併せて、家族のそれぞれの未払い代金を一括して支払う。これにより、代表者「○○ 一郎」は、家族のそれぞれの未払い代金を支払うために、自分が医療施設を利用しない日に、医療施設を訪れなくてもよく、時間的な負担を軽減することができる。また、利用者「○○ 花子」は、自分が医療施設を訪れた日に併せて、家族のそれぞれの未払い代金を支払えばよく、家族のそれぞれの未払い代金を支払う際にかかる負担の増大化を抑制することができる。
(決定処理手順の一例)
次に、図18を用いて、情報処理装置100によって実行される決定処理手順の一例について説明する。
図18は、決定処理手順の一例を示すフローチャートである。図18において、情報処理装置100は、現在の日が、まとめ支払い期間の初日であるか否かを判定する(ステップS1801)。ここで、初日ではない場合(ステップS1801:No)、情報処理装置100は、予定日情報テーブル700に記憶された予定日情報が更新されたか否かを判定する(ステップS1802)。
ここで、予定日情報が更新されていない場合(ステップS1802:No)、情報処理装置100は、ステップS1801の処理に戻る。一方で、初日である場合(ステップS1801:Yes)、または、予定日情報が更新された場合(ステップS1802:Yes)、情報処理装置100は、ステップS1803の処理に移行する。
ステップS1803では、情報処理装置100は、予定日情報テーブル700を参照して、代表者の予定日が、現在の日以降のまとめ支払い期間内にあるか否かを判定する(ステップS1803)。ここで、代表者の予定日が、現在の日以降のまとめ支払い期間内にある場合(ステップS1803:Yes)、情報処理装置100は、ステップS1804の処理に移行する。
ステップS1804では、情報処理装置100は、グループに所属する、代表者とは異なる他の利用者の予定日が、代表者の予定日より後ろであって、かつ、現在の日以降のまとめ支払い期間内にあるか否かを判定する(ステップS1804)。ここで、他の利用者の予定日が、代表者の予定日より後ろであって、かつ、現在の日以降のまとめ支払い期間内にある場合(ステップS1804:Yes)、情報処理装置100は、ステップS1805の処理に移行する。
ステップS1805では、情報処理装置100は、決済候補者を、代表者から、グループに所属する複数の利用者のうち、まとめ支払い期間内であって最も後ろにある予定日に施設を訪れる利用者に変更する(ステップS1805)。このとき、情報処理装置100は、代表者に対応する端末装置に問い合わせを送信し、端末装置からの応答に応じて決済候補者を変更してもよい。そして、情報処理装置100は、決定処理を終了する。
一方で、他の利用者の予定日が、代表者の予定日より前であるか、または、現在の日以降のまとめ支払い期間内にない場合(ステップS1804:No)、情報処理装置100は、決済候補者を代表者から変更せずに、決定処理を終了する。
一方で、ステップS1803において、代表者の予定日が、現在の日以降のまとめ支払い期間内にない場合(ステップS1803:No)、情報処理装置100は、ステップS1806の処理に移行する。
ステップS1806では、情報処理装置100は、グループに所属する、代表者とは異なる他の利用者の予定日が、現在の日以降のまとめ支払い期間内にあるか否かを判定する(ステップS1806)。ここで、他の利用者の予定日が、現在の日以降のまとめ支払い期間内にある場合(ステップS1806:Yes)、情報処理装置100は、ステップS1807の処理に移行する。
ステップS1807では、情報処理装置100は、決済候補者を、代表者から、グループに所属する複数の利用者のうち、まとめ支払い期間内であって最も後ろにある予定日に施設を訪れる利用者に変更する(ステップS1807)。このとき、情報処理装置100は、代表者に対応する端末装置に問い合わせを送信し、端末装置からの応答に応じて決済候補者を変更してもよい。そして、情報処理装置100は、決定処理を終了する。
一方で、他の利用者の予定日が、現在の日以降のまとめ支払い期間内にない場合(ステップS1806:No)、情報処理装置100は、決済候補者を代表者から変更せずに、決定処理を終了する。これにより、情報処理装置100は、決済候補者を変更することができる。
以上説明したように、情報処理装置100によれば、家族のうち、家族の未払い代金についての支払い期限日以前であって、かつ、支払い期限日に最も近い予定日に施設を訪れる利用者を、未払い代金を支払う決済候補者に決定することができる。これにより、情報処理装置100は、家族の誰かが、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。また、所定の施設は、利用者が来院する都度、利用者から代金を受け取らなくてもよくなり、会計窓口の業務を効率化することができる。
また、情報処理装置100によれば、家族のうちの代表者が、決済候補者に設定されている場合には、代表者の予定日よりも、家族のうちの他の利用者の予定日の方が、支払い期限日以前であって支払い期限日に近いか否かを判定することができる。そして、情報処理装置100によれば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、決済候補者を代表者から、家族のうちで、支払い期限日以前、かつ、支払い期限日に最も近い予定日に施設を訪れる最後の利用者に変更することができる。
これにより、情報処理装置100は、支払い期限日以前であって、かつ、新たに家族の誰かが診察を受ける可能性が低く、家族の未払い代金の増減が起こりにくくなった日に所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、代表者は、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。
また、決済候補者は、所定の施設に来院したついでに家族の未払い代金を一括して支払うことができ、決済候補者が家族全体の未払い代金を支払う際にかかる負担の増大化を抑制することができる。また、決済候補者が家族全体の未払い代金を一括して支払った後に、家族の誰かが診察を受けてしまう可能性を低減することができ、支払い期限日までの家族全体の未払い代金が一度で支払われる可能性を向上することができる。
また、情報処理装置100は、家族の代表者の方が、家族のうちの他の利用者の予定日よりも、支払い期限日に近いと判定した場合には、決済候補者を変更せず、代表者のままにすることができる。このため、情報処理装置100は、決済候補者を変更しない場合には、家族の代表者に決済候補者を通知しなくてもよく、家族の代表者の負担を軽減することができる。
また、情報処理装置100によれば、支払い期限日以前に代表者の予定日がないと判定した場合には、決済候補者を代表者から、家族のうちの最後の利用者に変更することができる。これにより、情報処理装置100は、支払い期限日以前であって、かつ、新たに家族の誰かが診察を受ける可能性が低く、家族の未払い代金の増減が起こりにくくなった日に、所定の施設を訪れる最後の利用者を、決済候補者にすることができる。そして、代表者は、家族全体の未払い代金を支払うためだけに所定の施設に来院しなくてもよくなり、家族全体の未払い代金を支払う際にかかる負担を軽減することができる。
また、決済候補者は、所定の施設に来院したついでに家族の未払い代金を一括して支払うことができ、決済候補者が家族全体の未払い代金を支払う際にかかる負担の増大化を抑制することができる。また、決済候補者が家族全体の未払い代金を一括して支払った後に、家族の誰かが診察を受けてしまう可能性を低減することができ、支払い期限日までの家族全体の未払い代金が一度で支払われる可能性を向上することができる。
また、情報処理装置100は、家族の代表者の方が、家族のうちの他の利用者の予定日よりも、支払い期限日に近いと判定した場合には、決済候補者を変更せず、代表者のままにすることができる。このため、情報処理装置100は、決済候補者を変更しない場合には、家族の代表者に決済候補者を通知しなくてもよく、家族の代表者の負担を軽減することができる。
また、情報処理装置100によれば、他の利用者の予定日の方が支払い期限日に近いと判定した場合には、家族のうちの最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信することができる。そして、情報処理装置100によれば、問い合わせを送信した結果、家族のうちの最後の利用者が未払い代金を支払うことを許可する応答を端末装置202から受信したことに応じて、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。
これにより、情報処理装置100は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。
また、情報処理装置100によれば、代表者の予定日がないと判定した場合には、家族のうちの最後の利用者が未払い代金を支払うことを許可するか否かの問い合わせを、代表者に対応する端末装置202に送信することができる。そして、情報処理装置100によれば、問い合わせを送信した結果、家族のうちの最後の利用者が未払い代金を支払うことを許可する応答を端末装置202から受信したことに応じて、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。
これにより、情報処理装置100は、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを代表者に判断させることができる。代表者は、最後の利用者が、未払い代金を支払うことを委託しても問題がないか否かを判断して、決済候補者を代表者から家族のうちの最後の利用者に変更するか否かを判断することができる。
また、情報処理装置100によれば、問い合わせに、家族のうちの最後の利用者を示す情報を含むことができる。これにより、情報処理装置100は、家族の代表者に、家族のうちの誰が、決済候補者の変更先になったかを把握させることができる。このため、代表者は、決済候補者の変更先になった家族のうちの最後の利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者が子供である場合には、決済候補者を変更することを許可しないことができる。
また、情報処理装置100によれば、問い合わせに、家族のうちの最後の利用者の予定日を含むことができる。これにより、情報処理装置100は、家族の代表者に、決済候補者の変更先になった利用者が、いつ所定の施設を訪れるかを把握させることができる。このため、代表者は、決済候補者の変更先になった利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者の予定日に、最後の利用者に付き添って所定の施設を訪れる場合には、決済候補者を変更することを許可しないことができる。また、代表者は、決済候補者の変更先になった利用者が、家族の未払い代金分のお金をいつ持っていけばよいかを把握することができ、お金を管理する際に役立てることができる。
また、情報処理装置100によれば、問い合わせに、未払い代金に関する情報を含むことができる。これにより、情報処理装置100は、家族の代表者に、家族の未払い代金がいくらであるかを把握させることができる。このため、代表者は、決済候補者の変更先になった利用者に、未払い代金を支払うことを許可するか否かを判断する指標を得ることができる。代表者は、例えば、家族のうちの最後の利用者が子供であっても、家族の未払い代金が比較的に少額である場合には、決済候補者を変更することを許可することができる。また、代表者は、お金を管理する際に役立てることができる。
また、情報処理装置100によれば、さらに、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、問い合わせを代表者に対応する端末装置202に送信することができる。これにより、情報処理装置100は、予め支払い適格を有さないと設定された利用者についての問い合わせに代表者が応対しなくてよいようにして、代表者の負担を軽減することができる。
また、情報処理装置100によれば、決済候補者を代表者から家族のうちの最後の利用者に変更した場合に、家族のうちの最後の利用者に対応する端末装置202に未払い代金の支払い要求を送信することができる。これにより、情報処理装置100は、家族のうちの最後の利用者に、家族の未払い代金の支払いを請求することができる。
また、情報処理装置100によれば、支払い要求に、家族のうちの最後の利用者を示す情報を含むことができる。これにより、情報処理装置100は、家族のうちの最後の利用者が、自分が決済候補者になったことを把握しやすくすることができる。
また、情報処理装置100によれば、支払い要求に、家族のうちの最後の利用者の予定日を含むことができる。これにより、情報処理装置100は、家族のうちの最後の利用者に、家族の未払い代金分のお金を、所定の施設にいつ持っていけばよいかを把握させることができる。
また、情報処理装置100によれば、支払い要求に、未払い代金に関する情報を含むことができる。これにより、情報処理装置100は、家族のうちの最後の利用者に、家族の未払い代金がいくらであるかを把握させ、所定の施設にいくらのお金を持っていけばよいかを把握させることができる。
また、情報処理装置100によれば、さらに、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合に、決済候補者を代表者から家族のうちの最後の利用者に変更することができる。これにより、情報処理装置100は、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。情報処理装置100は、例えば、家族のうちの子供を決済候補者にしてしまって問題が生じる可能性を低減することができる。
また、情報処理装置100によれば、さらに、予定日情報を参照して、代表者の予定日になった場合に、決済候補者を決定することができる。例えば、情報処理装置100によれば、支払い期限日以前の代表者の最後の予定日になってから、決済候補者を決定する。これにより、情報処理装置100は、少なくとも代表者の予定日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。また、情報処理装置100は、決済候補者を何度も変更してしまうことによる処理量の増大化を抑制することができる。
また、情報処理装置100によれば、さらに、予定日情報を参照して、支払い期限日以前である所定の日になった場合に、決済候補者を決定することができる。これにより、情報処理装置100は、少なくとも所定の日までは決済候補者が変わらないようにして、決済候補者が何度も変更されてしまう可能性を低減することができる。また、情報処理装置100は、決済候補者を何度も変更してしまうことによる処理量の増大化を抑制することができる。
また、情報処理装置100によれば、家族のうちの代表者が、決済候補者に設定されておらず、かつ、家族のうちの最後の利用者が未払い代金の支払い適格を満たしている場合には、決済候補者を家族のうちの最後の利用者に決定することができる。これにより、情報処理装置100は、決済候補者が設定されていなくても、予め支払い適格を有さないと設定された利用者は決済候補者にしないようにして、家族の未払い代金を支払う際に問題が生じる可能性を低減することができる。
また、情報処理装置100によれば、家族のそれぞれの次回予定日や家族の未払い代金をまとめて管理することができる。これにより、情報処理装置100は、家族の未払い代金の管理効率を向上させることができる。また、情報処理装置100は、家族の未払い代金が一括して支払われやすいため、家族のそれぞれが所定の施設を訪れる都度、代金が支払われたか否かを記憶しなくてもよくなる。
なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報処理プログラムは、コンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。記録媒体は、例えば、ハードディスク、フレキシブルディスク、CD(Compact Disc)−ROM、MO(Magneto−Optical disc)、DVD(Digital Versatile Disc)などである。また本情報処理プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)コンピュータが、
所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
処理を実行することを特徴とする情報処理方法。
(付記2)前記複数の利用者のうちの第1の利用者は、前記決済候補者に設定されており、
前記コンピュータが、
前記予定日情報を参照して、前記第1の利用者の予定日よりも、前記第1の利用者とは異なる他の利用者の予定日の方が、前記支払い期限日以前の予定日であって前記支払い期限日に近い予定日であるか否かを判定する、処理を実行し、
前記決定する処理は、
前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合には、前記決済候補者を前記第1の利用者から、前記複数の利用者のうちで前記第1の利用者とは異なり、前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた第2の利用者に変更する、ことを特徴とする付記1に記載の情報処理方法。
(付記3)前記コンピュータが、
前記予定日情報を参照して、前記支払い期限日以前に、前記第1の利用者の予定日があるか否かを判定する、処理を実行し、
前記決定する処理は、
前記第1の利用者の予定日がないと判定した場合には、前記決済候補者を前記第1の利用者から前記第2の利用者に変更する、ことを特徴とする付記2に記載の情報処理方法。
(付記4)前記コンピュータが、
前記他の利用者の予定日の方が前記支払い期限日に近いと判定した場合、または前記第1の利用者の予定日がないと判定した場合には、前記第2の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第1の利用者に対応する端末装置に送信する、処理を実行し、
前記決定する処理は、
前記問い合わせを送信した結果、前記第2の利用者が前記未払い代金を支払うことを許可する応答を前記端末装置から受信したことに応じて、前記決済候補者を前記第1の利用者から前記第2の利用者に変更する、処理を実行することを特徴とする付記3に記載の情報処理方法。
(付記5)前記問い合わせは、前記第2の利用者を示す情報を含む、ことを特徴とする付記4に記載の情報処理方法。
(付記6)前記問い合わせは、前記第2の利用者の予定日を含む、ことを特徴とする付記4または5に記載の情報処理方法。
(付記7)前記問い合わせは、前記未払い代金に関する情報を含む、ことを特徴とする付記4〜6のいずれか一つに記載の情報処理方法。
(付記8)前記送信する処理は、
さらに、前記第2の利用者が前記未払い代金の支払い適格を満たしている場合に、前記第2の利用者が前記未払い代金を支払うことを許可するか否かの問い合わせを、前記第1の利用者に対応する端末装置に送信する、ことを特徴とする付記4〜7のいずれか一つに記載の情報処理方法。
(付記9)前記出力する処理は、
前記決済候補者を前記第1の利用者から前記第2の利用者に変更した場合に、前記第2の利用者に対応する端末装置に前記未払い代金の支払い要求を送信する、ことを特徴とする付記2〜8のいずれか一つに記載の情報処理方法。
(付記10)前記支払い要求は、前記第2の利用者を示す情報を含む、ことを特徴とする付記9に記載の情報処理方法。
(付記11)前記支払い要求は、前記第2の利用者の予定日を含む、ことを特徴とする付記9または10に記載の情報処理方法。
(付記12)前記支払い要求は、前記未払い代金に関する情報を含む、ことを特徴とする付記9〜11のいずれか一つに記載の情報処理方法。
(付記13)前記決定する処理は、
さらに、前記第2の利用者が前記未払い代金の支払い適格を満たしている場合に、前記決済候補者を前記第1の利用者から前記第2の利用者に変更する、ことを特徴とする付記2〜12のいずれか一つに記載の情報処理方法。
(付記14)前記決定する処理は、
さらに、前記予定日情報を参照して、前記第1の利用者の予定日になった場合に、前記決済候補者を決定する、ことを特徴とする付記2〜13のいずれか一つに記載の情報処理方法。
(付記15)前記決定する処理は、
さらに、前記支払い期限日以前である所定の日になった場合に、前記決済候補者を決定する、ことを特徴とする付記1〜14のいずれか一つに記載の情報処理方法。
(付記16)前記決定する処理は、
前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者が前記未払い代金の支払い適格を満たしている場合に、前記決済候補者を前記支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者に決定する、ことを特徴とする付記1に記載の情報処理方法。
(付記17)コンピュータに、
所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
処理を実行させることを特徴とする情報処理プログラム。
(付記18)所定の施設を利用する複数の利用者と、前記複数の利用者それぞれが前記施設を訪れる予定日とを対応付けた予定日情報を参照して、前記予定日情報に含まれる予定日のうち前記複数の利用者の未払い代金についての支払い期限日以前の予定日であって、かつ、前記支払い期限日に最も近い予定日に対応付けられた利用者を、前記未払い代金を支払う決済候補者に決定し、
前記決済候補者に決定された前記利用者を示す情報を出力する、
制御部を有することを特徴とする情報処理装置。