【事件の表示】
　特願２００１−５７１６１０「マルチメディアデータ送受信装置及び方法」拒絶査定不服審判事件〔平成１３年１０月　４日国際公開、ＷＯ０１／７４０１２、平成１５年　９月３０日国内公表、特表２００３−５２９２８９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１２年１２月３０日（パリ条約による優先権主張２０００年３月２９日、米国）を国際出願日とする出願であって、平成１７年３月２８日付けで拒絶査定がなされ、これに対し、同年７月４日に拒絶査定に対する審判請求がなされるとともに同年７月２８日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成１７年７月２８日付けの手続補正を却下する。
　
［理由］
１．補正後の本願発明
　上記手続補正（以下、「本件補正」という。）は補正前の特許請求の範囲の請求項１に記載された発明を、
「無線パケット網でマルチメディアデータ送信または／及び受信システムにおいて、
　(a) ＲＴＰレーヤー直前でソースデータをパケット化する過程と、
　(b) 前記(a)過程でパケット化された一つまたはそれ以上のソースパケットに対して不均等エラープロテクションしたエラープロテクションパケットを付加する過程と、
　(c) 前記ソースパケットとエラープロテクションパケットを追加してＲＴＰパケットに生成する過程と
を含むマルチメディアデータ伝送方法。」
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１に記載された「ソースデータをパケット化する過程」の時期を「ＲＴＰレーヤー直前で」と限定して特許請求の範囲を減縮するものであるから、特許法第１７条の２第３項（新規事項）及び第４項（補正の目的）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．補正後の本願発明」の項で認定したとおりである。
　
（２）引用発明及び周知技術
　Ａ．原審の拒絶理由に引用された Jill M. Boyce，「Packet loss resilient transmission of MPEG video over the Internet」，Signal Processing: Image Communication，Elsevier Science B.V.，1999年9月，Vol. 15，Issues 1-2，p.7-24（以下、「引用例」という。）には図面とともに以下の事項（イ、ロ）が記載されている。
　イ．「1. Introduction
　Lately, there has been much interest in transmitting real-time audio and video over the Internet, using the Internet protocol (IP). For interactive applications such as video conferencing, which require low delay, Universal Datagram Protocol (UDP) [13] is generally used rather than Transmission Control Protocol (TCP). The real-time transport protocol (RTP) and the Internet multicast backbone, or MBone [14], use UDP transmission. Because UDP is an unreliable protocol, network packet losses occur, and they adversely affect the quality of received audio and video.
・・・中略・・・
 In this paper, a method is proposed to improve the quality of received MPEG video in the presence of network packet loss.」（７頁左欄１行〜８頁左欄１３行）
（邦訳）
「１．序論
　最近、インターネット・プロトコル（ＩＰ）によって、インターネットを経由してリアルタイムのオーディオとビデオを送ることに多くの関心が集まっている。低遅延が必要とされるテレビ会議のような対話型アプリケーションについては、伝送制御プロトコル（ＴＣＰ）ではなくて、ユニバーサル・データグラム・プロトコル（ＵＤＰ）［１３］が一般に用いられる。リアルタイム・トランスポート・プロトコル（ＲＴＰ）とインターネット・マルチキャスト・バックボーン、またはＭＢｏｎｅ［１４］では、ＵＤＰ伝送を用いる。ＵＤＰは信頼性のないプロトコルであるため、ネットワーク・パケット損失が起こり、そのために受信したオーディオとビデオの品質が悪影響を受ける。
・・・中略・・・
　本論文は、ネットワーク・パケットの損失が存在する場合に、受信MPEGビデオの品質を向上させるための方法を提案するものである。」
　ロ．「A suggestion was made in [24] to combine media-specific and media-independent techniques by applying the media-independent FEC techniques to the most significant bits of a coder's output, rather than applying FEC over the entire multimedia bitstream. If data partitioning was used to separate the “most significant” bits of the video bitstream, the high-priority partition alone could be protected. Fig. 2 shows an example of the packetization of video data using this approach, which is sometimes referred to as Unequal Error Protection. 
　3. Description of the HiPP method
　In the HiPP method, a data splitting function similar to MPEG-2 data partitioning is performed on an MPEG video stream in order to split it into a high-priority partition and a low-priority partition. Reed-Solomon forward error correction coding is performed only on the high priority partition. By limiting the application of the forward error correction to only the high-priority partition, the overhead requirement is reduced for protection against given packet loss rates.
　The high-priority protection method uses a concept similar to MPEG-2 data partitioning, but does not require network support for prioritization, as in [3]. In MPEG-2 data partitioning, the video bitstream is split into two layers - a base layer, also referred to as the high-priority (HP) partition, and an enhancement layer, also referred to as the low-priority (LP) partition. The more critical parts of the bitstream (such as headers, motion vectors, low-frequency DCT coefficients) are allocated to the HP partition, and the less critical data (such as higher frequency DCT coefficients) are allocated to the LP partition. A priority breakpoint is chosen for each slice, which determines which codeword types are arranged into which partition. Sequence, GOP, and picture headers are redundantly copied into both partitions for error resilience.」（１１頁左欄２３行〜同頁右欄２４行）
（邦訳）
　「メディアに特有の技術とメディアに無関係の技術を結合するために、[２４]の提案がなされた。それはＦＥＣをマルチメディア全体のビットストリームにわたって適用するのではなく、メディアと無関係のＦＥＣ技術をコーダの出力で最も有意なビットに適用することによる。ビデオ・ビットストリームの「最も有意な」ビットを切り離すために、データが分割されたのであれば、優先度の高い部分だけを保護することはできた。図２は、このアプローチによるビデオデータのパケット化の例を示しており、それは時々、不均等エラープロテクションと呼ばれる。 
　３．　ＨｉＰＰ方法の説明 
　ＨｉＰＰ方法では、高優先度の部分と低優先度の部分に分けるために、ＭＰＥＧ−２データ分割と同様のデータを分ける機能がＭＰＥＧビデオストリームについて発揮される。リードソロモン前方誤り訂正コーディングは、高優先度の部分についてのみ行われる。前方誤り訂正の適用を高優先度の部分のみに制限することにより、一定のパケット損失率に対する保護についてオーバーヘッドの要求は減少する。
　高優先度の保護方法は、ＭＰＥＧ−２データ分割と同様の概念を用いるが、[３]の場合のように、優先順位に関してネットワーク・サポートを必要としない。ＭＰＥＧ−２データ分割においては、ビデオ・ビットストリームは２層に分けられる。すなわち、基層，または高優先度（ＨＰ）の部分とも呼ばれるもの、及び、強化層，または低優先度（ＬＰ）の部分とも呼ばれるもの、である。より重要なビットストリームの部分（例えば、ヘッダ、動きベクトル、低周波ＤＣＴ係数）は、ＨＰ部分に割り当てられる。そして、重要度の低いデータ（例えば、高周波数のＤＣＴ係数）は、ＬＰ部分に割り当てられる。優先度の区切り点は、スライスごとに選ばれ、どのコードワードのタイプがどの部分に配置されるかを決定する。シーケンス、ＧＯＰ及び画像ヘッダは、エラー回復のために両方の部分に冗長にコピーされる。」
　
　上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると、上記イ．には、パケット網であるインターネットを経由してオーディオとビデオを送信する際に、リアルタイム・トランスポート・プロトコル（ＲＴＰ）を用いること、及び、ネットワークパケットの損失が認められる場合に、受信ＭＰＥＧビデオの品質を向上させるという課題が開示されている。
　また、上記ロ．には、前方誤り訂正（ＦＥＣ）を、コーダの出力で最も有意なビットに適用すること、及びそれは不均等エラープロテクション（Ｕｎｅｑｕａｌ　Ｅｒｒｏｒ　Ｐｒｏｔｅｃｔｉｏｎ）と呼ばれることが記載されている。さらに、伝送する対象であるビデオ・ビットストリームをより重要なビットストリームの部分の高優先度（ＨＰ）の部分と、重要度の低いデータである低優先度（ＬＰ）の部分の２層に分け、高優先度の部分についてのみリードソロモン前方誤り訂正コーディングを行う伝送方法が記載されている。
　さらに、図２、図６を参照すると、伝送されるパケットに対して、高優先度（ＨＰ）の部分に対するパリティのみをペイロードとするパケットが追加されていることが理解できる。
　そして、上記引用例に記載された、オーディオとビデオに対する各操作は、パケット網であるインターネットを経由して、オーディオとビデオを伝送する方法における過程であるということができる。
　したがって、上記引用例には以下の発明（以下、「引用発明」という。）が開示されている。
　「パケット網でオーディオ信号とビデオ信号を送信する際に、
　該オーディオ信号とビデオ信号に対して不均等エラープロテクションしたパリティのパケットを付加する過程と、
　該オーディオ信号とビデオ信号のうちエラープロテクションされた部分のパケットと、エラープロテクションされていない部分のパケットと、パリティのパケットを追加してパケットに生成する過程と
　を含むオーディオ信号とビデオ信号伝送方法。」
　
　また、例えば、ＩＥＴＦが技術標準であるＲＦＣとして１９９９年１２月に発行した J. Rosenberg, H. Schulzrinne，「An RTP Payload Format for Generic Forward Error Correction」，INTERNET SOCIETY, Network Working Group, Request for Comments: 2733, Category: Standards Track, December 1999 URL: http://www.ietf.org/rfc/rfc2733.txt （以下、「周知例」という。）には、図面とともに以下の事項（イ〜ホ）が記載されている。
　イ．「1 Introduction
　
The quality of packet voice on the Internet has been mediocre due, in part, to high packet loss rates. This is especially true on wide-area connections. Unfortunately, the strict delay requirements of real-time multimedia usually eliminate the possibility of retransmissions.
　
It is for this reason that forward error correction (FEC) has been proposed to compensate for packet loss in the Internet [1] [2]. In particular, the use of traditional error correcting codes, such as parity, Reed-Solomon, and Hamming codes, has attracted attention. To support these mechanisms, protocol support is required.
　
This document defines a payload format for RTP [3] which allows for generic forward error correction of real time media. In this context, generic means that the FEC protocol is (1) independent of the nature of the media being protected, be it audio, video, or otherwise, (2) flexible enough to support a wide variety of FEC mechanisms, (3) designed for adaptivity so that the FEC technique can be modified easily without out of band signaling, and (4) supportive of a number of different mechanisms for transporting the FEC packets.」（２頁１２行〜２９行）
（邦訳）
「１　序論
インターネット上のパケット音声の品質は、高いパケット損失率のせいもあって、あまり良くない。これは、広域接続で特にそうである。不運にも、リアル・タイム・マルチメディアの厳密な遅延要求は、通常、再送信の可能性を排除する。
　
この理由から、インターネットのパケット損失を補償するために、前方誤り訂正（ＦＥＣ）が提案された［１］［２］。パリティー、リード・ソロモン及びハミング・コードのような従来の誤り訂正符号の使用は、特に注目された。これらのメカニズムをサポートするために、プロトコル・サポートが必要である。
　
この文書は、リアルタイムメディアの一般的な前方誤り訂正を考慮に入れるＲＴＰ［３］のためのペイロードフォーマットを定義する。この文脈において、「一般的な」の意味するところは、ＦＥＣプロトコルが、（１）それがオーディオであれ、ビデオであれ、その他のものであれ、保護されているメディアの性質と無関係であること、（２）種々様々のＦＥＣメカニズムをサポートするために十分に柔軟であること、（３）このＦＥＣ技術はアウトバンド・シグナリングなしで、容易に修正することができるように、適応性のために設計されたこと、（４）ＦＥＣパケットを輸送するための多くの異なるメカニズムのサポートがあること、である。」
　
　ロ．「3 Basic Operation
　
   The payload format described here is used whenever a participant in an RTP session would like to protect a media stream it is sending with forward error correction (FEC). The FEC supported by the format are those codes based on simple exclusive or (xor) parities. The sender takes some set of packets from the media stream, and applies an xor operation across the payloads. The sender also applies the xor operation over components of the RTP headers. Based on the procedures defined here, the result is an RTP packet containing FEC information. This packet can be used at the receiver to recover any one of the packets used to generate the FEC packet. This document does not mandate the particular set of media packets combined to generate an FEC packet (such a set [is] referred to as a code). Use of differing sets results in a tradeoff between overhead, delay, and recoverability.  Section 4 outlines some possible combinations.」（３頁１６行〜３０行）
（邦訳）
　「３　基本操作
　
ＲＴＰセッションの参加者が前方誤り訂正（ＦＥＣ）で送っているメディア・ストリームを保護したい場合は、常にここで記述されたペイロードフォーマットが使用される。このフォーマットにサポートされたＦＥＣは単純な排他的論理和（ｘｏｒ）パリティーに基づいたコードである。送信側は、メディアストリームからいくつかのパケットのセットを得て、いくつかのペイロードを横切ってｘｏｒ演算を行う。送信側は、さらにＲＴＰヘッダーのコンポーネント上のｘｏｒ演算を行う。ここで定義された手続きに基づくと、その結果はＦＥＣ情報を含んだＲＴＰパケットである。このパケットはＦＥＣパケットを生成するために使用されるパケットのうちのどれか１つを回復するために受信側で使用することができる。この文書は、ＦＥＣパケットを生成するために結合したメディアパケットの特別のセットを指定するものではない（そのようなセット［は］コードと呼ばれる）。異なるセットの使用は、オーバーヘッドと遅延及び回復力の間のトレードオフに帰着する。セクション４では、いくつかの可能なコンビネーションを概説する。」
　
　ハ．「As the sender generates FEC packets, they are sent to the receivers. The sender still usually sends the original media stream, as if there were no FEC. This allows the media stream to still be used by receivers who are not FEC capable. However, some FEC codes do not require the original media to be sent; the FEC stream is sufficient for recovery. These codes have the drawback that all receivers must be FEC capable. However, they are supported by this format.」（４頁６行〜１２行）
（邦訳）
　「送信側はＦＥＣパケットを生成するとともに、受信側へ送信する。送信側は、あたかもＦＥＣがないかのように通常は従来どおりオリジナルのメディアストリームを送信する。これは、メディアストリームが、ＦＥＣが利用可能でない受信側によって従来どおり使用されることを可能にする。しかしながら、いくつかのＦＥＣコードは、ＦＥＣストリームが回復に十分である場合に、オリジナルのメディアが送信されることを要求しない。これらのコードは、全ての受信側がＦＥＣを利用可能でなければならないという欠点を持っているが、それらはこのフォーマットにサポートされる。」
　
　ニ．「4 Parity Codes
　
   For brevity, we define the function f(x,y,..) to be the XOR (parity) operator applied to the packets x,y,... The output of this function is another packet, called the parity packet. For simplicity, we assume here that the parity packet is computed as the bitwise XOR of the input packets. The exact procedure is specified in section 6.
　
   Recovery of data packets using parity codes is accomplished by generating one or more parity packets over a group of data packets.
   To be effective, the parity packets must be generated by linearly independent combinations of data packets. The particular combination is called a parity code. One class of codes takes a group of k data packets, and generates n-k parity packets. There are a large number of possible parity codes for a given n,k. The payload format does not mandate a particular code.
　
   For example, consider a parity code which generates a single parity packet over two data packets. If the original media packets are a,b,c,d, the packets generated by the sender are:
　
　a　　　　b　　　　c　　　　d　　　　　　　　　-- media stream
　　　　　　f(a,b)　　　　　　　f(c,d)　　　　　-- FEC stream
　
   where time increases to the right. In this example, the error correction scheme (we use the terms scheme and code interchangeably) introduces a 50% overhead. But if b is lost, a and f(a,b) can be used to recover b.」（５頁１行〜２３行）
（邦訳）
　「４　パリティコード
簡潔さのために、我々は、パケットｘ（ｙ）．．．にＸＯＲ（パリティー）演算子が適用されたものとして関数ｆ（ｘ（ｙ）．．）を定義する。この関数の出力はパリティーパケットと呼ばれる別のパケットである。単純さのために、我々は、パリティーパケットが入力パケットのビット演算のＸＯＲとして計算されると仮定する。正確な手続きはセクション６で詳細に述べる。
　
パリティコードを使用するデータ・パケットの回復は、データパケットのグループに関する１つ以上のパリティーパケットの生成により遂行される。効果的にするために、パリティーパケットは、データパケットの一次独立コンビネーションによって生成しなければならない。特定のコンビネーションはパリティコードと呼ばれる。コードの１つのクラスは、ｋ個のデータパケットのグループをとる。また、そのコードはｎ−ｋ個のパリティーパケットを生成する。与えられたｎ、ｋについて多くの可能なパリティコードがある。ペイロードフォーマットは特別のコードを指定しない。
　
例えば、２つのデータパケット上に単一のパリティーパケットを生成するパリティコードを考える。オリジナルのメディアパケットがａ、ｂ、ｃ、ｄ、である場合、送信側によって生成されたパケットは次のとおりである：
　
ａ　　　　ｂ　　　　ｃ　　　　ｄ　　　　　 ＜−−メディアストリーム
　　　　　　ｆ(ａ,ｂ)　　　　　 ｆ(ｃ,ｄ)　＜−−ＦＥＣストリーム
　
　ここで時間は右に増加する。この例において、エラー訂正スキーム（我々は、スキーム、コードという用語を交換可能に使用する）は、５０％のオーバーヘッドを導入する。しかし、ｂが失われる場合、ａとｆ（ａ，ｂ）はｂを回復するために使用することができる。」
　
　ホ．「6 FEC Packet Structure
　
   An FEC packet is constructed by placing an FEC header and FEC payload in the RTP payload, as shown in Figure 1:」（７頁１行〜３行）
（邦訳）
　「６　ＦＥＣパケット構造
　
　１つのＦＥＣパケットは、図１に示されているように、ＲＴＰペイロード中にＦＥＣヘッダーとＦＥＣペイロードが配置されて組み立てられている。」
　
　上記周知例のイ．によれば、当該周知例はインターネット上でマルチメディアデータをパケット通信する際に、パケットの損失を補償する誤り訂正を行うことに関している。また、ロ．には、ＲＴＰにおいて前方誤り訂正（ＦＥＣ）で送信しているメディアストリームを保護すること、送信側は、メディアストリームからいくつかのパケットのセットを得て、いくつかのペイロードを横切ってＦＥＣに係る演算を行うこと、が記載されている。ハ．には、オリジナルのメディアパケットと、生成されたＦＥＣパケットがそれぞれ送受信されることが記載されている。ニ．には、複数のメディアパケットに対してＦＥＣパケットが生成されることが記載されている。また、ホ．の記載及び図１は、ＦＥＣパケットが生成された直後にＲＴＰパケットが生成されることを示しており、このことから、ＲＴＰレーヤー直前でＦＥＣが行われることが理解できる。
　また、前方誤り訂正（ＦＥＣ）はエラープロテクションの一形態である。
　
　したがって、上記周知例に開示されているように、「ＲＴＰレーヤー直前でマルチメディアデータをパケット化し、該パケット化された複数のメディアパケットに対してＦＥＣパケットを生成し、メディアパケットとＦＥＣパケットをＲＴＰパケットに生成すること」は周知技術と認められる。
　
（３）対比・判断
　補正後の発明と引用発明とを対比すると、
　ａ．引用発明の「パケット網」と補正後の発明の「無線パケット網」は「パケット網」である点で一致し、
　ｂ．引用発明の「オーディオ信号とビデオ信号」と補正後の発明の「マルチメディアデータ」は「マルチメディアデータ」である点で一致し、
　ｃ．引用発明の「オーディオ信号とビデオ信号」と補正後の発明の「ソースデータ」は、引用発明の「オーディオ信号とビデオ信号」が、送信するデータのうち送信のための操作を行う前のデータであることが明らかであるから、「ソースデータ」である点で一致し、
　ｄ．引用発明の「パリティのパケット」と補正後の発明の「エラープロテクションパケット」は、本願の発明の詳細な説明の記載からみて、補正後の発明のエラープロテクションパケットがＦＥＣ過程で生成されたパリティのパケットであることを考慮すると、両者は「エラープロテクションパケット」である点で一致し、
　ｅ．引用発明の「該オーディオ信号とビデオ信号に対して不均等エラープロテクションしたパリティのパケットを付加する過程」と補正後の発明の「一つまたはそれ以上のソースパケットに対して不均等エラープロテクションしたエラープロテクションパケットを付加する過程」は、上記ｃ．ｄ．でした対比の結果を考慮すると「ソースデータに対して不均等エラープロテクションしたエラープロテクションパケットを付加する過程」である点で一致し、
　ｆ．引用発明の「該オーディオ信号とビデオ信号のうちエラープロテクションされた部分のパケットと、エラープロテクションされていない部分のパケットと、パリティのパケットを追加してパケットに生成する過程」と補正後の発明の「前記ソースパケットとエラープロテクションパケットを追加してＲＴＰパケットに生成する過程」は、上記ｂ．ｄ．でした対比の結果を考慮すると「マルチメディアデータをパケット化したものとエラープロテクションパケットを追加してパケットに生成する過程」である点で一致する。
　
　したがって、補正後の発明と引用発明は、以下の点で一致ないし相違している。
（一致点）
　「パケット網でマルチメディアデータを送信する際に、
　ソースデータに対して不均等エラープロテクションしたエラープロテクションパケットを付加する過程と、
　マルチメディアデータをパケット化したものとエラープロテクションパケットを追加してパケットに生成する過程
　を含むマルチメディアデータ伝送方法。」
　
（相違点１）「パケット網」に関し、補正後の発明では「無線パケット網」であるのに対し、引用発明ではパケット網の種類が特定されていない点。
（相違点２）「ソースデータに対して不均等エラープロテクションした」に関し、補正後の発明では、該エラープロテクションの前に「ＲＴＰレーヤー直前でソースデータをパケット化する過程」を有し、該エラープロテクションされる対象が、ソースデータがパケット化された「一つまたはそれ以上のソースパケット」であるのに対し、引用発明では、該パケット化する過程を有しておらず、エラープロテクションの対象が、パケット化されていない「ソースデータ」である点。
（相違点３）「マルチメディアデータをパケット化したもの」に関し、補正後の発明では、マルチメディアデータがパケット化された「ソースパケット」であるのに対し、引用発明では、「マルチメディアデータのうちエラープロテクションされた部分のパケットと、エラープロテクションされていない部分のパケット」である点。
（相違点４）「パケットに生成する過程」に関し、補正後の発明では、「ＲＴＰパケット」に生成しているのに対し、引用発明では、生成されるパケットの種類が特定されていない点。
　
　そこで、まず、上記相違点１の「パケット網」について検討するに、例えば特開２０００−７８１９７号公報、特開２０００−３２０５５号公報、特開２０００−６９５３１号公報に開示されているように、無線パケット網でマルチメディアデータを伝送するシステム、及び方法は既に周知であるから、引用発明における「パケット網」として、無線パケット網を採用することは、当業者であれば適宜なし得ることである。
　次いで、上記相違点２ないし４について検討するに、上記周知例の「メディアパケット」「ＦＥＣパケット」は補正後の発明の「ソースパケット」「エラープロテクションパケット」にそれぞれ相当するから、上記周知技術は「ＲＴＰレーヤー直前でマルチメディアデータをパケット化し、該パケット化された複数のソースパケットに対してエラープロテクションパケットを生成し、ソースパケットとエラープロテクションパケットをＲＴＰパケットに生成すること」と言い換えることができる。そして、引用発明において、「不均等エラープロテクション」するための入力データの形式及び出力データの形式に上記周知技術を適用する上での阻害要因は何ら見あたらないから、入力データ（相違点２）について、「ＲＴＰレーヤー直前でマルチメディアデータをパケット化する過程」を設け、該パケット化された「複数のソースパケット」に対して不均等エラープロテクションを行うようにすること、及び、出力データ（相違点３、４）について、「ソースパケットとエラープロテクションパケットを追加してＲＴＰパケットに生成する」ようにすることは、当業者であれば容易になし得ることである。
　また、補正後の発明に係る「無線パケット網でマルチメディアデータ送信または／及び受信システム」は、「または／及び」で関連づけられる事項であるから、当該構成については、その一方の「無線パケット網でマルチメディアデータ送信システム」について検討すれば充分である。
　そして、補正後の発明の作用効果も、引用発明、及び周知技術から当業者が予測できる範囲のものである。
　
　以上のとおり、補正後の発明は引用発明及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１７年７月２８日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１６年１１月３０日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　「無線パケット網でマルチメディアデータ送信または／及び受信システムにおいて、
　(a) ソースデータをパケット化する過程と、
　(b) 前記(a)過程でパケット化された一つまたはそれ以上のソースパケットに対して不均等エラープロテクションしたエラープロテクションパケットを付加する過程と、
　(c) 前記ソースパケットとエラープロテクションパケットを追加してＲＴＰパケットに生成する過程と
を含むマルチメディアデータ伝送方法。」
　
２．引用発明及び周知技術
　引用発明及び周知技術は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明及び周知技術」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明及び周知技術に基づいて容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。