【事件の表示】
　特願２０１２−１１３９３１「受信機」拒絶査定不服審判事件〔平成２５年　１月１０日出願公開、特開２０１３−　　９３３２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　経緯
１　経緯
　本件出願は、平成２４年５月１８日（優先権主張平成２３年５月２０日）の出願であって、その手続きの経緯は、以下のとおりである。
　　
　平成２７年　７月１０日：手続補正
　平成２８年　３月　１日：拒絶理由の通知
　平成２８年　５月　９日：手続補正・意見書
　平成２８年　８月２５日：拒絶理由の通知（最後）
　平成２８年１１月　７日：意見書
　平成２９年　４月１８日：拒絶査定
　平成２９年　４月２５日：拒絶査定の謄本の送達
　平成２９年　７月１９日：拒絶査定不服審判の請求
　平成２９年　７月１９日：手続補正
　　
２　査定の概要
　原査定の理由は、概略、次のとおりである。
　　
［査定の理由］
　この出願の請求項１〜５に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　
　　　　　　　　　　　　　　　記
　引用文献１：馬場秋継、外５名，放送とIPコンテンツの同期提示機能の組込み受信機への実装，映像情報メディア学会  ２０１０年冬季大会講演予稿集  ［ＣＤ−ＲＯＭ］，社団法人映像情報メディア学会，２０１０年１１月２６日，10-1
　引用文献２：特表２００８−５４６２２１号公報
　引用文献３：金次保明、外７名，放送通信連携システムＨｙｂｒｉｄｃａｓｔの提案，映像情報メディア学会技術報告，日本，（社）映像情報メディア学会，２０１１年　２月１１日，第35巻、第７号，pp.31〜34
　　
第２　補正却下の決定
　平成２９年７月１９日付けの手続補正について次のとおり決定する。
 　 
［補正却下の決定の結論］
　平成２９年７月１９日付けの手続補正を却下する。
　　
［理由］
１　補正の内容
　平成２９年７月１９日付けの手続補正（以下「本件補正」という。）は、特許請求の範囲についてする補正である。
　　
　本件補正は、
（補正前の請求項１〜５）
「　【請求項１】
　通信コンテンツを記憶した後に出力する同期用バッファと、
　前記同期用バッファの出力をバッファさせる同期制御部と、
　サービス事業者サーバからダウンロードされたアプリケーションプログラムに記述された命令を読み出して実行する命令実行部と
　を備え、
　前記同期制御部は、前記命令実行部によって出力同期のためのメソッドが呼び出された場合に、前記同期用バッファの出力をバッファさせて前記通信コンテンツを放送コンテンツに同期させる
　ことを特徴とする受信機。
　　【請求項２】
　放送コンテンツを記憶した後に出力する第１同期用バッファと、
　通信コンテンツを記憶した後に出力する第２同期用バッファと、
　前記第１同期用バッファまたは前記第２同期用バッファのいずれか一方の出力をバッファさせる同期制御部と、
　サービス事業者サーバからダウンロードされたアプリケーションプログラムに記述された命令を読み出して実行する命令実行部と
　を備え、
　前記同期制御部は、前記命令実行部によって出力同期のためのメソッドが呼び出された場合に、前記第１同期用バッファまたは前記第２同期用バッファのいずれか一方の出力をバッファさせる
　ことを特徴とする受信機。
　　【請求項３】
　前記メソッドは、遅延時間を示す引数を伴うメソッドであり、前記同期制御部は、前記引数が示す遅延時間だけ前記第１同期用バッファまたは前記第２同期用バッファのいずれか一方の出力を遅延させる
　ことを特徴とする請求項２に記載の受信機。
　　【請求項４】
　前記命令実行部によって呼び出されたメソッドが、遅延時間を示す引数を伴うメソッドである場合において、前記遅延時間を示す引数が正数であるとき、前記同期制御部は、前記引数に応じた時間だけ前記第１同期用バッファの出力を遅らせ、前記遅延時間を示す引数が負数であるとき、前記同期制御部は、前記引数に応じた時間だけ前記第２同期用バッファの出力を遅延させる
　ことを特徴とする請求項３に記載の受信機。
　　【請求項５】
　前記命令実行部によって呼び出されたメソッドが、遅延時間を示す第１引数と、前記第１同期用バッファまたは前記第２同期用バッファの何れの出力を遅延させるかを指定する第２引数とを伴うメソッドである場合に、前記同期制御部は、前記第１引数が示す遅延時間だけ、前記第２引数が示すバッファの出力を遅延させる
　ことを特徴とする請求項３に記載の受信機。」
　　
を、次のとおり補正後の請求項１に補正するものである（下線は補正箇所である。）。
　　
（補正後の請求項１）
「　【請求項１】
　通信コンテンツを記憶した後に出力する同期用バッファと、
　前記同期用バッファの出力をバッファさせる同期制御部と、
　サービス事業者サーバからダウンロードされたアプリケーションプログラムに記述された命令を読み出して実行する命令実行部と
　を備え、
　前記同期制御部は、前記命令実行部によって出力同期のためのメソッドが呼び出された場合に、
放送ストリームから分離されたクロックリファレンスに基づいて生成されるタイマーカウンタ値に応じた値を前記同期用バッファに与えることで
前記放送ストリームから分離された
　ことを特徴とする受信機。」
　　
２　新規事項
　補正後の請求項１における「前記同期制御部は、・・・
放送ストリームから分離されたクロックリファレンスに基づいて生成されるタイマーカウンタ値に応じた値を前記同期用バッファに与えること
　詳細は、以下のとおりである。
　　
　請求人は、上記補正の根拠として、
「時計４０３は、タイマーカウンタ値を出力する。時計４０３は、ＰＣＲが示すタイマーカウンタ値により発振器の周波数を調整し、放送送信側と時刻を同期させる。」（段落【０１９２】）、
「・・・放送受信部４０１から供給された放送ストリームを、ＰＣＲ（Program Clock Reference）・・・に分離する。」（段落【０１８７】）、
「第１デコーダ４０５−１は、時計４０３から出力された時刻に対応したＰＴＳが設定されている第１同期用バッファ４０４−１内のＰＥＳパケットを特定し、・・・出力する。」（段落【０１９３】）、
「例えば、本実施形態では、delayStreamPresentation()が、通信コンテンツの出力に対して放送コンテンツの出力を遅延させることを示す出力遅延メソッドであり、遅延時間dを引数とする場合を説明したが、これに限られない。」（段落【０２２４】）を挙げている。
　しかしながら、「同期制御部」が、「放送ストリームから分離されたクロックリファレンスに基づいて生成されるタイマーカウンタ値に応じた値を前記同期用バッファに与える」ことは、上記の請求人が根拠とする箇所には記載されておらず、願書に最初に添付した明細書の他の部分、特許請求の範囲、図面に記載されているとは認められない。
　また、「同期制御部」が、「放送ストリームから分離されたクロックリファレンスに基づいて生成されるタイマーカウンタ値に応じた値を前記同期用バッファに与える」ことが、自明の事項とも認められない。
　　
　したがって、本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでなく、特許法第１７条の２第３項の規定に違反している。 
 　 
３　まとめ 
　したがって、本件補正は、特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　よって、補正却下の決定の結論のとおり決定する。
 　 
第３　本願発明について 
１　本願発明 
　平成２９年７月１９日付けの手続補正は、上記のとおり却下されたので、本願の請求項１〜５に係る発明は、平成２８年５月９日付け手続補正により補正された特許請求の範囲の記載からみて、その特許請求の範囲の請求項１〜５に記載した事項により特定されるとおりのものであるところ、請求項１に係る発明（以下「本願発明」という。）は、次のとおりのものである。
　　
（本願発明）
「（Ａ）通信コンテンツを記憶した後に出力する同期用バッファと、
（Ｂ）前記同期用バッファの出力をバッファさせる同期制御部と、
（Ｃ）サービス事業者サーバからダウンロードされたアプリケーションプログラムに記述された命令を読み出して実行する命令実行部と
　を備え、
（Ｄ）前記同期制御部は、前記命令実行部によって出力同期のためのメソッドが呼び出された場合に、前記同期用バッファの出力をバッファさせて前記通信コンテンツを放送コンテンツに同期させる
（Ｅ）ことを特徴とする受信機。」
　　
（（Ａ）〜（Ｅ）は当審で付与した。以下各構成要件を「構成要件Ａ」〜「構成要件Ｅ」という。）
　　
２　引用文献の記載事項及び引用文献に記載された発明
（１）引用文献１
ア　引用文献１の記載事項
　原査定の拒絶の理由に引用された引用文献１には、「放送とIPコンテンツの同期提示機能の組込み受信機への実装」（タイトル）に関し、図面と共に次に掲げる事項が記載されている（下線は当審で付与した。）。
　　
（ア）「1. はじめに
　我々は、通信機能を活用し放送サービスを強化することを目指すHybridcastTMシステムの研究を進めている。そのサービスのひとつとして、放送と同時にIPネットワーク経由で放送内容をより拡張するための様々なコンテンツを配信し、受信機で同期・合成して提示するサービスを提案している。我々は、これまでPCでの試作により、映像フレーム精度の同期の実現などを確認した。今回、組込み型受信機での同期機能の実現性を試作により確認したので報告する。」（左欄１〜１０行）
　　
（イ）「2. 放送IP同期の基本原理
　提案する同期提示手法では、放送とIPの送出系のシステムクロックを共有させ、
放送番組に付加されている提示時刻情報PTS
BR
と同期したPTS
IP
IPで送るＡＶストリームや各種コンテンツに付加する
受信側では、PTS
BR
とPTS
IP
が同じ値となるデータが同時に提示されるようタイミング制御する
　　
（ウ）「3. 組込み受信機の試作
3.1. 構成
　図１に、同期提示システムの基本構成を示す。
受信機
B
IP
IPストリームの到着時間の差や遅延変動を吸収するためのバッファ
　　
（エ）「3.2. 同期手法と動作確認
　文献[3]では、精密同期のためにデコードの前後にバッファを設けてＡＶストリーム間の同期を実現した。組込み受信機では、Pi部分がオンチップのハードウェアのため、デコード後にバッファを追加する変更は困難であり、Piの前段のみでバッファリングする必要がある。本試作では、AVストリーム間の同期を以下の手法で実現した。字幕、静止画の同期は文献[2]と同じ手法を用いた。
(1)ハードウェア依存のAPIを用い、提示制御部でのPTS
BR
、PTS
IP1
を取得する。PTS
BR
を基準としてPTS
IP1
との差を計算する。
(2)Piの一時停止、再開を制御するAPIを用い、手順1の差分だけP
BR
, P
IP
の一方を一時停止する。
(3) Piの停止中もBiでTSがバッファリングされ、一時停止の解除後はTSがPiに読み込まれると同時に再生が再開されるため、デコード後のバッファなしでＡＶストリームが同期して提示される。
　
上記の構成、手法により、ハイビジョン映像(17Mbps程度)、字幕、静止画データが放送番組と同期して提示できる
　本試作により、Piの前段にTS信号用のバッファを設ける簡易な構成と、バッファ読込みと提示のタイミングを同時に調整する制御手法により、所望の同期機能が実現できることが確認できた。」（左欄２９行〜右欄２１行）
　　
（オ）
「
」
　　
イ　引用文献１に記載された発明
　引用文献１には、「受信機」が記載されており、この受信機を引用文献１に記載された発明として認定する。
　上記（ウ）によると、当該受信機は、「IPストリームの到着時間の差や遅延変動を吸収するためのバッファBIP」を備えている。
　上記（イ）における「受信側では、PTSBR（放送番組に付加されている提示時刻情報）とPTSIP（IPで送るＡＶストリームや各種コンテンツに付加するPTSBRと同期したPTS）が同じ値となるデータが同時に提示されるようタイミング制御する」こと、及び、上記（オ）の図１の「タイミング制御」を参酌すると、当該受信機は、「バッファBIPの出力を、PTSBR（放送番組に付加されている提示時刻情報）とPTSIP（IPストリームに付加するPTSBRと同期したPTS）が同じ値となるデータが同時に提示されるように、タイミング制御を行うタイミング制御部」を備えているいえる。
　上記（エ）によると、当該受信機は、「(1)ハードウェア依存のAPIを用い、提示制御部でのPTSBR、PTSIP1を取得する。PTSBRを基準としてPTSIP1との差を計算」し、「(2)Piの一時停止、再開を制御するAPIを用い、手順1の差分だけPBR, PIPの一方を一時停止」し、「(3) Piの停止中もBiでTSがバッファリングされ、一時停止の解除後はTSがPiに読み込まれると同時に再生が再開されるため、デコード後のバッファなしでＡＶストリームが同期して提示」することにより、IPストリームが放送番組と同期して提示される。
　ＡＰＩは、アプリケーションプログラムにおいて読み出されるものであり、上記の動作は、アプリケーションプログラムにおいて読み出されたＡＰＩにより行われるものと認められる。
　以上より、当該受信機は、アプリケーションプログラムにおいて読み出されたＡＰＩにより、バッファリングして、IPストリームと放送番組を同期させるものである。
　　
　以上より、引用文献１には、次の発明（以下「引用発明」という。）が記載されていると認められる。
　　
（引用発明）
「（ａ）IPストリームの到着時間の差や遅延変動を吸収するためのバッファと、
（ｂ）前記バッファの出力を、PTSBR（放送番組に付加されている提示時刻情報）とPTSIP（IPストリームに付加するPTSBRと同期したPTS）が同じ値となるデータが同時に提示されるように、タイミング制御を行うタイミング制御部と
を備え、
（ｃ）アプリケーションプログラムにおいて読み出されたＡＰＩにより、バッファリングして、IPストリームと放送番組を同期させる
（ｄ）ことを特徴とする受信機。」
　　
（（ａ）〜（ｄ）は、引用発明の構成を区別するために付与した。以下各構成を「構成ａ」〜「構成ｄ」という。）
　　
（２）引用文献２
ア　引用文献２の記載事項
　原査定の拒絶の理由に引用された引用文献２には、「放送録画再生装置および方法」（発明の名称）に関し、図面と共に次に掲げる事項が記載されている（下線は当審で付与した。）。
　　
「【０１９０】
　実施の形態では、ＡＩＴの開始時刻から
サービスを
再生するために
両メソッドを連続して呼び出す構成としたが、これをひとまとめにした新たなメソッドをＡＰＩとして新設してもよい
　　
イ　引用文献２に記載された技術
　上記アによると、引用文献２には、「放送録画再生装置において、サービスを再生するために、メソッドを含むＡＰＩを設ける技術」が記載されている。
　　
（３）引用文献３
ア　引用文献３の記載事項
　原査定の拒絶の理由に引用された引用文献３には、「放送通信連携システムHybridcastの提案」（タイトル）に関し、図面と共に次に掲げる事項が記載されている（下線は当審で付与した。）。
　　
（ア）「5.4. 受信機
　受信機は，受信する放送波に多重化された情報をもとにして，
サービス事業者サーバにアプリの要求を行う
アプリがダウンロードされたら，アプリを実行して，サービス事業者サーバにアクセスしてコンテンツを取得する
　受信機能，ネットワークのインタフェース，表示なの基本機能の実装はメーカに依存する．Hybridcast受信機は，同期機能，アプリ管理機能などHybridcastサービスを実行するために必要な機能を持つ．APIは共通化し，アプリの制作を容易にするとともに，アプリが受信機に依存しないようにする．
　Hybridcastでは，PCや携帯端末などのデバイスとの連携のための機能も取り入れている．」（３４頁左欄５〜１８行）
　　
イ　引用文献３に記載された技術
　上記ア（ア）によると、引用文献３には、「受信機がサービス事業者サーバにアプリの要求を行い、アプリがダウンロードされたら、アプリを実行する技術」が記載されている。
　　
３　対比
（１）本願発明と引用発明とを対比する。
ア　構成要件Ａと構成ａとを対比する。
　構成ａの「バッファ」は、「IPストリームの到着時間の差や遅延変動を吸収するため」に用いられるものであるから、「通信コンテンツを記憶した後に出力する同期用バッファ」といえ、構成要件Ａと一致する。
　　
イ　構成要件Ｂと構成ｂとを対比する。
　構成ｂの「前記バッファの出力を、PTSBR（放送番組に付加されている提示時刻情報）とPTSIP（IPストリームに付加するPTSBRと同期したPTS）が同じ値となるデータが同時に提示されるように、タイミング制御を行う」ことは、「前記同期用バッファの出力をバッファさせる」ことといえ、このような制御を行うタイミング制御部は、「同期制御部」といえる。
　したがって、構成要件Ｂと構成ｂとは、「前記同期用バッファの出力をバッファさせる同期制御部」として一致する。
　　
ウ　構成要件Ｃと構成ｃとを対比する。
　構成ｃは、「アプリケーションプログラムにおいて読み出されたＡＰＩにより、バッファリングして、IPストリームと放送番組を同期させる」ものであり、このような動作をさせるためには、アプリケーションプログラムに記述された命令を読み出して実行する命令実行部を、受信機が備えているといえる。
　したがって、構成要件Ｃと構成ｃとは、「アプリケーションプログラムに記述された命令を読み出して実行する命令実行部」として共通する。
　しかしながら、「アプリケーションプログラム」について、本願発明は、「サービス事業者サーバからダウンロードされた」アプリケーションプログラムであるのに対し、引用発明は、「サービス事業者サーバからダウンロードされた」アプリケーションプログラムと特定されていない点で相違する。
　　
エ　構成要件Ｄと構成ｂとを対比する。
　構成ｂの「前記バッファの出力を、PTSBR（放送番組に付加されている提示時刻情報）とPTSIP（IPストリームに付加するPTSBRと同期したPTS）が同じ値となるデータが同時に提示されるように、タイミング制御を行う」ことは、「前記同期用バッファの出力をバッファさせて前記通信コンテンツを放送コンテンツに同期させる」ことといえる。
　したがって、構成要件Ｄと構成ｂとは、「前記同期制御部は、前記同期用バッファの出力をバッファさせて前記通信コンテンツを放送コンテンツに同期させる」として共通する。
　しかしながら、「同期制御部」について、本願発明は、「前記命令実行部によって出力同期のためのメソッドが呼び出された場合」に同期させるのに対し、引用発明は、当該「前記命令実行部によって出力同期のためのメソッドが呼び出された場合」に同期させると特定していない点で相違する。
　　
オ　構成要件Ｅと構成ｄとを対比する。
　構成ｄの「受信機」は、「受信装置」といえるから、「受信装置」として、構成Ｅと一致する。
　　
（２）一致点、相違点
　以上によると、本願発明と引用発明の一致点、相違点は次のとおりである。
　　
（一致点）
　通信コンテンツを記憶した後に出力する同期用バッファと、
　前記同期用バッファの出力をバッファさせる同期制御部と、
　アプリケーションプログラムに記述された命令を読み出して実行する命令実行部と
　を備え、
　前記同期制御部は、前記同期用バッファの出力をバッファさせて前記通信コンテンツを放送コンテンツに同期させる
　ことを特徴とする受信機。
　　
（相違点１）
　「アプリケーションプログラム」について、本願発明は、「サービス事業者サーバからダウンロードされた」アプリケーションプログラムであるのに対し、引用発明は、「サービス事業者サーバからダウンロードされた」アプリケーションプログラムと特定されていない点
　　
（相違点２）
　「同期制御部」について、本願発明は、「前記命令実行部によって出力同期のためのメソッドが呼び出された場合」に同期させるのに対し、引用発明は、当該「前記命令実行部によって出力同期のためのメソッドが呼び出された場合」に同期させると特定していない点
　　
４　相違点の判断等 
（１）相違点１について
　上記２（３）イのとおり、引用文献３には、「受信機がサービス事業者サーバにアプリの要求を行い、アプリがダウンロードされたら、アプリを実行する技術」が記載されている。
　引用発明は、アプリケーションプログラムを用いるものであるから、引用発明に引用文献３に記載された技術を適用して、引用発明の「アプリケーションプログラム」を「サービス事業者サーバからダウンロードされた」ものとすることは、当業者が容易に想到し得ることである。
　　
（２）相違点２について
　上記２（２）イのとおり、引用文献２には、「放送録画再生装置において、サービスを再生するために、メソッドを含むＡＰＩを設ける技術」が記載されている。
　引用発明は、IPストリーム（サービスに相当）を再生するために、アプリケーションプログラムを用いるものであるから、引用発明に引用文献２に記載された技術を適用して、アプリケーションプログラムとして、メソッドを含むＡＰＩを用いるようにすることは、当業者が容易に想到し得ることである。
　ここで、引用発明の「ＡＰＩ」は、「バッファリングして、IPストリームと放送番組を同期させる」ものであるから、上記のメソッドは、「出力同期のためのメソッド」となる。
　したがって、引用発明に引用文献２に記載された発明を適用して、引用発明において、「前記命令実行部によって出力同期のためのメソッドが呼び出された場合」に同期させるようにすることは、当業者が容易に想到し得ることである。
　　
（３）そして、本願発明が奏する効果は、その容易想到である構成から当業者が容易に予測し得る範囲内のものであり、同範囲を超える顕著なものでもない。
　　
（４）したがって、本願発明は、引用発明及び引用文献２、引用文献３に記載された技術に基づいて当業者が容易に発明することができたものと認められる。
　　
５　むすび 
　以上のとおり、本願の請求項１に係る発明は、引用文献１に記載された発明及び引用文献２、引用文献３に記載された技術に基づいて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　　
　よって、結論のとおり審決する。