JP2020126479A - 受付処理装置、制御方法、プログラム、及びシステム - Google Patents

Abstract

【課題】顧客による代金の不払いを防止する。【解決手段】受付処理装置２０００は、サービス又は商品の提供を要求する顧客１０の属性に基づいて、顧客１０の電子決済を可能とする電子決済情報３０が、その顧客１０についての要求受付処理に必要であるか否かを判定する。受付処理装置２０００は、要求受付処理を実行する。電子決済情報３０が必要であると判定された場合、受付処理装置２０００は、電子決済情報３０を取得した後に、要求受付処理を終了する。【選択図】図１

Description

本発明は、顧客に対するサービスや商品の提供を管理する技術に関する。

顧客に対するサービスや商品（以下、サービス等）の提供を管理するシステムが開発されている。例えば特許文献１には、患者から任意にクレジットカード番号の登録を受け付け、クレジットカード番号を登録した患者については、登録したクレジットカード番号を用いた自動決済を希望でき、窓口での会計を省略することができるシステムが開示されている。

特開２００６−００４４０４号公報

サービス等の提供が代金の支払いよりも先に行われるケースがある。例えば病院では、診察や治療を行った後に、代金の支払いが行われる。このようなケースでは、顧客が代金を支払わずに帰ってしまうという危険性が存在する。

この点、特許文献１のシステムでは、クレジットカード番号を登録するか否かは、顧客が選択できる事項である。そして、代金の支払いを行う意思がない顧客は、クレジットカード番号の登録を行わないと考えられる。そのため、特許文献１のシステムでは、顧客による代金の不払いを防止することは難しい。

本発明は上述した課題に鑑みてなされたものである。本発明の目的の一つは、顧客による代金の不払いを防止する技術を提供することである。

本発明の受付処理装置は、１）サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理部と、２）顧客の属性に基づいて、顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定部と、有する。
顧客の電子決済情報が必要であると判定された場合、その顧客についての電子決済情報を取得した後、受付処理を完了する。

本発明の制御方法は、コンピュータによって実行される。当該制御方法は、１）サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理ステップと、２）顧客の属性に基づいて、顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定ステップと、を有する。
顧客の電子決済情報が必要であると判定された場合、その顧客についての電子決済情報を取得した後、受付処理を完了する。

本発明のシステムは、第１の受付処理装置と第２の受付処理装置を有する。第１の受付処理装置及び第２の受付処理装置はいずれも、サービス又は商品の提供を要求する顧客の受付処理を実行する。
第１の受付処理装置は、設定言語が所定の言語であり、受付処理に、顧客について電子決済を可能とする電子決済情報を取得する処理が含まれる。
第２の受付処理装置は、設定言語が所定の言語以外の言語であり、要求受付処理に、顧客について電子決済情報を取得する処理が含まれない。

本発明のプログラムは、本発明の制御方法が有する各ステップをコンピュータに実行させる。

本発明によれば、顧客による代金の不払いを防止する技術が提供される。

本実施形態の受付処理装置の概要を説明するための図である。 病院において診察の受け付けを行う受付機における画面の遷移を例示する図である。 実施形態１の受付処理装置の機能構成を例示する図である。 受付処理装置を実現するための計算機を例示する図である。 実施形態１の受付処理装置によって実行される処理の流れを例示するフローチャートである。 受付処理装置を利用する流れをより具体的に例示する図である。 受付処理装置の実現形態を例示する図である。 利用者端末のハードウエア構成を例示する図である。 計算機の正面の外観を例示する図である。 変形例の受付処理装置の利用環境を例示する図である。

以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。また各ブロック図において、特に説明がない限り、各ブロックは、ハードウエア単位の構成ではなく機能単位の構成を表している。

［実施形態１］
＜概要＞
図１は、本実施形態の受付処理装置の概要を説明するための図である。なお、図１は、受付処理装置２０００に対する理解を容易にするための例示であり、受付処理装置２０００の機能は図１に表されているものに限定されない。

受付処理装置２０００は、任意の施設で運用され、施設を利用する人（顧客１０）からの要求を受け付ける処理（顧客１０の受付処理）を実行する。以下、顧客１０からの要求を受け付ける処理を、単に要求受付処理とも表記する。受付処理装置２０００が運用される施設は、例えば、病院やホテルなどである。顧客１０からの要求は、顧客１０に対するサービス又は商品（以下、サービス等）の提供の要求である。また、顧客１０からの要求に係るサービス等（すなわち、顧客１０によって要求されているサービス等）の提供には、代金の支払いが必要であるとする。ただし後述するように、顧客１０の属性によっては、代金の支払いが不要であることもある。

受付処理装置２０００において、要求受付処理の内容は、その要求に係る顧客１０（その要求を行っている顧客１０）の属性に依存する。具体的には、受付処理装置２０００は、顧客１０の属性に基づいて、顧客１０について電子決済を可能とする情報（以下、電子決済情報３０）が要求受付処理に必要であるか否かを判定する。そして、電子決済情報３０が必要であると判定された場合、受付処理装置２０００は、電子決済情報３０を取得した後に、要求受付処理を完了する。取得した電子決済情報３０は、所定の記憶装置に格納される。以下、この記憶装置を、決済情報記憶装置５０と呼ぶ。

図２は、病院において診察の受け付けを行う受付機における画面の遷移を例示する図である。この例では、診察がサービスに該当する。また、顧客１０は患者である。まず受付処理装置２０００は、診察券を挿入することを促す画面６０をディスプレイ装置に表示させる。患者が診察券を受付処理装置２０００に挿入すると、受付処理装置２０００は、診察券から得られる患者の識別情報などを利用して患者の属性を特定し、その属性に基づいて、電子決済情報３０が必要であるか否かを判定する。

電子決済情報３０が必要である場合、受付処理装置２０００は、電子決済情報３０を取得してから、要求受付処理を完了する。例えば受付処理装置２０００は、要求受付処理を完了する前に、電子決済情報３０を得るための入力を促す画面７０をディスプレイ装置に表示させる。図２の例では、クレジットカード情報の入力が求められている。患者は、クレジットカード番号等の情報を入力した後、ＯＫボタンを押す。これにより、受付処理装置２０００は、電子決済情報３０として、クレジットカードによる決済を可能とする情報を取得する。その後、受付処理装置２０００は、その他の受付処理（例えば、診察を待つ人の一覧を表すリストデータに当該患者の識別情報を追加する処理など）を行い、受付が完了したことを表す画面８０をディスプレイ装置に表示させる。

一方、電子決済情報３０が不要である場合、受付処理装置２０００は、画面７０の表示は行わず、前述した「その他の受付処理」に相当する処理を行い、受付が完了したことを表す画面８０をディスプレイ装置に表示させる。

なお、図２を用いて説明した処理は、受付処理装置２０００に対する理解を容易にするための例示であり、受付処理装置２０００が行う具体的な処理を限定するものではない。例えば後述するように、顧客１０の属性を特定する方法は、顧客１０の識別情報を利用する方法に限定されない。

＜作用効果＞
サービス等の提供を行う際、先にサービス等の提供をした後、その代金の支払いが後で行われるということがある。例えば病院では、診察を行った後に代金の支払いが行われる。また、ホテルでは、チェックアウトの際に料金の支払いが行われることもある。具体的には、宿泊費をチェックアウトの際に支払うケースや、宿泊費の他に追加で発生した代金（ルームサービスの利用料など）の支払いをチェックアウトの際に行うケースである。

このように代金が後払いである場合、顧客が代金を支払わずに帰ってしまう危険性がある。すなわち、代金の不払いが発生する恐れがある。

代金の不払いを防ぐ方法の一つとして、全ての顧客から、サービス等の提供を行う前に、電子決済を可能とする情報（電子決済情報）を取得しておくという方法が考えられる。こうすることで、顧客が代金を支払わずに帰ってしまった場合でも、その顧客について取得しておいた電子決済情報を利用して、代金の決済処理を実行することができる。しかしながらこの方法には、代金を支払う意思がある人からみれば、受付の時間が不必要に長くなるなど、施設の利便性が低下してしまうという問題がある。

この点、受付処理装置２０００では、全ての顧客１０が電子決済情報３０を提供しなければならないわけではなく、電子決済情報３０の要否が顧客１０の属性によって判定される。ここで、代金の不払いが発生する蓋然性が比較的高いと推測される顧客１０の属性では電子決済情報３０が必要と判定され、なおかつ代金の不払いが発生する蓋然性が比較的低いと推測される顧客１０の属性では電子決済情報３０が不要であるように適切な判定条件を設定すれば、受付処理装置２０００は、代金の不払いが発生する蓋然性が比較的高いと推測される顧客１０のみに対して、電子決済情報３０の提供を要求することになる。よって、本実施形態の受付処理装置２０００によれば、代金を支払う意思がある人にとって施設等の利便性が低下することを防ぎつつ、サービス等の提供に対する代金をより確実に得ることができるようになる。

また、受付処理装置２０００では、電子決済情報３０を提供するか否かが顧客１０の意思によって決定されるのではなく、顧客１０の属性基づき受付処理装置２０００によって決定される。そのため、受付処理装置２０００によれば、代金の支払いを行う意思のない顧客１０が、電子決済情報３０の提供を行わないことを自分の意思で選択することはできない。よって、顧客１０からより確実に代金を徴収することが可能となる。

以下、本実施形態についてさらに詳細を述べる。

＜機能構成の例＞
図３は、実施形態１の受付処理装置２０００の機能構成を例示する図である。受付処理装置２０００は、判定部２０２０及び受付処理部２０４０を有する。判定部２０２０は、顧客１０の属性に基づいて、顧客１０についての電子決済情報３０が、顧客１０についての要求受付処理に必要であるか否かを判定する。受付処理部２０４０は、要求受付処理を実行する。ここで、電子決済情報３０が必要であると判定された場合、受付処理部２０４０は、電子決済情報３０を取得した後に、要求受付処理を完了する。

＜受付処理装置２０００のハードウエア構成の例＞
受付処理装置２０００の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、受付処理装置２０００の各機能構成部がハードウエアとソフトウエアとの組み合わせで実現される場合について、さらに説明する。

図４は、受付処理装置２０００を実現するための計算機１０００を例示する図である。計算機１０００は任意の計算機である。例えば計算機１０００は、Personal Computer（PC）やサーバマシンなどの据え置き型の計算機である。その他にも例えば、計算機１０００は、スマートフォンやタブレット端末などの可搬型の計算機である。なお、計算機１０００は、受付処理装置２０００を実現するために設計された専用の計算機であってもよいし、汎用の計算機であってもよい。

計算機１０００は、バス１０２０、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０を有する。バス１０２０は、プロセッサ１０４０、メモリ１０６０、ストレージデバイス１０８０、入出力インタフェース１１００、及びネットワークインタフェース１１２０が、相互にデータを送受信するためのデータ伝送路である。ただし、プロセッサ１０４０などを互いに接続する方法は、バス接続に限定されない。

プロセッサ１０４０は、CPU（Central Processing Unit）、GPU（Graphics Processing Unit）、FPGA（Field−Programmable Gate Array）などの種々のプロセッサである。メモリ１０６０は、RAM（Random Access Memory）などを用いて実現される主記憶装置である。ストレージデバイス１０８０は、ハードディスク、SSD（Solid State Drive）、メモリカード、又は ROM（Read Only Memory）などを用いて実現される補助記憶装置である。

入出力インタフェース１１００は、計算機１０００と入出力デバイスとを接続するためのインタフェースである。例えば入出力インタフェース１１００には、キーボードなどの入力装置や、ディスプレイ装置などの出力装置が接続される。

ネットワークインタフェース１１２０は、計算機１０００を通信網に接続するためのインタフェースである。この通信網は、例えば LAN（Local Area Network）や WAN（Wide Area Network）である。ネットワークインタフェース１１２０が通信網に接続する方法は、無線接続であってもよいし、有線接続であってもよい。

ストレージデバイス１０８０は、受付処理装置２０００の各機能構成部を実現するプログラムモジュールを記憶している。プロセッサ１０４０は、これら各プログラムモジュールをメモリ１０６０に読み出して実行することで、各プログラムモジュールに対応する機能を実現する。

＜処理の流れ＞
図５は、実施形態１の受付処理装置２０００によって実行される処理の流れを例示するフローチャートである。判定部２０２０は、顧客１０の属性に基づいて、顧客１０についての電子決済情報３０が、その顧客１０についての要求受付処理に必要であるか否かを判定する（Ｓ１０２）。受付処理部２０４０は、顧客１０についての要求受付処理を実行する（Ｓ１０４）。ここで、電子決済情報３０が必要であると判定された場合における要求受付処理には、その電子決済情報３０を取得して決済情報記憶装置５０に格納するという処理が含まれる。

図６は、受付処理装置２０００を利用する流れをより具体的に例示する図である。まず受付処理装置２０００は、顧客１０に対し、要求を特定するための入力を促す情報を出力する（Ｓ２０２）。例えば図２では、診察券の入力を促す画面が表示されている。顧客１０は、要求を特定するための入力を行う（Ｓ２０４）。

要求を特定するための入力は任意である。例えば図２の例では、診察券の入力が行われている。受付処理装置２０００は、診察券から得られる患者の識別情報で患者のデータベースの参照等を行うことにより、患者の要求を特定することができる。より具体的には、例えば診察の事前予約が行われていれば、その予約に係る診察が患者の要求であると特定できる。その他にも例えば、受付処理装置２０００は、顧客１０の要求を特定するための入力を促す画面をディスプレイ装置に表示させ、その画面に対する入力に基づいて、要求を特定してもよい。

また、受付処理装置２０００に対する入力を得ることなく、顧客１０からの要求が特定されてもよい。この場合、Ｓ２０２及びＳ２０４が不要となる。例えば受付処理装置２０００は、受付処理装置２０００に接続されたセンサで顧客１０の生体情報を自動的に取得することで顧客１０を特定し、その顧客１０に予め対応づけられている要求（例えば、予約済みの診察など）を特定する。

判定部２０２０は、顧客１０の属性を示す情報を取得する（Ｓ２０６）。以下、顧客１０の属性を示す情報を、属性情報と呼ぶ。判定部２０２０は、属性情報を用いて、顧客１０についての電子決済情報３０が必要であるか否かを判定する（Ｓ２０８）。

電子決済情報３０が必要であると判定された場合（Ｓ２０８：必要）、受付処理部２０４０は、電子決済情報３０の入力を促す情報を出力する（Ｓ２１０）。例えば図２の例では、クレジットカード情報を入力する入力画面が表示されている。顧客１０は、電子決済情報３０を入力する（Ｓ２１２）。受付処理部２０４０は、入力された電子決済情報３０を決済情報記憶装置５０に格納する（Ｓ２１４）。受付処理部２０４０は、残りの要求受付処理を実行する（Ｓ２１６）。

電子決済情報３０が必要でないと判定された場合（Ｓ２０８：不要）、受付処理部２０４０は、残りの要求受付処理を実行する（Ｓ２１６）。

ただし、電子決済情報３０が必要でないと判断された場合でも、顧客１０が電子決済情報３０を入力できるようにしてもよい。例えば、電子決済情報３０を事前に登録しておくことで代金の支払いが自動的に行われるようにできる場合、顧客１０が自ら電子決済情報３０の登録を望むことも考えられる。

そこで例えば受付処理装置２０００は、ただし、電子決済情報３０を入力するかどうかを顧客１０に選択させ、顧客１０が入力することを選択した場合は、入力された電子決済情報３０を決済情報記憶装置５０に格納してもよい。その他にも例えば、受付処理装置２０００は、電子決済情報３０が必要であるか否かにかかわらず、電子決済情報３０を入力するための入力画面を出力してもよい。この場合、電子決済情報３０が必要でないと判定された場合には、電子決済情報３０の入力をせずに次の画面に遷移できる（例えば、「入力せずに次へ」などのボタンを設ける）ようにする。

＜受付処理装置２０００の実現形態＞
受付処理装置２０００は、顧客１０によって操作される利用者端末として実現されてもよいし、顧客１０によって操作される利用者端末から受信するデータに応じて動作するサーバマシンとして動作してもよい。

図７は、受付処理装置２０００の実現形態を例示する図である。図７の上段では、受付処理装置２０００が利用者端末１００として実現されている。利用者端末１００は、受付処理装置２０００が運用されている施設を利用する顧客１０によって操作される端末であり、例えば病院に設置される受付機である。

利用者端末１００は、ネットワークを介して決済情報記憶装置５０に接続されている。利用者端末１００は、電子決済情報３０を取得した場合、ネットワークを介して決済情報記憶装置５０にアクセスして、決済情報記憶装置５０に電子決済情報３０を格納する。

図７の下段では、受付処理装置２０００がサーバマシン１１０として実現されている。この場合、利用者端末１００は、顧客１０とサーバマシン１１０との間のインタフェースとして機能する。すなわち、利用者端末１００は、顧客１０が入力した情報をサーバマシン１１０へ送信し、サーバマシン１１０の処理結果を顧客１０へ提示する。

サーバマシン１１０は、ネットワークを介して決済情報記憶装置５０と接続されている。サーバマシン１１０は、利用者端末１００から送信された電子決済情報３０を取得し、決済情報記憶装置５０に格納する。

なお、受付処理装置２０００がサーバマシン１１０として実現される場合において、利用者端末１００は、サーバマシン１１０（受付処理装置２０００）と同様のハードウエアで構成することができる。

＜＜利用者端末１００のハードウエア構成の例＞＞
図８は、利用者端末１００のハードウエア構成を例示する図である。また、図９は、計算機３０００の正面の外観を例示する図である。利用者端末１００は、計算機３０００を用いて実現される。計算機３０００は、受付処理装置２０００を実現する計算機１０００と同様に、プロセッサ、メモリ、ストレージデバイス、入出力インタフェース、及びネットワークインタフェースを有する。

計算機３０００には、入出力インタフェース３１００を介して、タッチパネルディスプレイ２０２、スピーカ２０４、レシートプリンタ２０６、釣銭機２０８、カメラ２１０、マイク２１２、スキャナ２１４、磁気カードリーダ２１６、ＩＣカードリーダ２１８、カード発行機２２０、及びＡ４用紙プリンタ２２２が接続されている。タッチパネルディスプレイ２０２は、顧客１０に提示する画面を表示する機能、及び顧客１０によるタッチ操作を受け付ける機能を有する。スピーカ２０４は、任意の音声の出力に利用される。レシートプリンタ２０６は、紙媒体で顧客に情報を提供するために用いられる。例えば、受付処理が完了した顧客１０に対して受付番号を発行する場合に、受付番号を印字した紙がレシートプリンタ２０６から出力される。釣銭機２０８は、現金投入口から投入された現金の格納、及び現金払い戻し口を介した現金の払い出しに利用される。

カメラ２１０は、顧客１０を撮像するために利用される。例えば顧客１０を撮像することで得られた画像を用いて、顧客１０の特定が行われる。マイク２１２は、顧客１０から音声入力を受け付けるために利用される。スキャナ２１４は、保険証やパスポートなど、情報が表示されている媒体を撮像して画像を生成するために利用される。スキャナ２１４によって得られる画像に対して文字認識処理などの画像解析を行うことにより、種々の情報を得ることができる。なお、スキャナ２１４を用いて読み取られる情報は、文字に限定されない。例えばスキャナ２１４は、多次元コードの読取りに利用されてもよい。磁気カードリーダ２１６は、磁気カードから情報を読み取るために利用される。ＩＣカードリーダ２１８は、ＩＣカードから情報を読み取るために利用される。

カード発行機２２０は、顧客１０に対して新規のカード（例えば診察券など）を発行するために利用される。Ａ４用紙プリンタ２２２は、種々の情報が印字された紙を出力するために利用される。

なお、受付処理装置２０００が利用者端末１００として実現される場合、計算機３０００は計算機１０００に相当する。一方、受付処理装置２０００がサーバマシン１１０として実現される場合、計算機３０００は、ネットワークを介して計算機１０００（サーバマシン１１０を実現する計算機）と接続される。

＜顧客１０からの要求について：Ｓ２０２、Ｓ２０４＞
受付処理装置２０００は、顧客１０からの要求を表すデータを取得する。このデータを、リクエストデータと呼ぶ。例えばリクエストデータは、受付処理装置２０００に対する入力操作に基づいて生成される。例えば、施設が提供しているサービスの一覧をディスプレイ装置に表示させ、操作者がその中から利用するサービスを選択するようにする。この際、顧客１０を特定するための情報も入力されるとする。顧客１０を特定するための情報は、例えば、顧客１０の識別情報である。その他にも例えば、予め各顧客１０の生体情報（例えば顔画像や指紋など）とその顧客１０の識別情報とを対応づけて記憶装置に記憶させておき、センサを利用して顧客１０の生体情報を得ることで、顧客１０の識別情報を特定してもよい。

なお、顧客１０が利用したいサービス等は、予め登録されていてもよい。例えば病院において診察の予約をしておいたり、ホテルにおいて宿泊の予約をしておいたりするケースである。この場合、顧客１０の識別情報に対応づけて、その顧客１０が行う要求を表すリクエストデータを予め記憶させておく。この場合、受付処理装置２０００は、顧客１０の識別情報を取得し、取得したその顧客１０に対応づけられているリクエストデータを取得する。

また、前述したように、受付処理装置２０００に対する入力を得ることなく、顧客１０からの要求が特定されてもよい。例えば受付処理装置２０００は、受付処理装置２０００に接続されたセンサで顧客１０の識別情報（生体情報）を自動的に取得することで顧客１０を特定し、その顧客１０に予め対応づけられているリクエストデータを取得する。

＜電子決済情報３０について：Ｓ２１０、Ｓ２１２＞
電子決済情報３０は、顧客１０の介入を要することなく電子決済を可能とする情報である。例えば電子決済情報３０としては、クレジットカード情報、銀行口座の情報、QR コード（登録商標）決済の情報を利用することができる。例えば、クレジットカードや銀行のキャッシュカードなどの媒体から情報を読み出すリーダを受付処理装置２０００に設けておき、顧客１０がこのリーダに媒体を読み取らせる（例えば、クレジットカードリーダに対してクレジットカードを挿入する）。受付処理装置２０００は、このリーダによって読み取られた情報を電子決済情報３０として取得する。その他にも例えば、受付処理装置２０００は、顧客１０に対して電子決済情報３０を入力するための入力画面（図２の画面７０など）を表示し、その入力画面に入力された情報を、電子決済情報３０として取得する。

その他にも例えば、顧客１０が所持する携帯端末等に予め電子決済情報３０を記憶させておいてもよい。この場合、受付処理装置２０００は、顧客１０の携帯端末等から電子決済情報３０を取得する。例えば電子決済情報３０は、携帯端末等から受付処理装置２０００に対し、無線通信（例えば NFC（Near Field Communication）で送信される。この場合、受付処理装置２０００には、顧客１０の携帯端末と通信するための構成（例えば、NFC リーダ）が設けられる。

＜電子決済情報３０の要否の判定：Ｓ１０２、Ｓ２０８＞
判定部２０２０は、顧客１０の属性に基づいて電子決済情報３０の要否を判定する（Ｓ１０２）。具体的には、判定部２０２０は、属性情報に示される顧客１０の属性が所定条件を満たしているか否かを判定することによって、電子決済情報３０の要否を判定する。所定条件が満たされている場合には、電子決済情報３０の取得が行われる。

＜＜所定条件のバリエーション＞＞
所定条件としては、様々なものを採用することができる。例えば所定条件として、「顧客１０の国籍が所定の国籍に該当しないこと」という条件を採用しうる。所定の国籍は、例えば、受付処理装置２０００が運用されている国の国籍である。例えば所定の国籍を日本国籍とした場合、日本国籍を持たない顧客１０の属性は所定条件を満たす。そのため、日本国籍を持たない顧客１０については、電子決済情報３０が必要となる。一方で、日本国籍を持つ顧客１０については、電子決済情報３０が不要となる。その他にも例えば、所定条件として、「顧客１０の住所が所定の国（例えば受付処理装置２０００が運用されている国）でないこと」という条件を採用しうる。

顧客１０の国籍や住所を特定する方法には、様々な方法を採用することができる。例えば、顧客１０の国籍は、国籍が記載又は記録されている身分証明書（パスポートなど）を用いて特定することができる。より具体的には、身分証明書をスキャナで読み取ることによって身分証明書に印字されている国籍を特定する方法や、身分証明書に組み込まれているＩＣチップからＩＣカードリーダで国籍の情報を取得する方法などが考えられる。住所についても同様に、住所が記載又は記録されている身分証明書を用いて特定することができる。

国籍については、顧客１０の外見の特徴から特定してもよい。具体的には、受付処理装置２０００は、顧客１０の顔をカメラで撮像することで得られた顧客１０の顔画像を画像解析することにより、顧客１０の国籍を特定してもよい。

所定条件としては、その他にも例えば、「顧客１０が事前予約を行っていないこと」、「顧客１０がブラックリストに登録されていること」、又は「ブラックリストで顧客１０を検索するための個人情報が顧客１０から提供されていないこと」などの条件を採用しうる。ここでいうブラックリストには、信用度が低い人物や危険度が高い人物を示す任意のリストを利用できる。なお、ブラックリストで顧客１０を検索するために必要な個人情報の種類（氏名、住所、生年月日など）は、固定で定められていてもよいし、受付処理装置２０００の管理者等によって設定されてもよい。

その他にも例えば、所定条件として、「顧客１０による要求が所定の時間帯に行われたこと」や「顧客１０に対してサービスの提供が完了する予定の時刻が所定の時間帯であること」という条件を採用しうる。例えば所定の時間帯には、代金の支払いを行わずに帰ろうとする顧客１０をスタッフ等の監視によって発見しづらい時間帯を設定する。こうすることで、「代金の支払いの発生を監視によって防ぐことが比較的容易な時間帯には、電子決済情報３０の取得を省略して施設の利便性を高めつつ、監視では代金の不払いの発生を防ぐことが難しい時間帯には、電子決済情報３０を取得するようにして代金の不払いの発生を防ぐようにする」という運用が可能となる。

その他にも例えば、所定条件として、「顧客１０の使用言語が所定の言語でない」という条件を採用しうる。例えば所定の言語には、受付処理装置２０００が運用されている国における公用語が設定される。所定の言語を日本語とした場合、顧客１０の使用言語が日本語である場合には所定条件が満たされず、顧客１０の使用言語が日本語以外である場合には所定条件が満たされる。

例えば、受付処理装置２０００が顧客１０によって操作される端末であってその設定言語（表示される言語や入力を受け付ける言語）を顧客１０が指定できるようにしておく。この場合、顧客１０によって指定された設定言語を、顧客１０の使用言語として扱うことができる。

その他にも例えば、所定条件として、「代金の支払いが必要であること」という条件を採用することができる。顧客１０がサービス等の提供に対して代金を支払う必要がないケースもあるためである。例えば病院では、年齢などといった所定の条件を満たす患者について、費用の支払いが免除されることがある。その他にも例えば、施設の利用料の支払い方法として、施設を利用する度に代金を支払うという方法と、複数回の利用（例えば所定期間内の利用）について事前に一括で支払っておくという方法とが選択できるケースもある。このケースでは、事前に一括の支払いを行った顧客１０については、代金の支払いが不要である。

その他にも例えば、所定条件として、「過去所定期間内に施設を利用していないこと」という条件を採用することができる。例えば、「過去６ヶ月以内に施設を利用していないこと」という条件の場合には、現在の日付を基準として過去６ヶ月以内に施設を利用していれば、電子決済情報３０の登録が不要となる。一方、現在の日付を基準として過去６ヶ月以内に施設を利用していなければ、電子決済情報３０の登録が必要となる。過去所定期間に施設を利用したか否かは、顧客１０による施設利用の履歴に基づいて特定することができる。施設利用の履歴は、顧客１０の識別情報に対応づけて記録しておく（例えば、後述する利用者情報に含めておく）。

その他にも例えば、所定条件として、「所定の保険に加入していないこと」という条件を採用することができる。例えば海外からの旅行者が顧客１０であった場合、顧客１０が海外旅行保険に加入していれば、仮に顧客１０が代金の支払いを行わなかったとしても、顧客１０が加入している保険から代金を徴収できる。

その他にも例えば、受付処理装置２０００が病院である場合には、所定条件として、「顧客１０が保険証を持っていないこと」、「顧客１０に対して健康保険組合の保険証が交付されていないこと（言い換えれば、顧客１０が健康保険組合に加入していないこと）」、「顧客１０が紹介状を持っていないこと」、又は「顧客１０が初診であること（言い換えれば、再診でないこと）」などといった条件を採用しうる。

＜＜属性について＞＞
判定部２０２０は、所定条件が満たされているか否かを判定するために、顧客１０の属性を示す属性情報を取得する。顧客１０の属性としては、様々ものを利用しうる。例えば顧客１０の属性は、国籍、住所、事前予約の有無、ブラックリストに登録されているか否か、ブラックリストで顧客１０を検索するために必要な顧客１０の個人情報が提供されているか否か、顧客１０による要求が行われた時刻、顧客１０に対するサービスの提供が完了する予定の時刻、顧客１０の使用言語、代金の支払いの要否、施設の利用履歴、所定の保険への加入の有無、保険証を持っているか否か、保険証が交付されているか否か、紹介状を持っているか否か、又は初診であるか否かなどである。なお、属性情報には、これら種々の属性のうち、前述した所定条件が満たされているか否かの判定に必要なものが含まれていればよい。例えば、「顧客１０の国籍が所定の国籍に該当しないこと」という所定条件を利用する場合、顧客１０の属性情報には、顧客１０の国籍を示すようにする。

＜＜属性情報の取得：Ｓ２０６＞＞
属性情報を取得する方法は様々である。例えば判定部２０２０は、属性情報を、施設で管理されている顧客１０に関する情報（以下、利用者情報）から得る。例えば利用者情報は、顧客１０が施設の利用登録を行う際、顧客１０によって入力され、所定の記憶装置（以下、利用者情報記憶装置）に記憶される。ただし、属性によっては、その属性値が顧客１０によって直接入力されなくてもよい。例えば、事前予約の有無、初診であるか否か、又は施設の利用履歴などは、病院で管理されている情報であり、病院で運用されている端末（データベースサーバなど）によって利用者情報に書き込まれる。これらの属性情報は、受付処理装置２０００から利用者情報記憶装置にアクセスして利用者情報を参照することにより、取得するこができる。

その他にも例えば、属性情報は、受付処理装置２０００に対して入力されてもよい。例えば顧客１０は、受付処理装置２０００を利用して受付を行う際、各種属性の属性値を入力する。例えば病院で受付を行う際、顧客１０は、保険証の有無や紹介状の有無などといった情報を受付処理装置２０００に対して入力する。この際、受付処理装置２０００は、顧客１０に対してこれらの情報の入力を促すように、これらの情報を入力可能な入力画面をディスプレイ装置に表示させる。そして受付処理装置２０００は、入力画面に対する入力に基づいて、属性情報を取得する。

また、属性情報の入力は、身分証明書などの種々の媒体を用いて行われてもよい。例えば、保険証やパスポートなどのように情報が記載されている媒体をスキャナ（例えば図８のスキャナ２１４）に読み取らせることで、識別番号、氏名、住所、国籍、又は生年月日などといった種々の属性情報を入力することができる。また、保険証券など、保険に加入していることを証明する媒体をスキャナに読み取らせることで、保険に加入していることを証明する情報（保険証券番号（保険加入者の識別番号）、氏名、住所、又は生年月日など）を入力することができる。その他にも例えば、磁気カードを磁気カードリーダ（例えば図８の磁気カードリーダ２１６）に読み取らせたり、ＩＣカードをＩＣカードリーダ（例えば図８のＩＣカードリーダ２１８）に読み取らせたりすることでも、種々の属性情報を入力することができる。

その他にも例えば、属性として顧客１０の使用言語を採用するとする。この場合、受付処理装置２０００は、自身の設定言語を表す情報を、顧客１０の使用言語を示す属性情報として取得してもよい。

その他にも例えば、属性として、顧客１０による要求が行われた時刻を採用するとする。この場合、例えば判定部２０２０は、顧客１０による受付処理装置２０００の操作が開始された時刻を、顧客１０による要求が行われた時刻として取得する。なお、操作の開始時刻は、受付処理装置２０００が所定の記憶装置に記憶させておく。

その他にも例えば、属性として、代金の支払いの要否を採用するとする。この場合、例えば代金の支払いの要否を表す情報は、予め前述した利用者情報に含められている。その他にも例えば、判定部２０２０は、代金の支払いの要否の判定に必要な顧客１０の属性を示す属性情報を取得することで、代金支払いの要否を判定してもよい。代金の支払いの要否の判定に必要な顧客１０の属性は、代金の支払いの要否の判定基準によって定まる。例えば顧客１０の年齢に基づいて判定を行う場合、判定部２０２０は、顧客１０の年齢を示す情報を取得する。

その他にも例えば、属性として、顧客１０に対してサービスの提供が完了する予定の時刻を採用するとする。この場合、例えば判定部２０２０は、顧客１０による要求が行われた時刻を取得し、その時刻にサービスの提供に要すると予想される時刻を加算することで、顧客１０に対してサービスの提供が完了する予定の時刻を算出する。また、サービスの提供が完了する予定の時刻が予め決まっている場合（例えばホテルにおけるチェックアウト時刻）、判定部２０２０は、当該時刻を示す情報を取得する。なお、サービスの提供に要すると予想される時刻を算出する技術や、予め決まっているサービス提供の完了予定時刻を取得する技術には、既存の技術を利用することができる。

ここで、一度取得した顧客１０の属性情報は、その顧客１０の利用者情報に追加して記憶させることが好適である。例えば、顧客１０がパスポートをスキャナに読み取らせることで顧客１０の国籍が特定された場合、受付処理装置２０００は、顧客１０の利用者情報に国籍情報を追加する。こうすることで次回以降、顧客１０の国籍を特定するためのパスポートの読み取りが不要となる。

このように一度取得した顧客１０の属性情報を利用者情報に含めて記憶させる場合、判定部２０２０は、判定に必要な属性情報が利用者情報に含まれるか否かを判定する。必要な属性情報が利用者情報に含まれる場合、判定部２０２０は、利用者情報からその属性情報を取得する。一方、判定部２０２０は、必要な属性情報が利用者情報に含まれない場合、その属性情報の入力を促す出力（例えば、入力画面の出力）を行い、入力された属性情報を取得する。

ただし、属性情報に有効期限を設けておき、利用者情報に含まれている属性情報が有効期限内である場合のみ、利用者情報に含まれている属性情報を利用するようにしてもよい。例えば病院では、月ごとに保険証を確認するという運用が行われていることが多い。そこで、属性情報の種類ごとに、その属性情報の有効期限を定めておく。判定部２０２０は、必要な属性情報が利用者情報に含まれており、なおかつその属性情報が有効期限内である（現在日時が有効期限より前ある）場合に、利用者情報に含まれている属性情報を利用する。一方で、必要な属性情報が利用者情報に含まれないか、又は利用者情報に含まれているその属性情報が有効期限を過ぎている場合（現在日時が有効期限の後である）場合、判定部２０２０は、その属性情報の入力を促す出力を行い、入力された属性情報を取得する。

＜要求受付処理：Ｓ１０４、Ｓ２１０からＳ２１６＞
受付処理部２０４０は要求受付処理を行う（Ｓ１０４）。電子決済情報３０が必要である場合における要求受付処理には、顧客１０の電子決済情報３０を決済情報記憶装置５０に格納する処理（Ｓ２１４）が含まれる。

電子決済情報３０が必要な場合、まず受付処理部２０４０は、電子決済情報３０を取得する（Ｓ２１０、Ｓ２１２）。電子決済情報３０を取得する方法については、前述した通りである。受付処理部２０４０は、取得した電子決済情報３０を決済情報記憶装置５０に格納する。この際、電子決済情報３０は、顧客１０の識別情報に対応づけて格納される。顧客１０の識別情報は、例えば前述したリクエストデータの取得の際に得られる。

＜＜電子決済情報３０が既に決済情報記憶装置５０に記憶されているケース＞＞
顧客１０が同じ施設を複数回利用する場合、その顧客１０の電子決済情報３０が既に決済情報記憶装置５０に記憶されている可能性がある。そこで受付処理部２０４０は、顧客１０の電子決済情報３０が既に決済情報記憶装置５０に記憶されている場合には、電子決済情報３０の取得を行わなくてよい。

例えば受付処理部２０４０は、電子決済情報３０が必要であると判定された顧客１０について、その顧客１０の識別情報で決済情報記憶装置５０を検索し、顧客１０の電子決済情報３０が既に決済情報記憶装置５０に記憶されているか否かを判定する。顧客１０の識別情報に対応づけて電子決済情報３０が決済情報記憶装置５０に記憶されている場合、受付処理部２０４０は、電子決済情報３０の取得を行わない。一方、顧客１０の識別情報に対応づけて電子決済情報３０が決済情報記憶装置５０に記憶されていない場合、受付処理部２０４０は、電子決済情報３０を取得し、取得した電子決済情報３０を決済情報記憶装置５０に格納する。

＜＜その他の受付処理について＞＞
受付処理部２０４０が実行する受付処理のうち、電子決済情報３０を決済情報記憶装置５０に格納するという処理以外の処理は、前述したリクエストデータによって定まる。具体的な要求受付処理には、任意の処理を採用することができる。例えば要求受付処理には、サービス等の提供を待つ人の一覧を表すリストデータに、顧客１０の識別情報を追加するという処理が含まれる。その他にも例えば、要求が施設の利用である場合、受付処理には、「顧客１０のステータスを、施設を利用できる状態に変更する」という処理や、「施設を利用するために必要な磁気カードを発行する」という処理などが含まれうる。

＜電子決済情報３０を利用した決済＞
顧客１０による代金の支払いが行われなかった場合、電子決済情報３０を利用した決済が実行されるようにする。このようにすることで、サービス等の提供に係る代金を確実に徴収することができる。なお、クレジットカード情報などを利用して電子決済を行う技術には、既存の技術を利用することができる。

電子決済情報３０を利用した決済処理は、受付処理装置２０００によって実行されてもよいし、受付処理装置２０００以外の装置によって実行されてもよい。以下では説明を容易にするため、電子決済情報３０を利用した決済処理が受付処理装置２０００によって行われるものとして、説明を行う。なお、電子決済情報３０を利用した決済を行う機能構成部を、決済処理部と呼ぶ。決済処理部は、顧客１０による代金の支払いが行われず、なおかつその顧客１０についての電子決済情報３０が決済情報記憶装置５０に記憶されていたら、その電子決済情報３０を利用して、その顧客１０が支払うべき代金の決済を実行する。

ここで、顧客１０による代金の支払いが行われなかったと判断する基準は様々である。例えば受付処理装置２０００は、顧客１０が代金を支払うべき期限を定め、その期限を過ぎても代金の支払いが行われていない場合に、電子決済情報３０を利用した決済を実行する。顧客１０が代金を支払うべき期限は、例えば、顧客１０に対するサービス等が所定の状態になってから所定時間が経過した時点として定められる。例えば病院の場合、医師による診察が完了した状態や、会計窓口のスタッフから呼び出しが行われた状態などを、上記所定の状態として扱うことができる。その他にも例えば、ホテルの場合、現在時刻がチェックアウト時刻以降になったという状態を、上記所定の状態として扱うことができる。すなわち、診察の完了、会計窓口のスタッフからの呼び出し、又はチェックアウト時刻の到来などから所定の時間が経過しても代金が支払われていなかったら、電子決済情報３０を利用した決済が行われる。

ここで、顧客１０に対するサービス等が所定の状態になったことを把握するためには、受付処理装置２０００の外部の装置から情報を取得する必要があるケースもある。例えば、「医師による診察が完了した状態」という状態への遷移は、患者の診察の完了を示す入力が医師の端末に対して行われたことなどを契機に起こる。また、「会計窓口のスタッフから呼び出しが行われた状態」という状態への遷移は、患者を呼び出したことを示す入力が会計窓口の端末に対して行われたことなどを契機に起こる。

そこでこのような場合、受付処理装置２０００は、顧客１０に対するサービス等が所定の状態になったことを表す情報を外部の装置から受信することで、顧客１０に対するサービスが所定の状態になったことを把握する。例えば受付処理装置２０００は、医師の端末から、顧客１０（患者）の診察の完了を示す情報を受信したら、その受信時点から所定時間経過後に、その顧客１０による代金の支払いが行われたか否かを判定する。そして、顧客１０による代金の支払いが行われていなかったら、受付処理装置２０００は、その顧客１０についての電子決済情報３０を利用して決済処理を行う。

一方で、外部の装置から情報を得なくても、「顧客１０に対するサービス等が所定の状態になってから所定時間が経過した時点」を期限とした決済処理を実現できるケースもある。例えばホテルにおいてチェックアウト時刻を利用するケースでは、「顧客１０による代金の支払いが行われたか否かを判定する」という処理を、その顧客１０のチェックアウト時刻から所定時間後に実行される処理として予めスケジュールしておくといった実現方法が考えられる。上記判定処理において、顧客１０による代金の支払いが行われていないと判定されたら、受付処理装置２０００は、その顧客１０についての電子決済情報３０を利用して決済処理を行う。

代金の支払いの期限を定める方法は、上述した方法に限定されない。例えば代金の支払いの期限は、サービス等の提供日を基準として定められてもよい。具体的には、サービス等の提供日の終了時点（すなわち、提供日の次の日の０時）や、サービス等の提供日から所定の日数が経過した日の所定時刻（例えば、提供日の一週間後の午前９時）などのように期限を定めることができる。このように期限を定めるケースでは、例えば前述したように、「顧客１０による代金の支払いが行われたか否かを判定する」という処理を、代金の支払いの期限になったタイミングで実行されるようにスケジュールしておくという方法により、電子決済情報３０を利用した決済処理を実現できる。

また、顧客１０による代金の支払いが行われなかったと判断する基準は、支払い期限に基づくものに限定されない。例えば受付処理装置２０００は、顧客１０による代金の支払いが行われなかった旨を示す入力操作が行われた場合に、電子決済情報３０を利用した決済を実行してもよい。例えばこの入力操作は、施設のスタッフ（例えば、会計窓口のスタッフなど）によって行われる。より具体的には、施設のスタッフが操作する端末（例えば会計窓口に設置されている PC）において、顧客１０による代金の支払いが行われなかったことを示す入力が行われたら、その端末から受付処理装置２０００に対し、顧客１０による代金の支払いが行われなかった旨を示す情報が送信されるようにする。例えば病院において、会計窓口のスタッフが顧客１０を呼び出したにもかかわらず、顧客１０が会計窓口に現れなかったら、会計スタッフが端末に対し、顧客１０が代金の支払いを行わなかったことを示す入力を行うというケースが考えられる。

なお、電子決済情報３０を利用した決済には、代金を支払わなかった顧客１０についての電子決済情報３０が決済情報記憶装置５０に記憶されている必要がある。そこで受付処理装置２０００は、顧客１０について電子決済情報３０を利用した決済を行うと判定したら、その顧客１０の識別情報で決済情報記憶装置５０を検索する。そして、その顧客１０の識別情報に対応する電子決済情報３０が得られたら、受付処理装置２０００は、その電子決済情報３０を利用した決済を行う。

顧客１０の識別情報に対応する電子決済情報３０が決済情報記憶装置５０に記憶されていない際に受付処理装置２０００が行う処理は任意である。例えば受付処理装置２０００は、代金の支払いを行わなかった顧客１０の識別情報を示す通知を出力する。この通知の出力先は任意である。例えば、受付処理装置２０００が運用されている施設の管理者の端末や、犯罪を監視する組織（警備会社や警察など）が所有する端末などを出力先とすることができる。

なお、電子決済情報３０を用いた決済が行われた場合においても、上述した各端末に対して通知が出力されるようにしてもよい。このようにすることで、代金を徴収できたか否かにかかわらず、代金の支払いを自主的に行わなかった顧客１０を把握することができる。

＜変形例＞
使用言語に基づいて電子決済情報３０の要否が定まる場合、以下で説明する構成を採用することもできる。図１０は、変形例の受付処理装置２０００の利用環境を例示する図である。この例では、同一の施設に、設定言語がそれぞれ異なる複数の受付処理装置２０００が設置される。そして、設定言語が所定の言語である受付処理装置２０００−１では、顧客１０からの要求の受付処理に、電子決済情報３０の取得が含まれない。一方、設定言語が所定の言語以外の受付処理装置２０００−２では、顧客１０からの要求の受付処理に、電子決済情報３０の取得が含まれる。

例えば所定の言語が日本語である場合、設定言語が日本語である受付処理装置２０００−１では、電子決済情報３０の取得が行われない。一方、設定言語が英語や中国語などといった日本語以外の言語である受付処理装置２０００−２では、電子決済情報３０の取得が行われる。

このような構成を採用する場合、受付処理装置２０００が行う処理には、電子決済情報３０の要否を判定する処理が含まれなくてもよい。すなわち、受付処理装置２０００は、受付処理部２０４０を備えればよく、判定部２０２０を備えなくてもよい。そこで例えば、受付処理装置２０００に対し、要求受付処理に電子決済情報３０の取得が含まれるか否かの設定操作を行えるようにしておく。具体的には、受付処理装置２０００は、要求受付処理に電子決済情報３０の取得が含まれるか否かを指定する入力を管理者から受け付ける。「要求受付処理に電子決済情報３０の取得が含まれる」という設定がなされている受付処理装置２０００の受付処理部２０４０は、要求受付処理において、電子決済情報３０の取得を行う。一方、「要求受付処理に電子決済情報３０の取得が含まれない」という設定がなされている受付処理装置２０００の受付処理部２０４０は、要求受付処理において、電子決済情報３０の取得を行わない。

管理者は、設定言語が所定の言語である受付処理装置２０００に対しては、要求受付処理に電子決済情報３０の取得を含まないように、設定操作を行う。一方で、管理者は、設定言語が所定言語でない受付処理装置２０００に対しては、要求受付処理に電子決済情報３０の取得が含まれるように、設定操作を行う。こうすることで、「電子決済情報３０の要否を判定する」という機能を受付処理装置２０００に持たせることなく、設定言語が所定言語である場合に電子決済情報３０の取得が行われるという運用を実現することができる。

ここで、変形例の受付処理装置２０００がサーバマシンとして実現されるとする。この場合、前述した要求受付処理に電子決済情報３０の取得が含まれるか否かの設定は、利用者端末に対して行われる。要求受付処理に電子決済情報３０の取得が含まれるという設定が行われている利用者端末では、電子決済情報３０を顧客１０から得るための処理が行われ、要求受付処理に利用される情報の中に電子決済情報３０を入れて、受付処理装置２０００に対して送信する。一方で、要求受付処理に電子決済情報３０の取得が含まれないという設定が行われている利用者端末では、受付処理装置２０００に対して送信される情報の中には電子決済情報３０が含まれない。

要求受付処理に必要な情報を利用者端末から取得した受付処理装置２０００（サーバマシン）は、取得した情報の中に電子決済情報３０が含まれているか否かを判定する。取得した情報の中に電子決済情報３０が含まれている場合、受付処理装置２０００は、取得した電子決済情報３０を決済情報記憶装置５０に格納する。一方、取得した情報の中に電子決済情報３０が含まれていない場合、受付処理装置２０００は、電子決済情報３０を決済情報記憶装置５０に格納するという処理を行わない。

以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記各実施形態の組み合わせ、又は上記以外の様々な構成を採用することもできる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

以下、参考形態の例を付記する。
１． サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理部と、
前記顧客の属性に基づいて、前記顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定部と、
有し、
前記顧客の前記電子決済情報が必要であると判定された場合、その顧客についての前記電子決済情報を取得した後、前記受付処理を完了する受付処理装置。
２． 前記顧客の属性は、前記サービス又は前記商品に対する不払いの可能性に関する情報である、１．に記載の受付処理装置。
３． 前記顧客の属性は、所定の保険への加入の有無、保険証を持っているか否か、及び保険証が交付されているか否かのうち、いずれか１つ以上を含む、１．又は２．に記載の受付処理装置。
４． 前記顧客の属性は、国籍及び使用言語のうち、いずれか１つ以上を含む、１．又は２．に記載の受付処理装置。
５． 前記顧客の属性は、ブラックリストに登録されているか否かを含む、１．又は２．に記載の受付処理装置。
６． 前記顧客による代金の支払いが行われなかった場合に、その顧客の電子決済情報を用いて前記代金の決済を行う決済処理部を有する、１．乃至５．いずれか一つに記載の受付処理装置。
７． 前記決済処理部は、前記顧客が代金を支払う期限を過ぎてもその顧客による代金の支払いが行われていない場合に、前記顧客による代金の支払いが行われなかったと判定する、６．に記載の受付処理装置。
８． 前記決済処理部は、前記顧客による代金の支払いが行われなかったことを示す入力操作が行われた場合に、前記顧客による代金の支払いが行われなかったと判定する、６．に記載の受付処理装置。

９． コンピュータによって実行される制御方法であって、
サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理ステップと、
前記顧客の属性に基づいて、前記顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定ステップと、を有し、
前記顧客の電子決済情報が必要であると判定された場合、その顧客についての前記電子決済情報を取得した後、前記受付処理を完了する、制御方法。
１０． 前記顧客の属性は、前記サービス又は前記商品に対する不払いの可能性に関する情報である、９．に記載の制御方法。
１１． 前記顧客の属性は、所定の保険への加入の有無、保険証を持っているか否か、及び保険証が交付されているか否かのうち、いずれか１つ以上を含む、９．又は１０．に記載の制御方法。
１２． 前記顧客の属性は、国籍及び使用言語のうち、いずれか１つ以上を含む、９．又は１０．に記載の制御方法。
１３． 前記顧客の属性は、ブラックリストに登録されているか否かを含む、９．又は１０．に記載の制御方法。
１４． 前記顧客による代金の支払いが行われなかった場合に、その顧客の電子決済情報を用いて前記代金の決済を行う決済処理ステップを有する、９．乃至１３．いずれか一つに記載の制御方法。
１５． 前記決済処理ステップにおいて、前記顧客が代金を支払う期限を過ぎてもその顧客による代金の支払いが行われていない場合に、前記顧客による代金の支払いが行われなかったと判定する、１４．に記載の制御方法。
１６． 前記決済処理ステップにおいて、前記顧客による代金の支払いが行われなかったことを示す入力操作が行われた場合に、前記顧客による代金の支払いが行われなかったと判定する、１４．に記載の制御方法。

１７． ９．乃至１６．いずれか一つに記載の制御方法の各ステップをコンピュータに実行させるプログラム。

１８． 第１の受付処理装置と第２の受付処理装置を有する要求処理システムであって、
前記第１の受付処理装置及び前記第２の受付処理装置はいずれも、サービス又は商品の提供を要求する顧客の受付処理を実行し、
前記第１の受付処理装置は、
設定言語が所定の言語であり、
前記受付処理に、前記顧客について電子決済を可能とする電子決済情報を取得する処理が含まれ、
前記第２の受付処理装置は、
設定言語が前記所定の言語以外の言語であり、
前記受付処理に、前記顧客について前記電子決済情報を取得する処理が含まれない、システム。

１０ 顧客
３０ 電子決済情報
５０ 決済情報記憶装置
６０ 画面
７０ 画面
８０ 画面
１００ 利用者端末
１１０ サーバマシン
２０２ タッチパネルディスプレイ
２０４ スピーカ
２０６ レシートプリンタ
２０８ 釣銭機
２１０ カメラ
２１２ マイク
２１４ スキャナ
２１６ 磁気カードリーダ
２１８ ＩＣカードリーダ
２２０ カード発行機
２２２ Ａ４用紙プリンタ
１０００ 計算機
１０２０ バス
１０４０ プロセッサ
１０６０ メモリ
１０８０ ストレージデバイス
１１００ 入出力インタフェース
１１２０ ネットワークインタフェース
２０００ 受付処理装置
２０２０ 判定部
２０４０ 受付処理部
３０００ 計算機
３０２０ バス
３０４０ プロセッサ
３０６０ メモリ
３０８０ ストレージデバイス
３１００ 入出力インタフェース
３１２０ ネットワークインタフェース

Claims (11)

1. サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理部と、
   前記顧客の属性に基づいて、前記顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定部と、
   有し、
   前記顧客の前記電子決済情報が必要であると判定された場合、その顧客についての前記電子決済情報を取得した後、前記受付処理を完了する受付処理装置。
2. 前記顧客の属性は、前記サービス又は前記商品に対する不払いの可能性に関する情報である、請求項１に記載の受付処理装置。
3. 前記顧客の属性は、所定の保険への加入の有無、保険証を持っているか否か、及び保険証が交付されているか否かのうち、いずれか１つ以上を含む、請求項１又は２に記載の受付処理装置。
4. 前記顧客の属性は、国籍及び使用言語のうち、いずれか１つ以上を含む、請求項１又は２に記載の受付処理装置。
5. 前記顧客の属性は、ブラックリストに登録されているか否かを含む、請求項１又は２に記載の受付処理装置。
6. 前記顧客による代金の支払いが行われなかった場合に、その顧客の電子決済情報を用いて前記代金の決済を行う決済処理部を有する、請求項１乃至５いずれか一項に記載の受付処理装置。
7. 前記決済処理部は、前記顧客が代金を支払う期限を過ぎてもその顧客による代金の支払いが行われていない場合に、前記顧客による代金の支払いが行われなかったと判定する、請求項６に記載の受付処理装置。
8. 前記決済処理部は、前記顧客による代金の支払いが行われなかったことを示す入力操作が行われた場合に、前記顧客による代金の支払いが行われなかったと判定する、請求項６に記載の受付処理装置。
9. コンピュータによって実行される制御方法であって、
   サービス又は商品の提供を要求する顧客の受付処理を実行する受付処理ステップと、
   前記顧客の属性に基づいて、前記顧客の電子決済を可能とする電子決済情報が必要であるか否かを判定する判定ステップと、を有し、
   前記顧客の電子決済情報が必要であると判定された場合、その顧客についての前記電子決済情報を取得した後、前記受付処理を完了する、制御方法。
10. 請求項９に記載の制御方法の各ステップをコンピュータに実行させるプログラム。
11. 第１の受付処理装置と第２の受付処理装置を有する要求処理システムであって、
    前記第１の受付処理装置及び前記第２の受付処理装置はいずれも、サービス又は商品の提供を要求する顧客の受付処理を実行し、
    前記第１の受付処理装置は、
    設定言語が所定の言語であり、
    前記受付処理に、前記顧客について電子決済を可能とする電子決済情報を取得する処理が含まれ、
    前記第２の受付処理装置は、
    設定言語が前記所定の言語以外の言語であり、
    前記受付処理に、前記顧客について前記電子決済情報を取得する処理が含まれない、システム。

Images