JP2010079374A - 受付処理システムおよび受付処理方法 - Google Patents

Abstract

【課題】顧客の待ち時間を効率よく短縮することが可能な、新規かつ改良された受付処理システムを提供する。
【解決手段】利用者が有する携帯電話と通信網を介して接続され、前記携帯電話から受け付けた取引の受付の予約に関する情報が記録された予約情報データベースを管理する予約情報管理サーバと、利用者に関する個人情報や過去の取引履歴が記録された顧客情報データベースを管理する顧客情報管理サーバと、を含んで構成され、店頭窓口での取引に関する受付予約を管理する受付処理システムにおいて、前記予約情報管理サーバは、前記携帯電話から取引の受付予約を受け付けた場合、前記顧客情報管理サーバが管理する前記顧客情報データベースに記録されている顧客情報の中から、前記携帯電話の利用者に対応する顧客情報を前記顧客情報管理サーバから取得し、前記携帯電話へ送信することを特徴とする。
【選択図】図１

Description

本発明は、受付処理システムおよび受付処理方法に関する。

従来、金融機関などの営業店において取引を開始するには、顧客は、受付用端末から受付番号が印刷された受付票を受け取り、受付番号が呼び出されるまで営業店内のロビーで待つという受付処理を行う必要がある。受付票を受け取った顧客は、取引に応じた申込書などを準備してロビーで待機し、受付番号が呼ばれた後、窓口において取引を開始することができる。

ここで、顧客に待ち時間短縮による利便性を提供するために、営業店における受付処理を短縮するためのシステムの構築が図られている。例えば、特許文献１には、顧客が携帯電話で事前入力を行うことにより、営業店が顧客の携帯電話にメールを送信することにより取引開始の順番が来たことを知らせることができるシステムが開示されている。これにより、顧客は、ロビーで待機して順番待ちをする必要がなくなる。また、特許文献２には、予約時間を設定した顧客に対して、予約時間前に携帯電話にメールを送信し、予約の確認、キャンセル、最予約などを行う機会を提供可能なシステムが開示されている。これにより、顧客は、ロビーで待機して順番待ちをする必要がなくなる。さらに、顧客は、予約のキャンセル、最予約なども携帯電話を介して行うことができる。

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

しかし、上記各特許文献に記載されたシステムを利用しても、顧客は、結局取引に応じた申込書などを記入する必要があり、顧客に負担がかかるという問題があった。また、携帯電話において申込書などを事前入力するにしても、営業店が備えている顧客情報などを利用することができなかった。したがって、記入不備などが発生することにより、窓口での取引時間が長くなり、その結果として、他の顧客の待ち時間が長くなってしまうという問題があった。さらに、顧客の携帯電話に前もってメール連絡するにしても、営業店から携帯電話を有する顧客までの距離は顧客によって異なる。したがって、顧客によっては、実際の取引可能時間よりも大幅に早く営業店に到着してしまったり、実際の取引可能時間よりも大幅に遅れて営業店に到着してしまったりし、結果として効率よく待ち時間を利用することができないという問題があった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、顧客が待ち時間を効率よく利用することが可能な、新規かつ改良された受付処理システムおよび受付処理方法を提供することにある。

上記課題を解決するために、本発明のある観点によれば、利用者が有する携帯電話と通信網を介して接続され、前記携帯電話から受け付けた取引の受付の予約に関する情報が記録された予約情報データベースを管理する予約情報管理サーバと、利用者に関する個人情報や過去の取引履歴が記録された顧客情報データベースを管理する顧客情報管理サーバと、を含んで構成され、店頭窓口での取引に関する受付予約を管理する受付処理システムにおいて、前記予約情報管理サーバは、前記携帯電話から取引の受付予約を受け付けた場合、前記顧客情報管理サーバが管理する前記顧客情報データベースに記録されている顧客情報の中から、前記携帯電話の利用者に対応する顧客情報を前記顧客情報管理サーバから取得し、前記携帯電話へ送信する受付処理システムが提供される。

係る構成により、予約情報管理サーバは、携帯電話から取引の受付の予約に関する情報を受信し、予約情報データベースに記録して管理することができる。また、予約情報管理サーバは、顧客情報管理サーバから、受付予約を行った利用者の顧客情報を取得し、携帯電話へ送信することができる。これより利用者は、顧客情報管理サーバが管理している顧客情報を携帯電話で取得することができ、当該顧客情報に基づいて取引に必要な各種情報を入力することができる。

また、前記予約情報管理サーバは、利用者が前記予約情報管理サーバから受信した前記顧客情報に基づいて前記携帯電話に入力した希望する取引に関する情報を、事前入力情報として前記予約情報データベースに記録してもよい。

また、前記受付処理システムは、営業店毎に設置され該営業店の店頭窓口で利用者の受付処理を行う受付端末と、営業店毎に設置され該営業店の店頭窓口での利用者の受付状況に関する情報が記録された受付情報データベースを管理する受付情報管理サーバと、をさらに備えてもよい。この場合、前記受付情報管理サーバは、前記顧客情報管理サーバが管理する前記顧客情報データベースに記録されている顧客情報の中から、前記店頭窓口で受付処理を行っている利用者に対応する顧客情報を前記顧客情報管理サーバから取得し、前記受付情報データベースに記録することもできる。

また、前記受付情報管理サーバは、前記受付情報データベースに記録されている受付状況に関する情報に基づいて、前記店頭窓口で受付処理を行っている利用者が希望する取引の待ち人数を算出し、該待ち人数に基づいて、該利用者が取引を開始することが可能な時刻を算出し、算出した待ち人数および時刻を前記受付情報データベースに記録してもよい。

また、前記受付情報管理サーバは、前記受付情報データベースに記録された前記待ち人数および時刻を前記受付端末へ送信し、前記受付端末は、前記受付情報管理サーバから送信された前記待ち人数および時刻を表示させてもよい。

また、前記予約情報管理サーバは、利用者が前記店頭窓口で受付処理を行った後に一時退店した場合に、該利用者が有する携帯電話の位置情報に基づいて、前記携帯電話に再来店の呼び出しメールを送信してもよい。

また、前記予約情報管理サーバは、一時退店している利用者が有する携帯電話の位置情報に基づいて、該利用者が前記店頭に再来店することが可能な時刻を算出し、前記受付情報管理サーバが算出した該利用者が取引を開始することが可能な時刻まで所定時間内となった場合に、再来店の呼び出しメールを前記携帯電話へ送信してもよい。

また、前記予約情報管理サーバは、一時退店している利用者が有する携帯電話の位置情報に基づいて算出した該利用者が前記店頭に再来店することが可能な時刻が、前記受付情報管理サーバが算出した該利用者が取引を開始することが可能な時刻から所定時間経過している場合には、再来店の予定変更に関する情報を前記携帯電話へ送信してもよい。

また、前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が今後取引を開始することが可能な時刻に関する情報を前記受付情報管理サーバから取得し、前記携帯電話へ送信してもよい。

また、前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が他の営業店の店頭において今後取引を開始することが可能な時刻に関する情報を、前記他の営業店の店頭に備えられる受付情報管理サーバから取得し、前記携帯電話へ送信してもよい。

また、前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が有する前記携帯電話から取得した位置情報に基づいて該利用者の現在位置から近い営業店を検索し、該利用者が検索された営業店の店頭において今後取引を開始することが可能な時刻に関する情報を、前記検索された営業店の店頭に備えられる受付情報管理サーバから取得し、前記携帯電話へ送信してもよい。

また、利用者が前記店頭窓口で受付処理を行った後に一時退店を希望する場合、前記顧客情報管理サーバは、前記携帯電話のＩＣチップに記録される携帯電話固有情報と前記携帯電話のメールアドレスとを関連付けて前記顧客情報データベースに記録してもよい。

また、前記顧客情報管理サーバは、前記店頭窓口で受付処理をしている利用者が有する携帯電話のＩＣチップに記録されている携帯電話固有情報を、非接触ＩＣリーダライタを介して取得し、該利用者が有する前記携帯電話のメールアドレスを、前記予約情報管理サーバを介して取得し、取得した前記携帯電話固有情報と前記メールアドレスとを関連付けて前記顧客情報データベースに記録してもよい。

また、前記顧客情報管理サーバは、前記携帯電話から取得した前記携帯電話固有情報に関連付けられたメールアドレスが前記顧客情報データベースに既に記録されている場合には、該メールアドレスを前記予約情報管理サーバへ送信し、前記予約情報管理サーバは、前記顧客情報管理サーバから送信された前記メールアドレスを、該利用者の前記事前入力情報と関連付けて前記予約情報データベースに記録してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、利用者が有する携帯電話と通信網を介して接続され、前記携帯電話から受け付けた取引の受付の予約に関する情報が記録された予約情報データベースを管理する予約情報管理サーバと、利用者に関する個人情報や過去の取引履歴が記録された顧客情報データベースを管理する顧客情報管理サーバと、を含んで構成され、店頭窓口での取引に関する受付予約を管理する受付処理システムにおける受付処理方法であって、前記予約情報管理サーバが、前記携帯電話から取引の受付予約を受け付ける予約受付開始ステップと、前記予約情報管理サーバが、前記受付予約を行った利用者に関する所定の情報を前記顧客情報管理サーバへ送信して該利用者の顧客情報を要求する顧客情報要求ステップと、前記顧客情報管理サーバが、前記顧客情報要求ステップに応じて、前記顧客情報データベースに記録されている顧客情報の中から、該利用者に対応する顧客情報を検索して前記予約情報管理サーバへ送信する第１の顧客情報送信ステップと、前記予約情報管理サーバが、前記第１の顧客情報送信ステップにより受信した前記顧客情報を前記携帯電話へ送信する第２の顧客情報送信ステップと、を含むことを特徴とする受付処理方法が提供される。

以上説明したように本発明により、顧客が待ち時間を効率よく利用することが可能である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。また、説明は以下の順序で行うものとする。
１．本発明の実施形態の概要
２．実施形態の１つに係る受付処理システム１００の全体構成
３．各種データベースの一例
４．処理フロー
４−１．事前窓口予約の処理フロー
４−２．来店受付の処理フロー
４−３．一時退店時における呼出処理フロー
４−４．一時退店後の再来店時における受付処理フロー
５．まとめ

（１．本発明の実施形態の概要）
本発明の実施形態の１つに係る受付処理システムの詳細を説明するにあたり、まず本実施形態の概要について説明する。なお、以下の説明においては、受付処理を行う事業所の一例として、金融機関を例に説明するが、本発明はこれに限定されるものではない。事業所は、複数の来客者が窓口で取引・相談等する際に、順番待ちの受付処理を行うような事業所であれば、例えば、役所、病院、店舗などであってもよい。

上述したように、従来の金融機関などの営業店において取引を開始するには、顧客は、受付用端末から受付番号が印刷された受付票を受け取り、受付番号が呼び出されるまで営業店内のロビーで待つという受付処理を行う必要がある。受付票を受け取った顧客は、取引に応じた申込書などを準備してロビーで待機し、受付番号が呼ばれた後、窓口において取引を開始することができる。このような従来の受付処理では、取引開始までの待ち時間が長い場合、顧客は、長時間ロビーで待機する必要がある。また、待機中に記入する申込書の顧客情報などに不備があった場合、窓口での取引時間が長くなり、その結果として、他の顧客の取引開始が遅れてしまうおそれもある。さらに、待ち時間中に一時退店した場合、顧客の都合により再来店するタイミングが遅れた場合などには、取引開始がさらに遅れて、他の顧客の待ち時間がさらに長くなってしまうおそれもある。

このような問題点に対して、本発明の実施形態に係る受付処理システムは、顧客の待ち時間を効率よく利用可能とし、あるいは短縮化することを可能とする。

具体的には、顧客はまず、携帯電話で金融機関が備える予約情報管理サーバにアクセスし、希望する取引の情報などを事前入力する。この際、予約情報管理サーバは、金融機関が備える顧客情報ＤＢに記録されている顧客情報や取引履歴を取得することができる。したがって、顧客は、金融機関が管理している顧客情報や取引履歴に基づいて、自分の口座番号や名義、振込先の口座番号などの取引に必要な情報を改めて入力する必要がない。この結果、誤入力や入力忘れなどにより窓口での取引時間が長くなってしまうという問題を解消することができる。

また、顧客が窓口で受付処理をした後に一時退店を希望する場合には、携帯電話を利用することにより、顧客の現在地に応じて、顧客毎に適切な時刻に呼び出しをすることができる。具体的には、一時退店した顧客の携帯電話から位置情報を適宜取得し、現在位置から金融機関の営業店の窓口までの距離を算出し、再来店するまでに要する時間を算出する。このようにして算出した時間と実際に取引を開始可能な時刻とを比較することにより、一時退店している顧客毎に適切な時間に呼び出しを通知することができる。これにより、一時退店している顧客が、実際の取引可能時間よりも大幅に早く営業店に到着してしまったり、実際の取引可能時間よりも大幅に遅れて営業店に到着してしまったりするといった問題を解消することができる。

さらに、一時退店している顧客が取引開始時刻に間に合いそうにない場合や、顧客の都合により再来店の予定を変更したい場合などには、顧客の携帯電話を利用することにより、再来店の予定変更を促すこともできる。具体的には、一時退店した顧客の携帯電話から取得した位置情報に基づいて、再来店可能な時刻が取引開始時刻より所定時間以上遅れそうな場合には、再来店の予定時刻の変更や、再来店する営業所の変更に関する案内をメールで送信する。これにより、顧客は、一時退店後に都合が悪くなった場合や取引場所を他の営業店に変更したい場合などに、適宜再来店の予定を変更することができる。すなわち、取引開始時刻に間に合う顧客を優先的に呼び出し、取引開始時刻に間に合いそうにない顧客に対しては再来店の予約変更を案内することができ、結果として、複数の顧客の待ち時間を効率よく利用可能とし、あるいは短縮することが可能となる。

以下、このような特徴を有する本発明の実施形態の１つに係る受付処理システム１００の詳細について説明する。

（２．受付処理システム１００の全体構成）
まず、本発明の実施形態の１つに係る受付処理システム１００の全体構成について説明する。図１は、本実施形態に係る受付処理システム１００の全体構成を示す説明図である。

図１に示すように、受付処理システム１００は主に、携帯電話１１０と、データセンタ１２０と、複数の営業店１３０と、金融機関センタ１５０と、を含んで構成される。以下、受付処理システム１００の各構成について説明する。

（携帯電話１１０）
携帯電話１１０は、顧客（利用者）が有する携帯電話であり、インターネットなどの公衆通信網１６０を介してデータセンタ１２０と通信接続により各種データを送受信することができる。顧客は、携帯電話１１０からデータセンタ１２０にアクセスすることにより、金融機関の営業店における各種取引の事前予約を行うことができる。なお、図１に示す例では、説明の便宜上１つの携帯電話１１０のみを示しているが、複数の顧客が有する携帯電話１１０が、公衆通信網１６０を介してデータセンタ１２０と通信接続により各種データを送受信することができることは言うまでもない。

（データセンタ１２０）
データセンタ１２０は、金融機関が備えるデータ管理センタであり、顧客からの予約に関する情報を受け付けて管理する。上述したように、データセンタ１２０は、インターネットなどの公衆通信網１６０を介して携帯電話１１０から各種取引の事前予約に関する情報などを受信することができる。データセンタ１２０は、このように携帯電話１１０から受信する事前予約に関する各種情報を管理する予約情報管理サーバ１２２を含んで構成される。予約情報管理サーバ１２２は、複数の顧客が有する携帯電話１１０から受信した事前予約に関する情報を、予約情報ＤＢに記録して管理する。予約情報ＤＢに記録される情報としては、例えば、氏名、支店名、取引種別、来店予定日時、取引詳細、顧客の位置情報、メールアドレスなどが想定されるが、特定の情報に限定されるものではない。なお、予約情報管理サーバ１２２が管理する予約情報ＤＢの一例については後述する。

また、データセンタ１２０に備えられる予約情報管理サーバ１２２は、金融機関内で閉じられた金融機関内通信網１７０を介して、各営業店１３０に備えられる店頭受付システム１３２と通信接続により各種データを送受信することができる。予約情報管理サーバ１２２は、携帯電話１１０から受信した情報を、各営業店１３０や後述する金融機関センタ１５０へ送信したり、各営業店１３０や金融機関センタ１５０が備える各種情報を受信したりすることができる。これにより、予約情報管理サーバ１２２は、例えば、金融機関センタ１５０が備える顧客情報管理サーバ１５２が管理している顧客情報などを取得し、携帯電話１１０へ送信することもできる。なお、予約情報管理サーバ１２２が、携帯電話１１０、営業店１３０、金融機関センタ１５０と各種データを送受信する処理の流れについては、後述する処理フローにおいて説明する。

（営業店１３０）
営業店１３０は、実際に顧客が来店して窓口で取引を行う場所であり、金融機関は通常、複数の営業店Ａ、Ｂ、Ｃ・・・を備えている。本実施形態では、営業店１３０には、店頭受付を処理する店頭受付システム１３２が備えられている。なお、各営業店１３０には、同様の店頭受付システム１３２が備えられている。したがって、本明細書においては、１の営業店Ａのみについて説明するが、金融機関が備えている複数の各営業店１３０において、同様に本実施形態の受付処理を実現することができることは言うまでもない。

営業店１３０が備える店頭受付システム１３２は、顧客が来店した際に、受付処理を実行するシステムである。図１に示すように、店頭受付システム１３２は主に、受付情報管理サーバ１３４と、受付端末１３６と、非接触ＩＣリーダライタ１３８と、受付番号管理装置１４０と、係員用端末１４２と、を含んで構成される。店頭受付システム１３２を構成する各要素は、営業店１３０内のネットワークにより接続され各種情報を転送することができる。また、店頭受付システム１３２を構成する各要素は、必ずしも独立した端末や装置などで構成される必要はなく、例えば、１つの端末に各要素の機能が備えられていてもよい。以下、本実施形態における店頭受付システム１３２の各構成要素の詳細について説明する。

受付情報管理サーバ１３４は、顧客が営業店１３０に来店した際に行う受付処理に関する各種情報を、受付情報ＤＢとして管理する。受付情報ＤＢに記録される情報としては、例えば、受付日時、受付番号、予測呼出時間、取引種別、氏名、一時退店状況などの受付状況に関する情報が想定されるが、特定の情報に限定されるものではない。なお、受付情報管理サーバ１３４が管理する受付情報ＤＢの一例については後述する。

受付端末１３６は、顧客が営業店１３０に来店した際に受付処理を行う端末である。受付端末１３６は、操作案内を表示するディスプレイや、顧客が操作入力するための操作ボタンなどを備えている。顧客は、例えば、ディスプレイの案内表示に従って、希望する取引を選択したり、予約待ち人数や予測待ち時間などの情報を確認したり、一時退店の登録をしたりすることができる。なお、顧客が受付端末１３６を利用して行う受付処理の流れや、受付端末１３６が備えるディスプレイの案内表示の一例については、後述する処理フローにおいて説明する。

非接触ＩＣリーダライタ１３８は、携帯電話１１０が備えるＩＣチップなどに記録された情報を読み取る情報読み取り部である。非接触ＩＣリーダライタ１３８は、例えば、本人認証をする際や、一時退店の登録を行う際などに、顧客が所有する携帯電話１１０が備えるＩＣチップに記録された固有の携帯電話情報（ＩＤなど）を携帯電話１１０から読み取ることができる。このようにして、非接触ＩＣリーダライタ１３８が読み取った携帯電話情報は、後述する金融機関センタ１５０が備える顧客情報管理サーバ１５２へ送信され、本人確認などが行われる。なお、非接触ＩＣリーダライタ１３８を介した各種情報の読み取り処理の流れについては、後述する処理フローにおいて説明する。

受付番号管理装置１４０は、顧客が営業店１３０に来店して窓口で受付処理を行う際に受付番号を発行する。受付番号管理装置１４０は、例えば、顧客に対して、営業店１３０の窓口で受付処理をした順番に受付番号を発行する。これにより、顧客は、受付番号が呼ばれた際に、窓口に行って取引を開始することができる。受付番号管理装置１４０が発行した受付番号は、受付情報管理サーバ１３４が管理する受付情報ＤＢにおいて、顧客の受付処理に関する情報と関連付けられて記録される。なお、受付番号管理装置１４０が行う、受付番号の発行処理の流れについては、後述する処理フローにおいて説明する。

係員用端末１４２は、顧客が取引を行う際に、営業店１３０の係員が各種処理をするための端末である。営業店１３０の係員は、受付情報管理サーバ１３４が管理する受付情報ＤＢに記録されている受付情報や、金融機関センタ１５０で管理されている顧客情報ＤＢに記録されている顧客情報などを、係員用端末１４２で閲覧し、取引に関する処理を実行することができる。

以上のように、営業店１３０が備える店頭受付システム１３２は、金融機関内通信網１７０を介してデータセンタ１２０や、金融機関センタ１５０と通信接続により各種データを送受信することができる。したがって、例えば、店頭受付システム１３２は、顧客の受付処理を行う際に、データセンタ１２０の予約情報管理サーバ１２２が管理する予約情報ＤＢから、当該顧客に関する予約情報を取得することもできる。また、店頭受付システム１３２は、顧客の受付処理を行う際に、後述する金融機関センタ１５０の顧客情報管理サーバ１５２が管理する顧客情報ＤＢから、当該顧客に関する顧客情報を取得することもできる。なお、店頭受付システム１３２が行う、データセンタ１２０の予約情報管理サーバ１２２および金融機関センタ１５０の顧客情報管理サーバ１５２との各種情報の送受信の処理の流れについては、後述する処理フローにおいて説明する。

（金融機関センタ１５０）
金融機関センタ１５０は、金融機関が備えるデータ管理センタであり、顧客に関する顧客情報を管理する顧客情報管理サーバ１５２を含んで構成される。顧客情報管理サーバ１５２は、複数の顧客に関する顧客情報を、顧客情報ＤＢとして管理し、ＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ：顧客管理）システムの一環として機能する。顧客情報は、例えば、顧客が金融機関の口座を開設する際などにあらかじめ顧客情報ＤＢに記録されている。また、顧客が金融機関の窓口において行った取引の履歴なども適宜顧客情報ＤＢに記録することもできる。顧客情報ＤＢに記録される情報としては、例えば、氏名、口座支店名、店番、口座番号、住所、年齢、取引履歴などが想定されるが、特定の情報に限定されるものではない。なお、顧客情報管理サーバ１５２が管理する顧客情報ＤＢの一例については後述する。

また、金融機関センタ１５０は、金融機関内で閉じられた金融機関内通信網１７０を介して、データセンタ１２０や各営業店１３０と通信接続により各種データを送受信することができる。顧客情報管理サーバ１５２は、例えば、データセンタ１２０の予約情報管理サーバ１２２や営業店１３０の店頭受付システム１３２からの要求に応じて、顧客情報を、予約情報管理サーバ１２２や店頭受付システム１３２へ送信することができる。また、顧客情報管理サーバ１５２は、店頭受付システム１３２からの要求に応じて、顧客情報ＤＢに記録されている顧客情報を更新・追加・変更・削除等することもできる。なお、顧客情報管理サーバ１５２が、予約情報管理サーバ１２２や店頭受付システム１３２と各種データを送受信する処理の流れについては、後述する処理フローにおいて説明する。

以上、本実施形態に係る受付処理システム１００の全体構成について説明したが、図１に示した全体構成は、本実施形態に係る受付処理システム１００の一例であり、必ずしも図１に示した構成に限定されるものではない。例えば、データセンタ１２０の予約情報管理サーバ１２２、および金融機関センタ１５０の顧客情報管理サーバ１５２が、同一の管理センタ内に備えられてもよい。また、営業店１３０に備えられる店頭受付システム１３２を構成する各要素は、必ずしも独立した端末や装置で構成される必要はなく、１または複数の端末や装置などに備えられてもよい。

（３．各情報ＤＢの一例）
次に、予約情報管理サーバ１２２が管理する予約情報ＤＢ、受付情報管理サーバ１３４が管理する受付情報ＤＢ、顧客情報管理サーバ１５２が管理する顧客情報ＤＢの構成例について図２〜４を参照にして説明する。

（予約情報ＤＢの一例）
まず、予約情報管理サーバ１２２が管理する予約情報ＤＢについて説明する。図２は、予約情報管理サーバ１２２が管理する予約情報ＤＢの構成の一例を示す説明図である。

図２に示すように、予約情報ＤＢには、予約日時、氏名、営業店名、取引種別、事前入力情報、位置情報、到着予測時刻、近隣支店、メールアドレスなどの情報が記録されている。上述したように、予約情報ＤＢには、顧客が取引の受付を予約する際に入力する情報や、顧客が窓口で受付処理をした後に一時退店した場合の顧客の呼び出しに必要な情報などが記録されている。

例えば、予約日時、氏名、営業店名、取引種別、事前入力情報などは、顧客が事前予約をする際に携帯電話１１０に入力した情報である。事前入力情報は取引毎に必要な情報であり、例えば、振込先、振込み金額、電話番号、などの各種情報が含まれる。また、位置情報、到着予測時刻、近隣支店などは、顧客が一時退店中に、予約情報管理サーバ１２２が、携帯電話１１０の位置情報に基づいて適宜更新する情報である。また、メールアドレスは、顧客が一時退店する際に登録したメールアドレスである。なお、図２に示した予約情報ＤＢの構成は、本実施形態を説明する上での一例であり、これらに限定されるものではない。

（受付情報ＤＢの一例）
次に、受付情報管理サーバ１３４が管理する受付情報ＤＢについて説明する。図３は、受付情報管理サーバ１３４が管理する受付情報ＤＢの構成の一例を示す説明図である。

図３に示すように、受付情報ＤＢには、受付日時、受付番号、取引種別、予測取引開始時刻、氏名、顧客情報、一時退店状況などの情報が記録されている。上述したように、受付情報ＤＢには、顧客が営業店の窓口で取引の受付をした際の情報や、当該顧客の顧客情報などが記録されている。

例えば、予測取引開始時刻は、受付情報管理サーバ１３４が受付情報ＤＢに記録されている受付状況に基づいて算出した時刻であり、受付番号は、受付番号管理装置１４０が発行した受付番号である。また、顧客情報には、顧客情報管理サーバ１５２から取得した情報が記録されている。さらに、一時退店状況は、顧客が一時退店しているか否かを表す情報であり、顧客が一時退店しているか否かによって適宜更新されるものである。なお、図３に示した受付情報ＤＢの構成は、本実施形態を説明する上での一例であり、これらに限定されるものではない。

（顧客情報ＤＢの一例）
次に、顧客情報管理サーバ１５２が管理する顧客情報ＤＢについて説明する。図４は、顧客情報管理サーバ１５２が管理する顧客情報ＤＢの構成の一例を示す説明図である。

図４に示すように、顧客情報ＤＢには、氏名、口座営業店名、店番、口座番号、住所、年齢、取引履歴、メールアドレス、携帯電話固有情報などの情報が記録されている。上述したように、顧客情報ＤＢには、顧客に関する詳細な情報や、当該顧客が過去に行った取引に関する情報などが記録されている。

例えば、氏名、住所、年齢、メールアドレス、携帯電話固有情報などの個人情報は、金融機関の口座を開設する際に登録されるものである。また、詳細は後述する処理フローにおいて説明するが、メールアドレスや携帯電話固有情報などは、顧客が一時退店する際に登録することもできる。取引履歴は、顧客が取引を行うたびに更新されるものであり、詳細は後述する処理フローにおいて説明するが、顧客の事前入力処理などに利用される。なお、図４に示した顧客情報ＤＢの構成は、本実施形態を説明する上での一例であり、これらに限定されるものではない。

以上各情報管理サーバが管理するＤＢの構成例について説明したが、これらの各ＤＢは、後述する処理により適宜更新されるものであり、図２〜４に示した例に限定されるものではない。また、各情報管理サーバは、他の管理サーバが管理するＤＢに適宜アクセスして情報を参照したり、取得したりすることも当然に可能である。

（４．処理フロー）
次に、顧客が予約受付を行う際に、上記のように構成される受付処理システム１００において行われる処理の流れの詳細について説明する。

（４−１．事前窓口予約の処理フロー）
まず、顧客が携帯電話１１０を利用して窓口予約を事前に行う際の処理の流れについて説明する。図５は、本実施形態に係る受付処理システム１００において、顧客が携帯電話１１０を利用して窓口予約を事前に行う際の処理の流れを示すシーケンス図である。

図５に示すように、顧客は、ステップ２００において、携帯電話１１０の操作画面により窓口予約を開始する。顧客は、例えば、携帯電話１１０の操作ボタンやタッチパネルなどを操作して、金融機関が提供するＷＥＢページなどにアクセスすることにより、窓口予約の開始を携帯電話１１０に指示することができる。

次に、ステップ２０２において、携帯電話１１０は、顧客により入力された受付予約に必要な受付予約情報を予約情報管理サーバ１２２へ送信する。受付予約情報としては、例えば、顧客の氏名、来店営業店名、来店予定時間、取引種別などの情報が想定されるが、これらの特定の情報に限定されるものではない。

これを受けて予約情報管理サーバ１２２は、ステップ２０２により携帯電話１１０から送信された受付予約情報を、ステップ２０４において予約情報ＤＢに記録する。

次に、顧客は、ステップ２０６において、携帯電話１１０の画面に表示される案内に従って、本人確認情報を携帯電話１１０に入力する。これを受けて、携帯電話１１０は、ステップ２０８において、顧客により入力された本人確認情報を予約情報管理サーバ１２２へ送信する。本人確認情報としては、例えば、口座番号、氏名、生年月日、パスワードなどの情報が想定されるが、これらの特定の情報に限定されるものではない。例えば、金融機関の口座を開設する際に設定したユーザＩＤとパスワードなどを本人確認情報とすることもできる。この場合、顧客は、ユーザＩＤとパスワードを入力するだけで、後述する処理により詳細の顧客情報を取得することもできる。この結果、顧客は、事前入力を正確かつ簡易に行うことができる。

次に、ステップ２１０において、予約情報管理サーバ１２２は、ステップ２０８により受信した本人確認情報に対応する顧客情報の取得を要求する顧客情報要求信号を顧客情報管理サーバ１５２へ送信する。このとき、予約情報管理サーバ１２２は、ステップ２０８により受信した本人確認情報を顧客情報要求信号に含めて顧客情報管理サーバ１５２へ送信する。

これを受けて顧客情報管理サーバ１５２は、ステップ２１２において、顧客情報ＤＢに記録されている複数の顧客に対応する顧客情報の中から、顧客情報要求信号に含まれる本人確認情報に対応する顧客の顧客情報を検索する。このようにして検索された顧客情報は、ステップ２１４において、顧客情報管理サーバ１５２から予約情報管理サーバ１２２へ送信された後、ステップ２１６において、携帯電話１１０へ送信される。

その後、顧客は、ステップ２１８において、携帯電話１１０の画面に表示される案内に従って、希望する取引の内容に関する情報である事前入力情報を携帯電話１１０に入力する。事前入力情報としては、例えば、氏名、口座営業店名、店番、口座番号、振込先の金融機関番号、振込先の口座番号、振込金額などの情報が想定されるが、これらの特定の情報に限定されるものではない。

なお、ステップ２１８において、顧客は、ステップ２１６により携帯電話１１０が取得した顧客情報を利用することができる。上述したように、顧客情報ＤＢに記録されている顧客情報には、顧客の氏名、口座営業店名、店番、口座番号、取引履歴などの情報が含まれている。したがって、顧客は、ステップ２１８において、あらためて、自分の氏名や口座番号などの情報を入力する必要がない。また、過去に取引した相手の口座に振込みを行う場合などにおいては、取引履歴に取引先の口座番号等の情報が含まれているため、改めて取引先の口座番号などの情報を入力する必要もない。このように、顧客は、金融機関の備える顧客情報管理サーバ１５２が管理する顧客情報を取得することにより、取引の詳細情報を正確かつ簡易に入力することができる。

図６は、取引の詳細情報を入力する際の携帯電話１１０の画面表示例を示す説明図である。図６に示す情報のうち、自分の口座番号などは顧客情報管理サーバ１５２から取得済みであるため、顧客は改めて入力する必要がない。また、例えば、図６に示した振込先履歴の表示を選択することにより、顧客情報管理サーバ１５２から取得した顧客情報に基づいて、過去に取引した相手の口座番号などが自動で入力される。したがって、改めて各種取引情報を入力するといった煩雑な操作が不要となる。また、誤入力により窓口での取引時間が長引いてしまい、結果として他の顧客の待ち時間が長くなってしまうという問題も解消することができる。

その後、ステップ２２０において、携帯電話１１０は、ステップ２１８で顧客により入力された事前入力情報を予約情報管理サーバ１２２へ送信する。これを受けて予約情報管理サーバ１２２は、ステップ２２２において、携帯電話１１０から受信した事前入力情報を予約情報ＤＢに記録する。

以上の処理フローにより、顧客は、金融機関の窓口受付の予約をすることができる。また、金融機関が備える予約情報管理サーバ１２２は、窓口受付予約の内容の詳細に関する事前入力情報を予約情報ＤＢに記録して管理することができる。

（４−２．来店受付の処理フロー）
次に、上記処理により窓口受付の事前予約を行った顧客が金融機関の営業店１３０に来店し、来店受付を行う際の処理の流れについて説明する。図７、８は、本実施形態に係る受付処理システム１００において、事前窓口予約を行った顧客が来店し、来店受付を行う際の処理の流れを示すシーケンス図である。

図７に示すように、ステップ３００において、事前窓口予約を行った顧客は予約を行った金融機関の営業店１３０に来店し、営業店１３０が備える受付端末１３６により受付処理を開始する。顧客は、例えば、受付端末１３６の画面に表示された案内などに従って、受付端末１３６の操作ボタンやタッチパネルなどを操作することにより受付処理を開始することができる。顧客はまず、例えば、受付端末１３６の画面に表示された複数の取引種別の中から、希望する取引種別を選択することができる。

次に、受付端末１３６は、ステップ３０２において、顧客により入力された取引種別情報を受付情報管理サーバ１３４へ送信する。これを受けて受付情報管理サーバ１３４は、ステップ３０４において、受信した取引種別情報を、受付日時とともに受付情報ＤＢに記録する。

次に、ステップ３０６において、顧客は、受付端末１３６の画面に表示される案内に従って、受付端末１３６に顧客識別を行うための媒体を挿入する。顧客識別を行うための媒体としては、例えば、キャッシュカードや通帳などが想定されるが特定の媒体に限定されるものではない。また、例えば、携帯電話１１０に非接触ＩＣなどの記録媒体が備えられている場合には、顧客は、非接触ＩＣリーダライタ１３８に携帯電話１１０をかざしてもよい。

その後、ステップ３０８において、受付端末１３６は、ステップ３０６により取得した顧客識別情報を顧客情報管理サーバ１５２へ送信する。受付端末１３６が送信する顧客識別情報としては、例えば、ステップ３０６により顧客の通帳などから取得した営業店番号、口座番号、口座名義や、携帯電話１１０に備えられる非接触ＩＣに記録された固有の携帯電話ＩＤなどが想定されるが、特定の情報に限定されるものではない。

次に、顧客情報管理サーバ１５２は、ステップ３１０において、顧客情報ＤＢに記録されている複数の顧客に対応する顧客情報の中から、受付端末１３６から取得した顧客識別情報に対応する顧客の顧客情報を検索する。このようにして検索された顧客情報は、ステップ３１２において、顧客情報管理サーバ１５２から受付情報管理サーバ１３４へ送信される。これを受けて受付情報管理サーバ１３４は、ステップ３１４において、取得した顧客情報を受付情報ＤＢに記録する。この際、受付情報管理サーバ１３４は、顧客情報を、上述したステップ３０４により受付情報ＤＢに記録された受付日時や取引種別と関連付けて受付情報ＤＢに記録する。

次に、受付番号管理装置１４０は、ステップ３１６において、受付処理を行っている顧客の受付番号を受付端末１３６へ送信する。これを受けて受付端末１３６は、ステップ３１７において、当該受付番号が記録された用紙を発行する。なお、本実施形態では受付番号が記録された用紙を発行することとしているが、特定の番号取得の方法に限定されるものではない。例えば、受付端末１３６に備え付けられている非接触ＩＣリーダライタ１３８を介して顧客の携帯電話１１０が受付番号を取得する形でもよい。受付番号管理装置１４０は、例えば、受付情報管理サーバ１３４が管理する受付情報ＤＢに記録されている受付番号が取引種別毎に連番になるように受付番号が記録された用紙を発行することができる。その後、受付番号管理装置１４０は、ステップ３１８において、顧客に対して発行した受付番号を受付情報管理サーバ１３４へ送信する。

これを受けて受付情報管理サーバ１３４は、ステップ３２０において、取得した受付番号を受付情報ＤＢに記録する。この際、受付情報管理サーバ１３４は、受付番号を、上述したステップ３１４により受付情報ＤＢに記録された受付日時、取引種別、顧客情報などと関連付けて受付情報ＤＢに記録する。

さらに、受付情報管理サーバ１３４は、ステップ３２２において、当該顧客が取引を開始するまでに要する予測待ち時間を算出する。受付情報管理サーバ１３４は、受付情報ＤＢに登録されている各種取引種別毎の受付状況に基づいて予測待ち時間を算出することが出来る。受付情報管理サーバ１３４は、例えば、ある取引の処理に必要な平均時間と、当該取引の待ち人数とに基づいて、予測待ち時間を算出することができる。このようにして算出された予測待ち時間は、現在時刻に加算された後、予測取引開始時刻として、ステップ３２０により受付情報ＤＢに記録された受付日時、取引種別、顧客情報、受付番号などの受付情報に関連付けて受付情報ＤＢに記録される。

その後、受付情報管理サーバ１３４は、ステップ３２４において、顧客が要望する取引に関する待ち人数、予測待ち時間および予測取引開始時刻を受付端末１３６へ送信する。受付情報管理サーバ１３４は、上述した処理ステップにより受付情報ＤＢに記録された受付情報に基づいて、待ち人数、予測待ち時間および予測取引開始時刻を、受付端末１３６へ送信することができる。これを受けて受付端末１３６は、ステップ３２６において、取得した待ち人数、予測待ち時間および予測取引開始時刻をディスプレイに表示させることができる。

図９は、ステップ３２６により、待ち人数、予測待ち時間および予測取引開始時刻を表示する受付端末１３６のディスプレイの表示例を示す説明図である。図９を参照すると、顧客が要望する取引に関して、８人の別の顧客が当該取引の開始を待っていることがわかる。さらに、当該顧客が取引を開始するまで６０分の待ち時間が必要であり、１１：４０から取引が開始可能であることがわかる。このように、顧客は、受付端末１３６のディスプレイを見ることにより、取引開始までに要する時間などを認識することができる。

また、受付端末１３６は、ステップ３２６において、図９に示すように、予測待ち時間などの情報と共に、一時退店の要望を受け付ける案内をディスプレイに表示する。顧客は、例えば、待ち時間が長い場合には、一度自宅に帰宅したり、買い物をしたり、食事をしたりするなど、営業店１３０から一時的に退店することを望むことが想定される。このような場合、本実施形態に係る受付処理システム１００では、顧客が一時退店した場合においても、営業店１３０に再来店すべき時刻を顧客毎に適切に判断し、顧客毎に再来店の案内を携帯電話１１０に通知することができる。

まず、受付端末１３６は、ステップ３２８において、顧客が一時退店を希望したか否かを判断する。顧客は、ステップ３２６により受付端末１３６のディスプレイに表示された案内に従って、一時退店を選択することができる。図９に示した表示例においては、顧客は、「はい」のボタンを押すことにより、一時退店を選択することが出来る。したがって、受付端末１３６は、ディスプレイのタッチパネル機能または操作ボタンなどに入力された信号などを取得することにより、顧客が一時退店を希望したか否かを判断することができる。

ステップ３２８により顧客が一時退店を希望しないと判断された場合、窓口での受付処理は終了する。この場合、顧客は、営業店１３０のロビーなどにおいて、取引開始の呼び出しがあるまで待機することとなる。もちろん、顧客は、一時退店し、予測待ち時間の前に自主的に再来店してもよい。

一方、ステップ３２８により顧客が一時退店を希望したと判断された場合、受付端末１３６は、ステップ３３０において、携帯電話１１０を非接触ＩＣリーダライタ１３８にかざすように、案内表示をディスプレイに表示させる。図１０はステップ３３０により受付端末１３６のディスプレイに表示される案内表示の一例を示す説明図である。顧客は、図１０に示したような案内表示に従って、ステップ３３２において、携帯電話１１０を非接触ＩＣリーダライタ１３８にかざすことができる。

その後、ステップ３３４において、非接触ＩＣリーダライタ１３８は、ステップ３２２により顧客が非接触ＩＣリーダライタ１３８にかざした携帯電話１１０が備えるＩＣチップに記録されている情報を読み出す。通常ＩＣチップには、ＩＤなどの携帯電話１１０の固有情報が記録されている。非接触ＩＣリーダライタ１３８は、ＩＣチップに記録されている携帯電話固有情報を読み出した後、ステップ３３６において、当該携帯電話固有情報を受付情報管理サーバ１３４および顧客情報管理サーバ１５２へ送信する。

これを受けて、受付情報管理サーバ１３４は、顧客が一時退店の登録をしたと判断し、ステップ３３７において、受付情報ＤＢを更新する。具体的には、受付情報ＤＢに記録されている一時退店状況に関する記録を「一時退店中」へ更新する。

また、顧客情報管理サーバ１５２は、ステップ３３８において、顧客情報ＤＢに記録されている顧客情報の中から、当該携帯電話固有情報に対応する顧客情報を検索し、当該顧客の携帯電話１１０のメールアドレスが登録されているか否かを判断する。詳細は後述する処理ステップにおいて説明するが、例えば、以前に同様の一時退店処理を行った顧客の場合、顧客情報管理サーバ１５２が管理する顧客情報ＤＢには、当該顧客の有する携帯電話の携帯電話固有情報やメールアドレスが記録されている。したがって、２回目以降の取引処理を行う際には、顧客情報管理サーバ１５２が管理する顧客情報ＤＢには、既に当該顧客のメールアドレスが携帯電話固有情報に関連付けられて記録されている。また、例えば、顧客が金融機関の口座を開設する際などに、携帯電話１１０の固有情報とメールアドレスをあらかじめ登録しておくこともできる。このような場合には、１回目の取引処理を行う際においても、顧客情報管理サーバ１５２が管理する顧客情報ＤＢには、既に当該顧客のメールアドレスが携帯電話固有情報に関連付けられて記録されている。

ステップ３３８により、携帯電話１１０のメールアドレスが登録されていないと判断された場合、顧客情報管理サーバ１５２は判断結果を受付端末１３６へ送信し、メールアドレスの登録案内を表示するように指示する。これを受けて受付端末１３６は、ステップ３４４において、携帯電話１１０のメールアドレスを登録するように、案内をディスプレイに表示させる。受付端末１３６は、例えば、ディスプレイに登録用のＵＲＬを表示してもよいし、登録用のＵＲＬに対応する二次元バーコードを表示してもよいし、赤外線通信や非接触ＩＣなどを利用して登録用のＵＲＬを取得するような案内を表示してもよい。

次に、顧客は、ステップ３４６において、携帯電話１１０を介してメールアドレスの登録用ＵＲＬを受付端末１３６から取得する。例えば、顧客は、受付端末１３６のディスプレイに表示されるＵＲＬを直接入力することにより当該ＵＲＬを取得することができる。また、顧客は、受付端末１３６のディスプレイに表示された二次元バーコードを撮影することにより、当該二次元バーコードに対応するＵＲＬを取得することもできる。また、顧客は、受付端末１３６のディスプレイに表示される案内表示に従って、非接触ＩＣリーダライタ１３８に携帯電話１１０をかざすことによりＵＲＬを取得することなどもできる。このように、携帯電話１１０は、種々の方法で受付端末１３６からメールアドレスの登録用のＵＲＬを取得することができるが、ＵＲＬの取得方法は特定の方法に限定されるものではない。

次に、ステップ３４８において、顧客は、携帯電話１１０のブラウザなどを起動することにより、ステップ３４６で取得したＵＲＬにアクセスし、携帯電話１１０のメールアドレスを入力する。その後、携帯電話１１０は、ステップ３５０において、顧客により入力されたメールアドレスを予約情報管理サーバ１２２へ送信する。携帯電話１１０は、例えば、顧客がメールアドレスを入力して送信ボタンなどを選択した場合に、当該メールアドレスを予約情報管理サーバ１２２へ送信することができる。

これを受けて予約情報管理サーバ１２２は、ステップ３５２において、金融機関内通信網１７０を介して、取得したメールアドレスを顧客情報管理サーバ１５２へ送信する。その後、顧客情報管理サーバ１５２は、ステップ３５４において、取得したメールアドレスをステップ３３６により取得した携帯電話固有情報と関連付けて顧客情報ＤＢに記録する。これにより、同じ顧客が次回取引の受付処理を行う際には、既に顧客情報ＤＢに携帯電話固有情報およびメールアドレスが登録されているため、顧客は、再度メールアドレスの登録を行う必要がない。

さらに、ステップ３５６において、予約情報管理サーバ１２２は、ステップ３５０により取得したメールアドレスを予約情報ＤＢに記録する。また、ステップ３３８において、顧客情報ＤＢに既にメールアドレスが登録されていると判断された場合、ステップ３４０において、当該メールアドレスが、金融機関内通信網１７０を介して顧客情報管理サーバ１５２から予約情報管理サーバ１２２へ送信されている。この場合も、予約情報管理サーバ１２２は、ステップ３５６において、当該メールアドレスを予約情報ＤＢに記録することができる。なお、予約情報管理サーバ１２２は、当該メールアドレスを、上述したステップ２２２により予約情報ＤＢに記録されている事前入力情報に関連付けて予約情報ＤＢに記録する。これにより、予約情報管理サーバ１２２は、一時退店している顧客に対して、予約情報ＤＢに記録されているメールアドレス宛に再来店の案内メールなどを送信することができる。

以上の処理フローにより、顧客は、営業店１３０の窓口における受付処理を行うことができる。また、受付情報管理サーバ１３４が管理する受付情報ＤＢに記録されている受付情報に基づいて、取引待ち人数や予測待ち時間に関する情報を顧客に提供することができる。さらに、顧客が一時退店を希望する場合には、再来店の案内通知を送信するために、携帯電話１１０のメールアドレスを登録するように促すことができる。このようにして、登録されたメールアドレスは、事前入力情報などと関連付けられて予約情報ＤＢに記録されるため、一時退店した顧客に対して、当該メールアドレス宛に再来店の案内メールなどを送信することができるようになる。

（４−３．一時退店時における呼出処理フロー）
次に、上記処理により一時退店した顧客に対して呼び出しを行う際の処理の流れについて説明する。図１１、１２は、本実施形態に係る受付処理システム１００において、窓口における受付後に一時退店した顧客に対して呼び出しを行う際の処理の流れを示すシーケンス図である。

図１１に示すように、ステップ４００において、予約情報管理サーバ１２２は、携帯電話１１０から位置情報を取得する。位置情報には、例えば、携帯電話１１０に備えられるＧＰＳ機能などを利用した緯度・経度などの情報が含まれている。予約情報管理サーバ１２２は、携帯電話１１０から、一定時間ごとに位置情報を取得する。予約情報管理サーバ１２２は、あらかじめ顧客の携帯電話１１０から位置情報の取得許可を取得することにより、携帯電話１１０と通信して位置情報を取得することができる。また、顧客が自主的に位置情報を予約情報管理サーバ１２２へ送信することもできる。本実施形態においては、予約情報管理サーバ１２２は、携帯電話１１０の位置情報を取得することができれば、特定の取得方法に限定されるものではない。このようにして取得した位置情報に基づいて、予約情報管理サーバ１２２は、一時退店している顧客の位置を認識することができる。

次に、ステップ４０２において、予約情報管理サーバ１２２は、ステップ４００により取得した位置情報に基づいて、当該顧客が営業店１３０に来店するまでに要する時間に基づいて到着予測時刻を算出する。予約情報管理サーバ１２２は、例えば、顧客の位置と営業店１３０の所在地とに基づいて、現在顧客がいる場所から営業店１３０までの距離を算出し、当該距離に基づいて来店までに要する時間を算出することができる。このようにして算出した時間と、現在時刻に加えることにより、当該顧客が現在地から営業店１３０に来店した場合の到着予測時刻を算出することができる。

その後、予約情報管理サーバ１２２は、ステップ４０４において、受付情報管理サーバ１３４から当該顧客の受付情報に記録されている予測取引開始時刻の取得を要求する。受付情報管理サーバ１３４は、上述したように、ステップ３２２により算出した予測待ち時間に基づいて、顧客の要望する取引を開始可能な予測取引開始時刻を受付情報ＤＢに記録して管理している。したがって、受付情報管理サーバ１３４は、ステップ４０６において、予約情報管理サーバ１２２からの要求に応じて、受付情報ＤＢに記録されている予測取引開始時刻を抽出し、予約情報管理サーバ１２２へ送信する。

次に、ステップ４０８において、予約情報管理サーバ１２２は、ステップ４０２により算出した到着予測時刻と、ステップ４０６により取得した予測取引開始時刻を比較し、到着予測時刻が予測取引開始時刻まで所定時間内であるか否かを判断する。予約情報管理サーバ１２２は、当該所定時間を呼出設定時間としてあらかじめ設定しておくことができる。

例として、ステップ４０６により取得した予測取引開始時刻が「１１：４０」で、呼出設定時間が「５分」と設定されている場合を例に説明する。この場合、予約情報管理サーバ１２２は、ステップ４０２より算出した到着予測時刻が、予測取引開始時刻「１１：４０」まで呼出設定時間「５分」以内であるか否か、すなわち「１１：３５」を経過しているか否かを判断する。例えば、ステップ４０２で算出した到着予測時刻が「１１：２０」であった場合、「１１：３５」を経過していないため、再びステップ４００に戻り、携帯電話１１０の位置情報を取得する。一方、例えば、ステップ４０２で算出した到着予測時刻が「１１：３６」であった場合、「１１：３５」を経過しているため、予約情報管理サーバ１２２は、ステップ４１０において、携帯電話１１０に呼び出し案内のメールを送信する。

このように、予約情報管理サーバ１２２は、携帯電話１１０の位置情報に基づいて顧客の位置を認識し、当該位置に基づいて呼び出し案内のメールを携帯電話１１０に送信することができる。これにより、予約情報管理サーバ１２２は、営業店１３０から比較的近い位置にいる顧客に対しては、予測取引開始時刻の直前に呼び出し案内を通知し、営業店１３０から比較的遠い位置にいる顧客に対しては、予測取引開始時刻よりも早い段階で呼び出し案内を通知することができる。この結果、実際の取引可能時間よりも大幅に早く営業店１３０に到着してしまったり、実際の取引可能時間よりも大幅に遅れて営業店１３０に到着してしまったりするといった問題を解消でき、効率よく待ち時間を利用可能とし、あるいは短縮することが可能である。

なお、予約情報管理サーバ１２２があらかじめ設定する呼出設定時間は、金融機関の管理者などが任意に設定することができるものであり、特定の時間に限定されるものではない。例えば、余裕を持って呼び出し案内を通知するためには、呼出設定時間を長めに設定することもできる。

呼び出し案内のメールを受信した携帯電話１１０は、ステップ４１２において、携帯電話１１０の画面に呼び出し案内を表示する。携帯電話１１０は、また、再来店の予定変更を希望するか否かの案内表示もあわせて画面に表示する。図１３は、呼び出し案内および再来店の予定変更の案内を表示する携帯電話１１０の画面表示例を示す説明図である。顧客は、図１３に示すような通知を受けることで、営業店１３０に再度来店する時間であることを認識することができる。また、都合により現在は再来店することができない場合は、再来店の予定変更を選択することにより、後述する処理フローにより再来店の予定を変更することもできる。

顧客が再来店の予定変更を希望しない場合、予約情報管理サーバ１２２は、その後継続的に、ステップ４１６において、携帯電話１１０から位置情報を取得する。また、予約情報管理サーバ１２２は、ステップ４１８において、ステップ４１６により取得した位置情報に基づいて、ステップ４０２による処理と同様に、当該顧客が営業店１３０に来店するまでに要する時間に基づいて到着予測時刻を算出する。これにより、予約情報管理サーバ１２２は、呼び出し案内をメールした後に、顧客が営業店１３０に近づいているか否かを認識することができる。

その後、ステップ４２０において、予約情報管理サーバ１２２は、ステップ４１８により算出した到着予測時刻と、ステップ４０６により取得した予測取引開始時刻を比較し、到着予測時刻が予測取引開始時刻より所定時間遅くなっているか否かを判断する。予約情報管理サーバ１２２は、当該所定時間を再来店予定変更設定時間としてあらかじめ設定しておくことができる。

例として、ステップ４０６により取得した予測取引開始時刻が「１１：４０」で、再来店予定変更設定時間が「１０分」と設定されている場合を例に説明する。この場合、予約情報管理サーバ１２２は、ステップ４１８より算出した到着予測時刻が、予測取引開始時刻「１１：４０」より再来店予定変更設定時間「１０分」以上遅くなっているか否か、すなわち「１１：５０」を経過しているか否かを判断する。例えば、ステップ４１８で算出した到着予測時刻が「１１：３７」であった場合、「１１：５０」を経過していないため、再びステップ４１６に戻り、携帯電話１１０の位置情報を取得する。一方、例えば、ステップ４１８で算出した到着予測時刻が「１１：５２」であった場合、「１１：５０」を経過しているため、予約情報管理サーバ１２２は、ステップ４２２において、携帯電話１１０に再来店の予定変更通知に関する情報をメールで送信する。

このように、予約情報管理サーバ１２２は、呼び出し案内を通知した後も、継続的に携帯電話１１０の位置情報に基づいて顧客の位置を認識し、当該位置に基づいて、顧客が営業店１３０に近づいているか否かを認識することができる。この結果、呼び出し案内を通知したにもかかわらず、顧客が営業店１３０に近づいていない場合などには、再来店の予定変更案内を携帯電話１１０にメールすることができる。すなわち、現在顧客がいる位置からは、取引開始時間から所定時間内に来店することはできないと判断した場合には、再来店の予定変更を通知することで、他の取引待ちの顧客の待ち時間が遅れてしまうことを防止することができる。

再来店の予定変更案内メールを受信した携帯電話１１０は、ステップ４２６において、当該メールの情報を画面に表示する。なお、上述したステップ４１４において、再来店の予定変更を顧客が希望した場合にも、携帯電話１１０は、同様にステップ４２６において、同様の予定変更情報を画面に表示する。図１４は、再来店の予定変更案内を表示する携帯電話１１０の表示例を示す説明図である。図１４に示すように、顧客は、携帯電話１１０に表示された案内に従って再来店の予定変更を行うことができる。図１４に示す例においては、顧客は、本日中に再来店を希望するか、後日に再来店を希望するかを選択することができる。

その後、携帯電話１１０は、ステップ４２８において、予約情報管理サーバ１２２に対して、今後の取引可能時刻に関する情報の取得を要求する。このとき、例えば、図１４に示した例において、顧客が本日中の再来店を選択した場合には、携帯電話１１０は、本日中に取引可能な時刻に関する情報の取得を要求することができる。一方、顧客が特定の日時における再来店を選択した場合には、携帯電話１１０は、選択された日時の近辺の取引可能な時刻に関する情報の取得を要求することができる。もちろん、図１４に示した表示は、本実施形態を説明する上での一例であり、本発明はこれに限定されるものではない。したがって、顧客が日時を選択しない場合においても、携帯電話１１０は、今後取引可能な時刻に関する情報を、予約情報管理サーバ１２２に対して要求することも当然に可能である。

携帯電話１１０からの取得要求に応じて、予約情報管理サーバ１２２は、ステップ４３０において、受付情報管理サーバ１３４に対して、今後の取引可能な時刻に関する情報の取得を要求する。上述したように、受付情報管理サーバ１３４は、受付情報ＤＢに取引の受付情報を記録して管理している。したがって、受付情報管理サーバ１３４は、受付情報ＤＢに記録された情報に基づいて、当該顧客が希望する取引を今後開始することが可能な時刻を算出することができる。このようにして算出された取引可能時刻のリストは、ステップ４３２において、受付情報管理サーバ１３４から予約情報管理サーバ１２２へ送信された後に、ステップ４３４において、携帯電話１１０へ送信される。

さらに、予約情報管理サーバ１２２は、携帯電話１１０からの取得要求に応じて、ステップ４３６において、他の営業店１３０が備える受付情報管理サーバ１３４に対して、他の営業店１３０において今後の取引可能な時刻に関する情報の取得を要求する。この際、予約情報管理サーバ１２２は、現在の携帯電話１１０の位置情報に基づいて、顧客の位置から近い位置に存在する営業店１３０が備える受付情報管理サーバ１３４に対して、情報の取得を要求することができる。これを受けて、他の営業店１３０の受付情報管理サーバ１３４は、ステップ４３８において、他の営業店１３０において今後取引可能な時刻のリストを予約情報管理サーバ１２２へ送信する。その後、予約情報管理サーバ１２２は、ステップ４４０において、他の営業店から取得した取引可能時刻のリストを携帯電話１１０へ送信する。

その後、携帯電話１１０は、ステップ４３４およびステップ４４０により取得した今後の取引可能時刻のリストを画面表示する。図１５は、今後の取引可能時刻のリストを表示する携帯電話１１０の表示画面の一例を示す説明図である。図１５に示すように、携帯電話１１０の画面には、ステップ４３４により取得した本来取引をするはずだった営業店１３０（新宿支店）の取引可能時刻のみでなく、ステップ４４０により取得した他の営業店１３０（渋谷支店）の取引可能時刻も表示されている。これにより、顧客は、一時退店した後に移動して他の営業店１３０により近くなった場合などには、他の営業店１３０での取引を選択することもできる。

その後、ステップ４４４において、顧客が取引を希望する営業店１３０および取引時刻を選択すると、携帯電話１１０は、ステップ４４６において、顧客により選択された情報を予約情報管理サーバ１２２へ送信する。これを受けて予約情報管理サーバ１２２は、携帯電話１１０から受信した情報を受付情報管理サーバ１３４へ送信する。なお、図１２においては、本来顧客が取引を行う予定であった営業店１３０の受付情報管理サーバ１３４へ選択情報が送信されているが、ステップ４４４により他の営業店１３０が選択された場合には、選択された他の営業店１３０の受付情報管理サーバ１３４へ選択情報が送信される。

これを受けて受付情報管理サーバ１３４は、ステップ４５０において、受信した選択情報の内容に基づいて、受付情報ＤＢの情報を更新する。このようにして再来店の予定変更が行われた場合、再度ステップ４００に戻り、携帯電話１１０の位置情報に基づいて、新しく変更された取引可能時刻が近づくと呼び出し案内が携帯電話１１０にメールされることとなる。

以上の処理フローにより、顧客は、営業店１３０を一時退店した場合においても、再来店すべき時刻になると、予約情報管理サーバ１２２から再来店の呼び出しメールを携帯電話１１０で受信することができる。この際、予約情報管理サーバ１２２は、携帯電話１１０の位置情報に基づいて呼び出しメールを送信するタイミングを顧客毎に変化させることができる。したがって、顧客は、実際の取引可能時間よりも大幅に早く営業店１３０に到着してしまったり、実際の取引可能時間よりも大幅に遅れて営業店１３０に到着してしまったりすることがない。また、都合により現在再来店ができない場合などには、他の営業店１３０を含めて、今後の取引可能な時刻を予約情報管理サーバ１２２から取得することができる。これにより、顧客は、一時退店後に都合が悪くなった場合などにも、柔軟に取引時間を調整することができる。この結果、顧客が取引開始時間に遅れることにより、他の顧客の待ち時間が遅れてしまうといった問題を解消でき、効率よく待ち時間を短縮することが可能である。

（４−４．再来店時における受付処理フロー）
次に、上記処理により一時退店した顧客が再来店して取引を開始する際の処理の流れについて説明する。図１６は、本実施形態に係る受付処理システム１００において、窓口における受付後に一時退店した顧客が再来店して取引を開始する際の処理の流れを示すシーケンス図である。

図１６に示すように、ステップ５００において、再来店した顧客は、受付端末１３６により再来店の受付処理を開始する。顧客は、例えば、受付端末１３６の画面に表示された案内などに従って、受付端末１３６の操作ボタンやタッチパネルなどを操作することにより再来店の受付処理を開始することができる。顧客は、例えば、受付端末１３６の画面に表示された複数の選択画面の中から、再来店の受付を選択することができる。

受付端末１３６は、再来店の受付処理の開始を顧客により要求されると、ステップ５０２において、携帯電話１１０を非接触ＩＣリーダライタ１３８にかざすように、画面に案内を表示する。これにより、顧客は、ステップ５０４において、携帯電話１１０を非接触ＩＣリーダライタ１３８にかざすことができる。

これを受けて非接触ＩＣリーダライタ１３８は、ステップ５０６において、顧客がかざした携帯電話１１０のＩＣチップに記録されている携帯電話固有情報を読み出す。その後、非接触ＩＣリーダライタ１３８は、読み出した携帯電話固有情報を、ステップ５０８において、顧客情報管理サーバ１５２へ送信する。

次に、ステップ５１０において、顧客情報管理サーバ１５２は、ステップ５０８により受信した携帯電話固有情報に対応する顧客情報を、顧客情報ＤＢから検索する。その後、顧客情報管理サーバ１５２は、ステップ５１２において、検索した顧客情報を受付情報管理サーバ１３４へ送信する。

これを受けて受付情報管理サーバ１３４は、受付情報ＤＢに記録されている受付情報と、顧客情報管理サーバ１５２から送信された顧客情報とが一致することを確認し、一時退店していた顧客が再来店したことを確認することができる。その後、受付情報管理サーバ１３４は、ステップ５１４において、受付情報ＤＢを更新する。具体的には、受付情報ＤＢに記録されている一時退店状況に関する記録を、「一時退店中」から「再来店受付済」へ更新する。

その後、受付情報管理サーバ１３４は、ステップ５１６において、予約情報管理サーバ１２２に対して、再来店した顧客の事前入力情報の取得を要求する。この際、受付情報管理サーバ１３４は、例えば、顧客の氏名や口座番号などの所定の情報を予約情報管理サーバ１２２へ送信することができる。

これを受けて予約情報管理サーバ１２２は、受付情報管理サーバ１３４から送信された顧客の氏名などの情報に対応する事前入力情報を予約情報ＤＢから検索し、ステップ５１８において、検索した事前入力情報を受付情報管理サーバ１３４へ送信する。

その後、受付情報管理サーバ１３４は、ステップ５２０において、当該顧客の取引に関する各種情報を係員用端末１４２へ送信する。受付情報管理サーバ１３４が係員用端末１４２へ送信する取引情報としては、受付情報ＤＢに記録されている受付情報の他、ステップ５１２により取得した顧客情報や、ステップ５１８により取得した事前入力情報などが含まれる。

窓口の担当係員は、ステップ５２０により係員用端末１４２へ送信された取引情報を閲覧し、必要な書類などを準備した後、ステップ５２２において、当該顧客の受付番号の呼び出しを受付番号管理装置１４０へ指示する。これを受けて受付番号管理装置１４０は、呼び出し指示を受けた受付番号をモニタに表示したり、音声で出力したりすることにより顧客の呼び出しを実行する。これにより、顧客は、窓口に行き取引を開始することができる。

（５．まとめ）
以上本発明の実施形態の１つに係る受付処理システム１００の詳細について説明した。上述したように、本実施形態に係る受付処理システム１００においては、顧客は、携帯電話１１０により取引の事前受付を行うことができる。このとき、金融機関が管理する顧客情報ＤＢに記録されている顧客情報（口座番号や取引履歴など）を利用することで、希望する取引の詳細を入力するという煩雑な操作を、正確かつ簡易に行うことができる。この結果、誤入力や入力漏れなどにより取引時間が延びてしまい、他の顧客の待ち時間が長くなってしまうという問題を解消することが可能である。

また、本実施形態に係る受付処理システム１００では、窓口にて受付処理を行った後、一時退店を希望する場合には、携帯電話１１０を利用することにより、顧客の現在地に応じて、顧客毎に適切な時刻に呼び出しをすることができる。これにより、顧客は、実際の取引可能時間よりも大幅に早く営業店１３０に到着してしまったり、実際の取引可能時間よりも大幅に遅れて営業店１３０に到着してしまったりするといった問題を解消することが可能である。

さらに、本実施形態に係る受付処理システム１００では、一時退店している顧客が取引開始時刻に間に合いそうにない場合や、顧客の都合により再来店の予定を変更したい場合などには、再来店の予定変更を促すこともできる。これにより、顧客は、一時退店後に都合が悪くなった場合や取引場所を他の営業店１３０に変更したい場合などには、適宜再来店の予定を変更することができる。この結果、取引開始時刻に間に合う顧客を優先的に呼び出し、間に合いそうにない顧客に対しては再来店の予約変更を案内し、複数の顧客の待ち時間を効率よく短縮することも可能である。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、事業所の一例として金融機関を例に説明したが、本発明はかかる例に限定されない。例えば、役所、病院、店舗などのように、複数の顧客と取引、相談などをすることを目的とし、複数の顧客が取引や相談などに先立って受付を必要とする事業所であれば、本発明の受付処理システムを適用することができる。

また、本明細書において、シーケンス図に記述されたステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的に又は個別的に実行される処理をも含む。また時系列的に処理されるステップでも、場合によっては適宜順序を変更することが可能であることは言うまでもない。

本発明の実施形態の１つに係る受付処理システム１００の全体構成を示す説明図である。 同実施形態において、予約情報管理サーバ１２２が管理する予約情報ＤＢの構成の一例を示す説明図である。 同実施形態において、受付情報管理サーバ１３４が管理する受付情報ＤＢの構成の一例を示す説明図である。 同実施形態において、顧客情報管理サーバ１５２が管理する顧客情報ＤＢの構成の一例を示す説明図である。 同実施形態に係る受付処理システム１００において、顧客が携帯電話１１０を利用して窓口予約を事前に行う際の処理の流れを示すシーケンス図である。 同実施形態において、事前入力情報を入力する際の携帯電話１１０の画面表示例を示す説明図である。 同実施形態に係る受付処理システム１００において、事前窓口予約を行った顧客が来店し、窓口において受付を行う際の処理の流れを示すシーケンス図である。 同実施形態に係る受付処理システム１００において、事前窓口予約を行った顧客が来店し、窓口において受付を行う際の処理の流れを示すシーケンス図である。 同実施形態において、待ち人数、予測待ち時間および一時退店の案内を表示する、受付端末１３６のディスプレイの表示例を示す説明図である。 同実施形態において、携帯電話１１０を非接触ＩＣリーダライタ１３８にかざすように案内表示する、受付端末１３６のディスプレイの表示例を示す説明図である。 同実施形態に係る受付処理システム１００において、窓口における受付後に一時退店した顧客に対して呼び出しを行う際の処理の流れを示すシーケンス図である。 同実施形態に係る受付処理システム１００において、窓口における受付後に一時退店した顧客に対して呼び出しを行う際の処理の流れを示すシーケンス図である。 同実施形態において、呼び出し案内および再来店の予定変更の案内を表示する携帯電話１１０の画面表示例を示す説明図である。 同実施形態において、再来店の予定変更案内を表示する携帯電話１１０の表示例を示す説明図である。 同実施形態において、今後の取引可能時刻のリストを表示する携帯電話１１０の表示画面の一例を示す説明図である。 同実施形態に係る受付処理システム１００において、窓口における受付後に一時退店した顧客が再来店して取引を開始する際の処理の流れを示すシーケンス図である。

符号の説明

１００ 受付処理システム
１１０ 携帯電話
１２０ データセンタ
１２２ 予約情報管理サーバ
１３０ 営業店
１３２ 店頭受付システム
１３４ 受付情報管理サーバ
１３６ 受付端末
１３８ 非接触ＩＣリーダライタ
１４０ 受付番号管理装置
１４２ 係員用端末
１５０ 金融機関センタ
１５２ 顧客情報管理サーバ
１６０ 公衆通信網
１７０ 金融機関内通信網

Claims (15)

1. 利用者が有する携帯電話と通信網を介して接続され、前記携帯電話から受け付けた取引の受付の予約に関する情報が記録された予約情報データベースを管理する予約情報管理サーバと、
   利用者に関する個人情報や過去の取引履歴が記録された顧客情報データベースを管理する顧客情報管理サーバと、を含んで構成され、店頭窓口での取引に関する受付予約を管理する受付処理システムにおいて、
   前記予約情報管理サーバは、前記携帯電話から取引の受付予約を受け付けた場合、前記顧客情報管理サーバが管理する前記顧客情報データベースに記録されている顧客情報の中から、前記携帯電話の利用者に対応する顧客情報を前記顧客情報管理サーバから取得し、前記携帯電話へ送信することを特徴とする受付処理システム。
2. 前記予約情報管理サーバは、利用者が前記予約情報管理サーバから受信した前記顧客情報に基づいて前記携帯電話に入力した希望する取引に関する情報を、事前入力情報として前記予約情報データベースに記録することを特徴とする、請求項１に記載の受付処理システム。
3. 営業店毎に設置され、該営業店の店頭窓口で利用者の受付処理を行う受付端末と、
   営業店毎に設置され、該営業店の店頭窓口での利用者の受付状況に関する情報が記録された受付情報データベースを管理する受付情報管理サーバと、
   をさらに備え、
   前記受付情報管理サーバは、前記顧客情報管理サーバが管理する前記顧客情報データベースに記録されている顧客情報の中から、前記店頭窓口で受付処理を行っている利用者に対応する顧客情報を前記顧客情報管理サーバから取得し、前記受付情報データベースに記録することを特徴とする、請求項２に記載の受付処理システム。
4. 前記受付情報管理サーバは、前記受付情報データベースに記録されている受付状況に関する情報に基づいて、前記店頭窓口で受付処理を行っている利用者が希望する取引の待ち人数を算出し、該待ち人数に基づいて、該利用者が取引を開始することが可能な時刻を算出し、算出した待ち人数および時刻を前記受付情報データベースに記録することを特徴とする、請求項３に記載の受付処理システム。
5. 前記受付情報管理サーバは、前記受付情報データベースに記録された前記待ち人数および時刻を前記受付端末へ送信し、
   前記受付端末は、前記受付情報管理サーバから送信された前記待ち人数および時刻を表示させることを特徴とする、請求項４に記載の受付処理システム。
6. 前記予約情報管理サーバは、利用者が前記店頭窓口で受付処理を行った後に一時退店した場合に、該利用者が有する携帯電話の位置情報に基づいて、前記携帯電話に再来店の呼び出しメールを送信することを特徴とする、請求項５に記載の受付処理システム。
7. 前記予約情報管理サーバは、一時退店している利用者が有する携帯電話の位置情報に基づいて、該利用者が前記店頭に再来店することが可能な時刻を算出し、前記受付情報管理サーバが算出した該利用者が取引を開始することが可能な時刻まで所定時間内となった場合に、再来店の呼び出しメールを前記携帯電話へ送信することを特徴とする、請求項６に記載の受付処理システム。
8. 前記予約情報管理サーバは、一時退店している利用者が有する携帯電話の位置情報に基づいて算出した該利用者が前記店頭に再来店することが可能な時刻が、前記受付情報管理サーバが算出した該利用者が取引を開始することが可能な時刻から所定時間経過している場合には、再来店の予定変更に関する情報を前記携帯電話へ送信することを特徴とする、請求項７に記載の受付処理システム。
9. 前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が今後取引を開始することが可能な時刻に関する情報を前記受付情報管理サーバから取得し、前記携帯電話へ送信することを特徴とする、請求項８に記載の受付処理システム。
10. 前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が他の営業店の店頭において今後取引を開始することが可能な時刻に関する情報を、前記他の営業店の店頭に備えられる受付情報管理サーバから取得し、前記携帯電話へ送信することを特徴とする、請求項９に記載の受付処理システム。
11. 前記予約情報管理サーバは、一時退店している利用者が再来店の予定変更を希望する通知を前記携帯電話から受信した場合、該利用者が有する前記携帯電話から取得した位置情報に基づいて該利用者の現在位置から近い営業店を検索し、該利用者が検索された営業店の店頭において今後取引を開始することが可能な時刻に関する情報を、前記検索された営業店の店頭に備えられる受付情報管理サーバから取得し、前記携帯電話へ送信することを特徴とする、請求項１０に記載の受付処理システム。
12. 利用者が前記店頭窓口で受付処理を行った後に一時退店を希望する場合、
    前記顧客情報管理サーバは、前記携帯電話のＩＣチップに記録される携帯電話固有情報と前記携帯電話のメールアドレスとを関連付けて前記顧客情報データベースに記録することを特徴とする、請求項６〜１１に記載の受付処理システム。
13. 前記顧客情報管理サーバは、前記店頭窓口で受付処理をしている利用者が有する携帯電話のＩＣチップに記録されている携帯電話固有情報を、非接触ＩＣリーダライタを介して取得し、該利用者が有する前記携帯電話のメールアドレスを、前記予約情報管理サーバを介して取得し、取得した前記携帯電話固有情報と前記メールアドレスとを関連付けて前記顧客情報データベースに記録することを特徴とする、請求項１２に記載の受付処理システム。
14. 前記顧客情報管理サーバは、前記携帯電話から取得した前記携帯電話固有情報に関連付けられたメールアドレスが前記顧客情報データベースに既に記録されている場合には、該メールアドレスを前記予約情報管理サーバへ送信し、
    前記予約情報管理サーバは、前記顧客情報管理サーバから送信された前記メールアドレスを、該利用者の前記事前入力情報と関連付けて前記予約情報データベースに記録することを特徴とする、請求項１３に記載の受付処理システム。
15. 利用者が有する携帯電話と通信網を介して接続され、前記携帯電話から受け付けた取引の受付の予約に関する情報が記録された予約情報データベースを管理する予約情報管理サーバと、
    利用者に関する個人情報や過去の取引履歴が記録された顧客情報データベースを管理する顧客情報管理サーバと、を含んで構成され、店頭窓口での取引に関する受付予約を管理する受付処理システムにおける受付処理方法であって、
    前記予約情報管理サーバが、前記携帯電話から取引の受付予約を受け付ける予約受付開始ステップと、
    前記予約情報管理サーバが、前記受付予約を行った利用者に関する所定の情報を前記顧客情報管理サーバへ送信して該利用者の顧客情報を要求する顧客情報要求ステップと、
    前記顧客情報管理サーバが、前記顧客情報要求ステップに応じて、前記顧客情報データベースに記録されている顧客情報の中から、該利用者に対応する顧客情報を検索して前記予約情報管理サーバへ送信する第１の顧客情報送信ステップと、
    前記予約情報管理サーバが、前記第１の顧客情報送信ステップにより受信した前記顧客情報を前記携帯電話へ送信する第２の顧客情報送信ステップと、
    を含むことを特徴とする受付処理方法。

Images