• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1312683
審判番号 不服2015-3796  
総通号数 197 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-05-27 
種別 拒絶査定不服の審決 
審判請求日 2015-02-27 
確定日 2016-03-23 
事件の表示 特願2013- 3347「インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法」拒絶査定不服審判事件〔平成25年 5月 9日出願公開、特開2013- 85293〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本件出願は,2006年12月21日を国際出願日とする特願2009-542741号の一部を平成25年1月11日に新たな特許出願としたものであって,平成26年1月8日付け拒絶理由通知に対して同年4月18日に意見書及び手続補正書が提出されたが同年10月23日付けで拒絶査定がなされ,これを不服として平成27年2月27日付けで審判請求がなされるとともに手続補正書が提出されたものである。

第2 補正却下の決定
[補正却下の決定の結論]
平成27年2月27日に提出された手続補正書による手続補正(以下,「本件補正」という。)を却下する。

[理由]
1 本願発明と補正後の発明
本件補正は,平成26年4月18日に提出された手続補正書の特許請求の範囲の請求項1に記載された

「リアルタイムメディアパケットを保護する方法であって,
リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し,
前記メディアパケットを並び替え,複数の列及び複数の行の2次元行列を形成し,
前記メディアパケットからメディアビット列を生成し,
前記生成されたメディアビット列のそれぞれの終端で,前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし,
それぞれパディングされたビット列が最も長いビット列の長さを有するように,以前にパディングされたビット列の終端で更にパディングし,
前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し,
複数の前方誤り訂正ビット列を生成し,
前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し,
前記生成された前方誤り訂正パケットを送信し,ただし,前記前方誤り訂正パケットは,インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記2次元行列の列のインデックスを表す次元により分離され,
前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し,
前記前方誤り訂正パケットは,前記メディアパケットのフォーマットを変更せずに生成され,前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され,非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする方法。」

という発明(以下,「本願発明」という。)を,補正後の特許請求の範囲の請求項1に記載された

「リアルタイムメディアパケットを保護する方法であって,
リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し,
前記メディアパケットを並び替え,複数の列及び複数の行の2次元行列を形成し,
前記メディアパケットからメディアビット列を生成し,
前記生成されたメディアビット列のそれぞれの終端で,前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし,
それぞれパディングされたビット列が最も長いビット列の長さを有するように,以前にパディングされたビット列の終端で更にパディングし,
前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し,
複数の前方誤り訂正ビット列を生成し,
前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し,ただし,前方誤り訂正パリティパケットインデックスの最上位の数ビットが第3のインデックスフィールドに挿入され,
前記生成された前方誤り訂正パケットを送信し,ただし,前記前方誤り訂正パケットは,インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記2次元行列の列のインデックスを表す次元により分離され,
前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し,
前記前方誤り訂正パケットは,前記メディアパケットのフォーマットを変更せずに生成され,前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され,非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする方法。」

という発明(以下,「補正後の発明」という。)に変更することを含むものである。

2 新規事項の有無,補正の目的要件について
本件補正は,願書に最初に添付した明細書,特許請求の範囲若しくは図面に記載した事項の範囲内において,補正前の特許請求の範囲の請求項1に記載された「前方誤り訂正パケット」について「前方誤り訂正パリティパケットインデックスの最上位の数ビットが第3のインデックスフィールドに挿入され」る点を付加して限定することにより特許請求の範囲を限定的に減縮するものであって,特許法第17条の2第3項(新規事項)及び特許法第17条の2第4項第2号(補正の目的)の規定に適合している。

3 独立特許要件について
上記補正は特許請求の範囲の減縮を目的とするものであるから,上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。

(1)補正後の発明
上記「1 本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。

(2)引用発明
原査定の拒絶の理由に引用されたPro-MPEG Code of Practice #3 release 2,2004年 7月,p.1,5-11,14,URL,http://www.pro-mpeg.org/documents/wancop3.pdf(以下,「引用例」という。)には,以下の事項が記載されている。

ア 「4.5 FEC Scheme

4.5.1 Background

・・・(中略)・・・
The biggest issue with FEC systems on IP networks is that, because of the UDP checksums, channel bit errors get translated into packet losses. In addition to this, buffer and re-route issues cause burst packet losses. The combination of packet losses from the three sources - gross reordering, bit-error induced losses and burst losses needs to be low enough so that the FEC scheme is not broken more than the negotiated error rate. Because any bit errors cause the packet to be discarded there is no requirement for an error correction scheme that can handle errored packets - every packet will either arrive correct or not at all.

An RTP payload format for Generic Forward Error Correction Packets has been defined in the RFC 2733 to enable error correction of real time media. This standard allows the use of traditional error correcting codes. A major advantage of this scheme is that it can be used with any video formats standards (MPEG, SDI, SDTI, ...) as long as it is encapsulated in a RTP packet. However, this standard limits the scope of packets used to generate the Forward Error Correction payload, to 24 consecutive packets.
(当審仮訳:
4.5 FECスキーム

4.5.1 背景

・・・(中略)・・・
IPネットワーク上でのFECシステムに関する最大の問題は,UDPチェックサムのため,チャネルビットエラーがパケット損失に変換されることである。これに加え,バッファと経路切替問題によりバースト的なパケット損失を引き起こす。3つの原因-大雑把な再順序付け,ビットエラーに基づく損失,バースト損失,によるパケット損失を組合せたものは,取り決められたエラーレートを超えてFECスキームが破壊されることがないよう十分に低くなる必要がある。どのようなビットエラーによってもパケットが廃棄されるので,エラーを含むパケットを処理できるような誤り訂正スキームは必要ない-全てのパケットは正しいまま到着するか,全く到着しないかのどちらかである。

リアルタイムメディアの誤り訂正を可能にするために,既存の前方誤り訂正パケットのためのRTPペイロードフォーマットがRFC2733で定義されている。この標準は,旧来からの誤り訂正符号の利用を許容する。この標準の主な利点は,それがRTPパケットにカプセリング可能なものである限り,どのようなビデオフォーマット標準(MPEG,SDI,SDTI,...)に対しても使えることである。しかしながら,この標準は,前方誤り訂正ペイロードを生成するために用いられるパケットの範囲を24個の連続したパケットに限定する。)」(5頁)

イ「4.5.2 FEC packet arrangement

To recover burst loss, an extension to the existing RFC is proposed. The same traditional error correcting codes are applied to non-consecutive media packets that can be spaced of more than 24 packets. Each FEC packet is associated to packets periodically selected. Therefore, consecutive RTP packets can be recovered from consecutive FEC packets. The process is detailed in Figure 1.

(図1:省略)
Fig.1 Encoding scheme…

In Figure 1, the encoding scheme is schematized for L*D media packets. The period chosen is L. Thus the payload of the k^(th) FEC packet is computed based on the D packets numbered nL+k (0≦n≦D - 1).

・・・(中略)・・・

The main advantage of this scheme is the burst error correction capacity. The error correcting function chosen is XOR which has the ability to recover any one lost packet . If a one dimensional scheme based on XOR is used (i.e. applied to D consecutive packets), a burst error of two or more lost packets is not recoverable. However, if the two dimensional scheme is used, the recoverability is greatly improved, since it can recover up to L consecutive packets.

Though this scheme is very robust to bursts of packet losses (it corrects L consecutive packets lost), if only 2 packets are lost and these packets are in the same column, there is no way to correct these losses. It is therefore recommended that two simultaneous FEC streams should be supported, which will allow for a far higher correction capability, at the expense of increased overhead. These FEC streams shall be carried on separate UDP ports, to allow them to have separate sequence number handling, and to maintain backward compatibility with previous implementations that only supported a single (column) FEC stream.

The first port shall carry the column FEC stream and the second port shall carry the row FEC stream.
(当審仮訳:
4.5.2 FECパケット配列

バースト損失を回復するため,既存のRFCに対する拡張を提案する。同じ旧来の誤り訂正符号が24パケット以上に亘って配置される非連続的なメディアパケットに適用される。各FECパケットは周期的に選択されるパケットに関連している。そのため,連続したFECパケットから連続したRTPパケットが回復できる。この過程は図1に詳説される。

(図1:省略)
図1.符号化スキーム...

図1において,符号化スキームがL*Dのメディアパケットについて図式化されている。選ばれた周期はLである。このように,k番目のFECパケットのペイロードはnL+k (0≦n≦D - 1)と番号付けられたD個のパケットに基づいて計算される。

・・・(中略)・・・

このスキームの主な利点は,バースト的な誤り訂正能力である。選択された誤り訂正機能はXORでどのような1パケットでも回復できる能力がある。もしも,XORに基づく1次元方式が適用された場合(すなわち,D個の連続したパケットに適用された場合),2個またはそれ以上の損失パケットが生じるバーストエラーは回復できない。しかしながら,2次元方式が使われれば,L個の連続パケットまで回復可能であるため,回復力は大きく改善する。

このスキームはバースト的なパケット損失に対して非常にロバストであるが(L個の連続したパケット損失を訂正する),もしもたった2個のパケットが損失し,しかもこれらのパケットが同じ列であるならば,これらの損失を回復する術はない。それ故,2つの同時的なFECストリームがサポートされるべきであり,それにより,増大するオーバーヘッドの代償としてはるかに高い訂正能力を持たせることができる。これらのFECストリームは別々のUDPポートで運ばれるべきであり,それにより,別々のシーケンス番号処理を可能とし,また,1つの(列の)FECストリームのみをサポートする前述の例との後方互換性を維持できる。

第1のポートは列FECストリームを運び,第2のポートは行FECストリームを運ぶ。」(5-7頁)

ウ「4.5.5 FEC header format

The FEC header described in the RFC 2733 is originally 12 bytes. To allow for the extension to the error correction scheme, the FEC header needs to be modified as detailed in Figure 3.
(図3 省略)
Fig.3 Definition of the FEC header

The following fields are as defined in RFC2733:
・SNBase low bits: minimum sequence number of the packets associated to the FEC packet. For MPEG2 transport streams 16 bit sequence numbers are sufficient, so this parameter shall contain the entire sequence number. For protocols with longer sequence numbers this field will contain the least significant 16 bits of the sequence number.
・・・(中略)・・・
The additional fields have been modified from what was in RFC2733, or are new. The definition of these is:
・・・(中略)・・・
Type: This field indicates which error-correcting code is chosen. It can be XOR (type=0), Hamming (type=1), Reed-Solomon (type=2).
・・・(中略)・・・
SNBase ext bits: This field is reserved for use with protocols which require extended sequence numbers longer than 16 bits. For MPEG2 transport streams 16 bit sequence numbers are sufficient, so this parameter shall be set to zero. For protocols with longer sequence numbers this field will contain the next eight bits of the sequence number, beyond that which is in SNBase low bits.
(当審仮訳:
4.5.5 FECヘッダフォーマット

RFC2733に記述されたFECヘッダはもともと12バイトである。誤り訂正スキームの拡張を許容するために,FECヘッダは図3に詳述されるように変更される必要がある。
(図3:省略)
図3.FECヘッダの定義

以下のフィールドがRFC2733で定義されている:
・SNBase low bits:FECパケットに関連するパケットの最小のシーケンス番号。MPEG2トランスポートストリームに対しては16ビットのシーケンス番号で十分であり,このパラメータは全シーケンス番号を格納できる。より長いシーケンス番号を用いるプロトコルに対しては,このフィールドはシーケンス番号の下位の16ビットを格納する。
・・・(中略)・・・
付加的なフィールドがRFC2733のものに対して修正され,もしくは,新たに設けられた。それらの定義は:
・・・(中略)・・・
・Type:このフィールドはどの誤り訂正符号が選ばれているかを示す。それは,XOR(type=0),ハミング(type=1),リード-ソロモン(type=2)であり得る。
・・・(中略)・・・
・SNBase ext bits:このフィールドは16ビットより長い拡張したシーケンス番号を必要とするプロトコルで使用されるために予約されている。MPEG2トランスポートストリームに対しては16ビットのシーケンス番号で十分であり,そのためこのパラメータは0にセットされる。より長いシーケンス番号のプロトコルに対してはこのフィールドはシーケンス番号のうちSNBase low bitsにあるビットを超える部分の8ビットを格納する。」(9-11頁)

上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると,
上記引用例には,リアルタイムメディアの誤り訂正を可能にするためにRFC2733で定義された既存の前方誤り訂正パケット用のRTPペイロードフォーマットを拡張することに関する技術が記載されており,具体的には,
a RTPパケットを並び替え,L列D行の2次元行列を形成し,前記2次元行列の各RTPパケット列から1つのFECパケットのペイロードを計算すること(図1および摘記事項イ),
b FECパケットのペイロードに図3に記載された拡張されたFECヘッダを付加してFECパケットを生成すること,
c FECパケットは,FECパケットに関連するRTPパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別されること(摘記事項ウ)
が記載されている。
ここで,上記RTPパケットは上位レイヤから受信すること,及び,上記FECパケットやRTPパケットがIPネットワーク上で送信されることは当業者にとり明らかであり,また,FECパケットによって関連するRTPパケットの誤り訂正がなされることから,引用例にはRTPパケットを保護する方法が記載されているといえる。

以上を総合すると,上記引用例には,以下の発明(以下,「引用発明」という。)が開示されていると認める。

「RTPパケットを保護する方法であって,
リアルタイムメディアデータを表すRTPパケットを受信し,
前記RTPパケットを並び替え,L列D行の2次元行列を形成し,
前記2次元行列の各RTPパケット列から1つのFECパケットのペイロードを計算し,
前記FECパケットのペイロードにFECヘッダを付加してFECパケットを生成し,
前記生成されたFECパケットをIPネットワークで送信し,ただし,前記FECパケットは,前記FECパケットに関連する前記RTPパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別され,
IPネットワークで前記RTPパケットを送信することを有し,
前記FECパケットは,前記RTPパケットのフォーマットを変更せずに生成され,IPネットワークで送信される,方法。」

(3)対比
補正後の発明と引用発明とを対比するに,
a 引用発明の「RTPパケット」は補正後の発明の「リアルタイムメディアパケット」及び「メディアパケット」に相当する。
b 引用発明の「FEC」はforward error correction(前方誤り訂正)の略であり,補正後の発明の「前方誤り訂正」と同義である。
c 引用発明の「前記2次元行列の各RTPパケット列から1つのFECパケットのペイロードを計算し」と,
補正後の発明の「前記メディアパケットからメディアビット列を生成し,前記生成されたメディアビット列のそれぞれの終端で,前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし,それぞれパディングされたビット列が最も長いビット列の長さを有するように,以前にパディングされたビット列の終端で更にパディングし,前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し,複数の前方誤り訂正ビット列を生成し」とは,
「前記メディアパケットから前方誤り訂正ビット列を生成し」で共通する。
d 引用発明の「前記FECパケットのペイロードにFECヘッダを付加してFECパケットを生成し」と,
補正後の発明の「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し,ただし,前方誤り訂正パリティパケットインデックスの最上位の数ビットが第3のインデックスフィールドに挿入され」とは,
「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し」で共通する。
e 引用発明の「前記FECパケットに関連する前記RTPパケット列の最小のシーケンス番号」に関し,「前記FECパケットに関連する前記RTPパケット列」は,図1に記載されたRTPパケットの2次元行列の1つの列に含まれるRTPパケット列であるが,引用発明の「前記2次元行列の各RTPパケット列から1つのFECパケットのペイロードを計算し」の構成によれば,このRTPパケット列は対応するFECパケットの生成の基礎となっているといえる。
さらに,このRTPパケット列の「最小のシーケンス番号」は第1行のRTPパケットのシーケンス番号(0乃至L-1のいずれか)であって,2次元行列の「列のインデックス」を表し,また,この「列のインデックス」によってFECパケット間を区別可能となっていることも明らかである。
以上を踏まえると,
引用発明の「前記FECパケットは,前記FECパケットに関連する前記RTPパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別され」は,
補正後の発明の「前記前方誤り訂正パケットは,インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記2次元行列の列のインデックスを表す次元により分離され」に相当する。
f 引用発明の「前記FECパケットは,前記RTPパケットのフォーマットを変更せずに生成され,IPネットワークで送信される」と,
補正後の発明の「前記前方誤り訂正パケットは,前記メディアパケットのフォーマットを変更せずに生成され,前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され,非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」とは,
「前記前方誤り訂正パケットは,前記メディアパケットのフォーマットを変更せずに生成され,送信される」で共通する。

従って,両者は以下の点で一致ないし相違している。

(一致点)
「リアルタイムメディアパケットを保護する方法であって,
リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し,
前記メディアパケットを並び替え,複数の列及び複数の行の2次元行列を形成し,
前記メディアパケットから前方誤り訂正ビット列を生成し,
前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し,
前記生成された前方誤り訂正パケットを送信し,ただし,前記前方誤り訂正パケットは,インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記2次元行列の列のインデックスを表す次元により分離され,
前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し,
前記前方誤り訂正パケットは,前記メディアパケットのフォーマットを変更せずに生成され,送信される,方法。」

(相違点1)
「前記メディアパケットから前方誤り訂正ビット列を生成」する点に関し,
補正後の発明では,「前記メディアパケットからメディアビット列を生成し,前記生成されたメディアビット列のそれぞれの終端で,前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし,それぞれパディングされたビット列が最も長いビット列の長さを有するように,以前にパディングされたビット列の終端で更にパディングし,前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し,複数の前方誤り訂正ビット列を生成」するのに対し,
引用発明では,「前記2次元行列の各RTPパケット列から1つのFECパケットのペイロードを計算」する点。

(相違点2)
「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成」する点に関し,
補正後の発明では,「前方誤り訂正パリティパケットインデックスの最上位の数ビットが第3のインデックスフィールドに挿入され」るのに対し,
引用発明ではそのような構成を有しない点。

(相違点3)
「前方誤り訂正パケット」の「送信」に関し,
補正後の発明では,「前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され,非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」のに対し,
引用発明では,単に「IPネットワークで送信される」ものである点。

(4)判断
上記相違点につき検討する。

(相違点1)について
引用例には,前方誤り訂正符号としてリード-ソロモン符号(RS符号)を用いることが示唆されているが(摘記事項ウ),当該RS符号化がシンボル単位の符号化であって,「符号化処理のために情報ビットをシンボルの倍数に対応するビット長にパディングにより揃えること」及び,RS符号を複数の可変長パケットを通じて適用する場合に「各パケットのパケット長をパディングにより揃えること」は,いずれもRS符号化処理における周知技術である(例えば,前置報告で引用された特開2002-204219号公報(以下,「周知例1」という。)の段落【0038】や,原査定の拒絶の理由に引用された特開2006-325113号公報(以下,「周知例2」という。)の段落【0046】-【0047】を参照。)。
さらに,一般に,誤り訂正符号としてRS符号を用いる場合,複数の冗長ビット列(冗長パケット)が生成されることは技術常識である。
そうすると,引用発明において,2次元行列の各RTPパケット列からそれぞれFECパケットのペイロードを計算する場合に,FECとして引用例に示唆されたRS符号を採用するとともにRS符号化処理に関する上記周知例2,3に例示された周知技術を採用して,補正後の発明のように,「前記メディアパケットからメディアビット列を生成し,前記生成されたメディアビット列のそれぞれの終端で,前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし,それぞれパディングされたビット列が最も長いビット列の長さを有するように,以前にパディングされたビット列の終端で更にパディングし,前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し,複数の前方誤り訂正ビット列を生成」することは,当業者であれば容易になし得たものである。

(相違点2)について
引用発明と同様にRFC2733に準拠するリアルタイムトランスポート(RTP)フォーマットにおける前方誤り訂正(FEC)ヘッダに,受信側での前方誤り訂正デコーディング処理に必要な情報を所定のフィールドを設けて格納することについては種々検討されており,FECとして前方誤り訂正ブロックにおける複数の前方誤り訂正パケットの中で自身の前方誤り訂正パケットがどの位置に存在するパケットであるのかを示す情報,すなわち,補正後の発明の「前方誤り訂正パリティパケットインデックス」を前方誤り訂正(FEC)ヘッダに所定のフィールドを設けて格納することは,例えば,上記周知例2の図6及び段落【0093】に記載された「FEC Sequence」フィールドのように周知の構成である。
ここで,一般にヘッダのフィールドに所望のビット列を格納しようとするとき,当該ビット列の桁数とフィールドに格納できるビット数に応じて,複数のフィールドにビット列を分割して格納し,連結させて読み出せるようにすることは,引用例に,RTPパケットのシーケンス番号を下位ビットと上位ビットに分割してそれぞれ「SNBase low bits」と「SNBase ext bits」に格納することが記載されているように(摘記事項ウ),常套手段にすぎない。
そうすると,引用発明のFECヘッダに,上記周知例2記載の「FEC Sequence」フィールドを設けて「インデックスフィールド」を構成することは当業者が容易に想到し得たものである。その際,当該「インデックスフィールド」を所定数の下位ビットを格納するフィールドと所定数の上位ビットを格納するフィールドとから構成することは当業者が必要に応じて適宜行い得る設計的事項であり,また,このとき,所定数の上位ビットを格納するフィールドを補正後の発明のように「第3のインデックスフィールド」と称することも適宜なし得ることである。

(相違点3)について
後方互換性を目的として,データパケットと冗長パケットを別ストリームとして伝送することは,原査定の拒絶の理由に引用された相原 玲二 他,HDTV MPEG2 over IPv6システムの開発,情報処理学会研究報告,日本,社団法人情報処理学会,2002年10月,Vol.2002 No.93,p.7-12(以下,「周知例3」という。)に「提案するパケットフォーマットを図5に示す。メディアパケット(media packet)は送信元から伝送されるユーザデータで,冗長パケット(FEC packet)はFECアルゴリズムによって新しく生成したパケットである。2つのパケットはそれぞれ別ストリームとして伝送し,後方互換性を提供する。」(9頁左欄)とあるように,RFC2733でも規定されている周知技術に過ぎず,このとき,各ストリームを異なるポートで伝送することは,例えば,引用例において2つのFECストリーム(列FECストリームと行FECストリーム)を別々のUDPポートで運ぶことで1つの(列の)FECストリームのみをサポートする場合との後方互換性を持たせているように(摘記事項イ),当業者が当然成すべきことに過ぎない。
したがって,引用発明において「前方誤り訂正パケット」が「IPネットワークで送信される」際に,補正後の発明のように「前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され,非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」構成とすることは,上記周知例3に例示される周知技術に基づいて当業者が容易に想到し得たものである。

そして,補正後の発明が奏する効果も引用発明及び周知技術から容易に予測できる範囲内のものである。

(5)まとめ
以上のとおり,補正後の発明は,引用発明に基づいて周知技術を参酌することにより当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。
したがって,本件補正は,特許法第17条の2第5項において準用する特許法第126条第5項の規定に違反するので,特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

第3 本願発明について
1 本願発明
本件補正は上記のとおり却下されたので,本願発明は,上記「第2 補正却下の決定 1 本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。

2 引用発明と周知技術
引用発明及び周知技術は,上記「第2 補正却下の決定」の項中の「3 独立特許要件について」の項中の「(2)引用発明」の項で認定したとおりである。

3 対比・判断
本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。
そうすると,本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が,上記「第2 補正却下の決定」の項中の「3 独立特許要件について」の項で検討したとおり,引用発明に基づいて周知技術を参酌することにより容易に発明できたものであるから,本願発明も同様の理由により,容易に発明できたものである。

4 むすび
以上のとおり,本願発明は,引用発明に基づいて周知技術を参酌することにより当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,他の請求項に係る発明について審理するまでもなく,本願は拒絶すべきものである。
よって,結論のとおり審決する。
 
審理終結日 2015-10-14 
結審通知日 2015-10-20 
審決日 2015-11-09 
出願番号 特願2013-3347(P2013-3347)
審決分類 P 1 8・ 121- Z (H04L)
P 1 8・ 575- Z (H04L)
最終処分 不成立  
前審関与審査官 谷岡 佳彦  
特許庁審判長 大塚 良平
特許庁審判官 林 毅
新川 圭二
発明の名称 インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法  
代理人 伊東 忠重  
代理人 大貫 進介  
代理人 伊東 忠彦  

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