運営:アスタミューゼ株式会社
  • ポートフォリオ機能


追加

関連ワード 承継 /  29条1項3号 /  インターネット /  アクセス /  進歩性(29条2項) /  容易に発明 /  一致点の認定 /  公知技術 /  下位概念 /  技術的範囲 /  技術常識 /  発明の詳細な説明 /  共有 /  クレーム /  技術的意義 /  発明の要旨認定 /  容易に想到(容易想到性) /  特許発明 /  実施 /  加工 /  交換 /  具体的態様 /  請求の範囲 /  変更 / 
元本PDF 裁判所収録の全文PDFを見る pdf
事件 平成 22年 (行ケ) 10003号 審決取消請求事件
裁判所のデータが存在しません。
裁判所 知的財産高等裁判所
判決言渡日 2010/10/19
権利種別 特許権
訴訟類型 行政訴訟
判例全文
判例全文


平成22年(行ケ)第10003号 審決取消請求事件(特許)
口頭弁論終結日 平成22年10月5日
判決
原 告 JFEシステムズ株式会社
訴訟代理人弁護士 上 山 浩
同 小長谷真理
訴訟代理人弁理士 高 矢 諭
被 告 株式会社ベルシステム24
※(ただし,平成22年6月
1日に,本訴提起時の被告で
あった株式会社ベルシステム
24(承継前被告)を吸収合
併した株式会社BCJ?4が
同日付けで商号を承継後株式
会社ベルシステム24に変更
したもの)
訴訟代理人弁護士 野 口 明 男
同三好豊
同飯塚卓也
訴訟代理人弁理士 原 島 典 孝
主文
1 原告の請求を棄却する。
2 訴訟費用は原告の負担とする。
事実及び理由
第1 請求
特許庁が無効2009?8001 00号事件について平成21年11月3



0日にした審決を取り消す。
第2 事案の概要
,「 」 1 本件は 名称を コールセンタシステム及びプレディクティブダイヤラ装置
とする発明についての特許第350 5460号(出願日 平成12年2月17
日,登録日 平成15年12月19日, 請求項の数14,甲4。以下「本件特
許」という )の請求項1(以下「本件 発明」という )に対し,被告が特許権 。。
者である原告を被請求人として特許無効 審判請求をしたところ,特許庁が特許
29条2項違反を理由としてこれを認 容する審決をしたことから,これに不
服の原告が取消しを求めた事案である。
2 争点は,本件発明が,下記引用例1及 び2との関係で進歩性を有するか(特
許法29条2項 ,である。 )

・引用例1:米国特許第4797911号明細書(発明の名称「顧客アカウン
ト・オンラインサービスシステム ,特許登録日 平成元年(1989年)1 」
月10日,甲1。以下これに記載さ れた発明を「引用発明1」という ) 。
・引用例2:特開平9?25235 1号公報(発明の名称「発呼制御方法 ,公 」
,。 「 」 開日 平成9年9月22日 甲2 以下これに記載された発明を 引用発明2
という ) 。
第3 当事者の主張
1 請求の原因
(1) 特許庁における手続の経緯
原告(旧商号川鉄情報システム株式 会社)は,本件特許の特許権者である
ところ,被告は,平成21年5月18 日,本件特許の請求項1に対し,本件
,( ,) 発明は 引用発明1と同一である 特許法 29条1項3号違反 無効理由1
又は引用発明1及び2から当業者が容 易にその発明をすることができた(同
条2項違反,無効理由2)ことを理由 として,無効審判請求をした。



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



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



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



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



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



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



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



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





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



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



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



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



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



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



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



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



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



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





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



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



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



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



アカウント情報の件数は,本件明細 書の段落【0025】の「該ペーシン
グ制御部56から要求があった発信 データ群」の数(=N)と同程度であ
るなどとして,引用発明1でメイン フレームコンピュータ16からシステ
ム制御装置11に「一括送信」され るデータの件数が数件にすぎないなど
と主張するが,次のとおり,失当である。
すなわち,引用発明1に おいては,メインフレ ーム16からシステム制
御装置11に複数の顧客アカウント 情報が転送(図4Aのステップ27)
された後,後記第4,2(2)アQに記 載されているように 「‥‥判定29 ,
は新しい呼出し(又は再呼出し)が 必要かを調べる。‥‥もし必要であれ
ば,システム制御装置11はステッ プ30に進み,呼出す次のアカウント
の電話番号を抽出する 」という処理がされる。このステップ30におけ 。
る「アカウント情報群から次のアカ ウントの電話番号を抽出する」処理こ
そが,本件発明における,プレディ クティブ発信用データベース12から
発信データ群(N)を抽出する処理 に相当するのである。そして,引用例
1のFIG.4Aに開示されている とおり,このステップ30を経て電話
発信処理が終了した後も,ステップ 25において群処理が完了したか否か
の判断がされ,その結果が「No」 であれば,メインフレームコンピュー
タ16から新たにアカウント情報を 得ることなく,再度ステップ28以下
の処理を行うこととされているのである。
したがって,引用発明1 においては,メインフ レームコンピュータ16
からアカウント情報群を1回取得す るうちに,発信データ群Nの電話発信
処理を複数回行うことが予定されて いるのであるから,メインフレーム1
6からシステム制御装置11に転送 されるアカウント情報は,本件特許発
明でいう発信データ群Nよりも多いことは明らかである。
また,原告は,引用発明 1が出願された198 7年当時の主記憶容量が
極めて限られていたと主張するが, 引用例1に「システム制御装置11が



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



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



・ このようなプレディクティブ発信業務を行っている従来のコールセン 「
タシステム,及び,そこで用いられ るプレディクティブ発信装置で発信
データを作成する際には,図1に示 す如く,ステップ100で,全ての
顧客情報を管理しているマスタデー タベース(DB)10から,プレデ
ィクティブ発信を行うデータを所定 の条件で抽出して,プレディクティ
ブ発信専用のデータベース(DB) 12を作成した後,ステップ102
で,プレディクティブ発信用データ ベース12で選択された顧客の電話
番号を自動的にダイヤルして発信す るプレディクティブ発信処理を行っ
ていた (段落【0003 ) 。」】
・ 図1】プレディクティブ発信における従来の発信中止処理を示す流れ 【

・ そのため,一旦プレディクティブ発信処理が開始されてしまうと,例 「
えば顧客から着信する通話によるイ ンバウンド業務,インターネット
電子メール,又はその他の事務部門 等における顧客からのコンタクト等
によりプレディクティブ発信を行わ なくてもよい発信不要データがステ
ップ200で発生した場合には,ス テップ202で,マスタデータベー
ス10に発信不要データが発生した という情報を記憶させて,マスタデ
ータベース10を更新し,次いで, ステップ204で,バッチ処理又は
人が介在して,プレディクティブ発 信用データベース12から発信不要



データを削除したり,あるいは,発 信停止フラグを立てる等の処理が行
われていた (段落【0004 ) 。」】
・ 発明が解決しようとする課題】し かしながら,このような方法では, 「【
バッチ処理又は人が介在することに より,時間的なタイムラグが発生し
て,発信不要データが削除される前 に,当該データのプレディクティブ
発信が行われてしまう場合があった 。更に,昨今,コールセンタ,イン
ターネット,電子メール等といった 顧客に対するコンタクトチャンネル
,, も多様化してきており プレディクテ ィブ発信業務を行っている途中で
発信が不要となったデータを削除す ることが,ますます困難になってき
ている (段落【0005 ) 。」】
・ 本発明は,前記従来の問題点を解決するべくなされたもので,発信不 「
要データのプレディクティブ 発信を発信直前に止めることを課題とす
る (段落【0007 ) 。 」】
・ 本発明が採用されたコールセンタシステムの全体構成を図2に示す。 「
このコールセンタシステムは,オペ レータ毎に設けられた,複数(図で
は3台)の電話機20,及び,オペ レータを補助するクライアント装置
22と,前記電話機20を公衆電話 回線網(PSTN)14を介して顧
客の電話機16に接続するための交換機(PBX= Private Branch
eXchange)30と,インターネ ット接続用のウェブ(Web)サーバ装
置32と,電子メールを受信するた めのメールサーバ装置34と,全て
の顧客情報を管理しているマスタデ ータベース(DB)10を管理して
いるマスタDB管理装置36と,例 えば事務部門に設けられた顧客情報
処理部門38と,前記クライアント 装置22,PBX30,ウェブサー
バ装置32,メールサーバ装置34 ,マスタDB管理装置36及び顧客
情報処理部門38とローカルエリア ネットワーク(LAN)40を介し
て接続された,プレディクティブ発 信業務を行うと共に,プレディクテ



ィブ発信が不要となった発信不要デ ータの発信を発信直前に止めるリア
ルタイムコール止め機能を有するCTI(Computer Telephony
Integration)サーバ装置50とを含んで構成されている (段落【0 。 」
024 ) 】
・ 図2】本発明が採用されたコールセンタシステムの実施形態の全体構 【
成を示すブロック図
・ 前記CTIサーバ装置50は,図3に詳細に示す如く,例えばパソコ 「
ンで構成されるクライアント装置2 2に内蔵されたクライアントプログ
ラム24からLAN40経由でCT I命令を受信し,又,各種着信信号
を,後出CTI制御部54及びデー タベース(DB)制御部58から受
信してクライアントプログラム24 に送信するクライアント制御部52
と,該クライアント制御部52から 送信されたCTI命令及びDB制御
部58から送信された発信可能デー タをPBX30に送信して,発信処
理を行うと共に,PBX30から送 られてくる着信,応答,切断等の情





報を管理し,プレディクティブ発信 した結果,着信した情報はDB制御
部58へ送信し,それ以外の着信情 報はクライアント制御部52へ送信
するCTI制御部54と,予測発信 を行うためのプレディクティブ発信
のデータ数(呼数)NをDB制御部 58へ通知するペーシング制御部5
6と,該ペーシング制御部56から 要求があった発信データ群をプレデ
ィクティブ発信用DB12から抽出 すると共に,抽出したデータをマス
タDB10と比較して,マスタDB 10に存在する発信不要データをチ
ェックし,発信可能なデータをCT I制御部54へ送信する一方,発信
不要なデータは発信不要データベー ス(DB)60に格納するデータベ
ース(DB)制御部58とを備えている (段落【0025 ) 。」】
・ 図3】前記実施形態のCTIサーバ装置及びその周辺を示すブロック 【


以下 図4を参照して 本実施形態の処理手順を説明する 段落 0 「, , 。」 (【
026 ) 】
・ 図4】前記実施形態におけるリアルタイムコール止め発信処理の全般 【



を示す流れ図
・ まずステップ300で,キャンペーン(業務)単位毎に設定された, 「
。, 図5に示すような条件設定テーブルを読み込む 本実施形態においては
電話番号T又は,顧客識別情報の一つであるコールID Cを,データ
を読み込むためのキーとすることができる (段落【0027 ) 。」】
・ 次いでステップ302で,上位プログラムが終了したか否かを判定す 「
る。判定結果が否である場合には, 本処理を終了し,判定結果が正であ
る場合には,ステップ304に進み ,ペーシング制御部56から発信デ
ータ数Nを取得する (段落【0028 ) 。」】
・ 次いでステップ306に進み,本発明に係るリアルタイムコール止め 「
/発信処理を行う (段落【0029 ) 。」】
・ このリアルタイムコール止め/発信処理は,具体的には,図6に示す 「
如く行われる。即ち,まずステップ 400で,前記プレディクティブ発



信用DB12から発信データを抽出 する。次いでステップ402で,マ
スタDB10を検索し,ステップ4 04で,発信不要データではないと
判定された時には ステップ406に進み 発信処理を行う 段落 0 ,,。」 (【
030 ) 】
・ 一方,ステップ404で発信不要データであると判定された時には, 「
ステップ408に進み,発信せずに 発信不要DB60に登録する (段 。」
落【0031 ) 】
・ ステップ406又は408終了後,図4のステップ308に戻り,発 「
信数がNとなるまで,ステップ30 6のリアルタイムコール止め/発信
処理を繰り返す (段落【0032 ) 。 」】
・ 前記実施形態においては,発信不要データを専用の発信不要DB60 「
に登録していたが,マスタDB10 に登録したり,あるいは,マスタD
B10のフラグ等に反映することも 可能である。キーの種類も,電話番
号やコールIDに限定されず ,他の顧客識別情報を用いることができ
る (段落【0035 ) 。 」】
イ 上記記載によると,本件発明は,従 来,プレディクティブ発信を行わな
,, くてもよい発信不要データが発生した場合 バッチ処理又は人が介在して
プレディクティブ発信用データベース1 2から発信不要データを削除した
り,あるいは,発信停止フラグを立てる 等の処理が行われていたところ,
そのような従来技術においてはバッチ処 理や人の介在によるタイムラグが
発生して本来プレディクティブ発信が不 要なデータについてのプレディク
ティブ発信が行われてしまうという問題 点があったとの点を解決すべく,
「顧客情報を管理しているデータベース からプレディクティブ発信を行う
データを所定の条件で抽出して,プレデ ィクティブ発信用のデータベース
を作成した後」に生ずる,マスタデータ ベースの更新に伴って生ずるプレ
ディクティブ発信用データベースへの更 新の伝播のタイムラグという課題



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



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



各着信の状態の記録とを別に維持しな がら,メインフレームファイル内
の顧客アカウント情報をオンライン更新す るための装置を提供する 」 。
(3欄1?6行)
J 「従って,本発明の目的は,顧客 アカウントの全ての変更の記録と,
必要に応じて,各発信と各着信の状態 とを別に維持しながら,メインフ
レームファイル内の顧客アカウント情 報を直ちにオンライン更新するた
めの方法及び装置を提供するこ とである (3欄7?12行) 。」
「, K この好適な実施形態は4つの幹線インタフェース部10a?10d
システム制御装置11,16幹線×1 0線・クロス点スイッチ13,デ
ータ制御装置15,メインフレームコ ンピュータ16,及び10個のオ
ペレータ端末12a?12jを備える 。16本の幹線T1?T16は集
成幹線インタフェース部10とクロス 点スイッチ13に接続される。各
幹線インタフェース部10a?10d は4つの幹線を収容し,幹線イン
タフェース部10aは幹線T1?T4 にサービスを提供し,幹線インタ
フェース部10bは幹線T5?T8にサー ビスを提供する(他同様 。 )
各幹線インタフェース部10a?10 dは次の機能:幹線占有,ダイヤ
リング,呼出し進行監視,メッセージ 再生,及びメッセージ記録を実行
する。下記に幹線インタフェース部1 0a?10dについてより詳細に
説明する。スイッチ13はクロス点ス イッチである必要はなく,別の同
。, , () 様な装置であってもよい 例えば スイッチ13は 構内交換 PBX
スイッチ等の電話システム又はその一部であってもよい (3欄48? 。 」
65行)
L 「ここで本実施形態の動作を考え る。メインフレームコンピュータ1
6は,所望の数のアカウントの顧客ア カウント情報をデータ制御装置1
5に一括転送又はオンライン転送によ り提供する。次にデータ制御装置
15はこの情報をポートHPS1を介 してシステム制御装置11に提供



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



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



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



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







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



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



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



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



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



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



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



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



・ 19図】コールセンター1でのコールリストの一例を示す図 【
・ 顧客選択部212(1)は,コールリスト1の最初の顧客A氏の電 「
話番号を取り出し,A氏に電話をかける 。A氏とは電話が繋がり,テ
レマーケティングが行われたとする。な お,この時点ではA氏に関す
る不在等の情報はないものとする (段落【0134 ) 。 」】
・ 次に,顧客選択部212(1)は,コールリスト1の次の顧客B氏 「
の電話番号を取り出し,B氏に電話をか ける。ここで,B氏は不在で
あったとする。この場合,不在か否かは ,実際にB氏の電話番号に電
話をかけ,一定時間内に応答があるか否 かでB氏の不在を判断するの
で,B氏に電話をかけてからB氏の不在 を確認するまでの時間は無駄
な時間となる (段落【0135 ) 。 」】
・ B氏の不在を確認すると,顧客情報通知部215(1)は,B氏が 「
不在である旨の情報をコールセンター2 に通知する。その際,送られ
るデータの例を図20に示す。この場合 は,B氏が不在である情報,
B氏の不在を発見した時刻 B氏の電話番号が送られる 段落 0 ,。 」 (【
136 ) 】
・ 図20】コールセンター1からコールセンター2に送られる不在者 【
情報の一例を示す図



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





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



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



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



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



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



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



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



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



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



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





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