JP2004348765A - 予約受付方法、事前呼出方法及びそのプログラム - Google Patents

Abstract

【課題】 高いセキュリティを確保でき、電気通信回線に異常が発生しても業務を継続できる予約受付方法を提供する。
【解決手段】 ユーザが予約を希望するとき、ユーザ端末６に予約依頼を入力する。ユーザ端末６は予約依頼をリモートサーバ２に送信する。リモートサーバ２は予約依頼を保存する。受付処理装置１がリモートサーバ２へ問い合わせメッセージを送信したとき、リモートサーバ２は問い合わせメッセージに応答したのち、保存した予約依頼を受付処理装置１に送信する。受付処理装置１は受信した予約依頼に基づいて予約受付を行う。以上の動作により、受付処理装置１は問い合わせメッセージに応答したサーバから情報を受けるため、不正アクセスを防止できる。
【選択図】 図１

Description

本発明は、予約受付方法及びそのプログラムに関し、さらに詳しくは、ユーザ端末と、前記ユーザ端末と電気通信回線を介して接続可能なリモートサーバと、前記リモートサーバと前記電気通信回線を介して接続可能な受付処理装置とを用いた、サービスの提供を受けるための予約受付方法及びそのプログラムに関する。

現在、銀行では受付窓口への先着順に利用者に予約受付番号を発行し、予約受付番号順に利用者に対してサービスを提供している。また、病院では先着順に予約受付番号を発行し、予約受付番号順に診察を行っている。

以上に示したように、銀行や病院のようなユーザに来所してもらいサービスを提供する業種では、先着順にサービスを提供するために予約受付番号を発券するシステムが導入されている場合がある。

しかしながら、発券システムの場合はサービス窓口や診察室といったサービス提供所に列をなして並ぶ必要はないものの、サービス提供所付近にはとどまっておく必要があった。なぜなら呼出を受ける時期は不明であり、電光掲示板の見える範囲又は呼出音声が聞こえる範囲内にいなければ、自己の予約受付番号が呼び出されたか否かがわからないからである。よって、受付後サービスを受けるまでの時間帯は銀行内や病院内といった所定の場所に拘束されなければならず、時間の無駄が生じていた。

このような時間の無駄の解消を目的として、近年携帯電話によるインターネット接続機能を使った診察申し込みシステムが注目を浴びている。しかしながら、セキュリティの確保の問題やインターネットで障害が発生した場合にシステムが停止する等の問題がある。
特公昭６１−２２３３９号公報 特公昭６３−４１１０５号公報 特公平７−１１７９７０号公報 特開２０００−２５９７４６号公報 特開２００２−７４００５号公報 特開２００２−１３３１３１号公報 特開２００２−１３３１３２号公報 特開２００１−３３１５９０号公報

本発明の目的は、予約受付後サービスの提供を受けるまでの時間を有効に利用できる予約受付システムを提供することである。

本発明の他の目的は、高いセキュリティを確保でき、電気通信回線に異常が発生しても業務を継続できる予約受付システムを提供することである。

課題を解決するための手段及び発明の効果

本発明による予約受付方法は、ユーザ端末と、ユーザ端末に接続可能なリモートサーバと、リモートサーバに接続可能な受付処理装置とによる予約受付方法であって、ユーザ端末からリモートサーバに予約依頼を送信するステップと、リモートサーバに送信された予約依頼を受付処理装置に送信するステップと、受付処理装置に送信された予約依頼に基づいて予約受付を行うステップとを備える。

ユーザが予約を行うとき、ユーザはユーザ端末に予約依頼を入力する。ユーザ端末は入力された予約依頼をリモートサーバに送信する。予約依頼を受信したリモートサーバは、その予約依頼を受付処理装置に送信する。このように、予約依頼はユーザ端末から必ずリモートサーバを経由して受付処理装置へ送信される。よって、受付処理装置はユーザ端末から予約依頼等の情報を直接受信することはない。そのため、受付処理装置はユーザ端末からの不正アクセスを防止でき、受付処理装置のセキュリティは向上する。その結果、不正アクセス等による受付処理装置の動作停止を防止でき、受付処理装置は継続して動作することができる。

好ましくは、予約受付方法はさらに、受付処理装置からリモートサーバに問い合わせを行うステップを備え、予約依頼を受付処理装置に送信するステップでは、問い合わせに応じて、予約依頼を送信する。

この場合、リモートサーバは受付処理装置からの問い合わせがない限り、予約依頼を受付処理装置に送信しない。すなわち、受付処理装置は自身が発信した問い合わせに応じてリモートサーバから送信される予約依頼しか受信しない。よって、受付処理装置のセキュリティはさらに向上する。

なお、この場合、受付処理装置のアドレスを固定する必要がなくなる。なぜなら、リモートサーバから受付処理装置に予約依頼が送信される場合、必ずその前に受付処理装置からリモートサーバへ問い合わせが行われ、その問い合わせによりリモートサーバが受付処理装置のアドレスを特定するからである。よって、受付処理装置は専用線を利用しなくてよく、設備費用を抑えることができる。

好ましくは、予約受付方法はさらに、問い合わせに対するリモートサーバからの応答を所定期間内に受付処理装置が受信したか否かを判断するステップと、応答を所定期間内に受信しなかったと判断した場合、受付処理装置のオペレータに警告を通知するステップとを備える。

この場合、受付処理装置はリモートサーバに問い合わせをした後、所定期間内にリモートサーバからの応答を受信したか否かを判断する。リモートサーバからの応答がない場合は、電気通信回線やリモートサーバに何らかの障害が発生していると考えられる。そこで、応答がない場合、受付処理装置はオペレータに対して音声や画面表示等により警告を通知する。その結果、オペレータは電気通信回線やリモートサーバに障害が発生していることを容易に認識でき、迅速な対応を行うことができる。

好ましくは、予約受付方法はさらに、受付処理装置からリモートサーバに予約状況を示す予約状況データを所定期間ごとに送信するステップと、ユーザ端末からの要求に応じてリモートサーバからユーザ端末に予約状況データを送信するステップとを備える。

この場合、受付処理装置は予約状況データを所定期間ごとにリモートサーバに送信する。そのため、リモートサーバ内の予約状況データを受付処理装置内の予約状況データに同期させることができる。さらに、リモートサーバはユーザ端末からの要求に応じて予約状況データを返信する。これにより、ユーザは予約依頼を行う前にほぼ最新の予約状況を参照できる。

好ましくは、予約受付方法はさらに、ユーザ端末からリモートサーバに予約受付番号を送信するステップと、リモートサーバに送信された予約受付番号及び予約状況データに基づいて、サービスの提供を受けるまでの待ち人数及び／又は待ち時間を呼出状況データとして算出するステップと、リモートサーバからユーザ端末に呼出状況データを送信するステップとを備える。

この場合、ユーザ端末のユーザは予約完了後に、予約受付番号をユーザ端末からリモートサーバに送信する。リモートサーバは予約受付番号及び予約状況データに基づいて、ユーザがサービスの提供を受けるまでの待ち人数及び／又は待ち時間を呼出状況データとして算出する。算出された呼出状況データはユーザ端末に送信される。よって、ユーザは自分がサービスの提供を受けるまでにあとどの位の待ち人数がいるか、又はどの位の待ち時間があるかを把握できる。その結果、ユーザがサービスの提供を受けるまでの時間を有効に活用できる。

本発明による事前呼出方法は、サービスの提供を受けるまでの呼出状況データを有するリモートサーバに接続可能なユーザ端末による事前呼出方法であって、外部から入力された呼出条件を保存するステップと、外部から入力された予約受付番号をリモートサーバに送信するステップと、予約受付番号に基づいてリモートサーバから送信された呼出状況データを受信するステップと、呼出状況データが呼出条件を満たすか否かを判断するステップと、呼出条件を満たしたとき、ユーザ端末のユーザに呼出条件を満たした旨を通知するステップとを備える。

本発明による事前呼出方法では、ユーザはたとえばサービスを受けるまでの待ち人数が１０人未満になった場合に通知する等の呼出条件をユーザ端末に入力する。その後、ユーザはユーザ端末に予約受付番号を入力し、ユーザ端末は入力された予約受付番号をリモートサーバに送信する。リモートサーバは予約受付番号に基づいて予約受付番号のユーザがサービスの提供を受けるまでの呼出状況データをユーザ端末に送信する。ユーザ端末は受信した呼出状況データが呼出条件を満たすか否かを判断し、満たした場合はその旨の通知を音声や振動、又は画面表示等により行う。その結果、ユーザは自分がサービスの提供を受ける番が近づいている旨をユーザ端末に知らせてもらうことができる。その結果、ユーザは自分がサービスの提供を受けるまでの時間を有効に活用できる。

好ましくは、事前呼出方法は、判断するステップで呼び出し条件を満たさないと判断したとき、予約受付番号をリモートサーバに送信するステップと、呼出状況データを受信するステップと、呼出状況データが呼出条件を満たすか否かを判断するステップとを繰り返す。

この場合、ユーザ端末は呼出状況データが呼出条件を満たすまで、予約受付番号をリモートサーバに送信し、呼出状況データを受信し、受信した呼出状況が呼出条件を満足するか否かを判断するという一連の動作を繰り返す。その結果、ユーザは１回呼出条件及び予約受付番号を入力すれば、繰り返し予約受付番号の入力を繰り返すことなく自分がサービスの提供を受ける番が近づいている旨をユーザ端末に知らせてもらうことができる。

以下、本発明の実施の形態を図面を参照して詳しく説明する。図中同一又は相当部分には同一符号を付してその説明を援用する。

１．予約受付システムの全体構成

図１を参照して、予約受付システム１０は、受付処理装置１とリモートサーバ２とを備える。受付処理装置１とリモートサーバ２とはインターネット等の電気通信回線３を介して接続される。

受付処理装置１は、ＣＰＵ(Central Processing Unit)１１と、メモリ１２と、ハードディスク１３と、掲示ディスプレイ１５と、マウスやキーボード等の入力部１６と、発券部１７とを含む。ハードディスク１３はメイン側状況データファイル１３１とメイン側受付データファイル１３２とを含む。メイン側状況データファイル１３１は、発行済みの予約受付番号のうちの最新の予約受付番号、待ち人数、待ち時間、現在呼び出し中の予約受付番号や呼び出し時に不在であった者の予約受付番号等の情報（以下、状況データと称する）を記憶する。メイン側受付データファイル１３２は予約依頼を記憶する。掲示ディスプレイ１５は病院内で来訪者が閲覧可能な場所に設置されるのが好ましい。また、病院内に複数の診察室がある場合は、入力部１６は受付場所及び診察室ごとに設置されてもよい。発券部１７は来訪者に対して予約受付番号券を発行する。受付処理装置１はリモートサーバ２から送信される予約依頼に基づいて、診察の予約受付業務を行う。また、受付処理装置１はリモートサーバ２とは独立して、予約の受付を行うこともできる。

一方、リモートサーバ２は、ＣＰＵ２１と、メモリ２２と、ハードディスク２３とを含む。ハードディスク２３は、リモート側状況データファイル２３１と、リモート側受付データファイル２３２と、統計データファイル２３３とを含む。リモート側状況データファイル２３１は受付処理装置１から送信された状況データが保存される。リモート側受付データファイル２３２はユーザが利用するＰＤＡ（ Personal Digital Assistant ）や携帯電話機等の携帯端末４又は固定端末５（以下、携帯端末４及び固定端末５をユーザ端末６とも称する）から送信された予約依頼を保存する。統計データファイル２３３は所定期間ごと（たとえば、１時間ごと）の状況データの統計結果が保存される。リモートサーバ２はユーザ端末６から電気通信回線３を介して予約依頼を受ける。リモートサーバ２が予約依頼を受けることで、ユーザは病院へ行く前に自宅又は外から診察を予約できる。

受付処理装置１及びリモートサーバ２に予約受付プログラムをインストールすることで、受付処理装置１及びリモートサーバ２は以下に示す予約受付処理を実行できる。なお、予約受付プログラムはメモリ１２及びメモリ２２にマイクロプログラムとして予め記憶されていてもよい。

また、携帯端末４はＣＰＵ４１及びメモリ４２を含み、事前呼出プログラムをインストールすることで、事前呼出処理を行うことができる。携帯端末４は予め事前呼出プログラムをインストールされたうえで販売されてもよい。また、リモートサーバ２のハードディスク２３に事前呼出プログラムが予め保存されており、ユーザが携帯端末４を購入後、リモートサーバ２から事前呼出プログラムを携帯端末４にダウンロードしてもよい。

２．遠隔予約受付処理

予約受付システム１０による予約受付処理のうち、病院外にいるユーザから予約受付を行う動作（以下、遠隔予約受付処理と称する）について説明する。ユーザが在宅のまま診察の予約を行う場合や、外出しているユーザが診察の予約を行う場合に遠隔予約受付処理が行われる。

遠隔予約受付処理はリモートサーバ２がユーザ端末６から予約依頼を受ける処理（仮予約受付処理）と、所定期間ごとにリモートサーバ２が受付処理装置１へ予約依頼を送信し、受付処理装置１がユーザの予約を受け付ける処理（本予約受付処理）と、予約受付が完了したか否かをユーザが問い合わせる処理（予約完了問い合わせ処理）とに分かれる。以下、それぞれの処理について説明する。

２−１．仮予約受付処理
図２を参照して、ユーザが病院の予約を行いたい場合、ユーザはユーザ端末６の予約依頼情報入力画面に予約依頼情報を入力する（Ｓ１０１）。図３にユーザが携帯端末４を用いた場合の予約依頼情報入力画面を示す。予約依頼情報にはユーザの氏名、生年月日、携帯電話番号、初診でない場合は診察券番号をそれぞれ入力する。なお、ユーザの氏名と診察券番号と生年月日とがユーザＩＤと連結してリモートサーバ２のハードディスク２３内に予め保存されている場合は、ユーザは予約依頼情報としてユーザＩＤをユーザ端末６に入力してもよい。ユーザ端末６は入力された予約依頼情報をリモートサーバ２に送信する（Ｓ１０２）。リモートサーバ２は予約依頼情報を受信後（Ｓ１０３）、受信前の所定期間内に定期通信処理が行われたか否かを判断する（Ｓ１０４）。ここで、定期通信処理とは、受付処理装置１とリモートサーバ２との間で情報を定期的に送受信する処理をいう。定期通信処理については後述する。定期通信処理が行われたか否かは、リモート側状況データファイル２３１内の状況データがステップＳ１０３の受信前の所定期間内に更新されているか否かで判断される。

ステップＳ１０４で定期通信処理が行われていないと判断した場合、リモートサーバ２は予約受付システム１０内で異常が発生していると判断する。なぜなら、定期通信処理が行われていないということは、受付処理装置１に異常が発生しているか、又は電気通信回線３に異常が発生していると考えられるからである。よってこの場合、リモートサーバ２は予約受付システムが現在停止している旨の通知（以下、エラー通知と称する）をユーザ端末６に送信する（Ｓ１０５）。ユーザ端末６は停止している旨の情報を受信し、ディスプレイ（図示せず）に表示する（Ｓ１０８）。

一方、ステップＳ１０４での判断の結果、所定期間内に定期通信処理が行われていたと判断した場合、リモートサーバ２は仮予約受付処理を行う（Ｓ１０６）。具体的には、リモートサーバ２はユーザ端末６から送信された予約依頼情報をリモート側受付データファイル２３２に記憶する。

仮予約受付処理が終了した後、リモートサーバ２は仮予約受付完了通知をユーザ端末６に送信する（Ｓ１０７）。ユーザ端末６は仮予約受付完了通知を受信し、ディスプレイに表示する（Ｓ１０８）。

２−２．本予約受付処理
仮予約受付処理が完了しただけでは、ユーザの予約は完了しない。受付処理装置１がユーザの予約受付を行って初めてユーザの予約が完了する。そのため、受付処理装置１がリモートサーバ２から予約依頼情報を取得する本予約受付処理が行われる。図４に本予約受付処理の動作を示す。なお、図４に示すように、本予約受付処理の全体動作をステップＳ２０とする。

図４を参照して、本予約受付処理（Ｓ２０）は受付処理装置１とリモートサーバ２とが定期的に情報を送受信する定期通信処理の後で行われる。なお、定期通信処理については後述する。受付処理装置１はリモート側受付データファイル２３２に新たな予約依頼情報が記録されているか否かを判断する。（Ｓ２０２〜Ｓ２０６）。ここで、新たな予約依頼情報とは、前回の本予約受付処理以降にリモート側受付データファイル２３２に保存された予約依頼情報をいう。受付処理装置１は新たな予約依頼情報の有無についての問い合わせメッセージをリモートサーバ２に送信する（Ｓ２０２）。リモートサーバ２は問い合わせメッセージを受信後（Ｓ２０３）、リモート側受付データファイル２３２内に新たな予約依頼情報が保存されているか否かを判断し、その判断結果を送信する（Ｓ２０４）。受付処理装置１はリモートサーバ２からの判断結果を受信後（Ｓ２０５）、判断結果に基づいて新たな予約依頼情報の有無を判断する（Ｓ２０６）。判断の結果、新たな予約依頼情報がない場合、受付処理装置１は予約受付処理を終了する。

一方、新たな予約依頼情報がある場合、受付処理装置１はリモート側受付データファイル２３２に保存されている予約依頼情報を取得する処理を行う（Ｓ２０７〜Ｓ２１５）。具体的には、受付処理装置１は予約依頼情報の要求メッセージをリモートサーバ２に送信する（Ｓ２０７）。リモートサーバ２は要求メッセージを受信後（Ｓ２０８）、リモート側受付データファイル２３２に保存された予約依頼情報を受付処理装置１に送信する（Ｓ２０９）。受付処理装置１は予約依頼情報を受信後、ハードディスク１３内のメイン側受付データファイル１３２に保存する（Ｓ２１０）。

予約依頼情報を保存後、受付処理装置１はメイン側状況データファイル１３１に保存された最新の状況データと保存した予約依頼情報とに基づいて、予約受付番号計算処理（Ｓ２１１）、待ち人数計算処理（Ｓ２１２）及び待ち時間計算処理（Ｓ２１３）を行う。予約受付番号計算処理では、予約依頼の早かった予約依頼情報順に予約受付番号を付与する（Ｓ２１１）。具体的には、状況データ内の最新の発行済み予約受付番号を参照して、予約依頼の早かった予約依頼情報ごとに予約受付番号を順次カウントアップさせて付与する。たとえば、ステップＳ２１０で受信した予約依頼が３件あり、状況データ内の最新の発行済み予約受付番号が「３００５０」である場合、受付処理装置１は予約依頼の早かった予約依頼情報ごとに「３００５１」、「３００５２」、「３００５３」の予約受付番号を付与する。なお、予約受付番号は１０ずつカウントアップさせ、「３００６０」、「３００７０」、「３００８０」としてもよい。また、待ち人数計算処理では、次の式（１）により待ち人数を算出する（Ｓ２１２）。

待ち人数＝予約受付番号−呼出番号 （１）
ここで、呼出番号とは、診察室から呼び出しを受けた番号（すなわち、診察待ちが終了した番号）である。待ち時間計算処理では、次の式（２）により待ち時間を算出する（Ｓ２１３）。

待ち時間＝待ち人数×予想時間 （２）
ここで、予想時間は任意に決定できる時間である。たとえば病院での診察が１人当たり平均５分かかるのであれば、予想時間＝５分とすることができる。さらに、時間帯によって１人当たりの診察時間が異なる場合や、内科や外科といったように分野により診察時間が異なる場合は、時間帯や分野ごとに予想時間を決定できる。さらに、待ち人数が１人〜１０人までの間は予想時間＝３分とし、待ち人数１１人以降については予想時間＝５分というように、待ち人数に応じて予想時間を変えることもできる。なお、ステップＳ２１１〜Ｓ２１３の算出結果はメイン側状況データファイル１３１に保存される。

以上の計算処理を終了後、受付処理装置１はステップＳ２１２で算出した予約受付番号に基づいて予約受付番号券を発券部１７から発行する（Ｓ２１４）。また、ステップＳ２１１で算出した待ち人数及びステップＳ２１３で算出した待ち時間の情報を病院内の掲示ディスプレイ１５に表示する（Ｓ２１５）。ステップＳ２１５における掲示ディスプレイの画面を図５に示す。呼出番号表示部２０１に呼出番号が、待ち人数表示部２０２に待ち人数が、待ち時間表示部２０３に待ち時間がそれぞれ表示される。受付処理装置１はＳ２１１〜Ｓ２１５の動作をＳ２１０で受診した予約情報数分繰り返す。

以上の動作を終了後、受付処理装置１はＳ２１１で算出した予約情報ごとの予約受付番号をリモートサーバ２に送信する（Ｓ２１６）。なお、予約受付番号の送信時にメイン側状況データファイル１３１に保存された状況データも送信される。リモートサーバ２は予約依頼情報ごとの予約受付番号を受信後（Ｓ２１７）、予約受付番号を対応する予約依頼情報とリンクしてリモート側受付データファイル２３２に保存する（Ｓ２１８）。なお、待ち人数、待ち時間及び呼出番号はリモート側状況データファイル２３１に保存される。

２−３．予約完了問い合わせ処理
ユーザはユーザ端末６を用いて受付処理装置１での予約受付が完了したか否かを問い合わせできる。図６を参照して、ユーザはユーザ端末６を用いて問い合わせメッセージをリモートサーバ２へ送信する（Ｓ３０１）。図７にユーザが携帯端末４を用いた場合のステップＳ３０１での携帯端末画面を示す。このとき、ユーザが画面中の「確認画面を見る」を選択すれば、携帯端末４からリモートサーバ２へ問い合わせメッセージが送信される。リモートサーバ２は問い合わせメッセージを受信後（Ｓ３０２）、予約受付が受付処理装置１で完了したか否かを判断する（Ｓ３０３）。具体的には、リモートサーバ２はユーザ端末６を特定する情報（たとえば電話番号や予めリモートサーバ２から付与される識別番号等）からリモート側受付データファイル２３２内のユーザの予約依頼情報を参照し、その予約依頼情報が受付処理装置１から付与された予約受付番号を有するか否かを判断する。判断の結果、予約受付番号を有しない場合、リモートサーバ２は予約受付が未完了である旨の通知（未完了通知）をユーザ端末６に送信する（Ｓ３０４）。ユーザ端末６は未完了通知を受信後、ディスプレイに表示する（Ｓ３０５）。

一方、ステップＳ３０３での判断の結果、予約受付番号を有している場合、リモートサーバ２はユーザ端末６に対して、付与された予約受付番号とリモート側状況データファイル２３１内の状況データとを送信する（Ｓ３０４）。ユーザ端末６は予約受付番号と状況データとを受信後、予約受付番号と状況データとをディスプレイに表示する（Ｓ３０５）。このときの携帯端末４の画面を図８に示す。

以上の動作により、ユーザは病院に行くことなく、病院外から診察の予約を行うことができる。

３．定期通信処理
受付処理装置１とリモートサーバ２とは所定期間ごとに情報を授受する定期通信処理を行う。定期通信処理を行うことで、メイン側状況データファイル１３１内の情報とリモート側状況データファイル２３１内の状況データとを同期させる。図９に定期通信処理の動作を示す。なお、図９中の受付処理装置１側での定期通信処理動作を定期通信処理Ｓ４１、リモートサーバ２側での定期通信処理動作を定期通信処理Ｓ４２とする。

図９を参照して、受付処理装置１は定期通信処理として初めにオンラインフラグがオンか否かを判断する（Ｓ４０１）。オンラインフラグは、予約受付システム１０が正常に動作している場合は「オン」となり、何らかの異常により予約受付システム１０が正常に動作していない場合は「オフ」となる。オンラインフラグはハードディスク１３内に記憶されている。オンラインフラグが「オフ」の場合（Ｓ４０１）、定期通信処理は一端終了し、所定期間経過後に（Ｓ４１５）再びステップＳ４０１に戻る。一方、オンラインフラグが「オン」の場合、受付処理装置１は定期通信の準備を行う（Ｓ４０２）。具体的には前回の定期通信処理後に更新された状況データ（以下、更新データと称する）をメイン側状況データファイル１３１から検索する。検索された更新データは送信可能なデータフォーマットに変換される。

定期通信準備を終了後、受付処理装置１は更新データを含む定期通信メッセージをリモートサーバ２に送信する（Ｓ４０３）。リモートサーバ２は定期通信メッセージを受信後（Ｓ４０４）、受信したメッセージが有効か否かを判断する（Ｓ４０５）。メッセージの有効性を判断する１つの理由は、更新データのデータ落ちや更新データの文字化け等がないかチェックするためである。また、他の理由は、送信されたメッセージが受付処理装置１から送信されたものか否かをチェックすることで、不正アクセスを防止するためである。

判断の結果、メッセージが有効である場合（Ｓ４０５）、リモートサーバ２はステータスを「ＯＫ」とし（Ｓ４０６）、受信した更新データをリモート側状況データファイル２３１に保存する（Ｓ４０７）。このとき、更新日時も保存される。一方、判断の結果、メッセージが無効である場合（Ｓ４０５）、リモートサーバ２はステータスを「ＮＧ」とする（Ｓ４０８）。なお、ステータスはハードディスク２３内に記録される。ステータスを決定後、リモートサーバ２は応答メッセージを受付処理装置１に送信する（Ｓ４０９）。なお、応答メッセージにはステータス情報が含まれる。

受付処理装置１はステップＳ４０３でメッセージを送信後、リモートサーバ２からの応答メッセージを所定期間待つ（Ｓ４１０）。所定期間を経過しても応答メッセージがない場合（Ｓ４１１）、受付処理装置１は、電気通信回線３又はリモートサーバ２になんらかの異常が発生していると判断し、エラー通知を掲示ディスプレイ１５に表示する（Ｓ４１３）。なお、エラー通知は音又は音声により行われてもよい。その後、受付処理装置１はオンラインフラグを「オフ」とする（Ｓ４１４）。なお、オンラインフラグを「オフ」とする作業は手動で行っても良い。オンラインフラグを「オフ」とすることで、受付処理装置１は電気通信回線３から完全に独立し、後述するように病院内にて予約受付処理を単独で行うことができる。

一方、所定期間内に応答メッセージを受けた場合（Ｓ４１１）、受信した応答メッセージに含まれるステータスがＯＫか否かを判断する（Ｓ４１２）。判断の結果、ステータスがＯＫの場合、図４に示した本予約受付処理Ｓ２０を行う。ステップＳ４１２での判断の結果、ステータスがＮＧの場合、電気通信回線３又はリモートサーバ２でトラブルが発生していると判断し、エラー通知を掲示ディスプレイ１５に表示する（Ｓ４１３）。このとき、オンラインフラグは自動又は手動により「オフ」とする（Ｓ４１４）。

以上の動作により、本発明の実施の形態による予約受付システムでは、受付処理装置１及びリモートサーバ２の２つのサーバを用いて定期通信処理を行う。そのため、電気通信回線３又はリモートサーバ２になんらかのトラブルが発生しても、受付処理装置１は単独で予約受付処理を行うことができる。よって、トラブル発生時も予約受付システム１０を稼働させ続けることができ、システム全体は停止しない。また、定期通信処理では、定期通信メッセージは必ず受付処理装置１からリモートサーバ２へ送信され、その逆はない。すなわち、受付処理装置１は自分が定期通信メッセージを送信し、応答してきたリモートサーバ２以外とは情報の送受信を行わない。よって、受付処理装置１のセキュリティを極めて高くすることができる。

４．呼出状況通知処理
遠隔予約受付処理により受付処理装置１で予約受付を完了し、予約受付番号を付与されたユーザは、自分の予約受付番号が呼ばれるまでの待ち人数及び待ち時間等の情報（呼出状況データ）の通知を受けることができる（呼出状況通知処理）。図１０を参照して、ユーザはユーザ端末６に予約受付番号を入力し、ユーザ端末６は入力された予約受付番号を含む問い合わせメッセージをリモートサーバ２に送信する（Ｓ５０１）。ステップＳ５０１で携帯端末４を用いた場合の予約受付番号入力画面を図１１に示す。リモートサーバ２は問い合わせメッセージを受信後（Ｓ５０２）、受信前の所定期間内に定期通信処理がなされたか否かを判断する（Ｓ５０３）。定期通信処理がなされたか否かの判断は、リモート側状況データファイル２３１内の更新日時記録を参照して行う。

判断の結果、定期通信処理がなされていない場合（Ｓ５０３）、電気通信回線３又は受付処理装置１に異常が発生していると判断する。このときリモートサーバ２はエラー通知をユーザ端末６に送信する（Ｓ５０４）。一方、定期通信処理がなされている場合、リモートサーバ２は予約受付システム１０が正常に動作していると判断する。このとき、リモートサーバ２はリモート側状況データファイル２３１内の状況データを用いて呼出状況データの算出を行う。具体的には、ステップＳ５０２で受信した予約受付番号が呼出されるまでの待ち人数と、待ち時間とを予約受付番号及び式（１），（２）を用いて算出する。算出結果は呼出状況データとしてユーザ端末６に送信される（Ｓ５０５）。ユーザ端末６は呼出状況データを受信後、ディスプレイに表示する（Ｓ５０６）。携帯端末４を用いた場合のステップＳ５０６の画面を図１２に示す。

以上の動作により、ユーザは病院外にいる場合でも、自分の予約受付番号が呼び出されるまでの待ち人数や待ち時間等の情報を把握できる。そのため、ユーザは病院で呼び出される直前まで病院内にいる必要はなく、呼び出されるまでの時間を有効に利用できる。

なお、ユーザが携帯端末４を利用している場合、呼び出される所定時間前に音振動、又は表示により呼出時間が近い旨の通知をユーザが受けるようにすることもできる。

図１３を参照して、携帯端末４のユーザは初めに予約受付番号と呼出条件とを携帯端末４に入力する（Ｓ６０１）。ここで、呼出条件とは、たとえば待ち時間が３０分未満となった場合に通知を行う、又は待ち人数が１０人よりも少なくなった場合に通知を行う、といった条件をいう。予約受付番号及び呼出条件が入力された後、携帯端末４は現在サービス圏内か否かを判断する（Ｓ６０２）。サービス圏外の場合、携帯端末４は警告音や振動により、又は、ディスプレイに警告表示を行うことにより、ユーザに注意を促す（Ｓ６０３）。その後、所定期間経過後に（Ｓ６０４）再びステップＳ６０２の動作に戻る。

一方、サービス圏内の場合、携帯端末４は入力された予約受付番号を含む問い合わせメッセージをリモートサーバ２に送信する（Ｓ６２０）。続いて、リモートサーバは図１０における呼出状況通知処理中のステップＳ５０２〜Ｓ５０５の動作を行い、エラー通知又は算出した呼出状況データを携帯端末４に送信する。携帯端末４はエラー通知又は呼出状況データを受信する（Ｓ６０５）。

受信後、携帯端末４は受信した情報に基づいて予約受付システム１０が正常に動作しているか否かを判断する（Ｓ６０６）。予約受付システムが停止している場合（すなわち、ステップＳ６０５でエラー通知を受信した場合）、携帯端末４はエラー通知をディスプレイに表示したり、警告音を発したりしてユーザの注意を促す（Ｓ６０７）。一方、予約受付システムが正常に動作している場合（すなわち、ステップＳ６０５で呼出状況データを受信した場合）、携帯端末４は呼出状況データ及びステップＳ６０１で入力した呼出条件に基づいて、ユーザに通知を行うか否かを判断する（Ｓ６０８）。具体的には、携帯端末４は呼出状況データ中の待ち時間が３０分未満か否かを判断する。又は、携帯端末４は呼出状況データ中の待ち人数が１０人未満か否かを判断する。

判断の結果、呼出状況データが呼出条件を満足していない場合、所定時間経過後（Ｓ６０４）に再びステップＳ６０２の動作に戻る。一方、呼出状況データが呼出条件を満足している場合、携帯端末４は呼出時間が近づいた旨の通知を行う（Ｓ６０９）。通知は音や振動により、又はディスプレイへの画面表示により行われる。

続いて、携帯端末４は所定期間経過後（Ｓ６１０）、キー操作が行われたか否かを判断する（Ｓ６１１）。ここで、キー操作とは、ステップＳ６０９の通知を停止させるためのキー操作であり、たとえば携帯端末４内の複数のボタン（図示せず）内のいずれかを押せばキー操作が行われたことになる。キー操作が行われた場合（Ｓ６１１）、ユーザが通知を認識したため、携帯端末４は動作を終了する。一方、キー操作が行われなかった場合（Ｓ６１１）、携帯端末４は所定時間経過後（Ｓ６０４）、再びステップＳ６０２に戻る。ユーザが通知を認識していないため、再び通知を行う必要があるためである。なお、ステップＳ６０４の所定時間は、ユーザの予約受付番号の呼出時間が近づくにつれて、短くなってもよい。たとえば、待ち時間が１０分以上の場合、ステップＳ６０４の所定時間が３分であり、待ち時間が１０分未満の場合、所定時間が１分となってもよい。

以上の動作により、ユーザは携帯端末４に一度呼出条件を入力しておけば、自己の予約受付番号の呼出が近づいたときに自動的に音声又は画面表示により通知を受ける。そのため、病院外にいたため呼出時に間に合わなかったといった事態を未然に防ぐことができる。

５．予約状況通知処理
ユーザはユーザ端末６を用いて病院の予約状況を把握することもできる。図１４を参照して、ユーザはユーザ端末６を用いて、予約状況の問い合わせメッセージを送信する（Ｓ７０１）。リモートサーバ２は問い合わせメッセージを受信後（Ｓ７０２）、受信前の所定期間内に定期通信処理を行ったか否かを判断する（Ｓ７０３）。定期通信処理が行われていない場合、リモートサーバ２はユーザ端末６へエラー通知を行う（Ｓ７０４）。このとき、ユーザ端末６はエラー通知を受け、ディスプレイに表示する（Ｓ７０６）。一方、定期通信処理が行われていた場合、リモートサーバ２はリモート側状況データファイル２３１内の状況データをユーザ端末６に送信する（Ｓ７０５）。ここで、状況データは待ち人数、待ち時間、現在呼出されている予約受付番号等を含む。ユーザ端末６は状況データを受信後、ディスプレイに表示する（Ｓ７０６）。ステップＳ７０６でのユーザ端末６のディスプレイ画面を図１５に示す。

以上の動作により、ユーザは病院に行くことなく在宅又は外出時に病院の予約状況を把握することができ、予約を行うか否かを判断するときの有効な情報を取得できる。

６．統計情報通知処理
予約状況通知処理では、ユーザが問い合わせをした時点での病院の状況データを見ることができたが、病院の混雑具合をもっと大局的に見たい場合もある。このような場合、ユーザは統計情報を参照することで、病院の１週間単位又は１ヶ月単位での混雑具合を把握できる。図１６を参照して、リモートサーバ２は所定期間ごと（たとえば１時間ごと）の状況データをリモート側状況データファイル２３１から統計データファイル２３３に保存する（Ｓ１２０１）。このとき、所定時間ごとの状況データは統計データとして保存される。所定期間ごとにデータを取得するのは混雑状況を時間単位で統計することが最も混雑状況を理解しやすいからである。ただし、統計データファイル２３３への保存条件は時間以外の条件を設定してもよい。

ユーザはユーザ端末６を用いて統計データの要求メッセージをリモートサーバ２に送信する（Ｓ１２０２）。リモートサーバ２は要求メッセージの受信後（Ｓ１２０３）、統計データファイル２３３に保存してある統計データをユーザ端末６に送信する（Ｓ１２０４）。このとき、統計内容を理解しやすいように、統計データをグラフ化して送信してもよい。ユーザ端末６は送信された統計データを受信後、ディスプレイに表示する（Ｓ１２０５）。

以上の動作により、ユーザは所定期間ごとの混雑状況を把握できる。よって、統計データを参照することで、病院の予約受付を行うときの参考にすることができる。

７．単独予約受付処理
以上に示した処理は受付処理装置１とリモートサーバ２との間で情報を送受信することにより予約受付を行っていた。しかしながら、先述したとおり、受付処理装置１が独立して予約受付処理を行うこともできる。以下、受付処理装置１単独での予約受付処理及び呼出処理（単独予約受付処理）について説明する。単独予約受付処理は発券処理と呼出処理と呼出スキップ処理とを含む。

７−１．発券処理
図１７を参照して、ユーザからの求めに応じて、病院の受付担当者は受付処理装置１の入力部１６を用いて発券操作を行う（Ｓ８０１）。たとえば、受付担当者は病院に診察を受けに来た患者から診察券等を受け取った後、受付処理装置１に発券依頼を入力する。入力が終了後、受付処理装置１はユーザに付与すべき予約受付番号を算出する（Ｓ８０２）。予約受付番号は受付順に番号をカウントされるが、１ずつカウントされてもよいし、１０ずつカウントされてもよい。ただし、たとえば予約受付番号の上位複数桁は業務（内科や外科等）の区分として使用することもでき、また上位数桁を日付に割り当てることもできる。

予約受付番号の算出後、受付処理装置１は待ち人数算出処理を行う（Ｓ８０３）。待ち人数は式(1)により算出される。続いて、受付処理装置１は待ち時間算出処理を行う（Ｓ８０４）。待ち時間は、式（２）で算出される。以上の計算を終了後、受付処理装置１は予約受付番号券を発券部１７より発券する（Ｓ８０５）。続いて、受付処理装置１は待ち人数及び待ち時間を掲示ディスプレイ１５に表示する（Ｓ８０６）。なお、ステップＳ８０２〜Ｓ８０４での算出結果はメイン側状況データファイル１３１に保存され、ステップＳ８０６以降に行われる定期通信処理（Ｓ４１，Ｓ４２）にて状況データとしてリモートサーバ２に送信される。定期通信処理は図９の動作と同じである。

７−２．呼出処理
図１８を参照して、病院内の各診察室での診断が終了した場合、その診察室の担当医又は担当看護士等は診察が終了した旨を受付処理装置１の入力部１６を用いて入力する（Ｓ９０１）。このとき、受付処理装置１は呼出番号算出処理を行う（Ｓ９０２）。具体的には、呼び出しの対象となった予約受付番号を１カウント増加する（Ｓ９０２）。続いて、受付処理装置１は待ち人数算出処理（Ｓ９０３）及び待ち時間算出処理（Ｓ９０４）を行う。待ち人数算出処理では、受付処理装置１は式（１）を用いてメイン側状況データファイル１３１に保存された待ち人数から１人分差し引く。また、待ち時間算出処理ではステップＳ９０３で更新した待ち人数に基づいて式（２）より待ち時間を算出する。なお、ステップＳ９０２〜Ｓ９０４の算出結果はメイン側状況データファイル１３１に保存される。

以上の動作を終了後、受付処理装置１は呼出音又は呼出音声を発し（Ｓ９０５）、掲示ディスプレイにステップＳ９０２で算出した呼出番号を表示する（Ｓ９０６）。以降、受付処理装置１とリモートサーバ２との間で定期通信処理（Ｓ４１，Ｓ４２）が行われる。

７−３．呼出スキップ処理
呼出を行っても診察室に患者が現れない場合、その患者が不在とみなして患者の予約受付番号をスキップ処理できる。図１９を参照して、診察室の担当医又は担当看護士が受付処理装置１の入力部１６を用いてスキップを指示する（Ｓ１００１）。このとき、メイン側状況データファイル１３１内の不在者テーブルにスキップされた予約受付番号（スキップデータ）が記録され（Ｓ１００２）、受付処理装置１の掲示ディスプレイ１５にはスキップデータが表示される。図２０にステップＳ１００３における掲示ディスプレイの画面を示す。スキップされた予約受付番号を表示することで、患者がスキップされたか否かが容易にわかるためである。

続いて、受付処理装置１はスキップした予約受付番号の数（スキップ数）をカウントする（Ｓ１００４）。スキップ数を算出後、受付処理装置１は図１８におけるステップＳ９０２〜Ｓ９０６の動作（呼出処理）を行う。呼出処理終了後、受付処理装置１は定期通信処理を行う。定期通信処理で送信する状況データには、スキップ数を含んでもよい。

なお、スキップされた予約受付番号の患者が所定期間内に現れなかった場合、や、スキップされた予約受付番号の患者が所定期間内に現れた場合、受付作業者は該当する予約受付番号を消去できる。図２１を参照して、受付作業者が受付処理装置１の入力部１６を用いて所定時間内に現れなかった患者の予約受付番号を削除する（Ｓ１１０１）。又は、所定時間内に現れて診察を行った患者の予約受付番号を削除する（Ｓ１１０２）。このとき、受付処理装置１内の不在者テーブル内の該当する予約受付番号が削除され、その結果、スキップデータは更新される（Ｓ１１０３）。更新されたスキップデータは掲示ディスプレイ１５に表示される（Ｓ１１０４）。このとき受付処理装置１はスキップ数についても更新する（Ｓ１１０５）。その後、受付処理装置１は定期通信処理（Ｓ４１，Ｓ４２）を行う。

以上の動作により、受付処理装置１単独でも予約受付処理ができる。よって、ユーザ端末６を利用しない患者に対しても、予約受付処理ができる。また、電気通信回線３に異常が発生した場合でも、受付処理装置１だけで、予約の受付及び呼び出しができる。

さらに、受付処理装置１とリモートサーバ２内の状況データは定期通信処理により同期されるため、受付処理装置１が単独予約受付処理を行った場合でも、呼出状況通知処理における呼出状況データや、混雑状況通知処理における状況データの精度が低くなることはない。

なお、本実施の形態では病院での予約受付システムについて説明したが、本発明は銀行やレストランといった所定の場所でサービスを提供する業種に対しても同様に利用できる。受付処理装置１とリモートサーバ２とは、同一業者が管理してもよいし、異なる業者が管理してもよい。また、受付処理装置１の掲示ディスプレイ１５は病院や銀行、レストランといった施設内に設置されてもよいし、病院や銀行、又はレストランの施設付近の喫茶店や商店街等に複数台設置されてもよい。掲示ディスプレイ１５を施設外に設置することで、携帯端末４等のユーザ端末６を利用しないユーザも施設内に留まって順番を待つ必要がなくなる。

本発明の実施の形態での説明中の「所定期間」は適切に定められ、全て同じ期間として設定されても良いし、個々の期間として設定されてもよい。

以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。

本発明の実施の形態による予約受付システムの全体構成を示す機能ブロック図である。 図１に示した予約受付システムの予約依頼処理の動作を示すフロー図である。 図２中のステップＳ１０１における予約依頼情報入力画面図である。 図１に示した予約受付システムの予約受付処理の動作を示すフロー図である。 図４中のステップＳ２１５における掲示ディスプレイ画面図である。 図１に示した予約受付システムの完了通知処理の動作を示すフロー図である。 図６中のステップＳ３０１における入力画面図である。 図６中のステップＳ３０５における完了通知画面図である。 図１に示した予約受付システムの定期通信処理の動作を示すフロー図である。 図１に示した予約受付システムの呼出状況通知処理の動作を示すフロー図である。 図１０中のステップＳ５０１における入力画面図である。 図１０中のステップＳ５０６における呼出状況通知画面図である。 図１に示した予約受付システムの呼出状況通知処理の他の例の動作を示すフロー図である。 図１に示した予約受付システムの混雑状況通知処理の動作を示すフロー図である。 図１４中のステップＳ７０６における混雑状況通知画面図である。 図１に示した予約受付システムの統計情報通知処理の動作を示すフロー図である。 図１に示した予約受付システムの発券処理の動作を示すフロー図である。 図１に示した予約受付システムの呼出処理の動作を示すフロー図である。 図１に示した予約受付システムのスキップ処理の動作を示すフロー図である。 図１９中のステップＳ１００３における掲示ディスプレイ画面図である。 図１に示した予約受付システムの呼出スキップ処理の他の例の動作を示すフロー図である。

符号の説明

１ 受付処理装置
２ リモートサーバ
３ 電気通信回線
４ 携帯端末
５ 固定端末
６ ユーザ端末
１３，２３ ハードディスク
１５ ディスプレイ

Claims (14)

1. ユーザ端末と、前記ユーザ端末に接続可能なリモートサーバと、前記リモートサーバに接続可能な受付処理装置とによる予約受付方法であって、
   前記ユーザ端末から前記リモートサーバに予約依頼を送信するステップと、
   前記リモートサーバに送信された予約依頼を前記受付処理装置に送信するステップと、
   前記受付処理装置に送信された予約依頼に基づいて予約受付を行うステップとを備えることを特徴とする予約受付方法。
2. 請求項１に記載の予約受付方法であってさらに、
   前記受付処理装置から前記リモートサーバに問い合わせを行うステップを備え、
   前記予約依頼を前記受付処理装置に送信するステップでは、前記問い合わせに応じて、前記予約依頼を送信することを特徴とする予約受付方法。
3. 請求項２に記載の予約受付方法であってさらに、
   前記問い合わせに対する前記リモートサーバからの応答を所定期間内に前記受付処理装置が受信したか否かを判断するステップと、
   前記応答を所定期間内に受信しなかったと判断した場合、前記受付処理装置のオペレータに警告を通知するステップとを備えることを特徴とする予約受付方法。
4. 請求項１〜請求項３のいずれか１項に記載の予約受付方法であってさらに、
   前記受付処理装置から前記リモートサーバに予約状況を示す予約状況データを所定期間ごとに送信するステップと、
   前記ユーザ端末からの要求に応じて前記リモートサーバから前記ユーザ端末に前記予約状況データを送信するステップとを備えることを特徴とする予約受付方法。
5. 請求項４に記載の予約受付方法であってさらに、
   前記ユーザ端末から前記リモートサーバに予約受付番号を送信するステップと、
   前記リモートサーバに送信された予約受付番号及び前記予約状況データに基づいて、サービスの提供を受けるまでの待ち人数及び／又は待ち時間を呼出状況データとして算出するステップと、
   前記リモートサーバから前記ユーザ端末に前記呼出状況データを送信するステップとを備えることを特徴とする予約受付方法。
6. ユーザ端末から予約依頼を受信するリモートサーバに接続可能な受付処理装置による予約受付方法であって、
   前記リモートサーバに問い合わせを行うステップと、
   前記問い合わせに応じて前記リモートサーバから送信される予約依頼を受信するステップと、
   前記予約依頼に基づいて予約受付を行うステップとを備えることを特徴とする予約受付方法。
7. 請求項６に記載の予約受付方法であってさらに、
   前記問い合わせに対する前記リモートサーバからの応答を所定期間内に受信したか否かを判断するステップと、
   前記応答を所定期間内に受信しなかったと判断した場合、前記受付処理装置のオペレータに警告を通知するステップとを備えることを特徴とする予約受付方法。
8. 予約受付を行う受付処理装置及びユーザ端末に接続可能なリモートサーバによる予約受付方法であって、
   前記ユーザ端末から送信された予約依頼を保存するステップと、
   前記受付処理装置からの問い合わせに応じて前記保存された予約依頼を前記受付処理装置に送信するステップとを備えることを特徴とする予約受付方法。
9. 請求項８に記載の予約受付方法であってさらに、
   所定期間ごとに前記受付処理装置から送信される予約状況を示す予約状況データを受信するステップと、
   前記ユーザ端末からの要求に応じて、前記予約状況データを前記ユーザ端末に送信するステップとを備えることを特徴とする予約受付方法。
10. 請求項９に記載の予約受付方法であってさらに、
    前記ユーザ端末から予約受付番号を受信するステップと、
    前記予約受付番号及び前記予約状況データに基づいて、サービスの提供を受けるまでの待ち人数及び／又は待ち時間を呼出状況データとして算出するステップと、
    前記呼出状況データを前記ユーザ端末に送信するステップとを備えることを特徴とする予約受付方法。
11. 請求項１〜請求項１０のいずれかに１項に記載のステップをコンピュータに実行させるための予約受付プログラム。
12. サービスの提供を受けるまでの呼出状況データを有するリモートサーバに接続可能なユーザ端末による事前呼出方法であって、
    外部から入力された呼出条件を保存するステップと、
    外部から入力された予約受付番号を前記リモートサーバに送信するステップと、
    前記予約受付番号に基づいて前記リモートサーバから送信された前記呼出状況データを受信するステップと、
    前記呼出状況データが前記呼出条件を満たすか否かを判断するステップと、
    前記呼出条件を満たしたとき、前記ユーザ端末のユーザに呼出条件を満たした旨を通知するステップとを備えることを特徴とする事前呼出方法。
13. 請求項１２に記載の事前呼出方法であって、
    前記判断するステップで前記呼び出し条件を満たさないと判断したとき、前記予約受付番号を前記リモートサーバに送信するステップと、前記呼出状況データを受信するステップと、前記呼出状況データが前記呼出条件を満たすか否かを判断するステップとを繰り返すことを特徴とする事前呼出方法。
14. 請求項１２又は請求項１３に記載のステップをコンピュータに実行させるための事前呼出プログラム。
    
    

Images