• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L
管理番号 1347014
審判番号 不服2017-1609  
総通号数 230 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-02-22 
種別 拒絶査定不服の審決 
審判請求日 2017-02-03 
確定日 2018-12-04 
事件の表示 特願2014-518829「マルチメディアシステムにおける前方誤り訂正パケットの生成方法とその誤り訂正パケットを送受信する方法及び装置」拒絶査定不服審判事件〔平成25年 1月17日国際公開、WO2013/009048、平成26年 8月25日国内公表、特表2014-521245〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2012年(平成24年)7月6日(優先権主張 平成23年7月8日 韓国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
平成27年 7月 6日:手続補正書の提出
平成28年 2月 5日:拒絶理由通知
平成28年 5月16日:意見書、手続補正書の提出
平成28年 9月23日:拒絶査定
平成29年 2月 3日:審判請求書の提出
平成29年12月15日:拒絶理由通知
平成30年 3月19日:意見書、手続補正書の提出

第2 本願発明
本願の特許請求の範囲に記載された発明は、平成30年3月19日付け手続補正書の特許請求の範囲に記載されたとおりであるところ、請求項1に係る発明(以下、「本願発明」という。)は以下のとおりである。
「【請求項1】
マルチメディアシステムにおける前方誤り訂正(Forward Error Correction;FEC)符号化を遂行するための方法であって、
複数のソースシンボルブロックの各々に対して、第1のFEC符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第1の回復パケットを含むFECパケットブロックを生成するステップと、
前記複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して少なくとも一つの第2の回復パケットを生成するステップと、を含み、
前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結され、
ここで、前記少なくとも一つの第1の回復パケットのうちの回復パケットは、前記回復パケットに対応する第1のFECパケットブロックの境界を表す情報を含む、ことを特徴とする方法。」

第3 当審で通知した拒絶の理由
当審で通知した平成29年12月15日付け拒絶理由(以下、「当審の拒絶理由」という。)の拒絶理由における理由1は、「本件出願の請求項1-4に係る発明は、その出願前に日本国内または外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。」というものである。

引用文献1:米国特許出願公開第2007/0300127号明細書
引用文献2:特開2005-159433号公報
参考文献:J.Rosenberg et al., "An RTP Payload Format for Generic Forward Error Correction", RFC2733, 1999.12, https://tools.ietf.org/rfc/rfc2733.txt


第4 引用文献
1 引用文献1
(1) 当審の拒絶理由で引用された米国特許出願公開第2007/0300127号明細書(以下、「引用文献1」という。)には、図面とともに、以下の事項が記載されている。(下線は当審が付与した。)
ア 「BRIEF SUMMARY OF THE INVENTION
[0024] According to one embodiment of the invention, a method of encoding data for transmissions from a source to a destination over a communications channel is provided. The method operates on an ordered set of source symbols and may generate zero or more redundant symbols from the source symbols, wherein data is encoded in a first step according to a first FEC code and in a second step, data is encoded according to a second FEC code, more complex than the first FEC code. The first FEC code might be a simple erasure code and the second a more complex erasure code. The first FEC code and/or the second FEC code might comprise coding known in the art. These steps result in two groups of encoded data in such a way that a low-complexity receiver may make use of one of the groups of encoded data while higher complexity receivers may make use of both groups of encoded data, providing more error protection than either FEC code alone.」
(当審訳)「発明の概要
[0024]本発明の一実施形態によれば、通信チャネルを介して送信元から宛先へ送信するデータを符号化する方法が提供される。この方法は、ソースシンボルの順序付けられたセットに対して機能し、ソースシンボルからゼロ又はそれ以上の冗長シンボルを生成することができ、データは第1のステップで第1のFEC符号に従って符号化され、第2のステップではデータは第2のFEC符号に従って符号化され、第2のFEC符号は第1のFEC符号よりも複雑である。第1のFEC符号は単純な消失符号であり、第2のものはより複雑な消失符号である。第1のFEC符号及び/又は第2のFEC符号は当技術分野で既知の符号化を含むことができる。これらの工程は符号化データの2つのグループをもたらし、複雑さの低い受信機はそのグループの1つを利用し、一方で、より複雑さの高い受信機は符号化されたデータのグループの両方を利用することができ、FEC符号のいずれか1つのみよりも、より強力な誤り保護を提供する。」

イ 「[0035] In embodiments described herein, data to be encoded is segmented into "source blocks," each block comprising a number of packets of data, known as "source packets," with the number of source packets in a block possibly varying between blocks. For each source block, a number of "FEC repair" packets are generated by the encoder, the number also possibly varying between blocks. ・・・略・・・」
(当審訳)「ここで記述される実施例では、符号化されるデータは「ソースブロック」に分割され、各々のブロックはいくつかの「ソースブロック」として知られるデータパケットを含む。ソースブロックの各々について、いくつかの「FECリペア」パケットがエンコーダを用いて生成され、その数はブロック間で異なり得る。・・・略・・・」

ウ 「Relationship Between Packets and Symbols
[0052] As described above, forward erasure correction codes operate on symbols chosen from a fixed alphabet. For example, the symbols may be chosen from an alphabet of size 2M in which case there is an obvious mapping between symbols and strings of M binary digits. Such symbols are hereinafter referred to as having a size of M bits. Data is often sent over a communications channel in the form of packets. In some cases, there is a one-to-one mapping between symbols and packets. In other cases, including for example those described in Luby II, packets may be larger than symbols, with a packet comprising several symbols. Additionally, symbols and packets may comprise the same data but the bit order and placement may differ, or additional information may be placed into the FEC symbols which is not contained within the packet, for example a binary representation of the packet length. Equally, data may be present in packets which is not present in the FEC symbols, for example information added to a packet to indicate which FEC symbols it contains or data that does not need to be protected by the FEC code, for example because it comprises fields that are not used or have the same value in every packet or because it could be recovered in other ways.
[0053] In the case of hybrid codes, to obtain some of the advantages, the symbols of the first code and those of the second code will have certain relationships. Specifically, a source symbol of the first code will comprise the data of one or more source symbols of the second code. It should be understood that the source symbols of the first code may be a different size from those of the second code, that there may be information in symbols of the first code that is not present in the symbols of the second code and that where a source symbol of the first code comprises the data of one of the source symbols of the first code this means only that knowledge of the source symbol of the second code could be obtained from knowledge of the source symbol of the first code and not, for example, that the source symbol of the first code contains a verbatim copy of the source symbol of the second code.

Relationship Between Source Blocks
・・・略・・・
[0055] In the case of hybrid codes, to obtain some of the advantages, the source blocks of the first code and those of the second code will have certain relationships. Specifically, the source blocks of the first code preferentially should each be a subset of a source block of the second code. More precisely, given a source block of the first code, a number of the source symbols of the second code may be obtained according to the section "Relationship between packets and symbols" herein and these source symbols preferentially should all be part of the same source block of the second code.
[0056] An example of a possible relationship between source blocks of the first and second codes is illustrated in FIG. 4 , which shows a source block of a Second FEC code 410 constructed from 40 source packets, S0, S1, . . . , S39. Also shown are two source blocks of a First FEC code, 420 and 430 , each constructed from 20 packets taken from the same set of 40 packets.」
(当審訳)「パケットとシンボルとの関係
[0052]上記のように、前方消失訂正符号は固定されたアルファベットから選択されたシンボルに対して作用する。例えば、シンボルは、2Mのサイズのアルファベットから選択することができ、その場合、シンボルと2進M桁の文字列との間に明白な対応関係が存在する。このようなシンボルはMビットのサイズを有するものとして以下に言及する。データはしばしばパケットの形態で通信チャネルを介して送信される。場合によっては、シンボルとパケットとの間には1対1の対応関係がある。例えば、Luby IIに記載されたものを含む他の場合では、パケットがシンボルよりも大きく、パケットがいくつかのシンボルを含んでもよい。さらに、シンボルおよびパケットは同じデータを含むことができるが、ビット順序および配置は異なっていてもよく、または、パケットの中に含まれない、例えばパケット長の2進表現のような追加の情報をFECシンボルの中に配置することができる。同様に、データは、パケット内に存在するが、FECシンボル内に存在しなくともよい。それは、例えば、FECシンボルを含んでいることを示すためにパケットに付加された情報、又は、FEC符号によって保護される必要のないデータであり、それが使用されない、又は、すべてのパケットが同じ値を持っているフィールドを含んでいるため、あるいは、他の方法で回復することができるためである。
[0053]ハイブリッドコードの場合には、いくつかの利点を得るために、第1の符号のシンボル及び第2の符号のシンボルは一定の関係を有する。具体的には、第1の符号のソースシンボルは第2の符号の1又はそれ以上のソースシンボルのデータを含む。第1の符号のソースシンボルは第2の符号のソースシンボルと異なるサイズであってもよく、第2の符号のシンボルの中に存在しないが、第1の符号のシンボルに存在する情報であってもよく、第1の符号のソースシンボルは第1の符号のソースシンボルのうちの1つのデータを含み、これは、第2の符号のソースシンボルの知識が、第1の符号のソースシンボルの知識から得ることができるかできないかを意味するにすぎず、例えば、第1の符号のソースシンボルは第2の符号のソースシンボルの逐語的なコピーを含むことを意味する。

ソースブロック間の関係
・・・略・・・
[0055]ハイブリッドコードの場合には、いくつかの利点を得るために、第1の符号のソースブロックと第2の符号のものとは一定の関係を有する。具体的には、第1の符号のソースブロックは第2の符号のソースブロックのサブセットであることが望ましい。より正確には、第1の符号のソースブロックが与えられると、第2の符号のソースシンボルの数は、”パケット及びシンボル間の関係”のセクションに従って得ることができ、これらのソースシンボルはすべての第2の符号の同じソースブロックの一部でなければならない。
[0056]第1及び第2の符号のソースブロックの間の可能な関係の一例を図4に示す。図4は40個のソースパケットS0、S1、・・・、S39から構成された第2のFEC符号410のソースブロックを示す。第1のFEC420、430の2つのソースブロックは示されており、各々は40個のパケットの同じセットから選択された20個のパケットから構成される。」

エ 「Examples of First FEC Codes
・・・略・・・
Other Well-Known Parity Codes
[0145]
Many parity codes are known within particular application areas. For example RFC 2733 describes examples of codes. Codes described in the "Professional-MPEG Code of Practice 3" might be used with streams of RTP packets.
・・・略・・・
Examples of Second FEC Codes
[0151] The second FEC code used in the hybrid code schemes described here may be any of many forward erasure correction codes which are known in the art. For example, the second FEC codes chain reaction codes such as LT Codes and Raptor Codes or fixed rate codes such as Reed-Solomon codes, Low-Density Parity Check Codes, LDGM Staircase and LDGM Triangle codes.」
(当審訳)「第1のFEC符号の例
・・・略・・・
他のよく知られているパリティ符号
[0145]
多くのパリティ符号が特定の適用分野において知られている。例えばRFC2733では符号の例が記載されている。”Pro-MPEGcop3”に記述された符号は、RTPパケットのストリームに使用することができる。
・・・略・・・
第2のFEC符号の例
[0151]ここに記載されたハイブリッド符号化方式で使用される第2のFEC符号は、当技術分野において公知である多くの前方誤り訂正符号のいずれであってもよい。例えば、第2のFEC符号は、LT符号、ラプター符号のような連鎖反応符号、またはリード・ソロモン符号、低密度パリティチェック符号、LDGM階段符号、LDGMトライアングル符号のような固定レート符号である。」

オ 「[0200] FIG. 5 provides error correction performance results for several codes, including the Pro-MPEG Code Of Practice 3 code (510), the Raptor code (520) and a hybrid code (530) in which the codes 510 and 520 are used as first and second code respectively. The figure shows results for a scenario typical for IPTV in which a 6 Mbit/s video stream is encapsulated into IP data packets and sent over a network with FEC protection provided using source blocks each containing 400 ms of video data. The simulated packet loss rate is plotted on the x-axis and for each packet loss rate and each code the amount of FEC overhead required to meet a typical IPTV quality target of an average of one packet loss every four hours is shown.」
(当審訳)「[0200]図5はいくつかの符号の誤り訂正の性能結果をします。その符号にはPro-MPEGcop3(510)、ラプタ-符号(520)、ハイブリッド符号(530)が含まれ、符号510、520は第1及び第2の符号として用いられる。この図ではIPTVに典型的な方式の結果を示し、6Mbit/sのビデオストリームは、IPデータパケットにカプセル化され、それぞれが400msのビデオデータを含むソースブロックを使用して、FEC保護付のネットワークを介して送信される。シミュレートされたパケット損失率はx軸にプロットされ、各パケット損失率と、各符号について4時間毎のパケット損失の平均IPTV品質目標を満たすために必要なFECオーバヘッドの量が示されている。」

カ Figure4として、以下の図面が記載されており、この図面から、第1のFEC符号のソースブロック420はソースパケットS0、S1、・・・、S19から構成され、第1のFEC符号のソースブロック430はソースパケットS20、S21、・・・、S39から構成され、第2のFEC符号のソースブロック410は第1のFEC符号のソースブロック420、430から構成されていることが読み取れる。


(2) 引用文献1の上記摘記事項から、以下の事項がいえる。
ア 上記(1)オの段落[0200]の「The figure shows results for a scenario typical for IPTV in which a 6 Mbit/s video stream is encapsulated into IP data packets and sent over a network with FEC protection provided using source blocks each containing 400 ms of video data.」(「この図ではIPTVに典型的な方式の結果を示し、6Mbit/sのビデオストリームは、IPデータパケットにカプセル化され、それぞれが400msのビデオデータを含むソースブロックを使用して、FEC保護付のネットワークを介して送信される。」)との記載からみて、前方誤り訂正(FEC)符号化をIPTVシステムに適用することが記載されており、引用文献1には、「IPTVシステムにおける前方誤り訂正(FEC)符号化を遂行するための方法。」が記載されているといえる。

イ 上記(1)カによれば、Figure4からは、「第1のFEC符号のソースブロック420はソースパケットS0、S1、・・・、S19から構成され、第1のFEC符号のソースブロック430はソースパケットS20、S21、・・・、S39から構成され、第2のFEC符号のソースブロック410は第1のFEC符号のソースブロック420、430から構成されていること」が読み取れる。
ここで、本願明細書の段落【0029】の「第1のFEC符号化により生成されたM個の第1の符号化シンボル205?207又はM個の第1のソースシンボル201a?203aは、第2のソースシンボルとして使用され、図2に示すように、第2の符号化シンボルのような第2の符号化シンボル209は、第2のソースシンボルに対して第2のFEC符号化を遂行することによって、第1の符号化シンボル205?207と第2の回復シンボルのような第2の回復シンボル208を含むことができる。」との記載によれば、「連結」とは「第1のFEC符号化」の対象である「M個の第1のソースシンボル201a?203a」を「第2のソースシンボル」として「第2のFEC符号化」の対象として使用する処理であると解することは、少なくとも排除されない。
してみると、上記のFigure4から読み取れる事項は、「第1のFEC符号のソースブロック420及びソースブロック430は連結されて第2のFEC符号のソースブロックを構成されていること」といえる。

ウ (I) 上記(1)ウの段落[0055]の「Specifically, the source blocks of the first code preferentially should each be a subset of a source block of the second code.」(「具体的には、第1の符号のソースブロックは第2の符号のソースブロックのサブセットであることが望ましい。」)との記載、
(II) 同段落[0056]の「An example of a possible relationship between source blocks of the first and second codes is illustrated in FIG. 4 , which shows a source block of a Second FEC code 410 constructed from 40 source packets, S0, S1, . . . , S39. Also shown are two source blocks of a First FEC code, 420 and 430 , each constructed from 20 packets taken from the same set of 40 packets.」(「第1及び第2の符号のソースブロックの間の可能な関係の一例を図4に示す。図4は40個のソースパケットS0、S1、・・・、S39から構成された第2のFEC符号410のソースブロックを示す。第1のFEC420、430の2つのソースブロックは示されており、各々は40個のパケットの同じセットから選択された20個のパケットから構成される。」)との記載、及び、
(III) 図4から読み取れる「第1のFEC符号のソーズブロック420はソースパケットS0、S1、・・・、S19から構成され、第1のFEC符号のソースブロック430はソースパケットS20、S21、・・・、S39から構成され、第2のFEC符号のソースブロック410は第1のFEC符号のソースブロック420、430から構成されている」、すなわち、「第1のFEC符号のソーズブロック420及びソースブロック430は連結されて第2のFEC符号のソースブロック410を構成していること」、
を総合すると、「第1のFEC符号を構成する複数のソースブロックの各々は、少なくとも一つのソースパケットから構成されること。」、「第1のFEC符号を構成する複数のソースブロックは第2のFEC符号のソースブロックを構成すること。」及び「第1のFEC符号を構成する複数のソースブロックは連結されて、第2のFEC符号のソースブロックを構成していること。」が記載されているといえる。
このため、上記「第1のFEC符号を構成する複数のソースブロックの各々は、少なくとも一つのソースパケットから構成されること。」との事項から、「少なくとも一つのソースパケットから構成される複数のソースブロックの各々に対して第1のFEC符号化が遂行されること。」が記載されているといえ、上記「第1のFEC符号を構成する複数のソースブロックは第2のFEC符号のソースブロックを構成すること。」との事項から、「前記複数のソースブロックに対して、第2のFEC符号化が遂行されていること。」が記載されているといえ、上記「第1のFEC符号を構成する複数のソースブロックは連結されて、第2のFEC符号のソースブロックを構成していること。」との事項から、「前記複数のソースブロックは第2のFEC符号化のために連結されていること。」が記載されているといえる。

エ 上記(1)ウの段落[0052]の「In some cases, there is a one-to-one mapping between symbols and packets. In other cases, including for example those described in Luby II, packets may be larger than symbols, with a packet comprising several symbols.」(「場合によっては、シンボルとパケットとの間には1対1の対応関係がある。例えば、Luby IIに記載されたものを含む他の場合では、パケットがシンボルよりも大きく、パケットがいくつかのシンボルを含んでもよい。」)との記載からみて、引用文献1には、「ソースパケットは、1又は複数のシンボルを含むこと。」が記載されているといえる。
ここで、上記(1)アの段落[0024]の「The method operates on an ordered set of source symbols and may generate zero or more redundant symbols from the source symbols, wherein data is encoded in a first step according to a first FEC code and in a second step, data is encoded according to a second FEC code, more complex than the first FEC code. For each source block, a number of "FEC repair" packets are generated by the encoder, the number also possibly varying between blocks.」(「この方法は、ソースシンボルの順序付けられたセットに対して機能し、ソースシンボルからゼロ又はそれ以上の冗長シンボルを生成することができ、データは第1のステップで第1のFEC符号に従って符号化され、第2のステップではデータは第2のFEC符号に従って符号化され、第2のFEC符号は第1のFEC符号よりも複雑である。」)との記載からみて、段落[0052]の「symbols」(シンボル)は「source symbols」(ソースシンボル)であるといえる。

オ 前記イ乃至エの事項より、引用文献1には、「1又は複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、第1のFEC符号化を遂行すること。」が記載されているといえる。

カ 上記(1)イの段落[0035]の「In embodiments described herein, data to be encoded is segmented into "source blocks," each block comprising a number of packets of data, known as "source packets," with the number of source packets in a block possibly varying between blocks. For each source block, a number of "FEC repair" packets are generated by the encoder, the number also possibly varying between blocks.」(「ここで記述される実施例では、符号化されるデータは「ソースブロック」に分割され、各々のブロックはいくつかの「ソースブロック」として知られるデータパケットを含む。ソースブロックの各々について、いくつかの「FECリペア」パケットがエンコーダを用いて生成され、その数はブロック間で異なり得る。)との記載、及び、実施例における符号化はFEC符号に従った符号化であった、「第1のFEC符号に従った符号化」及び「第2のFEC符号に従った符号化」とを含んでいることから、「第1のFEC符号に従った符号化」及び「第2のFEC符号に従った符号化」を遂行されることで「FECリペア」パケット、即ち、「回復パケット」が生成されるといえる。

キ 上記(1)エの段落[0145]の直前の「Other Well-Known Parity Codes」という記載は、「Examples of First FEC Codes」(段落[0140])の後に記載され、「Examples of Second FEC Codes」(段落[0150])の前に記載されているから、第2のFEC符号化の例は、第1のFEC符号化の例とは別の例であるといえる。
そして、上記(1)エの段落[0145]には、「For example RFC 2733 describes examples of codes.」と記載されているから、引用文献1には、「RFC2733に準拠した符号化方式により第1のFEC符号化を遂行すること。」が記載されているといえる。
ここで、RFC2733に準拠した符号化方式は、メディアパケットをFEC符号化することによって、前記メディアパケットの誤りや欠落を回復するためのFECパケットを生成するものであり、また、このFECパケットのヘッダには、FECパケットに対応するメディアパケットの最小のシーケンス番号が含まれることは、技術常識である(必要ならば、「RFC2733」について記載された「J.Rosenberg et al., "An RTP Payload Format for Generic Forward Error Correction", RFC2733, 1999.12, https://tools.ietf.org/rfc/rfc2733.txt」(以下、「参考文献1」という。)の下記参考記載を参照のこと。)。

(参考文献1の参考記載)
(ア)「2 Terminology」の「FEC Packet: The forward error correction algorithms at the transmitter take the media packets as an input. They output both the media packets that they are passed, and new packets called FEC packets.」((当審訳)「FECパケット:トランスミッタでの前方誤り訂正アルゴリズムは、メディアパケットを入力として受け取る。これらは、渡されたメディアパケットとFECパケットと呼ばれる新たなパケットとの両方を出力する。」)との記載。

(イ)「3 Basic Operation」の「As the sender generates FEC packets, they are sent to the receivers.」((当審訳)「送信者がFECパケットを生成すると、それらは受信者に送信される。」)との記載。

(ウ)「6 FEC Packet Structure」の「6.2 FEC Header」の「Figure2: Parity Header Format」の記載


(エ)「6 FEC Packet Structure」の「6.2 FEC Header」の「The SN base field MUST be set to the minimum sequence number of those media packets protected by FEC.」((当審訳)「SNベースフィールドは、FECによって保護されたメディアパケットの最少シーケンス番号に設定されなければならない。」)との記載。

そして、RFC2733では、FEC符号化の対象パケットをメディアパケットと言い表しているものの、メディアパケットは入力として受け取るパケットであることから、該メディアパケットはソースパケットといえる。
したがって、技術常識を踏まえると、引用文献1には、「RFC2733に準拠した第1のFEC符号化を遂行することによって、各々が少なくとも一つのソースブロックの各々に対応するFECパケット(以下、「第1のFECパケット」という。)を生成すること。」及び「前記第1のFECパケットは、前記第1のFECパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含むこと。」が記載されているといえる。

ク 上記(1)エの段落[0151]の直前の「Examples of Second FEC Codes」という記載、及び、同段落[0151]の「the second FEC codes chain reaction codes ・・・略・・・fixed rate codes such as Reed-Solomon codes・・・略・・・, LDGM Staircase and LDGM Triangle codes.」((当審訳)「第2のFEC符号は・・・略・・・のような連鎖反応符号又はリードソロモン符号・・・略・・・LDGM階段符号、LDGMトライアングル符号符号のような固定レート符号である。」)との記載からみて、引用文献1には、第2のFEC符号の例として、リードソロモン符号或いはLDGM階段符号やLDGMトライアングル符号などのLDGM符号を用いることが記載されている。
リードソロモン符号やLDGM符号による第2のFEC符号化では、データパケットの誤りや欠落を回復するためのFEC(以下、「第2のFEC」という。)を生成するものであるということは技術常識であり、上記オを踏まえると、引用文献1には、「第2のFEC符号化を遂行して回復パケット(以下、「第2の回復パケット」という)を生成すること。」が記載されているといえる。

ケ 以上のア?クによれば、引用文献1には、以下の発明(以下、「引用発明」という。)が記載されていると認める。
「IPTVシステムにおける前方誤り訂正(FEC)符号化を遂行するための方法であって、
複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、RFC2733に準拠した第1のFEC符号化を遂行することによって、各々が少なくと一つのソースブロックの各々に対応する第1のFECパケットを生成するステップと、
前記複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して第2の回復パケットを生成するステップと、を含み、
前記複数のソースブロックは前記第2のFEC符号化のために連結され、
前記第1のFECパケットは、前記第1のFECパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含む、
ことを特徴とする方法。」

2 引用文献2
(1) 当審の拒絶理由で引用された特開2005-159433号公報(以下、「引用文献2」という。)には、図面とともに、以下の事項が記載されている。(下線は当審が付与した。)
ア 「【0006】
さらに、パケットロストに対応するエラー訂正手法として、例えば、FEC[Forward Error Correction:後記非特許文献2(IETF RFC2733)参照]という技術がある。FECのエラー訂正手法について、図7に示す。この図7に示すように、FECでは、エンコーダ装置100側において排他的論理和(XOR)演算に基づいて生成した冗長パケット(パリティ)P1を、送信データ(パケット)D1,D2とともに送信しておくことにより、途中のインターネット等のネットワーク300においてパケットロストが発生しても、デコーダ装置200側においてこの冗長パケットP1からロストしたパケットD1又はD2を復元することができ、エンコーダ装置100側からのパケット再送を必要としない手法である。」

イ 「【0054】
なお、上述した例では、冗長パケットの送信間隔により再送要求の送信タイミングを制御しているが、MPEGパケットの送信間隔に基づいて前記のようなレート計算を行なうことでも、上記と同様の作用効果が得られる。
〔B〕第2実施形態の説明
上述した第1実施形態では、冗長パケットの送信間隔によって再送要求を即時で送信するかどうかを判断したが、低レートの場合でもロストしたパケット(番号)によっては直後に冗長パケットを受信する可能性がある。例えば図5に示すように、N=10個のMPEGパケットに1個の冗長パケット(FECパケット)を送信する場合、パケット番号1番や2番あるいは11番や12番のように1つの冗長パケットで復元可能なパケットグループの中で早い段階で送信されるものと、パケット番号9番や10番あるいは19番や20番のように1つの冗長パケットで復元可能なパケットグループの中で遅い段階で送信されるものとでは、パケットロストした場合に冗長パケットを受信するまでの時間に大きな違いが生じる。」

ウ 「【0056】
例えば、システムレート=100kbps、パケット長=512バイト、冗長パケット生成間隔=10パケットに1個で、図5に示す1番や11番のパケットがロストした場合は、
(512[bytes]*8[bits/byte]/100000[bits/sec])*10=409.6[msec]
となり、409.6msec経過するまで冗長パケットが到着しない。
一方、同じ条件(システムレート=100kbps、パケット長=512バイト、冗長パケット生成間隔=10パケットに1個)で、図5に示す10番や20番のパケットがロストした場合は、
(512[bytes]*8[bits/byte]/100,000[bits/sec])*1=40.96[msec]
となり、40.96msec後には冗長パケットが到着することになる。」

エ 図5として、以下の図面が記載されており、この図面から、10個のMPEGパケット1、2、・・・、10に対して1個のFECパケット修復パケットが挿入され、10個のMPEGパケット11、12、・・・、20に対して1個のFECパケット修復パケットが挿入されて、送信されることが読み取れる。


(2) 上記(1)ア?同エの摘記事項から以下の事項がいえる。
引用文献2の段落【0054】の「例えば図5に示すように、N=10個のMPEGパケットに1個の冗長パケット(FECパケット)を送信する場合、」という記載、及び、第5図から読み取れる「10個のMPEGパケット1、2、・・・、10に対して1個のFECパケット修復パケットが挿入され、10個のMPEGパケット11、12、・・・、20に対して1個のFECパケット修復パケットが挿入されて、送信されること」との事項からみて、引用文献2には、「10個のMPEGパケットにつき、1個のFECパケットを挿入して送信すること。」が記載されているといえる。
この「1個のFECパケット」に関連して、段落【0056】に示された数式をみると、シーケンス番号1番と11番のMPEGパケットについては、「(512[bytes]*8[bits/byte]/100,000[bits/sec])*10」の時間後に、対応する「1個のFECパケット」を受信することが示されている。
段落【0056】の「システムレート=100kbps、パケット長=512バイト」という記載より、前記数式のうち「(512[bytes]*8[bits/byte]/100,000[bits/sec])」の部分は「1つのMPEGパケットの受信に要する時間」であるといえるから、その「*10」倍の時間後に「1個のFECパケット」を受信するということは、シーケンス番号1番、11番のMPEGパケットについては、自パケットの10個後に、対応するFECパケットを受信するといえる。
同様に、シーケンス番号10番と20番のMPEGパケットについては、「(512[bytes]*8[bits/byte]/100,000[bits/sec])*1」の時間後にFECパケットを受信することが記載されいるから、10番と20番のMPEGパケットについては、自パケットのすぐ後(「*1」)に、それぞれに対応するFECパケットを受信するといえる。
してみると、段落【0054】や第5図において、「10個のMPEGパケット」につき挿入される「1個のFECパケット」は、「直前の10個のMPEGパケット」を回復する「FECパケット」であるから、引用文献2には、「10個のMPEGパケットにつき、その直後に、前記10個のMPEGパケットに対応する1個のFECパケットを挿入して送信すること。」が記載されているといえる。
そして、「10個のMPEGパケットにつき、その直後に、前記10個のMPEGパケットに対応する1個のFECパケットを挿入して送信する」ということは、「複数(10個)のMPEGパケットの直後に前記複数(10個)のMPEGパケットに対応する(1個の)FECパケット」によって「一連の送信単位」を「生成すること」であるといえ、また、これは「FEC符号化を遂行すること」といえる。

以上によれば、引用文献2には、「RFC2733を利用したエラー訂正方法において、FEC符号化を遂行することより、複数のMPEGパケットの直後に前記複数のMPEGパケットに対応するFECパケットを付加して、一連の送信単位を生成すること。」という技術的事項(以下、「引用文献2の記載事項」という。)が記載されていると認める。

第5 対比・判断
1 対比
本願発明と引用発明とを、以下で対比する。
(1) 引用発明の「IPTVシステム」は、本願発明における「マルチメディアシステム」に含まれる。

(2) 引用発明における「複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、RFC2733に準拠した第1のFEC符号化を遂行すること」は、本願発明における「複数のソースブロックの各々に対して、第1のFEC符号化を遂行」することに含まれる。

(3) 引用発明における「前記複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して第2の回復パケットを生成する」ことは、本願発明における「複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して少なくとも一つの第2の回復パケットを生成する」ことに含まれる。

(4) してみると、本願発明と引用発明とは、以下の点で一致し、相違する。
(一致点)
「マルチメディアシステムにおける前方誤り訂正(Forward Error Correction;FEC)符号化を遂行するための方法であって、
複数のソースシンボルブロックの各々に対して、第1のFEC符号化を遂行するステップと、
前記複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して少なくとも一つの第2の回復パケットを生成するステップと、を含み、
前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結される、
ことを特徴とする方法。」

(相違点)
一致する「第1のFEC符号化を遂行するステップ」に関して、本願発明では、「第1のFEC符号化を遂行する」ことで「各々が少なくとも一つのソースパケット及び少なくとも一つの第1の回復パケットを含むFECパケットブロック」が生成され、「前記少なくとも一つの第1の回復パケットのうちの回復パケットは、前記回復パケットに対応する第1のFECパケットブロックの境界を表す情報を含」むのに対して、引用発明では、「第1のFEC符号化を遂行」することで「第1のFECパケット」が生成され、「第1のFECパケットは、前記第1のFECパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含む」ものの、「各々が少なくとも一つのソースパケット及び少なくとも一つの第1の回復パケットを含むFECパケットブロック」が生成されること、及び、回復パケットが「回復パケットに対応する第1のFECパケットブロックの境界を表す情報を含」むことは特定されていない点。

2 検討
(1) 相違点の検討
引用文献2には、「RFC2733を利用したエラー訂正方法において、FEC符号化を遂行することより、複数のMPEGパケットの直後に前記複数のMPEGパケットに対応するFECパケットを付加して、一連の送信単位を生成すること。」(引用文献2の記載事項)が記載されている。
ここで、「MPEGパケット」はソースとしてエンコーダに入力されるパケットであるから「ソースパケット」といえ、「一連の送信単位」は「FECパケットを含む送信単位(ブロック)であるから、「FECパケットブロック」といえる。
このため、引用文献2の記載事項は、実質的に、「RFC2733を利用したエラー訂正方法において、FEC符号化を遂行することより、複数のソースパケットの直後に前記複数のソースパケットに対応するFECパケットを付加して、FECパケットブロックを生成すること。」であるといえる。
そして、引用発明における「第1のFEC符号化」は「RFC2733に準拠した符号化方式によりFEC符号化を遂行」するものであり、引用文献2の段落【0006】にはFEC技術を示す文献としてRFC2733が記載されていることから、引用発明と引用文献2の記載事項とは「RFC2733に準拠した符号化方式」である点で共通するといえ、引用発明における「RFC2733に準拠した符号化方式」として、引用文献2の記載事項を適用して、引用発明において、第1のFEC符号化を遂行することより、複数のソースパケットの直後に前記複数のソースパケットに対応するFECパケットを付加して、FECパケットブロックを生成することは、当業者であれば容易に想到し得たことである。
このとき、「FEC」は前方誤り訂正(Forward Error Correction)の意味であって、誤りを回復するものであるから、「FECパケット」は「回復パケット」といえる。
さらに、FECヘッダに含める「ソースパケットの最小のシーケンス番号」は、「複数のソースパケットと第1の回復パケットからなるFECパケットブロック」の、先頭のパケットのシーケンス番号を表すことになる。そして、「先頭のパケット」とは、自パケットを含むFECパケットブロックの開始となるパケットであり、一つ前のFECパケットブロックとの境界となるパケットであるから、「先頭のパケット」の「シーケンス番号」は「FECパケットブロックの境界を表す情報」といえる。
してみると、引用発明における「第1のFEC符号化を遂行することによって、各々が少なくと一つのソースブロックの各々に対応する第1のFECを生成する」ことに関して、「複数のソースパケット」及び「少なくとも一つの第1の回復パケット」を含む「第1のFECパケットブロック」が生成されるようにする、即ち、「第1のFEC符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第1の回復パケットを含むFECパケットブロックを生成する」ようにするとともに、「前記少なくとも一つの第1の回復パケットのうちの回復パケットは、前記回復パケットに対応する第1のFECパケットブロックの境界を表す情報を含む」ようにすることは、当業者であれば、引用発明及び引用文献2の記載事項に基づいて容易に発明できたものである。

(2) 作用・効果の検討
本願明細書の段落【0007】、【0008】の記載からみて、本願発明が解決しようとする課題は「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(FEC)パケットを生成する方法を提供すること」であり、同段落【0014】の記載からみて、本願発明の効果は「FECパケット生成及び伝送方法により、ネットワーク上の数個の伝送経路を介してコンテンツの配信中にパケットの到達シーケンスの変更又はパケット損失の発生にもかかわらず、損失したパケットを容易に回復し、それによってユーザーに良質のコンテンツ及びサービスを提供することができる」というものである。
これに対して、引用発明は「IPTVシステムにおける前方誤り訂正(FEC)符号化を遂行するための方法」であって、引用発明の「IPTVシステム」は本願発明における「マルチメディアシステム」に含まれるとともに、前方誤り訂正(FEC)符号化はパケット損失を防止するためのものであることは技術常識であることから、引用発明は「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(FEC)パケットを生成する方法」であるといえ、「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(FEC)パケットを生成する方法を提供すること」との課題は、引用発明により解決されているといえる。
また、引用発明の「第1のFECパケット」は、「FECパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含」んでいる(第4の1(2)ク参照)ことから、ネットワーク上の伝送経路を介してコンテンツの配信中にパケットの到達シーケンスの変更又はパケット損失が発生しても、到達シーケンスの変更やパケット損失を検出し、その回復は容易に行うことができることから、効果の点に顕著な差異は認められない。
以上のことから、引用発明及び引用文献2の記載事項からみて、本願発明の作用・効果は顕著なものとは認められない。

(3) 請求人の主張の検討
平成30年3月19日付け意見書において、審判請求人は「引用文献1および2は、補正後の請求項1の「複数のソースシンボルブロックの各々に対して、第1のFEC符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第1の回復パケットを含むFECパケットブロックを生成するステップと、前記複数のソースシンボルブロックに対して、第2のFEC符号化を遂行して少なくとも一つの第2の回復パケットを生成するステップと、を含み、前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結され」る構成で示されるような、2段階のFEC符号化について開示しておらず、当業者が当該構成を容易に想到可能であるような動機または示唆を示すものではありません。/以上の理由により、補正後の請求項1に係る発明は、当業者が引用文献1および2に開示の発明から容易に成し得たものではないと確信します。」と主張している(なお、「/」は改行を示す。)。
ここで、「前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結され」との事項は、本願明細書の段落【0023】の「少なくとも一つのソースパケットと少なくとも一つの第1の回復パケットの全体ペイロードに対する第2の回復シンボルを含む少なくとも一つの第2の回復パケットを生成するステップ」、及び、同段落【0024】の「少なくとも一つのソースパケットの全体ペイロードに対する第2の回復シンボルを含む少なくとも一つの第2の回復パケットを生成するステップ」に基づいた補正である旨を請求人は主張していることから、請求人の上記主張をも考慮すると、本願発明の「前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結され」るとの事項は、段落【0023】及び【0024】に開示された、少なくとも一つのソースパケットと少なくとも一つの第1の回復パケットの全体ペイロードに対する第2の回復シンボルを含む少なくとも一つの第2の回復パケットを生成するという2段階のFEC符号化を示すものであると解される。
これに対して、引用発明は、上記第4の1(2)イのとおり、段落[0055]に「具体的には、第1の符号のソースブロックは第2の符号のソースブロックのサブセットであることが望ましい。」、及び、段落[0056]に「第1及び第2の符号のソースブロックの間の可能な関係の一例を図4に示す。図4は40個のソースパケットS0、S1、・・・、S39から構成された第2のFEC符号410のソースブロックを示す。第1のFEC420、430の2つのソースブロックは示されており、各々は40個のパケットの同じセットから選択された20個のパケットから構成される。」と記載されているとともに、図4から「第1のFEC符号のソーズブロック420はソースパケットS0、S1、・・・、S19から構成され、第1のFEC符号のソースブロック430はソースパケットS20、S21、・・・、S39から構成され、第2のFEC符号のソースブロック410は第1のFEC符号のソースブロック420、430から構成されている、すなわち、第1のFEC符号のソーズブロック420及びソースブロック430は連結されて第2のFEC符号のソースブロック410を構成していること」が読み取れることから、ソースパケットS0、S1、・・・、S19に対して第1のFEC符号化が行われて第1のFEC符号のソースブロック420が生成され、ソースパケットS20、S21、・・・、S39に対して第1のFEC符号化が行われて第1のFEC符号のソースブロック430が生成され、さらに、第1のFEC符号のソースブロック420、430に対して第2のFEC符号化が行われ、第2のFEC符号のソースブロック410が生成されているといえ、これは、同オのとおり、参考文献1の記載を参酌すれば、少なくとも一つのソースパケットと少なくとも一つの第1の回復パケットの全体ペイロードに対する第2の回復シンボルを含む少なくとも一つの第2の回復パケットを生成するという、2段階のFEC符号化が行われているといえる。
してみると、引用発明は、段落【0023】及び【0024】に開示された2段階のFEC符号化を行っており、「前記複数のソースシンボルブロックは前記第2のFEC符号化のために連結され」ているといえるから、請求人が主張するような差異があるとは認められず、請求人の主張は採用できない。

(4) 小括
上記のとおりであるから、本願発明は、引用発明及び引用文献2の記載事項から当業者が容易に発明できたものである。

第6 むすび
以上のとおり、本願発明は、特許法29条2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

よって、結論のとおり審決する。
 
別掲
 
審理終結日 2018-06-21 
結審通知日 2018-06-25 
審決日 2018-07-19 
出願番号 特願2014-518829(P2014-518829)
審決分類 P 1 8・ 121- WZ (H04L)
最終処分 不成立  
前審関与審査官 谷岡 佳彦  
特許庁審判長 北岡 浩
特許庁審判官 富澤 哲生
吉田 隆之
発明の名称 マルチメディアシステムにおける前方誤り訂正パケットの生成方法とその誤り訂正パケットを送受信する方法及び装置  
代理人 阿部 達彦  
代理人 崔 允辰  
代理人 木内 敬二  
代理人 実広 信哉  

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