ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L 審判 査定不服 原文新規事項追加の補正 特許、登録しない(前置又は当審拒絶理由) H04L |
|---|---|
| 管理番号 | 1360960 |
| 審判番号 | 不服2018-4527 |
| 総通号数 | 245 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2020-05-29 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2018-04-04 |
| 確定日 | 2020-03-17 |
| 事件の表示 | 特願2015-508859「通信システムでパケットを送受信するための装置及び方法」拒絶査定不服審判事件〔平成25年10月31日国際公開、WO2013/162250、平成27年 6月25日国内公表、特表2015-518346〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、平成25年4月23日(パリ条約に基づく優先権主張外国庁受理 平成24年4月23日 韓国、平成24年4月30日 韓国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。 平成26年10月30日 :手続補正書の提出 平成29年 3月 3日付け:拒絶理由通知書 平成29年 6月23日 :意見書、手続補正書の提出 平成29年11月27日付け:拒絶査定 平成30年 4月 4日 :拒絶査定不服審判の請求、手続補正書の提出 平成31年 2月20日付け:拒絶理由通知書 令和 元年 5月27日 :意見書、手続補正書の提出 令和 元年 6月18日付け:最後の拒絶理由通知書 令和 元年 9月24日 :意見書、手続補正書の提出 第2 令和元年9月24日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 令和元年9月24日にされた手続補正(以下、「本件補正」という。)を却下する。 [理由] 1 本件補正について (1)本件補正後の特許請求の範囲 本件補正により、特許請求の範囲の請求項1の記載は、次のとおり補正された(下線部は、補正箇所である。)。 「【請求項1】 メディアデータを送信するための方法において、 伝送する少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を順方向エラー訂正(FEC)符号化し、リペアシンボルを生成する段階と; 前記少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を利用してFECパケットを生成する段階と; 前記リペアシンボルを利用してリペアパケットを生成する段階と; 前記リペアパケットを含む前記FECパケットを送信する段階と;を含み、 ここで、FECパケットヘッダーは、順次に増加するシーケンス番号を含み、 前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子と前記リペアパケットのための連続的なシーケンス番号を含み、 対応するFECブロックの初期シーケンス番号は、FECブロック境界情報として各パケットのヘッダーに含まれ、 前記FECパケットは前記FECブロック境界情報を含み、前記リペアパケットのヘッダーの分離されたシーケンス番号は、前記FECブロックのパケットに順に割り当てられる、 ことを特徴とするパケット伝送方法。」 2 補正の適否 本件補正により、本願の請求項1に係る発明に「前記リペアパケットのヘッダーの分離されたシーケンス番号は、前記FECブロックのパケットに順に割り当てられる」との発明特定事項(以下、「特定事項1」という。)が加えられた。本件補正は、以下に示すように、本願の出願当初の明細書、特許請求の範囲及び図面(以下、「当初明細書等」という。)に記載した事項の範囲内でなされたものではない。 (1) 当初明細書等において、シーケンス番号の割り当てに関する記載は、「シーケンス番号は、FECソースパケットに順に割り当てられ、分離されたシーケンス番号は、FEC復旧パケットに順に割り当てられる。」(【0053】)との記載のみである。当該記載に鑑みれば、シーケンス番号には、(a)FECソースパケットに順に割り当てられる「シーケンス番号」と、(b)FEC復旧パケットに順に割り当てられる「分離されたシーケンス番号」とがある。 また、当初明細書等の「以下で説明は、本発明の実施例によるFECパケット生成手続に関する。パケットヘッダーのペイロード形式は、対応するペイロードにマッチングするために構成される。すなわち、ソースペイロードのためのパケットのペイロード形式は、オーディオ、ビデオなどのような、ソースペイロード形式を示す。そして、復旧ペイロードのためのパケットのペイロード形式は、復旧ペイロードを示す。」(【0053】)との記載及び【0055】の【表1】によれば、FECソースパケット及びFEC復旧パケットは全体でFECパケットと総称され、それらのヘッダー構造は共通であり、前記(a)及び(b)は共にヘッダーの「シーケンス番号」のフィールドに格納され、両者はヘッダーの「ペイロード形式」の内容により区別されると認められる。 【表1】  (2) しかしながら、特定事項1の「分離されたシーケンス番号」は、リペアパケットすなわちFEC復旧パケットのためのものであるにも関わらず「FECブロックのパケット」すなわちFECソースパケット及びFEC復旧パケットの双方に順に割り当てられたものである点で、前記(a)とも前記(b)とも異なるものである。 3 本件補正についてのむすび 前記2(2)のとおりであるから、本件補正により特定事項1を加えた本件補正発明は、当初明細書等に記載した事項の範囲内のものとはいえない。したがって、本件補正は、特許法17条の2第3項の規定に違反するので、同法159条1項の規定において読み替えて準用する同法53条1項の規定により却下すべきものである。 よって、上記補正の却下の決定の結論のとおり決定する。 第3 本願発明について 1 本願発明 本件補正は前記第2のとおり却下されたので、本願の請求項1?10に係る発明は、本件補正前の令和元年5月27日にされた手続補正により補正された特許請求の範囲の請求項1?10に記載された事項により特定されるものと認められるところ、その請求項1に係る発明(以下「本願発明」という。)は、以下のとおりのものである。 「【請求項1】 メディアデータを送信するための方法において、 伝送する少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を順方向エラー訂正(FEC)符号化し、リペアシンボルを生成する段階と; 前記少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を利用してFECパケットを生成する段階と; 前記リペアシンボルを利用してリペアパケットを生成する段階と; 前記リペアパケットを含む前記FECパケットを送信する段階と;を含み、 ここで、FECパケットヘッダーは、順次に増加するシーケンス番号を含み、 前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子と前記リペアパケットのための連続的なシーケンス番号を含み、 対応するFECブロックの初期シーケンス番号は、FECブロック境界情報として各パケットのヘッダーに含まれ、 前記FECパケットはFECの境界に関する情報を含む ことを特徴とするパケット伝送方法。」 2 当審の拒絶理由通知書の概要 当審の拒絶の理由である、令和元年6月18日付け拒絶理由通知の理由は、概略、次のとおりのものである。 理由1.この出願は、明細書、特許請求の範囲及び図面の記載が不備のため、特許法第36条第6項第1号に規定する要件を満たしていない。 理由2.この出願は、特許請求の範囲の記載が特許法第36条第6項第2号に規定する要件を満たしていない。 理由3.この出願の請求項1に係る発明は、以下の引用文献1に記載された発明並びに引用文献2及び3に示される周知技術に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献1.岸田 崇志 他,“IPストリーム伝送のための誤り訂正機能をもつアプリケーションゲートウェイの開発”,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2004年,Vol.104,No.36,pp.23-28,TM2004-15 引用文献2.特開2007-28241号公報 引用文献3.米国特許出願公開第2012/0079339号明細書 3 引用文献の記載事項 (1) 引用文献1について ア 引用文献1には、図面とともに、次の記載がある。なお、下線は強調のために当審が付した。 (ア) 24頁左欄24行?右欄3行 「本システムの特徴を以下に挙げる。 (中略) 4) バースト損失に強い インターネットで起きるパケット損失はバースト的なものが多いため、パケット損失への対応としてバースト損失に強いReed-Solomon符号を用いたFEC(Forward Error Correction)を採用した。Reed-Solomon符号は、ブロック符号の1つであり、送信すべき情報を連続した複数のビット単位で(シンボル)で分割し、符号化、復号化を行う誤り訂正符号である。1ブロックはN個のシンボルによって構成され、そのうちK個がデータシンボルであり、N-K個が冗長シンボルである場合、(N,K)の冗長度と呼ぶ。」 (イ) 24頁右欄19?22行 「○2 Gateway1はHost Aから受信したメディアパケットにヘッダを付けて拡張パケットを生成する。また、FECエンコードにより、冗長パケットを生成し拡張パケットとともに送信する。」 (当審注:前記「○2」は、いわゆる丸付き数字の2、すなわち、数字の「2」が丸で囲まれた記号を表す。) (ウ) 24頁右欄31?36行 「現在、本システムはRTP/RTCPを対象に実装を行っている。このとき、メディアパケット(RTP)に併設する制御用パケット(RTCP)はゲートウェイでメディアパケットと同様にヘッダを付加して拡張パケットとして生成されるが、メディアパケットに比べ送信頻度が少ないため冗長パケットを生成しない仕様となっている。」 (エ) 図1  (オ) 25頁左欄1?9行 「2.3. パケットフォーマット (a) ヘッダ構成 ゲートウェイ間での通信に用いられるヘッダの構成を図2に示す。ここでは、ストリームデータの転送プロトコルとしてRTP、ストリームデータの制御プロトコルとしてRTCPを想定している。ゲートウェイ間を通信するパケットにはゲートウェイヘッダが付けられる。ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成される。」 (カ) 25頁左欄12?14行 「本研究では、信頼性を高めるためにReed-Solomon FECを付加機能として実装した。そのため、拡張ヘッダとしてFECヘッダを定義した。」 (キ) 25頁左欄15?16行 「また、ゲートウェイで基本ヘッダが付加されたものを拡張パケットと呼ぶ。」 (ク) 25頁左欄20?25行 「図2の例のようにRTPパケットの場合は、FECにより信頼性を高めるため、基本ヘッダとともに拡張ヘッダのFECヘッダ(12byte)を付けることで拡張パケットとなる。一方、RTCPパケットは基本ヘッダのみを付けることで拡張パケットとなる。」 (ケ) 図2  (コ) 表1  (サ) 表2  (シ) 26頁右欄1?22行 「3.4. システムのオーバーヘッド 本システムではパケットのゲートウェイ中継時に、拡張ヘッダや冗長パケット分の帯域増加と遅延が生じる。本節では、本システム使用時の帯域増加率とFEC処理による遅延時間を測定した。 3.4.1. 帯域増加率 ゲートウェイ間の通信は、冗長パケットのサイズ(最大ペイロードサイズ)と拡張パケットのヘッダのサイズ分帯域が増加する。帯域の増加率Bは(1)式により算出した。mpsが最大ペイロードサイズ、extは拡張パケットのサイズ(20byte)、(n,k)は冗長度でkは1ブロック内のメディアパケット数、xは受信したパケットのサイズである。最大ペイロードサイズは1ブロック内の最大ペイロードサイズで、このサイズでReed-Solomonエンコードの演算処理を行う。(中略) 今回の測定では、圧縮方式がmjpegを使用し、ペイロードは固定長で1328byteである。これより(1)式のx及びmpsは1328であり、Bと実測値は同じになる。」 (当審注:上記の「extは拡張パケットのサイズ(20byte)」との記載は、「extは拡張パケットのヘッダのサイズ(20byte)」の誤記と認める。) (ス) 26頁右欄(1)式  イ(ア)a 前記ア(イ)によれば、引用文献1に記載されたGateway1の動作は、メディアパケットにヘッダを付けて拡張パケットを生成する段階と、FECエンコードにより、冗長パケットを生成する段階を含む。 b 前記ア(ウ)によれば、メディアパケットはRTPパケットであり、前記ア(ク)によれば、RTPパケットの場合は、基本ヘッダ(8byte)とともに拡張ヘッダのFECヘッダ(12byte)を付けることで拡張パケット(以下、このパケットを「RTP拡張パケット」という。)となり、そして、前記ア(オ)によれば、ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成されるのだから、前記aの「メディアパケットにヘッダを付けて拡張パケットを生成する段階」は「メディアパケット(RTP)に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階」だといえる。 c 前記ア(ア)、(シ)及び(ス)によれば、引用文献1に記載されたGateway1は、シンボル長を最大ペイロードサイズとして冗長度を(n,k)としたReed-Solomon符号により、k個のメディアパケットを1ブロックとしてFECエンコードして、n-k個の冗長パケットのペイロードを生成すると認められる。 d 前記ア(オ)によれば、ゲートウェイ間を通信するパケットにはゲートウェイヘッダが付けられ、ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成される。そして冗長パケットは、明らかにゲートウェイ間を通信するパケットである。加えて、前記ア(コ)の表1によれば、基本ヘッダにはペイロードタイプを格納するフィールドが存在し、ペイロードタイプの値が44ならば冗長パケットを表すから、冗長パケットのゲートウェイヘッダには基本ヘッダが含まれる。さらに、前記ア(カ)によれば、拡張ヘッダはReed-Solomon FECを付加機能として実装したために定義されたのだから、Reed-Solomon符号を用いたFECエンコードにより得られる冗長パケットのゲートウェイヘッダには拡張ヘッダが含まれる。このことは、RTCPが冗長パケットを生成しないこと(前記ア(ウ))から、冗長パケットがRTPで伝送されると推認されること、及び、図1においてRedundant packet(冗長パケットのことと認める)にData packetと同様のヘッダが付されていることとも整合する。そうすると、前記cにおける冗長パケットのペイロードに、基本ヘッダ及び拡張ヘッダが付されることによって、冗長パケットが生成されると認められるから、前記aの「FECエンコードにより、冗長パケットを生成する段階」は、「k個のメディアパケット(RTP)を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階」と「n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階」との2つの段階を含んでいると認められる。 e 前記b及びdを総合すると、引用文献1にはGateway1の動作として、「メディアパケット(RTP)に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階と;k個のメディアパケット(RTP)を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階と;n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階とを含む」ことが開示されている。 (イ) 前記ア(イ)によれば、引用文献1に記載されたGateway1の動作は、冗長パケットを拡張パケットとともに送信する段階を含む。 前記ア(イ)の拡張パケットは、前記(ア)bのとおり、メディアパケットに基本ヘッダ及び拡張ヘッダを付けたRTP拡張パケットである。他方、前記ア(キ)によれば、ゲートウェイで基本ヘッダが付加されたものを「拡張パケット」と称しているが、冗長パケットも基本ヘッダが付与されているので、前記ア(キ)の拡張パケットはRTP拡張パケットとは異なっていることが明らかであり、以下、これを「広義の拡張パケット」という。 そして、前記(ア)eのとおり、RTP拡張パケット及び冗長パケットはいずれも基本ヘッダ(及び拡張ヘッダ)を付加されたものであるから、両者とも広義の拡張パケットに含まれる。このことは、ゲートウェイ間を通信するパケットには基本ヘッダと拡張ヘッダが付されること(前記ア(オ))、基本ヘッダのペイロードタイプのフィールドによりメディアパケットと冗長パケットとが区別されること(前記ア(コ)の表1)とも整合する。 そうすると、前記「冗長パケットを拡張パケットとともに送信する段階」は、「冗長パケットを含む広義の拡張パケットを送信する段階」であるといえ、引用文献1は、Gateway1の動作として、前記段階を含むことを開示している。 (ウ) 前記(イ)のとおり、基本ヘッダは広義の拡張パケットのヘッダの一部分を成すものである。そして、基本ヘッダには、シーケンス番号のフィールドに、パケットのシーケンス番号が格納される(前記ア(コ)の表1)。 また、広義の拡張ヘッダの一種である冗長パケットの基本ヘッダには、ペイロードタイプのフィールドに冗長パケットを表す値44が格納され、シーケンス番号のフィールドにパケットのシーケンス番号が格納される(前記ア(コ)の表1)。 そうすると、引用文献1には、「広義の拡張パケットの基本ヘッダーはパケットのシーケンス番号を含む」こと、及び、「冗長パケットの基本ヘッダーは、冗長パケットを示す値44とパケットのシーケンス番号とを含むこと」が開示されている。 (エ) 前記ア(サ) 表2によれば、広義の拡張パケットの拡張ヘッダには、SNベースのフィールドに、Reed-Solomon符号の1ブロック内の最小シーケンス番号が格納される。 前記(ア)cのとおり、Reed-Solomon符号の1ブロックはk個のメディアパケット(RTP)から成るので、前記最小シーケンス番号は、Reed-Solomon符号を用いたFECエンコードの対象となったk個のメディアパケットの最小シーケンス番号である。 そうすると、引用文献1には、「Reed-Solomon符号を用いたFECエンコードの対象となったブロックを構成するk個のメディアパケット(RTP)の最小シーケンス番号が、各々の広義の拡張パケットのヘッダーに含まれる」ことが開示されている。 (オ) 前記(イ)のとおり、引用文献1のGateway1の動作は、冗長パケットをRTP拡張パケットとともに送信する段階を含むのであるから、引用文献1はパケット伝送方法を開示しているといえる。そして、前記(ア)bのとおり、RTP拡張パケットはメディアパケットであるから、前記パケット伝送方法は、メディアデータを送信するための方法に他ならない。 (カ) 前記(ア)?(オ)によれば、引用文献1には、以下の発明(以下、「引用発明」という。)が記載されている。 「メディアデータを送信するための方法であって、 メディアパケット(RTP)に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階と; k個のメディアパケット(RTP)を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階と; n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階と; 冗長パケットを含む広義の拡張パケットを送信する段階と;を含み、 ここで、広義の拡張パケットの基本ヘッダーはパケットのシーケンス番号を含み、 冗長パケットの基本ヘッダーは、冗長パケットを示す値44とパケットのシーケンス番号とを含み、 Reed-Solomon符号を用いたFECエンコードの対象となったブロックを構成するk個のメディアパケット(RTP)の最小シーケンス番号が、各々の広義の拡張パケットのヘッダーに含まれる パケット伝送方法。」 (2) 引用文献2について 引用文献2には、図面とともに、次の記載がある。なお、下線は強調のために当審が付した。 ア 「【0017】 図13は,FECによる損失パケット回復の方法を説明する図である。ここで使用する誤り訂正符号は,k個の値の入力に対して(n-k)個の冗長な値を演算し,合計でn個の値を出力する(n,k)誤り訂正符号である。このような符号の例としては,(n,k)リードソロモン符号,(n,k)ハミング符号,インタリーブした(n,k)パリティ符号,(n,k)LDPC符号などが挙げられる。 イ 「【0021】 FEC符号化演算が終了したら,FEC符号化バッファ402の各行をペイロードとする通信パケットを構成し,通信ネットワーク301へ送出する。図13においては,符号情報のペイロードを格納した通信パケットをメディアパケット,FEC符号を格納した冗長な通信パケットをFECパケットと称している。」 ウ 「【0025】 図14は,RFC2733で規定されるFECパケットのヘッダフォーマットの一部を模式的に表したものである。メディアパケットおよびFECパケットは,RFC3550で規定されるRTPパケットフォーマットに準拠するが,このRTPヘッダに存在するシーケンス番号フィールド(16ビット)に,それぞれのシーケンス番号を付与する。」 エ 図14  図14からは、k個のメディアパケットのヘッダにはMからM+k-1のシーケンス番号が付与され、n-k個のFECパケットのヘッダにはFからF+(n-k-1)のシーケンス番号が付与されることが認められる。 4 対比 本願発明と引用発明とを対比する。 (1) 本願発明と引用発明とは、「メディアデータを送信するための方法」及び「パケット伝送方法」である点で一致する。 (2) 引用発明の「メディアパケット(RTP)」は、明らかに本願発明の「伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)」である。 誤り訂正の技術分野において、Reed-Solomon符号が著名な誤り訂正符号であること及びFEC(Forward Error Correction)が前方エラー訂正を意味することに鑑みると、引用発明における「Reed-Solomon符号を用いてFECエンコード」することは、本願発明における「順方向エラー訂正(FEC)符号化」することに相当する。 引用発明において「k個のメディアパケット(RTP)を1ブロックとしてReed-Solomon符号を用いてFECエンコードして」生成される「冗長パケットのペイロード」は、メディアパケット(RTP)の誤り訂正のためのシンボルであることが明らかであり、本願発明の「リペアシンボル」に相当する。そうすると、本願発明と引用発明とは、「伝送する少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を順方向エラー訂正(FEC)符号化し、リペアシンボルを生成する段階」を含む点で一致する。 (3) 引用発明の「冗長パケット」は、「冗長パケットのペイロード」に基本ヘッダ及び拡張ヘッダを付して生成されるものであるから、「冗長パケットのペイロード」を利用して生成されるものである。そうすると、本願発明と引用発明とは「前記リペアシンボルを利用してリペアパケットを生成する段階」を含む点で一致する。 (4) 引用発明の「RTP拡張パケット」は、「メディアパケット(RTP)」にゲートウェイヘッダを付加することにより生成される点で、「メディアパケット(RTP)を利用して生成される」といえる。 また、引用発明の「冗長パケット」は、前記(2)のとおり、「メディアパケット(RTP)」をReed-Solomon符号を用いてFECエンコードして生成されたペイロードにヘッダを付加して生成される点で、「メディアパケット(RTP)を利用して生成される」といえる。 そして、「広義の拡張パケット」は、前記3(1)イ(イ)に示したとおり「RTP拡張パケット」及び「冗長パケット」含むものであるから、本願発明の「FECパケット」に相当する。 そうすると、引用発明の「広義の拡張パケット」に含まれる「RTP拡張パケット」及び「冗長パケット」はいずれも「メディアパケット(RTP)を利用して生成される」といえるから、本願発明と引用発明とは、「前記少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を利用してFECパケットを生成する段階」を含む点で一致する。 (5) 引用発明の「冗長パケットを含む広義の拡張パケットを送信する段階」は、本願発明の「前記リペアパケットを含む前記FECパケットを送信する段階」に相当する。 (6) パケット通信の技術常識に鑑みると、パケットに付されるシーケンス番号は、順次に増加する番号である。そうすると、引用発明の「パケットのシーケンス番号」は本願発明の「順次に増加するシーケンス番号」に相当し、本願発明と引用発明とは「FECパケットヘッダーは、順次に増加するシーケンス番号を含」む点で一致する。 (7) 引用発明の「冗長パケットを示す値44」は、明らかに本願発明の「リペアパケットを示す識別子」である。 シーケンス番号は連続的な番号のことであるから、本願発明と引用発明とは、「前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子とパケットのための連続的なシーケンス番号を含」む点で共通する。 (8) 引用発明の「広義の拡張パケット」のヘッダーに含まれる「最小シーケンス番号」は、FECエンコードの対象となったブロックを構成するk個のメディアパケット(RTP)の最小番号である。そうすると、前記「最小シーケンス番号」は、FECエンコードを行う対象となるブロックの最初のメディアパケットのシーケンス番号であるから「初期シーケンス番号」であって、対応するFECブロックの境界を表す情報だといえる。よって、本願発明と引用発明とは、「対応するFECブロックの初期シーケンス番号は、FECブロック境界情報として各パケットのヘッダーに含まれ」る点で一致する。 (9) 請求人が令和元年9月24日提出の意見書で『「FECの境界」と「FECブロック境界」とは同一の意味であり、「FECの境界に関する情報」と「FECブロック境界情報」とは同一の意味であるものと思料致します。』(1頁下から8行目?下から6行目)と主張する以上、本願発明の「前記FECパケットはFECの境界に関する情報を含む」との発明特定事項は、「前記FECパケットはFECブロック境界情報を含む」の意味であると解すべきである。 そうすると、本願発明と引用発明とが前記(8)のとおり「対応するFECブロックの初期シーケンス番号は、FECブロック境界情報として各パケットのヘッダーに含まれ」る点で一致する以上、本願発明と引用発明とが「前記FECパケットはFECの境界に関する情報を含む」点で一致することは明らかである。 (10) 前記(1)?(9)によれば、本願発明と引用発明との一致点及び相違点は以下のとおりである。 〈一致点〉 「メディアデータを送信するための方法において、 伝送する少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を順方向エラー訂正(FEC)符号化し、リペアシンボルを生成する段階と; 前記少なくとも1つの伝送パケット(ｔｒanｓｐｏｒｔ ｐackeｔ)を利用してFECパケットを生成する段階と; 前記リペアシンボルを利用してリペアパケットを生成する段階と; 前記リペアパケットを含む前記FECパケットを送信する段階と;を含み、 ここで、FECパケットヘッダーは、順次に増加するシーケンス番号を含み、 前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子とパケットのための連続的なシーケンス番号を含み、 対応するFECブロックの初期シーケンス番号は、FECブロック境界情報として各パケットのヘッダーに含まれ、 前記FECパケットはFECの境界に関する情報を含む ことを特徴とするパケット伝送方法。」である点。 〈相違点〉 本願発明のリペアパケットのヘッダーに含まれる「連続的なシーケンス番号」は、「リペアパケットのための」ものであるのに対し、引用発明の冗長パケットの基本ヘッダーに含まれる「シーケンス番号」は、冗長パケットのためのものであるのか否かが明らかではない点。 5 判断 前記相違点について検討する。 FEC符号化において、メディアパケット、冗長パケットにそれぞれシーケンス番号を付与すること、すなわち、冗長パケットに冗長パケット用のシーケンス番号を付与することは周知技術である(前記3(2))。 前記周知技術は、パケットに対してFEC符号化を行ってFECパケットを生成する技術であるから、引用発明における冗長パケットのシーケンス番号として、前記周知技術のように、冗長パケット用のシーケンス番号を用いることは、当業者であれば容易に想到し得ることである。 そして、本願発明の効果は、引用発明の構成及び前記周知技術から当然に奏されるものであり、格別のものではない。 以上のとおりであるから、本願発明は、引用発明及び周知技術に基づいて、容易に発明できたものである。 第4 むすび 以上のとおり、本願発明は、特許法29条2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 別掲 |
|
| 審理終結日 | 2019-10-15 |
| 結審通知日 | 2019-10-21 |
| 審決日 | 2019-11-01 |
| 出願番号 | 特願2015-508859(P2015-508859) |
| 審決分類 |
P
1
8・
121-
WZ
(H04L)
P 1 8・ 562- WZ (H04L) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 谷岡 佳彦 |
| 特許庁審判長 |
吉田 隆之 |
| 特許庁審判官 |
富澤 哲生 丸山 高政 |
| 発明の名称 | 通信システムでパケットを送受信するための装置及び方法 |
| 代理人 | 崔 允辰 |
| 代理人 | 阿部 達彦 |
| 代理人 | 実広 信哉 |
| 代理人 | 木内 敬二 |