平成22年 (行ケ) 10003号審決取消請求事件

運営：アスタミューゼ株式会社

会員機能

判例データベース

審決データベース

ポートフォリオ機能

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

この判例の個人情報、企業機密に関する修正依頼をする

関連ワード	承継 / 29条1項3号 / インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 一致点の認定 / 公知技術 / 下位概念 / 技術的範囲 / 技術常識 / 発明の詳細な説明 / 共有 / クレーム / 技術的意義 / 発明の要旨認定 / 容易に想到(容易想到性) / 特許発明 / 実施 / 加工 / 交換 / 具体的態様 / 請求の範囲 / 変更 /

関連ワード

承継 / 29条1項3号 / インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 一致点の認定 / 公知技術 / 下位概念 / 技術的範囲 / 技術常識 / 発明の詳細な説明 / 共有 / クレーム / 技術的意義 / 発明の要旨認定 / 容易に想到(容易想到性) / 特許発明 / 実施 / 加工 / 交換 / 具体的態様 / 請求の範囲 / 変更 /

元本PDF	裁判所収録の全文PDFを見る

事件	平成 22年 (行ケ) 10003号審決取消請求事件
事件	裁判所のデータが存在しません。
裁判所	知的財産高等裁判所
判決言渡日	2010/10/19
権利種別	特許権
訴訟類型	行政訴訟

判例全文
判例全文平成２２年（行ケ）第１０００３号審決取消請求事件（特許）口頭弁論終結日平成２２年１０月５日判決原告ＪＦＥシステムズ株式会社訴訟代理人弁護士上山浩同小長谷真理訴訟代理人弁理士高矢諭被告株式会社ベルシステム２４ ※（ただし，平成２２年６月１日に，本訴提起時の被告であった株式会社ベルシステム２４（承継前被告）を吸収合併した株式会社ＢＣＪ?４が同日付けで商号を承継後株式会社ベルシステム２４に変更したもの）訴訟代理人弁護士野口明男同三好豊同飯塚卓也訴訟代理人弁理士原島典孝主文１原告の請求を棄却する。２訴訟費用は原告の負担とする。事実及び理由第１請求特許庁が無効２００９?８００１００号事件について平成２１年１１月３０日にした審決を取り消す。第２事案の概要，「」１本件は名称をコールセンタシステム及びプレディクティブダイヤラ装置とする発明についての特許第３５０５４６０号（出願日平成１２年２月１７日，登録日平成１５年１２月１９日，請求項の数１４，甲４。以下「本件特許」という）の請求項１（以下「本件発明」という）に対し，被告が特許権。。者である原告を被請求人として特許無効審判請求をしたところ，特許庁が特許法29条2項違反を理由としてこれを認容する審決をしたことから，これに不服の原告が取消しを求めた事案である。２争点は，本件発明が，下記引用例１及び２との関係で進歩性を有するか（特許法29条2項，である。）記・引用例１：米国特許第４７９７９１１号明細書（発明の名称「顧客アカウント・オンラインサービスシステム，特許登録日平成元年（１９８９年）１」月１０日，甲１。以下これに記載された発明を「引用発明１」という）。・引用例２：特開平９?２５２３５１号公報（発明の名称「発呼制御方法，公」，。「」開日平成９年９月２２日甲２以下これに記載された発明を引用発明２という）。第３当事者の主張１請求の原因 (1) 特許庁における手続の経緯原告（旧商号川鉄情報システム株式会社）は，本件特許の特許権者であるところ，被告は，平成２１年５月１８日，本件特許の請求項１に対し，本件，（，）発明は引用発明１と同一である特許法 29条1項3号違反無効理由１又は引用発明１及び２から当業者が容易にその発明をすることができた（同条２項違反，無効理由２）ことを理由として，無効審判請求をした。特許庁は，上記請求を，無効２００９?８００１００号事件として審理した上，平成２１年１１月３０日「特許第３５０５４６０号の請求項１に係，る発明についての特許を無効とする」旨の審決をし，その謄本は同年１２。月１０日原告に送達された。 (2) 発明の内容本件特許の請求項の数は１４であるところ，その請求項１（本件発明）の内容は，次のとおりである。「顧客情報を管理しているデータベースからプレディクティブ発信を行うデータを所定の条件で抽出して，プレディクティブ発信用のデータベースを作成した後，該プレディクティブ発信用のデータベースで選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて，顧客から着信する通話によるインバウンド業務，インターネット，電子メール，又はその他の事務部門における該顧客からのコンタクトにより，プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に，該プレディクティブ発信用のデータベースから抽出された発信データを，プレディクティブ発信時に，電話番号又は他の顧客識別情報をキーとして，指定されたデータベースを指定された条件で検索することにより，該発信不要データであると判定された場合には，その発信を中止するリアルタイムコール止めを行うことを特徴とするコールセンタシステム」。 (3) 審決の内容，。，，ア審決の内容は別添審決写しのとおりであるその要点は本件発明は引用発明と同一とはいえないが，引用発明１及び２に基づいて当業者が容易に発明することができたから特許法 29条2項により特許を受けることができない，というものである。イなお，審決が認定した引用発明１及び２の内容は，次のとおりである。・引用発明１の内容「顧客のアカウント情報を管理しているデータベース（メインフレームコンピュータ（１６）内）からプレディクティブ発信を行う所望の数の顧客アカウント情報が転送され，所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っている顧客オンラインサービスシステムにおいて，特定の顧客からの着信，請求に対する支払いにより，プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に，メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ，該発信不要データであると判定された場合には，新しい発信の必要性を計算する（ステップ２８）顧客オンラインサービスシステム」。・引用発明２の内容「発信データを発信不要データベースに照会して発信不要データであると判定するにあたり，電話番号をキーとして，発信不要データベースを指定された条件で検索する，プレディクティブ発信制御方法」。 (4) 審決の取消事由しかしながら，審決には，容易想到とした判断に関し，以下のような誤りがあるから，審決は違法として取り消されるべきである。ア取消事由１（本件発明の要旨認定の誤り）本件発明は，バッチ処理でのプレディクティブ発信用データベース（以下，データベースを「ＤＢ」と称することがある）作成処理を行う従来。技術のシステム構成を前提としつつ，バッチ処理によりリアルタイム性が妨げられていた問題を解決すべく，発信不要データを指定されたＤＢに記録し，プレディクティブ発信時に当該指定されたＤＢを検索することで，リアルタイムでコール止めを行うことを可能にした点に特徴がある。審決は，本件発明を正しく把握せず，本件発明の上記の特徴部分の認定を誤ったものである。すなわち，予めプレディクティブ発信用ＤＢをバッチ処理で作成しておく従来技術のコールセンタシステムでは，一旦プレディクティブ発信用データが作成された後に発信不要データが生じた場合，発信作業は，既に作成されて内容が固定されたプレディクティブ発信用ＤＢを用いて行われるため，発信不要データが顧客マスタＤＢに書き込まれたとしても，それを発信業務にすぐに反映させることができないという問題があった。この場合，発信業務を発信不要データの発生に対応させるためには，従来技術では，改めてバッチ処理を実行して顧客マスタＤＢから該当するデータを検索・抽出し，プレディクティブ発信用ＤＢに反映させるか，あるいはオペレータの操作を介在させて顧客マスタＤＢに書き込まれた発信不要データをプレディクティブ発信用ＤＢに反映させることが必要であった。しかし，これらの作業には一定の時間を要するため，タイムラグが生じてしまい，結局，従来技術では，発信不要データが発生しても，リアルタイムでコール止めを行うことができないという問題点があった。本件発明は，プレディクティブ発信用ＤＢ作成を行うという従来の構成，，，を踏襲しつつ上記の問題を解決した発明でありその課題解決の方法は「プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に，当該発信不要データを「指定されたＤＢ」に記録し，プレディク」ティブ発信時に当該指定されたＤＢを検索することで，リアルタイムコール止めを実現するというものである。つまり，本件発明は，プレディクティブ発信時に用いるＤＢ（プレディクティブ発信用ＤＢ）をバッチ処理で作成することにより，高い処理効率を可能にし，かつ，コストの低減も可能にしつつ，所定の構成を組み合わせることでコール止めのリアルタイム処理を可能にしたものである。確かに，本件明細書（特許公報，甲４）には，本件発明の処理が「バッチ処理」であることの直接的な記載はないものの，技術常識に照らせば，，，それがバッチ処理であることはいうまでもなく明白であるばかりかまた本件特許のクレームの「おいて」書きの部分の「プレディクティブ発信用のデータベースを作成した後」という文言自体，これがバッチ処理であることを明確に示すものである。以上のとおり，本件発明は，バッチ処理構成を基本にしつつ，コール止めのリアルタイム処理に必要な構成を採用したという，いわば「バッチ処理とリアルタイム処理のハイブリッド構成」を採用した点に特徴があり，審決は，このような本件発明の要旨認定を誤ったものである。イ取消事由２（引用発明１認定の誤り） (ｱ) 一般的なプレディクティブ発信処理のコールセンタシステムでは，一日の間にプレディクティブ発信を行う対象の顧客データを予めバッチ処理で顧客マスタＤＢから抽出し，プレディクティブ発信用のＤＢを作成しておく方式が採用されている。しかし，このバッチ処理によりプレディクティブ発信用ＤＢを作成してプレディクティブ発信を行う従来技術では，顧客データに何らかの変更が生じた場合，直ちにその変更を発信業務に反映させることができないという問題点があった。引用発明１は，上記の従来技術の問題点を解決するため，プレディクティブ発信用ＤＢをバッチ処理により作成するという過程を取り除き，プレディクティブ発信時にリアルタイムで顧客マスタＤＢから発信用データを直接抽出する構成を採用した点に特徴がある。すなわち，引用発明１の最大の特徴は，バッチ処理でプレディクティブ発信用ＤＢを作成する処理を排除している点にある。審決は，引用発明１を正しく把握しておらず，上記のような引用発明１の特徴部分の認定を見落としているものである。ａまず，後記第４，２(2) アＣの記載の「メインフレームコンピュータに記憶される顧客アカウント情報」は「顧客マスタＤＢ」に該当する。また「オペレータ（顧客アカウント，セールス，又はサービス，）」担当者がアクセスするための別のコンピュータに設置されるコピーは，オペレータがこれにアクセスし，この情報に基づいてダイヤルするためのものであるから「発信用のＤＢ」に該当し，これをプレデ，ィクティブ発信用の装置に用いる場合は「プレディクティブ発信用ＤＢ」に該当する。なお，一般に，あるマスタＤＢから所定の条件に合致するデータを検索・抽出して他のＤＢを作成する処理がバッチ処理で行われることは，技術常識である。ｂ後記第４，２(2) アＥの記載の「処理されたビジネス用の顧客アカウント情報」とは，上記ａの「メインフレームコンピュータに記憶される顧客アカウント情報」について１日の業務の中で何らかの処理が行われて変更が生じた情報を意味しており「顧客データに生じた変，更」に相当する。すなわち，上記Ｅの記載では，通常のコールセンタ業務において顧客データに変更が生じた場合，その変更内容は「以前に作られたコピー」又は「別のファイル」に保存され，直接顧客マスタＤＢや発信用のＤＢには書き込まれないので「１日の業務，又はビジネスセッシ，ョンの終了時」にその変更情報を「メインフレーム内の顧客アカウント情報」すなわち「顧客マスタＤＢ」に書き込まなければならないことが述べられている。この処理のサイクルないしタイミングが「１日の業務，又はビジネスセッションの終了時」であることから，これはバッチ処理によって行われることが自明である。ｃそして，後記第４，２(2) アＦの記載には，以前に作って別に保存された「顧客アカウント情報のコピー「ディスク又はテープ等の記」，憶媒体に記憶される顧客アカウントのコピー」又は「別のファイル」に保存されている顧客データに生じた変更を「メインフレーム又はシステム制御装置」を介して「顧客マスタＤＢ」に書き込む作業をオペレータが行う場合，オペレータの時間が浪費されてしまうという課題。「」があげられているこの貴重なオペレータの時間がまた浪費されるは，本件明細書の段落【０００５】に記載された課題と同様の課題である。このように，引用発明１が従来技術のシステム構成から生じる課題としてあげているのは，バッチ処理により顧客マスタＤＢからプレディクティブ発信用ＤＢを予め作成しておくシステム構成における課題である。，，「」ｄ後記第４２(2)アＧの記載から明らかなとおり顧客マスタＤＢからバッチ処理により「プレディクティブ発信用ＤＢ」を作成する従来技術のコールセンタシステムで生じる課題解決のために，引用発明１は，プレディクティブ発信用ＤＢの作成処理を強いて取り去り，顧客マスタＤＢだけですべての顧客情報をオンライン（リアルタイム）処理で管理する方法を採用しているのであり，引用発明１がプレディクティブ発信用ＤＢを作成しないオンライン（リアルタイム）処理を採用するものであることは，後記第４，２(2) アＨ，Ｉ，Ｊの各記載からも明らかである。ｅこのような構成を採用した結果引用発明１では後記第４２(2) ，，，アＮ，Ｏ，Ｐに記載のとおり「メインフレーム１６は自動的かつ直，ちに該顧客アカウント情報を更新する。また，自動更新であるので，オペレータに提供されるいかなる情報も最新の情報である。従って，オペレータはメインフレーム１６に直接接続されているように見える」という効果を得ることができるのであるから，引用発明１は，バッチ処理でのプレディクティブ発信用ＤＢの作成処理を取り除き，それに代えて顧客マスタＤＢから直接プレディクティブ発信の対象データを抽出するというオンライン（リアルタイム）処理を採用した点に特徴を有していることは明らかである。 (ｲ) 被告は，引用発明１においてもプレディクティブ発信用ＤＢを作成していることは明らかであると主張する。しかし，引用例１には，プレディクティブ発信用「ＤＢ」が「作成」されることは，どこにも開示されていない。引用例１に開示されているのは「所望の数の顧客アカウン，ト情報」が「転送」されることのみである。ウ取消事由３（一致点認定の誤り） (ｱ) 審決は，本件発明と引用発明１との一致点につき，引用発明１の「転送され」た「所望の数の顧客アカウント情報」も，本件発明の「プレディクティブ発信用のデータベース」も「プレディクティブ発信用のデータの集合」であることに変わりはないとする。しかし，引用発明１で「転送される「所望の数のアカウント情報」」とは，発信対象となる数件の顧客データの通信（転送）データを意味するにすぎず，顧客マスタＤＢから別個のファイルとして作成される「データベース」とは全く異なるものであるから，本件発明の「データベー」「」「」スと引用発明１の所望の数のアカウント情報とをデータの集合といった抽象化された概念のレベルで同一視することは不可能でありかつ誤りである。また，引用発明１で「メインフレーム１６」に「アカウントの状態に変化があったか否か等を問い合わせる対象のデータはオンラインリ」，（アルタイム）処理によって抽出された発信データであって，本件発明のようにバッチ処理にて作成されたプレディクティブ発信用ＤＢから抽出された発信データとは異なる。したがって「両者は『プレディクティブ発信用のデータの集合を得，て，該プレディクティブ発信用のデータの集合で選択された顧客の電話番号を自動的にダイヤルして発信する』点で共通する」との審決の認定は誤りである。 (ｲ) 次に，本件発明では，コールセンタ業務とは異なる別系統の情報であるインターネットや電子メールにより顧客からコンタクトがあった場合にも発信直前にコール止めを行うことができる。ところが，引用発明１には「インターネット」及び「電子メール」による顧客からのコンタクトにより発信不要データが生じることについては，開示もなければ示唆もない。引用発明１は本件発明の１３年前に出願されたものであり，インターネットや電子メールでの顧客からのコンタクトに対応するといった構成及び効果を想定していないことは明らかである。したがって，引用発明１に「インターネット「電子メール」での顧」客からのコンタクトについて開示がなくとも「着信及び／又は請求に，対する支払及びクレジット」により「最新ではなくなる可能性がある」「顧客アカウント情報」の中に「インターネット「電子メール」によ」る顧客からのコンタクトから得られる情報が含まれるとする審決の認定は誤りである。 (ｳ) そして，コール止めについて，引用発明１には「顧客マスタＤＢ」，を意味する「メインフレーム１６」に該アカウントの状態を問い合わせることが開示されているのみである。一方，本件発明は，プレディクティブ発信時に発信用データについて「指定されたデータベース」に「指定された条件で検索する」という構成を採用することで「顧客マスタＤＢ」以外のＤＢを検索することも，可能にしているのであって，本件発明の「指定されたデータベース」には「顧客マスタＤＢ」以外のＤＢも含んでいる。したがって「引用発明１の『メインフレームコンピュータ１６に該，アカウントの状態を問い合わせる』ことと本件発明の『プレディクティブ発信用のデータベースから抽出された発信データを『電話番号又は，』他の顧客識別情報をキーとして指定されたデータベースを指定された条件で検索すること』とは『プレディクティブ発信用のデータの集合か，ら抽出された発信データを指定されたデータベースに照会すること』で共通する」とする審決の認定は誤りである。 (ｴ) 以上にかんがみ，引用発明１と本件発明の一致点をあげるならば，次の点のみである。「顧客情報を管理しているデータベースから，選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて，顧客から着信する通話によるインバウンド業務，又は事務部門における該顧客からのコンタクトにより，プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に，プレディクティブ発信時に，発信データが発信不要データであると判定された場合には，その発信を中止するリアルタイムコール止めを行うコールセンタシステム」。エ取消事由４（引用発明２認定の誤り）審決は，引用発明２を，前記のとおり「発信データを発信不要データベースに照会して発信不要データであると判定するにあたり，電話番号をキーとして，発信不要データベースを指定された条件で検索する，プレディクティブ発信制御方法」と認定しているが，次のとおり，その認定は誤りである。引用発明２は，複数のコールセンタ間での顧客の不在・話中の情報共有に関する発明であり「アウトバウンド業務」で得られた情報を「アウト，バウンド業務」の処理に反映するものである。一般に，コールセンタシステム全体としては，顧客の様々な情報（例えば，契約の締結，解除，住所変更，職場の変更等）を取り扱う業務系コンピュータシステムと，プレディクティブ発信処理を行うシステムは，別系統のシステムとして構成されている。プレディクティブ発信処理を行うシステムは，例えば，ＰＤＳ（Predi ctive Dialer System）のような専用装置が用いられることが一般的である。発信処理，すなわち，アウトバウンド業務は，このＰＤＳにより処理される。これに対して，インバウンド業務すなわち顧客からの様々なコンタクトの情報を顧客マスタＤＢで管理する業務は，一般に専用システムのＰＤＳで行うことはできず，業務系コンピュータシステムで行われるようになっている。引用発明２は，コールセンター１のＰＤＳによるアウトバウンド業務で得た情報をコールセンター２のＰＤＳによるアウトバウンド業務に反映させるものであって，コールセンター１とコールセンター２は，それぞれの業務系コンピュータシステムが保有するアウトバウンド業務以外の別系統のシステムから得た情報を活用することは不可能である。したがって，審決の引用発明２に関する認定のうち「顧客情報受信部，２１６(2) が有する顧客情報は，全体として”発信不要データベース”ということができるとの記載部分の発信不要の顧客情報受信部２１６(2) 」「が有する顧客情報」は，本件発明における「顧客から着信する通話によるインバウンド業務，インターネット，電子メール，又はその他の事務部門等における顧客からのコンタクト等（本件明細書の段落【０００４）の」】ような他のシステム系統から得られた情報を含んでおらず，審決が「発信不要データベース」と称する顧客情報は，本件発明で発信不要データの検索対象となる「指定されたデータベース」が保有するような他のシステム系統から得られた情報を含まない。オ取消事由５（相違点１認定判断の誤り） (ｱ) 本件発明は，前述のとおり，バッチ処理構成を基本にしつつ，それに部分的にすなわちコール止めの部分に限ってリアルタイム処理を組み合わせるというハイブリッド型構成を採用することで，バッチ処理のメリットを確保しつつ，リアルタイム性を部分的に実現している点に特徴がある。これに対し，引用発明１は，前述のとおり，バッチ処理を完全に排除し，フルリアルタイム処理型を採用することで，バッチ処理のメリットを犠牲にしつつ，常に最新の情報を扱えるというリアルタイム処理の恩恵を最大限に追求している点に特徴がある。ところで，バッチ処理とオンライン（リアルタイム）処理とでは，情報システムの基本的な性格が対極にあるから，システムに要求される処理内容に応じて，バッチ処理構成を採用するか，オンライン（リアルタイム）処理構成を採用するかが必然的に決定される。すなわち，バッチ処理とオンライン（リアルタイム）処理は二律背反であって，片方を選択しながらもう一方のメリットも取りうるものではなく，コールセンタ業務において，バッチ処理によるプレディクティブ発信用ＤＢを作成するか，プレディクティブ発信用ＤＢを作成せずにオンライン（リアルタイム）処理を行うかは，システムの基本構成として両極端の選択であって，審決のいうような「発信業務の目的と，元より存在する顧客データベースが内容としてどのような性質や規模の顧客情報を有していたかに応じて従属的に決まる設計事項にすぎない」というものではない。したがって，引用発明１においては，プレディクティブ発信用ＤＢを作成し用いることは，絶対にあり得ないことである。このような構成を採用したとたん，従来技術に後戻りしてしまい，引用発明１の目的を達成できなくなってしまうからである。したがって，引用発明１にプレディクティブ発信用ＤＢを用いる処理を組み合わせることは，引用発明１の目的を実現不可能にすることになり，阻害事由がある。よって，そのような構成を当業者が想到することはあり得ない。 (ｲ) 本件発明は，発信不要データを「指定されたデータベース」から検索するという構成を採用することで，顧客マスタＤＢ以外のＤＢを検索することも可能としている。これに対し，引用発明１は，変更が生じたデータをすべて顧客マスタＤＢに書き込むことが必須であり，その書き込みに要する時間と検索に要する時間から生じる発信処理とのタイムラグは避けられない。このように，本件発明は引用発明１と比較してはるかに優れた作用効果を有するのであるから，この点においても，引用発明１において相違点１のように構成することは，容易想到とはいえない。 (ｳ) 引用発明１の「所望の数」は「所定の条件」に相当しない。，バッチ処理によりプレディクティブ発信用ＤＢを作成しプレディクティブ発信を行う従来技術のコールセンタ業務において，プレディクティブ発信を行うデータを抽出する「所定の条件（本件発明）とは，顧客」情報内にある男女の別，年齢，居住地域，履歴等の顧客の属性に関する情報を条件とすることを意味し例えば１００件２５００件などの所，，「望の数（引用発明１）を条件とすることを意味しないことは，当該コ」ールセンタシステムを扱う当業者にとって自明である。 (ｴ) 引用発明１の「転送され」るは，本件発明の「作成」に該当しない。引用例１の記載である後記第４，２(2)アＬの「メインフレームコンピュータ１６は，所望の数のアカウントの顧客アカウント情報をデータ制御装置１５に一括転送又はオンライン転送により提供する」におけ。る「転送」は「顧客アカウント情報」を「メインフレームコンピュー，タ１６」から「データ制御装置１５」に送ることを意味しているにすぎない。また，後記第４，２(2)アＱの「２６からスタート後，第１ステップ２７ではメインフレーム１６から一括モード転送により複数の顧客アカウント情報を得る」における「転送」は「メインフレーム１６」から。，「システム制御装置１１」に「複数の顧客アカウント情報」が送られることを意味しているにすぎない。そして「転送」の語彙自体に「作成」の意味は含まれず「他から送，，られてきたものを，さらに他へ送ること」を意味することは，一般常識である。 (ｵ) 引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」は「データベース」ではない。引用発明１における「転送され」は，後記第４，２(2) アＬの引用例１の記載によれば「一括転送又はオンライン転送」されるものであり，その「一括転送」の対象は「a number of customers」であるところ「a ， number of」は「several」と同義であり，せいぜい３ないし５件の顧客データにすぎない。このように，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に「一括送信」されるデータの件数が数件にすぎないことは，引用発明１における自動発信処理の仕方からも明らかである。すなわち，引用発明１における自動発信処理は，まず，メインフレームコンピュータ１６が顧客のアカウント情報のファイルから読み出した数件のデータを自動発信処理を行う装置であるシステム制御装置１１に送信する。ここで送信されるデータ（アカウント情報）の件数は，回線あるいはオペレータの空きが出ないように効率的に自動発信するのに必要な件数であるから，本件特許に関する後記第４，２(1)の段落【００２５】の「該ペーシング制御部５６から要求があった発信データ群」の件数と同程度といえる。なぜなら，引用例１添付のＦＩＧ．４Ａのフローチャート２５と２７の流れから明らかなように，引用発明１は，ステップ２７で受信した一群の発信データの処理が一通り終わると，また次の一群のデータをメインフレームコンピュータ１６から受信するようになっているが，この処理の流れは，本件明細書の図４のステップ３０４から３０８の流れとほぼ同様のものである。したがって，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に「一括送信」されるデータの件数は，本件明細書の図４の「」とほぼ同様の件 N 数と考えられるからである。，（）また引用発明１のシステム制御装置１１はファイル磁気ディスクを備えておらず，メインフレーム１６から転送された顧客アカウント情報は，システム制御装置１１のメモリ上に記憶される。しかし，引用発明１が出願された１９８７年当時の主記憶容量は極めて限られていたから，この点でもシステム制御装置１１に一括転送される顧客アカウント情報の件数がごく少数であったことは明白である。以上のように，引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」は，せいぜい３ないし５件のごく少数の顧客アカウント情報にすぎず「データベース」として系統的な整，理・管理が可能なほどの大量のデータではないから，これを「データベース」と称することは明白な誤りである。カ取消事由６（相違点２認定判断の誤り）次のとおり，引用発明１に引用発明２を組み合わせることに想到することは極めて困難である。 (ｱ) 引用発明１は，プレディクティブ発信用ＤＢを排除することに特徴を有する発明であるから，引用発明１は，後記第４，２(2) アＥに記載された「処理されたビジネス用の顧客アカウント情報は，以前に作られたコピーに入力されるか，又は別のファイルに保持される」という従来技術の構成を排除し，すべてのデータを顧客マスタＤＢのみで管理するようにすることでその目的を実現しているしたがって引用発明１に別。，「のファイル」を用いる構成を組み合わせることには阻害要因があるところ，引用発明２の不在情報が記録される引用例２の【図１９】及び【図２１】のテーブルは，引用例１の上記Ｅ記載の「処理されたビジネス用の顧客アカウント情報は‥‥別のファイルに保持される」に相当するから，引用発明１に引用発明２の不在情報が記録される「別のファイル」の構成を適用することには阻害事由がある。，，，よって引用発明１に引用発明２を適用することは阻害事由があり容易想到とはいえない。 (ｲ) 引用発明２は，複数のコールセンタ間の情報共有に関する発明であって，ＰＤＳがアウトバウンド業務で得た情報を別のＰＤＳと共有するも，，のであってインバウンド業務等を処理する業務系システムが保有するアウトバウンド業務以外の別系統のシステムから得た情報を活用することはできない。これに対し，本件発明は，インバウンド業務で得た情報をアウトバウンド業務に反映させるという，別系統のシステムの垣根を越えて発信不要データを利用するものである。本件発明は，当該構成を採用することで，顧客の架電状況（不在又は話中）以外の「インターネット，電子メール，又はその他の事務部門等における顧客からのコンタクト等」を活用できるから，引用発明２とは課題も課題解決手段（すなわち発明の構成）も異にする。 (ｳ) 仮に引用発明１と引用発明２とを組み合わせて，他のコールセンタから発信不要データに該当する情報を得たとしても，当該発信不要データに該当する顧客アカウント情報とオンライン処理によりまさしく今発信しようとして転送した「a number of customers ，すなわち，わずか３」ないし５件の顧客アカウント情報が一致する確率は極めて小さい。したがって，引用発明１に引用発明２を組み合わせる意義は非常に乏しく，組み合わせの動機付けがないというべきである。２請求原因に対する認否請求原因(1)ないし(3) の各事実は認めるが，(4)は争う。３被告の反論審決の認定判断に誤りはなく，原告主張の取消事由はいずれも理由がない。 (1) 取消事由１に対しアそもそも，審決が認定した「本件特許発明の要旨」は，本件特許の特許，，請求の範囲の記載に基づいて記載されたものにすぎずこの点については原告も審決が行った当該認定を認めているのであるから，本件発明の要旨認定には何ら誤りはない。イまた，原告は，審決の要旨認定において，本件発明がプレディクティブ発信用ＤＢがバッチ処理によって作成されていると限定されていないことが要旨認定の誤りであるかのように主張している。しかしながら，本件発明で作成される「プレディクティブ発信用のデータベース」が，原告が主張するような「バッチ処理」によって作成されるものであると解釈される理由は，特許請求の範囲の文言上存在しないし，発明の詳細な説明等においても存在しない。したがってプレディクティブ発信用データベースがおよそ必ずバ，「」「ッチ処理」によって行われるものであるという前提で「本件発明は，‥ ， ‥，いわば『バッチ処理とリアルタイム処理のハイブリッド構成』を採用した点に特徴がある」等と主張し，審決が本件発明の要旨認定を誤った。という原告の主張は根拠がない。 (2) 取消事由２に対しア原告は，この点に関し，要するに，引用発明１においてはプレディクティブ発信用ＤＢが作成されておらず，プレディクティブ発信用ＤＢを排除することが最大の特徴である旨主張する。しかし，次に述べるとおり，引用発明１においてもプレディクティブ発信用ＤＢを作成していることは明らかであり，原告の主張こそ，引用発明１の技術的な理解を根本的に誤ったものにほかならない。すなわち，引用例１には，後記第４，２(2) アＡ，Ｌ，Ｑのとおり，原告の引用する箇所とは別に，プレディクティブ発信用データの作成に関する記載がある。これらの記載によれば，メインフレームコンピュータからデータ制御装置を介してシステム制御装置に転送される「顧客アカウント情報」に基づいて電話番号がダイヤルされるのであるから，これらが本件発明における「プレディクティブ発信用のデータ」に相当することは明らかである。そして「所望の数の顧客アカウント情報」が転送されるので，あるから，これが「プレディクティブ発信用のデータの集合」であることは当然である。したがって，引用発明１においてもプレディクティブ発信用ＤＢを作成していることは明らかである。イまた，原告は，引用発明１は，プレディクティブ発信用ＤＢの作成処理を強いて取り去り，顧客マスタＤＢだけですべての顧客情報をオンライン（リアルタイム）処理で管理する方法を採用していると主張する。しかし，原告が指摘する明細書の記載は，いずれも，メインフレームコンピュータに格納された顧客アカウント情報を修正する場合に，当該修正をオンラインで行うことを指摘したものにすぎず，メインフレームコンピュータから発信対象となる架電先のデータをどのように抽出するかについての構成を述べたものではないし，また，プレディクティブ発信用ＤＢを。，，作成する構成と矛盾するものでもないすなわち引用発明１においてはメインフレームコンピュータから所望の数の顧客アカウント情報を抽出してプレディクティブ発信用ＤＢを作成してプレディクティブ発信の用に供するが，その後にメインフレームコンピュータ内の顧客アカウント情報を修正する場合には，当該情報の修正をオンラインで行う。そして，プレディクティブ発信用ＤＢとメインフレームコンピュータ内の顧客アカウント情報との間に生じうる齟齬については，後記第４，２(2)アＲに記載されているとおり，発信の際に最新のデータをメインフレームコンピュータに問い合わせることによって解決しているのである。上記Ｒの記載が開示する第１の方法（システム制御装置１１はステップ２７で一度に１つのアカウントだけのアカウント情報を得ること）こそが，原告の主張するリアルタイム抽出処理にほかならないのであって，引用発明１は，このリアルタイム抽出処理とは明確に異なる「別の一つの」方法，すなわち，システム制御装置１１に複数の顧客アカウント情報が記憶され，発信を待っていることを前提に，システム制御装置１１が発信の順番の到来した顧客アカウント情報についてメインフレーム１６に問い合わせるという構成をとることによって，システム制御装置１１に記憶されたアカウント情報（プレディクティブ発信用ＤＢである）と，メインフレームに記憶された顧客ア。カウント情報との間に生じうる齟齬を解決することを明らかにしているのである。したがって，引用発明１は，顧客マスタＤＢだけですべての顧客情報をオンライン（リアルタイム）処理で管理する方法を採用しているものではない。ウ以上のとおり，審決が行った引用発明１の内容の認定には何ら誤りがない。 (3) 取消事由３に対しこの点に関する原告の主張は，結局のところ，本件発明の要旨に関する原告独自の理解と，引用発明１の内容に対する独自の理解に基づくものにすぎないから，前記(1) 及び(2) で論じたところからすれば，審決が行った一致点の認定には何らの誤りもないが，念のため，反論する。ア原告の主張(ｱ) に対しそもそも審決は「所望の数の顧客アカウント情報」と「プレディクテ，ィブ発信用のデータベース」とが一致点であるとは認定しておらず，むしろ相違点として認定しているのであるから，原告の主張は，審決の認定を争う理由になり得ず，主張自体失当である。イ原告の主張(ｲ) に対し本件発明において，顧客からのコンタクトは「顧客から着信する通話，によるインバウンド業務，インターネット，電子メール，又はその他の事務部門における該顧客からのコンタクト」と記載されており「又は」に，よって接続されていることから明らかなように，これらのいずれか１つに。，よるコンタクトがあれば一致点と認定することに不足はないしたがって引用発明１に「インターネット」及び「電子メール」による顧客からのコンタクトが記載されていなくても，他の点については記載されているのであるから，これを一致点とすることに問題はなく，審決に誤りはない。ウ原告の主張(ｳ) に対し原告は，引用発明１で，発信直前に顧客アカウントの状態を問い合わせる先が「メインフレーム１６」であるのに対し，本件発明では「指定されたデータベース」である点で相違すると主張するが，原告のこの主張は，本件特許における「指定されたデータベース」が，実施例においては「マスタＤＢ１０」とされている（段落【００３０，図６参照）ことを忘れ】た主張である。すなわち，引用発明１の「メインフレーム１６」が，上記実施例の「マスタＤＢ１０」に相当するものであることは，原告も認めているところ，本件発明の実施態様として複数の実施態様が考えられる場合に，そのうちの一部の実施態様について公知文献の開示があれば，本件発明の進歩性を否定することができるのであるから，引用発明１の「メインフレーム１６」が，本件発明の「指定されたデータベース」に相当することに疑問の余地はないというべきであって，原告の主張は失当である。 (4) 取消事由４に対し，，原告は審決が引用発明２についても誤った認定をしていると主張するが技術思想の相違を述べるに留まり，原告の主張は不明確というほかない。また，引用発明２の認定について，原告は「審決が『発信不要データベース』と称する顧客情報は，本件発明で発信不要データの検索対象となる『指定されたデータベース』が保有するような他のシステム系統から得られた情報を含まない」ことを強調しているが，審決の文言上，上記の点は審決の認定の内容とはなっていないのであるから，引用発明２の認定誤りの根拠とはなり得ない。したがって，審決が行った引用発明２の内容の認定には何らの誤りもない。 (5) 取消事由５に対しア原告の主張(ｱ) に対し原告は，本件発明と引用発明１との相違点１についての審決の認定誤りの具体的内容として，プレディクティブ発信用のデータの集合を作成するに当たり本件発明はバッチ処理によっているのに対し引用発明１はオ，，「ンライン（リアルタイム）処理」によっている点で根本的に相違するなどと主張する。しかしながら，既に指摘したように，本件発明で作成されるプレディクティブ発信用ＤＢがバッチ処理によって作成されることが要求されているものとは解されないから，原告が主張するようにプレディクティブ発信用ＤＢをバッチ処理により作成することを本質的な要素とするものと解することはできない。のみならず，そもそも引用発明１においては，メインフレーム１６から所望の数の顧客アカウント情報を取り出してシステム制御装置に転送する処理は「一括モード転送が好ましい」とされ，まさに「バッチ処理」を，予定しているのであるから，引用発明１が「オンライン（リアルタイム）処理」によっているとの主張も誤りである。イ原告の主張(ｲ) に対し原告は，本件発明においては，引用発明１にはない優れた作用効果が得られるなどと主張する。しかし，上記のとおり，本件発明の「指定されたデータベース」には検索用のデータベースとして顧客マスタＤＢを指定する場合も当然に含まれると解されるところ，特許の技術的範囲の一部について公知文献に開示があれば特許の進歩性を否定しうることは前記のとおりであるから，原告の主張はそもそもこの点において既に失当である。ウ原告の主張(ｳ) に対し原告は，引用発明１の「所望の数」は「所定の条件」に相当しないと主張する。しかし，本件発明における「所定の条件」については，当該文言はもとより，明細書上にも何らかの限定的な意義を与えるような根拠となるべき記載はなく，一定の件数を指定して発信対象データを抽出することも含まれるというべきであり，引用発明１において「所望の数」の顧客アカウント情報を転送することも「所定の条件」に該当することは当然である。ま，「」「」，た仮に所望の数が所定の条件の下位概念とはいえないとしても原告もいうように「所望の数」の発信用データを抽出するに当たり，例，えば何らかの顧客の属性に関する情報を条件とすることもコールセンタシステムの当業者にとって自明のことである。エ原告の主張(ｴ) に対し原告は，引用発明１の「転送され」るは，本件発明の「作成」に該当しないと主張する。，「」しかしコンピュータにおいてある機器から他の機器にデータが転送されて他の機器の記憶装置に記録される場合，ＤＢの加工過程が介在するか否かにかかわらず，他の機器の記憶装置に，それまで存在していなかっ「」，，たデータが作成されることは明らかであるから引用発明１のようにある機器に存在するデータ集合の中から他の機器に「転送」すべきデータ集合を抽出することも転送データの「作成」に該当するといえる。また，引用発明１においては，システム制御装置１１に転送されるデータが，メインフレーム１６に記憶されている顧客アカウント情報のうちの「所望の数」のみである場合も当然に予定されており，上述のとおり「所望の数」も「所定の条件」の１つであるうえ「所望の数」の転送に当たって，顧，客の属性に関する情報を条件として，当該条件に基づいて顧客アカウント情報を抽出しようとすることも，当業者には自明な選択肢であり，設計事項にすぎない。オ原告の主張(ｵ) に対し原告は，引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」は「データベース」ではないと主張する。，「」，しかし引用発明１における所望の数の顧客のアカウント情報とは「複数の顧客のアカウント情報」に関する情報であり，その内容も，少なくとも「顧客名，顧客電話番号，アカウント番号，及び／又はあるタイプのメインフレームデータベース指標番号」を含むものであるから，まさし「」。く原告自身が主張するデータベースの定義に該当することは疑いない次に，原告は，引用発明１における一括転送の対象はせいぜい３ないし５件の顧客データにすぎないなどと主張するが，そのようなことは引用発，。明１の明細書には全く記載されておらず原告の主張は何らの根拠もないこの点に関し，原告は，引用例１の図４の記載を根拠に，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に送信されるアカウント情報の件数は，本件明細書の段落【００２５】の「該ペーシング制御部５６から要求があった発信データ群」の数（＝Ｎ）と同程度であるなどとして，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に「一括送信」されるデータの件数が数件にすぎないなどと主張するが，次のとおり，失当である。すなわち，引用発明１においては，メインフレーム１６からシステム制御装置１１に複数の顧客アカウント情報が転送（図４Ａのステップ２７）された後，後記第４，２(2)アＱに記載されているように「‥‥判定２９，は新しい呼出し（又は再呼出し）が必要かを調べる。‥‥もし必要であれば，システム制御装置１１はステップ３０に進み，呼出す次のアカウントの電話番号を抽出する」という処理がされる。このステップ３０におけ。る「アカウント情報群から次のアカウントの電話番号を抽出する」処理こそが，本件発明における，プレディクティブ発信用データベース１２から発信データ群（Ｎ）を抽出する処理に相当するのである。そして，引用例１のＦＩＧ．４Ａに開示されているとおり，このステップ３０を経て電話発信処理が終了した後も，ステップ２５において群処理が完了したか否かの判断がされ，その結果が「Ｎｏ」であれば，メインフレームコンピュータ１６から新たにアカウント情報を得ることなく，再度ステップ２８以下の処理を行うこととされているのである。したがって，引用発明１においては，メインフレームコンピュータ１６からアカウント情報群を１回取得するうちに，発信データ群Ｎの電話発信処理を複数回行うことが予定されているのであるから，メインフレーム１６からシステム制御装置１１に転送されるアカウント情報は，本件特許発明でいう発信データ群Ｎよりも多いことは明らかである。また，原告は，引用発明１が出願された１９８７年当時の主記憶容量が極めて限られていたと主張するが，引用例１に「システム制御装置１１が十分な記憶容量を有する場合は，システム制御装置１１は顧客アカウントのファイル全体を保持し，この記録全体をオペレータ端末に送信してもよい」との記載（後記第４，２(2)アＰ）があるように，システム制御装置。１１は相当程度の記憶容量を有することも想定されているのである。したがって，３ないし５件程度の顧客アカウント情報しか保持できないなどという原告の主張は，明細書の記載にもまた当業者の技術常識にも明らかに反する。さらにいうならば，引用例１の記載（後記第４，２(2) アＲ）も，システム制御装置１１に一括転送される顧客アカウント情報の件数が相当程度に上ることを予定した記載である。一括転送される顧客アカウント情報が原告のいうように３ないし５件程度にとどまるのであれば，発信待ちの間にシステム制御装置１１に記憶されたアカウント情報が「最新でなくなる可能性」は非常に小さく，この点に配慮する必要はなくなるからである。 (6) 取消事由６に対しア原告の主張(ｱ) に対し前述のとおり，引用発明１はプレディクティブ発信用ＤＢを排除することを特徴とするものでは全くなく，メインフレームコンピュータ１６からシステム制御装置１１へと複数の顧客アカウント情報が一括モード転送されることにより，プレディクティブ発信用ＤＢが作成される一方，メインフレームコンピュータ１６の顧客アカウント情報に発信の可否を問い合わせるものであり，メインフレームコンピュータが引用発明２の「別のファイル」となりうることは明らかであるから，原告の主張はその前提において誤っており，失当である。イ原告の主張(ｲ)及び(ｳ) に対し引用発明１はアウトバウンド業務で得られた発信不要データと，インバウンド業務で得られた発信不要データのいずれをも発信回避に使用できるのであるから，引用発明２のアウトバウンド業務で得られた発信不要データを発信回避に用いる技術を引用発明１に適用することに困難はない。そして，その場合に，当業者が，アウトバウンド業務で得られた発信不要データによる発信回避のためにしか引用発明２の技術を適用せず，インバウンド業務で得られた発信不要データには上記技術を適用しないなどということはおよそ考えられないから，引用発明１に引用発明２の技術を組み合わせることによって，本件発明の構成を得ることは当業者に容易である。第４当裁判所の判断１請求原因(1) （特許庁における手続の経緯，(2) （発明の内容，(3) （審））決の内容）の各事実は，当事者間に争いがない。２容易想到性の有無審決は，本件発明は引用発明１及び２から容易に想到できるとし，一方，原告はこれを争うので，以下検討する。 (1) 本件発明の意義ア本件明細書（甲４）には，次の記載がある。・発明の属する技術分野】本発明は，顧客の電話番号を自動的にダイヤ「【ルして発信するプレディクティブ発信業務を行っているコールセンタシステム，及び，プレディクティブダイヤラ装置に係り，特に，プレディクティブ発信業務を行っている途中で不要となったデータの発信を発信直前に止めることが可能なコールセンタシステム，及び，そこで用いられるプレディクティブダイヤラ装置に関する（段落【０００１）。」】・従来の技術】コールセンタシステムの利用者が，能動的に顧客と連絡「【を取りたい場合に，予測発信機能を用いて，顧客の電話番号を自動的にダイヤルし，顧客と接続された呼のみをオペレータに接続することによって，オペレータの効率を向上させるプレディクティブ発信業務が行われている（段落【０００２）。」】・このようなプレディクティブ発信業務を行っている従来のコールセン「タシステム，及び，そこで用いられるプレディクティブ発信装置で発信データを作成する際には，図１に示す如く，ステップ１００で，全ての顧客情報を管理しているマスタデータベース（ＤＢ）１０から，プレディクティブ発信を行うデータを所定の条件で抽出して，プレディクティブ発信専用のデータベース（ＤＢ）１２を作成した後，ステップ１０２で，プレディクティブ発信用データベース１２で選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信処理を行っていた（段落【０００３）。」】・図１】プレディクティブ発信における従来の発信中止処理を示す流れ【図・そのため，一旦プレディクティブ発信処理が開始されてしまうと，例「えば顧客から着信する通話によるインバウンド業務，インターネット，電子メール，又はその他の事務部門等における顧客からのコンタクト等によりプレディクティブ発信を行わなくてもよい発信不要データがステップ２００で発生した場合には，ステップ２０２で，マスタデータベース１０に発信不要データが発生したという情報を記憶させて，マスタデータベース１０を更新し，次いで，ステップ２０４で，バッチ処理又は人が介在して，プレディクティブ発信用データベース１２から発信不要データを削除したり，あるいは，発信停止フラグを立てる等の処理が行われていた（段落【０００４）。」】・発明が解決しようとする課題】しかしながら，このような方法では，「【バッチ処理又は人が介在することにより，時間的なタイムラグが発生して，発信不要データが削除される前に，当該データのプレディクティブ発信が行われてしまう場合があった。更に，昨今，コールセンタ，インターネット，電子メール等といった顧客に対するコンタクトチャンネル，，も多様化してきておりプレディクティブ発信業務を行っている途中で発信が不要となったデータを削除することが，ますます困難になってきている（段落【０００５）。」】・本発明は，前記従来の問題点を解決するべくなされたもので，発信不「要データのプレディクティブ発信を発信直前に止めることを課題とする（段落【０００７）。」】・本発明が採用されたコールセンタシステムの全体構成を図２に示す。「このコールセンタシステムは，オペレータ毎に設けられた，複数（図では３台）の電話機２０，及び，オペレータを補助するクライアント装置２２と，前記電話機２０を公衆電話回線網（ＰＳＴＮ）１４を介して顧客の電話機１６に接続するための交換機（ＰＢＸ＝ Private Branch eXchange）３０と，インターネット接続用のウェブ（Ｗｅｂ）サーバ装置３２と，電子メールを受信するためのメールサーバ装置３４と，全ての顧客情報を管理しているマスタデータベース（ＤＢ）１０を管理しているマスタＤＢ管理装置３６と，例えば事務部門に設けられた顧客情報処理部門３８と，前記クライアント装置２２，ＰＢＸ３０，ウェブサーバ装置３２，メールサーバ装置３４，マスタＤＢ管理装置３６及び顧客情報処理部門３８とローカルエリアネットワーク（ＬＡＮ）４０を介して接続された，プレディクティブ発信業務を行うと共に，プレディクティブ発信が不要となった発信不要データの発信を発信直前に止めるリアルタイムコール止め機能を有するＣＴＩ（Computer Telephony Integration）サーバ装置５０とを含んで構成されている（段落【０。」０２４）】・図２】本発明が採用されたコールセンタシステムの実施形態の全体構【成を示すブロック図・前記ＣＴＩサーバ装置５０は，図３に詳細に示す如く，例えばパソコ「ンで構成されるクライアント装置２２に内蔵されたクライアントプログラム２４からＬＡＮ４０経由でＣＴＩ命令を受信し，又，各種着信信号を，後出ＣＴＩ制御部５４及びデータベース（ＤＢ）制御部５８から受信してクライアントプログラム２４に送信するクライアント制御部５２と，該クライアント制御部５２から送信されたＣＴＩ命令及びＤＢ制御部５８から送信された発信可能データをＰＢＸ３０に送信して，発信処理を行うと共に，ＰＢＸ３０から送られてくる着信，応答，切断等の情報を管理し，プレディクティブ発信した結果，着信した情報はＤＢ制御部５８へ送信し，それ以外の着信情報はクライアント制御部５２へ送信するＣＴＩ制御部５４と，予測発信を行うためのプレディクティブ発信のデータ数（呼数）ＮをＤＢ制御部５８へ通知するペーシング制御部５６と，該ペーシング制御部５６から要求があった発信データ群をプレディクティブ発信用ＤＢ１２から抽出すると共に，抽出したデータをマスタＤＢ１０と比較して，マスタＤＢ１０に存在する発信不要データをチェックし，発信可能なデータをＣＴＩ制御部５４へ送信する一方，発信不要なデータは発信不要データベース（ＤＢ）６０に格納するデータベース（ＤＢ）制御部５８とを備えている（段落【００２５）。」】・図３】前記実施形態のＣＴＩサーバ装置及びその周辺を示すブロック【図・以下図４を参照して本実施形態の処理手順を説明する段落０「，，。」（【０２６）】・図４】前記実施形態におけるリアルタイムコール止め発信処理の全般【を示す流れ図・まずステップ３００で，キャンペーン（業務）単位毎に設定された，「。，図５に示すような条件設定テーブルを読み込む本実施形態においては電話番号Ｔ又は，顧客識別情報の一つであるコールＩＤＣを，データを読み込むためのキーとすることができる（段落【００２７）。」】・次いでステップ３０２で，上位プログラムが終了したか否かを判定す「る。判定結果が否である場合には，本処理を終了し，判定結果が正である場合には，ステップ３０４に進み，ペーシング制御部５６から発信データ数Ｎを取得する（段落【００２８）。」】・次いでステップ３０６に進み，本発明に係るリアルタイムコール止め「／発信処理を行う（段落【００２９）。」】・このリアルタイムコール止め／発信処理は，具体的には，図６に示す「如く行われる。即ち，まずステップ４００で，前記プレディクティブ発信用ＤＢ１２から発信データを抽出する。次いでステップ４０２で，マスタＤＢ１０を検索し，ステップ４０４で，発信不要データではないと判定された時にはステップ４０６に進み発信処理を行う段落０，，。」（【０３０）】・一方，ステップ４０４で発信不要データであると判定された時には，「ステップ４０８に進み，発信せずに発信不要ＤＢ６０に登録する（段。」落【００３１）】・ステップ４０６又は４０８終了後，図４のステップ３０８に戻り，発「信数がＮとなるまで，ステップ３０６のリアルタイムコール止め／発信処理を繰り返す（段落【００３２）。」】・前記実施形態においては，発信不要データを専用の発信不要ＤＢ６０「に登録していたが，マスタＤＢ１０に登録したり，あるいは，マスタＤＢ１０のフラグ等に反映することも可能である。キーの種類も，電話番号やコールＩＤに限定されず，他の顧客識別情報を用いることができる（段落【００３５）。」】イ上記記載によると，本件発明は，従来，プレディクティブ発信を行わな，，くてもよい発信不要データが発生した場合バッチ処理又は人が介在してプレディクティブ発信用データベース１２から発信不要データを削除したり，あるいは，発信停止フラグを立てる等の処理が行われていたところ，そのような従来技術においてはバッチ処理や人の介在によるタイムラグが発生して本来プレディクティブ発信が不要なデータについてのプレディクティブ発信が行われてしまうという問題点があったとの点を解決すべく，「顧客情報を管理しているデータベースからプレディクティブ発信を行うデータを所定の条件で抽出して，プレディクティブ発信用のデータベースを作成した後」に生ずる，マスタデータベースの更新に伴って生ずるプレディクティブ発信用データベースへの更新の伝播のタイムラグという課題を「リアルタイムコール止め」という解決手段によって解決しようとするものであることが認められる。 (2) 引用発明の意義ア引用例１（甲１）には，以下の記載がある（なお，以下の記載はすべて甲１の２記載の和訳により，末尾のかっこ内に原文〔甲１〕の摘示箇所を示す。。）Ａ「メインフレームコンピュータ（１６）は，顧客又は潜在的顧客のアカウント情報，例えば顧客名，顧客電話番号，顧客アカウントコード，顧客注文状態等を保持し顧客アカウント情報群をシステム制御装置１，（１にデータ制御装置１５を介して送信するシステム制御装置１）（）。（１）は幹線インタフェース部（１０ａ ?１０ｄ）に顧客の電話番号をダイヤルし，発信の状態を監視するよう命令する（フロントページ左欄。」２７行?右欄５行）「，，，Ｂ多くのビジネス特に多数の顧客アカウントを有するビジネスは定期的に顧客に電話でコンタクトして，更新されたアカウント情報を得，，，たり顧客に期限経過勘定を督促したり滞納勘定について集金したり又は他の業務を行う。また，幾つかのビジネスは，以前に郵送したカタログ又は広告に応答して電話で行うセールス，或いは顧客に電話をする直接勧誘によるセールスに主に又はだけに基づいている（１欄１２? 。」２０行）Ｃ「このようなビジネスにおいて，顧客アカウント情報は通常，メインフレームコンピュータに記憶され，顧客アカウント情報のコピーがディスク又はテープ等の記憶媒体に記憶される。次に，このコピーは，オペレータ（顧客アカウント，セールス，又はサービス担当者）がアクセスするための別のコンピュータに設置される（１欄２０?２６行）。」Ｄ「従って，オペレータの時間をより有効に使用できるように，オペレータの介入なしに自動的に番号をダイヤルし，呼出しに応答があった場合だけオペレータを接続し，メインフレームにある顧客アカウント記録を表示する方法及び装置が必要とされている（１欄３８?４４行）。」Ｅ「通常，処理されたビジネス用の顧客アカウント情報は，以前に作られたコピーに入力されるか又は別のファイルに保持される従って 1 ，。，日の業務，又はビジネスセッションの終了時に，該コピーの変更は，メインフレームシステム内の顧客アカウント情報に取り込まれ，統合されなければならない（１欄６３?６８行）。」Ｆ「このため，メインフレーム又はシステム制御装置から顧客アカウント情報の最新のコピーを得て，顧客アカウントへの変更を含む最新ファイルに更新するのに貴重なオペレータ時間がまた浪費される（２欄１。」０?１４行）Ｇ「従って，オペレータがメインフレームファイルと変更ファイルの違いを探す必要なく最新の顧客アカウント情報に直ちにアクセスできるように，メインフレーム内の顧客アカウント情報をオンライン又はリアルタイムに更新し，また問題発生時，呼出し結果及び任意の変更を見つけるか又はコピーできるように，顧客アカウント情報になされた変更のコピーと各呼び出しの状態情報を維持するための方法及び装置が必要とされている（２欄１５?２４行）。」Ｈ「本発明は，電話番号をダイヤルさせ，応答を待つ作業からオペレータを解放するための方法及び装置を提供し，予備的な顧客アカウント情報を得る作業からオペレータを解放し，メインフレーム内の顧客アカウント情報のオンライン直接更新を可能にすることで，顧客アカウントファイルに変更を統合する必要をなくし，かつ，オペレータに顧客アカウントの最新情報を提供する（２欄２８?３７行）。」Ｉ「また，本発明は，顧客アカウントの全ての変更の記録と，各発信と各着信の状態の記録とを別に維持しながら，メインフレームファイル内の顧客アカウント情報をオンライン更新するための装置を提供する」。（３欄１?６行）Ｊ「従って，本発明の目的は，顧客アカウントの全ての変更の記録と，必要に応じて，各発信と各着信の状態とを別に維持しながら，メインフレームファイル内の顧客アカウント情報を直ちにオンライン更新するための方法及び装置を提供することである（３欄７?１２行）。」「，Ｋこの好適な実施形態は４つの幹線インタフェース部１０ａ?１０ｄシステム制御装置１１，１６幹線×１０線・クロス点スイッチ１３，データ制御装置１５，メインフレームコンピュータ１６，及び１０個のオペレータ端末１２ａ?１２ｊを備える。１６本の幹線Ｔ１?Ｔ１６は集成幹線インタフェース部１０とクロス点スイッチ１３に接続される。各幹線インタフェース部１０ａ?１０ｄは４つの幹線を収容し，幹線インタフェース部１０ａは幹線Ｔ１?Ｔ４にサービスを提供し，幹線インタフェース部１０ｂは幹線Ｔ５?Ｔ８にサービスを提供する（他同様。）各幹線インタフェース部１０ａ?１０ｄは次の機能：幹線占有，ダイヤリング，呼出し進行監視，メッセージ再生，及びメッセージ記録を実行する。下記に幹線インタフェース部１０ａ?１０ｄについてより詳細に説明する。スイッチ１３はクロス点スイッチである必要はなく，別の同。，，（）様な装置であってもよい例えばスイッチ１３は構内交換ＰＢＸスイッチ等の電話システム又はその一部であってもよい（３欄４８? 。」６５行）Ｌ「ここで本実施形態の動作を考える。メインフレームコンピュータ１６は，所望の数のアカウントの顧客アカウント情報をデータ制御装置１５に一括転送又はオンライン転送により提供する。次にデータ制御装置１５はこの情報をポートＨＰＳ１を介してシステム制御装置１１に提供する。或いは，システム制御装置１１はこの情報を直接メインフレーム１６とそのディスクドライブシステムから得てもよい。次にシステム制御装置１１はアカウント毎に顧客名，顧客電話番号，アカウント番号，及び／又はあるタイプのメインフレームデータベース指標番号を抽出す。，，る幹線Ｔ１が使用可能であると仮定するとシステム制御装置１１は幹線インタフェース部１０ａに幹線Ｔ１を占有するよう命令し，顧客電話番号を幹線インタフェース部１０ａに提供し，幹線インタフェース部１０ａにこの顧客電話番号をダイヤルするよう命令する。幹線インタフェース部１０ａは顧客電話番号をダイヤルし，この呼出しの状態を求めて幹線Ｔ１を監視する（５欄１３?３１行）。」Ｍ「幹線Ｔ１を介して被呼者が応答した時，空いたオペレータが居ない。，と仮定する幹線インタフェース部１０ａはメッセージ再生機を起動しシステム制御装置１１に被呼者が応答したことを通知する。空いたオペレータが居ないことを確認後，システム制御装置１１は幹線インタフェース部１０ａが被呼者へ予め記録された所望のメッセージの再生を続けることを許可する。システム制御装置１１が空いたオペレータが居ると判断すると，システム制御装置１１はクロス点スイッチ１３に，利用可能なオペレータ端末１２を幹線Ｔ１に接続させ，幹線インタフェース部１０ａに幹線Ｔ１を解放し，メッセージを停止し，次のメッセージに進み，短縮された顧客アカウント情報を該利用可能なオペレータ端末１２に送信するよう命令する（６欄２３?３７行）。」Ｎ「キーボード１２ａ６を介してオペレータが行った全ての入力は，端末１２ａ４によってシステム制御装置１１に送信され，オンラインモードにおいてデータ制御装置１５に送信される。本実施形態では，システム制御装置１１は入力の数とタイプ，接続時間等に関する統計を維持する。データ制御装置１５は高速直列ポートＨＳＰ１２を介して変更をメインフレーム１６に送信し，メインフレーム１６は主データベース内の当該顧客アカウント情報を更新する。従って，メインフレーム１６に記憶されオペレータに提供される顧客アカウント情報は最新の情報である（７欄５?１６行）。」Ｏ「また，メインフレーム１６の主データベース内の当該顧客アカウント情報を直ちに更新するので，オペレータが行った顧客アカウント情報への変更を各業務日の終りに統合する必要がないこと，及び一日の任意の時点で顧客が電話をかけてくる，又は顧客を呼出した時，オペレータに提供される顧客アカウント情報は最新の更新された顧客アカウント情報であるという利点があることが理解されるであろう（７欄２１?３。」０行）Ｐ「従って，オペレータによる顧客アカウント情報へのいかなる変更も直ちにメインフレーム１６に提供され，メインフレーム１６は自動的か。，，つ直ちに該顧客アカウント情報を更新するまた自動更新であるのでオペレータに提供されるいかなる情報も最新の情報である。従って，オペレータはメインフレーム１６に直接接続されているように見える。本実施形態では，システム制御装置１１は短縮された顧客アカウント情報だけをオペレータ端末１２に送信するが，もしシステム制御装置１１が十分な記憶容量を有する場合は，システム制御装置１１は顧客アカウントのファイル全体を保持し，この記録全体をオペレータ端末に送信してもよい（７欄３６?５０行）。」（Ｑ「システム制御装置１１により使用されるロジックのフローチャートである図４Ａ及び図４Ｂを参照する。２６からスタート後，第１ステップ２７ではメインフレーム１６から一括モード転送により複数の顧客のアカウント情報を得る。このアカウント情報はメインフレームデータベース指標番号又はキーを含んでもよい。或いは，システム制御装置１１は複数のアカウントの短縮されたアカウント情報，例えば名前，電話番号，アカウント番号，及び／又は指標番号を得てもよい。一括モード転送が好ましいが，もし望むなら，システム制御装置１１はメインフレーム１６から１つの顧客アカウントに関する情報を得てもよい。次のステップ２８では，オペレータの予想される空き状況に基づいて新しい呼出（）。，し又は再呼出しの必要性を計算する空いたオペレータが居る場合新しい呼出し（又は再呼出し）が必要となる。しかし，全てのオペレータが話中である場合，所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合とない場合がある。判定２９は新しい呼出し（又は再呼出し）が必要かを調べる。もし否であれば，システム制御装置１１はステップ２８に戻る。もし必要であれば，システム制御装置１１はステップ３０に進み，呼出す次のアカウントの電話番号を抽出する。判定３１は幾つかの要因に基づいて抽出した電話番号をダイヤルすることが許されるかを検査する。これらの要因は，通常相手が位置するタイムゾーン，該電話番号に以前電話をかけたか，以前かけた該電話番号は話中であった／応答がなかった／使われていなかったか，該電話番号に最後にかけてからの経過時間，該アカウントは昼間／夜間／ある時間帯に呼出すべきかに関する情報，及び所望の優先度（より大きな勘定が優先）を含む。これらの要因に基づいてこの電話番号をダイヤルすることが許されない場合，システム制御装置１１はステップ２８に戻る。この電話番号をダイヤルすることが許される場合，システム制御装置１１はステップ３２に進む（９欄４２行?１０欄１２行）。」Ｒ「ステップ２７でシステム制御装置１１は一群の顧客アカウントのアカウント情報を得るので，その後の着信及び／又は請求に対する支払い及びクレジットにより，システム制御装置１１に記憶されたアカウント情報は，発信待ちの列において特定の顧客アカウントの順番が来る時までに最新ではなくなる可能性がある。この問題を扱う幾つかの方法が存在する。１つの方法は，システム制御装置１１はステップ２７で一度に。，１つのアカウントだけのアカウント情報を得ることである別の方法はメインフレーム１６に情報が入力されるたびに，メインフレーム１６が当該アカウントに関する更新された情報をシステム制御装置１１に送信することである。本実施形態で使用する方法は，アカウントに電話をかける前に，システム制御装置１１がメインフレーム１６に該アカウントの状態を問合せることである。これに応答して，メインフレーム１６は該アカウントの状態に変化があったか否かと，変化があった場合，どんな状態変化が発生したかをシステム制御装置１１に通知する。状態に変化がなかった場合，又は変化が該特定のアカウントに電話をかける必要性に影響しない場合，システム制御装置１１はステップ３２に進む。該アカウントに電話をかけることがもはや適当でない場合，システム制御装置１１はステップ２８に戻る（１０欄１３?３７行）。」・・イ上記記載によれば，引用例１は，顧客のアカウント情報を管理しているメインフレームコンピュータ（１６）内からプレディクティブ発信を行う所望の数の顧客アカウント情報がデータ制御装置１５を介して，システム制御装置１１に転送され，所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っている顧客オンラインサービスシステムにおいて「システム制，御装置１１は一群の顧客アカウントのアカウント情報を得るので，その後の着信及び／又は請求に対する支払い及びクレジットにより，システム制御装置１１に記憶されたアカウント情報は，発信待ちの列において特定の顧客アカウントの順番が来る時までに最新ではなくなる可能性がある上」（記アＲ参照）という課題を解決するため，アカウントに電話をかける前にシステム制御装置１１がメインフレーム１６に該アカウントの状態を問合せて発信不要データであると判定された場合は新しい発信の必要性を計算するという解決手段を採用したという技術であることが認められる。 (3) 原告主張の取消事由に対する判断ア取消事由１（本件発明の要旨認定の誤り）について (ｱ) 原告は，本件発明の要旨認定には誤りがあると主張するが，そもそも審決は，本件発明について，特許請求の範囲請求項１の記載のとおりに要旨を認定しているにすぎず，その記載自体については原告も認めると認否しているのであるから，審決の要旨認定に誤りがあるということはできない。 (ｲ) また，原告は，前記第３，１(4) アのとおり，本件発明は，バッチ処理構成を基本にしつつ，コール止めのリアルタイム処理に必要な構成を採用したという，いわば「バッチ処理とリアルタイム処理のハイブリッド構成」を採用した点に特徴があり，本件発明の「プレディクティブ発信用データベース」が「バッチ処理」により作成されたものであることを前提とした主張を展開している。しかし「プレディクティブ発信用データベース」が「バッチ処理」，により作成されるものである点については，本件特許の特許請求の範囲には何ら記載はなく，本件明細書及び図面にも何ら開示されていない。また，本件発明の意義は前記(1) イのとおりであり，本件発明は，プレディクティブ発信用データベースが作成された後の，発信不要データの発生から発信までのタイムラグを問題とし，この問題の解決を課題としたものであって，プレディクティブ発信用データベースを「バッチ処理」で行うことを前提としたものではなく，プレディクティブ発信用データベースを「バッチ処理」で行う場合に生じる問題の解決を課題としたものでもない。したがって，原告の主張する本件発明の課題認識は，本件明細書に開示された本件発明の課題とは異なるものであって，本件発明の技術内容を正解しないものである。 (ｳ) この点につき，原告は，クレームの「おいて」書きの部分の「プレディクティブ発信用ＤＢを作成した後」という文言は，これがバッチ処理であることを明確に示すものであると主張する。しかし，本件明細書の記載を全体として見た場合「作成」の文言に，よって作成の方法が何ら特定されていないことは後述するとおりであり「作成」の文言からバッチ処理といった意味を読み取ることはでき，ないというべきであるから，この点に関する原告の主張は採用することができない。イ取消事由２（引用発明１認定の誤り）について (ｱ) 前記(2) アの記載によれば，引用例１には，前記(2) イに記載された技術事項が記載されていると認められるから，引用発明１の内容につき前記第３，１(3) イのとおりとした審決の認定に誤りはない。 (ｲ) この点につき，原告は，前記(2 ) アＣ，Ｅ，Ｆ，Ｇ，Ｎ，Ｏ，Ｐ等の記載を根拠として，引用発明１は，プレディクティブ発信用ＤＢをバッチ処理により作成するという過程を強いて取り去り，顧客マスタＤＢだけですべての顧客情報をオンライン処理（リアルタイム処理）で管理する方法を採用しているのであって，プレディクティブ発信用ＤＢを排除することが最大の特徴である旨主張する。しかし，被告主張のとおり，原告が指摘する明細書の記載は，いずれも顧客情報の修正処理に関するものであって，発信処理に係る記載ではないから，そもそも原告の主張は失当である。仮にそうでないとしても，原告の主張ａにおいて「オペレータがア，クセスするための別のコンピュータに設置されるコピー」が「プレディクティブ発信用ＤＢ」に該当するとの原告の主張は，引用例１の記載に基づくものとはいえない。引用例１において「オペレータの時間をよ，り有効に使用できるように，オペレータの介入なしに自動的に番号をダイヤルし，呼出しに応答があった場合だけオペレータを接続（Ｄ）す」るプレディクティブ発信における顧客へのダイヤルを行うに当たって，そのダイヤルによる呼出しに対する応答後に初めて割り当てられて接続されるオペレータ端末上の情報をダイヤル時つまり呼出に対する応答前に参照することはあり得ず，引用例１のオペレータ端末に設置されたコピーは，プレディクティブ発信のための顧客へのダイヤルを行うに当たって決して参照され得ないものであるからである。そして，前記(2) アＬの記載によれば，本件発明の「プレディクティブ発信用のデータベース」に対応させるべき引用例１記載の構成は，上記Ｃにある「オペレータがアクセスするための別のコンピュータに設置される顧客アカウントのコピー」ではなく，むしろ，上記Ｌにある「所望の数のアカウントの顧客アカウント情報」である。したがって，引用例１のオペレータ端末に設置されたコピーが本件発明のプレディクティブ発信用ＤＢに該当するものである旨の主張は，引用例１の記載内容と両立しないものである。また，原告の主張ｂ，ｃ，ｄ，ｅについては，上記原告の主張ａが正しいことを前提としているところ，上記のとおり，この主張は引用例１の記載に基づかないものであるから，この主張は，誤った前提に基づく主張である。すなわち，原告が引用発明１において作成処理が取り除かれたものであると主張しているものは，上記Ｃに記載された「オペレータ（顧客アカウント，セールス，又はサービス担当者）がアクセスするための別のコンピュータに設置されるコピー」であるところ，これは前述したとおり，本件発明におけるプレディクティブ発信用のデータベースに相当する構成ではなく，これを排除するかどうかは本件発明と無関係である。そして，本件発明におけるプレディクティブ発信用のデータベースに相当する引用発明１の構成である上記Ｌにある「所望の数のアカウントの顧客アカウント情報」は，引用発明１において排除されていない。そうすると，引用発明１が本件発明のプレディクティブ発信用のデータベースに相当する構成を排除したものであるとの主張は，引用例１の記載に基づくものではなく，失当である。ウ取消事由３（一致点認定の誤り）について (ｱ) 原告の主張(ｱ) について原告は，本件発明の「プレディクティブ発信用のデータベース」と引用発明１の「所望の数のアカウント情報」とを「データの集合」といった抽象化された概念のレベルで同一視することは不可能でありかつ誤りであると主張する。しかし「プレディクティブ発信用のデータベース」は，顧客の電話，番号を自動的にダイヤルして発信するに当たって顧客情報を管理しているデータベースから抽出して作成されるものであってその文言上デ，，「ータベース」であり，かつ，プレディクティブ発信に用いられるものであることが特定されているとはいえるものの，本願明細書の発明の詳細，「」な説明の記載を精査してもプレディクティブ発信用のデータベースの文言の技術的意義をさらに特定する記載は見当たらない。，，，（。そこでその一般的意義を検討するにまず広辞苑第６版甲１８２００８年株式会社岩波書店）によれば「データベース」とは「系，，統的に整理・管理された情報の集まり」を意味すると認められ，それ。以上の限定はないから「プレディクティブ発信用のデータベース」に，おいても，系統的に整理・管理された情報の集まりであって，プレディクティブ発信時に順次データを参照できればよく，それ以上の管理情報や管理システムの存在を前提とするものではないと認められる。一方，引用発明１の文言の技術的意義についてみると，後記オ(ｵ) で認定するとおり，引用例１における「所望の数の」あるいは「複数の」という文言は「少数の」あるいは「３ないし５の」の意味を含むもの，というよりは，むしろ，処理を遅滞なく行える程度であるとともに発信待ちの間にデータが古くなる程度にまとまった相当の量であるという意味を含んでおり，また，この「所望の数の顧客アカウント情報」からアカウントの電話番号が抽出されてダイヤルされるのであって，そのために必要な整理・管理がなされているものである。そうすると「所望の，数の顧客アカウント情報」は，プレディクティブ発信に用いることができるように系統的に整理・管理された，ある程度まとまった量の情報の集まりであると認められる。また，本件発明における「プレディクティブ発信用のデータベース」がバッチ処理により作成されたものであるか否かは本件発明と無関係の事項であることは，前記ア認定のとおりである。以上によれば，引用発明１の「所望の数のアカウント情報」と本件発明の「プレディクティブ発信用のデータベース」とは「プレディクテ，ィブ発信を行う発信データの集合」である点では共通しているということができるから，この点を一致点として認定した審決に誤りはない。 (ｲ) 原告の主張(ｲ) について原告は，引用発明１の「最新ではなくなる可能性がある「顧客アカ」ウント情報」の中に「インターネット「電子メール」による顧客から」のコンタクトから得られる情報が含まれるとする審決の認定は誤りであると主張する。しかし，本件発明において，顧客からのコンタクトは「顧客から着，信する通話によるインバウンド業務，インターネット，電子メール，又はその他の事務部門における該顧客からのコンタクトと記載され顧」，「客から着信する通話によるインバウンド業務「インターネット「電」，」，子メール「その他の事務部門における該顧客からのコンタクト」は，」，「又は」で接続された択一事項であるから，引用発明１においてこれらのいずれか１つによる顧客からのコンタクトがあれば一致点となるところ，審決においては，引用発明が「顧客から着信する通話によるインバウンド業務」と「その他の事務部門における該顧客からのコンタクト」による顧客からのコンタクトがあることを認定しており，本件発明と少なくとも２つの点で一致しているから，審決の認定に誤りはない。 (ｳ) 原告の主張(ｳ) について原告は，本件発明の「指定されたデータベース」には「顧客マスタＤＢ」以外のＤＢも含んでいることを理由として「引用発明１の『メイ，ンフレームコンピュータ１６に該アカウントの状態を問い合わせる』ことと本件発明の『プレディクティブ発信用のデータベースから抽出された発信データを『電話番号又は他の顧客識別情報をキーとして指定さ，』れたデータベースを指定された条件で検索すること』とは『プレディ，クティブ発信用のデータの集合から抽出された発信データを指定されたデータベースに照会すること』で共通する」とする審決の認定は誤りであると主張する。しかし，本件発明における，検索される「指定されたデータベース」の技術的意義については，特許請求の範囲の文言上何らの限定がなされていないばかりか，本件明細書の発明の詳細な説明をみると，この「指定されたデータベース」の唯一の実施例として「マスターＤＢ１０」を検索する例が記載されているところ，このマスターＤＢ１０は，本件発明の「顧客を管理しているデータベース」に対応する構成であるから，少なくとも「指定されたデータベース」は「顧客を管理しているデータベース」を含むものである。，，「」一方引用発明１は本件発明の顧客を管理しているデータベースに対応する「メインフレームコンピュータ１６」内にある「顧客を管，理しているデータベース」を検索するものである。そうすると，引用発明１の「メインフレームコンピュータ１６」内にある「顧客を管理しているデータベース」は，本件発明における，検索される「指定されたデータベース」に相当する構成でもあるから，この旨を説示した審決に誤りはない。エ取消事由４（引用発明２認定の誤り）について (ｱ) 引用発明２は，相違点２の判断において参照された公知技術であるところ，引用例２（甲２）には，以下の記載がある。・図１８に示す形態での２つのコールセンターで，コールセンター１「からコールセンター２に顧客の不在情報が通知される例を用いる。コールセンター１におけるコールリスト１（２１１（１）は，図１９）で示される内容であるとする。この場合，コールセンター１では，以下の手順で電話をかける（段落【０１３３）。」】・図１８】２つのコールセンター・システムの連携及び各コールセン【ター・システムのホストコンピュータの内部構成の一例を示す図・１９図】コールセンター１でのコールリストの一例を示す図【・顧客選択部２１２（１）は，コールリスト１の最初の顧客Ａ氏の電「話番号を取り出し，Ａ氏に電話をかける。Ａ氏とは電話が繋がり，テレマーケティングが行われたとする。なお，この時点ではＡ氏に関する不在等の情報はないものとする（段落【０１３４）。」】・次に，顧客選択部２１２（１）は，コールリスト１の次の顧客Ｂ氏「の電話番号を取り出し，Ｂ氏に電話をかける。ここで，Ｂ氏は不在であったとする。この場合，不在か否かは，実際にＢ氏の電話番号に電話をかけ，一定時間内に応答があるか否かでＢ氏の不在を判断するので，Ｂ氏に電話をかけてからＢ氏の不在を確認するまでの時間は無駄な時間となる（段落【０１３５）。」】・Ｂ氏の不在を確認すると，顧客情報通知部２１５（１）は，Ｂ氏が「不在である旨の情報をコールセンター２に通知する。その際，送られるデータの例を図２０に示す。この場合は，Ｂ氏が不在である情報，Ｂ氏の不在を発見した時刻Ｂ氏の電話番号が送られる段落０，。」（【１３６）】・図２０】コールセンター１からコールセンター２に送られる不在者【情報の一例を示す図・コールセンター２の顧客情報受信部２１６（２）は，図２０に示さ「れたデータを受け取る。なお，Ｂ氏が不在であることおよびこれを検出した時刻等の情報は，自身の顧客情報受信部２１６（１）に格納するか，あるいはコールリスト１中にフィールドを設けて記録しておく（段落【０１３７）。」】・次に，同時にテレマーケティング業務を行っているコールセンター「２での手順を以下に述べる。コールセンター２におけるコールリスト２（２１１（２）は，図２１で示される内容であるとする（段落）。」【０１３８）】・図２１】コールセンター１からコールセンター２に送られる不在者【情報の一例を示す図・顧客選択部２１７（２）は，コールリスト２の最初の顧客Ｘ氏の電「話番号を取り出し，Ｘ氏を発呼する候補とする。この際，顧客情報受信部２１６（２）を参照し，Ｘ氏の不在情報が届いていないかチェックする。なお，自身で検出したある顧客の不在等の情報をコールリスト中に記録しておく場合，コールリスト２中のＸ氏の不在情報の欄もチェックする（段落【０１３９）。」】・この場合は，Ｘ氏の不在情報は届いていないので，Ｘ氏に電話をか「，，。けＸ氏とは電話がつながりテレマーケティングが行われたとする次に，顧客選択部２１７（２）は，コールリスト２の次の顧客Ｂ氏の。，（），電話番号を取り出すそして顧客情報受信部２１６２を参照し。」（【】）Ｂ氏の不在情報を届いていないかチェックする段落０１４０・ここでは，図２０に示されたＢ氏の不在情報が届けられていたとす「る。顧客選択部２１７（２）は，現在の時刻とＢ氏の不在情報の時刻とを比較し，Ｂ氏の不在が発見された時刻から一定の時間が経過していない場合は，Ｂ氏は不在である確率が大きいと判断し，Ｂ氏への電話は後に回し，コールリスト２の次の顧客であるＹ氏の電話番号を取り出す（段落【０１４１）。」】「，，・このことにより不在である確率の大きいＢ氏に電話をかけてから一定時間内に応答がないことを確認し，Ｂ氏の不在を確認するまでの無駄な時間を省くことができる（段落【０１４２）。」】 (ｲ) 上記記載によれば，引用例２に記載された発呼制御方法は，プレディクティブ発信をしようとする顧客情報について現に発信すべきか否かを照会するに当たり，顧客の電話番号を取り出し，顧客情報受信部２１６（２）を参照することによって，発信する必要のないデータ（発信不要データ）を電話番号で検索するものであることが認められる。そうすると，顧客情報受信部２１６（２）の有する顧客情報を「発信不要データベース」と称することに何ら問題はないから，審決が，引用発明２を「発信データを発信不要データベースに照会して発信不要データであると判定するにあたり，電話番号をキーとして，発信不要データベースを指定された条件で検索する，プレディクティブ発信制御方法」と認定した点に誤りはない。 (ｳ) 原告は，審決の引用発明２に関する認定のうち「顧客情報受信部２，１６(2) が有する顧客情報は，全体として”発信不要データベース”ということができる」との記載部分の発信不要の「顧客情報受信部２１６ (2) が有する顧客情報」は，本件発明における「顧客から着信する通話によるインバウンド業務，インターネット，電子メール，又はその他の事務部門等における顧客からのコンタクト等」のような他のシステム系統から得られた情報を含んでいないなどと主張するが，本件では，本件発明と引用発明１との相違点２の判断に当たって，発信データを指定されたデータベースに「照会」することにより発信不要データであると判定する具体的態様がメインフレームコンピュータに該特定の顧客のアカウントの状態を問い合わせるものである引用発明１に，本件発明のように電話番号又は他の顧客識別情報をキーとして指定されたデータベースを指定された条件で検索するものとするような公知技術を組み合わせる必要があるところ，審決は，引用例２の具体的な記載に基づいて，発信データを指定されたデータベースに照会するに当たって電話番号又は他の顧客情報をキーとして指定された条件で検索することが公知技術であると認定しているものであるから，引用例２には，発信しないデータを電話番号で検索する点が開示されていれば十分なのであって，引用例２の発信しないデータがどのように生成されたものであるかは問題でないというべきである。したがって，この点に関する原告の主張は採用することができない。オ取消事由５（相違点１認定判断の誤り）について (ｱ) 引用発明１における「プレディクティブ発信を行う「顧客アカウン」ト情報」とは，プレディクティブ発信に用いることができるように系統，「」的に整理・管理された情報の集まりであり引用発明１における転送は，プレディクティブ発信において用いられる情報の集まりである「所望の数の顧客アカウント情報」を生成する処理である。また「顧客ア，カウント情報」は「所望の数」のものであるから，所望の数に達したか否かを条件として抽出されたものである。他方，本件発明は，プレディクティブ発信に用いることができるように系統的に整理・管理された情報の集まりを「プレディクティブ発信用のデータベース」と表現し，何らかの条件，方法によってこの情報の集まりを生成することを「所定の条件で抽出」して「作成」すると表現，しているものである。そうすると，引用発明１のプレディクティブ発信に用いることができるように系統的に整理・管理された情報の集まりである「所望の数の顧客アカウント情報」を「プレディクティブ発信用のデータベース」と表現し「所望の数」の情報の集まりが「転送」によって生成されること，を「所定の条件で抽出」して「作成」されると表現することは，当業，者（その発明に属する技術の分野における通常の知識を有する者）が適宜なし得たことである。審決は，上述の論旨を説示したものであって，その内容に誤りはない。 (ｲ) 原告の主張(ｱ) について原告は，本件発明は，バッチ処理構成を基本にしつつ，それに部分的にすなわちコール止めの部分に限ってリアルタイム処理を組み合わせるというハイブリッド型構成であるのに対し，引用発明１は，バッチ処理，，を完全に排除しフルリアルタイム処理型を採用したことを前提として引用発明１にプレディクティブ発信用ＤＢを用いる処理を組み合わせることは，引用発明１の目的を実現不可能にすることになり，阻害事由があるなどと主張する。しかし，本件発明で作成されるプレディクティブ発信用ＤＢがバッチ処理によって作成されることが要求されるものでないこと，引用発明１は，バッチ処理を完全に排除し，フルリアルタイム処理型を採用したものとは解されないことは，前記ア及びイで説示したとおりであるから，この点に関する原告の主張は前提において採用することができない。 (ｳ) 原告の主張(ｲ) について原告は，本件発明は，発信不要データを「指定されたデータベース」から検索するという構成を採用することで，顧客マスタＤＢ以外のＤＢを検索することも可能である旨主張する。しかし，この点が本件発明と引用発明１との相違点でなく一致点であることは，前記ウ(ｳ) で説示したとおりである。原告の主張は審決の論旨を正解しないものであって，採用することができない。 (ｴ) 原告の主張(ｳ)及び(ｴ) について原告は，引用発明１の「所望の数」は「所定の条件」に相当しない，引用発明１の「転送され」るは本件発明の「作成」に該当しない，などと主張する。しかし，本件発明に係る特許請求の範囲の記載及び発明の詳細な説明の記載を精査しても「所定の条件で抽出する」というのがどのような，条件によって抽出することなのか，また「作成する」とはどのような，方法により作成することなのかを直接的に特定する記載はない。かえって前記(1) イで認定したとおり発明の詳細な説明の段落０，，【００２】ないし【０００５】における課題に関する記載からみて，本件発明は，プレディクティブ発信用データベースの作成後に発生する問題の解決を課題としており，プレディクティブ発信用データベースの作成自体に伴う問題の解決を課題としたものではないから，プレディクティブ発信用データベースをどのような条件でどのような方法によって作成するかは，課題解決と無関係の事項であることが読み取れる。したがって，一定の件数を指定して発信対象データを抽出することも「所定の条件」に含まれるというべきであり，引用発明１において「所望の数」の顧客アカウント情報を転送することも「所定の条件」に該当すると解することに何ら問題はないし，コンピュータにおいて，データ「」，，が転送されてそれが他の記憶装置に記録されればその記憶装置にそれまで存在していなかったデータが新たに記録されることになるのであるから，それを「作成」と称することに何ら問題はないというべきであり，したがって，引用発明１のように，ある機器に存在するデータ集合の中から他の機器に「転送」すべきデータ集合を抽出することも転送データの「作成」に該当するということができる。以上のとおりであるから，この点に関する原告の主張は採用することができない。 (ｵ) 原告の主張(ｵ) についてａこの点に関し，原告は，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に「一括送信」されるデータの件数が３ないし５件程度にすぎないこと等を根拠として，引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」は「データベース」ではないと主張する。しかし，前記ウ(ｱ) で認定したとおり「データベース」とは「系，，統的に整理・管理された情報の集まり」を意味すると認められると。ころ，引用発明１においても「所望の数の顧客アカウント情報」か，らアカウントの電話番号が抽出されてダイヤルされるのであって，そのために必要な整理・管理がなされているものであると認められるから，上記の定義に従えば「転送されたプレディクティブ発信を行う，所望の数の顧客のアカウント情報」を「データベース」と称することに何ら問題はない。ｂまた，原告は「一括転送」の対象は「a number of customers」で，あるところ「a number of」は「several」と同義であり，せいぜい，３ないし５件の顧客データにすぎないと主張する。しかし，引用例１の明細書上「一括転送」の対象が数件のデータ，である旨の記載はない。かえって，同明細書には，前記(2)アＰのとおり「システム制御装置１１が十分な記憶容量を有する場合は，シ，ステム制御装置１１は顧客アカウントのファイル全体を保持し，この記録全体をオペレータ端末に送信してもよい」との記載があり，同。記載によれば，システム制御装置１１は顧客アカウントのファイル全体を保持できる程の記憶容量を有することも想定されているといえるものである。ｃさらに，原告は，引用例１のＦＩＧ．４の記載を根拠に，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に送信されるアカウント情報の件数は，本件明細書の段落【００２５】の「該ペーシング制御部５６から要求があった発信データ群」の数（＝Ｎ）と同程度であるなどとして，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に「一括送信」されるデータの件数が数件にすぎないなどとも主張する。，，。しかし上記原告の主張は引用例１の記載を正解したものでないむしろ引用例１の記載からすると，引用例１における「所望の数の」あるいは「複数の」という文言は，プレディクティブ発信のデータ数（呼数）Ｎよりは多い数であって，むしろ，プレディクティブ発信処理を遅滞なく行える程度に，かつ，発信待ちの間にデータが古くなる程度に，まとまった相当の量であるという意味を含んでいると認められる。すなわち，まず，前記(2) アＬの記載からみて，引用例１においては「所望の数の顧客アカウント情報」がシステム制御装置１１に転，送され，その上で，システム制御装置１１がこの「所望の数の顧客アカウント情報」から選択された顧客電話番号にダイヤルしており，メインフレームコンピュータ１６内の顧客のアカウント情報を管理しているデータベース（顧客管理情報を管理しているデータベース）からではなく，転送された「所望の数の顧客アカウント情報」から選択された顧客電話番号にダイヤルしていることが理解される。そして，引用例１の「メインフレームコンピュータ１６は，所望，の数のアカウントの顧客アカウント情報をデータ制御装置１５に一括転送又はオンライン転送により提供する前記(2)アＬの記載２。」（），「６からスタート後，第１ステップ２７ではメインフレーム１６から一括モード転送により複数の顧客のアカウント情報を得る（前記(2) 。」アＱ）の記載「次のステップ２８では，オペレータの予想される空，（）。き状況に基づいて新しい呼出し又は再呼出しの必要性を計算する空いたオペレータが居る場合，新しい呼出し（又は再呼出し）が必要となる。しかし，全てのオペレータが話中である場合，所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合とない場合がある。判定２９は新しい呼出し（又は再呼出し）が必要かを調べる。‥‥もし必要であれば，システム制御装置１１はステップ３０に進み呼出す次のアカウントの電話番号を抽出する前，。」（記(2) アＱ）の記載，及び「ステップ２７でシステム制御装置１１は一群の顧客アカウントのアカウント情報を得るので，その後の着信及び／又は請求に対する支払い及びクレジットにより，システム制御装置１１に記憶されたアカウント情報は，発信待ちの列において特定の顧客アカウントの順番が来る時までに最新ではなくなる可能性がある（前記(2)アＲ）の記載からみて，システム制御装置１１は，プ。」レディクティブ発信を行うオペレータの空き状況等による統計的な予測に基づいて転送された所望の数の顧客アカウント情報からアカウントの電話番号を選択するものであり，また「所望の数の顧客アカウ，ント情報」は転送された後プレディクティブ発信のために選択されるまでの間に転送元となったメインフレームコンピュータの顧客データベースに対して最新ではなくなる可能性がありこれに対して前記(2)，アＲに掲げられる様々な解決方法がある旨が記載されているものである。そうすると，統計的な予測に基づいてプレディクティブ発信を遅滞なく行うために，これを遅滞なく行える程度の量の顧客アカウント情報がシステム制御装置１１に転送されているはずであるから，転送された「所望の数の顧客アカウント情報」は，プレディクティブ発信処理を遅滞なく行う程度にまとまった相当の量のものであるととともに「発信待ちの列において特定の顧客アカウントの順番が来る時ま，でに最新ではなくなる可能性がある」という事態が発生する程度にまとまった相当の量のものであると認められる。さらに，上記原告の主張は，原告が根拠として引用する引用例１のＦＩＧ．４Ａの記載内容とも整合していない。すなわち，本件明細書における「予測発信を行うためのプレディクティブ発信のデータ数（呼数）Ｎ（段落【００２５）というのは，」】「オペレータの予想される空き状況」や「利用可能な幹線」の数に即して決定されるプレディクティブ発信のデータ数なのであるから，引用例１においては，ステップ２８の「オペレータの予想される空き状況に基づいて新しい呼出し（又は再呼出し）の必要性を計算する」やステップ３２の「幹線インターフェイス部に利用可能な幹線を問い合」。，わせるにおける処理の結果に応じて決定されるものであるそしてたかだか予測発信を行うためのプレディクティブ発信のデータ数個「（数）Ｎ」の顧客アカウントのみをメインフレームからシステム制御装，，，置１１に転送するのであればステップ２８２９及びステップ３２３３に対応する処理は，ステップ２７の転送の処理に先だってなされているはずであって，これらの処理が転送後に行われることはあり得ないというべきであるから，引用発明１でメインフレームコンピュータ１６からシステム制御装置１１に送信されるアカウント情報の件数は，本件明細書の段落【００２５】の「該ペーシング制御部５６から要求があった発信データ群」の数（＝Ｎ）と同程度であるということはないというべきである。以上のとおり「a number of」という文言から，直ちに，引用発明，１の「一括転送」が３ないし５件程度のデータの転送であるとの原告の主張は採用できない。したがって，引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」は「データベース」ではないとの原告の主張も失当である。カ取消事由６（相違点２認定判断の誤り）について (ｱ) 前記エ(ｲ) で認定したとおり，引用例２の記載事項からみて，発信データを指定されたデータベースに照会するに当たって電話番号をキーとして指定された条件で検索することは，少なくとも引用例２に記載された公知の技術であると認められる。そして，引用発明１は，プレディクティブ発信をするに当たってメインフレームコンピュータ１６に該特定の顧客のアカウントの状態を問い合わせるのであるから，発信データについて指定されたデータベースに照会するものであるということができる。そうすると，引用発明１において，発信データについて指定されたデータベースに照会するに当たって引用例２に記載された公知技術を採用して，電話番号をキーとして照会するように構成することは，当業者が容易になし得たことであり，この旨を述べた審決に誤りはない。 (ｲ) 原告の主張(ｱ) について原告は，引用発明１は，プレディクティブ発信用ＤＢを排除することに特徴を有する発明であるから，引用発明１に「別のファイル」を用いる構成を組み合わせることには阻害要因があると主張する。しかし，前記イで認定したとおり，引用発明１はオンライン（リアルタイム）処理を実現するために，バッチ処理でのプレディクティブ発信用ＤＢ作成処理を取り去るという構成を採用したものとは認められないから，原告の主張はその前提において失当であり，採用することができない。 (ｳ) 原告の主張(ｲ) 及び(ｳ) について原告は，引用発明２は，複数のコールセンタ間の情報共有に関する発，，明であり本件発明と引用発明２とは課題も課題解決手段も異なるとか引用発明１に引用発明２を組み合わせる動機付けがない旨主張する。しかし，前記エ(ｲ) で説示したとおり，引用発明１に引用発明２を適用するに当たっては，引用例２には発信しないデータを電話番号で検索する点が開示されていれば十分なのであって，引用例２の発信しないデータがどのように生成されたものであるかは問題ではないというべきであるから，引用発明２が，複数のコールセンタ間の情報共有に関する発明であって課題も解決手段も異なっていたとしても，引用発明１において，発信データについて指定されたデータベースに照会するに当たって引用例２に記載された公知の技術を採用して，電話番号をキーとして照会するように構成することは当業者であれば容易になし得たことというべきである。また，引用発明１における転送された顧客アカウント情報の数が３ないし５件程度ではない点は，前記オ( ｵ)で述べたとおりであるから，引用発明１と引用発明２との組合せについて動機付けに欠けるところはない。したがって，原告の主張は，その前提において失当であり，採用することができない。３結論以上のとおり，原告の主張する取消事由は全て理由がない。よって，原告の請求を棄却することとして，主文のとおり判決する。知的財産高等裁判所第１部裁判長裁判官中野哲弘裁判官東海林保裁判官矢口俊哉

判例全文

判例全文

平成２２年（行ケ）第１０００３号審決取消請求事件（特許）
口頭弁論終結日平成２２年１０月５日
判決
原告ＪＦＥシステムズ株式会社
訴訟代理人弁護士上山浩
同小長谷真理
訴訟代理人弁理士高矢諭
被告株式会社ベルシステム２４
※（ただし，平成２２年６月
１日に，本訴提起時の被告で
あった株式会社ベルシステム
２４（承継前被告）を吸収合
併した株式会社ＢＣＪ?４が
同日付けで商号を承継後株式
会社ベルシステム２４に変更
したもの）
訴訟代理人弁護士野口明男
同三好豊
同飯塚卓也
訴訟代理人弁理士原島典孝
主文
１原告の請求を棄却する。
２訴訟費用は原告の負担とする。
事実及び理由
第１請求
特許庁が無効２００９?８００１００号事件について平成２１年１１月３

０日にした審決を取り消す。
第２事案の概要
，「」１本件は名称をコールセンタシステム及びプレディクティブダイヤラ装置
とする発明についての特許第３５０５４６０号（出願日平成１２年２月１７
日，登録日平成１５年１２月１９日，請求項の数１４，甲４。以下「本件特
許」という）の請求項１（以下「本件発明」という）に対し，被告が特許権。。
者である原告を被請求人として特許無効審判請求をしたところ，特許庁が特許
法29条2項違反を理由としてこれを認容する審決をしたことから，これに不
服の原告が取消しを求めた事案である。
２争点は，本件発明が，下記引用例１及び２との関係で進歩性を有するか（特
許法29条2項，である。）
記
・引用例１：米国特許第４７９７９１１号明細書（発明の名称「顧客アカウン
ト・オンラインサービスシステム，特許登録日平成元年（１９８９年）１」
月１０日，甲１。以下これに記載された発明を「引用発明１」という）。
・引用例２：特開平９?２５２３５１号公報（発明の名称「発呼制御方法，公」
，。「」開日平成９年９月２２日甲２以下これに記載された発明を引用発明２
という）。
第３当事者の主張
１請求の原因
(1) 特許庁における手続の経緯
原告（旧商号川鉄情報システム株式会社）は，本件特許の特許権者である
ところ，被告は，平成２１年５月１８日，本件特許の請求項１に対し，本件
，（，）発明は引用発明１と同一である特許法 29条1項3号違反無効理由１
又は引用発明１及び２から当業者が容易にその発明をすることができた（同
条２項違反，無効理由２）ことを理由として，無効審判請求をした。

特許庁は，上記請求を，無効２００９?８００１００号事件として審理し
た上，平成２１年１１月３０日「特許第３５０５４６０号の請求項１に係，
る発明についての特許を無効とする」旨の審決をし，その謄本は同年１２。
月１０日原告に送達された。
(2) 発明の内容
本件特許の請求項の数は１４であるところ，その請求項１（本件発明）の
内容は，次のとおりである。
「顧客情報を管理しているデータベースからプレディクティブ発信を行うデ
ータを所定の条件で抽出して，プレディクティブ発信用のデータベースを作
成した後，該プレディクティブ発信用のデータベースで選択された顧客の電
話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行って
いるコールセンタシステムにおいて，
顧客から着信する通話によるインバウンド業務，インターネット，電子メ
ール，又はその他の事務部門における該顧客からのコンタクトにより，プレ
ディクティブ発信を行わなくてもよい発信不要データが発生した場合に，
該プレディクティブ発信用のデータベースから抽出された発信データを，
プレディクティブ発信時に，電話番号又は他の顧客識別情報をキーとして，
指定されたデータベースを指定された条件で検索することにより，該発信不
要データであると判定された場合には，その発信を中止するリアルタイムコ
ール止めを行うことを特徴とするコールセンタシステム」。
(3) 審決の内容
，。，，ア審決の内容は別添審決写しのとおりであるその要点は本件発明は
引用発明と同一とはいえないが，引用発明１及び２に基づいて当業者が容
易に発明することができたから特許法 29条2項により特許を受けること
ができない，というものである。
イなお，審決が認定した引用発明１及び２の内容は，次のとおりである。

・引用発明１の内容
「顧客のアカウント情報を管理しているデータベース（メインフレーム
コンピュータ（１６）内）からプレディクティブ発信を行う所望の数の
顧客アカウント情報が転送され，所望の数の顧客アカウント情報から選
択された顧客の電話番号を自動的にダイヤルして発信するプレディクテ
ィブ発信業務を行っている顧客オンラインサービスシステムにおいて，
特定の顧客からの着信，請求に対する支払いにより，プレディクティブ
発信を行わなくてもよい発信不要データが発生した場合に，メインフレ
ームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあ
わせ，該発信不要データであると判定された場合には，新しい発信の必
要性を計算する（ステップ２８）顧客オンラインサービスシステム」。
・引用発明２の内容
「発信データを発信不要データベースに照会して発信不要データである
と判定するにあたり，電話番号をキーとして，発信不要データベースを
指定された条件で検索する，プレディクティブ発信制御方法」。
(4) 審決の取消事由
しかしながら，審決には，容易想到とした判断に関し，以下のような誤り
があるから，審決は違法として取り消されるべきである。
ア取消事由１（本件発明の要旨認定の誤り）
本件発明は，バッチ処理でのプレディクティブ発信用データベース（以
下，データベースを「ＤＢ」と称することがある）作成処理を行う従来。
技術のシステム構成を前提としつつ，バッチ処理によりリアルタイム性が
妨げられていた問題を解決すべく，発信不要データを指定されたＤＢに記
録し，プレディクティブ発信時に当該指定されたＤＢを検索することで，
リアルタイムでコール止めを行うことを可能にした点に特徴がある。審決
は，本件発明を正しく把握せず，本件発明の上記の特徴部分の認定を誤っ

たものである。
すなわち，予めプレディクティブ発信用ＤＢをバッチ処理で作成してお
く従来技術のコールセンタシステムでは，一旦プレディクティブ発信用デ
ータが作成された後に発信不要データが生じた場合，発信作業は，既に作
成されて内容が固定されたプレディクティブ発信用ＤＢを用いて行われる
ため，発信不要データが顧客マスタＤＢに書き込まれたとしても，それを
発信業務にすぐに反映させることができないという問題があった。
この場合，発信業務を発信不要データの発生に対応させるためには，従
来技術では，改めてバッチ処理を実行して顧客マスタＤＢから該当するデ
ータを検索・抽出し，プレディクティブ発信用ＤＢに反映させるか，ある
いはオペレータの操作を介在させて顧客マスタＤＢに書き込まれた発信不
要データをプレディクティブ発信用ＤＢに反映させることが必要であっ
た。しかし，これらの作業には一定の時間を要するため，タイムラグが生
じてしまい，結局，従来技術では，発信不要データが発生しても，リアル
タイムでコール止めを行うことができないという問題点があった。
本件発明は，プレディクティブ発信用ＤＢ作成を行うという従来の構成
，，，を踏襲しつつ上記の問題を解決した発明でありその課題解決の方法は
「プレディクティブ発信を行わなくてもよい発信不要データが発生した場
合に，当該発信不要データを「指定されたＤＢ」に記録し，プレディク」
ティブ発信時に当該指定されたＤＢを検索することで，リアルタイムコー
ル止めを実現するというものである。つまり，本件発明は，プレディクテ
ィブ発信時に用いるＤＢ（プレディクティブ発信用ＤＢ）をバッチ処理で
作成することにより，高い処理効率を可能にし，かつ，コストの低減も可
能にしつつ，所定の構成を組み合わせることでコール止めのリアルタイム
処理を可能にしたものである。
確かに，本件明細書（特許公報，甲４）には，本件発明の処理が「バッ

チ処理」であることの直接的な記載はないものの，技術常識に照らせば，
，，それがバッチ処理であることはいうまでもなく明白であるばかりかまた
本件特許のクレームの「おいて」書きの部分の「プレディクティブ発信用
のデータベースを作成した後」という文言自体，これがバッチ処理である
ことを明確に示すものである。
以上のとおり，本件発明は，バッチ処理構成を基本にしつつ，コール止
めのリアルタイム処理に必要な構成を採用したという，いわば「バッチ処
理とリアルタイム処理のハイブリッド構成」を採用した点に特徴があり，
審決は，このような本件発明の要旨認定を誤ったものである。
イ取消事由２（引用発明１認定の誤り）
(ｱ) 一般的なプレディクティブ発信処理のコールセンタシステムでは，一
日の間にプレディクティブ発信を行う対象の顧客データを予めバッチ処
理で顧客マスタＤＢから抽出し，プレディクティブ発信用のＤＢを作成
しておく方式が採用されている。しかし，このバッチ処理によりプレデ
ィクティブ発信用ＤＢを作成してプレディクティブ発信を行う従来技術
では，顧客データに何らかの変更が生じた場合，直ちにその変更を発信
業務に反映させることができないという問題点があった。
引用発明１は，上記の従来技術の問題点を解決するため，プレディク
ティブ発信用ＤＢをバッチ処理により作成するという過程を取り除き，
プレディクティブ発信時にリアルタイムで顧客マスタＤＢから発信用デ
ータを直接抽出する構成を採用した点に特徴がある。すなわち，引用発
明１の最大の特徴は，バッチ処理でプレディクティブ発信用ＤＢを作成
する処理を排除している点にある。審決は，引用発明１を正しく把握し
ておらず，上記のような引用発明１の特徴部分の認定を見落としている
ものである。
ａまず，後記第４，２(2) アＣの記載の「メインフレームコンピュー

タに記憶される顧客アカウント情報」は「顧客マスタＤＢ」に該当す
る。また「オペレータ（顧客アカウント，セールス，又はサービス，
）」担当者がアクセスするための別のコンピュータに設置されるコピー
は，オペレータがこれにアクセスし，この情報に基づいてダイヤルす
るためのものであるから「発信用のＤＢ」に該当し，これをプレデ，
ィクティブ発信用の装置に用いる場合は「プレディクティブ発信用Ｄ
Ｂ」に該当する。なお，一般に，あるマスタＤＢから所定の条件に合
致するデータを検索・抽出して他のＤＢを作成する処理がバッチ処理
で行われることは，技術常識である。
ｂ後記第４，２(2) アＥの記載の「処理されたビジネス用の顧客アカ
ウント情報」とは，上記ａの「メインフレームコンピュータに記憶さ
れる顧客アカウント情報」について１日の業務の中で何らかの処理が
行われて変更が生じた情報を意味しており「顧客データに生じた変，
更」に相当する。
すなわち，上記Ｅの記載では，通常のコールセンタ業務において顧
客データに変更が生じた場合，その変更内容は「以前に作られたコピ
ー」又は「別のファイル」に保存され，直接顧客マスタＤＢや発信用
のＤＢには書き込まれないので「１日の業務，又はビジネスセッシ，
ョンの終了時」にその変更情報を「メインフレーム内の顧客アカウン
ト情報」すなわち「顧客マスタＤＢ」に書き込まなければならないこ
とが述べられている。この処理のサイクルないしタイミングが「１日
の業務，又はビジネスセッションの終了時」であることから，これは
バッチ処理によって行われることが自明である。
ｃそして，後記第４，２(2) アＦの記載には，以前に作って別に保存
された「顧客アカウント情報のコピー「ディスク又はテープ等の記」，
憶媒体に記憶される顧客アカウントのコピー」又は「別のファイル」

に保存されている顧客データに生じた変更を「メインフレーム又はシ
ステム制御装置」を介して「顧客マスタＤＢ」に書き込む作業をオペ
レータが行う場合，オペレータの時間が浪費されてしまうという課題
。「」があげられているこの貴重なオペレータの時間がまた浪費される
は，本件明細書の段落【０００５】に記載された課題と同様の課題で
ある。
このように，引用発明１が従来技術のシステム構成から生じる課題
としてあげているのは，バッチ処理により顧客マスタＤＢからプレデ
ィクティブ発信用ＤＢを予め作成しておくシステム構成における課題
である。
，，「」ｄ後記第４２(2)アＧの記載から明らかなとおり顧客マスタＤＢ
からバッチ処理により「プレディクティブ発信用ＤＢ」を作成する従
来技術のコールセンタシステムで生じる課題解決のために，引用発明
１は，プレディクティブ発信用ＤＢの作成処理を強いて取り去り，顧
客マスタＤＢだけですべての顧客情報をオンライン（リアルタイム）
処理で管理する方法を採用しているのであり，引用発明１がプレディ
クティブ発信用ＤＢを作成しないオンライン（リアルタイム）処理を
採用するものであることは，後記第４，２(2) アＨ，Ｉ，Ｊの各記載
からも明らかである。
ｅこのような構成を採用した結果引用発明１では後記第４２(2) ，，，
アＮ，Ｏ，Ｐに記載のとおり「メインフレーム１６は自動的かつ直，
ちに該顧客アカウント情報を更新する。また，自動更新であるので，
オペレータに提供されるいかなる情報も最新の情報である。従って，
オペレータはメインフレーム１６に直接接続されているように見え
る」という効果を得ることができるのであるから，引用発明１は，バ
ッチ処理でのプレディクティブ発信用ＤＢの作成処理を取り除き，そ

れに代えて顧客マスタＤＢから直接プレディクティブ発信の対象デー
タを抽出するというオンライン（リアルタイム）処理を採用した点に
特徴を有していることは明らかである。
(ｲ) 被告は，引用発明１においてもプレディクティブ発信用ＤＢを作成し
ていることは明らかであると主張する。しかし，引用例１には，プレデ
ィクティブ発信用「ＤＢ」が「作成」されることは，どこにも開示され
ていない。引用例１に開示されているのは「所望の数の顧客アカウン，
ト情報」が「転送」されることのみである。
ウ取消事由３（一致点認定の誤り）
(ｱ) 審決は，本件発明と引用発明１との一致点につき，引用発明１の「転
送され」た「所望の数の顧客アカウント情報」も，本件発明の「プレデ
ィクティブ発信用のデータベース」も「プレディクティブ発信用のデー
タの集合」であることに変わりはないとする。
しかし，引用発明１で「転送される「所望の数のアカウント情報」」
とは，発信対象となる数件の顧客データの通信（転送）データを意味す
るにすぎず，顧客マスタＤＢから別個のファイルとして作成される「デ
ータベース」とは全く異なるものであるから，本件発明の「データベー
」「」「」スと引用発明１の所望の数のアカウント情報とをデータの集合
といった抽象化された概念のレベルで同一視することは不可能でありか
つ誤りである。
また，引用発明１で「メインフレーム１６」に「アカウントの状態に
変化があったか否か等を問い合わせる対象のデータはオンラインリ」，（
アルタイム）処理によって抽出された発信データであって，本件発明の
ようにバッチ処理にて作成されたプレディクティブ発信用ＤＢから抽出
された発信データとは異なる。
したがって「両者は『プレディクティブ発信用のデータの集合を得，

て，該プレディクティブ発信用のデータの集合で選択された顧客の電話
番号を自動的にダイヤルして発信する』点で共通する」との審決の認定
は誤りである。
(ｲ) 次に，本件発明では，コールセンタ業務とは異なる別系統の情報であ
るインターネットや電子メールにより顧客からコンタクトがあった場合
にも発信直前にコール止めを行うことができる。
ところが，引用発明１には「インターネット」及び「電子メール」に
よる顧客からのコンタクトにより発信不要データが生じることについて
は，開示もなければ示唆もない。引用発明１は本件発明の１３年前に出
願されたものであり，インターネットや電子メールでの顧客からのコン
タクトに対応するといった構成及び効果を想定していないことは明らか
である。
したがって，引用発明１に「インターネット「電子メール」での顧」
客からのコンタクトについて開示がなくとも「着信及び／又は請求に，
対する支払及びクレジット」により「最新ではなくなる可能性がある」
「顧客アカウント情報」の中に「インターネット「電子メール」によ」
る顧客からのコンタクトから得られる情報が含まれるとする審決の認定
は誤りである。
(ｳ) そして，コール止めについて，引用発明１には「顧客マスタＤＢ」，
を意味する「メインフレーム１６」に該アカウントの状態を問い合わせ
ることが開示されているのみである。
一方，本件発明は，プレディクティブ発信時に発信用データについて
「指定されたデータベース」に「指定された条件で検索する」という構
成を採用することで「顧客マスタＤＢ」以外のＤＢを検索することも，
可能にしているのであって，本件発明の「指定されたデータベース」に
は「顧客マスタＤＢ」以外のＤＢも含んでいる。

したがって「引用発明１の『メインフレームコンピュータ１６に該，
アカウントの状態を問い合わせる』ことと本件発明の『プレディクティ
ブ発信用のデータベースから抽出された発信データを『電話番号又は，』
他の顧客識別情報をキーとして指定されたデータベースを指定された条
件で検索すること』とは『プレディクティブ発信用のデータの集合か，
ら抽出された発信データを指定されたデータベースに照会すること』で
共通する」とする審決の認定は誤りである。
(ｴ) 以上にかんがみ，引用発明１と本件発明の一致点をあげるならば，次
の点のみである。
「顧客情報を管理しているデータベースから，選択された顧客の電話番
号を自動的にダイヤルして発信するプレディクティブ発信業務を行って
いるコールセンタシステムにおいて，
顧客から着信する通話によるインバウンド業務，又は事務部門におけ
る該顧客からのコンタクトにより，プレディクティブ発信を行わなくて
もよい発信不要データが発生した場合に，
プレディクティブ発信時に，発信データが発信不要データであると判
定された場合には，その発信を中止するリアルタイムコール止めを行う
コールセンタシステム」。
エ取消事由４（引用発明２認定の誤り）
審決は，引用発明２を，前記のとおり「発信データを発信不要データベ
ースに照会して発信不要データであると判定するにあたり，電話番号をキ
ーとして，発信不要データベースを指定された条件で検索する，プレディ
クティブ発信制御方法」と認定しているが，次のとおり，その認定は誤り
である。
引用発明２は，複数のコールセンタ間での顧客の不在・話中の情報共有
に関する発明であり「アウトバウンド業務」で得られた情報を「アウト，

バウンド業務」の処理に反映するものである。
一般に，コールセンタシステム全体としては，顧客の様々な情報（例え
ば，契約の締結，解除，住所変更，職場の変更等）を取り扱う業務系コン
ピュータシステムと，プレディクティブ発信処理を行うシステムは，別系
統のシステムとして構成されている。プレディクティブ発信処理を行うシ
ステムは，例えば，ＰＤＳ（Predi ctive Dialer System）のような専用装
置が用いられることが一般的である。発信処理，すなわち，アウトバウン
ド業務は，このＰＤＳにより処理される。これに対して，インバウンド業
務すなわち顧客からの様々なコンタクトの情報を顧客マスタＤＢで管理す
る業務は，一般に専用システムのＰＤＳで行うことはできず，業務系コン
ピュータシステムで行われるようになっている。
引用発明２は，コールセンター１のＰＤＳによるアウトバウンド業務で
得た情報をコールセンター２のＰＤＳによるアウトバウンド業務に反映さ
せるものであって，コールセンター１とコールセンター２は，それぞれの
業務系コンピュータシステムが保有するアウトバウンド業務以外の別系統
のシステムから得た情報を活用することは不可能である。
したがって，審決の引用発明２に関する認定のうち「顧客情報受信部，
２１６(2) が有する顧客情報は，全体として”発信不要データベース”と
いうことができるとの記載部分の発信不要の顧客情報受信部２１６(2) 」「
が有する顧客情報」は，本件発明における「顧客から着信する通話による
インバウンド業務，インターネット，電子メール，又はその他の事務部門
等における顧客からのコンタクト等（本件明細書の段落【０００４）の」】
ような他のシステム系統から得られた情報を含んでおらず，審決が「発信
不要データベース」と称する顧客情報は，本件発明で発信不要データの検
索対象となる「指定されたデータベース」が保有するような他のシステム
系統から得られた情報を含まない。

オ取消事由５（相違点１認定判断の誤り）
(ｱ) 本件発明は，前述のとおり，バッチ処理構成を基本にしつつ，それに
部分的にすなわちコール止めの部分に限ってリアルタイム処理を組み合
わせるというハイブリッド型構成を採用することで，バッチ処理のメリ
ットを確保しつつ，リアルタイム性を部分的に実現している点に特徴が
ある。
これに対し，引用発明１は，前述のとおり，バッチ処理を完全に排除
し，フルリアルタイム処理型を採用することで，バッチ処理のメリット
を犠牲にしつつ，常に最新の情報を扱えるというリアルタイム処理の恩
恵を最大限に追求している点に特徴がある。
ところで，バッチ処理とオンライン（リアルタイム）処理とでは，情
報システムの基本的な性格が対極にあるから，システムに要求される処
理内容に応じて，バッチ処理構成を採用するか，オンライン（リアルタ
イム）処理構成を採用するかが必然的に決定される。すなわち，バッチ
処理とオンライン（リアルタイム）処理は二律背反であって，片方を選
択しながらもう一方のメリットも取りうるものではなく，コールセンタ
業務において，バッチ処理によるプレディクティブ発信用ＤＢを作成す
るか，プレディクティブ発信用ＤＢを作成せずにオンライン（リアルタ
イム）処理を行うかは，システムの基本構成として両極端の選択であっ
て，審決のいうような「発信業務の目的と，元より存在する顧客データ
ベースが内容としてどのような性質や規模の顧客情報を有していたかに
応じて従属的に決まる設計事項にすぎない」というものではない。
したがって，引用発明１においては，プレディクティブ発信用ＤＢを
作成し用いることは，絶対にあり得ないことである。このような構成を
採用したとたん，従来技術に後戻りしてしまい，引用発明１の目的を達
成できなくなってしまうからである。したがって，引用発明１にプレデ

ィクティブ発信用ＤＢを用いる処理を組み合わせることは，引用発明１
の目的を実現不可能にすることになり，阻害事由がある。よって，その
ような構成を当業者が想到することはあり得ない。
(ｲ) 本件発明は，発信不要データを「指定されたデータベース」から検索
するという構成を採用することで，顧客マスタＤＢ以外のＤＢを検索す
ることも可能としている。これに対し，引用発明１は，変更が生じたデ
ータをすべて顧客マスタＤＢに書き込むことが必須であり，その書き込
みに要する時間と検索に要する時間から生じる発信処理とのタイムラグ
は避けられない。
このように，本件発明は引用発明１と比較してはるかに優れた作用効
果を有するのであるから，この点においても，引用発明１において相違
点１のように構成することは，容易想到とはいえない。
(ｳ) 引用発明１の「所望の数」は「所定の条件」に相当しない。，
バッチ処理によりプレディクティブ発信用ＤＢを作成しプレディクテ
ィブ発信を行う従来技術のコールセンタ業務において，プレディクティ
ブ発信を行うデータを抽出する「所定の条件（本件発明）とは，顧客」
情報内にある男女の別，年齢，居住地域，履歴等の顧客の属性に関する
情報を条件とすることを意味し例えば１００件２５００件などの所，，「
望の数（引用発明１）を条件とすることを意味しないことは，当該コ」
ールセンタシステムを扱う当業者にとって自明である。
(ｴ) 引用発明１の「転送され」るは，本件発明の「作成」に該当しない。
引用例１の記載である後記第４，２(2)アＬの「メインフレームコン
ピュータ１６は，所望の数のアカウントの顧客アカウント情報をデータ
制御装置１５に一括転送又はオンライン転送により提供する」におけ。
る「転送」は「顧客アカウント情報」を「メインフレームコンピュー，
タ１６」から「データ制御装置１５」に送ることを意味しているにすぎ

ない。
また，後記第４，２(2)アＱの「２６からスタート後，第１ステップ
２７ではメインフレーム１６から一括モード転送により複数の顧客アカ
ウント情報を得る」における「転送」は「メインフレーム１６」から。，
「システム制御装置１１」に「複数の顧客アカウント情報」が送られる
ことを意味しているにすぎない。
そして「転送」の語彙自体に「作成」の意味は含まれず「他から送，，
られてきたものを，さらに他へ送ること」を意味することは，一般常識
である。
(ｵ) 引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧
客のアカウント情報」は「データベース」ではない。
引用発明１における「転送され」は，後記第４，２(2) アＬの引用例
１の記載によれば「一括転送又はオンライン転送」されるものであり，
その「一括転送」の対象は「a number of customers」であるところ「a ，
number of」は「several」と同義であり，せいぜい３ないし５件の顧客
データにすぎない。
このように，引用発明１でメインフレームコンピュータ１６からシス
テム制御装置１１に「一括送信」されるデータの件数が数件にすぎない
ことは，引用発明１における自動発信処理の仕方からも明らかである。
すなわち，引用発明１における自動発信処理は，まず，メインフレー
ムコンピュータ１６が顧客のアカウント情報のファイルから読み出した
数件のデータを自動発信処理を行う装置であるシステム制御装置１１に
送信する。ここで送信されるデータ（アカウント情報）の件数は，回線
あるいはオペレータの空きが出ないように効率的に自動発信するのに必
要な件数であるから，本件特許に関する後記第４，２(1)の段落【００
２５】の「該ペーシング制御部５６から要求があった発信データ群」の

件数と同程度といえる。なぜなら，引用例１添付のＦＩＧ．４Ａのフロ
ーチャート２５と２７の流れから明らかなように，引用発明１は，ステ
ップ２７で受信した一群の発信データの処理が一通り終わると，また次
の一群のデータをメインフレームコンピュータ１６から受信するように
なっているが，この処理の流れは，本件明細書の図４のステップ３０４
から３０８の流れとほぼ同様のものである。したがって，引用発明１で
メインフレームコンピュータ１６からシステム制御装置１１に「一括送
信」されるデータの件数は，本件明細書の図４の「」とほぼ同様の件 N
数と考えられるからである。
，（）また引用発明１のシステム制御装置１１はファイル磁気ディスク
を備えておらず，メインフレーム１６から転送された顧客アカウント情
報は，システム制御装置１１のメモリ上に記憶される。しかし，引用発
明１が出願された１９８７年当時の主記憶容量は極めて限られていたか
ら，この点でもシステム制御装置１１に一括転送される顧客アカウント
情報の件数がごく少数であったことは明白である。
以上のように，引用発明１の「転送されたプレディクティブ発信を行
う所望の数の顧客アカウント情報」は，せいぜい３ないし５件のごく少
数の顧客アカウント情報にすぎず「データベース」として系統的な整，
理・管理が可能なほどの大量のデータではないから，これを「データベ
ース」と称することは明白な誤りである。
カ取消事由６（相違点２認定判断の誤り）
次のとおり，引用発明１に引用発明２を組み合わせることに想到するこ
とは極めて困難である。
(ｱ) 引用発明１は，プレディクティブ発信用ＤＢを排除することに特徴を
有する発明であるから，引用発明１は，後記第４，２(2) アＥに記載さ
れた「処理されたビジネス用の顧客アカウント情報は，以前に作られた

コピーに入力されるか，又は別のファイルに保持される」という従来技
術の構成を排除し，すべてのデータを顧客マスタＤＢのみで管理するよ
うにすることでその目的を実現しているしたがって引用発明１に別。，「
のファイル」を用いる構成を組み合わせることには阻害要因があるとこ
ろ，引用発明２の不在情報が記録される引用例２の【図１９】及び【図
２１】のテーブルは，引用例１の上記Ｅ記載の「処理されたビジネス用
の顧客アカウント情報は‥‥別のファイルに保持される」に相当するか
ら，引用発明１に引用発明２の不在情報が記録される「別のファイル」
の構成を適用することには阻害事由がある。
，，，よって引用発明１に引用発明２を適用することは阻害事由があり
容易想到とはいえない。
(ｲ) 引用発明２は，複数のコールセンタ間の情報共有に関する発明であっ
て，ＰＤＳがアウトバウンド業務で得た情報を別のＰＤＳと共有するも
，，のであってインバウンド業務等を処理する業務系システムが保有する
アウトバウンド業務以外の別系統のシステムから得た情報を活用するこ
とはできない。これに対し，本件発明は，インバウンド業務で得た情報
をアウトバウンド業務に反映させるという，別系統のシステムの垣根を
越えて発信不要データを利用するものである。本件発明は，当該構成を
採用することで，顧客の架電状況（不在又は話中）以外の「インターネ
ット，電子メール，又はその他の事務部門等における顧客からのコンタ
クト等」を活用できるから，引用発明２とは課題も課題解決手段（すな
わち発明の構成）も異にする。
(ｳ) 仮に引用発明１と引用発明２とを組み合わせて，他のコールセンタか
ら発信不要データに該当する情報を得たとしても，当該発信不要データ
に該当する顧客アカウント情報とオンライン処理によりまさしく今発信
しようとして転送した「a number of customers ，すなわち，わずか３」

ないし５件の顧客アカウント情報が一致する確率は極めて小さい。した
がって，引用発明１に引用発明２を組み合わせる意義は非常に乏しく，
組み合わせの動機付けがないというべきである。
２請求原因に対する認否
請求原因(1)ないし(3) の各事実は認めるが，(4)は争う。
３被告の反論
審決の認定判断に誤りはなく，原告主張の取消事由はいずれも理由がない。
(1) 取消事由１に対し
アそもそも，審決が認定した「本件特許発明の要旨」は，本件特許の特許
，，請求の範囲の記載に基づいて記載されたものにすぎずこの点については
原告も審決が行った当該認定を認めているのであるから，本件発明の要旨
認定には何ら誤りはない。
イまた，原告は，審決の要旨認定において，本件発明がプレディクティブ
発信用ＤＢがバッチ処理によって作成されていると限定されていないこと
が要旨認定の誤りであるかのように主張している。
しかしながら，本件発明で作成される「プレディクティブ発信用のデー
タベース」が，原告が主張するような「バッチ処理」によって作成される
ものであると解釈される理由は，特許請求の範囲の文言上存在しないし，
発明の詳細な説明等においても存在しない。
したがってプレディクティブ発信用データベースがおよそ必ずバ，「」「
ッチ処理」によって行われるものであるという前提で「本件発明は，‥ ，
‥，いわば『バッチ処理とリアルタイム処理のハイブリッド構成』を採用
した点に特徴がある」等と主張し，審決が本件発明の要旨認定を誤った。
という原告の主張は根拠がない。
(2) 取消事由２に対し
ア原告は，この点に関し，要するに，引用発明１においてはプレディクテ

ィブ発信用ＤＢが作成されておらず，プレディクティブ発信用ＤＢを排除
することが最大の特徴である旨主張する。
しかし，次に述べるとおり，引用発明１においてもプレディクティブ発
信用ＤＢを作成していることは明らかであり，原告の主張こそ，引用発明
１の技術的な理解を根本的に誤ったものにほかならない。
すなわち，引用例１には，後記第４，２(2) アＡ，Ｌ，Ｑのとおり，原
告の引用する箇所とは別に，プレディクティブ発信用データの作成に関す
る記載がある。これらの記載によれば，メインフレームコンピュータから
データ制御装置を介してシステム制御装置に転送される「顧客アカウント
情報」に基づいて電話番号がダイヤルされるのであるから，これらが本件
発明における「プレディクティブ発信用のデータ」に相当することは明ら
かである。そして「所望の数の顧客アカウント情報」が転送されるので，
あるから，これが「プレディクティブ発信用のデータの集合」であること
は当然である。したがって，引用発明１においてもプレディクティブ発信
用ＤＢを作成していることは明らかである。
イまた，原告は，引用発明１は，プレディクティブ発信用ＤＢの作成処理
を強いて取り去り，顧客マスタＤＢだけですべての顧客情報をオンライン
（リアルタイム）処理で管理する方法を採用していると主張する。
しかし，原告が指摘する明細書の記載は，いずれも，メインフレームコ
ンピュータに格納された顧客アカウント情報を修正する場合に，当該修正
をオンラインで行うことを指摘したものにすぎず，メインフレームコンピ
ュータから発信対象となる架電先のデータをどのように抽出するかについ
ての構成を述べたものではないし，また，プレディクティブ発信用ＤＢを
。，，作成する構成と矛盾するものでもないすなわち引用発明１においては
メインフレームコンピュータから所望の数の顧客アカウント情報を抽出し
てプレディクティブ発信用ＤＢを作成してプレディクティブ発信の用に供

するが，その後にメインフレームコンピュータ内の顧客アカウント情報を
修正する場合には，当該情報の修正をオンラインで行う。そして，プレデ
ィクティブ発信用ＤＢとメインフレームコンピュータ内の顧客アカウント
情報との間に生じうる齟齬については，後記第４，２(2)アＲに記載され
ているとおり，発信の際に最新のデータをメインフレームコンピュータに
問い合わせることによって解決しているのである。上記Ｒの記載が開示す
る第１の方法（システム制御装置１１はステップ２７で一度に１つのアカ
ウントだけのアカウント情報を得ること）こそが，原告の主張するリアル
タイム抽出処理にほかならないのであって，引用発明１は，このリアルタ
イム抽出処理とは明確に異なる「別の一つの」方法，すなわち，システム
制御装置１１に複数の顧客アカウント情報が記憶され，発信を待っている
ことを前提に，システム制御装置１１が発信の順番の到来した顧客アカウ
ント情報についてメインフレーム１６に問い合わせるという構成をとるこ
とによって，システム制御装置１１に記憶されたアカウント情報（プレデ
ィクティブ発信用ＤＢである）と，メインフレームに記憶された顧客ア。
カウント情報との間に生じうる齟齬を解決することを明らかにしているの
である。
したがって，引用発明１は，顧客マスタＤＢだけですべての顧客情報を
オンライン（リアルタイム）処理で管理する方法を採用しているものでは
ない。
ウ以上のとおり，審決が行った引用発明１の内容の認定には何ら誤りがな
い。
(3) 取消事由３に対し
この点に関する原告の主張は，結局のところ，本件発明の要旨に関する原
告独自の理解と，引用発明１の内容に対する独自の理解に基づくものにすぎ
ないから，前記(1) 及び(2) で論じたところからすれば，審決が行った一致

点の認定には何らの誤りもないが，念のため，反論する。
ア原告の主張(ｱ) に対し
そもそも審決は「所望の数の顧客アカウント情報」と「プレディクテ，
ィブ発信用のデータベース」とが一致点であるとは認定しておらず，むし
ろ相違点として認定しているのであるから，原告の主張は，審決の認定を
争う理由になり得ず，主張自体失当である。
イ原告の主張(ｲ) に対し
本件発明において，顧客からのコンタクトは「顧客から着信する通話，
によるインバウンド業務，インターネット，電子メール，又はその他の事
務部門における該顧客からのコンタクト」と記載されており「又は」に，
よって接続されていることから明らかなように，これらのいずれか１つに
。，よるコンタクトがあれば一致点と認定することに不足はないしたがって
引用発明１に「インターネット」及び「電子メール」による顧客からのコ
ンタクトが記載されていなくても，他の点については記載されているので
あるから，これを一致点とすることに問題はなく，審決に誤りはない。
ウ原告の主張(ｳ) に対し
原告は，引用発明１で，発信直前に顧客アカウントの状態を問い合わせ
る先が「メインフレーム１６」であるのに対し，本件発明では「指定され
たデータベース」である点で相違すると主張するが，原告のこの主張は，
本件特許における「指定されたデータベース」が，実施例においては「マ
スタＤＢ１０」とされている（段落【００３０，図６参照）ことを忘れ】
た主張である。すなわち，引用発明１の「メインフレーム１６」が，上記
実施例の「マスタＤＢ１０」に相当するものであることは，原告も認めて
いるところ，本件発明の実施態様として複数の実施態様が考えられる場合
に，そのうちの一部の実施態様について公知文献の開示があれば，本件発
明の進歩性を否定することができるのであるから，引用発明１の「メイン

フレーム１６」が，本件発明の「指定されたデータベース」に相当するこ
とに疑問の余地はないというべきであって，原告の主張は失当である。
(4) 取消事由４に対し
，，原告は審決が引用発明２についても誤った認定をしていると主張するが
技術思想の相違を述べるに留まり，原告の主張は不明確というほかない。
また，引用発明２の認定について，原告は「審決が『発信不要データベー
ス』と称する顧客情報は，本件発明で発信不要データの検索対象となる『指
定されたデータベース』が保有するような他のシステム系統から得られた情
報を含まない」ことを強調しているが，審決の文言上，上記の点は審決の認
定の内容とはなっていないのであるから，引用発明２の認定誤りの根拠とは
なり得ない。したがって，審決が行った引用発明２の内容の認定には何らの
誤りもない。
(5) 取消事由５に対し
ア原告の主張(ｱ) に対し
原告は，本件発明と引用発明１との相違点１についての審決の認定誤り
の具体的内容として，プレディクティブ発信用のデータの集合を作成する
に当たり本件発明はバッチ処理によっているのに対し引用発明１はオ，，「
ンライン（リアルタイム）処理」によっている点で根本的に相違するなど
と主張する。
しかしながら，既に指摘したように，本件発明で作成されるプレディク
ティブ発信用ＤＢがバッチ処理によって作成されることが要求されている
ものとは解されないから，原告が主張するようにプレディクティブ発信用
ＤＢをバッチ処理により作成することを本質的な要素とするものと解する
ことはできない。
のみならず，そもそも引用発明１においては，メインフレーム１６から
所望の数の顧客アカウント情報を取り出してシステム制御装置に転送する

処理は「一括モード転送が好ましい」とされ，まさに「バッチ処理」を，
予定しているのであるから，引用発明１が「オンライン（リアルタイム）
処理」によっているとの主張も誤りである。
イ原告の主張(ｲ) に対し
原告は，本件発明においては，引用発明１にはない優れた作用効果が得
られるなどと主張する。
しかし，上記のとおり，本件発明の「指定されたデータベース」には検
索用のデータベースとして顧客マスタＤＢを指定する場合も当然に含まれ
ると解されるところ，特許の技術的範囲の一部について公知文献に開示が
あれば特許の進歩性を否定しうることは前記のとおりであるから，原告の
主張はそもそもこの点において既に失当である。
ウ原告の主張(ｳ) に対し
原告は，引用発明１の「所望の数」は「所定の条件」に相当しないと主
張する。
しかし，本件発明における「所定の条件」については，当該文言はもと
より，明細書上にも何らかの限定的な意義を与えるような根拠となるべき
記載はなく，一定の件数を指定して発信対象データを抽出することも含ま
れるというべきであり，引用発明１において「所望の数」の顧客アカウン
ト情報を転送することも「所定の条件」に該当することは当然である。ま
，「」「」，た仮に所望の数が所定の条件の下位概念とはいえないとしても
原告もいうように「所望の数」の発信用データを抽出するに当たり，例，
えば何らかの顧客の属性に関する情報を条件とすることもコールセンタシ
ステムの当業者にとって自明のことである。
エ原告の主張(ｴ) に対し
原告は，引用発明１の「転送され」るは，本件発明の「作成」に該当し
ないと主張する。

，「」しかしコンピュータにおいてある機器から他の機器にデータが転送
されて他の機器の記憶装置に記録される場合，ＤＢの加工過程が介在する
か否かにかかわらず，他の機器の記憶装置に，それまで存在していなかっ
「」，，たデータが作成されることは明らかであるから引用発明１のように
ある機器に存在するデータ集合の中から他の機器に「転送」すべきデータ
集合を抽出することも転送データの「作成」に該当するといえる。また，
引用発明１においては，システム制御装置１１に転送されるデータが，メ
インフレーム１６に記憶されている顧客アカウント情報のうちの「所望の
数」のみである場合も当然に予定されており，上述のとおり「所望の数」
も「所定の条件」の１つであるうえ「所望の数」の転送に当たって，顧，
客の属性に関する情報を条件として，当該条件に基づいて顧客アカウント
情報を抽出しようとすることも，当業者には自明な選択肢であり，設計事
項にすぎない。
オ原告の主張(ｵ) に対し
原告は，引用発明１の「転送されたプレディクティブ発信を行う所望の
数の顧客のアカウント情報」は「データベース」ではないと主張する。
，「」，しかし引用発明１における所望の数の顧客のアカウント情報とは
「複数の顧客のアカウント情報」に関する情報であり，その内容も，少な
くとも「顧客名，顧客電話番号，アカウント番号，及び／又はあるタイプ
のメインフレームデータベース指標番号」を含むものであるから，まさし
「」。く原告自身が主張するデータベースの定義に該当することは疑いない
次に，原告は，引用発明１における一括転送の対象はせいぜい３ないし
５件の顧客データにすぎないなどと主張するが，そのようなことは引用発
，。明１の明細書には全く記載されておらず原告の主張は何らの根拠もない
この点に関し，原告は，引用例１の図４の記載を根拠に，引用発明１で
メインフレームコンピュータ１６からシステム制御装置１１に送信される

アカウント情報の件数は，本件明細書の段落【００２５】の「該ペーシン
グ制御部５６から要求があった発信データ群」の数（＝Ｎ）と同程度であ
るなどとして，引用発明１でメインフレームコンピュータ１６からシステ
ム制御装置１１に「一括送信」されるデータの件数が数件にすぎないなど
と主張するが，次のとおり，失当である。
すなわち，引用発明１においては，メインフレーム１６からシステム制
御装置１１に複数の顧客アカウント情報が転送（図４Ａのステップ２７）
された後，後記第４，２(2)アＱに記載されているように「‥‥判定２９，
は新しい呼出し（又は再呼出し）が必要かを調べる。‥‥もし必要であれ
ば，システム制御装置１１はステップ３０に進み，呼出す次のアカウント
の電話番号を抽出する」という処理がされる。このステップ３０におけ。
る「アカウント情報群から次のアカウントの電話番号を抽出する」処理こ
そが，本件発明における，プレディクティブ発信用データベース１２から
発信データ群（Ｎ）を抽出する処理に相当するのである。そして，引用例
１のＦＩＧ．４Ａに開示されているとおり，このステップ３０を経て電話
発信処理が終了した後も，ステップ２５において群処理が完了したか否か
の判断がされ，その結果が「Ｎｏ」であれば，メインフレームコンピュー
タ１６から新たにアカウント情報を得ることなく，再度ステップ２８以下
の処理を行うこととされているのである。
したがって，引用発明１においては，メインフレームコンピュータ１６
からアカウント情報群を１回取得するうちに，発信データ群Ｎの電話発信
処理を複数回行うことが予定されているのであるから，メインフレーム１
６からシステム制御装置１１に転送されるアカウント情報は，本件特許発
明でいう発信データ群Ｎよりも多いことは明らかである。
また，原告は，引用発明１が出願された１９８７年当時の主記憶容量が
極めて限られていたと主張するが，引用例１に「システム制御装置１１が

十分な記憶容量を有する場合は，システム制御装置１１は顧客アカウント
のファイル全体を保持し，この記録全体をオペレータ端末に送信してもよ
い」との記載（後記第４，２(2)アＰ）があるように，システム制御装置。
１１は相当程度の記憶容量を有することも想定されているのである。した
がって，３ないし５件程度の顧客アカウント情報しか保持できないなどと
いう原告の主張は，明細書の記載にもまた当業者の技術常識にも明らかに
反する。
さらにいうならば，引用例１の記載（後記第４，２(2) アＲ）も，シス
テム制御装置１１に一括転送される顧客アカウント情報の件数が相当程度
に上ることを予定した記載である。一括転送される顧客アカウント情報が
原告のいうように３ないし５件程度にとどまるのであれば，発信待ちの間
にシステム制御装置１１に記憶されたアカウント情報が「最新でなくなる
可能性」は非常に小さく，この点に配慮する必要はなくなるからである。
(6) 取消事由６に対し
ア原告の主張(ｱ) に対し
前述のとおり，引用発明１はプレディクティブ発信用ＤＢを排除するこ
とを特徴とするものでは全くなく，メインフレームコンピュータ１６から
システム制御装置１１へと複数の顧客アカウント情報が一括モード転送さ
れることにより，プレディクティブ発信用ＤＢが作成される一方，メイン
フレームコンピュータ１６の顧客アカウント情報に発信の可否を問い合わ
せるものであり，メインフレームコンピュータが引用発明２の「別のファ
イル」となりうることは明らかであるから，原告の主張はその前提におい
て誤っており，失当である。
イ原告の主張(ｲ)及び(ｳ) に対し
引用発明１はアウトバウンド業務で得られた発信不要データと，インバ
ウンド業務で得られた発信不要データのいずれをも発信回避に使用できる

のであるから，引用発明２のアウトバウンド業務で得られた発信不要デー
タを発信回避に用いる技術を引用発明１に適用することに困難はない。そ
して，その場合に，当業者が，アウトバウンド業務で得られた発信不要デ
ータによる発信回避のためにしか引用発明２の技術を適用せず，インバウ
ンド業務で得られた発信不要データには上記技術を適用しないなどという
ことはおよそ考えられないから，引用発明１に引用発明２の技術を組み合
わせることによって，本件発明の構成を得ることは当業者に容易である。
第４当裁判所の判断
１請求原因(1) （特許庁における手続の経緯，(2) （発明の内容，(3) （審））
決の内容）の各事実は，当事者間に争いがない。
２容易想到性の有無
審決は，本件発明は引用発明１及び２から容易に想到できるとし，一方，原
告はこれを争うので，以下検討する。
(1) 本件発明の意義
ア本件明細書（甲４）には，次の記載がある。
・発明の属する技術分野】本発明は，顧客の電話番号を自動的にダイヤ「【
ルして発信するプレディクティブ発信業務を行っているコールセンタシ
ステム，及び，プレディクティブダイヤラ装置に係り，特に，プレディ
クティブ発信業務を行っている途中で不要となったデータの発信を発信
直前に止めることが可能なコールセンタシステム，及び，そこで用いら
れるプレディクティブダイヤラ装置に関する（段落【０００１）。」】
・従来の技術】コールセンタシステムの利用者が，能動的に顧客と連絡「【
を取りたい場合に，予測発信機能を用いて，顧客の電話番号を自動的に
ダイヤルし，顧客と接続された呼のみをオペレータに接続することによ
って，オペレータの効率を向上させるプレディクティブ発信業務が行わ
れている（段落【０００２）。」】

・このようなプレディクティブ発信業務を行っている従来のコールセン「
タシステム，及び，そこで用いられるプレディクティブ発信装置で発信
データを作成する際には，図１に示す如く，ステップ１００で，全ての
顧客情報を管理しているマスタデータベース（ＤＢ）１０から，プレデ
ィクティブ発信を行うデータを所定の条件で抽出して，プレディクティ
ブ発信専用のデータベース（ＤＢ）１２を作成した後，ステップ１０２
で，プレディクティブ発信用データベース１２で選択された顧客の電話
番号を自動的にダイヤルして発信するプレディクティブ発信処理を行っ
ていた（段落【０００３）。」】
・図１】プレディクティブ発信における従来の発信中止処理を示す流れ【
図
・そのため，一旦プレディクティブ発信処理が開始されてしまうと，例「
えば顧客から着信する通話によるインバウンド業務，インターネット，
電子メール，又はその他の事務部門等における顧客からのコンタクト等
によりプレディクティブ発信を行わなくてもよい発信不要データがステ
ップ２００で発生した場合には，ステップ２０２で，マスタデータベー
ス１０に発信不要データが発生したという情報を記憶させて，マスタデ
ータベース１０を更新し，次いで，ステップ２０４で，バッチ処理又は
人が介在して，プレディクティブ発信用データベース１２から発信不要

データを削除したり，あるいは，発信停止フラグを立てる等の処理が行
われていた（段落【０００４）。」】
・発明が解決しようとする課題】しかしながら，このような方法では，「【
バッチ処理又は人が介在することにより，時間的なタイムラグが発生し
て，発信不要データが削除される前に，当該データのプレディクティブ
発信が行われてしまう場合があった。更に，昨今，コールセンタ，イン
ターネット，電子メール等といった顧客に対するコンタクトチャンネル
，，も多様化してきておりプレディクティブ発信業務を行っている途中で
発信が不要となったデータを削除することが，ますます困難になってき
ている（段落【０００５）。」】
・本発明は，前記従来の問題点を解決するべくなされたもので，発信不「
要データのプレディクティブ発信を発信直前に止めることを課題とす
る（段落【０００７）。」】
・本発明が採用されたコールセンタシステムの全体構成を図２に示す。「
このコールセンタシステムは，オペレータ毎に設けられた，複数（図で
は３台）の電話機２０，及び，オペレータを補助するクライアント装置
２２と，前記電話機２０を公衆電話回線網（ＰＳＴＮ）１４を介して顧
客の電話機１６に接続するための交換機（ＰＢＸ＝ Private Branch
eXchange）３０と，インターネット接続用のウェブ（Ｗｅｂ）サーバ装
置３２と，電子メールを受信するためのメールサーバ装置３４と，全て
の顧客情報を管理しているマスタデータベース（ＤＢ）１０を管理して
いるマスタＤＢ管理装置３６と，例えば事務部門に設けられた顧客情報
処理部門３８と，前記クライアント装置２２，ＰＢＸ３０，ウェブサー
バ装置３２，メールサーバ装置３４，マスタＤＢ管理装置３６及び顧客
情報処理部門３８とローカルエリアネットワーク（ＬＡＮ）４０を介し
て接続された，プレディクティブ発信業務を行うと共に，プレディクテ

ィブ発信が不要となった発信不要データの発信を発信直前に止めるリア
ルタイムコール止め機能を有するＣＴＩ（Computer Telephony
Integration）サーバ装置５０とを含んで構成されている（段落【０。」
０２４）】
・図２】本発明が採用されたコールセンタシステムの実施形態の全体構【
成を示すブロック図
・前記ＣＴＩサーバ装置５０は，図３に詳細に示す如く，例えばパソコ「
ンで構成されるクライアント装置２２に内蔵されたクライアントプログ
ラム２４からＬＡＮ４０経由でＣＴＩ命令を受信し，又，各種着信信号
を，後出ＣＴＩ制御部５４及びデータベース（ＤＢ）制御部５８から受
信してクライアントプログラム２４に送信するクライアント制御部５２
と，該クライアント制御部５２から送信されたＣＴＩ命令及びＤＢ制御
部５８から送信された発信可能データをＰＢＸ３０に送信して，発信処
理を行うと共に，ＰＢＸ３０から送られてくる着信，応答，切断等の情

報を管理し，プレディクティブ発信した結果，着信した情報はＤＢ制御
部５８へ送信し，それ以外の着信情報はクライアント制御部５２へ送信
するＣＴＩ制御部５４と，予測発信を行うためのプレディクティブ発信
のデータ数（呼数）ＮをＤＢ制御部５８へ通知するペーシング制御部５
６と，該ペーシング制御部５６から要求があった発信データ群をプレデ
ィクティブ発信用ＤＢ１２から抽出すると共に，抽出したデータをマス
タＤＢ１０と比較して，マスタＤＢ１０に存在する発信不要データをチ
ェックし，発信可能なデータをＣＴＩ制御部５４へ送信する一方，発信
不要なデータは発信不要データベース（ＤＢ）６０に格納するデータベ
ース（ＤＢ）制御部５８とを備えている（段落【００２５）。」】
・図３】前記実施形態のＣＴＩサーバ装置及びその周辺を示すブロック【
図
・
以下図４を参照して本実施形態の処理手順を説明する段落０「，，。」（【
０２６）】
・図４】前記実施形態におけるリアルタイムコール止め発信処理の全般【

を示す流れ図
・まずステップ３００で，キャンペーン（業務）単位毎に設定された，「
。，図５に示すような条件設定テーブルを読み込む本実施形態においては
電話番号Ｔ又は，顧客識別情報の一つであるコールＩＤＣを，データ
を読み込むためのキーとすることができる（段落【００２７）。」】
・次いでステップ３０２で，上位プログラムが終了したか否かを判定す「
る。判定結果が否である場合には，本処理を終了し，判定結果が正であ
る場合には，ステップ３０４に進み，ペーシング制御部５６から発信デ
ータ数Ｎを取得する（段落【００２８）。」】
・次いでステップ３０６に進み，本発明に係るリアルタイムコール止め「
／発信処理を行う（段落【００２９）。」】
・このリアルタイムコール止め／発信処理は，具体的には，図６に示す「
如く行われる。即ち，まずステップ４００で，前記プレディクティブ発

信用ＤＢ１２から発信データを抽出する。次いでステップ４０２で，マ
スタＤＢ１０を検索し，ステップ４０４で，発信不要データではないと
判定された時にはステップ４０６に進み発信処理を行う段落０，，。」（【
０３０）】
・一方，ステップ４０４で発信不要データであると判定された時には，「
ステップ４０８に進み，発信せずに発信不要ＤＢ６０に登録する（段。」
落【００３１）】
・ステップ４０６又は４０８終了後，図４のステップ３０８に戻り，発「
信数がＮとなるまで，ステップ３０６のリアルタイムコール止め／発信
処理を繰り返す（段落【００３２）。」】
・前記実施形態においては，発信不要データを専用の発信不要ＤＢ６０「
に登録していたが，マスタＤＢ１０に登録したり，あるいは，マスタＤ
Ｂ１０のフラグ等に反映することも可能である。キーの種類も，電話番
号やコールＩＤに限定されず，他の顧客識別情報を用いることができ
る（段落【００３５）。」】
イ上記記載によると，本件発明は，従来，プレディクティブ発信を行わな
，，くてもよい発信不要データが発生した場合バッチ処理又は人が介在して
プレディクティブ発信用データベース１２から発信不要データを削除した
り，あるいは，発信停止フラグを立てる等の処理が行われていたところ，
そのような従来技術においてはバッチ処理や人の介在によるタイムラグが
発生して本来プレディクティブ発信が不要なデータについてのプレディク
ティブ発信が行われてしまうという問題点があったとの点を解決すべく，
「顧客情報を管理しているデータベースからプレディクティブ発信を行う
データを所定の条件で抽出して，プレディクティブ発信用のデータベース
を作成した後」に生ずる，マスタデータベースの更新に伴って生ずるプレ
ディクティブ発信用データベースへの更新の伝播のタイムラグという課題

を「リアルタイムコール止め」という解決手段によって解決しようとする
ものであることが認められる。
(2) 引用発明の意義
ア引用例１（甲１）には，以下の記載がある（なお，以下の記載はすべて
甲１の２記載の和訳により，末尾のかっこ内に原文〔甲１〕の摘示箇所を
示す。。）
Ａ「メインフレームコンピュータ（１６）は，顧客又は潜在的顧客のア
カウント情報，例えば顧客名，顧客電話番号，顧客アカウントコード，
顧客注文状態等を保持し顧客アカウント情報群をシステム制御装置１，（
１にデータ制御装置１５を介して送信するシステム制御装置１）（）。（
１）は幹線インタフェース部（１０ａ ?１０ｄ）に顧客の電話番号をダ
イヤルし，発信の状態を監視するよう命令する（フロントページ左欄。」
２７行?右欄５行）
「，，，Ｂ多くのビジネス特に多数の顧客アカウントを有するビジネスは
定期的に顧客に電話でコンタクトして，更新されたアカウント情報を得
，，，たり顧客に期限経過勘定を督促したり滞納勘定について集金したり
又は他の業務を行う。また，幾つかのビジネスは，以前に郵送したカタ
ログ又は広告に応答して電話で行うセールス，或いは顧客に電話をする
直接勧誘によるセールスに主に又はだけに基づいている（１欄１２? 。」
２０行）
Ｃ「このようなビジネスにおいて，顧客アカウント情報は通常，メイン
フレームコンピュータに記憶され，顧客アカウント情報のコピーがディ
スク又はテープ等の記憶媒体に記憶される。次に，このコピーは，オペ
レータ（顧客アカウント，セールス，又はサービス担当者）がアクセス
するための別のコンピュータに設置される（１欄２０?２６行）。」
Ｄ「従って，オペレータの時間をより有効に使用できるように，オペレ

ータの介入なしに自動的に番号をダイヤルし，呼出しに応答があった場
合だけオペレータを接続し，メインフレームにある顧客アカウント記録
を表示する方法及び装置が必要とされている（１欄３８?４４行）。」
Ｅ「通常，処理されたビジネス用の顧客アカウント情報は，以前に作ら
れたコピーに入力されるか又は別のファイルに保持される従って 1 ，。，
日の業務，又はビジネスセッションの終了時に，該コピーの変更は，メ
インフレームシステム内の顧客アカウント情報に取り込まれ，統合され
なければならない（１欄６３?６８行）。」
Ｆ「このため，メインフレーム又はシステム制御装置から顧客アカウン
ト情報の最新のコピーを得て，顧客アカウントへの変更を含む最新ファ
イルに更新するのに貴重なオペレータ時間がまた浪費される（２欄１。」
０?１４行）
Ｇ「従って，オペレータがメインフレームファイルと変更ファイルの違
いを探す必要なく最新の顧客アカウント情報に直ちにアクセスできるよ
うに，メインフレーム内の顧客アカウント情報をオンライン又はリアル
タイムに更新し，また問題発生時，呼出し結果及び任意の変更を見つけ
るか又はコピーできるように，顧客アカウント情報になされた変更のコ
ピーと各呼び出しの状態情報を維持するための方法及び装置が必要とさ
れている（２欄１５?２４行）。」
Ｈ「本発明は，電話番号をダイヤルさせ，応答を待つ作業からオペレー
タを解放するための方法及び装置を提供し，予備的な顧客アカウント情
報を得る作業からオペレータを解放し，メインフレーム内の顧客アカウ
ント情報のオンライン直接更新を可能にすることで，顧客アカウントフ
ァイルに変更を統合する必要をなくし，かつ，オペレータに顧客アカウ
ントの最新情報を提供する（２欄２８?３７行）。」
Ｉ「また，本発明は，顧客アカウントの全ての変更の記録と，各発信と

各着信の状態の記録とを別に維持しながら，メインフレームファイル内
の顧客アカウント情報をオンライン更新するための装置を提供する」。
（３欄１?６行）
Ｊ「従って，本発明の目的は，顧客アカウントの全ての変更の記録と，
必要に応じて，各発信と各着信の状態とを別に維持しながら，メインフ
レームファイル内の顧客アカウント情報を直ちにオンライン更新するた
めの方法及び装置を提供することである（３欄７?１２行）。」
「，Ｋこの好適な実施形態は４つの幹線インタフェース部１０ａ?１０ｄ
システム制御装置１１，１６幹線×１０線・クロス点スイッチ１３，デ
ータ制御装置１５，メインフレームコンピュータ１６，及び１０個のオ
ペレータ端末１２ａ?１２ｊを備える。１６本の幹線Ｔ１?Ｔ１６は集
成幹線インタフェース部１０とクロス点スイッチ１３に接続される。各
幹線インタフェース部１０ａ?１０ｄは４つの幹線を収容し，幹線イン
タフェース部１０ａは幹線Ｔ１?Ｔ４にサービスを提供し，幹線インタ
フェース部１０ｂは幹線Ｔ５?Ｔ８にサービスを提供する（他同様。）
各幹線インタフェース部１０ａ?１０ｄは次の機能：幹線占有，ダイヤ
リング，呼出し進行監視，メッセージ再生，及びメッセージ記録を実行
する。下記に幹線インタフェース部１０ａ?１０ｄについてより詳細に
説明する。スイッチ１３はクロス点スイッチである必要はなく，別の同
。，，（）様な装置であってもよい例えばスイッチ１３は構内交換ＰＢＸ
スイッチ等の電話システム又はその一部であってもよい（３欄４８? 。」
６５行）
Ｌ「ここで本実施形態の動作を考える。メインフレームコンピュータ１
６は，所望の数のアカウントの顧客アカウント情報をデータ制御装置１
５に一括転送又はオンライン転送により提供する。次にデータ制御装置
１５はこの情報をポートＨＰＳ１を介してシステム制御装置１１に提供

する。或いは，システム制御装置１１はこの情報を直接メインフレーム
１６とそのディスクドライブシステムから得てもよい。次にシステム制
御装置１１はアカウント毎に顧客名，顧客電話番号，アカウント番号，
及び／又はあるタイプのメインフレームデータベース指標番号を抽出す
。，，る幹線Ｔ１が使用可能であると仮定するとシステム制御装置１１は
幹線インタフェース部１０ａに幹線Ｔ１を占有するよう命令し，顧客電
話番号を幹線インタフェース部１０ａに提供し，幹線インタフェース部
１０ａにこの顧客電話番号をダイヤルするよう命令する。幹線インタフ
ェース部１０ａは顧客電話番号をダイヤルし，この呼出しの状態を求め
て幹線Ｔ１を監視する（５欄１３?３１行）。」
Ｍ「幹線Ｔ１を介して被呼者が応答した時，空いたオペレータが居ない
。，と仮定する幹線インタフェース部１０ａはメッセージ再生機を起動し
システム制御装置１１に被呼者が応答したことを通知する。空いたオペ
レータが居ないことを確認後，システム制御装置１１は幹線インタフェ
ース部１０ａが被呼者へ予め記録された所望のメッセージの再生を続け
ることを許可する。システム制御装置１１が空いたオペレータが居ると
判断すると，システム制御装置１１はクロス点スイッチ１３に，利用可
能なオペレータ端末１２を幹線Ｔ１に接続させ，幹線インタフェース部
１０ａに幹線Ｔ１を解放し，メッセージを停止し，次のメッセージに進
み，短縮された顧客アカウント情報を該利用可能なオペレータ端末１２
に送信するよう命令する（６欄２３?３７行）。」
Ｎ「キーボード１２ａ６を介してオペレータが行った全ての入力は，端
末１２ａ４によってシステム制御装置１１に送信され，オンラインモー
ドにおいてデータ制御装置１５に送信される。本実施形態では，システ
ム制御装置１１は入力の数とタイプ，接続時間等に関する統計を維持す
る。データ制御装置１５は高速直列ポートＨＳＰ１２を介して変更をメ

インフレーム１６に送信し，メインフレーム１６は主データベース内の
当該顧客アカウント情報を更新する。従って，メインフレーム１６に記
憶されオペレータに提供される顧客アカウント情報は最新の情報であ
る（７欄５?１６行）。」
Ｏ「また，メインフレーム１６の主データベース内の当該顧客アカウン
ト情報を直ちに更新するので，オペレータが行った顧客アカウント情報
への変更を各業務日の終りに統合する必要がないこと，及び一日の任意
の時点で顧客が電話をかけてくる，又は顧客を呼出した時，オペレータ
に提供される顧客アカウント情報は最新の更新された顧客アカウント情
報であるという利点があることが理解されるであろう（７欄２１?３。」
０行）
Ｐ「従って，オペレータによる顧客アカウント情報へのいかなる変更も
直ちにメインフレーム１６に提供され，メインフレーム１６は自動的か
。，，つ直ちに該顧客アカウント情報を更新するまた自動更新であるので
オペレータに提供されるいかなる情報も最新の情報である。従って，
オペレータはメインフレーム１６に直接接続されているように見える。
本実施形態では，システム制御装置１１は短縮された顧客アカウント
情報だけをオペレータ端末１２に送信するが，もしシステム制御装置１
１が十分な記憶容量を有する場合は，システム制御装置１１は顧客アカ
ウントのファイル全体を保持し，この記録全体をオペレータ端末に送信
してもよい（７欄３６?５０行）。」（
Ｑ「システム制御装置１１により使用されるロジックのフローチャート
である図４Ａ及び図４Ｂを参照する。２６からスタート後，第１ステッ
プ２７ではメインフレーム１６から一括モード転送により複数の顧客の
アカウント情報を得る。このアカウント情報はメインフレームデータベ
ース指標番号又はキーを含んでもよい。或いは，システム制御装置１１

は複数のアカウントの短縮されたアカウント情報，例えば名前，電話番
号，アカウント番号，及び／又は指標番号を得てもよい。一括モード転
送が好ましいが，もし望むなら，システム制御装置１１はメインフレー
ム１６から１つの顧客アカウントに関する情報を得てもよい。次のステ
ップ２８では，オペレータの予想される空き状況に基づいて新しい呼出
（）。，し又は再呼出しの必要性を計算する空いたオペレータが居る場合
新しい呼出し（又は再呼出し）が必要となる。しかし，全てのオペレー
タが話中である場合，所定の時間内にオペレータが空く統計的確率に基
づいて新しい呼出しが必要である場合とない場合がある。判定２９は新
しい呼出し（又は再呼出し）が必要かを調べる。もし否であれば，シス
テム制御装置１１はステップ２８に戻る。もし必要であれば，システム
制御装置１１はステップ３０に進み，呼出す次のアカウントの電話番号
を抽出する。判定３１は幾つかの要因に基づいて抽出した電話番号をダ
イヤルすることが許されるかを検査する。これらの要因は，通常相手が
位置するタイムゾーン，該電話番号に以前電話をかけたか，以前かけた
該電話番号は話中であった／応答がなかった／使われていなかったか，
該電話番号に最後にかけてからの経過時間，該アカウントは昼間／夜間
／ある時間帯に呼出すべきかに関する情報，及び所望の優先度（より大
きな勘定が優先）を含む。これらの要因に基づいてこの電話番号をダイ
ヤルすることが許されない場合，システム制御装置１１はステップ２８
に戻る。この電話番号をダイヤルすることが許される場合，システム制
御装置１１はステップ３２に進む（９欄４２行?１０欄１２行）。」
Ｒ「ステップ２７でシステム制御装置１１は一群の顧客アカウントのア
カウント情報を得るので，その後の着信及び／又は請求に対する支払い
及びクレジットにより，システム制御装置１１に記憶されたアカウント
情報は，発信待ちの列において特定の顧客アカウントの順番が来る時ま

でに最新ではなくなる可能性がある。この問題を扱う幾つかの方法が存
在する。１つの方法は，システム制御装置１１はステップ２７で一度に
。，１つのアカウントだけのアカウント情報を得ることである別の方法は
メインフレーム１６に情報が入力されるたびに，メインフレーム１６が
当該アカウントに関する更新された情報をシステム制御装置１１に送信
することである。本実施形態で使用する方法は，アカウントに電話をか
ける前に，システム制御装置１１がメインフレーム１６に該アカウント
の状態を問合せることである。これに応答して，メインフレーム１６は
該アカウントの状態に変化があったか否かと，変化があった場合，どん
な状態変化が発生したかをシステム制御装置１１に通知する。状態に変
化がなかった場合，又は変化が該特定のアカウントに電話をかける必要
性に影響しない場合，システム制御装置１１はステップ３２に進む。該
アカウントに電話をかけることがもはや適当でない場合，システム制御
装置１１はステップ２８に戻る（１０欄１３?３７行）。」
・

・
イ上記記載によれば，引用例１は，顧客のアカウント情報を管理している
メインフレームコンピュータ（１６）内からプレディクティブ発信を行う
所望の数の顧客アカウント情報がデータ制御装置１５を介して，システム
制御装置１１に転送され，所望の数の顧客アカウント情報から選択された
顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業
務を行っている顧客オンラインサービスシステムにおいて「システム制，
御装置１１は一群の顧客アカウントのアカウント情報を得るので，その後
の着信及び／又は請求に対する支払い及びクレジットにより，システム制
御装置１１に記憶されたアカウント情報は，発信待ちの列において特定の

顧客アカウントの順番が来る時までに最新ではなくなる可能性がある上」（
記アＲ参照）という課題を解決するため，アカウントに電話をかける前に
システム制御装置１１がメインフレーム１６に該アカウントの状態を問合
せて発信不要データであると判定された場合は新しい発信の必要性を計算
するという解決手段を採用したという技術であることが認められる。
(3) 原告主張の取消事由に対する判断
ア取消事由１（本件発明の要旨認定の誤り）について
(ｱ) 原告は，本件発明の要旨認定には誤りがあると主張するが，そもそも
審決は，本件発明について，特許請求の範囲請求項１の記載のとおりに
要旨を認定しているにすぎず，その記載自体については原告も認めると
認否しているのであるから，審決の要旨認定に誤りがあるということは
できない。
(ｲ) また，原告は，前記第３，１(4) アのとおり，本件発明は，バッチ処
理構成を基本にしつつ，コール止めのリアルタイム処理に必要な構成を
採用したという，いわば「バッチ処理とリアルタイム処理のハイブリッ
ド構成」を採用した点に特徴があり，本件発明の「プレディクティブ発
信用データベース」が「バッチ処理」により作成されたものであること
を前提とした主張を展開している。
しかし「プレディクティブ発信用データベース」が「バッチ処理」，
により作成されるものである点については，本件特許の特許請求の範囲
には何ら記載はなく，本件明細書及び図面にも何ら開示されていない。
また，本件発明の意義は前記(1) イのとおりであり，本件発明は，プ
レディクティブ発信用データベースが作成された後の，発信不要データ
の発生から発信までのタイムラグを問題とし，この問題の解決を課題と
したものであって，プレディクティブ発信用データベースを「バッチ処
理」で行うことを前提としたものではなく，プレディクティブ発信用デ

ータベースを「バッチ処理」で行う場合に生じる問題の解決を課題とし
たものでもない。したがって，原告の主張する本件発明の課題認識は，
本件明細書に開示された本件発明の課題とは異なるものであって，本件
発明の技術内容を正解しないものである。
(ｳ) この点につき，原告は，クレームの「おいて」書きの部分の「プレデ
ィクティブ発信用ＤＢを作成した後」という文言は，これがバッチ処理
であることを明確に示すものであると主張する。
しかし，本件明細書の記載を全体として見た場合「作成」の文言に，
よって作成の方法が何ら特定されていないことは後述するとおりであ
り「作成」の文言からバッチ処理といった意味を読み取ることはでき，
ないというべきであるから，この点に関する原告の主張は採用すること
ができない。
イ取消事由２（引用発明１認定の誤り）について
(ｱ) 前記(2) アの記載によれば，引用例１には，前記(2) イに記載された
技術事項が記載されていると認められるから，引用発明１の内容につき
前記第３，１(3) イのとおりとした審決の認定に誤りはない。
(ｲ) この点につき，原告は，前記(2 ) アＣ，Ｅ，Ｆ，Ｇ，Ｎ，Ｏ，Ｐ等の
記載を根拠として，引用発明１は，プレディクティブ発信用ＤＢをバッ
チ処理により作成するという過程を強いて取り去り，顧客マスタＤＢだ
けですべての顧客情報をオンライン処理（リアルタイム処理）で管理す
る方法を採用しているのであって，プレディクティブ発信用ＤＢを排除
することが最大の特徴である旨主張する。
しかし，被告主張のとおり，原告が指摘する明細書の記載は，いずれ
も顧客情報の修正処理に関するものであって，発信処理に係る記載では
ないから，そもそも原告の主張は失当である。
仮にそうでないとしても，原告の主張ａにおいて「オペレータがア，

クセスするための別のコンピュータに設置されるコピー」が「プレディ
クティブ発信用ＤＢ」に該当するとの原告の主張は，引用例１の記載に
基づくものとはいえない。引用例１において「オペレータの時間をよ，
り有効に使用できるように，オペレータの介入なしに自動的に番号をダ
イヤルし，呼出しに応答があった場合だけオペレータを接続（Ｄ）す」
るプレディクティブ発信における顧客へのダイヤルを行うに当たって，
そのダイヤルによる呼出しに対する応答後に初めて割り当てられて接続
されるオペレータ端末上の情報をダイヤル時つまり呼出に対する応答前
に参照することはあり得ず，引用例１のオペレータ端末に設置されたコ
ピーは，プレディクティブ発信のための顧客へのダイヤルを行うに当た
って決して参照され得ないものであるからである。
そして，前記(2) アＬの記載によれば，本件発明の「プレディクティ
ブ発信用のデータベース」に対応させるべき引用例１記載の構成は，上
記Ｃにある「オペレータがアクセスするための別のコンピュータに設置
される顧客アカウントのコピー」ではなく，むしろ，上記Ｌにある「所
望の数のアカウントの顧客アカウント情報」である。
したがって，引用例１のオペレータ端末に設置されたコピーが本件発
明のプレディクティブ発信用ＤＢに該当するものである旨の主張は，引
用例１の記載内容と両立しないものである。
また，原告の主張ｂ，ｃ，ｄ，ｅについては，上記原告の主張ａが正
しいことを前提としているところ，上記のとおり，この主張は引用例１
の記載に基づかないものであるから，この主張は，誤った前提に基づく
主張である。すなわち，原告が引用発明１において作成処理が取り除か
れたものであると主張しているものは，上記Ｃに記載された「オペレー
タ（顧客アカウント，セールス，又はサービス担当者）がアクセスする
ための別のコンピュータに設置されるコピー」であるところ，これは前

述したとおり，本件発明におけるプレディクティブ発信用のデータベー
スに相当する構成ではなく，これを排除するかどうかは本件発明と無関
係である。そして，本件発明におけるプレディクティブ発信用のデータ
ベースに相当する引用発明１の構成である上記Ｌにある「所望の数のア
カウントの顧客アカウント情報」は，引用発明１において排除されてい
ない。そうすると，引用発明１が本件発明のプレディクティブ発信用の
データベースに相当する構成を排除したものであるとの主張は，引用例
１の記載に基づくものではなく，失当である。
ウ取消事由３（一致点認定の誤り）について
(ｱ) 原告の主張(ｱ) について
原告は，本件発明の「プレディクティブ発信用のデータベース」と引
用発明１の「所望の数のアカウント情報」とを「データの集合」といっ
た抽象化された概念のレベルで同一視することは不可能でありかつ誤り
であると主張する。
しかし「プレディクティブ発信用のデータベース」は，顧客の電話，
番号を自動的にダイヤルして発信するに当たって顧客情報を管理してい
るデータベースから抽出して作成されるものであってその文言上デ，，「
ータベース」であり，かつ，プレディクティブ発信に用いられるもので
あることが特定されているとはいえるものの，本願明細書の発明の詳細
，「」な説明の記載を精査してもプレディクティブ発信用のデータベース
の文言の技術的意義をさらに特定する記載は見当たらない。
，，，（。そこでその一般的意義を検討するにまず広辞苑第６版甲１８
２００８年株式会社岩波書店）によれば「データベース」とは「系，，
統的に整理・管理された情報の集まり」を意味すると認められ，それ。
以上の限定はないから「プレディクティブ発信用のデータベース」に，
おいても，系統的に整理・管理された情報の集まりであって，プレディ

クティブ発信時に順次データを参照できればよく，それ以上の管理情報
や管理システムの存在を前提とするものではないと認められる。
一方，引用発明１の文言の技術的意義についてみると，後記オ(ｵ) で
認定するとおり，引用例１における「所望の数の」あるいは「複数の」
という文言は「少数の」あるいは「３ないし５の」の意味を含むもの，
というよりは，むしろ，処理を遅滞なく行える程度であるとともに発信
待ちの間にデータが古くなる程度にまとまった相当の量であるという意
味を含んでおり，また，この「所望の数の顧客アカウント情報」からア
カウントの電話番号が抽出されてダイヤルされるのであって，そのため
に必要な整理・管理がなされているものである。そうすると「所望の，
数の顧客アカウント情報」は，プレディクティブ発信に用いることがで
きるように系統的に整理・管理された，ある程度まとまった量の情報の
集まりであると認められる。
また，本件発明における「プレディクティブ発信用のデータベース」
がバッチ処理により作成されたものであるか否かは本件発明と無関係の
事項であることは，前記ア認定のとおりである。
以上によれば，引用発明１の「所望の数のアカウント情報」と本件発
明の「プレディクティブ発信用のデータベース」とは「プレディクテ，
ィブ発信を行う発信データの集合」である点では共通しているというこ
とができるから，この点を一致点として認定した審決に誤りはない。
(ｲ) 原告の主張(ｲ) について
原告は，引用発明１の「最新ではなくなる可能性がある「顧客アカ」
ウント情報」の中に「インターネット「電子メール」による顧客から」
のコンタクトから得られる情報が含まれるとする審決の認定は誤りであ
ると主張する。
しかし，本件発明において，顧客からのコンタクトは「顧客から着，

信する通話によるインバウンド業務，インターネット，電子メール，又
はその他の事務部門における該顧客からのコンタクトと記載され顧」，「
客から着信する通話によるインバウンド業務「インターネット「電」，」，
子メール「その他の事務部門における該顧客からのコンタクト」は，」，
「又は」で接続された択一事項であるから，引用発明１においてこれら
のいずれか１つによる顧客からのコンタクトがあれば一致点となるとこ
ろ，審決においては，引用発明が「顧客から着信する通話によるインバ
ウンド業務」と「その他の事務部門における該顧客からのコンタクト」
による顧客からのコンタクトがあることを認定しており，本件発明と少
なくとも２つの点で一致しているから，審決の認定に誤りはない。
(ｳ) 原告の主張(ｳ) について
原告は，本件発明の「指定されたデータベース」には「顧客マスタＤ
Ｂ」以外のＤＢも含んでいることを理由として「引用発明１の『メイ，
ンフレームコンピュータ１６に該アカウントの状態を問い合わせる』こ
とと本件発明の『プレディクティブ発信用のデータベースから抽出され
た発信データを『電話番号又は他の顧客識別情報をキーとして指定さ，』
れたデータベースを指定された条件で検索すること』とは『プレディ，
クティブ発信用のデータの集合から抽出された発信データを指定された
データベースに照会すること』で共通する」とする審決の認定は誤りで
あると主張する。
しかし，本件発明における，検索される「指定されたデータベース」
の技術的意義については，特許請求の範囲の文言上何らの限定がなされ
ていないばかりか，本件明細書の発明の詳細な説明をみると，この「指
定されたデータベース」の唯一の実施例として「マスターＤＢ１０」を
検索する例が記載されているところ，このマスターＤＢ１０は，本件発
明の「顧客を管理しているデータベース」に対応する構成であるから，

少なくとも「指定されたデータベース」は「顧客を管理しているデータ
ベース」を含むものである。
，，「」一方引用発明１は本件発明の顧客を管理しているデータベース
に対応する「メインフレームコンピュータ１６」内にある「顧客を管，
理しているデータベース」を検索するものである。
そうすると，引用発明１の「メインフレームコンピュータ１６」内に
ある「顧客を管理しているデータベース」は，本件発明における，検索
される「指定されたデータベース」に相当する構成でもあるから，この
旨を説示した審決に誤りはない。
エ取消事由４（引用発明２認定の誤り）について
(ｱ) 引用発明２は，相違点２の判断において参照された公知技術であると
ころ，引用例２（甲２）には，以下の記載がある。
・図１８に示す形態での２つのコールセンターで，コールセンター１「
からコールセンター２に顧客の不在情報が通知される例を用いる。コ
ールセンター１におけるコールリスト１（２１１（１）は，図１９）
で示される内容であるとする。この場合，コールセンター１では，以
下の手順で電話をかける（段落【０１３３）。」】
・図１８】２つのコールセンター・システムの連携及び各コールセン【
ター・システムのホストコンピュータの内部構成の一例を示す図

・１９図】コールセンター１でのコールリストの一例を示す図【
・顧客選択部２１２（１）は，コールリスト１の最初の顧客Ａ氏の電「
話番号を取り出し，Ａ氏に電話をかける。Ａ氏とは電話が繋がり，テ
レマーケティングが行われたとする。なお，この時点ではＡ氏に関す
る不在等の情報はないものとする（段落【０１３４）。」】
・次に，顧客選択部２１２（１）は，コールリスト１の次の顧客Ｂ氏「
の電話番号を取り出し，Ｂ氏に電話をかける。ここで，Ｂ氏は不在で
あったとする。この場合，不在か否かは，実際にＢ氏の電話番号に電
話をかけ，一定時間内に応答があるか否かでＢ氏の不在を判断するの
で，Ｂ氏に電話をかけてからＢ氏の不在を確認するまでの時間は無駄
な時間となる（段落【０１３５）。」】
・Ｂ氏の不在を確認すると，顧客情報通知部２１５（１）は，Ｂ氏が「
不在である旨の情報をコールセンター２に通知する。その際，送られ
るデータの例を図２０に示す。この場合は，Ｂ氏が不在である情報，
Ｂ氏の不在を発見した時刻Ｂ氏の電話番号が送られる段落０，。」（【
１３６）】
・図２０】コールセンター１からコールセンター２に送られる不在者【
情報の一例を示す図

・コールセンター２の顧客情報受信部２１６（２）は，図２０に示さ「
れたデータを受け取る。なお，Ｂ氏が不在であることおよびこれを検
出した時刻等の情報は，自身の顧客情報受信部２１６（１）に格納す
るか，あるいはコールリスト１中にフィールドを設けて記録してお
く（段落【０１３７）。」】
・次に，同時にテレマーケティング業務を行っているコールセンター「
２での手順を以下に述べる。コールセンター２におけるコールリスト
２（２１１（２）は，図２１で示される内容であるとする（段落）。」
【０１３８）】
・図２１】コールセンター１からコールセンター２に送られる不在者【
情報の一例を示す図
・顧客選択部２１７（２）は，コールリスト２の最初の顧客Ｘ氏の電「
話番号を取り出し，Ｘ氏を発呼する候補とする。この際，顧客情報受
信部２１６（２）を参照し，Ｘ氏の不在情報が届いていないかチェッ
クする。なお，自身で検出したある顧客の不在等の情報をコールリス
ト中に記録しておく場合，コールリスト２中のＸ氏の不在情報の欄も
チェックする（段落【０１３９）。」】
・この場合は，Ｘ氏の不在情報は届いていないので，Ｘ氏に電話をか「
，，。けＸ氏とは電話がつながりテレマーケティングが行われたとする
次に，顧客選択部２１７（２）は，コールリスト２の次の顧客Ｂ氏の
。，（），電話番号を取り出すそして顧客情報受信部２１６２を参照し

。」（【】）Ｂ氏の不在情報を届いていないかチェックする段落０１４０
・ここでは，図２０に示されたＢ氏の不在情報が届けられていたとす「
る。顧客選択部２１７（２）は，現在の時刻とＢ氏の不在情報の時刻
とを比較し，Ｂ氏の不在が発見された時刻から一定の時間が経過して
いない場合は，Ｂ氏は不在である確率が大きいと判断し，Ｂ氏への電
話は後に回し，コールリスト２の次の顧客であるＹ氏の電話番号を取
り出す（段落【０１４１）。」】
「，，・このことにより不在である確率の大きいＢ氏に電話をかけてから
一定時間内に応答がないことを確認し，Ｂ氏の不在を確認するまでの
無駄な時間を省くことができる（段落【０１４２）。」】
(ｲ) 上記記載によれば，引用例２に記載された発呼制御方法は，プレディ
クティブ発信をしようとする顧客情報について現に発信すべきか否かを
照会するに当たり，顧客の電話番号を取り出し，顧客情報受信部２１６
（２）を参照することによって，発信する必要のないデータ（発信不要
データ）を電話番号で検索するものであることが認められる。
そうすると，顧客情報受信部２１６（２）の有する顧客情報を「発信
不要データベース」と称することに何ら問題はないから，審決が，引用
発明２を「発信データを発信不要データベースに照会して発信不要デー
タであると判定するにあたり，電話番号をキーとして，発信不要データ
ベースを指定された条件で検索する，プレディクティブ発信制御方法」
と認定した点に誤りはない。
(ｳ) 原告は，審決の引用発明２に関する認定のうち「顧客情報受信部２，
１６(2) が有する顧客情報は，全体として”発信不要データベース”と
いうことができる」との記載部分の発信不要の「顧客情報受信部２１６
(2) が有する顧客情報」は，本件発明における「顧客から着信する通話
によるインバウンド業務，インターネット，電子メール，又はその他の

事務部門等における顧客からのコンタクト等」のような他のシステム系
統から得られた情報を含んでいないなどと主張するが，本件では，本件
発明と引用発明１との相違点２の判断に当たって，発信データを指定さ
れたデータベースに「照会」することにより発信不要データであると判
定する具体的態様がメインフレームコンピュータに該特定の顧客のアカ
ウントの状態を問い合わせるものである引用発明１に，本件発明のよう
に電話番号又は他の顧客識別情報をキーとして指定されたデータベース
を指定された条件で検索するものとするような公知技術を組み合わせる
必要があるところ，審決は，引用例２の具体的な記載に基づいて，発信
データを指定されたデータベースに照会するに当たって電話番号又は他
の顧客情報をキーとして指定された条件で検索することが公知技術であ
ると認定しているものであるから，引用例２には，発信しないデータを
電話番号で検索する点が開示されていれば十分なのであって，引用例２
の発信しないデータがどのように生成されたものであるかは問題でない
というべきである。したがって，この点に関する原告の主張は採用する
ことができない。
オ取消事由５（相違点１認定判断の誤り）について
(ｱ) 引用発明１における「プレディクティブ発信を行う「顧客アカウン」
ト情報」とは，プレディクティブ発信に用いることができるように系統
，「」的に整理・管理された情報の集まりであり引用発明１における転送
は，プレディクティブ発信において用いられる情報の集まりである「所
望の数の顧客アカウント情報」を生成する処理である。また「顧客ア，
カウント情報」は「所望の数」のものであるから，所望の数に達したか
否かを条件として抽出されたものである。
他方，本件発明は，プレディクティブ発信に用いることができるよう
に系統的に整理・管理された情報の集まりを「プレディクティブ発信用

のデータベース」と表現し，何らかの条件，方法によってこの情報の集
まりを生成することを「所定の条件で抽出」して「作成」すると表現，
しているものである。
そうすると，引用発明１のプレディクティブ発信に用いることができ
るように系統的に整理・管理された情報の集まりである「所望の数の顧
客アカウント情報」を「プレディクティブ発信用のデータベース」と表
現し「所望の数」の情報の集まりが「転送」によって生成されること，
を「所定の条件で抽出」して「作成」されると表現することは，当業，
者（その発明に属する技術の分野における通常の知識を有する者）が適
宜なし得たことである。審決は，上述の論旨を説示したものであって，
その内容に誤りはない。
(ｲ) 原告の主張(ｱ) について
原告は，本件発明は，バッチ処理構成を基本にしつつ，それに部分的
にすなわちコール止めの部分に限ってリアルタイム処理を組み合わせる
というハイブリッド型構成であるのに対し，引用発明１は，バッチ処理
，，を完全に排除しフルリアルタイム処理型を採用したことを前提として
引用発明１にプレディクティブ発信用ＤＢを用いる処理を組み合わせる
ことは，引用発明１の目的を実現不可能にすることになり，阻害事由が
あるなどと主張する。
しかし，本件発明で作成されるプレディクティブ発信用ＤＢがバッチ
処理によって作成されることが要求されるものでないこと，引用発明１
は，バッチ処理を完全に排除し，フルリアルタイム処理型を採用したも
のとは解されないことは，前記ア及びイで説示したとおりであるから，
この点に関する原告の主張は前提において採用することができない。
(ｳ) 原告の主張(ｲ) について
原告は，本件発明は，発信不要データを「指定されたデータベース」

から検索するという構成を採用することで，顧客マスタＤＢ以外のＤＢ
を検索することも可能である旨主張する。
しかし，この点が本件発明と引用発明１との相違点でなく一致点であ
ることは，前記ウ(ｳ) で説示したとおりである。原告の主張は審決の論
旨を正解しないものであって，採用することができない。
(ｴ) 原告の主張(ｳ)及び(ｴ) について
原告は，引用発明１の「所望の数」は「所定の条件」に相当しない，
引用発明１の「転送され」るは本件発明の「作成」に該当しない，など
と主張する。
しかし，本件発明に係る特許請求の範囲の記載及び発明の詳細な説明
の記載を精査しても「所定の条件で抽出する」というのがどのような，
条件によって抽出することなのか，また「作成する」とはどのような，
方法により作成することなのかを直接的に特定する記載はない。
かえって前記(1) イで認定したとおり発明の詳細な説明の段落０，，【
００２】ないし【０００５】における課題に関する記載からみて，本件
発明は，プレディクティブ発信用データベースの作成後に発生する問題
の解決を課題としており，プレディクティブ発信用データベースの作成
自体に伴う問題の解決を課題としたものではないから，プレディクティ
ブ発信用データベースをどのような条件でどのような方法によって作成
するかは，課題解決と無関係の事項であることが読み取れる。
したがって，一定の件数を指定して発信対象データを抽出することも
「所定の条件」に含まれるというべきであり，引用発明１において「所
望の数」の顧客アカウント情報を転送することも「所定の条件」に該当
すると解することに何ら問題はないし，コンピュータにおいて，データ
「」，，が転送されてそれが他の記憶装置に記録されればその記憶装置に
それまで存在していなかったデータが新たに記録されることになるので

あるから，それを「作成」と称することに何ら問題はないというべきで
あり，したがって，引用発明１のように，ある機器に存在するデータ集
合の中から他の機器に「転送」すべきデータ集合を抽出することも転送
データの「作成」に該当するということができる。
以上のとおりであるから，この点に関する原告の主張は採用すること
ができない。
(ｵ) 原告の主張(ｵ) について
ａこの点に関し，原告は，引用発明１でメインフレームコンピュータ
１６からシステム制御装置１１に「一括送信」されるデータの件数が
３ないし５件程度にすぎないこと等を根拠として，引用発明１の「転
送されたプレディクティブ発信を行う所望の数の顧客のアカウント情
報」は「データベース」ではないと主張する。
しかし，前記ウ(ｱ) で認定したとおり「データベース」とは「系，，
統的に整理・管理された情報の集まり」を意味すると認められると。
ころ，引用発明１においても「所望の数の顧客アカウント情報」か，
らアカウントの電話番号が抽出されてダイヤルされるのであって，そ
のために必要な整理・管理がなされているものであると認められるか
ら，上記の定義に従えば「転送されたプレディクティブ発信を行う，
所望の数の顧客のアカウント情報」を「データベース」と称すること
に何ら問題はない。
ｂまた，原告は「一括転送」の対象は「a number of customers」で，
あるところ「a number of」は「several」と同義であり，せいぜい，
３ないし５件の顧客データにすぎないと主張する。
しかし，引用例１の明細書上「一括転送」の対象が数件のデータ，
である旨の記載はない。かえって，同明細書には，前記(2)アＰのと
おり「システム制御装置１１が十分な記憶容量を有する場合は，シ，

ステム制御装置１１は顧客アカウントのファイル全体を保持し，この
記録全体をオペレータ端末に送信してもよい」との記載があり，同。
記載によれば，システム制御装置１１は顧客アカウントのファイル全
体を保持できる程の記憶容量を有することも想定されているといえる
ものである。
ｃさらに，原告は，引用例１のＦＩＧ．４の記載を根拠に，引用発明
１でメインフレームコンピュータ１６からシステム制御装置１１に送
信されるアカウント情報の件数は，本件明細書の段落【００２５】の
「該ペーシング制御部５６から要求があった発信データ群」の数（＝
Ｎ）と同程度であるなどとして，引用発明１でメインフレームコンピ
ュータ１６からシステム制御装置１１に「一括送信」されるデータの
件数が数件にすぎないなどとも主張する。
，，。しかし上記原告の主張は引用例１の記載を正解したものでない
むしろ引用例１の記載からすると，引用例１における「所望の数の」
あるいは「複数の」という文言は，プレディクティブ発信のデータ数
（呼数）Ｎよりは多い数であって，むしろ，プレディクティブ発信処
理を遅滞なく行える程度に，かつ，発信待ちの間にデータが古くなる
程度に，まとまった相当の量であるという意味を含んでいると認めら
れる。
すなわち，まず，前記(2) アＬの記載からみて，引用例１において
は「所望の数の顧客アカウント情報」がシステム制御装置１１に転，
送され，その上で，システム制御装置１１がこの「所望の数の顧客ア
カウント情報」から選択された顧客電話番号にダイヤルしており，メ
インフレームコンピュータ１６内の顧客のアカウント情報を管理して
いるデータベース（顧客管理情報を管理しているデータベース）から
ではなく，転送された「所望の数の顧客アカウント情報」から選択さ

れた顧客電話番号にダイヤルしていることが理解される。
そして，引用例１の「メインフレームコンピュータ１６は，所望，
の数のアカウントの顧客アカウント情報をデータ制御装置１５に一括
転送又はオンライン転送により提供する前記(2)アＬの記載２。」（），「
６からスタート後，第１ステップ２７ではメインフレーム１６から一
括モード転送により複数の顧客のアカウント情報を得る（前記(2) 。」
アＱ）の記載「次のステップ２８では，オペレータの予想される空，
（）。き状況に基づいて新しい呼出し又は再呼出しの必要性を計算する
空いたオペレータが居る場合，新しい呼出し（又は再呼出し）が必要
となる。しかし，全てのオペレータが話中である場合，所定の時間内
にオペレータが空く統計的確率に基づいて新しい呼出しが必要である
場合とない場合がある。判定２９は新しい呼出し（又は再呼出し）が
必要かを調べる。‥‥もし必要であれば，システム制御装置１１はス
テップ３０に進み呼出す次のアカウントの電話番号を抽出する前，。」（
記(2) アＱ）の記載，及び「ステップ２７でシステム制御装置１１は
一群の顧客アカウントのアカウント情報を得るので，その後の着信及
び／又は請求に対する支払い及びクレジットにより，システム制御装
置１１に記憶されたアカウント情報は，発信待ちの列において特定の
顧客アカウントの順番が来る時までに最新ではなくなる可能性があ
る（前記(2)アＲ）の記載からみて，システム制御装置１１は，プ。」
レディクティブ発信を行うオペレータの空き状況等による統計的な予
測に基づいて転送された所望の数の顧客アカウント情報からアカウン
トの電話番号を選択するものであり，また「所望の数の顧客アカウ，
ント情報」は転送された後プレディクティブ発信のために選択される
までの間に転送元となったメインフレームコンピュータの顧客データ
ベースに対して最新ではなくなる可能性がありこれに対して前記(2)，

アＲに掲げられる様々な解決方法がある旨が記載されているものであ
る。
そうすると，統計的な予測に基づいてプレディクティブ発信を遅滞
なく行うために，これを遅滞なく行える程度の量の顧客アカウント情
報がシステム制御装置１１に転送されているはずであるから，転送さ
れた「所望の数の顧客アカウント情報」は，プレディクティブ発信処
理を遅滞なく行う程度にまとまった相当の量のものであるとととも
に「発信待ちの列において特定の顧客アカウントの順番が来る時ま，
でに最新ではなくなる可能性がある」という事態が発生する程度にま
とまった相当の量のものであると認められる。
さらに，上記原告の主張は，原告が根拠として引用する引用例１の
ＦＩＧ．４Ａの記載内容とも整合していない。
すなわち，本件明細書における「予測発信を行うためのプレディク
ティブ発信のデータ数（呼数）Ｎ（段落【００２５）というのは，」】
「オペレータの予想される空き状況」や「利用可能な幹線」の数に即
して決定されるプレディクティブ発信のデータ数なのであるから，引
用例１においては，ステップ２８の「オペレータの予想される空き状
況に基づいて新しい呼出し（又は再呼出し）の必要性を計算する」や
ステップ３２の「幹線インターフェイス部に利用可能な幹線を問い合
」。，わせるにおける処理の結果に応じて決定されるものであるそして
たかだか予測発信を行うためのプレディクティブ発信のデータ数個「（
数）Ｎ」の顧客アカウントのみをメインフレームからシステム制御装
，，，置１１に転送するのであればステップ２８２９及びステップ３２
３３に対応する処理は，ステップ２７の転送の処理に先だってなされ
ているはずであって，これらの処理が転送後に行われることはあり得
ないというべきであるから，引用発明１でメインフレームコンピュー

タ１６からシステム制御装置１１に送信されるアカウント情報の件数
は，本件明細書の段落【００２５】の「該ペーシング制御部５６から
要求があった発信データ群」の数（＝Ｎ）と同程度であるということ
はないというべきである。
以上のとおり「a number of」という文言から，直ちに，引用発明，
１の「一括転送」が３ないし５件程度のデータの転送であるとの原告
の主張は採用できない。
したがって，引用発明１の「転送されたプレディクティブ発信を行
う所望の数の顧客のアカウント情報」は「データベース」ではないと
の原告の主張も失当である。
カ取消事由６（相違点２認定判断の誤り）について
(ｱ) 前記エ(ｲ) で認定したとおり，引用例２の記載事項からみて，発信デ
ータを指定されたデータベースに照会するに当たって電話番号をキーと
して指定された条件で検索することは，少なくとも引用例２に記載され
た公知の技術であると認められる。
そして，引用発明１は，プレディクティブ発信をするに当たってメイ
ンフレームコンピュータ１６に該特定の顧客のアカウントの状態を問い
合わせるのであるから，発信データについて指定されたデータベースに
照会するものであるということができる。
そうすると，引用発明１において，発信データについて指定されたデ
ータベースに照会するに当たって引用例２に記載された公知技術を採用
して，電話番号をキーとして照会するように構成することは，当業者が
容易になし得たことであり，この旨を述べた審決に誤りはない。
(ｲ) 原告の主張(ｱ) について
原告は，引用発明１は，プレディクティブ発信用ＤＢを排除すること
に特徴を有する発明であるから，引用発明１に「別のファイル」を用い

る構成を組み合わせることには阻害要因があると主張する。
しかし，前記イで認定したとおり，引用発明１はオンライン（リアル
タイム）処理を実現するために，バッチ処理でのプレディクティブ発信
用ＤＢ作成処理を取り去るという構成を採用したものとは認められない
から，原告の主張はその前提において失当であり，採用することができ
ない。
(ｳ) 原告の主張(ｲ) 及び(ｳ) について
原告は，引用発明２は，複数のコールセンタ間の情報共有に関する発
，，明であり本件発明と引用発明２とは課題も課題解決手段も異なるとか
引用発明１に引用発明２を組み合わせる動機付けがない旨主張する。
しかし，前記エ(ｲ) で説示したとおり，引用発明１に引用発明２を適
用するに当たっては，引用例２には発信しないデータを電話番号で検索
する点が開示されていれば十分なのであって，引用例２の発信しないデ
ータがどのように生成されたものであるかは問題ではないというべきで
あるから，引用発明２が，複数のコールセンタ間の情報共有に関する発
明であって課題も解決手段も異なっていたとしても，引用発明１におい
て，発信データについて指定されたデータベースに照会するに当たって
引用例２に記載された公知の技術を採用して，電話番号をキーとして照
会するように構成することは当業者であれば容易になし得たことという
べきである。また，引用発明１における転送された顧客アカウント情報
の数が３ないし５件程度ではない点は，前記オ( ｵ)で述べたとおりであ
るから，引用発明１と引用発明２との組合せについて動機付けに欠ける
ところはない。
したがって，原告の主張は，その前提において失当であり，採用する
ことができない。
３結論

以上のとおり，原告の主張する取消事由は全て理由がない。よって，原告の
請求を棄却することとして，主文のとおり判決する。
知的財産高等裁判所第１部
裁判長裁判官中野哲弘
裁判官東海林保
裁判官矢口俊哉

ページ上部へ