• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1264150
審判番号 不服2011-9284  
総通号数 155 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-11-30 
種別 拒絶査定不服の審決 
審判請求日 2011-05-02 
確定日 2012-10-05 
事件の表示 特願2006-553302「プログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法」拒絶査定不服審判事件〔平成17年 9月 1日国際公開、WO2005/081534、平成19年11月22日国内公表、特表2007-534230〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 その1.手続の経緯
本願は,2005年2月11日(パリ条約による優先権主張外国庁受理2004年2月13日 アメリカ合衆国)を国際出願日とする出願であって,
平成18年9月25日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成22年1月27日付けで審査官により拒絶理由が通知され,これに対して同年7月26日付けで意見書が提出されると共に手続補正がなされたが,同年12月22日付けで審査官により拒絶査定がなされ,これに対して平成23年5月2日付けで審判請求がなされると共に手続補正がなされ,同年6月24日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,同年11月8日付けで当審により特許法第134条第4項の規定に基づく審尋がなされ,平成24年1月25日付けで回答書の提出があったものである。

その2.平成23年5月2日付けの手続補正の却下の決定
結論

平成23年5月2日付け手続補正を却下する。

理由

1.補正の内容
平成23年5月2日付けの手続補正(以下,「本件手続補正」という)により,特許請求の範囲は,
「 【請求項1】
コンピュータによって実行される,暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって,
所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること(1701)であって,前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは,復号されることなくスケーリングされること(1701)と,
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)と,
前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)と
を含み,
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは,トランスコーダ可読ヘッダとは独立に暗号化可能であり,
トランスコードの際に,前記トランスコーダ可読ヘッダを読み出すことによって,前記複数の結合可能部分のうちの少なくとも1つの結合可能部分およびこれに関する暗号チェックサムが削除される
方法。
【請求項2】
前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも1つの部分および前記暗号チェックサムを暗号化すること
をさらに含む請求項1に記載の方法。
【請求項3】
前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも1つの結合可能部分は,前記プログレッシブ暗号化されたスケーラブルデータ列の他の部分とは独立に解読する
請求項1に記載の方法。
【請求項4】
前記暗号チェックサムは,前記プログレッシブ暗号化されたスケーラブルデータ列の結合可能部分について計算される
請求項1に記載の方法。
【請求項5】
第1の暗号チェックサムが,第1の結合可能部分について計算され,
第2の暗号チェックサムが,第2の結合可能部分,前記第1の結合可能部分および前記第1の暗号チェックサムの結合について計算される
請求項1に記載の方法。
【請求項6】
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,
前記結合可能部分および前記暗号チェックサムに関係した情報
を含む
請求項1に記載の方法。
【請求項7】
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,データパケットのトランスコードを行うことを可能にする
請求項1に記載の方法。
【請求項8】
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,前記プログレッシブ暗号化されたスケーラブル列の前記結合可能部分および前記暗号化チェックサムとは独立に書き込まれる
請求項1に記載の方法。
【請求項9】
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分のそれぞれは,送信可能パケットにおける他の結合可能部分とは独立に,前記パケットから抽出される
請求項1に記載の方法。」(以下,上記引用の請求項各項を,「補正前の請求項」という)から,
「 【請求項1】
コンピュータによって実行される,暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって,
トランスコーダが,所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること(1701)であって,前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは,復号されることなくスケーリングされること(1701)と,
前記トランスコーダが,前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)と,
前記トランスコーダが,前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)と
を含み,
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは,トランスコーダ可読ヘッダとは独立に暗号化可能であり,
トランスコードの際に,前記トランスコーダ可読ヘッダを読み出すことによって,前記複数の結合可能部分のうちの少なくとも1つの結合可能部分およびこれに関する暗号チェックサムが削除され,
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムとは独立に書き込まれる
方法。
【請求項2】
前記トランスコーダが,前記プログレッシブ暗号化されたスケーラブルデータ列の前記
少なくとも1つの部分および前記暗号チェックサムを暗号化すること
をさらに含む請求項1に記載の方法。
【請求項3】
前記プログレッシブ暗号化されたスケーラブルデータ列の前記少なくとも1つの結合可能部分は,前記プログレッシブ暗号化されたスケーラブルデータ列の他の部分とは独立に解読する
請求項1に記載の方法。
【請求項4】
前記暗号チェックサムは,前記プログレッシブ暗号化されたスケーラブルデータ列の結合可能部分について計算される
請求項1に記載の方法。
【請求項5】
第1の暗号チェックサムが,第1の結合可能部分について計算され,
第2の暗号チェックサムが,第2の結合可能部分,前記第1の結合可能部分および前記第1の暗号チェックサムの結合について計算される
請求項1に記載の方法。
【請求項6】
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,
前記結合可能部分および前記暗号チェックサムに関係した情報
を含む
請求項1に記載の方法。
【請求項7】
前記プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる前記データは,データパケットのトランスコードを行うことを可能にする
請求項1に記載の方法。
【請求項8】
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分のそれぞれは,送信可能パケットにおける他の結合可能部分とは独立に,前記パケットから抽出される
請求項1に記載の方法。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
2-1.新規事項
本件手続補正が,平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項により読み替える同法第17条の2第3項の規定を満たすものであるか否か,即ち,本件手続補正が,平成23年5月2日付けで提出された明細書,請求の範囲の日本語による翻訳文,及び,国際出願の願書に添付された図面(以下,これを「当初明細書等」という)の範囲内でなされたものであるかについて,以下に検討する。

本件手続補正は,補正前の請求項1に記載の,
「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること(1701)」,
「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)」,
「前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)」
を,
「トランスコーダが」,「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること(1701)」,
「トランスコーダが」,「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)」,
「トランスコーダが」,「前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)」
と補正するものである。

そこで,上記引用の請求項1記載における「(1701)」,「(1703)」,「(1705)」,「(1707)」という番号が付された各処理について,当初明細書等の記載内容を検討すると,
当初明細書等の段落【0149】に,
「【0149】
図17は,一実施の形態による,プログレッシブ暗号化されたスケーラブルデータ列を符号化するための方法で実行されるステップのフローチャートである。
ステップ1701において,所望のスケーラブル属性を保有するようにスケーリングされるプログレッシブ暗号化されたスケーラブルデータ列のバージョンを生成するために結合するプログレッシブ暗号化されたスケーラブルデータ列の結合可能部分を特定するデータが,プログレッシブ暗号化されたスケーラブルデータ列に関連付けられる。
一実施の形態によれば,上記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンは,復号されることなくスケーリングされる。
ステップ1703において,プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分について,暗号チェックサムが計算される。
ステップ1705において,暗号チェックサムが,プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けられる。」(以下,「引用記載1」という)
と記載されていて,上記引用の記載から明らかなように,引用記載1,及び,関連する図面である【図17】は,「符号化するための方法」を示したものであって,該方法を,“誰”,或いは,“何”が行うかまでは記載されていない。
そして,引用記載1の「プログレッシブ暗号化されたスケーラブルデータ列を符号化するための方法で実行される」から,当該技術分野における技術常識を勘案すれば,引用記載1のステップは,「符号化器」によって実行すると解するのが妥当である。

次に,上記「(1701)」,「(1703)」,「(1705)」,「(1707)」という番号が付された各処理を“誰”,或いは,“何”が行っているかを更に検討すると,
当初明細書等には,
「【0037】
図3は,本発明の一実施の形態による簡略化したデータ配信システム30の機能要素を示すブロック図である。
図3の例では,システム30は,符号化器32,トランスコーダ34,第1の復号器36,および第2の復号器38を含む。
システム30は,同様の機能要素だけでなく他のタイプの機能要素(たとえば,ストレージ要素,パケット化器,ストリーミング要素等)も含むより大きなシステムまたはネットワークの一部であってもよい。
本実施の形態では,符号化器32はデータを符号化(圧縮)し,トランスコーダ34は符号化データをトランスコード(たとえば,スケーリング)し,復号器36および38はデータを復号(伸張)する。
これらの機能は,単一のデバイスで実行することもできるし,或るタイプのネットワークにおいて接続することができる1つまたは2つ以上のデバイス間に分散させることもできる。
【0038】
また,要素32,34,36,および38は,今説明した機能以外の機能も実行することができる。
たとえば,符号化器32は,データを暗号化して,データをチェックするためのチェックサムまたは暗号化チェックサムを計算することもでき,また符号化データを別のブロックへ送信する前に符号化データをスケーリングすることもでき,復号器38は,符号化データを復号する前に符号化データをスケーリングすることができる。
一実施の形態では,符号化器32は,JPEG2000標準規格に基づいた符号化方式を使用する。
【0039】
加えて,トランスコーダ34は,そうではなくて,符号化データのスケーリングされたバージョンを別のトランスコーダへ送信することができ,別のトランスコーダは,次に,このスケーリングされたデータをスケーリングして,それを別のトランスコーダに送信し,この別のトランスコーダも同様に動作する。
また,復号器36は,たとえスケーリングされたデータをトランスコーダ34から受信しても,そのスケーリングされたデータをさらにスケーリングすることができる。
さらに,復号器36および38は,エンドユーザデバイスでなくてもよい。
たとえば,復号器36および38は,符号化データを復号して,その復号データを,たとえば移動電話へ送信することができる。
移動電話は,画像プロダクトをレンダリングして表示する。」(以下,「引用記載2」という。なお,下線は当審にて,説明の都合上附加したものである。以下,同じ),
という記載が存在し,引用記載2中の段落【0038】に記載の内容から,
「符号化器32」が,「データを暗号化」すること,「暗号化チェックサムを計算すること」,及び,「符号化データを別のブロックへ送信する前にスケーリングすること」は明らかである。

しかしながら,当初明細書等に,
「【0072】
図6は,本発明の一実施の形態に従ってデータをスケーリング(たとえば,トランスコード)するためのプロセスのフローチャート60である。
図7は,本発明の一実施の形態に従ってデータを符号化するためのプロセスのフローチャート70である。
図8は,本発明の一実施の形態に従ってデータを復号するためのプロセス80のフローチャートである。
具体的なステップがフローチャート60,70,および80に開示されているが,このようなステップは例示である。
・・・・(中略)・・・・
【0073】
一般に,フローチャート60は,図5Aおよび図5Bのスケーラ54(たとえば,図3のトランスコーダ34または復号器38)によって実施され,フローチャート70は,図3,図4A,および図4Bの符号化器32によって実施され,フローチャート80は,図3の復号器36によって実施される。
しかしながら,上述したように,異なる機能ブロックが,異なる機能を実行することもできるし,1つのデバイスが,複数の機能を実行することもできるし,1つまたは複数の機能を複数のデバイス間に分散することもできる。
【0074】
最初に図6を参照して,ステップ61において,符号化データ列が,(たとえば,ビットストリームまたはファイルにおいて)アクセスされる。
符号化データは,そのデータを符号化するのに使用された符号化方式に従って編成されている。
一実施の形態では,符号化方式は,JPEG2000標準規格に基づいている。
符号化データの一部または全部は暗号化されている場合もある。
・・・・(中略)・・・・
【0079】
ステップ64において,スケーラブルプロファイルデータが,符号化データにおいてセグメントを突き止めるのに使用される。
重要なことは,セグメントが,スケーリングデバイスによる符号化方式の知識を必要とすることなく見つけられるということである。
【0080】
ステップ65において,符号化データのスケーリングされたバージョンが,セグメントを使用して作成される。
また,符号化データのスケーリングされたバージョンは,暗号化データを解読することなく作成される。
【0081】
ステップ66において,一実施の形態では,符号化データのスケーリングされたバージョンが下流デバイスへ転送される。
・・・・(中略)・・・・
【0082】
ステップ67において,一実施の形態では,変更された参照情報(たとえば,変更されたスケーラブルプロファイルデータ)が,符号化データのスケーリングされたバージョンに基づいて生成される。
スケーリングされたバージョンのセグメントは,符号化方式とは独立に,スケーラブル属性の選択された値に関連付けられ,それによって,別のデバイスが,符号化方式の知識を必要とすることなく,スケーリングされたバージョンにおいてセグメントを突き止めることが可能になり,スケーリングされたバージョンをスケーリングすることが可能になる。
変更された参照情報は,符号化データのスケーリングされたバージョンと共に記憶することもできるし,それとは別に記憶することもできる。
【0083】
次に図7を参照して,ステップ71において,データが,符号化方式を使用して符号化され,ファイルに記憶される。
一実施の形態では,この符号化方式は,JPEG2000標準規格に概ね準拠している。
【0084】
ステップ72において,ファイルにおけるデータセグメントのロケーションが特定される。
【0085】
ステップ73において,データセグメントおよびスケーラブル属性の選択された値がインデックスされる。
スケーラブル属性は,その後のスケーリングオペレーションで符号化データをどのようにスケーリングするかを指定する。
インデックスは,符号化方式とは独立であり,デバイスが,符号化方式の知識を必要とすることなく,セグメントを突き止めることを可能にし,かつ符号化データをスケーリングすることを可能にする。
一実施の形態では,スケーラブル属性の選択された値は,符号化デバイスに入力される。
【0086】
ステップ74において,データセグメントおよびスケーラブル属性の選択された値のインデックスを含む参照情報が記憶される。
一実施の形態では,このインデックスは,符号化データのファイルに追加される。
別の実施の形態では,このインデックスは,ファイルとは別に記憶される。
【0087】
ステップ75において,一実施の形態では,符号化データの少なくとも一部が暗号化される。 このような一実施の形態では,符号化データの各データセグメントは,プログレッシブ暗号化される。」(以下,「引用記載3」という),
と記載され,引用記載3中の段落【0072】,段落【0073】,及び,段落【0080】に記載された事項から,
「符号化データのスケーリングされたバージョンは,暗号化データを解読することなく作成される」のは,「トランスコーダ」によってである点が読み取れ,
当初明細書等の,
「【0118】
図12は,本発明の一実施の形態による,復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャートである。
ステップ1201において,暗号化スケーラブルメディアに関連付けられるデータであって,所望のスケーラブル属性を保有するようにスケーリングされるメディアを生成するために結合する暗号化スケーラブルメディアの部分を特定するデータが,アクセスされる。
ステップ1203において,暗号化スケーラブルメディアの部分の1つまたは2つ以上および関連した暗号チェックサムが結合されて,送信可能なデータ列にされる。
ステップ1205において,スケーラブルメディアに関連付けられるデータであって,所望のスケーラブル属性を保有するようにスケーリングされるメディアを生成するために結合するスケーラブルメディアの部分を特定するデータが,再マッピングされる。
【0119】
ステップ1207において,スケーラブルメディアの部分に関連付けられるデータであって,スケーラブルメディアの部分を暗号化するのに使用される暗号化システムの保護属性を特定するデータが,再マッピングされる。
暗号化スケーラブルメディアの1つまたは2つ以上の部分および関連した暗号チェックサムは,暗号化スケーラブルメディアのスケーリングされたバージョンを構成できることが十分理解されるはずである。」(以下,「引用記載4」という),
という記載が,「本発明の一実施の形態による,復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャート」であることから,引用記載3について指摘した事項と勘案すると,引用記載4における「本発明の一実施の形態による,復号することなく暗号化スケーラブルメディアをスケーリングする方法で実行されるステップのフローチャート」は,「スケーラ」,即ち,「トランスコーダ」によって行われているものと解される。

ここで,引用記載4における「関連チェックサムが結合され」るとは,どのような処理であるか,当初明細書等に記載の内容を,更に検討すると,
まず,補正後の請求項1に,「プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付ける」と記載されていることから,補正後の請求項1に記載の「スケーリング」には,「トランケート」が含まれることは,明らかである。
そして,「トランケート(英語原文;truncate)」とは,“〔長い文章{ぶんしょう}・文字列{もじれつ}などを〕切り詰める,〔数を〕切り捨てる”ことを意味するものであって,その具体的処理については,当初明細書等の,
「【0131】
本実施の形態では,トランスコードセッションが行われると(たとえば,417),トランスコーダは,所望のスケーリング結果を達成するために,選択されたトランケート可能単位をトランケートすることができる。
例示の実施の形態によれば,トランスコードされているメディアセグメントが暗号化されている場合,この形式のトランスコードを実行するのに,解読は必要とされない。
図14Aに示す例では,トランケート可能単位Bおよびその関連した暗号チェックサム416がトランケートされる。
トランケートされずかつ解読されない,メディアセグメントの残りの部分418は,その後,その必要な暗号チェックサムCCS(A)415,独立復号可能部分A403,およびヘッダ414が完全な状態のままで転送される。」(以下,「引用記載5」という),
および,関連する図面である【図15A】,【図15B】に記載された内容から,
“セグメントA,B,Cとその暗号チェックサムCSS(A),CSS(B),CSS8(C)から構成されるスケーラブルメディアコンテンツ列から,セグメントBを,トランケートするとは,セグメントA,Cとその暗号チェックサムCSS(A),CSS8(C)から構成されるスケーラブルメディアコンテンツ列を生成する”ことであって,当該「トランケート」処理においては,「暗号チェックサム」は,関連する「セグメント」と共に,「スケーラブルメディアコンテンツ列」から削除されるものであって,このとき,新たな「暗号チェックサム」が計算されるものでないことは,引用記載5から明らかである。
また,当初明細書等の上記に引用した記載以外の箇所において,「復号することなく暗号化スケーラブルメディアをスケーリングする」処理過程の何れかにおいて,「トランスコーダ」,或いは,「スケーラ」によって,「暗号チェックサム」が計算されることは記載されてない。
以上のとおりであるから,
補正後の請求項1に記載の,
「前記トランスコーダが,前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)と」
は,当初明細書等に記載されたものではない。

よって,本件手続補正は,平成18年9月25日付けで提出された明細書,請求の範囲の日本語による翻訳文,及び,図面の範囲内でなされたものではない。

3.補正却下むすび
したがって,本件手続補正は,平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項により読み替える同法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,結論のとおり決定する。

その3.本願発明について
平成23年5月2日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明は,上記項目1において,補正前の請求項1として引用した,平成22年7月26日付けの手続補正により補正された特許請求の範囲の請求項1に記載された次のとおりのものである。

「コンピュータによって実行される,暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法であって,
所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを,前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること(1701)であって,前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは,復号されることなくスケーリングされること(1701)と,
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)と,
前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)と
を含み,
前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは,トランスコーダ可読ヘッダとは独立に暗号化可能であり,
トランスコードの際に,前記トランスコーダ可読ヘッダを読み出すことによって,前記複数の結合可能部分のうちの少なくとも1つの結合可能部分およびこれに関する暗号チェックサムが削除される
方法。」

その4.引用刊行物に記載の発明
一方,原審が拒絶理由に引用した,本願の第1国出願前に既に公知である,「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日」(以下,これを「引用刊行物1」という)には,次の事項が記載されている。

A.「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.」(5頁1行?19行)
(要約
この論文は,完全に,コンテンツに非特異的な方法において,任意のスケーラブル・コンテンツの表現と適応のためのエンド・ツー・エンドの方法論を示すものである。スケーラブルなビット・ストリームは,必然的に,対照的な多次元な論理的構造を形成し,そして,任意の適応化が,本質的にその構造の下向きの操作である。より上位の論理構造は,リッチ・メディアを含む,様々なビット・ストリームに,より一般的に適用可能であるように,この多層構造上に定義されている。結果として得られる合成モデルは,構造化スケーラブル・メタフォーマット(SSM)と呼ばれる。SSMに準拠したスケーラブルなビット・ストリームを生成しなければならないという,暗黙のビットストリーム制約は別にして,SSMに基礎を置く,完全な適応化と,伝達基盤を構築するために標準化される必要がある異なる2つの要素,(1)二値,或いは,ビット・ストリーム・リソースの構造,および,種々の適合したヴァージョンを得るために,それをどのように扱えるかとの,二値,或いは,XML表現と,(2)受信端末の能力と優先度に由来する送信制限のXMLの仕様,がある。制約事項と記述子を解釈することで,汎用適応化エンジンは,それを符号化,及び/または,暗号化するための,そのコンテンツの仕様の知識なしに,規定された要求と受信者の能力に適合するように,適切に適応化することができる。汎用適応化エンジンによって,異なる適応化基盤は,最早,スケーラブル・メディアの異なるタイプを必要としない。<当審にて訳出,以下,同じ>)

B.「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.」(9頁9行?10頁6行)
(2.SSMによるデジタルアイテムの適用
2.1 SSMベースの配信モデル
標準的な,メディア配信モデルを示す,図1を検討すると,そこでは,発信者によって生成されたメディアは,最終的な受信者に到達する前に,適宜の長さの適応化エンジンの鎖を通過する。メディアの発信は,受信者の終端で,それを体験するために用いられる,ソフトウェア,或いは,ハードウェアと同じく,実際のメディア符号化フォーマットを理解していると仮定する。同一の会社が,メディア・コンテンツと,体験システムの両方を作成しているか,或いは,制作者が,体験システムを開発するベンダーに,その技術を公開しているか,或いは,メディアのフォーマットが,SSM準拠のオープン・スタンダードであることが望ましい。
実際のコンテンツ-タイプとそれの復号がどのようなものかに関係なく,スケーラブル・リソースのビット・ストリームは,全ての中間の適応化エンジンが読み取り,操作することができる,SSMで整合している。これらのエンジンは,SSM準拠のスケーラブル・コンテンツを受信し,多重出力ストリームに乗せて,適応化されたコンテンツを配信する。適応後の全てのコンテンツもまた,SSMのメタ-フォーマットに準拠しているので,それは,配信の後段において,再適応化されることが可能である。
SSM準拠のメディア・ビット・ストリームと共に,適応化エンジンは,全ての可能な適応についての適応化エンジンのための,不可欠な情報を含む,記述メタ-データ(図1の細い白い矢印を参照されたい)も処理する。SSMモデルは,可能な適応化の選択を制限し,この記述のコンパクトな表現を許可する。適応化エンジンは,適応化の後段で適応化を受けることが可能になるように,メディア・ビット・ストリームだけでなく,記述メタ-データにも,適応化を行う。適応化エンジンに,この情報を示し,伝達するための,様々な可能性が存在する。MPEG-21 DIAの間では,XMLを用いる傾向があり,それは,それ自身が,メディア・ビット・ストリームの一部として,二値形式で,この情報を表現することが,単純な拡張であり,またさらに,緊密さと扱いやすさの考察に基づくことが望ましい。この情報は,リソース記述メタデータと呼ばれる。)

C.「 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.」(10頁14?21行)
(メディアの受信者/消費者と同様にメディアの発信者/制作者も,エンドユーザに経験を供給するために符号化に関する特定の知識を持っていなければならないが,内容は何か,また,それがどのように適切に適応化するためにコード化されたか,中間のインフラストラクチャーが知る必要はないことに注意する。適応化処理は,単に,リソース記述メタデータと出力制約に基づき,実際のコンテンツの仕様には依存しない。さらに,コンテンツは,それ自身,暗号化され得,トランスコーディングは,暗号化された領域において,以前どおりに開始することができる。)

D.「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.」(11頁22行?12頁21行)
(2.3 ネットワーク パケット化との関係
SSMが,全体的なスケーラブル・コンテンツ,および,どのようにフォーマット準拠のスケーラブル・コンテンツが適応化されるかを記述するメタデータのためのフォーマットについてである間は,現実の送信シナリオにおいて,コンテンツが,パケット化され,送られる必要性があるであろうことを理解することが重要である。この際,種々のデザイン選択の間で,特に興味のあるものが2つ存在する。1つは,ファイル-フォーマットとしてのSSMの解釈に基礎を置くもの,他は,パケット-フォーマットとしての解釈に基礎を置くものである。
ファイル-フォーマット用法の場合において,スケーラブル・リソースは,実際に,標準的なネットワーク・パケットよりずっと大きい。適応化エンジンが,ネットワーク・パケット化,及び,送信前に,全部のSSMファイルを,1回で,適応化するか,或いは,適応化は,多重ステージにおいて,場合により,ダウンストリームに実施されるかの,何れかである。しかしながら,後の場合においては,全てのSSM準拠のリソースが,適応化処理を開始することができる以前に,適応化エンジンによって,取得可能である必要がないことを理解することが重要である。実際,リソースの記述と,出力制約の仕様は,メディア・コンテンツに,どのように適応化を行うかを決定するために,適応化エンジンによって必要とされる,全てである。メタ-データが,全て,受信されているのであれば,図3における,スケーラブル・ビット・ストリームは,多重ネットワーク・パケットのステージに入り,既に作られている適応化決定を基礎とし,それらが到着するとして,エンジンによって,送られるか,落とされるか,部分的に落とされるかの何れかである。それ故,同一の適応化モデルが,ストリーム化されたファイルと同じように,1回でコード変換されたファイルにも当てはまる。
パケット-フォーマットのケースにおいて,全てのSMM準拠のコンテンツは,1つのパケットからなり,それは,途中の最適化エンジンで最適化され,転送され得るものである。トランケ-ションに基づくスケーラブルな最適化に基づいたパケットは,前の[28],[29]で検討されていた。このシナリオにおいては,XMLよりはむしろ,バイナリに変換する形式を用いることの方が理にかなっている。
この文章の残りでは,どのようにして,全体的なスケーラブル・ビット-ストリームが形づくられ,要求される制約は何か,どの情報が,リソースに属するリソース記述メタデータ(XML)に含まれるか,そして,どのようにして,能力と優先事項が,出力制約の仕様(XML)で運ばれるかといった:SSMの構造の仕様を述べる。また,どのようにして,ネットワーク最適化エンジンで,最適化決定がなされるかについても述べる。)

(あ)上記Bの「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準拠のメディア・ビット・ストリームと共に,適応化エンジンは,全ての可能な適応についての適応化エンジンのための,不可欠な情報を含む,記述メタ-データ(図1の細い白い矢印を参照されたい)も処理する。)」という記載から,
引用刊行物1に記載の「適応化エンジン」は,“メディア・ビット・ストリームと,適応化処理に必要な記述メタ-データとを処理する”ものであることが読み取れ,
また,上記で引用したBの記載内容と,上記Aの「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に基礎を置く,完全な適応化と,伝達基盤を構築するために標準化される必要がある異なる2つの要素,(1)二値,或いは,ビット・ストリーム・リソースの構造,および,種々の適合したヴァージョンを得るために,それをどのように扱えるかとの,二値,或いは,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. (制約事項と記述子を解釈することで,汎用適応化エンジンは,それを符号化,及び/または,暗号化するための,そのコンテンツの仕様の知識なしに,規定された要求と受信者の能力に適合するように,適切に適応化することができる)」という記載,及び,上記Bの「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を用いる傾向があり,それは,それ自身が,メディア・ビット・ストリームの一部として,二値形式で,この情報を表現することが,単純な拡張であり,またさらに,緊密さと扱いやすさの考察に基づくことが望ましい。この情報は,リソース記述メタデータと呼ばれる。)」という記載と,上記で「適応化エンジン」に対して指摘した事項から,引用刊行物1に記載の「リソース記述メタデータ」は,“SSMに準拠したスケーラブル・メディア・コンテンツは,適応化エンジンが,それを解釈することで,該スケーラブル・メディア・コンテンツがどのように符号化,及び,暗号化されたかの情報なしで,即ち,該スケーラブル・メディア・コンテンツを復号化,或いは,復号することなく,適応化が行えるようにするための,XMLで記述された記述子である”ことが読み取れる。

(い)上記(あ)において引用したAに記載の内容,及び,上記Bの「 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を用いる傾向があり,それは,それ自身が,メディア・ビット・ストリームの一部として,二値形式で,この情報を表現することが,単純な拡張であり,またさらに,緊密さと扱いやすさの考察に基づくことが望ましい。この情報は,リソース記述メタデータと呼ばれる)」という記載から,
引用刊行物1に記載の「XMLで記述された記述子」は,“メディア・ビット・ストリーム,或いは,スケーラブル・コンテンツの一部として表現されるものである”ことが読み取れる。
また,上記Bの「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.(メディアの発信は,受信者の終端で,それを体験するために用いられる,ソフトウェア,或いは,ハードウェアと同じく,実際のメディア符号化フォーマットを理解していると仮定する)」,という記載,及び,上記(あ)において引用した記載から,
引用刊行物1に記載の「メディア・ビット・ストリーム」は,“ハードウェアによって処理される”ことが読み取れ,当該技術分野においては,「ハードウェア」として,「コンピュータ」が含まれることは,当業者にとって自明の事項であるから,結果として,上記で引用した引用刊行物1の記載から,引用刊行物1に記載の「メディア・ビット・ストリーム」は,“コンピュータによって処理される”ことが読み取れる。

(う)上記Aの「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.(制約事項と記述子を解釈することで,汎用適応化エンジンは,それを符号化,及び/または,暗号化するための,そのコンテンツの仕様の知識なしに,規定された要求と受信者の能力に適合するように,適切に適応化することができる。)」という記載,上記Cの「 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.(メディアの受信者/消費者と同様にメディアの発信者/制作者も,エンドユーザに経験を供給するために符号化に関する特定の知識を持っていなければならないが,内容は何か,また,それがどのように適切に適応化するためにコード化されたかを,中間のインフラストラクチャーが知る必要はないことに注意する)」という記載,及び,上記Cの「the content itself can be encrypted, and transcoding can still proceed as before in the encrypted domain.(コンテンツは,それ自身,暗号化され得,トランスコーディングは,暗号化された領域において,以前どおりに開始することができる)」という記載から,
引用刊行物1に記載の「メディア」,或いは,「コンテンツ」は,“「メディアの制作者」,或いは,「メディアの発信者」が,「コード化」し,「記述子」を附与し,更に,「暗号化」する”こと,当該「メディア」の「トランスコーディング」は,“中間のインフラストラクチャーにおいて,暗号化された状態で,どのように暗号化/復号化されたかの知識を必要とすることなく行われる”ことが読み取れ,
また上記(あ)において引用した,上記Bの記載から,引用刊行物1に記載の「メディア」は,「メディア・ビット・ストリーム」であり,前記「メディア・ビット・ストリーム」は、「スケーラブルなリソースのビットストリーム」であることは明らかであるから,上記で検討した事項から,引用刊行物1に記載の「スケーラブルなリソースのビットストリーム」は,“中間のインフラストラクチャーにおいて,暗号化された状態で,復号することなく行われる”ことが,引用刊行物1から読み取れる。

(え)上記Dの「 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.(メタ-データが,全て,受信されているのであれば,図3における,スケーラブル・ビット・ストリームは,多重ネットワーク・パケットのステージに入り,既に作られている適応化決定を基礎とし,それらが到着するとして,エンジンによって,送られるか,落とされるか,部分的に落とされるかの何れかである。)」,及び,「Packet based scalable adaptation based on truncation has been considered before [28], [29].(トランケ-ションに基づくスケーラブルな最適化に基づいたパケットは,前の[28],[29]で検討されていた。)」という記載から,引用刊行物1に記載の「最適化」には,「トランケ-ション(truncation)」が含まれることが読み取れ,上記(あ)?(う)で検討した事項,及び,上記A?Dに引用した記載内容から,引用刊行物1に記載の「適応化エンジン」が,「適応化」,即ち,「トランスコーディング」を行っていること,該「トランスコーディング」に,「スケーリング」が含まれることは明らかであり,そして,該「トランケ-ション」が,“スケーリング”の1つであることは,当業者に自明の事項であるから,
以上,(あ)?(え)において検討した事項から,引用刊行物1には,次の発明(以下,「引用発明1」という)が記載されていると認める。

コンピュータによって実行される,暗号化されたスケーラブル・メディア・ストリームをスケーリングするための方法であって,
トランケートを含む,どのようなスケーリングを行ったかを示す情報である記述子を,前記スケーラブル・メディア・ストリームに附与し,
ここで,前記暗号化されたスケーラブル・メディア・ストリームは,復号されることなくスケーリングされるものであり,
トランスコーディングの際に,記述子を解釈することによって,トランケートが行われる
方法。

また,原審が拒絶理由に引用した,本願の第1国出願前に既に公知である,国際公開第03/030542号(2003年4月10日公開,以下,これを「引用刊行物2」という)には、関連する図面と共に,次の事項が記載されている。

E.「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. 」(12頁19?37行)
(概観すると,本発明は,スケーラブルに符号化可能なあらゆるデータを対象とし,特に,スケーラブル符号化を漸進的暗号化(progressive encryption)と組み合わせるあらゆるデータを対象とする。
本出願の目的上,スケーラブル符号化は,入力として原データを取り込み,出力としてスケーラブルに符号化されたデータを生成するプロセスとして定義される。
このスケーラブル符号化において,スケーラブルに符号化されたデータは,その一部が,様々な品質レベルを有する原データを復元するために使用できるという特性を有する。
具体的には,スケーラブルに符号化されたデータは,多くの場合,組み込みビットストリームと考えられる。
このビットストリームの最初の部分は,そのビットストリームの残りの部分からの情報を必要とすることなく,原データをベースライン品質で復元したものを復号するのに使用することができ,このビットストリームの部分の漸進的に大きな部分は,原データを改善して復元したものを復号するのに使用することができる。
本出願の目的上,漸進的暗号化は,入力として原データ(平文)を取り込み,出力として漸進的に暗号化されたデータ(暗号文)を生成するプロセスとして定義される。
この漸進的暗号化において,漸進的に暗号化されたデータは,最初の部分が,原データの残りの部分からの情報を必要とすることなく単独で解読でき,漸進的に大きな部分は,この同じ特性により解読できるという特性を有する。
この漸進的に大きな部分では,解読は,ビットストリームの後の部分ではなく前の部分からのデータを必要とすることがある。<引用刊行物2の日本語公報である特表2005-528631号より引用,なお,当審にて一部,訳を補っている,以下,同じ>)

F.「 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. 」(16頁14?26行)
( ステップ608を続けて参照すると,本発明の一実施形態では,ペイロードデータ(例えばスケーラブル映像データ)は,漸進的に暗号化される一方,ヘッダデータは,トランスコードノードがこの情報を使用してトランスコードの判定を行うことができるように,暗号化されずに残される。例えば,一実施形態では,この暗号されないヘッダは,暗号化されたペイロードデータ内の推奨された切断点のような情報を収容する。別の実施形態では,これらのヘッダデータは,中間のトランスコードノードによる準(near)レート歪み(RD(rate distortion))-最適ビットレート削減を行うために使用される。さらに,本実施形態では,トランスコードノードは,ヘッダデータを使用して,漸進的に暗号化されたスケーラブル映像データの解読もヘッダデータの解読も必要とすることなく,トランスコードの判定を行うこともできる。本発明のさらに別の実施形態では,ヘッダデータは,暗号化されて,セキュリティをさらに付加する。)

G.「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.」(22頁9?27行)
(本発明によると,データパケットをトランスコードする方法は,暗号化されたデータパケットに対して実行される。;すなわち,メディアデータは,解読されない。 トランスコード機能は,データパケット(具体的には,データパケットのペイロード部)を切断(トランケート)すること,ストリームから一定のデータパケットを除去すること,またはデータパケットを変更することなく通過させることを含むことができる。

まず図18Aを参照すると,入来する暗号化および/または符号化が行われたデータパケットが,トランスコーダ1620によって受信される。 この実施形態では,各データパケットのヘッダ部は暗号化されていない。トランスコーダ1620は,ヘッダ部を読み出す。ヘッダ部は,トランスコードの判定を行うために使用可能な情報を収容している。一実施形態では,ヘッダ部の情報は,切断(トランケート)点の指定を含む。別の実施形態では,切断(トランケート)点は,ヘッダに設けられた情報から導出される。

例えば,ヘッダ部は,データパケットのペイロード部を切断(トランケート)するための推奨された点(例えばビット番号)を指定する情報を収容することができる。各データパケットは,異なる切断(トランケート)点を有してもよいことが理解される。)

H.「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.」(23頁13?18行)
(また、ヘッダ部は、例えば番号により各データパケットを識別する情報を収容することもできる。したがって、トランスコーダ1620は、ストリームから一定のデータパケットを除去することができる; 例えば、1つおきのパケット(例えば奇数番号のパケット)が除去されるべきである場合、トランスコーダ1620は、ヘッダ情報を使用して、奇数番号のデータパケットを識別し、それらのデータパケットを、データパケットのストリームから除去することができる。)

I.「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. 」(26頁16?29行)
(図20の実施形態では,データパケット2000は,ヘッダデータ部2002と,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004とを含む。 上述したように,ヘッダデータ部2002は,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004をトランスコードするためにトランスコーダ1620によって使用される情報を含む。 例えば,ヘッダデータ部2002は,データパケット2000のペイロード部(例えば,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004)を切断(トランケート)するための推奨された点(例えば,ビット番号)指定する情報を収容することができる。 また,ヘッダデータ部2002は,例えば番号により各データパケットを識別する情報を収容することもできる。 したがって,トランスコーダ1620は,一定のデータパケットをストリームから除去することもできる。 例えば,1つおきのパケット(例えば奇数番号のパケット)が除去されるべきである場合,トランスコーダ1620は,ヘッダデータ部2002の情報を使用して,奇数番号のデータパケットを識別し,それらのデータパケットを,データパケットのストリームから除去することができる。)

(お)上記Eの「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)と組み合わせるあらゆるデータを対象とする。)」という記載,上記Gの「incoming encrypted and/or encoded data packets are received by transcoder1620.(入来する暗号化および/または符号化が行われたデータパケットが,トランスコーダ1620によって受信される。)」という記載,及び,上記引用のEの記載中の「漸進的暗号化(progressive encryption)」から,該「漸進的暗号化」は,「プログレッシブ暗号化」と同一のものであるということから,引用刊行物2には,“トランスコーダが,スケーラブルに符号化され,プログレッシブ暗号化されたデータパケットを受信する”点が記載されていることが読み取れ,加えて,上記Eの「Specifically, the scalably coded data are often thought of as an embedded bitstream.(具体的には,スケーラブルに符号化されたデータは,多くの場合,組み込みビットストリームと考えられる。)」という記載から,前記“スケーラブルに符号化され,プログレッシブ暗号化されたデータパケット”は,“スケーラブルに符号化され,プログレッシブに暗号化されたビットストリーム”を含むことが読み取れるので,結果として,上記引用の引用刊行物2に記載の内容から,“トランスコーダが,スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームを受信する”ことが読み取れる。

(か)上記Gの「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.(データパケットをトランスコードする方法は,暗号化されたデータパケットに対して実行される。;すなわち,メディアデータは,解読されない。トランスコード機能は,データパケット(具体的には,データパケットのペイロード部)を切断(トランケート)すること,ストリームから一定のデータパケットを除去すること,またはデータパケットを変更することなく通過させることを含むことができる。)」という記載と,上記(お)で検討した事項から,引用刊行物2には,“トランスコーダで受信された,スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームは,トランスコーダによって,復号されることなく,切断(トランケート)され,ストリームから一定のデータが除去される”ことが記載されていると読み取れ,
同じく上記Gの「 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.(トランスコーダ1620は,ヘッダ部を読み出す。ヘッダ部は,トランスコードの判定を行うために使用可能な情報を収容している。一実施形態では,ヘッダ部の情報は,切断(トランケート)点の指定を含む。)」という記載,及び,上記Hの「The header portion may also contain information identifying each data packet by number, for example.(また、ヘッダ部は、例えば番号により各データパケットを識別する情報を収容することもできる。)」という記載,並びに,上記Iの「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.(ヘッダデータ部2002は,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004をトランスコードするためにトランスコーダ1620によって使用される情報を含む。 例えば,ヘッダデータ部2002は,データパケット2000のペイロード部(例えば,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004)を切断(トランケート)するための推奨された点(例えば,ビット番号)指定する情報を収容することができる。)」という記載から,引用刊行物2に記載の「ヘッダ部」には,“スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームのトランスコードの判定を行うために使用可能な情報が収容され,前記使用可能な情報には,前記スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームをトランケートするための,トランケート点が含まれる”ことが読み取れる。

(き)上記Iの「 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(また,ヘッダデータ部2002は,例えば番号により各データパケットを識別する情報を収容することもできる。 したがって,トランスコーダ1620は,一定のデータパケットをストリームから除去することもできる。)」という記載と,上記(お),及び,(か)で検討した事項から,引用刊行物2に記載の「トランスコーダ」は,“ヘッダに収容された情報を用いて,スケーラブルに符号化され,プログレッシブ暗号化されたビット・ストリームをトランケートし,前記ビット・ストリームの一部を除去する”ものであることが読み取れ,上記Iの「data packet2000 includes header data portion 2002 and scalably encoded, progressively encrypted video data portion2004 .(データパケット2000は,ヘッダデータ部2002と,スケーラブルに符号化されて漸進的に暗号化された映像データ部2004とを含む。)」という記載から,引用刊行物2に記載の「ヘッダ部」は,“ビットストリームに含まれる”ことが読み取れる。

(く)上記Fの「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.(ペイロードデータ(例えばスケーラブル映像データ)は,漸進的に暗号化される一方,ヘッダデータは,トランスコードノードがこの情報を使用してトランスコードの判定を行うことができるように,暗号化されずに残される。)」という記載,同じく,上記Fの「In yet another embodiment of the present invention, the header data are encrypted to add additional security.(本発明のさらに別の実施形態では,ヘッダデータは,暗号化されて,セキュリティをさらに付加する。)」という記載,並びに,上記Gの「in this embodiment, the header portion of each data packet is not encrypted.(この実施形態では,各データパケットのヘッダ部は暗号化されていない。)」という記載から,引用刊行物2に記載の「ヘッダ部」は,“ビットストリーム内のペイロードデータとは,別々に暗号化可能である”ことが読み取れるので,
以上(お)?(く)に検討した事項から,引用刊行物2には,次の発明(以下,「引用発明2」という)が記載されているものと認める。

スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームをトランスコードする,トランスコーダであって,
前記スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームは,前記ビットストリームをトランケートするためのトランケート点,或いは,前記ビット・ストリームの一部を削除するための点を収容したヘッダ部と,ペイロードデータとを有し,
前記ビット・ストリームは,トランスコーダにおいて,復号されることなくトランスコードされ,
トランスコードの際に,前記ヘッダ部の収容した情報を用いて,前記ビット・ストリームの一部が削除されることを有し,
前記ヘッダ部は,ビットストリームのペイロードデータとは,別々に暗号化可能である
トランスコーダ。

更に,原審が拒絶理由に引用した,本願の第1国出願前に既に公知である,特開平10-105449号公報(1998年4月24日公開,以下,これを「引用刊行物3」という)には,関連する図面と共に,次の事項が記載されている。

J.「【0001】
【発明の属する技術分野】本発明は,電子データ伝送の分野に関わり,異なるセキュリティ要件を有する複数のデータコンポーネントの記憶または伝送を安全にバンドル操作することのできるファイル構造を提供するものである。このファイル構造を勝手に書き換えるようなことがあると,即時に中継ぎコンポーネントが開かれてそれが明らかとなる。」

K.「【0030】従って,これらの異なるセキュリティ要件に対処するために,本発明は,図2の一実施例に示す一般保護ファイルフォーマット(GSFF)を提供する。このファイルフォーマットによれば,複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる。各ファイルには,他のファイルとは異なるセキュリティ要件を設定することができる。この保護ファイルフォーマットを使えば,異なるファイルタイプを単一のラッパーで交換することができる。また,この保護ファイルフォーマットによれば,1つのファイルを複数のセクションに分割して,それらを単一ファイルにラップすることができる。ファイル内の各セクションは,独自にセキュリティ保護がなされる。これによって,機密情報だけを保護し,他のセクションはセキュリティ保護の必要があまりない,または全くその必要がない状態にしておくことができる。その結果,セキュリティに関与する操作は,ファイルのほんの一部しか必要ないため,性能が上がる。
【0031】本発明の一般保護ファイルフォーマットがサポートするセキュリティ機能には,暗号化によるデータ機密性,ハッシュによるデータ完全性,メッセージダイジェスト,メッセージ確認コード(MAC,ANSI規格として定義されている)およびデジタル署名が含まれる。
【0032】図2に示すように,一般保護ファイルフォーマットには,ファイル見出し10,続いて,複数のファイル本体12,ファイル後書き14,その次にデータ16がある。各ファイル本体12には,後述するとおり,他の実施される本体とは異なるセキュリティ要件を設定することができる。例えば,1つのファイルは暗号化を必要とし,他のファイルはデータ完全性の保護だけを必要とする場合などである。
【0033】各ファイルは,その要件に従ってラップされ,ファイル本体に記述される。データのポインタは,ファイル本体セクションに含まれ,データはファイル後書きの後に置かれる。
【0034】本発明の一般保護ファイルフォーマットはディレクトリベースのファイルフォーマットである。ファイル見出し,ファイル本体およびファイル後書きはラッパー内ではディレクトリとみなされる。ファイル見出しには,一般保護ファイルフォーマットのファイル識別子,バージョン番号およびラッパーの長さが含まれる。各ファイル本体には,そのファイル本体に関連するエントリが含まれる。ファイル後書きは,ラッパー全体のセキュリティ保護に用いることができる。
【0035】ファイル見出しの構造の概略を図3に示す。ファイル見出しには,一般保護ファイルフォーマット識別子20,ファイルフォーマットを単に識別する一対のバイトのタグ(例えば,インテルとモトローラのバイト順を識別する),一般保護ファイルフォーマットのバージョン番号22,ファイルインジケータ24および一般保護ファイルフォーマットの全ファイル長26が含まれる。
【0036】各ファイル本体は,ラッパーに含まれるファイルを記述する。図4に概略を示すように,ファイル本体には,本体ファイルとしてファイルのタイプを識別して,ファイル長を設定するためのファイル本体タグ28,次にセキュリティ規格30がある。セキュリティ規格には,セキュリティタイプ,セキュリティアルゴリズム,セキュリティアルゴリズムパラメータ,暗号鍵情報,操作モード,フィルタ,キャラクタセット,出力ファイル規格パラメータ,データ長,およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている。」

(け)上記Jの「本発明は,電子データ伝送の分野に関わり,異なるセキュリティ要件を有する複数のデータコンポーネントの記憶または伝送を安全にバンドル操作することのできるファイル構造を提供するものである」との記載から,引用刊行物に記載の「ファイル」は,「電子データ伝送」に用いられるものであることが読み取れ,
上記Kの「このファイルフォーマットによれば,複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる。各ファイルには,他のファイルとは異なるセキュリティ要件を設定することができる。この保護ファイルフォーマットを使えば,異なるファイルタイプを単一のラッパーで交換することができる。また,この保護ファイルフォーマットによれば,1つのファイルを複数のセクションに分割して,それらを単一ファイルにラップすることができる。ファイル内の各セクションは,独自にセキュリティ保護がなされる。」という記載から,
引用刊行物3における「ファイルフォーマット」が,“複数のファイルをラップして記憶または交換用に単一のエンティティにすることができる”ものであること,及び,“1つのファイルのセクションに分割して,各セクションに異なるセキュリティ保護を施し,それを,単一のファイルにラップ”し得るものであることが読み取れ,このことから,“各セクション”のそれぞれは,“ファイル”であることも読み取れる。
したがって,引用刊行物3においては,
“一旦,ファイルを分割し,分割したファイルのそれぞれに異なるセキュリティ保護を施し,それを再び単一のファイルにラップする”態様を含むものであることが読み取れる。

(こ)上記Kの「本発明の一般保護ファイルフォーマットがサポートするセキュリティ機能には,暗号化によるデータ機密性,ハッシュによるデータ完全性,メッセージダイジェスト,メッセージ確認コード(MAC,ANSI規格として定義されている)およびデジタル署名が含まれる」という記載から,
引用刊行物3における「ファイルフォーマットの機能」には,「暗号化によるデータ機密性,ハッシュによるデータ完全性,メッセージダイジェスト,メッセージ確認コード(MAC,ANSI規格として定義されている)およびデジタル署名が含まれる」ことが読み取れる。

(さ)上記Kの「一般保護ファイルフォーマットには,ファイル見出し10,続いて,複数のファイル本体12,ファイル後書き14,その次にデータ16がある。各ファイル本体12には,後述するとおり,他の実施される本体とは異なるセキュリティ要件を設定することができる。例えば,1つのファイルは暗号化を必要とし,他のファイルはデータ完全性の保護だけを必要とする場合などである」という記載,及び,上記Kの「各ファイル本体は,ラッパーに含まれるファイルを記述する。図4に概略を示すように,ファイル本体には,本体ファイルとしてファイルのタイプを識別して,ファイル長を設定するためのファイル本体タグ28,次にセキュリティ規格30がある。セキュリティ規格には,セキュリティタイプ,セキュリティアルゴリズム,セキュリティアルゴリズムパラメータ,暗号鍵情報,操作モード,フィルタ,キャラクタセット,出力ファイル規格パラメータ,データ長,およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている」という記載から,
引用刊行物3における「ファイル」には,それぞれ異なる「セキュリティ要件」が設定可能であり,前記「ファイル」を記述する「ファイル本体」には,「セキュリティ規格」があり,前記「セキュリティ規格」には,「セキュリティタイプ,セキュリティアルゴリズム,セキュリティアルゴリズムパラメータ,暗号鍵情報,操作モード,フィルタ,キャラクタセット,出力ファイル規格パラメータ,データ長,およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている」ことが読み取れる。

以上,(け)?(さ)で検討した事項から,引用刊行物3には,次の周知技術が記載されているものと認める。

データ伝送に用いられる1つのファイルを複数のファイルに分割して,前記分割された各ファイルに異なるセキュリティ保護を施し,それを,単一のファイルにラップする方法であって,
前記方法に用いるファイルフォーマットの機能には,暗号化によるデータ機密性,ハッシュによるデータ完全性,メッセージダイジェスト,メッセージ確認コード(MAC,ANSI規格として定義されている)およびデジタル署名が含まれ,
前記各ファイルには,それぞれ異なるセキュリティ要件が設定可能であり,前記各ファイルを記述するファイル本体には,セキュリティ規格があり,前記セキュリティ規格には,セキュリティタイプ,セキュリティアルゴリズム,セキュリティアルゴリズムパラメータ,暗号鍵情報,操作モード,フィルタ,キャラクタセット,出力ファイル規格パラメータ,データ長,およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれている,
方法。

その5.本願発明と引用発明との対比
次に,本願発明と引用発明1とを対比すると,
イ.引用発明1における「スケーラブル・メディア・ストリーム」は,
本願発明における「スケーラブルデータ列」に相当するので,
引用発明1における「コンピュータによって実行される,暗号化されたスケーラブル・メディア・ストリームをスケーリングするための方法」と,
本願発明における「コンピュータによって実行される、暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法」とは,
“コンピュータによって実行される,暗号化されたスケーラブルデータ列をスケーリングするための方法”である点で共通し,
ロ.引用発明1における「トランケートを含む,そのようなスケーリングを行ったかを示す情報である記述子」は,「スケーラブル・メディア・ストリーム」に附与されているものであるから,前記「記述子」は,前記「スケーラブル・メディア・ストリーム」に関連付けされていることは明らかであり,
前記「記述子」も,本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」も,「スケーラブル・メディア・ストリーム」,或いは,「スケーラブルデータ列」の「スケーリング」の際に用いられるものであるから,
引用発明1における「トランケートを含む,どのようなスケーリングを行ったかを示す情報である記述子」と,
本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」とは,
“暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータ”である点で共通するので,
引用発明1における「トランケートを含む,どのようなスケーリングを行ったかを示す情報である記述子を,前記スケーラブル・メディア・ストリームに附与し」と,
本願発明における「所望のスケーラブル属性を保有するようにスケーリングされる前記プログレッシブ暗号化されたスケーラブルデータ列のスケーリングされたバージョンを生成するために結合する前記プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータを、前記プログレッシブ暗号化された(1703)スケーラブルデータ列に関連付けること」とは,
“暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータを,前記暗号化されたスケーラブルデータ列に関連付ける”ことである点で共通し,
ハ.引用発明1における「前記暗号化されたスケーラブル・メディア・ストリームは,復号されることなくスケーリングされる」と,
本願発明における「前記プログレッシブ暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされる」とは,
“暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされる”点で共通し,
引用発明1における「記述子」は,上記イで検討したように,暗号化されたデータに附与されたものであり,一方,本願発明における「トランスコーダ可読ヘッダ」が,「暗号化されたスケーラブルデータ列」に結合していることは明らかであるから,
引用発明1における「トランスコーディングの際に,記述子を解釈することによって,トランケートが行われる」と,
本願発明における「トランスコードの際に、前記トランスコーダ可読ヘッダを読み出すことによって、前記複数の結合可能部分のうちの少なくとも1つの結合可能部分およびこれに関する暗号チェックサムが削除される」とは,
“トランスコードの際に,暗号化されたスケーラブルデータ列に附与されたデータを用いることで,トランスコードが行われる”点で共通するので,
以上イ?ハで検討した事項から,本願発明と,引用発明1との一致点,及び,相違点は次のとおりである。

[一致点]
コンピュータによって実行される,暗号化されたスケーラブルデータ列をスケーリングするための方法であって,
暗号化されたスケーラブルデータ列をスケーリングするために用いられるデータを,前記暗号化されたスケーラブルデータ列に関連付けられ,
暗号化されたスケーラブルデータ列の前記スケーリングされたバージョンは、復号されることなくスケーリングされ,
トランスコードの際に,暗号化されたスケーラブルデータ列に附与されたデータを用いることで,トランスコードが行われる
方法

[相違点1]
“暗号化されたスケーラブルデータ列”が,
本願発明においては,
「暗号化データの先行する部分を原データの残り部分からの情報を必要とせずに単独で解読可能であるという特性を有するプログレッシブ暗号化されたスケーラブルデータ列」であるのに対して,
引用発明1においては,「プログレッシブ暗号化」については言及されていない点,

[相違点2]
“暗号化されたスケーラブルデータ列に関連付けられたデータ”が,
本願発明においては,
「プログレッシブ暗号化されたスケーラブルデータ列のトランケート可能な複数の結合可能部分を特定するデータ」であるのに対して,
引用発明1においては,
「どのようなスケーリングを行ったかを示す情報」であって,「トランケート可能な複数の結合可能部分を特定するデータ」ではない点,

[相違点3]
本願発明においては,
「前記プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分それぞれの暗号チェックサムを計算すること(1705)と,
前記暗号チェックサムを,前記プログレッシブ暗号化されたスケーラブルデータ列の少なくとも1つの部分に関連付けること(1707)と」を含むものであるのに対して,
引用発明1においては,
「暗号チェックサム」に関して言及されていない点,

[相違点4]
本願発明においては,
「プログレッシブ暗号化されたスケーラブルデータ列の前記結合可能部分および前記暗号チェックサムは,トランスコーダ可読ヘッダとは独立に暗号化可能であ」るのに対して,
引用発明1においては,
「記述子」が暗号化されるかについては,言及されていない点,

[相違点5]
“トランスコードの際に,暗号化されたスケーラブルデータ列に附与されたデータを用いることで,トランスコードが行われる”ことに関して,
本願発明においては,
“附与されたデータ”は,「トランスコーダ可読ヘッダ」であり,“トランスコード”は,「複数の結合可能部分のうちの少なくとも1つの結合可能部分およびこれに関する暗号チェックサムが削除される」ことであるに対して,
引用発明においては,
“附与されたデータ”は,「記述子」であり,“トランスコード”は,「トランケート」ではあるが,「暗号チェックサムが除去される」ことまでは言及されていない点,

その6.当審の判断
上記相違点について検討する。

[相違点1],[相違点2],及び,[相違点4]について,
上記項目その4.引用刊行物に記載の発明において引用した引用発明2は,同項目その4で認定したとおりの構成を有しており,引用発明2の構成から明らかなように,
「スケーラブルに符号化され,プログレッシブ暗号化されたビットストリームをトランスコードする」こと,
「トランスコードの際に,前記ヘッダ部の収容した情報を用いて,前記ビット・ストリームの一部が削除される」こと,及び,
「ヘッダ部は,ビットストリームのペイロードデータとは,別々に暗号化可能である」ことは,本願の第1国出願前に,当業者には公知の技術事項である。
そして,引用発明1も,引用発明2も,“暗号化されたスケーラブル・ビット・ストリームをスケーリングする”技術に関するものであり,引用発明1の「記述子」も,引用発明2における「ヘッダ部」も,共に,「スケーラブル・ビット・ストリーム」に附与,或いは,結合されたものであるから,引用発明1における「記述子」を,引用発明2における「ヘッダ部」に変更し,引用発明1における「トランケート」処理に,更に,ビット・ストリームの一部を削除する処理を加えること,及び,該ヘッダ部を,独立に暗号化するようにすることは,当業者が適宜なし得る事項である。
よって,相違点1,相違点2,及び,相違点4は格別のものでない。

[相違点3],及び,[相違点5]について,
上記項目その4.引用刊行物に記載の発明において引用した周知技術に示したとおり,データ転送で送信されるファイルを,複数に分割し,分割した各ファイルについて,それぞれ異なるセキュリティ要件が設定可能であり,前記各ファイルを記述するファイル本体には,セキュリティ規格があり,前記セキュリティ規格には,セキュリティタイプ,セキュリティアルゴリズム,セキュリティアルゴリズムパラメータ,暗号鍵情報,操作モード,フィルタ,キャラクタセット,出力ファイル規格パラメータ,データ長,およびフィルタ後書きに後続する安全に保護されたファイルデータ用データポインタが含まれているようにすることは,本願の第1国出願前に,当業者には周知の技術事項であり,該分割されたファイルは,即ち,分割されたデータであるから,当該周知技術が,引用発明1における,スケーラブル・ビット・ストリームに適用可能であることは,また,前記セキュリティ要件,或いは,セキュリティ規格に,「暗号チェックサム」を含め得ることは,当業者とって自明の事項であるから,引用発明において,スケーラブル・ビット・ストリームを複数に分割し,それぞれにプログレッシブ暗号化とは異なるセキュリティ要件である,例えば,暗号チェックサム等を適用することは,当業者が適宜なし得る事項である。
そして,上記で検討したことと,上記[相違点1],[相違点2],及び,[相違点4]についてで検討した事項とから,引用発明1において,スケーラブル・ビット・ストリームの一部を,ヘッダ部の情報に基づいて削除した場合に,前記一部に関連するセキュリティ要件も同時に削除されるようにすることは,当業者にとって自明の事項である。
よって,相違点3,及び,相違点5は格別のものでない。

上記で検討したごとく,相違点1?5はいずれも格別のものではなく,そして,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
以上のとおりであるから,本願発明は,引用発明1,及び,引用発明2,並びに,周知技術から,当業者が容易になし得たものである。

その7.むすび
したがって,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2012-05-11 
結審通知日 2012-05-14 
審決日 2012-05-28 
出願番号 特願2006-553302(P2006-553302)
審決分類 P 1 8・ 561- Z (H04L)
P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 山崎 達也
特許庁審判官 石井 茂和
田中 秀人
発明の名称 プログレッシブ暗号化されたスケーラブルデータ列をスケーリングするための方法  
代理人 特許業務法人アイ・ピー・エス  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ