【事件の表示】
　特願２０１１−１７１３０２「アニメーション再生システム，サーバ装置，端末装置，再生方法，情報処理方法及びプログラム」拒絶査定不服審判事件〔平成２５年　２月２１日出願公開、特開２０１３−　３７４４７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯
　本願は，平成２３年８月４日の出願であって，その手続の経緯は，以下のとおりである。
　平成２５年　９月２６日　　：手続補正
　平成２６年　７月　７日付け：拒絶理由の通知
　平成２６年　９月１１日　　：手続補正
　平成２６年１０月１７日付け：拒絶査定
　平成２６年１０月２１日　　：拒絶査定の謄本の送達
　平成２７年　１月１６日　　：拒絶査定不服審判の請求
　平成２７年１１月１０日付け：拒絶理由の通知（当審）
　平成２７年１２月２２日　　：手続補正
２　本願発明
　特許請求の範囲の請求項１に係る発明（以下「本願発明」という。）は，平成２７年１２月２２日付け手続補正書により補正された明細書，特許請求の範囲及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　なお，下記のとおり，説明のために（Ａ）から（Ｄ）までの記号を当審において付与した。以下，構成要件Ａ，構成要件Ｂなどと称することとする。
「【請求項１】
（Ａ）　サーバ装置と端末装置とがネットワークを介して通信可能に接続されたアニメーション再生システムであって，
（Ｂ）　前記サーバ装置は，
（Ｂ−１）　前記端末装置にアニメーションＧＩＦファイルを再生するための再生プログラムを送信し，
（Ｂ−２）　前記端末装置より前記アニメーションＧＩＦファイルを指定する情報を含む要求を受信すると，前記アニメーションＧＩＦファイルに対応する，前記再生プログラムにより扱うことが可能な文字列により構成される文字列ファイルを前記端末装置に送信し，
（Ｃ）　前記端末装置は，
（Ｃ−１）　前記再生プログラムが無い場合，前記アニメーションＧＩＦファイルを再生不可能であり，
（Ｃ−２）　前記アニメーションＧＩＦファイルを再生する場合，前記要求を前記サーバ装置に送信し，
（Ｃ−３）前記サーバ装置より前記文字列ファイルを受信すると，前記再生プログラムにより，前記文字列ファイルを解釈し，解釈した結果に基づき複数の画像ファイルを生成し，前記複数の画像ファイルを再生する
（Ｄ）アニメーション再生システム。」
３　引用発明及び周知技術
（１）引用例１の記載事項及び引用発明１
（１−１）引用例１の記載事項
　当審の平成２７年１１月１０日付けの拒絶理由に引用された，特表２００８−５１３８９７号公報（以下「引用例１」という。）には，「モバイルメッセージングシステムおよび方法」として，図面とともに以下の事項が記載されている。
ア　「【０００３】
  従来，モバイル装置を用いてマルチメディア（たとえばテキスト，画像，ビデオ，および音声）をメッセージングすることは扱いにくく，多くの場合は不可能である。たとえば，ショートメッセージサービス（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）（ＳＭＳ）は，１６０文字以内のテキストメッセージの送信に限定される。マルチメディアメッセージングサービス（Ｍｕｌｔｉｍｅｄｉａ  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ）（ＭＭＳ）はテキストならびに他のメディアの送信を可能にする一方で，ＭＭＳは，メッセージが受信者に配信された後における送信者および受信者からの遠隔によるメッセージの格納である持続性に欠けている。特に，メッセージがＭＭＳを介して配信された後，配信を担うサーバは，たとえばマルチメディアコンテンツの後日の参照または再利用のためのメッセージのコピーを保持しない。結果的に，モバイルユーザがＭＭＳの使用を通して進行中の方法で互いに共働する能力は，著しく限定される。さらに，インターネットプロトコル（ＩＰ）チャネルを介して（たとえばＩＰマルチメディアサブシステム（ＩＭＳ）を介して，またはモバイル装置上で稼動するブラウザを通して）モバイル装置にマルチメディアを配信するための従来のアプローチは，配信時間およびネットワーキング信頼性の両方について大いに改善されることができる。」
イ　「【００２２】
  本発明の実施形態は，ユーザがモバイル装置，デスクトップ装置，セットトップ装置または他の装置からメッセージを送るかにかかわらず，エンドユーザにシームレスな経験を提供する，装置およびネットワークにとらわれないマルチメディアメッセージング環境に関する。この環境の範囲内において，たとえばウェブ（ＨＴＴＰ），ＳＭＴＰ／ＰＯＰ／ＩＭＡＰ，ＳＩＰ，ＣＤＭＡおよびＧＳＭ（ＧＰＲＳ，ＥＤＧＥ）などの異なるネットワークおよび／またはプロトコルにわたって，装置は互いにメッセージを送ることができる。
【００２３】
  図１は，サーバ１０２（それぞれが一つ以上のサーバインタフェース１０４およびメモリ１０６を備えている），たとえば携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｔ）などの一つ以上のモバイル装置，および／またはデスクトップコンピュータなどの一つ以上の非モバイル装置などのユーザ機器１０８を含むシステム１００の実施形態を示す。システム１００はさらに，ゲートウェイ１１０と，レンダリングエンジン１１２と，ＨＴＴＰ／ｅメールサービス１１４と，ロードバランサー１１６と，サードパーティゲートウェイ１１８とを備える。たとえば，本発明の実施形態は，モバイル装置または非モバイル装置のユーザが，モバイルユーザの起動状況（たとえばオンライン，オフライン，使用中，不在，タイプ中，アイドルなど）を決定するためにモバイルユーザについての存在情報を見ることと，モバイルユーザをテキスト，画像，音声，ビデオなどの複数メディアに関連するコミュニケーションに携わらせることとを可能にし得る。ユーザ機器１０８（および随意にメッセージに関連したメタ情報）の間で通信されるメッセージは，たとえば将来のメッセージにおけるマルチメディアコンテンツの後日の参照および／または再利用のために，メモリ１０６におけるドキュメント（またはドキュメントの部分）としてサーバ１０４によって持続される（格納される）。システム１００におけるドキュメントがｎｍｌベースのドキュメントである場合，システム１００は，そのさまざまな構成要素において，「ネトマット（ｎｅｔｏｍａｔ）」変更子を用いてラベルされ得る（たとえばネトマットサーバ１０２）。
【００２４】
  モバイル装置および非モバイル装置は，クライアントアプローチまたはクライアントレス（ｃｌｉｅｎｔｌｅｓｓ）アプローチを用いることによって，システム１００にネットワーク接続され得る。（後略）」
ウ　「【００６９】
  （インライン圧縮ＡＳＣＩＩ符号化バイナリーアセット）
  モバイルネットワークが拡大するにつれて，小さな画面によって特徴づけられ，信頼性のないネットワーク接続性および低い帯域幅になりやすい装置に対して，フォーマットされたマルチメディアプレゼンテーションを配信する，より速く，より効率的で，ユーザフレンドリな方法に対するニーズも拡大する。モバイルおよび固定ネットワークにわたるメッセージにおいてマルチメディアを交換する既存の方法は，本発明と比較すると，指数関数的に高い数のクライアント／サーバの呼び出し／応答を必要とする。したがって，ネットワークにより高い要求を課し，送信セッションをネットワーク障害にさらし，ユーザをより長い待ち時間にさらす。
【００７０】
  電話ブラウザ（ｐｈｏｎｅ  ｂｒｏｗｓｅｒ）などの従来のモバイルアプリケーションは，画像を含むＨＴＭＬまたはＸＨＴＭＬなどのマルチメディアファイルをロードするために以下のステップを必要とする。最初に，ＨＴＭＬファイルについてのユーザからのリクエストに応じて，ＨＴＭＬファイルがロードされなければならない。次に，ＨＴＭＬファイルにおける各埋め込み画像がロードされなければならない。ここで，各埋め込み画像は別々のユーザリクエストを必要とする。ＭＭＳおよび他のメッセージングシステムによって同様の戦略が採用される。一つ以上の呼び出しがサーバによって受信されないことに起因して，またはモバイル装置によって受信されたコンテンツにおける送信エラーに起因して，情報についての複数の呼び出しが結果としてエラーになり得る。
【００７１】
  一実施形態において，従来のシステムとは異なり，システム１００は，複数の呼び出しを排除し，メッセージサイズを低減することによって，マルチメディアコンテンツをモバイル装置１０８に効率的に配信する。特に，モバイル装置１０８からの単一の呼び出しは，サーバ１０２に，ＡＳＣＩＩ符号化されたおよび圧縮された（たとえばサーバ１０２によって圧縮され符号化された）マルチメディアアセットを含むｎｍｌファイルを送信させる。圧縮されると，ＡＳＣＩＩ符号化されて圧縮されたファイルは１２パーセント〜３０パーセント小さい。すべてのＴＣＰ／ＩＰ接続のために必要とされるオーバヘッドを低減することにより（すなわち呼び出し／応答の数を低減させることにより），追加の１０パーセントの利点が達成される。一つのメッセージに複数のアセットを含むメッセージを配信する能力は，結果としてより速い配信になり，著しく改善されたユーザ経験を実現させる。システム１００はモバイル環境に比類なく適切である。システム１００は，サーバが応答しなければならない呼び出しの回数を限定することによって，サーバ１０２の資源をも保護する。たとえば，図５はモバイル装置の表示画面のスクリーンショットであり，ここでは，サーバ１０２（図１）への単一の呼び出しに応答して，７つの画像５０２〜５１４（および関連テキスト）がモバイル装置に送信される。
【００７２】
  図６は，インライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとしての５つの画像（サイズは合計５０ｋ）を含むコンテンツを，マルチメディアクライアントアプリケーションがインストールされた（さらにメッセージがｎｍｌメッセージである）モバイル装置に配信するために必要とされる配信時間に対して，同じコンテンツを（ＡＳＣＩＩ符号化バイナリーアセットのインライン圧縮を用いない）モバイル装置のＨＴＭＬブラウザに送信するために必要とされる配信時間を示すグラフである。より詳しくは，２８．８ｋｂｐｓラインにわたる配信について，圧縮ＡＳＣＩＩ符号化バイナリーアセットは４８．４秒で配信されたのに対して，ＨＴＭＬブラウザへの同じコンテンツの送信は６６．５秒を必要とした。
【００７３】
  以下は，３つの画像を含むｎｍｌファイルについての説明的なコードを示す。この例において，インラインメッセージは，ＬＺ７７アルゴリズムおよびＨｕｆｆｍａｎ符号化の組み合わせを含む標準的なデータ圧縮アルゴリズムを用いて圧縮され，Ｂａｓｅ６４として符号化される。インライン画像（たとえば１２７２バイト）は，ＪＰＧ形式におけるもともとの画像（たとえば１５６４バイト）よりも小さい。
【００７４】
【化３】
【００７５】
【化４】
【００７６】
【化５】
【００７７】
【化６】
（後略）」
（１−２）引用発明１
　上記（１−１）の摘記事項アからウまでの記載及び関連する図面並びにこの分野における技術常識を考慮して引用例１の記載を検討する。
（ア）　上記イ及びウには，上記アの課題を解決するための，マルチメディアコンテンツをモバイル装置に配信するシステムにおいて，前記システムがサーバとモバイル装置とを含むこと，及び前記モバイル装置が前記システムにネットワーク接続されることについて記載されている。
　また，上記ウには，複数の画像を含むマルチメディアコンテンツがモバイル装置に送信されて表示される，すなわち，再生されることについて記載されている。
　以上の記載を踏まえれば，引用例１には，『サーバとモバイル装置とがネットワークを介して通信可能に接続され，前記モバイル装置において複数の画像を含んだマルチメディアコンテンツを再生するシステム』が記載されているといえる。
（イ）　上記ウには，ユーザリクエストとして，前記モバイル装置からの呼出しがなされると，前記複数の画像を含むマルチメディアコンテンツが前記モバイル装置に送信されることについて記載されている。
　また，上記ウには，前記サーバから前記モバイル装置に，前記マルチメディアコンテンツがＢａｓｅ６４に符号化された，上記ウに摘記した段落【００７４】から段落【００７７】までに示されているような，文字列のファイルを送信すること，及び複数の画像を含むマルチメディアコンテンツが前記モバイル装置に送信されて表示されることについて記載されている。
　以上の記載を踏まえれば，引用例１には，『前記サーバ』が，『前記モバイル装置から，前記複数の画像を含むマルチメディアコンテンツのリクエストがなされると，前記複数の画像を含むマルチメディアコンテンツに対応する，Ｂａｓｅ６４により符号化した文字列のファイルを，前記モバイル装置に送信』すること，及び『前記モバイル装置』が，『前記複数の画像を含むマルチメディアコンテンツを再生する場合，前記リクエストを前記サーバに対して行』うことについて記載されているといえる。
（ウ）　上記（イ）で検討したように，上記ウには，前記サーバから前記モバイル装置に，前記複数の画像を含むマルチメディアコンテンツに係る，上記ウに摘記した段落【００７４】から段落【００７７】までに示されているような，文字列のファイルが送信されることについて記載されている。
　また，上記（ア）で検討したように，上記ウには，複数の画像を含むマルチメディアコンテンツがモバイル装置に送信されて表示される，すなわち，再生されることについて記載されている。
　したがって，以上の記載・事項を踏まえれば，引用例１には，前記モバイル装置が，『前記サーバより前記文字列のファイルを受信し，前記複数の画像を再生する』ことについて記載されているといえる。
（エ）　上記（ア）で検討したように，上記ウには，マルチメディアコンテンツをモバイル装置に配信するシステムが記載されている。また，上記ウには，複数の画像を含むマルチメディアコンテンツがモバイル装置において表示される，すなわち再生されることについて記載されている。
　以上の記載を踏まえれば，引用例１には，『複数の画像を含んだマルチメディアコンテンツを再生するシステム』が記載されているといえる。
（オ）　まとめ
　以上によれば，引用例１には，次の発明（以下「引用発明１」という。）が開示されている。なお，引用発明に対し，下記のとおり，当審において，（ａ）から（ｄ）までの記号を説明のために付与した。以下，構成要件ａ，構成要件ｂなどと称することとする。
（引用発明１）
「（ａ）　サーバとモバイル装置とがネットワークを介して通信可能に接続され，前記モバイル装置において複数の画像を含んだマルチメディアコンテンツを再生するシステムであって，
（ｂ）　前記サーバは，
（ｂ−１）前記モバイル装置から，前記複数の画像を含むマルチメディアコンテンツのリクエストがなされると，前記複数の画像を含むマルチメディアコンテンツに対応する，Ｂａｓｅ６４により符号化した文字列のファイルを，前記モバイル装置に送信し，
（ｃ）前記モバイル装置は，
（ｃ−１）　前記複数の画像を含むマルチメディアコンテンツを再生する場合，前記リクエストを前記サーバに対して行い，
（ｃ−２）　前記サーバより前記文字列のファイルを受信し，前記複数の画像を再生する，
（ｄ）複数の画像を含んだマルチメディアコンテンツを再生するシステム。」
（２）引用例２，３の記載事項及び周知技術
（２−１）引用例２の記載事項
　当審の平成２７年１１月１０日付けの拒絶理由に引用された，特開２００４−１３９６０２号公報（以下「引用例２」という。）には，図面とともに以下の事項が記載されている。
ア　「【００３９】
　なお，本実施の形態においては，メールの本文に挿入するイラストを，テキストデータからなるものとして説明をおこなったが，これに限定するものではなく，ＪＰＥＧなどの静止画像データ，ＭＰＥＧやＡＶＩといった動画像データ，Ｍｏｔｉｏｎ−ＪＰＥＧやＧＩＦアニメーションなどの疑似静止画像データ，あるいはベクトル形式により作成されたデータをイラストとして挿入するようにしてもよい。この場合，イラスト挿入手段６は，イラストをＢＡＳＥ６４，ｕｕｅｎｃｏｄｅなどといった電子メールの添付ファイルで用いられるファイルエンコード方式によりエンコードするとともに，文書作成編集手段２は，文書をＨＴＭＬ形式として作成する。イラストは電子メールの添付ファイルとなるが，添付された画像の表示位置は，文書の本文中にＨＴＭＬで指定されており，メールの受信者は，メール作成画面２５上の指定された位置に，イラストが挿入された状態で文書を見ることができる。なお，ＨＴＭＬ形式でイラストの表示位置を指定する際には，カスケーディングスタイルシート（ＣＳＳ）と呼ばれる記述方法を用いてもよい。（後略）」
イ　「【００４５】
　なお，本実施の形態においては，メールの本文に挿入するイラストを，テキストデータからなるものとして説明をおこなったが，これに限定するものではなく，ＪＰＥＧなどの静止画像データ，ＭＰＥＧやＡＶＩといった動画像データ，Ｍｏｔｉｏｎ−ＪＰＥＧやＧＩＦアニメーションなどの疑似静止画像データ，あるいはベクトル形式により作成されたデータをイラストとして挿入するようにしてもよい。この場合，イラスト挿入手段６は，イラストをＢＡＳＥ６４，ｕｕｅｎｃｏｄｅなどといった電子メールの添付ファイルで用いられるファイルエンコード方式によりエンコードするとともに，文書作成編集手段２は，文書をＨＴＭＬ形式として作成する。イラストは電子メールの添付ファイルとなるが，添付された画像の表示位置は，文書の本文中にＨＴＭＬで指定されており，メールの受信者は，メール作成画面２５上の指定された位置に，イラストが挿入された状態で文書を見ることができる。上述のテキストデータをイラストとして用いた場合と同じく，メール作成画面２５上では，送信側においても受信側においても，文書とイラストとは同一画面上に表示される。（後略）」
（２−２）引用例３の記載事項
　当審の平成２７年１１月１０日付けの拒絶理由に引用された，特開２００２−２９７５２１号公報（以下「引用例３」という。）には，図面とともに以下の事項が記載されている。
ア　「【０４７５】まず，アニメーションを表示させるメール１５１の送信の処理について説明する。
【０４７６】図３２に例を示すアニメーションメールと名前が付されたアイコンがタップされたとき，PDA１のスクリプトランチャ５２０は，スクリプトデータベース５２１からアニメーションメールスクリプト５３４を読み出す。PDA１のスクリプトランチャ５２０は，インターフェース５０４を介して，読み出したアニメーションメールスクリプト５３４を構文解析部５０５に供給する。
【０４７７】PDA１の構文解析部５０５は，アニメーションメールスクリプト５３４の所定の文字列を中間コードに変換して，所定の文字列が中間コードとされたスクリプトをスクリプトインタプリタ５０６に供給する。
【０４７８】PDA１のスクリプトインタプリタ５０６は，構文解析部５０５から供給された，所定の文字列が中間コードとされたスクリプトの実行の処理により，本文およびアニメーションを表示させるためのデータを取得する。スクリプトインタプリタ５０６は，取得した，本文およびアニメーションを表示させるためのデータを，インターフェース５０４を介して，エンコーダ５１８に供給する。
【０４７９】エンコーダ５１８は，アニメーションを表示させるためのデータを，Base64などの方式により符号化し，符号化したデータをメール生成部５１９に供給する。エンコーダ５１８は，本文をそのままメール生成部５１９に供給する。」
イ　「【０４８９】図５３および図５４は，メール１５１を受信したPDA１による，アニメーションを表示する処理を説明する図である。
【０４９０】アニメーションを表示させるスクリプトを格納したメール１５１が受信されたとき，PDA１のメール送受信プログラム１０４は，図５３に例を示すダイアログボックスを表示部２１に表示する。
【０４９１】ダイアログボックスの”ＹＥＳ”と名前が付されたボタンがタップされたとき，メール送受信プログラム１０４は，メール１５１を開き，例えば，図５４に示す本文を表示部２１に表示させる。
【０４９２】受信されたメール１５１が開かれたとき，PDA１のメール送受信プログラム１０４は，メール送受信プログラムプラグインインターフェース５０１を介して，メール１５１をメール構文解析部５０２に供給する。
【０４９３】PDA１のメール構文解析部５０２は，メール１５１から，スクリプトおよびデータを抽出し，抽出したスクリプトおよびデータをデコーダ５０３に供給する。
【０４９４】デコーダ５０３は，Base64などの方式により符号化されているデータを復号し，インターフェース５０４を介して，復号されたデータをスクリプトインタプリタ５０６に供給する。
【０４９５】デコーダ５０３は，インターフェース５０４を介して，スクリプトをそのまま構文解析部５０５に供給する。
【０４９６】PDA１の構文解析部５０５は，デコーダ５０３から供給されたスクリプトの所定の文字列を中間コードに変換して，所定の文字列が中間コードとされたスクリプトをスクリプトインタプリタ５０６に供給する。
【０４９７】PDA１のスクリプトインタプリタ５０６は，復号されたデータを基に，構文解析部５０５から供給された，所定の文字列が中間コードとされたスクリプトを実行し，リソースアクセスマネージャ５０８にアニメーションの表示を要求する。リソースアクセスマネージャ５０８は，スクリプトインタプリタ５０６からの要求に対応して，プラットフォームリソースアクセスインターフェース５０９を介して，Ｉ／Ｏモジュール５１０に，アニメーションの表示を要求する。
【０４９８】PDA１のＩ／Ｏモジュール５１０は，例えば，図５４に示すように，表示部２１に，本文と共に，アニメーションを表示させる。
【０４９９】このように，PDA１は，受信したメール１５１を基に，アニメーションを表示することができる。」
ウ　「【０５０７】次に，図５６のフローチャートを参照して，メール１５１を受信したPDA１による，アニメーションの表示の処理を説明する。
【０５０８】ステップＳ９２１において，メール送受信プログラム１０４は，メール１５１を表示しようとしているか否かを判定し，メール１５１を表示しようとしていないと判定された場合，ステップＳ９２１に戻り，判定の処理を繰り返す。
【０５０９】ステップＳ９２１において，メール１５１を表示しようとしていると判定された場合，ステップＳ９２２に進み，メール構文解析部５０２は，メール送受信プログラム１０４から供給されたメール１５１から，データおよびスクリプトを抽出する。
【０５１０】メール構文解析部５０２は，抽出したデータをデコーダ５０３に供給する。デコーダ５０３は，抽出された，Base64などの方式により符号化されているデータを復号する。デコーダ５０３は，復号されたデータをスクリプトインタプリタ５０６に供給する。
【０５１１】メール構文解析部５０２は，デコーダ５０３およびインターフェース５０４を介して，抽出したスクリプトを構文解析部５０５に供給する。構文解析部５０５は，スクリプトの所定の文字列を中間コードに変換し，所定の文字列が中間コードとされたスクリプトをスクリプトインタプリタ５０６に供給する。
【０５１２】ステップＳ９２３において，スクリプトインタプリタ５０６は，デコーダ５０３から供給されたデータを基に，所定の文字列が中間コードに変換されたスクリプトを実行する。
【０５１３】ステップＳ９２４において，スクリプトインタプリタ５０６は，アニメーションを表示させるためのデータを基に，表示部２１にアニメーションを表示させ，処理は終了する。
【０５１４】このように，PDA１は，メール１５１を基に，アニメーションを表示することができる。本発明に係るPDA１は，アニメーションを表示させるためのプログラムを取得したり，またはメールの添付ファイルをいちいち開いたりする必要がなく，受信したメール１５１を開いたとき，アニメーションが表示される。」
（２−３）引用例２，３に示されている周知技術
　上記（２−１）及び（２−２）の摘記事項及び関連する図面並びにこの分野における技術常識を踏まえると，引用例２には，メールの本文に挿入されるＧＩＦアニメーション等をＢａｓｅ６４でエンコードして送信し，受信側で当該ＧＩＦアニメーションを表示することが記載され，引用例３には，アニメーションを表示させるメールを送信する際に，アニメーションを表示させるためのデータをＢａｓｅ６４で符号化すること，及びアニメーションを表示させるスクリプトを格納したメールが受信されると，Ｂａｓｅ６４で符号化されているデータを復号し，アニメーションを表示することが記載されている。
　これらの記載を踏まえると，引用例２，３には，以下の周知技術が記載されているといえる。
（周知技術）
「Ｂａｓｅ６４で符号化されたアニメーションが受信側装置で再生されること」
　なお，上述のように，引用例２における上記（２−１）のア及びイの摘記箇所には，当該アニメーションとして，ＧＩＦアニメーションが例示されている。
（３）引用例４の記載事項及び引用発明２
（３−１）引用例４の記載事項
　当審の平成２７年１１月１０日付けの拒絶理由に引用された，特開２００３−３３３５３８号公報（以下「引用例４」という。）には，「動画再生装置動画再生プログラム動画再生システムおよびカラー画像暗号化復号化システム」として，図面とともに以下の事項が記載されている。
ア　「【０００３】
【発明が解決しようとする課題】携帯電話など省システムリソースの小型機器では，ＣＰＵパワー，搭載メモリー，グラフィック処理ＬＳＩ，通信速度などの制約から，上記の方式で圧縮された動画データを用いて実用的に動画を再生することは困難であった。すなわち，小型機器で実用的に動画を再生するためには，データ量を低減したり，プログラムを軽量化したり，ダウンロード中の待ち時間を体感的に軽減したり，暗号化等に伴って処理量やデータ量が増加することを軽減したり，多種多様な小型機器の性能の違いに適合させたりするなど多くの改良すべき問題がある。」
イ　「【００２６】また，サーバー（１１０）から動画データとこれを再生するための動画再生プログラムとをクライアント（１２０）にダウンロードして動画を再生する動画再生システムにおいて，サーバー（１１０）は，動画再生プログラムを有していないクライアント（１２０）に動画データを送信するときは，動画データと動画再生プログラムとをクライアントに送信し，動画再生プログラムを既に有しているクライアント（１２０）に動画データを送信するときは，動画データのみをクライアント（１２０）に送信する。クライアント（１２０）は，サーバー（１１０）から受信した動画再生プログラムをプログラム記憶手段（１２）に保持するとともに，サーバー（１１０）から受信した動画データを，プログラム記憶手段（１２）に記憶してある動画再生プログラムを用いて再生する。
【００２７】このように，動画データと動画再生プログラムとに切り分け，必要な場合にだけサーバー（１１０）からクライアント（１２０）に動画再生プログラムを送信するので，通信されるデータ量を軽減することができる。
【００２８】またクライアント（１２０）は，動画データの受信および受信した動画データの再生にかかわる当該クライアント（１２０）の性能情報を収集してこれをサーバー（１１０）に送信し，サーバー（１１０）は，クライアント（１２０）から受信した性能情報に応じた動画データをクライアント（１２０）に配信する。携帯電話などの小型機器では，メーカーや機種ごとにグラフィックスの表示能力の差が大きく異なるので，クライアント（１２０）としての小型機器に搭載された動画再生装置が，当該小型機器に搭載されているＬＳＩ，ＣＰＵの能力，表示デバイスの性能などをサーバー（１１０）側に通知する事で，それぞれの機器に最適な表示情報をサーバー（１１０）側で動的に選択して送信することができる。」
ウ　「【００４８】動画データをデコーダー部１３でリアルタイムで展開することが困難な場合には，動画の再生前に，事前にデコーダー部１３で動画データを動画に展開し，１枚ずつの静止画の連続として再びメモリー部１２に戻す。このとき，メモリー部１２に格納する静止画の枚数や画像サイズを機器の処理能力や使用可能メモリー量に合わせて調整する。そして動画の再生時には，メモリー部１２に格納してある複数の静止画を組み合わせて１枚の静止画を表示画面に形成することを高速で繰り返し行う。これにより，見かけ上，動画が再生される。」
（３−２）引用発明２
　上記（３−１）の摘記事項及び関連する図面並びにこの分野における技術常識を考慮して引用例４の記載を検討する。
　上記（３−１）のアからウまでには，サーバから動画データをクライアントにダウンロードし，当該クライアントにおいて，動画を再生する，あるいは，静止画を繰り返して表示することで，見かけ上，動画を再生する動画再生システムにおいて，動画再生プログラムを有していないクライアントに動画データを送信するときは，動画データと動画再生プログラムとをクライアントに送信し，動画再生プログラムをすでに有しているクライアントに動画データを送信するときは，動画データのみをクライアントに送信することが記載されている。
　ここで，動画は『画像に係るコンテンツ』ということができ，サーバからクライアントへの動画再生プログラムの送信は，『クライアントがその再生をするためのプログラムを有していないとき』になされるものといえる。
　したがって，引用例４には，次の発明（以下「引用発明２」という。）が開示されているといえる。
（引用発明２）
「画像に係るコンテンツを再生するクライアントがその再生をするためのプログラムを有していないときに，前記画像に係るコンテンツを送信するサーバが前記再生をするためのプログラムをクライアントに送信すること」
４　対比
　本願発明と引用発明１とを対比する。
（１）本願発明の構成要件Ａ，Ｂ及びＣと引用発明１の構成要件ａ，ｂ及びｃとの対比
　引用発明１の「サーバ」，「モバイル装置」は，それぞれ本願発明の「サーバ装置」，「端末装置」に相当する。
　引用発明１において再生される「複数の画像を含んだマルチメディアコンテンツ」と，本願発明において再生される「アニメーション」は，「画像に係るコンテンツ」である点で共通する。
　よって，引用発明１と本願発明とは，「サーバ装置と端末装置とがネットワークを介して通信可能に接続された，画像に係るコンテンツを再生するシステム」という点で共通し，引用発明では，その画像に係るコンテンツが「複数の画像を含んだマルチメディアコンテンツ」であって，「アニメーション」ではない点で本願発明と相違する。また，引用発明１の構成要件ｂ「前記サーバは，」は，本願発明の構成要件Ｂ「前記サーバ装置は，」に相当し，引用発明１の構成要件ｃ「前記モバイル装置は，」は，本願発明の構成要件Ｃ「前記端末装置は，」に相当する。
（２）本願発明の構成要件Ｂ−１について
　本願発明では，前記サーバ装置につき，構成要件Ｂ−１において，「前記端末装置にアニメーションＧＩＦファイルを再生するための再生プログラムを送信」することについて特定されているが，引用発明１では，そのような構成を有していない。
（３）本願発明の構成要件Ｂ−２と引用発明１の構成要件ｂ−１との対比
　上記（１）で検討したように，引用発明１の「モバイル装置」は，本願発明の「端末装置」に相当する。
　引用発明１の「前記複数の画像を含むマルチメディアコンテンツ」と，本願発明の「アニメーションＧＩＦファイル」は，「画像に係るコンテンツ」に係るものであるという点で共通する。
　引用発明１において，この画像に係るコンテンツの「リクエストがなされる」ことについてみるに，当該リクエストは，ユーザの所望するコンテンツの配信を受けるための要求であるから，当該リクエストが，少なくともコンテンツを指定する情報を含んでいなければならないことは明らかである。また，当該リクエストが，コンテンツの配信を受けるモバイル装置から送信され，コンテンツの配信を行うサーバにより受信されなければならないことも明らかである。したがって，引用発明１の前記「リクエストがなされる」ことは，当該コンテンツを「指定する情報を含む要求」が前記サーバ装置において「受信」されること，ということができる。
　引用発明１の「Ｂａｓｅ６４により符号化した文字列のファイル」は，上記（１−１）カに摘記した段落【００７４】から段落【００７７】までに示されているような文字列で構成されるものであるから，本願発明の「文字列により構成される文字列ファイル」に相当する。
　よって，引用発明１と本願発明とは，「前記端末装置より画像に係るコンテンツを指定する情報を含む要求を受信すると，前記画像に係るコンテンツに対応する，文字列により構成される文字列ファイルを前記端末装置に送信」する点で共通し，引用発明１では，前記画像に係るコンテンツが「アニメーションＧＩＦファイル」として構成されていないこと，及び前記文字列により構成される文字列ファイルが上記構成要件Ｂ−１に係る「前記再生プログラム」により「扱うことが可能」なものであることについて，特定されていない点で本願発明と相違する。
（４）本願発明の構成要件Ｃ−１について
　本願発明では，前記端末装置につき，構成要件Ｃ−１において，前記構成要件Ｂ−１に係る「前記再生プログラム」が「無い場合，前記アニメーションＧＩＦファイルを再生不可能であ」ることが特定されているが，引用発明１ではそのような構成を有していない点で，本願発明と引用発明１とは相違する。
（５）本願発明の構成要件Ｃ−２と引用発明１の構成要件ｃ−１との対比
　上記（３）で検討したように，引用発明１の「前記複数の画像を含むマルチメディアコンテンツ」と，本願発明の「アニメーションＧＩＦファイル」は，「画像に係るコンテンツ」に係るものであるという点で共通する。
　上記（３）の検討により，引用発明１の「前記リクエスト」を「行う」ことは，本願発明の「前記要求」の「送信」に相当するものといえる。
　上記（１）で検討したように，引用発明１の「サーバ」は，本願発明の「サーバ装置」に相当する。
　よって，引用発明１と本願発明とは，「画像に係るコンテンツを再生する場合，前記要求を前記サーバ装置に送信」する点で共通し，引用発明１では，前記「画像に係るコンテンツ」が「アニメーションＧＩＦファイル」として構成されていない点で本願発明と相違する。
（６）本願発明の構成要件Ｃ−３と引用発明１の構成要件ｃ−２との対比
　上記（１）で検討したように，引用発明１の「サーバ」は，本願発明の「サーバ装置」に相当する。また，上記（３）での検討を踏まえると，引用発明１の「文字列のファイル」は，本願発明の「文字列ファイル」に相当する。
　引用発明１における，「複数の画像」を再生することと，本願発明の「複数の画像ファイル」を再生することとは，「複数の画像」を再生する点で共通する。
　よって，引用発明１と本願発明とは，「前記サーバ装置より前記文字列ファイルを受信し，複数の画像を再生する」点で共通し，引用発明１では，前記受信から前記再生までの間の処理に関し，上記構成要件Ｂ−１に係る「前記再生プログラム」により，前記文字列ファイルを解釈し，解釈した結果に基づき複数の画像ファイルを生成することについて特定されていない点で本願発明と相違する。
（７）本願発明の構成要件Ｄと引用発明１の構成要件ｄとの対比
　上記（１）の検討により，引用発明１の「複数の画像を含んだマルチメディアコンテンツを再生するシステム」と，本願発明の「アニメーション再生システム」とは，「画像に係るコンテンツを再生するシステム」という点で共通し，引用発明１では，その画像に係るコンテンツが「アニメーション」ではない点で本願発明と相違する。
（８）まとめ
　上記（１）から（７）までに示した対比結果に基づき，本願発明と引用発明１との間の一致点と相違点をまとめると，以下のとおりである。
（一致点）
「サーバ装置と端末装置とがネットワークを介して通信可能に接続された，画像に係るコンテンツを再生するシステムであって，
　前記サーバ装置は，
　前記端末装置より画像に係るコンテンツを指定する情報を含む要求を受信すると，前記画像に係るコンテンツに対応する，文字列により構成される文字列ファイルを前記端末装置に送信し，
　前記端末装置は，
　前記画像に係るコンテンツを再生する場合，前記要求を前記サーバ装置に送信し，
　前記サーバ装置より前記文字列ファイルを受信し，複数の画像を再生する，
　前記画像に係るコンテンツを再生するシステム。」
（相違点１）
　前記画像に係るコンテンツが，本願発明では，「アニメーションＧＩＦファイル」であるのに対し，引用発明１では，「複数の画像を含んだマルチメディアコンテンツ」であり，そのために，再生するものが，本願発明では，「文字列ファイルを解釈し，解釈した結果生成」された「複数の画像ファイル」からなる「アニメーション」であるのに対し，引用発明１では，「複数の画像を含んだマルチメディアコンテンツ」である点
（相違点２）
　前記文字列ファイルを受信し，複数の画像を再生するに当たり，本願発明では，前記文字列を扱うことができる「再生プログラム」が，前記サーバ装置から前記端末装置に送信されており，これによって，前記再生がなされることになるのに対し，引用発明１では，単に前記再生がなされる点
（相違点３）
　本願発明では，前記端末装置が「前記再生プログラムが無い場合」，前記アニメーションＧＩＦファイルを「再生不可能であ」るのに対し，引用発明１では，再生プログラムがなければ，コンテンツの再生が不可能であるのかが明らかでない点
５　当審の判断
（１）上記（相違点１）について
　引用発明１は，サーバから端末装置に向けて複数の画像を含むコンテンツを送信するシステムであって，さらに，前記複数の画像を文字列にして前記送信を行うものである。
　一方，端末装置間でメールを送信する際の技術ではあるが，上記３（２−３）に周知技術として示したように，Ｂａｓｅ６４で符号化されたアニメーションが受信側装置で再生されることは，本願出願前において，すでに周知となっていたものである。
　引用例１の段落【０００３】及び【００２３】に「ビデオ」への言及がなされていることからもうかがえるように，引用発明１のような画像を処理するシステムにおいて，静止画のみならず，動画も取り扱えるようにすることは，当業者が自然に志向することである。
　そして，当該周知技術は，アニメーション，すなわち動画を処理する技術であり，加えて，画像を送信する際の工夫として，画像データの送信の際にＢａｓｅ６４というテキストデータにエンコードする方式を用いて符号化し，画像を文字列として送受信している点において，引用発明１と共通するものであるから，当該周知技術を引用発明１に適用することについての動機付けがあるといえる。
　ここで，引用発明１と当該周知技術とでは，画像の送信元が，サーバであるのか，端末装置であるのか，という点での相違はあるものの，コンテンツの送信元として，サーバも端末装置も一般的なものであり，当業者であれば，端末装置からの送信技術を，サーバからの送信技術に適用することは，通常の創作能力を発揮する過程で試みることといえ，また，引用発明１と当該周知技術との間で，技術的に当該適用を妨げる事情も認められない。
　また，アニメーションの再生をアニメーションＧＩＦファイルを用いて行うことは，本願出願前に周知である（引用例２には，当該アニメーションとして，ＧＩＦアニメーションが例示されている。）。そして，特開２００９−２５５６３８号公報の段落【００２３】や，特開２００３−０６１０４０号公報の段落【０１２９】，【０１３０】及び図３０に示されているように，アニメーションＧＩＦファイルが，複数のＧＩＦファイルから構成され，表示に当たり，それらが順次再生されることは周知の事項である。
　以上を踏まえると，引用発明１に上記周知技術を適用し，その際に，上記アニメーションＧＩＦファイルについての周知の事項を考慮することにより，引用発明１における「複数の画像を含んだマルチメディアコンテンツ」について，「アニメーションＧＩＦファイル」を採用し，複数の画像を再生する際に，同ファイルの構成に鑑みて，文字列ファイルから前記複数のＧＩＦファイルに対応する「複数の画像ファイルを生成し」，「再生する」ことによって，「アニメーション」が再生されるように構成することは，当業者が容易に想到し得たことである。
（２）上記（相違点２）及び（相違点３）について
　引用発明１は，モバイル装置において，Ｂａｓｅ６４により符号化された文字列のファイルから複数の画像を再生するという，特定の再生処理を行うものであるところ，当該再生処理が確実になされるために，前記モバイル装置が，前記特定の再生処理を行える性能を備えていなければならないことは，明らかである一方，モバイル装置によっては，必ずしもそのような特定の再生処理を行えるプログラムを有していない場合があり得ることは，当業者が当然に想定するところである。したがって，前記モバイル装置が特定の再生処理を行うプログラムを有していなければ，それに対処して再生処理が確実になされるようにすることは，当業者にとって自明の課題である。
　ここで，上記３（３−２）に示したように，引用例２には，「画像に係るコンテンツを再生するクライアントがその再生をするためのプログラムを有していないときに，前記画像に係るコンテンツを送信するサーバが前記再生をするためのプログラムをクライアントに送信すること」，という引用発明２が開示されている。ここで，引用発明２の「クライアント」は，引用発明１の「モバイル装置」に相当する。そして，この引用発明２は，上記自明の課題を解決する公知の発明であるといえる。
　したがって，引用発明１において，コンテンツの再生が確実になされるように，引用発明２を適用し，前記モバイル装置が再生プログラムを有していない場合に，前記サーバから前記モバイル装置に対し，前記再生プログラムを送信し，前記再生プログラムにより，モバイル装置で文字列ファイルから複数の画像を再生するという，コンテンツ再生の処理を行えるようにすることは，当業者が容易に想到し得たことである（相違点２）。そして，当該適用により，モバイル装置が再生プログラムを有していない場合に，再生プログラムを送信することでコンテンツ再生を可能とするのであるから，当該モバイル装置が前記再生プログラムを有していない場合に，当該モバイル装置における再生が不可能であることは，当該適用に当たり，当然に想定される条件にすぎない（相違点３）。
（３）さらに，本願発明の作用・効果も，引用発明１，２及び周知技術から当業者が予測できる範囲のものである。
（４）したがって，本願発明は，引用発明１，２及び周知技術に基づいて当業者が容易に発明をすることができたものである。
６　むすび
　以上のとおり，本願発明は，引用発明１，２及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，その他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　よって，結論のとおり審決する。