【事件の表示】
　特願２００６−５５３３０２「プログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法」拒絶査定不服審判事件〔平成１７年　９月　１日国際公開、ＷＯ２００５／０８１５３４、平成１９年１１月２２日国内公表、特表２００７−５３４２３０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
その１．手続の経緯
　本願は，２００５年２月１１日（パリ条約による優先権主張外国庁受理２００４年２月１３日　アメリカ合衆国）を国際出願日とする出願であって，
　平成１８年９月２５日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，平成２２年１月２７日付けで審査官により拒絶理由が通知され，これに対して同年７月２６日付けで意見書が提出されると共に手続補正がなされたが，同年１２月２２日付けで審査官により拒絶査定がなされ，これに対して平成２３年５月２日付けで審判請求がなされると共に手続補正がなされ，同年６月２４日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，同年１１月８日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２４年１月２５日付けで回答書の提出があったものである。
　
その２．平成２３年５月２日付けの手続補正の却下の決定
　結論
　
　平成２３年５月２日付け手続補正を却下する。
　
　理由
　
１．補正の内容
　平成２３年５月２日付けの手続補正（以下，「本件手続補正」という）により，特許請求の範囲は，
「　【請求項１】
　コンピュータによって実行される，暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって，
　所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること（１７０１）であって，前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは，復号されることなくスケーリングされること（１７０１）と，
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）と，
　前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）と
　を含み，
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは，トランスコーダ可読ヘッダとは独立に暗号化可能であり，
　トランスコードの際に，前記トランスコーダ可読ヘッダを読み出すことによって，前記複数の結合可能部分のうちの少なくとも１つの結合可能部分およびこれに関する暗号チェックサムが削除される
　方法。
　　【請求項２】
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも１つの部分および前記暗号チェックサムを暗号化すること
　をさらに含む請求項１に記載の方法。
　　【請求項３】
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも１つの結合可能部分は，前記プログレッシブ暗号化されたスケーラブルデータ列の他の部分とは独立に解読する
　請求項１に記載の方法。
　　【請求項４】
　前記暗号チェックサムは，前記プログレッシブ暗号化されたスケーラブルデータ列の結合可能部分について計算される
　請求項１に記載の方法。
　　【請求項５】
　第１の暗号チェックサムが，第１の結合可能部分について計算され，
　第２の暗号チェックサムが，第２の結合可能部分，前記第１の結合可能部分および前記第１の暗号チェックサムの結合について計算される
　請求項１に記載の方法。
　　【請求項６】
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，
　前記結合可能部分および前記暗号チェックサムに関係した情報
　を含む
　請求項１に記載の方法。
　　【請求項７】
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，データパケットのトランスコードを行うことを可能にする
　請求項１に記載の方法。
　　【請求項８】
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，前記プログレッシブ暗号化されたスケーラブル列の前記結合可能部分および前記暗号化チェックサムとは独立に書き込まれる
　請求項１に記載の方法。
　　【請求項９】
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分のそれぞれは，送信可能パケットにおける他の結合可能部分とは独立に，前記パケットから抽出される
　請求項１に記載の方法。」（以下，上記引用の請求項各項を，「補正前の請求項」という）から，
「　【請求項１】
　コンピュータによって実行される，暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって，
　トランスコーダが，所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること（１７０１）であって，前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは，復号されることなくスケーリングされること（１７０１）と，
　前記トランスコーダが，前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）と，
　前記トランスコーダが，前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）と
　を含み，
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは，トランスコーダ可読ヘッダとは独立に暗号化可能であり，
　トランスコードの際に，前記トランスコーダ可読ヘッダを読み出すことによって，前記複数の結合可能部分のうちの少なくとも１つの結合可能部分およびこれに関する暗号チェックサムが削除され，
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムとは独立に書き込まれる
　方法。
　　【請求項２】
　前記トランスコーダが，前記プログレッシブ暗号化されたスケーラブルデータ列の前記
少なくとも１つの部分および前記暗号チェックサムを暗号化すること
　をさらに含む請求項１に記載の方法。
　　【請求項３】
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも１つの結合可能部分は，前記プログレッシブ暗号化されたスケーラブルデータ列の他の部分とは独立に解読する
　請求項１に記載の方法。
　　【請求項４】
　前記暗号チェックサムは，前記プログレッシブ暗号化されたスケーラブルデータ列の結合可能部分について計算される
　請求項１に記載の方法。
　　【請求項５】
　第１の暗号チェックサムが，第１の結合可能部分について計算され，
　第２の暗号チェックサムが，第２の結合可能部分，前記第１の結合可能部分および前記第１の暗号チェックサムの結合について計算される
　請求項１に記載の方法。
　　【請求項６】
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，
　前記結合可能部分および前記暗号チェックサムに関係した情報
　を含む
　請求項１に記載の方法。
　　【請求項７】
　前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは，データパケットのトランスコードを行うことを可能にする
　請求項１に記載の方法。
　　【請求項８】
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分のそれぞれは，送信可能パケットにおける他の結合可能部分とは独立に，前記パケットから抽出される
　請求項１に記載の方法。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
２−１．新規事項
　本件手続補正が，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件手続補正が，平成２３年５月２日付けで提出された明細書，請求の範囲の日本語による翻訳文，及び，国際出願の願書に添付された図面（以下，これを「当初明細書等」という）の範囲内でなされたものであるかについて，以下に検討する。
　
　本件手続補正は，補正前の請求項１に記載の，
「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること（１７０１）」，
「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）」，
「前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）」
　を，
「トランスコーダが」，「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること（１７０１）」，
「トランスコーダが」，「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）」，
「トランスコーダが」，「前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）」
　と補正するものである。
　
　そこで，上記引用の請求項１記載における「（１７０１）」，「（１７０３）」，「（１７０５）」，「（１７０７）」という番号が付された各処理について，当初明細書等の記載内容を検討すると，
　当初明細書等の段落【０１４９】に，
「【０１４９】
　図１７は，一実施の形態による，プログレッシブ暗号化されたスケーラブルデータ列を符号化するための方法で実行されるステップのフローチャートである。
　ステップ１７０１において，所望のスケーラブル属性を保有するようにスケーリングされるプログレッシブ暗号化されたスケーラブルデータ列のバージョンを生成するために結合するプログレッシブ暗号化されたスケーラブルデータ列の結合可能部分を特定するデータが，プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる。
　一実施の形態によれば，上記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンは，復号されることなくスケーリングされる。
　ステップ１７０３において，プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分について，暗号チェックサムが計算される。
　ステップ１７０５において，暗号チェックサムが，プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けられる。」（以下，「引用記載１」という）
　と記載されていて，上記引用の記載から明らかなように，引用記載１，及び，関連する図面である【図１７】は，「符号化するための方法」を示したものであって，該方法を，“誰”，或いは，“何”が行うかまでは記載されていない。
　そして，引用記載１の「プログレッシブ暗号化されたスケーラブルデータ列を符号化するための方法で実行される」から，当該技術分野における技術常識を勘案すれば，引用記載１のステップは，「符号化器」によって実行すると解するのが妥当である。
　
　次に，上記「（１７０１）」，「（１７０３）」，「（１７０５）」，「（１７０７）」という番号が付された各処理を“誰”，或いは，“何”が行っているかを更に検討すると，
　当初明細書等には，
「【００３７】
　図３は，本発明の一実施の形態による簡略化したデータ配信システム３０の機能要素を示すブロック図である。
　図３の例では，システム３０は，符号化器３２，トランスコーダ３４，第１の復号器３６，および第２の復号器３８を含む。
　システム３０は，同様の機能要素だけでなく他のタイプの機能要素（たとえば，ストレージ要素，パケット化器，ストリーミング要素等）も含むより大きなシステムまたはネットワークの一部であってもよい。
　本実施の形態では，符号化器３２はデータを符号化（圧縮）し，
トランスコーダ３４は符号化データをトランスコード（たとえば，スケーリング）し
　これらの機能は，単一のデバイスで実行することもできるし，或るタイプのネットワークにおいて接続することができる１つまたは２つ以上のデバイス間に分散させることもできる。
【００３８】
　また，要素３２，３４，３６，および３８は，今説明した機能以外の機能も実行することができる。
　たとえば，
符号化器３２は，データを暗号化して，データをチェックするためのチェックサムまたは暗号化チェックサムを計算することもでき，また符号化データを別のブロックへ送信する前に符号化データをスケーリングすることもでき
　一実施の形態では，符号化器３２は，ＪＰＥＧ２０００標準規格に基づいた符号化方式を使用する。
【００３９】
　加えて，
トランスコーダ３４は，そうではなくて，符号化データのスケーリングされたバージョンを別のトランスコーダへ送信することができ
　また，復号器３６は，たとえスケーリングされたデータをトランスコーダ３４から受信しても，そのスケーリングされたデータをさらにスケーリングすることができる。
　さらに，復号器３６および３８は，エンドユーザデバイスでなくてもよい。
　たとえば，復号器３６および３８は，符号化データを復号して，その復号データを，たとえば移動電話へ送信することができる。
　移動電話は，画像プロダクトをレンダリングして表示する。」（以下，「引用記載２」という。なお，下線は当審にて，説明の都合上附加したものである。以下，同じ），
　という記載が存在し，引用記載２中の段落【００３８】に記載の内容から，
「符号化器３２」が，「データを暗号化」すること，「暗号化チェックサムを計算すること」，及び，「符号化データを別のブロックへ送信する前にスケーリングすること」は明らかである。
　
　しかしながら，当初明細書等に，
「【００７２】
　
図６は，本発明の一実施の形態に従ってデータをスケーリング（たとえば，トランスコード）するためのプロセスのフローチャート６０である
　
図７は，本発明の一実施の形態に従ってデータを符号化するためのプロセスのフローチャート７０である
　図８は，本発明の一実施の形態に従ってデータを復号するためのプロセス８０のフローチャートである。
　具体的なステップがフローチャート６０，７０，および８０に開示されているが，このようなステップは例示である。
　　　　　　　　　　　　　・・・・（中略）・・・・
【００７３】
　一般に，
フローチャート６０は，図５Ａおよび図５Ｂのスケーラ５４（たとえば，図３のトランスコーダ３４または復号器３８）によって実施され
フローチャート７０は，図３，図４Ａ，および図４Ｂの符号化器３２によって実施され
　しかしながら，上述したように，異なる機能ブロックが，異なる機能を実行することもできるし，１つのデバイスが，複数の機能を実行することもできるし，１つまたは複数の機能を複数のデバイス間に分散することもできる。
【００７４】
　最初に図６を参照して，ステップ６１において，符号化データ列が，（たとえば，ビットストリームまたはファイルにおいて）アクセスされる。
　符号化データは，そのデータを符号化するのに使用された符号化方式に従って編成されている。
　一実施の形態では，符号化方式は，ＪＰＥＧ２０００標準規格に基づいている。
　符号化データの一部または全部は暗号化されている場合もある。
　　　　　　　　　　　　　・・・・（中略）・・・・
【００７９】
　ステップ６４において，スケーラブルプロファイルデータが，符号化データにおいてセグメントを突き止めるのに使用される。
　重要なことは，セグメントが，スケーリングデバイスによる符号化方式の知識を必要とすることなく見つけられるということである。
【００８０】
　ステップ６５において，符号化データのスケーリングされたバージョンが，セグメントを使用して作成される。
　また，
符号化データのスケーリングされたバージョンは，暗号化データを解読することなく作成される
【００８１】
　ステップ６６において，一実施の形態では，符号化データのスケーリングされたバージョンが下流デバイスへ転送される。
　　　　　　　　　　　　　・・・・（中略）・・・・
【００８２】
　ステップ６７において，一実施の形態では，変更された参照情報（たとえば，変更されたスケーラブルプロファイルデータ）が，符号化データのスケーリングされたバージョンに基づいて生成される。
　スケーリングされたバージョンのセグメントは，符号化方式とは独立に，スケーラブル属性の選択された値に関連付けられ，それによって，別のデバイスが，符号化方式の知識を必要とすることなく，スケーリングされたバージョンにおいてセグメントを突き止めることが可能になり，スケーリングされたバージョンをスケーリングすることが可能になる。
　変更された参照情報は，符号化データのスケーリングされたバージョンと共に記憶することもできるし，それとは別に記憶することもできる。
【００８３】
　次に図７を参照して，ステップ７１において，データが，符号化方式を使用して符号化され，ファイルに記憶される。
　一実施の形態では，この符号化方式は，ＪＰＥＧ２０００標準規格に概ね準拠している。
【００８４】
　ステップ７２において，ファイルにおけるデータセグメントのロケーションが特定される。
【００８５】
　ステップ７３において，データセグメントおよびスケーラブル属性の選択された値がインデックスされる。
　スケーラブル属性は，その後のスケーリングオペレーションで符号化データをどのようにスケーリングするかを指定する。
　
インデックスは，符号化方式とは独立であり，デバイスが，符号化方式の知識を必要とすることなく，セグメントを突き止めることを可能にし，かつ符号化データをスケーリングすることを可能にする
　一実施の形態では，スケーラブル属性の選択された値は，符号化デバイスに入力される。
【００８６】
　ステップ７４において，データセグメントおよびスケーラブル属性の選択された値のインデックスを含む参照情報が記憶される。
　一実施の形態では，このインデックスは，符号化データのファイルに追加される。
　別の実施の形態では，このインデックスは，ファイルとは別に記憶される。
【００８７】
　
ステップ７５において，一実施の形態では，符号化データの少なくとも一部が暗号化される。　このような一実施の形態では，符号化データの各データセグメントは，プログレッシブ暗号化される
　と記載され，引用記載３中の段落【００７２】，段落【００７３】，及び，段落【００８０】に記載された事項から，
「符号化データのスケーリングされたバージョンは，暗号化データを解読することなく作成される」のは，「トランスコーダ」によってである点が読み取れ，
　当初明細書等の，
「【０１１８】
　図１２は，
本発明の一実施の形態による，復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャートである
　ステップ１２０１において，暗号化スケーラブルメディアに関連付けられるデータであって，所望のスケーラブル属性を保有するようにスケーリングされるメディアを生成するために結合する暗号化スケーラブルメディアの部分を特定するデータが，アクセスされる。
　ステップ１２０３において，暗号化スケーラブルメディアの部分の１つまたは２つ以上および関連した暗号チェックサムが結合されて，送信可能なデータ列にされる。
　ステップ１２０５において，スケーラブルメディアに関連付けられるデータであって，所望のスケーラブル属性を保有するようにスケーリングされるメディアを生成するために結合するスケーラブルメディアの部分を特定するデータが，再マッピングされる。
【０１１９】
　ステップ１２０７において，スケーラブルメディアの部分に関連付けられるデータであって，スケーラブルメディアの部分を暗号化するのに使用される暗号化システムの保護属性を特定するデータが，再マッピングされる。
　暗号化スケーラブルメディアの１つまたは２つ以上の部分および関連した暗号チェックサムは，暗号化スケーラブルメディアのスケーリングされたバージョンを構成できることが十分理解されるはずである。」（以下，「引用記載４」という），
　という記載が，「本発明の一実施の形態による，復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャート」であることから，引用記載３について指摘した事項と勘案すると，引用記載４における「本発明の一実施の形態による，復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャート」は，「スケーラ」，即ち，「トランスコーダ」によって行われているものと解される。
　
　ここで，引用記載４における「関連チェックサムが結合され」るとは，どのような処理であるか，当初明細書等に記載の内容を，更に検討すると，
　まず，補正後の請求項１に，「プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付ける」と記載されていることから，補正後の請求項１に記載の「スケーリング」には，「トランケート」が含まれることは，明らかである。
　そして，「トランケート（英語原文；ｔｒｕｎｃａｔｅ）」とは，“〔長い文章｛ぶんしょう｝・文字列｛もじれつ｝などを〕切り詰める，〔数を〕切り捨てる”ことを意味するものであって，その具体的処理については，当初明細書等の，
「【０１３１】
　本実施の形態では，トランスコードセッションが行われると（たとえば，４１７），トランスコーダは，所望のスケーリング結果を達成するために，選択されたトランケート可能単位をトランケートすることができる。
　例示の実施の形態によれば，トランスコードされているメディアセグメントが暗号化されている場合，この形式のトランスコードを実行するのに，解読は必要とされない。
　図１４Ａに示す例では，トランケート可能単位Ｂおよびその関連した暗号チェックサム４１６がトランケートされる。
　トランケートされずかつ解読されない，メディアセグメントの残りの部分４１８は，その後，その必要な暗号チェックサムＣＣＳ（Ａ）４１５，独立復号可能部分Ａ４０３，およびヘッダ４１４が完全な状態のままで転送される。」（以下，「引用記載５」という），
　および，関連する図面である【図１５Ａ】，【図１５Ｂ】に記載された内容から，
　“セグメントＡ，Ｂ，Ｃとその暗号チェックサムＣＳＳ（Ａ），ＣＳＳ（Ｂ），ＣＳＳ８（Ｃ）から構成されるスケーラブルメディアコンテンツ列から，セグメントＢを，トランケートするとは，セグメントＡ，Ｃとその暗号チェックサムＣＳＳ（Ａ），ＣＳＳ８（Ｃ）から構成されるスケーラブルメディアコンテンツ列を生成する”ことであって，当該「トランケート」処理においては，「暗号チェックサム」は，関連する「セグメント」と共に，「スケーラブルメディアコンテンツ列」から削除されるものであって，このとき，新たな「暗号チェックサム」が計算されるものでないことは，引用記載５から明らかである。
　また，当初明細書等の上記に引用した記載以外の箇所において，「復号することなく暗号化スケーラブルメディアをスケーリングする」処理過程の何れかにおいて，「トランスコーダ」，或いは，「スケーラ」によって，「暗号チェックサム」が計算されることは記載されてない。
　以上のとおりであるから，
　補正後の請求項１に記載の，
「前記トランスコーダが，前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）と」
　は，当初明細書等に記載されたものではない。
　
　よって，本件手続補正は，平成１８年９月２５日付けで提出された明細書，請求の範囲の日本語による翻訳文，及び，図面の範囲内でなされたものではない。
　
３．補正却下むすび
　したがって，本件手続補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，結論のとおり決定する。
　
その３．本願発明について
　平成２３年５月２日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明は，上記項目１において，補正前の請求項１として引用した，平成２２年７月２６日付けの手続補正により補正された特許請求の範囲の請求項１に記載された次のとおりのものである。
　
「コンピュータによって実行される，暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって，
　所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを，前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること（１７０１）であって，前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは，復号されることなくスケーリングされること（１７０１）と，
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）と，
　前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）と
　を含み，
　前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは，トランスコーダ可読ヘッダとは独立に暗号化可能であり，
　トランスコードの際に，前記トランスコーダ可読ヘッダを読み出すことによって，前記複数の結合可能部分のうちの少なくとも１つの結合可能部分およびこれに関する暗号チェックサムが削除される
　方法。」
　
その４．引用刊行物に記載の発明
　一方，原審が拒絶理由に引用した，本願の第１国出願前に既に公知である，「Debargha Mukherjee, et al., Structured Scalable Meta-formats(SSM) Version 2.0 for Content Agnostic Digital Item Adaptation - Principles and Complete Syntax, [online], 2003年4月21日」（以下，これを「引用刊行物１」という）には，次の事項が記載されている。
　
Ａ．「Abstract
　This paper develops an end-to-end methodology for representation and adaptation of arbitrary scalable content in a fully content non-specific manner. Scalable bit-streams are naturally organized in a symmetric multi-dimensional logical structure, and any adaptation is essentially a downward manipulation of the structure. Higher logical constructs are defined on top of this multi-tier structure to make the model more generally applicable to a variety of bit-streams involving rich media. The resultant composite model is referred to as the Structured Scalable Meta-format (SSM). Apart from the implicit bit-stream constraints that must be satisfied to make a scalable bit-stream SSM-compliant, two other elements that need to be standardized to build a complete adaptation and delivery infrastructure based on SSM are: (1) a binary or XML description of the structure of the bit-stream resource and how it is to be manipulated to obtain various adapted versions; and (2) a XML specification of outbound constraints derived from capabilities and preferences of receiving terminals. By interpreting the descriptor and the constraints a universal adaptation engine can adapt the content appropriately to suit the specified needs and preferences of recipients, without knowledge of the specifics of the content, its encoding and/or encryption. With universal adaptation engines, different adaptation infrastructures are no longer needed for different types of scalable media.」(５頁１行〜１９行)
（要約
　この論文は，完全に，コンテンツに非特異的な方法において，任意のスケーラブル・コンテンツの表現と適応のためのエンド・ツー・エンドの方法論を示すものである。スケーラブルなビット・ストリームは，必然的に，対照的な多次元な論理的構造を形成し，そして，任意の適応化が，本質的にその構造の下向きの操作である。より上位の論理構造は，リッチ・メディアを含む，様々なビット・ストリームに，より一般的に適用可能であるように，この多層構造上に定義されている。結果として得られる合成モデルは，構造化スケーラブル・メタフォーマット(SSM)と呼ばれる。SSMに準拠したスケーラブルなビット・ストリームを生成しなければならないという，暗黙のビットストリーム制約は別にして，SSMに基礎を置く，完全な適応化と，伝達基盤を構築するために標準化される必要がある異なる２つの要素，（１）二値，或いは，ビット・ストリーム・リソースの構造，および，種々の適合したヴァージョンを得るために，それをどのように扱えるかとの，二値，或いは，XML表現と，（２）受信端末の能力と優先度に由来する送信制限のXMLの仕様，がある。制約事項と記述子を解釈することで，汎用適応化エンジンは，それを符号化，及び／または，暗号化するための，そのコンテンツの仕様の知識なしに，規定された要求と受信者の能力に適合するように，適切に適応化することができる。汎用適応化エンジンによって，異なる適応化基盤は，最早，スケーラブル・メディアの異なるタイプを必要としない。当審にて訳出，以下，同じ）
　
Ｂ．「2. Digital Item Adaptation with SSM
2.1 SSM based Delivery Model
  Consider Figure 1, which shows a generic media delivery model, where media data created by the originator is routed through an arbitrarily long chain of adaptation engines before reaching an eventual recipient. It is assumed that both the originator of the media as well as the software or hardware system used to experience it at the recipient end understand the actual media-encoding format. It is likely that either the same company created both the media content and the experiencing system, or the creator opened up its technology for vendors to develop the experiencing system, or the media format is an SSM-compliant open standard.
  Irrespective of the actual content-type and its encoding however, the scalable resource bit-stream is conformant with SSM, which all intermediate adaptation engines can interpret and manipulate. These engines receive SSM compliant scalable content, and deliver adapted content over multiple outbound streams. All content after adaptation is also SSM meta-format compliant so that it can be re-adapted at a subsequent stage of delivery.
  Along with the SSM-compliant media bit-stream an adaptation engine also processes a description meta-data (shown in thin white arrows in Figure 1) that contains vital information for the adaptation engine about all possible adaptations. The SSM model restricts the possible adaptation choices and allows a compact representation of this description. The adaptation engine not only adapts the media bit-stream but also the description meta-data, so that a subsequent stage of adaptation can be applied. There are a variety of possibilities for representing and conveying this information to adaptation engines. While in MPEG-21 DIA the trend is to use XML, it is to be noted that representing this information in binary form as part of the media bit-stream itself is a straightforward extension, and may even be preferred based on considerations of compactness and manageability. This information is referred to as resource description metadata.」（９頁９行〜１０頁６行）
（２．ＳＳＭによるデジタルアイテムの適用
　２．１　ＳＳＭベースの配信モデル
標準的な，メディア配信モデルを示す，図１を検討すると，そこでは，発信者によって生成されたメディアは，最終的な受信者に到達する前に，適宜の長さの適応化エンジンの鎖を通過する。メディアの発信は，受信者の終端で，それを体験するために用いられる，ソフトウェア，或いは，ハードウェアと同じく，実際のメディア符号化フォーマットを理解していると仮定する。同一の会社が，メディア・コンテンツと，体験システムの両方を作成しているか，或いは，制作者が，体験システムを開発するベンダーに，その技術を公開しているか，或いは，メディアのフォーマットが，SSM準拠のオープン・スタンダードであることが望ましい。
　実際のコンテンツ−タイプとそれの復号がどのようなものかに関係なく，スケーラブル・リソースのビット・ストリームは，全ての中間の適応化エンジンが読み取り，操作することができる，SSMで整合している。これらのエンジンは，SSM準拠のスケーラブル・コンテンツを受信し，多重出力ストリームに乗せて，適応化されたコンテンツを配信する。適応後の全てのコンテンツもまた，SSMのメタ−フォーマットに準拠しているので，それは，配信の後段において，再適応化されることが可能である。
　SSM準拠のメディア・ビット・ストリームと共に，適応化エンジンは，全ての可能な適応についての適応化エンジンのための，不可欠な情報を含む，記述メタ-データ（図１の細い白い矢印を参照されたい）も処理する。SSMモデルは，可能な適応化の選択を制限し，この記述のコンパクトな表現を許可する。適応化エンジンは，適応化の後段で適応化を受けることが可能になるように，メディア・ビット・ストリームだけでなく，記述メタ-データにも，適応化を行う。適応化エンジンに，この情報を示し，伝達するための，様々な可能性が存在する。MPEG-21　DIAの間では，XMLを用いる傾向があり，それは，それ自身が，メディア・ビット・ストリームの一部として，二値形式で，この情報を表現することが，単純な拡張であり，またさらに，緊密さと扱いやすさの考察に基づくことが望ましい。この情報は，リソース記述メタデータと呼ばれる。）
　
Ｃ．「  Note that while the originator/creator of the media as well as the recipients/consumers of the media must have specific knowledge about the encoding in order to provide an experience for the end-user, the intermediate infrastructure does not need to know what the content is and how it has been encoded in order to adapt appropriately. The adaptation operation is based purely on an interpretation of the resource descriptor metadata and the outbound constraints, and does not depend on the specifics of the actual content. Furthermore, the content itself can be encrypted, and transcoding can still proceed as before in the encrypted domain.」（１０頁１４〜２１行）
（メディアの受信者/消費者と同様にメディアの発信者/制作者も，エンドユーザに経験を供給するために符号化に関する特定の知識を持っていなければならないが，内容は何か，また，それがどのように適切に適応化するためにコード化されたか，中間のインフラストラクチャーが知る必要はないことに注意する。適応化処理は，単に，リソース記述メタデータと出力制約に基づき，実際のコンテンツの仕様には依存しない。さらに，コンテンツは，それ自身，暗号化され得，トランスコーディングは，暗号化された領域において，以前どおりに開始することができる。）
　
Ｄ．「2.3 Relation to Network Packetization
  It is important to realize that while SSM is about formats for generic scalable content and meta-data describing how format-compliant scalable content is to be adapted, in an actual delivery scenario the content would probably need to be packetized and transmitted. In this regard, among various design choices, there are two that are of particular interest, one based on interpretation of SSM as a file-format, and another based on interpretation as a packet-format. 
 In the file-format usage case, the scalable resource is actually much larger than a typical network packet. Either the adaptation engine adapts an entire SSM file in one shot  before network packetization and transmission, or the adaptation is conducted downstream possibly in multiple stages. In the latter case however, it is important to realize that it is not necessary that the entire SSM compliant resource be available at the adaptation engine before the adaptation operation can commence. In fact, the resource description and the outbound constraint specifications are all that are needed for an adaptation engine to decide how to adapt the media content. As long as the meta-data has been received in full, the scalable bit-stream resource in Figure 3 may come in stages in multiple network packets, and either forwarded or dropped or partially dropped by the engine as they arrive, based on the adaptation decisions already made. Thus, the same adaptation model applies both to files transcoded in one shot as well as to a streamed file.
  In the packet-format case, the entire SSM compliant content comprises one packet, which can be adapted by a mid-stream adaptation engine and transmitted. Packet based scalable adaptation based on truncation has been considered before [28], [29]. In this scenario, it may make more sense to include the resource description as part of the packet, using a form of binary encoding rather than XML.
  In the rest of this document, we will describe the specifics of the SSM framework: how a generic scalable bit-stream is modeled and what the required constraints are, what information is contained in the resource description metadata (XML) that goes with the resource, and how the capabilities and preferences are conveyed in the outbound constraints specifications (XML). We will also describe how the adaptation decisions are made at a network adaptation engine.」（１１頁２２行〜１２頁２１行）
（２．３　ネットワーク　パケット化との関係
SSMが，全体的なスケーラブル・コンテンツ，および，どのようにフォーマット準拠のスケーラブル・コンテンツが適応化されるかを記述するメタデータのためのフォーマットについてである間は，現実の送信シナリオにおいて，コンテンツが，パケット化され，送られる必要性があるであろうことを理解することが重要である。この際，種々のデザイン選択の間で，特に興味のあるものが２つ存在する。１つは，ファイル−フォーマットとしてのSSMの解釈に基礎を置くもの，他は，パケット−フォーマットとしての解釈に基礎を置くものである。
　ファイル−フォーマット用法の場合において，スケーラブル・リソースは，実際に，標準的なネットワーク・パケットよりずっと大きい。適応化エンジンが，ネットワーク・パケット化，及び，送信前に，全部のSSMファイルを，１回で，適応化するか，或いは，適応化は，多重ステージにおいて，場合により，ダウンストリームに実施されるかの，何れかである。しかしながら，後の場合においては，全てのSSM準拠のリソースが，適応化処理を開始することができる以前に，適応化エンジンによって，取得可能である必要がないことを理解することが重要である。実際，リソースの記述と，出力制約の仕様は，メディア・コンテンツに，どのように適応化を行うかを決定するために，適応化エンジンによって必要とされる，全てである。メタ-データが，全て，受信されているのであれば，図３における，スケーラブル・ビット・ストリームは，多重ネットワーク・パケットのステージに入り，既に作られている適応化決定を基礎とし，それらが到着するとして，エンジンによって，送られるか，落とされるか，部分的に落とされるかの何れかである。それ故，同一の適応化モデルが，ストリーム化されたファイルと同じように，１回でコード変換されたファイルにも当てはまる。
　パケット−フォーマットのケースにおいて，全てのSMM準拠のコンテンツは，１つのパケットからなり，それは，途中の最適化エンジンで最適化され，転送され得るものである。トランケ−ションに基づくスケーラブルな最適化に基づいたパケットは，前の［２８］，［２９］で検討されていた。このシナリオにおいては，XMLよりはむしろ，バイナリに変換する形式を用いることの方が理にかなっている。
　この文章の残りでは，どのようにして，全体的なスケーラブル・ビット−ストリームが形づくられ，要求される制約は何か，どの情報が，リソースに属するリソース記述メタデータ（XML）に含まれるか，そして，どのようにして，能力と優先事項が，出力制約の仕様（XML）で運ばれるかといった：SSMの構造の仕様を述べる。また，どのようにして，ネットワーク最適化エンジンで，最適化決定がなされるかについても述べる。）
　
（あ）上記Ｂの「Along with the SSM-compliant media bit-stream an adaptation engine also processes a description meta-data (shown in thin white arrows in Figure 1) that contains vital information for the adaptation engine about all possible adaptations.（SSM準拠のメディア・ビット・ストリームと共に，適応化エンジンは，全ての可能な適応についての適応化エンジンのための，不可欠な情報を含む，記述メタ-データ（図１の細い白い矢印を参照されたい）も処理する。）」という記載から，
　引用刊行物１に記載の「適応化エンジン」は，“メディア・ビット・ストリームと，適応化処理に必要な記述メタ-データとを処理する”ものであることが読み取れ，
　また，上記で引用したＢの記載内容と，上記Ａの「two other elements that need to be standardized to build a complete adaptation and delivery infrastructure based on SSM are:(1) a binary or XML description of the structure of the bit-stream resource and how it is to be manipulated to obtain various adapted versions（SSMに基礎を置く，完全な適応化と，伝達基盤を構築するために標準化される必要がある異なる２つの要素，（１）二値，或いは，ビット・ストリーム・リソースの構造，および，種々の適合したヴァージョンを得るために，それをどのように扱えるかとの，二値，或いは，XML表現）」，及び，「By interpreting the descriptor and the constraints a universal adaptation engine can adapt the content appropriately to suit the specified needs and preferences of recipients, without knowledge of the specifics of the content, its encoding and/or encryption. （制約事項と記述子を解釈することで，汎用適応化エンジンは，それを符号化，及び／または，暗号化するための，そのコンテンツの仕様の知識なしに，規定された要求と受信者の能力に適合するように，適切に適応化することができる）」という記載，及び，上記Ｂの「Irrespective of the actual content-type and its encoding however, the scalable resource bit-stream is conformant with SSM, which all intermediate adaptation engines can interpret and manipulate.（実際のコンテンツ−タイプとそれの復号がどのようなものかに関係なく，スケーラブル・リソースのビット・ストリームは，全ての中間の適応化エンジンが解読し，操作することができる，SSMで整合している。）」，「There are a variety of possibilities for representing and conveying this information to adaptation engines. While in MPEG-21 DIA the trend is to use XML, it is to be noted that representing this information in binary form as part of the media bit-stream itself is a straightforward extension, and may even be preferred based on considerations of compactness and manageability. This information is referred to as resource description metadata.（適応化エンジンに，この情報を示し，伝達するための，様々な可能性が存在する。MPEG-21　DIAの間では，XMLを用いる傾向があり，それは，それ自身が，メディア・ビット・ストリームの一部として，二値形式で，この情報を表現することが，単純な拡張であり，またさらに，緊密さと扱いやすさの考察に基づくことが望ましい。この情報は，リソース記述メタデータと呼ばれる。）」という記載と，上記で「適応化エンジン」に対して指摘した事項から，引用刊行物１に記載の「リソース記述メタデータ」は，“SSMに準拠したスケーラブル・メディア・コンテンツは，適応化エンジンが，それを解釈することで，該スケーラブル・メディア・コンテンツがどのように符号化，及び，暗号化されたかの情報なしで，即ち，該スケーラブル・メディア・コンテンツを復号化，或いは，復号することなく，適応化が行えるようにするための，XMLで記述された記述子である”ことが読み取れる。
　
（い）上記（あ）において引用したＡに記載の内容，及び，上記Ｂの「 While in MPEG-21 DIA the trend is to use XML, it is to be noted that representing this information in binary form as part of the media bit-stream itself is a straightforward extension, and may even be preferred based on considerations of compactness and manageability. This information is referred to as resource description metadata.（MPEG-21　DIAの間では，XMLを用いる傾向があり，それは，それ自身が，メディア・ビット・ストリームの一部として，二値形式で，この情報を表現することが，単純な拡張であり，またさらに，緊密さと扱いやすさの考察に基づくことが望ましい。この情報は，リソース記述メタデータと呼ばれる）」という記載から，
　引用刊行物１に記載の「XMLで記述された記述子」は，“メディア・ビット・ストリーム，或いは，スケーラブル・コンテンツの一部として表現されるものである”ことが読み取れる。
　また，上記Ｂの「It is assumed that both the originator of the media as well as the software or hardware system used to experience it at the recipient end understand the actual media-encoding format.（メディアの発信は，受信者の終端で，それを体験するために用いられる，ソフトウェア，或いは，ハードウェアと同じく，実際のメディア符号化フォーマットを理解していると仮定する）」，という記載，及び，上記（あ）において引用した記載から，
　引用刊行物１に記載の「メディア・ビット・ストリーム」は，“ハードウェアによって処理される”ことが読み取れ，当該技術分野においては，「ハードウェア」として，「コンピュータ」が含まれることは，当業者にとって自明の事項であるから，結果として，上記で引用した引用刊行物１の記載から，引用刊行物１に記載の「メディア・ビット・ストリーム」は，“コンピュータによって処理される”ことが読み取れる。
　
（う）上記Ａの「By interpreting the descriptor and the constraints a universal adaptation engine can adapt the content appropriately to suit the specified needs and preferences of recipients, without knowledge of the specifics of the content, its encoding and/or encryption.（制約事項と記述子を解釈することで，汎用適応化エンジンは，それを符号化，及び／または，暗号化するための，そのコンテンツの仕様の知識なしに，規定された要求と受信者の能力に適合するように，適切に適応化することができる。）」という記載，上記Ｃの「 Note that while the originator/creator of the media as well as the recipients/consumers of the media must have specific knowledge about the encoding in order to provide an experience for the end-user, the intermediate infrastructure does not need to know what the content is and how it has been encoded in order to adapt appropriately.（メディアの受信者/消費者と同様にメディアの発信者/制作者も，エンドユーザに経験を供給するために符号化に関する特定の知識を持っていなければならないが，内容は何か，また，それがどのように適切に適応化するためにコード化されたかを，中間のインフラストラクチャーが知る必要はないことに注意する）」という記載，及び，上記Ｃの「the content itself can be encrypted, and transcoding can still proceed as before in the encrypted domain.（コンテンツは，それ自身，暗号化され得，トランスコーディングは，暗号化された領域において，以前どおりに開始することができる）」という記載から，
　引用刊行物１に記載の「メディア」,或いは,「コンテンツ」は，“「メディアの制作者」，或いは，「メディアの発信者」が，「コード化」し，「記述子」を附与し，更に，「暗号化」する”こと，当該「メディア」の「トランスコーディング」は，“中間のインフラストラクチャーにおいて，暗号化された状態で，どのように暗号化／復号化されたかの知識を必要とすることなく行われる”ことが読み取れ，
　また上記（あ）において引用した，上記Ｂの記載から，引用刊行物１に記載の「メディア」は，「メディア・ビット・ストリーム」であり，前記「メディア・ビット・ストリーム」は、「スケーラブルなリソースのビットストリーム」であることは明らかであるから，上記で検討した事項から，引用刊行物１に記載の「スケーラブルなリソースのビットストリーム」は，“中間のインフラストラクチャーにおいて，暗号化された状態で，復号することなく行われる”ことが，引用刊行物１から読み取れる。
　
（え）上記Ｄの「 As long as the meta-data has been received in full, the scalable bit-stream resource in Figure 3 may come in stages in multiple network packets, and either forwarded or dropped or partially dropped by the engine as they arrive, based on the adaptation decisions already made.（メタ-データが，全て，受信されているのであれば，図３における，スケーラブル・ビット・ストリームは，多重ネットワーク・パケットのステージに入り，既に作られている適応化決定を基礎とし，それらが到着するとして，エンジンによって，送られるか，落とされるか，部分的に落とされるかの何れかである。）」，及び，「Packet based scalable adaptation based on truncation has been considered before [28], [29].（トランケ−ションに基づくスケーラブルな最適化に基づいたパケットは，前の［２８］，［２９］で検討されていた。）」という記載から，引用刊行物１に記載の「最適化」には，「トランケ−ション（truncation）」が含まれることが読み取れ，上記（あ）〜（う）で検討した事項，及び，上記Ａ〜Ｄに引用した記載内容から，引用刊行物１に記載の「適応化エンジン」が，「適応化」，即ち，「トランスコーディング」を行っていること，該「トランスコーディング」に，「スケーリング」が含まれることは明らかであり，そして，該「トランケ−ション」が，“スケーリング”の１つであることは，当業者に自明の事項であるから，
　以上，（あ）〜（え）において検討した事項から，引用刊行物１には，次の発明（以下，「引用発明１」という）が記載されていると認める。
　
　コンピュータによって実行される，暗号化されたスケーラブル・メディア・ストリームをスケーリングするための方法であって，
　トランケートを含む，どのようなスケーリングを行ったかを示す情報である記述子を，前記スケーラブル・メディア・ストリームに附与し，
　ここで，前記暗号化されたスケーラブル・メディア・ストリームは，復号されることなくスケーリングされるものであり，
　トランスコーディングの際に，記述子を解釈することによって，トランケートが行われる
　方法。
　
　また，原審が拒絶理由に引用した，本願の第１国出願前に既に公知である，国際公開第０３／０３０５４２号（２００３年４月１０日公開，以下，これを「引用刊行物２」という）には、関連する図面と共に，次の事項が記載されている。
　
Ｅ．「As an overview, the present invention is directed towards any data which can be scalably encoded and, specifically, any data that combine scalable encoding with progressive encryption. For purposes of the present application, scalable coding is defined as a process which takes original data as input and creates scalably coded data as output, where the scalably coded data have the property that portions of it can be used to reconstruct the original data with various quality levels. Specifically, the scalably coded data are often thought of as an embedded bitstream. The first portion of the bitstream can be used to decode a baseline-quality reconstruction of the original data, without requiring any information from the remainder of the bitstream, and progressively larger portions of the bitstream can be used to decode improved reconstructions of the original data. For purposes of the present application, progressive encryption is defined as a process which takes original data (plain text) as input and creates progressively encrypted data (cipher text) as output, where the progressively encrypted data have the property that the first portion can be decrypted alone, without requiring information from the remainder of the original data; and progressively larger portions can be decrypted with this same property, in which decryption can require data from earlier but not later portions of the bitstream. 」（１２頁１９〜３７行）
（概観すると，本発明は，スケーラブルに符号化可能なあらゆるデータを対象とし，特に，スケーラブル符号化を漸進的暗号化（progressive encryption）と組み合わせるあらゆるデータを対象とする。
  本出願の目的上，スケーラブル符号化は，入力として原データを取り込み，出力としてスケーラブルに符号化されたデータを生成するプロセスとして定義される。
  このスケーラブル符号化において，スケーラブルに符号化されたデータは，その一部が，様々な品質レベルを有する原データを復元するために使用できるという特性を有する。
  具体的には，スケーラブルに符号化されたデータは，多くの場合，組み込みビットストリームと考えられる。
  このビットストリームの最初の部分は，そのビットストリームの残りの部分からの情報を必要とすることなく，原データをベースライン品質で復元したものを復号するのに使用することができ，このビットストリームの部分の漸進的に大きな部分は，原データを改善して復元したものを復号するのに使用することができる。
  本出願の目的上，漸進的暗号化は，入力として原データ（平文）を取り込み，出力として漸進的に暗号化されたデータ（暗号文）を生成するプロセスとして定義される。
  この漸進的暗号化において，漸進的に暗号化されたデータは，最初の部分が，原データの残りの部分からの情報を必要とすることなく単独で解読でき，漸進的に大きな部分は，この同じ特性により解読できるという特性を有する。
  この漸進的に大きな部分では，解読は，ビットストリームの後の部分ではなく前の部分からのデータを必要とすることがある。＜引用刊行物２の日本語公報である特表２００５−５２８６３１号より引用，なお，当審にて一部，訳を補っている，以下，同じ＞）
　
Ｆ．「 With reference still to step608 , in one embodiment of the present invention, while the payload data (e.g., the scalable video data) are encrypted progressively, the header data are left unencrypted so that transcoding nodes can use this information to make transcoding decisions. For example, in one embodiment, the unencrypted header contains information such as recommended truncation points within the encrypted payload data. In another embodiment, these header data are used to achieve near rate distortion (RD)-optimal bitrate reduction by intermediate transcoding nodes. Moreover, in the present embodiment, the transcoding nodes can use the header data to make transcoding decisions without requiring decryption of the progressively encrypted scalable video data or the header data. In yet another embodiment of the present invention, the header data are encrypted to add additional security. 」（１６頁１４〜２６行）
（ ステップ６０８を続けて参照すると，本発明の一実施形態では，ペイロードデータ（例えばスケーラブル映像データ）は，漸進的に暗号化される一方，ヘッダデータは，トランスコードノードがこの情報を使用してトランスコードの判定を行うことができるように，暗号化されずに残される。例えば，一実施形態では，この暗号されないヘッダは，暗号化されたペイロードデータ内の推奨された切断点のような情報を収容する。別の実施形態では，これらのヘッダデータは，中間のトランスコードノードによる準（near）レート歪み（ＲＤ（rate distortion））−最適ビットレート削減を行うために使用される。さらに，本実施形態では，トランスコードノードは，ヘッダデータを使用して，漸進的に暗号化されたスケーラブル映像データの解読もヘッダデータの解読も必要とすることなく，トランスコードの判定を行うこともできる。本発明のさらに別の実施形態では，ヘッダデータは，暗号化されて，セキュリティをさらに付加する。）
　
Ｇ．「In accordance with the present invention, the method for transcoding data packets is performed on the encrypted data packets; this is, the media data are not decrypted. Transcoding functions can include truncation of the data packets(specifically, the payload portions of the data packets), eliminating certain data packets from the stream, or passing the data packets through without modification.
 
  With reference first to figure 18A, incoming encrypted and/or encoded data packets are received by transcoder1620. in this embodiment, the header portion of each data packet is not encrypted. Transcoder1620 reads the header portion, with contains information that can be used to make transcoding decisions. in one embodiment, the information in the header portion incudes specification of the truncation points. in another embodiment, the truncation points are derived from the information provided in the header.
 
  For example, the header portion may contain information specifying recommended point(e.g., a number of a bit) for truncating the payload portion of the data packets. It is appreciated that each data packet may have a different truncation point.」（２２頁９〜２７行）
（本発明によると，データパケットをトランスコードする方法は，暗号化されたデータパケットに対して実行される。；すなわち，メディアデータは，解読されない。 トランスコード機能は，データパケット（具体的には，データパケットのペイロード部）を切断（トランケート）すること，ストリームから一定のデータパケットを除去すること，またはデータパケットを変更することなく通過させることを含むことができる。
　
  まず図１８Ａを参照すると，入来する暗号化および／または符号化が行われたデータパケットが，トランスコーダ１６２０によって受信される。 この実施形態では，各データパケットのヘッダ部は暗号化されていない。トランスコーダ１６２０は，ヘッダ部を読み出す。ヘッダ部は，トランスコードの判定を行うために使用可能な情報を収容している。一実施形態では，ヘッダ部の情報は，切断（トランケート）点の指定を含む。別の実施形態では，切断（トランケート）点は，ヘッダに設けられた情報から導出される。
　
  例えば，ヘッダ部は，データパケットのペイロード部を切断（トランケート）するための推奨された点（例えばビット番号）を指定する情報を収容することができる。各データパケットは，異なる切断（トランケート）点を有してもよいことが理解される。）
　
Ｈ．「The header portion may also contain information identifying each data packet by number, for example. Accordingly, transcoder1620  can eliminate certain data packets from the stream; for example, if every other packet is to be eliminated (e.g., the odd-numbered packets), transcoder1620  can use the header information to identify the odd-numbered data packets and eliminate those from the stream of data packets.」（２３頁１３〜１８行）
（また、ヘッダ部は、例えば番号により各データパケットを識別する情報を収容することもできる。したがって、トランスコーダ１６２０は、ストリームから一定のデータパケットを除去することができる； 例えば、１つおきのパケット（例えば奇数番号のパケット）が除去されるべきである場合、トランスコーダ１６２０は、ヘッダ情報を使用して、奇数番号のデータパケットを識別し、それらのデータパケットを、データパケットのストリームから除去することができる。）
　
Ｉ．「In the embodiment of  FIG. 20 , data packet2000  includes header data portion  2002  and scalably encoded, progressively encrypted video data portion2004 . As mentioned above, header data portion2002  includes information that is used by transcoder  1620  to transcode the scalably encoded, progressively encrypted video data portion2004 . For example, header data portion2002  may contain information specifying recommended points (e.g., a number of a bit) for truncating the payload portion (e.g., the scalably encoded, progressively encrypted video data portion2004 ) of data packet2000 . Header data portion2002  may also contain information identifying each data packet by number, for example. Accordingly, transcoder1620  can eliminate certain data packets from the stream; for example, if every other packet is to be eliminated (e.g., the odd-numbered packets), transcoder1620  can use the information in header data portion2002  to identify the odd-numbered data packets and eliminate those from the stream of data packets. 」（２６頁１６〜２９行）
（図２０の実施形態では，データパケット２０００は，ヘッダデータ部２００２と，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４とを含む。 上述したように，ヘッダデータ部２００２は，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４をトランスコードするためにトランスコーダ１６２０によって使用される情報を含む。 例えば，ヘッダデータ部２００２は，データパケット２０００のペイロード部（例えば，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４）を切断（トランケート）するための推奨された点（例えば，ビット番号）指定する情報を収容することができる。 また，ヘッダデータ部２００２は，例えば番号により各データパケットを識別する情報を収容することもできる。 したがって，トランスコーダ１６２０は，一定のデータパケットをストリームから除去することもできる。 例えば，１つおきのパケット（例えば奇数番号のパケット）が除去されるべきである場合，トランスコーダ１６２０は，ヘッダデータ部２００２の情報を使用して，奇数番号のデータパケットを識別し，それらのデータパケットを，データパケットのストリームから除去することができる。）
　
（お）上記Ｅの「the present invention is directed towards any data which can be scalably encoded and, specifically, any data that combine scalable encoding with progressive encryption.（本発明は，スケーラブルに符号化可能なあらゆるデータを対象とし，特に，スケーラブル符号化を漸進的暗号化（progressive encryption）と組み合わせるあらゆるデータを対象とする。）」という記載，上記Ｇの「incoming encrypted and/or encoded data packets are received by transcoder1620.（入来する暗号化および／または符号化が行われたデータパケットが，トランスコーダ１６２０によって受信される。）」という記載，及び，上記引用のＥの記載中の「漸進的暗号化（progressive encryption）」から，該「漸進的暗号化」は，「プログレッシブ暗号化」と同一のものであるということから，引用刊行物２には，“トランスコーダが，スケーラブルに符号化され，プログレッシブ暗号化されたデータパケットを受信する”点が記載されていることが読み取れ，加えて，上記Ｅの「Specifically, the scalably coded data are often thought of as an embedded bitstream.（具体的には，スケーラブルに符号化されたデータは，多くの場合，組み込みビットストリームと考えられる。）」という記載から，前記“スケーラブルに符号化され，プログレッシブ暗号化されたデータパケット”は，“スケーラブルに符号化され，プログレッシブに暗号化されたビットストリーム”を含むことが読み取れるので，結果として，上記引用の引用刊行物２に記載の内容から，“トランスコーダが，スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームを受信する”ことが読み取れる。
　
（か）上記Ｇの「the method for transcoding data packets is performed on the encrypted data packets; this is, the media data are not decrypted. Transcoding functions can include truncation of the data packets(specifically, the payload portions of the data packets), eliminating certain data packets from the stream, or passing the data packets through without modification.(データパケットをトランスコードする方法は，暗号化されたデータパケットに対して実行される。；すなわち，メディアデータは，解読されない。トランスコード機能は，データパケット（具体的には，データパケットのペイロード部）を切断（トランケート）すること，ストリームから一定のデータパケットを除去すること，またはデータパケットを変更することなく通過させることを含むことができる。)」という記載と，上記（お）で検討した事項から，引用刊行物２には，“トランスコーダで受信された，スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームは，トランスコーダによって，復号されることなく，切断（トランケート）され，ストリームから一定のデータが除去される”ことが記載されていると読み取れ，
　同じく上記Ｇの「 Transcoder1620 reads the header portion, with contains information that can be used to make transcoding decisions. in one embodiment, the information in the header portion incudes specification of the truncation points.（トランスコーダ１６２０は，ヘッダ部を読み出す。ヘッダ部は，トランスコードの判定を行うために使用可能な情報を収容している。一実施形態では，ヘッダ部の情報は，切断（トランケート）点の指定を含む。）」という記載，及び，上記Ｈの「The header portion may also contain information identifying each data packet by number, for example.（また、ヘッダ部は、例えば番号により各データパケットを識別する情報を収容することもできる。）」という記載，並びに，上記Ｉの「header data portion2002  includes information that is used by transcoder1620  to transcode the scalably encoded, progressively encrypted video data portion2004. For example, header data portion2002  may contain information specifying recommended points (e.g., a number of a bit) for truncating the payload portion (e.g., the scalably encoded, progressively encrypted video data portion  2004 ) of data packet2000.（ヘッダデータ部２００２は，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４をトランスコードするためにトランスコーダ１６２０によって使用される情報を含む。 例えば，ヘッダデータ部２００２は，データパケット２０００のペイロード部（例えば，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４）を切断（トランケート）するための推奨された点（例えば，ビット番号）指定する情報を収容することができる。）」という記載から，引用刊行物２に記載の「ヘッダ部」には，“スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームのトランスコードの判定を行うために使用可能な情報が収容され，前記使用可能な情報には，前記スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームをトランケートするための，トランケート点が含まれる”ことが読み取れる。
　
（き）上記Ｉの「 Header data portion2002  may also contain information identifying each data packet by number, for example. Accordingly, transcoder1620  can eliminate certain data packets from the stream（また，ヘッダデータ部２００２は，例えば番号により各データパケットを識別する情報を収容することもできる。 したがって，トランスコーダ１６２０は，一定のデータパケットをストリームから除去することもできる。）」という記載と，上記（お），及び，（か）で検討した事項から，引用刊行物２に記載の「トランスコーダ」は，“ヘッダに収容された情報を用いて，スケーラブルに符号化され，プログレッシブ暗号化されたビット・ストリームをトランケートし，前記ビット・ストリームの一部を除去する”ものであることが読み取れ，上記Ｉの「data packet2000  includes header data portion  2002  and scalably encoded, progressively encrypted video data portion2004 .（データパケット２０００は，ヘッダデータ部２００２と，スケーラブルに符号化されて漸進的に暗号化された映像データ部２００４とを含む。）」という記載から，引用刊行物２に記載の「ヘッダ部」は，“ビットストリームに含まれる”ことが読み取れる。
　
（く）上記Ｆの「while the payload data (e.g., the scalable video data) are encrypted progressively, the header data are left unencrypted so that transcoding nodes can use this information to make transcoding decisions.（ペイロードデータ（例えばスケーラブル映像データ）は，漸進的に暗号化される一方，ヘッダデータは，トランスコードノードがこの情報を使用してトランスコードの判定を行うことができるように，暗号化されずに残される。）」という記載，同じく，上記Ｆの「In yet another embodiment of the present invention, the header data are encrypted to add additional security.（本発明のさらに別の実施形態では，ヘッダデータは，暗号化されて，セキュリティをさらに付加する。）」という記載，並びに，上記Ｇの「in this embodiment, the header portion of each data packet is not encrypted.（この実施形態では，各データパケットのヘッダ部は暗号化されていない。）」という記載から，引用刊行物２に記載の「ヘッダ部」は,“ビットストリーム内のペイロードデータとは，別々に暗号化可能である”ことが読み取れるので,
　以上（お）〜（く）に検討した事項から，引用刊行物２には，次の発明（以下，「引用発明２」という）が記載されているものと認める。
　
　スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームをトランスコードする，トランスコーダであって，
　前記スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームは，前記ビットストリームをトランケートするためのトランケート点，或いは，前記ビット・ストリームの一部を削除するための点を収容したヘッダ部と，ペイロードデータとを有し，
　前記ビット・ストリームは，トランスコーダにおいて，復号されることなくトランスコードされ，
　トランスコードの際に，前記ヘッダ部の収容した情報を用いて，前記ビット・ストリームの一部が削除されることを有し,
　前記ヘッダ部は,ビットストリームのペイロードデータとは,別々に暗号化可能である
　トランスコーダ。
　
　更に，原審が拒絶理由に引用した，本願の第１国出願前に既に公知である，特開平１０−１０５４４９号公報（１９９８年４月２４日公開，以下，これを「引用刊行物３」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｊ．「【０００１】
【発明の属する技術分野】本発明は，電子データ伝送の分野に関わり，異なるセキュリティ要件を有する複数のデータコンポーネントの記憶または伝送を安全にバンドル操作することのできるファイル構造を提供するものである。このファイル構造を勝手に書き換えるようなことがあると，即時に中継ぎコンポーネントが開かれてそれが明らかとなる。」
　
Ｋ．「【００３０】従って，これらの異なるセキュリティ要件に対処するために，本発明は，図２の一実施例に示す一般保護ファイルフォーマット（GSFF）を提供する。このファイルフォーマットによれば，複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる。各ファイルには，他のファイルとは異なるセキュリティ要件を設定することができる。この保護ファイルフォーマットを使えば，異なるファイルタイプを単一のラッパーで交換することができる。また，この保護ファイルフォーマットによれば，１つのファイルを複数のセクションに分割して，それらを単一ファイルにラップすることができる。ファイル内の各セクションは，独自にセキュリティ保護がなされる。これによって，機密情報だけを保護し，他のセクションはセキュリティ保護の必要があまりない，または全くその必要がない状態にしておくことができる。その結果，セキュリティに関与する操作は，ファイルのほんの一部しか必要ないため，性能が上がる。
【００３１】本発明の一般保護ファイルフォーマットがサポートするセキュリティ機能には，暗号化によるデータ機密性，ハッシュによるデータ完全性，メッセージダイジェスト，メッセージ確認コード（MAC，ANSI規格として定義されている）およびデジタル署名が含まれる。
【００３２】図２に示すように，一般保護ファイルフォーマットには，ファイル見出し１０，続いて，複数のファイル本体１２，ファイル後書き１４，その次にデータ１６がある。各ファイル本体１２には，後述するとおり，他の実施される本体とは異なるセキュリティ要件を設定することができる。例えば，１つのファイルは暗号化を必要とし，他のファイルはデータ完全性の保護だけを必要とする場合などである。
【００３３】各ファイルは，その要件に従ってラップされ，ファイル本体に記述される。データのポインタは，ファイル本体セクションに含まれ，データはファイル後書きの後に置かれる。
【００３４】本発明の一般保護ファイルフォーマットはディレクトリベースのファイルフォーマットである。ファイル見出し，ファイル本体およびファイル後書きはラッパー内ではディレクトリとみなされる。ファイル見出しには，一般保護ファイルフォーマットのファイル識別子，バージョン番号およびラッパーの長さが含まれる。各ファイル本体には，そのファイル本体に関連するエントリが含まれる。ファイル後書きは，ラッパー全体のセキュリティ保護に用いることができる。
【００３５】ファイル見出しの構造の概略を図３に示す。ファイル見出しには，一般保護ファイルフォーマット識別子２０，ファイルフォーマットを単に識別する一対のバイトのタグ（例えば，インテルとモトローラのバイト順を識別する），一般保護ファイルフォーマットのバージョン番号２２，ファイルインジケータ２４および一般保護ファイルフォーマットの全ファイル長２６が含まれる。
【００３６】各ファイル本体は，ラッパーに含まれるファイルを記述する。図４に概略を示すように，ファイル本体には，本体ファイルとしてファイルのタイプを識別して，ファイル長を設定するためのファイル本体タグ２８，次にセキュリティ規格３０がある。セキュリティ規格には，セキュリティタイプ，セキュリティアルゴリズム，セキュリティアルゴリズムパラメータ，暗号鍵情報，操作モード，フィルタ，キャラクタセット，出力ファイル規格パラメータ，データ長，およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている。」
　
（け）上記Ｊの「本発明は，電子データ伝送の分野に関わり，異なるセキュリティ要件を有する複数のデータコンポーネントの記憶または伝送を安全にバンドル操作することのできるファイル構造を提供するものである」との記載から，引用刊行物に記載の「ファイル」は，「電子データ伝送」に用いられるものであることが読み取れ，
　上記Ｋの「このファイルフォーマットによれば，複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる。各ファイルには，他のファイルとは異なるセキュリティ要件を設定することができる。この保護ファイルフォーマットを使えば，異なるファイルタイプを単一のラッパーで交換することができる。また，この保護ファイルフォーマットによれば，１つのファイルを複数のセクションに分割して，それらを単一ファイルにラップすることができる。ファイル内の各セクションは，独自にセキュリティ保護がなされる。」という記載から，
　引用刊行物３における「ファイルフォーマット」が，“複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる”ものであること，及び，“１つのファイルのセクションに分割して，各セクションに異なるセキュリティ保護を施し，それを，単一のファイルにラップ”し得るものであることが読み取れ，このことから，“各セクション”のそれぞれは，“ファイル”であることも読み取れる。
　したがって，引用刊行物３においては，
“一旦，ファイルを分割し，分割したファイルのそれぞれに異なるセキュリティ保護を施し，それを再び単一のファイルにラップする”態様を含むものであることが読み取れる。
　
（こ）上記Ｋの「本発明の一般保護ファイルフォーマットがサポートするセキュリティ機能には，暗号化によるデータ機密性，ハッシュによるデータ完全性，メッセージダイジェスト，メッセージ確認コード（MAC，ANSI規格として定義されている）およびデジタル署名が含まれる」という記載から，
　引用刊行物３における「ファイルフォーマットの機能」には，「暗号化によるデータ機密性，ハッシュによるデータ完全性，メッセージダイジェスト，メッセージ確認コード（MAC，ANSI規格として定義されている）およびデジタル署名が含まれる」ことが読み取れる。
　
（さ）上記Ｋの「一般保護ファイルフォーマットには，ファイル見出し１０，続いて，複数のファイル本体１２，ファイル後書き１４，その次にデータ１６がある。各ファイル本体１２には，後述するとおり，他の実施される本体とは異なるセキュリティ要件を設定することができる。例えば，１つのファイルは暗号化を必要とし，他のファイルはデータ完全性の保護だけを必要とする場合などである」という記載，及び，上記Ｋの「各ファイル本体は，ラッパーに含まれるファイルを記述する。図４に概略を示すように，ファイル本体には，本体ファイルとしてファイルのタイプを識別して，ファイル長を設定するためのファイル本体タグ２８，次にセキュリティ規格３０がある。セキュリティ規格には，セキュリティタイプ，セキュリティアルゴリズム，セキュリティアルゴリズムパラメータ，暗号鍵情報，操作モード，フィルタ，キャラクタセット，出力ファイル規格パラメータ，データ長，およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている」という記載から，
　引用刊行物３における「ファイル」には，それぞれ異なる「セキュリティ要件」が設定可能であり，前記「ファイル」を記述する「ファイル本体」には，「セキュリティ規格」があり，前記「セキュリティ規格」には，「セキュリティタイプ，セキュリティアルゴリズム，セキュリティアルゴリズムパラメータ，暗号鍵情報，操作モード，フィルタ，キャラクタセット，出力ファイル規格パラメータ，データ長，およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている」ことが読み取れる。
　
　以上，（け）〜（さ）で検討した事項から，引用刊行物３には，次の周知技術が記載されているものと認める。
　
　データ伝送に用いられる１つのファイルを複数のファイルに分割して，前記分割された各ファイルに異なるセキュリティ保護を施し，それを，単一のファイルにラップする方法であって，
　前記方法に用いるファイルフォーマットの機能には，暗号化によるデータ機密性，ハッシュによるデータ完全性，メッセージダイジェスト，メッセージ確認コード（MAC，ANSI規格として定義されている）およびデジタル署名が含まれ，
　前記各ファイルには，それぞれ異なるセキュリティ要件が設定可能であり，前記各ファイルを記述するファイル本体には，セキュリティ規格があり，前記セキュリティ規格には，セキュリティタイプ，セキュリティアルゴリズム，セキュリティアルゴリズムパラメータ，暗号鍵情報，操作モード，フィルタ，キャラクタセット，出力ファイル規格パラメータ，データ長，およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている，
　方法。
　
その５．本願発明と引用発明との対比
　次に，本願発明と引用発明１とを対比すると，
イ．引用発明１における「スケーラブル・メディア・ストリーム」は，
　本願発明における「スケーラブルデータ列」に相当するので，
　引用発明１における「コンピュータによって実行される，暗号化されたスケーラブル・メディア・ストリームをスケーリングするための方法」と，
　本願発明における「コンピュータによって実行される、暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法」とは,
“コンピュータによって実行される,暗号化されたスケーラブルデータ列をスケーリングするための方法”である点で共通し，
ロ．引用発明１における「トランケートを含む，そのようなスケーリングを行ったかを示す情報である記述子」は，「スケーラブル・メディア・ストリーム」に附与されているものであるから，前記「記述子」は，前記「スケーラブル・メディア・ストリーム」に関連付けされていることは明らかであり,
　前記「記述子」も，本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」も，「スケーラブル・メディア・ストリーム」,或いは,「スケーラブルデータ列」の「スケーリング」の際に用いられるものであるから，
　引用発明１における「トランケートを含む，どのようなスケーリングを行ったかを示す情報である記述子」と,
　本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」とは,
“暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータ”である点で共通するので，
　引用発明１における「トランケートを含む，どのようなスケーリングを行ったかを示す情報である記述子を，前記スケーラブル・メディア・ストリームに附与し」と，
　本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを、前記プログレッシブ暗号化された（１７０３）スケーラブルデータ列に関連付けること」とは，
“暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータを，前記暗号化されたスケーラブルデータ列に関連付ける”ことである点で共通し，
ハ．引用発明１における「前記暗号化されたスケーラブル・メディア・ストリームは，復号されることなくスケーリングされる」と，
　本願発明における「前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされる」とは，
“暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされる”点で共通し,
　引用発明１における「記述子」は,上記イで検討したように，暗号化されたデータに附与されたものであり，一方，本願発明における「トランスコーダ可読ヘッダ」が，「暗号化されたスケーラブルデータ列」に結合していることは明らかであるから，
　引用発明１における「トランスコーディングの際に，記述子を解釈することによって，トランケートが行われる」と，
　本願発明における「トランスコードの際に、前記トランスコーダ可読ヘッダを読み出すことによって、前記複数の結合可能部分のうちの少なくとも１つの結合可能部分およびこれに関する暗号チェックサムが削除される」とは，
“トランスコードの際に，暗号化されたスケーラブルデータ列に附与されたデータを用いることで，トランスコードが行われる”点で共通するので，
　以上イ〜ハで検討した事項から，本願発明と，引用発明１との一致点,及び，相違点は次のとおりである。
　
［一致点］
　コンピュータによって実行される,暗号化されたスケーラブルデータ列をスケーリングするための方法であって，
　暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータを，前記暗号化されたスケーラブルデータ列に関連付けられ,
　暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされ,
　トランスコードの際に，暗号化されたスケーラブルデータ列に附与されたデータを用いることで，トランスコードが行われる
　方法
　
［相違点１］
“暗号化されたスケーラブルデータ列”が,
　本願発明においては，
「暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列」であるのに対して,
　引用発明１においては,「プログレッシブ暗号化」については言及されていない点，
　
［相違点２］
“暗号化されたスケーラブルデータ列に関連付けられたデータ”が，
　本願発明においては，
「プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」であるのに対して，
　引用発明１においては，
「どのようなスケーリングを行ったかを示す情報」であって,「トランケート可能な複数の結合可能部分を特定するデータ」ではない点，
　
［相違点３］
　本願発明においては，
「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること（１７０５）と，
　前記暗号チェックサムを，前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも１つの部分に関連付けること（１７０７）と」を含むものであるのに対して，
　引用発明１においては，
　「暗号チェックサム」に関して言及されていない点，
　
［相違点４］
　本願発明においては,
「プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは，トランスコーダ可読ヘッダとは独立に暗号化可能であ」るのに対して，
　引用発明１においては,
「記述子」が暗号化されるかについては,言及されていない点，
　
［相違点５］
“トランスコードの際に，暗号化されたスケーラブルデータ列に附与されたデータを用いることで，トランスコードが行われる”ことに関して，
　本願発明においては，
“附与されたデータ”は,「トランスコーダ可読ヘッダ」であり,“トランスコード”は,「複数の結合可能部分のうちの少なくとも１つの結合可能部分およびこれに関する暗号チェックサムが削除される」ことであるに対して,
　引用発明においては，
“附与されたデータ”は，「記述子」であり，“トランスコード”は，「トランケート」ではあるが，「暗号チェックサムが除去される」ことまでは言及されていない点，
　
その６．当審の判断
　上記相違点について検討する。
　
［相違点１］,［相違点２］,及び，［相違点４］について,
　上記項目その４．引用刊行物に記載の発明において引用した引用発明２は，同項目その４で認定したとおりの構成を有しており，引用発明２の構成から明らかなように，
「スケーラブルに符号化され，プログレッシブ暗号化されたビットストリームをトランスコードする」こと，
「トランスコードの際に，前記ヘッダ部の収容した情報を用いて，前記ビット・ストリームの一部が削除される」こと，及び，
「ヘッダ部は,ビットストリームのペイロードデータとは,別々に暗号化可能である」ことは，本願の第１国出願前に，当業者には公知の技術事項である。
　そして，引用発明１も，引用発明２も,“暗号化されたスケーラブル・ビット・ストリームをスケーリングする”技術に関するものであり,引用発明１の「記述子」も，引用発明２における「ヘッダ部」も,共に,「スケーラブル・ビット・ストリーム」に附与,或いは,結合されたものであるから，引用発明１における「記述子」を，引用発明２における「ヘッダ部」に変更し,引用発明１における「トランケート」処理に,更に，ビット・ストリームの一部を削除する処理を加えること，及び,該ヘッダ部を,独立に暗号化するようにすることは,当業者が適宜なし得る事項である。
　よって,相違点１，相違点２，及び，相違点４は格別のものでない。
　
［相違点３］，及び，［相違点５］について，
　上記項目その４．引用刊行物に記載の発明において引用した周知技術に示したとおり,データ転送で送信されるファイルを，複数に分割し，分割した各ファイルについて，それぞれ異なるセキュリティ要件が設定可能であり，前記各ファイルを記述するファイル本体には，セキュリティ規格があり，前記セキュリティ規格には，セキュリティタイプ，セキュリティアルゴリズム，セキュリティアルゴリズムパラメータ，暗号鍵情報，操作モード，フィルタ，キャラクタセット，出力ファイル規格パラメータ，データ長，およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれているようにすることは，本願の第１国出願前に，当業者には周知の技術事項であり，該分割されたファイルは，即ち，分割されたデータであるから，当該周知技術が，引用発明１における，スケーラブル・ビット・ストリームに適用可能であることは，また，前記セキュリティ要件，或いは，セキュリティ規格に，「暗号チェックサム」を含め得ることは，当業者とって自明の事項であるから，引用発明において，スケーラブル・ビット・ストリームを複数に分割し，それぞれにプログレッシブ暗号化とは異なるセキュリティ要件である，例えば，暗号チェックサム等を適用することは，当業者が適宜なし得る事項である。
　そして，上記で検討したことと，上記［相違点１］,［相違点２］,及び，［相違点４］についてで検討した事項とから，引用発明１において，スケーラブル・ビット・ストリームの一部を，ヘッダ部の情報に基づいて削除した場合に，前記一部に関連するセキュリティ要件も同時に削除されるようにすることは，当業者にとって自明の事項である。
　よって，相違点３，及び，相違点５は格別のものでない。
　
　上記で検討したごとく，相違点１〜５はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　以上のとおりであるから，本願発明は，引用発明１，及び，引用発明２，並びに，周知技術から，当業者が容易になし得たものである。
　
その７．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。