【事件の表示】
　特願２００６−５３９３７０「デジタル放送で拡張された識別子を利用した目的受信装置のソフトウェアのアップデート方法」拒絶査定不服審判事件〔平成１７年　５月２６日国際公開、ＷＯ２００５／０４８６０４、平成１９年　６月　７日国内公表、特表２００７−５１５１０２、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　経緯 
　本願は、２００４年１１月４日（パリ条約による優先権主張外国庁受理２００３年１１月１７日、米国、２００４年１月９日、大韓民国）を国際出願日とする出願であって、手続の概要は以下のとおりである。
　　
　拒絶理由通知　：平成２１年　７月１４日（起案日）
　手続補正書　　：平成２１年１０月２１日
　拒絶査定　　　：平成２１年１１月１１日（起案日）
　審判請求書　　：平成２２年　３月１７日
　手続補正書　　：平成２２年　３月１７日
　　
第２　平成２２年３月１７日付けの手続補正について
　平成２２年３月１７日付けの手続補正は、適法である。
　理由は、以下のとおりである。
　　
［理由］
１　補正の目的
　平成２２年３月１７日付けの手続補正（以下「本件補正」という。）は、請求項１〜１０についてする補正である。
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてするものであり、特許請求の範囲の減縮を目的とするものと認められる。
　　
２　独立特許要件
　本件補正は特許請求の範囲の減縮を目的としているので、本件補正後における発明が特許出願の際独立して特許を受けることができるか否かを、以下に検討する。
　
（１）補正後発明１
ア　補正後発明１
　補正後の請求項１に係る発明（以下「補正後発明１」という。）は、補正後の特許請求の範囲の請求項１に記載された以下のとおりのものである。
　　
「ソフトウェアのアップデートの目的受信装置の拡張された識別子と拡張されたソフトウェアバージョンとを含む情報をブロードキャストするデータサービス報知を利用して、前記ソフトウェアのアップデートを予告するステップと、
　前記予告に応じて、前記拡張された識別子を持つ受信装置が前記ソフトウェアのアップデートを要求するステップと、
　前記要求に応じて、前記拡張された識別子を持つ受信装置に前記ソフトウェアを伝送するステップと、を含む拡張された識別子を利用したデジタル放送受信装置のソフトウェアのアップデート方法。」
　　
　ここで、補正後発明１の「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」がどのような「識別子」、「ソフトウエアバージョン」であるか検討する。
　発明の詳細な説明には、次の記載がある。
　　
〈技術分野〉
「【０００１】
　本発明は、デジタル放送で受信装置のソフトウェアのアップグレード方法に係り、より詳細には、受信装置のうちソフトウェアのアップデート対象となる受信装置を区別したソフトウェアのアップデート方法に関する。」
　　
〈背景技術〉
「【００１０】
　現在のＡＴＳＣデータ放送を通じて、受信装置の製造企業は特定のモデルの受信装置のソフトウェアをアップデートできるが、総１６ビットのモデルフィールドのみでは、多くの受信装置の製造企業の多くのモデルの受信装置をいちいち区別するには足りない。また同じモデルの受信装置であっても、受信装置に搭載されたソフトウェアのバージョンは時期別に若干ずつ異なる。また、ソフトウェアのバージョンを区別するための１６ビットのバージョンフィールドだけでは、ソフトウェアのバージョンを細部的に区別し難い。」
　　
〈発明が解決しようとする課題〉
「【００１１】
　本発明は、前述した問題点に鑑みてなされたものであり、本発明は、デジタル放送受信装置を区別できる拡張されたモデルフィールドと、アップデートのためのソフトウェアのバージョンをさらに細部的に区別可能にする拡張されたバージョンフィールドとを定義し、拡張されたモデルフィールド及びバージョンフィールドを利用して、アップデート対象となる受信装置を区別してソフトウェアのアップデートサービス方法を提供することをその技術的課題とする。」
　　
〈発明を実施するための最良の形態〉
「【００２０】
　図４は、ＡＴＳＣデータブロードキャスト標準（Ａ／９０）のＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄａｎｄ Ｃｏｎｔｒｏｌ）の互換性叙述子（Ｃｏｍｐａｔｉｂｉｌｉｔｙ Ｄｅｓｃｒｉｐｔｏｒ）の構文を示す表である。図４でｕｉｍｓｂｆは、ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔ ｆｉｒｓｔの略字である。
　【００２１】
　互換性叙述子でｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、１６ビットを持つフィールドであって、ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈを表す長さを除外したｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドを含む叙述子の総長さを示す。ｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは、１６ビットフィールドであって、叙述子の数を特定する。ｄｅｓｃｒｉｐｔｏｒＴｙｐｅは、８ビットフィールドであって、ハードウェアまたはソフトウェアのタイプを区別するところに使われる。ｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは８ビットフィールドであって、ｄｅｓｃｒｉｐｔｏｒＴｙｐｅ及びｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈを除外した総長さを示すフィールドである。
　【００２２】
　ｓｐｅｃｉｆｉｅｒＴｙｐｅは、８ビットフィールドであって、ｓｐｅｃｉｆｉｅｒＤａｔａフィールドのフォーマットを区別するところに使われるフィールドである。ｓｐｅｃｉｆｉｅｒＤａｔａは、２４ビットフィールドであって、一つの組織を唯一に識別する。このフィールドに割り当てられた値は、ｓｐｅｃｉｆｉｅｒＴｙｐｅフィールドに従属的である。
　【００２３】
　ｍｏｄｅｌは、１６ビットフィールドであって、組織により定義された多様なモデル間を区別するために使われるが、本発明の実施形態は、ｍｏｄｅｌフィールドを拡張して１２８ビットのＵＵＩＤを使用するが、これについては後述する。ｖｅｒｓｉｏｎは、１６ビットフィールドであって、組織により定義されたモデルの他のバージョン間を区別するために使われる。本発明の実施形態は、ｖｅｒｓｉｏｎフィールドを拡張してバージョンを細分化して区別可能にするが、これについては後述する。
　【００２４】
　ｓｕｂＤｅｓｃｒｉｐｔｏｒＣｏｕｎｔは８ビットフィールドであって、ｓｕｂＤｅｓｃｒｉｐｔｏｒの数を代表するフィールドである。
　【００２５】
　本発明の実施形態で（１）ｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは、２個の叙述子を持つということを表示するように０×０００２値を持つ。（２）ｄｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドは、システムハードウェアを示すように０×０１値を持つ。（３）ｓｐｅｃｉｆｉｅｒＴｙｐｅフィールドは、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）ＯＵＩを意味するように０×０１値を持つ。（４）ｓｐｅｃｉｆｉｅｒＤａｔａフィールドの最初の叙述子は、ＩＥＥＥがソフトウェアのアップデートが意図される端末装置の製造企業のために割り当てられた唯一の値を持っていなければならない。
　【００２６】
　（５）０×００００及び０×ＦＦＦＦの場合を除いては、最初の叙述子のｍｏｄｅｌ及びｖｅｒｓｉｏｎフィールドは端末装置の製造企業により定義されるねばならないが、これはソフトウェアのアップデートに使われる。（６）最初の叙述子のｍｏｄｅｌフィールドの値が０×００００ならば、本発明の実施形態によるｅｘｔｅｎｄｅｄＭｏｄｅｌＳｕｂＤｅｓｃｒｉｐｔｏｒは、図５のように定義されて叙述子中になければならない。（７）もし、最初の叙述子のｍｏｄｅｌフィールド値が０×ＦＦＦＦならば、特定製造企業のあらゆるモデルにソフトウェアのアップデートが適用される。（８）最初の叙述子のｖｅｒｓｉｏｎフィールド値が０×００００ならば、本発明の実施形態によるｅｘｔｅｎｄｅｄＶｅｒｓｉｏｎＳｕｂＤｅｓｃｒｉｐｔｏｒは、図６のように定義されて叙述子中になければならない。（９）もし、最初の叙述子のｖｅｒｓｉｏｎフィールド値が０×ＦＦＦＦならば、特定製造企業により特定されたモデルのあらゆるバージョンにソフトウェアのアップデートが適用される。
　【００２７】
　（１０）最初の叙述子のｓｕｂＤｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは２より大きいことがあるが、そうした場合に端末装置は、ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドが０×０１や０×０２に特定されていないいかなる副叙述子も無視する。（１１）２番目の叙述子のｄｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドは０×０２値を持つが、これはシステムソフトウェアであることを表す。（１２）前記（３）から（１０）の限定は、端末装置のハードウェアよりはアップデートされるソフトウェアコンポーネントを特定するのに使われる製造企業とモデル及びバージョンを除いては２番目の叙述子に適用される。
　【００２８】
　図５は、本発明の実施形態による拡張されたモデル副叙述子（Ｅｘｔｅｎｄｅｄ Ｍｏｄｅｌ Ｓｕｂ−Ｄｅｓｃｒｉｐｔｏｒ）の構文を示す表である。
　拡張されたモデル副叙述子は、ハードウェアまたはソフトウェアモデルを特定するために製造企業により割り当てられたＵＵＩＤを使用する。本発明の実施形態は、ＵＵＩＤを使用することによって、ＤＳＭ−ＣＣ互換叙述子の１６ビットモデルフィールドよりハードウェアまたはソフトウェアを区別するためのはるかに大きい空間を持つことができる。
　【００２９】
　ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅは、副叙述子のタイプを示す値である。本副叙述子のタイプを表す値は０×０１を持つ。ｓｕｂＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本フィールド後の副叙述子中にあるバイトの数を表す値である。このフィールド値は０×１０を持つ。ｕｕｉｄ（）は製造企業が決定したＵＵＩＤを特定するフィールドであるが、ＵＵＩＤは、ハードウェアまたはソフトウェアモデルを唯一に識別させる。
　【００３０】
　図６は、本発明の実施形態による拡張されたバージョン副叙述子の構文を示す表である。
　拡張されたバージョン副叙述子は、ハードウェアまたはソフトウェアバージョンを特定するのに使われるが、製造企業が割り当てた主バージョン、副バージョン、及びマイクロバージョン数字を持つ。本発明の実施形態による拡張されたバージョン副叙述子は、ハードウェア装置バージョンまたはソフトウェアコンポーネントバージョンを識別するためのさらに拡張性のあるメカニズムを提供する。
　【００３１】
　ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅは、副叙述子のタイプを示すフィールドである。本副叙述子のタイプを示す値は０×０２である。ｓｕｂＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本副叙述子による副叙述子中のバイト数を示すフィールドである。ｍａｊｏｒは、製造企業により決定された主バージョン数を特定する。ｍｉｎｏｒは副バージョン数を特定し、ｍｉｃｒｏはマイクロバージョン数を特定する。各バージョンで０×ＦＦＦＦ値を持つ場合には、各バージョンのあらゆるバージョンを表すのに使用する。
　【００３２】
　図７は、本発明の実施形態によるソフトウェアのアップデート情報叙述子の構文を示す表である。
　基本的にソフトウェアのアップデートデータサービスは、ＡＴＳＣ−Ａ／９０により定義されたデータサービス報知（Ｄａｔａ Ｓｅｒｖｉｃｅ Ａｎｎｏｕｎｃｅｍｅｎｔ）を使用して知らせる。限定的な内容は図７を参照して説明する。ソフトウェアのアップデート情報叙述子は、ソフトウェアのアップデートデータサービス報知の文脈（ｃｏｎｔｅｘｔ）でソフトウェアのアップデートについての情報を提供するところに使用する。これについての構文を説明する。
　【００３３】
　ｄｅｓｃｒｉｐｔｏｒ Ｔａｇは、叙述子のタイプを表すフィールドであって、このフィールドは８ビットの定数値を持つ。ｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本叙述子でこのフィールドについているバイトの数を表すが、使われるフィールドとして８ビット値を持つ。ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒは、前記図４ないし図６を通じて説明した互換性叙述子を特定するところに使用するフィールドである。」
　　
　以上の記載によれば、補正後の発明は、「デジタル放送で受信装置のソフトウェアのアップグレード方法に係り、より詳細には、受信装置のうちソフトウェアのアップデート対象となる受信装置を区別したソフトウェアのアップデート方法に関する」（段落【０００１】）もので、「現在のＡＴＳＣデータ放送を通じて、受信装置の製造企業は特定のモデルの受信装置のソフトウェアをアップデートできるが、総１６ビットのモデルフィールドのみでは、・・・多くのモデルの受信装置をいちいち区別するには足り」ず、「・・・また、ソフトウェアのバージョンを区別するための１６ビットのバージョンフィールドだけでは、ソフトウェアのバージョンを細部的に区別し難い」（段落【００１０】）という背景もと、「デジタル放送受信装置を区別できる拡張されたモデルフィールドと、アップデートのためのソフトウェアのバージョンをさらに細部的に区別可能にする拡張されたバージョンフィールドとを定義し、拡張されたモデルフィールド及びバージョンフィールドを利用して、アップデート対象となる受信装置を区別してソフトウェアのアップデートサービス方法を提供する」（段落【００１１】）ものである。
　「ソフトウェアのアップデートデータサービスは、ＡＴＳＣ−Ａ／９０により定義されたデータサービス報知を使用して知らせ」（段落【００３２】）、ソフトウェアのアップデート情報叙述子は、「前記図４ないし図６を通じて説明した互換性叙述子を特定するところに使用するフィールド」（段落【００３３】）を有している。
　具体的には、多様なモデル間を区別するために使われる１６ビットのｍｏｄｅｌフィールドが０×０００ならば、ｅｘｔｅｎｄｅｄＭｏｄｅｌＳｕｂＤｅｓｃｒｉｐｔｏｒ（拡張されたモデル副叙述子）を使用する（段落【００２３】、【００２６】、【００２８】）。モデルの他のバージョン間を区別する１６ビットのｖｅｒｓｉｏｎフィールドが０×０００ならば、ｅｘｔｅｎｄｅｄＶｅｒｓｉｏｎＳｕｂＤｅｓｃｒｉｐｔｏｒ（拡張されたバージョン副叙述子）を使用する。
　以上によれば、「目的受信装置の拡張された識別子」は、データサービス報知を使用してブロードキャストされるもので、データサービス報知には、「識別子」が存在し、さらに、「識別子」では区別するのに足りないものを区別するために「識別子」を拡張したものが「目的受信装置の拡張された識別子」であると認められる。また、「拡張されたソフトウェアバージョン」は、データサービス報知を使用してブロードキャストされるもので、データサービス報知には、「ソフトウエアバージョン」が存在し、さらに、「ソフトウエアバージョン」では区別できないものを区別するために「ソフトウエアバージョン」を拡張したものが「拡張されたソフトウェアバージョン」であると認められる。
　　
イ　刊行物に開示された技術
　原査定の拒絶の理由で引用された特開２０００−３５０１８５号公報（以下「刊行物１」という。）には、以下の記載がある。
　　
〈技術分野〉
「　　【０００１】
　　【発明の属する技術分野】
本発明は、デジタル放送受信装置及びデジタル放送送信装置に関し、特に、デジタル放送受信装置において現在制御に用いられている制御プログラムを、デジタル放送送信装置から放送される新しい制御プログラムに書き換える技術に関する。」
　　
〈従来技術〉
「　　【００１７】
　伝送される制御プログラムのデータフォーマットは通常 ＡＲＩＢ（Association of Radio Industries and Businesses）ＳＴＤ−Ｂ１６で規格されるダウンロード制御テーブル（Download Control Table：以下、「ＤＣＴ」と記す）と、ダウンロードテーブル（Download Table：以下、「ＤＬＴ」と記す）とを用いる。勿論、各放送事業者は個別に独自のフォーマットを用いることもできる。また、ＤＣＴとＤＬＴは共にセクション構造のテーブルの一種である。
　　　【００１８】
　図３３は、ＤＣＴのフォーマットを示す図である。
　ＤＣＴには、ＤＣＴのテーブルＩＤ、セクション長、トランスポート・ストリームＩＤ（transport_stream_id）、ダウンロード・パケットＩＤ（DL_PID）、モデル情報長（model_info_length）、及び、モデル情報（model_info）等が含まれる。
　　　【００１９】
　ＤＣＴのテーブルＩＤは“0xC0”である。
　トランスポート・ストリームＩＤは、トランスポート・ストリームの識別子であり、チューナー９０１で受信すべき変調波の周波数を特定する。
　ダウンロード・パケットＩＤは、パケットの識別子であり、ＴＤ９０４で取り出すべきパケットを特定する。
　　　【００２０】
　モデル情報長は、モデル情報の全データ量を、バイト単位で示すデータである。
　モデル情報には、受信装置のメーカーを識別するメーカーＩＤ（maker_id）と、受信装置のモデルを識別するモデルＩＤ（model_id）と、受信装置のソフトバージョンを識別するバージョンＩＤ（version_id）とが含まれる。
　　　【００２１】
　図３４は、ＤＬＴのフォーマットを示す図である。
　ＤＬＴには、ＤＬＴのテーブルＩＤ、セクション長、メーカーＩＤ、モデルＩＤ、バージョンＩＤ、及び、コード・データ・バイト（code_data_byte）等が含まれる。なお、ＤＬＴにおいて、先頭のテーブルＩＤからモデル情報フィールドの直前までの部分をセクションヘッダと呼ぶ。
　　　【００２２】
　ＤＬＴのテーブルＩＤは“0xC1”である。
　セクション長は、常に“0x89C”である。
　メーカーＩＤ、モデルＩＤ、及び、バージョンＩＤについては、ＤＣＴと同様である。
　コード・データ・バイトは、ソフトウェア本体を表し、そのデータ量は８ビット×２０４８（２Ｋバイト）である。
　　　【００２３】
　ＤＣＴとＤＬＴについては、「ＣＳデジタル放送用標準共用受信機、標準規格、ＡＲＩＢ　ＳＴＡＮＤＡＲＤ、ＡＲＩＢ　ＳＴＤ−Ｂ１６　１．０版（社団法人　電波産業会）：ｐ１２〜１６」に詳しい記載がある。
　ＤＣＴは、デジタル放送受信装置で受信される全ての変調波に多重されている。
　　　【００２４】
　上記デジタル放送受信装置は、何れかの変調波を受信し、フラッシュメモリ９０９に記憶しているダウンロードプログラムを常に実行するＣＰＵ９０８の制御によって、ＴＤ９０４に受信した変調波に多重されたＤＣＴのフィルタリングを行なわせる。続いて、フィルタリングしたＤＣＴを、一旦ＤＲＡＭ９１０に格納させ、ＣＰＵ９０８が、メーカーＩＤ、モデルＩＤ、及び、バージョンＩＤに基づいて、適合するＤＬＴが存在するか否かを判断する。
　　　【００２５】
　ＣＰＵ９０８が適合するＤＬＴが存在すると判断すると、制御プログラムを変更できる事を利用者に伝えるためのメッセージを、ＣＰＵ９０８が画面合成装置９１２を制御してモニタ９１５に表示させる。
　図３５は、従来の制御プログラム書き換え方法のフローチャートを示す図である。」
　　
　以上の記載から、従来技術における「モデルＩＤ」、「バージョンＩＤ」は、拡張されたものではなく、補正後発明の「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」ではない。
　　
　実施の形態１は、段落【００４３】〜【０１５７】に記載されており、
「本発明の実施の形態１は、受信側の制御プログラムの大半が制御プログラム更新の際には使用されていないことに注目し、送信側で、制御プログラムをダウンロード処理用プログラムと非ダウンロード処理用プログラムとに区別して送信し、受信側で、メモリ中の非ダウンロード処理用プログラムを格納している領域をダウンロード処理用プログラム用のワークエリアとして用いることにより、制御プログラム更新機能の追加によるメモリの記憶容量の増加を抑えるもの」（＜概要＞、段落【００４３】）であり、
　段落【０１０６】〜【０１１１】及び図１１に、ダウンロード開始処理の手順が記載されている。該記載のＤＣＴにおける「モデルＩＤ」、「バージョンＩＤ」及びＤＬＴにおける「モデルＩＤ」、「バージョンＩＤ」は、拡張されたものではなく、補正後発明の「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」ではない。
　　
　段落【００５７】には、
「“new_version”はダウンロード後に更新すべきソフトウェアのバージョンを指定する。ダウンロード後にプログラム受信装置のソフトウェアのバージョンがこの“new_version”に更新される。
　“exmodel_id”は、ＤＬＴのモデルＩＤの拡張の為のものであり、ダウンロードの対象となるモデルを限定する。プログラム受信装置の拡張モデルＩＤとこの“exmodel_id”とが一致した場合にのみ、このＤＬＴがダウンロードの対象であるとプログラム受信装置により判断される。」
と記載されている。上記「“exmodel_id”は、ＤＬＴのモデルＩＤの拡張の為のものであり」の記載は、「拡張の為」と記載されているものの、データサービス報知に「モデルＩＤ」が存在するものではなく、さらに、「モデルＩＤ」では区別するのに足りないものを区別するために「モデルＩＤ」を拡張したものであると認められない。
　したがって、「“exmodel_id”」は、補正後発明１の「目的受信装置の拡張された識別子」ではない。
　また、段落【００５７】におけるソフトウエアのバージョンは、拡張されたものではない。
　　
　段落【０１５７】〜【０２０３】には、実施の形態２〜５が記載されているが、「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」は開示されていない。
　　
　以上のとおり、刊行物１には、「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」は開示されていない。
　　
　原査定の拒絶の理由で引用された
　　特開２００２−１９１０３９号公報（以下「刊行物２」という。）、
　　特開２００３−２１６３７５号公報（以下「刊行物３」という。）、
　　特開２００３−２２３３８７号公報（以下「刊行物４」という。）
にも、「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」は開示されていない。
　　
ウ　判断
　上記イのとおり、刊行物１〜４には、「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」は開示されていない。
　そうすると、補正後発明１は、刊行物１〜４に記載された発明に基づいて当業者が容易に発明できたものとはいえない。
　他に補正後発明１が特許出願の際独立して特許を受けることができるものではない理由を発見しない。
　　
（２）補正後発明２〜８
　補正後の請求項２〜８に係る発明（以下各発明を請求項の番号を用いて「補正後発明２」等という。）は、補正後発明１を直接又は間接的に引用しているので、補正後発明１と同じ理由で、補正後発明２〜８が特許出願の際独立して特許を受けることができるものではない理由を発見しない。
　　
（３）補正後発明９、１０
　補正後の請求項９は独立請求項であり、補正後の請求項９に係る発明（以下「補正後発明９」という。）は、補正後発明１と同様に「目的受信装置の拡張された識別子」、「拡張されたソフトウェアバージョン」との事項を有している。
　したがって、補正後発明１と同じ理由で、補正後発明９が特許出願の際独立して特許を受けることができるものではない理由を発見しない。
　また、補正後の請求項１０に係る発明は、補正後発明９を引用しているので、補正後発明９と同じ理由で、補正後の請求項１０に係る発明が特許出願の際独立して特許を受けることができるものではない理由を発見しない。
　　
第３　本願発明について 
　平成２２年３月１７日付けの手続補正は、上記第２のとおり適法である。
　本願の請求項１〜１０に係る発明は、平成２２年３月１７日付け手続補正により補正された明細書、特許請求の範囲及び図面の記載からみて、その特許請求の範囲の請求項１〜１０に記載した事項により特定されるとおりのものであると認める。 
　そして、本願については、原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。