【事件の表示】
　上記当事者間の特許第３５０５４６０号発明「コールセンタシステム及びプレディクティブダイヤラ装置」の特許無効審判事件について、次のとおり審決する。
【結　論】
　特許第３５０５４６０号の請求項１に係る発明についての特許を無効とする。
　審判費用は、被請求人の負担とする。
【理　由】
第１　手続の経緯
　本件に係る手続の概要は次のとおりである。
　
平成１２年　２月１７日　　　　　　出願（特願２０００−３９９８９号）
平成１５年１２月１９日　　　　　　設定登録（特許第３５０５４６０号，
　　　　　　　　　　　　　　　　　　　　　　請求項の数［１４］）
平成２１年　５月１８日　　　　　　無効審判請求書
平成２１年　８月１２日　　　　　　答弁書（被請求人）
平成２１年１０月１５日（差出日）　口頭審理陳述要領書（請求人）
平成２１年１０月１５日　　　　　　口頭審理陳述要領書（被請求人）
平成２１年１０月２７日　　　　　　口頭審理、審理終結（口頭で通知）
　
第２　本件特許発明
　本件特許の請求項１に係る発明（以下、「本件特許発明」という。）は、設定登録時の明細書又は図面の記載からして、その特許請求の範囲の請求項１に記載された次のとおりのものと認める。
　
「顧客情報を管理しているデータベースからプレディクティブ発信を行うデータを所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後、該プレディクティブ発信用のデータベースで選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて、
　顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
　該プレディクティブ発信用のデータベースから抽出された発信データを、プレディクティブ発信時に、電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行うことを特徴とするコールセンタシステム。」
　
第３　当事者の主張
１　請求人の主張
　請求人株式会社ベルシステム２４は、本件特許発明についての特許を無効にする、審判費用は被請求人の負担とする、との審決を求め、その理由として次の無効理由１及び２を挙げ、本件特許は特許法第１２３条第１項第２号に該当するので無効とすべきであると主張している。また、証拠方法として甲第１〜第３号証を提出している。
　
　[無効理由１]
　本件特許発明は、その出願前に頒布された刊行物である甲第１号証に記載された発明であるから、特許法第２９条第１項第３号の規定に違反してなされたものである。
　
　[無効理由２]
　本件特許発明は、その出願前に頒布された刊行物である甲第１号証に記載された発明、あるいは、甲第１号証と甲第２号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものであるから、特許法第２９条第２項の規定に違反してなされたものである。
　
　[証拠方法]
　甲第１号証　　：　米国特許第４７９７９１１号明細書
　甲第１号証の２：　甲第１号証の翻訳文
　甲第２号証　　：　特開平９−２５２３５１号公報
　甲第３号証　　：　三菱事務機械株式会社，“コストパフォーマンス抜群
　　　　　　　　　　のプレディクティブ・ダイヤリング・システム”，月
　　　　　　　　　　刊テレマーケティングジャーナル，アイビーシステム
　　　　　　　　　　株式会社発行，平成６年８月２５日，１９９４年９月
　　　　　　　　　　号,Ｖｏｌ．７，Ｎｏ．９，ｐｐ１９−２２
　
２　被請求人の主張
　被請求人ＪＦＥシステムズ株式会社は、答弁書において、本件審判の請求は成り立たない、審判費用は請求人の負担とする、との審決を求め、本件特許発明は、甲第１号証に記載された発明ではないから、特許法第２９条第１項第３号の規定に違反してなされたものではなく、甲第１号証に記載された発明、あるいは、甲第１号証と甲第２号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものではないから、特許法第２９条第２項の規定に違反してなされたものではなく、本件特許発明を無効とすべき理由は存在しない旨主張する。
　
第４　当審の判断
１　無効理由１についての判断
（１）甲第１号証に記載の発明
　甲第１号証には、「CUSTOMER ACCOUNT ONLINE SERVICING SYSTEM」（仮訳：顧客アカウントオンラインサービスシステム）として、図面とともに次の記載がある。
　
ア．「A mainframe computer (16) contains customer or potential customer account information such as customer name, customer telephone number, customer account code, customer order status, etc. Mainframe computer (16) sends batches of customer account information to a system controller (11) via a data controller (15). System controller(11) directs trunk interface units(10a-10d) to dial the customer's telephone number and monitor the status of the outgoing calls. 」
（フロントページ）
（仮訳：メインフレームコンピュータ（１６）は、顧客又は潜在的顧客のアカウント情報、例えば顧客名、顧客電話番号、顧客アカウントコード、顧客注文状態等を含む。メインフレームコンピュータ（１６）は、顧客アカウント情報群をシステム制御装置（１１）にデータ制御装置（１５）を介して送信する。システム制御装置（１１）は幹線インタフェース部（１０ａ〜１０ｄ）に顧客の電話番号をダイヤルし、発信の状態を監視するよう命令する。）
　
イ．「Many businesses, especially those with large numbers of customer accounts, periodically contact the customer by telephone to obtain updated account information, remind the customer of a past due account, collect on delinquent accounts, or conduct other business. Also, some businesses are based primarily or exclusively upon sales conducted via telephone, either in response to a previously mailed catalog or advertisement or from direct solicitation by calling the customer.」
（第１欄第１２−２０行）
（仮訳：多くのビジネス、特に、多数の顧客アカウントを有するビジネスは、定期的に顧客に電話でコンタクトして、最新のアカウント情報を得たり、顧客に期限経過勘定を督促したり、滞納勘定について集金したり、又は他の業務を行う。また、幾つかのビジネスは、以前に郵送したカタログ又は広告に応答して電話で行うセールス、或いは顧客に電話をする直接勧誘によるセールスに主に又はだけに基づいている。）
　
ウ．「Therefore, there is need for a method and an apparatus which automatically dials the call without operator intervention or control and only connects the operator and displays the customer account record, which is resident in the mainframe, if the call is answered, thereby allowing the operator's time to be more effectively used.」
（第１欄第３８−４４行）
（仮訳：従って、オペレータの時間をより有効に使用できるように、オペレータの介入なしに自動的に番号をダイヤルし、呼出しに応答があった場合だけオペレータを接続し、メインフレームにある顧客アカウント記録を表示する方法及び装置が必要とされている。）
　
エ．「The preferred embodiment comprises four trunk interface units 10a-10d, a system controller 11, a 16 trunk-by-10 line cross-point switch 13, a data controller 15, a mainframe compute 16, and 10 operator terminals 12a-12j. Sixteen trunk lines T1-T16 are connected to composite trunk interface unit 10 and cross-point switch 13. Each trunk interface unit 10a-10d accommodates four trunk lines so that trunk interface unit 10a services trunks T1-T4, trunk interface unit 10b services trunks T5-T8, and so forth. Each trunk interface unit 10a-10d performs the following functions: trunk seizure; dialing; call progress monitoring; message playing; and message recording. Trunk interface units 10a-10d are explained in more detail below. Switch 13 need not be a cross-point switch but may be another similar device. For example, switch 13 may be, or may be part of, a telephone system, such as the private branch exchange (PBX) switch.」
（第３欄第４８−６５行）
（仮訳：この好適な実施形態は４つの幹線インタフェース部１０ａ〜１０ｄ、システム制御装置１１、１６幹線×１０線・クロス点スイッチ１３、データ制御装置１５、メインフレームコンピュータ１６、及び１０個のオペレータ端末１２ａ〜１２ｊを備える。１６本の幹線Ｔ１〜Ｔ１６は集成幹線インタフェース部１０とクロス点スイッチ１３に接続される。各幹線インタフェース部１０ａ〜１０ｄは４つの幹線を収容し、幹線インタフェース部１０ａは幹線Ｔ１〜Ｔ４にサービスを提供し、幹線インタフェース部１０ｂは幹線Ｔ５〜Ｔ８にサービスを提供する（他同様）。各幹線インタフェース部１０ａ〜１０ｄは次の機能：幹線占有、ダイヤリング、呼出し進行監視、メッセージ再生、及びメッセージ記録を実行する。下記に幹線インタフェース部１０ａ〜１０ｄについてより詳細に説明する。スイッチ１３はクロス点スイッチである必要はなく、別の同様な装置であってもよい。例えば、スイッチ１３は、構内交換（ＰＢＸ）スイッチ等の電話システム又はその一部であってもよい。）
　
オ．「Consider now the operation of the preferred embodiment. Mainframe computer 16 will provide, by a batch transfer or online transfer, the customer account information for a desired number of accounts to data controller 15. Data controller 15 then provides this information via port HPS1 to system controller 11. Alternatively, system controller 11 may obtain this information directly from mainframe 16 and its associated disk drive systems. System controller 11 then extracts, for each account, the name of the customer, the customer's telephone number, the account number, and/or some type of mainframe database index number. Assuming that trunk T1 is available, then system controller 11 will direct trunk interface unit 10a to seize trunk T1, provide the customers telephone number to trunk interface unit 10a, and direct trunk interface unit 10a to dial the customer's telephone number. Trunk interface unit 10a dials the customer's telephone number and then monitors trunk T1 for the status of the call.」
（第５欄第１３−３１行）
（仮訳：ここで本実施形態の動作を考える。メインフレームコンピュータ１６は、所望の数のアカウントの顧客アカウント情報をデータ制御装置１５に一括転送又はオンライン転送により提供する。次にデータ制御装置１５はこの情報をポートＨＰＳ１を介してシステム制御装置１１に提供する。或いは、システム制御装置１１はこの情報を直接メインフレーム１６とそのディスクドライブシステムから得てもよい。次にシステム制御装置１１はアカウント毎に顧客名、顧客電話番号、アカウント番号、及び／又はあるタイプのメインフレームデータベース指標番号を抽出する。幹線Ｔ１が使用可能であると仮定すると、システム制御装置１１は、幹線インタフェース部１０ａに幹線Ｔ１を占有するよう命令し、顧客電話番号を幹線インタフェース部１０ａに提供し、幹線インタフェース部１０ａにこの顧客電話番号をダイヤルするよう命令する。幹線インタフェース部１０ａは顧客電話番号をダイヤルし、この呼出しの状態を求めて幹線Ｔ１を監視する。）
　
カ．「Assume now that when the party called on trunk T1 answered, an operator was not available. Trunk interface unit 10a starts the message player and advises system controller 11 that the called party has answered. After ascertaining that an operator is not available, system controller 11 will allow trunk interface unit 10a to continue playing the desired prerecorded message to the called party. As soon as system controller 11 determines that an operator is available, system controller 11 will cause cross-point switch 13 to connect the available operator terminal 12 to trunk T1, direct trunk interface unit 10a to release trunk T1, direct unit 10a to stop the message, advance to the next message, and send the abbreviated customer account information to the available operator terminal 12.」
（第６欄第２３−３７行）
（仮訳：幹線Ｔ１を介して被呼者が応答した時、空いたオペレータが居ないと仮定する。幹線インタフェース部１０ａはメッセージ再生機を起動し、システム制御装置１１に被呼者が応答したことを通知する。空いたオペレータが居ないことを確認後、システム制御装置１１は幹線インタフェース部１０ａが被呼者へ予め記録された所望のメッセージの再生を続けることを許可する。システム制御装置１１が空いたオペレータが居ると判断すると、システム制御装置１１はクロス点スイッチ１３に利用可能なオペレータ端末１２を幹線Ｔ１に接続させ、幹線インタフェース部１０ａに、幹線Ｔ１を解放し、メッセージを停止し、次のメッセージに進み、短縮された顧客アカウント情報を該利用可能なオペレータ端末１２に送信するよう命令する。）
　
キ．「Also, it will be appreciated that the customer account information in the main database in mainframe computer 16 is immediately updated so that, at the end of the business day, it is not necessary to consolidate changes made by the operator(s) to the customer account information and also provides the benefit that, at any time during the day when the customer calls or is called, the customer account information available to the operator is the current, updated customer account information.」
（第７欄第２１−３０行）
（仮訳：また、メインフレーム１６の主データベース内の当該顧客アカウント情報を直ちに更新するので、オペレータが行った顧客アカウント情報への変更を各業務日の終わりに統合する必要がないこと、及び一日の任意の時点での顧客が電話をかけてくる、又は顧客を呼出した時、オペレータに提供される顧客のアカウント情報は最新の更新された顧客アカウント情報であるという利点があることが理解されるであろう。）
　
ク．「Turn now to FIGS. 4A and 4B which are a flow chart of the logic used by system controller 11. Upon starting 26, the first step 27 is to obtain, by batch mode transfer from mainframe 16, the account information for a number of customers. This account information may also contain a mainframe database index number or key. Alternatively, system controller 11 may obtain, for a number of accounts, abbreviated account information such as name, telephone number, account number and/or an index number. Batch mode transfer is preferred but, if desired, system controller 11 can obtain information on a single customer account from mainframe 16. The next step 28 is to calculate the need for a new call (or a repeat call) based upon the projected availability of an operator. If an operator is available, then there would be a need for a new call (or a repeat call). However, if all the operators are busy, then, based upon the statistical probability of an operator becoming available within a predetermined time, a new call may or may not be needed. Decision 29 tests whether a new (or repeat) call is needed. If not, then system controller 11 returns to step 28. If so, then system controller 11 proceeds to step 30 wherein it extracts the telephone number for the next account to be called. Decision 31 tests whether it is permissible to dial the extracted telephone number based upon several factors. Typically, the several factors would include the time zone in which the party is located, whether the telephone number was previously called, whether the telephone number previously called was busy, not answered or out of service, the amount of time since the last attempt to contact that telephone number information on whether the account should be called during daytime hours, nighttime hours, or only during certain hours, and the priority desired (larger bills called first). If it is not permissible to dial this telephone number, based upon these factors, then system controller 11 returns to step 28. If it is permissible to dial this telephone number, then system controller 11 proceeds to step 32.」
（第９欄第４２行−第１０欄第１２行）
（仮訳：システム制御装置１１により使用されるロジックのフローチャートである図４Ａ及び図４Ｂを参照する。２６からスタート後、第１ステップ２７ではメインフレーム１６から一括モード転送により複数の顧客のアカウント情報を得る。このアカウント情報はメインフレームデータベース指標番号又はキーを含んでもよい。或いは、システム制御装置１１は複数のアカウントの短縮されたアカウント情報、例えば名前、電話番号、アカウント番号、及び／又は指標番号を得てもよい。一括モード転送が好ましいが、もし望むなら、システム制御装置１１はメインフレーム１６から１つの顧客アカウントに関する情報を得てもよい。次のステップ２８では、オペレータの予想される空き状況に基づいて新しい呼出し（又は再呼出し）の必要性を計算する。空いたオペレータが居る場合、新しい呼出し（又は再呼出し）が必要となる。しかし、全てのオペレータが話中である場合、所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合とない場合がある。判定２９は新しい呼出し（又は再呼出し）が必要かを調べる。もし否であれば、システム制御装置１１はステップ２８に戻る。もし必要であれば、システム制御装置１１はステップ３０に進み、呼出す次のアカウントの電話番号を抽出する。判定３１は幾つかの要因に基づいて抽出した電話番号をダイヤルすることが許されるかを検査する。これらの要因は、通常相手が位置するタイムゾーン、該電話番号に以前電話をかけたか、以前かけた該電話番号は話し中であった／応答がなかった／使われていなかったか、該電話番号に最後にかけてからの経過時間、該アカウントは昼間／夜間／ある時間帯に呼出すべきかに関する情報、及び所望の優先度（より大きな勘定が優先）を含む。これらの要因に基づいてこの電話番号をダイヤルすることが許されない場合、システム制御装置１１はステップ２８に戻る。この電話番号をダイヤルすることが許される場合、システム制御装置１１はステップ３２に進む。）
　
ケ．「It will be appreciated that, since system controller 11 obtains account information for a batch of customer accounts at step 27, the account information contained in system controller 11 may, because of subsequent incoming calls and/or payments and credits to the bill, no longer be current by the time a particular customer account reaches its turn in the queue. There are several different approaches to handling this problem. One approach is for system controller 11 to obtain account information for only one account at a time at step 27. Another approach is, each time information is entered into mainframe 16, for mainframe 16 to send to system controller 11 updated information on that account. Another approach, which is used in the preferred embodiment, is for system controller 11 to request the status of each account from mainframe 16 before system controller 11 attempts to place a call for that account. Mainframe 16 would then advise system controller 11 if there has been a change in the status for that account and, if a change has been made, what change to the status has occurred. If there has been no change in the status or, if the change does not affect the need to call that particular account, then system controller 11 will proceed to step 32. If it is no longer appropriate to call that account, then system controller 11 will return to step 28.」
（第９欄第１３−３７行）
（仮訳：ステップ２７でシステム制御装置１１は一群の顧客アカウントのアカウント情報を得るので、その後の着信及び／又は請求に対する支払い及びクレジットにより、システム制御装置１１に記憶されたアカウント情報は、発信待ちの列において特定の顧客アカウントの順番が来る時までに最新ではなくなる可能性がある。この問題を扱う幾つかの方法が存在する。１つの方法は、システム制御装置１１はステップ２７で一度に１つのアカウントだけのアカウント情報を得ることである。別の方法は、メインフレーム１６に情報が入力されるたびに、メインフレーム１６が当該アカウントに関する更新された情報をシステム制御装置１１に送信することである。本実施形態で使用する方法は、アカウントに電話をかける前に、システム制御装置１１がメインフレーム１６に該アカウントの状態を問合せることである。これに応答して、メインフレーム１６は該アカウントの状態に変化があったか否かと、変化があった場合、どんな状態変化が発生したかをシステム制御装置１１に通知する。状態に変化がなかった場合、又は変化が該特定のアカウントに電話をかける必要性に影響しない場合、システム制御装置１１はステップ３２に進む。該アカウントに電話をかけることがもはや適当でない場合、システム制御装置１１はステップ２８に戻る。）
　
　甲第１号証に記載された顧客オンラインサービスシステムは、顧客アカウント情報を管理するためのデータベースを有したメインフレームコンピュータ（１６）があって（上記キ．）、所望の数の顧客アカウント情報をメインフレームコンピュータ（１６）からシステム制御装置（１１）へ転送するものである（上記オ．及びク．）。
　上記オ．及びク．の記載、並びに図４Ａ及び図４Ｂで示されたシステム制御装置（１１）のフローチャートでの、「EXTRACT TEL.NO. FOR AN ACCOUNT FROM ACCOUNT INFORMATION BATCH」（仮訳：アカウント情報バッチから、あるアカウントの電話番号を抽出する）、「SEND TEL.# TO DIALER CONNECTED TO AVAIL. TRUNK」（仮訳：利用可能なトランクに接続されたダイヤラーに電話番号を送る。）という一連の処理の記載から、顧客オンラインサービスシステムは、転送された所望の数の顧客のアカウント情報から、顧客の電話番号を自動的に選択してダイヤル発信する処理をするといえるものである。
　また、ダイヤル発信の態様は、
・「従って、オペレータの時間をより有効に使用できるように、オペレータの介入なしに自動的に番号をダイヤルし、呼出しに応答があった場合だけオペレータを接続し、…」（上記ウ．）
・「…オペレータの予想される空き状況に基づいて新しい呼出し（又は再呼出し）…しかし、全てのオペレータが話中である場合、所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合…」（上記ク．）
　とあるから、予想を取り入れた発信を行い、相手がでたときにだけオペレータにつなぐものであって、これは、例えば、甲第３号証や、“「ＮＴＴ技術ジャーナル」にみる最新情報通信用語集”，初版第３刷，社団法人電気通信協会発行，平成１０年５月１０日，ｐ５９３にも例示される、典型的な「プレディクティブ」発信である。
　この点について、被請求人は、答弁書において、第１２頁第１３行「甲第１号証の方法、すなわち個々のプレディティブ発信の都度…」、同頁第１９行「甲第１号証において顧客への発信（プレディクティブ発信）処理は、…」と答弁しており、甲第１号証のダイヤル発信の態様はプレディクティブ発信であることを事実上認めている。
　そして、上記ケ．では、特定の顧客のアカウントについて、着信、請求に対する支払いがあったため、特定の顧客に発信することがもはや適当でない場合があることが示されており、この場合の特定の顧客のアカウント情報をデータとしてみれば、“発信不要データ”が発生したといえる。そして、発信防止策として、「システム制御装置１１がメインフレーム１６に該アカウントの状態を問合せ…これに応答して、メインフレーム１６は該アカウントの状態に変化があったか否かと、変化があった場合、どんな状態変化が発生したかをシステム制御装置１１に通知する。…該アカウントに電話をかけることがもはや適当でない場合、」とあるから、特定の顧客のアカウントの状態を問いあわせ、特定の顧客のアカウント情報がデータとして“発信不要データ”であるか否かを判定するものといえるものである。
　そして、“発信不要データ”であると判定された場合には、「該アカウントに電話をかけることがもはや適当でない場合、システム制御装置１１はステップ２８に戻る。」と示されており、そのステップ２８とは、（次の）新しい発信の必要性を計算する（上記ク．）というものである。
　
　以上のことから、甲第１号証には次の発明（以下、「引用発明１」という。）が開示されていると認められる。
　
「顧客のアカウント情報を管理しているデータベース（メインフレームコンピュータ（１６）内）からプレディクティブ発信を行う所望の数の顧客アカウント情報が転送され、所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っている顧客オンラインサービスシステムにおいて、
　特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
　メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する（ステップ２８）顧客オンラインサービスシステム。」
　
（２）対比
　本件特許発明と引用発明１とを対比する。
　
ａ．引用発明１の「顧客のアカウント情報」は、「顧客情報」である。
　
ｂ．上記ａ．を考慮すると、引用発明１の「顧客のアカウント情報を管理しているデータベース（メインフレームコンピュータ（１６）内）」は、本件特許発明の「顧客情報を管理しているデータベース」に相当する。
　
ｃ．引用発明１の「プレディクティブ発信を行う所望の数の顧客アカウント情報が転送され、所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信する」と、本件特許発明の「プレディクティブ発信を行うデータを所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後、該プレディクティブ発信用のデータベースで選択された顧客の電話番号を自動的にダイヤルして発信する」とを対比すると、引用発明１の「転送され」た「所望の数の顧客アカウント情報」も、本件特許発明の「プレディクティブ発信用のデータベース」も、“プレディクティブ発信用のデータの集合”であることに変わりはないから、両者は「プレディクティブ発信用のデータの集合を得て、該プレディクティブ発信用のデータの集合で選択された顧客の電話番号を自動的にダイヤルして発信する」点で共通する。
　
ｄ．引用発明１の「顧客オンラインサービスシステム」は、コールセンタとしての機能を提供するものであるから、本件特許発明の「コールセンタシステム」と実質的に同じものである。
　
ｅ．引用発明１の「特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい」については、例えば、顧客オンラインサービスシステムが、上記「（１）甲第１号証に記載の発明」の項の摘記イ．の「期限経過勘定の督促」業務で用いられる場合には、既に特定の顧客が借金を窓口（その他の事務部門）で直接返済しており（コンタクトしており）、もはや発信して督促すべきでないことが、一事例として自明であり、これは、本件特許発明における「その他の事務部門における該顧客からのコンタクト」により、「プレディクティブ発信を行わなくてもよい」事例に該当する。
　また、上記「（１）甲第１号証に記載の発明」の項の摘記イ．の「セールス」業務で用いられる場合には、既に顧客からの電話（インバウンド業務）でセールス対象品を受注しており、もはや発信して勧誘しなくてもよいことが、一事例として自明であり、これは、本件特許発明における「顧客から着信する通話によるインバウンド業務」により、「プレディクティブ発信を行わなくてもよい」事例に該当する。
　よって、本件特許発明の「顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい」（以下、「構成Ａ」という。）と、引用発明１の「特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい」（以下、「構成Ｂ」という。）とを対比すると、構成Ａが択一的記載であり、選択肢のうち二つが、上記のように、構成Ｂにより充足されるものである。そして、構成Ａの選択肢の少なくとも一つが構成Ｂにより充足されれば、他の選択肢に関係なく、構成Ｂは構成Ａに含まれるという意味において、構成Ｂは構成Ａに相当する。
　
ｆ．
（ア）引用発明１の「メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ」ることとは、具体的には、引用発明１の「データベース（メインフレームコンピュータ（１６）内）」に対して、その状態を照会することであるのは自明である。そして、「検索」は「照会」の態様であること、上記ｃ．をも考慮すれば、引用発明１の「メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ」ることと、本件特許発明の「プレディクティブ発信用のデータベースから抽出された発信データを、」「電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索すること」とは、「プレディクティブ発信用のデータの集合から抽出された発信データを、指定されたデータベースに照会すること」で共通する。
　
（イ）引用発明１の「新しい発信の必要性を計算する（ステップ２８）」では、新しい（次の顧客への）発信を計算する時点で、特定の顧客への発信（call.コール）はもはや行われないことが確定し、その発信は発信前に即時、すなわち実時間（リアルタイム）で止められたと解せるから、本件特許発明の「その発信を中止するリアルタイムコール止めを行う」に相当する。
　
（ウ）引用発明１の「メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する（ステップ２８）」処理は、一連のプレディクティブ発信処理の一部をなすものであって、「プレディクティブ発信時」での処理といえる。
　
（エ）したがって、上記（ア）〜（ウ）からして、引用発明１の「メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する（ステップ２８）」と、本件特許発明の「該プレディクティブ発信用のデータベースから抽出された発信データを、プレディクティブ発信時に、電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行う」とは、「該プレディクティブ発信用のデータの集合から抽出された発信データを、プレディクティブ発信時に、指定されたデータベースに照会することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行う」点で共通する。
　
　したがって、引用発明１と本件特許発明とは、次の点で一致する。
　
（一致点）
「顧客情報を管理しているデータベースからプレディクティブ発信用のデータの集合を得て、該プレディクティブ発信用のデータの集合で選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて、
　顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
　該プレディクティブ発信用のデータの集合から抽出された発信データを、プレディクティブ発信時に、指定されたデータベースに照会することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行うコールセンタシステム。」
　
　一方で、両者は、次の点で相違する。
　
（相違点１）
　プレディクティブ発信業務として自動的にダイヤルされる顧客の電話番号の選択元となる「プレディクティブ発信用のデータの集合」に関し、本件特許発明では、「所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後」の「該プレディクティブ発信用のデータベース」であるのに対し、引用発明１では「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」である点。
（相違点２）
　発信データを指定されたデータベースに「照会」することにより発信不要データであると判定する具体的態様は、本件特許発明では、「電話番号又は他の顧客識別情報をキーとして」、指定されたデータベースを「指定された条件で検索する」ものであるのに対し、引用発明１では、メインフレームコンピュータ（１６）に「該特定の顧客のアカウントの状態を問いあわせ」るものである点。
　
（３）無効理由１についてのまとめ
　本件特許発明と引用発明１とは、上記のとおり、相違点１及び２において相違するものであるから、本件特許発明は甲第１号証に記載された発明であるとはいえない。
　以上のとおりであるから、無効理由１には理由がない。
　
２　無効理由２についての判断
　「１　無効理由１についての判断」に続き、本項においては、甲第２号証に記載の発明を認定し、次いで、相違点１及び相違点２について判断する。最後に、無効理由２に理由があるか否かについてまとめる。
　
（１）甲第２号証に記載の発明
　甲第２号証には、「発呼制御方法」として、図面とともに次の記載がある。
　
ア．「【０１２３】（実施形態３）次に、実施形態３について説明する。本実施形態の各コールセンター・システム（アウトバウンド業務処理システム）の構成は、基本的には図１７と同様である。
【０１２４】すなわち、図１７のように、オペレータ（図中３０３）一人あたり１台の端末３０４と電話機３０５が設置され、各端末３０４はホストコンピュータ２０１に接続されている。また、各電話機３０５は交換機３０６を経由して外線と接続される。
【０１２５】最も初歩的なシステムでは、コールリスト２１１に従って端末３０４に顧客の電話番号が表示され、オペレータが自身で電話をダイヤル操作して発呼を行う。ホストコンピュータ２０１と交換機３０６が連動している初歩的なシステムでは、端末３０４からの指示により交換機３０６経由で（コールリスト２１１に従って）自動的に電話が発信され、電話機３０５に接続される。また、パワーダイヤリングやプレディクティブ・ダイヤリングを行うシステムでは、交換機３０６はホストコンピュータ２０１と接続され、コールリスト２１１に従って適宜自動発呼される。本発明は、上記のどのシステムにも適用可能である。」
（第２２、２３欄、段落１２３−１２５）
　
イ．「【０１３３】図１８に示す形態での２つのコールセンターで、コールセンター１からコールセンター２に顧客の不在情報が通知される例を用いる。コールセンター１におけるコールリスト１（２１１（１））は、図１９で示される内容であるとする。この場合、コールセンター１では、以下の手順で電話をかける。
【０１３４】顧客選択部２１２（１）は、コールリスト１の最初の顧客Ａ氏の電話番号を取り出し、Ａ氏に電話をかける。Ａ氏とは電話が繋がり、テレマーケティングが行われたとする。なお、この時点ではＡ氏に関する不在等の情報はないものとする。
【０１３５】次に、顧客選択部２１２（１）は、コールリスト１の次の顧客Ｂ氏の電話番号を取り出し、Ｂ氏に電話をかける。ここで、Ｂ氏は不在であったとする。この場合、不在か否かは、実際にＢ氏の電話番号に電話をかけ、一定時間内に応答があるか否かでＢ氏の不在を判断するので、Ｂ氏に電話をかけてからＢ氏の不在を確認するまでの時間は無駄な時間となる。
【０１３６】Ｂ氏の不在を確認すると、顧客情報通知部２１５（１）は、Ｂ氏が不在である旨の情報をコールセンター２に通知する。その際、送られるデータの例を図２０に示す。この場合は、Ｂ氏が不在である情報、Ｂ氏の不在を発見した時刻、Ｂ氏の電話番号が送られる。
【０１３７】コールセンター２の顧客情報受信部２１６（２）は、図２０に示されたデータを受け取る。なお、Ｂ氏が不在であることおよびこれを検出した時刻等の情報は、自身の顧客情報受信部２１６（１）に格納するか、あるいはコールリスト１中にフィールドを設けて記録しておく。
【０１３８】次に、同時にテレマーケティング業務を行っているコールセンター２での手順を以下に述べる。コールセンター２におけるコールリスト２（２１１（２））は、図２１で示される内容であるとする。
【０１３９】顧客選択部２１７（２）は、コールリスト２の最初の顧客Ｘ氏の電話番号を取り出し、Ｘ氏を発呼する候補とする。この際、顧客情報受信部２１６（２）を参照し、Ｘ氏の不在情報が届いていないかチェックする。なお、自身で検出したある顧客の不在等の情報をコールリスト中に記録しておく場合、コールリスト２中のＸ氏の不在情報の欄もチェックする。
【０１４０】この場合は、Ｘ氏の不在情報は届いていないので、Ｘ氏に電話をかけ、Ｘ氏とは電話がつながり、テレマーケティングが行われたとする。次に、顧客選択部２１７（２）は、コールリスト２の次の顧客Ｂ氏の電話番号を取り出す。そして、顧客情報受信部２１６（２）を参照し、Ｂ氏の不在情報を届いていないかチェックする。
【０１４１】ここでは、図２０に示されたＢ氏の不在情報が届けられていたとする。顧客選択部２１７（２）は、現在の時刻とＢ氏の不在情報の時刻とを比較し、Ｂ氏の不在が発見された時刻から一定の時間が経過していない場合は、Ｂ氏は不在である確率が大きいと判断し、Ｂ氏への電話は後に回し、コールリスト２の次の顧客であるＹ氏の電話番号を取り出す。
【０１４２】このことにより、不在である確率の大きいＢ氏に電話をかけてから、一定時間内に応答がないことを確認し、Ｂ氏の不在を確認するまでの無駄な時間を省くことができる。」
（第２４，２５欄、段落１３３−１４２）
　
　甲第２号証に記載された発呼制御方法は、プレディクティブ発信（上記ア．段落１２５）しようとする顧客情報（発信データ）について現に発信すべきか否かを照会するにあたり、顧客の電話番号を取り出し、顧客情報受信部２１６（２）を参照する（上記イ．段落１３９，１４０）ものである。ここで、顧客情報受信部２１６（２）は、現に発信すべきでない顧客情報として、図２０に示されるような、「状況（例：不在）」「顧客名（例：Ｂ）」「電話番号（例：１１１−３３３３）」「時刻（例：○○時××分）」を受信するもの（上記イ．段落１３６、１３７）であって、このような受信を繰り返し、しかも、参照可能であることから、顧客情報受信部２１６（２）が有する顧客情報は、全体として“発信不要データベース”ということができる。
　そして、前記のように、顧客の電話番号を取り出し、顧客情報受信部２１６（２）を参照することが、具体的には、発信不要データベースに対して、電話番号をキーとして指定された条件（不在情報が届いたか否か（上記イ．段落１４０））で検索するものであることは、一般的なデータベースの参照方法に照らし明らかなことである。
　
　したがって、甲第２号証には次の発明（以下、「引用発明２」という。）が開示されていると認められる。
　
「発信データを発信不要データベースに照会して発信不要データであると判定するにあたり、電話番号をキーとして、発信不要データベースを指定された条件で検索する、プレディクティブ発信制御方法。」
　
（２）相違点１についての判断
　相違点１について再掲すると、プレディクティブ発信業務として自動的にダイヤルされる顧客の電話番号の選択元となる「プレディクティブ発信用のデータの集合」に関し、本件特許発明では、「所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後」の「該プレディクティブ発信用のデータベース」であるのに対し、引用発明１では「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」である点である。
　そして、相違点１について検討するに、
ａ．引用発明１の「所望の数の顧客アカウント情報」における「所望の数」は、所定の数を条件とすることであるから、「所定の条件」にほかならず、
ｂ．引用発明１の「所望の数の顧客アカウント情報」は、メインフレームコンピュータ（１６）内のデータベースからひき出されたものであるから、「抽出」されたものであり、
ｃ．引用発明１の「所望の数の顧客アカウント情報」は、「転送され」るものであるから、転送先において「作成」されたということができ、
ｄ．「プレディクティブ発信用のデータの集合」としての引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」を、「データベース」と称するのは適宜のことある、
　ことから、結局のところ、引用発明１の「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」は、本件特許発明の「所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」に含まれる。また、当該「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」（当該「プレディクティブ発信用データベース」）を用いて、プレディクティブ発信業務を行うのは当然だから、プレディクティブ発信用のデータベースを作成した「後」の「該プレディクティブ発信用データベース」から、自動ダイヤルされる顧客の電話番号を選択することも適宜のことである。
　したがって、引用発明１において、上記相違点１のごとく構成することに格別の困難性は認められない。
　
　仮に、上記相違点１に係る、本件特許発明の「プレディクティブ発信を行うデータを所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」が、多様な情報を管理する、顧客情報を管理している（マスタ）データベースから、業務目的（例：督促）にかなうように、所定の条件（例：滞納している者）で抽出して作成したデータベースであると仮定・解釈しても、引用発明１において、そのように仮定・解釈されたデータベースを備え、相違点１のごとく構成することは、当業者にとって困難なことではない。
　すなわち、一般に、コールセンタがプレディクティブ発信を行うにあたり、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いるか否かは、発信業務の目的と、元より存在する顧客データベースが内容としてどのような性質や規模の顧客情報を有していたかに応じて従属的に定まる設計的事項にすぎない（例えば、顧客データベースが、小規模であったり、既に発信業務の目的にかなうものであれば、所定の条件で抽出したプレディティブ発信用のデータベースを作成する必要もなく、逆にそうでなければ、作成の必要があるという程度のことである。）。さらに、本件特許の出願日より相当以前からコールセンタを利用したビジネスは拡大しており、顧客データベースやコールセンタの業務目的の多様性から、コールセンタがプレディクティブ発信業務を行う場合には、業務目的にかなうように、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いることが顕著であって、このことは甲第３号証の記載（第２０頁「（４）運用上，不可欠な機能…業務毎に、顧客リスト…を設定できる。」の記載、第２２頁「顧客データベース」「選択処理」「選択された顧客ファイル」「コーリングリストの作成」の記載。）からもうかがえる。また、本件特許明細書においても、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いること自体は従来技術であることを開示しているところである。
　このような事情に照らせば、引用発明１において、上記の仮定・解釈の意味での、「プレディクティブ発信を行うデータを所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」を備えるようにすることもなし得ることである。また、当該「プレディクティブ発信用データベース」を用いて、プレディクティブ発信業務を行うのは当然だから、プレディクティブ発信用のデータベースを作成した「後」の「該プレディクティブ発信用データベース」から、自動ダイヤルされる顧客の電話番号を選択することも適宜のことである。
　したがって、引用発明１において、上記のように仮定・解釈されたデータベースを備え、相違点１のごとく構成することは、当業者にとって困難なことではない。
　
（３）相違点２についての判断
　相違点２について再掲すると、発信データを指定されたデータベースに照会して発信不要データであると判定する具体的態様が、本件特許発明では、「電話番号又は他の顧客識別情報をキーとして」、指定されたデータベースを「指定された条件で検索する」ものであるのに対し、引用発明１では「メインフレームコンピュータ（１６）に該特定の顧客のアカウントの状態を問いあわせ」るものであるところ、引用発明１において、発信データを指定されたデータベースに照会して発信不要データであると判定する具体的態様として、引用発明２の態様を適用し、「電話番号をキーとして」、指定されたデータベース（メインフレームコンピュータ（１６）内のデータベース）を「指定された条件で検索する」ことに何らの困難はない。
　したがって、引用発明１に引用発明２を適用して、相違点２の如く構成することは、当業者が容易になし得たものである。
　
（４）無効理由２についてのまとめ
　本件特許発明は、上記のとおり、引用発明１及び引用発明２に基づいて、当業者が容易になし得たものである。すなわち、本件特許発明は、甲第１号証及び甲第２号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものであり、特許法第２９条第２項の規定に違反してなされたものである。
　したがって、無効理由２には理由がある。
　
第５　むすび
　以上のとおりであるから、本件特許発明は、特許法第２９条第２項の規定に違反してなされたものであるから、特許法第１２３条第１項第２号に該当し、無効とすべきものである。
　審判に関する費用については、特許法第１６９条第２項の規定で準用する民事訴訟法第６１条の規定により、被請求人が負担すべきものである。
　
　よって、結論のとおり審決する。