ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04Q |
|---|---|
| 管理番号 | 1268174 |
| 審判番号 | 不服2011-11357 |
| 総通号数 | 158 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2013-02-22 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2011-05-31 |
| 確定日 | 2013-01-04 |
| 事件の表示 | 特願2006-538390「ローカル受信機へのコンテンツ配布を制限するための方法及びシステム」拒絶査定不服審判事件〔平成17年 5月12日国際公開、WO2005/043797、平成19年 6月28日国内公表、特表2007-517424〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、平成16年11月1日(パリ条約による優先権主張外国庁受理2003年10月31日、米国)を国際出願日とする出願であって、平成22年4月22日付けで拒絶理由通知がなされ、同年10月26日付けで手続補正がなされたが、平成23年1月26日付けで拒絶査定がなされ、これに対し、平成23年5月31日に拒絶査定不服審判の請求がなされるとともに手続補正がなされたものである。 2.本願発明 本願の請求項22に係る発明(以下、「本願発明」という。)は、平成23年5月31日付け手続補正書の特許請求の範囲の「請求項22」に記載されたとおりの次のものと認める。 「【請求項22】 コンテンツを配布する方法であって、 制限された範囲のチャネル上に復号キーを送信し、 前記復号キーをシンクによって受信し、 前記受取り通知に応答して前記コンテンツを送信し、 前記復号キーを使用して前記コンテンツを復号する ことを含むことを特徴とする方法。」 なお、上記請求項22の記載のみからは、同請求項22でいう (1)「制限された範囲のチャネル上に復号キーを送信する」の主体、 (2)「前記受取り通知」の内容、 (3)「前記受取り通知に応答して前記コンテンツを送信する」の主体、 (4)「前記復号キーを使用して前記コンテンツを復号する」の主体、 がそれぞれ明確ではないが、明細書の段落【0031】?【0032】及びその他の発明の詳細な説明の記載から総合的に判断すれば、上記(1)「復号キー」と上記(3)の「コンテンツ」を送信する主体はソースであること、上記(4)の「復号キーを使用して前記コンテンツを復号する」の主体はシンクであること、そして上記(2)「前記受取り通知」は、シンクが復号キーを受信したことをソースに対して知らせる通知であることは、それぞれ明らかであるので、本審決では、上記のように解した。 3.引用例 原査定の拒絶の理由に引用された「特開2003-224556号公報」(以下、「引用例」という。)には、以下の事項が記載されている。 あ.「【0005】 【発明が解決しようとする課題】ここで、ある送信装置から、著作権を保護すべきAVデータ(ただし、暗号化したもの)を、受信装置に転送する場合を考える。当該AVデータをやりとりする範囲(ただし、受信装置が復号できる範囲)は、一定の範囲内(例えば、当該AVデータを使用できる正当な権限の範囲内(例えば、著作権30条の私的使用の範囲内)あるいはそれよりもさらに狭い範囲内)に制限され、そのような範囲を越えてのAVデータのやりとりは(視聴料や著作権料等の支払いが伴うようにするなどの措置を考えない限りは)できないようにされるのが望ましい。 【0006】一定の範囲内でのAVデータのやり取りの典型的な例は、IEEE1394や無線ネットワーク等のホームネットワークに閉じた通信である。 【0007】一定の範囲内を越えたAVデータのやり取りの典型的な例は、「公衆網(例えば、インターネットや、電話網等)」を介したやり取りである。 【0008】近い将来、デジタルネットワークの種類は、無線、パソコンネットワーク等と、色々な種類に増加するものと考えられるが、これらの多くでは著作権保護は考慮されていないのが現状である。 【0009】また、ネットワークはローカルなものから、グローバルなものまで幅広くあり、著作権保護の観点からは明確に区別されるのが望ましい。 【0010】本発明は、上記事情を考慮してなされたもので、著作権を保護すべきコンテンツ・データを暗号化して転送し復号して利用できる範囲を、一定の範囲内に制限することの可能な通信装置及び通信制御方法を提供することを目的とする。」 い.「【0023】 【発明の実施の形態】以下、図面を参照しながら発明の実施の形態を説明する。 【0024】図1に、本実施形態のネットワークシステムの構成例を示す。 【0025】図1は、ある家庭の家庭ネットワークと、これに接続されたネットワーク機器を示している。もちろん、図1に示したネットワーク機器以外に、他のネットワーク機器や、その他の装置が存在しても構わない。 【0026】図1に例示されるように、この家庭には、家庭ネットワークとして、イーサネット(有線ネットワーク)6と無線ネットワーク5が存在し、これらが無線基地局(無線アクセスポイント)4で相互接続されている。この無線基地局4は、ブリッジ(イーサネットブリッジ)の役割を果たす。無線ネットワーク5上でも、イーサネットフレーム(あるいは、これに順ずる形)で、パケットは転送されるものとする(ただし、これに限定するものではない)。例えば、IEEE802.11aや、IEEE802.11b等の無線LANがこれにあたる。さらに、無線ネットワーク5には、無線AV送信装置1と、無線AV受信装置2が、イーサネット6には有線AV受信装置3が、それぞれ接続されている。 【0027】無線AV送信装置1と、無線AV受信装置2との間では、AVデータのやり取りを行なう。無線AV送信装置1と、有線AV受信装置3との間についても同様である。無線AV送信装置1は、セットトップボックスやDVDプレーヤ等といったAVデータのソースデバイスとなり得る機器であり、無線AV受信装置2や有線AV受信装置3は、テレビやディスプレイ、スピーカ、あるいは録画・録音装置といった、AVデータのシンクデバイスとなり得る機器である。 【0028】図2に、無線AV送信装置1の内部構成例を示す。 【0029】図2に示されるように、無線AV送信装置1は、AVデータの生成や蓄積を行い、ネットワークに送出するAVデータのソースとなるAVデータ生成/蓄積部11、タイムスタンプ処理やシーケンス番号処理等、これらのAVデータのトランスポートレイヤ層の処理を行なうRTP処理部12、これらのパケットをTCP/IPのパケットで送受信するTCP/IPパケット送受信部13、暗号化等の著作権保護の処理が必要なデータに関して、AVデータの暗号化処理を行なう著作権保護暗号化部14、イーサネットフレームを送受信するイーサネットフレーム送受信部15、IPアドレスとイーサネットアドレスの対応を取るためのIP/イーサネットアドレス対応テーブル16、著作権保護のために、AV受信装置との間で認証や鍵交換等を行なうための著作権保護認証・鍵交換部17、無線ネットワークとのインタフェース部(無線ネットワークI/F部)18を備えている。 【0030】図3に、無線AV受信装置2の内部構成例を示す。 【0031】図3に示されるように、無線AV受信装置2は、無線ネットワークとのインタフェース部(無線ネットワークI/F部)28、イーサネットフレームを送受信するイーサネットフレーム送受信部25、著作権保護のために暗号化されて転送されてきたAVデータを復号化する著作権保護復号化部24、これらのパケットをTCP/IPのパケットで送受信するTCP/IPパケット送受信部23、タイムスタンプ処理やシーケンス番号処理等、これらのAVデータのトランスポートレイヤ層の処理を行なうRTP処理部22、受信したAVデータの再生や蓄積(録音や録画)を行い、AVデータのシンクとなるAVデータ再生/蓄積部21、IPアドレスとイーサネットアドレスの対応を取るためのIP/イーサネットアドレス対応テーブル26、著作権保護のために、AV送信装置との間で認証や鍵交換等を行なうための著作権保護認証・鍵交換部27を備えている。」 う.「【0040】さて、以下では、本実施形態の動作について説明する。なお、著作権保護の仕組みとしては、例えばDTCP(Digiｔal TｒanｓmiｓｓiｏnCｏnｔenｔ Pｒｏｔecｔiｏn)の仕組みを用いた場合を想定して説明する(なお、他の著作権保護の仕組みを用いても構わない)。DTCPについては、hｔｔｐ://ｗｗｗ.dｔcｐ.cｏmに詳しい。 【0041】図6に、本家庭ネットワークにおけるシーケンス例を示す。なお、図7に、無線AV送信装置1の認証・鍵交換に関する手順の一例を示し、図8に、無線AV受信装置2の認証・鍵交換に関する手順の一例を示す(なお、以下の各シーケンス例についても、無線AV送信装置1及び有線AV受信装置3の認証・鍵交換に関する手順の一例は、図7及び図8と同様である)。 【0042】ここでは、無線AV受信装置2が、無線AV送信装置1に対して、AVデータの送信を要求する場合を例にとって考える。このとき、例えばAV/Cプロトコル(1394トレードアソシエーションが規定した、AV機器制御用のコマンド、及びそのプロトコル)や、RTSP(IETFが規定した、WebサーバのAVストリーミング機能の遠隔制御用のプロトコル)を使って、TCP/IP上にてコマンド(プロトコル)のやり取りを行なう(S1)。 【0043】すると、無線AV送信装置1は、上記コマンドを受け付け、無線AV受信装置2に対して、AVデータの送信を開始する(S2,S3,S121)。このAVデータの送信は、TCP/IPのパケット(あるいはUDP/IPのパケットでも良い)にて行なわれる。実際には、図9に示すように、転送されるAVデータは、RTP(リアルタイムトランスポートプロトコル)(IETFにて標準化された、AVデータ転送用の転送プロトコル)にて転送されても良い。ここで、送信するデータは、著作権保護により保護すべきAVデータであるとする。この場合、RTPにて転送されるAVデータは、暗号化がなされた上で転送される(S2)。また、RTPパケットには、CCI(コピー制御情報)や、暗号管理情報、暗号再計算タイミング等の著作権保護用制御データが付与された形で、(暗号化された)AVデータが転送される。 【0044】これを受信した無線AV受信装置2は、受信したAVデータに暗号がかけられていることを発見しあるいはAVデータが暗号化されて転送されてくることを事前に察知するなりして(S101)、無線AV送信装置1に対して、暗号鍵(ここでは、暗号鍵=復号鍵とする)の入手を試みるべく認証・鍵交換手順を要求し(S4,S102,S122)、これを契機として、無線AV送信装置1と無線AV受信装置2との間で、認証・鍵交換手順を行う(S5,S103,S123)。 【0045】この際の認証・鍵交換の要求(S4)及び実際の認証・鍵交換手順(S5)は、図5にあるようなTCP/IPパケット上で行なわれるのではなく、図10にあるように、無線レイヤフレームに、AKE(認証・鍵交換)用のデータが直接搭載される形にて行なわれる。この無線レイヤヘッダのうち、「その無線レイヤフレームが、どのようなプロトコルのためのフレームであるか」を表示するフィールドとして、著作権保護プロトコルであること(例えば、DTCPであること)を意味する数値が入ることにしても良い。このようにすることにより、著作権保護(AKE)用のフレームが転送されていることが、受信側のノードは認識することができるようになる。 【0046】また、このAKE手順は、無線レイヤフレームを用いて行なわれるため、このAKE手順が無線ネットワーク5内に留まって処理されることが確実に保証される。 【0047】つまり、かりにTCP/IPパケットにてAKE手順を行なう場合を考えると、その場合には、隣の家同士や長距離あるいは国境を越えて(TCP/IPパケットが届くので)AKEパケットを交換することができるようになり、例えば著作権法30条の私的使用の範囲を越える範囲でのAVデータの転送(コピーを含む)がなされてしまう場合があり得る。 【0048】これに対して、本実施形態のようにAKE手順を無線レイヤフレームを用いて行なうことで、AKEがなされる最大範囲は、同一の無線ネットワーク上の中に留まることが保証される。なぜなら、無線レイヤフレームは、無線ネットワークを越えて転送されることが出来ないからである。 【0049】もちろん、この仕組みを強固にするために、「AKE手順を転送している無線フレームは、必ず、対向側のネットワークにブリッジ接続しない」という無線基地局やブリッジ装置を作成すると、上記の保証をより完全に行なうことが出来る。 【0050】さて、上記の認証・鍵交換手順が終了すると、無線AV送信装置1と無線AV受信装置2との間にて、暗号鍵の値の共有が行なえる状態になっていることを意味する。繰り返すと、この状態(2つのノード間で暗号鍵の値が共有できる状態)は、同じ無線ネットワーク5に接続されたノード同士に限定される。つまり、無線AV送信装置1と無線AV受信装置2との間では、無線レイヤ制御パケットの転送が可能なので、上記AKE手順が成立することが可能である。一方、無線AV送信装置1と有線AV受信装置3との間では、AKEのためのパケット(フレーム)のやりとりが、無線AV送信装置1から見て、無線基地局4から向こう側(無線基地局から、有線AV受信装置間)では不可能であるため、AKE手順が成功することがない。このことから、著作権保護が通用する区間を「無線ネットワーク内(それも、1つのIPサブネット内)」という形に限定することが可能となる。 【0051】このようにして、「無線ネットワークをこえたAKE、ひいては不当なAVデータの転送」を未然に防ぐことが可能となる。」 え.「【0059】また、図6や図12の手順において、AVデータ転送が開始された後に認証・鍵交換要求及び認証・鍵交換手順を行ったが、AVデータ転送が開始される以前に認証・鍵交換要求及び認証・鍵交換手順を行う構成も可能である。また、図6や図12の手順において、AVデータの転送が完了してから、認証・鍵交換要求及び認証・鍵交換手順を行うようにしてもよいし、AVデータの転送の途中で、認証・鍵交換要求及び認証・鍵交換手順を行うようにしてもよい。また、図6や図12の手順において、認証・鍵交換要求及び認証・鍵交換手順に成功した後に、あらためて暗号化されたAVデータを最初から転送する構成も可能である。また、図6や図12の手順において、認証・鍵交換要求や認証・鍵交換手順において、一方の装置から他方の装置にあるメッセージを出し、該他方の装置から該一方の装置に該あるメッセージに対する応答を返す際に、該一方の装置が該あるメッセージを出してからこれに対する該応答を受けるまでの時間が、予め定められた基準時間を超える場合には、該認証・鍵交換要求や認証・鍵交換手順を中止するようにしてもよい。・・・」 また、上記記載事項を関連する図面と技術常識に照らせば以下のことがいえる。 (1)引用例の「同一の無線ネットワーク」は、無線レイヤフレームにAKE(認証・鍵交換)用のデータが直接搭載される形になって行われるものであり、AKE手順を無線レイヤフレームを用いて行うことで、AKEがなされる最大範囲は、同一の無線ネットワーク上の中に留まることが保証されるものである。換言すれば、AKE用データに含まれる復号に用いられる暗号鍵(暗号鍵=復号鍵)は無線レイヤフレームが用いられることによって同一の無線ネットワーク以外には送信されないことが保証されるものであるから、引用例の上記無線レイヤフレームが伝送されるチャネルは、「制限された範囲のチャネル」と言い得る。 (2)引用例の「暗号鍵」は、暗号化され転送されたコンテンツデータを復号するためにも使用されるものであるから「復号キー」と言い得る。 (3)引用例の「無線AV受信装置」は、コンテンツや復号するための暗号鍵を使用してコンテンツを復号する装置であることから、「シンク」と言い得る。 (4)引用例の「無線AV受信装置」は、上記「あ.」の段落【0010】にも摘記したとおり、暗号化され転送されたコンテンツデータを暗号鍵を用いて復号して利用するものであることは明らかであるから、「復号キーを使用してコンテンツを復号する」機能を当然に有しているものである。 (5)上記「え.」の「AVデータ転送が開始される以前に認証・鍵交換要求及び認証・鍵交換手順を行う構成」は、「復号キー変換の後にコンテンツを送信する構成」を表している。 したがって、引用例には実質的に次の発明(以下、「引用発明」という。)が記載されているといえる。 「コンテンツを配布する方法であって、 制限された範囲のチャネル上に復号キーを送信し、 前記復号キーをシンクによって受信し、 復号キーの交換の後、前記コンテンツを送信し、 前記復号キーを使用して前記コンテンツを復号する ことを含むことを特徴とする方法。」 4.本願発明と引用発明との対比 本願発明と引用発明とを対比すると、両者間には以下の一致点、相違点があるといえる。 (一致点) 「コンテンツを配布する方法であって、 制限された範囲のチャネル上に復号キーを送信し、 前記復号キーをシンクによって受信し、 前記コンテンツを送信し、 前記復号キーを使用して前記コンテンツを復号する ことを含むことを特徴とする方法。」である点。 (相違点) 本願発明の「コンテンツを配布する方法」は、コンテンツを「受取り通知」に応答して送信するものであるのに対し、引用発明の「コンテンツを配布する方法」は、コンテンツを「受取り通知」に応答して送信するものであるとは限らない点。 5.判断 (1)上記相違点について 以下の事情を勘案すると、引用発明の「コンテンツを配布する方法」を、コンテンツを「受取り通知」に応答して送信するものとすることは、当業者が容易に推考し得たことというべきである。 ア.引用発明において、復号キーの交換が正常に行われない場合には、暗号化コンテンツを送信してもその送信が無駄になってしまうことは明らかであるから、引用発明において、コンテンツの送信を復号キーの交換の完了後に行うようにするのが望ましい場合があることは、当事者に自明である。 イ.引用発明において、コンテンツの送信を復号キーの交換の完了後に行うことを確実にするために、「シンクが復号キーを受け取ったことをソースに知らせ、ソースがそれを確認した後にコンテンツを送信する」という手順の採用が有用であることも当業者に自明である。 ウ.引用発明において、上記「シンクが復号キーを受け取ったことをソースに知らせ、ソースが確認した後にコンテンツを送信する」という手順を採用できない理由はない。 エ.以上のことは、引用発明の「コンテンツを配布する方法」を、コンテンツを「受取り通知」に応答して送信するものとすることが、当業者にとって容易であったことを意味している。 (2)本願発明の効果について 本願発明の構成によってもたらされる効果は、引用発明の記載事項及び周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。 6.むすび 以上のとおり、本願発明は、引用発明の記載事項及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-07-31 |
| 結審通知日 | 2012-08-06 |
| 審決日 | 2012-08-17 |
| 出願番号 | 特願2006-538390(P2006-538390) |
| 審決分類 |
P
1
8・
121-
Z
(H04Q)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 冨田 高史 |
| 特許庁審判長 |
小曳 満昭 |
| 特許庁審判官 |
本郷 彰 近藤 聡 |
| 発明の名称 | ローカル受信機へのコンテンツ配布を制限するための方法及びシステム |
| 代理人 | 西島 孝喜 |
| 代理人 | 熊倉 禎男 |
| 代理人 | 大塚 文昭 |
| 代理人 | 須田 洋之 |