ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 H04L 審判 査定不服 2項進歩性 特許、登録しない。 H04L 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L |
|---|---|
| 管理番号 | 1209574 |
| 審判番号 | 不服2007-24642 |
| 総通号数 | 122 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2010-02-26 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2007-09-06 |
| 確定日 | 2010-01-04 |
| 事件の表示 | 特願2003-278460「受信装置、及び受信方法」拒絶査定不服審判事件〔平成17年 2月17日出願公開、特開2005- 45612〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1.手続の経緯 本願は、平成15年7月23日の出願であって、平成16年8月26日に手続補正がなされ、平成18年11月28日付けで拒絶理由が通知され、平成19年2月5日に意見書が提出されると共に手続補正がなされたが、同年8月1日付けで拒絶査定がなされた。これに対し、同年9月6日に審判請求がなされ、同年10月9日に手続補正がなされ、平成20年7月30日に審査官より前置報告がなされ、平成21年8月4日付けで当審より審尋がなされ、同年10月2日に回答書が提出されたものである。 第2.補正却下の決定 [補正却下の決定の結論] 平成19年10月9日付けの手続補正を却下する。 [理由] 1.本願発明と本件補正後発明 平成19年10月9日付けの手続補正(以下、「本件補正」という。)は、平成19年2月5日付けの手続補正により補正された特許請求の範囲の請求項2に記載された発明 「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、 ストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、 上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順と、 上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順と、 を備えることを特徴とする受信方法。」(以下、「本願発明」という。)を、 「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、 上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、 上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順と、 上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順と、 を備えることを特徴とする受信方法。」(以下、「本件補正後発明」という。) に補正することを含むものである。 2.新規事項の有無、補正の目的要件について 上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、当該補正前の発明(本願発明)の「認証要求手順」に係る「ストリームデータ」を「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信される」ものに限定して特許請求の範囲を減縮するものであるから、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項(新規事項)及び、第4項第2号(補正の目的)の規定に適合している。 3.独立特許要件について 上記補正は特許請求の範囲の減縮を目的とするものであるから、上記本件補正後発明が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。 (1)本件補正後発明 上記「1.本願発明と本件補正後発明」の項で認定したとおりである。 (2)引用発明 原審の拒絶理由に引用された特開2001-326651号公報(以下、「引用文献1」という)には、図面と共に以下の事項が記載されている。 (ア)「【0020】 【発明の実施の形態】以下、図面を参照しながら発明の実施の形態を説明する。 【0021】(第1の実施形態)図1に、本実施形態のAVデータ転送システムの構成例を示す。 【0022】図1に示されるように、ソース機器(無線端末または無線インタフェースを有する装置)101と、シンク機器(無線端末または無線インタフェースを有する装置)103が、無線ネットワーク106に接続されている。無線ネットワーク106としては、Blｕeｔｏｏｔhを仮定して説明する。Blｕeｔｏｏｔhは、低コスト、低消費電力などを特徴とする無線LANの一種である(例えば、hｔｔｐ://ｗｗｗ.blｕeｔｏｏｔh.cｏmにて取得可能に開示されている文書に説明が詳しい)。なお、ソース機器101のノードID=[A]、シンク機器103のノードID=[B]であるものとする。 【0023】ソース機器とは、AVデータの送信元すなわちソースとなる機器(例えばVTR(ビデオテープレコーダ))のことを意味し、シンク機器とは、AVデータの受信先すなわちシンクとなる機器(例えばディスプレイ)のことを意味する。ここで、AVデータ(もしくはAVストリーム)は、映像や音声がこれに該当するが、映像や音声にそれら以外のデータが含まれている場合もある。 【0024】本実施形態では、ソース機器とシンク機器との間でやり取りされる(すなわち、ソース機器が送信し、シンク機器が受信する)AVデータは、著作権保護がかけられるべきデータであるとする。著作権保護のためには、AVデータを暗号化した状態で送受信する(すなわち、ソース機器側で暗号化し、シンク機器側で復号化する)ものとする。このため、ソース機器とシンク機器との間では、AVデータのやり取りに先立って認証鍵交換手順が行われることになる。」 (イ)「【0030】次に、ソース機器101とシンク機器103との間のシーケンスの初期手順について説明する。 【0031】図4および図5(図5は図4の続きである)に、ソース機器101とシンク機器103との間のシーケンスの初期手順例を示す。 【0032】ここで、本実施形態においては、ソース機器101とシンク機器103との間でやり取りされるAVデータごと、つまりAVデータが転送されるBlｕeｔｏｏｔhのチャネルごとに異なる暗号鍵が与えられている場合について説明する。また、本実施形態では、シンク機器103の側がコントローラとなり、ソース機器101を制御する場合を考える。 【0033】まず、ソース機器101とシンク機器103は、互いにL2CAPのコネクト要求とコネクト応答のやり取りを行う(S41)。本実施形態のBlｕeｔｏｏｔhにおいては、Blｕeｔｏｏｔh上のAVデータのやり取りを行うためのチャネル設定や制御情報の交換を行うプロトコルが存在する(ここでは、このプロトコルをストリームプロトコルと呼ぶ;またSPはストリームプロトコルの略である)。 【0034】このコネクト要求/応答は、このSPを行うためのチャネルを確立するためのやり取りである。このやり取りを通して、ソース機器101側はチャネルA0(以下、CH-A0と表記する)を、シンク機器103側はチャネルB0(以下、CH-B0と表記する)を確保する(S42,S43)。」 (ウ)【0036】次に、この確立されたチャネルを用いて、ストリームプロトコルのやり取りが行われる。まず、シンク機器103は、何らかの方法(例えば、コントロールプロトコルのUNITコマンドで問い合わせることによって、あるいはユーザが入力することによって)でソース機器101側がVTRであることを認識しているとする。このとき「ソース機器はどのような構成を持ったVTRであるか」を知るためのコマンドがSUBUNIT INFOコマンドである。このコマンドを通して、シンク機器103は、ソース機器101に対して、ソース機器101のVTRサブユニットがどのような構成をしているかについて問い合わせることが可能である(S46)。なお、サブユニットとは、IEEE1394やBlｕeｔｏｏｔh等のAV機器で、ある機器内の機能を構成要素として論理的に記述する際に用いられる概念である(その詳細は1394AV/Cスペックに開示されている)。」 (エ)「【0039】次に、ソース機器101とシンク機器103は、L2CAPのコネクト要求/コネクト応答のやり取りを、AVデータの転送のためのプロトコル(ここでは、このプロトコルをトランスポートプロトコルと呼ぶ;またTPはトランスポートプロトコルの略である)がチャネルを確立するために行う。ここではMPEG4ビデオとAACオーディオの2チャネル分確保(CH-A1/CH-B1及びCH-A2/CH-B2)する(S48?S53)。 【0040】次に、これらの確保したBlｕeｔｏｏｔhチャネルを、対象となる出力プラグに接続するための手順を行う。これも、SPの一部分であるため、SPのコマンドの一つであるSPコネクトコマンドが用いられる(S54,S55)。ここでは、「CH-A1はVTRサブユニットの出力プラグ1に繋ぎなさい」という意味のメッセージや「CH-A2はVTRサブユニットの出力プラグ2に繋ぎなさい」という意味のメッセージがソース機器101側に届く。ソース機器101は、この指示に従う(図7に記述したL2CAPチャネルと出力プラグの対応関係のように接続される)。 【0041】ここで、このSPコネクトコマンドには、相手側(この例の場合、ソース機器101)側のチャネルとサブユニット/プラグの対応関係の情報の他に、このコマンドの送信側(この例の場合、シンク機器103)のチャネルとサブユニット/プラグの対応関係の情報も記載してあってもよい。このようにすることで、相手側機器(この例の場合、ソース機器101)に対して、コマンドの送信側のチャネルとサブユニット/プラグの対応関係を明に通知することが可能となる。これによって、例えば、相手側機器が、自機器のどのサブユニットやプラグに対して認証鍵交換等の手続を行うべきかについての情報を相手側機器に対して通知することが可能となる。」 (オ)「【0050】次に、ソース機器101とシンク機器103との間のシーケンス初期手順以降の手順について説明する。 【0051】続いて、シンク機器103は、DTCPの方式に従って、ソース機器101に対して著作権保護のための認証鍵交換の手続をはじめる。この認証鍵交換の方式としては、いくつかの方法が考えられる。 【0052】＜第1の方法＞図11に、第1の方法の場合のシーケンスの一例を示す。 【0053】第1の方法は、認証鍵交換の際に、ソース機器101側/シンク機器103側双方の、Blｕeｔｏｏｔhチャネルに関する情報、またはサブユニットとプラグに関する情報(図10のような対応テーブルを参照することによって、どちらの情報からも同様の情報を入手することが可能であるため、どちらでもよい)を添付させる方法である。このようにすることにより、ソース機器101は、この認証鍵交換についての要求(チャレンジ)が、どのチャネルに対するものであるかを認識することが可能である。この双方のBlｕeｔｏｏｔhチャネルに関する情報または双方のサブユニットとプラグに関する情報は、図11のように、DTCPの認証鍵交換のやり取りに添付される。 【0054】この場合の認証鍵交換は以下のようになる。 【0055】まず、シンク機器103からソース機器101へ、チャレンジ変数Bnと証明書Bceｒｔを送付する(S111)。なお、それらの情報に、チャネル情報、またはサブユニット/プラグ情報が添付される。この点は、図11に示すように、以下の手順でも同様である。 【0056】次に、ソース機器101からシンク機器103へのチャレンジ変数Anと証明書Aceｒｔの送付を行い(S112)、これらを元に認証を行う。 【0057】次に、シンク機器103からソース機器101に対して、両機器間の認証鍵生成のための情報(Bｖ)、システムリニューアビリティ管理情報Bｓｒm、署名Sを送付する(S113)。 【0058】つぎに、ソース機器101からシンク機器103に対して、両機器間の認証鍵精製のための情報(Aｖ)、システムリニューアビリティ管理情報Aｓｒm、署名Sを送付する(S114)。 【0059】次に、両機器にて認証鍵Kaｕｔhの生成、共有を行う。 【0060】次に、ソース機器101からシンク機器103に対して、ある関数gを使って、交換鍵Kｘ、認証鍵Kaｕｔhを変数としたg(Kｘ、Kaｕｔh)を送信し(S115)、ソース機器101とシンク機器103との間でKｘを共有する。 【0061】次に、ソース機器101からシンク機器103に対して、整数Ncを送信する(S116)。 【0062】そして、ある関数fを用いて、f(Kｘ、Nc)を計算することにより、暗号鍵Kを計算する。 【0063】以上の手順により、ソース機器101とシンク機器103との間で、AVデータを暗号化して転送するための暗号鍵の共有を図ることができるようになる。」 (カ)「【0071】＜第3の方法＞図13に、第3の方法の場合のシーケンスの一例を示す。 【0072】第3の方法は、図4のSP SUBUNIT INFO応答やSPコピープロテクションコマンドのように事前に著作権保護に関する情報交換の手順を踏んだ後に認証鍵交換を要求に行くのではなく、暗号化されたAVデータをシンク機器103が受信してはじめてソース機器101に対して認証鍵交換を要求に行くようにした場合の例である。ここでは、著作権保護に関する情報が既知であるものとする(例えば、方式が固定されているなどである)。 【0073】この場合の認証鍵交換は以下のようになる。 【0074】まず、シンク機器103からソース機器101に対して、CP PLAYコマンドが発行される(S131)。 【0075】シンク機器103からCP PLAYコマンドを受信したソース機器101は、指定されたサブユニットからのAVデータの送信を開始する(S132,S133)。ここで、例えば、最初の数秒間は、実際のAVデータ(暗号化データ)は送信せず、空データの送信を行ってもよい。これは、認証鍵交換が終了するまで、シンク機器103は実際のAVデータ再生は行うことができないため、認証鍵交換を行う時間を与える意味がある。 【0076】さて、これを受け取ったシンク機器103は、「該データが、ソース機器101から送られてきた、暗号化された、AVデータである」ということを認識することができる。なお、AVデータであることは、先のSPコネクトコマンドから認識可能である。また、ソース機器101から送られてきているということは、Blｕeｔｏｏｔhパケットヘッダを見ることにより認識可能である。また、暗号化されていることは、AVデータに付与されたトランスポートヘッダから認識可能である。 【0077】ここで、シンク機器103は、ソース機器101に対して、認証鍵交換の要求を行うが、シンク機器103側の、Blｕeｔｏｏｔhチャネルに関する情報、またはサブユニットとプラグに関する情報(前述と同様の理由によっていずれでもよい)を添付する。以降の手順は、基本的に第2の方法と同様である。シンク機器103のBlｕeｔｏｏｔhチャネルに関する情報またはサブユニットとプラグに関する情報は、図13のように、DTCPの認証鍵交換のやり取りに添付される。 【0078】さて、CH-A1/CH-B1についての暗号鍵(K1とする)が共有された後、ソース機器101は、暗号鍵k1でMPEG4データ(C1)を暗号化した映像データ[C1]k1をCH-A1/CH-B1によって送信し(S140)、シンク機器103は、CH-A1/CH-B1で受信した映像データ[C1]k1を暗号鍵k1で復号化した後に例えばこれをデコードして映像表示することができる。」 (キ)「【0084】(第2の実施形態)次に、第2の実施形態について説明する。 【0085】本実施形態の構成は基本的には第1の実施形態と同様である(図1、2、3、6、7、8、9、10参照)。第1の実施形態では、シンク機器103がソース機器101をコントロールするコントローラとなったが、本実施形態では、ソース機器101がシンク機器103をコントロールするコントローラとなっている。 【0086】以下では、本実施形態が第1の実施形態と相違する点を中心に説明する。 【0087】まず、ソース機器101とシンク機器103との間のシーケンスの初期手順について説明する。 【0088】図14および図15(図15は図14の続きである)に、ソース機器101とシンク機器103のシーケンスの初期手順例を示す。ここでも、AVデータが転送されるBlｕeｔｏｏｔhのチャネルごとに異なる暗号鍵が用いられる場合について説明する。」 (ク)「【0100】次に、ソース機器101とシンク機器103との間のシーケンス初期手順以降の手順について説明する。 【0101】続いて、シンク機器103は、DTCPの方式に従って、ソース機器101に対して著作権保護のための認証鍵交換の手続をはじめる。この認証鍵交換の方式として、第1の実施形態と同様に、いくつかの方法が考えられる。 (中略) 【0111】＜第3の方法＞図18に、本実施形態の第3の方法の場合のシーケンスの一例を示す。 【0112】本実施形態の第3の方法は、第1の実施形態の第3の方法(図13参照)と同様に、図17のSP SUBUNIT INFO応答や、SPコピープロテクションコマンドのように、事前に著作権保護に関する事前の情報交換は行わず、暗号化されたAVデータをシンク機器103が受信して、はじめて、ソース機器101に対して認証鍵交換を要求に行く場合である。 【0113】まず、第1の実施形態の図13のS131では、シンク機器103からソース機器101に対して、AVデータの送信を要求するための制御コマンドであるCP PLAYコマンドが送信されたが、本実施形態の図18のS190では、ソース機器101からシンク機器103に対して、AVデータの受信を要求するための制御コマンドであるCP 表示コマンドが発行される。ここで、ソース機器101は、(CH-B1,CH-B2経由で)AVデータの送信を開始する(S132,S133)。以降の手順は、基本的に第1の実施形態の第3の方法(図13参照)と同様である。 【0114】さて、これを受け取ったシンク機器103は、「該データが、ソース機器101から送られてきた、暗号化された、AVデータである」ということを認識することができる。なお、AVデータであることは、先のSPコネクトコマンドから認識可能である。また、ソース機器101から送られてきているということは、Blｕeｔｏｏｔhパケットヘッダを見ることにより認識可能である。また、暗号化されていることは、AVデータに付与されたトランスポートヘッダから認識可能である。 【0115】ここで、シンク機器103は、ソース機器101に対して、認証鍵交換の要求を行うが、シンク機器103側のBlｕeｔｏｏｔhチャネルに関する情報、またはサブユニットとプラグに関する情報(前述と同様の理由によっていずれでもよい)を添付する。 【0116】送信側のソース機器101は、このBlｕeｔｏｏｔhチャネルに関する情報、またはサブユニットとプラグに関する情報を参照し、図6のようなチャネル対応テーブルや図10のようなチャネル/サブユニット/プラグ対応テーブルを参照するなどして、ソース機器101は、この認証鍵交換についての要求(チャレンジ)が、どのチャネルに対するものであるのかを認識することが可能である。 【0117】この場合も、Blｕeｔｏｏｔhチャネルごとに別々の暗号鍵を使ってAVデータの暗号化を行うことになる。」 (a)上記(ア)の「【0024】本実施形態では、ソース機器とシンク機器との間でやり取りされる(すなわち、ソース機器が送信し、シンク機器が受信する)AVデータは、著作権保護がかけられるべきデータであるとする。著作権保護のためには、AVデータを暗号化した状態で送受信する(すなわち、ソース機器側で暗号化し、シンク機器側で復号化する)ものとする。」との記載から、引用文献1には、ソース機器から送信される暗号化されたAVデータをシンク機器で受信するための方法が記載されたものと解される。 そして、上記(ア)の「【0022】図1に示されるように、ソース機器(無線端末または無線インタフェースを有する装置)101と、シンク機器(無線端末または無線インタフェースを有する装置)103が、無線ネットワーク106に接続されている。無線ネットワーク106としては、Blｕeｔｏｏｔhを仮定して説明する。」との記載、及び、上記(キ)の「【0088】図14および図15(図15は図14の続きである)に、ソース機器101とシンク機器103のシーケンスの初期手順例を示す。ここでも、AVデータが転送されるBlｕeｔｏｏｔhのチャネルごとに異なる暗号鍵が用いられる場合について説明する。」との記載から、当該AVデータは、無線ネットワークであるBlｕeｔｏｏｔhを介して送信されるものと解されること、上記(ア)の「【0023】ソース機器とは、(中略))ここで、AVデータ(もしくはAVストリーム)は、映像や音声がこれに該当するが、映像や音声にそれら以外のデータが含まれている場合もある。」との記載から、当該AVデータにはストリームも含まれると解されることから、引用文献1には 無線ネットワークであるBlｕeｔｏｏｔhを介し、ソース機器から送信される、ストリームも含む、暗号化されたAVデータをシンク機器で受信するための方法 が記載されたものと認められる。 (b)上記(キ)の「【0087】まず、ソース機器101とシンク機器103との間のシーケンスの初期手順について説明する。」、及び、上記(ク)の「【0100】次に、ソース機器101とシンク機器103との間のシーケンス初期手順以降の手順について説明する。 【0101】続いて、シンク機器103は、DTCPの方式に従って、ソース機器101に対して著作権保護のための認証鍵交換の手続をはじめる。」との記載からみて、第2の実施形態として引用文献1に記載された方法は、ソース機器とシンク機器の間で、シーケンスの初期手順をまず行った上で、続いて著作権保護のための認証鍵交換の手続がはじめられるものと解される。 そして、上記(イ)、(ウ)及び(エ)の記載から、引用文献1に記載のシーケンスの初期手順とは、ソース機器とシンク機器との間でチャネルを確立するものであることが読み取れる。 さらに、上記(ク)の「【0112】本実施形態の第3の方法は、第1の実施形態の第3の方法(図13参照)と同様に、(中略)暗号化されたAVデータをシンク機器103が受信して、ソース機器101に対して認証鍵交換を要求に行く場合である。 【0113】まず、第1の実施形態の図13のS131では、シンク機器103からソース機器101に対して、AVデータの送信を要求するための制御コマンドであるCP PLAYコマンドが送信されたが、本実施形態の図18のS190では、ソース機器101からシンク機器103に対して、AVデータの受信を要求するための制御コマンドであるCP 表示コマンドが発行される。ここで、ソース機器101は、(CH-B1,CH-B2経由で)AVデータの送信を開始する(S132,S133)。以降の手順は、基本的に第1の実施形態の第3の方法(図13参照)と同様である。」との記載、及び、上記(オ)の「(c)上記(オ)の「【0054】この場合の認証鍵交換は以下のようになる。 【0055】まず、シンク機器103からソース機器101へ、チャレンジ変数Bnと証明書Bceｒｔを送付する(S111)。 【0056】次に、ソース機器101からシンク機器103へのチャレンジ変数Anと証明書Aceｒｔの送付を行い(S112)、これらを元に認証を行う。」との記載から、引用文献1に第2の実施形態の第3の方法として記載された方法では、認証鍵交換の手続は、ソース機器が暗号化されたAVデータの送信を開始し、該暗号化されたAVデータをシンク機器が受信して、ソース機器に対してチャレンジ変数Bnと証明書Bceｒｔを送付し、認証を要求することによって始められるものであることが読み取れるから、 引用文献1には、 ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたAVデータの送信を開始し、該暗号化されたAVデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順 が記載されたものと認められる。 (c)上記(オ)の「【0054】この場合の認証鍵交換は以下のようになる。 (中略) 【0060】次に、ソース機器101からシンク機器103に対して、ある関数gを使って、交換鍵Kｘ、認証鍵Kaｕｔhを変数としたg(Kｘ、Kaｕｔh)を送信し(S115)、ソース機器101とシンク機器103との間でKｘを共有する。 【0061】次に、ソース機器101からシンク機器103に対して、整数Ncを送信する(S116)。 【0062】そして、ある関数fを用いて、f(Kｘ、Nc)を計算することにより、暗号鍵Kを計算する。 【0063】以上の手順により、ソース機器101とシンク機器103との間で、AVデータを暗号化して転送するための暗号鍵の共有を図ることができるようになる。」 との記載において、「暗号鍵K」と「AVデータを暗号化して転送するための暗号鍵」とは同一のものと解される。 また、上記(カ)の「【0078】さて、CH-A1/CH-B1についての暗号鍵(K1とする)が共有された後、ソース機器101は、暗号鍵k1でMPEG4データ(C1)を暗号化した映像データ[C1]k1をCH-A1/CH-B1によって送信し(S140)、シンク機器103は、CH-A1/CH-B1で受信した映像データ[C1]k1を暗号鍵k1で復号化した後に例えばこれをデコードして映像表示することができる。」との記載において、いずれも映像データを暗号化して転送するための鍵である「暗号鍵(K1とする)」及び「暗号鍵k1」は、上記(オ)に記載された「暗号鍵K」と同一の暗号鍵と解されること、また、映像データを暗号化して転送するための暗号鍵は、映像データを復号化するための暗号鍵でもあることが読み取れることから、引用文献1に記載の暗号鍵Kは、ソース機器から送信される暗号化されたAVデータを復号化するためのものであると解される。 したがって、引用文献1には、 認証鍵交換の手順は、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたAVデータを復号化するための暗号鍵を計算して共有するための情報である、g(Kｘ、Kaｕｔh)や整数Ncを送信する手順を含むこと が記載されたものと認められる。 以上のことから、引用文献1には、第2の実施形態の第3の方法として、以下の発明(以下、「引用発明」という。)が記載されている。 無線ネットワークであるBlｕeｔｏｏｔhを介し、ソース機器から送信される、ストリームも含む、暗号化されたAVデータをシンク機器で受信するための方法であって、 ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたAVデータの送信を開始し、該暗号化されたAVデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順と、 認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたAVデータを復号化するための暗号鍵を計算して共有するための情報である、g(Kｘ、Kaｕｔh)や整数Ncを送信する手順 を含む受信方法。 (3)対比 引用発明と、本件補正後発明とを対比する。 引用発明における「ソース機器」及び「ストリームも含む、暗号化されたAVデータ」は、本件補正後発明における「外部電子機器」及び「ストリームデータ」にそれぞれ相当する。 引用発明における「データバス」と、本件補正後発明における「無線ネットワークであるBlｕeｔｏｏｔh」とは、データの通信路という点で一致するから、引用発明の「無線ネットワークであるBlｕeｔｏｏｔhを介し、ソース機器から送信される、ストリームも含む、暗号化されたAVデータをシンク機器で受信するための方法」と、本件補正後発明の「データバスを介し、外部電子機器から送信されるストリームデータを受信するための受信方法」とは、”データの通信路を介し、外部電子機器から送信されるストリームデータを受信するための受信方法”である点で一致する。 引用発明における「ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順」は、シンク機器と、ソース機器との間の接続を確立するものであり、当該シーケンス初期手順に続いて行われる、ソース機器が暗号化されたAVデータの送信は、接続が確立されたことに応じてソース機器がシンク機器に対して行うものといえる。 そして、引用発明における「暗号化されたAVデータをシンク機器が受信して、ソース機器に対して認証を要求する」ことは、シンク機器が、暗号化されたAVデータを受信するのに応じ、ソース機器に対して認証要求を行うことと同じである したがって、引用発明における「ソース機器とシンク機器との間でチャネルを確立するシーケンス初期手順に続き、ソース機器が暗号化されたAVデータの送信を開始し、該暗号化されたAVデータをシンク機器が受信して、ソース機器に対して認証を要求することによって認証鍵交換の手続を始める手順」と、本件補正後発明における「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順」とは、同じものである。 引用発明における「認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたAVデータを復号化するための暗号鍵を計算して共有するための情報である、g(Kｘ、Kaｕｔh)や整数Ncを送信する手順」に関し、「認証鍵交換の手順」は、シンク機器のソース機器に対する認証の要求に応じて始まるものであるから、ソース機器からシンク機器に対して、g(Kｘ、Kaｕｔh)や整数Ncを送信する手順は、シンク機器の認証要求にソース機器が応じて行うものといえる。 また、引用発明において、ソース機器からシンク機器に対して情報が送信された場合に、シンク機器が当該情報を取得することは自明なことであり、ソース機器から送信される「g(Kｘ、Kaｕｔh)や整数Nc」は、いずれもシンク機器がAVデータを解読するために使用する情報であるといえるから、本件補正後発明における「暗号化ストリームデータを解読するための情報」と同じものである。 したがって、引用発明における「認証鍵交換の手順において、ソース機器からシンク機器に対して、ソース機器から送信される暗号化されたAVデータを復号化するための暗号鍵を計算して共有するための情報である、g(Kｘ、Kaｕｔh)や整数Ncを送信する手順」と、本件補正後発明における「上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する解読情報取得手順」とは、同じものである。 よって、本件補正後発明と引用発明とは、以下の点で一致し、また相違する。 (一致点) データの通信路を介し、外部電子機器から送信されるストリームデータを受信するための受信方法であって、 上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータを受信するのに応じ、上記外部電子機器に対する認証要求を行う認証要求手順と、 上記認証要求に応じて上記外部電子機器から送信される、暗号化ストリームデータを解読するための情報を取得する手順と を備える受信方法 (相違点) (相違点1) 本件補正後発明は、データの通信路が「データバス」であるのに対して、引用発明は、データの通信路が「無線ネットワークであるBlｕeｔｏｏｔh」である点。 (相違点2) 本件補正後発明は、「上記ストリームデータの受信が停止した後、再度上記外部電子機器からストリームデータが受信された場合に、再度上記認証要求を行う再認証要求手順」を備えるのに対し、引用発明は、当該再認証要求手順を備えることは明らかではない点。 (4)判断 上記相違点について判断する。 (相違点1)について; 暗号化されたAVデータを送受信するデータの通信路として、データバスを採用することは、原査定の拒絶理由に引用された特開2002-245718号公報(以下、「引用文献2」という。)に「【0002】【従来の技術】デジタル映像信号処理技術(中略)こうしたストリームデータの伝送に最も適したデジタルインターフェースとして、IEEE1394-1995規格に定められた高速シリアルバス(以下1394バスと記す」が有る。(中略)【0004】このようなコンテンツの不正なコピーを防止するための技術としてDTCP(Digiｔal Tｒanｓmiｓｓiｏn Cｏnｔenｔｓ Pｒｏｔecｔiｏn)方式が1394バスでは採用されている。」と記載されているように本願出願前に周知の技術事項であり、引用文献1にも、IEEE1394につき「【0036】次に、この確立されたチャネルを用いて、ストリームプロトコルのやり取りが行われる。(中略)なお、サブユニットとは、IEEE1394やBlｕeｔｏｏｔh等のAV機器で、ある機器内の機能を構成要素として論理的に記述する際に用いられる概念である(その詳細は1394AV/Cスペックに開示されている)。」のように言及されていることからみれば、引用発明において、暗号化されたAVデータを送受信するデータの通信路として、周知のデータバスであるIEEE1394を採用することは当業者が容易に想到し得た事項である。 よって、相違点1は格別のものではない。 (相違点2)について; 著作権保護のためにAVデータを暗号化して送受信する技術分野において、ストリームデータの受信が停止した場合に、シンク機器が暗号鍵を破棄することは、引用文献2に「【0029】ストリームの伝送を終了するときには、ソース側からのストリームを止め(手順1008)、ソースとシンク間のコネクションを破棄し(手順1009)、ソース側シンク側それぞれの鍵データを破棄する(手順1010、1011)。」と記載されているように周知の技術事項である。 そして、暗号鍵が破棄された後で再度暗号化されたAVデータがシンク機器に送信された場合に、当該シンク機器が復号のために暗号鍵を取得するよう構成することは当業者が当然に行うべき事項であることからすれば、引用発明において、シンク機器がAVデータの受信が停止した場合には暗号鍵を破棄すると共に、再度ソース機器から暗号化されたAVデータが受信された場合には、暗号鍵を取得するためにソース機器に対して再度認証の要求を行うよう構成することは当業者が容易に想到し得た事項である。 よって、相違点2は格別のものではない。 なお、ストリームデータの伝送が終了する場合の他、ストリームデータの受信が様々な原因で停止すなわち”中断”した場合において、受信を再開する時に認証鍵交換を行うことも当業者にとり周知の技術事項である。 (例、本願出願前に頒布された刊行物である特開平11-289326号公報に、従来の技術として以下の記載がある。(なお、下線は当審で付与した。) 「【0009】図10は、従来のデータ送受信システムにおいて、コントロールキーを更新するとした場合の、コントロールキー更新と認証・鍵交換の実行の関係を示す模式図である。図の横方向は、時間の経過を表し、一段目の帯は、STBがデータ信号を送信中であることを示す。2段目の矢印は、同じコントロールキーKcが使用されている範囲を示し、本図では途中でKc[1]からKc[2]に更新されたことを示している。3?5段目の帯は、各ケースにおけるVTR装置が受信状態であることを示し、帯が途切れている範囲は、受信が中断状態であることを示す。また、3?5段目の縦向きの両矢印は、認証・鍵交換が実行されたことを示す。 【0010】ケース1のVTR装置は、受信開始後に受信中断がないため、受信開始時に認証・鍵交換を実行し、以後は、コントロールキーKcの更新時のみに認証・鍵交換を実行するだけでよい。ケース2およびケース3のVTR装置は、受信開始後に受信中断が起こったため、受信再開時に認証・鍵交換を実行しなければならない。特に、ケース3のVTR装置においては、中断時間が短かったため、受信再開時にKcが更新されていないにも関わらず、改めて認証・鍵交換を実行しなければならず、他のケースに比べてトータルの実行回数が増えることとなる。」) したがって、AVデータの受信がストリームデータの伝送の終了する場合の他、様々な原因で中断した場合について進んで検討しても、引用発明において、AVデータの受信再開時にシンク機器が認証鍵交換の手順を実行するべく、AVデータを再度受信した時にソース機器に対して再度認証の要求を行うよう構成することは当業者が容易に想到し得た事項である。 上記で検討したごとく、相違点1及び相違点2は格別のものではなく、そして、本件補正後発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものではない。 以上のとおり、本件補正後発明は、引用発明及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。 4.結語 したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3.本願発明について 1.本願発明 平成19年10月9日付けの手続補正は上記のとおり却下されたので、本願発明は、上記「第2.補正却下の決定」の項中の「1.本願発明と本件補正後発明」の項で本願発明として認定したとおりのものである。 2.引用発明 引用発明は、上記「第2.補正却下の決定」の項中の「3.独立特許要件について」の項中の「(2)引用発明」の項で認定したとおりのものである。 3.対比・判断 そこで、本願発明と引用発明とを対比するに、本願発明は、上記本件補正後発明の「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信されるストリームデータ」から、認証要求手順に係るストリームデータの限定である「上記外部電子機器との接続が確立されたことに応じて当該外部電子機器から送信される」を省いたものである。 そうすると、本願発明の構成に当該限定を付加した補正後の発明が、上記「第2.補正却下の決定」の項中の「3.独立特許要件について」の項で検討したとおり、引用文献1に第2の実施形態の第3の方法として記載された発明である引用発明及び周知の技術事項に基づいて容易に発明できたものである。 (なお、引用文献1において、平成18年11月28日付け拒絶理由通知書において明示された箇所である同文献【0051】段落乃至【0083】段落に記載の第1の実施形態の第3の方法は、AVデータの送信が、シンク機器がソース機器へCP PLAYコマンドが送信されたことに応じて行われる点でのみ引用発明(第2の実施形態の第3の方法)と相違するものであることからみて、AVデータの送信について格別限定のない本願発明と、当該第1の実施形態の第3の方法として記載された発明とを対比した場合の一致点及び相違点は、本願発明と引用発明との一致点及び相違点と各々同一である。 したがって、本願発明は、引用発明と同様にして、引用文献1に第1の実施形態中の第3の方法として記載された発明から当業者が容易に発明をすることができたものといえる。) 4.むすび 以上のとおり、本願発明は、引用発明及び周知の技術事項に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第29条第2項の規定により、特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2009-10-28 |
| 結審通知日 | 2009-11-04 |
| 審決日 | 2009-11-17 |
| 出願番号 | 特願2003-278460(P2003-278460) |
| 審決分類 |
P
1
8・
572-
Z
(H04L)
P 1 8・ 121- Z (H04L) P 1 8・ 575- Z (H04L) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 新田 亮、青木 重徳 |
| 特許庁審判長 |
吉岡 浩 |
| 特許庁審判官 |
石井 茂和 宮司 卓佳 |
| 発明の名称 | 受信装置、及び受信方法 |
| 代理人 | 鈴木 伸夫 |
| 代理人 | 脇 篤夫 |