【事件の表示】
　特願２００４−１００３０７「ＩＰ通信メディアの自動圧縮」拒絶査定不服審判事件〔平成１６年１０月２８日出願公開、特開２００４−３０４８０２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１６年３月３０日（パリ条約による優先権主張２００３年３月３１日、米国）の出願であって、平成２２年７月２８日付けで拒絶査定がなされ、これに対し同年１２月３日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２　補正却下の決定
　［補正却下の決定の結論］  
　　平成２２年１２月３日付けの手続補正を却下する。
　
　［理由］
１．本願発明と補正後の発明
　上記手続補正（以下、「本件補正」という。）は、補正前の平成２２年３月１５日付けの手続補正書の特許請求の範囲の請求項１に記載された、
「通信装置であって、
　ａ）通信インターフェースと；
　ｂ）該通信インターフェースに関連する制御システムとから成り、
　該制御システムが、
　　１）第１セッションを介してリモートセッション装置と通信し；
　　２）前記通信装置と前記リモートセッション装置との間における前記第１セッションの間における低下した帯域幅の状態を検出し；
　　３）前記第１セッションの間における前記低下した帯域幅の状態を検出すると、増大した圧縮比率を使用して、前記第１セッションの間における前記リモートセッション装置と通信し；
　　４）所定の時間周期の後、前記増大した圧縮比率の無い標準的な様式における前記第１セッションの間における前記リモートセッション装置との通信に復帰する、
通信装置。」
という発明（以下、「本願発明」という。）を、平成２２年１２月３日付けの手続補正書の特許請求の範囲の請求項１に記載された、
　
「通信装置であって、
　ａ）通信インターフェースと；
　ｂ）該通信インターフェースに関連する制御システムとから成り、
　該制御システムが、
　　１）第１セッションを介してリモートセッション装置と通信し；
　　２）
　　　　ａ）前記リモートセッション装置との通信に関連するパケット損失であって、前記パケット損失が所定の閾値を超過するとき、低下した帯域幅の状態を検出し；
　　　　ｂ）前記リモートセッション装置との通信に関連するパケット遅延であって、前記パケット遅延が前記所定の閾値を超過するとき、前記低下した帯域幅の状態を検出し；
　　　　ｃ）前記リモートセッション装置との通信に関連するジッタであって、当該ジッタが前記所定の閾値を超過するとき、前記低下した帯域幅の状態を検出するようにして、前記パケット損失と、前記パケット遅延と、前記ジッタとをモニターすることにより、前記通信装置と前記リモートセッション装置との間における前記第１セッションの間における前記低下した帯域幅の状態を検出するためにセッションのクオリティをモニターし；
　　３）前記第１セッションの間における前記低下した帯域幅の状態を検出すると、増大した圧縮比率を使用して、前記第１セッションの間における前記リモートセッション装置と通信し；
　　４）所定の時間周期の後、前記増大した圧縮比率の無い標準的な様式における前記第１セッションの間における前記リモートセッション装置との通信に復帰する、
通信装置。」
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．補正の適否
（１）新規事項の有無、補正の目的要件について
　上記本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１の「低下した帯域幅の状態を検出」について「低下した帯域幅の状態を検出するためにセッションのクオリティをモニターし」と限定するとともに、当該モニターの対象を、「ａ）前記リモートセッション装置との通信に関連するパケット損失であって、前記パケット損失が所定の閾値を超過するとき、低下した帯域幅の状態を検出し；ｂ）前記リモートセッション装置との通信に関連するパケット遅延であって、前記パケット遅延が前記所定の閾値を超過するとき、前記低下した帯域幅の状態を検出し；ｃ）前記リモートセッション装置との通信に関連するジッタであって、当該ジッタが前記所定の閾値を超過するとき、前記低下した帯域幅の状態を検出するようにして、前記パケット損失と、前記パケット遅延と、前記ジッタとをモニターすることにより、」と具体的に限定することにより、特許請求の範囲を減縮するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び同法第１７条の２第４項(補正の目的）の規定に適合している。
　
（２）独立特許要件について
　上記本件補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が、特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２−１）　補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
（２−２）　引用発明
　Ａ．原査定の拒絶の理由に引用された米国特許出願公開第２００３／００１２１３８号明細書（以下「引用例」という。）には、「Codec with network congestion detection and automatic fallback: methods, systems  program products」（当審仮訳：ネットワーク輻輳検波および自動フォールバックを備えた符号化復号化:方法、システムプログラム・プロダクト）として以下の事項（イ．〜ホ．）が記載されている。
　
（引用例）
　イ．「A codec detects congestion in a packet network and responds via a session control protocol to re-negotiate codec-type and/or parameters with the receiving codec to reduce bit rate for supporting a session. Once the connection and session are established, encoded packets start flowing between the two codecs. A control entity sends and receives network congestion control packets periodically in the session. The congestion control packets provide a heartbeat signal to the receiving codec. When the network is not congested, all heartbeat packets will be passed through the network. As network congestion increases, routers within the network discard excess packets to prevent network failure. The codecs respond to the missing packets by slowing down the bit rate or proceeding to renegotiate a lower bit rate via the session control protocol. If there are no missing packets, the codecs detect if the session is operating at the highest bit rate, and if not, re-negotiate a higher bit rate. 」（要約）
　（当審仮訳）
　「コーデックは、パケットネットワークの輻輳を検出し、セッション制御プロトコルを通して応答し、コーデックのタイプ及び（又は）受信コーデックに関するパラメータを再度取決め、現状のセッション(supporting a session)のビットレートを減少させます。一旦、接続とセッションが確立されれば、符号化されたパケットは2つのコーデック間で流れ始めます。コントロールエンティティは、セッション中、ネットワークの輻輳制御パケットを定期的に送受信します。輻輳制御パケットは受信コーデックに「ハートビート」という信号を受信コーデックに供給します。ネットワークに輻輳が生じていないとき、すべての「ハートビート」パケットは、ネットワークを通過します。ネットワークの輻輳が増加するにつれて、ネットワーク内のルーターは超過したパケットを廃棄して、ネットワークの接続不良(to prevent network failure)を避けます。コーデックは、セッション制御プロトコルを通し、失ったパケットに対して、ビットレートを遅くするか(slowing down the bit rate)、より（圧縮率の高い）低いビットレートとするよう再度取り決める(proceeding to renegotiate a lower bit rate)ことにより対応します。もし、失ったパケットが存在しない場合、コーデックはセッションが最も高いビットレートで運用しているかどうか検出し、そうでなければ、より高いビットレートで運用するよう再度取り決めます。」
　
　ロ．「 [0024]  In  FIG. 1, a  network congestion detection and automatic correction system  100  for a packet network  102 , typically the internet or a private network or a virtual network, the system providing improved speech, video, and data transmissions to terminals or end points  104  and  106 . The terminals are connected to the Internet via Internet Service Providers (ISP)  110  and  112 , respectively. Other networks require similar access points. The service providers are in turn linked to routers  116  within the network  102  for directing the calls and data between the terminals  104  and  106 . The operation of the internet for initiating and routing calls between terminals is well known and described, for example, in the text Internet Architectures by D. Minoli and A. Schmidt, published by John Wiley  Sons, New York, N.Y.,  1998  (ISBN 0-471-19081-0). 
 [0025]  Terminals  104 ,  106  and the service providers  110 ,  112  function according to the framework of International Telecommunications Union (ITU) H.323 Standard for audio, video and data communications across packet networks including the Internet. Alternately, H.323 enabled terminals  108 ,  109 , are connected to the network via service providers that may not support H.323 functions. However, these terminals may establish H323 sessions with other H.323-enabled terminals. H.323 allows multi-media products and applications from multiple vendors to inter-operate without concern for compatibility. H.323 covers a selection of audio and video codecs, shared applications, call control, and system control. H.323 includes ITU H.245 which is used to negotiate capabilities under control aspects of the conference between two or more end points. Details of H.323 are described in the International Telecommunications Union (ITU) specifications. 
 [0026]  The terminals include coder/decoder techniques for compressing speech, video, or data signals and recovering the original signals from compressed data. The speech compression and decompression techniques have been standardized by the ITU, e.g., G.711, G.723.1, G.726, G.728, G.729A. 
 [0027]  In an alternative embodiment, a network congestion detection system  150  is shown in  FIG. 1A . A terminal  152  is connected to a central office access aggregation  154  via a Digital Subscriber Line Access Multiplexer (DSLAM)  156  or other remote access technology (i.e. cable modem, wireless). The multiplexer is linked to an Internet Service Provider (ISP)  158  for digital communication and interacts with a voice gateway  160  for voice communications to a Pubic Switch Telephone Network (PSTN)  162 . System  150  automatically detects network congestion and corrects for congestion in the same manner as will now be described for the packet network shown in  FIG. 1 . 
 [0028]  Returning to  FIG. 1, a  speech, video, or data session is set up between two terminals, e.g.,  104 ,  106 , executing compression/decompression algorithms, e.g., G.723, as voice codecs. The codecs compress and packetize the speech which is transmitted over the network using UDP protocol at the transport layer. One of the two codecs may be a voice gateway device  160  within the network as shown in  FIG. 1A  providing a means for the terminal at the other end to access the PSTN. Each of the codecs must be configured in accordance with a previously negotiated Service Level Agreement (SLA) with the operator of the network. The SLA defines, among other things, a preferred codec type and a guaranteed minimum bit rate (minimum session quality) codec type. 
 [0029]  The terminals and the service providers  110 ,  112  execute software implementing the H.323 protocol which manages call signaling for two or more end points engaged in a session. The H.323 protocol defines procedures for two voice codec devices to negotiate a commonly-agreed to codec type. 
 [0030]  In the absence of significant network congestion, the terminals select the codec type with the highest session quality (typically also the highest bit rate, but lowest implementation complexity) from among the set of codec types which can be commonly supported between the two devices. At least two different codec types or two different bit rate modes within the same codec type must be commonly supported between the two terminal devices. It is preferable to select multiple bit rates within the same codec type in order to minimize the transient effects of switching from one bit rate to another. A particular response time advantage for switching rates can be achieved if the codec type includes an embedded bit stream with predetermined priorities associated with different groups of bits within a packet. When using such a codec type, a lower bit rate may be achieved without negotiating with the other end by simply dropping the lower priority bits in the encoding process, thus creating a smaller packet to send during each interval. The receiving decoder will automatically recognize that the received packet has less than the expected amount of data and since the priorities of the group of bits are predetermined, the decoder knows which bits were not sent, and knows how to recreate a lower quality speech signal with the bits received without having to negotiate the lower bit rate. The receiving decoder may optionally signal the co-located encoder to reduce the bit rate in the opposite direction by the same amount in order to better deal with the network congestion which was originally detected in that direction.」（３頁右欄２行−４頁左欄３７行）
　（当審仮訳）
   「[0024] 図1には、パケットネットワーク102、典型的には、インターネット、プライベートネットワーク、あるいは仮想ネットワークのような、音声、画像、データを端末あるいはエンドポイント104、106に伝送するネットワークに対する、輻輳の検出、及び自動訂正システムが記載されています。各端末はインターネットサービスプロバイダ（ISP）110,112を介してそれぞれインターネットに接続されています。他のネットワークは同様のアクセス・ポイントを要求します。サービス・プロバイダは、ターミナル104、106間の呼およびデータ送信のために、ネットワーク102内のルーター116に順次接続されます。ターミナル間の呼の初期化及びルーティングのインターネット上の処理はよく知られており、例えば、ジョン・ワイリー・アンド・サンズ(ニューヨーク、1998年)出版の「インターネットアーキテクチャ」、D.ミノリ、A.シュミット著に説明されています。
[0025]端末104,106とサービスプロバイダ110,112は、インターネット等のパケット送信ネットワークで音声、映像、データ送信に関するITUのH.323という標準の枠組みにしたがって機能します。H.323で動作する、端末108,109はH.323の機能をサポートしないサービスプロバイダを介してネットワークに接続されるかもしれません。しかしながら、これらの端末は、H.323をサポートする端末とH.323のセッションを構築することができます。H.323によって、マルチメディア信号やマルチメディアアプリケーションを多数のベンダーから相互動作する端末に互換性に関する懸念無く送ることができます。H.323は、音声及び映像コーデック、共有アプリケーション、呼制御およびシステム制御を選択します。H.323は、ITU H.245を含んでおり、2つ以上のエンドポイント間の能力の調整に使用されます。H.323の詳細は国際電気通信連合(ITU)の仕様書に記述されています。
[0026] 端末は、符号化器／復号化器を備えており、音声、映像あるいはデータ信号を圧縮し、また圧縮データから原信号を回復します。音声圧縮および伸張技術はITU(例えばG.711、G.723.1、G.726、G.728、G.729A)によって標準化されています。
[0027] 他の実施形態では、ネットワーク輻輳検出システム150は図1Aで示されます。端末152は、デジタル加入者線多重化装置(DSLAM)156あるいは他の遠隔アクセス技術(つまりケーブル・モデム、ワイヤレス)によって中央局アクセス集合体154に接続されます。多重化装置はディジタル通信用のインターネット・サービス・プロバイダー(ISP)158に接続され、公衆電話回線網(PSTN)162と音声通信を行うための音声ゲートウエイ160と相互に通信します。システム150は自動的にネットワーク輻輳を検出し、図1に示されるパケットネットワーク用に記述されたものと同じ方法で輻輳を修正します。
[0028]説明を 図1に戻して、音声、映像あるいはデータのセッションは、2つの端末間104,106で形成され、圧縮/伸張アルゴリズム(例えば音声コーデックとしてG.723))を実行します。コーデックは、トランスポート層で”UDP”プロトコルを使用して、音声を圧縮しパケット化します。そして、該パケット化された音声はネットワークを通して送信されます。2つのコーデックのうちの1つは、ネットワーク内の音声ゲートウェイデバイス160でも良く、図1Aの中で示されるように、当該音声ゲートウェイデバイス160はPSTNにアクセスするためにもう一端の端末への接続手段となります。いずれのコーデックもネットワークのオペレーターと事前に合意されたサービスレベル協定(SLA)に従って構成されなければなりません。SLAはその他の事項に加え、好ましいコーデック・タイプおよび保証された最小ビット・レート(最小のセッション品質)を定義します。
[0029] 端末、サービス・プロバイダ110、112は、セッションに従事する2つ以上のエンドポイントに対する呼を管理するH.323プロトコルを駆動するソフトウェアを実行します。H.323プロトコルは、2つの音声コーデック装置のための手続きを定義し、両者に共通のコーデックタイプを交渉します。
[0030] ネットワーク輻輳がひどくない状態では、端末は、端末間で共通に利用可能なコーデック・タイプの中から最も高いセッション品質(典型的には最も高いビットレートかつ最もシンプルなもの)を備えたコーデック・タイプを選択します。少なくとも2つの異なるコーデック・タイプあるいは同じコーデック・タイプ内の2つの異なるビットレートモードが、2つの端末装置間で共通に利用可能でなければなりません。あるビットレートから別のビットレートに変わる時の一時的な影響を最小化するために同じコーデック・タイプ内のマルチビット・レートの中からいずれかを選択することが望ましいです。コーデック・タイプがパケット内のビットの異なるグループに関連し事前に定義した優先事項を備えた埋込み型ビット・ストリームを含んでいる場合、ビットレートの変更に有利な特別の応答時間を達成することができます。そのようなコーデック・タイプを使用する場合、低いビット・レートは、符号化プロセスで単に優先度が低いビットを捨てることにより、通信中の別の端末と交渉せずに、達成されます。その結果、各送信期間中に、より小さなパケットを作成し、送信します。受信デコーダは、受信パケットが予測されるデータ量より少ないことを自動的に認識し、ビットのグループの優先度は予め決まっているので、該受信デコーダは、どのビットが送られなかったか知っており、ビットレートの交渉をしなくても、受信したビットから低品質の音声信号をどのように再構成するかを知っています。受信デコーダは、ネットワークの輻輳に対処するために、同じ装置に設置されたエンコーダが逆方向に送信する信号のビットレートを縮小するように、オプションとして通知してもよい。」
　
　ハ．「[0035] FIG. 2  illustrates a processing loop  300  which is passed through once for each packet received at an end point in detecting network congestion or the absence of congestion, the process slowing down the bit rate or increasing the bit rate, respectively according to a predetermined threshold based upon a count of missing packets occurring in a selected time interval. Each time a packet is received in block  301 , a first decision block  303  determines whether or not there are any missing packets. 」（４頁右欄３６行−４４行）
（当審仮訳）
「[0035] 図2は、処理ループ300を図説したものであり、エンドポイントで受け取られた各パケットに対して当該処理ループ300上の処理を行います。ネットワーク輻輳を検出した場合や輻輳がなかった場合には、選択された期間内に生じたパケット損失に基づき、事前に定めた閾値にしたがいビットレートを減少させるまたは増加させる処理を行います。パケットがブロック301に受け取られるごとに、最初の判定ブロック303はパケット損失があるかどうか判断します。」
　
  ニ．「[0037] After the expiration of the time interval in decision block  307 , missing packet count, if any, is compared to a slowdown threshold or a speed up threshold in terms of missing packet count for determining whether to slowdown or increase the session bit rate for the best speech quality consistent with network congestion or lack thereof. 」（５頁左欄１６行−２１行）
（当審仮訳）
　「[0037] 判定ブロック307の時間経過後、パケット損失がもしあれば、スローダウンしきい値あるいはスピードアップしきい値と比較され、ネットワーク輻輳あるいは輻輳による不足の状態に整合する最善の通話品質のためセッションのビットレートを減少させるまたは増加させることを決定します。」
　
　ホ．「[0038] After the sampling or time interval has expired in Block  307 , the process advances to Block  311  which determines whether the error count is above a slow down threshold determined as described above. If the count is above the slow down threshold, Block  313  determines whether the codec is already operating at the lowest bit rate permitted. If not, block  315  is entered and the codec initiates bit rate re-negotiations using H.323 messages with the sending codec to select a lower bit-rate codec to reduce network congestion, after which block  309  is entered to reconstruct the original session content from the encoded data. Where the bit rate is determined in Block  313  to be already at the lowest bit rate, the packet is passed to block  309  for reconstructing the original session content from the encoded data. In either case, after completing the reconstruction of the original session content, the process returns to block  301 . 
 [0039] Returning to Block  311  if the missing packet count does not require a slowdown, the process transfers to Block  317  which determines whether the missing packet count is below the speedup threshold. Preferably, the speedup threshold is set such that even if all encoded session packets are received successfully, consistently missing congestion control packets would prevent speed up. If the session is already above the speedup threshold, Block  317  transfers the packet to Block  309  for reconstruction of original session data and return of the process to Block  301  to await processing of the next packet. If the count is below the speedup threshold, the process transfers to Block  319  which determines whether or not the codec is already operating at the highest bit rate permitted. If not currently at the highest permitted rate, the process transfers to Block  321  in which the receiving codec initiates bit rate re-negotiations with the sending codec to select a higher bit rate for the session with a corresponding higher session quality.」（５頁左欄４４行−右欄１５行）
（当審仮訳）
　「[0038] ブロック307のサンプリング時間または時間間隔が終了した後、処理はブロック311へ進む。そこでは、誤り数が上述のスローダウンしきい値以上かどうか判断します。カウントした誤り数がスローダウンしきい値以上の場合、ブロック313はコーデックが認められた中で最低のビットレートで既に作動しているかどうか判断します。もし、最低ビットレートでなければ、処理はブロック315に移り、コーデックは、ネットワークの輻輳を低下させるため、より低いビットレートのコーデックを選択するためのコーデックを送ることで、H.323メッセージを用いてビットレートの再交渉を開始します。その後、処理はブロック309に移り、コード化されたデータからオリジナルのセッションを再構築します。ブロック313で決定されるビットレートが既に最低のビットレートであった場合には、パケットはブロック309にそのまま渡されます。いずれの場合も、オリジナルのセッション内容の再構成を終えた後、処理はブロック301に戻ります。
[0039] ブロック311に戻り、パケット損失数がスローダウンを要求しない場合に、処理はブロック317に移り、パケット損失数がスピードアップしきい値未満かどうか判断します。好ましくは、コード化されたセッション・パケットがすべて正常に受信した場合でも一貫して輻輳制御パケットの損失がスピードアップを防ぐようなしきい値はセットされます。セッションが既にスピードアップしきい値以上の場合、ブロック317は、パケットをブロック309に転送し、オリジナルのセッション・データの再構成を行います。そして、次のパケットの処理を待つため処理をブロック301に戻します。もし、パケット損失数がスピードアップしきい値未満である場合、処理はブロック319に移り、コーデックが可能な限り最も高いビットレートで既に動作しているかどうか判断します。現時点で許された最速のビットレートではない場合には、処理はブロック312に移り、受信コーデックはより高いセッション品質に整合するより高いビットレートを選択するコーデックを送ることでビットレートの再交渉を始めます。」
　　                                               　
上記引用例の記載及びこの分野における技術常識を考慮すると、
　（ａ）まず、上記引用例のロ．（[0024]）及び図１にあるように、端末またはエンドポイント(terminals or end points 104 and 106)は、パケットネットワーク102、典型的には、インターネット、プライベートネットワーク、あるいは仮想ネットワークを通して、音声、画像、データを送受信するから、明らかに「通信装置」といえる。
　そして、上記引用例のロ．（[0028]）及び図１にあるように、端末間104,106(通信装置）で音声、画像またはデータのセッションを介して通信が確立されるから、引用例には、
　『通信装置であって、
　音声、画像またはデータのセッションを介して他の通信装置と通信』
することが記載されている。
　（ｂ）上記引用例ハ．（[0035]）、ホ．（[0038]）及び図２には、ネットワークの輻輳を検出する、または、輻輳が起こっていないことを検出するために、パケット損失をカウントし、該パケット損失が予め定められたスローダウン閾値を超えるか否か比較しており、前記閾値を超える場合には、より低いビットレートのコーデックを選択して、次のパケットの受信を待つとあるから、引用例には、
　『前記他の通信装置との通信に関連するパケット損失であって、前記パケット損失が予め定められたスローダウン閾値を超過するとき、ネットワークの輻輳を検出するようにして、
　前記パケット損失をモニターすることにより、前記通信装置間における音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出するためにセッションのパケット損失をモニターし、
　前記音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出すると、より低いビットレートのコーデックを選択して、前記他の通信装置と通信』することが記載されている。
　（ｃ）また、上記引用例ハ．（[0035]）、ニ．（[0037]）、ホ．（[0039]）及び図２には、パケット損失をカウントし、スローダウン不要である場合に、前記パケット損失をスピードアップ閾値と比較し、前記パケット損失が前記スピードアップ閾値を下回る場合に、当該セッションに対し、より高いビットレートのコーデックを選択するとあるから、引用例には、
　『前記パケット損失がスローダウンを必要とせず、スピードアップ閾値を下回る場合に、より高いビットレートのコーデックにおける前記音声、映像またはデータのセッションの間における前記他の通信装置と通信』することが記載されている。
　
　したがって、上記引用例の記載及びこの分野における技術常識を考慮すると、上記引用例には、以下の発明（以下「引用発明」という。）が記載されているものと認める。
   　
　（引用発明）
「通信装置であって、
　音声、画像またはデータのセッションを介して他の通信装置と通信し、
　前記他の通信装置との通信に関連するパケット損失であって、前記パケット損失が予め定められたスローダウン閾値を超過するとき、ネットワークの輻輳を検出するようにして、
　前記パケット損失をモニターすることにより、前記通信装置間における音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出するためにセッションのパケット損失をモニターし、
　前記音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出すると、より低いビットレートのコーデックを選択して、前記他の通信装置と通信し、
　前記パケット損失がスローダウンを必要とせず、スピードアップ閾値を下回る場合に、より高いビットレートのコーデックにおける前記音声、映像またはデータのセッションの間における前記他の通信装置と通信する
　通信装置。」
　
（２−３）　対比・判断
　［対比］
　補正後の発明と引用発明を対比する。
　
　（ア）まず、引用発明と補正後の発明は「通信装置」に関する発明である点で一致する。また、引用発明の「音声、画像またはデータのセッション」は、上記通信装置間の通信に関するセッションであることは自明であり、これを「第１セッション」と呼ぶことは任意である。そして、引用発明の「通信装置」は、前記「第１セッション」を介して「他の通信装置」と通信するものであり、当該「他の通信装置」は一般的に前記「通信装置」から離れた位置にあることは当業者の技術常識であるから、引用発明の「他の通信装置」は補正後の発明の「リモートセッション装置」に相当する。したがって、引用発明の
　「通信装置であって、音声、画像またはデータのセッションを介して他の通信装置と通信し、」は、補正後の発明の
　「通信装置であって、第１セッションを介してリモートセッション装置と通信し」と差異がない。
　
　（イ）引用発明の「予め定められたスローダウン閾値」は、「所定の閾値」といえる。また、引用発明の「ネットワークの輻輳」とは、送受信される信号が混雑により十分な通信資源を確保できない状態であり、ネットワークの通信帯域幅を確保できない状態を含むから、補正後の発明の「低下した帯域幅の状態」と差異がない。
　したがって、引用発明の
　「前記他の通信装置との通信に関連するパケット損失であって、前記パケット損失が予め定められたスローダウン閾値を超過するとき、ネットワークの輻輳を検出し、」は、
　補正後の発明の
　「前記リモートセッション装置との通信に関連するパケット損失であって、前記パケット損失が所定の閾値を超過するとき、低下した帯域幅の状態を検出し；」と差異がない。
　
　（ウ）また、引用発明の「前記パケット損失をモニターすることにより」と、補正後の発明の「前記パケット損失と、前記パケット遅延と、前記ジッタとをモニターすることにより、」とは、「前記パケット損失をモニターすることにより」との点で一致する。また、引用発明の「通信装置間」は、上記（ア）の対比を踏まえると、補正後の発明の「前記通信装置と前記リモートセッション装置との間」に相当する。また、引用発明の「セッションのパケット損失」は、セッションの品質、すなわち、クオリティを表す一つの指標といえるから、「パケット損失をモニターすること」は、セッションのクオリティーをモニターしているといえ、結局、引用発明の
　「前記パケット損失をモニターすることにより、前記通信装置間における音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出するためにセッションのパケット損失をモニターし、」と、補正後の発明の
　「前記パケット損失と、前記パケット遅延と、前記ジッタとをモニターすることにより、前記通信装置と前記リモートセッション装置との間における前記第１セッションの間における前記低下した帯域幅の状態を検出するためにセッションのクオリティをモニターし；」とは、
　「前記パケット損失をモニターすることにより、前記通信装置と前記リモートセッション装置との間における前記第１セッションの間における低下した帯域幅の状態を検出するためにセッションのクオリティをモニターし；」の点で一致する。                 
　
　（エ）また、引用発明の「より低いビットレートのコーデックを選択」することは、音声、画像、データの圧縮における品質を下げ、データの圧縮率を上げる、すなわち圧縮比率を増大することを意味することは当業者の技術常識であるから、補正後の発明の「増大した圧縮比率」を使用することに相当する。したがって、引用発明の
　「前記音声、映像またはデータのセッションの間における前記ネットワークの輻輳を検出すると、より低いビットレートのコーデックを選択して、他の通信装置と通信し、」は、補正後の発明の
　「前記第１セッションの間における前記低下した帯域幅の状態を検出すると、増大した圧縮比率を使用して、前記第１セッションの間における前記リモートセッション装置と通信し；」と差異がない。
　
　（オ）また、引用発明の「パケット損失がスローダウンを必要とせず、スピードアップ閾値を下回る場合」と、補正後の発明の「所定の時間周期の後」とは、「所定の条件を満たす」こととして共通である。そして、引用発明の「より高いビットレートのコーデック」とは、圧縮における品質を良くし、データの圧縮比率を下げることを意味することは上記と同様に当業者の技術常識であるから、補正後の発明の「前記増大した圧縮比率のない標準的な様式」とは、「前記増大した圧縮比率を下げる」点で一致する。したがって、引用発明の
　「パケット損失がスローダウンを必要とせず、スピードアップ閾値を下回る場合に、より高いビットレートのコーデックにおける前記音声、映像またはデータのセッションの間における前記他の通信装置と通信する」ことは、補正後の発明の
　「所定の時間周期の後、前記増大した圧縮比率の無い標準的な様式における前記第１セッションの間における前記リモートセッション装置との通信に復帰する」ことと、
　「所定の条件を満たす際、前記増大した圧縮比率を下げ、前記第１セッションの間における前記リモートセッション装置との通信する」点で一致する。
　
  したがって、両者は以下の点で一致し、また相違している。
　
　（一致点）
　「通信装置であって、
　第１セッションを介してリモートセッション装置と通信し
　前記リモートセッション装置との通信に関連するパケット損失であって、前記パケット損失が所定の閾値を超過するとき、低下した帯域幅の状態を検出するようにして；
　前記パケット損失をモニターすることにより、前記通信装置と前記リモートセッション装置との間における前記第１セッションの間における低下した帯域幅の状態を検出するためにセッションのクオリティをモニターし；
　前記第１セッションの間における前記低下した帯域幅の状態を検出すると、増大した圧縮比率を使用して、前記第１セッションの間における前記リモートセッション装置と通信し；
　所定の条件を満たす際、前記増大した圧縮比率を下げ、前記第１セッションの間における前記リモートセッション装置との通信する通信装置。」
　
　（相違点）
　（１）「通信装置」に関し、
　補正後の発明では、「通信インターフェース」を備え、「該通信インターフェースに関連する制御システム」をも備えるのに対し、引用発明では、通信インターフェース及び該通信インターフェースに関連する制御システムを備えるか不明である点
　（２）「モニター」する対象に関し、
　補正後の発明では、「パケット損失と、パケット遅延と、ジッタとをモニター」し、「パケット遅延」、「ジッタ」に対しても、「所定の閾値を超過するとき、低下した帯域幅の状態を検出」しているのに対し、
　引用発明では、「パケット損失をモニター」しており、その他についてモニターしていない点。
　（３）「所定の条件を満たす際、前記増大した圧縮比率を下げ、前記第１セッションの間における前記リモートセッション装置との通信」するに関し、
　補正後の発明では、「所定の時間周期の後、前記増大した圧縮比率の無い標準的な様式における前記第１セッションの間における前記リモートセッション装置との通信に復帰」するのに対し、
　引用発明では、「パケット損失がスローダウンを必要とせず、スピードアップ閾値を下回る場合に、より高いビットレートのコーデックにおける前記音声、映像またはデータのセッションの間における前記他の通信装置と通信」する点。
　　
　［判断］
　上記相違点（１）について検討する。
　引用発明では、通信装置と他の通信装置が通信をすることから、一般的な「通信インターフェース」を備えることや、当該通信インターフェースを制御する、CPU等何らかの構成を備えることもまた自明であり、当該制御する構成を制御システムと呼ぶことは任意である。そして、引用発明におけるパケット損失をモニターする構成やモニター結果を閾値と比較し、コーデックの選択等を前記制御システムで行うよう構成することも格別のものでない。　
　したがって、相違点（１）は格別でない。
　
　上記相違点（２）について検討する。
　通信端末間の通信量が増加した際に、より圧縮効率が高いデータに圧縮率を変換して通信する通信端末において、通信量の増加を、パケット損失のみならず、パケット遅延、ジッタにより検出することは、普通に行われていることである。(例えば、原査定の拒絶の理由で示した文献（特開平１１−２９８５２８号公報（特に、【００３４】−【００４０】及び図４参照。））や特開２００２−２０４２７８号公報（特に、【００５０】及び図１１参照。））
　したがって、引用発明においても、モニターする対象をパケット損失のみならず、パケット損失と、パケット遅延と、ジッタとすることは当業者が適宜なし得るものである。
　
　次に、相違点（３）について検討する。
　ネットワークの輻輳が生じた際に、所定の輻輳制御処理を行うとともに、タイマを起動し、タイマが所定時間を計測したときに通常動作状態、すなわち、所定の輻輳制御処理を行う前の状態に復帰させることは、当業者に周知（例えば、特開平７−１４７５９２号公報(特に、【０００５】、【００４５】、【００４６】及び図１０、１１参照。））の構成であるから、相違点（３）は格別のものではない。
　         　
　そして、補正後の発明の作用効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、補正後の発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
３．むすび
　以上のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１．本願発明
　本件補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。　
  　
２．引用発明
　引用発明は、上記「第２　補正却下の決定」の「（２−２）　引用発明」の項で認定したとおりである。
　
３．対比・判断
　本願発明は、上記補正後の発明から当該補正に係る構成を省いたものである。
　
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加又は限定した補正後の発明が、上記「第２　補正却下の決定」の「（２−３）対比・判断」の項に記載したとおり、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。