【事件の表示】
　特願２００５−２８６３０３「コンピュータと電話の統合」拒絶査定不服審判事件〔平成１８年　４月２０日出願公開、特開２００６−１０９４７１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１７年９月３０日（パリ条約による優先権主張　２００４年９月３０日　（ＵＳ）アメリカ合衆国）の出願であって、平成２０年４月１７日付けで手続補正がなされ、同年１０月１７日付けの最後の拒絶の理由の通知に対して、平成２１年４月２２日付けで手続補正がなされたが、同年１１月２日付けで補正の却下の決定がされると共に、同日付けで拒絶査定がされ、これに対し平成２２年３月１０日に拒絶査定に対する審判請求がされると共に、同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成２２年３月１０日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正は、平成２０年４月１７日付け手続補正書の特許請求の範囲の請求項１７に記載された、
　「データ処理システムにて（ｉ）コール、および（ｉｉ）該コールの起呼側を識別する第１のデータを受信するステップと、
　（ｉ）該第１のデータに基づく、および（ｉｉ）コンピュータ・ファイル・アドレスを識別する第２のデータを、セッション開始プロトコルメッセージ内に埋め込むステップと、
　該コールを、コールの宛先に転送するステップであって、該コールの転送が該セッション開始プロトコルメッセージを該コールの宛先に送信する処理から成るステップと、を含む方法。」
という発明（以下、「本願発明」という。）を、
　「データ処理システムにて（ｉ）音声コール、および（ｉｉ）該音声コールの起呼側を識別する第１のデータを受信するステップと、
　（１）該第１のデータに基づく、および（ｉｉ）該起呼側についての顧客関連情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレスを識別する第２のデータを、セッション開始プロトコルメッセージ内に埋め込むステップと
　該音声コールをコールの宛先にコール転送するステップであって、該音声コールのコール転送が該セッション開始プロトコルメッセージを該コールの宛先に送信する処理から成り、該顧客関連情報を指し示す該コンピュータ・ファイル・アドレスが該コール転送それ自身に埋め込まれているステップと、を含む方法。」
という発明（以下、「補正後の発明」という。）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、「コール」、「転送」をそれぞれ「音声コール」、「コール転送」と限定し、「コンピュータ・ファイル・アドレス」を「該起呼側についての顧客関連情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレス」と限定し、「コールを、コールの宛先に転送するステップ」について、「該コールの転送が該セッション開始プロトコルメッセージを該コールの宛先に送信する処理から成る」ところ、さらに「該顧客関連情報を指し示す該コンピュータ・ファイル・アドレスが該コール転送それ自身に埋め込まれている」と限定して、特許請求の範囲を減縮するものである。
　よって上記補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び第１７条の２第４項第２号（補正の目的、特許請求の範囲の減縮）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものと認められるから、上記補正後の発明が特許出願の際、独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
（２）引用発明
Ａ．原審の拒絶の理由に引用された特開２００２−５７８０１号公報（以下、「引用例１」という。）には、図面と共に以下の事項イ．〜ニ．が記載されている。
　
イ．「【００１２】コールセンタ３では、内部ネットワーク１１に、ＣＴＩ（computer telephonyintegration）サーバ１３、データベース（ＤＢ）サーバ１４、アプリケーションサーバ１５、ルータ１６及び内部用オペレータ１７が接続されている。交換機（ＰＢＸ）１２は、公衆回線２とＣＴＩサーバ１３の間に接続され、公衆回線２を介して顧客の電話機１からの電話の呼を受け付ける。
【００１３】ＣＴＩサーバ１３は、顧客又は顧客の要求に応じて、内部ネットワーク１１に接続された内部オペレータ用ＰＣ１７若しくは外部ネットワーク４に接続された外部オペレータ用ＰＣ５に対して又は外部ネットワーク４に接続された複数の外部オペレータ用ＰＣ５ａ，５ｂ，５ｃのうちのいずれかに対して、交換機１２に入力された呼に対応する顧客の電話機１との通信が行えるように接続を制御する。例えば、顧客の問い合わせの内容に応じて、その内容の知識を持ったオペレータに顧客の電話機１が自動的に接続される。
【００１４】データベースサーバ１４は、後に説明するデータベースを有する。ＣＴＩサーバ１３は、データベースサーバ１４内のデータベースに応じて、適したオペレータのＰＣ１７又は５に接続する。その際、ＣＴＩサーバ１３は、交換機１２に入力された電話機１からの電話の音声信号を、内部ネットワーク１１で通信可能なデジタル形式のＨ．３２３規格の信号に変換する。ＣＴＩサーバ１３が内部オペレータ用ＰＣ１７に接続すると、内部ネットワーク１１上の音声信号は内部オペレータ用ＰＣに送信され、内部オペレータが顧客に対応することができる。」（段落００１２〜００１４）
　
ロ．「【００２２】図３は、本実施形態によるコールセンタシステムの処理を示すフローチャートである。ステップＳＡ１では、ＣＴＩサーバ１３が顧客からの電話の着信待ちの状態にある。顧客の電話機１からコールセンタ３に電話の呼があると、ステップＳＡ２でＣＴＩサーバ１３はその呼を着信する。
【００２３】ステップＳＡ３では、ＣＴＩサーバ１３が自動音声ガイダンスにより顧客の電話に応答する。顧客は、その音声ガイダンスに従い、電話機１のプッシュボタンを押す。ＣＴＩサーバ１３は、そのプッシュボタンの信号を受信して顧客の問い合わせ内容を判別する。具体的には、データベースサーバ１４内の図４に示すテーブルに応じて、内容判別を行う。」（段落００２２〜００２３）
　
ハ．「【００４９】ステップＳＣ１では、ＣＴＩサーバが発信者番号及び自動音声応答等で得た顧客情報とオペレータの状況よりオペレータを選出する。ステップＳＣ２では、ＣＴＩサーバがオペレータＡのＰＣに発信顧客情報等を送信し、顧客の電話機とオペレータＡのＰＣとの回線を接続する。
【００５０】ステップＳＢ１では、オペレータＡのＰＣの画面に顧客情報を表示し、顧客の音声信号を再生する。オペレータＡは、顧客の問い合わせに応答し、図１２に示した画面に入力する。」（段落００４９〜００５０）
　
ニ．「【００５７】図１４は、エスカレーション処理の具体例を示すフローチャートである。ステップＳＥ１では、発信者番号を取得する。発信者番号を取得できた場合は、その発信者番号から顧客データベース（図５）及び履歴データベース（図６）を検索し、問い合わせが前回からの継続であるか否かを判断する。継続の場合には、後に説明する図１５のフローチャートの処理を行う。継続でない場合には、以下の処理を行う。
【００５８】ステップＳＥ２では、図４に示したテーブルに従い、音声ガイダンスを行う。例えば、「こちらは、○○サポートサービスです。プリンタに関するお問い合わせは１、ファックスに関するお問い合わせは２、コピーに関するお問い合わせは３を押して下さい。」との音声を流す。例えば、顧客が「１」のプッシュボタンを押したとする。
【００５９】続いて、図４のテーブルに従い、音声ガイダンスとして、「新製品情報に関するお問い合わせは１、故障や不具合に関する問い合わせは２、最新ドライバの入手に関するお問い合わせは３を押して下さい。」との音声を流す。例えば、顧客が「２」のプッシュボタンを押したとする。
【００６０】続いて、図４のテーブルに従い、音声ガイダンスとして、「プリンタの種類がレーザプリンタでしたら１、インクジェットプリンタでしたら２を押して下さい。」との音声を流す。例えば、顧客が「１」のプッシュボタンを押したとする。続いて、「オペレータに接続します。」との音声が流れる。
【００６１】ステップＳＥ３では、オペレータの１回目の選択を行う。顧客は、上記の操作で、「１」、「２」、「１」の順番でプッシュボタンを押しているので、図４のテーブルを参照して、オペレータグループ１−２−１Ｇを選択する。図１０のグループ所属テーブルを参照すると、オペレータグループ１−２−１Ｇに所属してるオペレータはオペレータＡ及びＪであることがわかり、その中で通話可能なオペレータを探す。
【００６２】さらに、図９のデータベースを参照して、通話可能なオペレータの中からその時点で累計応答時間が少ないオペレータを選択する。例えば、オペレータＡを選択する。
【００６３】次に、顧客の発信者番号から検索された顧客データベース（図５）や履歴データベース（図６）や顧客アセットデータベース（図７）の情報と、音声ガイダンスで入力された情報とを、オペレータＡのＰＣに送信し、顧客の電話をオペレータＡのＰＣに接続する。」（段落００５７〜００６３）
　
　上記摘記事項イ．〜ニ．の記載及び図面によれば、引用例１は、コールセンタにおいて呼を処理する方法に関するものである。
　引用例１の段落０００９〜００７６に記載されている第１の実施形態について見ると、まず上記摘記事項ロ．の段落００２２には「顧客の電話機１からコールセンタ３に電話の呼があると、ステップＳＡ２でＣＴＩサーバ１３はその呼を着信する。」と記載されており、ＣＴＩサーバにて電話の呼を着信するとされている。ここで、段落００２３の記載や、上記摘記事項ハ．の段落００５０の記載等によれば、電話機１を使用する顧客は音声で通信することがわかり、また、「着信」は「受信」と言い換えることもできることからすれば、「ＣＴＩサーバにて音声の呼を受信する」ようにされているということができる。
　また、上記摘記事項ニ．の段落００５７乃至００６１には「ステップＳＥ１では、発信者番号を取得する。発信者番号を取得できた場合は、その発信者番号から顧客データベース（図５）及び履歴データベース（図６）を検索し、問い合わせが前回からの継続であるか否かを判断する。…ステップＳＥ３では、オペレータの１回目の選択を行う。」という記載があるが、その動作主体については明記されていないところ、この記載がエスカレーション処理（図１３の処理）の具体例を示すものであって、その説明として上記摘記事項ハ．の段落００４９には「ＣＴＩサーバが発信者番号及び自動音声応答等で得た顧客情報とオペレータの状況よりオペレータを選出する。」と記載されていることと、上記したようにＣＴＩサーバがまず呼を受信していることとを併せて考えれば、呼を受信したＣＴＩサーバが、各データベースを検索して情報を得るために発信者番号を取得していることは明らかであり、取得のために受信をしていることも自明である。
　また、同様に、上記摘記事項ハ．の記載及び上記摘記事項ニ．の記載を併せて考えれば、ＣＴＩサーバが、発信者番号に基づく顧客情報を得て、選択したオペレータに呼を接続すると共に、顧客情報を送信することが開示されているといえる。ここで、「顧客情報」は「起呼側についての」情報であることや、呼を受信（着信）したＣＴＩサーバが選択したオペレータに呼を接続することを「転送する」と言い換えられることは、技術常識から明らかである。
　さらに、上記摘記事項イ．の段落００１４によれば、ＣＴＩサーバはＨ．３２３規格により通信を行うものであることも分かる。
　
　したがって、これらの記載事項によると、引用例１には以下の発明（以下「引用発明１」という。）が記載されていると認められる。
　
　「Ｈ．３２３規格により通信を行うＣＴＩサーバにて（ｉ）音声の呼、および（ｉｉ）発信者番号を受信するステップと、
　該発信者番号に基づく起呼側についての顧客情報を得るステップと
　該音声の呼を呼の宛先に転送するステップであって、該音声の呼の転送と共に顧客情報を送信するステップと、を含む方法。」
　
Ｂ．原審の拒絶の理由に引用された特開２００２−２１８０６３号公報（以下、「引用例２」という。）には、図面と共に以下の事項ホ．〜ヘ．が記載されている。
　
ホ．「【０００１】
【発明の属する技術分野】本発明は、電気通信システムに関し、特に、発呼者に関する情報を被呼者に配信するための、電気通信システム内の設備（ファシリティ）に関する。」（段落０００１）
　
ヘ．「【００２６】コンピュータのような他のデバイスの場合、交換機１２２は、ＴＣＰ／ＩＰリンクやその他の適当な大容量リンクを介して、発呼者プロファイルデータを送信することが可能である。一部のアプリケーションでは、特に発呼者プロファイルが大量であり、加入者端末がこのような大量の情報を表示することが可能である場合、交換機１２２は、実際の発呼者プロファイル情報に対するポインタまたはロケータのみを配信することが好ましいことがある。その場合、実際の発呼者プロファイル情報は、ＣＰＤＳ／ＳＣＰ１１０とは別のサーバに格納され、それによって配信されることも可能である。
【００２７】例えば、交換機１２２は、被呼者がアクセス可能なウェブサーバに格納された、加入者の発呼者プロファイル情報を指示するＵＲＬ（またはその他のポインタあるいはロケータ）を、適当な端末に配信する。その場合、ＵＲＬはＣＰＤＳ／ＳＣＰ１１０に格納される一方、発呼者プロファイル情報は、ＣＰＡＳ１１２のような（インターネット上の、または、私設ネットワーク上の）電気通信サービスプロバイダによって運用されるウェブサーバ上に、または、他のプロバイダや発呼者によって運用されるウェブサーバ上に格納されることが可能である。加入者端末１２４は、好ましくは、自動的に、または、端末ユーザの要求あるいは許可に応じて、交換機１２２によって供給されるＵＲＬにある発呼者プロファイルウェブページをフェッチし表示するように適応される。被呼者、日時、またはその他の分類ファクタに依存して異なる発呼者プロファイル情報を提供するサービスも、例えば発呼者プロファイル加入者によって設定されるルールに従って選択される相異なる利用可能な発呼者プロファイルＵＲＬのセットのうちの１つのＵＲＬを配信することによって、ＣＰＤＳ／ＳＣＰ１１０を通じて提供されることが可能である。また、ＣＰＤＳ／ＳＣＰ１１０あるいは交換機１２２は、加入者端末１２４または関連する表示ユニットの表示能力に依存して、いくつかの利用可能なＵＲＬのうちの適当な１つを、配信のために選択することが可能である。」（段落００２６〜００２７）
　
　上記摘記事項ホ．〜ヘ．の記載及び図面によれば、引用例２は、発呼者に関する情報を被呼者に配信して、被呼加入者端末１２４で発呼者プロファイルウェブページを表示させるためのものである。ここで、「発呼者」、「被呼者」をそれぞれ「起呼側」、「被呼側」と言い換えれば、引用例２は、「起呼側についての情報を被呼側に表示させるためのもの」ということができる。
　また、上記摘記事項ヘ．の段落００２７には、「被呼者がアクセス可能なウェブサーバに格納された、加入者の発呼者プロファイル情報を指示するＵＲＬ（またはその他のポインタあるいはロケータ）を、適当な端末に配信する。」という記載があるが、上記の言い換えを考慮すれば、「起呼側についてのプロファイル情報を指示するＵＲＬを配信すること」が開示されているといえる。
　したがって、これらの記載事項によると、引用例２には以下の発明（以下「引用発明２」という。）が記載されていると認められる。
　
「起呼側についての情報を被呼側に表示させるために、起呼側についてのプロファイル情報を指示するＵＲＬを配信するもの」
　
（３）対比・判断
　補正後の発明と引用発明１とを対比する。
　
ａ．引用発明１の「音声の呼」、「呼」は、補正後の発明の「音声コール」、「コール」に一致している。
　
ｂ．発信者番号が起呼側端末を識別できるデータであることは技術常識であるから、引用発明１の「発信者番号」は、補正後の発明の「音声コールの起呼側を識別する第１のデータ」に含まれるものである。
　
ｃ．引用発明１の「顧客情報」は、上記摘記事項．ニの段落００６３に記載されているように、図５乃至図７の情報であり、これらが顧客に関連する情報であることは明らかであるから、補正後の発明の「顧客関連情報」に相当する。
　
ｄ．引用発明１の「転送」と補正後の発明の「コール転送」とは、共にコール（呼）を所定の宛先に接続する処理である点で一致している。
　
ｅ．引用発明１の「Ｈ．３２３規格により通信を行うＣＴＩサーバ」と補正後の発明の「データ処理システム」とは、共にコール（呼）に関するデータ処理をするシステムである点で一致している。
　
　したがって、補正後の発明と引用発明１は、以下の点で一致ないし相違している。
　
（一致点）
　「データ処理システムにて（ｉ）音声コール、および（ｉｉ）該音声コールの起呼側を識別する第１のデータを受信するステップと、
　該音声コールをコールの宛先にコール転送するステップと、を含む方法。」
　
（相違点１）
　補正後の発明はコール転送について、「該音声コールのコール転送が該セッション開始プロトコルメッセージを該コールの宛先に送信する処理から成り」とされているのに対し、引用発明１はＨ．３２３規格により通信を行うものではあるものの、具体的な処理については示されていない点。
　
（相違点２）
　補正後の発明では、「（１）該第１のデータに基づく、および（ｉｉ）該起呼側についての顧客関連情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレスを識別する第２のデータを、セッション開始プロトコルメッセージ内に埋め込むステップ」があり、「該顧客関連情報を指し示す該コンピュータ・ファイル・アドレスが該コール転送それ自身に埋め込まれている」とされているのに対し、引用発明１では「発信者番号に基づく起呼側についての顧客情報を得るステップ」があり、転送するステップにおいて「該音声の呼の転送と共に顧客情報を送信する」ようにされており、起呼側についての顧客関連情報そのものが音声の呼の転送と共に送られるようにされている点。
　
　まず、上記相違点１について検討する。
　ＩＰ上の呼制御プロトコルとして、Ｈ．３２３とＳＩＰ（セッション開始プロトコル）とが共に周知であり、同様に用いられ得るものであることは、例えば、特開２００３−３４８２２９号公報の段落００２０〜００２７、特開２００１−１１１６９８号公報の段落００１７、００３８、００４７、特開２００４−２２９２９６号公報の段落０１１４等の記載によっても分かるように、技術常識である。したがって、引用発明１の呼制御プロトコルをＳＩＰ（セッション開始プロトコル）に替えることは適宜なし得たことに過ぎない。そして、セッション開始プロトコルにおいては、呼の接続はメッセージの送信によってなされるものであるから、コール転送がセッション開始プロトコルメッセージをコールの宛先に送信する処理から成るようにすることは、通常の手順を採用したに過ぎず、格別のこととは認められない。
　
　次に、上記相違点２について検討する。
　上記「（２）引用発明及び周知技術」のＢ．で述べたように、引用発明２は「起呼側についての情報を被呼側に表示させるために、起呼側についてのプロファイル情報を指示するＵＲＬを配信するもの」であるが、引用発明２の「プロファイル情報」は「コンピュータ・ファイル」であることは明らかであり、技術常識を鑑みれば、ＵＲＬは一般に「情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレスを識別するデータ」であるといえるから、引用発明２は「起呼側についての情報を被呼側に表示させるために、起呼側についての情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレスを識別するデータを配信するもの」ということができる。ここで、引用発明１と引用発明２とは、共に起呼側についての情報を被呼側に表示させるものであって、作用、機能が共通しているから、両者を組み合わせ、顧客関連情報そのものを送ることに替えて、「顧客関連情報をアクセスすることのできるコンピュータ・ファイルを指し示すコンピュータ・ファイル・アドレスを識別するデータ」を送るようにすることは、当業者であれば容易に想到し得たことである。なお、当該「データ」は、起呼側の顧客に関連する情報を特定するものとなるから、「起呼側を識別する第１のデータ」に基づくものとなることは当然である。
　そして、上記のようにした場合、当該データ（第２のデータ）はコール転送においてセッション開始プロトコルメッセージと共に送られることとなるが、さらにＵＲＬをメッセージに含めて（埋め込んで）送ることが周知技術であることを鑑みれば（例えば、特開２００１−１１１６９８号公報の段落００４８〜００５０、図１１、特開２００４−２２９２９６号公報の段落００９３等を参照）、「第２のデータを、セッション開始プロトコルメッセージ内に埋め込むステップ」を設け、「該顧客関連情報を指し示す該コンピュータ・ファイル・アドレスが該コール転送それ自身に埋め込まれている」ようにすることは、当業者であれば適宜なし得たことである。
　
　また、効果についても、引用発明から当業者が予測し得る範囲のものである。
　
　以上のとおり、本願の補正後の発明は引用発明１、引用発明２及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際、独立して特許を受けることができないものである。
　
４．結語
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２２年３月１０日付けの手続補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりのものである。
　
２．引用発明
　引用発明１及び引用発明２は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３．対比・判断
　本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明１、引用発明２及び周知技術に基づいて容易に想到できたものであるから、本願発明も同様の理由により、容易に想到できたものである。
　
第４．むすび
　したがって、本願発明は、引用発明１、引用発明２及び周知技術に基づいて、当業者であれば容易に想到し得たものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。