2016-001742

特願２０１４－　　　６６５「デバイスへのオーディオ処理能力の動的供給」拒絶査定不服審判事件〔平成２６年　５月２９日出願公開，特開２０１４－　９９８９３〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 第１　手続の経緯 本件審判請求に係る出願（以下，「本願」という。）は，２０１０年１月２１日（パリ条約による優先権主張外国庁受理２００９年１月２９日（以下，「優先日」という。），米国）を国際出願日とする特願２０１１－５４８１０１号の一部を平成２６年１月６日に新たな特許出願としたものであって，その手続の経緯は以下のとおりである。 平成２６年　１月３０日　　　：翻訳文，手続補正書，出願審査請求 書，上申書の提出 平成２７年　３月　９日付け　：拒絶理由の通知 平成２７年　６月１７日　　　：意見書，手続補正書の提出 平成２７年１０月２８日付け　：拒絶査定 平成２８年　２月　５日　　　：審判請求書，手続補正書の提出 平成２８年　３月１０日　　　：前置報告 平成２８年　５月１６日　　　：上申書の提出 第２　平成２８年２月５日付けの手続補正についての補正却下の決定 ［補正却下の決定の結論］ 平成２８年２月５日付けの手続補正を却下する。 ［理由］ １　補正の内容 平成２８年２月５日付けの手続補正（以下，「本件補正」という。）の内容は，平成２７年６月１７日付けの手続補正により補正された特許請求の範囲の請求項１乃至２３の記載 「　　【請求項１】 第１の無線ネットワークを通してデバイスと通信するように構成された第１の無線インターフェースと， 第２の無線ネットワークを通してリモートサーバと通信するように構成された第２の無線インターフェースであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，第２の無線インターフェースと， 前記第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信することと， 前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成されたコントローラと， を備え， 前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含む，無線通信デバイス。 【請求項２】 前記構成情報は，前記デバイスの１つまたは複数の処理能力を示すように構成された構成インジケータをさらに含む，請求項１に記載の無線通信デバイス。 【請求項３】 前記デバイスはデータを復号するためのデフォルトコーデックを記憶しており，前記データは第２の特定の形式で符号化されたオーディオである，請求項１に記載の無線通信デバイス。 【請求項４】 前記実行ファイルは，前記デバイスに含まれる揮発性メモリにダウンロードされ，前記デフォルトコーデックは前記デバイスに含まれる不揮発性メモリに記憶される，請求項３に記載の無線通信デバイス。 【請求項５】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項１に記載の無線通信デバイス。 【請求項６】 第１の無線ネットワークを通して第２のデバイスと通信するための第１の無線インターフェースと，第２の無線ネットワークを通してリモートサーバと通信するための第２の無線インターフェースと，を含む無線通信デバイスであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，無線通信デバイスを備え， 前記無線通信デバイスは，前記第１の無線ネットワークを通して前記第２のデバイスから第２のデバイス構成情報を検索することと， 前記第２のデバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記第２のデバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが前記無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記第２のデバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成され， 前記第２のデバイス構成情報を検索することは，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索することを備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含む，装置。 【請求項７】 前記第２のデバイスは，前記第１の無線ネットワークを通して前記実行ファイルを受信するように構成された，請求項６に記載の装置。 【請求項８】 前記第２のデバイスは無線ヘッドセットである，請求項７に記載の装置。 【請求項９】 前記第１の無線ネットワークはブルートゥースネットワークである，請求項７に記載の装置。 【請求項１０】 前記無線通信デバイスは，セルラ電話または携帯情報端末（PDA）である，請求項６に記載の装置。 【請求項１１】 前記無線通信デバイスは，前記実行ファイルをダウンロードするために，ブルートゥース一般オブジェクト交換プロファイルを用いる，請求項７に記載の装置。 【請求項１２】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項８に記載の装置。 【請求項１３】 前記無線通信デバイスは， 前記ヘッドセットのハードウェア構成を識別するように構成された回路構成と， 前記ハードウェア構成に基づいて前記実行ファイルを選択するように構成された回路構成と， を含む，請求項８に記載の装置。 【請求項１４】 前記実行ファイルはオーディオ実行ファイルである，請求項１３に記載の装置。 【請求項１５】 第１の無線ネットワークを通してリモートサーバと通信するための手段であって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，手段と， 第２の無線ネットワークを通して第２のデバイスと通信するための手段と， 前記第２の無線ネットワークを通して前記第２のデバイスから第２のデバイス構成情報を検索するための手段と， 前記第２のデバイス構成情報に基づいて実行ファイルを選択するための手段であって，前記実行ファイルは特定の形式でデータを処理するように前記第２のデバイスを構成するためのものである，手段と， 前記選択された実行ファイルがローカルに記憶されているかどうかを判断し，もし記憶されていなければ前記第１の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索するための手段と， 前記第２の無線ネットワークを通して前記第２のデバイスに前記選択された実行ファイルをダウンロードするための手段と， を備え， 前記第２のデバイス構成情報を検索するための手段は，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索するための手段を備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含む，装置。 【請求項１６】 前記リモートサーバで前記実行ファイルを記憶するための手段と， 前記記憶するための手段から前記実行ファイルを検索し，前記検索された実行ファイルを前記ダウンロードするための手段に提供するための手段と， をさらに備える，請求項１５に記載の装置。 【請求項１７】 前記第２の無線ネットワークはブルートゥースネットワークである，請求項１５に記載の装置。 【請求項１８】 前記装置は，セルラ電話または携帯情報端末（PDA）である，請求項１６に記載の装置。 【請求項１９】 前記ダウンロードするための手段は，前記実行ファイルをダウンロードするために，ブルートゥース一般オブジェクト交換プロファイルを用いる，請求項１６に記載の装置。 【請求項２０】 前記ダウンロードするための手段は，前記第２のデバイスに少なくとも部分的に含まれる，請求項１６に記載の装置。 【請求項２１】 前記第２のデバイスはヘッドセットである，請求項１６に記載の装置。 【請求項２２】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項２１に記載の装置。 【請求項２３】 前記ヘッドセットのハードウェア構成を識別するための手段と， 前記ハードウェア構成に基づいて前記実行ファイルを選択するための手段と， をさらに備える，請求項２１に記載の装置。」 （以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。） を， 「　　【請求項１】 第１の無線ネットワークを通してデバイスと通信するように構成された第１の無線インターフェースと， 第２の無線ネットワークを通してリモートサーバと通信するように構成された第２の無線インターフェースであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，第２の無線インターフェースと， 前記第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信することと， 前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成されたコントローラと， を備え， 前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す，無線通信デバイス。 【請求項２】 前記構成情報は，前記デバイスの１つまたは複数の処理能力を示すように構成された構成インジケータをさらに含む，請求項１に記載の無線通信デバイス。 【請求項３】 前記デバイスはデータを復号するためのデフォルトコーデックを記憶しており，前記データは第２の特定の形式で符号化されたオーディオである，請求項１に記載の無線通信デバイス。 【請求項４】 前記実行ファイルは，前記デバイスに含まれる揮発性メモリにダウンロードされ，前記デフォルトコーデックは前記デバイスに含まれる不揮発性メモリに記憶される，請求項３に記載の無線通信デバイス。 【請求項５】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項１に記載の無線通信デバイス。 【請求項６】 第１の無線ネットワークを通して第２のデバイスと通信するための第１の無線インターフェースと，第２の無線ネットワークを通してリモートサーバと通信するための第２の無線インターフェースと，を含む無線通信デバイスであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，無線通信デバイスを備え， 前記無線通信デバイスは，前記第１の無線ネットワークを通して前記第２のデバイスから第２のデバイス構成情報を検索することと， 前記第２のデバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記第２のデバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが前記無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記第２のデバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成され， 前記第２のデバイス構成情報を検索することは，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索することを備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記第２のデバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す，装置。 【請求項７】 前記第２のデバイスは，前記第１の無線ネットワークを通して前記実行ファイルを受信するように構成された，請求項６に記載の装置。 【請求項８】 前記第２のデバイスは無線ヘッドセットである，請求項７に記載の装置。 【請求項９】 前記第１の無線ネットワークはブルートゥースネットワークである，請求項７に記載の装置。 【請求項１０】 前記無線通信デバイスは，セルラ電話または携帯情報端末（PDA）である，請求項６に記載の装置。 【請求項１１】 前記無線通信デバイスは，前記実行ファイルをダウンロードするために，ブルートゥース一般オブジェクト交換プロファイルを用いる，請求項７に記載の装置。 【請求項１２】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項８に記載の装置。 【請求項１３】 前記無線通信デバイスは， 前記ヘッドセットのハードウェア構成を識別するように構成された回路構成と， 前記ハードウェア構成に基づいて前記実行ファイルを選択するように構成された回路構成と， を含む，請求項８に記載の装置。 【請求項１４】 前記実行ファイルはオーディオ実行ファイルである，請求項１３に記載の装置。 【請求項１５】 第１の無線ネットワークを通してリモートサーバと通信するための手段であって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，手段と， 第２の無線ネットワークを通して第２のデバイスと通信するための手段と， 前記第２の無線ネットワークを通して前記第２のデバイスから第２のデバイス構成情報を検索するための手段と， 前記第２のデバイス構成情報に基づいて実行ファイルを選択するための手段であって，前記実行ファイルは特定の形式でデータを処理するように前記第２のデバイスを構成するためのものである，手段と， 前記選択された実行ファイルがローカルに記憶されているかどうかを判断し，もし記憶されていなければ前記第１の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索するための手段と， 前記第２の無線ネットワークを通して前記第２のデバイスに前記選択された実行ファイルをダウンロードするための手段と， を備え， 前記第２のデバイス構成情報を検索するための手段は，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索するための手段を備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記第２のデバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す，装置。 【請求項１６】 前記リモートサーバで前記実行ファイルを記憶するための手段と， 前記記憶するための手段から前記実行ファイルを検索し，前記検索された実行ファイルを前記ダウンロードするための手段に提供するための手段と， をさらに備える，請求項１５に記載の装置。 【請求項１７】 前記第２の無線ネットワークはブルートゥースネットワークである，請求項１５に記載の装置。 【請求項１８】 前記装置は，セルラ電話または携帯情報端末（PDA）である，請求項１６に記載の装置。 【請求項１９】 前記ダウンロードするための手段は，前記実行ファイルをダウンロードするために，ブルートゥース一般オブジェクト交換プロファイルを用いる，請求項１６に記載の装置。 【請求項２０】 前記ダウンロードするための手段は，前記第２のデバイスに少なくとも部分的に含まれる，請求項１６に記載の装置。 【請求項２１】 前記第２のデバイスはヘッドセットである，請求項１６に記載の装置。 【請求項２２】 前記特定の形式は，PCM，ADPCM，MP3，AAC，WMA，およびRealからなるグループから選択されるオーディオ符号化形式を含む，請求項２１に記載の装置。 【請求項２３】 前記ヘッドセットのハードウェア構成を識別するための手段と， 前記ハードウェア構成に基づいて前記実行ファイルを選択するための手段と， をさらに備える，請求項２１に記載の装置。」 （当審注：下線は，請求人が付与したものである。以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。） に補正するものである。 そして，本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてなされており，特許法第１７条の２第３項の規定に適合している。 また，本件補正は，特別な技術的特徴を変更（シフト補正）をしようとするものではなく，特許法第１７条の２第４項の規定に適合している。 ２　目的要件 本件補正は上記「１　補正の内容」のとおり，本件審判の請求と同時にする補正であり，特許請求の範囲について補正をしようとするものであるから，本件補正が，特許法第１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。 （１）補正前の請求項と，補正後の請求項とを比較すると，補正後の請求項１乃至２３はそれぞれ，補正前の請求項１乃至２３に対応することは明らかである。 （２）よって，本件補正は，下記の補正事項１乃至３よりなるものである。 ＜補正事項１＞ 補正前の請求項１の 「前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含む」との記載を， 補正後の請求項１の 「前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」との記載に変更する補正。 ＜補正事項２＞ 補正前の請求項６の 「前記第２のデバイス構成情報を検索することは，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索することを備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含む」との記載を， 補正後の請求項６の 「前記第２のデバイス構成情報を検索することは，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索することを備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記第２のデバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」との記載に変更する補正。 ＜補正事項３＞ 補正前の請求項１５の 「前記第２のデバイス構成情報を検索するための手段は，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索するための手段を備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含む」との記載を， 補正後の請求項１５の 「前記第２のデバイス構成情報を検索するための手段は，前記第２のデバイスが生成した，前記第２のデバイスの構成を示すSDPサービス応答を検索するための手段を備え，前記SDPサービス応答は，前記第２のデバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記第２のデバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記第２のデバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」との記載に変更する補正。 （３）補正事項１乃至３について 補正事項１は，発明特定事項である「前記SDPサービス応答」に，「前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」の限定を加えることを目的とするものであり， また，補正事項２，３は，発明特定事項である「前記SDPサービス応答」に，「前記第２のデバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」の限定を加えることを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。 （４）したがって，上記補正事項１乃至３は限定的減縮を目的とするものであるから，本件補正は，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当すると言えることから，特許法第１７条の２第５項の規定に適合するものである。 ３　独立特許要件 以上のように，本件補正は，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮（限定的減縮）を目的とする上記補正事項１乃至３を含むものである。そこで，限定的減縮を目的として補正された補正後の請求項１に記載された発明（以下，「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。 （１）本件補正発明 本件補正発明は，上記平成２８年２月５日付けの手続補正により補正された特許請求の範囲，明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。 「　第１の無線ネットワークを通してデバイスと通信するように構成された第１の無線インターフェースと， 第２の無線ネットワークを通してリモートサーバと通信するように構成された第２の無線インターフェースであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，第２の無線インターフェースと， 前記第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信することと， 前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成されたコントローラと， を備え， 前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み， 前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す，無線通信デバイス。」 （２）引用例 （２－１）引用例１に記載されている技術的事項および引用発明 ア　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年３月９日付けの拒絶理由通知において引用された，特開２００６－３１３３７号公報（平成１８年２月２日出願公開，以下，「引用例１」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ａ　「【００１５】 １．第１の実施の形態 １－１．システムの概要 図１は，本発明における第１の実施の形態としてのコンテンツダウンロードシステム１の概要を示した図である。 図１において，第１の実施の形態のコンテンツダウンロードシステム１としては，記録再生装置２，パーソナルコンピュータ３，サーバ装置４，ネットワーク５を少なくとも含んで構成される。 先ず，記録再生装置２としては，ポータブル用途のものを想定している。また，記憶媒体として，例えばＭＤ（Mini Disc：光磁気ディスク）についての記録再生が可能な構成が採られる。 また，パーソナルコンピュータ３は，本発明で言う情報処理装置であり，例えばＵＳＢ（Universal Serial Bus）ケーブル等を介して記録再生装置２との間でのデータ通信を行うことが可能とされる。また，ネットワーク５を介してサーバ装置４との間でもデータ通信を行うことが可能とされる。 そして，第１の実施の形態の場合では，サーバ装置４に対してコンテンツデータが格納されている。つまり，このような第１の実施の形態のコンテンツダウンロードシステム１としては，サーバ装置４に格納されるコンテンツデータを，パーソナルコンピュータ３を経由して記録再生装置２にダウンロードして，これを装填されたＭＤに対して記録，再生するという使用形態を想定している。」 Ｂ　「【００２５】 ＵＳＢインタフェイス１８は，ＵＳＢケーブルを介して接続された外部機器との間でデータ通信を行うために備えられる。特に，この場合のＵＳＢインタフェイス１８を介しては，ＣＰＵ６の制御に基づいて，図１に示したパーソナルコンピュータ３との間で各種のデータ，例えばオーディオデータ等の送受信が行われる。 【００２６】 なお，外部機器との間の通信インタフェイスとしては，例えばＩＥＥＥ１３９４インタフェイス等の他のインタフェイスを採用することもできる。さらには，有線によるものに限らず，例えば無線ＬＡＮ（Local Area Network）やBluetooth等の無線による通信インタフェイスも採用できる。 …（後略）…」 Ｃ　「【００２７】 １－３．情報処理装置の構成 図３は，図１に示したパーソナルコンピュータ３の内部構成例を示すブロック図である。 図３において，先ずＣＰＵ２１は，起動されたプログラムに基づいてパーソナルコンピュータ３全体の制御，演算処理を行う。例えばユーザに対する入出力動作，ＨＤＤ３０へのデータファイルの格納や管理情報の作成・更新等を行う。 この場合のＣＰＵ２１としても，図示するバス３５を介して各部との間で制御信号やデータのやりとりを行うようにされる。 …（中略）… 【００２９】 ＵＳＢインタフェイス２３は，ＵＳＢケーブルを介して接続された外部機器との間でデータ通信を行うために備えられる。上記もしたように，特にこの場合のＵＳＢインタフェイス２３を介しては，図２に示した記録再生装置２との間でオーディオデータ等の各種データの送受信が行われる。 …（中略）… 【００３５】 通信処理部３１は，ＣＰＵ２１の制御に基づいて送信データのエンコード処理，受信データのデコード処理を行う。 ネットワークインタフェイス３２は，上記通信処理部３１でエンコードされた送信データを，図１に示したネットワーク５を介して所定の機器，例えばサーバ装置４に送信する。またネットワーク５を介してサーバ装置４などの外部機器から送信されてきた信号を通信処理部３１に受け渡す。 通信処理部３１は受信した情報をＣＰＵ２１に転送する。」 Ｄ　「【００４４】 １－５．動作概要 これまでで説明した第１の実施の形態としてのコンテンツダウンロードシステム１の構成により実現しようとする動作を，次の図５を参照して説明する。 なお，図５では，第１の実施の形態としてのコンテンツダウンロードシステム１において行われる動作の概要を模式的に示している。 先ず，第１の実施の形態の場合は，サーバ装置４において格納されるコンテンツデータをパーソナルコンピュータ３を介して記録再生装置２にダウンロードする使用形態を想定したものである。 …（中略）… 【００４６】 ここで，このリソース情報７ｂの情報内容について，次の図６を参照して説明しておく。 このリソース情報７ｂとは，先にも述べたように記録再生装置２におけるデコード処理に係るリソースについて示す情報となる。 具体的には，図６に示される各種の情報を含むのもとなる。 図６において，先ず「ＤＳＰの種類」は，図２に示したＤＳＰ１２の種類（例えば製造メーカーの情報等）を示す情報である。また，「動作周波数」は，ＤＳＰ１２の動作周波数を表す。 また，「再生に割り当てられる最大処理能力値」は，ＤＳＰ１２がデコード処理に割くことのできる最大処理能力を示す値である。具体的には，ＭＩＰＳ（Million Instructions Per Second）の値等とされればよい。 【００４７】 また，「再生に割り当てられる最大メモリ容量」は，ＤＳＰ１２が備えるメモリにデコード処理時に割り当てることができる最大容量を示す。この場合は，ＤＳＰ１２が備えるフラッシュメモリ１６と内蔵ＲＡＭの双方の容量が示される。 また，「コプロセッサの情報」としては，ＤＳＰ１２が備えるコプロセッサについての情報を示す。例えば，ＤＳＰ１２がハフマン復号器等のコプロセッサを備える場合はその情報が示される。 【００４８】 さらに，「対応するコーデックの情報」としては，ＤＳＰ１２がデコード処理可能なコーデックの種類を示す情報となる。例えば，図２に示したフラッシュメモリ１６に格納されるデコード処理プログラム１６ａとして，ＡＴＲＡＣとＡＴＲＡＣ３とのコーデックに対応したデコードプログラムが格納されて，これらＡＴＲＡＣ及びＡＴＲＡＣ３のコーデックにより圧縮処理されたオーディオデータについてのデコード処理が可能な場合は，その旨を示す情報が格納される。 なお，この図６にて示したリソース情報７ｂの情報内容はあくまで一例であり，記録再生装置２におけるデコード処理に係るリソースについて示す情報であればこれらに限定されるものではない。」 Ｅ　「【００４９】 図５において，先の（２）の動作によってリソース情報７ｂを要求されたパーソナルコンピュータ３は，（３）として示すように，記録再生装置２からリソース情報７ｂを取得する動作を行う。つまり，ＵＳＢケーブルを介して接続された記録再生装置２に対する制御を行って，図２に示したフラッシュメモリ１６に格納されているリソース情報７ｂをパーソナルコンピュータ３側に送信させるものである。 そして，このようにリソース情報７ｂを取得すると，パーソナルコンピュータ３は，（４）として示すようにこのリソース情報７ｂをサーバ装置４に対して送信する。 【００５０】 パーソナルコンピュータ３からリソース情報７ｂを受信したサーバ装置４では，（５）と示すように，リソース情報・最適コーデック対応情報４８ｂ参照してリソース情報７ｂに応じた最適なコーデックを割り出すようにされる。 【００５１】 ここで，このようなリソース情報・最適コーデック対応情報４８ｂとしては，受信されたリソース情報７ｂから，記録再生装置２が対応可能な最適なコーデックを割り出すための情報となる。 具体的には，例えば各コーデックごとに，リソース情報７ｂとしての先の図６に示したそれぞれの項目について必要最低限のスペックを示した情報となる。すなわち，この場合ではＡＴＲＡＣ，ＡＴＲＡＣ３，ＡＴＲＡＣ３plusの各コーデック対応に，図６に示した各項目について必要となる最低限のスペックを示したものとなる。 【００５２】 サーバ装置４では，このようにリソース情報・最適コーデック対応情報４８ｂに示される各項目の必要最低限スペックの情報と，受信されたリソース情報７ｂの各項目の情報とについて比較を行って，記録再生装置２が対応可能な最適なコーデックを割り出すようにされる。…（後略）…」 Ｆ　「【００５５】 図５において，サーバ装置４は，上記した（６）の動作として，先の（１）によりパーソナルコンピュータ３側から指定されたタイトルによるコンテンツデータのうち，上述にようにして割り出された最適コーデックによりエンコードされたコンテンツデータを認識するようにされる。 【００５６】 さらに，サーバ装置４では，（７）として示すようにパーソナルコンピュータ３側から受信されたリソース情報７ｂに基づき，記録再生装置２が最適コーデックに対応しているか否かの判別処理を行うようにされる。すなわち，先の図６に示したリソース情報７ｂ中の「対応するコーデックの情報」として，割り出された最適コーデックの情報が含まれているか否かについての判別処理を行うようにされる。 【００５７】 その上でサーバ装置４では，（８）の動作として，先の（６）により認識されたコンテンツデータの送信を行うと共に，上記した（７）による判別結果に応じては，最適コーデックのデコードプログラムを送信するようにされる。 つまり，（７）による判別処理によって，記録再生装置２が最適コーデックに対応しているとされた場合は，認識された最適コーデックによるコンテンツデータのみをパーソナルコンピュータ３側に送信するようにされる。 また，（７）の判別処理の結果，記録再生装置２が最適コーデックに対応していないとされた場合は，コンテンツデータと共に，最適コーデックによりエンコードされたコンテンツデータについてのデコード処理を可能とするためのデコードプログラムを，パーソナルコンピュータ３側に送信するものである。 【００５８】 パーソナルコンピュータ３では，（９）の動作として，サーバ装置４より受信されたコンテンツデータについての記録と，また，受信の有無に応じてはデコードプログラムについての記録を記録再生装置２に実行させる。 つまり，受信されたコンテンツデータについては，図２に示したメディアドライブ１１に装填されたＭＤに対する記録を実行させ，デコードプログラムについてはフラッシュメモリ１６に対する記録動作を実行させる。」 Ｇ　「【００５９】 このような第１の実施の形態としての動作によれば，記録再生装置２のリソース情報７ｂに応じた，最適な（最新の）コーデックによるコンテンツデータを記録再生装置２に対してダウンロードすることができる。つまり，記録再生装置２ごとに，それぞれが対応するとされるコーデックによるコンテンツデータをダウンロードすることが可能となる。 そして，これによれば，例えばすべての記録再生装置２にて対応可能な旧バージョンによるコーデックのコンテンツデータを一義的にダウンロードするとした場合のように，新バージョンに対応する記録再生装置２の能力を活かしきれなくなるといった事態を防止できる。 【００６０】 また，上記実施の形態の動作によれば，記録再生装置２が割り出された最適コーデックについてのデコード処理機能を有していない場合は，これに対応させるためのデコードプログラムも記録再生装置２側にダウンロードされるものとなる。 これによれば，記録再生装置２のデコード処理に係るリソース（つまりデコード処理能力）は割り出された最適コーデックに対応可能なスペック（能力）を有するが，デコードプログラムが対応していないがためにその再生が不能とされる場合にも，割り出された最適コーデックによるコンテンツデータについての再生を行わせることができる。 つまり，これによって記録再生装置２の有するデコード処理能力を最大限に発揮させることができるものである。」 Ｈ　「【０１０４】 さらに，第１の実施の形態では，サーバ装置４側においてリソース情報７ｂに応じた最適コーデックを割り出すようにしたが，パーソナルコンピュータ３にリソース情報・最適コーデック対応情報４８ｂを備えさせてパーソナルコンピュータ３側が最適コーデックを割り出すようにし，サーバ装置４側はパーソナルコンピュータ３側からの要求に応じたコンテンツデータを送信するのみとされる構成が採られてもよい。」 イ　ここで，引用例１に記載されている事項を検討する。 （ア）上記Ａの段落【００１５】の「図１において，第１の実施の形態のコンテンツダウンロードシステム１としては，記録再生装置２，パーソナルコンピュータ３，サーバ装置４，ネットワーク５を少なくとも含んで構成される。」，「また，パーソナルコンピュータ３は，本発明で言う情報処理装置であり，例えばＵＳＢ（Universal Serial Bus）ケーブル等を介して記録再生装置２との間でのデータ通信を行うことが可能とされる。また，ネットワーク５を介してサーバ装置４との間でもデータ通信を行うことが可能とされる。」，「そして，第１の実施の形態の場合では，サーバ装置４に対してコンテンツデータが格納されている。」との記載からすると，「コンテンツダウンロードシステム」は「記録再生装置」，「情報処理装置」，「サーバ装置」から構成され，「情報処理装置」は，「記録再生装置」との間でデータ通信を行うための「ＵＳＢケーブル」と，コンテンツデータが格納されている「サーバ装置」との間でデータ通信を行うための「ネットワーク」とに接続されていることが読み取れる。 また，上記Ｂの段落【００２６】の「さらには，有線によるものに限らず，例えば無線ＬＡＮ（Local Area Network）やBluetooth等の無線による通信インタフェイスも採用できる。」，上記Ｃの段落【００２９】の「ＵＳＢインタフェイス２３は，ＵＳＢケーブルを介して接続された外部機器との間でデータ通信を行うために備えられる。上記もしたように，特にこの場合のＵＳＢインタフェイス２３を介しては，図２に示した記録再生装置２との間でオーディオデータ等の各種データの送受信が行われる。」との記載からすると，「パーソナルコンピュータ」と「記録再生装置」との間で，Bluetooth等の無線の無線通信インタフェイスを介してデータを通信する態様が読み取れ，上記Ｃの段落【００３５】の「ネットワークインタフェイス３２は，上記通信処理部３１でエンコードされた送信データを，図１に示したネットワーク５を介して所定の機器，例えばサーバ装置４に送信する。」との記載からすると，「パーソナルコンピュータ」と「サーバ装置」との間の「ネットワーク」で「ネットワークインタフェイス」を介してデータを通信する態様が読み取れる。 そうすると，引用例１には， “記録再生装置との間のBluetooth等の無線でデータ通信を行うための無線通信インタフェイスと，コンテンツデータが格納されているサーバ装置との間のネットワークでデータ通信を行うためのネットワークインタフェイスと”を備えた“パーソナルコンピュータ。” が記載されていると解される。 （イ）上記Ｅの段落【００４９】の「図５において，先の（２）の動作によってリソース情報７ｂを要求されたパーソナルコンピュータ３は，（３）として示すように，記録再生装置２からリソース情報７ｂを取得する動作を行う。」との記載からすると，「パーソナルコンピュータ」は，「記録再生装置」から「リソース情報」を取得することが読み取れる。 また，上記Ｄの段落【００４６】～【００４８】の「このリソース情報７ｂとは，先にも述べたように記録再生装置２におけるデコード処理に係るリソースについて示す情報となる。具体的には，図６に示される各種の情報を含むのもとなる。図６において，先ず「ＤＳＰの種類」は，図２に示したＤＳＰ１２の種類（例えば製造メーカーの情報等）を示す情報である。また，「動作周波数」は，ＤＳＰ１２の動作周波数を表す。また，「再生に割り当てられる最大処理能力値」は，ＤＳＰ１２がデコード処理に割くことのできる最大処理能力を示す値である。具体的には，ＭＩＰＳ（Million Instructions Per Second）の値等とされればよい。…（中略）…さらに，「対応するコーデックの情報」としては，ＤＳＰ１２がデコード処理可能なコーデックの種類を示す情報となる。例えば，図２に示したフラッシュメモリ１６に格納されるデコード処理プログラム１６ａとして，ＡＴＲＡＣとＡＴＲＡＣ３とのコーデックに対応したデコードプログラムが格納されて，これらＡＴＲＡＣ及びＡＴＲＡＣ３のコーデックにより圧縮処理されたオーディオデータについてのデコード処理が可能な場合は，その旨を示す情報が格納される。」との記載からすると，「リソース情報」は，Bluetooth等の無線通信インタフェイスを介して，「記録再生装置」のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むことが読み取れるから，引用例１には， “記録再生装置から，Bluetooth等の無線通信インタフェイスを介して，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得”する“パーソナルコンピュータ。” が記載されていると解される。 （ウ）上記Ｅの段落【００４９】の「そして，このようにリソース情報７ｂを取得すると，パーソナルコンピュータ３は，（４）として示すようにこのリソース情報７ｂをサーバ装置４に対して送信する。」，段落【００５０】の「パーソナルコンピュータ３からリソース情報７ｂを受信したサーバ装置４では，（５）と示すように，リソース情報・最適コーデック対応情報４８ｂ参照してリソース情報７ｂに応じた最適なコーデックを割り出すようにされる。」，段落【００５２】の「サーバ装置４では，このようにリソース情報・最適コーデック対応情報４８ｂに示される各項目の必要最低限スペックの情報と，受信されたリソース情報７ｂの各項目の情報とについて比較を行って，記録再生装置２が対応可能な最適なコーデックを割り出すようにされる。」との記載からすると，「パーソナルコンピュータ」は，「記録再生装置」から受信した「リソース情報」を「サーバ装置」に送信し，「サーバ装置」は，「リソース情報」に応じた「記録再生装置」に最適な「コーデック」を割り出すことが読み取れる。 ここで，上記Ｈの段落【０１０４】の「さらに，第１の実施の形態では，サーバ装置４側においてリソース情報７ｂに応じた最適コーデックを割り出すようにしたが，パーソナルコンピュータ３にリソース情報・最適コーデック対応情報４８ｂを備えさせてパーソナルコンピュータ３側が最適コーデックを割り出すようにし，サーバ装置４側はパーソナルコンピュータ３側からの要求に応じたコンテンツデータを送信するのみとされる構成が採られてもよい。」との記載からすると，「サーバ装置」側で「リソース情報」に応じた最適な「コーデック」を割り出す態様に代わるものとして，「パーソナルコンピュータ」側で「リソース情報」に応じた最適な「コーデック」を割り出す態様が読み取れる。 また，上記Ｆの段落【００５６】の「さらに，サーバ装置４では，（７）として示すようにパーソナルコンピュータ３側から受信されたリソース情報７ｂに基づき，記録再生装置２が最適コーデックに対応しているか否かの判別処理を行うようにされる。」，段落【００５７】の「また，（７）の判別処理の結果，記録再生装置２が最適コーデックに対応していないとされた場合は，コンテンツデータと共に，最適コーデックによりエンコードされたコンテンツデータについてのデコード処理を可能とするためのデコードプログラムを，パーソナルコンピュータ３側に送信するものである。」との記載からすると，最適「コーデック」に係る「デコードプログラム」に「記録再生装置」が対応していない場合には，「パーソナルコンピュータ」は「サーバ装置」からコンテンツデータと共に，当該「デコードプログラム」を受信することが読み取れるから，引用例１には， “リソース情報に応じた記録再生装置に最適なコーデックを割り出し，最適なコーデックに係るデコードプログラムに記録再生装置が対応していない場合には，サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信”する“パーソナルコンピュータ。” が記載されていると解される。 （エ）上記Ｆの段落【００５８】の「パーソナルコンピュータ３では，（９）の動作として，サーバ装置４より受信されたコンテンツデータについての記録と，また，受信の有無に応じてはデコードプログラムについての記録を記録再生装置２に実行させる。」との記載，上記Ｇの段落【００５９】の「このような第１の実施の形態としての動作によれば，記録再生装置２のリソース情報７ｂに応じた，最適な（最新の）コーデックによるコンテンツデータを記録再生装置２に対してダウンロードすることができる。」，段落【００６０】の「また，上記実施の形態の動作によれば，記録再生装置２が割り出された最適コーデックについてのデコード処理機能を有していない場合は，これに対応させるためのデコードプログラムも記録再生装置２側にダウンロードされるものとなる。」との記載からすると，「パーソナルコンピュータ」は，「サーバ装置」からコンテンツデータと共に，「リソース情報」に応じた最適な「コーデック」に係る「デコードプログラム」を受信し，それらを「記録再生装置」にダウンロードすることが読み取れるから，引用例１には， “コンテンツデータと共に，最適なコーデックに係るデコードプログラムを記録再生装置に対してダウンロード”する“パーソナルコンピュータ。” が記載されていると解される。 （オ）上記Ｃの段落【００２７】の「図３において，先ずＣＰＵ２１は，起動されたプログラムに基づいてパーソナルコンピュータ３全体の制御，演算処理を行う。例えばユーザに対する入出力動作，ＨＤＤ３０へのデータファイルの格納や管理情報の作成・更新等を行う。」との記載からすると，「パーソナルコンピュータ」が備える「ＣＰＵ」が，上記（イ）乃至（エ）で検討した「パーソナルコンピュータ」の動作の制御を行っていることが読み取れる。 ウ　以上，（ア）乃至（オ）で示した事項から，引用例１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。 「記録再生装置との間のBluetooth等の無線でデータ通信を行うための無線通信インタフェイスと， コンテンツデータが格納されているサーバ装置との間のネットワークでデータ通信を行うためのネットワークインタフェイスと， 前記記録再生装置から，Bluetooth等の前記無線通信インタフェイスを介して，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得し， 前記リソース情報に応じた前記記録再生装置に最適なコーデックを割り出し，前記最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信し， 前記コンテンツデータと共に，前記最適なコーデックに係る前記デコードプログラムを前記記録再生装置に対してダウンロードする，ことを制御するＣＰＵと， を備えたパーソナルコンピュータ。」 （２－２）引用例２に記載されている技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年３月９日付けの拒絶理由通知において引用された，特開２０００－１３４２３７号公報（平成１２年５月１２日出願公開，以下，「引用例２」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｊ　「【００３９】（第３実施形態）図８は，本発明の第３実施形態に係るシステム構成である。ここでは，第１実施形態との違いについてのみ説明する。 【００４０】本第３実施形態では，前述のＤＬＢ１７が外部ネットワーク２０と電話回線などで接続されており，外部のネットワークからソフトウェアデコーダをダウンロードできるように構成されている。外部のネットワークとしては，インターネットなどが考えられる。ＤＬＢ１７の動作手順の一例を図９に示す。 【００４１】すなわち，ＤＬＢ１７は，ＴＶ１２あるいはＰＣ１１の制御機器によりダウンロード要求が行われると，そのダウンロード要求されたソフトウェアデコーダを保持しているか否かを調べ（ステップＳ５０１），保持してない場合には，インターネットなどの外部ネットワークを介して予め決められた所定のサーバからソフトウェアデコーダをダウンロードし，それを保持する（ステップＳ５０２）。そして，ＴＶ１２あるいはＰＣ１１の制御機器によりダウンロード要求されたソフトウェアデコーダを制御機器に送出する（ステップＳ５０３）。」 （２－３）引用例３に記載されている技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の平成２７年１０月２８日付けの拒絶査定において引用された，特開２００３－２０９７８２号公報（平成１５年７月２５日出願公開，以下，「引用例３」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｋ　「【００２５】 ブルートゥース対応機器間の通信仕様として，送受信機器の用途ごとのプロファイル（Profile）が策定されているほか，機器の接続，認証，暗号化などを行うためのＧＡＰ（Generic Access Profile）や，他の機器に登録されているサービスを発見するためのＳＤＰ（Service Discovery Profile）など，他のプロファイルの下層に位置し，共通した仕様を定めているプロファイルを備えている。ブルートゥース機器間で通信を行うためには，双方が同じプロファイルに対応している必要がある。 …（中略）… 【００３１】サービスディスカバリプロトコルＳＤＰでは，それぞれ上位層でのクライアントサーバ間の機器間で，通信可能な範囲にあるブルートゥース機器が提供可能なサービスやその特徴を知るために，互いに照会している。」 （２－４）引用例４に記載されている技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の平成２７年１０月２８日付けの拒絶査定において引用された，特開２００８－３０５４１５号公報（平成２０年１２月１８日出願公開，以下，「引用例４」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｌ　「【００５９】 図４において，まず，携帯端末７０１から，近傍にBluetoothデバイスが存在するか探索（Inquiry）が行われる（矢印a）。探索に対して，近傍のBluetoothデバイス７０２，７０３は応答を返す（矢印b1，b2）。この時，非Bluetoothデバイス７０４は応答を返さない。携帯端末７０１は，Bluetoothデバイス７０２，７０３と順番に接続（Page）を行い，サービスディスカバリプロトコル（SDP）を利用して，各Bluetoothデバイスの種類やサポートするプロファイルを取得する（矢印c1，d1，e1，c2，d2，e2）。」 （２－５）参考文献５に記載されている技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった，特開２００３－３０９５４１号公報（平成１５年１０月３１日出願公開，以下，「参考文献５」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｍ　「【００５５】ここで，オーディオ・ビジュアル（ＡＶ）機器の分野においてＢｌｕｅｔｏｏｔｈ通信を導入した場合，図１に示すように，ステレオ・コンポやメディア・プレイヤなどのオーディオ・データ・ストリームの出力源となるＳｏｕｒｃｅ装置１１をマスタとして定義する一方で，ヘッドフォン１２やパーソナル・コンピュータ（ＰＣ）１３などのオーディオ出力ターゲットとなるＳｉｎｋ装置をスレーブ機器として定義することができる。 【００５６】図２には，図１に示したＢｌｕｅｔｏｏｔｈピコネット１０を構成するＳｏｕｒｃｅ装置としてのオーディオ・プレーヤ（マスタ）１１と，Ｓｉｎｋ装置としてのヘッドフォン（スレーブ）１２の構成を模式的に示している。」 Ｎ　「【０１０１】図８には，Ｓｏｕｒｃｅ装置１１とＳｉｎｋ装置１２間でのＧＡＶＤＰに従ってストリーミングのセットアップと解放を行うためのＳｏｕｒｃｅ装置とＳｉｎｋ装置間での処理の流れを詳細に示している。但し，同図中で"＊"が付されたものは"Generic Access Profile"（ＧＡＰ）で規定されている処理手続であり，また，"＊＊"が付されたものは"Service Discovery Protocol"（ＳＤＰ）で定義されている処理手続であると理解されたい。ＧＡＰ及びＳＤＰは，Ｂｌｕｅｔｏｏｔｈの共通基本機能である。 …（中略）… 【０１０７】次いで，サービス・ディスカバリ（Service Discovery），すなわち，スレーブが備える機能又はサービスを検出するために，ＳＤＰ用のＬ２ＣＡＰチャンネル（論理リンク・チャンネル）を張り，ＳＤＰプロトコルによりＳｉｎｋ装置１２がどのようなサービスに対応しているか（すなわち，Ｓｉｎｋ装置１２が対応しているプロトコル，プロファイルなどの情報）を知る。そして，ＳＤＰ用のＬ２ＣＡＰチャンネルを解放してから，ＡＶＤＴＰシグナリングのためのＬ２ＣＡＰチャンネルを張る。 【０１０８】このようにして，ＧＡＶＤＰで定義されているストリーミング開始（Start Streaming）処理手続を経て，オーディオ・ストリームの伝送が行われる。」 （２－６）参考文献６に記載されている技術的事項 本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった，特開２００１－１０３０６７号公報（平成１３年４月１３日出願公開，以下，「参考文献６」という。）には，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｐ　「【００４６】図３に，図１の構成でＡＶデータ（ＢＴ端末１１１のＶＴＲ＿ＳｕｂＵｎｉｔ１１２内に記憶されているデータ）をＢＴ端末１０１がＢｌｕｅｔｏｏｔｈ経由で読み出して，鑑賞等する場合の処理シーケンスの一例を示す。 【００４７】（１）ＢＴ端末１０１とＢＴ端末１１１とが接近し，各々がお互いの通信可能領域に存在することを認識する（Ｂａｓｅｂａｎｄ処理による）。 【００４８】（２）ＢＴ端末１０１とＢＴ端末１１１との間でのＡＶ／Ｃメッセージ転送のための論理コネクションを設定する（Ｌ２ＣＡＰ処理による）。 【００４９】（３）ＢＴ端末１０１およびＢＴ端末１１１が，それぞれ，無線リンクの状態情報をＢｌｕｅｔｏｏｔｈ上のプロトコル（ＨＣＩ）を用いて収集し，それをＳＤＰプロトコルで用いられるディスクリプタ（Ｄｅｓｃｒｉｐｔｏｒ）内に記憶する。なお，この場合，図１中のＳＤＰ情報（１０３，１１３）が，ＳＤＰプロトコルで用いられるＤｅｓｃｒｉｐｔｏｒ情報に対応する。 …（中略）… 【００５３】（７）ＢＴ端末１０１およびＢＴ端末１１１が，それぞれ，無線リンクの状態情報をＢｌｕｅｔｏｏｔｈ上のプロトコル（ＨＣＩ）を用いて収集し，それをＳＤＰプロトコルで用いられるＤｅｓｃｒｉｐｔｏｒ（１０３，１１３）内に記憶する。 【００５４】（８）ＢＴ端末１０１上のＡＶアプリケーションが，自端末のＳＤＰプロトコルにおけるＤｅｓｃｒｉｐｔｏｒ情報を読み取り，Ｂｌｕｅｔｏｏｔｈのリンク状態情報を入手する。 …（中略）… 【００６１】ここで，上記処理シーケンス中の処理（３），（７）で収集されるＢｌｕｅｔｏｏｔｈリンクの状態情報としては，例えば，その時点でＢｌｕｅｔｏｏｔｈ上で利用可能な転送方式の種類（例えばＡＣＬやＳＣＯ）と，それら転送方式の状態（例えば帯域情報やチャネル情報）などが考えられる。また，Ｂｌｕｅｔｏｏｔｈのバージョン情報（例えばＶｅｒ．１もしくはＶｅｒ．２）や，Ｂｌｕｅｔｏｏｔｈの動作している電力モード（例えば高電力モードもしくは低電力モード）などの状態情報を通知することも考えられる。さらには，Ｌ２ＣＡＰ上の論理コネクション設定数などの，データリンクレイヤ情報を通知することも考えられる。また，可能であれば，ＢＴ端末のハードウェア情報（例えば，無線処理部の機能情報や，従っているプロトコルのバージョン情報など）も，無線のリンク状態情報の一部として取り込んでいくことも考えられる。 …（中略）… 【００６３】図４に，本実施形態で実行されているＳＤＰプロトコルが保持するＤｅｓｃｒｉｐｔｏｒ情報の一例を示す。 …（中略）… 【００６５】図４には示していないが，このＤｅｓｃｒｉｐｔｏｒ情報には，Ｂｌｕｅｔｏｏｔｈの状態情報として，ＡＣＬやＳＣＯといった転送方式の種類別の情報以外にも，Ｂｌｕｅｔｏｏｔｈのバージョン情報や電力モードやハードウェア情報などの他の状態情報も記述可能である。このようなＤｅｓｃｒｉｐｔｏｒを用いることにより，ＳＤＰプロトコル２６を用いることで，他のＢＴ端末から読み出すことが可能となる。」 （３）対比 ア　本件補正発明と引用発明とを対比する。 （ア）引用発明の「パーソナルコンピュータ」は，「記録再生装置」との間の「Bluetooth等の無線」でデータ通信を行うための「無線通信インタフェイス」と，コンテンツデータが格納されている「サーバ装置」との間の「ネットワーク」でデータ通信を行うための「ネットワークインタフェイス」とを備えていることから，引用発明の「パーソナルコンピュータ」，「記録再生装置」，「サーバ装置」はそれぞれ，本件補正発明の「無線通信デバイス」，「デバイス」，「リモートサーバ」に相当する。 そうすると，「パーソナルコンピュータ」と「サーバ装置」の間を無線ネットワークを介して通信することは周知慣用であることから，引用発明の「Bluetooth等の無線」，「無線通信インタフェイス」はそれぞれ，本件補正発明の「第１の無線ネットワーク」，「第１の無線インターフェース」に相当し，引用発明の「ネットワーク」，「ネットワークインタフェイス」はそれぞれ，本件補正発明の「第２の無線ネットワーク」，「第２の無線インターフェース」に相当すると言える。 （イ）引用発明の「ＣＰＵ」は，「記録再生装置から，Bluetooth等の前記無線通信インタフェイスを介して，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得」するところ，上記（ア）での検討から，引用発明の「記録再生装置」は本件補正発明の「デバイス」に相当し，「リソース情報」は「記録再生装置」内の少なくとも処理ハードウェアリソースを識別するためのものであると言えるから，引用発明の「リソース情報」は本件補正発明の「デバイス構成情報」に相当すると言える。 そして，引用発明の「リソース情報」は，「パーソナルコンピュータ」がBluetooth等の前記無線通信インタフェイスを介して「記録再生装置」から取得するものの，「記録再生装置」が生成した「SDPサービス応答」を受信することについて言及されていないことから，本件補正発明は，「SDPサービス応答」を受信する点で引用発明と相違する。 また，引用発明の「ＣＰＵ」は，「パーソナルコンピュータ」内で処理動作の制御を行っていることから，本件補正発明の「コントローラ」に対応する。 そうすると，引用発明の「ＣＰＵ」が「記録再生装置から，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得」することと，本件補正発明の「コントローラ」が「第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信すること」，「前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み，前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」とは，後記する点で相違するものの，“コントローラ”が“第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信すること”である点で共通していると言える。 （ウ）引用発明の「ＣＰＵ」は，「リソース情報に応じた前記記録再生装置に最適なコーデックを割り出し，前記最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信」するところ，「コーデックに係るデコードプログラム」は，特定のコーデックの形式でデータを処理するように「記録再生装置」を構成するためのものであると言えるから，引用発明の「コーデックに係るデコードプログラム」は本件補正発明の「実行ファイル」に相当すると言え，引用発明では，「リソース情報に応じた前記記録再生装置に最適なコーデックを割り出し」ているが，実質的に，「リソース情報」に基づいて「コーデックに係るデコードプログラム」を選択するとみることができる。 また，引用発明では，「最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信」するところ，必要があれば「サーバ装置」から「デコードプログラム」を検索するとみることができるから，本件補正発明における「選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索すること」とは，“必要があれば，第２の無線ネットワークを通してリモートサーバから選択された実行ファイルを検索する”点で一致すると言える。 そうすると，引用発明の「ＣＰＵ」が「リソース情報に応じた前記記録再生装置に最適なコーデックを割り出し，前記最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信」することと，本件補正発明の「コントローラ」が「前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと，前記選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索すること」とは，後記する点で相違するものの，“コントローラ”が“デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと，必要があれば前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索すること”である点で共通していると言える。 （エ）引用発明の「ＣＰＵ」は，「コンテンツデータと共に，前記最適なコーデックに係る前記デコードプログラムを前記記録再生装置に対してダウンロードする」ところ，最適なコーデックに係る「デコードプログラム」は，すなわち，選択された「デコードプログラム」であるから，「Bluetooth等の無線」を通して，「記録再生装置」に選択された「デコードプログラム」をダウンロードすると言える。 そうすると，引用発明の「ＣＰＵ」が「前記最適なコーデックに係る前記デコードプログラムを前記記録再生装置に対してダウンロードする」ことは，本件補正発明の「コントローラ」が「第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすること」に相当すると言える。 イ　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 ＜一致点＞ 「第１の無線ネットワークを通してデバイスと通信するように構成された第１の無線インターフェースと， 第２の無線ネットワークを通してリモートサーバと通信するように構成された第２の無線インターフェースであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，第２の無線インターフェースと， 前記第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信することと， 前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと， 必要があれば，前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成されたコントローラと， を備えた，無線通信デバイス。」 ＜相違点１＞ リモートサーバからの実行ファイルの検索に関し，本件補正発明では，「選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ」「リモートサーバ」から検索するのに対して，引用発明では，「最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，」「サーバ装置」から最適なコーデックに係る「デコードプログラム」を受信する点。 ＜相違点２＞ デバイス構成情報の受信に関し，本件補正発明では，「デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み，前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」のに対して，引用発明では，「記録再生装置から，Bluetooth等の前記無線通信インタフェイスを介して，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得」するものの，「SDPサービス応答」を受信することについて言及されていない点。 （４）当審の判断 上記相違点１，２について検討する。 ア　相違点１について 引用発明では，「最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信」するところ，必要があれば「サーバ装置」から「デコードプログラム」を検索するとみることができる。 一方，デジタルＡＶデータ再生技術に関し，必要なデコーダを自身で保持しているか否かを判断し，保持していなければ，外部のサーバからデコーダをダウンロードすることは，例えば，引用例２（上記Ｊを参照）に記載されるように，本願の優先日前には当該技術分野における周知技術であった。 そして，引用発明と上記周知技術とは，デジタルＡＶデータ再生技術であって，デコードプログラムを装置に提供することを課題とする点で一致している。 そうすると，引用発明において上記周知技術を適用し，最適なコーデックに係る選択されたデコードプログラムがパーソナルコンピュータ内に記憶されているかどうかを判断し，もし記憶されていなければ，サーバ装置からデコードプログラムを受信すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。 イ　相違点２について 引用発明では，「記録再生装置から，Bluetooth等の前記無線通信インタフェイスを介して，前記記録再生装置のデコード処理に係るＤＳＰ等ハードウェアの情報や，デコード処理可能なコーデック種類の情報を含むリソース情報を取得し」，「最適なコーデックに係るデコードプログラムに前記記録再生装置が対応していない場合には，前記サーバ装置からコンテンツデータと共に，前記デコードプログラムを受信」するところ，「パーソナルコンピュータ」は「記録再生装置」と無線通信を行うに先立ち，「記録再生装置」のハードウェアの情報や，デコード処理可能なコーデック種類，すなわち符号化形式の情報を受信し，「記録再生装置」がコーデックに係るデコードプログラム，すなわち復号器実行ファイルを受信し得，かつ様々な符号化形式をサポートするように再構成され得ることを示すと言える。 また，Bluetoothを使用した無線通信において，サービスディスカバリプロトコル（ＳＤＰ）を利用して，通信に先立ち，通信相手のデバイスのサービス属性等のプロファイルをSDPのサービス応答で受信することは，例えば，引用例３（上記Ｋを参照），引用例４（上記Ｌを参照），参考文献５（上記Ｍ，Ｎを参照），参考文献６（上記Ｐを参照）に記載されるように，本願の優先日前には当該技術分野において普通に実施されていた技術であった。特に，オーディオ情報の復号処理に係る情報や，無線通信に係るハードウェアの情報をプロファイルとして，Bluetoothのサービスディスカバリプロトコル（ＳＤＰ）を利用して，通信相手のデバイスからSDPのサービス応答で受信することは，例えば，参考文献５（上記Ｍ，Ｎを参照），参考文献６（上記Ｐを参照）に記載されるように，本願の優先日前には既に周知技術であった。 そうすると，引用発明において上記周知技術を適用し，記録再生装置の構成を示すSDPサービス応答を受信し，SDPサービス応答は，記録再生装置によってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および記録再生装置の構成情報を示す属性を含むSDPサービス記録を含むものとし，さらにSDPサービス応答は，記録再生装置がオーディオ復号器実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示すこと，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。 ウ　小括 上記で検討したごとく，相違点１，２に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。 したがって，本件補正発明は，上記引用発明及び，引用例２乃至４，参考文献５乃至６に記載の当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。 ４　補正却下の決定のむすび 上記「３　独立特許要件」で指摘したとおり，補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，本件補正は特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 よって，上記補正却下の決定の結論のとおり決定する。 第３　本願発明について １　本願発明 平成２８年２月５日付けの手続補正は上記のとおり却下されたので，補正後の請求項１に対応する補正前の請求項１に係る発明（以下，「本願発明」という。）は，平成２７年６月１７日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。 「　第１の無線ネットワークを通してデバイスと通信するように構成された第１の無線インターフェースと， 第２の無線ネットワークを通してリモートサーバと通信するように構成された第２の無線インターフェースであって，前記リモートサーバは１つまたは複数の実行ファイルを記憶する，第２の無線インターフェースと， 前記第１の無線ネットワークを通して前記デバイスからデバイス構成情報を受信することであって，前記デバイス構成情報は前記デバイス内の少なくとも処理ハードウェアリソースを識別する，受信することと， 前記デバイス構成情報に基づいて実行ファイルを選択することであって，前記実行ファイルは特定の形式でデータを処理するように前記デバイスを構成するためのものである，選択することと， 前記選択された実行ファイルが無線通信デバイス内に記憶されているかどうかを判断し，もし記憶されていなければ前記第２の無線ネットワークを通して前記リモートサーバから前記選択された実行ファイルを検索することと， 前記第１の無線ネットワークを通して前記デバイスに前記選択された実行ファイルをダウンロードすることと， を行うように構成されたコントローラと， を備え， 前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含む，無線通信デバイス。」 ２　引用例に記載されている技術的事項及び引用発明 原査定の拒絶の理由に引用された，引用発明は，前記「第２　平成２８年２月５日付けの手続補正についての補正却下の決定」の「３　独立特許要件」の「（２）引用例」に記載したとおりである。 ３　対比・判断 本願発明は，前記「第２　平成２８年２月５日付けの手続補正についての補正却下の決定」の「３　独立特許要件」で検討した本件補正発明の発明特定事項である「前記デバイス構成情報を受信することは，前記デバイスが生成した，前記デバイスの構成を示すSDPサービス応答を受信することを備え，前記SDPサービス応答は，前記デバイスによってサポートされているオーディオ復号器，復号器実行ファイルを受信するための能力，および前記デバイス構成情報を示す属性を含むSDPサービス記録を含み，前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」から「前記SDPサービス応答は，前記デバイスが，前記実行ファイルを受信し得，かつ様々なオーディオ符号化形式をサポートするように再構成され得ることを示す」との限定事項を削除したものである。 そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２８年２月５日付けの手続補正についての補正却下の決定」の「３　独立特許要件」の「（２）引用例」乃至「（４）当審の判断」に記載したとおり，引用発明及び引用例２乃至４に記載の当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。 第４　むすび 以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 よって，結論のとおり審決する。