【事件の表示】
　平成１１年特許願第１２０６６５号「リモートブランチシステム」拒絶査定不服審判事件〔平成１２年１１月　７日出願公開、特開２０００−３１１２０７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１１年４月２７日の出願であって、平成１６年５月２４日付けで拒絶理由通知がされ、これに対し、同年７月２３日付けで意見書及び手続補正書が提出されたものの、同年８月３１日付けで拒絶査定がされ、これに対し、同年１０月７日に拒絶査定に対する審判請求がなされ、同年１０月２９日付けで手続補正書が提出されたものである。
　
２．平成１６年１０月２９日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　　平成１６年１０月２９日付けの手続補正を却下する。
　
［理由］
（１）平成１６年１０月２９日付けの手続補正の内容
　平成１６年１０月２９日付けで提出された手続補正書による手続補正（以下、「本件補正」という。）は、特許請求の範囲の記載を以下のように補正し、併せて発明の詳細な説明の欄の関連する記載を補正するものである。
　
【請求項１】　顧客が操作する複数の顧客端末と、
　前記顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末と、
　センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えたリモートブランチシステムにおいて、
　運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け、
　前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブルと、顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とするリモートブランチシステム。
　
（２）本件補正前の特許請求の範囲の記載
　本件補正前（平成１６年７月２３日付け手続補正書により補正された）の特許請求の範囲の記載は、以下のとおりである。
　
【請求項１】　顧客が操作する複数の顧客端末と、
　前記顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末と、
　センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えたリモートブランチシステムにおいて、
　どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブルと、顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とするリモートブランチシステム。
　
（３）本件補正についての検討
　本件補正は、特許請求の範囲についての補正を含み、その内容は補正前の請求項１に記載された「センタ端末」が、「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」たものであることを限定する記載を付加すると共に、補正前の請求項１に記載された「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」を、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」であると限定するものであり、当該請求項に記載した発明を特定するために必要な事項を限定するものであって、本件補正の前後で当該請求項に記載された発明の産業上の利用分野及び解決しようとする課題を変更するものではないから、本件補正の目的は、特許法第１７条の２第４項第２号（特許請求の範囲の減縮）に該当する。なお、本件補正の目的が、特許法第１７条の２第４項第１号（請求項の削除）、第３号（誤記の訂正）、第４号（明りょうでない記載の釈明）に該当しないことは明らかである。
　そこで、本件補正後における特許請求の範囲の前記請求項１に記載されている事項により特定される発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（４）引用例
（引用例１）
　原査定の拒絶の理由に引用された特開平１０−２５４８３１号公報（平成１０年９月２５日出願公開、以下「引用例１」という。）には、図面と共に、以下の事項が記載されている。
（Ａ）【０００１】〜【００５２】段落
「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、複数端末の制御方法に関し、特に無人自動契約受付システムにおける複数端末の制御方法に関するものである。
【０００２】
【従来の技術】近年、消費者金融業界において、無人自動契約受付システムが、マルチメディア時代の新しいサービスとして利用者から高い評価を受けている。その理由として、高機能でユーザフレンドリな操作性や、プライバシーにも配慮していることなどが挙げられる。また、金融会社側も大きな店舗を持たなくても、ホストと通信することにより契約が可能なため、無人自動契約受付専門の小さな店を出店するだけで顧客を獲得することが可能なことや、人件費の節約などの利点があり、無人自動契約受付システムの需要はますます高まると考えられる。
【０００３】無人自動契約受付システムは、一般的には、顧客が操作する端末（顧客端末）と社員が操作する端末（センター端末）から構成されている。ここで、センター端末は、以下のような目的で使用される。
(1)顧客端末のスキャナで読み込んだ申込書等を、センター端末に転送してそれを表示し、記入不備がないか、正しく読み込んでいるかをオペレータが目視でチェックする。
(2)顧客端末のスキャナで読み込んだ免許証の写真と、顧客端末のカメラから本人の映像とを照合し、本人であるかをオペレータが確認する。
(3)審査結果をオペレータが入力する。
【０００４】一方、顧客端末とセンター端末の接続形態としては、以下の形態がある。
(1)顧客端末とセンター端末を同一の支店内に設置し、相互の接続を行う。
(2)無人店舗のような離れた場所に顧客端末を設置して、通信回線を利用してセンター端末と接続する。
(3)地区センター等で一括して審査業務を行うように場合、地区センターにセンター端末をまとめて配置し、通信回線を利用して顧客端末と接続する。
【０００５】
【発明が解決しようとする課題】これら接続形態(1)〜(3)のうち、例えば接続形態(3)を採る無人自動契約受付システムの場合は、一般に、地区センターに顧客端末に対応したセンター端末が設置される。ここで、センター端末が１台の顧客端末しか接続できない場合には顧客端末の台数分のセンター端末が必要であり、センター端末がｎ台分の顧客端末を接続できるなら、（顧客端末の台数−１）／ｎ＋１台の台数のセンター端末が必要になる。
【０００６】しかしながら、上述した従来の接続形態の場合には、センター側の端末台数が多く必要になるので、ハードウェアの導入コストが高くなるとともに、設置スペースも問題となり、また複数台の端末と複数台のセンター端末との接続関係が固定的にならざるを得ないことから、来客があった顧客端末がそれに対応してバラバラにセンター端末に接続されることになるため、センター端末のオペレータの運用が煩雑になり、しかもセンター端末がハード障害などで使用不能になった場合に、対応する顧客端末も使用不能になってしまうという問題があった。
【０００７】本発明は、上記課題に鑑みてなされたものであり、その目的とするところは、ハードウェアの導入コストの低減および設置スペースの削減を可能とするとともに、複数台の端末と複数台のセンター端末の接続に際して効率的な接続を実現する複数端末の制御方法を提供することにある。
【０００８】
【課題を解決するための手段】本発明による複数端末の制御方法は、複数台の端末に対して複数台のセンター端末を設けるとともに、これら複数台のセンター端末の運用を管理する管理端末を設け、複数台の端末の各々と複数台のセンター端末の各々との接続に際し、複数台の端末が各々の接続先を管理端末に対して問い合わせる一方、管理端末が接続先の問い合わせがあった端末に対してその接続先を複数台のセンター端末の運用状況に基づいて割り当てるようにする。
【０００９】
【発明の実施の形態】以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。
【００１０】図１は、本発明に係る無人自動契約受付システムのシステム構成図である。図１において、本システムは、地区センターに設置された管理端末（以下、運用サーバーと称する）１および複数台（本例では、２台）のセンター端末２-1，２-2と、地区センターから離れた支店に設置されたｎ台の顧客端末３-1，３-2，…，３-nとからなり、運用サーバー１やセンター端末２-1，２-2と顧客端末３-1，３-2，…，３-nとが通信回線４を利用して接続された構成となっている。
【００１１】運用サーバー１は、例えばパーソナルコンピュータ（以下、パソコンと略称する）からなる制御装置１１と、ディスプレイ１２とから構成されている。センター端末２-1，２-2は、例えばパソコンからなる制御装置２１と、ディスプレイ２２と、例えば４台のマルチメディア通信装置２３-1〜２３-4とから構成されている。そして、運用サーバー１とセンター端末２-1，２-2、さらにはセンター端末２-1，２-2の各々における制御装置２１とマルチメディア通信装置２３-1〜２３-4は、例えばＬＡＮ(local area network)５を通して互いに通信が可能となっている。
【００１２】一方、顧客端末３-1，３-2，…，３-nの各々は、例えばパソコンからなる制御装置３１およびマルチメディア通信装置３２からなり、制御装置３１とマルチメディア通信装置３２とが例えばＬＡＮ６-1，６-2，…，６-nを介して互いに通信が可能な構成となっている。顧客端末３-1〜３-nの各々にはさらに、図示しないが、顧客を映すカメラや、通話のためのハンドセット（送受話器）が装備されている。ここで、顧客端末３-1，３-2，…，３-nはそれぞれＡ支店，Ｂ支店，…，Ｘ支店に設置されたものとする。
【００１３】なお、地区センター側のＬＡＮ５と通信回線４との間には、Ａ支店用，Ｂ支店用，…，Ｘ支店用のルーター７-1，７-2，…，７-nが介在している。同様に、支店側のＬＡＮ６-1，６-2，…，６-nの各々と通信回線４との間には、ルーター８-1，８-2，…，８-nが介在している。
【００１４】上記構成の無人自動契約受付システムにおいて、センター端末２-1，２-2は、起動されると運用サーバー１に対して開局した旨の通知を行う。このとき、センター端末２-1，２-2は各々、何台の顧客端末と接続可能な構成であるかも併せて通知する。ここで、何台の顧客端末と接続可能であるかは、マルチメディア通信装置の台数によって決まる。本例の場合には、センター端末２-1，２-2はいずれも４台の顧客端末と接続可能な構成となっている。
【００１５】また、顧客端末３-1，３-2，…，３-nの各制御装置３１から運用サーバー１の制御装置１１に対して接続先の問い合わせが行われる（図中、(1)の経路）。これに対し、運用サーバー１の制御装置１１から顧客端末３-1，３-2，…，３-nの各制御装置３１へは接続先の通知が行われる（図中、(2)の経路）。また、入力データやスキャナで読み取ったデータ等の一般的なデータの通信は、センター端末２-1，２-2の各制御装置２１と顧客端末３-1，３-2，…，３-nの各制御装置３１の間で行われる（図中、(3)の経路）。
【００１６】次に、上記構成の無人自動契約受付システムを実際に運用する場合の具体的な実施例について説明する。
【００１７】〔実施例１〕この実施例１では、顧客端末３-1，３-2，…，３-nの各制御装置３１からの接続先の問い合わせに対し、運用サーバー１の制御装置１１は複数台（本例では、２台）のセンター端末２-1，２-2のうち１台目のセンター端末２-1から空いている順に接続先を割り当てる構成を採っている。
【００１８】この実施例１に係る無人自動契約受付システムにおいて、契約受付に際して、センター端末２-1，２-2側と顧客端末３-1〜３-n側の各マルチメディア通信装置間の通信を確立するまでの運用サーバー１および顧客端末３-1〜３-nの各処理手順について、図２のフローチャートにしたがって説明する。
【００１９】先ず、顧客端末３-1〜３-n側の処理手順を示す図２（Ａ）のフローチャートにおいて、顧客端末３-1〜３-nの各制御装置３１は、常時、各顧客端末３-1〜３-nに備え付けられている感知センサ等によって来客の有無を監視し（ステップＳ１１）、来客が有ると、その旨を端末の名称やアドレス等の情報と共に運用サーバー１に通知し、接続すべきセンター端末のアドレスを問い合わせる（ステップＳ１２）。そして、運用サーバー１からの返信を待つ（ステップＳ１３）。
【００２０】運用サーバー１から返信があると、先ず、その受信データがセンター端末のアドレス情報であるか否かを判断し（ステップＳ１４）、アドレス情報の受信でない場合には、運用サーバー１から接続先がない旨の情報が返信されたものとし、例えば「しばらくお待ちください。」なるメッセージを表示し（ステップＳ１５）、顧客を待機させる。そして、センター端末のリソースが空くのを一定時間待ち（ステップＳ１６）、一定時間経過したら、ステップＳ１２に戻って再度運用サーバー１に対して接続先の問い合わせを行う。
【００２１】ステップＳ１４において、アドレス情報の受信の場合には、このアドレスを基にセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる（ステップＳ１７）。そして、センター端末から通知されたアドレスを基に自分のマルチメディア通信装置３２に対して、センター端末で指定されたマルチメディア通信装置との接続コマンドを発行し、マルチメディア通信装置間の通信を確立する（ステップＳ１８）。
【００２２】次に、運用サーバー１側の処理手順を示す図２（Ｂ）のフローチャートにおいて、運用サーバー１の制御装置１１は、常時、顧客端末３-1〜３-n側からのマルチメディア通信装置のアドレスの問い合わせを待ち（ステップＳ２１）、その問い合わせがあると、常時管理している複数台のセンター端末の運用状況を参照する（ステップＳ２２）。そして、１台目のセンター端末から空きがないかを順に調べ（ステップＳ２３，Ｓ２４）、空きが無い場合には、接続先がない旨を顧客端末３-1〜３-n側に返信する（ステップＳ２５）。
【００２３】一方、ステップＳ２３において、空いているセンター端末があると判定した場合には、その空いているセンター端末のリソース（本例では、ディスプレイ２２の表示領域やマルチメディア通信装置２３-1〜２３-4のような、接続する顧客端末ごとに必要な資源）をリザーブし（ステップＳ２６）、顧客端末３-1〜３-n側に対して接続先のセンター端末のアドレスを通知する（ステップＳ２７）。
【００２４】上述した一連の処理シーケンスを図３に示す。ここで、この処理シーケンス図を参照しつつ、例えばＡ支店に来客があった場合を例に採って、一連の処理の流れについて説明する。なお、本例では、運用サーバー１の運用管理の対象は、２台のセンター端末２-1，２-2とする。
【００２５】先ず、Ａ支店に来客があり、顧客端末３-1に備え付けの感知センサ等がこれを検知すると、顧客端末３-1はその旨を運用サーバー１に通知する。このとき、顧客端末３-1の名称やアドレス等の情報を送信するとともに、センター端末２-1，２-2の何れと接続すれば良いかを問い合わせる。この問い合わせに対して、運用サーバー１は、常時管理しているセンター端末２-1，２-2の運用状況に基づいてどちらかに空きがないかを順に調べる。
【００２６】このときに、センター端末２-1，２-2のいずれも空いていなければ、顧客端末３-1に対してその旨の情報（接続先なし）を返信する。すると、これを受けて顧客端末３-1は、例えば「しばらくお待ちください。」なるメッセージを表示し、センター端末が空くのを待つ。このメッセージの表示により、顧客は待機中である旨を把握でき、不必要な入力操作などを行うことがない。そして、一定時間経過した後、再度運用サーバー１に対して接続先の問い合わせを行う。
【００２７】一方、センター端末２-1，２-2のどちらかが空いている場合には、運用サーバー１はその空いているセンター端末のリソース（本例では、ディスプレイ２２の表示領域やマルチメディア通信装置２３-1〜２３-4のような、接続する顧客端末ごとに必要な資源）をリザーブし、顧客端末３-1に対して接続先のセンター端末のアドレスを通知する。
【００２８】これを受けて顧客端末３-1側では、運用サーバー１で指定されたセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる。その後、自分のマルチメディア通信装置に対して、センター端末から指定されたマルチメディア通信装置との接続コマンドを発行する。以上の一連の処理により、指定されたセンター端末側と顧客端末３-1側のマルチメディア通信装置間の通信が確立する。
【００２９】なお、顧客端末３-1が運用サーバー１に対して接続先の問い合わせを行った際に、運用サーバー１が他の顧客端末と通信中であるなどによって運用サーバー１と通信できない場合には、あらかじめ顧客端末３-1に登録されているセンター端末に接続するようにすることで、顧客端末３-1の待機時間を少なくできる。センター端末側では、顧客端末からの接続開始時および接続終了時にその旨の通知を運用サーバー１に対して行う。これにより、運用サーバー１は、センター端末２-1，２-2の運用状況を把握する。
【００３０】センター端末側と顧客端末側間の通信が確立すると、顧客端末３-1側からは、スキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどが通信回線４を通して通信先のセンター端末に送信され、センター端末側からは審査結果などが顧客端末３-1に対して返信されることで、契約のための諸手続きが行われる。
【００３１】顧客端末３-2，…，３-nについても、顧客端末３-1の場合と同様に、来客があった場合に、運用サーバー１に対して接続先の問い合わせを行い、これを受けて運用サーバー１ではセンター端末の運用状況を調べ、１台目のセンター端末から空いている順に接続先を割り当て、これを受けて顧客端末３-2，…，３-nでは、割り当てられた接続先のセンター端末との接続を行う処理が行われる。
【００３２】このように、実施例１に係る無人自動契約受付システムでは、運用サーバー１を設置し、この運用サーバー１によって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、センター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができる。
【００３３】また、センター端末を１台目から空いている順に割り当てるようにしたことにより、顧客が少ない場合は、センターのオペレータが少人数で済み、顧客が増えてきたら、それに対応してオペレータの人数を増やせば良いため、時間帯や曜日などで顧客の数が増減が多い場合など、顧客の数に合わせてセンター端末のオペレータを増減するような場合に有用なものとなる。
【００３４】〔実施例２〕この実施例２では、顧客端末３-1，３-2，…，３-nの各制御装置３１からの接続先の問い合わせに対し、運用サーバー１の制御装置１１は複数台（本例では、２台）のセンター端末２-1，２-2のうち運用頻度の低いものから順番に接続先を割り当てる構成を採っている。
【００３５】この実施例２に係る無人自動契約受付システムにおいて、契約受付に際して、センター端末２-1，２-2側と顧客端末３-1〜３-n側の各マルチメディア通信装置間の通信を確立するまでの運用サーバー１および顧客端末３-1〜３-nの処理手順について、図４のフローチャートにしたがって説明する。
【００３６】先ず、顧客端末３-1〜３-n側の処理手順を示す図４（Ａ）のフローチャートにおいて、顧客端末３-1〜３-nの各制御装置３１は、常時、各顧客端末３-1〜３-nに備え付けられている感知センサ等によって来客の有無を監視し（ステップＳ３１）、来客が有ると、その旨を端末の名称やアドレス等の情報と共に運用サーバー１に通知し、接続すべきセンター端末のアドレスを問い合わせる（ステップＳ３２）。そして、運用サーバー１からの返信を待つ（ステップＳ３３）。
【００３７】運用サーバー１から返信があると、先ず、その受信データがセンター端末のアドレス情報であるか否かを判断し（ステップＳ３４）、アドレス情報の受信でない場合には、運用サーバー１から接続先がない旨の情報が返信されたものとし、例えば「しばらくお待ちください。」なるメッセージを表示し（ステップＳ３５）、顧客を待機させる。そして、センター端末のリソースが空くのを一定時間待ち（ステップＳ３６）、一定時間経過したら、ステップＳ３２に戻って再度運用サーバー１に対して接続先の問い合わせを行う。
【００３８】ステップＳ３４において、アドレス情報の受信の場合には、このアドレスを基にセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる（ステップＳ３７）。そして、センター端末から通知されたアドレスを基に自分のマルチメディア通信装置３２に対して、センター端末で指定されたマルチメディア通信装置との接続コマンドを発行し、マルチメディア通信装置間の通信を確立する（ステップＳ３８）。
【００３９】次に、運用サーバー１側の処理手順を示す図４（Ｂ）のフローチャートにおいて、運用サーバー１の制御装置１１は、常時、顧客端末３-1〜３-n側からのマルチメディア通信装置のアドレスの問い合わせを待ち（ステップＳ４１）、その問い合わせがあると、常時管理している複数台のセンター端末の運用状況を参照する（ステップＳ４２）。そして、先ず、センター端末に空きがあるか否かを全てのセンター端末に対して調べ（ステップＳ４３）、空きが無い場合には、接続先がない旨を顧客端末３-1〜３-n側に返信する（ステップＳ４４）。
【００４０】一方、ステップＳ４３において、空いているセンター端末があると判定した場合には、各端末の運用頻度、例えば全てのセンター端末について接続中の顧客端末数を調べ、接続中の顧客端末数が一番少ないセンター端末のリソース（本例では、ディスプレイ２２の表示領域やマルチメディア通信装置２３-1〜２３-4のような、接続する顧客端末ごとに必要な資源）をリザーブし（ステップＳ４５）、顧客端末３-1〜３-n側に対して接続先のセンター端末のアドレスを通知する（ステップＳ４６）。
【００４１】上述した一連の処理シーケンスを図５に示す。ここで、この処理シーケンス図を参照しつつ、例えばＡ支店に来客があった場合を例に採って、一連の処理の流れについて説明する。なお、本例においても、運用サーバー１の運用管理の対象は、２台のセンター端末２-1，２-2とする。
【００４２】先ず、Ａ支店に来客があり、顧客端末３-1に備え付けの感知センサ等がこれを検知すると、顧客端末３-1はその旨を運用サーバー１に通知する。このとき、顧客端末３-1の名称やアドレス等の情報を送信するとともに、センター端末２-1，２-2の何れと接続すれば良いかを問い合わせる。この問い合わせに対して、運用サーバー１は、常時管理しているセンター端末２-1，２-2の運用状況に基づいて各端末の運用頻度、例えば全てのセンター端末について接続中の顧客端末数を調べる。
【００４３】このときに、センター端末２-1，２-2のいずれも空いていなければ、顧客端末３-1に対してその旨の情報（接続先なし）を返信する。すると、これを受けて顧客端末３-1は、例えば「しばらくお待ちください。」なるメッセージを表示し、センター端末が空くのを待つ。このメッセージの表示により、顧客は待機中である旨を把握でき、不必要な入力操作などを行うことがない。そして、一定時間経過した後、再度運用サーバー１に対して接続先の問い合わせを行う。
【００４４】一方、センター端末２-1，２-2のどちらかが空いている場合は、接続中の顧客端末数が一番少ないセンター端末を選択し、そのセンター端末のリソース（本例では、ディスプレイ２２の表示領域やマルチメディア通信装置２３-1〜２３-4のような、接続する顧客端末ごとに必要な資源）をリザーブし、顧客端末３-1に対して接続先のセンター端末のマルチメディア通信装置のアドレスを通知する。
【００４５】これを受けて顧客端末３-1側では、運用サーバー１で指定されたセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる。その後、自分のマルチメディア通信装置に対して、センター端末から指定されたマルチメディア通信装置との接続コマンドを発行する。以上の一連の処理により、指定されたセンター端末側と顧客端末側のマルチメディア通信装置間の通信が確立する。
【００４６】なお、顧客端末３-1が運用サーバー１に対して接続先の問い合わせを行った際に、運用サーバー１が他の顧客端末と通信中であるなどによって運用サーバー１と通信できない場合には、あらかじめ顧客端末３-1に登録されているセンター端末に接続するようにすることで、顧客端末３-1の待機時間を少なくできる。センター端末側では、顧客端末からの接続開始時および接続終了時にその旨の通知を運用サーバー１に対して行う。これにより、運用サーバー１は、センター端末２-1，２-2の運用状況を把握する。
【００４７】センター端末側と顧客端末側間の通信が確立すると、顧客端末３-1側からは、スキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどが通信回線４を通して通信先のセンター端末に送信され、センター端末側からは審査結果などが顧客端末３-1に対して返信されることで、契約のための諸手続きが行われる。
【００４８】顧客端末３-2，…，３-nについても、顧客端末３-1の場合と同様に、来客があった場合に、運用サーバー１に対して接続先の問い合わせを行い、これを受けて運用サーバー１では全てのセンター端末について接続中の顧客端末数を調べ、接続中の顧客端末数の一番少ないセンター端末を選択して接続先を割り当て、これを受けて顧客端末３-2，…，３-nでは、割り当てられた接続先のセンター端末との接続を行う処理が行われる。
【００４９】このように、実施例２に係る無人自動契約受付システムでは、実施例１の場合と同様に、運用サーバー１を設置し、この運用サーバー１によって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、センター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができる。
【００５０】また、センター端末を接続中の顧客端末数の少ないものから順に割り当てるようにしたことにより、使用可能なセンター端末に対して顧客端末が均等に割り当てられることになるため、センター端末のオペレータの人数が固定の場合に、オペレータの負荷が偏らず、各オペレータの負荷を均等にすることができる利点がある。
【００５１】なお、上記実施形態では、無人自動契約受付システムにおける複数台の顧客端末の制御に適用した場合について説明したが、本発明は、無人自動契約受付システムへの適用に限定されるものではなく、１台のセンター端末で複数の端末を制御する構成のシステム全般に適用可能である。
【００５２】
【発明の効果】以上詳細に説明したように、本発明によれば、運用サーバーを設置し、この運用サーバーによって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、あるセンター端末がハード障害などで使用不能になっても他のセンター端末で対応でき、しかもセンター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができるため、ハードウェアの導入コストの低減と設置スペースの削減が可能となる。」
　
　そうしてみると、引用例１には、以下の発明（以下、「引用例１記載の発明」という。）が開示されていると認められる。
「顧客が操作する複数の顧客端末と、
　前記顧客端末と接続して該顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどを受信し、審査結果などを該顧客端末に対して返信することで、契約のための諸手続きを行う複数のセンタ端末と、
　センタ端末に接続する顧客端末を振り分ける運用サーバー（管理端末）とを備えた無人自動契約受付システムにおいて、
　起動時に開局した旨の通知と併せて、何台の顧客端末と接続可能な構成であるかを前記運用サーバー（管理端末）に通知する機能を各センタ端末に設け、
　顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段を前記運用サーバー（管理端末）に備えたことを特徴とする無人自動契約受付システム」
　
（引用例２）
　また、原査定の拒絶の理由に引用された、中島　周、安藤史郎、「セルフサービス金融端末への共同作業技術の応用」、電子情報通信学会誌、日本、社団法人電子情報通信学会、１９９８年３月２５日、第８１巻、第３号、第２５９−２６５頁（以下「引用例２」という。）には、図と共に、以下の事項が記載されている。
（Ｂ）第２６３頁左欄第３６行〜第２６５頁左欄第１７行
「　４．  非対称共同作業
　同期対面型の共同作業の技術はほとんどが対称的なハードウェア・ソフトウェア構成を有し，使用者から見たユーザインタフェース・機能も全く同じである． しかし，３．で説明したような金融端末における共同作業には種々の非対称性がある．まず，顧客と専門家のそれぞれの作業内容が異なっでいる．例えば顧客側では契約申込処理のプログラムが実行され，専門家端末には顧客からのデータの審査，外部データベースへの照会，自社データベースへの登録などが実行される．顧客端末には図４のようにセンサ，プリンタ，スキャナ，無停止電源など種々の周辺機器がついているが，専門家端末はごく少数のものだけである．また，コンピュータへの習熟度の差から，顧客端末では全画面のタッチパネルで操作されるユーザインタフェースが提供されるが，専門家端末はウィンドウシステムを使ったＧＵＩが使われる．もともと金融端末は人に邪魔されずに一人で利用していたので，顧客は専門家との過度の対話は好まない．しかし，専門家は契約処理の場合，顧客を慎重に観察する必要がある．
　このような種々の非対称性を損なわずに共同作業技術を導入するには以下のような方策が必要となる．
（１）共同作業で会議機能を提供するプログラムは閉じた会議システムではなく，外部から詳細な制御ができるようなミドルウェアとして実現する． これによつてそのミドルウェア上で異なるアプリケーション同士が通信しながらステップによっては同期をとりながら稼動するシステムが実現できる．
（２）会議機能を実現する個々のプロダラム自身が非対称性を実現できる機能をもつ．例えば，顧客と専門家で文書データの共有表示・編集を行う共有黒板プログラムがウィンドウのタイトルバーなどの個々の要素の表示・非表示などのユーザインタフェースを作業者ごとに変えられること，共同編集機能が作業者ごとに操作できる機能範囲が変更できること，顧客からの接続時には空いている専門家が自動的に選択されて接続されることなどである．
（３）そして前述の二つの方策を前提として，システム全体で非対面同期型の新しい共同作業を実現して，専門家の負荷を減らす．
　非対面同期型の例として，書類の記入とその遠隔での確認・訂正指示の処理を図５によって説明する．
　まずブランクの書類が印刷され，顧客はそれに手書きでデータを記入する．その後その書類はスキャナで読み取られ，イメージデータが専門家端末に送られる．このとき，専門家はそのイメージデータを見て書類の内容を審査する．しかし，このときに未記入や書き間違いなどによって書類訂正の作業が必要となる．記入ミスの種類のほとんどは決まっており，その数は数種類である．専門家は記入ミスを見つけると，事前に分類されたミスの種類を選び，イメージデータに注釈を加えてから共有化する．すると，顧客端末には，それぞれのミスに対応した修正手続きの内容が注釈つきのイメージデータと共に表示される．専門家は１方向のビデオ会議機能で顧客の様子を観察しているが，顧客側には専門家の動画像も音声も送られない．もし人間同士の対話が必要な複雑な訂正処理の場合は，双方向のビデオ会議機能を使用する．双方向のビデオ会議機能を使わない通常の訂正処理では，顧客からはあたかも顧客端末という機械が書類のミスを見つけ，注釈をつけてその訂正方法を指示しているようにみえる．この方法は，顧客が不必要に専門家との対話による干渉を受けず，また専門家も短時間で書類訂正を指示できるという長所をもっている．つまり，実際は機械と人間とで書類内容の遠隔訂正を実現しているのだが，顧客には自分のインタフェースである機械しか見えていない．これは，いままでにない非対面同期型の共同作業と位置づけることもできる，新しい形態の共同作業である． これはまた，机上の検討ではなく，現実の契約業務の分析とその業務のコンピュータシステムによる実装から発見されたことに意義がある．」
　
（引用例３）
　同じく、原査定の拒絶の理由に引用された特開平５−２９８２５０号公報（平成５年１１月１２日出願公開、以下「引用例３」という。）には、図面と共に、以下の事項が記載されている。
（Ｃ）【０００７】〜【００１７】段落
「【０００７】
【実施例】次に、本発明の実施例について図面を参照して説明する。
【０００８】図１は本発明のマルチホストシステムの一実施例を示すブロック図である。
【０００９】本実施例のマルチホストシステムは、図１に示すように、Ａ業務１１からＧ業務１７までの７つの業務がホスト１からホスト４までの４台のホストコンピュータに存在しているマルチホストシステムで、特定のホストコンピュータであるホスト１には、業務とそれに対応するホストコンピュータ情報とを記憶している業務・ホスト対応テーブル７と、端末５の要求に応答して業務・ホスト対応テーブル７にアクセスし対応ホストコンピュータ情報を読み出す業務・ホスト認識部６と、このホストコンピュータ情報の供給に応答してこれを端末に通知する接続ホスト情報通知部８を備えている。
【００１０】一方、端末５には、希望する業務に対応するホストコンピュータ情報を要求するホストコンピュータ情報要求部１０とホスト１からのホストコンピュータ情報の供給に応答してそのホストコンピュータに接続するホスト接続部９とを備えている。
【００１１】図２には、業務・ホスト対応テーブル７の記憶内容の一例を示している。接続対象業務に対してその名称と、それの存在するホスト名、そのホストのネットワークアドレスが記憶されている。
【００１２】図１および図２を参照して、端末５がホスト３に存在するＥ業務１５を利用する場合についての本実施例の動作について説明する。
【００１３】端末５は、ホスト１に接続し、ホストコンピュータ情報要求部１０により接続対象業務名であるＥ業務１５の名称をホスト１に送り接続すべきホストコンピュータの情報を要求する。
【００１４】ホスト１の業務・ホスト認識部６はこの端末５の要求の受信に応答して、受信した接続対象業務名をもとに業務・ホスト対応テーブル７を参照し対応する接続ホストコンピュータ情報、すなわち、接続ホスト名である「ホスト３」、そのネットワークアドレスである「０００３」および接続対象業務名である「Ｅ」を読み出し接続ホスト情報通知部８に供給する。接続ホスト情報通知部８は業務・ホスト認識部６から供給された接続ホストコンピュータ情報を端末５に送信する。
【００１５】端末５はホスト１から供給された接続ホストコンピュータ情報にもとづいてホスト接続部９によりホスト３に端末５を接続して希望の業務であるＥ業務１５を実行することができる。
【００１６】このようにして本実施例ではホスト１に業務・ホスト対応テーブル７を設けることによりシステム構成の変更等に際してはこれのみを変更するだけで対応でき融通性に富んだシステムを構成でき、かつ、誤操作を減少できるという効果を有している。
【００１７】
【発明の効果】以上説明したように、本発明のマルチホストシステムは、特定のホストコンピュータに業務とホストコンピュータとの対応情報を記憶し、一元管理を行なうことにより、システム変更に際しても融通性を増大させ、かつ、誤操作を少なくできるという効果を有している。」
　
（引用例４）
　また、特開平１０−５１５５０号公報（平成１０年２月２０日出願公開、以下、「引用例４」という。）には、図面と共に、以下の事項が記載されている。
（Ｄ）【００１７】〜【００５３】段落
「【００１７】
【発明の実施の形態】図１は、本発明が適用されるシステム構成を示す。本発明は、同図に示すように、カスタマ２０、企業システム１０から構成され、企業システム１０の一つであるカスタマ２０から受け付けた問い合わせを担当者２００に引き継ぐための受付応対システム１００を有する。
【００１８】受付応対システム１００は、図２に示すように、カスタマ２０からの電話による受付を行うサーバ１２０、当該サーバ１２０により参照されるファイル群を管理するファイル管理システム１３０、サーバ１２０により接続先の担当者に対して音声情報を転送する交換機１１０、当該交換機１１０から担当者２００に対して音声情報を転送する企業内電話回線（以下、内線と記す）１５０及び、サーバ１２０から転送される画像情報を取得すると共に、内線１５０により音声情報を受信する担当者用端末装置２１０より構成される。
【００１９】図３は、本発明のサーバの構成を示す。同図に示すサーバ１２０は、入力部１２１、表示部１２２、検索部１２３、担当者決定部１２４、情報転送部１２５及びタイマ１２６から構成される。入力部１２１は、受付オペレータからの指示入力及び問い合わせを行っている顧客の識別情報を入力する。
【００２０】表示部１２２は、入力部１２１から入力された情報及び、検索１２３により検索された結果等を表示する。検索部１２３は、入力部１２１から入力された情報に基づいてファイル管理システム内１３０のファイルを検索し、当該検索結果を表示部１２２に表示する。担当者決定部１２４は、検索部１２３により検索された検索結果から所定の条件に合致する担当者を決定する。決定条件としては、カスタマの問い合わせ内容を担当し、所定のレベルを備え、現時点において応対可能である要件が必要となる。
【００２１】情報転送部１２５は、受付オペレータが内線１５０を介して音声により問い合わせ内容等の概要を出力するための音声出力部（図示せず）とＬＡＮ１４０を介して、カスタマ情報、タイマ１２６により計測されている経過時間等の情報を転送する画面情報転送部（図示せず）から構成される。タイマ１２６は、カスタマからの問い合わせを受け付けた時刻から経過した時間を計測する。
【００２２】図４は、本発明のファイル管理システムを示す。サーバ１２０の検索部１２３において、検索対象となるファイル群は、応対履歴情報ファイル１３１、顧客情報ファイル１３２、担当者情報ファイル１３３、及び各種業務ファイル１３４より構成される。応対履歴情報ファイル１３１は、カスタマの問い合わせ及び担当者の応答履歴が管理されるファイルであり、図５に示すように、受付番号、受付日時、顧客番号、質問区分、受付内容、回答内容、完了日付／時刻、受付担当者コード、回答担当者コード、回答結果等が設定される。
【００２３】顧客情報ファイル１３２は、顧客毎の情報を管理するファイルであり、図６に示すように、顧客番号、顧客名、電話番号、住所、顧客種別等が設定されている。担当者情報ファイル１３３は、担当者毎の情報を管理するファイルであり、図７に示すように、担当者コード、担当者名、内線番号、部署コード、部署名、スキルレベル、使用端末ＩＤ、担当者状態ａ、担当者状態ｂ等が設定される。担当者状態ａは、担当者のスケジュール情報を日付により管理しており、担当者状態ｂは、応対可能、離席等の現時点の担当者の状態を表している。例えば、担当者が離席する場合に、離席を意味する情報をＬＡＮ１５０を介して入力することにより、当該項目の内容が“応対可能”から“離席”に変更される。
【００２４】各種業務情報ファイル１３４は、種々の業務内容が格納されているファイルであり、受付オペレータや応答する担当者により必要に応じて参照される情報が格納される。以下に、上記の構成に基づいた本発明の動作の概要を説明する。図８は、本発明の一連の動作のフローチャートである。
【００２５】ステップ１０１）  受付オペレータは、カスタマからの問い合わせを受け付けると、サーバ１２０の入力部１２０からカスタマから聴取した顧客番号を入力する。これにより、タイマ１２６が起動される。
ステップ１０２）  入力された顧客番号に基づいて検索部１２３は、応対履歴情報ファイル１３１を検索して、カスタマ履歴情報を取得し、表示部１２２に転送する。
【００２６】ステップ１０３）  表示部１２２は、検索部１２３から取得した検索結果としてカスタマ履歴情報を表示する。
ステップ１０４）  受付オペレータは、表示部１２２に表示されたカスタマ履歴情報を参照して、カスタマから聴取した問い合わせ内容に対応する業務名または、質問区分等を入力する。これにより、検索部１２３は、受付オペレータにより指定された業務名または、質問区分に基づいて担当者情報ファイル１３３を検索する。このとき、受付オペレータが特定の業務名または、質問区分を入力できない場合に、曖昧な検索条件を入力した場合であっても曖昧検索による方法、または、エキスパートシステムを介在させることにより担当者情報ファイル１３３へのアクセスを許容するものとする。
【００２７】更に、担当者決定部１２４は、検索された結果において、所定の応答レベルに達している担当者（例えば、レベル３以上）であり、かつ、応対履歴情報ファイル１３１の回答結果を参照して、前回同一カスタマに対して回答の成果があったか否かを判定し、さらに、担当者情報ファイル１３３の担当者状態ｂのデータを参照して、現時点において、応答可能な担当者を選択する。複数の候補がある場合には、複数の担当者を表示部１２２に転送する。
【００２８】ステップ１０５）  検索部１２３が担当者情報ファイル１３３を検索した結果である応答可能な担当者のを表示部１２２に表示する。
ステップ１０６）  受付オペレータは、表示部１２２に表示された担当者を指定し、表示されている担当者の内線番号にダイヤルする。担当者の候補が複数存在する場合には、最適であると考えられる担当者を任意に指定し、内線１５０を介して音声情報により当該担当者に問い合わせの概要等を伝える。
【００２９】ステップ１０７）  情報転送部１２５は、指定された担当者の端末ＩＤを宛先としてＬＡＮ１４０を介して、経過時間を含む顧客情報及び顧客履歴情報等必要な情報を転送する。また、このとき、サーバ１２０は、受付オペレータのコード及び受付日付／時刻を応対履歴情報ファイル１３１に反映させる。
ステップ１０８）  担当者は、端末から現時点において応対が可能であるかを否かの応答を返却する。応答が不可能な場合には、上記のステップ１０４に移行する。
【００３０】ステップ１０９）  指定した担当者の応対が可能な場合には、内線１４０を用いて交換機１１０を介してカスタマに応対する。
ステップ１１０）  担当者は、カスタマに対する応対が終了すると、ＬＡＮ１４０を介して自担当者コード、完了日付／時刻、及び回答内容、回答結果等を入力する。これにより、サーバ１２０は、当該入力内容を応対履歴情報ファイル１３１に反映する。
【００３１】
【実施例】以下、本発明の実施例を図面と共に説明する。以下の実施例では、カスタマから商品に対するクレームが発生した場合の処理を説明する。第１の実施例として、カスタマが以前に問い合わせを行っている（顧客履歴情報あり）場合の処理を説明し、第２の実施例として、新規のカスタマ（顧客履歴情報なし）からの問い合わせの場合の処理を説明する。
【００３２】［第１の実施例］本実施例の動作を図８のフローチャートに基づいて説明する。
（１）  カスタマ（顧客番号００１）から受付オペレータがクレームの電話を受け付け、受付オペレータが顧客番号“００１”入力部１２１から入力すると同時に、タイマ１２６が起動する（ステップ１０１）。
【００３３】（２）  検索部１２３は、顧客番号“００１”に基づいて顧客情報ファイル１３２及び応対履歴ファイル１３１を検索し、検索結果を担当者決定部１２４に転送する。これにより、図９に示す画面が表示部１２２に表示される。ここで、サーバ１２０は、応対履歴情報ファイル１３１に新規に応対レコードを生成し、自動的に受付番号（１０１）、受付日付・時刻（９６年６月１日）、顧客番号（００１）、質問区分（商品クレーム：０５）、受付担当者コード（Ｒ０３）をデータとして設定する。
【００３４】（３）  この表示画面に対して受付オペレータが転送先担当者リストをクリックすると、図１０に示す画面が表示される。このとき、担当者決定部１２４が予め設定されている、スキルレベル３以上、応対可能者という条件に基づいて担当者の絞り込みを行う。これにより、図１０に示すように、表示部１２２に当該カスタマに応対したキャリアを有する担当者のリストが表示される（ステップ１０３、１０４、１０５）。なお、表示部１２２に表示される担当者の順位は、所定の優先順位のカテゴリを設け、部署毎または、スキルレベル順にソートされた形で表示するようにしてもよい。
【００３５】（４）  受付オペレータは、図１０のように表示された担当者リストから任意の担当者をクリック等により選択する。また、担当者決定部１２４により、最適であると判断される（レベルが最も高い等）担当者の表示欄をブリンキング表示するように制御することも可能である。同図の例において、担当者コード“Ａ０６”の担当者ＣＣＣが選択されたものとする。
【００３６】（５）  受付オペレータは表示されている内線番号（３３５６）に電話をかけ、クレームの内容を音声により、通知する（ステップ１０６）。同時に、ＬＡＮ１４０を介して情報転送部１２５は、指定された担当者の端末ＩＤ（ＣＣＣ）に応対履歴情報及び顧客情報を転送する。また、このとき、タイマ１２６で計時しているクレームの受け付けを開始してからの時間も併せて通知する（ステップ１０７）。
【００３７】（６）  担当者（ＣＣＣ）が受付オペレータから内線を受け付け、カスタマに対する応対が可能であるか否かを告げる（ステップ１０８）。オペレータが担当者から応対が不可能である旨を通知された場合には、上記の（２）以降の処理を再度繰り返して他の担当者を同様の方法で検索する。担当者が応対が可能である場合には、図１１に示す画面を見てカスタマに対応する（ステップ１０９）。
【００３８】また、担当者用の画面の上部には、受け付けを開始してから現時点までの経過時間が併せて表示されているため、カスタマを長時間待たせている場合には、その旨を詫びる等の対応が可能となる。
（７）  担当者のカスタマの応対が終了すると、担当者は、回答内容を画面の回答内容の欄に入力する。回答内容として、この例では、『返品受け付け』のように入力する。さらに、回答を保留した場合には、回答結果欄の“保留”をクリックし、解決した場合には、“解決”をクリックする。
【００３９】（８）  担当者が入力した回答内容及び回答結果、回答が終了した日時をＬＡＮ１４０によりサーバ１２０に転送する。
（９）  サーバ１２０は、担当者の端末から転送された情報及び、回答担当者コード（Ａ０６）等を上記の（２）で生成された当該応対に対する応対履歴情報ファイル１３１の応対レコードに反映させる（ステップ１１０）。
【００４０】［第２の実施例］次に、本発明の第２の実施例として、新規のカスタマによる問い合わせがあった場合の処理を説明する。図１２は、本発明の第２の実施例の新規カスタマ応対処理のフローチャートである。以下、図１２のフローチャートに沿って処理を説明する。
【００４１】ステップ２０１）  新規のカスタマからクレームの電話を受け付ける。このとき、受付オペレータは、当該カスタマが顧客番号を保持していないことを認識すると、カスタマの氏名や電話番号を聴取して、図１３に示す画面への入力を行う。
ステップ２０２）  ステップ２０１において、受付オペレータが応対を開始すると同時にタイマ１２６が起動される。
【００４２】ステップ２０３）  問い合わせをしているカスタマが新規であるので、ステップ２０４に移行する。カスタマがリピータである場合には、前述の第１の実施例の処理を行う。
ステップ２０４）  受付オペレータは、カスタマから質問の内容を受け付ける。この例では、商品（電化製品の使用方法）の問い合わせであるものとする。受付オペレータは、質問内容の『電化製品の使用方法』を画面上の受付内容の欄に入力する。
【００４３】ステップ２０５）  検索部１２３は、“電化製品”で業務情報ファイル１３４を検索し、電化製品を扱う部署コードを取得する。
ステップ２０６）  さらに、検索部１２３は、ステップ２０５で取得した部署コードで、担当者情報ファイル１３３を検索し、当該部署の担当コードを抽出する。
【００４４】ステップ２０７）  その結果を前述の図１０に示すように転送先の担当者のリストを表示部１２２に表示する。
ステップ２０８）  受付オペレータは、表示部１２２に表示された担当者リストから当該質問内容に最適であると思われる担当者を指定入力する。このとき、担当者決定部１２４において、担当者情報ファイル１３３の担当者状態ｂを参照して現時点において応対可能な担当者のみを自動的に表示するようにしてもよい。この例では、担当者コード“Ａ０１”の担当者を指定するものとする。
【００４５】ステップ２０９）  当該カスタマの応対を行う担当者が決定すると応対履歴情報ファイル１３１に新規のレコードを生成すると共に、顧客情報ファイル１３２にも当該カスタマの新規レコードを作成する。
ステップ２１０）  受付オペレータは、内線を用いて当該担当者（Ａ０１）の内線番号（１２３４）に対して音声によりカスタマから要件を伝えると共に、ＬＡＮ１４０により顧客氏名等の情報を画面情報として担当者の端末ＩＤ（ａａａ）に送信する。
【００４６】以降の担当者の処理は、前述の第１の実施例と同様であるため、その説明を省略する。
［第３の実施例］次に、第３の実施例として、担当者情報ファイル１３３の更新の処理を説明する。本実施例における担当者情報ファイル１３３の更新は、担当者が使用する端末ＩＤや内線番号が変更になる場合、及び担当者状態ａの担当者スケジュールの更新の２つのパターンがある。
【００４７】最初に、担当者が使用する端末ＩＤと内線番号が変更になる例について説明する。担当者は、業務の開始前に図１４に示す画面より当日使用する端末から担当者コード及び内線番号を指定する。これにより、検索部１２３は、当該担当者コードか担当者情報ファイル１３３を検索して、該当するレコードを検索し、当該レコードに入力に使用された端末ＩＤと、担当者から入力された内線番号を設定して更新する。
【００４８】これにより、当日担当者が使用する端末や内線番号が変更された場合に、担当者情報ファイルの内容が当該変更に応じて更新されるため、常に受付オペレータが参照する転送先担当者リストの内容が無矛盾に表示される。次に、担当者の所定期間（週間、月間）のスケジュールの変更及び登録を行う場合について説明する。担当者のスケジュールの変更や登録を行う際には、図１５に示すように、例えば、１週間の出勤予定入力用の画面が表示される。同図において、予め土・日曜及び祭日等はカレンダ機能によりその旨が予め表示されているものとし、担当者は『出勤』『休暇』のいずれかをクリックすることにより、出勤予定の入力を行う。この情報は、担当者情報ファイル１３３の担当者状態ａに格納される。
【００４９】また、本発明は、上記の動作をプロセスとして、プログラムを構築することが可能であり、このプログラムを可搬記憶媒体に格納し、当該受付システムを実施するコンピュータにインストールすることで、当該システムを実行できる。なお、本発明は、上記の実施例に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【００５０】
【発明の効果】第１及び第７の発明によれば、カスタマの問い合わせの窓口となる受付オペレータがカスタマから問い合わせを含む連絡を受けた場合に、該問い合わせの内容に応じた担当者に転送する際に、画面上に、当該問い合わせ内容に適する担当者のリストが表示されることにより、受付オペレータは、表示されたリストから最適であると判断される担当者を選択または、最適であると決定されて表示されている担当者を指定して、確実に応対を引き継ぐことが可能となる。
【００５１】また、第２の発明によれば、受付オペレータから担当者に対してカスタマの情報を転送し、担当者の端末上の表示手段に表示することにより、担当者は、自分が有する資料等を探すことなく、スムーズにカスタマの応対可能である。また、カスタマ問い合わせ内容のニュアンス等表示手段上に表示されないような情報は、従来通り内線を用いて受付オペレータと会話できる。
【００５２】第３及び第８の発明によれば、カスタマとの応対を開始した時間が画面上に表示されるため、応対までにかなり待機させたカスタマに対しては、お詫び等のメッセージを伝えることが可能である。第４の発明によれば、カスタマからの問い合わせ時に、担当者の現在の状態を取得することにより、当該カスタマとその時点で対応が可能な担当者を決定することが可能となる。
【００５３】第５及び第９の発明によれば、担当者のレベルや、担当者の現在の状況に応じて最適な担当者を検索して、応対を引き継ぐことにより、より適切な応対が可能となる。第６及び第１０の発明によれば、担当者の内線や、端末ＩＤがリアルタイムに担当者情報に反映されるため、受付オペレータに提示される情報と実際の担当者が使用する内線番号及び端末ＩＤとの間に常に整合がとれているため、転送先に指定した担当者が存在しない等の矛盾を防ぐことが可能である。」
　
（５）対比
　そこで、本願補正発明と引用例１記載の発明とを比較すると、
ａ）引用例１記載の発明の「顧客端末と接続して該顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどを受信し、審査結果などを該顧客端末に対して返信することで、契約のための諸手続きを行う複数のセンタ端末」と、本願補正発明の「顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末」は、「顧客端末と接続して該顧客端末と所定の処理をする複数のセンタ端末」で共通し、
ｂ）引用例１記載の発明の「運用サーバー（管理端末）」は、本願補正発明の「運用管理端末」に相当し、
ｃ）引用例１記載の発明の「起動時に開局した旨の通知と併せて、何台の顧客端末と接続可能な構成であるかを前記運用サーバー（管理端末）に通知する機能を各センタ端末に設け」ることと、本願補正発明の「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」ることは、「運用開始時に業務に関する情報を前記運用管理端末に通知する登録機能を各センタ端末に設け」ることで共通し、
ｄ）引用例１記載の発明の「顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段」と、本願補正発明の「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」は、「顧客端末に対する業務が実行可能なセンタ端末を参照して選択して前記顧客端末に通知する手段」で共通し、
ｅ）引用例１記載の発明の「無人自動契約受付システム」と、本願補正発明の「リモートブランチシステム」は、以下の点で相違するものの、「無人自動契約受付のためのシステム」である点で共通していることから、本願補正発明と引用例１記載の発明は、
「顧客が操作する複数の顧客端末と、
　前記顧客端末と接続して該顧客端末と所定の処理をする複数のセンタ端末と、
　センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えた受付システムにおいて、
　運用開始時に業務に関する情報を前記運用管理端末に通知する登録機能を各センタ端末に設け、
　顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とする無人自動契約受付のためのシステム」
である点で一致し、以下の点で相違している。
　
［相違点１］
　本願補正発明は、「顧客端末と接続して該顧客端末を遠隔操作するセンタ端末」を備えた「リモートブランチシステム」であるのに対して、引用例１記載の発明は、「センタ端末」が「顧客端末を遠隔操作する」ものであるか明確でないため、「リモートブランチシステム」であるか明確でない点。
　
［相違点２］
　本願補正発明の「運用管理端末」が、「実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるのに対して、引用例１記載の発明の「運用管理端末」は、このようなセンタ端末登録テーブルを備え、このテーブルを参照してセンタ端末を選択していない点。
　
［相違点３］
　本願補正発明では、「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて」、運用管理端末のセンタ端末登録テーブルに登録するのに対して、引用例１記載の発明では、「オペレータが選択した実行可能な業務を通知する」機能をセンタ端末に設けていない点。
　
（６）当審の判断
［相違点１について］
　上記摘記事項（Ｂ）にあるように、引用例２には、非対面同期型の例として、書類の記入とその遠隔での確認・訂正指示の処理について、図５により、「・・・書類はスキャナで読み取られ，イメージデータが専門家端末に送られる．このとき，専門家はそのイメージデータを見て書類の内容を審査する．しかし，このときに未記入や書き間違いなどによって書類訂正の作業が必要となる．・・・専門家は記入ミスを見つけると，事前に分類されたミスの種類を選び，イメージデータに注釈を加えてから共有化する．すると，顧客端末には，それぞれのミスに対応した修正手続きの内容が注釈つきのイメージデータと共に表示される．・・・顧客からはあたかも顧客端末という機械が書類のミスを見つけ，注釈をつけてその訂正方法を指示しているようにみえる．この方法は，顧客が不必要に専門家との対話による干渉を受けず，また専門家も短時間で書類訂正を指示できるという長所をもっている．つまり，実際は機械と人間とで書類内容の遠隔訂正を実現しているのだが，顧客には自分のインタフェースである機械しか見えていない．」と説明されており、このような顧客端末に書類記入ミスに対応した修正手続きの内容を注釈つきのイメージデータと共に表示させる等の書類内容の遠隔訂正を実現する専門家端末における遠隔操作の手段を、引用例１記載の発明における、顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データなどを受信し、審査結果などを該顧客端末に対して返信するセンタ端末に採用して、該顧客端末を遠隔操作するセンタ端末とし、システムを無人自動契約受付のためのリモートブランチシステムとすることは、当業者が容易に成し得たものと認められる。
　したがって、相違点１に係る本願補正発明の構成は、引用例１記載の発明、引用例２記載の事項に基づいて、当業者が容易に想到し得たものである。
　
［相違点２について］
　上記摘記事項（Ｃ）にあるように、引用例３には、「接続対象業務に対してその名称と、それの存在するホスト名、そのホストのネットワークアドレスが記憶され、どのホストコンピュータでどの業務が実行可能かを書換え可能に登録する業務・ホスト対応テーブル」（００１１、００１６、００１７段落、図２）と、「端末で要求された業務が実行可能なホストコンピュータを前記業務・ホスト対応テーブルを参照し対応する接続ホストコンピュータ情報を前記端末に通知する手段」（００１２〜００１５段落）が記載されていると認められる。
　引用例３に記載された技術的手段を引用例１記載の発明に採用することに、技術的に格別の困難性は認められず、適用する際に、業務・ホスト対応テーブルの内容を、実行可能な業務をそのセンタ端末を示す識別子と対応させたものとすることは、用途変更に伴う設計変更であり、当業者が通常の創作活動の範囲内で容易に成し得たものと認められる。
　してみれば、引用例１記載の発明の運用管理端末において、「実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるようにすることは、当業者が容易に成し得たものと認められる。
　したがって、相違点２に係る本願補正発明の構成は、引用例１記載の発明、引用例３記載の事項に基づいて、当業者が容易に想到し得たものである。
　
［相違点３について］
　上記摘記事項（Ｄ）にあるように、引用例４には、実施例として、受付オペレータは、カスタマから電化製品の使用方法の問い合わせを受け付けた場合に、前記受付オペレータは、『電化製品の使用方法』を画面上の受付内容の欄に入力し、検索部は、“電化製品”で業務情報ファイルを検索し、電化製品を扱う部署コードを取得し、検索部は、取得した部署コードで、担当者情報ファイルを検索し、当該部署の担当コードを抽出する（００４２〜００４３段落）ことが記載され、更に、「担当者は、業務の開始前に図１４に示す画面より当日使用する端末から担当者コード及び内線番号を指定する。これにより、検索部１２３は、当該担当者コードか担当者情報ファイル１３３を検索して、該当するレコードを検索し、当該レコードに入力に使用された端末ＩＤと、担当者から入力された内線番号を設定して更新する。・・・担当者情報ファイルの内容が当該変更に応じて更新されるため、常に受付オペレータが参照する転送先担当者リストの内容が無矛盾に表示される。」（００４７〜００４８段落）と記載されている。
　これらの記載からみて、引用例４の受付応答システムは、業務開始前に担当者が当日使用する端末から担当者コード等を指定することにより、担当者情報ファイルの担当者コードと使用端末ＩＤとを対応させて変更登録する機能を各端末に設けているものと認められ、当該担当者が対応可能な業務（すなわち、使用端末で実行可能な業務）は、前記担当者情報ファイルに担当者コードと対応して登録されている部署コードにより自動的に決定されていると認められるものの、このような自動的に決定される内容を、単に手動化すること、すなわち、担当者が周知な入力手段を操作して、実行可能な業務を選択するようにすることは、単なる設計変更に過ぎず、自由な選択が可能となること等は手動化による自明な効果に過ぎない。
　してみれば、引用例４記載の技術的事項及び周知技術を引用例１記載の発明に適用して、運用開始時にオペレータが選択した実行可能な業務を運用管理端末に通知する登録機能を各センタ端末に設けると共に、前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す端末ＩＤ（本願補正発明の「識別子」に相当）と対応させて、顧客の要求に対応可能なセンタ端末を選択するための手段に登録するようにすることは、当業者が容易に成し得たものと認められる。
　したがって、相違点３に係る本願補正発明の構成は、引用例１記載の発明、引用例４記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものである。
　
　そして、請求項１に係る発明の作用効果も、引用例１−４及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、本願補正発明は、引用例１記載の発明、引用例２−４記載の事項及び周知技術に基づいて、当業者が容易に発明することができたものであるから、特許法２９条２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（７）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するものであるから、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
（１）本願請求項１に係る発明について
　平成１６年１０月２９日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１６年７月２３日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、上記のとおりのものである。
　
（２）引用例
　原査定の拒絶の理由に引用された引用例１−３、及びその記載事項は、前記「２．（４）」に記載したとおりである。　
　
（３）対比
　本願発明は、前記２．（１）で検討した本願補正発明から、「センタ端末」に関する限定事項である「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」との構成を省き、「センタ端末登録テーブル」に関する特定事項について、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」を「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」に上位概念化したものである。
　そうすると、本願発明と引用例１記載の発明とは、前記２．（５）に記載した点で一致し、以下の点で相違する。
　
［相違点１］
　本願発明は、「顧客端末と接続して該顧客端末を遠隔操作するセンタ端末」を備えた「リモートブランチシステム」であるのに対して、引用例１記載の発明は、「センタ端末」が「顧客端末を遠隔操作する」ものであるか明確でないため、「リモートブランチシステム」であるか明確でない点。
　
［相違点２］
　本願発明の「運用管理端末」が、「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるのに対して、引用例１記載の発明の「運用管理端末」は、このようなセンタ端末登録テーブルを備え、このテーブルを参照してセンタ端末を選択していない点。
　
（４）当審の判断
［相違点１について］
　相違点１に係る本願発明の構成は、相違点１に係る本願補正発明の構成と同一であり、前記２．（６）［相違点１について］で検討したとおり、相違点１に係る本願補正発明の構成は、引用例１記載の発明、引用例２記載の事項に基づいて、当業者が容易に想到し得たものであるから、相違点１に係る本願発明の構成も、引用例１記載の発明、引用例２記載の事項に基づいて、当業者が容易に想到し得たものである。
　
［相違点２について］
　相違点２に係る本願発明の構成である「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」は、相違点２に係る本願補正発明の構成である「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」を上位概念化したものであり、　前記２．（６）［相違点２について］で検討したとおり、相違点２に係る本願補正発明の構成は、引用例１記載の発明、引用例３記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものであるから、相違点２に係る本願発明の構成も、引用例１記載の発明、引用例３記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものである。
　
　また、本願発明の作用効果も、引用例１−３から当業者が予測できる範囲のものである。
　
　してみれば、本願発明は、引用例１記載の発明、引用例２、３記載の事項に基づいて、当業者が容易に発明することができたものである。
　
（５）むすび
　以上のとおり、本願発明は、引用例１記載の発明、引用例２、３記載の事項に基づいて、当業者が容易に発明することができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。