【事件の表示】
　特願２０１６−２４１００４「プログラム及びプログラム配信方法」拒絶査定不服審判事件〔平成２９年　４月　６日出願公開、特開２０１７−　６８８６６、請求項の数（４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２４年１０月２６日に出願した特願２０１２−２３７１９１号の一部を平成２７年２月１２日に新たな出願とした特願２０１５−２５３９６号の一部を平成２８年５月１８日に新たな出願とした特願２０１６−９９７８３号の一部を平成２８年１２月１３日に新たな出願としたものであって、平成２９年４月４日付けで拒絶理由通知がされ、同年６月８日付けで手続補正がされ、同年８月２３日付けで拒絶査定（原査定）がされ、これに対し、同年１１月２８日に拒絶査定不服審判の請求がされると同時に、手続補正がされ、平成３０年２月１４日に前置報告がされ、同年５月９日に審判請求人から前記報告に対する上申がされたものである。
第２　原査定の概要
　原査定（平成２９年８月２３日付け拒絶査定）の概要は次のとおりである。
　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　記
・請求項　１−４
・引用文献等　１−５
　　　　　　　　　　　　　＜引用文献等一覧＞
１．特開２００４−３６２０９０号公報
２．特開平８−２１４２８５号公報
３．特開２０１２−１９６４２４号公報
４．特開平７−２２５７２４号公報
５．特開２０１１−１５４５１３号公報
第３　本願発明
　本願請求項１−４に係る発明（以下、それぞれ「本願発明１」−「本願発明４」という。）は、平成２９年１１月２８日付けの手続補正書で補正された特許請求の範囲の請求項１−４に記載された事項により特定される発明であり、以下のとおりの発明である。
「【請求項１】
　クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、
　前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
　前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
　前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
　前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含み、
　前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム。
　　【請求項２】
　前記クライアント機に配信するステップにおいて、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を配信する、請求項１に記載のプログラム。
　　【請求項３】
　前記アプリケーションプログラムは、前記指示を受け入れる機能を備え、
　前記受け入れる機能が、前記指示に従って、前記アプリケーションプログラムの一部分を入れ替える又は書き換える、請求項２に記載のプログラム。
　　【請求項４】
　クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に実行させるプログラム配信方法であって、
　前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
　前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
　前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を有し、
　前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含み、
　前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム配信方法。」
第４　引用文献１の記載事項
　原査定の拒絶の理由に引用された引用文献１には、図面とともに以下の事項が記載されている。
１．「【０００１】
【発明の属する技術分野】
本発明は、
車載端末などの移動端末に対してソフトウエアを配信する技術
【０００２】
【従来の技術】
携帯電話やＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙ−ｐｈｏｎｅ  Ｓｙｓｔｅｍ）を利用してインターネットに接続可能な移動端末が登場している。最近では、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ  Ｓｈｏｒｔ  Ｒａｎｇｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）や無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの狭域無線通信を利用した移動端末向けの狭域通信サービスの検討も始まっている。
【０００３】
この種の移動端末では、インターネット上のソフトウエア配信システムにアクセスし、ソフトウエアをダウンロードすることで、新たな機能を追加することが可能となる。移動端末にソフトウエアを配信するシステムとしては、特許文献１、２などが提案されている。
【０００４】
【特許文献１】
特開２００３−８７８３７号公報
【特許文献２】
特開２００３−６５７８５号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、
移動端末は、一般に携帯性を重視した構成となっており、ＣＰＵ性能、画面解像度、グラフィック性能、メモリやハードディスクの容量などは通常のパーソナルコンピュータに比べて貧弱であることが多い
したがって、移動端末のスペックや使用状態（リソース容量など）に応じたソフトウエアをダウンロードしなければ、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないこともある
【０００６】
特に、車両に設置された車載端末にあっては、この問題が顕著となる。車載端末は、車両に設置されるという構成上、モバイルパソコンなどの移動端末に比べてスペックやリソース容量の制限が大きいこと、また、買い換え周期が長く、古いスペックの端末がいつまでも使用され続ける可能性が高いこと、などがその理由である。しかも、新たに追加したソフトウエアにより、車両の運転に必要な他の機能（たとえば、ナビゲーション機能やラジオ機能など）の動作が阻害されては、運転に支障がでるおそれもある。
【０００７】
とはいえ、移動端末の個々のスペックや使用状態に合わせて、網羅的に何十〜何百種類ものバージョンのソフトウエアを予め用意しておくとすれば、ソフトウエア配信システム側に膨大なディスクスペースが必要となるため、とても現実的ではない。
【０００８】
本発明は上記実情に鑑みてなされたものであって、その
目的とするところは、移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供すること
２．「【００３２】
（第１の実施形態）
図１は、本発明の一実施形態に係るソフトウエア配信システムの構成を示す図
【００３３】
ソフトウエア配信システム１は、移動端末２に対してソフトウエアを配信し、移動端末２の機能追加を行うシステム
ソフトウエア配信システム１は、広域ネットワークであるインターネット３に接続されており、インターネット３を介して移動端末２とデータの送受信を行う
【００３４】
ソフトウエア配信システム１が対象とする移動端末２には、車載端末、モバイルパソコン、情報携帯端末（ＰＤＡ）、携帯電話などが含まれる。図１では、移動体である車両２０に設置され、ＤＳＲＣもしくは無線ＬＡＮの基地局４を介してインターネット３に接続する車載端末２ａと、やはり車両２０に設置され、
携帯電話基地局５を介してインターネット３に接続する車載端末２ｂと、携帯電話基地局５を介してインターネット３に接続する情報携帯端末２ｃ
移動端末２の種類は多岐にわたり、個々の端末によってスペックや使用状態が異なる
【００３５】
本実施形態の
ソフトウエア配信システム１では、センター１０が移動端末２のスペックなどに合わせて最適なソフトウエアを生成し、配信する処理を行う
配信するソフトウエアの元となる基本ソフトウエアは、ソフトウエア記憶手段である基本ソフトウエアＤＢ（データベース）１１が記憶し管理している
【００３６】
基本ソフトウエアＤＢ１１には、移動端末上で種々のサービス機能を実現するためのソフトウエアが格納され
サービス機能としては、たとえば、ナビゲーション機能、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｎ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定され
基本ソフトウエアＤＢ１１では、これらのサービス機能を実現するソフトウエアを、ソースプログラム
の形式で記憶し
【００３７】
基本ソフトウエアとしてのソースプログラム
は、移動端末２が採り得るスペック
を考慮して冗長的かつ汎用的にコーディングされ
センター１０がソースプログラム
をコンパイル引数やリンク引数を変えてコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成する
【００３８】
また、基本ソフトウエアとしての汎用ソフトウエアは、移動端末２が採り得るスペックや使用状態を考慮して冗長的かつ汎用的な機能を有している。通常は、動作オプションなどが記述された設定ファイルとセットで用いられる。汎用ソフトウエアはその起動時などに設定ファイルを読み込み、それにしたがって動作態様を切り替え可能に作成されている。センター１０は、移動端末２のスペックや使用状態に合わせて汎用ソフトウエアの動作態様が最適化されるように、設定ファイルを生成することができる。
【００３９】
ソフトウエア配信システム１の各機能は、基本ハードウエアとして、ＣＰＵ（中央演算処理装置）、メモリ、ハードディスク、通信ＩＦ（インターフェース）などを備える汎用のコンピュータシステムにおいて、ハードディスクに記憶されたプログラムがＣＰＵに読み込まれ実行されることにより実現され
【００４０】
次に、ソフトウエア配信システム１の各機能の具体的な構成および処理の流れについて詳しく説明する。
【００４１】
センター１０は、配信可能なソフトウエアの一覧を移動端末２に通知する一覧通知手段として機能する。センター１０では、図２のフローチャートに示すプロセスが常に動作しており、移動端末２から「サービス確認メッセージ」を受信すると（ステップＳ１）、その移動端末２に「サービス一覧メッセージ」を送信する（ステップＳ２）。サービス一覧メッセージは、たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などのサービス機能の名称がリストになっている情報である。ここでセンター１０は、「サービス一覧メッセージ」を作成するため、基本ソフトウエアＤＢ１１に問い合せてもよい。
【００４２】
図３（ａ）〜（ｃ）は、移動端末２のユーザが追加機能を選択する際の処理シーケンスを表している。移動端末２は、（ａ）〜（ｃ）のうちいずれのシーケンスを用いてもよい。
【００４３】
（ａ）のシーケンスでは、移動端末２が、一定時間ごとにセンター１０に「サービス確認メッセージ」を送信し、「サービス一覧メッセージ」を受け取ることで、常に最新のサービス機能一覧を保有している。そして、ユーザから「機能確認メッセージ」を受け取ったときに、サービス機能一覧を画面に表示する。ユーザは、一覧を閲覧することにより、追加可能なソフトウエアを知ることでできるので、システムの利便性が向上する。ユーザがサービス機能一覧画面において追加機能を選択すると、移動端末２に「機能追加メッセージ」が入力されることになる。
【００４４】
（ｂ）のシーケンスでは、ユーザから「機能確認メッセージ」の入力があったときに、移動端末２がセンター１０にサービス機能一覧を取得しにいく。このシーケンスでは、移動端末２とセンター１０の間の通信が必要なときにしか行われないため、通信コストを削減することができるという利点がある。通信ＩＦとして従量制の携帯電話を用いている場合には、通信コストを抑えることのできる（ｂ）のシーケンスを利用することが好ましい。
【００４５】
（ｃ）のシーケンスでは、（ａ）のシーケンスと同様、移動端末２が自動的にサービス機能一覧を更新する。そして、新しいサービス機能を見つけた場合に、移動端末２からユーザに対してサービス機能一覧が表示される。このシーケンスでは、ユーザが明示的に機能確認を行わなくても新しいサービス機能の一覧が表示されるので、操作性が向上する。
【００４６】
上記（ａ）〜（ｃ）のうちいずれかのシーケンスによって、ユーザから「機能追加メッセージ」が入力された後の処理について、図４〜図７を参照して説明する。図４は、ソフトウエア配信処理のシーケンスを表すタイミングチャートであり、図５は、サービス追加要求メッセージのデータ構造を表す図であり、図６は、ソフトウエア配信処理に係る移動端末側の処理を表すフローチャートであり、
図７は、ソフトウエア配信処理に係るセンター側の処理を表すフローチャート
【００４７】
移動端末２は、ユーザから「機能追加メッセージ」の入力を受けると（ステップＳ１０）、「サービス追加要求メッセージ」を生成し、センター１０に送信する（ステップＳ１１）。そして、サービス実現ソフトウエアを受信するまで待機する（ステップＳ１２）。
【００４８】
「サービス追加要求メッセージ」は、
ソフトウエア配信要求である「要求サービス」と、移動端末２のスペックである「画面解像度」、「グラフィック性能」、「ＣＰＵ性能」、「記憶媒体空き容量」などを含む「端末プロファイル」とから構成される
【００４９】
センター１０は、移動端末２から「サービス追加要求メッセージ」を受信すると（ステップＳ２０）、要求サービスに対応した基本ソフトウエアを基本ソフトウエアＤＢ１１から取得する（ステップＳ２１）
【００５０】
続いて、
センター１０は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末２に配信するためのサービス実現ソフトウエアを生成する（ステップＳ２２）
【００５１】
基本ソフトウエアがソースプログラムや中間プログラムの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする
汎用的な基本ソフトウエアから、移動端末のスペックに合わせて最適化された特定ソフトウエア（サービス実現ソフトウエア）を得ることができる
【００５２】
ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末２の「画面解像度」よりも小さくなるようにしたり、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「ＣＰＵ性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう
【００５３】
センター１０は、このようにして生成されたサービス実現ソフトウエアを、移動端末２に送信する（ステップＳ２３）
【００５４】
移動端末２では、センター１０からサービス実現ソフトウエアを受信すると（ステップＳ１２）、それの組み込み（インストール）を実行する（ステップＳ１３）。そして、組み込みが完了すると、「機能追加完了メッセージ」を画面表示してユーザに通知する（ステップＳ１４）。
【００５５】
本実施形態のソフトウエア配信システム１では、１つないし少数の汎用的な基本ソフトウエアを保有しておけば足りるので、移動端末２の個々のスペックなどに合わせて数多くのバージョンのソフトウエアを用意しておく必要がなくなり、ディスクスペースの削減、ひいては、システムコストの削減を図ることができる。
【００５６】
また、基本ソフトウエアから移動端末２のスペックに合致した最適なサービス実現ソフトウエアを得ることができ、移動端末２上で最適な動作を保証し得るソフトウエアを配信することが可能となる。
【００５７】
すなわち、
従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、本実施形態のシステムでは、移動端末２のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される
第５　当審の判断
１．引用文献１に記載された発明
　引用文献１には、個々の端末によってスペックが異なる複数の移動端末２（２ａ、２ｂ、２ｃ）に対してソフトウエアを配信し、移動端末２の機能追加を行うソフトウエア配信システム１が記載されており（【図１】、【００３２】、【００３３】、【００３４】）、このソフトウエア配信システム１の機能は、プログラムが実行されることにより実現されるものである（【００３９】）。また、このソフトウエア配信システム１が配信するソフトウエアは、移動端末上で種々のサービス機能を実現するためのソフトウエアであり、たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定されている（【００３５】、【００３６】）。
　したがって、引用文献１には、「個々の端末によってスペックが異なる複数の移動端末２と通信可能であり、種々のサービス機能（たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など）を実現するソフトウエア配信システム１で実行されるプログラム」が記載されているといえる。
　引用文献１のソフトウエア配信システム１で実行されるプログラムは、以下のステップＳ２０−Ｓ２３を有するものである（【図５】、【図７】、【００４８】−【００５３】）。
（ステップＳ２０）
　ソフトウエア配信システム１のセンター１０は、移動端末２から「サービス追加要求メッセージ」を受信する（【００４９】）。「サービス追加要求メッセージ」は、「要求サービス」と、移動端末２のスペックを含む「端末プロファイル」とから構成される（【００４８】）。
（ステップＳ２１）
　要求サービスに対応した基本ソフトウエアを基本ソフトウエアＤＢ１１から取得する（【００４９】）。
（ステップＳ２２）
　センター１０は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末２に配信するためのサービス実現ソフトウエアを生成する（【００５０】）。基本ソフトウエアがソースプログラムの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする（【００５１】）。ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末２の「画面解像度」よりも小さくなるようにしたり、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「ＣＰＵ性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう（【００５２】）。
（ステップＳ２３）
　センター１０は、このようにして生成されたサービス実現ソフトウエアを、移動端末２に送信する（【００５３】）。
　上記各ステップＳ２０−Ｓ２３は、換言すれば、次のようなステップを含んでいるといえる。
「移動端末２から「要求サービス」と、移動端末２のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップと、
　前記「要求サービス」に対応したソースプログラムを基本ソフトウエアＤＢ１１から取得するステップと、
　前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップと、
　生成されたサービス実現ソフトウエアを、移動端末２に送信するステップ」
　引用文献１のソフトウエア配信システム１に実行させるプログラムは、「従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末２のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される」（【００５７】）ものである。
　以上によれば、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
［引用発明］
　個々の端末によってスペックが異なる複数の移動端末２と通信可能であり、種々のサービス機能（たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など）を実現するソフトウエア配信システム１で実行されるプログラムであって、
　該プログラムは、
　移動端末２から「要求サービス」と、移動端末２のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップと、
　前記「要求サービス」に対応したソースプログラムを基本ソフトウエアＤＢ１１から取得するステップと、
　前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップと、
　生成されたサービス実現ソフトウエアを、移動端末２に送信するステップと、
　を有し、
　従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末２のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される
　プログラム。
２．請求項１について
（１）対比
　本願発明１と引用発明とを対比する。 
ア．引用発明の「移動端末２」は、「ソフトウエア配信システム１」からプログラムが送信され、サービス機能を実現するものであるから、「クライアント機」といえるものであり、また、実現されるサービス機能は、「たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など」であるから、「オンラインサービス機能」を含むものである。さらに、「ソフトウエア配信システム１」が「情報処理装置」といえるのは明らかである。
　本願発明１の「複数の前記クライアント機で同時に進行する対戦ゲーム」は、「オンラインサービス機能」といえるから、引用発明と本願発明１の「クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、」「実行させ」る「プログラム」とは、「クライアント機と通信可能であり、オンラインサービス機能を実現する情報処理装置に、」「実行させ」る「プログラム」である点で共通するものである。
イ．引用発明のプログラムが有する、『移動端末２から「要求サービス」と、移動端末２のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップ』は、本願発明１の「前記クライアント機から当該クライアント機のスペック情報を取得するステップ」に相当する。
ウ．引用発明のプログラムが有する『前記「要求サービス」に対応したソースプログラムを基本ソフトウエアＤＢ１１から取得するステップと、前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップ』は、本願発明１の「前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」と、「前記オンラインサービス機能のためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップ」である点で共通するものである。
エ．引用発明のプログラムが有する「生成されたサービス実現ソフトウエアを、移動端末２に送信するステップ」は、本願発明１の「前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップ」に相当する。
オ．引用発明の「移動端末２」が「個々の端末によってスペックが異なる複数の移動端末」であることは、本願発明１の「前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含」むことに相当する。
カ．引用発明のプログラムは、「たとえば、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、」コンパイルするものであるから、「グラフィック性能」が低い移動端末と「グラフィック性能」が低くない移動端末などのスペックの異なる移動端末の間で、「画像表示処理の少なくとも一部を相違させ」るものであるといえ、本願発明１の「前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させるプログラム」と「前記画像表示処理の少なくとも一部を相違させるプログラム」である点で共通するものである。
　してみると、本願発明１と引用発明とは、以下の点で一致し、以下の点で相違する。
〈一致点〉
　クライアント機と通信可能であり、オンラインサービス機能を実現する情報処理装置に、
　前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
　前記オンラインサービス機能のためのアプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
　前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
　前記クライアント機は、所定のスペックを有する第１クライアント機と、前記所定のスペックより高いスペックを有する第２クライアント機とを含み、
　前記画像表示処理の少なくとも一部を相違させる
プログラム。
〈相違点〉
　本願発明１は、「複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させ、「前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ものであるのに対し、引用発明は、「オンラインサービス機能を実現する情報処理装置に、…前記オンラインサービス機能のためのアプリケーションプログラムを生成するための１つのソースコードを、…前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させ、「前記画像表示処理の少なくとも一部を相違させる」ものとはいえるものの、該オンラインサービス機能が「複数の前記クライアント機で同時に進行する対戦ゲーム」ではなく、「前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ものとは特定されていない点。
（２）相違点についての検討
　引用文献２（段落【００１６】、【００３８】、【００４３】）には、処理能力の高い端末に対しては、視覚的な効果の高い演出機能をより多く使用したプログラムを使用することがてき、処理能力の低い端末に対しては、プログラムを簡素化することにより処理時間を短縮したり、利用者に待ち時間を感じさせないような演出機能をもったプログラムを使用すること、端末がサーバに対して自己の演算処理能力及びグラフィックの処理能力を通知し、サーバ側ではこれに応じて最適な処理手順を表したプログラムをサーバからその端末に送信するようにして、それぞれの端末の演算処理能力やグラフィック処理能力に最適の情報を用いて処理を行わせることが、引用文献３（段落【０１４５】）には、対戦ゲームは、ゲームサーバからのウェブサービスの提供に基づき、プレイヤの通信端末のウェブブラウザにより表示されるウェブページによってゲームが進行すること、対戦ゲームは、ゲーム用ソフトウェアで実現される一部機能を通信端末にダウンロードあるいはインストールして実行する携帯とすることもできることが、引用文献４（段落【００４１】〜【００５８】）には、ユーザの計算機には、ユーザ計算機上のソフトウェアを自動更新するためのクライアント・プログラムが置かれ、提供者の計算機には、ユーザ計算機上のソフトウェアを自動更新するためのサーバ・プログラムと、サーバ・プログラムに管理されるソフトウェア・ライブラリが置かれており、提供者の計算機上のサーバ・プログラムは、ユーザ計算機上のクライアント・プログラムから、ユーザにおける現有ソフトウェア構成の情報を受けると、対象となるソフトウェア・ライブラリと比較し、ユーザのソフトウェアを更新するための更新指示情報と、必要な最新版ソフトウェア・モジュールを、クライアント・プログラムに自動的に送信し、ユーザの計算機上に置かれたクライアント・プログラムはユーザの計算機上での管理の対象となるソフトウェアの構成と実行を管理し、サーバ・プログラムから返信を受けると、その指示に従って必要ならば、ユーザ計算機上での対象ソフトウェアの更新をすることが、引用文献５（段落【００３２】）には、プリンター本体部の全体の動作を制御する制御プログラムは、更新用プログラムを用いてインストールされている制御プログラム（自分自身）を更新する処理を制御するための制御プログラムを含んでいることが記載され、また、前置報告において周知技術を示す文献として引用された引用文献６（特開２００４−３５７９６８号公報）の段落【００１８】には、ＩＳＰは、ゲーム‘カーレース’をゲーム会社のサーバからダウンロードして、情報通信端末４１と情報通信端末４８にゲーム‘カーレース’のソフトを転送して、情報通信端末４１と情報通信端末４８との間でＰ２Ｐでのネットワーク対戦ゲームを開始することが記載されている。
　引用文献３、引用文献６に記載されるように、サーバから通信端末へプログラムをダウンロードし対戦ゲームを行うことは普通に行われていることであるから、ソフトウエア配信システム１から移動端末２にサービス実現ソフトウエアを送信して、種々のサービス機能（たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など）を実現する引用発明において、ソフトウエア配信システム１が移動端末２にサービス実現ソフトウエアを送信して実現するサービス機能として、対戦ゲームを採用すること、すなわち、「対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させることは、当業者が容易に想到し得ることである。
　しかしながら、「複数のクライアント機で同時に進行する対戦ゲーム」において、「前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ために、「第１クライアント機」と「第２クライアント機」に配信する「アプリケーションプログラム」を「画像表示処理の少なくとも一部を相違」させたものとすることは、引用文献２−６にも記載されておらず、本願の優先日前において周知技術であるともいえない。
　また、引用発明には、第１クライアント機における画像の表示に関する時間と第２クライアント機における画像の表示に関する時間との差を減少させるように、クライアント機に配信されるアプリケーションプログラムの画像表示処理の少なくとも一部を相違させる動機もない。
　したがって本願発明１は、当業者であっても引用発明、引用文献２−６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
３．請求項２−３について
　本願発明２−３は、本願発明１を引用して限定するものであり、上記「２．請求項１について」にて述べたのと同様の理由により、引用発明及び引用文献２−６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
４．請求項４について
　本願発明４は、実質的に、本願発明１を「プログラム配信方法」として記載たものであるから、上記「２．請求項１について」にて述べたのと同様の理由により、引用発明及び引用文献２−６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第６　原査定について
　本願発明１−４は、
「複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための１つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を有し、「前記画像表示処理の少なくとも一部を相違させて、前記第１クライアント機と前記第２クライアント機との間で処理に関する時間の差を減少させ、前記第１クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第２クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」という技術的事項を有し、当該技術的事項は、原査定における引用文献１−５には記載されておらず、本願の優先日前における周知技術でもないので、本願発明１−４は、当業者であっても、原査定における引用文献１−５に基づいて容易に発明できたものではない。
　したがって、原査定を維持することはできない。
第７　むすび
　以上のとおり、本願発明１−４は、当業者が引用発明及び引用文献２−５に記載された技術的事項に基づいて容易に発明することができたものではない。
　したがって、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。