【事件の表示】
　特願２０１２−５３３１２１「ネットワークにおける信頼性の高いリアルタイム・データストリーミングのための効率的なアプリケーションレイヤの自動再送要求の再送信方法」拒絶査定不服審判事件〔平成２３年　４月１４日国際公開，ＷＯ２０１１／０４３７５６，平成２５年　３月　４日国内公表，特表２０１３−５０７８２６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，２００９年１０月７日を国際出願日とする出願であって，平成２６年４月２１日付けで最後の拒絶理由が通知され，同年７月３０日付けで手続補正されたが，平成２７年１月１５日付けで補正の却下の決定がされるとともに同日付けで拒絶査定され，これに対し，同年５月１９日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされ，平成２８年１月２７日付けで当審から拒絶理由が通知され，同年４月２８日付けで手続補正がなされたものである。
　その請求項１に係る発明（以下，「本願発明」という。）は，平成２８年４月２８日付け手続補正書により補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。
「リアルタイム・データストリーミングのためにサーバを動作させる方法であって，
　送信されるデータをバッファに入れ，前記バッファは所定量のデータを保持し，前記バッファに入れられたデータは最近受信したデータであり，
　データグラムプロトコルを使用した第１のチャネルを介して，前記バッファから取得されたデータをクライアント装置にマルチキャストし，前記データグラムプロトコルは順序外れのパケットを検出する手段又は失われたパケットを回復する手段を提供しないプロトコルであり，
　送信制御プロトコルを使用した第２のチャネルを介して，前記クライアント装置から，破損した或いは失われたと前記クライアント装置により判定されたデータの再送信の要求を受信し，
　前記サーバにより，前記要求されたデータが前記バッファに存在するか否かを判定し，
　前記要求されたデータが前記バッファに存在すると判定された場合，エラー回復及びデータのエンド・ツー・エンドの受信確認を提供する前記送信制御プロトコルを使用した前記第２のチャネルを介して，前記要求されたデータを前記クライアント装置にユニキャストすることを有する方法。」
２　引用発明及び周知技術
［引用発明］
　当審から通知した拒絶の理由に引用された特表２００９−５２１８８１号公報（以下，「引用例」という。）には，「ネットワーク環境におけるメディアデータ転送」に関し，図面とともに以下の事項が記載されている。
（１）「【請求項８】
　１組のシンク装置における１つのシンク装置にてデータをソース装置から受信する方法であって，
　（ａ）音声データを含む順番に並べられた一連のパケットを前記ソース装置がブロードキャストした結果として，複数のパケットを前記シンク装置にて受信するステップと，
　（ｂ）前記受信された複数のパケットを収集し，前記一連のパケットが受信されなかったかどうかを確認するステップと，
　（ｃ）受信されなかったことが確認されたパケットに関して，前記ソース装置に，前記受信されなかったパケットを伝送するように要求するステップと，
　（ｄ）前記ソース装置が前記受信されなかったパケットを伝送した結果として，前記受信されなかったパケットを受信するステップとを含む，前記方法。
【請求項９】
　ワイヤレスネットワーク環境において，パケットデータを伝送するソース装置にて前記ソース装置から１組のシンク装置にパケットデータを伝送する方法であって，
　（ａ）パケットデータを前記シンク装置に，前記シンク装置のいずれもが，前記シンク装置から受信したパケットデータを収集し，損失されたいずれのパケットをも特定し，且つ，損失パケットを検出したときに，前記ソース装置による前記損失パケットの伝送を要求することができるようにブロードキャストするステップと，
　（ｂ）特定のシンク装置からの１つ以上の要求を，１つ以上の損失データパケットを送信するために受信するステップと，
　（ｃ）前記１つ以上の損失データパケットを前記特定のシンク装置に送信するステップとを含む，前記方法。
【請求項１０】
　前記ステップ（ａ）が，さらに，ユーザ・データグラム・プロトコル伝送を用いて，最初にパケットを前記シンク装置にブロードキャストするステップを含む請求項９に記載の方法。
【請求項１１】
　ステップ（ｂ）にて受信される要求が，前記特定のシンク装置が，前記１つ以上の損失パケットの伝送を要求するために前記ソース装置との伝送制御プロトコル（ＴＣＰ）相互接続をセットアップした結果により行われる請求項９に記載の方法。」（２〜３ページ）
（２）「【００１３】
　ここで，本発明の好ましい形態を，添付図面を参照しつつ説明する。
　上記の特許出願と同様に，本発明の実施形態は，デジタルメディアストリームをネットワーク環境にて再生することに向けられている。デジタルメディアは，例えば家庭内で，標準ＴＣＰ／ＩＰ ８０２．１１ａ／ｂ／ｇワイヤレスネットワークを通じて送信される。もちろん，他の実施形態は別のワイヤレスネットワークを用いることができる。
【００１４】
　データストリーミングのための配置を，図１に示した配置にすることができる。この配置において，リスナ１が，１組の，スピーカの音声放出を制御するユニット(speaker emission control unit)２〜６により取り囲まれている。このスピーカ音声放出制御ユニットの各々が，適切なチャンネルで音声放出するためのスピーカ（例えば７），及び，処理ユニット（例えば８）を含み，処理ユニット８は，ワイヤレスパケット伝送を８０２．１１ネットワークにて受信し，これらのパケットを，出力するために処理する。
【００１５】
　処理ユニット８は，多機能オペレーションを提供することができ，ハイエンドオペレーティングシステム（例えば，リナックス(Linux)オペレーティングシステム）を作動させるＣＰＵユニット（メモリを含む），パケットワイヤレス伝送を実行するための８０２．１１チップセット，及び，様々なＦＰＧＡ等を含むことができ，これにより完全な機能を実行することができる。
【００１６】
　マルチチャンネル音声再生に関して，解決されるべき主な問題は，データを，ノードの１つ（例えば５）を含むことができるソースから複数のデータシンクへ，利用可能なネットワーク帯域幅の限度内にデータを維持した状態で転送することである。従って，ノード５は，データをその他のスピーカコントロールユニット２〜４及びユニット６にワイヤレスネットワークを通じて伝送するためのソースとして機能する。
【００１７】
　一実施形態において，ワイヤレス伝送は，ブロードキャストパケットが送信されることを可能にするユーザ・データグラム・プロトコル（ＵＤＰ）を用いて実行される。これは，ノード５が複数のパケットをネットワークを通じて１回送信することができ，これらのパケットがシンク装置２〜４及びシンク装置６の各々により同時に受信されることを意味する。不都合なことに，ＵＤＰは，受信のための信頼性機構を何も有さない。一実施形態において，ＵＤＰは，データをブロードキャストモードで伝送するためだけに用いられる。
【００１８】
　一実施形態において，データ伝送は，ユニバーサル・プラグアンド・プレイ(Universal Plug and Play)（ＵＰｎＰ）メディア規格に従う。ユニバーサル・プラグアンド・プレイ（ＵＰｎＰ）は，メディアレンダラ，メディアサーバ，及びコントロールポイントから成るメディアシステムを画成している。メディアレンダラは，メディアを物理的に再生する機能を果たす端末装置（例えば２〜６）である。メディアサーバはメディアファイルを収容し，また，レンダラがこれらのファイルにアクセスするためのインタフェースをもたらす。コントロールポイントは，任意の所与のメディアサーバから任意の所与のメディアレンダラへの音楽の再生をユーザが制御することを可能にする。図５を参照すると，音声ストリームをレンダリング（再生）するための配置が，ＵＰｎＰサーバ装置５１を含む。サーバ装置５１は，スピーカユニットの１つ（例えば５０）により実現されるレンダリング装置に音声を供給する。ＵＰｎＰ規格に従えば，通信は，通常，ＨＴＴＰプロトコルを介して実行される。そして，スピーカ装置５１は，付属装置の各々に，音声ストリームをＵＤＰプロトコルに従って提供する。
【００１９】
　図１を再び参照すると，装置２〜６の群は，通常，主要レンダラ（renderer）（例えば要素５）を用い，このレンダラは，その群における他の装置の全てを制御する。この主要レンダラ装置は，標準ＵＰｎＰメディアＡＶトランスポートサービスを提供する。このサービスは，ＵＰｎＰコントロールポイントにより制御されることができ，要求されるメディアファイルを設定して再生し，コマンド，例えば，再生，一時停止，停止等を実行する。
【００２０】
　ＵＰｎＰメディアサーバは，主に，メディアファイルをレンダラに，ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）を用いて供給する。コントロールポイントは，メディアサーバにより提供されたファイル全体をブラウジング又はサーチして，メディアレンダラに，所与のファイルの転送をセットアップするように指示することができる。一実施形態において，主要なメディアレンダラは，コントロールポイントから送られる適切なＵＰｎＰコマンドに応答して，ＵＰｎＰメディアサーバとの接続を開始し，そして，音声データファイルのＨＴＴＰを介したダウンロードを開始する。
【００２１】
　音声パケットは，ＵＤＰプロトコルに従って伝送される。このプロトコル下で，音声データは一定のサイズのパケットに分割され，またパケットヘッダが付加される。
【００２２】
　図２は，一実施形態に従うパケット２０全体のパケットヘッダ２１及びパケット本体２２を示す。図３は，図２のデータパケットのさらなる詳細を示す。パケット２０は，ネットワークを通じて同期装置(sync device)の各々に，ＵＤＰプロトコルを用いてブロードキャストされる。
【００２３】
　ブロードキャストＵＤＰパケットを用いることにより，全てのパケットを装置群に個々に送信することによる帯域幅オーバーヘッドをなくすことができる。各装置は，ブロードキャストされたこれらのパケットを受信し，そして，これらのパケットをデータのコヒーレントストリームに再構成する。
【００２４】
　先に論じたように，ワイヤレスネットワークキングの性質により，このＵＤＰブロードキャストプロセスを介して受信されるときまでに，パケットは，時々，歪み又は他の理由で失われることがある。パケットが損失を受けた場合にもデータストリームを継続できることを保証するために，再伝送スキームが開発されてきた。
【００２５】
　ＵＤＰパケット２０の各々は，固有のシーケンス番号を有し，この番号はデータストリームに再構成されるために必要とされる順番を示す。これらのシーケンス番号は，先に記載したように，パケットヘッダにてデータに付加される。シンク装置は，各ＵＤＰパケットを順番に受信することが想定され，従って，シンク装置は，ストリーム中の損失されたパケットのいずれをも，予測される次のパケットのシーケンス番号を，今回受信したばかりのパケットのシーケンス番号と比較することにより容易に検出することができる。
【００２６】
　図４は，損失を受けたパケットを処理するための，本発明の実施形態にて用いられるデータパケット伝送プロトコルを示す。１つの装置が，幾つかのパケットが損失を受けたと決定したならば，この装置はこれらのパケットが主要レンダラから再伝送されることを要求する。装置群中の各装置は，ＵＤＰブロードキャストをリッスン（監視）することに加え，損失パケットの再伝送を要求するために，主要メディアレンダラとの伝送制御プロトコル（ＴＣＰ）接続を起動時に開く。再伝送の要求は，再伝送コマンドコード及び必要なパケット番号を含むプロトコルを用いて行われる。」（５〜７ページ）
（３）「【００３０】
バッファ状態フィードバック
　バッファに保存されている十分なデータが常に存在することを保証するために，また，損失パケットの再伝送を可能にするために，データは再生速度よりもかなり速い速度で送信され得る。従って，各シンク装置は，このバッファのオーバーフローを防止するためのバッファ状態フィードバック機構を実行する。先に記載したものと同一のＴＣＰ接続を用いて，各スピーカは，音声データバッファのサイズに関する情報を主要装置に周期的に与える。シンクスレーブバッファのいずれかが，許容可能なカットオフレベルよりも大きいことが通知されたならば，主要ソース装置が，ＵＤＰブロードキャスト速度を，通知されたバッファサイズが減少するまで低下させる。
【００３１】
　別の装置により再伝送が要求された場合にパケットの履歴を保持しなければならない主要装置でのバッファオーバフローを防止するために，アクノリッジ（確認）(acknowledgement)システムが用いられる。各装置は，所定の個数のパケットの受信に成功した後，「アクノリッジ」パケットを送り返す。これは共通のチェックポイントとして機能する。すなわち，主要装置がアクノリッジを，接続された全ての装置から所定レベルに達するまで受信したならば，主要装置は，確認が最下位の(the lowest)パケットより以前のパケットも破棄することができる。なぜなら，その他の装置の全てが，このパケットまでのデータの受信に成功したことを通知しているからである。この機構は，主要装置がメモリ使用量を許容可能な程度に小さくしておくことを可能にする。」（７〜８ページ）
　上記（１）〜（３）の記載及び図面並びに当業者の技術常識を考慮すると，
ａ　上記（２）の【００１３】，【００１４】，【００１８】の記載によれば，引用例は音声ストリーム等のデータストリーミングについて記載されているといえる。そして，上記（１）及び上記（２）の【００１４】，【００１６】〜【００２０】の記載及び図１，図５によれば，スピーカの音声放出を制御する複数のスピーカ音声放出制御ユニット２〜６の各々がスピーカ７及び処理ユニット８を含み，このうち主要レンダラとされる１つのスピーカ音声放出制御ユニット５（ソース装置）は，データをその他のスピーカコントロールユニット２〜４及び６（シンク装置２〜４及びシンク装置６）にワイヤレスネットワークを通じて伝送するためのソースとして機能し，他の装置（２〜４及び６）を制御するものである。そして，当該ソース装置（主要レンダラ（要素５），スピーカ音声放出制御ユニット５，スピーカユニット５０（スピーカＡ））から他のスピーカコントロールユニット２〜４及び６（スピーカＢ〜Ｅ）へのワイヤレス伝送は，ブロードキャストパケットが送信されることを可能にするユーザ・データグラム・プロトコル（ＵＤＰ）を用いて実行されるものである。そして，当該ソース装置には，ＵＰｎＰサーバ装置５１よりＨＴＴＰプロトコルを介して実行される通信により音声が供給されるものである。
　したがって，引用例には，「音声ストリームのデータストリーミングのための方法であって，ソース装置は，ユーザ・データグラム・プロトコル（ＵＤＰ）を用いてデータを複数のシンク装置にブロードキャストする」ことが記載されていると認められる。
ｂ　上記（１），上記（２）の【００２４】〜【００２６】の記載及び図４によれば，各シンク装置は，ＵＤＰブロードキャストをリッスン（監視）して，予測される次のパケットのシーケンス番号を今回受信したばかりのパケットのシーケンス番号と比較することにより，ストリーム中の損失されたパケットを検出し，損失パケットの再伝送を要求するために主要メディアレンダラとの伝送制御プロトコル（ＴＣＰ）接続を開き，再伝送を要求するものであり，「ＴＣＰ損失パケット要求」はＴＣＰ接続を用いて送信されるものと解される。そして，当該要求を受けたソース装置は，要求された損失データパケットを特定のシンク装置に「ＴＣＰ損失パケット伝送」するものであり，当該伝送もＴＣＰ接続を用いて送信されるものと解される。
　ここで，図４では，「ＴＣＰ損失パケット要求」の矢印はソースからシンクに向かい，「ＴＣＰ損失パケット伝送」の矢印はシンクからソースに向かっているが，【００２５】，【００２６】の記載，及び損失パケットの再送要求がパケットの送信先から送信元に対して行われ，当該再送要求に応答して行われる損失パケットの再送がパケットの送信元から送信先に対して行われることが技術常識であることから，これらの矢印はそれぞれ，シンクからソースへの向き，及びソースからシンクへの向きの誤記であることは明らかである。
　また，上記（１）の請求項９の記載によれば，特定のシンク装置からの１つ以上の要求に対して，１つ以上の損失データパケットを当該特定のシンク装置に送信するのであるから，「ＴＣＰ損失パケット伝送」はユニキャストであるといえる。
　したがって，引用例には，「ＴＣＰ接続を用いて，前記シンク装置から，損失したと前記シンク装置により検出された損失パケットの再送信の要求を受信し，前記ソース装置により，ＴＣＰ接続を用いて，前記要求されたデータを前記シンク装置にユニキャストする」ことが記載されていると認められる。
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認める。
「音声ストリームのデータストリーミングのための方法であって，
　ソース装置は，ユーザ・データグラム・プロトコル（ＵＤＰ）を用いてデータを複数のシンク装置にブロードキャストし，
　ＴＣＰ接続を用いて，前記シンク装置から，損失したと前記シンク装置により検出された損失パケットの再送信の要求を受信し，
　前記ソース装置により，ＴＣＰ接続を用いて，前記要求されたデータを前記シンク装置にユニキャストする，方法。」
［周知技術］
　同じく当審から通知した拒絶の理由に引用された特表２００７−５３６７９６号公報（以下，「周知例１」という。）には，「メディアをストリーミングするための高速起動」に関し，図面とともに以下の事項が記載されている。
（４）「【００５７】
　図２に戻ると，本明細書で説明した高速起動は，ストリーミング中に１つ以上の配信チャネルを切り換えるプロセスも含む。転送プロトコル１５２は，様々な異なる配信チャネルを使用することができる。通常，各メディアストリームがサーバ装置１０４から，別の配信チャネルを使用するクライアント装置１０２に送信される。様々なメディアストリームのこれらの配信チャネルは，通常は同じタイプだが，異なるタイプであってもよい。
配信チャネルの２つの共通タイプは，ＴＣＰチャネルとＵＤＰチャネルである。ＴＣＰチャネルはＴＣＰパケットと呼ばれるパケットでデータを送信するが，ＵＤＰチャネルはＵＤＰパケットと呼ばれるパケットでデータを送信する。
　同じく当審から通知した拒絶の理由に引用された特表２００４−５０５３６３号公報（以下，「周知例２」という。）には，「ビデオ・メッセージング」に関し，図面とともに以下の事項が記載されている。
（５）「【請求項１８】
前記ビデオ・チャネルが
ＵＤＰチャネル
【請求項１９】
前記ビデオ・チャネルが
ＴＣＰチャネル
（６）「【００８４】
ビデオチャネルはビデオ・パケットの移送に利用されるＴＣＰ／ＩＰソケットである。
このチャネルはＵＤＰでもＴＣＰでもよい。
　同じく当審から通知した拒絶の理由に引用されたRealNetworks，Chapter 8: Multicasting（［当審仮訳］：第８章　マルチキャスティング），INTERNET DOCUMENT，インターネット＜URL:https://service.real.com/help/library/guides/helixuniversalproxy/htmfiles/multicst.htm＞，２００２年（以下，「周知例３」という。）には，図面とともに以下の事項が記載されている。
（７）「Chapter 8: Multicasting
（中略）
Protocols Used for Multicasting
　　Multicasting uses the application-layer protocol RTSP to both send control information over a TCP channel to each client and to multicast live broadcast data to all client over UDP channel (or a TCP channel if UDP is unavailable.) 」（２／５ページ）
（［当審仮訳］：
第８章　マルチキャスティング
　マルチキャスティングは，
ＴＣＰチャネルを介した各クライアントへの制御情報の送信
ＵＤＰチャネル（又は，ＵＤＰが利用可能でないならばＴＣＰチャネル）を介した
　上記（４）〜（７）の記載によれば，「ＵＤＰプロトコルを用いたパケットの送受信をＵＤＰチャネルで，ＴＣＰプロトコルを用いたパケットの送受信をＴＣＰチャネルで，それぞれ行うこと。」は，技術常識ともいえる周知事項である（以下，「周知技術」という。）。
３　対比・判断
　本願発明と引用発明とを対比すると，
（１）引用発明の「音声ストリームのデータストリーミング」は，「リアルタイム・データストリーミング」といえる。
　本願発明の「マルチキャスト」と引用発明の「ブロードキャスト」は，複数の装置に同時に送信するものである点で共通している。
（２）本願明細書の【０００２】，【００１７】等によれば，本願発明の「サーバ」は，送信されるデータをローカルファイルから，又は例えばコンテンツサーバ又はコンテンツ配信システムと通信している他のネットワークインタフェースモジュールから受信し，当該受信した同じデータを有線及び／又は無線ネットワークで複数の受信機（クライアント装置）に同時に送信するものである。一方，引用発明の「ソース装置」も，ＵＰｎＰサーバ装置５１よりＨＴＴＰプロトコルを介して実行される通信により音声が供給され，供給された音声に係る音声ストリームをワイヤレス伝送で複数のシンク装置にブロードキャストするものである。したがって，引用発明の「ソース装置」，「シンク装置」は，それぞれ本願発明の「サーバ」，「クライアント装置」に対応する。
　また，引用発明は「ソース装置」の動作を規定しているから，これを「サーバを動作させる方法」と称することは任意である。
（３）引用発明の「ユーザ・データグラム・プロトコル（ＵＤＰ）」は「データグラムプロトコル」といえ，引用例の【００１７】に記載のとおり，受信のための信頼性機構を何も有さないものであって，「前記データグラムプロトコルは順序外れのパケットを検出する手段又は失われたパケットを回復する手段を提供しないプロトコル」といえることは当業者に自明である。また，本願明細書には，本願発明の「順序外れのパケットを検出する手段又は失われたパケットを回復する手段を提供しないプロトコル」である「データグラムプロトコル」として，「UDP」が示されている。
　したがって，両者は，「データグラムプロトコルを使用して，データを複数のクライアント装置に同時に送信し，前記データグラムプロトコルは順序外れのパケットを検出する手段又は失われたパケットを回復する手段を提供しないプロトコルであり」の点で共通している。
（４）引用発明の「ＴＣＰ接続」の「ＴＣＰ」は，「ＴＣＰ（伝送制御プロトコル）」であり，「送信制御プロトコル」といえる。また，本願明細書には，本願発明の「エラー回復及びデータのエンド・ツー・エンドの受信確認を提供する」「送信制御プロトコル」として，「TCP」が示されているから，両者の「送信制御プロトコル」は共通といえる。
　また，引用発明の「損失したと前記シンク装置により検出された損失パケット」は，「破損した或いは失われたと前記クライアント装置により判定されたデータ」に含まれる。
　したがって，両者は，「送信制御プロトコルを使用して，前記クライアント装置から，破損した或いは失われたと前記クライアント装置により判定されたデータの再送信の要求を受信し」，「エラー回復及びデータのエンド・ツー・エンドの受信確認を提供する前記送信制御プロトコルを使用して，前記要求されたデータを前記クライアント装置にユニキャストする」点で共通している。
　以上を総合すると，本願発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「リアルタイム・データストリーミングのためにサーバを動作させる方法であって，
　データグラムプロトコルを使用して，データを複数のクライアント装置に同時に送信し，前記データグラムプロトコルは順序外れのパケットを検出する手段又は失われたパケットを回復する手段を提供しないプロトコルであり，
　送信制御プロトコルを使用して，前記クライアント装置から，破損した或いは失われたと前記クライアント装置により判定されたデータの再送信の要求を受信し，
　エラー回復及びデータのエンド・ツー・エンドの受信確認を提供する前記送信制御プロトコルを使用して，前記要求されたデータを前記クライアント装置にユニキャストすることを有する方法。」
（相違点１）
　一致点の「データを複数のクライアント装置に同時に送信し」に関し，本願発明は「データをクライアント装置にマルチキャスト」するのに対し，引用発明は「データをクライアント装置にブロードキャスト」する点。
（相違点２）
　本願発明は「送信されるデータをバッファに入れ，前記バッファは所定量のデータを保持し，前記バッファに入れられたデータは最近受信したデータであり」との構成を有しており，これに伴い，複数のクライアント装置に同時に送信するデータは「前記バッファから取得されたデータ」であり，再送信がなされるのは「前記サーバにより，前記要求されたデータが前記バッファに存在するか否かを判定し，前記要求されたデータが前記バッファに存在すると判定された場合」であるのに対し，引用発明はこれらの事項が明らかでない点。
（相違点３）
　一致点の「データグラムプロトコルを使用して・・・送信し」，「送信制御プロトコルを使用して，・・・受信し」及び「・・・前記送信制御プロトコルを使用して，・・・ユニキャストする」に関し，本願発明はそれぞれ「データグラムプロトコルを使用した第１のチャネルを介して・・・送信し」，「送信制御プロトコルを使用した第２のチャネルを介して・・・受信し」及び「・・・前記送信制御プロトコルを使用した前記第２のチャネルを介して，・・・ユニキャストする」のに対し，引用発明はチャネルについて明らかでない点。
　以下，各相違点について検討する。
（相違点１について）
　複数の装置に対するデータ（パケット）の送信方法として，ブロードキャスト及びマルチキャストはいずれも周知慣用のものであるから，引用発明におけるブロードキャストに替えてマルチキャストを採用することは，適宜なし得ることに過ぎない。
（相違点２について）
　引用例の【００３０】，【００３１】（上記２（３）参照。）の記載によれば，引用発明の各シンク装置及びソース装置もバッファを備えていると解するのが自然であり，また，再送技術の分野においては，送信側が再送信の要求に備えて，受信側に送信するデータをバッファに格納しておくこと，及び再送信の要求を受信した場合には，要求されたデータを前記バッファから取り出すために，当該要求されたデータが前記バッファの存在を判定することは，いずれも一般的に行われていることに過ぎない技術常識ともいえる事項である。
　そして，バッファが所定量のデータを保持するものであることは当然であり，また，ストリーミングであることに鑑みれば，バッファに入れられたデータは最近受信したデータであることも普通に考えられることにすぎない。　してみれば，相違点２は格別困難なことではなく，当業者が容易になし得ることに過ぎない。
（相違点３について）
　本願の請求項１の文言から明らかなように，本願発明の「第１のチャネル」は「データグラムプロトコルを使用した」ことにより規定されるものであり，「第２のチャネル」は「送信制御プロトコルを使用した」ことにより規定されるものである。
　そして，送受信はチャネルを介して行われるところ，「２　引用発明及び周知技術」の項の［周知技術］で認定したように，「ＵＤＰプロトコルを用いたパケットの送受信をＵＤＰチャネルで，ＴＣＰプロトコルを用いたパケットの送受信をＴＣＰチャネルで，それぞれ行うこと。」は技術常識ともいえる周知事項であることに鑑みれば，引用発明おける「ユーザ・データグラム・プロトコル（ＵＤＰ）を用いてデータを複数のシンク装置にブロードキャスト」するチャネルを「第１のチャネル」と称し，「ＴＣＰ接続を用いて」「受信」及び「ユニキャスト」するチャネルを「第２のチャネル」と称することは任意である。
　したがって，相違点３には実質的な相違は無い。
　本願発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測できる範囲のものである。
［請求人の主張について］
　請求人は平成２８年４月２８日付け意見書にて，(i) 「引用文献１には，スピーカ装置５０がサーバ装置から音声を受信しますが，この送信がユニキャストであるかマルチキャストであるかは記載されていません。１つのみのスピーカ装置５０が示されているため，ユニキャストであると想定されます。」，(ii)「また，スピーカ装置５０から更なるスピーカへの送信はＵＤＰプロトコルが使用され，再送信にはＴＣＰプロトコルが使用されます。しかし，ＵＤＰプロトコルを使用した送信と，ＴＣＰプロトコルを使用した再送信は，別々のチャネルで行われることを意味するとは限りません。引用文献１には，２つのチャネルが用いられることは記載も示唆もされていません。」，(iii) 「また，引用文献１には，もとのパケットの冗長伝送（時間を遅らせたパケット）がＵＤＰで行われます。これに加えて，アクノリッジパケットと，ＴＣＰ再送信要求と，ＴＣＰ再送信が同じ単一のチャネルで行われることになります。この単一のチャネルの状態が良好でない場合，更なる再送信が必要となります。」と主張している。
　しかしながら，引用発明のソース装置（スピーカ装置５０（スピーカＡ））が本願発明の「サーバ」に対応するものであり，引用例のスピーカ装置５０がＵＰｎＰメディアサーバ５１からＨＴＴＰプロトコルを介して実行される通信により音声を受信することは，本願明細書（【００１７】）でいう「送信機（サーバ）は，送信されるデータをローカルファイル（図示せず）から，又は例えばコンテンツサーバ又はコンテンツ配信システム（図示せず）と通信している他のネットワークインタフェースモジュール（図示せず）から受信する。」ことに相当するものである。そして，本願発明は，サーバにおける受信については「送信されるデータをバッファに入れ，前記バッファは所定量のデータを保持し，前記バッファに入れられたデータは最近受信したデータであり」と規定するのみであるから，引用例のＵＰｎＰメディアサーバ５１からスピーカ装置５０への通信がユニキャストであるかマルチキャストであるかは，本願発明の構成とは無関係の事項である。したがって，上記(i) の主張は採用できない。
　また，上記「（相違点３について）」のとおり，本願発明の「第１のチャネル」は「データグラムプロトコルを使用した」ことにより規定されるものであり，「第２のチャネル」は「送信制御プロトコルを使用した」ことにより規定されるものであるであるから，上記(ii)の主張は採用できない。
　更に，上記(iii)の「この単一のチャネルの状態が良好でない場合，更なる再送信が必要となります。」との主張は，本願明細書の【０００４】の「通常，無線ネットワークでのビデオ送信又は配信は，干渉，チャネルフェージング，衝突等のようなチャネルエラー状態により生じるパケットロスを含む。このようなチャネルエラー状態が生じると，プロトコルスタックの無線リンクレイヤは，固定の期間内に固定回数だけパケットを再送信することを試みる。」に基づくものと推察されるが，当該「干渉，チャネルフェージング，衝突等のようなチャネルエラー状態」は物理チャネルに係るものと解される。しかしながら，本願発明の「第１のチャネル」は「データグラムプロトコルを使用した」ことにより規定され，同「第２のチャネル」は「送信制御プロトコルを使用した」ことにより規定されるものであって，本願明細書にはこれらのチャネルが物理チャネルとして別々のチャネルなのか単一のチャネルなのかは明らかにしていない。したがって，上記(iii) の主張は，本願の特許請求の範囲及び発明の詳細な説明の記載に基づかないものであるから，採用できない。
４　むすび
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。