現在、審決メルマガは配信を一時停止させていただいております。再開まで今暫くお待ち下さい。

  • ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1352939
審判番号 不服2018-3611  
総通号数 236 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-08-30 
種別 拒絶査定不服の審決 
審判請求日 2018-03-13 
確定日 2019-06-25 
事件の表示 特願2015-511356「放送及び通信システムにおけるパケット送受信装置及び方法」拒絶査定不服審判事件〔平成25年11月14日国際公開、WO2013/168964、平成27年 7月23日国内公表、特表2015-520990〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2013年(平成25年)5月7日(パリ条約による優先権主張 外国庁受理2012年5月7日、大韓民国、外国庁受理2012年5月11日、大韓民国)を国際出願日とする出願であって、平成29年2月10日付けの拒絶理由の通知に対し、平成29年5月22日に意見書が提出されるとともに手続補正がなされたが、平成29年11月2日付けで拒絶査定がなされ、これに対して、平成30年3月13日に拒絶査定不服審判の請求がなされると同時に手続補正がなされたものである。

第2 平成30年3月13日にされた手続補正についての補正の却下の決定
[補正の却下の決定の結論]
平成30年3月13日にされた手続補正(以下、「本件補正」という。)を却下する。

[理由]
1 本件補正について(補正の内容)
(1)本件補正後の特許請求の範囲の記載
本件補正により、特許請求の範囲の請求項1の記載は、次のとおり補正された(下線部は、補正箇所である。)。
「放送及び通信システムにおけるデータを送信する方法であって、
同一の数の同一のサイズのシンボルエレメントに各々が分割される複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
第1のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第1のシンボルエレメントに配置し、前記第1のソースパケットに後続する第2のソースパケットを前記第1のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第2のシンボルエレメントに配置するステップと、前記ソースシンボルブロックの前記複数のソースシンボルを符号化して伝送するステップとを含み、
前記第1のシンボルエレメントの最後のシンボルエレメントが第1のソースシンボルの最後のシンボルエレメントではない場合、前記第1のソースパケットの少なくとも一部及び前記第2のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第1のソースシンボルに配置され、
前記第1のシンボルエレメントの最後のシンボルエレメントが前記第1のソースシンボルの最後のシンボルエレメントではなく、前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合、前記第1のシンボルエレメントの最後のシンボルエレメントは、前記第2のシンボルエレメントの最初のシンボルエレメントの前までパディングされることを特徴とするデータ送信方法。」

(2)本件補正前の特許請求の範囲
本件補正前の、平成29年5月22日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。
「放送及び通信システムにおけるデータを送信する方法であって、
同一の数の同一のサイズのシンボルエレメントに各々が分割される複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
第1のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第1のシンボルエレメントに配置し、前記第1のソースパケットに後続する第2のソースパケットを前記第1のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第2のシンボルエレメントに配置するステップと、前記ソースシンボルブロックの前記複数のソースシンボルを符号化して伝送するステップとを含み、
前記第1のシンボルエレメントの最後のシンボルエレメントが第1のソースシンボルの最後のシンボルエレメントではない場合、前記第1のソースパケットの少なくとも一部及び前記第2のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第1のソースシンボルに配置され、
前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合、前記第1のシンボルエレメントの最後のシンボルエレメントは、前記第2のシンボルエレメントの最初のシンボルエレメントの前までパディングされることを特徴とするデータ送信方法。」

2 補正の適否
本件補正は、本件補正前の請求項1に記載された「データ送信方法」における、「前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合」の動作について、上記のとおり、さらに、「前記第1のシンボルエレメントの最後のシンボルエレメントが前記第1のソースシンボルの最後のシンボルエレメントではなく、」との限定を付加するものであって、補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。
そこで、本件補正後の請求項1に記載される発明(以下、「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について、以下、検討する。

(1)本件補正発明
本件補正発明は、上記1(1)に記載したとおりのものである。

(2)引用文献の記載事項
ア 引用文献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>,2012年 4月」(以下、「引用文献1」という。)には、図面とともに、次の記載がある。
「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 belonging to one or several UDP packet flows related to a particular segment of the stream(s) (in time). The UDP flows include RTP, RTCP, SRTP and MIKEY packets.
(ii) Modification of source packets to indicate the position of the source data from the source packet within the source block
(iii) Definition of repair packets, sent over UDP, which can be used by the FEC decoder to reconstruct missing portions of the source block.
(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.」(第1頁第13行?第30行)
(当審仮訳:2 使用事例
2.1イントロダクション
TS26.346第8.2.2節に定義されたMBMS前方誤り訂正(FEC)を適用するための一般的なメカニズムによれば、メカニズムは、3つのコンポーネントからなる:
(i)(時間内の)ストリームの特定のセグメントに関連した、1個又は数個のUDPパケットフローに属するソースメディアパケットからのFECソースブロックの構成。UDPフローには、RTP、RTCP、SRTP及びMIKEYパケットなどが含まれる。
(ii)ソースブロック内のソースパケットからのソースデータの位置を示すソースパケットの改変
(iii)UDPを通して送られる、リペアパケットの定義、リペアパケットは、ソースブロックの欠落部分を再構成するために、FEC復号器によって使用される。
(i)と(ii)はソースブロックの構成に密接に関連し、そして、(iii)はFEC符号化スキームに関連する。
AL-FECスキームの性能はFEC符号化スキームの拡張だけでなく、より効率的なブロック構造によっても改善する。この節では、FECメカニズムの最初の2つのコンポーネントに関連する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 (N_(R)) 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.」(第2頁第1行?第22行)
(当審仮訳:2.2 MBMS AL-FECスキームの概説
図1にMBMS AL-FECスキームの概念的なプロセスを示す。AL-FECスキームはソースブロックを構成するソースパケットを処理することによって開始される。より正確には、図1のソースブロック構成器は、保護されるべきソースパケット(又はソースデータ)の順序付けられたシーケンスを積み重ねることによってソースブロックを生成する。
ソースブロックを構成した後、ソースブロック構成器はソースシンボルをFEC符号化器に入力として渡す。ここで、ソースシンボルはFECスキームが動作するソースブロック内のデータ単位である。ソースシンボルの形態がソースブロック構成器の動作によって決定されることは明らかである。さらに、所与のソースパケットについて、ソースシンボルの数、ここではKは動作に応じて変更可能である。
最後に、FEC符号化器はソースシンボルから所望の量(NR)のリペアシンボルを生成し、受信機に伝達されるように、これらのシンボルをFECリペアパケットに入れる。これらのリペアパケットは、任意のソースパケットフローから分離されるように、通常のUDP手順を利用して一意の宛先ポートに送信される。ここで、ソースブロッキングアルゴリズム及びFEC符号化は相対的に独立した動作であり、さらに、このAL-FEC符号化手順は、各ソースブロックに独立して提供されることに留意されたい。
TS26.346で定義されているFECソースブロックの現在の構成方法では、各ソースパケットは1個又はそれ以上のソースシンボルを他のソースパケットと独立して生成する。言い換えれば、ソースシンボルが2個又はそれ以上のソースパケットからのデータ部分を含むことはない。この制限により、図1に示されているようにゼロパディング処理が含まれる。結果として、たとえゼロパディングされたデータが送信されなくても、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまう。)

「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 + N_(R)) for AL-FEC scheme with the current MBMS source blocking algorithm where N_(R) 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’ + N_(R)) 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’ + N_(R)) is smaller than K/(K + N_(R)) for fixed N_(R).
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 (= N_(R)) 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 (= N_(R)) 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), N_(R), 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*N_(R)/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.」(第3頁第1行?第5頁第11行)
(当審仮訳:2.3 ソースブロックの構成と性能の関係
この小節では、いくつかの簡単な例を用いて現在のソースブロッキングアルゴリズムの拡張の必要性を示す。このために、まず現在のMBMSソースブロッキングアルゴリズムが所与のソースパケットからK個のソースシンボルを生成すると仮定する。それゆえ、N_(R)がリペアシンボル(パケット)の数を示すなら、現在のMBMSソースブロッキングアルゴリズムを用いたAL-FEC方式では、符号化率は、K/(K+N_(R))で定義される。
さらに、同一のソースパケットからK’個のソースシンボルを生成する別のソースブロッキングアルゴリズムを仮定する。ここで、図2に示すように、K’はKより小さい整数である。したがって、新しいソースブロッキングアルゴリズムの符号化率はK’/(K’ + N_(R))で定義される。ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得ることに留意されたい。
FECの観点からは、FEC符号化率は、ソースデータ保護のロバスト性と密接に関連している。一般的に、符号化率を小さくすると一定の量のパリティデータに対してよりロバスト性が高くなる。したがって、N_(R)が固定の場合に、K’/(K’ + N_(R))はK/(K + N_(R))より小さいから、図1の現在のMBMSアルゴリズムよりも、図2の後者のソースブロックアルゴリズムは、よりロバスト性が高くなる。
理解を容易にするために、図3と図4に極めて簡単な例を示す。まず、図3では、10 (= K)個のソースシンボルが現在のMBMSソースブロッキングアルゴリズムによって生成され、9(= N_(R))個のリペアシンボルがFEC符号化器によって生成されると仮定する。ここで、任意のFEC符号化器が利用可能である。さらに、3個のソースパケットと4個のリペアパケット(シンボル)がネットワークで欠落したと仮定する。図3に示されているように、3個の欠落したソースパケットは6個のソースシンボルの欠落(全てのシンボルの60%)に対応する。結果として、受信機は9個のシンボルだけを受け取り、受信されたシンボルの数9が全てのソースシンボルの数である10よりも小さいから、受信機がソースブロックを完全に再構成できないことは明らかである。つまり、いくつかのソースパケットを復元することはできない。
次に、図4のソースブロックについて、それぞれ7個(=K)のソースシンボルと9個(=N_(R))のリペアシンボルが、別のソースブロッキングアルゴリズムにより、そして、図3と同一のFEC符号化器により生成され、同じ3個のソースパケットと4個のリペアパケットが欠落すると仮定する。さらに、図4に示されているように、新しいソースブロックの4個のソースシンボル(全ソースシンボルの57%)の欠落に対応する3個のソースパケットが欠落したと仮定する。この場合、受信されたシンボル数は8であり、全ソースシンボル数の7よりも大きいから、全てのソースパケットを復元することができる。
結果として、図4のソースブロッキングアルゴリズムは、現在のソースブロッキングアルゴリズムよりロバスト性の高い保護レベルを提供することを示している。リペアシンボル(パケット)の数、NRとシンボルサイズTは所与のソースデータに対して固定されており、図3と図4でソースブロックの構成だけが異なることに留意されたい。したがって、どちらの場合でもオーバヘッドは、T*NR/Bsのように同じである。ここで、Bsは全ソースパケットの全データサイズ([ビット]又は[バイト])を意味する。
まとめると、所与のソースデータ(又はソースパケット)及びシンボルサイズについて、ソースブロックアルゴリズムが現在のMBMSソースブロッキングアルゴリズムよりも少ないソースシンボルを生成するなら、所与のFECコードに対して、よりロバスト性が高い保護レベルを追加のオーバヘッドなしに提供することができる。したがって、現在のソースブロッキングアルゴリズムの拡張がAL-FECスキームの性能を最大化するために必要とされる。)

「Figure 1 Conceptual AL-FEC Mechanism with the Current MBMS Source Block (K = 10, N_(R) = 9)


(タイトルの当審仮訳:図1 現在のMBMSソースブロックを用いた概念的なAL-FECメカニズム(K=10, N_(R)=9))

「Figure 3 Example of Unrecoverable Error in the Current MBMS Source Block (K = 10, N_(R) = 9)


(タイトルの当審仮訳:図3 現在のMBMSソースブロックにおける復元できない誤りの例(K=10, N_(R)=9))

「Figure 4 Example of Enhanced Robustness for Source Block Structure in Figure 2 (K’ = 7, N_(R) = 9)


(タイトルの当審仮訳:図4 図2のソースブロック構造のロバスト性を拡張した例(K’=7, N_(R)=9))

(イ)上記記載から、引用文献1には、次の技術的事項が記載されているものと認められる。
a MBMS AL-FECスキームについて
「2.1 イントロダクション」の記載によれば、引用文献1に記載された技術は、MBMSのためのFEC(前方誤り訂正)に関するものである。ここで、MBMSがMultimedia Broadcast Multicast Service(マルチメディア放送及びマルチキャストサービス)の略であることは周知である。
「2.2 MBMS AL-FECスキームの概説」(以下「2.2」という)及び図1の記載によれば、引用文献1に記載されたMBMS AL-FECスキームは、ソースブロック構成器が、保護されるべきソースパケットの順序付けられたシーケンスを積み重ねることによってソースブロックを生成するものである。
また、「2.2」の記載によれば、ソースシンボルはFECスキームが動作するソースブロック内のデータ単位であり、ソースシンボルの数K=10であるから、FECスキームは、複数のソースシンボルを含むソースブロックを生成するといえる。
そして、図1,3,4の記載によれば、MBMS AL-FECスキームにおいて、各ソースパケットからソースシンボルが生成されるといえる。
「2.3 ソースブロックの構成と性能の関係」(以下「2.3」という)及び図1,3,4の記載によれば、シンボルサイズTは所与のソースデータに対して固定されており、シンボルサイズがソースシンボルのサイズに対応することは明らかである。
「2.2」には、MBMS AL-FECスキームにおいて、ソースブロックを構成した後、ソースブロック構成器がソースシンボルをFEC符号化器に入力として渡し、最後に、FEC符号化器はソースシンボルから所望の量(NR)のリペアシンボルを生成し、受信機に伝達されるように、これらのシンボルをFECリペアパケットに入れることが記載されている。
したがって、現在のMBMS AL-FECスキームでは、複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って受信機に伝達するといえる。
ソースシンボルやリペアシンボルはデータであり、受信機に伝達することは、受信機に送信することであるから、MBMS AL-FECスキームは、マルチメディア放送及びマルチキャストサービス(MBMS)におけるソースシンボル及びリペアシンボル(データ)を送信する方法に関するものである。

b 現在のMBMSソースブロッキングアルゴリズムについて
「2.2」及び図1の記載によれば、FECソースブロックの現在の構成方法では、各ソースパケットは1個又はそれ以上のソースシンボルを他のソースパケットと独立して生成するものである。
換言すれば、FECソースブロックの現在の構成方法では、各ソースパケットからソースシンボルを生成するのであって、生成されたソースシンボルは2個又はそれ以上のソースパケットからのデータ部分を含むことはないという制限のもとでソースシンボルを生成するものである。この結果、ゼロパディング処理、すなわち、ソースパケットが1個又はそれ以上のソースシンボルを満たさない場合に、ゼロパディングが行われている。

c 別のMBMSソースブロッキングアルゴリズムについて
「2.2」には、FECソースブロックの現在の構成方法では、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことが課題となることが記載されている。
「2.3」の記載によれば、別のソースブロッキングアルゴリズム(すなわち、新しいソースブロッキングアルゴリズム)は、ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得ることに注目し、所与のソースデータ及びシンボルサイズについて、ソースブロックアルゴリズムが現在のMBMSソースブロッキングアルゴリズムよりも少ないソースシンボルを生成することで、所与のFECコードに対して、よりロバスト性が高い保護レベルを追加のオーバヘッドなしに提供するものである。
図4のソースブロックは、ソースシンボルとリペアシンボルが、別のソースブロッキングアルゴリズムにより、そして、図3と同一のFEC符号化器により生成されたものであり、別のソースブロッキングアルゴリズムは、現在のMBMSソースブロッキングアルゴリズムに対応する図3とはソースブロックの構成だけが異なるものである。
したがって、引用文献1の図4に記載された別のソースブロッキングアルゴリズムは、図3の現在のMBMSソースブロッキングアルゴリズムと同様に、各ソースパケットから1個又はそれ以上のソースシンボルを生成するものである。
また、図4のソースブロッキングアルゴリズムは、現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らしたものである。

(ウ)上記(ア)、(イ)から、引用文献1には、次の発明(以下「引用発明」という。)が記載されていると認められる。
「マルチメディア放送及びマルチキャストサービス(MBMS)におけるデータを送信する方法であって、
複数のソースシンボルを含むソースブロックを生成するステップと、
ソースシンボルのサイズであるシンボルサイズTは所与のソースデータに対して固定されており、各ソースパケットからソースシンボルを生成するステップと、
複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って、ソースシンボル及びリペアシンボルを受信機に伝達するステップとを含み、
各ソースパケットからソースシンボルを生成するステップは、
現在のMBMSソースブロッキングアルゴリズムにより、
各ソースパケットは1個又はそれ以上のソースシンボルを他のソースパケットと独立して生成し、ゼロパディング処理として、ソースパケットが1個又はそれ以上のソースシンボルを満たさない場合、ゼロパディングが行われるステップ、
あるいは、
別のMBMSソースブロッキングアルゴリズムにより、
各ソースパケットは、現在のMBMSソースブロッキングアルゴリズムとは、ソースブロックの構成だけが異なるものとして、1個又はそれ以上のソースシンボルを生成し、
現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らすステップを含む、
データ送信方法。」

イ 引用文献2
(ア)同じく原査定に引用され、本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった特開2009-105962号公報(以下、「引用文献2」という。)には、次の記載がある。

「【0001】
本発明は、データを送受信するためのシステムと方法に関する。」

「【0010】
本発明のさまざまな実施態様によって、データの送信および/または受信に二次元アレイ等を使用できるシステムと方法が提供される。本発明のさらに別のさまざまな実施態様によると、送信されるデータに関する特性値を計算することができ、その特性値をそのデータとともに送信することができる。このような特性値は、データの受信に利用できる。特性値としては、例えば、順方向誤り訂正(FEC)データ、または他のチャネル符号化デ
ータなどが挙げられる。
【0011】
本発明の実施態様は、多くのタイプのネットワーク(例えばディジタルビデオ・ブロードキャスティング(DVB)ネットワーク)で利用することができる。」

「【0018】
(一般的な動作)
本発明のさまざまな実施態様によると、データを送受信するためのシステムと方法が提供される。本発明のさまざまな実施態様によると、記憶位置のアドレス指定が可能な二次元アレイ等を作ること、および/または送信ノードによってそのような二次元アレイ等にアクセスすることができる。」
【0019】
図1を参照すると、このような実施態様では、ノードによって送信されるデータに対応するパケット等は、おそらく特定のあるバーストにおいて、二次元アレイ等に列方向にロードされることがわかる(ステップ101)。このようなパケット等は、例えばインターネット・プロトコル(IP)パケットとしてよい。したがってロードされたパケット等の内容は、1つ以上の列内の、1つ以上のアドレス可能な記憶位置を占めることができる。
【0020】
次に、二次元アレイ等のそれぞれの行に沿って1つ以上の特性値を計算することができる(ステップ103)。このような特性値は、例えば順方向誤り訂正(FEC)データを表わすことができる。特別な一例として、このようなFECデータは、リード-ソロモン誤り訂正データにすることが可能である。次に、ある1つの行に対応する計算した特性値を記憶しておき、その行に付加することができる。したがってその特性値は、その行の1つ以上のアドレス可能な記憶位置を占めることができる。」

「【0059】
(二次元アレイ等へのローディング、アドレス指定、サイジング)
上記のタイプの二次元アレイ等に対しては、本発明のさまざまな実施態様によると、多数の方法でロードすることができる。例えばローディングが列方向になされるさまざまな実施態様では、列1つにつき1つのパケット等(例えばIPパケット)だけをロードすることができる。
【0060】
このような実施態様では、アレイの行および/または列のサイズは、1つの列が最大サイズのパケット等を保持できるように選択することができる。1つの列にロードされたパケット等が最大サイズに満たない場合には、その列の残部を“スタッフデータ(stuff data)”で埋める。特別な一例として、残部をゼロで埋めることができる。
【0061】
図3には、上述のローディング法が示してある。図3では、パケット等301は最大サイズであるため、このパケット等が存在している列303にスタッフデータは付加されていない。他方でパケット等305は最大サイズに満たないため、スタッフデータ307がその列に付加されて、パケット等305とスタッフデータ307がその列全体を占めている。1つ以上の列全体がスタッフデータだけで占められていることもありうる。そのような列は、データを含む列の前、間、後に配置することや、これらの組み合わせにすることができる。
【0062】
ローディングが列方向になされるさまざまな実施態様の別の一例として、パケット等が、そのパケット等がロードされた列を完全には埋めない場合には、その列に、アレイ等にロードされる次のパケット等が続けてロードされるようにできる。さらに、ある列にロードされているパケットがその列を完全には収まりきらない場合には、収まりきらない部分を1つ以上の別の列に収納することができる。
【0063】
例えば特定のパケット等がある列にピタリと収まらなかった場合には、このような機能は、その列が、その列のアドレス可能な最後のエレメント(例えばその列のエレメントで、最上位の行方向アドレスを有するエレメント)までそのパケット等の内容で埋まるようにした後、そのパケット等の残部を、次の列に、その列のアドレス可能な最初のエレメント(例えばその列のエレメントで、最下位の行方向アドレスを有するエレメント)から始まるように収納することによって実現できる。
【0064】
図4には、上記したローディング法が示してある。図4では、パケット等401は、そのパケット等401がロードされる列403を完全には埋めていないため、列403の残部はパケット等405の一部で埋められる。しかしパケット等405は、列403のうちでパケット等401によって埋められずに残った部分にはピタリと収まらないため、そのパケット等405の残部を、列407に、この実施例では第1のエレメント(例えば列のエレメントで、最下位の行方向アドレスを有するエレメント)から始まるように配置する。
【0065】
上記したタイプのさまざまな実施態様では、スタッフデータはパケット等の間に収納されることに注意されたい。このような機能は、例えばパケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長(バイト)の複数倍の長さになるようにすることを目的として実現することができる。このような機能を利用した実施態様では、ローディングが列方向にある実施態様で行方向のアドレス指定を1バイト全体粒度で実現できるため、対応するアレイ等でのアドレス方式を簡単化することができる。上記のタイプの実施態様では、データで埋められた列の間、前、後のいずれかにスタッフデータの列を用いることや、これらの方法の組み合わせにすることもできる。」

「【0067】
例えば受信ノードでは、指示された列のアドレス可能な第1のエレメント(例えばその列のエレメントで、最下位の行方向アドレスを有するエレメント)に受信されたパケット等が収納され、その列の埋められていない部分はスタッフデータで埋められるようにできることが理解されよう。他方、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様では、上記のタイプの指標は、行と列の両方のアドレスを指定する必要があることに注意されたい。
【0068】
ここでアドレス指定に移ると、本発明のさまざまな実施態様では、アドレス指定方式を上記のタイプのアレイ等に関して決定できることに注意されたい。特定のサイズのアレイ等に関して考えると、アドレス指定方式の選択は、そのアレイ等のアドレス可能なエレメントの数を決定する効果を有するとみなすことができる。
【0069】
特定のサイズのアレイ等に関して考えると、行方向のアドレス方式の選択は、上記のタイプのアレイ等における行の数を決定する効果を有するとみなせるのに対し、列方向のアドレス方式の選択は、上記のタイプのアレイ等における列の数を決定する効果を有するとみなせることにも注意されたい。さらに、行方向と列方向のアドレス方式の選択は、特定のサイズのアレイ等に関して考えると、そのアレイ等のアドレス可能なエレメントのサイズの選択であると考えられることにも注意されたい。
【0070】
特別な一例として、上記のタイプのアレイ等は、行と列の両方のアドレス指定が1バイトの粒度でなされるように実現することができる。別の特別な一例として、上記のタイプのアレイ等にデータが列方向にロードされる場合には、列方向のアドレス指定を選択し、利用可能なアドレス空間を最大限に利用するようにすることができる。例えば32ビットのアドレス指定が利用できる場合、列方向のアドレス指定を選択し、可能な最大数の列が利用できるようにする。そのとき、おそらくアレイ等に記憶されるデータ(例えばIPパケット)の最大サイズを考慮して決定を行なう。」

「【0074】
ローディングが列方向である別の一例として、送信ノードは、送られるバーストごとにアレイ等のサイズを変えることができる。特別な一例として、送信ノードは、対応するアレイ等が、特定の1つのバースト内で送られるすべてのパケット等と、対応するあらゆる特性データとを保持できるように列の高さと行の幅を選択することができる。別の一例として、送信ノードは、同様に、但し指定されたおよび/または固定された列の高さまたは行の幅に従って動作することができる。例えば列の高さが指定されているとき、その列の高さは、アレイ等にロードされるタイプのパケット等の最大サイズに一致していてもよいし、他の何らかの値でもよい。列の高さおよび/または行の幅が固定されていない実施態様では、送信ノードは、すでに述べたように、受信ノードにサイズの指標を1つ以上送ることができる。アレイ等のサイズが固定されているさまざまな実施態様では、アレイ等のすべてが利用されないのであれば、送信ノードは、アレイ等のどの部分を利用するかの指示を受信ノードに送ることができることに注意されたい。このような指示は、例えばアドレスにすることができる。」

「【図1】


(【図1】本発明の実施態様によるデータ送信に関係するステップの具体例を示した説明図である。)

「【図3】


(【図3】本発明の実施態様による第1のローディング法の説明図である。)

「【図4】


(【図4】本発明の実施態様による第2のローディング法の説明図である。)

(イ)上記記載によれば、引用文献2には、次の技術が記載されているといえる。
【0001】及び【0011】の記載によれば、引用文献2に記載された技術は、ディジタルビデオ・ブロードキャスティング(DVB)ネットワークで利用することができ、データを送受信するための方法に関するものである。
【0010】,【0018】?【0020】及び図1の記載によれば、パケット等を列方向にロードした、記憶位置のアドレス指定が可能な二次元アレイ等を作り、データの送信に二次元アレイを使用できる方法である。また、送信されるデータに関する特性値(順方向誤り訂正(FEC)データ)を二次元アレイ等のそれぞれの行に沿って計算することができ、その特性値をその行に付加してそのデータとともに送信する方法である。
また、【0074】の記載によれば、送信ノードは、同様に、指定された及び/又は固定された列の高さに従って動作することができ、二次元アレイ等の列の高さは固定されているといえる。

【0059】及び【0060】の記載によれば、二次元アレイ等へのローディング法の「一つの実施態様」(以下、「一つの例」という。)は、列1つにつき1つのパケット等だけをロードするものであって、列の残部をスタッフデータ、一例として、ゼロで埋めるものである。
ここで、【0074】の記載によれば、列の高さは固定されており、アレイ等にロードされるタイプのパケット等の最大サイズでなく、他の何らかの値でもよい。
そうすると、当該「一つの例」に対応して、【0060】,【0061】,【0074】及び図3に記載されたローディング法は、二次元アレイの列のサイズは、パケット等の最大サイズとは異なる他の値が指定されており、パケット等が列のサイズであればスタッフデータは付加されず、パケット等が列のサイズに満たないのであればスタッフデータがその列に付加されて、パケット等とスタッフデータがその列全体を占めるものといえる。
つまり、引用文献2に記載された、「一つの例」では、パケット等が列のサイズよりも大きい場合は、列のサイズを越える残りの部分のデータは、当然別の列にロードされることとなるが、当該実施態様は、列1つにつき1つのパケット等だけをロードするものであるから、残りの部分のデータのサイズが別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加されるといえる。

一方で、【0062】の記載によれば、二次元アレイ等へパケット等を列方向にローディングする「別の一例」は、パケット等が、そのパケット等がロードされた列を完全には埋めない場合には、その列に、アレイ等にロードされる次のパケット等が続けてロードされるようにでき、さらに、ある列にロードされているパケットがその列を完全には収まりきらない場合には、収まりきらない部分を1つ以上の別の列に収納するものである。
また、【0064】及び図4の記載によれば、図4のローディング法では、パケット等401がロードされる列403を完全には埋めていないと、列403の残部はパケット405の一部で埋められる。そして、パケット等405が、列403のうちでパケット等401によって埋められずに残った部分にはピタリと収まらないと、そのパケット等405の残部を、列407(次の列)の第1のエレメントから始まるように配置する。
【0067】の記載によれば、【0062】,【0064】及び図4に記載されたローディング方法、すなわち、「別の一例」は、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様であるといえる。
したがって、「別の一例」は、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様であり、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるものである。また、ある列にロードされているパケット等がその列に完全には収まりきらない場合には、収まりきらない部分を次の列の第1のエレメントから始まるように配置するものである。
そして、【0065】には、図4に対応した、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様について、パケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長(バイト)の複数倍の長さになるようにすることを目的として、スタッフデータがパケット等の間に収納されることが記載されている。当該機能を利用すると、行方向のアドレス指定を1バイト全体粒度で実現可能である。
【0068】?【0070】の記載によれば、アドレス指定方式の選択は、特定のサイズのアレイ等に関して考えると、そのアレイ等のアドレス可能なエレメントの数やエレメントのサイズを選択するものであり、その特別な一例として、行と列の両方のアドレス指定が1バイトの粒度でなされるように実現することができるものである。
そうすると、「別の一例」において、続けてロードされる「次のパケット」のアドレスを指定するにあたり、アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応するものである。そして、粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長(バイト)の複数倍の長さになるようにするものである。
さらに、【0069】,【0070】及び【0074】の記載によれば、二次元アレイ等は、行方向と列方向に、粒度単位でアドレス指定が可能であり、列の高さが指定された及び/又は固定されたものである。ここで、列の高さは、上述したように、アレイ等にロードされるタイプのパケット等の最大サイズに一致していてもよいし、他の何らかの値でもよいものである。
また、【0063】の記載によれば、パケット等の内容で、その列のアドレス可能なエレメントをパケット等の内容で埋まるようにした後、次の列のアドレス可能な最初のエレメントに、そのパケット等の残部を収納しているから、エレメントのサイズはパケット等のサイズよりも小さいと言える。
ここで、引用文献2に記載された、列1つにつき1つのパケット等だけをロードする「一つの例」(図3に対応)と、列1つにつき2つ以上のパケット等が収納されるローディングを行なう「別の一例」(図4に対応)を比較すると、パケット等が列のサイズに満たない場合(ロードされた列を完全には埋めない場合)、前者は、スタッフデータがその列に付加されて列の残部を埋めるのに対し、後者は、その列に次のパケット等が続けてロードされるから、二次元アレイ等にローディングするパケットの合計サイズが同じであれば、後者の方が、スタッフデータが少なくなり、二次元アレイ等の行の幅(列の個数)も少なくなることは明らかである。

(ウ)上記(イ)によれば、引用文献2には、次の技術が記載されていると認められる。
「ディジタルビデオ・ブロードキャスティング(DVB)ネットワークで利用することができ、データを送受信するための方法であって、
データの送信に記憶位置のアドレス指定が可能であり、列の高さが指定された及び/又は固定された二次元アレイ等を使用し、
二次元アレイ等へパケット等を列方向にローディングするローディング法として、
一つの例として、
列1つにつき1つのパケット等だけをロードし、
二次元アレイの列のサイズは、パケット等の最大サイズとは異なる他の値が指定されており、
パケット等が列のサイズであればスタッフデータは付加されず、
パケット等が列のサイズに満たないのであればスタッフデータがその列に付加されて、パケット等とスタッフデータがその列全体を占め、
パケット等が列のサイズよりも大きい場合は、列のサイズを越える残りの部分のデータは、別の列にロードされ、残りの部分のデータのサイズが別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加され、
スタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるローディング法、
と、
別の一例として、
列1つにつき2つ以上のパケット等が収納されるローディングを行ない、
パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされ、
また、ある列にロードされているパケット等がその列に完全には収まりきらない場合には、収まりきらない部分を次の列の第1のエレメントから始まるように配置され、
記憶位置のアドレス指定が、行方向と列方向に、粒度単位で可能であり、
アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応し、当該エレメントのサイズはパケット等のサイズよりも小さく、
粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長(バイト)の複数倍の長さになるようにし、
スタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるローディング法、
の2つのローディング法。」

(3)引用発明との対比
ア 本件補正発明と引用発明とを対比する。
(ア)引用発明は、マルチメディア放送及びマルチキャストサービス(MBMS)におけるFECに関するものである。
ここで、マルチメディア放送は放送の一種であり、マルチキャストは通信の一種であるから、引用発明は、放送及び通信サービスを行うシステムに関するものである。
したがって、引用発明の「マルチメディア放送及びマルチキャストサービス(MBMS)におけるデータを送信する方法」は、本件補正発明の「放送及び通信システムにおけるデータを送信する方法」に相当する。
(イ)引用発明の「ソースブロック」は、「複数のソースシンボルを含む」点で、本件補正発明の「ソースシンボルブロック」と共通し、引用発明の「ソースブロック」は、本件補正発明の「ソースシンボルブロック」であるといえる。
(ウ)引用発明と本件補正発明は、「複数のソースシンボルを含むソースシンボルブロックを生成するステップ」を含む点で共通する。
(エ)引用発明は、「ソースシンボルのサイズであるシンボルサイズTは所与のソースデータに対して固定され」たものである。
また、本件補正発明は、「複数のソースシンボル」が、「同一の数の同一のサイズのシンボルエレメントに各々が分割される」から、ソースシンボルのサイズは、同一のサイズのシンボルエレメントの定数倍であり、固定されているといえる
したがって、引用発明と本件補正発明は、「複数のソースシンボル」の「サイズが固定されている」点で共通する。
(オ)引用発明は、「各ソースパケットからソースシンボルを生成するステップ」を含み、「各ソースパケット」には、一のソースパケットと、それに後続するソースパケットが含まれることは明らかである。
本件補正発明は、「第1のソースパケット」を「第1のシンボルエレメント」に配置し、「第2のソースパケット」を「第2のシンボルエレメント」に配置するものである。ここで、「第1のシンボルエレメント」及び「第2のシンボルエレメント」は、「ソースシンボルブロック内」の「一つ以上の連続するシンボルエレメント」を含むから、「複数のソースシンボル」の一部である。
また、本件補正発明は、「第1のソースパケットの少なくとも一部」及び「第2のソースパケットの少なくとも一部」を「第1のソースシンボル」に配置するものである。
したがって、引用発明と本件補正発明は、「第1のソースパケット」及び「第1のソースパケットに後続する第2のソースパケット」を「複数のソースシンボル」に配置するステップを含む点で共通する。
(カ)引用発明は、「複数のソースシンボルをFEC符号化器に入力し、ソースシンボルからリペアシンボルを生成し、リペアパケットに入れる符号化を行って、ソースシンボル及びリペアシンボルを受信機に伝達するステップ」を含み、引用発明の「複数のソースシンボル」は、「ソースブロック」に含まれる。
したがって、引用発明と本件補正発明は、「ソースシンボルブロックの複数のソースシンボルブロックを符号化して伝送するステップ」を含む点で共通する。
(キ)引用発明の「データ送信方法」は、本件補正発明の「データ送信方法」といえる。

イ 以上のことから、本件補正発明と引用発明との一致点及び相違点は、次のとおりである。
【一致点】
「放送及び通信システムにおけるデータを送信する方法であって、
サイズが固定されている複数のソースシンボルを含むソースシンボルブロックを生成するステップと、
第1のソースパケット及び第1のソースパケットに後続する第2のソースパケットを複数のソースシンボルに配置するステップと、
ソースシンボルブロックの複数のソースシンボルを符号化して伝送するステップとを含む、
データ送信方法。」

【相違点1】
一致点の「サイズが固定されている複数のソースシンボル」について、本件補正発明では、「同一の数の同一のサイズのシンボルエレメントに各々が分割される」のに対して、引用発明は、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題としているものの、「シンボルサイズTが所与のソースデータに対して固定されている」との記載に留まり、「別のMBMSソースブロッキングアルゴリズム」について「複数のソースシンボル」が同一の数の同一のサイズで分割されていることが特定されていない点。
【相違点2】
一致点の「第1のソースパケット及び第1のソースパケットに後続する第2のソースパケットを複数のソースシンボルに配置するステップ」について、本件補正発明は、「第1のソースパケットを前記ソースシンボルブロック内の一つ以上の連続するシンボルエレメントを含む第1のシンボルエレメントに配置し、前記第1のソースパケットに後続する第2のソースパケットを前記第1のシンボルエレメントに後続する一つ以上の連続するシンボルエレメントを含む第2のシンボルエレメントに配置するステップ」を含み、「前記第1のシンボルエレメントの最後のシンボルエレメントが第1のソースシンボルの最後のシンボルエレメントではない場合、前記第1のソースパケットの少なくとも一部及び前記第2のソースパケットの少なくとも一部は、前記ソースシンボルブロックの同一の前記第1のソースシンボルに配置され」、「前記第1のシンボルエレメントの最後のシンボルエレメントが前記第1のソースシンボルの最後のシンボルエレメントではなく、前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合、前記第1のシンボルエレメントの最後のシンボルエレメントは、前記第2のシンボルエレメントの最初のシンボルエレメントの前までパディングされる」のに対して、引用発明は、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題としているものの、「現在のMBMSソースブロッキングアルゴリズム」のソースブロックの構成及びゼロパディング処理について記載されているのみであって、「ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす」ための、「別のMBMSソースブロッキングアルゴリズム」のソースブロックの具体的な構成及びゼロパディング処理の詳細が特定されていない点。

(4)判断
以下、相違点について検討する。
ア 相違点1について
引用文献2に記載された技術の「記憶位置のアドレス指定が可能であり、列の高さが指定された及び/又は固定された二次元アレイ等」は、DVBネットワークで利用することができ、データの送信に使用され、パケット等がその列方向にローディングされるものであるから、「ソースシンボルブロック」に他ならない。
また、引用文献2に記載された技術の「二次元アレイ等」が複数の「列」を含むことは明らかであるから、引用文献2に記載された技術の「列」は、「ソースシンボルブロック」に含まれる「ソースシンボル」といえる。
そうすると、引用文献2に記載された技術の「二次元アレイ等の行の幅(列の個数)」は、本件補正発明における「ソースシンボルの数」に対応する。
引用文献2に記載された技術のスタッフデータは、列の残部を埋めるものであり、特別な一例として、残部をゼロで埋めるものであるから、スタッフデータが収納されることは、「パディングされること」に他ならない。
次に、引用発明は、シンボルサイズTが固定されており、引用文献2に記載された技術も、列の高さが指定された及び/又は固定された二次元アレイ等を使用するものであるから、引用発明と引用文献2に記載された技術とは、ソースシンボルのサイズが固定されている点で共通する。
引用発明における「現在のMBMSソースブロッキングアルゴリズム」は、「各ソースパケットは1個又はそれ以上のソースシンボルを他のソースパケットと独立して生成し、ゼロパディング処理として、ソースパケットが1個又はそれ以上のソースシンボルを満たさない場合、ゼロパディングが行われる」ものであるから、「列1つにつき1つのパケット等だけをロード」し、「パケット等が列のサイズに満たないのであればスタッフデータがその列に付加され」、「列のサイズを越える残りの部分のデータ」のサイズが「別の列のサイズに満たないのであれば、スタッフデータが当該別の列に付加され」るという、引用文献2に記載された技術の「一つの例」である。
一方で、「列1つにつき2つ以上のパケット等が収納されるローディングを行な」う引用文献2に記載された技術の「別の一例」は、「一つの例」と比較して、パディングのデータが少なくなり、ソースシンボル数も少なくなるローディング法であるから、「現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす」という引用発明の「別のMBMSソースブロッキングアルゴリズム」と同じ効果を有するローディング法である。
ここで、「別の一例」における「二次元アレイ等」は、列の高さが指定された及び/又は固定されたものであって、列方向にアドレス指定可能であり、アドレスは粒度(エレメントのサイズ)単位で指定されるから、「別の一例」の複数の「列」は粒度(エレメントのサイズ)単位ごとに同一の数に同一サイズで分割されているといえる。
したがって、「別の一例」は、同一の数の同一のサイズの粒度(エレメントのサイズ)単位ごとに分割される複数のソースシンボルをソースシンボルブロックにローディングするステップを含む方法である。
引用発明と引用文献2に記載された技術とは、ともに放送システムにおけるデータを送信する方法であって、ソースシンボルのサイズが固定されたソースシンボルブロックを生成し、送信されるデータに関する順方向誤り訂正データを計算してデータとともに送信するものであって、引用発明の「別のMBMSソースブロッキングアルゴリズム」と、引用文献2に記載された技術の「別の一例」は同じ効果を有するローディング法であるから、引用発明の「ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまう課題を解決するための別のMBMSソースブロッキングアルゴリズム」の具体的な方法として、引用文献2に記載された技術の「別の一例」のローディング法を採用して、複数のソースシンボルを同一の数の同一のサイズの粒度(エレメントのサイズ)単位ごとに分割されるようにして、複数のソースシンボルをソースシンボルブロックにローディングすることで、ソースシンボルブロックを生成するステップを含めることは、当業者が容易に想到し得たことである。

イ 相違点2について
「ア 相違点1について」で述べたように、引用発明における「別のMBMSソースブロッキングアルゴリズム」として、引用文献2に記載された技術の「別の一例」を採用した場合、「別の一例」における「列」は、同一の数の同一のサイズの粒度(エレメントのサイズ)単位ごとに分割されたものである。
そして、「別の一例」のエレメントのサイズは、パケット等のサイズよりも小さいから、「別の一例」のパケット等は、複数の粒度単位に配置されるといえる。そして、パケット等が連続する粒度単位に配置されることは、図4から明らかである。
また、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるから、パケット等の次のパケット等は、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置されるといえる。
したがって、「別の一例」は、パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置するステップを含む方法である。
また、一つ以上の連続する粒度単位を「第1のシンボルエレメント」と、それに後続する一つ以上の連続する粒度単位を「第2のシンボルエレメント」と称することは任意である。

上記によれば、「別の一例」は、パケット等がロードされた列を完全に埋めない場合は、その列に次のパケット等が続けてロードされ、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるものである。
そうすると、パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)の最後の粒度単位が、パケット等がロードされた列の最後の粒度単位ではない場合、当該列を完全に埋めないから、当該列には、パケット等の少なくとも一部及び次のパケット等の少なくとも一部がロードされるといえる。
したがって、「別の一例」は、パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるステップを含む方法である。

以上のとおり、引用文献2に記載された技術の「別の一例」は、パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位に後続する、一つ以上の連続する粒度単位に配置するステップを含む方法であり、パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるステップを含む方法である。
すなわち、「別の一例」では、パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、当該ソースシンボルには、パケット等の最後の粒度単位が配置され、さらに、それに後続する次のパケット等の最初の粒度単位が配置されるといえる。
「別の一例」は、粒度単位でのアドレス指定を実現するために、スタッフデータをパケット等の間に収納し、1つのパケット等とそれに付随するスタッフデータの長さが、ワード長(バイト)の複数倍の長さになるようにするものであるから、パケット等が、当該パケット等が配置される一つ以上の連続する粒度単位、すなわち、第1のシンボルエレメントを満たさない場合、第1のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までスタッフデータが収納されているといえる。
また、「ア 相違点1について」で述べたように、スタッフデータが収納されることは、「パディングされること」に他ならない。
上記によれば、「別の一例」は、パケット等が配置された第1のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、ソースシンボルには、パケット等の最後の粒度単位と、それに後続する次のパケット等の最初の粒度単位が配置され、さらに、パケット等が第1のシンボルエレメントを満たさない場合、第1のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるものである。

そうすると、「ア 相違点1について」で述べたように、引用発明における「別のMBMSソースブロッキングアルゴリズム」として、引用文献2に記載された技術の「別の一例」を採用して、
パケット等をソースシンボルブロック内の一つ以上の連続する粒度単位(第1のシンボルエレメント)に配置し、次のパケット等を、パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)に後続する、一つ以上の連続する粒度単位(第2のシンボルエレメント)に配置するステップを含め、
パケット等が配置された一つ以上の連続する粒度単位(第1のシンボルエレメント)の最後の粒度単位が、ソースシンボルの最後の粒度単位ではない場合、パケット等の少なくとも一部及び次のパケット等の少なくとも一部が、ソースシンボルブロックの同一のソースシンボルに配置されるようにし、
パケット等が配置された第1のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではなく、さらに、パケット等が第1のシンボルエレメントを満たさない場合、第1のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるようにすることは、当業者が容易に想到し得たことである。

ウ そして、これらの相違点を総合的に勘案しても、本件補正発明の奏する作用効果は、引用発明及び引用文献2に記載された技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

エ したがって、本件補正発明は、引用発明及び引用文献2に記載された技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。

3 請求人の主張について
(1)請求人は、平成30年3月13日に提出された審判請求書において、
引用文献1及び引用文献2が、本件補正発明の「前記第1のシンボルエレメントの最後のシンボルエレメントが前記第1のソースシンボルの最後のシンボルエレメントではなく、前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合、前記第1のシンボルエレメントの最後のシンボルエレメントは、前記第2のシンボルエレメントの最初のシンボルエレメントの前までパディングされること」(構成1)を開示及び示唆していない旨を主張し、さらに、「引用文献1および2を参照して、シンボルエレメントの概念に対して構成1を採用する点を明示的に開示するものではなく、シンボルエレメント単位でパディングが遂行され得る点も全く開示および示唆していません。また、引用文献1および2は、構成1に関して、ソースシンボルの開始部分でも最後の部分でもない中間部分にパディングが遂行される構成を開示も示唆もするものではありません。」と主張している(同審判請求書の「【本願発明が特許されるべき理由】(c)引用文献発明との差違について」を参照)。
審判請求書における当該主張について検討する。
「2(4)イ 相違点2について」で述べたように、引用発明において、引用文献2に記載された技術の「別の一例」のローディング法を採用して、パケット等が配置された第1のシンボルエレメントの最後の粒度単位が、ソースシンボルの最後の粒度単位ではなく、さらに、パケット等が第1のシンボルエレメントを満たさない場合、第1のシンボルエレメントの最後の粒度単位に後続する次のパケット等の最初の粒度単位の前までパディングされるようにすることは、当業者が容易に想到し得たことである。
そして、この場合の第1のシンボルエレメントの最後の粒度単位は、「ソースシンボルの開始部分でも最後の部分でもない中間部分」に他ならないから、引用文献2は、「構成1」を開示及び示唆するものである。

(2)請求人は、平成30年7月6日に提出された上申書において、
引用文献2には、「ローディングが列方向にある実施態様で行方向のアドレス指定を1バイト全体粒度で実現できるため、対応するアレイ等でのアドレス方式を簡単化することができる」(同文献段落[0065])と開示するのみであり、その目的はあくまでもアドレス方式の簡略化であるといえ、従って、引用文献2は、任意の粒度についてまで開示しているとはいえないと主張している。
また、引用文献2では、「パケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長(バイト)の複数倍の長さになるように」(同文献段落[0065])とあるように、丸められたデータは「ワード長(バイト)の複数倍の長さ」になるものであり、「ソースシンボル長」に依存する長さとなることを何ら開示及び示唆していない旨を主張している(同上申書の(2)参照)。
上申書の当該主張について検討すると、「2(2)イ 引用文献2(ウ)」で述べたように、引用文献2に記載された技術の「別の一例」のローディング法は、「アドレス指定方式を選択することによって、アドレス可能なエレメントの数やエレメントのサイズを選択可能なものであり、当該エレメントのサイズはアドレス指定が可能な粒度に対応」するものである。
したがって、引用文献2には、アドレス指定方式を選択することで、任意の粒度を選択可能なこと、すなわち、アドレス可能なエレメントのサイズを1バイト以外にすることが記載されている。
また、引用文献2に記載された技術の「別の一例」のローディング法は、粒度単位でのアドレス指定を実現するためのものであり、「2(4)ア 相違点1について」で述べたように、「別の一例」の複数の「列」(ソースシンボル)は粒度(エレメントのサイズ)単位ごとに同一の数に同一サイズで分割されているといえるから、引用文献2は、粒度(エレメントのサイズ)がソースシンボルを同一サイズで分割した長さとなっているといえる。

(3)請求人は、同上申書において、
引用文献2は、本願明細書の段落[0005]が開示する「ソースパケットの所望する長さを短縮させることにより相対的にゼロパディングの量を減少させることができる。しかしながら、ソースブロックを構成するシンボルの個数が大きく増加するために、非常に長い長さを有するFEC符号が必要とされる。」との課題を何ら開示及び示唆しておらず、引用文献1と組み合わせることで当該課題の解決が可能であることは、引用文献1及び2を参照したとしても自明ではないと主張している(同上申書の(2)参照)ので、当該主張について検討する。
引用文献1の「2.2」及び「2.3」には、引用発明が、ゼロパディング処理によりソースシンボル数の増加が引き起こされてしまうことを課題とするものであり、ソースシンボルの数の減少は、ソースブロックのゼロパディング部分を減らすことによって達成され得ることが記載されている。
また、引用文献2には、「2(2)イ 引用文献2(イ)」及び「2(2)イ 引用文献2(ウ)」で述べたように、引用文献2に記載された技術として「一つの例」と「別の一例」が記載されており、両者を比較すると、後者の方がスタッフデータが少なくなることは明らかである。
したがって、引用発明において、「一つの例」に対応する現在のMBMSソースブロッキングアルゴリズムよりも、ソースシンボル数を少なくして、ソースブロックのゼロパディング部分を減らす「別の一例」を採用することで、収納されるスタッフデータの量、すなわち、パディングの量を減少させ得ることは自明である。

(4)請求人は、同上申書において、
本願明細書の段落[0061]に開示された「他方、本発明の実施形態によるソースブロック内の行又は符号化シンボルがm個の領域に分割されるので、損失された部分と損失されない部分とに識別されることができ、したがって、m個の領域内の損失されない部分が復号のために使用されることにより、本発明の実施形態による復号性能を向上させることができる。」との格別な効果は、列ごとにローディングを行う実施形態のみを明示的に示す引用文献2の発明では獲得できるものではなく、つまり、請求項1に係る発明により得られる技術的効果は、引用文献1及び2に開示の発明とは異質であると主張している(同上申書の(3)参照)。
当該主張について検討すると、引用文献2の【0020】には、二次元アレイ等のそれぞれの行に沿って1つ以上の特性値(順方向誤り訂正(FEC)データ)を計算し、ある1つの行に対応する計算した特性値を記憶しておき、その行に付加することが記載されている。
技術常識を参酌すれば、当該二次元アレイ等を受信側に送信した場合、受信側において行われる誤り訂正処理は、当該二次元アレイ等の行に沿って行われるから、誤り訂正処理が損失されない行の部分について行われることは自明である。そして、二次元アレイ等のうち、損失された行の部分は誤り訂正処理に使用できないことは当然である。
したがって、本件補正発明の奏する作用効果は、引用発明及び引用文献2に記載された技術の「別の一例」の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

したがって、(1)?(4)の請求人の主張は、採用することができない。

4 本件補正についてのむすび
よって、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって、上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について
1 本願発明
平成30年3月13日にされた手続補正は、上記のとおり却下されたので、本願の請求項に係る発明は、平成29年5月22日にされた手続補正により補正された特許請求の範囲の請求項1ないし2に記載された事項により特定されるものであるところ、その請求項1に係る発明(以下「本願発明」という。)は、その請求項1に記載された事項により特定される、前記第2[理由]1(2)に記載のとおりのものである。

2 原査定の拒絶の理由
原査定の拒絶の理由は、この出願の請求項1,2に係る発明は、本願の優先権主張の日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1に記載された発明及び引用文献2に記載された事項に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない、というものである。

引用文献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>,2012年 4月
引用文献2:特開2009-105962号公報

3 引用文献
原査定の拒絶の理由で引用された引用文献1ないし2及びその記載事項は、前記第2の[理由]2(2)に記載したとおりである。

4 対比・判断
本願発明は、前記第2の[理由]2で検討した本件補正発明から、「前記第1のシンボルエレメントの最後のシンボルエレメントが前記第1のソースシンボルの最後のシンボルエレメントではなく、前記第1のソースパケットが前記第1のシンボルエレメントを満たさない場合、前記第1のシンボルエレメントの最後のシンボルエレメントは、前記第2のシンボルエレメントの最初のシンボルエレメントの前までパディングされること」の下線部に係る限定事項を削除したものである。
そうすると、本願発明の発明特定事項を全て含み、さらに他の事項を付加したものに相当する本件補正発明が、前記第2の[理由]2(3)、(4)に記載したとおり、引用発明及び引用文献2に記載された技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、引用発明及び引用文献2に記載された技術に基づいて、当業者が容易に発明をすることができたものである。

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

よって、結論のとおり審決する。
 
別掲
 
審理終結日 2019-01-23 
結審通知日 2019-01-28 
審決日 2019-02-08 
出願番号 特願2015-511356(P2015-511356)
審決分類 P 1 8・ 575- Z (H04L)
P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 谷岡 佳彦  
特許庁審判長 吉田 隆之
特許庁審判官 宮下 誠
古河 雅輝
発明の名称 放送及び通信システムにおけるパケット送受信装置及び方法  
代理人 崔 允辰  
代理人 実広 信哉  
代理人 木内 敬二  
代理人 阿部 達彦  
  • この表をプリントする

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