2017-700412

特許第６０３８４７８号発明「営業支援システムおよびサーバ」の特許異議申立事件について、次のとおり決定する。

【結　論】 特許第６０３８４７８号の請求項１ないし１２に係る特許を維持する。

【理　由】 １．手続の経緯 特許第６０３８４７８号の請求項１～１２に係る特許についての出願は、平成２４年４月１２日に特許出願され、平成２８年１１月１１日にその特許権の設定登録がされ、その後、その特許に対し、特許異議申立人　河原田隆により特許異議の申立てがされたものである。 ２．本件発明 特許第６０３８４７８号の請求項１～１２の特許に係る発明は、それぞれ、その特許請求の範囲の請求項１～１２に記載された事項により特定されるとおりのものである。 ３．申立理由の概要 特許異議申立人　河原田隆は、以下の二点について主張している。 （３－１）特許法第２９条第２項の規定に違反している旨の主張について 証拠として 特開２０１０－０６６９９６号公報（以下「刊行物１」という。） 特開２０１１－０３４４２０号公報（以下「刊行物２」という。） 特開２０００－０９０１５６号公報（以下「刊行物３」という。） 特開２００１－２０９７１２号公報（以下「刊行物４」という。） 特開２００３－３４８２４１号公報（以下「刊行物５」という。） 特開２００２－０３２５７７号公報（以下「刊行物６」という。） 特開２００１－１０９８１５号公報（以下「刊行物７」という。） 特開２００１－２２９２８６号公報（以下「刊行物８」という。） 特開２００１－３５７０９９号公報（以下「刊行物９」という。） を提出し、請求項１～１２に係る特許は特許法第２９条第２項の規定に違反してされたものであるから、請求項１～１２に係る特許を取り消すべきものである旨の主張をしている。 （３－２）特許法第３６条第６項第１号の規定を満たしていない旨の主張について 請求項１の「前記訪問代理店端末を介して、前記営業担当者スケジュール情報および前記訪問客情報の表示要求を受け付けると、当該営業担当者スケジュール情報および訪問客情報を、当該訪問代理店端末に表示させ」、請求項７の「前記営業担当者が属する訪問代理店の端末を介して、前記営業担当者スケジュール情報および前記訪問客情報の表示要求を受け付けると、当該営業担当者スケジュール情報および訪問客情報を、当該訪問代理店端末に表示させる第二の表示指示部」は、発明の詳細な説明に記載されておらず、請求項１及びこれを引用する請求項２～請求項６に係る発明、並びに、請求項７及びこれを引用する請求項８～請求項１２に係る発明は、特許法第３６条第６項第１号の規定を満たしていないから、請求項１～１２に係る特許を取り消すべきものである旨の主張している。 ４．刊行物の記載 （１）刊行物１には、以下のとおりの記載がある。（下線は合議体が付与した。） 【０００１】 本発明は、効率的に集荷を行なうための集荷管理システム、集荷管理プログラム及び集荷管理方法に関する。 【００２４】 以下、本発明を具体化した一実施形態を、図１～図１４に従って説明する。本実施形態では、顧客からの依頼に基づいて、配送会社の集配担当者（ＳＤ：サービスドライバー）が、海外向けの配送品の集荷を行なう集荷サービスを提供する場合に用いる集荷管理システム、集荷管理プログラム及び集荷管理方法として説明する。 【００２５】 本実施形態では、図１に示すように、顧客端末１０、集荷管理サーバ２０、ＳＤ端末３０、オペレータ端末４０を用いる。 ここで、顧客端末１０は、配送を依頼する顧客が利用するコンピュータ端末である。そして、この顧客端末１０は、各顧客が集荷管理サーバ２０にアクセスする場合に用いられる。顧客端末１０は、ネットワークを介してデータを送信する機能や、受信したデータを表示する機能等を有する。このため、この顧客端末１０は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭの他、キーボード、マウス等の入力手段、ディスプレイ等の出力手段、印刷を行なうためのプリンタ等を備えている。 【００２６】 集荷管理サーバ２０は、集荷を管理するためのコンピュータシステムである。本実施形態では、集荷管理サーバ２０は、新規顧客登録のために、図１に示すように制御部２１や各種データベースを備えている。本実施形態では、顧客マスタデータベース２２Ａ、国別マスタデータベース２２Ｂ、駐車場所マスタデータベース２２Ｃ、ＳＤマスタデータベース２２Ｄ、集荷マスタデータベース２２Ｅを備えている。更に、随時集荷依頼データベース２２Ｆ、臨時集荷依頼データベース２２Ｇ、英語訳辞書データベース２２Ｈ、集荷ルートデータベース２２Ｊ、地図データベース２２Ｋを備えている。 【００２７】 この制御部２１は、制御手段としてのＣＰＵ、ＲＡＭ及びＲＯＭ等を有し、後述する処理（候補者特定段階、集荷順番特定段階、担当者連絡段階、顧客連絡段階等を含む処理）を行なう。このための集荷管理プログラムを実行することにより、制御部２１は、図１に示すように、集荷ルート設定手段２１１、依頼受付手段２１２、ＳＤ候補特定手段２１３、担当ＳＤ設定手段２１４、集荷リスト出力手段２１５等として機能する。 【００２８】 集荷ルート設定手段２１１は、定時集荷や、予め登録された随時集荷や臨時集荷に応じて、集配担当者毎に集荷ルートを決定する処理を実行する。 依頼受付手段２１２は、顧客からの随時集荷や臨時集荷の依頼を受け付ける処理を実行する。本実施形態では、特に、集配担当者による集荷の開始後に随時集荷や臨時集荷の依頼を受け付けた場合の処理を説明する。 【００２９】 ＳＤ候補特定手段２１３は候補者特定手段、集荷順番特定手段、担当者設定手段として機能する。具体的には、集荷開始後に受け付けた随時集荷や臨時集荷に対応する集配担当者の候補者を決定する処理を実行する。 【００３０】 担当ＳＤ設定手段２１４は、担当者連絡手段、顧客連絡手段として機能し、集荷開始後に受け付けた随時集荷や臨時集荷に対応する集配担当者を設定する処理を実行する。このために、担当ＳＤ設定手段２１４は、集配担当者に対して確認連絡を行なってから回答を待機する期限（待機期限）に関するデータを保持している。 【００３１】 更に、集荷リスト出力手段２１５は、後述する集荷ルートデータベース２２Ｊに記録された集荷ルートレコードＲＪ（図４参照）に基づいて、集荷リストを作成し、この集荷リストをＳＤ端末３０に対して提供する処理を実行する。そして、ＳＤ端末３０から、集荷完了情報を取得した場合には、集荷ルートデータベース２２Ｊに集荷完了フラグを記録する。 【００５６】 臨時集荷依頼データベース２２Ｇは、図４（ａ）に示すように、顧客登録が行なわれていない利用者からの臨時の集荷依頼についての臨時集荷依頼レコードＲＧを記録する。この臨時集荷依頼レコードＲＧは、顧客登録が行なわれていない利用者から臨時集荷依頼を受け付けた場合に記録される。臨時集荷依頼レコードＲＧは、住所、会社名、部署名、担当者名、希望日、時間帯、あて先、種別／数量、重量／サイズ、内容品、支払方法、ラベル要否、ラベル必要数、確認フラグ、担当ＳＤコードに関するデータを含んで構成される。 【００５７】 住所データ領域には、臨時集荷依頼を行なった利用者の住所に関するデータが記録される。 会社名データ領域、部署名データ領域には、臨時集荷依頼を行なった利用者の会社や部署の名称に関するデータが記録される。 【００５８】 担当者名データ領域には、臨時集荷依頼を行なった担当者の氏名に関するデータが記録される。 希望日データ領域、時間帯データ領域には、臨時集荷を行なう希望日や時間帯に関するデータが記録される。 【００６３】 集荷ルートデータベース２２Ｊは集荷情報記憶手段として機能し、図４（ｂ）に示すように、集配担当者が集荷を行なう集荷先についての集荷ルートレコードＲＪを記録する。この集荷ルートレコードＲＪは、集荷の順番が決定された場合に記録される。集荷ルートレコードＲＪは、月日、ＳＤコード、順番、住所、顧客コード、時間帯、種別／数量、駐車場所コード、集荷完了フラグに関するデータを含んで構成される。 【００６４】 月日データ領域には、各集荷を行なう日付に関するデータが記録される。 ＳＤコードデータ領域には、各集配担当者を特定するための識別子に関するデータが記録される。 【００６５】 順番データ領域には、集荷の順番に関するデータが記録される。 住所データ領域、顧客コードデータ領域には、集荷先の住所や、集荷先の顧客を特定する識別子に関するデータが記録される。 【００６６】 時間帯データ領域には、この集荷先において集荷を行なう時間帯に関するデータが記録される。 種別／数量データ領域には、この集荷先において集荷する荷物の種別や数量に関するデータが記録される。 【００６７】 駐車場所コードデータ領域には、この集荷を行なうために自動車の停車する駐車場所を特定するための識別子に関するデータが記録される。 集荷完了フラグデータ領域には、集荷の完了を特定するためのフラグに関するデータが記録される。 【００６９】 オペレータ端末４０は、配送会社において、顧客対応を担当するオペレータが利用するコンピュータ端末である。そして、このオペレータ端末４０は、各オペレータが集荷管理サーバ２０にアクセスする場合に用いられる。オペレータ端末４０は、ネットワークを介してデータを送信する機能や、受信したデータを表示する機能等を有する。このため、このオペレータ端末４０は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭの他、キーボード、マウス等の入力手段、ディスプレイ等の出力手段、印刷を行なうためのプリンタ等を備えている。本実施形態では、顧客から電話コールにより新規依頼を受け付けたオペレータが、このオペレータ端末４０を用いて集荷依頼を入力するために利用する。 【００７０】 また、本実施形態では、集配担当者との通信を行なう場合には、各集配担当者が携帯する携帯電話端末（ＳＤ端末３０）を用いる。このＳＤ端末３０は、通常の電話モードの他に、電子メールの送受信を行なうためのメールモードやブラウザモード各種プログラムの実行処理を行なうプログラム実行モードを有する。このＳＤ端末３０は、通信制御部、表示部３１、操作部３２を備える。 【００７１】 通信制御部は、公知の方法により携帯電話網の基地局に接続されて、通話や電子メールの送受信のための通信処理を行なう。この携帯電話網は、インターネットを介して集荷管理サーバ２０に接続される。 【００７２】 操作部３１は、ＳＤ端末３０において利用者の指示を受け付けるユーザーインターフェイスであり、ダイヤル番号ボタンの他に、セレクタボタン、モード変更ボタンを備えている。 【００７３】 表示部３２は、ディスプレイによって構成されており、ＳＤ端末３０が受信した電子メールやウェブページを出力する。 このＳＤ端末３０には、集荷順番に基づいて集荷先を一覧表示させた集荷リストが表示される。そして、集配担当者は、この集荷リストを確認して、順番に集荷先の顧客を訪問し、集荷を行なう。そして、集荷を完了した場合、集荷リスト上の完了アイコンを選択することにより、集荷完了情報を集荷管理サーバ２０に送信する。 【００７５】 集荷サービスの利用を希望する顧客は、顧客端末１０を用いて、集荷管理サーバ２０にアクセスする。 この場合、図９に示すように、集荷管理サーバ２０の制御部２１は、顧客端末１０に対して、パスワード登録画面５０１を提供する。このパスワード登録画面５０１は、図１０（ａ）に示すように、利用希望者のメールアドレスとパスワードを設定する入力欄が設けられている。そして、登録アイコンが選択された場合、顧客端末１０は、顧客登録依頼を集荷管理サーバ２０に送信する。この顧客登録依頼には、パスワード登録画面５０１において、設定されたメールアドレスとパスワードに関するデータを含める。 【００８９】 又、顧客登録されていないサービス利用希望者の場合には、配送会社に集荷の依頼の電話コールを行なう。この場合、このような電話コールに対して、オペレータが対応することになる。 【００９０】 ここで、オペレータはオペレータ端末４０を用いて、集荷管理サーバ２０にアクセスする。この場合、図９に示すように、オペレータ端末４０のディスプレイには、集荷依頼画面（臨時）５０６が出力される。 【００９１】 この集荷依頼画面（臨時）５０６には、図１２（ａ）に示すように、臨時の集荷の依頼内容を設定するための入力欄が設けられている。 オペレータは電話コールで受け付けた内容に基づいて、集荷依頼画面（臨時）５０６への入力を行なう。なお、このような顧客が顧客登録を希望する場合には、新規登録希望アイコンを選択する。この場合には、受け付けた内容が集荷マスタデータベース２２Ｅに登録される。 【００９２】 そして、各入力欄への設定を終了した場合、登録アイコンを選択する。この場合、顧客端末１０は、集荷依頼画面（臨時）５０６において入力された各情報を含めた登録依頼を、集荷管理サーバ２０に送信する。 【００９３】 そして、制御部２１は、登録依頼の各情報に基づいて、臨時集荷依頼レコードＲＧを生成し、臨時集荷依頼データベース２２Ｇに記録する。 そして、随時集荷依頼と同様に、集荷管理サーバ２０の制御部２１の依頼受付手段２１２は、顧客端末１０に対して、図９に示すように、集荷受付仮登録メール５０５を送信する。 【００９４】 この場合にも、後述するように、集荷管理サーバ２０の制御部２１は、図５に示す新規受付処理を実行する。 このように、随時集荷や臨時集荷についての依頼を、各データベース（随時集荷依頼データベース２２Ｆ、臨時集荷依頼データベース２２Ｇ）に登録する。ここで、各レコードには、集荷希望日が設定される。 【００９５】 一方、既に集荷ルートレコードＲＪが設定されており、集荷が開始されている場合には、後述する担当ＳＤ決定処理が行なわれる。この場合、オペレータ端末４０のディスプレイには、集配担当者の現在状況と、集荷順番候補が表示されるオペレータ管理画面５０７が出力される。このオペレータ管理画面５０７において、網掛は集荷済、太枠は現在の集荷中を表わす。そして、集荷順番候補は破線枠によって表されている。また、集荷担当候補者のＳＤ端末３０には、図９に示すように、ＳＤ依頼画面５０８が出力される。 【００９６】 そして、集荷を担当する集配担当者が決定された場合には、図９に示すように、集荷管理サーバ２０の制御部２１は、顧客端末１０に対して、集荷受付完了メール５０９を送信する。この集荷受付完了メール５０９には、図１２（ｂ）に示すメッセージを含める。 【０１１２】 （集荷開始後の依頼受付処理） 次に、集荷開始後の依頼受付処理について、図６を用いて説明する。ここでは、集荷開始後に、当日の随時集荷又は臨時集荷の依頼を受けた場合を想定する。そして、この処理においては、図７（ａ）に示す問い合わせテーブルＴを用いる。この問い合わせテーブルＴは、制御部２１のメモリに記録される。 【０１１３】 問い合わせテーブルＴには、ＳＤコード、未集荷量、駐車場所コード、距離、集荷予定時刻、優先順位、回答内容に関するデータが記録される。 ＳＤコードデータ領域には、新たな集荷依頼に対応する候補者（集配担当者）を特定するための識別子に関するデータが記録される。 【０１１４】 未集荷量データ領域には、この候補者における集荷状況を特定するためのデータが記録される。本実施形態では、未集荷の件数に関するデータが記録される。 駐車場所コードデータ領域には、新たな集荷依頼に対応する場合に自動車を駐車する場所を特定するための識別子に関するデータが記録される。 【０１１５】 距離データ領域には、駐車場所から集荷先の住所までの距離に関するデータが記録される。 集荷予定時刻データ領域には、この候補者が集荷先に到着する予想時刻に関するデータが記録される。 【０１１６】 優先順位データ領域には、この候補者に対して集荷を依頼する優先順位に関するデータが記録される。 回答内容データ領域には、この集配担当者からの回答（対応可否）に関するデータが記録される。 【０１１７】 そして、この問い合わせテーブルＴを用いて、以下の処理を実行する。 まず、集荷管理サーバ２０の制御部２１は、集荷受付仮登録メール送信処理を実行する（ステップＳ２－１）。具体的には、制御部２１の依頼受付手段２１２は、集荷依頼を行なった顧客のメールアドレスに対して、集荷受付仮登録メール５０５を送信する。 【０１１８】 次に、集荷管理サーバ２０の制御部２１は、集荷場所を含む地区、隣接地区の集配担当者の特定処理を実行する（ステップＳ２－２）。具体的には、制御部２１の依頼受付手段２１２は、顧客登録されたサービス利用希望者から新たに集荷依頼を受け付けた場合には、この集荷依頼について随時集荷依頼データベース２２Ｆに随時集荷依頼レコードＲＦを登録する。一方、オペレータ端末４０において、顧客登録されていないサービス利用希望者から新たに集荷依頼を受け付けた場合には、臨時集荷依頼データベース２２Ｇに臨時集荷依頼レコードＲＧを登録する。 【０１１９】 次に、制御部２１のＳＤ候補特定手段２１３は、新たに受け付けた依頼の集荷先の住所に基づいて、集荷先住所が含まれる地区、及びこの地区に隣接する隣接地区を特定する。そして、ＳＤ候補特定手段２１３は、ＳＤマスタデータベース２２Ｄを用いて、この地区及び隣接地区の集配担当者を候補者として特定する。そして、ＳＤ候補特定手段２１３は、候補者のＳＤコードを問い合わせテーブルＴに記録する。 【０１２０】 そして、集荷管理サーバ２０の制御部２１は、以下の処理を候補者毎に繰り返す。 ここでは、集荷管理サーバ２０の制御部２１は、各候補者の未集荷地区の特定処理を実行する（ステップＳ２－３）。具体的には、制御部２１のＳＤ候補特定手段２１３は、特定した集配担当者の集荷ルートレコードＲＪを集荷ルートデータベース２２Ｊから抽出する。そして、ＳＤ候補特定手段２１３は、集荷完了フラグが記録されていないレコードを特定する。 【０１２１】 次に、集荷管理サーバ２０の制御部２１は、各候補者の未集荷量の算出処理を実行する（ステップＳ２－４）。具体的には、制御部２１のＳＤ候補特定手段２１３は、未集荷の集荷ルートレコードＲＪに記録された未集荷の件数を未集荷量として算出する。そして、ＳＤ候補特定手段２１３は、未集荷量を問い合わせテーブルＴに記録する。 【０１２２】 次に、集荷管理サーバ２０の制御部２１は、各候補の未集荷地区の集荷ルートにおいて集荷順番候補の仮設定処理を実行する（ステップＳ２－５）。具体的には、制御部２１のＳＤ候補特定手段２１３は、集配担当者毎に、未集荷の集荷先を道路情報に基づいて繋ぎ合わせたルートを地図データベース２２Ｋの地図上に設定する。そして、ＳＤ候補特定手段２１３は、各候補者の未集荷の集荷先ルートにおいて、新たな集荷依頼の集荷先住所に最も近くなる位置を特定する。そして、ＳＤ候補特定手段２１３は、この位置の前後の集荷先を特定し、これらの集荷先における集荷予定時刻を取得する。そして、最寄りの位置に対して、前後各集荷先の距離に応じて、時間を分配して、新たに依頼を受けた集荷先における集荷予定時刻を算出する。この場合、オペレータ端末４０においては、図１３（ａ）に示すオペレータ管理画面５０７のように、新たに依頼があった集荷先の住所に基づいて、新たな集荷スケジュール候補が仮設定される。そして、ＳＤ候補特定手段２１３は、算出した集荷予定時刻を問い合わせテーブルＴに記録する。 【０１２９】 そして、集荷管理サーバ２０の制御部２１は、候補者毎に優先順位の決定処理を実行する（ステップＳ２－１１）。具体的には、制御部２１のＳＤ候補特定手段２１３は、問い合わせテーブルＴに記録された駐車候補地からの距離、混雑状況、未集荷量、集荷の希望時間帯との差分に対して、評価値テーブルを用いて評価値を付与する。具体的には、この評価値テーブルにおいては、駐車可能場所からの距離が短い方が高い評価値が順次付与される。又、混雑状況に対しては、混雑率が低い方が高い評価値が順次付与される。未集荷量に対しては、未集荷量が少ない方が高い評価値が順次付与される。 【０１３０】 集荷の希望時間帯については、ＳＤ候補特定手段２１３は、集荷予定時刻と、顧客が希望する希望時間帯との時間差を算出する。そして、この評価値テーブルにおいては、この時間差が少ない方が高い評価値が順次設定される。 そして、ＳＤ候補特定手段２１３は、集配担当者毎に各評価値の合計を算出し、合計値が高い順番に優先順位を付与し、問い合わせテーブルＴに記録する。 【０１３１】 （担当者確認処理） 次に、図７（ｂ）を用いて、担当者確認処理について説明する。 【０１３２】 ここでは、集荷管理サーバ２０の制御部２１は、集荷の候補者に確認連絡処理を実行する（ステップＳ３－１）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、集荷候補の各集配担当者のＳＤ端末３０に確認メッセージを送信する。この場合、図１３（ｂ）に示すように、ＳＤ端末３０のディスプレイに表示された集荷リスト画面５０８ａ上に着信メッセージが出力される。この場合、集荷担当者はＳＤ端末３０の確認連絡のアイコンを選択する。この場合、ＳＤ端末３０のディスプレイには、図１４に示すように，対応選択画面５０８ｂが出力される。ここでは、担当者ＡのＳＤ端末３０の画面を想定している。そして、第１候補の担当者Ｂが「対応不可（ＮＯ）」、第２候補の担当者Ａが「対応可能（ＹＥＳ）」の場合、ＳＤ端末３０のディスプレイには、図１４に示すように，対応選択画面５０８ｃが出力される。この結果、ＳＤ端末３０のディスプレイには、集荷リスト画面５０８ｄのように変更される。 【０１３３】 次に、集荷管理サーバ２０の制御部２１は、担当ＳＤ決定処理を実行する（ステップＳ３－２）。ここでは、制御部２１の担当ＳＤ設定手段２１４は、各集配担当者から受信した応答連絡に基づいて担当ＳＤ決定処理を実行する。この担当ＳＤ決定処理については、図８を用いて、後述する。 【０１３４】 次に、集荷管理サーバ２０の制御部２１は、他の集荷候補者に割当完了連絡処理を実行する（ステップＳ３－３）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、今回の集荷を担当する者以外の集配担当者のＳＤ端末３０に対して、割当完了メッセージを送信する。この場合、割当完了メッセージを受信したＳＤ端末３０は、着信表示を消去する。 【０１３５】 次に、集荷管理サーバ２０の制御部２１は、今回の依頼についての集配担当者についてのスケジュール登録処理を実行する（ステップＳ３－４）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、この集荷について集荷ルートレコードＲＪを生成し、集荷ルートデータベース２２Ｊに登録する。そして、随時集荷依頼レコードＲＦや臨時集荷依頼レコードＲＧに、この集配担当者のＳＤコードを設定する。 【０１３６】 そして、集荷管理サーバ２０の制御部２１は、受付完了メールの送信処理を実行する（ステップＳ３－５）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、集荷依頼を行なった顧客のメールアドレスに対して、受付完了メールを送信する。この受付完了メールには、集荷予定者名及び集荷予定時刻に関する情報を含める。 【０１３７】 （担当ＳＤ決定処理） 次に、担当ＳＤ決定処理について、図８を用いて説明する。 ここでは、集荷管理サーバ２０の制御部２１は、待機処理を実行する（ステップＳ４－１）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、送信した確認連絡に対する各集配担当者からの応答を待機する。そして、集荷管理サーバ２０が、各集配担当者からの応答連絡を受信した場合には、制御部２１のＳＤ候補特定手段２１３は、問い合わせテーブルＴに、その回答内容を記録する。 【０１３８】 そして、集荷管理サーバ２０の制御部２１は、定期的に集配担当者からの応答連絡の有無の確認処理を実行する（ステップＳ４－２）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、集荷管理サーバ２０メモリに記録された問い合わせテーブルＴにおいて、応答連絡について更新があったかどうかを確認する。 【０１３９】 集配担当者からの応答連絡がない場合（ステップＳ４－２において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、待機期限が到来したかどうかについて確認処理を実行する（ステップＳ４－３）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、確認連絡を行なってからの経過時間と待機期限とを比較する。待機期限が到来していない場合（ステップＳ４－３において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、待機処理を継続する（ステップＳ４－１）。 【０１４０】 一方、応答連絡があった場合（ステップＳ４－２において「ＹＥＳ」の場合）には、集荷管理サーバ２０の制御部２１は、最優先候補からの回答内容が記録されているかどうかについての確認処理を実行する（ステップＳ４－４）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、問い合わせテーブルＴにおいて、最優先の集配担当者についての回答かどうかを特定する。 【０１４１】 最優先候補の集配担当者からの回答が記録されていない場合（ステップＳ４－４において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、待機処理を継続する（ステップＳ４－１）。 【０１４２】 一方、最優先候補の集配担当者からの回答内容が記録されている場合（ステップＳ４－４において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、この最優先候補が対応可能かどうかについての確認処理を実行する（ステップＳ４－５）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、問い合わせテーブルＴにおいて対応可能の回答（受託回答）が記録されているかどうかを確認する。 【０１４３】 最優先候補が対応可能な場合（ステップＳ４－５において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、対応する集配担当者の決定処理を実行する（ステップＳ４－１１）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、この集荷依頼について、最優先候補を集配担当者の集荷ルートレコードＲＪを生成し、集荷ルートデータベース２２Ｊに記録する。そして、担当ＳＤ決定処理を終了する。 【０１４４】 一方、最優先候補が対応可能でない場合（ステップＳ４－５において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、他に候補者が残っているかどうかについての確認処理を実行する（ステップＳ４－６）。 【０１４５】 他に候補者が残っていない場合（ステップＳ４－６において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、アラーム出力処理を実行する（ステップＳ４－１０）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、オペレータ端末４０に集荷依頼に対応する集配担当者を決定することができなかったことを示すアラームを出力する。この場合には、オペレータが、直接、集配担当者に対して連絡を行ない、集荷対応の再検討を促す。 【０１４６】 一方、他に候補者が残っている場合（ステップＳ４－６において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、優先順位の変更処理を実行する（ステップＳ４－７）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、対応不可の集配担当者の優先順位を削除し、残っている集配担当者について現在の順位を維持しながら優先順位を更新する。これにより、次候補の集荷担当者が最優先候補に繰り上げられる。 【０１４７】 次に、集荷管理サーバ２０の制御部２１は、新たに特定された最優先候補（次候補）は回答済かどうかについての確認処理を実行する（ステップＳ４－８）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、新たに特定された最優先候補についての回答状況を特定する。 【０１４８】 新たに特定された最優先候補が回答済の場合（ステップＳ４－８において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、ステップＳ４－５以降の処理を繰り返す。 一方、次候補が未回答の場合（ステップＳ４－８において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、待機処理を継続する（ステップＳ４－１）。 【０１４９】 また、待機期限が到来している場合（ステップＳ４－３において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、対応可能な集配担当者がいるかどうかについての確認処理を実行する（ステップＳ４－９）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、問い合わせテーブルＴにおいて、対応可能の回答（受諾回答）を行なった集配担当者の有無を確認する。 【０１５０】 そして、対応可能な集配担当者がいない場合（ステップＳ４－９において「ＮＯ」の場合）、集荷管理サーバ２０の制御部２１は、アラーム出力処理を実行する（ステップＳ４－１０）。 【０１５１】 一方、対応可能な集配担当者がいる場合（ステップＳ４－９において「ＹＥＳ」の場合）、集荷管理サーバ２０の制御部２１は、集配担当者の決定処理を実行する（ステップＳ４－１１）。具体的には、制御部２１の担当ＳＤ設定手段２１４は、問い合わせテーブルＴにおいて、優先順位が最も高い集配担当者を、集荷依頼に対応する集配担当者として決定する。そして、担当ＳＤ設定手段２１４は、今回の集荷依頼について、優先順位が最も高い集配担当者の集荷ルートレコードＲＪを生成し、集荷ルートデータベース２２Ｊに記録する。 以上の刊行物１の記載によれば、刊行物１には以下のとおりの発明が開示されている。（以下、刊行物１発明という。） 顧客登録が行なわれていない利用者からの臨時の集荷依頼についての臨時集荷依頼レコードＲＧを記録する臨時集荷依頼データベース、 集荷ルートレコードＲＪ（月日、ＳＤコード、順番、住所、顧客コード、時間帯、種別／数量、駐車場所コード、集荷完了フラグに関するデータを含む）を記録する集荷ルートデータベースを有する集荷管理サーバと、 臨時の集荷依頼を顧客対応を担当するオペレータが受けると、オペレータは電話コールで受け付けた内容に基づいて、集荷依頼画面（臨時）５０６への入力を行なうオペレータ端末と、 各集配担当者が携帯する携帯電話端末（以下、ＳＤ端末という。ＳＤは、配送会社の集配担当者（サービスドライバー）のこと）と、を備え、 集荷管理サーバは、 オペレータ端末を介して受け付けた内容を集荷マスタデータベースに登録すると、新たに受け付けた依頼の集荷先の住所に基づいて、集荷先住所が含まれる地区、及びこの地区に隣接する隣接地区を特定し、この地区及び隣接地区の集配担当者を候補者として特定し、各候補者の未集荷の集荷先ルートにおいて、新たな集荷依頼の集荷先住所に最も近くなる位置を特定し、この位置の前後の集荷先を特定し、これらの集荷先における集荷予定時刻を取得し、最寄りの位置に対して、前後各集荷先の距離に応じて、時間を分配して、新たに依頼を受けた集荷先における集荷予定時刻を算出し、新たに依頼があった集荷先の住所に基づいて、新たな集荷スケジュール候補を仮設定し、候補者毎に優先順位の決定処理を実行し、集荷候補の各集配担当者のＳＤ端末に確認メッセージを送信し、送信した確認連絡に対する各集配担当者からの応答を待機し、対応可能の回答の回答をした各集配担当者のうち優先順位の高い集配担当者を今回の集荷依頼について集配担当者とし、 集配担当者のＳＤ端末に、集荷リスト画面表示させ、 ＳＤ端末から、集荷完了情報を取得した場合には、集荷ルートデータベースに集荷完了フラグを記録する ことを特徴とする集荷管理システム。 （２）刊行物２には、以下のとおりの記載がある。 【００１７】 図２は、本発明の第一の実施形態に係るハードウェア（システム）構成を示す図である。携帯電話（２０１）は、訪問営業マンが持つ機器で、その画面は、図４および図５が表示されることとする。無線端末基地局（２０２）は、携帯電話（２０１）との接続を行う機器であり、それぞれ固有の場所の情報を持っていることとする。無線端末基地局（２０３）も同様である。インターネット（２０４）は、無線端末基地局（２０２）（２０３）とＬＡＮ（２０５）を結び、かつ、交通事故情報サービス（２０８）とＬＡＮ（２０５）を結ぶ回線である。ＬＡＮ（２０５）は、外部のインターネット回線（２０４）と内部のデータベース（２０６）、管理端末（２０７）を結ぶ回線である。データベース（２０６）は、図３で説明するテーブルを有するもので、携帯電話（２０１）や管理端末（２０７）からの入力を受け付け、あるいは、携帯電話（２０１）や管理端末（２０７）からの要求に応じて情報を出力する。管理端末（２０７）は、企業内部の管理者が利用する機器であり、その画面は図６で説明する。交通事故情報サービス（２０８）は、例えば鉄道会社や道路管理会社が提供する事故情報を通達するサービスである。 【００１８】 図３は、本発明の第一の実施形態に係るテーブル項目を示す図である。スケジュール情報テーブル（３０１）は、各訪問営業マンがいつ、どこに訪問するかを記載するテーブルであり、詳細は図７に示す。訪問先情報テーブル（３０２）は、各訪問先の場所や連絡電話番号を記載するテーブルであり、その詳細を図８に示す。通常時交通リスク情報テーブル（３０３）は、通常時の交通リスクを記載するテーブルである。たとえ、通常時であっても、時間帯や、快速に乗車できる、できないなどによって移動時間に幅が生じるため、その時間の幅をリスクとして情報を管理する。事故時交通リスク情報テーブル（３０４）は、事故時の交通リスクを記載するテーブルである。交通事故外部情報テーブル（３０５）は、外部の交通事故情報サービス（２０８）を企業内部に取り入れたテーブルである。なお、本実施形態は、企業に限定せず、ある組織であれば適用可能である。また、これらの情報が、課題を解決するための手段における「交通状況情報」に対応する。 【００１９】 図４は、本発明の第一の実施形態に係る携帯端末の通常時の表示内容を示した図である。プルダウンメニュー（４０１）は、本日予定の内容を示す。プルダウンメニュー（４０２）は、直近予定の内容、つまり、すぐ次の予定内容を示す。プルダウンメニュー（４０３）は、現在の状態内容を示す。 【００２０】 訪問先表示（４０４）（４０５）（４０６）は、本日の予定が表示される。この図では３件分だが、画面に記載しきれない場合には、「次の予定」などのボタンを用意し、ボタンが押下されたら、その次の予定内容を表示するという方式にしてもよい。 【００２１】 訪問先表示（４０７）は、直近予定の訪問先を表示する。直近とは、現在訪問中の次であってもよいし、また、スケジュールで現時刻の訪問先の次に訪問する訪問先のいずれでもよい。平均時間表示（４０８）は、直近予定の訪問先までの移動にかかる平均時間を示す。この計算は、図１１、図１２、図１３、図１４、図１５、図１７により、図１７のＳ１７０４またはＳ１７０７にて出力される。最短・最長時間表示（４０９）は、直近予定の訪問先までの移動にかかる最短あるいは最長時間を示す。この計算は、図１１、図１２、図１３、図１４、図１５、図１７により、図１７のＳ１７０５あるいはＳ１７０６、または、Ｓ１７０８あるいはＳ１７０９にて出力される。 【００２７】 図６は、本発明の第一の実施形態に係る管理端末の表示内容を示した図である。 営業マンプルダウンメニュー（６０１）は、訪問する営業マンを選択するメニュー項目である。業務年月日プルダウンメニュー（６０２）は、スケジュール対象の年月日を指定するメニュー項目である。他の表示項目は、図４あるいは図５と同様である。 【００２８】 図７は、本発明の第一の実施形態に係るスケジュール情報テーブルを示した図である。年月日列インデックス（７０１）は、スケジュールの年月日を示す。開始時間列インデックス（７０２）は、スケジュールの個々の項目の開始時間を示す。終了時間列インデックス（７０３）は、スケジュールの個々の項目の終了時間を示す。内容列インデックス（７０４）は、スケジュールの個々の項目の内容を示す。例えば、東様打合せ、であるとか、本田様ご契約、などである。場所列インデックス（７０５）は、スケジュールの個々の項目が実施される場所を示す。スケジュールを登録する際、これらのインデックス（７０１）～（７０５）を記載するものとする。 （３）刊行物３には、以下のとおりの記載がある。 【００３８】Ｃ．動作説明 Ｃ－１．スケジュール入力 図８は、本発明の好適な実施例におけるスケジュール入力手順を示すフローチャートである。まず、図１３に示すように、オペレータによって、スケジュール入力対象のユーザが選択され、スケジュール入力を指示するアイコンをクリックすると、本発明の好適な実施例におけるスケジュール入力手順が開始される（ブロック４０１、４０３）。 【００３９】手順が開始されると、まず、制御部１０５は、ユーザ名（ユーザインデックス情報）、基準となるユーザのスケジュールの特定日を取得し、図１３に示すような複数ユーザの特定日のスケジュール行が合計された合計行３１７を生成することを合計スケジュール行生成部１１３に指示する。表示制御部１０７は、合計スケジュール行生成部１１３により生成された情報を反映させ、表示部１０９に渡す。これにより、表示画面に合計行３１７が表示される。 【００４０】なお、本発明の好適な実施例において、ユーザの追加のオペレーション（例えば合計行に指定されたメンバー以外のメンバーがドラッグドロップされた等）がなされたと判断した場合には、制御部１０５は、そのユーザ名を取得し、合計スケジュール行生成部１１３に合計行３１７の再作成を指示する。 【００４１】そして、オペレータによるスケジュール内容の入力を検出した場合、合計行３１７の上でマウスドラッグ操作を行われたか、スケジュール表示ウインドウ３００のユーザスケジュール行３１１、３１３でマウスドラッグ操作を行われたかを判別することにより、入力対象スケジュールは、複数ユーザを対象としているか否かを判別する。 【００４２】なお、合計行３１７の上でマウスドラッグ操作が行われた場合や、スケジュール表示ウインドウ３００のユーザスケジュール行３１１、３１３でマウスドラッグ操作が行われた場合には、制御部１０５は、合計スケジュール行生成部１１３やスケジュール表示ウインドウ生成部１１１にスケジュールバーの生成を指示するとともに、スケジュールデータ入力パネル生成部１１７に図１４に示すようなスケジュールデータ入力パネルの生成を指示する。なお、本発明の好適な実施例のスケジュールデータ入力パネル７００には、メンバータグ７１９が提供されており、スケジュール入力するメンバーの参照およびその追加／削除が可能になっている。 （４）刊行物４には、以下のとおりの記載がある。 【００１５】本実施の形態の訪問支援システムは、情報要求元１（営業マンのノートパソコン、各地域の営業所、受注センタ等）及びお客のパソコンがネットワーク２（ｉｎｔｒｎｅｔ、ＷＡＮ、携帯電話網等）を介して本社サーバ３から所望の情報を転送させるシステムであり、本社サーバ３はお客のパソコン以外の情報要求元１に対しては、その情報要求元１の管理地域の地図情報、その地域の社員及び顧客情報に関連する全ての情報（以下営業活動支援情報という）を転送し、情報要求元１のパソコンは、指示に従って本社サーバ３から転送された情報を用いて指示された訪問支援画面を表示する。 （５）刊行物５には、以下のとおりの記載がある。 【００５８】送信要求を受信した管理コンピュータ２１は、受付識別子に基づいて受付データ記憶部２５から受付データ２５０を抽出する。そして、抽出した受付データ２５０に基づいてサービス情報をサービス担当者端末４０に送信する。このサービス情報には、顧客識別子、受付時刻、顧客の電話番号、機器識別子や問診結果に関するデータが含まれる。サービス担当者は、顧客識別子を用いて顧客データ記憶部２２に記録された顧客情報を引き出す。そして、顧客の電話番号を用いて顧客に連絡を行ない、訪問時刻の決定を行なう。 （６）刊行物６には、以下のとおりの記載がある。 【００４２】次に、前述したようにして振り分け決定した代理店へ顧客情報を送付するためのメール本文作成および発信処理について説明するに、以下の（１）項から（４）項の順に処理を行う。 （１）代理店宛メール送付 見込み客情報マスターファイル１２３の状態管理フラグが空欄もしくは「１」のレコードを選択して図１６に例示したような設定で決定代理店へメールを発信する。この場合におけるメール画面イメージの一例を、図１７に示している。このようなメールの発信終了後、見込み客情報マスターファイル１２３の経過管理フラグに送付済みフラグ「２」をたてる。 （２）初回担当者宛メール送付 見込み客情報マスターファイル１２３の状態管理フラグが空欄もしくは「２」のレコードを選択して図１８に例示したような設定で代理店担当者へメールを発信する。この発信の終了後、見込み客情報マスターファイル１２３の経過管理フ ラグに、担当者宛メール送付済みフラグ「３」をたてる。（３）第２回担当者宛メール送付 見込み客情報マスターファイルの状態管理フラグが「３」のレコードを選択してそのレコードのファイル追加日時が５日以上前の場合、図１９に例示したような設定で代理店担当者へメールを送付する。これは、折衝が遅れている旨の督促メールである。この発信終了後、見込み客情報マスターファイル１２３の状態管理フラグに担当者宛メール送付済みフラグ「４」をたてる。 （４）第３回担当者宛メール送付 見込み客情報マスターファイル１２３の状態管理フラグが「４」のレコードを選択して、そのレコードのファイル追加日時が１０日以上前の場合、図２０に例示するような設定で代理店担当者へメールを送付する。この発信終了後は、見込み客情報マスターファイル１２３の経過管理フラグに担当者宛メール送付済みフラグ「５」をたてる。 （７）刊行物７には、以下のとおりの記載がある。 【００２０】次に、制御装置１０７は、記憶装置１０９の派遣候補者領域に格納されている外出者の位置情報をもとに、各外出者と顧客との距離を計算し、その距離を所要時間に換算する処理を行い、記憶装置１０９の派遣候補者領域に付加する（Ｓ３４）。さらに、制御装置１０７は、応答してきた各外出者の最終作業の終了予定時刻（帰社途中の場合には応答時刻）に顧客までの所要時間を加算して顧客への到着予定時刻を算出し、記憶装置１０９の派遣候補者領域に付加する（Ｓ３５）。このときの記憶装置１０９の派遣候補者領域の状態を図５に示す。次に、制御装置１０７は、各外出者の顧客への到着予定時刻をもとに昇順にソートを行い、その結果により記憶装置１０９の派遣候補者領域を書き換える（Ｓ３６）。このときの記憶装置１０９の派遣候補者領域の状態を図６に示す。 【００２１】図１１は、派遣候補者の中から派遣する外出者の決定Ｓ４の処理手順の一例を示す。制御装置１０７は、記憶装置１０９から派遣候補者となる外出者の人数をカウントし、派遣候補者がいるか否かを判断する（Ｓ４１）。ここで、人数がゼロの場合には、端末１１１に「適当な派遣候補者はおりません」というメッセージを表示し、受付担当者に通知する（Ｓ４２）。一方、人数がゼロでない場合には、制御装置１０７は、記憶装置１０９の派遣候補者領域の最上位の外出者（顧客への到着予定時刻が最も早い者）のＰＨＳに発信し（Ｓ４３）、さらにスイッチ１０１を制御して音声応答装置１０３を接続し、「本日の作業が終了次第、△△市□□町の○○様へ向かって下さい。了解ならば０、都合が悪ければ１を押して下さい。了解の場合は○○様の依頼の状況を録音で聞けますので、電話を切らないで下さい。」というガイダンスを送る（Ｓ４４）。このガイダンスを聞いた外出者が応答する「０」または「１」のＰＢ信号はＰＢ信号受信器１０５に受信され、制御装置１０７で外出者の応答が判断される（Ｓ４５）。 （８）刊行物８には、以下のとおりの記載がある。 【００３２】ＩＤ番号はその営業担当者に付与されたコード番号（担当者番号）であり、パスワードは暗証番号としてその担当者に設定された担当者のみが知る番号であるから、本人認証はこのＩＤとパスワードにより確保される。支援管理センターのサーバ１は、ＩＤ番号とパスワードを入力すると、担当者データベース２２を検索してそのＩＤ番号とパスワードの正誤を判定し（ステップＳ２）、ＩＤ番号とパスワードが正しい場合、ステップＳ４に進み、当該担当者用のメニュー画面を送信する。一方、ＩＤ番号とパスワードが誤っている場合、ステップ３でその誤りを指摘する画面を携帯端末２に送り、ＩＤ番号とパスワードの再入力を促す。 （９）刊行物９には、以下のとおりの記載がある。 【００３２】「パスワード」とは、ユーザ識別ＩＤと対応付けられたワードをいう。パスワードは、ユーザ識別ＩＤ１つに対して１つであってもよいが、ログインの度に異なるパスワードであって、かつユーザ識別ＩＤと対応できるものであるワンタイムパスワードである場合には機密保護がより強固になる。 ５．判断 （１）特許法第２９条第２項の規定に違反している旨の主張について 請求項１に係る発明と刊行物１発明とを対比すると、刊行物１発明は、 「（サーバが）前記コールセンター端末を介して前記営業担当者スケジュール情報の表示要求を受け付けると、当該営業担当者スケジュール情報を当該コールセンター端末に表示させると共に、表示された当該営業担当者スケジュール情報に対してアポイントが取れた顧客への訪問予定の追加指示と、訪問先の顧客の住所の入力とを受け付け、 前記訪問予定の追加指示と、前記顧客の住所の入力を受け付けると、前記営業担当者スケジュール情報ＤＢおよび前記訪問客情報ＤＢを更新し、 営業担当者スケジュール情報に訪問予定が入力された営業担当者宛に、スケジュールが更新された旨を通知する通知情報を生成して電子メール送信」 する構成を有していない。 この点は、刊行物２ないし９にも記載されていない。したがって、請求項１に係る発明は、上記刊行物１に記載された発明及び刊行物２ないし９に記載された技術的事項から当業者が容易になし得るものではない。 特許異議申立人河原田隆は、当該構成について、刊行物１に記載されているとしているが、刊行物１に記載された発明では、メールで送信されるのは、「（スケジュールを変更可能であるか確認させるための）確認メッセージ」であり、「スケジュールが更新された旨を通知する通知情報」ではなく、「訪問予定」の意味が、本願請求項１に係る発明では、訪問することが確定した予定であり、刊行物１発明では、訪問者がその予定を確認するための訪問予定であって、そもそも異なるのであるから、特許異議申立人の主張は採用することができない。 また、請求項２ないし請求項６に係る発明は、請求項１に係る発明を更に減縮したものであるから、上記請求項１に係る発明についての判断と同様の理由により、上記刊行物１に記載された発明及び刊行物２ないし９に記載された技術的事項から当業者が容易になし得るものではない。 さらに、請求項７に係る発明は、請求項１に係る発明が「営業支援システム」であるところ、これに用いられる「管理サーバ」を特定した発明であって、上記刊行物１発明が有していない構成と同等の「営業担当者スケジュール情報に訪問予定が入力された営業担当者宛に、スケジュールが更新された旨を通知する通知情報を生成して電子メール送信する送信部」を有していないから、上記請求項１に係る発明についての判断と同様の理由により、上記刊行物１に記載された発明及び刊行物２ないし９に記載された技術的事項から当業者が容易になし得るものではない。 そして、請求項８ないし請求項１２に係る発明は、請求項７に係る発明を更に減縮したものであるから、上記請求項７に係る発明についての判断と同様の理由により、上記刊行物１に記載された発明及び刊行物２ないし９に記載された技術的事項から当業者が容易になし得るものではない。 （２）特許法第３６条第６項第１号の規定を満たしていない旨の主張について 以下では、「営業担当者スケジュール情報」と「訪問客情報」とに分けて検討する。 （ｉ）営業担当者スケジュール情報について 発明の詳細な説明には以下のとおりの記載がある。（下線は合議体が付与した。） 「営業担当者は、スケジュールが更新された旨を通知する通知情報を管理サーバ１０から取得し、訪問代理店端末３０を使って管理サーバ１０に格納されている自身のスケジュールや訪問先を確認する。」（【００１２】） 「図３は、営業担当者スケジュール情報２１０の一例を示した図である。図示するように、営業担当者スケジュール情報２１０には、所定年月日２１１と、訪問代理店の営業担当者名２１２と、時間帯ごとの各営業担当者の予定情報２１３と、が対応付けられて登録されている。 このような営業担当者スケジュール情報２１０は、顧客の訪問日時を入力するオペレーターに用いられる。また、自身のスケジュールを入力する営業担当者に用いられる。」（【００２０】、【００２１】） 「訪問代理店端末３０は、保険の営業代理業務を行っている訪問代理店に設置され、管理サーバ１０内の情報を表示させたり、かかる情報に入力を行うための装置である。」（【００２８】） これらの記載によれば、営業担当者は、訪問代理店端末を用いて、自身のスケジュールを確認したり、自身のスケジュールを入力したりすること、および、上記「確認」や「入力」の際には、営業担当者スケジュール情報を利用することが開示されているといえる。 そして、自身のスケジュールの「確認」や「入力」の際に、営業担当者スケジュール情報を利用するためには、当該情報を訪問代理店端末に表示させることは明白であり、営業担当者は、スケジュールの確認や入力を行うために、訪問代理店端末から、当該スケジュールの表示を要求し、サーバは、訪問代理店端末に営業担当者スケジュール情報を訪問代理店端末に表示させる技術思想は、これらの記載から読み取ることができるから、「前記訪問代理店端末を介して、前記営業担当者スケジュール情報の表示要求を受け付けると、当該営業担当者スケジュール情報を、当該訪問代理店端末に表示させ」ることについての記載はないということはできない。 （ｉｉ）訪問客情報について 発明の詳細な説明には以下のとおりの記載がある。（下線は合議体が付与した。） 「次に、訪問代理店端末３０に訪問客情報２２０の確認画面情報を表示させる処理について説明する。図１２は、かかる処理の流を示したシーケンス図である。なお、確認画面情報は、情報内容の確認に用いられるもので、情報の入力を受け付けるものではない。 訪問代理店端末３０は、営業担当者からの要求に応じて、管理サーバ１０へログインする（Ｓ０２１）。 次に、訪問代理店端末３０の全体制御部３２１は、営業担当者からの要求に応じて、管理サーバ１０に格納されている訪問客情報２２０の確認画面要求信号を生成し、これを管理サーバ１０へ送信する（Ｓ０２２）。 具体的には、訪問代理店端末３０の全体制御部３２１は、所定の情報入力画像を生成し、営業担当者が表示を要求する訪問客を特定するための情報の入力を受け付ける。例えば、訪問代理店端末３０の全体制御部３２１は、更新通知情報によって営業担当者に通知されている訪問客の会員番号２２１の入力を受け付ける。営業担当者から訪問客の会員番号２２１の入力を受け付けると、訪問代理店端末３０の全体制御部３２１は、入力された会員番号で特定される訪問客情報２２０の確認画面要求信号を生成し、これを管理サーバ１０に送信する。 確認画面要求信号を受信した管理サーバ１０の全体制御部３１１は、営業担当者スケジュール情報２１０＜当審注：営業担当者スケジュール情報２１０は、訪問客情報２２０の誤りと認める。＞の確認画面情報を生成し、これを訪問代理店端末３０に送信する（Ｓ０２３）。訪問客情報２２０の確認画面情報を取得すると、訪問代理店端末３０の出力処理部３２３は、これを出力装置５に表示する（Ｓ０２４）。 図１９は、訪問客情報２２０の確認画面情報が表示された訪問代理店端末３０の画面例４２１である。営業担当者は、表示された訪問客情報２２０の内容により、アポイントが取れた顧客５０の住所などを確認することができる。なお、このような訪問先情報の確認画面情報は、印刷ボタン４２２を押下することにより、訪問代理店端末３０に接続されているプリンタから印刷することができる。」（【００５６】－【００６１】） これらの記載によれば、訪問代理店端末を用いて、訪問客情報の確認画面要求信号を受信した管理サーバは、訪問客情報の確認画面情報を生成し、訪問代理店端末に表示させることが記載されているから、「前記訪問代理店端末を介して、前記訪問客情報の表示要求を受け付けると、訪問客情報を、当該訪問代理店端末に表示させ」ることについて記載されている。 （ｉｉｉ）まとめ 以上（ｉ）、（ｉｉ）の検討によれば、発明の詳細な説明には、「訪問代理店端末を介して、前記営業担当者スケジュール情報および前記訪問客情報の表示要求を受け付けると、当該営業担当者スケジュール情報および訪問客情報を、当該訪問代理店端末に表示させ」ることが記載されているといえるから、請求項１の「前記訪問代理店端末を介して、前記営業担当者スケジュール情報および前記訪問客情報の表示要求を受け付けると、当該営業担当者スケジュール情報および訪問客情報を、当該訪問代理店端末に表示させ」、請求項７の「前記営業担当者が属する訪問代理店の端末を介して、前記営業担当者スケジュール情報および前記訪問客情報の表示要求を受け付けると、当該営業担当者スケジュール情報および訪問客情報を、当該訪問代理店端末に表示させる第二の表示指示部」は、発明の詳細な説明に記載されており、請求項１及びこれを引用する請求項２～請求項６に係る発明、並びに、請求項７及びこれを引用する請求項８～請求項１２に係る発明は、特許法第３６条第６項第１号の規定を満たしていないという特許異議申立人の主張は、採用することができない。 ６．むすび したがって、特許異議の申立ての理由及び証拠によっては、請求項１～１２に係る特許を取り消すことはできない。 また、他に請求項１～１２に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。