【事件の表示】
　特願２０１５−５１１３５６「放送及び通信システムにおけるパケット送受信装置及び方法」拒絶査定不服審判事件〔平成２５年１１月１４日国際公開、ＷＯ２０１３／１６８９６４、平成２７年　７月２３日国内公表、特表２０１５−５２０９９０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１３年（平成２５年）５月７日（パリ条約による優先権主張　外国庁受理２０１２年５月７日、大韓民国、外国庁受理２０１２年５月１１日、大韓民国）を国際出願日とする出願であって、平成２９年２月１０日付けの拒絶理由の通知に対し、平成２９年５月２２日に意見書が提出されるとともに手続補正がなされたが、平成２９年１１月２日付けで拒絶査定がなされ、これに対して、平成３０年３月１３日に拒絶査定不服審判の請求がなされると同時に手続補正がなされたものである。
第２　平成３０年３月１３日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３０年３月１３日にされた手続補正（以下、「本件補正」という。）を却下する。
［理由］
１　本件補正について（補正の内容）
（１）本件補正後の特許請求の範囲の記載
　本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された（下線部は、補正箇所である。）。
「放送及び通信システムにおけるデータを送信する方法であって、
　同一の数の同一のサイズのシンボルエレメントに各々が分割される複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
　第１のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第１のシンボルエレメントに配置し、前記第１のソースパケットに後続する第２のソースパケットを前記第１のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第２のシンボルエレメントに配置するステップと、前記ソースシンボルブロックの前記複数のソースシンボルを符号化して伝送するステップとを含み、
　前記第１のシンボルエレメントの最後のシンボルエレメントが第１のソースシンボルの最後のシンボルエレメントではない場合、前記第１のソースパケットの少なくとも一部及び前記第２のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第１のソースシンボルに配置され、
　
前記第１のシンボルエレメントの最後のシンボルエレメントが前記第１のソースシンボルの最後のシンボルエレメントではなく、
（２）本件補正前の特許請求の範囲
　本件補正前の、平成２９年５月２２日にされた手続補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。
　「放送及び通信システムにおけるデータを送信する方法であって、
　同一の数の同一のサイズのシンボルエレメントに各々が分割される複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
　第１のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第１のシンボルエレメントに配置し、前記第１のソースパケットに後続する第２のソースパケットを前記第１のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第２のシンボルエレメントに配置するステップと、前記ソースシンボルブロックの前記複数のソースシンボルを符号化して伝送するステップとを含み、
　前記第１のシンボルエレメントの最後のシンボルエレメントが第１のソースシンボルの最後のシンボルエレメントではない場合、前記第１のソースパケットの少なくとも一部及び前記第２のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第１のソースシンボルに配置され、
　前記第１のソースパケットが前記第１のシンボルエレメントを満たさない場合、前記第１のシンボルエレメントの最後のシンボルエレメントは、前記第２のシンボルエレメントの最初のシンボルエレメントの前までパディングされることを特徴とするデータ送信方法。」
２　補正の適否
　本件補正は、本件補正前の請求項１に記載された「データ送信方法」における、「前記第１のソースパケットが前記第１のシンボルエレメントを満たさない場合」の動作について、上記のとおり、さらに、「前記第１のシンボルエレメントの最後のシンボルエレメントが前記第１のソースシンボルの最後のシンボルエレメントではなく、」との限定を付加するものであって、補正前の請求項１に記載された発明と補正後の請求項１に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の請求項１に記載される発明（以下、「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について、以下、検討する。
（１）本件補正発明
　本件補正発明は、上記１（１）に記載したとおりのものである。
（２）引用文献の記載事項
ア　引用文献１
（ア）原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である、「Samsung Electronics Co., Ltd.，Proposed Evaluation Procedure for Source Block Construction[online]，  3GPP TSG-SA WG4#68    S4-120366，インターネット＜URL:http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_68/Docs/S4-120366.zip＞，２０１２年　４月」（以下、「引用文献１」という。）には、図面とともに、次の記載がある。
「2 Use Case
2.1 Introduction
According to a generic mechanism for applying MBMS Forward Error Correction (FEC) defined in TS26.346 Clause 8.2.2, the mechanism consists of three components:
(i) 
Construction of an FEC source block from the source media packets
(ii) 
Modification of source packets
(iii) 
Definition of repair packets
(i) and (ii) are closely related to source block construction and (iii) is related to FEC coding scheme.
The performance of AL-FEC scheme can be improved by not only an enhanced FEC coding scheme, but also more efficient source block structure. This clause addresses the importance of efficient construction of the FEC source block which is related to the first two components of FEC mechanism. Note that the terminology used in the description of the FEC framework and scheme is aligned with what is defined in TS26.346 Clause 8.2.2 and Annex B.1.1.」（第１頁第１３行〜第３０行）
（当審仮訳：２　使用事例
２．１イントロダクション
TS26.346第8.2.2節に定義された
MBMS前方誤り訂正（FEC）を適用するための一般的なメカニズム
（i）（時間内の）ストリームの特定のセグメントに関連した、１個又は数個のUDPパケットフローに属するソースメディアパケットからのFECソースブロックの構成。UDPフローには、RTP、RTCP、SRTP及びMIKEYパケットなどが含まれる。
（ii）ソースブロック内のソースパケットからのソースデータの位置を示すソースパケットの改変
（iii）UDPを通して送られる、リペアパケットの定義、リペアパケットは、ソースブロックの欠落部分を再構成するために、FEC復号器によって使用される。
（i）と（ii）はソースブロックの構成に密接に関連し、そして、（iii）はFEC符号化スキームに関連する。
AL-FECスキームの性能はFEC符号化スキームの拡張だけでなく、より効率的なブロック構造によっても改善する。この節では、FECメカニズムの最初の２つのコンポーネントに関連するFECソースブロックの効率的な構成の重要性について述べる。なお、FECフレームワーク及びスキームの説明に使用される用語は、TS26.346第8.2.2節及び付録B.1.1において定義されたものと整合している。）（仮訳の下線は当審で付与。以下同じ。）
「2.2 Overview of MBMS AL-FEC Scheme
A conceptual process of MBMS AL-FEC scheme is depicted in Figure 1. The AL-FEC scheme begins by processing source packets to construct a source block. More precisely, a source block builder in Figure 1 generates a source block by piling up an ordered sequence of source packets (or source data) to be protected.
After constructing the source block, the source block builder passes the source symbols to the FEC encoder as the input. Here, the source symbol is a unit of data within a source block upon which the FEC scheme operates. It is clear that the form of source symbols is determined by the operation of the source block builder. Furthermore, for given source packets, the number of source symbols, namely K, can differ depending on the operation.
Finally, the FEC encoder generates the desired amount (NR) of repair symbols from the source symbols and places these symbols into FEC repair packets, to be conveyed to the receivers. These repair packets are sent using normal UDP procedures to a unique destination port to separate it from any of the source packet flows. Note that the source blocking algorithm and the FEC coding are relatively independent operation, furthermore, this AL-FEC encoding process is applied to each source block independently.
In the current construction method for the FEC source block defined in TS26.346, each source packet generates one or more source symbols independently to the other source packets. In other words, no source symbol includes a part of data from two or more source packets. This restriction induces a zero-padding process as shown in Figure 1. As a result, an increase of the number of source symbols is caused by the zero-padding operation, even though the zero-padded data are not transmitted.」（第２頁第１行〜第２２行）
（当審仮訳：２．２　MBMS AL-FECスキームの概説
図１にMBMS AL-FECスキームの概念的なプロセスを示す。AL-FECスキームはソースブロックを構成するソースパケットを処理することによって開始される。より正確には、図１の
ソースブロック構成器は、保護されるべきソースパケット
の順序付けられたシーケンスを積み重ねることによってソースブロックを生成する
ソースブロックを構成した後、ソースブロック構成器はソースシンボルをFEC符号化器に入力として渡す
ソースシンボルはFECスキームが動作するソースブロック内のデータ単位である
ソースシンボルの数、ここではK
最後に、FEC符号化器はソースシンボルから所望の量（NR）のリペアシンボルを生成し、受信機に伝達されるように、これらのシンボルをFECリペアパケットに入れる
TS26.346で定義されている
FECソースブロックの現在の構成方法では、各ソースパケットは１個又はそれ以上のソースシンボルを他のソースパケットと独立して生成する
ソースシンボルが２個又はそれ以上のソースパケットからのデータ部分を含むことはない。この制限により、
ゼロパディング処理が含まれる
ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまう
「2.3 Relation Between Source Block Structure and Performance
In this sub-clause, we present a necessity of the enhancement to the current source blocking algorithm with some simple examples. For this, we assume first that the current MBMS source blocking algorithm generates K source symbols from a given source packets. Therefore, the coding rate is defined by K/(K + NR) for AL-FEC scheme with the current MBMS source blocking algorithm where NR means the number of repair symbols (packets).
In addition, we assume that there is another source blocking algorithm generating K’ source symbols from the same source packets, for an integer K’ less than K, as depicted in Figure 2. Therefore, the coding rate is defined by K’/(K’ + NR) for new source blocking algorithm. Note that a decrease of the number of source symbols can be achieved by a reduction of zero-padding portion in the source block.
From an FEC viewpoint, the FEC coding rate is closely related to robustness of source data protection. In general, the smaller coding rate provides more robustness for fixed amount of parity data. Therefore, the latter source block algorithm in Figure 2 can provide more robust protection level than the current MBMS algorithm in Figure 1 since K’/(K’ + NR) is smaller than K/(K + NR) for fixed NR.
For easy understanding, we describe a very simple example in Figures 3 and 4. First, in Figure 3, assume that 10 (= K) source symbols are generated by the current MBMS source blocking algorithm and 9 (= NR) repair symbols are generated by an FEC encoder. Here, any FEC encoder is available. Furthermore, assume that 3 source packets and 4 repair packets (symbols) are lost on the network. As shown in Figure 3, 3 lost source packets corresponds to the loss of 6 source symbols (60% of the all source symbols). As a result, the receiver takes just 9 symbols and it is clear that the receiver cannot reconstruct the source block completely since the number of received symbols, 9, is smaller than the number of all source symbols, 10. That is, we cannot recover some source packets.
Second, for the source block in Figure 4, assume that 7 (= K) source symbols and 9 (= NR) repair symbols are generated by another source blocking algorithm and the same FEC encoder in Figure 3, respectively, and the same 3 source packets and 4 repair packets are lost. Furthermore, assume that 3 lost source packets corresponds to the loss of 4 source symbols in the new source block, as shown in Figure 4 (57% of the all source symbols). In this case, we can recover all the source packets since the number of received symbols, 8, is larger than the number of all source symbols, 7.
Consequently, it indicates that the source blocking algorithm in Figure 4 can provide more robust protection level than the current source blocking algorithm. Note that the number of repair symbols (packets), NR, and the symbol size T are fixed for the given source data, and only the source block structures are different in Figures 3 and 4. Therefore, the overhead for both cases is the same such as T*NR/Bs where Bs means the total data size ([bits] or [bytes]) of all source packets.
In summary, for given source data (or source packets) and symbol size, if a source block algorithm creates less source symbols than the current MBMS source blocking algorithm, it can provide more robust protection level without additional overhead, for given FEC code. Therefore, the enhancement to the current source blocking algorithm is needed to maximize the performance of AL-FEC scheme.」（第３頁第１行〜第５頁第１１行）
（当審仮訳：２．３　ソースブロックの構成と性能の関係
この小節では、いくつかの簡単な例を用いて現在のソースブロッキングアルゴリズムの拡張の必要性を示す。このために、まず現在のMBMSソースブロッキングアルゴリズムが所与のソースパケットからK個のソースシンボルを生成すると仮定する。それゆえ、NRがリペアシンボル（パケット）の数を示すなら、現在のMBMSソースブロッキングアルゴリズムを用いたAL-FEC方式では、符号化率は、K/(K+NR)で定義される。
さらに、同一のソースパケットからK’個のソースシンボルを生成する
別のソースブロッキングアルゴリズム
新しいソースブロッキングアルゴリズム
ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得る
FECの観点からは、FEC符号化率は、ソースデータ保護のロバスト性と密接に関連している。一般的に、符号化率を小さくすると一定の量のパリティデータに対してよりロバスト性が高くなる。したがって、NRが固定の場合に、K’/(K’ + NR)はK/(K + NR)より小さいから、図1の現在のMBMSアルゴリズムよりも、図２の後者のソースブロックアルゴリズムは、よりロバスト性が高くなる。
理解を容易にするために、図３と図４に極めて簡単な例を示す。まず、図３では、
１０ (= K)個のソースシンボルが現在のMBMSソースブロッキングアルゴリズムによって生成され、９(= N
R
)個のリペアシンボルがFEC符号化器によって生成される
受信機は９個のシンボルだけを受け取り
受信されたシンボル
次に、
図４のソースブロックについて、それぞれ７個(=K)のソースシンボルと９個(=
)のリペアシンボルが、別のソースブロッキングアルゴリズムにより、そして、図３と同一のFEC符号化器により生成され
結果として、
図４のソースブロッキングアルゴリズム
シンボルサイズTは所与のソースデータに対して固定されており、図３と図４でソースブロックの構成だけが異なること
まとめると、
所与のソースデータ（又はソースパケット）及びシンボルサイズについて、ソースブロックアルゴリズムが現在のMBMSソースブロッキングアルゴリズムよりも少ないソースシンボルを生成するなら、所与のFECコードに対して、よりロバスト性が高い保護レベルを追加のオーバヘッドなしに提供することができる
「Figure 1 Conceptual AL-FEC Mechanism with the Current MBMS Source Block (K = 10, NR = 9)
」
（タイトルの当審仮訳：図１　現在のMBMSソースブロックを用いた概念的なAL-FECメカニズム（K=10, NR=9））
「Figure 3 Example of Unrecoverable Error in the Current MBMS Source Block (K = 10, NR = 9)
」
（タイトルの当審仮訳：図３　現在のMBMSソースブロックにおける復元できない誤りの例（K=10, NR=9））
「Figure 4 Example of Enhanced Robustness for Source Block Structure in Figure 2 (K’ = 7, NR = 9)
」
（タイトルの当審仮訳：図４　図２のソースブロック構造のロバスト性を拡張した例（K’=7, NR=9））
（イ）上記記載から、引用文献１には、次の技術的事項が記載されているものと認められる。
ａ　MBMS AL-FECスキームについて
　「２．１　イントロダクション」の記載によれば、引用文献１に記載された技術は、MBMSのためのFEC（前方誤り訂正）に関するものである。ここで、MBMSがMultimedia Broadcast Multicast Service（マルチメディア放送及びマルチキャストサービス）の略であることは周知である。
　「２．２　MBMS AL-FECスキームの概説」（以下「２．２」という）及び図１の記載によれば、引用文献１に記載されたMBMS AL-FECスキームは、ソースブロック構成器が、保護されるべきソースパケットの順序付けられたシーケンスを積み重ねることによってソースブロックを生成するものである。
　また、「２．２」の記載によれば、ソースシンボルはFECスキームが動作するソースブロック内のデータ単位であり、ソースシンボルの数K=10であるから、FECスキームは、複数のソースシンボルを含むソースブロックを生成するといえる。
　そして、図１，３，４の記載によれば、MBMS AL-FECスキームにおいて、各ソースパケットからソースシンボルが生成されるといえる。
　「２．３　ソースブロックの構成と性能の関係」（以下「２．３」という）及び図１，３，４の記載によれば、シンボルサイズTは所与のソースデータに対して固定されており、シンボルサイズがソースシンボルのサイズに対応することは明らかである。
　「２．２」には、MBMS AL-FECスキームにおいて、ソースブロックを構成した後、ソースブロック構成器がソースシンボルをFEC符号化器に入力として渡し、最後に、FEC符号化器はソースシンボルから所望の量（NR）のリペアシンボルを生成し、受信機に伝達されるように、これらのシンボルをFECリペアパケットに入れることが記載されている。
　したがって、現在のMBMS AL-FECスキームでは、複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って受信機に伝達するといえる。
　ソースシンボルやリペアシンボルはデータであり、受信機に伝達することは、受信機に送信することであるから、MBMS AL-FECスキームは、マルチメディア放送及びマルチキャストサービス（MBMS）におけるソースシンボル及びリペアシンボル（データ）を送信する方法に関するものである。
ｂ　現在のMBMSソースブロッキングアルゴリズムについて
　「２．２」及び図１の記載によれば、FECソースブロックの現在の構成方法では、各ソースパケットは１個又はそれ以上のソースシンボルを他のソースパケットと独立して生成するものである。
　換言すれば、FECソースブロックの現在の構成方法では、各ソースパケットからソースシンボルを生成するのであって、生成されたソースシンボルは２個又はそれ以上のソースパケットからのデータ部分を含むことはないという制限のもとでソースシンボルを生成するものである。この結果、ゼロパディング処理、すなわち、ソースパケットが１個又はそれ以上のソースシンボルを満たさない場合に、ゼロパディングが行われている。
ｃ　別のMBMSソースブロッキングアルゴリズムについて
　「２．２」には、FECソースブロックの現在の構成方法では、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことが課題となることが記載されている。
　「２．３」の記載によれば、別のソースブロッキングアルゴリズム（すなわち、新しいソースブロッキングアルゴリズム）は、ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得ることに注目し、所与のソースデータ及びシンボルサイズについて、ソースブロックアルゴリズムが現在のMBMSソースブロッキングアルゴリズムよりも少ないソースシンボルを生成することで、所与のFECコードに対して、よりロバスト性が高い保護レベルを追加のオーバヘッドなしに提供するものである。
　図４のソースブロックは、ソースシンボルとリペアシンボルが、別のソースブロッキングアルゴリズムにより、そして、図３と同一のFEC符号化器により生成されたものであり、別のソースブロッキングアルゴリズムは、現在のMBMSソースブロッキングアルゴリズムに対応する図３とはソースブロックの構成だけが異なるものである。
　したがって、引用文献１の図４に記載された別のソースブロッキングアルゴリズムは、図３の現在のMBMSソースブロッキングアルゴリズムと同様に、各ソースパケットから１個又はそれ以上のソースシンボルを生成するものである。
　また、図４のソースブロッキングアルゴリズムは、現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らしたものである。
（ウ）上記（ア）、（イ）から、引用文献１には、次の発明（以下「引用発明」という。）が記載されていると認められる。
「マルチメディア放送及びマルチキャストサービス（MBMS）におけるデータを送信する方法であって、
　複数のソースシンボルを含むソースブロックを生成するステップと、
ソースシンボルのサイズであるシンボルサイズTは所与のソースデータに対して固定されており、各ソースパケットからソースシンボルを生成するステップと、
　複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って、ソースシンボル及びリペアシンボルを受信機に伝達するステップとを含み、
　各ソースパケットからソースシンボルを生成するステップは、
　現在のMBMSソースブロッキングアルゴリズムにより、
　各ソースパケットは１個又はそれ以上のソースシンボルを他のソースパケットと独立して生成し、ゼロパディング処理として、ソースパケットが１個又はそれ以上のソースシンボルを満たさない場合、ゼロパディングが行われるステップ、
　あるいは、
　別のMBMSソースブロッキングアルゴリズムにより、
　各ソースパケットは、現在のMBMSソースブロッキングアルゴリズムとは、ソースブロックの構成だけが異なるものとして、１個又はそれ以上のソースシンボルを生成し、
　現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らすステップを含む、
　データ送信方法。」
イ　引用文献２
（ア）同じく原査定に引用され、本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった特開２００９−１０５９６２号公報（以下、「引用文献２」という。）には、次の記載がある。
「【０００１】
  本発明は、
データを送受信するための
方法に関する
「【００１０】
  本発明のさまざまな実施態様によって、
データの送信
に二次元アレイ等を使用できる
方法
送信されるデータに関する特性値を計算することができ、その特性値をそのデータとともに送信する
順方向誤り訂正（FEC）データ
ータなどが挙げられる。
【００１１】
  本発明の実施態様は、多くのタイプのネットワーク（例えば
ディジタルビデオ・ブロードキャスティング（DVB）ネットワーク）で利用することができる
「【００１８】
（一般的な動作）
　本発明のさまざまな実施態様によると、データを送受信するためのシステムと方法が提供される。本発明のさまざまな実施態様によると、
記憶位置のアドレス指定が可能な二次元アレイ等
【００１９】
  図1を参照すると、このような実施態様では、ノードによって
送信されるデータに対応するパケット等
二次元アレイ等に列方向にロードされる
アドレス可能な記憶位置
【００２０】
　次に、
二次元アレイ等のそれぞれの行に沿って1つ以上の特性値を計算することができる
このような特性値は、例えば順方向誤り訂正（FEC）データを表わすことができる。
ある1つの行に対応する計算した特性値を記憶しておき、その行に付加することができる
「【００５９】
（二次元アレイ等へのローディング、アドレス指定、サイジング）
　上記のタイプの
二次元アレイ等に対しては、本発明のさまざまな実施態様によると、多数の方法でロードすることができる
ローディングが列方向になされるさまざまな実施態様
列1つにつき1つのパケット等
だけをロードする
【００６０】
　このような実施態様では、アレイの行および／または列のサイズは、1つの列が最大サイズのパケット等を保持できるように選択することができる。
1つの列にロードされたパケット等が最大サイズに満たない場合には、その列の残部を“スタッフデータ（stuff data）”で埋める。特別な一例として、残部をゼロで埋めることができる
【００６１】
　
図3には、上述のローディング法
パケット等301は最大サイズであるため、このパケット等が存在している列303にスタッフデータは付加されていない。他方でパケット等305は最大サイズに満たないため、スタッフデータ307がその列に付加されて、パケット等305とスタッフデータ307がその列全体を占めている。
【００６２】
　
ローディングが列方向になされるさまざまな実施態様の別の一例
パケット等が、そのパケット等がロードされた列を完全には埋めない場合には、その列に、アレイ等にロードされる次のパケット等が続けてロードされるようにできる。さらに、ある列にロードされているパケットがその列を完全には収まりきらない場合には、収まりきらない部分を1つ以上の別の列に収納することができる。
【００６３】
　例えば特定のパケット等がある列にピタリと収まらなかった場合には、このような機能は、
その列が、その列のアドレス可能な最後のエレメント（例えばその列のエレメントで、最上位の行方向アドレスを有するエレメント）までそのパケット等の内容で埋まるようにした後、そのパケット等の残部を、次の列に、その列のアドレス可能な最初のエレメント（例えばその列のエレメントで、最下位の行方向アドレスを有するエレメント）から始まるように収納する
【００６４】
　図4には、上記した
ローディング法
図4では、パケット等401は、そのパケット等401がロードされる列403を完全には埋めていないため、列403の残部はパケット等405の一部で埋められる。しかしパケット等405は、列403のうちでパケット等401によって埋められずに残った部分にはピタリと収まらないため、そのパケット等405の残部を、列407に、この実施例では第1のエレメント
から始まるように配置する。
【００６５】
　上記したタイプのさまざまな実施態様では、
スタッフデータはパケット等の間に収納される
パケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長（バイト）の複数倍の長さになるようにすることを目的として実現する
ローディングが列方向にある実施態様で行方向のアドレス指定を1バイト全体粒度で実現できる
「【００６７】
　例えば受信ノードでは、
指示された列のアドレス可能な第1のエレメント
列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様
【００６８】
　ここでアドレス指定に移ると、本発明のさまざまな実施態様では、アドレス指定方式を上記のタイプのアレイ等に関して決定できることに注意されたい。
特定のサイズのアレイ等に関して考えると、アドレス指定方式の選択は、そのアレイ等のアドレス可能なエレメントの数を決定する効果を有するとみなすことができる
【００６９】
　特定のサイズのアレイ等に関して考えると、行方向のアドレス方式の選択は、上記のタイプのアレイ等における行の数を決定する効果を有するとみなせるのに対し、列方向のアドレス方式の選択は、上記のタイプのアレイ等における列の数を決定する効果を有するとみなせることにも注意されたい。さらに、
行方向と列方向のアドレス方式の選択は、特定のサイズのアレイ等に関して考えると、そのアレイ等のアドレス可能なエレメントのサイズの選択であると考えられる
【００７０】
　
特別な一例として、上記のタイプのアレイ等は、行と列の両方のアドレス指定が1バイトの粒度でなされるように実現することができる
「【００７４】
　ローディングが列方向である別の一例として、送信ノードは、送られるバーストごとにアレイ等のサイズを変えることができる。特別な一例として、送信ノードは、対応するアレイ等が、特定の1つのバースト内で送られるすべてのパケット等と、対応するあらゆる特性データとを保持できるように列の高さと行の幅を選択することができる。別の一例として、
送信ノードは、同様に、但し指定されたおよび／または固定された列の高さまたは行の幅に従って動作することができる。例えば列の高さが指定されているとき、その列の高さは、アレイ等にロードされるタイプのパケット等の最大サイズに一致していてもよいし、他の何らかの値でもよい。
「【図１】
」
（【図１】本発明の実施態様によるデータ送信に関係するステップの具体例を示した説明図である。）
「【図３】
」
（【図３】本発明の実施態様による第1のローディング法の説明図である。）
「【図４】
」
（【図４】本発明の実施態様による第2のローディング法の説明図である。）
（イ）上記記載によれば、引用文献２には、次の技術が記載されているといえる。
　【０００１】及び【００１１】の記載によれば、引用文献２に記載された技術は、ディジタルビデオ・ブロードキャスティング（DVB）ネットワークで利用することができ、データを送受信するための方法に関するものである。
　【００１０】，【００１８】〜【００２０】及び図１の記載によれば、パケット等を列方向にロードした、記憶位置のアドレス指定が可能な二次元アレイ等を作り、データの送信に二次元アレイを使用できる方法である。また、送信されるデータに関する特性値（順方向誤り訂正（FEC）データ）を二次元アレイ等のそれぞれの行に沿って計算することができ、その特性値をその行に付加してそのデータとともに送信する方法である。
　また、【００７４】の記載によれば、送信ノードは、同様に、指定された及び／又は固定された列の高さに従って動作することができ、二次元アレイ等の列の高さは固定されているといえる。
　【００５９】及び【００６０】の記載によれば、二次元アレイ等へのローディング法の「一つの実施態様」（以下、「一つの例」という。）は、列1つにつき1つのパケット等だけをロードするものであって、列の残部をスタッフデータ、一例として、ゼロで埋めるものである。
　ここで、【００７４】の記載によれば、列の高さは固定されており、アレイ等にロードされるタイプのパケット等の最大サイズでなく、他の何らかの値でもよい。
　そうすると、当該「一つの例」に対応して、【００６０】，【００６１】，【００７４】及び図３に記載されたローディング法は、二次元アレイの列のサイズは、パケット等の最大サイズとは異なる他の値が指定されており、パケット等が列のサイズであればスタッフデータは付加されず、パケット等が列のサイズに満たないのであればスタッフデータがその列に付加されて、パケット等とスタッフデータがその列全体を占めるものといえる。
　つまり、引用文献２に記載された、「一つの例」では、パケット等が列のサイズよりも大きい場合は、列のサイズを越える残りの部分のデータは、当然別の列にロードされることとなるが、当該実施態様は、列1つにつき1つのパケット等だけをロードするものであるから、残りの部分のデータのサイズが別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加されるといえる。
　一方で、【００６２】の記載によれば、二次元アレイ等へパケット等を列方向にローディングする「別の一例」は、パケット等が、そのパケット等がロードされた列を完全には埋めない場合には、その列に、アレイ等にロードされる次のパケット等が続けてロードされるようにでき、さらに、ある列にロードされているパケットがその列を完全には収まりきらない場合には、収まりきらない部分を1つ以上の別の列に収納するものである。
　また、【００６４】及び図４の記載によれば、図４のローディング法では、パケット等４０１がロードされる列４０３を完全には埋めていないと、列４０３の残部はパケット４０５の一部で埋められる。そして、パケット等４０５が、列４０３のうちでパケット等４０１によって埋められずに残った部分にはピタリと収まらないと、そのパケット等４０５の残部を、列４０７（次の列）の第１のエレメントから始まるように配置する。
　【００６７】の記載によれば、【００６２】，【００６４】及び図４に記載されたローディング方法、すなわち、「別の一例」は、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様であるといえる。
　したがって、「別の一例」は、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様であり、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるものである。また、ある列にロードされているパケット等がその列に完全には収まりきらない場合には、収まりきらない部分を次の列の第１のエレメントから始まるように配置するものである。
　そして、【００６５】には、図４に対応した、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様について、パケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長（バイト）の複数倍の長さになるようにすることを目的として、スタッフデータがパケット等の間に収納されることが記載されている。当該機能を利用すると、行方向のアドレス指定を１バイト全体粒度で実現可能である。
　【００６８】〜【００７０】の記載によれば、アドレス指定方式の選択は、特定のサイズのアレイ等に関して考えると、そのアレイ等のアドレス可能なエレメントの数やエレメントのサイズを選択するものであり、その特別な一例として、行と列の両方のアドレス指定が1バイトの粒度でなされるように実現することができるものである。
　そうすると、「別の一例」において、続けてロードされる「次のパケット」のアドレスを指定するにあたり、アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応するものである。そして、粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長（バイト）の複数倍の長さになるようにするものである。
　さらに、【００６９】，【００７０】及び【００７４】の記載によれば、二次元アレイ等は、行方向と列方向に、粒度単位でアドレス指定が可能であり、列の高さが指定された及び／又は固定されたものである。ここで、列の高さは、上述したように、アレイ等にロードされるタイプのパケット等の最大サイズに一致していてもよいし、他の何らかの値でもよいものである。
　また、【００６３】の記載によれば、パケット等の内容で、その列のアドレス可能なエレメントをパケット等の内容で埋まるようにした後、次の列のアドレス可能な最初のエレメントに、そのパケット等の残部を収納しているから、エレメントのサイズはパケット等のサイズよりも小さいと言える。
　ここで、引用文献２に記載された、列1つにつき1つのパケット等だけをロードする「一つの例」（図３に対応）と、列1つにつき2つ以上のパケット等が収納されるローディングを行なう「別の一例」（図４に対応）を比較すると、パケット等が列のサイズに満たない場合（ロードされた列を完全には埋めない場合）、前者は、スタッフデータがその列に付加されて列の残部を埋めるのに対し、後者は、その列に次のパケット等が続けてロードされるから、二次元アレイ等にローディングするパケットの合計サイズが同じであれば、後者の方が、スタッフデータが少なくなり、二次元アレイ等の行の幅（列の個数）も少なくなることは明らかである。
（ウ）上記（イ）によれば、引用文献２には、次の技術が記載されていると認められる。
「ディジタルビデオ・ブロードキャスティング（DVB）ネットワークで利用することができ、データを送受信するための方法であって、
　データの送信に記憶位置のアドレス指定が可能であり、列の高さが指定された及び／又は固定された二次元アレイ等を使用し、
　二次元アレイ等へパケット等を列方向にローディングするローディング法として、
　一つの例として、
　列1つにつき1つのパケット等だけをロードし、
　二次元アレイの列のサイズは、パケット等の最大サイズとは異なる他の値が指定されており、
　パケット等が列のサイズであればスタッフデータは付加されず、
　パケット等が列のサイズに満たないのであればスタッフデータがその列に付加されて、パケット等とスタッフデータがその列全体を占め、
　パケット等が列のサイズよりも大きい場合は、列のサイズを越える残りの部分のデータは、別の列にロードされ、残りの部分のデータのサイズが別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加され、
　スタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるローディング法、
　と、
　別の一例として、
　列1つにつき2つ以上のパケット等が収納されるローディングを行ない、
　パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされ、
　また、ある列にロードされているパケット等がその列に完全には収まりきらない場合には、収まりきらない部分を次の列の第１のエレメントから始まるように配置され、
　記憶位置のアドレス指定が、行方向と列方向に、粒度単位で可能であり、
　アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応し、当該エレメントのサイズはパケット等のサイズよりも小さく、
　粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長（バイト）の複数倍の長さになるようにし、
　スタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるローディング法、
の２つのローディング法。」
（３）引用発明との対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明は、マルチメディア放送及びマルチキャストサービス（MBMS）におけるFECに関するものである。
　ここで、マルチメディア放送は放送の一種であり、マルチキャストは通信の一種であるから、引用発明は、放送及び通信サービスを行うシステムに関するものである。
　したがって、引用発明の「マルチメディア放送及びマルチキャストサービス（MBMS）におけるデータを送信する方法」は、本件補正発明の「放送及び通信システムにおけるデータを送信する方法」に相当する。
（イ）引用発明の「ソースブロック」は、「複数のソースシンボルを含む」点で、本件補正発明の「ソースシンボルブロック」と共通し、引用発明の「ソースブロック」は、本件補正発明の「ソースシンボルブロック」であるといえる。
（ウ）引用発明と本件補正発明は、「複数のソースシンボルを含むソースシンボルブロックを生成するステップ」を含む点で共通する。
（エ）引用発明は、「ソースシンボルのサイズであるシンボルサイズTは所与のソースデータに対して固定され」たものである。
　また、本件補正発明は、「複数のソースシンボル」が、「同一の数の同一のサイズのシンボルエレメントに各々が分割される」から、ソースシンボルのサイズは、同一のサイズのシンボルエレメントの定数倍であり、固定されているといえる
　したがって、引用発明と本件補正発明は、「複数のソースシンボル」の「サイズが固定されている」点で共通する。
（オ）引用発明は、「各ソースパケットからソースシンボルを生成するステップ」を含み、「各ソースパケット」には、一のソースパケットと、それに後続するソースパケットが含まれることは明らかである。
　本件補正発明は、「第１のソースパケット」を「第１のシンボルエレメント」に配置し、「第２のソースパケット」を「第２のシンボルエレメント」に配置するものである。ここで、「第１のシンボルエレメント」及び「第２のシンボルエレメント」は、「ソースシンボルブロック内」の「一つ以上の連続するシンボルエレメント」を含むから、「複数のソースシンボル」の一部である。
　また、本件補正発明は、「第１のソースパケットの少なくとも一部」及び「第２のソースパケットの少なくとも一部」を「第１のソースシンボル」に配置するものである。
　したがって、引用発明と本件補正発明は、「第１のソースパケット」及び「第１のソースパケットに後続する第２のソースパケット」を「複数のソースシンボル」に配置するステップを含む点で共通する。
（カ）引用発明は、「複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って、ソースシンボル及びリペアシンボルを受信機に伝達するステップ」を含み、引用発明の「複数のソースシンボル」は、「ソースブロック」に含まれる。
　したがって、引用発明と本件補正発明は、「ソースシンボルブロックの複数のソースシンボルブロックを符号化して伝送するステップ」を含む点で共通する。
（キ）引用発明の「データ送信方法」は、本件補正発明の「データ送信方法」といえる。
イ　以上のことから、本件補正発明と引用発明との一致点及び相違点は、次のとおりである。
【一致点】
「放送及び通信システムにおけるデータを送信する方法であって、
　サイズが固定されている複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
　第１のソースパケット及び第１のソースパケットに後続する第２のソースパケットを複数のソースシンボルに配置するステップと、
　ソースシンボルブロックの複数のソースシンボルを符号化して伝送するステップとを含む、
　データ送信方法。」
【相違点１】
　一致点の「サイズが固定されている複数のソースシンボル」について、本件補正発明では、「同一の数の同一のサイズのシンボルエレメントに各々が分割される」のに対して、引用発明は、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題としているものの、「シンボルサイズTが所与のソースデータに対して固定されている」との記載に留まり、「別のMBMSソースブロッキングアルゴリズム」について「複数のソースシンボル」が同一の数の同一のサイズで分割されていることが特定されていない点。
【相違点２】
　一致点の「第１のソースパケット及び第１のソースパケットに後続する第２のソースパケットを複数のソースシンボルに配置するステップ」について、本件補正発明は、「第１のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第１のシンボルエレメントに配置し、前記第１のソースパケットに後続する第２のソースパケットを前記第１のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第２のシンボルエレメントに配置するステップ」を含み、「前記第１のシンボルエレメントの最後のシンボルエレメントが第１のソースシンボルの最後のシンボルエレメントではない場合、前記第１のソースパケットの少なくとも一部及び前記第２のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第１のソースシンボルに配置され」、「前記第１のシンボルエレメントの最後のシンボルエレメントが前記第１のソースシンボルの最後のシンボルエレメントではなく、前記第１のソースパケットが前記第１のシンボルエレメントを満たさない場合、前記第１のシンボルエレメントの最後のシンボルエレメントは、前記第２のシンボルエレメントの最初のシンボルエレメントの前までパディングされる」のに対して、引用発明は、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題としているものの、「現在のMBMSソースブロッキングアルゴリズム」のソースブロックの構成及びゼロパディング処理について記載されているのみであって、「ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす」ための、「別のMBMSソースブロッキングアルゴリズム」のソースブロックの具体的な構成及びゼロパディング処理の詳細が特定されていない点。
（４）判断
　以下、相違点について検討する。
ア　相違点１について
　引用文献２に記載された技術の「記憶位置のアドレス指定が可能であり、列の高さが指定された及び／又は固定された二次元アレイ等」は、DVBネットワークで利用することができ、データの送信に使用され、パケット等がその列方向にローディングされるものであるから、「ソースシンボルブロック」に他ならない。
　また、引用文献２に記載された技術の「二次元アレイ等」が複数の「列」を含むことは明らかであるから、引用文献２に記載された技術の「列」は、「ソースシンボルブロック」に含まれる「ソースシンボル」といえる。
　そうすると、引用文献２に記載された技術の「二次元アレイ等の行の幅（列の個数）」は、本件補正発明における「ソースシンボルの数」に対応する。
　引用文献２に記載された技術のスタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるから、スタッフデータが収納されることは、「パディングされること」に他ならない。
　次に、引用発明は、シンボルサイズTが固定されており、引用文献２に記載された技術も、列の高さが指定された及び／又は固定された二次元アレイ等を使用するものであるから、引用発明と引用文献２に記載された技術とは、ソースシンボルのサイズが固定されている点で共通する。
　引用発明における「現在のMBMSソースブロッキングアルゴリズム」は、「各ソースパケットは１個又はそれ以上のソースシンボルを他のソースパケットと独立して生成し、ゼロパディング処理として、ソースパケットが１個又はそれ以上のソースシンボルを満たさない場合、ゼロパディングが行われる」ものであるから、「列1つにつき1つのパケット等だけをロード」し、「パケット等が列のサイズに満たないのであればスタッフデータがその列に付加され」、「列のサイズを越える残りの部分のデータ」のサイズが「別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加され」るという、引用文献２に記載された技術の「一つの例」である。
　一方で、「列1つにつき2つ以上のパケット等が収納されるローディングを行な」う引用文献２に記載された技術の「別の一例」は、「一つの例」と比較して、パディングのデータが少なくなり、ソースシンボル数も少なくなるローディング法であるから、「現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす」という引用発明の「別のMBMSソースブロッキングアルゴリズム」と同じ効果を有するローディング法である。
　ここで、「別の一例」における「二次元アレイ等」は、列の高さが指定された及び／又は固定されたものであって、列方向にアドレス指定可能であり、アドレスは粒度（エレメントのサイズ）単位で指定されるから、「別の一例」の複数の「列」は粒度（エレメントのサイズ）単位ごとに同一の数に同一サイズで分割されているといえる。
　したがって、「別の一例」は、同一の数の同一のサイズの粒度（エレメントのサイズ）単位ごとに分割される複数のソースシンボルをソースシンボルブロックにローディングするステップを含む方法である。
　引用発明と引用文献２に記載された技術とは、ともに放送システムにおけるデータを送信する方法であって、ソースシンボルのサイズが固定されたソースシンボルブロックを生成し、送信されるデータに関する順方向誤り訂正データを計算してデータとともに送信するものであって、引用発明の「別のMBMSソースブロッキングアルゴリズム」と、引用文献２に記載された技術の「別の一例」は同じ効果を有するローディング法であるから、引用発明の「ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまう課題を解決するための別のMBMSソースブロッキングアルゴリズム」の具体的な方法として、引用文献２に記載された技術の「別の一例」のローディング法を採用して、複数のソースシンボルを同一の数の同一のサイズの粒度（エレメントのサイズ）単位ごとに分割されるようにして、複数のソースシンボルをソースシンボルブロックにローディングすることで、ソースシンボルブロックを生成するステップを含めることは、当業者が容易に想到し得たことである。
イ　相違点２について
「ア　相違点１について」で述べたように、引用発明における「別のMBMSソースブロッキングアルゴリズム」として、引用文献２に記載された技術の「別の一例」を採用した場合、「別の一例」における「列」は、同一の数の同一のサイズの粒度（エレメントのサイズ）単位ごとに分割されたものである。
　そして、「別の一例」のエレメントのサイズは、パケット等のサイズよりも小さいから、「別の一例」のパケット等は、複数の粒度単位に配置されるといえる。そして、パケット等が連続する粒度単位に配置されることは、図４から明らかである。
　また、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるから、パケット等の次のパケット等は、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置されるといえる。
　したがって、「別の一例」は、パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置するステップを含む方法である。
　また、一つ以上の連続する粒度単位を「第１のシンボルエレメント」と、それに後続する一つ以上の連続する粒度単位を「第２のシンボルエレメント」と称することは任意である。
　上記によれば、「別の一例」は、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるものである。
　そうすると、パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）の最後の粒度単位が、パケット等がロードされた列の最後の粒度単位ではない場合、当該列を完全に埋めないから、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるといえる。
　したがって、「別の一例」は、パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるステップを含む方法である。
　以上のとおり、引用文献２に記載された技術の「別の一例」は、パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置するステップを含む方法であり、パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるステップを含む方法である。
　すなわち、「別の一例」では、パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、当該ソースシンボルには、パケット等の最後の粒度単位が配置され、さらに、それに後続する次のパケット等の最初の粒度単位が配置されるといえる。
　「別の一例」は、粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長（バイト）の複数倍の長さになるようにするものであるから、パケット等が、当該パケット等が配置される一つ以上の連続する粒度単位、すなわち、第１のシンボルエレメントを満たさない場合、第１のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までスタッフデータが収納されているといえる。
　また、「ア　相違点１について」で述べたように、スタッフデータが収納されることは、「パディングされること」に他ならない。
　上記によれば、「別の一例」は、パケット等が配置された第１のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、ソースシンボルには、パケット等の最後の粒度単位と、それに後続する次のパケット等の最初の粒度単位が配置され、さらに、パケット等が第１のシンボルエレメントを満たさない場合、第１のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるものである。
　そうすると、「ア　相違点１について」で述べたように、引用発明における「別のMBMSソースブロッキングアルゴリズム」として、引用文献２に記載された技術の「別の一例」を採用して、
　パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位（第１のシンボルエレメント）に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）に後続する、一つ以上の連続する粒度単位（第２のシンボルエレメント）に配置するステップを含め、
　パケット等が配置された一つ以上の連続する粒度単位（第１のシンボルエレメント）の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるようにし、
　パケット等が配置された第１のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではなく、さらに、パケット等が第１のシンボルエレメントを満たさない場合、第１のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるようにすることは、当業者が容易に想到し得たことである。
ウ　そして、これらの相違点を総合的に勘案しても、本件補正発明の奏する作用効果は、引用発明及び引用文献２に記載された技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
エ　したがって、本件補正発明は、引用発明及び引用文献２に記載された技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
３　請求人の主張について
（１）請求人は、平成３０年３月１３日に提出された審判請求書において、
　引用文献１及び引用文献２が、本件補正発明の「前記第１のシンボルエレメントの最後のシンボルエレメントが前記第１のソースシンボルの最後のシンボルエレメントではなく、前記第１のソースパケットが前記第１のシンボルエレメントを満たさない場合、前記第１のシンボルエレメントの最後のシンボルエレメントは、前記第２のシンボルエレメントの最初のシンボルエレメントの前までパディングされること」（構成１）を開示及び示唆していない旨を主張し、さらに、「引用文献１および２を参照して、シンボルエレメントの概念に対して構成１を採用する点を明示的に開示するものではなく、シンボルエレメント単位でパディングが遂行され得る点も全く開示および示唆していません。また、引用文献１および２は、構成１に関して、ソースシンボルの開始部分でも最後の部分でもない中間部分にパディングが遂行される構成を開示も示唆もするものではありません。」と主張している（同審判請求書の「【本願発明が特許されるべき理由】（ｃ）引用文献発明との差違について」を参照）。
　審判請求書における当該主張について検討する。
　「２（４）イ　相違点２について」で述べたように、引用発明において、引用文献２に記載された技術の「別の一例」のローディング法を採用して、パケット等が配置された第１のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではなく、さらに、パケット等が第１のシンボルエレメントを満たさない場合、第１のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるようにすることは、当業者が容易に想到し得たことである。
　そして、この場合の第１のシンボルエレメントの最後の粒度単位は、「ソースシンボルの開始部分でも最後の部分でもない中間部分」に他ならないから、引用文献２は、「構成１」を開示及び示唆するものである。
（２）請求人は、平成３０年７月６日に提出された上申書において、
　引用文献２には、「ローディングが列方向にある実施態様で行方向のアドレス指定を1バイト全体粒度で実現できるため、対応するアレイ等でのアドレス方式を簡単化することができる」（同文献段落[００６５]）と開示するのみであり、その目的はあくまでもアドレス方式の簡略化であるといえ、従って、引用文献２は、任意の粒度についてまで開示しているとはいえないと主張している。
　また、引用文献２では、「パケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長（バイト）の複数倍の長さになるように」（同文献段落[００６５]）とあるように、丸められたデータは「ワード長（バイト）の複数倍の長さ」になるものであり、「ソースシンボル長」に依存する長さとなることを何ら開示及び示唆していない旨を主張している（同上申書の（２）参照）。
　上申書の当該主張について検討すると、「２（２）イ　引用文献２（ウ）」で述べたように、引用文献２に記載された技術の「別の一例」のローディング法は、「アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応」するものである。
　したがって、引用文献２には、アドレス指定方式を選択することで、任意の粒度を選択可能なこと、すなわち、アドレス可能なエレメントのサイズを１バイト以外にすることが記載されている。
　また、引用文献２に記載された技術の「別の一例」のローディング法は、粒度単位でのアドレス指定を実現するためのものであり、「２（４）ア　相違点１について」で述べたように、「別の一例」の複数の「列」（ソースシンボル）は粒度（エレメントのサイズ）単位ごとに同一の数に同一サイズで分割されているといえるから、引用文献２は、粒度（エレメントのサイズ）がソースシンボルを同一サイズで分割した長さとなっているといえる。
（３）請求人は、同上申書において、
　引用文献２は、本願明細書の段落[０００５]が開示する「ソースパケットの所望する長さを短縮させることにより相対的にゼロパディングの量を減少させることができる。しかしながら、ソースブロックを構成するシンボルの個数が大きく増加するために、非常に長い長さを有するＦＥＣ符号が必要とされる。」との課題を何ら開示及び示唆しておらず、引用文献１と組み合わせることで当該課題の解決が可能であることは、引用文献１及び２を参照したとしても自明ではないと主張している（同上申書の（２）参照）ので、当該主張について検討する。
　引用文献１の「２．２」及び「２．３」には、引用発明が、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題とするものであり、ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得ることが記載されている。
　また、引用文献２には、「２（２）イ　引用文献２（イ）」及び「２（２）イ　引用文献２（ウ）」で述べたように、引用文献２に記載された技術として「一つの例」と「別の一例」が記載されており、両者を比較すると、後者の方がスタッフデータが少なくなることは明らかである。
　したがって、引用発明において、「一つの例」に対応する現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす「別の一例」を採用することで、収納されるスタッフデータの量、すなわち、パディングの量を減少させ得ることは自明である。
（４）請求人は、同上申書において、
　本願明細書の段落[００６１]に開示された「他方、本発明の実施形態によるソースブロック内の行又は符号化シンボルがｍ個の領域に分割されるので、損失された部分と損失されない部分とに識別されることができ、したがって、ｍ個の領域内の損失されない部分が復号のために使用されることにより、本発明の実施形態による復号性能を向上させることができる。」との格別な効果は、列ごとにローディングを行う実施形態のみを明示的に示す引用文献２の発明では獲得できるものではなく、つまり、請求項１に係る発明により得られる技術的効果は、引用文献１及び２に開示の発明とは異質であると主張している（同上申書の（３）参照）。
　当該主張について検討すると、引用文献２の【００２０】には、二次元アレイ等のそれぞれの行に沿って1つ以上の特性値（順方向誤り訂正（FEC）データ）を計算し、ある1つの行に対応する計算した特性値を記憶しておき、その行に付加することが記載されている。
　技術常識を参酌すれば、当該二次元アレイ等を受信側に送信した場合、受信側において行われる誤り訂正処理は、当該二次元アレイ等の行に沿って行われるから、誤り訂正処理が損失されない行の部分について行われることは自明である。そして、二次元アレイ等のうち、損失された行の部分は誤り訂正処理に使用できないことは当然である。
　したがって、本件補正発明の奏する作用効果は、引用発明及び引用文献２に記載された技術の「別の一例」の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　したがって、（１）〜（４）の請求人の主張は、採用することができない。
４　本件補正についてのむすび
　よって、本件補正は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　平成３０年３月１３日にされた手続補正は、上記のとおり却下されたので、本願の請求項に係る発明は、平成２９年５月２２日にされた手続補正により補正された特許請求の範囲の請求項１ないし２に記載された事項により特定されるものであるところ、その請求項１に係る発明（以下「本願発明」という。）は、その請求項１に記載された事項により特定される、前記第２［理由］１（２）に記載のとおりのものである。
２ 原査定の拒絶の理由
　原査定の拒絶の理由は、この出願の請求項１，２に係る発明は、本願の優先権主張の日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１に記載された発明及び引用文献２に記載された事項に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものである。
引用文献１：Samsung Electronics Co., Ltd.，Proposed Evaluation Procedure for Source Block Construction[online]，  3GPP TSG-SA WG4#68    S4-120366，インターネット＜URL:http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_68/Docs/S4-120366.zip＞，２０１２年　４月
引用文献２：特開２００９−１０５９６２号公報
３　引用文献
　原査定の拒絶の理由で引用された引用文献１ないし２及びその記載事項は、前記第２の［理由］２（２）に記載したとおりである。
４　対比・判断
　本願発明は、前記第２の［理由］２で検討した本件補正発明から、「
前記第１のシンボルエレメントの最後のシンボルエレメントが前記第１のソースシンボルの最後のシンボルエレメントではなく、
　そうすると、本願発明の発明特定事項を全て含み、さらに他の事項を付加したものに相当する本件補正発明が、前記第２の［理由］２（３）、（４）に記載したとおり、引用発明及び引用文献２に記載された技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、引用発明及び引用文献２に記載された技術に基づいて、当業者が容易に発明をすることができたものである。
第４ むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
よって、結論のとおり審決する。