【事件の表示】
　特願２００５−３３５９９４「被呼装置、発呼装置、通信システム、通信プログラムおよび通信方法」拒絶査定不服審判事件〔平成１９年　６月　７日出願公開、特開２００７−１４２９５６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は、平成１７年１１月２１日の出願であって、平成２３年４月８日付けで拒絶理由が通知され、同年６月２日付けで手続補正がされたが、同年９月７日付けで拒絶査定がなされ、これに対し、同年１２月１日に拒絶査定不服の審判が請求されるとともに、同日付けで手続補正がされたものである。 
 　 
第２　補正却下の決定 
［補正却下の決定の結論］ 
　平成２３年１２月１日付けの手続補正を却下する。 
　
［理由］ 
１．本願発明と補正後の発明 
　上記手続補正（以下、「本件補正」という。）は補正前の平成２３年６月２日付け手続補正書の特許請求の範囲の請求項１３に記載された 
　
　「【請求項１３】
　発呼装置との間で通話を含む複数の通信形態を取り得る被呼装置が行なう通信方法であって、
　前記被呼装置の記憶部には前記被呼装置の使用状態に対応した受信条件が予め記憶され、
　自装置の使用状態を収集する工程と、
　前記発呼装置からの要求に応じて、前記収集した使用状態に対応する受信条件を前記発呼装置へ送信する工程と、
　前記発呼装置からの前記受信条件に応じた接続要求に基づき通信回線を設定する工程とを含む、通信方法。」 
 　
という発明（以下、「本願発明」という。）を、 
　 
　「【請求項１２】
　発呼装置との間で通話を含む複数の通信形態を取り得る被呼装置が行なう通信方法であって、
　前記被呼装置の記憶部には前記被呼装置の使用状態に対応した受信条件がユーザによって変更可能に予め記憶され、
　自装置の使用状態を収集する工程と、
　前記発呼装置からの要求に応じて、前記収集した使用状態に対応して予め記憶された受信条件を前記発呼装置へ送信する工程と、
　前記発呼装置からの前記受信条件に応じた接続要求に基づき通信回線を設定する工程とを含む、通信方法。」
　
という発明（以下、「補正後の発明」という。）に変更することを含むものである。 
　
２．新規事項の有無、補正の目的要件について 
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１３に記載された、「受信条件が予め記憶され」に関し、「受信条件がユーザによって変更可能に予め記憶され」と限定し、また、「使用状態に対応する受信条件」に関し、「使用状態に対応して予め記憶された受信条件」と限定して、特許請求の範囲を減縮するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び同改正前の特許法第１７条の２第４項第２号（補正の目的）の規定に適合している。 
　
３．独立特許要件について 
　本件補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 
　
（１）補正後の発明 
　上記「１．本願発明と補正後の発明」の項で補正後の発明として認定したとおりである。 
　
（２）引用発明 
　原審の拒絶理由に引用された特開２００５−２７８０８４号公報（以下、「引用例」という。）には、図面とともに以下の事項が記載されている。 
　
イ．「【技術分野】
【０００１】
  本発明は、ＩＰ（Internet Protocol）電話による通信を行うための通信システムに関する。」（５頁） 
　
ロ．「【００２１】
  図１を参照すると、本発明の第１の実施形態による通信システムは、通信端末１０，２０と、ＳＩＰ（Session Initiation Protocol）サーバ３０と、プレゼンスサーバ４０と、これらを相互に接続するインターネット５０とを有している。なお、図１においては、通信端末１０，２０の２つが示されているが、通信端末の数は複数であれば特に制限はない。
【００２２】
  通信端末１０，２０は、インターネット５０上に配設されたＳＩＰサーバ３０により接続された上で、ＩＰ電話により互いに通信を行うＰＣ、ＰＤＡ、携帯電話等の汎用的な通信端末である。また、通信端末１０，２０は、自己の通信端末が管理、利用するリソース（マイク、レコーダ、ビデオカメラ、ＣＰＵ、メモリ、ＨＤＤ等）の状態を監視し、これらのリソース状態に基づくプレゼンス情報を、インターネット５０上に配設されたプレゼンスサーバ４０を中継して、相互に通知する。
【００２３】
  ＳＩＰサーバ３０は、通信端末１０，２０間でのＩＰ電話による通信時に通信端末１０，２０間の接続処理を行う接続処理部３１を有している。詳細には、接続処理部３１は、通信端末１０，２０との間で発信、着信、切断等のシグナリング情報をやり取りし、そのシグナリング情報に基づき通信端末１０，２０間を接続、切断する処理を行う。接続処理部３１により通信端末１０，２０間が接続された以降は、通信端末１０，２０間では、ＳＩＰサーバ３０を中継せず、データ（音声、映像、ファイル等）のＩＰパケットをやり取りする。なお、本通信システムが三者通話が可能なシステムに適用される場合には、通信端末１０，２０間では、不図示のミキシングサーバ（音声をミキシングするもの）を経由してＩＰパケットをやり取りする場合もある。
【００２４】
  プレゼンスサーバ４０は、プレゼンス情報の中継処理を行う。詳細には、プレゼンスサーバ４０は、通信端末１０，２０からプレゼンス情報を受信する機能や、通信端末１０，２０から他の通信端末のプレゼンス情報取得要求を受信する機能や、通信端末１０，２０に対し、その通信端末がプレゼンス情報の取得要求を行った他の通信端末のプレゼンス情報を配信する機能を備えている。
【００２５】
  ここで、通信端末１０，２０の構成について説明する。なお、通信端末２０の構成は図１からは省略されているが、通信端末２０も通信端末１０と同様の構成となっている。
【００２６】
  通信端末１０，２０は、ＩＰ電話機能部１２と、リソース状態監視部１３と、プレゼンス情報生成部１４と、プレゼンス情報送受信部１５と、プレゼンス情報表示部１６とを有している。これらの構成要素は、ＩＰ電話用ソフトウェア１１の実行により実現されるものであるが、専用のハードウェアにより構成されても良い。
【００２７】
  また、通信端末１０，２０は、ＩＰ電話機能以外の他の機能として、ＩＰ電話機能が利用するリソースを競合して利用するビデオ録画機能、ビデオカメラの画像を処理する画像処理機能の他、電子メール機能、チャット機能等が搭載されており、これら機能を実現する他のソフトウェアも格納されているが、これらのソフトウェアは図１からは省略されている。
【００２８】
  ＩＰ電話機能部１２は、ＩＰ電話による通信時に、自己の通信端末のデータ（自己の通信端末にて集音された音声、撮像された映像、自己の通信端末内に保存されているファイル等）をＩＰパケットに変換して他の通信端末に送信するとともに、他の通信端末のデータ（他の通信端末にて集音された音声、撮像された映像、他の通信端末内に保存されているファイル等）のＩＰパケットを受信し、受信したＩＰパケットを元のデータに変換する処理を実行する。
【００２９】
  リソース状態監視部１３は、自己の通信端末が管理、利用するリソース（マイク、レコーダ、ビデオカメラ、ＣＰＵ、メモリ、ＨＤＤ等）の状態を監視し、そのリソースの状態をプレゼンス情報生成部１４およびプレゼンス情報表示部１６に通知する。なお、リソース状態監視部１３は、リソースそのものを監視することとしても良く、また、リソースを競合して利用する他の機能（ビデオ録画機能等）の動作状況を監視することでリソースを監視することとしても良い。また、リソース状態監視部１３は、リソース状態を１回目に監視した以降は、リソース状態が変化する度に、変化後のリソース状態をプレゼンス情報生成部１４およびプレゼンス情報表示部１６に通知するものとする。
【００３０】
  プレゼンス情報生成部１４は、リソース状態監視部１３からリソース状態が通知される度に、通知されたリソース状態に基づいてプレゼンス情報を生成し、生成したプレゼンス情報をプレゼンス情報送受信部１５に出力する。
【００３１】
  プレゼンス情報送受信部１５は、プレゼンス情報生成部１４からプレゼンス情報が出力される度に、出力されたプレゼンス情報をプレゼンスサーバ４０に送信する。また、プレゼンスサーバ４０から他の通信端末のプレゼンス情報を受信し、プレゼンス情報表示部１６に出力する。
【００３２】
  プレゼンス情報表示部１６は、リソース状態監視部１３から通知されたリソースの状態を表示するとともに、プレゼンス情報送受信部１５から出力された他の通信端末のプレゼンス情報を表示する。その他にも、ＩＰ電話機能部１２がＩＰ電話による通信時に上記の動作を実行する場合等において、ユーザに対して各種の指示内容を表示する。
【００３３】
  なお、通信端末１０，２０は、ユーザ自身がユーザ状態（在席中、離席中、通話中、外出中等）を設定するためのユーザ設定手段も備えており、ユーザに設定されたユーザ状態をプレゼンス情報に含めて送受信することも可能であるが、このような技術は従来技術と何ら変わりはなく、本発明の本質的部分ではないため、図１からはユーザ設定手段およびそれに関連する構成要素は省略されている。」（７〜９頁）
　
ハ．「【００４９】
  図４に、リソース状態監視部１３の動作の一例を説明するフローチャートを示す。
【００５０】
  図４を参照すると、リソース状態監視部１３は、ＩＰ電話機能部１２が利用するリソースであるマイク、ビデオカメラ、レコーダのそれぞれについて、有効であるか（利用中でないか）、無効であるか（利用中であるか）、録画中であるか（ビデオ録画機能による録画中であるか）等を監視する（ステップ４０１）。
【００５１】
  具体的には、リソースの状態を監視する方法としては、次の（１）〜（３）に例示した方法が考えられる。
（１）ＯＳ（Operating System）に実装されているインターフェースを利用する方法
　ＯＳに実装されているＡＰＩ（Application Program Interface）を利用して、リソースの状態を監視する。
【００５２】
  例えば、ビデオカメラ向けに実装されているＡＰＩを実行し、実行に失敗した場合はビデオカメラの利用不可と判断する。
【００５３】
  また、音声入力用ソースの選択状況を取得するために実装されているＡＰＩを実行し、その結果、マイクが選択されない場合はマイクの利用不可と判断する。
（２）他のソフトウェアから出力されるログファイルを利用する方法
  ＩＰ電話機能部１２とリソースを競合して利用する他の機能のソフトウェアから出力されるログファイルの内容に基づいて、リソースの状態を監視する。
【００５４】
  例えば、ビデオ録画用ソフトウェアから出力されたログファイルに「録画開始」と記録されている場合は、レコーダが利用不可と判断し、ログファイルに「録画完了」と記録されている場合は、レコーダが利用可と判断する。
（３）ＩＰ電話用ソフトウェア１１に状態通知用のＡＰＩを実装する方法
  ＩＰ電話用ソフトウェア１１に状態通知用のＡＰＩを実装し、ＩＰ電話機能部１２とリソースを競合して利用する他の機能のソフトウェアから当該ソフトウェアの動作状態を状態通知用のＡＰＩを介して通知してもらうことにより、リソースの状態を監視する。
【００５５】
  例えば、ビデオ録画用ソフトウェアから録画開始時および録画完了時に、その旨を通知してもらえば、録画開始の通知を受けてから録画完了の通知を受けるまでの間は、レコーダが利用不可と判断する。
【００５６】
  続いて、リソース状態監視部１３は、ステップ４０１での監視が１回目の監視であれば（ステップ４０２）、その監視結果をプレゼンス情報生成部１４およびプレゼンス情報表示部１６に通知し（ステップ４０３）、１回目の監視でなければ、前回の監視結果との比較を行い（ステップ４０４）、前回から状態変化がなければ（ステップ４０５）、一定時間待機した後（ステップ４０６）、再度の監視を行う。ただし、前回から状態が変化していれば、ステップ４０１での監視結果をプレゼンス情報生成部１４およびプレゼンス情報表示部１６に通知する。」（１０〜１１頁）
　
ニ．「【００５９】
  図５に、プレゼンス情報生成部１４の動作の一例を説明するフローチャートを示す。
【００６０】
  図５を参照すると、プレゼンス情報生成部１４は、リソース状態監視部１３からのリソース状態の通知を受けると（ステップ５０１）、通知された情報を、プレゼンス情報生成部１４内に備えられたテーブルに登録する（ステップ５０２）。プレゼンス情報生成部１４内のテーブルの一例を図６に示す。なお、図６においては、監視対象のリソースが、マイク（mic）、ビデオカメラ（camera）、レコーダ（recorder）となっている。
【００６１】
  続いて、プレゼンス情報生成部１４は、テーブルに登録されている内容を所定のデータフォーマットに変換することでプレゼンス情報を生成し（ステップ５０３）、生成したプレゼンス情報をプレゼンス情報送受信部１５に出力する（ステップ５０４）。」（１１〜１２頁）
　
ホ．「【００６３】
  図９に、監視対象のリソースのそれぞれの状態に基づいて、通信端末単体としての状態のみを示すプレゼンス情報を生成する場合の動作の一例を説明するフローチャートを示す。なお、図９においては、監視対象がマイク、ビデオカメラ、レコーダであるものとする。
【００６４】
  図９を参照すると、プレゼンス情報生成部１４は、レコーダの状態を確認し、レコーダの状態が録画中であれば（ステップ９０１）、通信端末の状態を録画中とする（ステップ９０２）。また、ステップ９０１において、レコーダの状態が待機中であれば、マイクの状態を確認し、マイクの状態が無効であれば（ステップ９０３）、通信端末の状態を着信不可とする（ステップ９０４）。また、ステップ９０３において、マイクの状態が有効であれば、ビデオカメラの状態を確認し、ビデオカメラの状態が無効であれば（ステップ９０５）、通信端末の状態を電話着信可とし（ステップ９０６）、逆にビデオカメラの状態が有効であれば、通信端末の状態をテレビ電話着信可とする（ステップ９０７）。
【００６５】
  上述したように本実施形態においては、通信端末１０，２０は、自己の通信端末のＩＰ電話機能部１２が利用するリソースの状態に基づいてプレゼンス情報を生成しているため、これらのリソースがＩＰ電話機能以外の他の機能によって占有されているためにＩＰ電話を利用できないこともプレゼンス情報に反映させることができる。また、リソースの状態が変化する度に、変化後のリソースの状態に基づくプレゼンス情報を自動的に他の通信端末に通知することができ、また、他の通信端末でリソースの状態が変化した場合も変化後のリソース状態に基づくプレゼンス情報の通知を当該他の通信端末から自動的に受けて、そのプレゼンス情報を表示することができる。
【００６６】
  したがって、例えば、通信端末１０がＩＰ電話を利用できない状態にある場合、通信端末２０から通信端末１０へＩＰ電話による着信がなされることを回避できる。
【００６７】
  なお、本実施形態においては、通信端末１０，２０は、プレゼンスサーバ４０を中継せずに、プレゼンス情報を相互に直接通知する構成でも良い。この構成の場合、通信端末１０，２０内のプレゼンス情報送受信部１５は、他の通信端末に対して直接プレゼンス情報取得要求を行い、当該他の通信端末から直接プレゼンス情報を取得する。また、この構成の場合、プレゼンスサーバ４０を設ける必要はない。」（１２〜１３頁）
　
　上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の【００２６】の記載、及び図１によれば、通信端末（１０，２０）は、リソース状態監視部（１３）と、プレゼンス情報生成部（１４）と、プレゼンス情報送受信部（１５）とを備えている。
　また、上記ハ．の【００５０】の記載、及び図４によれば、前述のリソース状態監視部（１３）は、（α）通信端末（１０，２０）のリソース状態を監視している。
　また、上記ニ．の【００６０】の記載、及び図５によれば、前述のプレゼンス情報生成部（１４）は、通信端末（１０，２０）の前述のリソース状態をテーブルに登録している。ここで、上記ホ．の【００６４】における「図９を参照すると、プレゼンス情報生成部１４は、・・・ステップ９０１において、レコーダの状態が待機中であれば、マイクの状態を確認し、マイクの状態が無効であれば（ステップ９０３）、通信端末の状態を着信不可とする（ステップ９０４）。また、ステップ９０３において、マイクの状態が有効であれば、ビデオカメラの状態を確認し、ビデオカメラの状態が無効であれば（ステップ９０５）、通信端末の状態を電話着信可とし（ステップ９０６）、逆にビデオカメラの状態が有効であれば、通信端末の状態をテレビ電話着信可とする（ステップ９０７）。」との記載、及び図９によれば、前述のプレゼンス情報生成部（１４）は、前述のリソース状態に対応して「着信不可」「電話着信可」「テレビ電話着信可」としているから、（β）これは被呼側通信端末のリソース状態に対応した受信条件ということができ、被呼側通信端末の記憶部に記憶されていることは明らかである。
　また、上記ホ．の【００６７】における「通信端末１０，２０は、プレゼンスサーバ４０を中継せずに、プレゼンス情報を相互に直接通知する構成でも良い。この構成の場合、通信端末１０，２０内のプレゼンス情報送受信部１５は、他の通信端末に対して直接プレゼンス情報取得要求を行い、当該他の通信端末から直接プレゼンス情報を取得する。」との記載によれば、発呼側通信端末は、直接プレゼンス情報（すなわち、前述の受信条件）取得要求を行い、被呼側通信端末から直接受信条件を取得することが読み取れる。言い換えれば、被呼側通信端末は、（γ）発呼側通信端末からの要求に応じて、前述の監視したリソース状態に対応して記憶された受信条件を前述の発呼側通信端末へ送信するということができる。
　ここで、上記（α）〜（γ）を、方法として纏めると、被呼側通信端末は、発呼側通信端末との間で、電話、テレビ電話を行なうから、発呼側通信端末との間で通話を含む複数の通信形態を取り得る被呼側通信端末が行なう通信方法ということができる。
　
　したがって、通信方法を工程として纏めると、上記引用例には、以下の発明（以下、「引用発明」という。）が開示されているものと認められる。
　
　「発呼側通信端末との間で通話を含む複数の通信形態を取り得る被呼側通信端末が行なう通信方法であって、
　前記被呼側通信端末の記憶部には前記被呼側通信端末のリソース状態に対応した受信条件が記憶され、
　自通信端末のリソース状態を監視する工程と、
　前記発呼側通信端末からの要求に応じて、前記監視したリソース状態に対応して記憶された受信条件を前記発呼側通信端末へ送信する工程とを含む、通信方法。」
　
（３）対比・判断 
　補正後の発明と引用発明とを対比する。 
ａ．引用発明の「発呼側通信端末」及び「被呼側通信端末」は、補正後の発明の「発呼装置」及び「被呼装置」にそれぞれ相当する。
ｂ．引用発明の「リソース状態」は、上記引用例の上記ハ．の【００５０】における「リソース状態監視部１３は、ＩＰ電話機能部１２が利用するリソースであるマイク、ビデオカメラ、レコーダのそれぞれについて、有効であるか（利用中でないか）、無効であるか（利用中であるか）・・・等を監視する（ステップ４０１）。」との記載によれば、「リソース状態」は、利用（使用）中であるか否かという状態を意味するから、「使用状態」ということができる。
ｃ．引用発明の「監視」は、リソース状態（使用状態）を監視して収集するから、「収集」ということができる。
　
 　したがって、補正後の発明と引用発明は、以下の点で一致ないし相違している。 
 　 
（一致点） 
　「発呼装置との間で通話を含む複数の通信形態を取り得る被呼装置が行なう通信方法であって、
　前記被呼装置の記憶部には前記被呼装置の使用状態に対応した受信条件が記憶され、
　自装置の使用状態を収集する工程と、
　前記発呼装置からの要求に応じて、前記収集した使用状態に対応して記憶された受信条件を前記発呼装置へ送信する工程とを含む、通信方法。」
　
（相違点１）
　「使用状態に対応した受信条件」の記憶態様に関し、
　補正後の発明は、受信条件が「ユーザによって変更可能に予め」記憶されているのに対し、引用発明は、その様な特定がない点。
　
（相違点２）
　「使用状態に対応して記憶された受信条件」の記憶態様に関し、
　補正後の発明は、受信条件が「予め」記憶されているのに対し、引用発明は、その様な特定がない点。
　
（相違点３）
　「通信方法」に関し、
　補正後の発明は、「前記発呼装置からの前記受信条件に応じた接続要求に基づき通信回線を設定する工程」を含むのに対し、引用発明は、その様な工程を含むか否か不明である点。
　
　そこで、まず、上記相違点１及び２について検討する。 
　電話等の通信方法において、被呼装置のユーザによって、着呼の条件を変更可能にすることは、例えば、特開２００２−２２３２７１号公報（段落【００１２】、図２）、特開２０００−１９６７７６号公報（段落【００２４】〜【００３１】、【００４２】、【００４３】、図２、３）に開示されるように周知であるから、引用発明に周知技術を適用して、補正後の発明のように受信条件が「ユーザによって変更可能に予め」記憶されていること（相違点１）は当業者が容易になし得ることである。その際、受信条件が「予め」記憶されていること（相違点２）は当然である。
　
　次に、上記相違点３について検討する。
　上記引用例の上記ホ．の【００６６】における「通信端末１０がＩＰ電話を利用できない状態にある場合、通信端末２０から通信端末１０へＩＰ電話による着信がなされることを回避できる。」との記載によれば、被呼側通信端末（被呼装置）は、発呼側通信端末（発呼装置）から接続要求をする際の通信回線の設定について、受信条件を考慮することは明らかであるから、補正後の発明のように「前記発呼装置からの前記受信条件に応じた接続要求に基づき通信回線を設定する工程」を含むことは自然なことである。
　
　そして、補正後の発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲のものである。 
 　 
　以上のとおり、補正後の発明は引用発明及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。 
 　 
４．結語 
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。  
 　 
第３　本願発明について 
１．本願発明 
　平成２３年１２月１日付けの手続補正は上記のとおり却下されたので、本願発明は、上記「第２　補正却下の決定　１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。 
　 
２．引用発明 
　引用発明は、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。 
 　 
３．対比・判断 
　本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。 
　そうすると、本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明及び周知技術に基づいて容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。 
　 
４．むすび 
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　 
　よって、結論のとおり審決する。