JP2006228157A - 受付装置 - Google Patents

Abstract

【課題】 ユーザから申し込みを受け付ける際に、その申し込み内容に応じて手続きを変更することが可能な受付装置を提供する。
【解決手段】 本発明に係る受付装置は、ユーザから申し込みを受け付ける装置であって、申し込み対象物の属性と申し込み手続きの複雑度とを対応付けた対応テーブルから、申し込み対象物の属性に対応する複雑度を判定する複雑度判定部１６２と、前記複雑度判定部１６２によって判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する画面生成部１６４と、前記画面生成部１６４によって申し込みの意思が確認されたときに当該申し込みを受け付ける予約ＤＢ１３とを備える。
【選択図】 図５

Description

本発明は、ユーザから申し込みを受け付ける装置に関し、特に、会議室予約システムや商品購入システムにおいて会議室予約や商品購入の申し込みをする際に用いられる技術に関する。

限られた数の会議室を共同で利用するための会議室予約システムや、インターネットを利用した商品購入システム（例えば、特許文献１参照）では、会議室予約や商品購入の申し込みをユーザから受け付ける必要がある。たとえば、一般的な会議室予約システムでは、サーバ上で一元管理している会議室予約情報をクライアント端末から検索することができる。ユーザは、利用したい日時に空室の会議室があれば、その会議室について予約の申し込みをすることができる。
特開２００１−３４４４７８号公報

ところで、社長用応接室は社長が優先して利用できるようにしたい等、会議室によっては、その利用者に優先順位をつけたい場合がある。しかしながら、従来の会議室予約システムによると、どの会議室でも早い者勝ちで誰でも予約できてしまうという課題がある。

このような課題を解決するために、会議室ごとに利用者を制限することも考えられる。しかしながら、社長が社長用応接室を利用していない間は一般社員等に社長用応接室を利用させてもよい場合があり、一律に会議室ごとに利用者を制限することは妥当でない。

このように、会議室予約システムにおいては、容易に予約されることは避けたいが、一律に何らかの制限を課すことも避けたいという事情がある。しかし、従来の会議室予約システムには、このような要望にこたえる仕組みが存在しない。

もっとも、このような仕組みが必要なのは会議室予約システムだけではない。たとえば、インターネットを利用した商品購入システムにおいて、商品購入の申し込みがあったときも、容易に購入されることは避けたいが、一律に何らかの制限を課すことも避けたい場合がある。

本発明は、前記課題を解決するものであって、ユーザから申し込みを受け付ける際に、その申し込み内容に応じて手続きを変更することが可能な受付装置を提供することを目的とする。

前記目的を達成するために、本発明に係る受付装置は、ユーザから申し込みを受け付ける装置であって、申し込み対象物の属性と申し込み手続きの複雑度とを対応付けた対応テーブルを取得するテーブル取得手段と、申し込み対象物の属性を取得する属性取得手段と、前記テーブル取得手段によって取得された対応テーブルから、前記属性取得手段によって取得された申し込み対象物の属性に対応する複雑度を判定する判定手段と、前記判定手段によって判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認手段と、前記確認手段によって申し込みの意思が確認されたときに当該申し込みを受け付ける受付手段とを備えることを特徴とする。これによって、ユーザから申し込みを受け付ける際に、申し込み対象物の属性に応じて手続きを簡略化したり複雑化したりすることが可能となる。

具体的には、前記確認手段は、前記判定手段によって判定された複雑度が高いほど、申し込みをすることについて、より強い意志をユーザに求める。これによって、複雑度が高い申し込み手続ほど、ユーザは、より強い意志で申し込みをすることになるので、安易な申し込みがされることを防止することができる。

たとえば、前記確認手段は、前記判定手段によって判定された複雑度が高いほど、より多い回数で申し込みの意思をユーザに確認するようにしてもよい。これによって、複雑度が高い申し込み手続ほど、ユーザは、より多くの回数で申し込みの意思表示をすることになるので、安易な申し込みがされることを防止することができる。

ここで、前記対応テーブルは、重要度が高い申し込み対象物ほど、複雑度が高い申し込み手続を対応付けている。これによって、ユーザから申し込みを受け付ける際に、申し込み対象物の重要度に応じて手続きを簡略化したり複雑化したりすることが可能となる。

又は、前記対応テーブルは、申し込み対象物の属性とユーザの属性との組み合わせ毎に、申し込み手続きの複雑度を対応付けるようにし、前記属性取得手段は、申し込み対象物の属性とユーザの属性とを取得するようにし、前記判定手段は、前記テーブル取得手段によって取得された対応テーブルから、前記属性取得手段によって取得された申し込み対象物の属性とユーザの属性との組み合わせに対応する複雑度を判定するようにしてもよい。これによって、ユーザから申し込みを受け付ける際に、申し込み対象物の属性とユーザの属性との組み合わせに応じて手続きを簡略化したり複雑化したりすることが可能となる。

この場合、前記対応テーブルは、申し込み対象物の属性とユーザの属性との組み合わせで決まる重要度が高いほど、複雑度が高い申し込み手続を対応付けている。これによって、ユーザから申し込みを受け付ける際に、申し込み対象物の属性とユーザの属性との組み合わせで決まる重要度に応じて手続きを簡略化したり複雑化したりすることが可能となる。

また、本発明に係る受付装置は、ユーザから申し込みを受け付ける装置であって、申し込み対象物の属性と申し込み手続きの複雑度とを対応付けて記憶する対応記憶手段と、申し込み対象物の属性を取得する属性取得手段と、前記属性取得手段によって取得された申し込み対象物の属性に基づいて、前記対応記憶手段から前記申し込み対象物の属性に対応する複雑度を判定する判定手段と、前記判定手段によって判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認手段と、前記確認手段によって申し込みの意思が確認されたときに当該申し込みを受け付ける受付手段とを備えることを特徴とする。この構成によっても、前記と同様、ユーザから申し込みを受け付ける際に、申し込み対象物の属性に応じて手続きを簡略化したり複雑化したりすることが可能となる。

なお、本発明は、このような受付装置として実現することができるだけでなく、このような受付装置が備える特徴的な手段をステップとする受付方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。

以上のように、本発明に係る受付装置によれば、申し込み対象物の属性に応じて、申し込み手続きを簡略化したり複雑化したりすることができる。これによって、申し込み対象物の重要度が高いほど、申し込みをすることについて、より強い意志をユーザに求めることが可能となる。

また、本発明に係る受付装置によれば、申し込み対象物の属性とユーザの属性との組み合わせに応じて、申し込み手続きを簡略化したり複雑化したりすることができる。これによって、申し込み対象物の属性とユーザの属性との組み合わせで決まる重要度が高いほど、申し込みをすることについて、より強い意志をユーザに求めることが可能となる。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

（実施の形態１）
図１は、本発明を適用した会議室予約システムのハードウェア構成図である。図１に示されるように、本会議室予約システムは、サーバ（受付装置）１０と、このサーバ１０とネットワーク３０を介して接続された複数の端末２１〜２３等とからなる。ネットワーク３０の種類は特に限定されるものではない。

図２は、サーバ１０の概略機能ブロック図である。図２に示されるように、サーバ１０は、複雑度ＤＢ（database）１１と、対象物ＤＢ１２と、予約ＤＢ１３と、複雑度管理部１４と、対象物管理部１５と、予約手続き部１６と、通信部１７とを備えている。

複雑度管理部１４は、複雑度ＤＢ１１を管理するためのプログラム等である。システム管理者は、この複雑度管理部１４を介して複雑度ＤＢ１１を操作することができる。システム管理者とは、ここでは本会議室予約システムの管理者をいう。図３は、複雑度ＤＢ１１を操作する際の画面例を示す図である。ここでは、「複雑」「標準」「簡略」のそれぞれについて、０以上の整数を設定することができるようになっている。

対象物管理部１５は、対象物ＤＢ１２を管理するためのプログラム等である。対象物管理者は、この対象物管理部１５を介して対象物ＤＢ１２を操作することができる。対象物管理者とは、ここでは予約対象物である会議室の管理者をいう。図４は、対象物ＤＢ１２を操作する際の画面例を示す図である。ここでは、社長用応接室、特別会議室、一般会議室のそれぞれについて、「複雑」「標準」「簡略」のうちのいずれかを選択することができるようになっている。

予約手続き部１６は、予約ＤＢ１３を管理するためのプログラム等である。本会議室予約システムの一般利用者（以下「ユーザ」という）は、この予約手続き部１６を介して予約ＤＢ１３を操作することができる。ユーザとは、ここでは会議室の予約をする者をいい、一般社員であるか社長であるか等、その者の属性は問わない。ユーザが予約ＤＢ１３を操作するために必要となる画面例については後述する。

通信部１７は、端末２１等と通信を行うための通信ボード等である。
図５は、前記予約手続き部１６の詳細機能ブロック図である。図５に示されるように、予約手続き部１６は、機能的には、確認回数特定部１６１と複雑度判定部１６２と予約部１６３と画面生成部１６４と受信部１６５と送信部１６６とを有する。

確認回数特定部１６１は、複雑度ＤＢ１１を参照することによって、確認回数（後述する）を特定する。複雑度判定部（判定手段）１６２は、対象物ＤＢ１２を参照することによって、予約手続きの複雑度（後述する）を判定する。予約部１６３は、予約ＤＢ１３を参照することによって予約状況を確認するとともに、端末２１等からの予約情報を予約ＤＢ１３に設定する。

受信部（属性取得手段）１６５は、端末２１等から情報を受信する。端末２１等から受信する情報としては、たとえば、予約対象物である会議室の属性やユーザの属性等がある。ここでいう会議室の属性とは「社長用応接室」「特別会議室」「一般会議室」などの種別であり、また、ユーザの属性とは「社長」「一般社員」などの種別である。

画面生成部（確認手段）１６４は、端末２１等に表示される予約画面情報を生成する。画面生成部１６４によって生成される画面には、従来の会議室予約システムと同様の予約画面のほか、ユーザに会議室予約の申し込みの意思を確認する画面が含まれる（後述する）。

送信部１６６は、端末２１等へ予約画面情報を送信する。
図６（Ａ）は、複雑度ＤＢ１１の内部構成例を示す図である。図６（Ａ）に示されるように、複雑度ＤＢ１１は、「複雑度コード」「複雑度名」「確認回数」の各フィールドを備えている。「複雑度コード」フィールドには、「０１」「０２」「０３」など、複雑度を識別するための数字列が設定される。「複雑度名」フィールドには、「簡略」「標準」「複雑」など、予約手続きの複雑度名が設定される。「確認回数」フィールドには、ユーザに会議室予約の申し込みの意思を確認する回数が設定される（図３参照）。

ここでは、先頭レコードには、複雑度コードとして「０１」、複雑度名として「簡略」、確認回数として「０」が設定されている。２番目のレコードには、複雑度コードとして「０２」、複雑度名として「標準」、確認回数として「１」が設定されている。３番目のレコードには、複雑度コードとして「０３」、複雑度名として「複雑」、確認回数として「２」が設定されている。

すなわち、「簡略」とは、ユーザに会議室予約の申し込みの意思を確認する回数が０回であることを意味する。また、「標準」とは、ユーザに会議室予約の申し込みの意思を確認する回数が１回であることを意味する。さらに、「複雑」とは、ユーザに会議室予約の申し込みの意思を確認する回数が２回であることを意味する。

図６（Ｂ）は、対象物ＤＢ１２の内部構成例を示す図である。図６（Ｂ）に示されるように、対象物ＤＢ１２は、「対象物コード」「対象物名」「複雑度」の各フィールドを備えている。「対象物コード」フィールドには、「０１」「０２」「０３」など、対象物を識別するための数字列が設定される。「対象物名」フィールドには、「社長用応接室」「特別会議室」「一般会議室」など、予約対象物（会議室）の名称が設定される。「複雑度」フィールドには、「複雑」「標準」「簡略」など、予約手続きの複雑度が設定される（図４参照）。

ここでは、先頭レコードには、対象物コードとして「０１」、対象物名として「社長用応接室」、複雑度として「複雑」が設定されている。２番目のレコードには、対象物コードとして「０２」、対象物名として「特別会議室」、複雑度として「標準」が設定されている。３番目のレコードには、対象物コードとして「０３」、対象物名として「一般会議室」、複雑度として「簡略」が設定されている。

すなわち、社長用応接室を予約する手続きの複雑度は「複雑」とする旨が設定されている。また、特別会議室を予約する手続きの複雑度は「標準」とする旨が設定されている。さらに、一般会議室を予約する手続きの複雑度は「簡略」とする旨が設定されている。

図６（Ｃ）は、予約ＤＢ１３の内部構成例を示す図である。図６（Ｃ）に示されるように、予約ＤＢ１３は、「予約コード」「対象物」「開始日時」「終了日時」の各フィールドを備えている。「予約コード」フィールドには、「０００００１」「０００００２」など、予約を識別するための数字列が設定される。「対象物」フィールドには、「社長用応接室」「特別会議室」「一般会議室」など、予約対象物（会議室）の名称が設定される。「開始日時」フィールドには、「２００４年１１月２４日１３時００分」など、会議室の利用開始日時が設定される。「終了日時」フィールドには、「２００４年１１月２４日１４時３０分」など、会議室の利用終了日時が設定される。

ここでは、先頭レコードには、予約コードとして「０００００１」、対象物として「社長応接室」、開始日時として「２００４年１１月２４日１３時００分」、終了日時として「２００４年１１月２４日１４時３０分」が設定されている。２番目のレコードには、予約コードとして「０００００２」、対象物として「一般会議室」、開始時刻として「２００４年１１月２４日１４時００分」、終了時刻として「２００４年１１月２４日１７時００分」が設定されている。

すなわち、２００４年１１月２４日１３時００分から２００４年１１月２４日１４時３０分まで社長応接室が予約されていることを表している。また、２００４年１１月２４日１４時００分から２００４年１１月２４日１７時００分まで一般会議室が予約されていることを表している。

図７は、本会議室予約システムの動作を示すフローチャートであり、図８は、端末２１に表示される予約画面の遷移図である。以下、図７及び図８を用いて、社長用応接室を一般社員が予約する場合の動作について説明する。

まず、端末２１には、図８（Ａ）に示されるように、利用日時指定欄Ｅ１と利用会議室選択欄Ｅ２とを含む予約画面Ｓが表示される（Ｓ１）。ここでは、会議室の利用開始日時として「２００４年１１月２４日１３時００分」が、また、利用終了日時として「２００４年１１月２４日１４時３０分」が指定され、さらに、利用したい会議室として「社長用応接室」が選択されたものと仮定する（Ｓ２）。

この状態で、予約画面Ｓに含まれる予約ボタンがクリックされると、利用日時指定欄Ｅ１で指定された情報と利用会議室選択欄Ｅ２で選択された情報（以下、一括して「予約情報」という）が端末２１からサーバ１０に送信され、サーバ１０の受信部１６５に受信された後、予約部１６３に渡される。

予約部１６３は、予約ＤＢ１３を参照し、２００４年１１月２４日１３時００分から２００４年１１月２４日１４時３０分まで社長用応接室が空室であるかどうか、すなわち予約可能かどうかを確認する（Ｓ３）。そして、予約可能であることが確認できると（Ｓ３でＹＥＳ）、その旨を複雑度判定部１６２に通知する。

複雑度判定部１６２は、対象物ＤＢ１２を参照し、社長用応接室に対応する複雑度を判定する。そして、このように判定した複雑度を確認回数特定部１６１に通知する。

確認回数特定部１６１は、複雑度ＤＢ１１を参照し、この複雑度に対応する確認回数を特定する。そして、このように特定した確認回数を画面生成部１６４に通知する。

ここでは、図６（Ｂ）に示されるように、社長用応接室に対応する複雑度は「複雑」であり、また、図６（Ａ）に示されるように、この複雑度に対応する確認回数は「２」である。したがって、この場合は、以下に説明するように、ユーザに会議室予約の申し込みの意思を２回確認するようになっている（Ｓ４）。

まず、画面生成部１６４は、ユーザに会議室予約の申し込みの意思を確認するための画面情報を生成して送信部１６６に渡す。送信部１６６は、この画面情報を通信部１７を介して端末２１に送信する。

これによって、端末２１の予約画面Ｓには、図８（Ｂ）に示されるように、「予約登録してよろしいですか？」という確認メッセージが表示される。ここで、ユーザは、予約登録をしてよいと判断した場合にはＯＫボタンをクリックし、一方、予約登録をキャンセルする判断をした場合にはキャンセルボタンをクリックする。

このようにＯＫボタンがクリックされると、その旨が端末２１からサーバ１０に送信され、サーバ１０の画面生成部１６４に通知される。これによって、画面生成部１６４は、前記と同様、ユーザに会議室予約の申し込みの意思を確認するための画面情報を生成して送信部１６６に渡す。送信部１６６は、この画面情報を通信部１７を介して端末２１に送信する。

これによって、端末２１の予約画面Ｓには、図８（Ｃ）に示されるように、「本当によろしいですか？」という確認メッセージが表示される。ここで、ユーザは、本当に予約登録をしてよいと判断した場合にはＯＫボタンをクリックし、一方、予約登録をキャンセルする判断をした場合にはキャンセルボタンをクリックする。

このようにＯＫボタンがクリックされると、その旨が端末２１からサーバ１０に送信され、サーバ１０の予約部１６３に通知される。この通知を受けた予約部１６３は、図６（Ｃ）に示されるように、予約コード「０００００１」を付して当該予約情報を予約ＤＢ（受け付け手段）１３に登録した後、その旨を画面生成部１６４に通知する。この通知を受けた画面生成部１６４は、予約が完了した旨の画面情報を生成して送信部１６６に渡す。これによって、端末２１の予約画面Ｓには、図８（Ｄ）に示されるように、「予約が完了しました」というメッセージが表示される（Ｓ５）。

次に、図７及び図９を用いて、特別会議室を一般社員が予約する場合の動作について説明する。なお、ここでは、前記社長用応接室を一般社員が予約する場合の動作と同じ部分については詳しい説明を省略する。

まず、端末２１には、図９（Ａ）に示されるように、利用日時指定欄Ｅ１と利用会議室選択欄Ｅ２とを含む予約画面Ｓが表示される（Ｓ１）。ここでは、会議室の利用開始日時として「２００４年１１月２４日１３時００分」が、また、利用終了日時として「２００４年１１月２４日１４時３０分」が指定され、さらに、利用したい会議室として「特別会議室」が選択されたものと仮定する（Ｓ２）。

この状態で、予約画面Ｓに含まれる予約ボタンがクリックされると、予約情報が端末２１からサーバ１０の予約部１６３に渡される。予約部１６３は、２００４年１１月２４日１３時００分から２００４年１１月２４日１４時３０分まで特別会議室が空室であるかどうか、すなわち予約可能かどうかを確認する（Ｓ３）。そして、予約可能であることが確認できると（Ｓ３でＹＥＳ）、その旨を複雑度判定部１６２に通知する。この通知を受けた複雑度判定部１６２は、特別会議室に対応する複雑度を判定して確認回数特定部１６１に通知する。この通知を受けた確認回数特定部１６１は、この複雑度に対応する確認回数を特定する。

ここでは、図６（Ｂ）に示されるように、特別会議室に対応する複雑度は「標準」であり、また、図６（Ａ）に示されるように、この複雑度に対応する確認回数は「１」である。したがって、この場合は、以下に説明するように、ユーザに会議室予約の申し込みの意思を１回確認するようになっている（Ｓ４）。

すなわち、端末２１の予約画面Ｓには、図９（Ｂ）に示されるように、「予約登録してよろしいですか？」という確認メッセージが表示される。ここで、ＯＫボタンがクリックされると、その旨が端末２１からサーバ１０の予約部１６３に通知される。この通知を受けた予約部１６３は、当該予約情報を予約ＤＢ１３に登録した後、その旨を画面生成部１６４に通知する。この通知を受けた画面生成部１６４は、予約が完了した旨の画面情報を生成して送信部１６６に渡す。これによって、端末２１の予約画面Ｓには、図９（Ｃ）に示されるように、「予約が完了しました」というメッセージが表示される（Ｓ５）。

次に、図７及び図１０を用いて、一般会議室を一般社員が予約する場合の動作について説明する。なお、ここでは、前記社長用応接室を一般社員が予約する場合の動作と同じ部分については詳しい説明を省略する。

まず、端末２１には、図１０（Ａ）に示されるように、利用日時指定欄Ｅ１と利用会議室選択欄Ｅ２とを含む予約画面Ｓが表示される（Ｓ１）。ここでは、会議室の利用開始日時として「２００４年１１月２４日１３時００分」が、また、利用終了日時として「２００４年１１月２４日１４時３０分」が指定され、さらに、利用したい会議室として「一般会議室」が選択されたものと仮定する（Ｓ２）。

この状態で、予約画面Ｓに含まれる予約ボタンがクリックされると、予約情報が端末２１からサーバ１０の予約部１６３に渡される。予約部１６３は、２００４年１１月２４日１３時００分から２００４年１１月２４日１４時３０分まで一般会議室が空室であるかどうか、すなわち予約可能かどうかを確認する（Ｓ３）。そして、予約可能であることが確認できると（Ｓ３でＹＥＳ）、その旨を複雑度判定部１６２に通知する。この通知を受けた複雑度判定部１６２は、一般会議室に対応する複雑度を判定して確認回数判定部１６１に通知する。この通知を受けた確認回数特定部１６１は、この複雑度に対応する確認回数を特定する。 ここでは、図６（Ｂ）に示されるように、一般会議室に対応する複雑度は「簡略」であり、また、図６（Ａ）に示されるように、この複雑度に対応する確認回数は「０」である。したがって、この場合は、ユーザに会議室予約の申し込みの意思を確認しない（Ｓ４）。

すなわち、予約部１６３は、当該予約情報を予約ＤＢ１３に登録した後、その旨を画面生成部１６４に通知する。この通知を受けた画面生成部１６４は、予約が完了した旨の画面情報を生成して送信部１６６に渡す。これによって、端末２１の予約画面Ｓには、図１０（Ｂ）に示されるように、「予約が完了しました」というメッセージが表示される（Ｓ５）。

このように、本発明では、社長用応接室予約の申し込みを受け付けたときは、ユーザに会議室予約の申し込みの意思を２回確認する。また、特別会議室予約の申し込みを受け付けたときは、ユーザに会議室予約の申し込みの意思を１回確認する。さらに、一般会議室予約の申し込みを受け付けたときは、ユーザに会議室予約の申し込みの意思を確認しない。

以上のように、本実施の形態によれば、予約対象物である会議室の属性に応じて、予約手続きを簡略化したり複雑化したりすることができる。これによって、より重要度の高い会議室を予約する場合ほど、予約の申し込みをすることについて、より強い意志をユーザに求めることが可能となる。

なお、ここでは、ユーザに会議室予約の申し込みの意思を確認する最多回数を２回としているが、この確認回数は、前記したように複雑度ＤＢ１１を操作することによって変更することができる。同様に、複雑度は「複雑」「標準」「簡略」の３段階としているが、３段階以外の複雑度を複雑度ＤＢ１１に設定するようにしてもよい。

また、ここでは、会議室予約システムに本発明を適用した構成を例示したが、ユーザから何らかの申し込みを受け付ける必要があるシステムである以上、本発明を適用することができる。たとえば、オンラインで寄付を募る寄付システムに本発明を適用してもよい。この場合は、寄付金額が高額になるほど、申し込み手続きを複雑化するのが望ましい。同様に、オンラインでローンを申し込む場合や、有料コンテンツの視聴を申し込む場合にも、その申し込み金額が高額になるほど、申し込み手続きを複雑化するのが望ましい。

さらに、ここでは、一般社員が会議室を予約する場面を例示して説明したため、社長用応接室予約の申し込みを受け付けたときは、ユーザに会議室予約の申し込みの意思を２回確認することとしている。しかしながら、社長が社長用応接室を予約する場合は、ユーザに会議室予約の申し込みの意思を確認しない構成を採用するのが望ましい。ユーザが一般社員であるか社長であるかは、本システムにログインするためのユーザＩＤによって識別することができる。ユーザＩＤやそれに対応付けされた情報（以下「ユーザの属性」という）を用いる構成については、次の実施の形態２で詳しく説明する。

なお、ここでは、複雑度ＤＢ１１、対象物ＤＢ１２、予約ＤＢ１３をサーバ１０内に備えた構成を例示したが、本発明はこれに限定されるものではない。すなわち、これらのＤＢは外部装置に備えることとし、必要に応じて、この外部装置からＤＢの情報を取得するテーブル取得手段をサーバ１０に備える構成としても、前記と同様の効果を得ることができる。

（実施の形態２）
前記実施の形態１では、申し込み対象物の属性のみに基づいて、申し込み手続きの複雑度を決定する。それに対して、本実施の形態２では、申し込み対象物の属性とユーザの属性との組み合わせに基づいて、申し込み手続きの複雑度を決定する。

以下、ローン申し込みシステムに本発明を適用した構成を例に説明する。
まず、本システムのハードウェア構成は、前記実施の形態１と同様である。すなわち、図１に示されるように、サーバ（受付装置）１０と、このサーバ１０とネットワーク３０を介して接続された複数の端末２１〜２３等とからなる。

図１１は、本実施の形態２におけるサーバ１０の概略機能ブロック図である。図１１に示されるように、サーバ１０は、複雑度ＤＢ１１ａと、対象物ＤＢ１２ａと、実績ＤＢ１８と、ローンＤＢ１３ａと、複雑度管理部１４ａと、対象物管理部１５ａと、実績管理部１９と、ローン手続き部１６ａと、通信部１７とを備えている。ここで、複雑度ＤＢ１１ａと、複雑度管理部１４ａと、対象物管理部１５ａと、通信部１７の機能は前記実施の形態１と同じである。また、ローンＤＢ１３ａについては、設定される情報がローンに関する情報である点を除き、予約ＤＢ１３と同じである。以下、実績ＤＢ１８、実績管理部１９、ローン手続き部１６ａ、対象物ＤＢ１２ａについて説明する。

図１２（Ａ）は、実績ＤＢ１８の内部構成例を示す図である。図１２（Ａ）に示されるように、実績ＤＢ１８は、「ユーザＩＤ」「実績」の各フィールドを備えている。「ユーザＩＤ」フィールドには、「０００１」「０００２」「０００３」など、ユーザを識別するための数字列が設定される。「実績」フィールドには、「良」「普通」「不良」など、ローン返済の実績が設定される。

実績管理部１９は、実績ＤＢ１８を管理するためのプログラム等である。システム管理者は、この実績管理部１９を介して実績ＤＢ１８を操作することができる。図１２（Ｂ）は、実績ＤＢ１８を操作する際の画面例を示す図である。ここでは、ユーザＩＤごとに、「良」「普通」「不良」のうちのいずれかを選択することができるようになっている。

図１３は、ローン手続き部１６ａの詳細機能ブロック図である。図１３に示されるように、ローン手続き部１６ａは、機能的には、確認回数特定部１６１ａと複雑度判定部１６２ａと実績特定部１６７とローン部１６３ａと画面生成部１６４ａと受信部１６５ａと送信部１６６ａとを有する。ローン部１６３ａと実績特定部１６７と複雑度判定部１６２ａ以外の各部の機能は前記実施の形態１と同じである。

ローン部１６３ａは、ローンＤＢ１３ａを参照することによってローン状況を確認するとともに、端末２１等からのローン情報をローンＤＢ１３ａに設定する。実績特定部１６７は、実績ＤＢ１８を参照することによってローン返済の実績を特定し、その結果を複雑度判定部１６２ａに通知する。複雑度判定部１６２ａは、実績特定部１６７から通知された実績を考慮して対象物ＤＢ１２ａを参照することによって、ローン手続きの複雑度を判定する。

図１４は、対象物ＤＢ１２ａの内部構成例を示す図である。図１４に示されるように、対象物ＤＢ１２ａは、「対象物コード」「対象物名」「実績」「複雑度」の各フィールドを備えている。「対象物コード」フィールドには、「０１」「０２」「０３」など、申し込み対象物を識別するための数字列が設定される。「対象物名」フィールドには、「高額」「通常」「低額」など、申し込み対象物（ローン）の名称が設定される。「実績」フィールドには、「良」「普通」「不良」など、ローン返済の実績が設定される。「複雑度」フィールドには、「複雑」「標準」「簡略」など、ローン手続きの複雑度が設定される。すなわち、対象物名「高額」「通常」「低額」と実績「良」「普通」「不良」との組み合わせ毎に、複雑度「複雑」「標準」「簡略」が設定される。

ここでは、対象物名が「高額」で実績が「不良」の場合、複雑度は「複雑」とする旨が設定されている。これによって、ローン返済の実績が悪いユーザ（ユーザＩＤ：０００３）が高額ローンを申し込んだときは、ユーザに申し込みの意思を２回確認することになる。

また、対象物名が「高額」で実績が「良」の場合、複雑度は「標準」とする旨が設定されている。これによって、ローン返済の実績が良いユーザ（ユーザＩＤ：０００１）が高額ローンを申し込んだときは、ユーザに申し込みの意思を１回確認することになる。

さらに、対象物名が「低額」で実績が「良」の場合、複雑度は「簡略」とする旨が設定されている。これによって、ローン返済の実績が良いユーザ（ユーザＩＤ：０００１）が低額ローンを申し込んだときは、ユーザに申し込みの意思を確認しないことになる。

以上のように、本実施の形態では、申し込み対象物の属性とユーザの属性との組み合わせに応じて、申し込み手続きを簡略化したり複雑化したりすることができる。これによって、申し込み対象物の属性とユーザの属性との組み合わせで決まる重要度が高いほど、申し込みをすることについて、より強い意志をユーザに求めることが可能となる。

なお、ここでは、ユーザの属性として「ローン返済の実績」を例示したが、ユーザの属性として採用する情報はこれに限定されるものではない。たとえば、ユーザの属性として「ローン申し込み者の年齢」を採用すれば、若年層の申し込み者に対して、ローン申し込みの意思を多数回確認することが可能となる。また、有料コンテンツ視聴の申し込みを受け付けるシステムに本発明を適用した場合は、ユーザの属性として「コンテンツ視聴の申し込み実績」を採用してもよい。この場合は、たとえば、「コンテンツ視聴の申し込み実績」から個々のユーザの好みを分析して幾つかのタイプに分類しておく。そして、コンテンツ視聴の申し込みがあったときは、そのコンテンツが当該ユーザの好みのタイプであるかどうかを判定する。このようにすれば、好みのタイプでないことが判明した場合には、「当コンテンツはお客様の好みとは違うように思いますが、よろしいですか？」等の確認メッセージを表示することが可能となる。

また、ここでは、申し込み手続きを簡略化したり複雑化したりする構成の一例として、ユーザに申し込みの意思を確認する回数を変更する構成を例示したが、本発明はこれに限定されるものではない。たとえば、確認画面Ｓにおいて特定のコードを入力しなければ次の確認画面Ｓが表示されないようにし、複雑度が高くなるほど、入力すべきコードを長くするようにしてもよい。あるいは、確認画面Ｓに含まれるＯＫボタンをクリックしても一定時間が経過するまでは次の確認画面Ｓが表示されないようにし、複雑度が高くなるほど、この一定時間を長くするようにしてもよい。

本発明に係る受付装置は、申し込み手続きを簡略化したり複雑化したりすることが必要な会議室予約システム、ローン申し込みシステム、商品購入システム等の用途に適用できる。

本発明を適用した会議室予約システムのハードウェア構成図である。 サーバ（受付装置）の概略機能ブロック図である。 複雑度ＤＢを操作する際の画面例を示す図である。 対象物ＤＢを操作する際の画面例を示す図である。 予約手続き部の詳細機能ブロック図である。 複雑度ＤＢ・対象物ＤＢ・予約ＤＢの内部構成例を示す図である。 本発明を適用した会議室予約システムの動作を示すフローチャートである。 社長用応接室を予約する際に端末に表示される画面の遷移図である。 特別会議室を予約する際に端末に表示される画面の遷移図である。 一般会議室を予約する際に端末に表示される画面の遷移図である。 実施の形態２におけるサーバの概略機能ブロック図である。 実績ＤＢの内部構成例と、実績ＤＢを操作する際の画面例を示す図である。 ローン手続き部の詳細機能ブロック図である。 実施の形態２における対象物ＤＢの内部構成例を示す図である。

符号の説明

１０ サーバ（受付装置）
１１ 複雑度ＤＢ
１２ 対象物ＤＢ
１３ 予約ＤＢ（受付手段）
１４ 手続き管理部
１５ 対象物管理部
１６ 予約手続き部
１７ 通信部
１６１ 確認回数特定部
１６２ 複雑度判定部（判定手段）
１６３ 予約部
１６４ 画面生成部（確認手段）
１６５ 受信部（属性取得手段）
１６６ 送信部

Claims (9)

1. ユーザから申し込みを受け付ける装置であって、
   申し込み対象物の属性と申し込み手続きの複雑度とを対応付けた対応テーブルを取得するテーブル取得手段と、
   申し込み対象物の属性を取得する属性取得手段と、
   前記テーブル取得手段によって取得された対応テーブルから、前記属性取得手段によって取得された申し込み対象物の属性に対応する複雑度を判定する判定手段と、
   前記判定手段によって判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認手段と、
   前記確認手段によって申し込みの意思が確認されたときに当該申し込みを受け付ける受付手段と
   を備えることを特徴とする受付装置。
2. 前記確認手段は、前記判定手段によって判定された複雑度が高いほど、申し込みをすることについて、より強い意志をユーザに求める
   ことを特徴とする請求項１記載の受付装置。
3. 前記確認手段は、前記判定手段によって判定された複雑度が高いほど、より多い回数で申し込みの意思をユーザに確認する
   ことを特徴とする請求項２記載の受付装置。
4. 前記対応テーブルは、重要度が高い申し込み対象物ほど、複雑度が高い申し込み手続を対応付けている
   ことを特徴とする請求項１記載の受付装置。
5. 前記対応テーブルは、申し込み対象物の属性とユーザの属性との組み合わせ毎に、申し込み手続きの複雑度を対応付けており、
   前記属性取得手段は、申し込み対象物の属性とユーザの属性とを取得し、
   前記判定手段は、前記テーブル取得手段によって取得された対応テーブルから、前記属性取得手段によって取得された申し込み対象物の属性とユーザの属性との組み合わせに対応する複雑度を判定する
   ことを特徴とする請求項１記載の受付装置。
6. 前記対応テーブルは、申し込み対象物の属性とユーザの属性との組み合わせで決まる重要度が高いほど、複雑度が高い申し込み手続を対応付けている
   ことを特徴とする請求項５記載の受付装置。
7. ユーザから申し込みを受け付ける装置であって、
   申し込み対象物の属性と申し込み手続きの複雑度とを対応付けて記憶する対応記憶手段と、
   申し込み対象物の属性を取得する属性取得手段と、
   前記属性取得手段によって取得された申し込み対象物の属性に基づいて、前記対応記憶手段から前記申し込み対象物の属性に対応する複雑度を判定する判定手段と、
   前記判定手段によって判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認手段と、
   前記確認手段によって申し込みの意思が確認されたときに当該申し込みを受け付ける受付手段と
   を備えることを特徴とする受付装置。
8. ユーザから申し込みを受け付ける方法であって、
   申し込み対象物の属性と申し込み手続きの複雑度とを対応付けた対応テーブルを取得するテーブル取得ステップと、
   申し込み対象物の属性を取得する属性取得ステップと、
   前記テーブル取得ステップにおいて取得された対応テーブルから、前記属性取得ステップにおいて取得された申し込み対象物の属性に対応する複雑度を判定する判定ステップと、
   前記判定ステップにおいて判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認ステップと、
   前記確認ステップにおいて申し込みの意思が確認されたときに当該申し込みを受け付ける受付ステップと
   を含むことを特徴とする受付方法。
9. ユーザから申し込みを受け付けるためのプログラムであって、
   申し込み対象物の属性と申し込み手続きの複雑度とを対応付けた対応テーブルを取得するテーブル取得ステップと、
   申し込み対象物の属性を取得する属性取得ステップと、
   前記テーブル取得ステップにおいて取得された対応テーブルから、前記属性取得ステップにおいて取得された申し込み対象物の属性に対応する複雑度を判定する判定ステップと、
   前記判定ステップにおいて判定された複雑度に応じた態様で、申し込みの意思をユーザに確認する確認ステップと、
   前記確認ステップにおいて申し込みの意思が確認されたときに当該申し込みを受け付ける受付ステップと
   をコンピュータに実行させるためのプログラム。

Images