• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部無効 2項進歩性  H04M
審判 全部無効 1項3号刊行物記載  H04M
管理番号 1226116
審判番号 無効2009-800100  
総通号数 132 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-12-24 
種別 無効の審決 
審判請求日 2009-05-18 
確定日 2010-11-04 
事件の表示 上記当事者間の特許第3505460号発明「コールセンタシステム及びプレディクティブダイヤラ装置」の特許無効審判事件について、次のとおり審決する。 
結論 特許第3505460号の請求項1に係る発明についての特許を無効とする。 審判費用は、被請求人の負担とする。 
理由 第1 手続の経緯
本件に係る手続の概要は次のとおりである。

平成12年 2月17日 出願(特願2000-39989号)
平成15年12月19日 設定登録(特許第3505460号,
請求項の数[14])
平成21年 5月18日 無効審判請求書
平成21年 8月12日 答弁書(被請求人)
平成21年10月15日(差出日) 口頭審理陳述要領書(請求人)
平成21年10月15日 口頭審理陳述要領書(被請求人)
平成21年10月27日 口頭審理、審理終結(口頭で通知)

第2 本件特許発明
本件特許の請求項1に係る発明(以下、「本件特許発明」という。)は、設定登録時の明細書又は図面の記載からして、その特許請求の範囲の請求項1に記載された次のとおりのものと認める。

「顧客情報を管理しているデータベースからプレディクティブ発信を行うデータを所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後、該プレディクティブ発信用のデータベースで選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて、
顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
該プレディクティブ発信用のデータベースから抽出された発信データを、プレディクティブ発信時に、電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行うことを特徴とするコールセンタシステム。」

第3 当事者の主張
1 請求人の主張
請求人株式会社ベルシステム24は、本件特許発明についての特許を無効にする、審判費用は被請求人の負担とする、との審決を求め、その理由として次の無効理由1及び2を挙げ、本件特許は特許法第123条第1項第2号に該当するので無効とすべきであると主張している。また、証拠方法として甲第1?第3号証を提出している。

[無効理由1]
本件特許発明は、その出願前に頒布された刊行物である甲第1号証に記載された発明であるから、特許法第29条第1項第3号の規定に違反してなされたものである。

[無効理由2]
本件特許発明は、その出願前に頒布された刊行物である甲第1号証に記載された発明、あるいは、甲第1号証と甲第2号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものであるから、特許法第29条第2項の規定に違反してなされたものである。

[証拠方法]
甲第1号証 : 米国特許第4797911号明細書
甲第1号証の2: 甲第1号証の翻訳文
甲第2号証 : 特開平9-252351号公報
甲第3号証 : 三菱事務機械株式会社,“コストパフォーマンス抜群
のプレディクティブ・ダイヤリング・システム”,月
刊テレマーケティングジャーナル,アイビーシステム
株式会社発行,平成6年8月25日,1994年9月
号,Vol.7,No.9,pp19-22

2 被請求人の主張
被請求人JFEシステムズ株式会社は、答弁書において、本件審判の請求は成り立たない、審判費用は請求人の負担とする、との審決を求め、本件特許発明は、甲第1号証に記載された発明ではないから、特許法第29条第1項第3号の規定に違反してなされたものではなく、甲第1号証に記載された発明、あるいは、甲第1号証と甲第2号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものではないから、特許法第29条第2項の規定に違反してなされたものではなく、本件特許発明を無効とすべき理由は存在しない旨主張する。

第4 当審の判断
1 無効理由1についての判断
(1)甲第1号証に記載の発明
甲第1号証には、「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. 」
(フロントページ)
(仮訳:メインフレームコンピュータ(16)は、顧客又は潜在的顧客のアカウント情報、例えば顧客名、顧客電話番号、顧客アカウントコード、顧客注文状態等を含む。メインフレームコンピュータ(16)は、顧客アカウント情報群をシステム制御装置(11)にデータ制御装置(15)を介して送信する。システム制御装置(11)は幹線インタフェース部(10a?10d)に顧客の電話番号をダイヤルし、発信の状態を監視するよう命令する。)

イ.「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.」
(第1欄第12-20行)
(仮訳:多くのビジネス、特に、多数の顧客アカウントを有するビジネスは、定期的に顧客に電話でコンタクトして、最新のアカウント情報を得たり、顧客に期限経過勘定を督促したり、滞納勘定について集金したり、又は他の業務を行う。また、幾つかのビジネスは、以前に郵送したカタログ又は広告に応答して電話で行うセールス、或いは顧客に電話をする直接勧誘によるセールスに主に又はだけに基づいている。)

ウ.「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.」
(第1欄第38-44行)
(仮訳:従って、オペレータの時間をより有効に使用できるように、オペレータの介入なしに自動的に番号をダイヤルし、呼出しに応答があった場合だけオペレータを接続し、メインフレームにある顧客アカウント記録を表示する方法及び装置が必要とされている。)

エ.「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.」
(第3欄第48-65行)
(仮訳:この好適な実施形態は4つの幹線インタフェース部10a?10d、システム制御装置11、16幹線×10線・クロス点スイッチ13、データ制御装置15、メインフレームコンピュータ16、及び10個のオペレータ端末12a?12jを備える。16本の幹線T1?T16は集成幹線インタフェース部10とクロス点スイッチ13に接続される。各幹線インタフェース部10a?10dは4つの幹線を収容し、幹線インタフェース部10aは幹線T1?T4にサービスを提供し、幹線インタフェース部10bは幹線T5?T8にサービスを提供する(他同様)。各幹線インタフェース部10a?10dは次の機能:幹線占有、ダイヤリング、呼出し進行監視、メッセージ再生、及びメッセージ記録を実行する。下記に幹線インタフェース部10a?10dについてより詳細に説明する。スイッチ13はクロス点スイッチである必要はなく、別の同様な装置であってもよい。例えば、スイッチ13は、構内交換(PBX)スイッチ等の電話システム又はその一部であってもよい。)

オ.「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.」
(第5欄第13-31行)
(仮訳:ここで本実施形態の動作を考える。メインフレームコンピュータ16は、所望の数のアカウントの顧客アカウント情報をデータ制御装置15に一括転送又はオンライン転送により提供する。次にデータ制御装置15はこの情報をポートHPS1を介してシステム制御装置11に提供する。或いは、システム制御装置11はこの情報を直接メインフレーム16とそのディスクドライブシステムから得てもよい。次にシステム制御装置11はアカウント毎に顧客名、顧客電話番号、アカウント番号、及び/又はあるタイプのメインフレームデータベース指標番号を抽出する。幹線T1が使用可能であると仮定すると、システム制御装置11は、幹線インタフェース部10aに幹線T1を占有するよう命令し、顧客電話番号を幹線インタフェース部10aに提供し、幹線インタフェース部10aにこの顧客電話番号をダイヤルするよう命令する。幹線インタフェース部10aは顧客電話番号をダイヤルし、この呼出しの状態を求めて幹線T1を監視する。)

カ.「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.」
(第6欄第23-37行)
(仮訳:幹線T1を介して被呼者が応答した時、空いたオペレータが居ないと仮定する。幹線インタフェース部10aはメッセージ再生機を起動し、システム制御装置11に被呼者が応答したことを通知する。空いたオペレータが居ないことを確認後、システム制御装置11は幹線インタフェース部10aが被呼者へ予め記録された所望のメッセージの再生を続けることを許可する。システム制御装置11が空いたオペレータが居ると判断すると、システム制御装置11はクロス点スイッチ13に利用可能なオペレータ端末12を幹線T1に接続させ、幹線インタフェース部10aに、幹線T1を解放し、メッセージを停止し、次のメッセージに進み、短縮された顧客アカウント情報を該利用可能なオペレータ端末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.」
(第7欄第21-30行)
(仮訳:また、メインフレーム16の主データベース内の当該顧客アカウント情報を直ちに更新するので、オペレータが行った顧客アカウント情報への変更を各業務日の終わりに統合する必要がないこと、及び一日の任意の時点での顧客が電話をかけてくる、又は顧客を呼出した時、オペレータに提供される顧客のアカウント情報は最新の更新された顧客アカウント情報であるという利点があることが理解されるであろう。)

ク.「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.」
(第9欄第42行-第10欄第12行)
(仮訳:システム制御装置11により使用されるロジックのフローチャートである図4A及び図4Bを参照する。26からスタート後、第1ステップ27ではメインフレーム16から一括モード転送により複数の顧客のアカウント情報を得る。このアカウント情報はメインフレームデータベース指標番号又はキーを含んでもよい。或いは、システム制御装置11は複数のアカウントの短縮されたアカウント情報、例えば名前、電話番号、アカウント番号、及び/又は指標番号を得てもよい。一括モード転送が好ましいが、もし望むなら、システム制御装置11はメインフレーム16から1つの顧客アカウントに関する情報を得てもよい。次のステップ28では、オペレータの予想される空き状況に基づいて新しい呼出し(又は再呼出し)の必要性を計算する。空いたオペレータが居る場合、新しい呼出し(又は再呼出し)が必要となる。しかし、全てのオペレータが話中である場合、所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合とない場合がある。判定29は新しい呼出し(又は再呼出し)が必要かを調べる。もし否であれば、システム制御装置11はステップ28に戻る。もし必要であれば、システム制御装置11はステップ30に進み、呼出す次のアカウントの電話番号を抽出する。判定31は幾つかの要因に基づいて抽出した電話番号をダイヤルすることが許されるかを検査する。これらの要因は、通常相手が位置するタイムゾーン、該電話番号に以前電話をかけたか、以前かけた該電話番号は話し中であった/応答がなかった/使われていなかったか、該電話番号に最後にかけてからの経過時間、該アカウントは昼間/夜間/ある時間帯に呼出すべきかに関する情報、及び所望の優先度(より大きな勘定が優先)を含む。これらの要因に基づいてこの電話番号をダイヤルすることが許されない場合、システム制御装置11はステップ28に戻る。この電話番号をダイヤルすることが許される場合、システム制御装置11はステップ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.」
(第9欄第13-37行)
(仮訳:ステップ27でシステム制御装置11は一群の顧客アカウントのアカウント情報を得るので、その後の着信及び/又は請求に対する支払い及びクレジットにより、システム制御装置11に記憶されたアカウント情報は、発信待ちの列において特定の顧客アカウントの順番が来る時までに最新ではなくなる可能性がある。この問題を扱う幾つかの方法が存在する。1つの方法は、システム制御装置11はステップ27で一度に1つのアカウントだけのアカウント情報を得ることである。別の方法は、メインフレーム16に情報が入力されるたびに、メインフレーム16が当該アカウントに関する更新された情報をシステム制御装置11に送信することである。本実施形態で使用する方法は、アカウントに電話をかける前に、システム制御装置11がメインフレーム16に該アカウントの状態を問合せることである。これに応答して、メインフレーム16は該アカウントの状態に変化があったか否かと、変化があった場合、どんな状態変化が発生したかをシステム制御装置11に通知する。状態に変化がなかった場合、又は変化が該特定のアカウントに電話をかける必要性に影響しない場合、システム制御装置11はステップ32に進む。該アカウントに電話をかけることがもはや適当でない場合、システム制御装置11はステップ28に戻る。)

甲第1号証に記載された顧客オンラインサービスシステムは、顧客アカウント情報を管理するためのデータベースを有したメインフレームコンピュータ(16)があって(上記キ.)、所望の数の顧客アカウント情報をメインフレームコンピュータ(16)からシステム制御装置(11)へ転送するものである(上記オ.及びク.)。
上記オ.及びク.の記載、並びに図4A及び図4Bで示されたシステム制御装置(11)のフローチャートでの、「EXTRACT TEL.NO. FOR AN ACCOUNT FROM ACCOUNT INFORMATION BATCH」(仮訳:アカウント情報バッチから、あるアカウントの電話番号を抽出する)、「SEND TEL.# TO DIALER CONNECTED TO AVAIL. TRUNK」(仮訳:利用可能なトランクに接続されたダイヤラーに電話番号を送る。)という一連の処理の記載から、顧客オンラインサービスシステムは、転送された所望の数の顧客のアカウント情報から、顧客の電話番号を自動的に選択してダイヤル発信する処理をするといえるものである。
また、ダイヤル発信の態様は、
・「従って、オペレータの時間をより有効に使用できるように、オペレータの介入なしに自動的に番号をダイヤルし、呼出しに応答があった場合だけオペレータを接続し、…」(上記ウ.)
・「…オペレータの予想される空き状況に基づいて新しい呼出し(又は再呼出し)…しかし、全てのオペレータが話中である場合、所定の時間内にオペレータが空く統計的確率に基づいて新しい呼出しが必要である場合…」(上記ク.)
とあるから、予想を取り入れた発信を行い、相手がでたときにだけオペレータにつなぐものであって、これは、例えば、甲第3号証や、“「NTT技術ジャーナル」にみる最新情報通信用語集”,初版第3刷,社団法人電気通信協会発行,平成10年5月10日,p593にも例示される、典型的な「プレディクティブ」発信である。
この点について、被請求人は、答弁書において、第12頁第13行「甲第1号証の方法、すなわち個々のプレディティブ発信の都度…」、同頁第19行「甲第1号証において顧客への発信(プレディクティブ発信)処理は、…」と答弁しており、甲第1号証のダイヤル発信の態様はプレディクティブ発信であることを事実上認めている。
そして、上記ケ.では、特定の顧客のアカウントについて、着信、請求に対する支払いがあったため、特定の顧客に発信することがもはや適当でない場合があることが示されており、この場合の特定の顧客のアカウント情報をデータとしてみれば、“発信不要データ”が発生したといえる。そして、発信防止策として、「システム制御装置11がメインフレーム16に該アカウントの状態を問合せ…これに応答して、メインフレーム16は該アカウントの状態に変化があったか否かと、変化があった場合、どんな状態変化が発生したかをシステム制御装置11に通知する。…該アカウントに電話をかけることがもはや適当でない場合、」とあるから、特定の顧客のアカウントの状態を問いあわせ、特定の顧客のアカウント情報がデータとして“発信不要データ”であるか否かを判定するものといえるものである。
そして、“発信不要データ”であると判定された場合には、「該アカウントに電話をかけることがもはや適当でない場合、システム制御装置11はステップ28に戻る。」と示されており、そのステップ28とは、(次の)新しい発信の必要性を計算する(上記ク.)というものである。

以上のことから、甲第1号証には次の発明(以下、「引用発明1」という。)が開示されていると認められる。

「顧客のアカウント情報を管理しているデータベース(メインフレームコンピュータ(16)内)からプレディクティブ発信を行う所望の数の顧客アカウント情報が転送され、所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っている顧客オンラインサービスシステムにおいて、
特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する(ステップ28)顧客オンラインサービスシステム。」

(2)対比
本件特許発明と引用発明1とを対比する。

a.引用発明1の「顧客のアカウント情報」は、「顧客情報」である。

b.上記a.を考慮すると、引用発明1の「顧客のアカウント情報を管理しているデータベース(メインフレームコンピュータ(16)内)」は、本件特許発明の「顧客情報を管理しているデータベース」に相当する。

c.引用発明1の「プレディクティブ発信を行う所望の数の顧客アカウント情報が転送され、所望の数の顧客アカウント情報から選択された顧客の電話番号を自動的にダイヤルして発信する」と、本件特許発明の「プレディクティブ発信を行うデータを所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後、該プレディクティブ発信用のデータベースで選択された顧客の電話番号を自動的にダイヤルして発信する」とを対比すると、引用発明1の「転送され」た「所望の数の顧客アカウント情報」も、本件特許発明の「プレディクティブ発信用のデータベース」も、“プレディクティブ発信用のデータの集合”であることに変わりはないから、両者は「プレディクティブ発信用のデータの集合を得て、該プレディクティブ発信用のデータの集合で選択された顧客の電話番号を自動的にダイヤルして発信する」点で共通する。

d.引用発明1の「顧客オンラインサービスシステム」は、コールセンタとしての機能を提供するものであるから、本件特許発明の「コールセンタシステム」と実質的に同じものである。

e.引用発明1の「特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい」については、例えば、顧客オンラインサービスシステムが、上記「(1)甲第1号証に記載の発明」の項の摘記イ.の「期限経過勘定の督促」業務で用いられる場合には、既に特定の顧客が借金を窓口(その他の事務部門)で直接返済しており(コンタクトしており)、もはや発信して督促すべきでないことが、一事例として自明であり、これは、本件特許発明における「その他の事務部門における該顧客からのコンタクト」により、「プレディクティブ発信を行わなくてもよい」事例に該当する。
また、上記「(1)甲第1号証に記載の発明」の項の摘記イ.の「セールス」業務で用いられる場合には、既に顧客からの電話(インバウンド業務)でセールス対象品を受注しており、もはや発信して勧誘しなくてもよいことが、一事例として自明であり、これは、本件特許発明における「顧客から着信する通話によるインバウンド業務」により、「プレディクティブ発信を行わなくてもよい」事例に該当する。
よって、本件特許発明の「顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい」(以下、「構成A」という。)と、引用発明1の「特定の顧客からの着信、請求に対する支払いにより、プレディクティブ発信を行わなくてもよい」(以下、「構成B」という。)とを対比すると、構成Aが択一的記載であり、選択肢のうち二つが、上記のように、構成Bにより充足されるものである。そして、構成Aの選択肢の少なくとも一つが構成Bにより充足されれば、他の選択肢に関係なく、構成Bは構成Aに含まれるという意味において、構成Bは構成Aに相当する。

f.
(ア)引用発明1の「メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ」ることとは、具体的には、引用発明1の「データベース(メインフレームコンピュータ(16)内)」に対して、その状態を照会することであるのは自明である。そして、「検索」は「照会」の態様であること、上記c.をも考慮すれば、引用発明1の「メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ」ることと、本件特許発明の「プレディクティブ発信用のデータベースから抽出された発信データを、」「電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索すること」とは、「プレディクティブ発信用のデータの集合から抽出された発信データを、指定されたデータベースに照会すること」で共通する。

(イ)引用発明1の「新しい発信の必要性を計算する(ステップ28)」では、新しい(次の顧客への)発信を計算する時点で、特定の顧客への発信(call.コール)はもはや行われないことが確定し、その発信は発信前に即時、すなわち実時間(リアルタイム)で止められたと解せるから、本件特許発明の「その発信を中止するリアルタイムコール止めを行う」に相当する。

(ウ)引用発明1の「メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する(ステップ28)」処理は、一連のプレディクティブ発信処理の一部をなすものであって、「プレディクティブ発信時」での処理といえる。

(エ)したがって、上記(ア)?(ウ)からして、引用発明1の「メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ、該発信不要データであると判定された場合には、新しい発信の必要性を計算する(ステップ28)」と、本件特許発明の「該プレディクティブ発信用のデータベースから抽出された発信データを、プレディクティブ発信時に、電話番号又は他の顧客識別情報をキーとして、指定されたデータベースを指定された条件で検索することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行う」とは、「該プレディクティブ発信用のデータの集合から抽出された発信データを、プレディクティブ発信時に、指定されたデータベースに照会することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行う」点で共通する。

したがって、引用発明1と本件特許発明とは、次の点で一致する。

(一致点)
「顧客情報を管理しているデータベースからプレディクティブ発信用のデータの集合を得て、該プレディクティブ発信用のデータの集合で選択された顧客の電話番号を自動的にダイヤルして発信するプレディクティブ発信業務を行っているコールセンタシステムにおいて、
顧客から着信する通話によるインバウンド業務、インターネット、電子メール、又はその他の事務部門における該顧客からのコンタクトにより、プレディクティブ発信を行わなくてもよい発信不要データが発生した場合に、
該プレディクティブ発信用のデータの集合から抽出された発信データを、プレディクティブ発信時に、指定されたデータベースに照会することにより、該発信不要データであると判定された場合には、その発信を中止するリアルタイムコール止めを行うコールセンタシステム。」

一方で、両者は、次の点で相違する。

(相違点1)
プレディクティブ発信業務として自動的にダイヤルされる顧客の電話番号の選択元となる「プレディクティブ発信用のデータの集合」に関し、本件特許発明では、「所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後」の「該プレディクティブ発信用のデータベース」であるのに対し、引用発明1では「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」である点。
(相違点2)
発信データを指定されたデータベースに「照会」することにより発信不要データであると判定する具体的態様は、本件特許発明では、「電話番号又は他の顧客識別情報をキーとして」、指定されたデータベースを「指定された条件で検索する」ものであるのに対し、引用発明1では、メインフレームコンピュータ(16)に「該特定の顧客のアカウントの状態を問いあわせ」るものである点。

(3)無効理由1についてのまとめ
本件特許発明と引用発明1とは、上記のとおり、相違点1及び2において相違するものであるから、本件特許発明は甲第1号証に記載された発明であるとはいえない。
以上のとおりであるから、無効理由1には理由がない。

2 無効理由2についての判断
「1 無効理由1についての判断」に続き、本項においては、甲第2号証に記載の発明を認定し、次いで、相違点1及び相違点2について判断する。最後に、無効理由2に理由があるか否かについてまとめる。

(1)甲第2号証に記載の発明
甲第2号証には、「発呼制御方法」として、図面とともに次の記載がある。

ア.「【0123】(実施形態3)次に、実施形態3について説明する。本実施形態の各コールセンター・システム(アウトバウンド業務処理システム)の構成は、基本的には図17と同様である。
【0124】すなわち、図17のように、オペレータ(図中303)一人あたり1台の端末304と電話機305が設置され、各端末304はホストコンピュータ201に接続されている。また、各電話機305は交換機306を経由して外線と接続される。
【0125】最も初歩的なシステムでは、コールリスト211に従って端末304に顧客の電話番号が表示され、オペレータが自身で電話をダイヤル操作して発呼を行う。ホストコンピュータ201と交換機306が連動している初歩的なシステムでは、端末304からの指示により交換機306経由で(コールリスト211に従って)自動的に電話が発信され、電話機305に接続される。また、パワーダイヤリングやプレディクティブ・ダイヤリングを行うシステムでは、交換機306はホストコンピュータ201と接続され、コールリスト211に従って適宜自動発呼される。本発明は、上記のどのシステムにも適用可能である。」
(第22、23欄、段落123-125)

イ.「【0133】図18に示す形態での2つのコールセンターで、コールセンター1からコールセンター2に顧客の不在情報が通知される例を用いる。コールセンター1におけるコールリスト1(211(1))は、図19で示される内容であるとする。この場合、コールセンター1では、以下の手順で電話をかける。
【0134】顧客選択部212(1)は、コールリスト1の最初の顧客A氏の電話番号を取り出し、A氏に電話をかける。A氏とは電話が繋がり、テレマーケティングが行われたとする。なお、この時点ではA氏に関する不在等の情報はないものとする。
【0135】次に、顧客選択部212(1)は、コールリスト1の次の顧客B氏の電話番号を取り出し、B氏に電話をかける。ここで、B氏は不在であったとする。この場合、不在か否かは、実際にB氏の電話番号に電話をかけ、一定時間内に応答があるか否かでB氏の不在を判断するので、B氏に電話をかけてからB氏の不在を確認するまでの時間は無駄な時間となる。
【0136】B氏の不在を確認すると、顧客情報通知部215(1)は、B氏が不在である旨の情報をコールセンター2に通知する。その際、送られるデータの例を図20に示す。この場合は、B氏が不在である情報、B氏の不在を発見した時刻、B氏の電話番号が送られる。
【0137】コールセンター2の顧客情報受信部216(2)は、図20に示されたデータを受け取る。なお、B氏が不在であることおよびこれを検出した時刻等の情報は、自身の顧客情報受信部216(1)に格納するか、あるいはコールリスト1中にフィールドを設けて記録しておく。
【0138】次に、同時にテレマーケティング業務を行っているコールセンター2での手順を以下に述べる。コールセンター2におけるコールリスト2(211(2))は、図21で示される内容であるとする。
【0139】顧客選択部217(2)は、コールリスト2の最初の顧客X氏の電話番号を取り出し、X氏を発呼する候補とする。この際、顧客情報受信部216(2)を参照し、X氏の不在情報が届いていないかチェックする。なお、自身で検出したある顧客の不在等の情報をコールリスト中に記録しておく場合、コールリスト2中のX氏の不在情報の欄もチェックする。
【0140】この場合は、X氏の不在情報は届いていないので、X氏に電話をかけ、X氏とは電話がつながり、テレマーケティングが行われたとする。次に、顧客選択部217(2)は、コールリスト2の次の顧客B氏の電話番号を取り出す。そして、顧客情報受信部216(2)を参照し、B氏の不在情報を届いていないかチェックする。
【0141】ここでは、図20に示されたB氏の不在情報が届けられていたとする。顧客選択部217(2)は、現在の時刻とB氏の不在情報の時刻とを比較し、B氏の不在が発見された時刻から一定の時間が経過していない場合は、B氏は不在である確率が大きいと判断し、B氏への電話は後に回し、コールリスト2の次の顧客であるY氏の電話番号を取り出す。
【0142】このことにより、不在である確率の大きいB氏に電話をかけてから、一定時間内に応答がないことを確認し、B氏の不在を確認するまでの無駄な時間を省くことができる。」
(第24,25欄、段落133-142)

甲第2号証に記載された発呼制御方法は、プレディクティブ発信(上記ア.段落125)しようとする顧客情報(発信データ)について現に発信すべきか否かを照会するにあたり、顧客の電話番号を取り出し、顧客情報受信部216(2)を参照する(上記イ.段落139,140)ものである。ここで、顧客情報受信部216(2)は、現に発信すべきでない顧客情報として、図20に示されるような、「状況(例:不在)」「顧客名(例:B)」「電話番号(例:111-3333)」「時刻(例:○○時××分)」を受信するもの(上記イ.段落136、137)であって、このような受信を繰り返し、しかも、参照可能であることから、顧客情報受信部216(2)が有する顧客情報は、全体として“発信不要データベース”ということができる。
そして、前記のように、顧客の電話番号を取り出し、顧客情報受信部216(2)を参照することが、具体的には、発信不要データベースに対して、電話番号をキーとして指定された条件(不在情報が届いたか否か(上記イ.段落140))で検索するものであることは、一般的なデータベースの参照方法に照らし明らかなことである。

したがって、甲第2号証には次の発明(以下、「引用発明2」という。)が開示されていると認められる。

「発信データを発信不要データベースに照会して発信不要データであると判定するにあたり、電話番号をキーとして、発信不要データベースを指定された条件で検索する、プレディクティブ発信制御方法。」

(2)相違点1についての判断
相違点1について再掲すると、プレディクティブ発信業務として自動的にダイヤルされる顧客の電話番号の選択元となる「プレディクティブ発信用のデータの集合」に関し、本件特許発明では、「所定の条件で抽出して、プレディクティブ発信用のデータベースを作成した後」の「該プレディクティブ発信用のデータベース」であるのに対し、引用発明1では「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」である点である。
そして、相違点1について検討するに、
a.引用発明1の「所望の数の顧客アカウント情報」における「所望の数」は、所定の数を条件とすることであるから、「所定の条件」にほかならず、
b.引用発明1の「所望の数の顧客アカウント情報」は、メインフレームコンピュータ(16)内のデータベースからひき出されたものであるから、「抽出」されたものであり、
c.引用発明1の「所望の数の顧客アカウント情報」は、「転送され」るものであるから、転送先において「作成」されたということができ、
d.「プレディクティブ発信用のデータの集合」としての引用発明1の「転送されたプレディクティブ発信を行う所望の数の顧客のアカウント情報」を、「データベース」と称するのは適宜のことある、
ことから、結局のところ、引用発明1の「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」は、本件特許発明の「所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」に含まれる。また、当該「転送されたプレディクティブ発信を行う所望の数の顧客アカウント情報」(当該「プレディクティブ発信用データベース」)を用いて、プレディクティブ発信業務を行うのは当然だから、プレディクティブ発信用のデータベースを作成した「後」の「該プレディクティブ発信用データベース」から、自動ダイヤルされる顧客の電話番号を選択することも適宜のことである。
したがって、引用発明1において、上記相違点1のごとく構成することに格別の困難性は認められない。

仮に、上記相違点1に係る、本件特許発明の「プレディクティブ発信を行うデータを所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」が、多様な情報を管理する、顧客情報を管理している(マスタ)データベースから、業務目的(例:督促)にかなうように、所定の条件(例:滞納している者)で抽出して作成したデータベースであると仮定・解釈しても、引用発明1において、そのように仮定・解釈されたデータベースを備え、相違点1のごとく構成することは、当業者にとって困難なことではない。
すなわち、一般に、コールセンタがプレディクティブ発信を行うにあたり、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いるか否かは、発信業務の目的と、元より存在する顧客データベースが内容としてどのような性質や規模の顧客情報を有していたかに応じて従属的に定まる設計的事項にすぎない(例えば、顧客データベースが、小規模であったり、既に発信業務の目的にかなうものであれば、所定の条件で抽出したプレディティブ発信用のデータベースを作成する必要もなく、逆にそうでなければ、作成の必要があるという程度のことである。)。さらに、本件特許の出願日より相当以前からコールセンタを利用したビジネスは拡大しており、顧客データベースやコールセンタの業務目的の多様性から、コールセンタがプレディクティブ発信業務を行う場合には、業務目的にかなうように、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いることが顕著であって、このことは甲第3号証の記載(第20頁「(4)運用上,不可欠な機能…業務毎に、顧客リスト…を設定できる。」の記載、第22頁「顧客データベース」「選択処理」「選択された顧客ファイル」「コーリングリストの作成」の記載。)からもうかがえる。また、本件特許明細書においても、所定の条件で抽出して作成したプレディクティブ発信用のデータベースを用いること自体は従来技術であることを開示しているところである。
このような事情に照らせば、引用発明1において、上記の仮定・解釈の意味での、「プレディクティブ発信を行うデータを所定の条件で抽出して」「作成した」「プレディクティブ発信用のデータベース」を備えるようにすることもなし得ることである。また、当該「プレディクティブ発信用データベース」を用いて、プレディクティブ発信業務を行うのは当然だから、プレディクティブ発信用のデータベースを作成した「後」の「該プレディクティブ発信用データベース」から、自動ダイヤルされる顧客の電話番号を選択することも適宜のことである。
したがって、引用発明1において、上記のように仮定・解釈されたデータベースを備え、相違点1のごとく構成することは、当業者にとって困難なことではない。

(3)相違点2についての判断
相違点2について再掲すると、発信データを指定されたデータベースに照会して発信不要データであると判定する具体的態様が、本件特許発明では、「電話番号又は他の顧客識別情報をキーとして」、指定されたデータベースを「指定された条件で検索する」ものであるのに対し、引用発明1では「メインフレームコンピュータ(16)に該特定の顧客のアカウントの状態を問いあわせ」るものであるところ、引用発明1において、発信データを指定されたデータベースに照会して発信不要データであると判定する具体的態様として、引用発明2の態様を適用し、「電話番号をキーとして」、指定されたデータベース(メインフレームコンピュータ(16)内のデータベース)を「指定された条件で検索する」ことに何らの困難はない。
したがって、引用発明1に引用発明2を適用して、相違点2の如く構成することは、当業者が容易になし得たものである。

(4)無効理由2についてのまとめ
本件特許発明は、上記のとおり、引用発明1及び引用発明2に基づいて、当業者が容易になし得たものである。すなわち、本件特許発明は、甲第1号証及び甲第2号証に記載された発明に基づいて、当業者が容易にその発明をすることができたものであり、特許法第29条第2項の規定に違反してなされたものである。
したがって、無効理由2には理由がある。

第5 むすび
以上のとおりであるから、本件特許発明は、特許法第29条第2項の規定に違反してなされたものであるから、特許法第123条第1項第2号に該当し、無効とすべきものである。
審判に関する費用については、特許法第169条第2項の規定で準用する民事訴訟法第61条の規定により、被請求人が負担すべきものである。

よって、結論のとおり審決する。
 
審決日 2009-11-30 
出願番号 特願2000-39989(P2000-39989)
審決分類 P 1 113・ 113- Z (H04M)
P 1 113・ 121- Z (H04M)
最終処分 成立  
前審関与審査官 大塚 良平冨田 高史  
特許庁審判長 山本 春樹
特許庁審判官 石井 研一
柳下 勝幸
登録日 2003-12-19 
登録番号 特許第3505460号(P3505460)
発明の名称 コールセンタシステム及びプレディクティブダイヤラ装置  
代理人 一色国際特許業務法人  
代理人 飯塚 卓也  
代理人 牧野 剛博  
代理人 三好 豊  
代理人 野口 明男  
代理人 高矢 諭  
代理人 松山 圭佑  

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