• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06Q
審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1186947
審判番号 不服2004-20687  
総通号数 108 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2008-12-26 
種別 拒絶査定不服の審決 
審判請求日 2004-10-07 
確定日 2008-10-30 
事件の表示 平成11年特許願第120665号「リモートブランチシステム」拒絶査定不服審判事件〔平成12年11月 7日出願公開、特開2000-311207〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成11年4月27日の出願であって、平成16年5月24日付けで拒絶理由通知がされ、これに対し、同年7月23日付けで意見書及び手続補正書が提出されたものの、同年8月31日付けで拒絶査定がされ、これに対し、同年10月7日に拒絶査定に対する審判請求がなされ、同年10月29日付けで手続補正書が提出されたものである。

2.平成16年10月29日付けの手続補正についての補正却下の決定
[補正却下の決定の結論]
平成16年10月29日付けの手続補正を却下する。

[理由]
(1)平成16年10月29日付けの手続補正の内容
平成16年10月29日付けで提出された手続補正書による手続補正(以下、「本件補正」という。)は、特許請求の範囲の記載を以下のように補正し、併せて発明の詳細な説明の欄の関連する記載を補正するものである。

【請求項1】 顧客が操作する複数の顧客端末と、
前記顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末と、
センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えたリモートブランチシステムにおいて、
運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け、
前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブルと、顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とするリモートブランチシステム。

(2)本件補正前の特許請求の範囲の記載
本件補正前(平成16年7月23日付け手続補正書により補正された)の特許請求の範囲の記載は、以下のとおりである。

【請求項1】 顧客が操作する複数の顧客端末と、
前記顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末と、
センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えたリモートブランチシステムにおいて、
どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブルと、顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とするリモートブランチシステム。

(3)本件補正についての検討
本件補正は、特許請求の範囲についての補正を含み、その内容は補正前の請求項1に記載された「センタ端末」が、「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」たものであることを限定する記載を付加すると共に、補正前の請求項1に記載された「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」を、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」であると限定するものであり、当該請求項に記載した発明を特定するために必要な事項を限定するものであって、本件補正の前後で当該請求項に記載された発明の産業上の利用分野及び解決しようとする課題を変更するものではないから、本件補正の目的は、特許法第17条の2第4項第2号(特許請求の範囲の減縮)に該当する。なお、本件補正の目的が、特許法第17条の2第4項第1号(請求項の削除)、第3号(誤記の訂正)、第4号(明りょうでない記載の釈明)に該当しないことは明らかである。
そこで、本件補正後における特許請求の範囲の前記請求項1に記載されている事項により特定される発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)について以下に検討する。

(4)引用例
(引用例1)
原査定の拒絶の理由に引用された特開平10-254831号公報(平成10年9月25日出願公開、以下「引用例1」という。)には、図面と共に、以下の事項が記載されている。
(A)【0001】?【0052】段落
「【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、複数端末の制御方法に関し、特に無人自動契約受付システムにおける複数端末の制御方法に関するものである。
【0002】
【従来の技術】近年、消費者金融業界において、無人自動契約受付システムが、マルチメディア時代の新しいサービスとして利用者から高い評価を受けている。その理由として、高機能でユーザフレンドリな操作性や、プライバシーにも配慮していることなどが挙げられる。また、金融会社側も大きな店舗を持たなくても、ホストと通信することにより契約が可能なため、無人自動契約受付専門の小さな店を出店するだけで顧客を獲得することが可能なことや、人件費の節約などの利点があり、無人自動契約受付システムの需要はますます高まると考えられる。
【0003】無人自動契約受付システムは、一般的には、顧客が操作する端末(顧客端末)と社員が操作する端末(センター端末)から構成されている。ここで、センター端末は、以下のような目的で使用される。
(1)顧客端末のスキャナで読み込んだ申込書等を、センター端末に転送してそれを表示し、記入不備がないか、正しく読み込んでいるかをオペレータが目視でチェックする。
(2)顧客端末のスキャナで読み込んだ免許証の写真と、顧客端末のカメラから本人の映像とを照合し、本人であるかをオペレータが確認する。
(3)審査結果をオペレータが入力する。
【0004】一方、顧客端末とセンター端末の接続形態としては、以下の形態がある。
(1)顧客端末とセンター端末を同一の支店内に設置し、相互の接続を行う。
(2)無人店舗のような離れた場所に顧客端末を設置して、通信回線を利用してセンター端末と接続する。
(3)地区センター等で一括して審査業務を行うように場合、地区センターにセンター端末をまとめて配置し、通信回線を利用して顧客端末と接続する。
【0005】
【発明が解決しようとする課題】これら接続形態(1)?(3)のうち、例えば接続形態(3)を採る無人自動契約受付システムの場合は、一般に、地区センターに顧客端末に対応したセンター端末が設置される。ここで、センター端末が1台の顧客端末しか接続できない場合には顧客端末の台数分のセンター端末が必要であり、センター端末がn台分の顧客端末を接続できるなら、(顧客端末の台数-1)/n+1台の台数のセンター端末が必要になる。
【0006】しかしながら、上述した従来の接続形態の場合には、センター側の端末台数が多く必要になるので、ハードウェアの導入コストが高くなるとともに、設置スペースも問題となり、また複数台の端末と複数台のセンター端末との接続関係が固定的にならざるを得ないことから、来客があった顧客端末がそれに対応してバラバラにセンター端末に接続されることになるため、センター端末のオペレータの運用が煩雑になり、しかもセンター端末がハード障害などで使用不能になった場合に、対応する顧客端末も使用不能になってしまうという問題があった。
【0007】本発明は、上記課題に鑑みてなされたものであり、その目的とするところは、ハードウェアの導入コストの低減および設置スペースの削減を可能とするとともに、複数台の端末と複数台のセンター端末の接続に際して効率的な接続を実現する複数端末の制御方法を提供することにある。
【0008】
【課題を解決するための手段】本発明による複数端末の制御方法は、複数台の端末に対して複数台のセンター端末を設けるとともに、これら複数台のセンター端末の運用を管理する管理端末を設け、複数台の端末の各々と複数台のセンター端末の各々との接続に際し、複数台の端末が各々の接続先を管理端末に対して問い合わせる一方、管理端末が接続先の問い合わせがあった端末に対してその接続先を複数台のセンター端末の運用状況に基づいて割り当てるようにする。
【0009】
【発明の実施の形態】以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。
【0010】図1は、本発明に係る無人自動契約受付システムのシステム構成図である。図1において、本システムは、地区センターに設置された管理端末(以下、運用サーバーと称する)1および複数台(本例では、2台)のセンター端末2-1,2-2と、地区センターから離れた支店に設置されたn台の顧客端末3-1,3-2,…,3-nとからなり、運用サーバー1やセンター端末2-1,2-2と顧客端末3-1,3-2,…,3-nとが通信回線4を利用して接続された構成となっている。
【0011】運用サーバー1は、例えばパーソナルコンピュータ(以下、パソコンと略称する)からなる制御装置11と、ディスプレイ12とから構成されている。センター端末2-1,2-2は、例えばパソコンからなる制御装置21と、ディスプレイ22と、例えば4台のマルチメディア通信装置23-1?23-4とから構成されている。そして、運用サーバー1とセンター端末2-1,2-2、さらにはセンター端末2-1,2-2の各々における制御装置21とマルチメディア通信装置23-1?23-4は、例えばLAN(local area network)5を通して互いに通信が可能となっている。
【0012】一方、顧客端末3-1,3-2,…,3-nの各々は、例えばパソコンからなる制御装置31およびマルチメディア通信装置32からなり、制御装置31とマルチメディア通信装置32とが例えばLAN6-1,6-2,…,6-nを介して互いに通信が可能な構成となっている。顧客端末3-1?3-nの各々にはさらに、図示しないが、顧客を映すカメラや、通話のためのハンドセット(送受話器)が装備されている。ここで、顧客端末3-1,3-2,…,3-nはそれぞれA支店,B支店,…,X支店に設置されたものとする。
【0013】なお、地区センター側のLAN5と通信回線4との間には、A支店用,B支店用,…,X支店用のルーター7-1,7-2,…,7-nが介在している。同様に、支店側のLAN6-1,6-2,…,6-nの各々と通信回線4との間には、ルーター8-1,8-2,…,8-nが介在している。
【0014】上記構成の無人自動契約受付システムにおいて、センター端末2-1,2-2は、起動されると運用サーバー1に対して開局した旨の通知を行う。このとき、センター端末2-1,2-2は各々、何台の顧客端末と接続可能な構成であるかも併せて通知する。ここで、何台の顧客端末と接続可能であるかは、マルチメディア通信装置の台数によって決まる。本例の場合には、センター端末2-1,2-2はいずれも4台の顧客端末と接続可能な構成となっている。
【0015】また、顧客端末3-1,3-2,…,3-nの各制御装置31から運用サーバー1の制御装置11に対して接続先の問い合わせが行われる(図中、(1)の経路)。これに対し、運用サーバー1の制御装置11から顧客端末3-1,3-2,…,3-nの各制御装置31へは接続先の通知が行われる(図中、(2)の経路)。また、入力データやスキャナで読み取ったデータ等の一般的なデータの通信は、センター端末2-1,2-2の各制御装置21と顧客端末3-1,3-2,…,3-nの各制御装置31の間で行われる(図中、(3)の経路)。
【0016】次に、上記構成の無人自動契約受付システムを実際に運用する場合の具体的な実施例について説明する。
【0017】〔実施例1〕この実施例1では、顧客端末3-1,3-2,…,3-nの各制御装置31からの接続先の問い合わせに対し、運用サーバー1の制御装置11は複数台(本例では、2台)のセンター端末2-1,2-2のうち1台目のセンター端末2-1から空いている順に接続先を割り当てる構成を採っている。
【0018】この実施例1に係る無人自動契約受付システムにおいて、契約受付に際して、センター端末2-1,2-2側と顧客端末3-1?3-n側の各マルチメディア通信装置間の通信を確立するまでの運用サーバー1および顧客端末3-1?3-nの各処理手順について、図2のフローチャートにしたがって説明する。
【0019】先ず、顧客端末3-1?3-n側の処理手順を示す図2(A)のフローチャートにおいて、顧客端末3-1?3-nの各制御装置31は、常時、各顧客端末3-1?3-nに備え付けられている感知センサ等によって来客の有無を監視し(ステップS11)、来客が有ると、その旨を端末の名称やアドレス等の情報と共に運用サーバー1に通知し、接続すべきセンター端末のアドレスを問い合わせる(ステップS12)。そして、運用サーバー1からの返信を待つ(ステップS13)。
【0020】運用サーバー1から返信があると、先ず、その受信データがセンター端末のアドレス情報であるか否かを判断し(ステップS14)、アドレス情報の受信でない場合には、運用サーバー1から接続先がない旨の情報が返信されたものとし、例えば「しばらくお待ちください。」なるメッセージを表示し(ステップS15)、顧客を待機させる。そして、センター端末のリソースが空くのを一定時間待ち(ステップS16)、一定時間経過したら、ステップS12に戻って再度運用サーバー1に対して接続先の問い合わせを行う。
【0021】ステップS14において、アドレス情報の受信の場合には、このアドレスを基にセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる(ステップS17)。そして、センター端末から通知されたアドレスを基に自分のマルチメディア通信装置32に対して、センター端末で指定されたマルチメディア通信装置との接続コマンドを発行し、マルチメディア通信装置間の通信を確立する(ステップS18)。
【0022】次に、運用サーバー1側の処理手順を示す図2(B)のフローチャートにおいて、運用サーバー1の制御装置11は、常時、顧客端末3-1?3-n側からのマルチメディア通信装置のアドレスの問い合わせを待ち(ステップS21)、その問い合わせがあると、常時管理している複数台のセンター端末の運用状況を参照する(ステップS22)。そして、1台目のセンター端末から空きがないかを順に調べ(ステップS23,S24)、空きが無い場合には、接続先がない旨を顧客端末3-1?3-n側に返信する(ステップS25)。
【0023】一方、ステップS23において、空いているセンター端末があると判定した場合には、その空いているセンター端末のリソース(本例では、ディスプレイ22の表示領域やマルチメディア通信装置23-1?23-4のような、接続する顧客端末ごとに必要な資源)をリザーブし(ステップS26)、顧客端末3-1?3-n側に対して接続先のセンター端末のアドレスを通知する(ステップS27)。
【0024】上述した一連の処理シーケンスを図3に示す。ここで、この処理シーケンス図を参照しつつ、例えばA支店に来客があった場合を例に採って、一連の処理の流れについて説明する。なお、本例では、運用サーバー1の運用管理の対象は、2台のセンター端末2-1,2-2とする。
【0025】先ず、A支店に来客があり、顧客端末3-1に備え付けの感知センサ等がこれを検知すると、顧客端末3-1はその旨を運用サーバー1に通知する。このとき、顧客端末3-1の名称やアドレス等の情報を送信するとともに、センター端末2-1,2-2の何れと接続すれば良いかを問い合わせる。この問い合わせに対して、運用サーバー1は、常時管理しているセンター端末2-1,2-2の運用状況に基づいてどちらかに空きがないかを順に調べる。
【0026】このときに、センター端末2-1,2-2のいずれも空いていなければ、顧客端末3-1に対してその旨の情報(接続先なし)を返信する。すると、これを受けて顧客端末3-1は、例えば「しばらくお待ちください。」なるメッセージを表示し、センター端末が空くのを待つ。このメッセージの表示により、顧客は待機中である旨を把握でき、不必要な入力操作などを行うことがない。そして、一定時間経過した後、再度運用サーバー1に対して接続先の問い合わせを行う。
【0027】一方、センター端末2-1,2-2のどちらかが空いている場合には、運用サーバー1はその空いているセンター端末のリソース(本例では、ディスプレイ22の表示領域やマルチメディア通信装置23-1?23-4のような、接続する顧客端末ごとに必要な資源)をリザーブし、顧客端末3-1に対して接続先のセンター端末のアドレスを通知する。
【0028】これを受けて顧客端末3-1側では、運用サーバー1で指定されたセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる。その後、自分のマルチメディア通信装置に対して、センター端末から指定されたマルチメディア通信装置との接続コマンドを発行する。以上の一連の処理により、指定されたセンター端末側と顧客端末3-1側のマルチメディア通信装置間の通信が確立する。
【0029】なお、顧客端末3-1が運用サーバー1に対して接続先の問い合わせを行った際に、運用サーバー1が他の顧客端末と通信中であるなどによって運用サーバー1と通信できない場合には、あらかじめ顧客端末3-1に登録されているセンター端末に接続するようにすることで、顧客端末3-1の待機時間を少なくできる。センター端末側では、顧客端末からの接続開始時および接続終了時にその旨の通知を運用サーバー1に対して行う。これにより、運用サーバー1は、センター端末2-1,2-2の運用状況を把握する。
【0030】センター端末側と顧客端末側間の通信が確立すると、顧客端末3-1側からは、スキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどが通信回線4を通して通信先のセンター端末に送信され、センター端末側からは審査結果などが顧客端末3-1に対して返信されることで、契約のための諸手続きが行われる。
【0031】顧客端末3-2,…,3-nについても、顧客端末3-1の場合と同様に、来客があった場合に、運用サーバー1に対して接続先の問い合わせを行い、これを受けて運用サーバー1ではセンター端末の運用状況を調べ、1台目のセンター端末から空いている順に接続先を割り当て、これを受けて顧客端末3-2,…,3-nでは、割り当てられた接続先のセンター端末との接続を行う処理が行われる。
【0032】このように、実施例1に係る無人自動契約受付システムでは、運用サーバー1を設置し、この運用サーバー1によって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、センター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができる。
【0033】また、センター端末を1台目から空いている順に割り当てるようにしたことにより、顧客が少ない場合は、センターのオペレータが少人数で済み、顧客が増えてきたら、それに対応してオペレータの人数を増やせば良いため、時間帯や曜日などで顧客の数が増減が多い場合など、顧客の数に合わせてセンター端末のオペレータを増減するような場合に有用なものとなる。
【0034】〔実施例2〕この実施例2では、顧客端末3-1,3-2,…,3-nの各制御装置31からの接続先の問い合わせに対し、運用サーバー1の制御装置11は複数台(本例では、2台)のセンター端末2-1,2-2のうち運用頻度の低いものから順番に接続先を割り当てる構成を採っている。
【0035】この実施例2に係る無人自動契約受付システムにおいて、契約受付に際して、センター端末2-1,2-2側と顧客端末3-1?3-n側の各マルチメディア通信装置間の通信を確立するまでの運用サーバー1および顧客端末3-1?3-nの処理手順について、図4のフローチャートにしたがって説明する。
【0036】先ず、顧客端末3-1?3-n側の処理手順を示す図4(A)のフローチャートにおいて、顧客端末3-1?3-nの各制御装置31は、常時、各顧客端末3-1?3-nに備え付けられている感知センサ等によって来客の有無を監視し(ステップS31)、来客が有ると、その旨を端末の名称やアドレス等の情報と共に運用サーバー1に通知し、接続すべきセンター端末のアドレスを問い合わせる(ステップS32)。そして、運用サーバー1からの返信を待つ(ステップS33)。
【0037】運用サーバー1から返信があると、先ず、その受信データがセンター端末のアドレス情報であるか否かを判断し(ステップS34)、アドレス情報の受信でない場合には、運用サーバー1から接続先がない旨の情報が返信されたものとし、例えば「しばらくお待ちください。」なるメッセージを表示し(ステップS35)、顧客を待機させる。そして、センター端末のリソースが空くのを一定時間待ち(ステップS36)、一定時間経過したら、ステップS32に戻って再度運用サーバー1に対して接続先の問い合わせを行う。
【0038】ステップS34において、アドレス情報の受信の場合には、このアドレスを基にセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる(ステップS37)。そして、センター端末から通知されたアドレスを基に自分のマルチメディア通信装置32に対して、センター端末で指定されたマルチメディア通信装置との接続コマンドを発行し、マルチメディア通信装置間の通信を確立する(ステップS38)。
【0039】次に、運用サーバー1側の処理手順を示す図4(B)のフローチャートにおいて、運用サーバー1の制御装置11は、常時、顧客端末3-1?3-n側からのマルチメディア通信装置のアドレスの問い合わせを待ち(ステップS41)、その問い合わせがあると、常時管理している複数台のセンター端末の運用状況を参照する(ステップS42)。そして、先ず、センター端末に空きがあるか否かを全てのセンター端末に対して調べ(ステップS43)、空きが無い場合には、接続先がない旨を顧客端末3-1?3-n側に返信する(ステップS44)。
【0040】一方、ステップS43において、空いているセンター端末があると判定した場合には、各端末の運用頻度、例えば全てのセンター端末について接続中の顧客端末数を調べ、接続中の顧客端末数が一番少ないセンター端末のリソース(本例では、ディスプレイ22の表示領域やマルチメディア通信装置23-1?23-4のような、接続する顧客端末ごとに必要な資源)をリザーブし(ステップS45)、顧客端末3-1?3-n側に対して接続先のセンター端末のアドレスを通知する(ステップS46)。
【0041】上述した一連の処理シーケンスを図5に示す。ここで、この処理シーケンス図を参照しつつ、例えばA支店に来客があった場合を例に採って、一連の処理の流れについて説明する。なお、本例においても、運用サーバー1の運用管理の対象は、2台のセンター端末2-1,2-2とする。
【0042】先ず、A支店に来客があり、顧客端末3-1に備え付けの感知センサ等がこれを検知すると、顧客端末3-1はその旨を運用サーバー1に通知する。このとき、顧客端末3-1の名称やアドレス等の情報を送信するとともに、センター端末2-1,2-2の何れと接続すれば良いかを問い合わせる。この問い合わせに対して、運用サーバー1は、常時管理しているセンター端末2-1,2-2の運用状況に基づいて各端末の運用頻度、例えば全てのセンター端末について接続中の顧客端末数を調べる。
【0043】このときに、センター端末2-1,2-2のいずれも空いていなければ、顧客端末3-1に対してその旨の情報(接続先なし)を返信する。すると、これを受けて顧客端末3-1は、例えば「しばらくお待ちください。」なるメッセージを表示し、センター端末が空くのを待つ。このメッセージの表示により、顧客は待機中である旨を把握でき、不必要な入力操作などを行うことがない。そして、一定時間経過した後、再度運用サーバー1に対して接続先の問い合わせを行う。
【0044】一方、センター端末2-1,2-2のどちらかが空いている場合は、接続中の顧客端末数が一番少ないセンター端末を選択し、そのセンター端末のリソース(本例では、ディスプレイ22の表示領域やマルチメディア通信装置23-1?23-4のような、接続する顧客端末ごとに必要な資源)をリザーブし、顧客端末3-1に対して接続先のセンター端末のマルチメディア通信装置のアドレスを通知する。
【0045】これを受けて顧客端末3-1側では、運用サーバー1で指定されたセンター端末と接続し、使用可能なマルチメディア通信装置のアドレスを問い合わせる。その後、自分のマルチメディア通信装置に対して、センター端末から指定されたマルチメディア通信装置との接続コマンドを発行する。以上の一連の処理により、指定されたセンター端末側と顧客端末側のマルチメディア通信装置間の通信が確立する。
【0046】なお、顧客端末3-1が運用サーバー1に対して接続先の問い合わせを行った際に、運用サーバー1が他の顧客端末と通信中であるなどによって運用サーバー1と通信できない場合には、あらかじめ顧客端末3-1に登録されているセンター端末に接続するようにすることで、顧客端末3-1の待機時間を少なくできる。センター端末側では、顧客端末からの接続開始時および接続終了時にその旨の通知を運用サーバー1に対して行う。これにより、運用サーバー1は、センター端末2-1,2-2の運用状況を把握する。
【0047】センター端末側と顧客端末側間の通信が確立すると、顧客端末3-1側からは、スキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどが通信回線4を通して通信先のセンター端末に送信され、センター端末側からは審査結果などが顧客端末3-1に対して返信されることで、契約のための諸手続きが行われる。
【0048】顧客端末3-2,…,3-nについても、顧客端末3-1の場合と同様に、来客があった場合に、運用サーバー1に対して接続先の問い合わせを行い、これを受けて運用サーバー1では全てのセンター端末について接続中の顧客端末数を調べ、接続中の顧客端末数の一番少ないセンター端末を選択して接続先を割り当て、これを受けて顧客端末3-2,…,3-nでは、割り当てられた接続先のセンター端末との接続を行う処理が行われる。
【0049】このように、実施例2に係る無人自動契約受付システムでは、実施例1の場合と同様に、運用サーバー1を設置し、この運用サーバー1によって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、センター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができる。
【0050】また、センター端末を接続中の顧客端末数の少ないものから順に割り当てるようにしたことにより、使用可能なセンター端末に対して顧客端末が均等に割り当てられることになるため、センター端末のオペレータの人数が固定の場合に、オペレータの負荷が偏らず、各オペレータの負荷を均等にすることができる利点がある。
【0051】なお、上記実施形態では、無人自動契約受付システムにおける複数台の顧客端末の制御に適用した場合について説明したが、本発明は、無人自動契約受付システムへの適用に限定されるものではなく、1台のセンター端末で複数の端末を制御する構成のシステム全般に適用可能である。
【0052】
【発明の効果】以上詳細に説明したように、本発明によれば、運用サーバーを設置し、この運用サーバーによって顧客端末からの接続要求に対してセンター端末を割り当てるようにしたことにより、接続先のセンター端末を柔軟に決定することができるため、効率的な接続を実現できるとともに、あるセンター端末がハード障害などで使用不能になっても他のセンター端末で対応でき、しかもセンター端末と顧客端末の接続を固定的に決める従来方式に比べて、センター端末の台数を少なくすることができるため、ハードウェアの導入コストの低減と設置スペースの削減が可能となる。」

そうしてみると、引用例1には、以下の発明(以下、「引用例1記載の発明」という。)が開示されていると認められる。
「顧客が操作する複数の顧客端末と、
前記顧客端末と接続して該顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどを受信し、審査結果などを該顧客端末に対して返信することで、契約のための諸手続きを行う複数のセンタ端末と、
センタ端末に接続する顧客端末を振り分ける運用サーバー(管理端末)とを備えた無人自動契約受付システムにおいて、
起動時に開局した旨の通知と併せて、何台の顧客端末と接続可能な構成であるかを前記運用サーバー(管理端末)に通知する機能を各センタ端末に設け、
顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段を前記運用サーバー(管理端末)に備えたことを特徴とする無人自動契約受付システム」

(引用例2)
また、原査定の拒絶の理由に引用された、中島 周、安藤史郎、「セルフサービス金融端末への共同作業技術の応用」、電子情報通信学会誌、日本、社団法人電子情報通信学会、1998年3月25日、第81巻、第3号、第259-265頁(以下「引用例2」という。)には、図と共に、以下の事項が記載されている。
(B)第263頁左欄第36行?第265頁左欄第17行
「 4. 非対称共同作業
同期対面型の共同作業の技術はほとんどが対称的なハードウェア・ソフトウェア構成を有し,使用者から見たユーザインタフェース・機能も全く同じである. しかし,3.で説明したような金融端末における共同作業には種々の非対称性がある.まず,顧客と専門家のそれぞれの作業内容が異なっでいる.例えば顧客側では契約申込処理のプログラムが実行され,専門家端末には顧客からのデータの審査,外部データベースへの照会,自社データベースへの登録などが実行される.顧客端末には図4のようにセンサ,プリンタ,スキャナ,無停止電源など種々の周辺機器がついているが,専門家端末はごく少数のものだけである.また,コンピュータへの習熟度の差から,顧客端末では全画面のタッチパネルで操作されるユーザインタフェースが提供されるが,専門家端末はウィンドウシステムを使ったGUIが使われる.もともと金融端末は人に邪魔されずに一人で利用していたので,顧客は専門家との過度の対話は好まない.しかし,専門家は契約処理の場合,顧客を慎重に観察する必要がある.
このような種々の非対称性を損なわずに共同作業技術を導入するには以下のような方策が必要となる.
(1)共同作業で会議機能を提供するプログラムは閉じた会議システムではなく,外部から詳細な制御ができるようなミドルウェアとして実現する. これによつてそのミドルウェア上で異なるアプリケーション同士が通信しながらステップによっては同期をとりながら稼動するシステムが実現できる.
(2)会議機能を実現する個々のプロダラム自身が非対称性を実現できる機能をもつ.例えば,顧客と専門家で文書データの共有表示・編集を行う共有黒板プログラムがウィンドウのタイトルバーなどの個々の要素の表示・非表示などのユーザインタフェースを作業者ごとに変えられること,共同編集機能が作業者ごとに操作できる機能範囲が変更できること,顧客からの接続時には空いている専門家が自動的に選択されて接続されることなどである.
(3)そして前述の二つの方策を前提として,システム全体で非対面同期型の新しい共同作業を実現して,専門家の負荷を減らす.
非対面同期型の例として,書類の記入とその遠隔での確認・訂正指示の処理を図5によって説明する.
まずブランクの書類が印刷され,顧客はそれに手書きでデータを記入する.その後その書類はスキャナで読み取られ,イメージデータが専門家端末に送られる.このとき,専門家はそのイメージデータを見て書類の内容を審査する.しかし,このときに未記入や書き間違いなどによって書類訂正の作業が必要となる.記入ミスの種類のほとんどは決まっており,その数は数種類である.専門家は記入ミスを見つけると,事前に分類されたミスの種類を選び,イメージデータに注釈を加えてから共有化する.すると,顧客端末には,それぞれのミスに対応した修正手続きの内容が注釈つきのイメージデータと共に表示される.専門家は1方向のビデオ会議機能で顧客の様子を観察しているが,顧客側には専門家の動画像も音声も送られない.もし人間同士の対話が必要な複雑な訂正処理の場合は,双方向のビデオ会議機能を使用する.双方向のビデオ会議機能を使わない通常の訂正処理では,顧客からはあたかも顧客端末という機械が書類のミスを見つけ,注釈をつけてその訂正方法を指示しているようにみえる.この方法は,顧客が不必要に専門家との対話による干渉を受けず,また専門家も短時間で書類訂正を指示できるという長所をもっている.つまり,実際は機械と人間とで書類内容の遠隔訂正を実現しているのだが,顧客には自分のインタフェースである機械しか見えていない.これは,いままでにない非対面同期型の共同作業と位置づけることもできる,新しい形態の共同作業である. これはまた,机上の検討ではなく,現実の契約業務の分析とその業務のコンピュータシステムによる実装から発見されたことに意義がある.」

(引用例3)
同じく、原査定の拒絶の理由に引用された特開平5-298250号公報(平成5年11月12日出願公開、以下「引用例3」という。)には、図面と共に、以下の事項が記載されている。
(C)【0007】?【0017】段落
「【0007】
【実施例】次に、本発明の実施例について図面を参照して説明する。
【0008】図1は本発明のマルチホストシステムの一実施例を示すブロック図である。
【0009】本実施例のマルチホストシステムは、図1に示すように、A業務11からG業務17までの7つの業務がホスト1からホスト4までの4台のホストコンピュータに存在しているマルチホストシステムで、特定のホストコンピュータであるホスト1には、業務とそれに対応するホストコンピュータ情報とを記憶している業務・ホスト対応テーブル7と、端末5の要求に応答して業務・ホスト対応テーブル7にアクセスし対応ホストコンピュータ情報を読み出す業務・ホスト認識部6と、このホストコンピュータ情報の供給に応答してこれを端末に通知する接続ホスト情報通知部8を備えている。
【0010】一方、端末5には、希望する業務に対応するホストコンピュータ情報を要求するホストコンピュータ情報要求部10とホスト1からのホストコンピュータ情報の供給に応答してそのホストコンピュータに接続するホスト接続部9とを備えている。
【0011】図2には、業務・ホスト対応テーブル7の記憶内容の一例を示している。接続対象業務に対してその名称と、それの存在するホスト名、そのホストのネットワークアドレスが記憶されている。
【0012】図1および図2を参照して、端末5がホスト3に存在するE業務15を利用する場合についての本実施例の動作について説明する。
【0013】端末5は、ホスト1に接続し、ホストコンピュータ情報要求部10により接続対象業務名であるE業務15の名称をホスト1に送り接続すべきホストコンピュータの情報を要求する。
【0014】ホスト1の業務・ホスト認識部6はこの端末5の要求の受信に応答して、受信した接続対象業務名をもとに業務・ホスト対応テーブル7を参照し対応する接続ホストコンピュータ情報、すなわち、接続ホスト名である「ホスト3」、そのネットワークアドレスである「0003」および接続対象業務名である「E」を読み出し接続ホスト情報通知部8に供給する。接続ホスト情報通知部8は業務・ホスト認識部6から供給された接続ホストコンピュータ情報を端末5に送信する。
【0015】端末5はホスト1から供給された接続ホストコンピュータ情報にもとづいてホスト接続部9によりホスト3に端末5を接続して希望の業務であるE業務15を実行することができる。
【0016】このようにして本実施例ではホスト1に業務・ホスト対応テーブル7を設けることによりシステム構成の変更等に際してはこれのみを変更するだけで対応でき融通性に富んだシステムを構成でき、かつ、誤操作を減少できるという効果を有している。
【0017】
【発明の効果】以上説明したように、本発明のマルチホストシステムは、特定のホストコンピュータに業務とホストコンピュータとの対応情報を記憶し、一元管理を行なうことにより、システム変更に際しても融通性を増大させ、かつ、誤操作を少なくできるという効果を有している。」

(引用例4)
また、特開平10-51550号公報(平成10年2月20日出願公開、以下、「引用例4」という。)には、図面と共に、以下の事項が記載されている。
(D)【0017】?【0053】段落
「【0017】
【発明の実施の形態】図1は、本発明が適用されるシステム構成を示す。本発明は、同図に示すように、カスタマ20、企業システム10から構成され、企業システム10の一つであるカスタマ20から受け付けた問い合わせを担当者200に引き継ぐための受付応対システム100を有する。
【0018】受付応対システム100は、図2に示すように、カスタマ20からの電話による受付を行うサーバ120、当該サーバ120により参照されるファイル群を管理するファイル管理システム130、サーバ120により接続先の担当者に対して音声情報を転送する交換機110、当該交換機110から担当者200に対して音声情報を転送する企業内電話回線(以下、内線と記す)150及び、サーバ120から転送される画像情報を取得すると共に、内線150により音声情報を受信する担当者用端末装置210より構成される。
【0019】図3は、本発明のサーバの構成を示す。同図に示すサーバ120は、入力部121、表示部122、検索部123、担当者決定部124、情報転送部125及びタイマ126から構成される。入力部121は、受付オペレータからの指示入力及び問い合わせを行っている顧客の識別情報を入力する。
【0020】表示部122は、入力部121から入力された情報及び、検索123により検索された結果等を表示する。検索部123は、入力部121から入力された情報に基づいてファイル管理システム内130のファイルを検索し、当該検索結果を表示部122に表示する。担当者決定部124は、検索部123により検索された検索結果から所定の条件に合致する担当者を決定する。決定条件としては、カスタマの問い合わせ内容を担当し、所定のレベルを備え、現時点において応対可能である要件が必要となる。
【0021】情報転送部125は、受付オペレータが内線150を介して音声により問い合わせ内容等の概要を出力するための音声出力部(図示せず)とLAN140を介して、カスタマ情報、タイマ126により計測されている経過時間等の情報を転送する画面情報転送部(図示せず)から構成される。タイマ126は、カスタマからの問い合わせを受け付けた時刻から経過した時間を計測する。
【0022】図4は、本発明のファイル管理システムを示す。サーバ120の検索部123において、検索対象となるファイル群は、応対履歴情報ファイル131、顧客情報ファイル132、担当者情報ファイル133、及び各種業務ファイル134より構成される。応対履歴情報ファイル131は、カスタマの問い合わせ及び担当者の応答履歴が管理されるファイルであり、図5に示すように、受付番号、受付日時、顧客番号、質問区分、受付内容、回答内容、完了日付/時刻、受付担当者コード、回答担当者コード、回答結果等が設定される。
【0023】顧客情報ファイル132は、顧客毎の情報を管理するファイルであり、図6に示すように、顧客番号、顧客名、電話番号、住所、顧客種別等が設定されている。担当者情報ファイル133は、担当者毎の情報を管理するファイルであり、図7に示すように、担当者コード、担当者名、内線番号、部署コード、部署名、スキルレベル、使用端末ID、担当者状態a、担当者状態b等が設定される。担当者状態aは、担当者のスケジュール情報を日付により管理しており、担当者状態bは、応対可能、離席等の現時点の担当者の状態を表している。例えば、担当者が離席する場合に、離席を意味する情報をLAN150を介して入力することにより、当該項目の内容が“応対可能”から“離席”に変更される。
【0024】各種業務情報ファイル134は、種々の業務内容が格納されているファイルであり、受付オペレータや応答する担当者により必要に応じて参照される情報が格納される。以下に、上記の構成に基づいた本発明の動作の概要を説明する。図8は、本発明の一連の動作のフローチャートである。
【0025】ステップ101) 受付オペレータは、カスタマからの問い合わせを受け付けると、サーバ120の入力部120からカスタマから聴取した顧客番号を入力する。これにより、タイマ126が起動される。
ステップ102) 入力された顧客番号に基づいて検索部123は、応対履歴情報ファイル131を検索して、カスタマ履歴情報を取得し、表示部122に転送する。
【0026】ステップ103) 表示部122は、検索部123から取得した検索結果としてカスタマ履歴情報を表示する。
ステップ104) 受付オペレータは、表示部122に表示されたカスタマ履歴情報を参照して、カスタマから聴取した問い合わせ内容に対応する業務名または、質問区分等を入力する。これにより、検索部123は、受付オペレータにより指定された業務名または、質問区分に基づいて担当者情報ファイル133を検索する。このとき、受付オペレータが特定の業務名または、質問区分を入力できない場合に、曖昧な検索条件を入力した場合であっても曖昧検索による方法、または、エキスパートシステムを介在させることにより担当者情報ファイル133へのアクセスを許容するものとする。
【0027】更に、担当者決定部124は、検索された結果において、所定の応答レベルに達している担当者(例えば、レベル3以上)であり、かつ、応対履歴情報ファイル131の回答結果を参照して、前回同一カスタマに対して回答の成果があったか否かを判定し、さらに、担当者情報ファイル133の担当者状態bのデータを参照して、現時点において、応答可能な担当者を選択する。複数の候補がある場合には、複数の担当者を表示部122に転送する。
【0028】ステップ105) 検索部123が担当者情報ファイル133を検索した結果である応答可能な担当者のを表示部122に表示する。
ステップ106) 受付オペレータは、表示部122に表示された担当者を指定し、表示されている担当者の内線番号にダイヤルする。担当者の候補が複数存在する場合には、最適であると考えられる担当者を任意に指定し、内線150を介して音声情報により当該担当者に問い合わせの概要等を伝える。
【0029】ステップ107) 情報転送部125は、指定された担当者の端末IDを宛先としてLAN140を介して、経過時間を含む顧客情報及び顧客履歴情報等必要な情報を転送する。また、このとき、サーバ120は、受付オペレータのコード及び受付日付/時刻を応対履歴情報ファイル131に反映させる。
ステップ108) 担当者は、端末から現時点において応対が可能であるかを否かの応答を返却する。応答が不可能な場合には、上記のステップ104に移行する。
【0030】ステップ109) 指定した担当者の応対が可能な場合には、内線140を用いて交換機110を介してカスタマに応対する。
ステップ110) 担当者は、カスタマに対する応対が終了すると、LAN140を介して自担当者コード、完了日付/時刻、及び回答内容、回答結果等を入力する。これにより、サーバ120は、当該入力内容を応対履歴情報ファイル131に反映する。
【0031】
【実施例】以下、本発明の実施例を図面と共に説明する。以下の実施例では、カスタマから商品に対するクレームが発生した場合の処理を説明する。第1の実施例として、カスタマが以前に問い合わせを行っている(顧客履歴情報あり)場合の処理を説明し、第2の実施例として、新規のカスタマ(顧客履歴情報なし)からの問い合わせの場合の処理を説明する。
【0032】[第1の実施例]本実施例の動作を図8のフローチャートに基づいて説明する。
(1) カスタマ(顧客番号001)から受付オペレータがクレームの電話を受け付け、受付オペレータが顧客番号“001”入力部121から入力すると同時に、タイマ126が起動する(ステップ101)。
【0033】(2) 検索部123は、顧客番号“001”に基づいて顧客情報ファイル132及び応対履歴ファイル131を検索し、検索結果を担当者決定部124に転送する。これにより、図9に示す画面が表示部122に表示される。ここで、サーバ120は、応対履歴情報ファイル131に新規に応対レコードを生成し、自動的に受付番号(101)、受付日付・時刻(96年6月1日)、顧客番号(001)、質問区分(商品クレーム:05)、受付担当者コード(R03)をデータとして設定する。
【0034】(3) この表示画面に対して受付オペレータが転送先担当者リストをクリックすると、図10に示す画面が表示される。このとき、担当者決定部124が予め設定されている、スキルレベル3以上、応対可能者という条件に基づいて担当者の絞り込みを行う。これにより、図10に示すように、表示部122に当該カスタマに応対したキャリアを有する担当者のリストが表示される(ステップ103、104、105)。なお、表示部122に表示される担当者の順位は、所定の優先順位のカテゴリを設け、部署毎または、スキルレベル順にソートされた形で表示するようにしてもよい。
【0035】(4) 受付オペレータは、図10のように表示された担当者リストから任意の担当者をクリック等により選択する。また、担当者決定部124により、最適であると判断される(レベルが最も高い等)担当者の表示欄をブリンキング表示するように制御することも可能である。同図の例において、担当者コード“A06”の担当者CCCが選択されたものとする。
【0036】(5) 受付オペレータは表示されている内線番号(3356)に電話をかけ、クレームの内容を音声により、通知する(ステップ106)。同時に、LAN140を介して情報転送部125は、指定された担当者の端末ID(CCC)に応対履歴情報及び顧客情報を転送する。また、このとき、タイマ126で計時しているクレームの受け付けを開始してからの時間も併せて通知する(ステップ107)。
【0037】(6) 担当者(CCC)が受付オペレータから内線を受け付け、カスタマに対する応対が可能であるか否かを告げる(ステップ108)。オペレータが担当者から応対が不可能である旨を通知された場合には、上記の(2)以降の処理を再度繰り返して他の担当者を同様の方法で検索する。担当者が応対が可能である場合には、図11に示す画面を見てカスタマに対応する(ステップ109)。
【0038】また、担当者用の画面の上部には、受け付けを開始してから現時点までの経過時間が併せて表示されているため、カスタマを長時間待たせている場合には、その旨を詫びる等の対応が可能となる。
(7) 担当者のカスタマの応対が終了すると、担当者は、回答内容を画面の回答内容の欄に入力する。回答内容として、この例では、『返品受け付け』のように入力する。さらに、回答を保留した場合には、回答結果欄の“保留”をクリックし、解決した場合には、“解決”をクリックする。
【0039】(8) 担当者が入力した回答内容及び回答結果、回答が終了した日時をLAN140によりサーバ120に転送する。
(9) サーバ120は、担当者の端末から転送された情報及び、回答担当者コード(A06)等を上記の(2)で生成された当該応対に対する応対履歴情報ファイル131の応対レコードに反映させる(ステップ110)。
【0040】[第2の実施例]次に、本発明の第2の実施例として、新規のカスタマによる問い合わせがあった場合の処理を説明する。図12は、本発明の第2の実施例の新規カスタマ応対処理のフローチャートである。以下、図12のフローチャートに沿って処理を説明する。
【0041】ステップ201) 新規のカスタマからクレームの電話を受け付ける。このとき、受付オペレータは、当該カスタマが顧客番号を保持していないことを認識すると、カスタマの氏名や電話番号を聴取して、図13に示す画面への入力を行う。
ステップ202) ステップ201において、受付オペレータが応対を開始すると同時にタイマ126が起動される。
【0042】ステップ203) 問い合わせをしているカスタマが新規であるので、ステップ204に移行する。カスタマがリピータである場合には、前述の第1の実施例の処理を行う。
ステップ204) 受付オペレータは、カスタマから質問の内容を受け付ける。この例では、商品(電化製品の使用方法)の問い合わせであるものとする。受付オペレータは、質問内容の『電化製品の使用方法』を画面上の受付内容の欄に入力する。
【0043】ステップ205) 検索部123は、“電化製品”で業務情報ファイル134を検索し、電化製品を扱う部署コードを取得する。
ステップ206) さらに、検索部123は、ステップ205で取得した部署コードで、担当者情報ファイル133を検索し、当該部署の担当コードを抽出する。
【0044】ステップ207) その結果を前述の図10に示すように転送先の担当者のリストを表示部122に表示する。
ステップ208) 受付オペレータは、表示部122に表示された担当者リストから当該質問内容に最適であると思われる担当者を指定入力する。このとき、担当者決定部124において、担当者情報ファイル133の担当者状態bを参照して現時点において応対可能な担当者のみを自動的に表示するようにしてもよい。この例では、担当者コード“A01”の担当者を指定するものとする。
【0045】ステップ209) 当該カスタマの応対を行う担当者が決定すると応対履歴情報ファイル131に新規のレコードを生成すると共に、顧客情報ファイル132にも当該カスタマの新規レコードを作成する。
ステップ210) 受付オペレータは、内線を用いて当該担当者(A01)の内線番号(1234)に対して音声によりカスタマから要件を伝えると共に、LAN140により顧客氏名等の情報を画面情報として担当者の端末ID(aaa)に送信する。
【0046】以降の担当者の処理は、前述の第1の実施例と同様であるため、その説明を省略する。
[第3の実施例]次に、第3の実施例として、担当者情報ファイル133の更新の処理を説明する。本実施例における担当者情報ファイル133の更新は、担当者が使用する端末IDや内線番号が変更になる場合、及び担当者状態aの担当者スケジュールの更新の2つのパターンがある。
【0047】最初に、担当者が使用する端末IDと内線番号が変更になる例について説明する。担当者は、業務の開始前に図14に示す画面より当日使用する端末から担当者コード及び内線番号を指定する。これにより、検索部123は、当該担当者コードか担当者情報ファイル133を検索して、該当するレコードを検索し、当該レコードに入力に使用された端末IDと、担当者から入力された内線番号を設定して更新する。
【0048】これにより、当日担当者が使用する端末や内線番号が変更された場合に、担当者情報ファイルの内容が当該変更に応じて更新されるため、常に受付オペレータが参照する転送先担当者リストの内容が無矛盾に表示される。次に、担当者の所定期間(週間、月間)のスケジュールの変更及び登録を行う場合について説明する。担当者のスケジュールの変更や登録を行う際には、図15に示すように、例えば、1週間の出勤予定入力用の画面が表示される。同図において、予め土・日曜及び祭日等はカレンダ機能によりその旨が予め表示されているものとし、担当者は『出勤』『休暇』のいずれかをクリックすることにより、出勤予定の入力を行う。この情報は、担当者情報ファイル133の担当者状態aに格納される。
【0049】また、本発明は、上記の動作をプロセスとして、プログラムを構築することが可能であり、このプログラムを可搬記憶媒体に格納し、当該受付システムを実施するコンピュータにインストールすることで、当該システムを実行できる。なお、本発明は、上記の実施例に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【0050】
【発明の効果】第1及び第7の発明によれば、カスタマの問い合わせの窓口となる受付オペレータがカスタマから問い合わせを含む連絡を受けた場合に、該問い合わせの内容に応じた担当者に転送する際に、画面上に、当該問い合わせ内容に適する担当者のリストが表示されることにより、受付オペレータは、表示されたリストから最適であると判断される担当者を選択または、最適であると決定されて表示されている担当者を指定して、確実に応対を引き継ぐことが可能となる。
【0051】また、第2の発明によれば、受付オペレータから担当者に対してカスタマの情報を転送し、担当者の端末上の表示手段に表示することにより、担当者は、自分が有する資料等を探すことなく、スムーズにカスタマの応対可能である。また、カスタマ問い合わせ内容のニュアンス等表示手段上に表示されないような情報は、従来通り内線を用いて受付オペレータと会話できる。
【0052】第3及び第8の発明によれば、カスタマとの応対を開始した時間が画面上に表示されるため、応対までにかなり待機させたカスタマに対しては、お詫び等のメッセージを伝えることが可能である。第4の発明によれば、カスタマからの問い合わせ時に、担当者の現在の状態を取得することにより、当該カスタマとその時点で対応が可能な担当者を決定することが可能となる。
【0053】第5及び第9の発明によれば、担当者のレベルや、担当者の現在の状況に応じて最適な担当者を検索して、応対を引き継ぐことにより、より適切な応対が可能となる。第6及び第10の発明によれば、担当者の内線や、端末IDがリアルタイムに担当者情報に反映されるため、受付オペレータに提示される情報と実際の担当者が使用する内線番号及び端末IDとの間に常に整合がとれているため、転送先に指定した担当者が存在しない等の矛盾を防ぐことが可能である。」

(5)対比
そこで、本願補正発明と引用例1記載の発明とを比較すると、
a)引用例1記載の発明の「顧客端末と接続して該顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データ、カメラで映した顧客の画像データ、ハンドセットによる音声データなどを受信し、審査結果などを該顧客端末に対して返信することで、契約のための諸手続きを行う複数のセンタ端末」と、本願補正発明の「顧客端末と接続して該顧客端末を遠隔操作する複数のセンタ端末」は、「顧客端末と接続して該顧客端末と所定の処理をする複数のセンタ端末」で共通し、
b)引用例1記載の発明の「運用サーバー(管理端末)」は、本願補正発明の「運用管理端末」に相当し、
c)引用例1記載の発明の「起動時に開局した旨の通知と併せて、何台の顧客端末と接続可能な構成であるかを前記運用サーバー(管理端末)に通知する機能を各センタ端末に設け」ることと、本願補正発明の「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」ることは、「運用開始時に業務に関する情報を前記運用管理端末に通知する登録機能を各センタ端末に設け」ることで共通し、
d)引用例1記載の発明の「顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段」と、本願補正発明の「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」は、「顧客端末に対する業務が実行可能なセンタ端末を参照して選択して前記顧客端末に通知する手段」で共通し、
e)引用例1記載の発明の「無人自動契約受付システム」と、本願補正発明の「リモートブランチシステム」は、以下の点で相違するものの、「無人自動契約受付のためのシステム」である点で共通していることから、本願補正発明と引用例1記載の発明は、
「顧客が操作する複数の顧客端末と、
前記顧客端末と接続して該顧客端末と所定の処理をする複数のセンタ端末と、
センタ端末に接続する顧客端末を振り分ける運用管理端末とを備えた受付システムにおいて、
運用開始時に業務に関する情報を前記運用管理端末に通知する登録機能を各センタ端末に設け、
顧客端末に対する業務が実行可能なセンタ端末を選択して前記顧客端末に通知する手段を前記運用管理端末に備えたことを特徴とする無人自動契約受付のためのシステム」
である点で一致し、以下の点で相違している。

[相違点1]
本願補正発明は、「顧客端末と接続して該顧客端末を遠隔操作するセンタ端末」を備えた「リモートブランチシステム」であるのに対して、引用例1記載の発明は、「センタ端末」が「顧客端末を遠隔操作する」ものであるか明確でないため、「リモートブランチシステム」であるか明確でない点。

[相違点2]
本願補正発明の「運用管理端末」が、「実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるのに対して、引用例1記載の発明の「運用管理端末」は、このようなセンタ端末登録テーブルを備え、このテーブルを参照してセンタ端末を選択していない点。

[相違点3]
本願補正発明では、「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて」、運用管理端末のセンタ端末登録テーブルに登録するのに対して、引用例1記載の発明では、「オペレータが選択した実行可能な業務を通知する」機能をセンタ端末に設けていない点。

(6)当審の判断
[相違点1について]
上記摘記事項(B)にあるように、引用例2には、非対面同期型の例として、書類の記入とその遠隔での確認・訂正指示の処理について、図5により、「・・・書類はスキャナで読み取られ,イメージデータが専門家端末に送られる.このとき,専門家はそのイメージデータを見て書類の内容を審査する.しかし,このときに未記入や書き間違いなどによって書類訂正の作業が必要となる.・・・専門家は記入ミスを見つけると,事前に分類されたミスの種類を選び,イメージデータに注釈を加えてから共有化する.すると,顧客端末には,それぞれのミスに対応した修正手続きの内容が注釈つきのイメージデータと共に表示される.・・・顧客からはあたかも顧客端末という機械が書類のミスを見つけ,注釈をつけてその訂正方法を指示しているようにみえる.この方法は,顧客が不必要に専門家との対話による干渉を受けず,また専門家も短時間で書類訂正を指示できるという長所をもっている.つまり,実際は機械と人間とで書類内容の遠隔訂正を実現しているのだが,顧客には自分のインタフェースである機械しか見えていない.」と説明されており、このような顧客端末に書類記入ミスに対応した修正手続きの内容を注釈つきのイメージデータと共に表示させる等の書類内容の遠隔訂正を実現する専門家端末における遠隔操作の手段を、引用例1記載の発明における、顧客端末から送信されるスキャナで読み込んだ申込書や免許証の写真の入力データなどを受信し、審査結果などを該顧客端末に対して返信するセンタ端末に採用して、該顧客端末を遠隔操作するセンタ端末とし、システムを無人自動契約受付のためのリモートブランチシステムとすることは、当業者が容易に成し得たものと認められる。
したがって、相違点1に係る本願補正発明の構成は、引用例1記載の発明、引用例2記載の事項に基づいて、当業者が容易に想到し得たものである。

[相違点2について]
上記摘記事項(C)にあるように、引用例3には、「接続対象業務に対してその名称と、それの存在するホスト名、そのホストのネットワークアドレスが記憶され、どのホストコンピュータでどの業務が実行可能かを書換え可能に登録する業務・ホスト対応テーブル」(0011、0016、0017段落、図2)と、「端末で要求された業務が実行可能なホストコンピュータを前記業務・ホスト対応テーブルを参照し対応する接続ホストコンピュータ情報を前記端末に通知する手段」(0012?0015段落)が記載されていると認められる。
引用例3に記載された技術的手段を引用例1記載の発明に採用することに、技術的に格別の困難性は認められず、適用する際に、業務・ホスト対応テーブルの内容を、実行可能な業務をそのセンタ端末を示す識別子と対応させたものとすることは、用途変更に伴う設計変更であり、当業者が通常の創作活動の範囲内で容易に成し得たものと認められる。
してみれば、引用例1記載の発明の運用管理端末において、「実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるようにすることは、当業者が容易に成し得たものと認められる。
したがって、相違点2に係る本願補正発明の構成は、引用例1記載の発明、引用例3記載の事項に基づいて、当業者が容易に想到し得たものである。

[相違点3について]
上記摘記事項(D)にあるように、引用例4には、実施例として、受付オペレータは、カスタマから電化製品の使用方法の問い合わせを受け付けた場合に、前記受付オペレータは、『電化製品の使用方法』を画面上の受付内容の欄に入力し、検索部は、“電化製品”で業務情報ファイルを検索し、電化製品を扱う部署コードを取得し、検索部は、取得した部署コードで、担当者情報ファイルを検索し、当該部署の担当コードを抽出する(0042?0043段落)ことが記載され、更に、「担当者は、業務の開始前に図14に示す画面より当日使用する端末から担当者コード及び内線番号を指定する。これにより、検索部123は、当該担当者コードか担当者情報ファイル133を検索して、該当するレコードを検索し、当該レコードに入力に使用された端末IDと、担当者から入力された内線番号を設定して更新する。・・・担当者情報ファイルの内容が当該変更に応じて更新されるため、常に受付オペレータが参照する転送先担当者リストの内容が無矛盾に表示される。」(0047?0048段落)と記載されている。
これらの記載からみて、引用例4の受付応答システムは、業務開始前に担当者が当日使用する端末から担当者コード等を指定することにより、担当者情報ファイルの担当者コードと使用端末IDとを対応させて変更登録する機能を各端末に設けているものと認められ、当該担当者が対応可能な業務(すなわち、使用端末で実行可能な業務)は、前記担当者情報ファイルに担当者コードと対応して登録されている部署コードにより自動的に決定されていると認められるものの、このような自動的に決定される内容を、単に手動化すること、すなわち、担当者が周知な入力手段を操作して、実行可能な業務を選択するようにすることは、単なる設計変更に過ぎず、自由な選択が可能となること等は手動化による自明な効果に過ぎない。
してみれば、引用例4記載の技術的事項及び周知技術を引用例1記載の発明に適用して、運用開始時にオペレータが選択した実行可能な業務を運用管理端末に通知する登録機能を各センタ端末に設けると共に、前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す端末ID(本願補正発明の「識別子」に相当)と対応させて、顧客の要求に対応可能なセンタ端末を選択するための手段に登録するようにすることは、当業者が容易に成し得たものと認められる。
したがって、相違点3に係る本願補正発明の構成は、引用例1記載の発明、引用例4記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものである。

そして、請求項1に係る発明の作用効果も、引用例1-4及び周知技術から当業者が予測できる範囲のものである。

したがって、本願補正発明は、引用例1記載の発明、引用例2-4記載の事項及び周知技術に基づいて、当業者が容易に発明することができたものであるから、特許法29条2項の規定により特許出願の際独立して特許を受けることができないものである。

(7)むすび
以上のとおり、本件補正は、特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するものであるから、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

3.本願発明について
(1)本願請求項1に係る発明について
平成16年10月29日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成16年7月23日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される、上記のとおりのものである。

(2)引用例
原査定の拒絶の理由に引用された引用例1-3、及びその記載事項は、前記「2.(4)」に記載したとおりである。

(3)対比
本願発明は、前記2.(1)で検討した本願補正発明から、「センタ端末」に関する限定事項である「運用開始時にオペレータが選択した実行可能な業務を前記運用管理端末に通知する担当業務登録機能を各センタ端末に設け」との構成を省き、「センタ端末登録テーブル」に関する特定事項について、「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」を「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」に上位概念化したものである。
そうすると、本願発明と引用例1記載の発明とは、前記2.(5)に記載した点で一致し、以下の点で相違する。

[相違点1]
本願発明は、「顧客端末と接続して該顧客端末を遠隔操作するセンタ端末」を備えた「リモートブランチシステム」であるのに対して、引用例1記載の発明は、「センタ端末」が「顧客端末を遠隔操作する」ものであるか明確でないため、「リモートブランチシステム」であるか明確でない点。

[相違点2]
本願発明の「運用管理端末」が、「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」と、「顧客端末で選択された業務が実行可能なセンタ端末をこのセンタ端末登録テーブルを参照して選択して前記顧客端末に通知する手段」を備えるのに対して、引用例1記載の発明の「運用管理端末」は、このようなセンタ端末登録テーブルを備え、このテーブルを参照してセンタ端末を選択していない点。

(4)当審の判断
[相違点1について]
相違点1に係る本願発明の構成は、相違点1に係る本願補正発明の構成と同一であり、前記2.(6)[相違点1について]で検討したとおり、相違点1に係る本願補正発明の構成は、引用例1記載の発明、引用例2記載の事項に基づいて、当業者が容易に想到し得たものであるから、相違点1に係る本願発明の構成も、引用例1記載の発明、引用例2記載の事項に基づいて、当業者が容易に想到し得たものである。

[相違点2について]
相違点2に係る本願発明の構成である「どのセンタ端末でどの業務が実行可能かを書換え可能に登録するセンタ端末登録テーブル」は、相違点2に係る本願補正発明の構成である「前記運用開始時に運用可能なセンタ端末から通知される実行可能な業務をそのセンタ端末を示す識別子と対応させて登録する書換え可能なセンタ端末登録テーブル」を上位概念化したものであり、 前記2.(6)[相違点2について]で検討したとおり、相違点2に係る本願補正発明の構成は、引用例1記載の発明、引用例3記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものであるから、相違点2に係る本願発明の構成も、引用例1記載の発明、引用例3記載の事項及び周知技術に基づいて、当業者が容易に想到し得たものである。

また、本願発明の作用効果も、引用例1-3から当業者が予測できる範囲のものである。

してみれば、本願発明は、引用例1記載の発明、引用例2、3記載の事項に基づいて、当業者が容易に発明することができたものである。

(5)むすび
以上のとおり、本願発明は、引用例1記載の発明、引用例2、3記載の事項に基づいて、当業者が容易に発明することができたものであるから、特許法第29条2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2008-08-19 
結審通知日 2008-08-26 
審決日 2008-09-08 
出願番号 特願平11-120665
審決分類 P 1 8・ 121- Z (G06Q)
P 1 8・ 575- Z (G06Q)
最終処分 不成立  
前審関与審査官 猪瀬 隆広  
特許庁審判長 赤穂 隆雄
特許庁審判官 ▲吉▼田 耕一
山本 穂積
発明の名称 リモートブランチシステム  
代理人 金倉 喬二  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ