【事件の表示】
　特願２００３−２７８４６０「受信装置、及び受信方法」拒絶査定不服審判事件〔平成１７年　２月１７日出願公開、特開２００５−　４５６１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１５年７月２３日の出願であって、平成１６年８月２６日に手続補正がなされ、平成１８年１１月２８日付けで拒絶理由が通知され、平成１９年２月５日に意見書が提出されると共に手続補正がなされたが、同年８月１日付けで拒絶査定がなされた。これに対し、同年９月６日に審判請求がなされ、同年１０月９日に手続補正がなされ、平成２０年７月３０日に審査官より前置報告がなされ、平成２１年８月４日付けで当審より審尋がなされ、同年１０月２日に回答書が提出されたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成１９年１０月９日付けの手続補正を却下する。
　
［理由］
１．本願発明と本件補正後発明
　平成１９年１０月９日付けの手続補正（以下、「本件補正」という。）は、平成１９年２月５日付けの手続補正により補正された特許請求の範囲の請求項２に記載された発明
「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、
　ストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、
　上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順と、
　上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順と、
　を備えることを特徴とする受信方法。」（以下、「本願発明」という。）を、
「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、
　上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、
　上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順と、
　上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順と、
　を備えることを特徴とする受信方法。」（以下、「本件補正後発明」という。）
に補正することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、当該補正前の発明（本願発明）の「認証要求手順」に係る「ストリームデータ」を「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信される」ものに限定して特許請求の範囲を減縮するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び、第４項第２号（補正の目的）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記本件補正後発明が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。
　
（１）本件補正後発明
　上記「１．本願発明と本件補正後発明」の項で認定したとおりである。
　
（２）引用発明
　原審の拒絶理由に引用された特開２００１−３２６６５１号公報（以下、「引用文献１」という）には、図面と共に以下の事項が記載されている。
　
（ア）「【００２０】
【発明の実施の形態】以下、図面を参照しながら発明の実施の形態を説明する。
【００２１】（第１の実施形態）図１に、本実施形態のＡＶデータ転送システムの構成例を示す。
【００２２】図１に示されるように、ソース機器（無線端末または無線インタフェースを有する装置）１０１と、シンク機器（無線端末または無線インタフェースを有する装置）１０３が、無線ネットワーク１０６に接続されている。無線ネットワーク１０６としては、Ｂｌｕｅｔｏｏｔｈを仮定して説明する。Ｂｌｕｅｔｏｏｔｈは、低コスト、低消費電力などを特徴とする無線ＬＡＮの一種である（例えば、ｈｔｔｐ：／／ｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍにて取得可能に開示されている文書に説明が詳しい）。なお、ソース機器１０１のノードＩＤ＝［Ａ］、シンク機器１０３のノードＩＤ＝［Ｂ］であるものとする。
【００２３】ソース機器とは、ＡＶデータの送信元すなわちソースとなる機器（例えばＶＴＲ（ビデオテープレコーダ））のことを意味し、シンク機器とは、ＡＶデータの受信先すなわちシンクとなる機器（例えばディスプレイ）のことを意味する。ここで、ＡＶデータ（もしくはＡＶストリーム）は、映像や音声がこれに該当するが、映像や音声にそれら以外のデータが含まれている場合もある。
【００２４】本実施形態では、ソース機器とシンク機器との間でやり取りされる（すなわち、ソース機器が送信し、シンク機器が受信する）ＡＶデータは、著作権保護がかけられるべきデータであるとする。著作権保護のためには、ＡＶデータを暗号化した状態で送受信する（すなわち、ソース機器側で暗号化し、シンク機器側で復号化する）ものとする。このため、ソース機器とシンク機器との間では、ＡＶデータのやり取りに先立って認証鍵交換手順が行われることになる。」
　
（イ）「【００３０】次に、ソース機器１０１とシンク機器１０３との間のシーケンスの初期手順について説明する。
【００３１】図４および図５（図５は図４の続きである）に、ソース機器１０１とシンク機器１０３との間のシーケンスの初期手順例を示す。
【００３２】ここで、本実施形態においては、ソース機器１０１とシンク機器１０３との間でやり取りされるＡＶデータごと、つまりＡＶデータが転送されるＢｌｕｅｔｏｏｔｈのチャネルごとに異なる暗号鍵が与えられている場合について説明する。また、本実施形態では、シンク機器１０３の側がコントローラとなり、ソース機器１０１を制御する場合を考える。
【００３３】まず、ソース機器１０１とシンク機器１０３は、互いにＬ２ＣＡＰのコネクト要求とコネクト応答のやり取りを行う（Ｓ４１）。本実施形態のＢｌｕｅｔｏｏｔｈにおいては、Ｂｌｕｅｔｏｏｔｈ上のＡＶデータのやり取りを行うためのチャネル設定や制御情報の交換を行うプロトコルが存在する（ここでは、このプロトコルをストリームプロトコルと呼ぶ；またＳＰはストリームプロトコルの略である）。
【００３４】このコネクト要求／応答は、このＳＰを行うためのチャネルを確立するためのやり取りである。このやり取りを通して、ソース機器１０１側はチャネルＡ０（以下、ＣＨ−Ａ０と表記する）を、シンク機器１０３側はチャネルＢ０（以下、ＣＨ−Ｂ０と表記する）を確保する（Ｓ４２，Ｓ４３）。」
　
（ウ）【００３６】次に、この確立されたチャネルを用いて、ストリームプロトコルのやり取りが行われる。まず、シンク機器１０３は、何らかの方法（例えば、コントロールプロトコルのＵＮＩＴコマンドで問い合わせることによって、あるいはユーザが入力することによって）でソース機器１０１側がＶＴＲであることを認識しているとする。このとき「ソース機器はどのような構成を持ったＶＴＲであるか」を知るためのコマンドがＳＵＢＵＮＩＴ ＩＮＦＯコマンドである。このコマンドを通して、シンク機器１０３は、ソース機器１０１に対して、ソース機器１０１のＶＴＲサブユニットがどのような構成をしているかについて問い合わせることが可能である（Ｓ４６）。なお、サブユニットとは、ＩＥＥＥ１３９４やＢｌｕｅｔｏｏｔｈ等のＡＶ機器で、ある機器内の機能を構成要素として論理的に記述する際に用いられる概念である（その詳細は１３９４ＡＶ／Ｃスペックに開示されている）。」
　
（エ）「【００３９】次に、ソース機器１０１とシンク機器１０３は、Ｌ２ＣＡＰのコネクト要求／コネクト応答のやり取りを、ＡＶデータの転送のためのプロトコル（ここでは、このプロトコルをトランスポートプロトコルと呼ぶ；またＴＰはトランスポートプロトコルの略である）がチャネルを確立するために行う。ここではＭＰＥＧ４ビデオとＡＡＣオーディオの２チャネル分確保（ＣＨ−Ａ１／ＣＨ−Ｂ１及びＣＨ−Ａ２／ＣＨ−Ｂ２）する（Ｓ４８〜Ｓ５３）。
【００４０】次に、これらの確保したＢｌｕｅｔｏｏｔｈチャネルを、対象となる出力プラグに接続するための手順を行う。これも、ＳＰの一部分であるため、ＳＰのコマンドの一つであるＳＰコネクトコマンドが用いられる（Ｓ５４，Ｓ５５）。ここでは、「ＣＨ−Ａ１はＶＴＲサブユニットの出力プラグ１に繋ぎなさい」という意味のメッセージや「ＣＨ−Ａ２はＶＴＲサブユニットの出力プラグ２に繋ぎなさい」という意味のメッセージがソース機器１０１側に届く。ソース機器１０１は、この指示に従う（図７に記述したＬ２ＣＡＰチャネルと出力プラグの対応関係のように接続される）。
【００４１】ここで、このＳＰコネクトコマンドには、相手側（この例の場合、ソース機器１０１）側のチャネルとサブユニット／プラグの対応関係の情報の他に、このコマンドの送信側（この例の場合、シンク機器１０３）のチャネルとサブユニット／プラグの対応関係の情報も記載してあってもよい。このようにすることで、相手側機器（この例の場合、ソース機器１０１）に対して、コマンドの送信側のチャネルとサブユニット／プラグの対応関係を明に通知することが可能となる。これによって、例えば、相手側機器が、自機器のどのサブユニットやプラグに対して認証鍵交換等の手続を行うべきかについての情報を相手側機器に対して通知することが可能となる。」
　
（オ）「【００５０】次に、ソース機器１０１とシンク機器１０３との間のシーケンス初期手順以降の手順について説明する。
【００５１】続いて、シンク機器１０３は、ＤＴＣＰの方式に従って、ソース機器１０１に対して著作権保護のための認証鍵交換の手続をはじめる。この認証鍵交換の方式としては、いくつかの方法が考えられる。
【００５２】＜第１の方法＞図１１に、第１の方法の場合のシーケンスの一例を示す。
【００５３】第１の方法は、認証鍵交換の際に、ソース機器１０１側／シンク機器１０３側双方の、Ｂｌｕｅｔｏｏｔｈチャネルに関する情報、またはサブユニットとプラグに関する情報（図１０のような対応テーブルを参照することによって、どちらの情報からも同様の情報を入手することが可能であるため、どちらでもよい）を添付させる方法である。このようにすることにより、ソース機器１０１は、この認証鍵交換についての要求（チャレンジ）が、どのチャネルに対するものであるかを認識することが可能である。この双方のＢｌｕｅｔｏｏｔｈチャネルに関する情報または双方のサブユニットとプラグに関する情報は、図１１のように、ＤＴＣＰの認証鍵交換のやり取りに添付される。
【００５４】この場合の認証鍵交換は以下のようになる。
【００５５】まず、シンク機器１０３からソース機器１０１へ、チャレンジ変数Ｂｎと証明書Ｂｃｅｒｔを送付する（Ｓ１１１）。なお、それらの情報に、チャネル情報、またはサブユニット／プラグ情報が添付される。この点は、図１１に示すように、以下の手順でも同様である。
【００５６】次に、ソース機器１０１からシンク機器１０３へのチャレンジ変数Ａｎと証明書Ａｃｅｒｔの送付を行い（Ｓ１１２）、これらを元に認証を行う。
【００５７】次に、シンク機器１０３からソース機器１０１に対して、両機器間の認証鍵生成のための情報（Ｂｖ）、システムリニューアビリティ管理情報Ｂｓｒｍ、署名Ｓを送付する（Ｓ１１３）。
【００５８】つぎに、ソース機器１０１からシンク機器１０３に対して、両機器間の認証鍵精製のための情報（Ａｖ）、システムリニューアビリティ管理情報Ａｓｒｍ、署名Ｓを送付する（Ｓ１１４）。
【００５９】次に、両機器にて認証鍵Ｋａｕｔｈの生成、共有を行う。
【００６０】次に、ソース機器１０１からシンク機器１０３に対して、ある関数ｇを使って、交換鍵Ｋｘ、認証鍵Ｋａｕｔｈを変数としたｇ（Ｋｘ、Ｋａｕｔｈ）を送信し（Ｓ１１５）、ソース機器１０１とシンク機器１０３との間でＫｘを共有する。
【００６１】次に、ソース機器１０１からシンク機器１０３に対して、整数Ｎｃを送信する（Ｓ１１６）。
【００６２】そして、ある関数ｆを用いて、ｆ（Ｋｘ、Ｎｃ）を計算することにより、暗号鍵Ｋを計算する。
【００６３】以上の手順により、ソース機器１０１とシンク機器１０３との間で、ＡＶデータを暗号化して転送するための暗号鍵の共有を図ることができるようになる。」
　
（カ）「【００７１】＜第３の方法＞図１３に、第３の方法の場合のシーケンスの一例を示す。
【００７２】第３の方法は、図４のＳＰ ＳＵＢＵＮＩＴ ＩＮＦＯ応答やＳＰコピープロテクションコマンドのように事前に著作権保護に関する情報交換の手順を踏んだ後に認証鍵交換を要求に行くのではなく、暗号化されたＡＶデータをシンク機器１０３が受信してはじめてソース機器１０１に対して認証鍵交換を要求に行くようにした場合の例である。ここでは、著作権保護に関する情報が既知であるものとする（例えば、方式が固定されているなどである）。
【００７３】この場合の認証鍵交換は以下のようになる。
【００７４】まず、シンク機器１０３からソース機器１０１に対して、ＣＰ ＰＬＡＹコマンドが発行される（Ｓ１３１）。
【００７５】シンク機器１０３からＣＰ ＰＬＡＹコマンドを受信したソース機器１０１は、指定されたサブユニットからのＡＶデータの送信を開始する（Ｓ１３２，Ｓ１３３）。ここで、例えば、最初の数秒間は、実際のＡＶデータ（暗号化データ）は送信せず、空データの送信を行ってもよい。これは、認証鍵交換が終了するまで、シンク機器１０３は実際のＡＶデータ再生は行うことができないため、認証鍵交換を行う時間を与える意味がある。
【００７６】さて、これを受け取ったシンク機器１０３は、「該データが、ソース機器１０１から送られてきた、暗号化された、ＡＶデータである」ということを認識することができる。なお、ＡＶデータであることは、先のＳＰコネクトコマンドから認識可能である。また、ソース機器１０１から送られてきているということは、Ｂｌｕｅｔｏｏｔｈパケットヘッダを見ることにより認識可能である。また、暗号化されていることは、ＡＶデータに付与されたトランスポートヘッダから認識可能である。
【００７７】ここで、シンク機器１０３は、ソース機器１０１に対して、認証鍵交換の要求を行うが、シンク機器１０３側の、Ｂｌｕｅｔｏｏｔｈチャネルに関する情報、またはサブユニットとプラグに関する情報（前述と同様の理由によっていずれでもよい）を添付する。以降の手順は、基本的に第２の方法と同様である。シンク機器１０３のＢｌｕｅｔｏｏｔｈチャネルに関する情報またはサブユニットとプラグに関する情報は、図１３のように、ＤＴＣＰの認証鍵交換のやり取りに添付される。
【００７８】さて、ＣＨ−Ａ１／ＣＨ−Ｂ１についての暗号鍵（Ｋ１とする）が共有された後、ソース機器１０１は、暗号鍵ｋ１でＭＰＥＧ４データ（Ｃ１）を暗号化した映像データ［Ｃ１］ｋ１をＣＨ−Ａ１／ＣＨ−Ｂ１によって送信し（Ｓ１４０）、シンク機器１０３は、ＣＨ−Ａ１／ＣＨ−Ｂ１で受信した映像データ［Ｃ１］ｋ１を暗号鍵ｋ１で復号化した後に例えばこれをデコードして映像表示することができる。」
　
（キ）「【００８４】（第２の実施形態）次に、第２の実施形態について説明する。
【００８５】本実施形態の構成は基本的には第１の実施形態と同様である（図１、２、３、６、７、８、９、１０参照）。第１の実施形態では、シンク機器１０３がソース機器１０１をコントロールするコントローラとなったが、本実施形態では、ソース機器１０１がシンク機器１０３をコントロールするコントローラとなっている。
【００８６】以下では、本実施形態が第１の実施形態と相違する点を中心に説明する。
【００８７】まず、ソース機器１０１とシンク機器１０３との間のシーケンスの初期手順について説明する。
【００８８】図１４および図１５（図１５は図１４の続きである）に、ソース機器１０１とシンク機器１０３のシーケンスの初期手順例を示す。ここでも、ＡＶデータが転送されるＢｌｕｅｔｏｏｔｈのチャネルごとに異なる暗号鍵が用いられる場合について説明する。」
　
（ク）「【０１００】次に、ソース機器１０１とシンク機器１０３との間のシーケンス初期手順以降の手順について説明する。
【０１０１】続いて、シンク機器１０３は、ＤＴＣＰの方式に従って、ソース機器１０１に対して著作権保護のための認証鍵交換の手続をはじめる。この認証鍵交換の方式として、第１の実施形態と同様に、いくつかの方法が考えられる。
（中略）
【０１１１】＜第３の方法＞図１８に、本実施形態の第３の方法の場合のシーケンスの一例を示す。
【０１１２】本実施形態の第３の方法は、第１の実施形態の第３の方法（図１３参照）と同様に、図１７のＳＰ ＳＵＢＵＮＩＴ ＩＮＦＯ応答や、ＳＰコピープロテクションコマンドのように、事前に著作権保護に関する事前の情報交換は行わず、暗号化されたＡＶデータをシンク機器１０３が受信して、はじめて、ソース機器１０１に対して認証鍵交換を要求に行く場合である。
【０１１３】まず、第１の実施形態の図１３のＳ１３１では、シンク機器１０３からソース機器１０１に対して、ＡＶデータの送信を要求するための制御コマンドであるＣＰ ＰＬＡＹコマンドが送信されたが、本実施形態の図１８のＳ１９０では、ソース機器１０１からシンク機器１０３に対して、ＡＶデータの受信を要求するための制御コマンドであるＣＰ 表示コマンドが発行される。ここで、ソース機器１０１は、（ＣＨ−Ｂ１，ＣＨ−Ｂ２経由で）ＡＶデータの送信を開始する（Ｓ１３２，Ｓ１３３）。以降の手順は、基本的に第１の実施形態の第３の方法（図１３参照）と同様である。
【０１１４】さて、これを受け取ったシンク機器１０３は、「該データが、ソース機器１０１から送られてきた、暗号化された、ＡＶデータである」ということを認識することができる。なお、ＡＶデータであることは、先のＳＰコネクトコマンドから認識可能である。また、ソース機器１０１から送られてきているということは、Ｂｌｕｅｔｏｏｔｈパケットヘッダを見ることにより認識可能である。また、暗号化されていることは、ＡＶデータに付与されたトランスポートヘッダから認識可能である。
【０１１５】ここで、シンク機器１０３は、ソース機器１０１に対して、認証鍵交換の要求を行うが、シンク機器１０３側のＢｌｕｅｔｏｏｔｈチャネルに関する情報、またはサブユニットとプラグに関する情報（前述と同様の理由によっていずれでもよい）を添付する。
【０１１６】送信側のソース機器１０１は、このＢｌｕｅｔｏｏｔｈチャネルに関する情報、またはサブユニットとプラグに関する情報を参照し、図６のようなチャネル対応テーブルや図１０のようなチャネル／サブユニット／プラグ対応テーブルを参照するなどして、ソース機器１０１は、この認証鍵交換についての要求（チャレンジ）が、どのチャネルに対するものであるのかを認識することが可能である。
【０１１７】この場合も、Ｂｌｕｅｔｏｏｔｈチャネルごとに別々の暗号鍵を使ってＡＶデータの暗号化を行うことになる。」
　
（ａ）上記（ア）の「【００２４】本実施形態では、ソース機器とシンク機器との間でやり取りされる（すなわち、ソース機器が送信し、シンク機器が受信する）ＡＶデータは、著作権保護がかけられるべきデータであるとする。著作権保護のためには、ＡＶデータを暗号化した状態で送受信する（すなわち、ソース機器側で暗号化し、シンク機器側で復号化する）ものとする。」との記載から、引用文献１には、ソース機器から送信される暗号化されたＡＶデータをシンク機器で受信するための方法が記載されたものと解される。
　そして、上記（ア）の「【００２２】図１に示されるように、ソース機器（無線端末または無線インタフェースを有する装置）１０１と、シンク機器（無線端末または無線インタフェースを有する装置）１０３が、無線ネットワーク１０６に接続されている。無線ネットワーク１０６としては、Ｂｌｕｅｔｏｏｔｈを仮定して説明する。」との記載、及び、上記（キ）の「【００８８】図１４および図１５（図１５は図１４の続きである）に、ソース機器１０１とシンク機器１０３のシーケンスの初期手順例を示す。ここでも、ＡＶデータが転送されるＢｌｕｅｔｏｏｔｈのチャネルごとに異なる暗号鍵が用いられる場合について説明する。」との記載から、当該ＡＶデータは、無線ネットワークであるＢｌｕｅｔｏｏｔｈを介して送信されるものと解されること、上記（ア）の「【００２３】ソース機器とは、（中略））ここで、ＡＶデータ（もしくはＡＶストリーム）は、映像や音声がこれに該当するが、映像や音声にそれら以外のデータが含まれている場合もある。」との記載から、当該ＡＶデータにはストリームも含まれると解されることから、引用文献１には
　無線ネットワークであるＢｌｕｅｔｏｏｔｈを介し、ソース機器から送信される、ストリームも含む、暗号化されたＡＶデータをシンク機器で受信するための方法
　が記載されたものと認められる。
　
（ｂ）上記（キ）の「【００８７】まず、ソース機器１０１とシンク機器１０３との間のシーケンスの初期手順について説明する。」、及び、上記（ク）の「【０１００】次に、ソース機器１０１とシンク機器１０３との間のシーケンス初期手順以降の手順について説明する。
【０１０１】続いて、シンク機器１０３は、ＤＴＣＰの方式に従って、ソース機器１０１に対して著作権保護のための認証鍵交換の手続をはじめる。」との記載からみて、第２の実施形態として引用文献１に記載された方法は、ソース機器とシンク機器の間で、シーケンスの初期手順をまず行った上で、続いて著作権保護のための認証鍵交換の手続がはじめられるものと解される。
　そして、上記（イ）、（ウ）及び（エ）の記載から、引用文献１に記載のシーケンスの初期手順とは、ソース機器とシンク機器との間でチャネルを確立するものであることが読み取れる。
　さらに、上記（ク）の「【０１１２】本実施形態の第３の方法は、第１の実施形態の第３の方法（図１３参照）と同様に、（中略）暗号化されたＡＶデータをシンク機器１０３が受信して、ソース機器１０１に対して認証鍵交換を要求に行く場合である。
【０１１３】まず、第１の実施形態の図１３のＳ１３１では、シンク機器１０３からソース機器１０１に対して、ＡＶデータの送信を要求するための制御コマンドであるＣＰ ＰＬＡＹコマンドが送信されたが、本実施形態の図１８のＳ１９０では、ソース機器１０１からシンク機器１０３に対して、ＡＶデータの受信を要求するための制御コマンドであるＣＰ 表示コマンドが発行される。ここで、ソース機器１０１は、（ＣＨ−Ｂ１，ＣＨ−Ｂ２経由で）ＡＶデータの送信を開始する（Ｓ１３２，Ｓ１３３）。以降の手順は、基本的に第１の実施形態の第３の方法（図１３参照）と同様である。」との記載、及び、上記（オ）の「（ｃ）上記（オ）の「【００５４】この場合の認証鍵交換は以下のようになる。
【００５５】まず、シンク機器１０３からソース機器１０１へ、チャレンジ変数Ｂｎと証明書Ｂｃｅｒｔを送付する（Ｓ１１１）。
【００５６】次に、ソース機器１０１からシンク機器１０３へのチャレンジ変数Ａｎと証明書Ａｃｅｒｔの送付を行い（Ｓ１１２）、これらを元に認証を行う。」との記載から、引用文献１に第２の実施形態の第３の方法として記載された方法では、認証鍵交換の手続は、ソース機器が暗号化されたＡＶデータの送信を開始し、該暗号化されたＡＶデータをシンク機器が受信して、ソース機器に対してチャレンジ変数Ｂｎと証明書Ｂｃｅｒｔを送付し、認証を要求することによって始められるものであることが読み取れるから、
　引用文献１には、
　ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたＡＶデータの送信を開始し、該暗号化されたＡＶデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順
が記載されたものと認められる。
　
（ｃ）上記（オ）の「【００５４】この場合の認証鍵交換は以下のようになる。
（中略）
【００６０】次に、ソース機器１０１からシンク機器１０３に対して、ある関数ｇを使って、交換鍵Ｋｘ、認証鍵Ｋａｕｔｈを変数としたｇ（Ｋｘ、Ｋａｕｔｈ）を送信し（Ｓ１１５）、ソース機器１０１とシンク機器１０３との間でＫｘを共有する。
【００６１】次に、ソース機器１０１からシンク機器１０３に対して、整数Ｎｃを送信する（Ｓ１１６）。
【００６２】そして、ある関数ｆを用いて、ｆ（Ｋｘ、Ｎｃ）を計算することにより、暗号鍵Ｋを計算する。
【００６３】以上の手順により、ソース機器１０１とシンク機器１０３との間で、ＡＶデータを暗号化して転送するための暗号鍵の共有を図ることができるようになる。」
との記載において、「暗号鍵Ｋ」と「ＡＶデータを暗号化して転送するための暗号鍵」とは同一のものと解される。
　また、上記（カ）の「【００７８】さて、ＣＨ−Ａ１／ＣＨ−Ｂ１についての暗号鍵（Ｋ１とする）が共有された後、ソース機器１０１は、暗号鍵ｋ１でＭＰＥＧ４データ（Ｃ１）を暗号化した映像データ［Ｃ１］ｋ１をＣＨ−Ａ１／ＣＨ−Ｂ１によって送信し（Ｓ１４０）、シンク機器１０３は、ＣＨ−Ａ１／ＣＨ−Ｂ１で受信した映像データ［Ｃ１］ｋ１を暗号鍵ｋ１で復号化した後に例えばこれをデコードして映像表示することができる。」との記載において、いずれも映像データを暗号化して転送するための鍵である「暗号鍵（Ｋ１とする）」及び「暗号鍵ｋ１」は、上記（オ）に記載された「暗号鍵Ｋ」と同一の暗号鍵と解されること、また、映像データを暗号化して転送するための暗号鍵は、映像データを復号化するための暗号鍵でもあることが読み取れることから、引用文献１に記載の暗号鍵Ｋは、ソース機器から送信される暗号化されたＡＶデータを復号化するためのものであると解される。
　したがって、引用文献１には、
　認証鍵交換の手順は、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたＡＶデータを復号化するための暗号鍵を計算して共有するための情報である、ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃを送信する手順を含むこと
が記載されたものと認められる。
　
　以上のことから、引用文献１には、第２の実施形態の第３の方法として、以下の発明（以下、「引用発明」という。）が記載されている。
　無線ネットワークであるＢｌｕｅｔｏｏｔｈを介し、ソース機器から送信される、ストリームも含む、暗号化されたＡＶデータをシンク機器で受信するための方法であって、
　ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたＡＶデータの送信を開始し、該暗号化されたＡＶデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順と、
　認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたＡＶデータを復号化するための暗号鍵を計算して共有するための情報である、ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃを送信する手順
を含む受信方法。
　
（３）対比
　引用発明と、本件補正後発明とを対比する。
　引用発明における「ソース機器」及び「ストリームも含む、暗号化されたＡＶデータ」は、本件補正後発明における「外部電子機器」及び「ストリームデータ」にそれぞれ相当する。
　
　引用発明における「データバス」と、本件補正後発明における「無線ネットワークであるＢｌｕｅｔｏｏｔｈ」とは、データの通信路という点で一致するから、引用発明の「無線ネットワークであるＢｌｕｅｔｏｏｔｈを介し、ソース機器から送信される、ストリームも含む、暗号化されたＡＶデータをシンク機器で受信するための方法」と、本件補正後発明の「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法」とは、”データの通信路を介し、外部電子機器から送信されるストリームデータを受信するための受信方法”である点で一致する。
　
　引用発明における「ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順」は、シンク機器と、ソース機器との間の接続を確立するものであり、当該シーケンス初期手順に続いて行われる、ソース機器が暗号化されたＡＶデータの送信は、接続が確立されたことに応じてソース機器がシンク機器に対して行うものといえる。
　そして、引用発明における「暗号化されたＡＶデータをシンク機器が受信して、ソース機器に対して認証を要求する」ことは、シンク機器が、暗号化されたＡＶデータを受信するのに応じ、ソース機器に対して認証要求を行うことと同じである
　したがって、引用発明における「ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたＡＶデータの送信を開始し、該暗号化されたＡＶデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順」と、本件補正後発明における「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順」とは、同じものである。
　
　引用発明における「認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたＡＶデータを復号化するための暗号鍵を計算して共有するための情報である、ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃを送信する手順」に関し、「認証鍵交換の手順」は、シンク機器のソース機器に対する認証の要求に応じて始まるものであるから、ソース機器からシンク機器に対して、ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃを送信する手順は、シンク機器の認証要求にソース機器が応じて行うものといえる。
　また、引用発明において、ソース機器からシンク機器に対して情報が送信された場合に、シンク機器が当該情報を取得することは自明なことであり、ソース機器から送信される「ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃ」は、いずれもシンク機器がＡＶデータを解読するために使用する情報であるといえるから、本件補正後発明における「暗号化ストリームデータを解読するための情報」と同じものである。
　したがって、引用発明における「認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたＡＶデータを復号化するための暗号鍵を計算して共有するための情報である、ｇ（Ｋｘ、Ｋａｕｔｈ）や整数Ｎｃを送信する手順」と、本件補正後発明における「上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順」とは、同じものである。
　
　よって、本件補正後発明と引用発明とは、以下の点で一致し、また相違する。
　
（一致点）
　データの通信路を介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、
　上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、
　上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する手順と
を備える受信方法
　
（相違点）
（相違点１）
　本件補正後発明は、データの通信路が「データバス」であるのに対して、引用発明は、データの通信路が「無線ネットワークであるＢｌｕｅｔｏｏｔｈ」である点。
　
（相違点２）
　本件補正後発明は、「上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順」を備えるのに対し、引用発明は、当該再認証要求手順を備えることは明らかではない点。
　
（４）判断
　上記相違点について判断する。
（相違点１）について；
　暗号化されたＡＶデータを送受信するデータの通信路として、データバスを採用することは、原査定の拒絶理由に引用された特開２００２−２４５７１８号公報（以下、「引用文献２」という。）に「【０００２】【従来の技術】デジタル映像信号処理技術（中略）こうしたストリームデータの伝送に最も適したデジタルインターフェースとして、ＩＥＥＥ１３９４−１９９５規格に定められた高速シリアルバス（以下１３９４バスと記す」が有る。（中略）【０００４】このようなコンテンツの不正なコピーを防止するための技術としてＤＴＣＰ（Ｄｉｇｉｔａｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｅｎｔｓ　Ｐｒｏｔｅｃｔｉｏｎ）方式が１３９４バスでは採用されている。」と記載されているように本願出願前に周知の技術事項であり、引用文献１にも、ＩＥＥＥ１３９４につき「【００３６】次に、この確立されたチャネルを用いて、ストリームプロトコルのやり取りが行われる。（中略）なお、サブユニットとは、ＩＥＥＥ１３９４やＢｌｕｅｔｏｏｔｈ等のＡＶ機器で、ある機器内の機能を構成要素として論理的に記述する際に用いられる概念である（その詳細は１３９４ＡＶ／Ｃスペックに開示されている）。」のように言及されていることからみれば、引用発明において、暗号化されたＡＶデータを送受信するデータの通信路として、周知のデータバスであるＩＥＥＥ１３９４を採用することは当業者が容易に想到し得た事項である。
　よって、相違点１は格別のものではない。
　
（相違点２）について；
　著作権保護のためにＡＶデータを暗号化して送受信する技術分野において、ストリームデータの受信が停止した場合に、シンク機器が暗号鍵を破棄することは、引用文献２に「【００２９】ストリームの伝送を終了するときには、ソース側からのストリームを止め（手順１００８）、ソースとシンク間のコネクションを破棄し（手順１００９）、ソース側シンク側それぞれの鍵データを破棄する（手順１０１０、１０１１）。」と記載されているように周知の技術事項である。
　そして、暗号鍵が破棄された後で再度暗号化されたＡＶデータがシンク機器に送信された場合に、当該シンク機器が復号のために暗号鍵を取得するよう構成することは当業者が当然に行うべき事項であることからすれば、引用発明において、シンク機器がＡＶデータの受信が停止した場合には暗号鍵を破棄すると共に、再度ソース機器から暗号化されたＡＶデータが受信された場合には、暗号鍵を取得するためにソース機器に対して再度認証の要求を行うよう構成することは当業者が容易に想到し得た事項である。
　よって、相違点２は格別のものではない。
　
　なお、ストリームデータの伝送が終了する場合の他、ストリームデータの受信が様々な原因で停止すなわち”中断”した場合において、受信を再開する時に認証鍵交換を行うことも当業者にとり周知の技術事項である。
（例、本願出願前に頒布された刊行物である特開平１１−２８９３２６号公報に、従来の技術として以下の記載がある。（なお、下線は当審で付与した。）
「【０００９】図１０は、従来のデータ送受信システムにおいて、コントロールキーを更新するとした場合の、コントロールキー更新と認証・鍵交換の実行の関係を示す模式図である。図の横方向は、時間の経過を表し、一段目の帯は、ＳＴＢがデータ信号を送信中であることを示す。２段目の矢印は、同じコントロールキーＫｃが使用されている範囲を示し、本図では途中でＫｃ［１］からＫｃ［２］に更新されたことを示している。３〜５段目の帯は、各ケースにおけるＶＴＲ装置が受信状態であることを示し、帯が途切れている範囲は、受信が中断状態であることを示す。また、３〜５段目の縦向きの両矢印は、認証・鍵交換が実行されたことを示す。
【００１０】ケース１のＶＴＲ装置は、受信開始後に受信中断がないため、受信開始時に認証・鍵交換を実行し、以後は、コントロールキーＫｃの更新時のみに認証・鍵交換を実行するだけでよい。
ケース２およびケース３のＶＴＲ装置は、受信開始後に受信中断が起こったため、受信再開時に認証・鍵交換を実行しなければならない。
　したがって、ＡＶデータの受信がストリームデータの伝送の終了する場合の他、様々な原因で中断した場合について進んで検討しても、引用発明において、ＡＶデータの受信再開時にシンク機器が認証鍵交換の手順を実行するべく、ＡＶデータを再度受信した時にソース機器に対して再度認証の要求を行うよう構成することは当業者が容易に想到し得た事項である。
　
　上記で検討したごとく、相違点１及び相違点２は格別のものではなく、そして、本件補正後発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものではない。
　
　以上のとおり、本件補正後発明は、引用発明及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．結語
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
第３．本願発明について
１．本願発明
　平成１９年１０月９日付けの手続補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の項中の「１．本願発明と本件補正後発明」の項で本願発明として認定したとおりのものである。
　
２．引用発明
　引用発明は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりのものである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は、上記本件補正後発明の「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータ」から、認証要求手順に係るストリームデータの限定である「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信される」を省いたものである。
　そうすると、本願発明の構成に当該限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用文献１に第２の実施形態の第３の方法として記載された発明である引用発明及び周知の技術事項に基づいて容易に発明できたものである。
（なお、引用文献１において、平成１８年１１月２８日付け拒絶理由通知書において明示された箇所である同文献【００５１】段落乃至【００８３】段落に記載の第１の実施形態の第３の方法は、ＡＶデータの送信が、シンク機器がソース機器へＣＰ　ＰＬＡＹコマンドが送信されたことに応じて行われる点でのみ引用発明（第２の実施形態の第３の方法）と相違するものであることからみて、ＡＶデータの送信について格別限定のない本願発明と、当該第１の実施形態の第３の方法として記載された発明とを対比した場合の一致点及び相違点は、本願発明と引用発明との一致点及び相違点と各々同一である。
　したがって、本願発明は、引用発明と同様にして、引用文献１に第１の実施形態中の第３の方法として記載された発明から当業者が容易に発明をすることができたものといえる。）
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知の技術事項に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により、特許を受けることができない。
　
　よって、結論のとおり審決する。