• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1335499
審判番号 不服2016-9157  
総通号数 218 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-02-23 
種別 拒絶査定不服の審決 
審判請求日 2016-06-21 
確定日 2017-12-06 
事件の表示 特願2015-509153「アダプティブストリーミングのための,セグメントの保全性および信頼性のためのシステムおよび方法」拒絶査定不服審判事件〔平成25年10月31日国際公開,WO2013/163477,平成27年 7月 9日国内公表,特表2015-519814〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2013年4月25日(パリ条約による優先権主張外国庁受理2012年4月25日,2013年4月25日 アメリカ合衆国)を国際出願日とする出願であって,
平成26年11月28日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成27年11月13日付けで審査官により拒絶理由が通知され,これに対して平成28年2月1日付けで意見書が提出されると共に手続補正がなされたが,平成28年2月19日付けで審査官により拒絶査定がなされ(謄本送達:平成28年3月1日),これに対して平成28年6月21日付けで審判請求がなされると共に手続補正がなされ,平成28年7月15日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成28年10月26日付けで上申書の提出があったものである。

第2.平成28年6月21日付けの手続補正の却下の決定

[補正却下の決定の結論]

平成28年6月21日付け手続補正を却下する。

[理由]

1.補正の内容
平成28年6月21日付けの手続補正(以下,「本件手続補正」という)により,平成28年2月1日付けの手続補正により補正された特許請求の範囲,
「 【請求項1】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップとを含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得される,方法。
【請求項2】
前記正しいダイジェストまたはデジタル署名がサーバから受信される,請求項1に記載の方法。
【請求項3】
サーバが,前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する,請求項2に記載の方法。
【請求項4】
前記ダイジェストが暗号ハッシュである,請求項1に記載の方法。
【請求項5】
前記デジタル署名がメッセージ認証コードである,請求項1に記載の方法。
【請求項6】
セグメントの改変が,前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む,請求項1に記載の方法。
【請求項7】
前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するステップをさらに含む,請求項1に記載の方法。
【請求項8】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントであって,
プロセッサと,
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを備え,前記プログラミングが,
メディアストリームのセグメントを受信するための命令と,
前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と,
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するための命令と,を含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得される,ネットワークコンポーネント。
【請求項9】
前記正しいダイジェストまたは前記正しいデジタル署名がサーバから受信される,請求項8に記載のネットワークコンポーネント。
【請求項10】
前記サーバが,前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する,請求項9に記載のネットワークコンポーネント。
【請求項11】
前記ダイジェストがメッセージ認証コードを含む,請求項8に記載のネットワークコンポーネント。
【請求項12】
前記ダイジェストが暗号ハッシュを含む,請求項8に記載のネットワークコンポーネント。
【請求項13】
セグメントの改変が前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む,請求項8に記載のネットワークコンポーネント。
【請求項14】
前記プログラミングが,前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するための命令を更に含む,請求項8に記載のネットワークコンポーネント。
【請求項15】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって,前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む,受信するステップと,
前記UEを用いて,前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記UEを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと,
前記UEを用いて,前記セグメントが改変されているかどうかを判定するステップと,を含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得される,方法。
【請求項16】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される,請求項15に記載の方法。
【請求項17】
前記ダイジェストがメッセージ認証コードを含む,請求項15に記載の方法。
【請求項18】
前記ダイジェストが暗号ハッシュを含む,請求項15に記載の方法。
【請求項19】
前記暗号ハッシュがセキュアハッシュアルゴリズム(SHA)でありかつ前記SHAがSHA-256またはSHA-512を含む,請求項18に記載の方法。
【請求項20】
前記セグメントが改変されたかどうかを判定するステップが前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を判定するステップを含む,請求項15に記載の方法。
【請求項21】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたユーザ機器であって,
プロセッサと,
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体と,を備え,前記プログラミングが,
メディアストリームのセグメントを受信するステップであって,前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む,受信するための命令と,
前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と,
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するための命令と,
前記セグメントが改変されているかどうかを判定するための命令と,を備え,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得される,ユーザ機器。
【請求項22】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される,請求項21に記載のユーザ機器。
【請求項23】
前記ダイジェストがメッセージ認証コードを含む,請求項21に記載のユーザ機器。
【請求項24】
前記ダイジェストが暗号ハッシュを含む,請求項21に記載のユーザ機器。
【請求項25】
前記セグメントが改変されたかどうかを判定するステップが,前記メディアストリーム中の他のセグメントに対して前記セグメントの時間順序の変更を判定するステップを含む,請求項21に記載のユーザ機器。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「 【請求項1】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップとを含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され,前記MPDは,前記データ処理システムで受信される,方法。
【請求項2】
前記正しいダイジェストまたはデジタル署名がサーバから受信される,請求項1に記載の方法。
【請求項3】
サーバが,前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する,請求項2に記載の方法。
【請求項4】
前記ダイジェストが暗号ハッシュである,請求項1に記載の方法。
【請求項5】
前記デジタル署名がメッセージ認証コードである,請求項1に記載の方法。
【請求項6】
セグメントの改変が,前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む,請求項1に記載の方法。
【請求項7】
前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するステップをさらに含む,請求項1に記載の方法。
【請求項8】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントであって,
プロセッサと,
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを備え,前記プログラミングが,
メディアストリームのセグメントを受信するための命令と,
前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と,
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するための命令と,を含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され,前記MPDは,前記ネットワークコンポーネントで受信される,ネットワークコンポーネント。
【請求項9】
前記正しいダイジェストまたは前記正しいデジタル署名がサーバから受信される,請求項8に記載のネットワークコンポーネント。
【請求項10】
前記サーバが,前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する,請求項9に記載のネットワークコンポーネント。
【請求項11】
前記ダイジェストがメッセージ認証コードを含む,請求項8に記載のネットワークコンポーネント。
【請求項12】
前記ダイジェストが暗号ハッシュを含む,請求項8に記載のネットワークコンポーネント。
【請求項13】
セグメントの改変が前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む,請求項8に記載のネットワークコンポーネント。
【請求項14】
前記プログラミングが,前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するための命令を更に含む,請求項8に記載のネットワークコンポーネント。
【請求項15】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって,前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む,受信するステップと,
前記UEを用いて,前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記UEを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと,
前記UEを用いて,前記セグメントが改変されているかどうかを判定するステップと,を含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され,前記MPDは,前記ユーザ機器で受信される,方法。
【請求項16】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される,請求項15に記載の方法。
【請求項17】
前記ダイジェストがメッセージ認証コードを含む,請求項15に記載の方法。
【請求項18】
前記ダイジェストが暗号ハッシュを含む,請求項15に記載の方法。
【請求項19】
前記暗号ハッシュがセキュアハッシュアルゴリズム(SHA)でありかつ前記SHAがSHA-256またはSHA-512を含む,請求項18に記載の方法。
【請求項20】
前記セグメントが改変されたかどうかを判定するステップが前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を判定するステップを含む,請求項15に記載の方法。
【請求項21】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたユーザ機器であって,
プロセッサと,
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体と,を備え,前記プログラミングが,
メディアストリームのセグメントを受信するステップであって,前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む,受信するための命令と,
前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と,
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するための命令と,
前記セグメントが改変されているかどうかを判定するための命令と,を備え,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され,前記MPDは,前記ユーザ機器で受信される,ユーザ機器。
【請求項22】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される,請求項21に記載のユーザ機器。
【請求項23】
前記ダイジェストがメッセージ認証コードを含む,請求項21に記載のユーザ機器。
【請求項24】
前記ダイジェストが暗号ハッシュを含む,請求項21に記載のユーザ機器。
【請求項25】
前記セグメントが改変されたかどうかを判定するステップが,前記メディアストリーム中の他のセグメントに対して前記セグメントの時間順序の変更を判定するステップを含む,請求項21に記載のユーザ機器。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

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

ア.補正事項
本件手続補正は,補正前の請求項1に係る発明における発明特定事項である「MPD」について,「MPDは,前記データ処理システムで受信される」という記載を加えるものであり(以下,これを「補正事項1」という),
補正前の請求項8における発明特定事項である「MPD」について,「MPDは,前記ネットワークコンポーネントで受信される」という記載を加えるものであり(以下,これを「補正事項2」という),
補正前の請求項15,及び,補正前の請求項21における発明特定事項である「MPD」について,「MPDは,前記ユーザ機器で受信される」という記載を加えるものである(以下,これを「補正事項3」という)。
そして,当初明細書等には,補正事項1?補正事項3に相当する記載は存在しない。
そこで,当初明細書等に記載された内容から,補正事項1?補正事項3が読み取れるかについて,以下に検討する。

イ.補正事項1,及び,補正事項2について
当初明細書等には,補正後の請求項1に記載の「データ処理システム」,及び,補正後の請求項8に記載の「ネットワークコンポーネント」について,当初明細書等の請求の範囲の記載の他,「データ処理システム」に関しては,当初明細書等の段落【0016】に,「ネットワークコンポーネント」に関しては,当初明細書等の段落【0017】に記載されているのみである。
そして,上記に指摘のとおり,当初明細書等には,補正事項1,及び,補正事項2と同一の記載は存在せず,また,「データ処理システム」,及び,「ネットワークコンポーネント」に関連して,「MPD」が,受信されることを推察させるような記載も存在しない。
そして,「データ処理システム」,及び,「ネットワークコンポーネント」という表現では,当初明細書等において,「メディアストリーム」を受信する「クライアント」に解釈されるものではなく,当初明細書等の【図1】に開示されている,番号「102」を与えられた構成要素を「クライアント」,番号「104」を与えられた構成要素,或いは,番号「106」を与えられた構成要素を,「サーバ」と解すると,番号「108」を与えられた構成要素は,“中継のための構成要素”と見なすことができ,「データ処理システム」,及び,「ネットワークコンポーネント」という表現では,このような“中継のための構成要素”を含むことは,明らかであるから,仮に,当初明細書等の記載から,“クライアントが,MPDを受信する”という構成が読み取れたとしても,“中継のための構成要素を含み得る,「データ処理システム」,或いは,「ネットワークコンポーネント」が,MPDを受信する”という構成までは,読み取ることができない。

ウ.補正事項3について
当初明細書等には,「ユーザ機器」に関して,当初明細書等の請求の範囲の記載の他,段落【0018】に,
「ユーザ機器においてメディアストリームのセグメントを受信する」,
という,当初明細書等の請求の範囲と同等の記載が存在するほか,段落【0024】に,
「クライアントは,たとえば,パーソナルコンピュータ,ラップトップコンピュータ,タブレットコンピュータ,スマートフォン,携帯情報端末などを含む,任意のタイプのユーザ機器(UE)であってよい。」
と記載されていて,当初明細書等の発明の詳細な説明において,「ユーザ機器」が,「クライアント」であることは,読み取れる。
しかしながら,当初明細書等には,「ユーザ装置」,或いは,「クライアント」が,「MPD」を受信することについては,明文の記載は存在しない。
そこで,「MPD」について,当初明細書等の記載内容を検討すると,当初明細書等には,段落【0085】に,
「実施形態は組み合わされたダイジェストに関するURLを割り当てる。組み合わされたダイジェストに関するURLはそのダイジェストをどこで取り出すべきかを信号送信するためにMPDによって運ばれる。クライアントは組み合わされたダイジェストを取り出す。クライアントは特定のセグメントに関するダイジェストを抽出する。クライアントは抽出されたダイジェストをセグメントに関する局所的に生成されたダイジェストと比較し,結論を下す。」(下線は,当審にて,説明の都合上附加した。以下,同じ。)
と記載されていて,上記引用記載中の「組み合わされたダイジェストに関するURLはそのダイジェストをどこで取り出すべきかを信号送信するためにMPDによって運ばれる」ことと,「クライアントは組み合わされたダイジェストを取り出す」ことから,「クライアント」が,「URL」を運ぶ「MPD」を受け取る,即ち,受信するであろうことが,上記引用の記載から,一応,推察されるので,「ユーザ機器」に関する補正事項3が,当初明細書の記載に基づかないものであるとまでは,言えない。

エ.まとめ
以上,イ.,及び,ウ.において検討したとおりであるから,補正事項3については,当初明細書等に記載されていないとまでは,言えないものの,補正事項1,及び,補正事項2については,当初明細書等の記載の範囲内でなされたものではない。

(2)新規事項むすび
したがって,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

(2)独立特許要件
上記「(1)新規事項」において検討したとおり,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第3項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものであるが,
仮に,本件手続補正が,当初明細書等の記載の範囲内でなされたものであるとすると,補正事項1?補正事項3は,補正前の請求項1,補正前の請求項8,補正前の請求項15,及び,補正前の請求項21に係る発明における,発明特定事項である「MPD」を限定するものであると解せるので,
本件手続補正が,特許法第17条の2第6項において準用する同法第126条第7項の規定を満たすものであるか否か,即ち,補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か,以下に検討する。

ア.補正後の請求項1に係る発明
補正後の請求項1は,上記「(1)新規事項」において検討したとおり,当初明細書等に記載されていない事項を含むものであるが,一応,補正後の請求項1に係る発明(以下,「本件手続補正」という)を,上記「1.補正の内容」において,補正後の請求項1として引用した,次の記載のとおりのものであるとする。

「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップとを含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され,前記MPDは,前記データ処理システムで受信される,方法。」

イ.引用刊行物に記載の事項
(ア)原審における平成27年11月13日付けの拒絶理由(以下,これを「原審拒絶理由」という)に引用された,本願の第1国出願前に既に公知である,米国特許出願公開第2009/0210707号明細書(2009年8月20日公開,以下,これを「引用刊行物1」という)には,関連する図面と共に,次の事項が記載されている。

A.「[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. More particularly, 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.」
([0001] 本発明は,一般に,通信ネットワーク分野,特に,データネットワークを介した,ストリーミング,及び,個別メッセージ通信のための,アウト・オブ・バンド認証方法に関連している。より特別には,本発明は,公衆パケット型通信ネットワーク,例えば,インターネット・プロトコル(IP)ネットワークにおける,データの完全性と,接続の相手の信頼性の確保の解決に関連している。<当審にて訳出。以下,同じ。>)

B.「[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. Second channel8 is preferably a secure channel and is implemented in any known way to transmit control data in a secure way. Security protocols that operate at application, at transport or at network level, e.g. it may be implemented through SSL (Secure Socket Layer) or IPSEC (IPSecurity) can be employed in the second channel8.」
([0028] 第1チャンネル7は,データ,望ましくは,個別メッセージとしての,或いは,データ・ストリーム(例えば,マルチメディア,及び,リアルタイム・データ)としての,パケット・データの転送に用いられ,特定されていない(例えば,限定された)セキュリティ特性を有している。第2チャンネル8は,望ましくは,セキュア・チャンネルであり,セキュアな方法において,制御データを転送するための,何れかの既知の方法が,実装されている。アプリケーション・レベルで,トランスポート・レベルで,或いは,ネットワーク・レベルで動作する,例えば,SSL(セキュア・ソケット・レイヤ),或いは,IPSEC(IPセキュリティ)によって実装され得る,セキュア・プロトコルは,第2チャンネル8において,使用され得る。)

C.「[0031] Receiver control module11 is arranged upstream of the receiver3 and includes a receiver data buffer18, a receiver control buffer19 and a receiver processor20. Receiver data buffer18, e.g. a FIFO queue, is connected to the data channel7 and stores the data received on the data channel7. Receiver control buffer19, e.g. a FIFO queue, is connected to the secure channel8 and stores the control information received on the secure channel8. Receiver control buffer19 may be a physical component or may be implemented by and be inherent to the used protocol. For example, TLS (Transport layer Security) and IPSEC (IPSecurity) protocols have a buffer working in a sequential way, which may implement the receiver control buffer19.
[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. The receiver processor20 may also be connected to the receiver3 for sending thereto error messages, in a not shown manner. In alternative, error messages may be sent to an administration server (not shown) which can take suitable measures.
[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.」
([0031] 受信機制御モジュール11は,レシーバ3の上流に配置され,受信機データ・バッファ18,受信機制御バッファ19,及び,受信機プロセッサ20を備える。受信機データ・バッファ18,例えば,FIFOキューは,データ・チャンネル7に接続され,データ・チャンネル7から受信したデータを,格納する。受信機制御バッファ19,例えば,FIFOキューは,セキュア・チャンネル8に接続され,セキュア・チャンネル8から受信した制御情報を,格納する。受信機制御バッファ19は,物理コンポーネントか,使用されるプロトコルによって実装され,使用されるプロトコルに固有なものであり得る。例えば,TLS(トランスポート・レイヤ・セキュリティ),及び,IPSEC(IPセキュリティ)プロトコルは,連続して動作するバッファを有し,それは,受信機制御バッファ19を実装し得る。
[0032] 受信機プロセッサ20は,受信機データ・バッファ18と,受信機制御バッファの両方に接続され,両方からのデータを取得し,図3,4a,4b,及び,4cの参照と共に,以下に詳細に説明されているように,データ・チャンネル7により転送されたデータの信頼性を確認するための処理だけでなく,送信制御モジュール10との同期のために必要な処理も実行する。制御プロセッサは,また,説明されていない方法によって,そこへ,障害メッセージを送信することのために,受信機3に,接続され得る。選択肢として,障害メッセージは,適当な手段を取ることができる,管理者サーバ(図示せず)に送信され得る。
[0033] 送信機制御モジュール10と,受信機制御モジュール11は,物理ノードとして,或いは,既に,存在している,LAN5,6,或いは,ネットワーク4の資源によって実行されるソフトウェア・アプリケーションとして,実装され得る。)

D.「[0040] In addition, the sender control module10 divides the stream sent by the sender2 into a plurality of blocks A_(s)=[a_(s), . . . , a_(s+L)], each block comprising L message units, e.g. four message units, calculates an authentication value for each block and sends the authentication value through the secure channel8 to the receiver control module11. Here, the term “message units”refers, in general, to bytes; however, in packet-like transmissions, it may refer to packets. For the sake of simplicity, in the following description, reference will be made to byte, unless differently specified.」
([0040] 加えて,送信制御モジュール10は,それぞれのブロックが,L個の目メッセージ・ユニット,例えば,4個のメッセージ・ユニットを含む,多数のブロック A=[a_(s), . . . ,a_(s+L)]に,送信機2によって,送信されるストリームを,分割し,それぞれのブロックのために,認証値を計算し,セキュア・チャンネル8を介して,受信制御モジュール11に,認証値を送信する。ここで,“メッセージ・ユニット”という用語は,普通,バイトに言及するが,パケット型の送信においては,パケットに言及する。簡単のため,以下の説明においては,別の指定がない限り,言及は,バイトについてである。)

E.「[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_(1), b_(2), . . . , b_(N)] 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.」
([0055] 図4bは,受信機制御モジュール11が,送信信号を受信すると,直ちに,受信機プロセッサ20によって実行される処理のフローチャートを示す。特に,受信機モジュール11は,データ・チャンネル7から,データ・ストリーム[b_(1),b_(2), . . . ,b_(N)]の最初のバイトが,受信されると,直ちに,起動されることができる。
[0056] 受信機モジュールが,起動されると,受信されたデータ・ストリームは,受信機データ・バッファ18に,累積される。実際には,実施例にしたがって,チャンネル17から受信され,受信機3に誘導される,データ・ストリームは,複製され,複製されたデータ・ストリームは,受信データ・バッファ18に格納される。)

F.「[0061] If the result of the comparison is positive, that is if f_(s)=h_(s), it follows that [b_(s), . . . , b_(s+L)]=[a_(s), . . . , a_(s+L)] and the received block B_(s) 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_(s) 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).」
([0061] 比較の結果が,正,即ち,f_(s)=h_(s)であれば,それに続いて, [b_(s), . . . ,b_(s+L)]=[a_(s), . . . ,a_(s+L)]であり,受信されたブロック B_(s)は,認証される。それ故,送信機は,受信されたブロックが,想定された送信機によって,送信され(相手の信頼性),そして,それが,送信の途中で,改竄されていない(メッセージの完全性)ことを保証される。
[0062] ステップ70におけるチェックが,正の結果を与えるものであれば,上の手続(ステップ64?70)は,データ・ストリームの終わりまで,引き続くデータブロックB_(s)について,継続する(ステップ72からの,はいの出力)。もし,いいえであれば(ステップ70からの,いいえの出力),エラー手続が,実行される(ステップ74)。)

G.「[0071] After having received the first packet, the sender processor13 activates the authentication procedure and sends a first control message C1= 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 C1 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'. Then, the receiver processor20 compares h1 and h1 '. If they match, the integrity of packets 3-6 is positively verified.」
([0071] 最初のパケットが受信されると,送信機プロセッサ13は,認証手続を起動し,最初の制御メッセージC1=を,セキュア・チャンネル8内に送信する。その例において,同期データIは,RTPメッセージの,シーケンス番号であり(ここでは,2),L=4,そして,ハッシュ関数H=SHA-256である。その上に,送信機モジュール10は,それらが送信される命令において,パケットを,そのバッファ12に,ロードし,そして,4つのパケット(最初のブロック)がロードされると,最初のブロックのために,ハッシュ値h1を,計算する。次に,送信機プロセッサ13は,セキュア・チャンネル8の上へ,ハッシュ値h1を送信する。
[0072] その一方で,受信機モジュール11は,最初の制御メッセージC1を受信し,受信されるパケットを,そのデータ・バッファ18へ,受信すること,及び,ロードすることを,開始する。受信モジュール11が,ブロックを構成する,送信されるパケット数(ここでは,4)を受信すると,直ちに,受信機プロセッサ20は,それについて,ハッシュ関数,h1’を計算する。次に,受信機プロセッサ20は,h1と,h1’とを比較する。もし,それらが一致すれば,パケット3?6の完全性が,正であることが,証明される。)

(イ)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,「平林光浩,既存のWebサーバーで途切れない動画配信を実現,日経エレクトロニクス,2012年3月19日,第1078号, p.77-85」(以下,これを「引用刊行物2」という)には,関連する図面と共に,次の事項が記載されている。

H.「次世代の動画配信技術「MPEG-DASH」の国際標準化が決まった。動画圧縮技術の国際標準化団体である「Moving Picture Experts Group(MPEG)」が,2010年4月から仕様策定を本格化していた技術だ。パソコンだけではなく,スマートフォンやタブレット端末,薄型テレビなどの幅広い応用を目指している(図1)。
DASHは,「Dynamic AdaptiveStreaming over HTTP」の略称である。その名が示すように技術の特徴は大きく二つある。
一つは,再生端末の画面サイズや,伝送路の通信帯域(品質)に合わせて,配信する動画データを動的に変更できること。いわゆる「適応型ストリーミング技術」である。もう一つは,Webサイトの通信プロトコルとして一般的なHTTP(hypertext transferprotocol)を用いて動画を配信することだ。」(78頁左欄1行?中欄2行)

I.「MPDファイル
XML形式の階層構造で記述
MPEG-DASHでは,その特徴である適応型のストリーミング配信を実現するため,1本の動画コンテンツ用に画像サイズと符号化速度が異なる動画データ群を用意する(図2)。各動画データは,それぞれ「セグメント(Segment)」と呼ばれる数秒から10秒程度の単位で分割(断片化)し,配信(Web)サーバーに格納しておく。伝送路の状況に応じて,最適な符号化速度のセグメントを再生端末にHTTPで送信する。
この配信の仕組みを管理するために用いるデータが,MPDファイルである。
このファイルの仕様では,Webサーバーに格納された動画コンテンツの構成に関する情報を,XML(ex-tensible markup language)形式による階層構造で記述することを定めている(図3)。

データ要求の制御がカギ
再生端末側では,まず配信サーバーからMPDファイルを取得し,制御用のソフトウエアで同ファイルの内容を読み解く。MPDファイルに記述された情報を基に,Webサーバー側に動画再生に用いる動画や音声のセグメントを要求する。
この際に,再生端末の画面サイズや伝送路の状態などを加味して,それに合わせた最適な画像サイズや符号化速度を選ぶ。」(80頁右欄1行?末行)

J.「複数の構造体で階層的に記述 MPDファイルに記述する情報は例えば,動画を格納したWebサーバーのURL(uniform resource locator)や,格納してある動画データ群の圧縮方式,画像サイズや符号化速度,音声データの圧縮方式,音声の言語情報などである。これらを,「Period」「AdaptationSet」「Representation」といった複数の構造体による階層構造で記述する(p.81の図3)。」(83頁左欄1行?11行)

(ウ)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,「Anthony Vetro,“The MPEG-DASH Standard for Multimedia Streaming Over Internet”2011年, IEE MultiMedia, Volume 18 Issue 4,p.62-67」(以下,これを「引用刊行物3」という)には,関連する図面と共に,次の事項が記載されている。

K.「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.」(63頁右欄5行?64頁左欄35行)
(アダプティブ・ストリーミングの簡単なケース
図1は,オンデマンド,動的,アダプティブ・ストリーミングの関連な例を,説明している。この図で,マルチメディア・コンテンツは,映像と,音声のコンポーネントから成る。映像ソースは,3つの,代替可能な,ビットレート:5Mbps,2Mbps,及び,5Kbpsに,エンコードされている。加えて,低いフレーム・レートである,Iフレームのみのビット・ストリームは,トリック・モード再生の間中ストリーミングのために,備えられている。付随の音声コンテンツは,2つの言語がある:音声1は,音声トラックの吹き替えの英語版で,サラウンド音響で,128Kバイトと,48KバイトのAACに,置換可能に,エンコードされている;一方,音声2は,オリジナルのフランス語版で,128Kバイトと,48KバイトのAACに,置換可能に,エンコードされているだけである。
デバイスが,可能なクオリティで最高(5Mバイト)の映像ビットストリームと,例えば,デバイスが,サラウンド音響(図1におけるラベル1)に対応していないために,128KバイトのAACの英語音声の,要求されたセグメントによって,コンテンツのストリーミングを開始したと仮定する。映像と,音声の最初のセグメントをストリーミングし,実効の,ネットワーク帯域幅のモニタリング後に,デバイスは,実際に可能な帯域幅は,5Mbpsより低いことを知る。そこで,次に可能な,切替ポイントで,デバイスは,128KバイトAACの英語音声のストリーミングを維持したまま,ビデオを,中位品質のコンテンツからの,次のセグメントのストリーミングを用いて,2Mbpsまで下げて,切り替える(図1のラベル2)。デバイスは,実際の,ネットワーク帯域をモニタすることは継続し,ネットワーク帯域が,2Mbpsより,さらに減少したことを知る。それ故,連続した再生を維持するために,デバイスは,ストリームを,500Kbpの映像と,48Kbpsの音声にまで下げて,切り替える(図1のラベル3)。デバイスは,ネットワーク帯域が増加するまで,このレートで,再生を継続し,次に,映像を,2Mbpsまで上げて,切り替える(図1のラベル4)。しばらくして,ユーザが,中止し,巻き戻すことを決定する。このポイントで,デバイスは,音声は,ミュートしたまま,反転要求における映像再生のための,トリック・モード・トラックからの,映像のストリーミングを開始する(図1のラベル5)。要求されたポイントで,ユーザが,オリジナルのフランス語音声で,コンテンツを再生することを,クリックする。このポイントで,デバイスは,最高品質(5Mbps)からの映像と,128Kbpsのフランス語音声からの音声の,ストリーミングを,再開する(図1のラベル6)。
この例は,多分,マルチメディア・コンテンツの,動的ストリーミングの,最も簡単な使用例の1つである。より高度な,使用例は,多数のカメラの視野の切替,3Dマルチメディア・コンテンツのストリーミング,サブタイトルと字幕付の映像ストリーム,動的公告挿入,低レイテンシ・ライブ・ストリーミング,ミックスド・ストリーミング,及び,予め格納されたコンテンツの再生,その他を,含み得る。)

L.「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.」(65頁左欄25行?右欄3行)
(このデータ・モデルを使用するために,DASHクライアントは,最初に,MPDのXMLドキュメントを構文解析する。クライアントは,次に,MPDにおける記述要素,クライアントの能力,及び,ユーザの選択に基づいて使用する,表現のセットを,選択する。クライアントは,次に,タイムラインを構築し,要求されている適切なメディア・セグメントによって,メディア・コンテンツの再生を開始する。それぞれの表現の記述は,そのセグメントについての情報を含み,それは,個々のセグメントについての要求が,HTTP URLと,バイト範囲の用語に関して,定式化されることを可能にする。ライブ・プレゼンテーションのために,MPDはまた,セグメント入手可能性開始時間と,終了時間,およそのメディアの開始時間,及び,セグメントの,固定された,或いは,可変の持続時間を提供する。)

(エ)本願の第1国出願前に既に公知である,特開2009-105633号公報(2009年5月14日公開,以下,これを「周知文献1」という)には,関連する図面と共に,次の事項が記載されている。

M.「当該認証センタ装置により作成された認証子を受信する」(段落【0009】)

(オ)本願の第1国出願前に既に公知である,特開平9-311854号公報(1997年12月2日公開,以下,これを「周知文献2」という)には,関連する図面と共に,次の事項が記載されている。

N.「【0026】まず図4のフローチャートに示す文書送信側装置1の動作を説明する。文書送信側装置1では文書編集部5が,文書を生成する(ステップS31)。次に生成された文書からデジタル署名生成部6が一方向関数を用いて,文書のMDを生成する(ステップS32)。生成されたMDからデジタル署名を生成する(ステップS33)。文書のデジタル署名は,デジタル署名送信部7により格納時にインデクス情報として利用される情報とともに文書検証情報管理装置3に送信される(ステップS34)。文書は文書送信部7によって文書受信側装置2へ送信される(ステップS35)。
【0027】次に図4のフローチャートに示す文書受信側装置2の動作を説明する。文書受信側装置2は文書受信部11で文書送信側装置2の送信した文書を受信する(ステップS41)。次にデジタル署名検証部9において受信した文書からMDを取得する(ステップS42)。次に文書検証情報管理装置3に対してデジタル署名検索要求を送出する(ステップS43)。次に文書検証情報管理装置3からデジタル署名取得部10がデジタル署名を取得する(ステップS44)。取得したデジタル署名はデジタル署名検証部9において,公開鍵暗号方式における送信者のパブリック鍵で復号化される(ステップS45)。ステップS45においてデジタル署名を復号化して得られたMDとステップS42で再生成されたMDの値が比較される(ステップS46)。比較の結果,両者が一致すれば送信者が文書を作成したこと,および作成後文書に対する改竄がおこなわれていないことが判明し(ステップS47),一致しない場合は文書に対する改竄がおこなわれたことが判明する(ステップS48)。」

ウ.引用刊行物に記載の発明
(ア)上記Aの「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.(本発明は,一般に,通信ネットワーク分野,特に,データネットワークを介した,ストリーミング,及び,個別メッセージ通信のための,アウト・オブ・バンド認証方法に関連している。)」という記載,及び,同じく,上記Aの「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.(本発明は,公衆パケット型通信ネットワーク,例えば,インターネット・プロトコル(IP)ネットワークにおける,データの完全性と,接続の相手の信頼性の確保の解決に関連している。)」という記載から,引用刊行物1には,
“IPネットワークにおける,ストリーミング・データの完全性と,接続の相手の信頼性の確保の解決に関連する認証方法”
が記載されていることが読み取れる。

(イ)上記Bの「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.(第1チャンネル7は,データ,望ましくは,個別メッセージとしての,或いは,データ・ストリーム(例えば,マルチメディア,及び,リアルタイム・データ)としての,パケット・データの転送に用いられ,特定されていない(例えば,限定された)セキュリティ特性を有している。)」という記載,上記Dの「the sender control module10 divides the stream sent by the sender2 into a plurality of blocks A_(s)=[a_(s), . . . , a_(s+L)](送信制御モジュール10は・・・多数のブロック A=[a_(s), . . . ,a_(s+L)]に,送信機2によって,送信されるストリームを,分割し)」という記載,及び,上記Eの「the receiver module11 can be activated as soon as the first bytes of a data stream [b_(1), b_(2), . . . , b_(N)] are received from the data channel7.(受信機モジュール11は,データ・チャンネル7から,データ・ストリーム[b_(1),b_(2), . . . ,b_(N)]の最初のバイトが,受信されると,直ちに,起動されることができる。)」という記載から,引用刊行物1においては,
“受信機制御モジュールが,多数のブロックに分割された,マルチメディアのデータ・ストリームのパケット・データを受信”する
ことが読み取れる。

(ウ)上記Cの「Receiver control module11 is arranged upstream of the receiver3 and includes a receiver data buffer18, a receiver control buffer19 and a receiver processor20.(受信機制御モジュール11は,レシーバ3の上流に配置され,受信機データ・バッファ18,受信機制御バッファ19,及び,受信機プロセッサ20を備える。)」という記載,同じく,上記Cの「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.(受信機プロセッサ20は,受信機データ・バッファ18と,受信機制御バッファの両方に接続され,両方からのデータを取得し,図3,4a,4b,及び,4cの参照と共に,以下に詳細に説明されているように,データ・チャンネル7により転送されたデータの信頼性を確認するための処理だけでなく,送信制御モジュール10との同期のために必要な処理も実行する。)」という記載,及び,上記Gの「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'. (受信モジュール11が,ブロックを構成する,送信されるパケット数(ここでは,4)を受信すると,直ちに,受信機プロセッサ20は,それについて,ハッシュ関数,h1’を計算する。)」という記載から,引用刊行物1においては,
“受信機制御モジュールは,データ・チャネルにより転送されたデータの信頼性を確認するための処理として,受信したパケットのハッシュ値h1’を計算”する
ことが読み取れる。

(エ)上記Fの「If the result of the comparison is positive, that is if f_(s)=h_(s), it follows that [b_(s), . . . , b_(s+L)]=[a_(s), . . . , a_(s+L)] and the received block B_(s) 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).(比較の結果が,正,即ち,f_(s)=h_(s)であれば,それに続いて, [b_(s), . . . ,b_(s+L)]=[a_(s), . . . ,a_(s+L)]であり,受信されたブロック B_(s)は,認証される。それ故,送信機は,受信されたブロックが,想定された送信機によって,送信され(相手の信頼性),そして,それが,送信の途中で,改竄されていない(メッセージの完全性)ことを保証される。)」という記載,上記Gの「the sender processor13 sends the hash value h1 onto the secure channel8.(送信機プロセッサ13は,セキュア・チャンネル8の上へ,ハッシュ値h1を送信する。)」という記載,及び,同じく,上記Gの「the receiver processor20 compares h1 and h1 '. If they match, the integrity of packets 3-6 is positively verified.(受信機プロセッサ20は,h1と,h1’とを比較する。もし,それらが一致すれば,パケット3?6の完全性が,正であることが,証明される。)」という記載と,上記(ウ)において検討した事項から,引用刊行物1においては,
“受信機制御モジュールは,送信されたハッシュ値h1と,計算した,受信したパケットのハッシュ値h1’とを比較し,パケットの完全性を検証する”
ものであることが読み取れる。

(オ)以上,(ア)?(エ)において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「IPネットワークにおける,ストリーミング・データの完全性と,接続の相手の信頼性の確保の解決に関連する認証方法であって,
受信機制御モジュールが,多数のブロックに分割された,マルチメディアのデータ・ストリームのパケット・データを受信し,
受信機制御モジュールは,データ・チャネルにより転送されたデータの信頼性を確認するための処理として,受信したパケットのハッシュ値h1’を計算し,
受信機制御モジュールは,送信されたハッシュ値h1と,計算した,受信したパケットのハッシュ値h1’とを比較し,パケットの完全性を検証する,方法。」

エ.本件補正発明と引用発明との対比
(ア)引用発明における「ストリーミング・データ」とは,「データ・ストリーム」を「パケット」に分割したものを含み,引用発明における「パケット」が,本件補正発明における「セグメント」に相当し,
引用発明は,これらの「パケット」に対して,「完全性」と,「信頼性」の検証を行うものであるから,
引用発明における「IPネットワークにおける,ストリーミング・データの完全性と,接続の相手の信頼性の確保の解決に関連する認証方法」と,
本件補正発明における「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法」とは,
“ストリーミングのためのセグメントの保全性および信頼性を検証する方法”
である点で共通する。

(イ)引用発明における「受信機制御モジュール」,「多数のブロックに分割された,マルチメディアのデータ・ストリームのパケット・データ」が,
本件補正発明における「データ処理システム」,「メディアストリームのセグメント」に相当するので,
引用発明における「受信機制御モジュールが,多数のブロックに分割された,マルチメディアのデータ・ストリームのパケット・データを受信」することは,
本件補正発明における「データ処理システムにおいてメディアストリームのセグメントを受信するステップ」に相当する。

(ウ)引用発明における「受信したパケットのハッシュ値h1’」が,
本件補正発明における「セグメントに関するダイジェスト」に相当するので,
引用発明における「受信機制御モジュールは,データ・チャネルにより転送されたデータの信頼性を確認するための処理として,受信したパケットのハッシュ値h1’を計算」することが,
本件補正発明における「前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップ」に相当する。

(エ)引用発明において,「受信機制御モジュールは,送信されたハッシュ値h1と,計算した,受信したパケットのハッシュ値h1’とを比較し,パケットの完全性を検証する」ことは,正しい「ハッシュ値h1」と,「受信機制御モジュール」において,「計算し」て求めた,「受信したパケットのハッシュ値h1’」と比較することで,「受信したパケット」が,改変されているか否かを検証することに他ならないので,
引用発明における「受信機制御モジュールは,送信されたハッシュ値h1と,計算した,受信したパケットのハッシュ値h1’とを比較し,パケットの完全性を検証する」が,
本件補正発明における「データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップ」に相当する。

(オ)以上,(ア)?(エ)において検討した事項から,本件補正発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
ストリーミングのためのセグメントの保全性および信頼性を検証する方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップと,を含む方法。

[相違点1]
“ストリーミング”に関して,
本件補正発明においては,「アダプティブストリーミング」であるのに対して,
引用発明においては,「アダプティブストリーミング」については,特に言及されていない点。

[相違点2]
本件補正発明においては,「正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され」るものであるのに対して,
引用発明においては,「送信されたハッシュ値h1」であって,「MPDにおいて示されるURLを通じて取得され」るものではない点。

[相違点3]
本件補正発明においては,「MPDは,前記データ処理システムで受信される」ものであるのに対して,
引用発明においては,「MPD」に対する言及がない点。

オ.相違点についての当審の判断
(ア)[相違点1]について
「アダプティブストリーミング」については,上記Hに引用した,引用刊行物2の「DASHは,「Dynamic AdaptiveStreaming over HTTP」の略称である。その名が示すように技術の特徴は大きく二つある。
一つは,再生端末の画面サイズや,伝送路の通信帯域(品質)に合わせて,配信する動画データを動的に変更できること。いわゆる「適応型ストリーミング技術」である」という記載内容,或いは,上記Kに引用した,引用刊行物3の「A simple case of adaptive streaming(アダプティブ・ストリーミングの簡単なケース)」に始まる記載内容にもあるとおり,本願の第1国出願前に,当業者には周知の技術事項であるから,
引用発明において,「ストリーミング」を,「アダプティブストリーミング」とすることは,当業者が適宜なし得る事項である。
よって,[相違点1]は,格別のものではない。

(イ)[相違点2]について
上記Jに引用した,引用刊行物2の「複数の構造体で階層的に記述 MPDファイルに記述する情報は例えば,動画を格納したWebサーバーのURL(uniform resource locator)や,格納してある動画データ群の圧縮方式,画像サイズや符号化速度,音声データの圧縮方式,音声の言語情報などである」という記載内容,或いは,上記Lに引用した,引用刊行物3の「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が記述できること”は,本願の第1国出願前に,当業者には周知の技術事項であったといえる。
また,セキュリティの分野では,送信された情報の認証に用いる情報を,送信先以外から取得するような構成は,本願の第1国出願に,当業者には周知の技術事項であるから(必要であれば,上記Mに記載内容を引用した,周知文献1,或いは,上記Nに記載内容を引用した周知文献2等を参照されたい),引用発明においても,必要に応じて,比較のための「ハッシュ値h1」の取得先を,「MPD」に記述するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点2]は,格別のものではない。

(ウ)[相違点3]について
上記Iに引用した,引用刊行物2の「再生端末側では,まず配信サーバーからMPDファイルを取得し」と記載されているとおり,“MPDが,データ処理システム側で受信される”ようにすることは,本願の第1国出願前に,当業者には,周知の技術事項である。
したがって,引用発明においても,「MPD」を用いる構成を導入した際に,「受信機制御モジュール」側で,「MPD」を受信するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点3]は,格別のものではない。

(エ)上記で検討したごとく,[相違点1]?[相違点3]はいずれも格別のものではなく,そして,本件補正発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
よって,本件補正発明は,引用発明,引用刊行物2,及び,引用刊行物3に記載の発明と,当該技術分野における技術常識とに基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許出願の際,特許を受けることができない。

3.補正却下むすび
したがって,本件手続補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。

第3.本願発明について
平成28年6月21日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成28年2月1日付けの手続補正により補正された特許請求の範囲の請求項1に記載された,上記「第2.平成28年6月21日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1として引用した,次のとおりのものである。

「アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップとを含み,
前記正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得される,方法。」

第4.引用刊行物に記載の発明
上記「第2.平成28年6月21日付けの手続補正の却下の決定」の「イ.引用刊行物に記載の事項」において,引用刊行物1として引用した,米国特許出願公開第2009/0210707号明細書(2009年8月20日公開)には,上記「第2.平成28年6月21日付けの手続補正の却下の決定」の「ウ.引用刊行物に記載の発明」において認定したとおりの,次の引用発明が記載されている。

「IPネットワークにおける,ストリーミング・データの完全性と,接続の相手の信頼性をの確保の解決に関連する認証方法であって,
受信機制御モジュールが,多数のブロックに分割された,マルチメディアのデータ・ストリームのパケット・データを受信し,
受信機制御モジュールは,データ・チャネルにより転送されたデータの信頼性を確認するための処理として,受信したパケットのハッシュ値h1’を計算し,
受信機制御モジュールは,送信されたハッシュ値h1と,計算した,受信したパケットのハッシュ値h1’とを比較し,パケットの完全性を検証する,方法。」

第5.本願発明と引用発明との対比
本願発明は,上記「第2.平成28年6月21日付けの手続補正の却下の決定」において検討した,本件補正発明から,
「MPDは,前記データ処理システムで受信される」
という構成を削除したものであるから,
本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
ストリーミングのためのセグメントの保全性および信頼性を検証する方法であって,
データ処理システムにおいてメディアストリームのセグメントを受信するステップと,
前記データ処理システムを用いて,前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと,
前記データ処理システムを用いて,前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して,前記セグメントが改変されているかどうかを判定するステップと,を含む方法。

[相違点a]
“ストリーミング”に関して,
本願発明においては,「アダプティブストリーミング」であるのに対して,
引用発明においては,「アダプティブストリーミング」については,特に言及されていない点。

[相違点b]
本願発明においては,「正しいダイジェストまたは前記正しいデジタル署名は,MPD(メディアプレゼンテーション記述)において示されるURLを通して取得され」るものであるのに対して,
引用発明においては,「送信されたハッシュ値h1」であって,「MPDにおいて示されるURLを通じて取得され」るものではない点。

第6.相違点についての当審の判断
本願発明と,引用発明との[相違点a]は,本件補正発明と,引用発明との[相違点1]と同じものであり,本願発明と,引用発明との[相違点b]は,本件補正発明と,引用発明との[相違点2]と同じものであるから,上記「第2.平成28年6月21日付けの手続補正の却下の決定」の「2.補正の適否」における「(2)独立特許要件」の「オ.相違点についての当審の判断」において検討したとおり,格別のものではない。
そして,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

なお,審判請求人は,平成28年10月26日付けの意見書において,
「引用文献2に示されるように,従来のMPDは,メディアストリームを構成するファイル断片(則ち,セグメント)を示すために使用されます。一方,正しいダイジェストまたは正しいデジタル署名は,メディアストリームの構成に関する情報ではありません。
このように,正しいダイジェストまたは正しいデジタル署名の意味は,ファイル断片(則ち,セグメント)の意味と異なります。
故に,本願発明の上記特徴(前記正しいダイジェストまたは前記正しいデジタル署名は,MPDにおいて示されるURLを通して取得される)は,当業者が進歩性無しに容易に想到できる特徴でありません。」
旨主張しているが,「MPD」に関しては,上記「第2.平成28年6月21日付けの手続補正の却下の決定」の「2.補正の適否」における「(2)独立特許要件」の「オ.相違点についての当審の判断」においての「(イ)[相違点2]について」で検討したとおりであるから,審判請求人の主張は採用できない。

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

よって,結論のとおり審決する。
 
審理終結日 2017-07-04 
結審通知日 2017-07-11 
審決日 2017-07-26 
出願番号 特願2015-509153(P2015-509153)
審決分類 P 1 8・ 575- Z (H04L)
P 1 8・ 121- Z (H04L)
P 1 8・ 561- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
須田 勝巳
発明の名称 アダプティブストリーミングのための、セグメントの保全性および信頼性のためのシステムおよび方法  
代理人 木内 敬二  
代理人 佐伯 義文  

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