【事件の表示】
　特願２０１５−５０９１５３「アダプティブストリーミングのための，セグメントの保全性および信頼性のためのシステムおよび方法」拒絶査定不服審判事件〔平成２５年１０月３１日国際公開，ＷＯ２０１３／１６３４７７，平成２７年　７月　９日国内公表，特表２０１５−５１９８１４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２０１３年４月２５日（パリ条約による優先権主張外国庁受理２０１２年４月２５日，２０１３年４月２５日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２６年１１月２８日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，平成２７年１１月１３日付けで審査官により拒絶理由が通知され，これに対して平成２８年２月１日付けで意見書が提出されると共に手続補正がなされたが，平成２８年２月１９日付けで審査官により拒絶査定がなされ（謄本送達：平成２８年３月１日），これに対して平成２８年６月２１日付けで審判請求がなされると共に手続補正がなされ，平成２８年７月１５日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２８年１０月２６日付けで上申書の提出があったものである。
　
第２．平成２８年６月２１日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成２８年６月２１日付け手続補正を却下する。
　
　［理由］
　
１．補正の内容
　平成２８年６月２１日付けの手続補正（以下，「本件手続補正」という）により，平成２８年２月１日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップとを含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得される，方法。
　　【請求項２】
　前記正しいダイジェストまたはデジタル署名がサーバから受信される，請求項1に記載の方法。
　　【請求項３】
　サーバが，前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する，請求項2に記載の方法。
　　【請求項４】
　前記ダイジェストが暗号ハッシュである，請求項1に記載の方法。
　　【請求項５】
　前記デジタル署名がメッセージ認証コードである，請求項1に記載の方法。
　　【請求項６】
　セグメントの改変が，前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む，請求項1に記載の方法。
　　【請求項７】
　前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するステップをさらに含む，請求項1に記載の方法。
　　【請求項８】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントであって，
　プロセッサと，
　前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを備え，前記プログラミングが，
　　メディアストリームのセグメントを受信するための命令と，
　　前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と，
　　前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するための命令と，を含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得される，ネットワークコンポーネント。
　　【請求項９】
　前記正しいダイジェストまたは前記正しいデジタル署名がサーバから受信される，請求項8に記載のネットワークコンポーネント。
　　【請求項１０】
　前記サーバが，前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する，請求項9に記載のネットワークコンポーネント。
　　【請求項１１】
　前記ダイジェストがメッセージ認証コードを含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１２】
　　前記ダイジェストが暗号ハッシュを含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１３】
　セグメントの改変が前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１４】
　前記プログラミングが，前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するための命令を更に含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１５】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって，前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む，受信するステップと，
　前記UEを用いて，前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記UEを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと，
　前記UEを用いて，前記セグメントが改変されているかどうかを判定するステップと，を含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得される，方法。
　　【請求項１６】
　前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される，請求項15に記載の方法。
　　【請求項１７】
　前記ダイジェストがメッセージ認証コードを含む，請求項15に記載の方法。
　　【請求項１８】
　前記ダイジェストが暗号ハッシュを含む，請求項15に記載の方法。
　　【請求項１９】
　前記暗号ハッシュがセキュアハッシュアルゴリズム(SHA)でありかつ前記SHAがSHA-256またはSHA-512を含む，請求項18に記載の方法。
　　【請求項２０】
　前記セグメントが改変されたかどうかを判定するステップが前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を判定するステップを含む，請求項15に記載の方法。
　　【請求項２１】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたユーザ機器であって，
　プロセッサと，
　前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体と，を備え，前記プログラミングが，
　　メディアストリームのセグメントを受信するステップであって，前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む，受信するための命令と，
　　前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と，
　　前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するための命令と，
　　前記セグメントが改変されているかどうかを判定するための命令と，を備え，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得される，ユーザ機器。
　　【請求項２２】
　前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される，請求項21に記載のユーザ機器。
　　【請求項２３】
　前記ダイジェストがメッセージ認証コードを含む，請求項21に記載のユーザ機器。
　　【請求項２４】
　前記ダイジェストが暗号ハッシュを含む，請求項21に記載のユーザ機器。
　　【請求項２５】
　前記セグメントが改変されたかどうかを判定するステップが，前記メディアストリーム中の他のセグメントに対して前記セグメントの時間順序の変更を判定するステップを含む，請求項21に記載のユーザ機器。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップとを含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され，前記MPDは，前記データ処理システムで受信される，方法。
　　【請求項２】
　前記正しいダイジェストまたはデジタル署名がサーバから受信される，請求項1に記載の方法。
　　【請求項３】
　サーバが，前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する，請求項2に記載の方法。
　　【請求項４】
　前記ダイジェストが暗号ハッシュである，請求項1に記載の方法。
　　【請求項５】
　前記デジタル署名がメッセージ認証コードである，請求項1に記載の方法。
　　【請求項６】
　セグメントの改変が，前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む，請求項1に記載の方法。
　　【請求項７】
　前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するステップをさらに含む，請求項1に記載の方法。
　　【請求項８】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントであって，
　プロセッサと，
　前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを備え，前記プログラミングが，
　　メディアストリームのセグメントを受信するための命令と，
　　前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と，
　　前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するための命令と，を含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され，前記MPDは，前記ネットワークコンポーネントで受信される，ネットワークコンポーネント。
　　【請求項９】
　前記正しいダイジェストまたは前記正しいデジタル署名がサーバから受信される，請求項8に記載のネットワークコンポーネント。
　　【請求項１０】
　前記サーバが，前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する，請求項9に記載のネットワークコンポーネント。
　　【請求項１１】
　前記ダイジェストがメッセージ認証コードを含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１２】
　　前記ダイジェストが暗号ハッシュを含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１３】
　セグメントの改変が前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１４】
　前記プログラミングが，前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するための命令を更に含む，請求項8に記載のネットワークコンポーネント。
　　【請求項１５】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって，前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む，受信するステップと，
　前記UEを用いて，前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記UEを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと，
　前記UEを用いて，前記セグメントが改変されているかどうかを判定するステップと，を含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され，前記MPDは，前記ユーザ機器で受信される，方法。
　　【請求項１６】
　前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される，請求項15に記載の方法。
　　【請求項１７】
　前記ダイジェストがメッセージ認証コードを含む，請求項15に記載の方法。
　　【請求項１８】
　前記ダイジェストが暗号ハッシュを含む，請求項15に記載の方法。
　　【請求項１９】
　前記暗号ハッシュがセキュアハッシュアルゴリズム(SHA)でありかつ前記SHAがSHA-256またはSHA-512を含む，請求項18に記載の方法。
　　【請求項２０】
　前記セグメントが改変されたかどうかを判定するステップが前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を判定するステップを含む，請求項15に記載の方法。
　　【請求項２１】
　アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたユーザ機器であって，
　プロセッサと，
　前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体と，を備え，前記プログラミングが，
　　メディアストリームのセグメントを受信するステップであって，前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む，受信するための命令と，
　　前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と，
　　前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するための命令と，
　　前記セグメントが改変されているかどうかを判定するための命令と，を備え，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され，前記MPDは，前記ユーザ機器で受信される，ユーザ機器。
　　【請求項２２】
　前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される，請求項21に記載のユーザ機器。
　　【請求項２３】
　前記ダイジェストがメッセージ認証コードを含む，請求項21に記載のユーザ機器。
　　【請求項２４】
　前記ダイジェストが暗号ハッシュを含む，請求項21に記載のユーザ機器。
　　【請求項２５】
　前記セグメントが改変されたかどうかを判定するステップが，前記メディアストリーム中の他のセグメントに対して前記セグメントの時間順序の変更を判定するステップを含む，請求項21に記載のユーザ機器。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
（１）新規事項
　本件手続補正が，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件手続補正が，平成２６年１１月２８日付けで提出された明細書，請求の範囲の日本語による翻訳文，及び，国際出願の願書に添付した図面に記載した事項（以下，これを「当初明細書等」という）の範囲内でなされたものであるかについて，以下に検討する。
ア．補正事項
　本件手続補正は，補正前の請求項１に係る発明における発明特定事項である「MPD」について，「MPDは，前記データ処理システムで受信される」という記載を加えるものであり（以下，これを「補正事項１」という），
　補正前の請求項８における発明特定事項である「MPD」について，「MPDは，前記ネットワークコンポーネントで受信される」という記載を加えるものであり（以下，これを「補正事項２」という），
　補正前の請求項１５，及び，補正前の請求項２１における発明特定事項である「MPD」について，「MPDは，前記ユーザ機器で受信される」という記載を加えるものである（以下，これを「補正事項３」という）。
　そして，当初明細書等には，補正事項１〜補正事項３に相当する記載は存在しない。
　そこで，当初明細書等に記載された内容から，補正事項１〜補正事項３が読み取れるかについて，以下に検討する。
　
イ．補正事項１，及び，補正事項２について
　当初明細書等には，補正後の請求項１に記載の「データ処理システム」，及び，補正後の請求項８に記載の「ネットワークコンポーネント」について，当初明細書等の請求の範囲の記載の他，「データ処理システム」に関しては，当初明細書等の段落【００１６】に，「ネットワークコンポーネント」に関しては，当初明細書等の段落【００１７】に記載されているのみである。
　そして，上記に指摘のとおり，当初明細書等には，補正事項１，及び，補正事項２と同一の記載は存在せず，また，「データ処理システム」，及び，「ネットワークコンポーネント」に関連して，「MPD」が，受信されることを推察させるような記載も存在しない。
　そして，「データ処理システム」，及び，「ネットワークコンポーネント」という表現では，当初明細書等において，「メディアストリーム」を受信する「クライアント」に解釈されるものではなく，当初明細書等の【図１】に開示されている，番号「１０２」を与えられた構成要素を「クライアント」，番号「１０４」を与えられた構成要素，或いは，番号「１０６」を与えられた構成要素を，「サーバ」と解すると，番号「１０８」を与えられた構成要素は，“中継のための構成要素”と見なすことができ，「データ処理システム」，及び，「ネットワークコンポーネント」という表現では，このような“中継のための構成要素”を含むことは，明らかであるから，仮に，当初明細書等の記載から，“クライアントが，MPDを受信する”という構成が読み取れたとしても，“中継のための構成要素を含み得る，「データ処理システム」，或いは，「ネットワークコンポーネント」が，MPDを受信する”という構成までは，読み取ることができない。
　
ウ．補正事項３について
　当初明細書等には，「ユーザ機器」に関して，当初明細書等の請求の範囲の記載の他，段落【００１８】に，
「ユーザ機器においてメディアストリームのセグメントを受信する」，
　という，当初明細書等の請求の範囲と同等の記載が存在するほか，段落【００２４】に，
「クライアントは，たとえば，パーソナルコンピュータ，ラップトップコンピュータ，タブレットコンピュータ，スマートフォン，携帯情報端末などを含む，任意のタイプのユーザ機器（UE）であってよい。」
　と記載されていて，当初明細書等の発明の詳細な説明において，「ユーザ機器」が，「クライアント」であることは，読み取れる。
　しかしながら，当初明細書等には，「ユーザ装置」，或いは，「クライアント」が，「MPD」を受信することについては，明文の記載は存在しない。
　そこで，「MPD」について，当初明細書等の記載内容を検討すると，当初明細書等には，段落【００８５】に，
「実施形態は組み合わされたダイジェストに関するURLを割り当てる。
組み合わされたダイジェストに関するURLはそのダイジェストをどこで取り出すべきかを信号送信するためにMPDによって運ばれる
クライアントは組み合わされたダイジェストを取り出す
　と記載されていて，上記引用記載中の「組み合わされたダイジェストに関するURLはそのダイジェストをどこで取り出すべきかを信号送信するためにMPDによって運ばれる」ことと，「クライアントは組み合わされたダイジェストを取り出す」ことから，「クライアント」が，「URL」を運ぶ「MPD」を受け取る，即ち，受信するであろうことが，上記引用の記載から，一応，推察されるので，「ユーザ機器」に関する補正事項３が，当初明細書の記載に基づかないものであるとまでは，言えない。
　
エ．まとめ
　以上，イ．，及び，ウ．において検討したとおりであるから，補正事項３については，当初明細書等に記載されていないとまでは，言えないものの，補正事項１，及び，補正事項２については，当初明細書等の記載の範囲内でなされたものではない。
　
（２）新規事項むすび
　したがって，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
（２）独立特許要件
　上記「（１）新規事項」において検討したとおり，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，
　仮に，本件手続補正が，当初明細書等の記載の範囲内でなされたものであるとすると，補正事項１〜補正事項３は，補正前の請求項１，補正前の請求項８，補正前の請求項１５，及び，補正前の請求項２１に係る発明における，発明特定事項である「MPD」を限定するものであると解せるので，
　本件手続補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定を満たすものであるか否か，即ち，補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か，以下に検討する。
　
ア．補正後の請求項１に係る発明
　補正後の請求項１は，上記「（１）新規事項」において検討したとおり，当初明細書等に記載されていない事項を含むものであるが，一応，補正後の請求項１に係る発明（以下，「本件手続補正」という）を，上記「１．補正の内容」において，補正後の請求項１として引用した，次の記載のとおりのものであるとする。
　
「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップとを含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され，前記MPDは，前記データ処理システムで受信される，方法。」
　
イ．引用刊行物に記載の事項
（ア）原審における平成２７年１１月１３日付けの拒絶理由（以下，これを「原審拒絶理由」という）に引用された，本願の第１国出願前に既に公知である，米国特許出願公開第２００９／０２１０７０７号明細書（２００９年８月２０日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「[0001]　
The present invention in general relates to the field of communication networks, and in particular to an out-of-band authentication method for streaming and discrete message communication across a data network. 
the invention relates to a solution ensuring the integrity of the data and the authenticity of the parties of a connection for data exchange using a public packet-type communication network, e.g. an Internet Protocol(IP) network.
（［０００１］　
本発明は，一般に，通信ネットワーク分野，特に，データネットワークを介した，ストリーミング，及び，個別メッセージ通信のための，アウト・オブ・バンド認証方法に関連している。
本発明は，公衆パケット型通信ネットワーク，例えば，インターネット・プロトコル（ＩＰ）ネットワークにおける，データの完全性と，接続の相手の信頼性の確保の解決に関連している。
　
Ｂ．「[0028]　
First channel7 is used for transmitting data, preferably packet data, either as discrete messages or as data streams (for example, multimedia and real-time data) and has unspecified (e.g.,limited) security characteristics.
（［００２８］　
第１チャンネル７は，データ，望ましくは，個別メッセージとしての，或いは，データ・ストリーム（例えば，マルチメディア，及び，リアルタイム・データ）としての，パケット・データの転送に用いられ，特定されていない（例えば，限定された）セキュリティ特性を有している。
　
Ｃ．「[0031]　
Receiver control module11 is arranged upstream of the receiver3 and includes a receiver data buffer18, a receiver control buffer19 and a receiver processor20.
[0032]　
Receiver processor20 is connected to and acquires data from both the receiver data buffer18 and the receiver control buffer19 and performs the operations necessary for the synchronization with the sender control module10, as well as the operations for checking the authenticity of the data transmitted in data channel7, as explained in detail hereinbelow, with reference to FIGS.3, 4a, 4b and 4c.
[0033]　The sender control module10 and the receiver control module11 may be implemented as physical nodes or as software applications that are performed by already existing resources of the LANs5, 6 or the network4.」
（［００３１］　
受信機制御モジュール１１は，レシーバ３の上流に配置され，受信機データ・バッファ１８，受信機制御バッファ１９，及び，受信機プロセッサ２０を備える。
［００３２］　
受信機プロセッサ２０は，受信機データ・バッファ１８と，受信機制御バッファの両方に接続され，両方からのデータを取得し，図３，４ａ，４ｂ，及び，４ｃの参照と共に，以下に詳細に説明されているように，データ・チャンネル７により転送されたデータの信頼性を確認するための処理だけでなく，送信制御モジュール１０との同期のために必要な処理も実行する。
［００３３］　送信機制御モジュール１０と，受信機制御モジュール１１は，物理ノードとして，或いは，既に，存在している，ＬＡＮ５，６，或いは，ネットワーク４の資源によって実行されるソフトウェア・アプリケーションとして，実装され得る。）
　
Ｄ．「[0040]　In addition, 
the sender control module10 divides the stream sent by the sender2 into a plurality of blocks A
ｓ
=[a
ｓ
, . . . , a
ｓ＋Ｌ
]
（［００４０］　加えて，
送信制御モジュール１０は
多数のブロック　Ａ＝［ａ
ｓ
，　．　．　．　，ａ
ｓ＋Ｌ
］に，送信機２によって，送信されるストリームを，分割し
　
Ｅ．「[0055]　FIG.4b shows the flow chart of the operations performed by the receiver processor20, as soon as the receiver control module11 begins receiving a transmission. In particular, 
the receiver module11 can be activated as soon as the first bytes of a data stream [b
１
, b
２
, . . . , b
Ｎ
] are received from the data channel7.
[0056]　When the receiver module is activated, the received data stream is accumulated in the receiver data buffer18. In practice, according to an embodiment, the data stream received from channel7 and directed to the receiver3 is duplicated and the duplicated data stream is stored in the received data buffer18.」
（［００５５］　図４ｂは，受信機制御モジュール１１が，送信信号を受信すると，直ちに，受信機プロセッサ２０によって実行される処理のフローチャートを示す。特に，
受信機モジュール１１は，データ・チャンネル７から，データ・ストリーム［ｂ
１
，ｂ
２
， ． ． ． ，ｂ
Ｎ
］の最初のバイトが，受信されると，直ちに，起動されることができる。
［００５６］　受信機モジュールが，起動されると，受信されたデータ・ストリームは，受信機データ・バッファ１８に，累積される。実際には，実施例にしたがって，チャンネル１７から受信され，受信機３に誘導される，データ・ストリームは，複製され，複製されたデータ・ストリームは，受信データ・バッファ１８に格納される。）
　
Ｆ．「[0061]　
If the result of the comparison is positive, that is if f
ｓ
=h
ｓ
, it follows that [b
ｓ
, . . . , b
ｓ＋Ｌ
]=[a
ｓ
, . . . , a
ｓ＋Ｌ
] and the received block B
ｓ
 is authenticated. Therefore, the receiver is assured that the received block has been sent by the assumed sender (authenticity of the parties) and it has not been modified during the transmission (integrity of the message).
[0062]　If the checks in step70 give positive results, the above procedure (steps64-70) continues with the following blocks Bｓ until the end of the data stream (output yes form the step72), if not (output not from the step70), an error procedure is implemented (step74).」
（［００６１］　
比較の結果が，正，即ち，ｆ
ｓ
＝ｈ
ｓ
であれば，それに続いて， [ｂ
ｓ
，　．　．　．　，ｂ
ｓ＋Ｌ
］＝［ａ
ｓ
，　．　．　．　，ａ
ｓ＋Ｌ
］であり，受信されたブロック　Ｂ
ｓ
は，認証される。それ故，送信機は，受信されたブロックが，想定された送信機によって，送信され（相手の信頼性），そして，それが，送信の途中で，改竄されていない（メッセージの完全性）ことを保証される。
［００６２］　ステップ７０におけるチェックが，正の結果を与えるものであれば，上の手続（ステップ６４〜７０）は，データ・ストリームの終わりまで，引き続くデータブロックＢｓについて，継続する（ステップ７２からの，はいの出力）。もし，いいえであれば（ステップ７０からの，いいえの出力），エラー手続が，実行される（ステップ７４）。）
　
Ｇ．「[0071]　After having received the first packet, the sender processor13 activates the authentication procedure and sends a first control message Ｃ１=I,L,H in the secure channel8. In the example, the synchronization data I is the sequence number of the RTP message (here 2), L=4, and the hash function is H=SHA-256. Furthermore, the sender module10 begins to load its buffer12 with the packets in the order they are sent and, after loading four packets (first block), calculates the hash value h1 for the first block. Then, 
the sender processor13 sends the hash value h1 onto the secure channel8.
[0072]　In the meantime, the receiver module11 has received the first control message Ｃ１ and begins receiving and loading its data buffer18 with the received packets. 
As soon as the receiver module11 has received the communicated number of packets forming a block (here, four), the receiver processor20 calculates the hash function thereof, h1'.
 the receiver processor20  compares h1 and h1 '. If they match, the integrity of packets 3-6 is positively verified.
（［００７１］　最初のパケットが受信されると，送信機プロセッサ１３は，認証手続を起動し，最初の制御メッセージＣ１＝Ｉ，Ｌ，Ｈを，セキュア・チャンネル８内に送信する。その例において，同期データＩは，ＲＴＰメッセージの，シーケンス番号であり（ここでは，２），Ｌ＝４，そして，ハッシュ関数Ｈ＝ＳＨＡ−２５６である。その上に，送信機モジュール１０は，それらが送信される命令において，パケットを，そのバッファ１２に，ロードし，そして，４つのパケット（最初のブロック）がロードされると，最初のブロックのために，ハッシュ値ｈ１を，計算する。次に，
送信機プロセッサ１３は，セキュア・チャンネル８の上へ，ハッシュ値ｈ１を送信する。
［００７２］　その一方で，受信機モジュール１１は，最初の制御メッセージＣ１を受信し，受信されるパケットを，そのデータ・バッファ１８へ，受信すること，及び，ロードすることを，開始する。
受信モジュール１１が，ブロックを構成する，送信されるパケット数（ここでは，４）を受信すると，直ちに，受信機プロセッサ２０は，それについて，ハッシュ関数，ｈ１’を計算する。
受信機プロセッサ２０は，ｈ１と，ｈ１’とを比較する。もし，それらが一致すれば，パケット３〜６の完全性が，正であることが，証明される。
　
（イ）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，「平林光浩，既存のＷｅｂサーバーで途切れない動画配信を実現，日経エレクトロニクス，２０１２年３月１９日，第１０７８号,　ｐ．７７−８５」（以下，これを「引用刊行物２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｈ．「次世代の動画配信技術「ＭＰＥＧ−ＤＡＳＨ」の国際標準化が決まった。動画圧縮技術の国際標準化団体である「Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）」が，２０１０年４月から仕様策定を本格化していた技術だ。パソコンだけではなく，スマートフォンやタブレット端末，薄型テレビなどの幅広い応用を目指している（図１）。
　
ＤＡＳＨは，「Ｄｙｎａｍｉｃ  ＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ」の略称である。その名が示すように技術の特徴は大きく二つある。
　一つは，再生端末の画面サイズや，伝送路の通信帯域（品質）に合わせて，配信する動画データを動的に変更できること。いわゆる「適応型ストリーミング技術」である
　
Ｉ．「ＭＰＤファイル
ＸＭＬ形式の階層構造で記述
ＭＰＥＧ−ＤＡＳＨでは，その特徴である適応型のストリーミング配信を実現するため，１本の動画コンテンツ用に画像サイズと符号化速度が異なる動画データ群を用意する（図２）。各動画データは，それぞれ「セグメント（Ｓｅｇｍｅｎｔ）」と呼ばれる数秒から１０秒程度の単位で分割（断片化）し，配信（Ｗｅｂ）サーバーに格納しておく。伝送路の状況に応じて，最適な符号化速度のセグメントを再生端末にＨＴＴＰで送信する。
この配信の仕組みを管理するために用いるデータが，ＭＰＤファイルである。
　このファイルの仕様では，Ｗｅｂサーバーに格納された動画コンテンツの構成に関する情報を，ＸＭＬ（ｅｘ−ｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）形式による階層構造で記述することを定めている（図３）。
　
データ要求の制御がカギ
　
再生端末側では，まず配信サーバーからＭＰＤファイルを取得し
この際に，再生端末の画面サイズや伝送路の状態などを加味して，それに合わせた最適な画像サイズや符号化速度を選ぶ。」（８０頁右欄１行〜末行）
　
Ｊ．「
複数の構造体で階層的に記述  ＭＰＤファイルに記述する情報は例えば，動画を格納したＷｅｂサーバーのＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）や，格納してある動画データ群の圧縮方式，画像サイズや符号化速度，音声データの圧縮方式，音声の言語情報などである
　
（ウ）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，「Ａｎｔｈｏｎｙ　Ｖｅｔｒｏ，“Ｔｈｅ　ＭＰＥＧ−ＤＡＳＨ　Ｓｔａｎｄａｒｄ　ｆｏｒ　Ｍｕｌｔｉｍｅｄｉａ　Ｓｔｒｅａｍｉｎｇ　Ｏｖｅｒ　Ｉｎｔｅｒｎｅｔ”２０１１年, ＩＥＥ　ＭｕｌｔｉＭｅｄｉａ, Ｖｏｌｕｍｅ １８ Ｉｓｓｕｅ ４，ｐ．６２−６７」（以下，これを「引用刊行物３」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｋ．「
A simple case of adaptive streaming
　Figure 1 illustrates a simple example of ondemand, dynamic, adaptive streaming. In this figure, the multimedia content consists of video and audio components. The video source is encoded at three different alternative bitrates: 5 Mbytes, 2 Mbytes, and 500 kilobits per second (Kbps). Additionally, an I-frame-only bitstream with a low frame rate is provided for streaming during the trick-mode play. The accompanying audio content is available in two languages: audio 1 is a dubbed English version of the audio track and is encoded in surround sound, Advanced Audio Coding (AAC) with 128-Kbyte and 48-Kbps alternatives; while audio 2 is the original French version, encoded in AAC 128-Kbyte and 48-Kbps alternatives only.
　Assume that a device starts streaming the content by requesting segments of the video bitstream at the highest available quality (5 Mbytes) and the English audio at 128 Kbytes AAC because, for instance, the device doesn’t support surround audio (label 1 in Figure 1). After streaming the first segments of video and audio, and monitoring the effective network bandwidth, the device realizes that the actual available bandwidth is lower than 5 Mbps. So, at the next available switching point, it switches the video down to 2 Mbps by streaming the next segments from the mid-quality track while continuing streaming of the 128-Kbyte AAC English audio (label 2 in Figure 1). The device continues to monitor the actual network bandwidth and realizes that the network bandwidth has further decreased to a value lower than 2 Mbps. Therefore, to maintain continuous playback, the device further switches the streams down to 500-Kbps video and 48-Kbps audio (label 3 in Figure 1). It continues playing the content at these rates until the network bandwidth increases and then it switches the video up to 2 Mbytes (label 4 in Figure 1). After a while, the user decides to pause and rewind. At this point, the device starts streaming the video from the trick-mode track to play the video in reverse order, while audio is muted (label 5 in Figure 1). At the desired point, the user clicks to play the content with the original French audio. At this point, the device resumes streaming the video from the highest quality (5Mbytes) and audio from 128-Kbyte French audio (label 6 in Figure 1).
　This example perhaps is one of the most simple use cases of dynamic streaming of multimedia content. More advanced use cases might include switching between multiple camera views, 3D multimedia content streaming, video streams with subtitles and captions, dynamic ad insertion, low-latency live streaming, mixed-streaming and prestored content playback, and others.」（６３頁右欄５行〜６４頁左欄３５行）
（
アダプティブ・ストリーミングの簡単なケース
　図１は，オンデマンド，動的，アダプティブ・ストリーミングの関連な例を，説明している。この図で，マルチメディア・コンテンツは，映像と，音声のコンポーネントから成る。映像ソースは，３つの，代替可能な，ビットレート：５Ｍｂｐｓ，２Ｍｂｐｓ，及び，５Ｋｂｐｓに，エンコードされている。加えて，低いフレーム・レートである，Ｉフレームのみのビット・ストリームは，トリック・モード再生の間中ストリーミングのために，備えられている。付随の音声コンテンツは，２つの言語がある：音声１は，音声トラックの吹き替えの英語版で，サラウンド音響で，１２８Ｋバイトと，４８ＫバイトのＡＡＣに，置換可能に，エンコードされている；一方，音声２は，オリジナルのフランス語版で，１２８Ｋバイトと，４８ＫバイトのＡＡＣに，置換可能に，エンコードされているだけである。
　デバイスが，可能なクオリティで最高（５Ｍバイト）の映像ビットストリームと，例えば，デバイスが，サラウンド音響（図１におけるラベル１）に対応していないために，１２８ＫバイトのＡＡＣの英語音声の，要求されたセグメントによって，コンテンツのストリーミングを開始したと仮定する。映像と，音声の最初のセグメントをストリーミングし，実効の，ネットワーク帯域幅のモニタリング後に，デバイスは，実際に可能な帯域幅は，５Ｍｂｐｓより低いことを知る。そこで，次に可能な，切替ポイントで，デバイスは，１２８ＫバイトＡＡＣの英語音声のストリーミングを維持したまま，ビデオを，中位品質のコンテンツからの，次のセグメントのストリーミングを用いて，２Ｍｂｐｓまで下げて，切り替える（図１のラベル２）。デバイスは，実際の，ネットワーク帯域をモニタすることは継続し，ネットワーク帯域が，２Ｍｂｐｓより,さらに減少したことを知る。それ故，連続した再生を維持するために，デバイスは，ストリームを，５００Ｋｂｐの映像と，４８Ｋｂｐｓの音声にまで下げて，切り替える（図１のラベル３）。デバイスは，ネットワーク帯域が増加するまで，このレートで，再生を継続し，次に，映像を，２Ｍｂｐｓまで上げて，切り替える（図１のラベル４）。しばらくして，ユーザが，中止し，巻き戻すことを決定する。このポイントで，デバイスは，音声は，ミュートしたまま，反転要求における映像再生のための，トリック・モード・トラックからの，映像のストリーミングを開始する（図１のラベル５）。要求されたポイントで，ユーザが，オリジナルのフランス語音声で，コンテンツを再生することを，クリックする。このポイントで，デバイスは，最高品質（５Ｍｂｐｓ）からの映像と，１２８Ｋｂｐｓのフランス語音声からの音声の，ストリーミングを，再開する（図１のラベル６）。
　この例は，多分，マルチメディア・コンテンツの，動的ストリーミングの，最も簡単な使用例の１つである。より高度な，使用例は，多数のカメラの視野の切替，３Ｄマルチメディア・コンテンツのストリーミング，サブタイトルと字幕付の映像ストリーム，動的公告挿入，低レイテンシ・ライブ・ストリーミング，ミックスド・ストリーミング，及び，予め格納されたコンテンツの再生，その他を，含み得る。）
　
Ｌ．「To use this data model, the DASH client first parses the MPD XML document. The client then selects the set of representations it will use based on descriptive elements in the MPD, the client's capabilities, and user's choices. The client then builds a timeline and starts playing the multimedia content by requesting appropriate media segments. Each representation's description includes information about its segments, which enables requests for each segment to be formulated in terms of the HTTP URL and byte range.
 For live presentations, the MPD also provides segment availability start time and end time, approximate media start time, and the fixed or variable duration of segments
（このデータ・モデルを使用するために，ＤＡＳＨクライアントは，最初に，ＭＰＤのＸＭＬドキュメントを構文解析する。クライアントは，次に，ＭＰＤにおける記述要素，クライアントの能力，及び，ユーザの選択に基づいて使用する，表現のセットを，選択する。クライアントは，次に，タイムラインを構築し，要求されている適切なメディア・セグメントによって，メディア・コンテンツの再生を開始する。それぞれの表現の記述は，そのセグメントについての情報を含み，それは，個々のセグメントについての要求が，ＨＴＴＰ　ＵＲＬと，バイト範囲の用語に関して，定式化されることを可能にする。
ライブ・プレゼンテーションのために，ＭＰＤはまた，セグメント入手可能性開始時間と，終了時間，およそのメディアの開始時間，及び，セグメントの，固定された，或いは，可変の持続時間を提供する
　
（エ）本願の第１国出願前に既に公知である，特開２００９−１０５６３３号公報（２００９年５月１４日公開，以下，これを「周知文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｍ．「当該認証センタ装置により作成された認証子を受信する」（段落【０００９】）
　
（オ）本願の第１国出願前に既に公知である，特開平９−３１１８５４号公報（１９９７年１２月２日公開，以下，これを「周知文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｎ．「【００２６】まず図４のフローチャートに示す文書送信側装置１の動作を説明する。文書送信側装置１では文書編集部５が，文書を生成する（ステップＳ３１）。次に生成された文書からデジタル署名生成部６が一方向関数を用いて，文書のＭＤを生成する（ステップＳ３２）。生成されたＭＤからデジタル署名を生成する（ステップＳ３３）。文書のデジタル署名は，デジタル署名送信部７により格納時にインデクス情報として利用される情報とともに文書検証情報管理装置３に送信される（ステップＳ３４）。文書は文書送信部７によって文書受信側装置２へ送信される（ステップＳ３５）。
【００２７】次に図４のフローチャートに示す文書受信側装置２の動作を説明する。文書受信側装置２は文書受信部１１で文書送信側装置２の送信した文書を受信する（ステップＳ４１）。次にデジタル署名検証部９において受信した文書からＭＤを取得する（ステップＳ４２）。次に文書検証情報管理装置３に対してデジタル署名検索要求を送出する（ステップＳ４３）。次に文書検証情報管理装置３からデジタル署名取得部１０がデジタル署名を取得する（ステップＳ４４）。取得したデジタル署名はデジタル署名検証部９において，公開鍵暗号方式における送信者のパブリック鍵で復号化される（ステップＳ４５）。ステップＳ４５においてデジタル署名を復号化して得られたＭＤとステップＳ４２で再生成されたＭＤの値が比較される（ステップＳ４６）。比較の結果，両者が一致すれば送信者が文書を作成したこと，および作成後文書に対する改竄がおこなわれていないことが判明し（ステップＳ４７），一致しない場合は文書に対する改竄がおこなわれたことが判明する（ステップＳ４８）。」
　
ウ．引用刊行物に記載の発明
（ア）上記Ａの「The present invention in general relates to the field of communication networks, and in particular to an out-of-band authentication method for streaming and discrete message communication across a data network.（本発明は，一般に，通信ネットワーク分野，特に，データネットワークを介した，ストリーミング，及び，個別メッセージ通信のための，アウト・オブ・バンド認証方法に関連している。）」という記載，及び，同じく，上記Ａの「the invention relates to a solution ensuring the integrity of the data and the authenticity of the parties of a connection for data exchange using a public packet-type communication network, e.g. an Internet Protocol(IP) network.（本発明は，公衆パケット型通信ネットワーク，例えば，インターネット・プロトコル（ＩＰ）ネットワークにおける，データの完全性と，接続の相手の信頼性の確保の解決に関連している。）」という記載から，引用刊行物１には，
“ＩＰネットワークにおける，ストリーミング・データの完全性と，接続の相手の信頼性の確保の解決に関連する認証方法”
　が記載されていることが読み取れる。
　
（イ）上記Ｂの「First channel7 is used for transmitting data, preferably packet data, either as discrete messages or as data streams (for example, multimedia and real-time data) and has unspecified (e.g.,limited) security characteristics.（第１チャンネル７は，データ，望ましくは，個別メッセージとしての，或いは，データ・ストリーム（例えば，マルチメディア，及び，リアルタイム・データ）としての，パケット・データの転送に用いられ，特定されていない（例えば，限定された）セキュリティ特性を有している。）」という記載，上記Ｄの「the sender control module10 divides the stream sent by the sender2 into a plurality of blocks Aｓ=[aｓ, . . . , aｓ＋Ｌ]（送信制御モジュール１０は・・・多数のブロック　Ａ＝［ａｓ，　．　．　．　，ａｓ＋Ｌ］に，送信機２によって，送信されるストリームを，分割し）」という記載，及び，上記Ｅの「the receiver module11 can be activated as soon as the first bytes of a data stream [b１, b２, . . . , bＮ] are received from the data channel7.（受信機モジュール１１は，データ・チャンネル７から，データ・ストリーム［ｂ１，ｂ２， ． ． ． ，ｂＮ］の最初のバイトが，受信されると，直ちに，起動されることができる。）」という記載から，引用刊行物１においては，
“受信機制御モジュールが，多数のブロックに分割された，マルチメディアのデータ・ストリームのパケット・データを受信”する
　ことが読み取れる。
　
（ウ）上記Ｃの「Receiver control module11 is arranged upstream of the receiver3 and includes a receiver data buffer18, a receiver control buffer19 and a receiver processor20.（受信機制御モジュール１１は，レシーバ３の上流に配置され，受信機データ・バッファ１８，受信機制御バッファ１９，及び，受信機プロセッサ２０を備える。）」という記載，同じく，上記Ｃの「Receiver processor20 is connected to and acquires data from both the receiver data buffer18 and the receiver control buffer19 and performs the operations necessary for the synchronization with the sender control module10, as well as the operations for checking the authenticity of the data transmitted in data channel7, as explained in detail hereinbelow, with reference to FIGS.3, 4a, 4b and 4c.（受信機プロセッサ２０は，受信機データ・バッファ１８と，受信機制御バッファの両方に接続され，両方からのデータを取得し，図３，４ａ，４ｂ，及び，４ｃの参照と共に，以下に詳細に説明されているように，データ・チャンネル７により転送されたデータの信頼性を確認するための処理だけでなく，送信制御モジュール１０との同期のために必要な処理も実行する。）」という記載，及び，上記Ｇの「As soon as the receiver module11 has received the communicated number of packets forming a block (here, four), the receiver processor20 calculates the hash function thereof, h1'. （受信モジュール１１が，ブロックを構成する，送信されるパケット数（ここでは，４）を受信すると，直ちに，受信機プロセッサ２０は，それについて，ハッシュ関数，ｈ１’を計算する。）」という記載から，引用刊行物１においては，
“受信機制御モジュールは，データ・チャネルにより転送されたデータの信頼性を確認するための処理として，受信したパケットのハッシュ値ｈ１’を計算”する
　ことが読み取れる。
　
（エ）上記Ｆの「If the result of the comparison is positive, that is if fｓ=hｓ, it follows that [bｓ, . . . , bｓ＋Ｌ]=[aｓ, . . . , aｓ＋Ｌ] and the received block Bｓ is authenticated. Therefore, the receiver is assured that the received block has been sent by the assumed sender (authenticity of the parties) and it has not been modified during the transmission (integrity of the message).（比較の結果が，正，即ち，ｆｓ＝ｈｓであれば，それに続いて， [ｂｓ，　．　．　．　，ｂｓ＋Ｌ］＝［ａｓ，　．　．　．　，ａｓ＋Ｌ］であり，受信されたブロック　Ｂｓは，認証される。それ故，送信機は，受信されたブロックが，想定された送信機によって，送信され（相手の信頼性），そして，それが，送信の途中で，改竄されていない（メッセージの完全性）ことを保証される。）」という記載，上記Ｇの「the sender processor13 sends the hash value h1 onto the secure channel8.（送信機プロセッサ１３は，セキュア・チャンネル８の上へ，ハッシュ値ｈ１を送信する。）」という記載，及び，同じく，上記Ｇの「the receiver processor20  compares h1 and h1 '. If they match, the integrity of packets 3-6 is positively verified.（受信機プロセッサ２０は，ｈ１と，ｈ１’とを比較する。もし，それらが一致すれば，パケット３〜６の完全性が，正であることが，証明される。）」という記載と，上記（ウ）において検討した事項から，引用刊行物１においては，
“受信機制御モジュールは，送信されたハッシュ値ｈ１と，計算した，受信したパケットのハッシュ値ｈ１’とを比較し，パケットの完全性を検証する”
ものであることが読み取れる。
　
（オ）以上，（ア）〜（エ）において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「ＩＰネットワークにおける，ストリーミング・データの完全性と，接続の相手の信頼性の確保の解決に関連する認証方法であって，
　受信機制御モジュールが，多数のブロックに分割された，マルチメディアのデータ・ストリームのパケット・データを受信し，
　受信機制御モジュールは，データ・チャネルにより転送されたデータの信頼性を確認するための処理として，受信したパケットのハッシュ値ｈ１’を計算し，
　受信機制御モジュールは，送信されたハッシュ値ｈ１と，計算した，受信したパケットのハッシュ値ｈ１’とを比較し，パケットの完全性を検証する，方法。」
　
エ．本件補正発明と引用発明との対比
（ア）引用発明における「ストリーミング・データ」とは，「データ・ストリーム」を「パケット」に分割したものを含み，引用発明における「パケット」が，本件補正発明における「セグメント」に相当し，
　引用発明は，これらの「パケット」に対して，「完全性」と，「信頼性」の検証を行うものであるから，
　引用発明における「ＩＰネットワークにおける，ストリーミング・データの完全性と，接続の相手の信頼性の確保の解決に関連する認証方法」と，
　本件補正発明における「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法」とは，
“ストリーミングのためのセグメントの保全性および信頼性を検証する方法”
　である点で共通する。
　
（イ）引用発明における「受信機制御モジュール」，「多数のブロックに分割された，マルチメディアのデータ・ストリームのパケット・データ」が，
　本件補正発明における「データ処理システム」，「メディアストリームのセグメント」に相当するので，
　引用発明における「受信機制御モジュールが，多数のブロックに分割された，マルチメディアのデータ・ストリームのパケット・データを受信」することは，
　本件補正発明における「データ処理システムにおいてメディアストリームのセグメントを受信するステップ」に相当する。
　
（ウ）引用発明における「受信したパケットのハッシュ値ｈ１’」が，
　本件補正発明における「セグメントに関するダイジェスト」に相当するので，
　引用発明における「受信機制御モジュールは，データ・チャネルにより転送されたデータの信頼性を確認するための処理として，受信したパケットのハッシュ値ｈ１’を計算」することが，
　本件補正発明における「前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップ」に相当する。
　
（エ）引用発明において，「受信機制御モジュールは，送信されたハッシュ値ｈ１と，計算した，受信したパケットのハッシュ値ｈ１’とを比較し，パケットの完全性を検証する」ことは，正しい「ハッシュ値ｈ１」と，「受信機制御モジュール」において，「計算し」て求めた，「受信したパケットのハッシュ値ｈ１’」と比較することで，「受信したパケット」が，改変されているか否かを検証することに他ならないので，
　引用発明における「受信機制御モジュールは，送信されたハッシュ値ｈ１と，計算した，受信したパケットのハッシュ値ｈ１’とを比較し，パケットの完全性を検証する」が，
　本件補正発明における「データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップ」に相当する。
　
（オ）以上，（ア）〜（エ）において検討した事項から，本件補正発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　ストリーミングのためのセグメントの保全性および信頼性を検証する方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップと，を含む方法。
　
［相違点１］
“ストリーミング”に関して，
　本件補正発明においては，「アダプティブストリーミング」であるのに対して，
　引用発明においては，「アダプティブストリーミング」については，特に言及されていない点。
　
［相違点２］
　本件補正発明においては，「正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され」るものであるのに対して，
　引用発明においては，「送信されたハッシュ値ｈ１」であって，「MPDにおいて示されるURLを通じて取得され」るものではない点。
　
［相違点３］
　本件補正発明においては，「MPDは，前記データ処理システムで受信される」ものであるのに対して，
　引用発明においては，「MPD」に対する言及がない点。
　
オ．相違点についての当審の判断
（ア）［相違点１］について
　「アダプティブストリーミング」については，上記Ｈに引用した，引用刊行物２の「ＤＡＳＨは，「Ｄｙｎａｍｉｃ  ＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ」の略称である。その名が示すように技術の特徴は大きく二つある。
　一つは，再生端末の画面サイズや，伝送路の通信帯域（品質）に合わせて，配信する動画データを動的に変更できること。いわゆる「適応型ストリーミング技術」である」という記載内容，或いは，上記Ｋに引用した，引用刊行物３の「A simple case of adaptive streaming（アダプティブ・ストリーミングの簡単なケース）」に始まる記載内容にもあるとおり，本願の第１国出願前に，当業者には周知の技術事項であるから，
　引用発明において，「ストリーミング」を，「アダプティブストリーミング」とすることは，当業者が適宜なし得る事項である。
　よって，［相違点１］は，格別のものではない。
　
（イ）［相違点２］について
　上記Ｊに引用した，引用刊行物２の「複数の構造体で階層的に記述  ＭＰＤファイルに記述する情報は例えば，動画を格納したＷｅｂサーバーのＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）や，格納してある動画データ群の圧縮方式，画像サイズや符号化速度，音声データの圧縮方式，音声の言語情報などである」という記載内容，或いは，上記Ｌに引用した，引用刊行物３の「For live presentations, the MPD also provides segment availability start time and end time, approximate media start time, and the fixed or variable duration of segments（ライブ・プレゼンテーションのために，ＭＰＤはまた，セグメント入手可能性開始時間と，終了時間，およそのメディアの開始時間，及び，セグメントの，固定された，或いは，可変の持続時間を提供する）」という記載から，「ＭＰＤ」には，種々の情報が記述できること，そして，その情報として，“情報の取得場所であるＵＲＬが記述できること”は，本願の第１国出願前に，当業者には周知の技術事項であったといえる。
　また，セキュリティの分野では，送信された情報の認証に用いる情報を，送信先以外から取得するような構成は，本願の第１国出願に，当業者には周知の技術事項であるから（必要であれば，上記Ｍに記載内容を引用した，周知文献１，或いは，上記Ｎに記載内容を引用した周知文献２等を参照されたい），引用発明においても，必要に応じて，比較のための「ハッシュ値ｈ１」の取得先を，「ＭＰＤ」に記述するよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点２］は，格別のものではない。
　
（ウ）［相違点３］について
　上記Ｉに引用した，引用刊行物２の「再生端末側では，まず配信サーバーからＭＰＤファイルを取得し」と記載されているとおり，“MPDが，データ処理システム側で受信される”ようにすることは，本願の第１国出願前に，当業者には，周知の技術事項である。
　したがって，引用発明においても，「ＭＰＤ」を用いる構成を導入した際に，「受信機制御モジュール」側で，「ＭＰＤ」を受信するよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点３］は，格別のものではない。
　
（エ）上記で検討したごとく，［相違点１］〜［相違点３］はいずれも格別のものではなく，そして，本件補正発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　よって，本件補正発明は，引用発明，引用刊行物２，及び，引用刊行物３に記載の発明と，当該技術分野における技術常識とに基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許出願の際，特許を受けることができない。
　
３．補正却下むすび
　したがって，本件手続補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成２８年６月２１日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２８年２月１日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１として引用した，次のとおりのものである。
　
「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップとを含み，
　前記正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得される，方法。」
　
第４．引用刊行物に記載の発明
　上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」の「イ．引用刊行物に記載の事項」において，引用刊行物１として引用した，米国特許出願公開第２００９／０２１０７０７号明細書（２００９年８月２０日公開）には，上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」の「ウ．引用刊行物に記載の発明」において認定したとおりの，次の引用発明が記載されている。
　
「ＩＰネットワークにおける，ストリーミング・データの完全性と，接続の相手の信頼性をの確保の解決に関連する認証方法であって，
　受信機制御モジュールが，多数のブロックに分割された，マルチメディアのデータ・ストリームのパケット・データを受信し，
　受信機制御モジュールは，データ・チャネルにより転送されたデータの信頼性を確認するための処理として，受信したパケットのハッシュ値ｈ１’を計算し，
　受信機制御モジュールは，送信されたハッシュ値ｈ１と，計算した，受信したパケットのハッシュ値ｈ１’とを比較し，パケットの完全性を検証する，方法。」
　
第５．本願発明と引用発明との対比
　本願発明は，上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」において検討した，本件補正発明から，
「MPDは，前記データ処理システムで受信される」
　という構成を削除したものであるから，
　本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　ストリーミングのためのセグメントの保全性および信頼性を検証する方法であって，
　データ処理システムにおいてメディアストリームのセグメントを受信するステップと，
　前記データ処理システムを用いて，前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと，
　前記データ処理システムを用いて，前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して，前記セグメントが改変されているかどうかを判定するステップと，を含む方法。
　
［相違点ａ］
“ストリーミング”に関して，
　本願発明においては，「アダプティブストリーミング」であるのに対して，
　引用発明においては，「アダプティブストリーミング」については，特に言及されていない点。
　
［相違点ｂ］
　本願発明においては，「正しいダイジェストまたは前記正しいデジタル署名は，MPD（メディアプレゼンテーション記述）において示されるURLを通して取得され」るものであるのに対して，
　引用発明においては，「送信されたハッシュ値ｈ１」であって，「MPDにおいて示されるURLを通じて取得され」るものではない点。
　
第６．相違点についての当審の判断
　本願発明と，引用発明との［相違点ａ］は，本件補正発明と，引用発明との［相違点１］と同じものであり，本願発明と，引用発明との［相違点ｂ］は，本件補正発明と，引用発明との［相違点２］と同じものであるから，上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」の「２．補正の適否」における「（２）独立特許要件」の「オ．相違点についての当審の判断」において検討したとおり，格別のものではない。
　そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　なお，審判請求人は，平成２８年１０月２６日付けの意見書において，
「引用文献２に示されるように，従来のMPDは，メディアストリームを構成するファイル断片（則ち，セグメント）を示すために使用されます。一方，正しいダイジェストまたは正しいデジタル署名は，メディアストリームの構成に関する情報ではありません。
　このように，正しいダイジェストまたは正しいデジタル署名の意味は，ファイル断片（則ち，セグメント）の意味と異なります。
　故に，本願発明の上記特徴（前記正しいダイジェストまたは前記正しいデジタル署名は，MPDにおいて示されるURLを通して取得される）は，当業者が進歩性無しに容易に想到できる特徴でありません。」
　旨主張しているが，「ＭＰＤ」に関しては，上記「第２．平成２８年６月２１日付けの手続補正の却下の決定」の「２．補正の適否」における「（２）独立特許要件」の「オ．相違点についての当審の判断」においての「（イ）［相違点２］について」で検討したとおりであるから，審判請求人の主張は採用できない。
　
第７．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。