【事件の表示】
　特願２０１４−５１８８２９「マルチメディアシステムにおける前方誤り訂正パケットの生成方法とその誤り訂正パケットを送受信する方法及び装置」拒絶査定不服審判事件〔平成２５年　１月１７日国際公開、ＷＯ２０１３／００９０４８、平成２６年　８月２５日国内公表、特表２０１４−５２１２４５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１２年（平成２４年）７月６日（優先権主張　平成２３年７月８日　韓国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
　　平成２７年　７月　６日：手続補正書の提出
　　平成２８年　２月　５日：拒絶理由通知
　　平成２８年　５月１６日：意見書、手続補正書の提出
　　平成２８年　９月２３日：拒絶査定
　　平成２９年　２月　３日：審判請求書の提出
　　平成２９年１２月１５日：拒絶理由通知
　　平成３０年　３月１９日：意見書、手続補正書の提出
第２　本願発明
　本願の特許請求の範囲に記載された発明は、平成３０年３月１９日付け手続補正書の特許請求の範囲に記載されたとおりであるところ、請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
「【請求項１】
　マルチメディアシステムにおける前方誤り訂正(Forward Error Correction；ＦＥＣ)符号化を遂行するための方法であって、
　複数のソースシンボルブロックの各々に対して、第１のＦＥＣ符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第１の回復パケットを含むＦＥＣパケットブロックを生成するステップと、
　前記複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して少なくとも一つの第２の回復パケットを生成するステップと、を含み、
　前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結され、
　ここで、前記少なくとも一つの第１の回復パケットのうちの回復パケットは、前記回復パケットに対応する第１のＦＥＣパケットブロックの境界を表す情報を含む、ことを特徴とする方法。」
第３　当審で通知した拒絶の理由
　当審で通知した平成２９年１２月１５日付け拒絶理由（以下、「当審の拒絶理由」という。）の拒絶理由における理由１は、「本件出願の請求項１−４に係る発明は、その出願前に日本国内または外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」というものである。
　引用文献１：米国特許出願公開第２００７／０３００１２７号明細書
　引用文献２：特開２００５−１５９４３３号公報
　参考文献：J.Rosenberg et al., An RTP Payload Format for Generic Forward Error Correction, RFC2733, 1999.12, URLhttps://tools.ietf.org/rfc/rfc2733.txt 
 
第４　引用文献
１　引用文献１
（１）　当審の拒絶理由で引用された米国特許出願公開第２００７／０３００１２７号明細書（以下、「引用文献１」という。）には、図面とともに、以下の事項が記載されている。（下線は当審が付与した。）
ア　「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.
（当審訳）「発明の概要
[0024]本発明の一実施形態によれば、通信チャネルを介して送信元から宛先へ送信するデータを符号化する方法が提供される。
この方法は、ソースシンボルの順序付けられたセットに対して機能し、ソースシンボルからゼロ又はそれ以上の冗長シンボルを生成することができ、データは第１のステップで第１のＦＥＣ符号に従って符号化され、第２のステップではデータは第２のＦＥＣ符号に従って符号化され、第２のＦＥＣ符号は第１のＦＥＣ符号よりも複雑である。
イ　「[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. ・・・略・・・」
（当審訳）「ここで記述される実施例では、符号化されるデータは「ソースブロック」に分割され、各々のブロックはいくつかの「ソースブロック」として知られるデータパケットを含む。ソースブロックの各々について、いくつかの「ＦＥＣリペア」パケットがエンコーダを用いて生成され、その数はブロック間で異なり得る。・・・略・・・」
ウ　「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.
[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.
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.
[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]上記のように、前方消失訂正符号は固定されたアルファベットから選択されたシンボルに対して作用する。例えば、シンボルは、２Ｍのサイズのアルファベットから選択することができ、その場合、シンボルと２進Ｍ桁の文字列との間に明白な対応関係が存在する。このようなシンボルはＭビットのサイズを有するものとして以下に言及する。データはしばしばパケットの形態で通信チャネルを介して送信される。
場合によっては、シンボルとパケットとの間には１対１の対応関係がある。例えば、Ｌｕｂｙ ＩＩに記載されたものを含む他の場合では、パケットがシンボルよりも大きく、パケットがいくつかのシンボルを含んでもよい。
[0053]ハイブリッドコードの場合には、いくつかの利点を得るために、第１の符号のシンボル及び第２の符号のシンボルは一定の関係を有する。
具体的には、第１の符号のソースシンボルは第２の符号の１又はそれ以上のソースシンボルのデータを含む。
ソースブロック間の関係
・・・略・・・
[0055]ハイブリッドコードの場合には、いくつかの利点を得るために、第１の符号のソースブロックと第２の符号のものとは一定の関係を有する。
具体的には、第１の符号のソースブロックは第２の符号のソースブロックのサブセットであることが望ましい。
[0056]
第１及び第２の符号のソースブロックの間の可能な関係の一例を図４に示す。図４は４０個のソースパケットＳ０、Ｓ１、・・・、Ｓ３９から構成された第２のＦＥＣ符号４１０のソースブロックを示す。第１のＦＥＣ４２０、４３０の２つのソースブロックは示されており、各々は４０個のパケットの同じセットから選択された２０個のパケットから構成される。
エ　「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.
 ・・・略・・・ 
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 
fixed rate codes such as Reed-Solomon codes
LDGM Staircase and LDGM Triangle codes.
（当審訳）「第１のＦＥＣ符号の例
・・・略・・・
他のよく知られているパリティ符号
[0145]
多くのパリティ符号が特定の適用分野において知られている。
例えばＲＦＣ２７３３では符号の例が記載されている。
・・・略・・・
第２のＦＥＣ符号の例
[0151]ここに記載されたハイブリッド符号化方式で使用される第２のＦＥＣ符号は、当技術分野において公知である多くの前方誤り訂正符号のいずれであってもよい。
例えば、第２のＦＥＣ符号は、
リード・ソロモン符号
ＬＤＧＭ階段符号、ＬＤＧＭトライアングル符号のような固定レート符号である。
オ　「[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.
（当審訳）「[0200]図５はいくつかの符号の誤り訂正の性能結果をします。その符号にはＰｒｏ−ＭＰＥＧｃｏｐ３(５１０)、ラプタ−符号(５２０)、ハイブリッド符号（５３０）が含まれ、符号５１０、５２０は第１及び第２の符号として用いられる。
この図ではＩＰＴＶに典型的な方式の結果を示し、６Ｍｂｉｔ／ｓのビデオストリームは、ＩＰデータパケットにカプセル化され、それぞれが４００ｍｓのビデオデータを含むソースブロックを使用して、ＦＥＣ保護付のネットワークを介して送信される。
カ　Figure4として、以下の図面が記載されており、この図面から、
第１のＦＥＣ符号のソースブロック４２０はソースパケットＳ０、Ｓ１、・・・、Ｓ１９から構成され、第１のＦＥＣ符号のソースブロック４３０はソースパケットＳ２０、Ｓ２１、・・・、Ｓ３９から構成され、第２のＦＥＣ符号のソースブロック４１０は第１のＦＥＣ符号のソースブロック４２０、４３０から構成されていること
（２）　引用文献１の上記摘記事項から、以下の事項がいえる。
ア　上記（１）オの段落[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.」（「この図ではＩＰＴＶに典型的な方式の結果を示し、６Ｍｂｉｔ／ｓのビデオストリームは、ＩＰデータパケットにカプセル化され、それぞれが４００ｍｓのビデオデータを含むソースブロックを使用して、ＦＥＣ保護付のネットワークを介して送信される。」）との記載からみて、前方誤り訂正（ＦＥＣ）符号化をＩＰＴＶシステムに適用することが記載されており、引用文献１には、「ＩＰＴＶシステムにおける前方誤り訂正（ＦＥＣ）符号化を遂行するための方法。」が記載されているといえる。
イ　上記（１）カによれば、Figure4からは、「
第１のＦＥＣ符号のソースブロック４２０はソースパケットＳ０、Ｓ１、・・・、Ｓ１９から構成され、第１のＦＥＣ符号のソースブロック４３０はソースパケットＳ２０、Ｓ２１、・・・、Ｓ３９から構成され、第２のＦＥＣ符号のソースブロック４１０は第１のＦＥＣ符号のソースブロック４２０、４３０から構成されていること
　ここで、本願明細書の段落【００２９】の「第１のＦＥＣ符号化により生成されたＭ個の第１の符号化シンボル２０５〜２０７又はＭ個の第１のソースシンボル２０１ａ〜２０３ａは、第２のソースシンボルとして使用され、図２に示すように、第２の符号化シンボルのような第２の符号化シンボル２０９は、第２のソースシンボルに対して第２のＦＥＣ符号化を遂行することによって、第１の符号化シンボル２０５〜２０７と第２の回復シンボルのような第２の回復シンボル２０８を含むことができる。」との記載によれば、「連結」とは「第１のＦＥＣ符号化」の対象である「Ｍ個の第１のソースシンボル２０１ａ〜２０３ａ」を「第２のソースシンボル」として「第２のＦＥＣ符号化」の対象として使用する処理であると解することは、少なくとも排除されない。
　してみると、上記のFigure4から読み取れる事項は、「
第１のＦＥＣ符号のソースブロック４２０及びソースブロック４３０は連結されて第２のＦＥＣ符号のソースブロックを構成されていること
ウ　(I) 上記（１）ウの段落[0055]の「Specifically, the source blocks of the first code preferentially should each be a subset of a source block of the second code.」（「具体的には、
第１の符号のソースブロックは第２の符号のソースブロックのサブセットである
　(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.」（「第１及び第２の符号のソースブロックの間の可能な関係の一例を図４に示す。図４は
４０個のソースパケットＳ０、Ｓ１、・・・、Ｓ３９から構成された第２のＦＥＣ符号４１０のソースブロックを示す。第１のＦＥＣ４２０、４３０の２つのソースブロックは示されており、各々は４０個のパケットの同じセットから選択された２０個のパケットから構成される。
　(III) 図４から読み取れる「
第１のＦＥＣ符号のソーズブロック４２０はソースパケットＳ０、Ｓ１、・・・、Ｓ１９から構成され、第１のＦＥＣ符号のソースブロック４３０はソースパケットＳ２０、Ｓ２１、・・・、Ｓ３９から構成され、第２のＦＥＣ符号のソースブロック４１０は第１のＦＥＣ符号のソースブロック４２０、４３０から構成されている
第１のＦＥＣ符号のソーズブロック４２０及びソースブロック４３０は連結されて第２のＦＥＣ符号のソースブロック４１０を構成していること
を総合すると、「第１のＦＥＣ符号を構成する複数のソースブロックの各々は、少なくとも一つのソースパケットから構成されること。」、「第１のＦＥＣ符号を構成する複数のソースブロックは第２のＦＥＣ符号のソースブロックを構成すること。」及び「第１のＦＥＣ符号を構成する複数のソースブロックは連結されて、第２のＦＥＣ符号のソースブロックを構成していること。」が記載されているといえる。
　このため、上記「第１のＦＥＣ符号を構成する複数のソースブロックの各々は、少なくとも一つのソースパケットから構成されること。」との事項から、「少なくとも一つのソースパケットから構成される複数のソースブロックの各々に対して第１のＦＥＣ符号化が遂行されること。」が記載されているといえ、上記「第１のＦＥＣ符号を構成する複数のソースブロックは第２のＦＥＣ符号のソースブロックを構成すること。」との事項から、「前記複数のソースブロックに対して、第２のＦＥＣ符号化が遂行されていること。」が記載されているといえ、上記「第１のＦＥＣ符号を構成する複数のソースブロックは連結されて、第２のＦＥＣ符号のソースブロックを構成していること。」との事項から、「前記複数のソースブロックは第２のＦＥＣ符号化のために連結されていること。」が記載されているといえる。
エ　上記（１）ウの段落[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.」（「場合によっては、シンボルとパケットとの間には１対１の対応関係がある。例えば、Ｌｕｂｙ ＩＩに記載されたものを含む他の場合では、パケットがシンボルよりも大きく、パケットがいくつかのシンボルを含んでもよい。」）との記載からみて、引用文献１には、「ソースパケットは、１又は複数のシンボルを含むこと。」が記載されているといえる。 
　ここで、上記（１）アの段落[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.」（「この方法は、ソースシンボルの順序付けられたセットに対して機能し、ソースシンボルからゼロ又はそれ以上の冗長シンボルを生成することができ、データは第１のステップで第１のＦＥＣ符号に従って符号化され、第２のステップではデータは第２のＦＥＣ符号に従って符号化され、第２のＦＥＣ符号は第１のＦＥＣ符号よりも複雑である。」）との記載からみて、段落[0052]の「ｓｙｍｂｏｌｓ」（シンボル）は「ｓｏｕｒｃｅ　ｓｙｍｂｏｌｓ」（ソースシンボル）であるといえる。 
オ　前記イ乃至エの事項より、引用文献１には、「１又は複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、第１のＦＥＣ符号化を遂行すること。」が記載されているといえる。
カ　上記（１）イの段落[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.」（「ここで記述される実施例では、符号化されるデータは「ソースブロック」に分割され、各々のブロックはいくつかの「ソースブロック」として知られるデータパケットを含む。ソースブロックの各々について、いくつかの「ＦＥＣリペア」パケットがエンコーダを用いて生成され、その数はブロック間で異なり得る。）との記載、及び、実施例における符号化はＦＥＣ符号に従った符号化であった、「第１のＦＥＣ符号に従った符号化」及び「第２のＦＥＣ符号に従った符号化」とを含んでいることから、「第１のＦＥＣ符号に従った符号化」及び「第２のＦＥＣ符号に従った符号化」を遂行されることで「ＦＥＣリペア」パケット、即ち、「回復パケット」が生成されるといえる。
キ　上記（１）エの段落[0145]の直前の「Other Well-Known Parity Codes」という記載は、「Examples of First FEC Codes」（段落[0140]）の後に記載され、「Examples of Second FEC Codes」（段落[0150]）の前に記載されているから、第２のＦＥＣ符号化の例は、第１のＦＥＣ符号化の例とは別の例であるといえる。 
　そして、上記（１）エの段落[0145]には、「For example RFC 2733 describes examples of codes.」と記載されているから、引用文献１には、「ＲＦＣ２７３３に準拠した符号化方式により第１のＦＥＣ符号化を遂行すること。」が記載されているといえる。 
　ここで、ＲＦＣ２７３３に準拠した符号化方式は、メディアパケットをＦＥＣ符号化することによって、前記メディアパケットの誤りや欠落を回復するためのＦＥＣパケットを生成するものであり、また、このＦＥＣパケットのヘッダには、ＦＥＣパケットに対応するメディアパケットの最小のシーケンス番号が含まれることは、技術常識である（必要ならば、「ＲＦＣ２７３３」について記載された「J.Rosenberg et al., An RTP Payload Format for Generic Forward Error Correction, RFC2733, 1999.12, URLhttps://tools.ietf.org/rfc/rfc2733.txt」（以下、「参考文献１」という。）の下記参考記載を参照のこと。）。
（参考文献１の参考記載） 
（ア）「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.」（（当審訳）「ＦＥＣパケット：トランスミッタでの前方誤り訂正アルゴリズムは、メディアパケットを入力として受け取る。これらは、渡されたメディアパケットとＦＥＣパケットと呼ばれる新たなパケットとの両方を出力する。」）との記載。
（イ）「3 Basic Operation」の「As the sender generates FEC packets, they are sent to the receivers.」（（当審訳）「送信者がＦＥＣパケットを生成すると、それらは受信者に送信される。」）との記載。
（ウ）「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.」（（当審訳）「ＳＮベースフィールドは、ＦＥＣによって保護されたメディアパケットの最少シーケンス番号に設定されなければならない。」）との記載。
　そして、ＲＦＣ２７３３では、ＦＥＣ符号化の対象パケットをメディアパケットと言い表しているものの、メディアパケットは入力として受け取るパケットであることから、該メディアパケットはソースパケットといえる。
　したがって、技術常識を踏まえると、引用文献１には、「ＲＦＣ２７３３に準拠した第１のＦＥＣ符号化を遂行することによって、各々が少なくとも一つのソースブロックの各々に対応するＦＥＣパケット（以下、「第１のＦＥＣパケット」という。）を生成すること。」及び「前記第１のＦＥＣパケットは、前記第１のＦＥＣパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含むこと。」が記載されているといえる。
ク　上記（１）エの段落[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.」（（当審訳）「第２のＦＥＣ符号は・・・略・・・のような連鎖反応符号又はリードソロモン符号・・・略・・・ＬＤＧＭ階段符号、ＬＤＧＭトライアングル符号符号のような固定レート符号である。」）との記載からみて、引用文献１には、第２のＦＥＣ符号の例として、リードソロモン符号或いはＬＤＧＭ階段符号やＬＤＧＭトライアングル符号などのＬＤＧＭ符号を用いることが記載されている。 
　リードソロモン符号やＬＤＧＭ符号による第２のＦＥＣ符号化では、データパケットの誤りや欠落を回復するためのＦＥＣ（以下、「第２のＦＥＣ」という。）を生成するものであるということは技術常識であり、上記オを踏まえると、引用文献１には、「第２のＦＥＣ符号化を遂行して回復パケット（以下、「第２の回復パケット」という）を生成すること。」が記載されているといえる。
ケ　以上のア〜クによれば、引用文献１には、以下の発明（以下、「引用発明」という。）が記載されていると認める。
 「ＩＰＴＶシステムにおける前方誤り訂正（ＦＥＣ）符号化を遂行するための方法であって、
　複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、ＲＦＣ２７３３に準拠した第１のＦＥＣ符号化を遂行することによって、各々が少なくと一つのソースブロックの各々に対応する第１のＦＥＣパケットを生成するステップと、
　前記複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して第２の回復パケットを生成するステップと、を含み、
　前記複数のソースブロックは前記第２のＦＥＣ符号化のために連結され、
　前記第１のＦＥＣパケットは、前記第１のＦＥＣパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含む、
　ことを特徴とする方法。」 
２　引用文献２
（１）　当審の拒絶理由で引用された特開２００５−１５９４３３号公報（以下、「引用文献２」という。）には、図面とともに、以下の事項が記載されている。（下線は当審が付与した。）
ア　「【０００６】 
　さらに、
パケットロストに対応するエラー訂正手法として、例えば、ＦＥＣ［Ｆｏｒｗａｒｄ　Ｅｒｒｏｒ　Ｃｏｒｒｅｃｔｉｏｎ：後記非特許文献２（ＩＥＴＦ　ＲＦＣ２７３３）参照］という技術がある。
イ　「【００５４】 
　なお、上述した例では、冗長パケットの送信間隔により再送要求の送信タイミングを制御しているが、ＭＰＥＧパケットの送信間隔に基づいて前記のようなレート計算を行なうことでも、上記と同様の作用効果が得られる。 
　〔Ｂ〕第２実施形態の説明 
　上述した第１実施形態では、冗長パケットの送信間隔によって再送要求を即時で送信するかどうかを判断したが、低レートの場合でもロストしたパケット（番号）によっては直後に冗長パケットを受信する可能性がある。
例えば図５に示すように、Ｎ＝１０個のＭＰＥＧパケットに１個の冗長パケット（ＦＥＣパケット）を送信する場合、
ウ　「【００５６】 
　
例えば、システムレート＝１００ｋｂｐｓ、パケット長＝５１２バイト、冗長パケット生成間隔＝１０パケットに１個で、図５に示す１番や１１番のパケットがロストした場合は、
　
（５１２［ｂｙｔｅｓ］＊８［ｂｉｔｓ／ｂｙｔｅ］／１０００００［ｂｉｔｓ／ｓｅｃ］）＊１０＝４０９．６［ｍｓｅｃ］
となり、４０９．６ｍｓｅｃ経過するまで冗長パケットが到着しない。
　
一方、同じ条件（システムレート＝１００ｋｂｐｓ、パケット長＝５１２バイト、冗長パケット生成間隔＝１０パケットに１個）で、図５に示す１０番や２０番のパケットがロストした場合は、
　
(５１２［ｂｙｔｅｓ］＊８［ｂｉｔｓ／ｂｙｔｅ］／１００，０００［ｂｉｔｓ／ｓｅｃ］）＊１＝４０．９６［ｍｓｅｃ］
となり、４０．９６ｍｓｅｃ後には冗長パケットが到着することになる。
エ　図５として、以下の図面が記載されており、この図面から、
１０個のＭＰＥＧパケット１、２、・・・、１０に対して１個のＦＥＣパケット修復パケットが挿入され、１０個のＭＰＥＧパケット１１、１２、・・・、２０に対して１個のＦＥＣパケット修復パケットが挿入されて、送信されること
（２）　上記（１）ア〜同エの摘記事項から以下の事項がいえる。
　引用文献２の段落【００５４】の「例えば図５に示すように、Ｎ＝１０個のＭＰＥＧパケットに１個の冗長パケット（ＦＥＣパケット）を送信する場合、」という記載、及び、第５図から読み取れる「１０個のＭＰＥＧパケット１、２、・・・、１０に対して１個のＦＥＣパケット修復パケットが挿入され、１０個のＭＰＥＧパケット１１、１２、・・・、２０に対して１個のＦＥＣパケット修復パケットが挿入されて、送信されること」との事項からみて、引用文献２には、「１０個のＭＰＥＧパケットにつき、１個のＦＥＣパケットを挿入して送信すること。」が記載されているといえる。
　この「１個のＦＥＣパケット」に関連して、段落【００５６】に示された数式をみると、シーケンス番号１番と１１番のＭＰＥＧパケットについては、「（５１２［ｂｙｔｅｓ］＊８［ｂｉｔｓ／ｂｙｔｅ］／１００，０００［ｂｉｔｓ／ｓｅｃ］）＊１０」の時間後に、対応する「１個のＦＥＣパケット」を受信することが示されている。
 　段落【００５６】の「システムレート＝１００ｋｂｐｓ、パケット長＝５１２バイト」という記載より、前記数式のうち「（５１２［ｂｙｔｅｓ］＊８［ｂｉｔｓ／ｂｙｔｅ］／１００，０００［ｂｉｔｓ／ｓｅｃ］）」の部分は「１つのＭＰＥＧパケットの受信に要する時間」であるといえるから、その「＊１０」倍の時間後に「１個のＦＥＣパケット」を受信するということは、シーケンス番号１番、１１番のＭＰＥＧパケットについては、自パケットの１０個後に、対応するＦＥＣパケットを受信するといえる。
　同様に、シーケンス番号１０番と２０番のＭＰＥＧパケットについては、「（５１２［ｂｙｔｅｓ］＊８［ｂｉｔｓ／ｂｙｔｅ］／１００，０００［ｂｉｔｓ／ｓｅｃ］）＊１」の時間後にＦＥＣパケットを受信することが記載されいるから、１０番と２０番のＭＰＥＧパケットについては、自パケットのすぐ後（「＊１」）に、それぞれに対応するＦＥＣパケットを受信するといえる。
　してみると、段落【００５４】や第５図において、「１０個のＭＰＥＧパケット」につき挿入される「１個のＦＥＣパケット」は、「直前の１０個のＭＰＥＧパケット」を回復する「ＦＥＣパケット」であるから、引用文献２には、「１０個のＭＰＥＧパケットにつき、その直後に、前記１０個のＭＰＥＧパケットに対応する１個のＦＥＣパケットを挿入して送信すること。」が記載されているといえる。
　そして、「１０個のＭＰＥＧパケットにつき、その直後に、前記１０個のＭＰＥＧパケットに対応する１個のＦＥＣパケットを挿入して送信する」ということは、「複数（１０個）のＭＰＥＧパケットの直後に前記複数（１０個）のＭＰＥＧパケットに対応する（１個の）ＦＥＣパケット」によって「一連の送信単位」を「生成すること」であるといえ、また、これは「ＦＥＣ符号化を遂行すること」といえる。
　以上によれば、引用文献２には、「ＲＦＣ２７３３を利用したエラー訂正方法において、ＦＥＣ符号化を遂行することより、複数のＭＰＥＧパケットの直後に前記複数のＭＰＥＧパケットに対応するＦＥＣパケットを付加して、一連の送信単位を生成すること。」という技術的事項（以下、「引用文献２の記載事項」という。）が記載されていると認める。
第５　対比・判断
１　対比
　本願発明と引用発明とを、以下で対比する。
（１）　引用発明の「ＩＰＴＶシステム」は、本願発明における「マルチメディアシステム」に含まれる。
（２）　引用発明における「複数のソースシンボルを含む複数のソースパケットから構成される複数のソースブロックの各々に対して、ＲＦＣ２７３３に準拠した第１のＦＥＣ符号化を遂行すること」は、本願発明における「複数のソースブロックの各々に対して、第１のＦＥＣ符号化を遂行」することに含まれる。
  
（３）　引用発明における「前記複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して第２の回復パケットを生成する」ことは、本願発明における「複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して少なくとも一つの第２の回復パケットを生成する」ことに含まれる。
（４）　してみると、本願発明と引用発明とは、以下の点で一致し、相違する。
（一致点）
　「マルチメディアシステムにおける前方誤り訂正(Forward Error Correction；ＦＥＣ)符号化を遂行するための方法であって、
　複数のソースシンボルブロックの各々に対して、第１のＦＥＣ符号化を遂行するステップと、
　前記複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して少なくとも一つの第２の回復パケットを生成するステップと、を含み、
　前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結される、
ことを特徴とする方法。」
（相違点）
　一致する「第１のＦＥＣ符号化を遂行するステップ」に関して、本願発明では、「第１のＦＥＣ符号化を遂行する」ことで「各々が少なくとも一つのソースパケット及び少なくとも一つの第１の回復パケットを含むＦＥＣパケットブロック」が生成され、「前記少なくとも一つの第１の回復パケットのうちの回復パケットは、前記回復パケットに対応する第１のＦＥＣパケットブロックの境界を表す情報を含」むのに対して、引用発明では、「第１のＦＥＣ符号化を遂行」することで「第１のＦＥＣパケット」が生成され、「第１のＦＥＣパケットは、前記第１のＦＥＣパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含む」ものの、「各々が少なくとも一つのソースパケット及び少なくとも一つの第１の回復パケットを含むＦＥＣパケットブロック」が生成されること、及び、回復パケットが「回復パケットに対応する第１のＦＥＣパケットブロックの境界を表す情報を含」むことは特定されていない点。
２　検討
（１）　相違点の検討
　引用文献２には、「ＲＦＣ２７３３を利用したエラー訂正方法において、ＦＥＣ符号化を遂行することより、複数のＭＰＥＧパケットの直後に前記複数のＭＰＥＧパケットに対応するＦＥＣパケットを付加して、一連の送信単位を生成すること。」（引用文献２の記載事項）が記載されている。
　ここで、「ＭＰＥＧパケット」はソースとしてエンコーダに入力されるパケットであるから「ソースパケット」といえ、「一連の送信単位」は「ＦＥＣパケットを含む送信単位（ブロック）であるから、「ＦＥＣパケットブロック」といえる。
　このため、引用文献２の記載事項は、実質的に、「ＲＦＣ２７３３を利用したエラー訂正方法において、ＦＥＣ符号化を遂行することより、複数のソースパケットの直後に前記複数のソースパケットに対応するＦＥＣパケットを付加して、ＦＥＣパケットブロックを生成すること。」であるといえる。
　そして、引用発明における「第１のＦＥＣ符号化」は「ＲＦＣ２７３３に準拠した符号化方式によりＦＥＣ符号化を遂行」するものであり、引用文献２の段落【０００６】にはＦＥＣ技術を示す文献としてＲＦＣ２７３３が記載されていることから、引用発明と引用文献２の記載事項とは「ＲＦＣ２７３３に準拠した符号化方式」である点で共通するといえ、引用発明における「ＲＦＣ２７３３に準拠した符号化方式」として、引用文献２の記載事項を適用して、引用発明において、第１のＦＥＣ符号化を遂行することより、複数のソースパケットの直後に前記複数のソースパケットに対応するＦＥＣパケットを付加して、ＦＥＣパケットブロックを生成することは、当業者であれば容易に想到し得たことである。
　このとき、「ＦＥＣ」は前方誤り訂正（Forward Error Correction）の意味であって、誤りを回復するものであるから、「ＦＥＣパケット」は「回復パケット」といえる。
　さらに、ＦＥＣヘッダに含める「ソースパケットの最小のシーケンス番号」は、「複数のソースパケットと第１の回復パケットからなるＦＥＣパケットブロック」の、先頭のパケットのシーケンス番号を表すことになる。そして、「先頭のパケット」とは、自パケットを含むＦＥＣパケットブロックの開始となるパケットであり、一つ前のＦＥＣパケットブロックとの境界となるパケットであるから、「先頭のパケット」の「シーケンス番号」は「ＦＥＣパケットブロックの境界を表す情報」といえる。 
　してみると、引用発明における「第１のＦＥＣ符号化を遂行することによって、各々が少なくと一つのソースブロックの各々に対応する第１のＦＥＣを生成する」ことに関して、「複数のソースパケット」及び「少なくとも一つの第１の回復パケット」を含む「第１のＦＥＣパケットブロック」が生成されるようにする、即ち、「第１のＦＥＣ符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第１の回復パケットを含むＦＥＣパケットブロックを生成する」ようにするとともに、「前記少なくとも一つの第１の回復パケットのうちの回復パケットは、前記回復パケットに対応する第１のＦＥＣパケットブロックの境界を表す情報を含む」ようにすることは、当業者であれば、引用発明及び引用文献２の記載事項に基づいて容易に発明できたものである。
（２）　作用・効果の検討
　本願明細書の段落【０００７】、【０００８】の記載からみて、本願発明が解決しようとする課題は「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(ＦＥＣ)パケットを生成する方法を提供すること」であり、同段落【００１４】の記載からみて、本願発明の効果は「ＦＥＣパケット生成及び伝送方法により、ネットワーク上の数個の伝送経路を介してコンテンツの配信中にパケットの到達シーケンスの変更又はパケット損失の発生にもかかわらず、損失したパケットを容易に回復し、それによってユーザーに良質のコンテンツ及びサービスを提供することができる」というものである。
　これに対して、引用発明は「ＩＰＴＶシステムにおける前方誤り訂正（ＦＥＣ）符号化を遂行するための方法」であって、引用発明の「ＩＰＴＶシステム」は本願発明における「マルチメディアシステム」に含まれるとともに、前方誤り訂正（ＦＥＣ）符号化はパケット損失を防止するためのものであることは技術常識であることから、引用発明は「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(ＦＥＣ)パケットを生成する方法」であるといえ、「マルチメディアシステムにおけるパケット損失を防止するように前方誤り訂正(ＦＥＣ)パケットを生成する方法を提供すること」との課題は、引用発明により解決されているといえる。
　また、引用発明の「第１のＦＥＣパケット」は、「ＦＥＣパケットに対応するソースブロックを構成するソースパケットの最小のシーケンス番号を含」んでいる（第４の１（２）ク参照）ことから、ネットワーク上の伝送経路を介してコンテンツの配信中にパケットの到達シーケンスの変更又はパケット損失が発生しても、到達シーケンスの変更やパケット損失を検出し、その回復は容易に行うことができることから、効果の点に顕著な差異は認められない。
　以上のことから、引用発明及び引用文献２の記載事項からみて、本願発明の作用・効果は顕著なものとは認められない。
（３）　請求人の主張の検討
　平成３０年３月１９日付け意見書において、審判請求人は「引用文献１および２は、補正後の請求項１の「複数のソースシンボルブロックの各々に対して、第１のＦＥＣ符号化を遂行して各々が少なくとも一つのソースパケット及び少なくとも一つの第１の回復パケットを含むＦＥＣパケットブロックを生成するステップと、前記複数のソースシンボルブロックに対して、第２のＦＥＣ符号化を遂行して少なくとも一つの第２の回復パケットを生成するステップと、を含み、前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結され」る構成で示されるような、２段階のＦＥＣ符号化について開示しておらず、当業者が当該構成を容易に想到可能であるような動機または示唆を示すものではありません。／以上の理由により、補正後の請求項１に係る発明は、当業者が引用文献１および２に開示の発明から容易に成し得たものではないと確信します。」と主張している（なお、「／」は改行を示す。）。
　ここで、「前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結され」との事項は、本願明細書の段落【００２３】の「少なくとも一つのソースパケットと少なくとも一つの第１の回復パケットの全体ペイロードに対する第２の回復シンボルを含む少なくとも一つの第２の回復パケットを生成するステップ」、及び、同段落【００２４】の「少なくとも一つのソースパケットの全体ペイロードに対する第２の回復シンボルを含む少なくとも一つの第２の回復パケットを生成するステップ」に基づいた補正である旨を請求人は主張していることから、請求人の上記主張をも考慮すると、本願発明の「前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結され」るとの事項は、段落【００２３】及び【００２４】に開示された、少なくとも一つのソースパケットと少なくとも一つの第１の回復パケットの全体ペイロードに対する第２の回復シンボルを含む少なくとも一つの第２の回復パケットを生成するという２段階のＦＥＣ符号化を示すものであると解される。
　これに対して、引用発明は、上記第４の１（２）イのとおり、段落[0055]に「具体的には、第１の符号のソースブロックは第２の符号のソースブロックのサブセットであることが望ましい。」、及び、段落[0056]に「第１及び第２の符号のソースブロックの間の可能な関係の一例を図４に示す。図４は４０個のソースパケットＳ０、Ｓ１、・・・、Ｓ３９から構成された第２のＦＥＣ符号４１０のソースブロックを示す。第１のＦＥＣ４２０、４３０の２つのソースブロックは示されており、各々は４０個のパケットの同じセットから選択された２０個のパケットから構成される。」と記載されているとともに、図４から「第１のＦＥＣ符号のソーズブロック４２０はソースパケットＳ０、Ｓ１、・・・、Ｓ１９から構成され、第１のＦＥＣ符号のソースブロック４３０はソースパケットＳ２０、Ｓ２１、・・・、Ｓ３９から構成され、第２のＦＥＣ符号のソースブロック４１０は第１のＦＥＣ符号のソースブロック４２０、４３０から構成されている、すなわち、第１のＦＥＣ符号のソーズブロック４２０及びソースブロック４３０は連結されて第２のＦＥＣ符号のソースブロック４１０を構成していること」が読み取れることから、ソースパケットＳ０、Ｓ１、・・・、Ｓ１９に対して第１のＦＥＣ符号化が行われて第１のＦＥＣ符号のソースブロック４２０が生成され、ソースパケットＳ２０、Ｓ２１、・・・、Ｓ３９に対して第１のＦＥＣ符号化が行われて第１のＦＥＣ符号のソースブロック４３０が生成され、さらに、第１のＦＥＣ符号のソースブロック４２０、４３０に対して第２のＦＥＣ符号化が行われ、第２のＦＥＣ符号のソースブロック４１０が生成されているといえ、これは、同オのとおり、参考文献１の記載を参酌すれば、少なくとも一つのソースパケットと少なくとも一つの第１の回復パケットの全体ペイロードに対する第２の回復シンボルを含む少なくとも一つの第２の回復パケットを生成するという、２段階のＦＥＣ符号化が行われているといえる。
　してみると、引用発明は、段落【００２３】及び【００２４】に開示された２段階のＦＥＣ符号化を行っており、「前記複数のソースシンボルブロックは前記第２のＦＥＣ符号化のために連結され」ているといえるから、請求人が主張するような差異があるとは認められず、請求人の主張は採用できない。
（４）　小括
　上記のとおりであるから、本願発明は、引用発明及び引用文献２の記載事項から当業者が容易に発明できたものである。
第６　むすび
　以上のとおり、本願発明は、特許法２９条２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。