2016-007276

特願２０１５－　２５３９６「プログラム及びプログラム配信方法」拒絶査定不服審判事件〔平成２７年　６月１１日出願公開、特開２０１５－１０９１０９〕について、次のとおり審決する。

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

【理　由】 第１　手続の経緯 本願は、平成２４年１０月２６日を出願日とする特願２０１２－２３７１９１号の一部を、平成２７年２月１２日に新たな特許出願として出願したものであって、平成２７年５月１２日付けて拒絶理由が通知され、同年６月２９日付けで手続補正がなされ、同年９月１６日付けで最後の拒絶理由が通知され、同年１１月２４日付けで手続補正がなされたものの、平成２８年２月１２日付けの補正の却下の決定により平成２７年１１月２４日付けの手続補正は却下され、補正の却下の決定と同日付けで拒絶査定がなされた。 その後、平成２８年５月１８日に拒絶査定に対する審判請求がなされるとともに、同時に手続補正がなされたものである。 第２　平成２８年５月１８日付の手続補正についての補正却下の決定 ［補正却下の決定の結論］ 平成２８年５月１８日付の手続補正（以下、「本件補正」という。）を却下する。 ［理由］ １．補正後の本願発明 本件補正は、特許請求の範囲の請求項４を、 〈補正前の請求項４〉 「クライアント機と通信可能な情報処理装置に実行させるプログラム配信方法であって、 前記クライアント機から当該クライアント機のスペック情報を取得するステップと、 アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、 前記変換するステップで得たアプリケーションプログラムとして、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を前記クライアント機に配信するステップと、 前記アプリケーションプログラムの一部分が正常に入れ替え又は書き換えられたことを確認するステップと を有するプログラム配信方法。」 から、 〈補正後の請求項４〉 「複数のクライアント機と通信可能な情報処理装置に実行させるプログラム配信方法であって、 前記複数のクライアント機それぞれから当該クライアント機のスペック情報を取得するステップと、 アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、 前記変換するステップで得たアプリケーションプログラムとして、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を前記複数のクライアント機それぞれに配信するステップと、 前記アプリケーションプログラムの一部分が正常に入れ替え又は書き換えられたことを確認するステップと を有し、 前記スペック情報に応じた画像表示処理は、前記複数のクライアント機それぞれの処理に関する時間の差が減少するように、画像の表示に関する処理の少なくとも一部が変更された処理であるプログラム配信方法。」 とする補正事項を含むものである。下線は、補正箇所を示す。 上記補正事項は、補正前の請求項４に記載した発明を特定するために必要な事項である「情報処理装置」と通信可能な「クライアント機」について、「複数のクライアント機」と限定し、「スペック情報」を取得する「クライアント機」について「複数のクライアント機それぞれ」と限定し、「アプリケーションプログラムの一部分を入れ替える又は書き換える指示」を配信する「クライアント機」について「複数のクライアント機それぞれ」と限定し、「スペック情報に応じた画像表示処理」について、「前記複数のクライアント機それぞれの処理に関する時間の差が減少するように、画像の表示に関する処理の少なくとも一部が変更された処理である」との限定を付加するものであって、補正前の請求項４に記載された発明と補正後の請求項４に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。 また、特許法第１７条の２第３項、第４項に違反するところはない。 そこで、本件補正後の前記請求項４に記載された発明（以下、「本願補正発明」という。）が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について、以下に検討する。 ２．引用文献 （１）原査定の拒絶の理由に引用された特開２００４－３６２０９０号公報（以下、「引用文献１」という。）には、次のア～ウのとおりの記載がある。下線は、注目箇所に当審が付した。以下、同様。 ア 「【０００１】 【発明の属する技術分野】 本発明は、車載端末などの移動端末に対してソフトウエアを配信する技術に関する。 【０００２】 【従来の技術】 携帯電話やＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ－ｐｈｏｎｅ Ｓｙｓｔｅｍ）を利用してインターネットに接続可能な移動端末が登場している。最近では、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）や無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの狭域無線通信を利用した移動端末向けの狭域通信サービスの検討も始まっている。 【０００３】 この種の移動端末では、インターネット上のソフトウエア配信システムにアクセスし、ソフトウエアをダウンロードすることで、新たな機能を追加することが可能となる。移動端末にソフトウエアを配信するシステムとしては、特許文献１、２などが提案されている。 【０００４】 （中略） 【０００５】 【発明が解決しようとする課題】 しかしながら、移動端末は、一般に携帯性を重視した構成となっており、ＣＰＵ性能、画面解像度、グラフィック性能、メモリやハードディスクの容量などは通常のパーソナルコンピュータに比べて貧弱であることが多い。したがって、移動端末のスペックや使用状態（リソース容量など）に応じたソフトウエアをダウンロードしなければ、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないこともある。 【０００６】 特に、車両に設置された車載端末にあっては、この問題が顕著となる。車載端末は、車両に設置されるという構成上、モバイルパソコンなどの移動端末に比べてスペックやリソース容量の制限が大きいこと、また、買い換え周期が長く、古いスペックの端末がいつまでも使用され続ける可能性が高いこと、などがその理由である。しかも、新たに追加したソフトウエアにより、車両の運転に必要な他の機能（たとえば、ナビゲーション機能やラジオ機能など）の動作が阻害されては、運転に支障がでるおそれもある。 【０００７】 とはいえ、移動端末の個々のスペックや使用状態に合わせて、網羅的に何十～何百種類ものバージョンのソフトウエアを予め用意しておくとすれば、ソフトウエア配信システム側に膨大なディスクスペースが必要となるため、とても現実的ではない。 【０００８】 本発明は上記実情に鑑みてなされたものであって、その目的とするところは、移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供することにある。 【０００９】 【課題を解決するための手段】 上記目的を達成するために本発明のソフトウエア配信システムは、以下の手段ないし手順により移動端末にソフトウエアを配信する。なお、ソフトウエア配信処理に係る以下の手段ないし手順は、プログラムがコンピュータシステムに読み込まれ実行されることにより具体的に実現されるものである。 【００１０】 ソフトウエア配信システムは、ソフトウエア記憶手段によって、基本ソフトウエアを記憶している。ここで、基本ソフトウエアとは、引数を変えてコンパイルすることにより移動端末の種々のスペックまたは／および使用状態に対応可能なソースプログラムまたは中間プログラムであるか、あるいは、設定ファイルにより移動端末の種々のスペックまたは／および使用状態に対応可能な汎用ソフトウエアである。 【００１１】 ソフトウエア配信システムは、要求受信手段によって、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信する。 【００１２】 端末プロファイルに含まれる移動端末のスペックとしては、画面解像度、グラフィック性能、ＣＰＵ性能、記憶媒体の空き容量などの情報が考えられ、また、移動端末の使用状態としては、処理負荷などの情報が考えられる。端末プロファイルにいずれの情報を含めるかは、システム構成などに応じて適宜変更可能である。 【００１３】 そして、ソフトウエア配信システムは、生成手段によって、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成する。 【００１４】 たとえば、基本ソフトウエアがソースプログラムまたは中間プログラムの場合には、生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な引数で基本ソフトウエアをコンパイルするとよい。 【００１５】 一方、基本ソフトウエアが汎用ソフトウエアの場合には、生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な設定ファイルを作成するとよい。 【００１６】 そして、ソフトウエア配信システムは、配信手段によって、生成された特定ソフトウエアを移動端末に配信すればよい。 【００１７】 このような構成によれば、ソフトウエア配信システムでは、１つないし少数の基本ソフトウエアを保有しておけば足りるので、移動端末の個々のスペックなどに合わせて数多くのバージョンのソフトウエアを用意しておく必要がなくなり、ディスクスペースの削減、ひいては、システムコストの削減を図ることができる。 【００１８】 また、基本ソフトウエアから移動端末のスペックや使用状態に合致した最適な特定ソフトウエアを得ることができ、移動端末上で最適な動作を保証し得るソフトウエアを配信することが可能となる。」 イ 「【００３２】 （第１の実施形態） 図１は、本発明の一実施形態に係るソフトウエア配信システムの構成を示す図である。 【００３３】 ソフトウエア配信システム１は、移動端末２に対してソフトウエアを配信し、移動端末２の機能追加を行うシステムである。ソフトウエア配信システム１は、広域ネットワークであるインターネット３に接続されており、インターネット３を介して移動端末２とデータの送受信を行う。 【００３４】 ソフトウエア配信システム１が対象とする移動端末２には、車載端末、モバイルパソコン、情報携帯端末（ＰＤＡ）、携帯電話などが含まれる。図１では、移動体である車両２０に設置され、ＤＳＲＣもしくは無線ＬＡＮの基地局４を介してインターネット３に接続する車載端末２ａと、やはり車両２０に設置され、携帯電話基地局５を介してインターネット３に接続する車載端末２ｂと、携帯電話基地局５を介してインターネット３に接続する情報携帯端末２ｃとが例示されている。このように、移動端末２の種類は多岐にわたり、個々の端末によってスペックや使用状態が異なる。 【００３５】 本実施形態のソフトウエア配信システム１では、センター１０が移動端末２のスペックなどに合わせて最適なソフトウエアを生成し、配信する処理を行う。ここで、配信するソフトウエアの元となる基本ソフトウエアは、ソフトウエア記憶手段である基本ソフトウエアＤＢ（データベース）１１が記憶し管理している。 【００３６】 基本ソフトウエアＤＢ１１には、移動端末上で種々のサービス機能を実現するためのソフトウエアが格納されている。サービス機能としては、たとえば、ナビゲーション機能、ＶｏＩＰ（Ｖｏｉｃｅ ｏｎ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定される。基本ソフトウエアＤＢ１１では、これらのサービス機能を実現するソフトウエアを、ソースプログラム、中間プログラム、汎用ソフトウエアなどの基本ソフトウエアの形式で記憶している。 【００３７】 基本ソフトウエアとしてのソースプログラムや中間プログラムは、移動端末２が採り得るスペックや使用状態を考慮して冗長的かつ汎用的にコーディングされている。センター１０がソースプログラムや中間プログラムをコンパイル引数やリンク引数を変えてコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成することができる。」 ウ 「【００４７】 移動端末２は、ユーザから「機能追加メッセージ」の入力を受けると（ステップＳ１０）、「サービス追加要求メッセージ」を生成し、センター１０に送信する（ステップＳ１１）。そして、サービス実現ソフトウエアを受信するまで待機する（ステップＳ１２）。 【００４８】 「サービス追加要求メッセージ」は、図５に示すように、ソフトウエア配信要求である「要求サービス」と、移動端末２のスペックである「画面解像度」、「グラフィック性能」、「ＣＰＵ性能」、「記憶媒体空き容量」などを含む「端末プロファイル」とから構成される。「要求サービス」には、サービス機能を一意に特定可能な識別記号などが記述される。 【００４９】 センター１０は、移動端末２から「サービス追加要求メッセージ」を受信すると（ステップＳ２０）、要求サービスに対応した基本ソフトウエアを基本ソフトウエアＤＢ１１から取得する（ステップＳ２１）。たとえば、要求サービスとして「ナビゲーション機能」が指定された場合には、ナビゲーション機能を実現するための基本ソフトウエアとして、ソースプログラム、中間プログラムもしくは汎用ソフトウエア、または、それらの組み合わせが取り出される。 【００５０】 続いて、センター１０は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末２に配信するためのサービス実現ソフトウエアを生成する（ステップＳ２２）。 【００５１】 基本ソフトウエアがソースプログラムや中間プログラムの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする。また、汎用ソフトウエアの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適な設定ファイルを生成するのである。これにより、汎用的な基本ソフトウエアから、移動端末のスペックに合わせて最適化された特定ソフトウエア（サービス実現ソフトウエア）を得ることができる。 【００５２】 ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末２の「画面解像度」よりも小さくなるようにしたり、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「ＣＰＵ性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう。 【００５３】 センター１０は、このようにして生成されたサービス実現ソフトウエアを、移動端末２に送信する（ステップＳ２３）。このとき、サービス実現ソフトウエアが利用する設定ファイルも併せて送信する。 【００５４】 移動端末２では、センター１０からサービス実現ソフトウエアを受信すると（ステップＳ１２）、それの組み込み（インストール）を実行する（ステップＳ１３）。そして、組み込みが完了すると、「機能追加完了メッセージ」を画面表示してユーザに通知する（ステップＳ１４）。」 ａ． 段落【００３３】の記載によれば、引用文献１には、 「移動端末２とインターネットを介してデータの送受信を行うソフトウエア配信システム１が、移動端末２に対してソフトウエアを配信する方法。」について記載されている。 ｂ． 段落【００３５】～【００３７】，図１の記載によれば、上記ａ．の「ソフトウエア配信システム１」は、「センター１０と基本ソフトウエアＤＢ１１とで構成され、基本ソフトウエアＤＢ１１では、サービス機能を実現するソフトウエアを、ソースプログラム、中間プログラムなどの基本ソフトウエアの形式で記憶し、センター１０は、ソースプログラムや中間プログラムをコンパイル引数やリンク引数を変えてコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成する」ものである。 ｃ． 段落【００４７】～【００４９】の記載によれば、「センター１０」は、「移動端末２」から、「ソフトウエア配信要求である要求サービスと、移動端末２のスペックである画像解像度、グラフィック性能、ＣＰＵ性能、記憶媒体空き容量などを含む端末プロファイルとから構成されるサービス追加要求メッセージを受信する」ものである。 ｄ． 段落【００５０】～【００５２】の記載によれば、上記ｂ．の特定プログラムの生成は、「センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致する最適なコンパイル引数やリンク引数で基本ソフトウェアをコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成する」ものである。 ここで、「最適化とは、表示画面のサイズが移動端末２の画像解像度よりも小さくなるようにしたり、移動端末２のグラフィック性能が低い場合には表示画面の色数や画像を削減したり、ＣＰＵ性能が低い場合や記憶媒体の空き容量が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりする」ことである。 ｅ． 段落【００５３】，【００５４】の記載によれば、「センター１０は、生成された特定プログラムを移動端末２に送信し、移動端末２では、センター１０から特定プログラムを受信すると、その組み込みを実行し、組み込みが完了すると、ユーザに通知する」ものである。 ｆ． 以上ａ．～ｅ．によれば、引用文献１には、 「移動端末２とインターネットを介してデータの送受信を行うソフトウエア配信システム１が、移動端末２に対してソフトウエアを配信する方法であって、 ソフトウエア配信システム１は、センター１０と基本ソフトウエアＤＢ１１とで構成され、 基本ソフトウエアＤＢ１１では、サービス機能を実現するソフトウエアを、ソースプログラム、中間プログラムなどの基本ソフトウエアの形式で記憶しておき、 センター１０は、移動端末２から、ソフトウエア配信要求である要求サービスと、移動端末２のスペックである画像解像度、グラフィック性能、ＣＰＵ性能、記憶媒体空き容量などを含む端末プロファイルとから構成されるサービス追加要求メッセージを受信し、 センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致する最適なコンパイル引数やリンク引数で基本ソフトウェアをコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成し、 ここで、最適化とは、表示画面のサイズが移動端末２の画像解像度よりも小さくなるようにしたり、移動端末２のグラフィック性能が低い場合には表示画面の色数や画像を削減したり、ＣＰＵ性能が低い場合や記憶媒体の空き容量が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることであり、 センター１０は、生成された特定プログラムを移動端末２に送信し、 移動端末２では、センター１０から特定プログラムを受信すると、その組み込みを実行し、組み込みが完了すると、ユーザに通知する、 ソフトウエアの配信方法。」の発明（以下「引用発明１」という。）が記載されている。 （２）原査定の拒絶の理由に引用された特開平７－２２５７２４号公報（以下、「引用文献２」という。）には、次のア～オのとおりの記載がある。 ア 「【０００１】 【産業上の利用分野】本発明はユーザの計算機上にあるソフトウェアをネットワークを介して更新するソフトウェア遠隔自動更新システムおよび方法に関する。」 イ 「【０００５】この場合に、ネットワークを経由してソフトウェアを入手するためのソフトウェアは、入手対象のソフトウェアとは全く別個のものであり、対象ソフトウェアの更新管理をしているわけではない。また、どの情報を入手してくるかは、ユーザが自分で判断している。 （ｄ）ネットワークを介した分散ソフトウェアの結合実行 ソフトウェアを実行するためには、通常ソースプログラムの翻訳・結合を行って実行形式にしておく必要がある。ユーザ計算機上にソースプログラムを置いてから翻訳・結合するのが通常であるが、時には、ソースプログラムが別の計算機（すなわち、提供計算機）上にある場合がある。この場合に、ユーザは、ユーザ計算機から、ネットワークを介して提供者計算機にアクセスし、そのソースプログラムを提供者計算機上で翻訳・結合してから、ダウンロードして、あるいは、ソースプログラムをダウンロードしてから、ユーザ計算機上で翻訳・結合して、ユーザ計算機上で実行可能にすることができる。 【０００６】この方法は、基本的には、上記（ｃ）の一種であるが、ソフトウェアの実行に一層近くなっている場合である。この場合にも、ユーザは、ソースプログラムが別の計算機にあることを意識し、ソースプログラムのどのモジュールやファイルを使用するかを明確に指定して（例えば、バージョン名をも含んだファイル名を指定して）、翻訳・結合を行っている。責任はすべてユーザに帰せられる。」 ウ 「【００１２】 【発明が解決しようとする課題】一般的な状況として、計算機のソフトウェアが多様・大規模・複雑・高度になってきており、それを利用しているユーザの数が急激に増加し（数千、数万、数十万．．．）、多様化、分散化してきている。このような中で、ユーザが使っている計算機ソフトウェアを適正に維持・管理・更新・改良していくことは、提供者側にとっても、ユーザ側にとっても、大きな負担となっている。 【００１３】このような状況にもかかわらず、上記した従来の方法は、（ａ）（ｂ）に示したように、ソフトウェアの更新情報を個別に人手を介して提供者が主導して配布するか、（ｂ）（ｃ）（ｄ）に示したように、ユーザ主導で入手するかである。そして、ソフトウェアのどの部分（モジュールなど）のどの版を送付／入手するかの判断、および、ソフトウェアのインストールや再インストールはすべて人手で行われており、この人手で行う部分に多くの不便と問題を生じている。 【００１４】また、提供者側からみると、提供している一つのソフトウェアについても、それが多数のユーザによって、さまざまの時期に入手され、ばらばらに管理されているため、それらが適正に利用できるように保証し、サービスするには多くの問題に直面する。すなわち、上記した従来技術においては、次のような問題点がある。 ＜問題点１＞多数のユーザが、さまざまの時期にさまざまの構成でソフトウェアを入手し使用しているために、ユーザ側のソフトウェアの構成を、提供者側が把握することが困難である。 ＜問題点２＞バグを発見し、提供者側のソフトウェアを修正しても、ユーザ側にあるソフトウェアを直ぐに訂正することはできない。このため、ユーザのソフトウェアの訂正が完了するまでユーザに迷惑をかけることとなる。 ＜問題点３＞機能拡張や新バージョンの提供などの新しいサービスを可能にしても、それがユーザに行き渡るまでに長期間かかる。 ＜問題点４＞ソフトウェアを実際に使用しているユーザを提供者が充分把握できないことが多いので、提供者側から迅速・適切にユーザに連絡したり、働きかけたりすることができない。 【００１５】特に、流通ソフトウェアなどにより、ユーザ層が拡大するにつれてこの問題点が大きくなる。 ＜問題点５＞ユーザ計算機での（再）インストールを、提供者が出かけて実行することは多大なコストを要するので、実行不可能であることが多く、一方、ユーザ任せにすると、提供者側が提供しているサービスをすべて実現できるとは限らない。 【００１６】一方、ユーザ側からみても、迅速・適切なサービスが受けられず、ソフトウェアの（再）インストールや更新・管理に多大の手間を要し、充分にソフトウェアを使えないという問題点が生ずる。 ＜問題点６＞ユーザ自身のハードウェア／ソフトウェア環境に合わせて、入手ソフトウェアを適切にインストールし、適切なバージョン管理を行うことは、大変な知識と労力を必要とする。熟練したユーザ以外には、手をつけられない場合が多い。 ＜問題点７＞ソフトウェアにバグがあると、自分が実行したい仕事を計算機上で正しく行えない。提供者からバグ訂正版を入手し、それを再インストールしなければならないが、それまでに長期間かかることが多い。 ＜問題点８＞新機能追加や新バージョンが発表・発売されても、自分でそれらを入手し、再インストールするまでは使えない。入手と再インストールには、手数と日数を要する。 ＜問題点９＞バグ訂正、機能追加、新バージョンなどの情報を知らないことがあり、不便なまま使っている場合が多くある。 ＜問題点１０＞もし、提供者が、バグ訂正や機能追加などの情報を度々連絡してきて、その度にユーザが再インストールをしていたのでは、煩わしくてしかたがない。 【００１７】以上の問題点を一括すると、ソフトウェアを更新するための情報（ソフトウェア）の配布・入手と、ユーザ計算機上での更新（再インストール）を、提供者またはユーザの人手を介して行うことに伴う問題と困難であると言える。本発明は上記した従来技術の問題点を解決するためになされたものであって、本発明の第１の目的は、各地に分散している多数のソフトウェア・ユーザに対して、ソフトウェア提供者が作成・更新したソフトウェアを、必要に応じて迅速・適切に配布・提供し、ユーザ計算機上でソフトウェアを更新して実行可能とすることができるソフトウェア遠隔自動更新システムおよび方法を提供することである。 【００１８】本発明の第２の目的は、ユーザ計算機上でソフトウェア障害が起こったとき、障害の正確な情報を自動的に提供者に連絡することができ、また、提供者側が、この障害情報に基づき訂正を行いソフトウェアを修正すれば、ユーザが直ちに訂正されたソフトウェアを使用することができるソフトウェア遠隔自動更新システムおよび方法を提供することである。」 エ 「【００４１】 【実施例】 （１）システムの構成 図２は本発明の実施例のシステムの構成を示す図であり、同図において、１１－１，１１－２はそれぞれ、ユーザＡおよびユーザＢの計算機であり、それぞれの計算機１１－１，１１－２には、ユーザ計算機上のソフトウェアを自動更新したり、障害情報を送信するためのクライアント・プログラムＣＰが置かれている。 【００４２】また、ユーザＡの計算機には旧版構成のソフトウェアＳ１が置かれており、ユーザＢの計算機には、最新版構成のソフトウェアＳ２が置かれ、これらは上記クライアントプログラムＣＰにより管理される。１２は提供者の計算機であり、提供者の計算機１２には、ユーザ計算機上のソフトウェアを自動更新するためのサーバ・プログラムＳＰと、サーバ・プログラムＳＰに管理されるソフトウェア・ライブラリＳＬが置かれている。 【００４３】また、１３はユーザの計算機１１－１，１１－２と、提供者の計算機１２間を接続する通信ネットワークであり、上記クライアント・プログラムＣＰとサーバ・プログラムＳＰは通信ネットワーク１３を介して情報交換される。なお、上記通信ネットワーク１３は専用回線でも公衆回線でもよく、クライアント・プログラムＣＰまたはサーバ・プログラムＳＰにより接続が確立され、その情報の送信および受信の間だけ利用できればよい。 【００４４】提供者の計算機１２上のサーバ・プログラムＳＰは提供者側の開発・保守作業の結果としての、対象ソフトウェア・ライブラリＳＬを（特に、版数、構成管理の面で）管理しており、特に、ユーザ計算機１１－１，１１－２上のクライアント・プログラムＣＰから、ユーザにおける現有ソフトウェア構成の情報を受けると、対象となるソフトウェア・ライブラリＳＬと比較し、ユーザのソフトウェアＳ１，Ｓ２を更新するための更新指示情報と、必要な更新版ソフトウェア・モジュールを、クライアント・プログラムＣＰに自動的に返信する。 【００４５】また、提供者の計算機１２上のソフトウェア・ライブラリＳＬは複数のモジュール群Ｍa,...,Ｍn からなり、各モジュールのバグ訂正、更新、機能追加、新モジュール追加などの情報が記録され、各モジュールの版数および構成が管理されている。同図のソフトウェア・ライブラリＳＬでは、従来版としてモジュール群Ｍa,…, Ｍi,…, Ｍm があり、その中でモジュールＭi が更新されて更新版Ｍi*ができており、さらに新規モジュールＭn ができあがった状態が示されている。すなわち、最新版は、モジュール群Ｍa,…, Ｍi*, …, Ｍm,Ｍn から構成される。 【００４６】ユーザの計算機１１－１，１１－２上に置かれたクライアント・プログラムＣＰはユーザの計算機上での管理の対象となるソフトウェアの構成と実行を管理し、特に、対象ソフトウェアが起動されると、そのソフトウェアの実行の前に、現在のソフトウェアの構成の情報（現有版情報）を抽出して、ネットワーク３を介してサーバ・プログラムＳＰに送信し、これが最新版であるかどうかを問い合わせる。 【００４７】そして、サーバ・プログラムから返信を受けると、その指示に従って必要ならば、ユーザ計算機上での対象ソフトウェアの更新をする。その後に、ユーザが起動した命令に従って、更新したソフトウェアを起動する。また、同図では、ユーザＡの計算機１１－１に旧版構成のソフトウェアＳ１のモジュール群Ｍa ，…，Ｍi ，…，Ｍm が置かれており、ユーザＢの計算機に、最新版構成のソフトウェアＳ２のモジュール群Ｍa ，…，Ｍi*，…，Ｍm ，Ｍnが置かれた状態が示されており、これらは上記クライアントプログラムＣＰに管理される。 【００４８】同図において、ユーザＡが、ユーザ計算機１１－１上のソフトウェアＳ１を起動しようとすると、クライアント・プログラムＣＰがそれを検知し、現有版の情報をまとめてネットワーク１３を介して提供者の計算機１２上のサーバ・プログラムＳＰに問い合わせる。同図の例では、ユーザ計算機１１－１のソフトウェアＳ１はモジュール群Ｍa ，…，Ｍi ，…，Ｍm から構成されるので、この情報をネットワーク１３を介してサーバ・プログラムＳＰに送信し問い合わせる。 【００４９】提供者のサーバ・プログラムＳＰは上記情報が受信されると、ソフトウェア・ライブラリＳＬの構成と比較し、ユーザＡのソフトウェアＳ１を更新するための指示情報と、更新版ソフトウェアを返送する。同図の例では、モジュールＭi をＭi*に更新し、モジュールＭn を追加する指示情報と、更新版モジュールＭi*と新規モジュールＭn を返送する。 【００５０】ユーザＡのクライアント・プログラムＣＰは上記情報を用いて、ソフトウェアＳ１を最新版に自動的に更新する。同図の例では、ユーザ計算機１１－１のソフトウェアＳ１はモジュール群Ｍa ，…，Ｍi*，…，Ｍm ，Ｍn に更新される。その結果、ユーザＡのソフトウェアＳ１は、ユーザＢの計算機のソフトウェアＳ２のように最新版に更新される。その後、クライアント・プログラムＣＰはユーザＡの指示通り、最新版になったソフトウェアを起動する。 （以下、略）」 オ 「【００５５】そして、ステップＳ９において、ユーザの起動命令に従って、対象ソフトウェアが起動され、実行が開始される。このとき、上記したステップＳ２からステップＳ８の処理により対象ソフトウェアは提供者が提供するソフトウェアの最新版になっていることが保証される。 (ii)提供者の計算機上での処理 図４は提供者の計算機上の処理を示す図であり、同図により提供者の計算機１２におけるサーバ・プログラムＳＰの処理を説明する。 【００５６】ステップＳ１において、提供者の計算機１２上でサーバ・プログラムが起動され、常時待機の体制をとる。ステップＳ２において、ネットワーク１３を介して任意のユーザの計算機のクライアント・プログラムからの更新照会を受け付け、そのユーザが使っている対象ソフトウェアの現用版の構成情報を受信する。図２の例において、ユーザＡからの照会の場合の受信情報は、モジュール構成Ｍa ，…，Ｍi ，…，Ｍm である。 【００５７】ステップＳ３において、サーバ・プログラムＳＰはサーバ・プログラムＳＰが管理している対象ソフトウェアのソフトウェア・ライブラリＳＬの構成と比較して、照会してきたユーザの対象ソフトウェアを更新するための更新指示情報を作成する。ユーザの現有版の構成が、ソフトウェア・ライブラリＳＬの構成と一致している場合には、更新指示情報は「更新必要なし」とする。 【００５８】図２のユーザＡの例では、更新指示情報は前記したように、「Ｍi を削除、Ｍi*, Ｍn を挿入」となる。ステップＳ４において、サーバ・プログラムＳＰはネットワーク１３を介して、照会したきたクライアント・プログラムＣＰに対して、更新指示情報と、更新に必要な更新版ソフトウェア本体とを返信する。」 以上、下線部の記載によれば、引用文献２には、 「従来の、ソースプログラムが提供計算機上にある場合に、ユーザが、ユーザ計算機から、ネットワークを介して提供者計算機にアクセスし、そのソースプログラムを提供者計算機上で翻訳・結合して実行形式にした上で、ダウンロードする代わりに、多様化、分散化しているユーザが使用する計算機ソフトウェアを適正に維持・管理・更新・改良していくために、ユーザの計算機上にあるソフトウェアをネットワークを介して更新するソフトウェア遠隔自動更新方法であって、 提供者の計算機１２には、ユーザ計算機上のソフトウェアを自動更新するためのサーバ・プログラムＳＰと、サーバ・プログラムＳＰに管理されるソフトウェア・ライブラリＳＬが置かれ、 ユーザ計算機１１－１，１１－２上のクライアント・プログラムＣＰから、ユーザにおける現有ソフトウェア構成の情報を受けると、対象となるソフトウェア・ライブラリＳＬと比較し、ユーザのソフトウェアＳ１，Ｓ２を更新するための更新指示情報と、必要な更新版ソフトウェア・モジュールを、クライアント・プログラムＣＰに自動的に返信する、 ソフトウェア遠隔自動更新方法。」の発明（以下、「引用発明２」という。）が記載されている。 （３）原査定の拒絶の理由に引用された特開２００１－１１７７８１号公報（以下、「引用文献３」という。）には、次のア～ウのとおりの記載がある。 ア 「【００３９】プログラム送信装置２０２は、プログラム受信側端末（ここでは、通信端末装置１０２）へ、更新対象となるプログラム、すなわち更新プログラムを送信する。プログラム受信装置２０３は、プログラム送信側端末（ここでは、通信端末装置１０１）から送信された更新プログラムを受信し、プログラムを更新する。 【００４０】次いで、プログラム送信装置２０２およびプログラム受信装置２０３の構成について説明する。図３は、本発明の実施の形態１に係る通信端末装置のプログラム送信装置の概略構成を示す要部ブロック図であり、図４は、本発明の実施の形態１に係る通信端末装置のプログラム受信装置の概略構成を示す要部ブロック図である。なお、図１と同一の構成には同一の符号を付し、詳しい説明は省略する。 【００４１】図３に示すプログラム送信装置２０２において、コマンド選択部３０１は、入力された信号によって示される命令を判断する。プログラム送信部３０２は、記憶部３０３に記憶されている更新プログラムを読み出し、送信する。記憶部３０３は、更新プログラムおよび通信端末装置が動作するための各種プログラムを記憶しており、例えばフラッシュ・ロム等である。 【００４２】チェックサム演算部３０４は、プログラムの更新が正しく行われたか否か判定するために使用する、いわゆるチェックサムを計算する。チェックサム照合部３０５は、プログラム送信側端末で計算されたチェックサムとプログラム受信側端末で計算されたチェックサムとの照合を行う。 【００４３】起動指示部３０６は、通信端末装置１０２をプログラム受信側端末として起動させるための信号を出力する。切り替え部３０７は、出力される信号を切り替える。電圧測定部３０８は、電源供給装置１０８より供給される電力の電圧を測定し、その電圧に従ってスイッチ３０９の接続／切断を制御する。 【００４４】一方、図４に示すプログラム受信装置２０３において、コマンド選択部４０１は、入力された信号によって示される命令を判断する。プログラム更新部４０２は、受信した更新プログラムを記憶部４０３に書き込む。記憶部４０３は、通信端末装置が動作するための各種プログラムを記憶しており、例えばフラッシュ・ロム等である。 【００４５】チェックサム演算部４０４は、プログラムの更新が正しく行われたか否か判定するために使用する、いわゆるチェックサムを計算する。切り替え部４０５は、出力される信号を切り替える。」 イ 「【００５９】また、ＳＴ５１０において、コマンド選択部３０１は、チェックサム演算部３０４に対して、チェックサム演算を開始するよう指示する。この指示により、チェックサム演算部３０４は、更新プログラムの送信が行われているのと並行して、チェックサム演算を行う。 【００６０】次いで、ＳＴ６０７において、プログラム受信側端末のプログラム更新部４０２が、受信した更新プログラムを、ＳＴ６０５において判定したタイプに従って、記憶部４０３に書き込む。なお、書き込み前には、記憶部４０３に記憶されている更新対象となるプログラムは、プログラム更新部４０２によってあらかじめ消去されている。このように、プログラム受信側端末でそれぞれのタイプに応じてプログラムの書き込みが行われるため、プログラム受信側端末がそれぞれタイプの違うフラッシュ・ロムを搭載している場合であっても、プログラム送信側端末は、すべてのプログラム受信側端末に対して同一の動作にてプログラム送信を行えば足りる。 【００６１】次いで、更新プログラムの送信がすべて終了すると、ＳＴ５１１において、プログラム送信側端末のプログラム送信部３０２は、プログラム受信側端末に対して、チェックサム要求信号を送信する。そして、ＳＴ６０８において、チェックサム要求信号を受信したプログラム受信側端末のコマンド選択部４０１が、チェックサム演算部４０４に対して、チェックサム演算を行うよう指示する。これにより、チェックサム演算部４０４はチェックサム演算を行う。 【００６２】チェックサム演算部４０４は、チェックサム演算が終了すると、ＳＴ６０９において、その結果をプログラム送信側端末へ送信する。このとき、切り替え部４０５は、チェックサム演算部４０４と信号送受信線１０６とを接続するような状態となっている。 【００６３】次いで、チェックサムの演算結果を受信したプログラム送信側端末のコマンド選択部３０１は、ＳＴ５１２において、チェックサム照合部３０５に対して、チェックサムの演算結果の照合を行うよう指示する。これにより、チェックサム照合部３０５は、チェックサム演算部３０４で算出されたチェックサムの演算結果と受信したチェックサムの演算結果とを照合する。 【００６４】照合した結果、一致する場合には、チェックサム照合部３０５は、ＳＴ５１３において、表示灯１１０を消灯させ、プログラム更新が成功した旨を通信端末装置ユーザへ知らせる。そして、ＳＴ５１６において、チェックサム照合部３０５は、スイッチ３０９を切断する。これにより、プログラム受信側端末への電力供給が停止されることになり、プログラム更新処理が終了する。」 以上、下線部の記載によれば、引用文献３には、 「プログラム送信装置２０２は、プログラム受信側端末２０３へ、更新プログラムを送信し、プログラム受信装置２０３は、プログラム送信側端末２０２から送信された更新プログラムを受信し、プログラムを更新する方法であって、 プログラム送信装置２０２のコマンド選択部３０１は、チェックサム演算部３０４に対して、チェックサム演算を開始するよう指示することにより、チェックサム演算部３０４は、更新プログラムの送信が行われているのと並行して、チェックサム演算を行い、 更新プログラムの送信がすべて終了すると、プログラム送信側端末のプログラム送信部３０２は、プログラム受信側端末２０３に対して、チェックサム要求信号を送信し、 チェックサム要求信号を受信したプログラム受信側端末２０３のコマンド選択部４０１が、チェックサム演算部４０４に対して、チェックサム演算を行うよう指示し、チェックサム演算部４０４はチェックサム演算を行い、その結果をプログラム送信側端末２０２へ送信し、 チェックサムの演算結果を受信したプログラム送信側端末２０２のコマンド選択部３０１は、チェックサム照合部３０５に対して、チェックサムの演算結果の照合を行うよう指示し、チェックサム照合部３０５は、チェックサム演算部３０４で算出されたチェックサムの演算結果と受信したチェックサムの演算結果とを照合し、照合した結果、一致する場合には、プログラム更新が成功した旨を通信端末装置ユーザへ知らせ、プログラム更新処理が終了する プログラムの更新方法。」の発明（以下、「引用発明３」という。）が記載されている。 ３．対比 そこで、本願補正発明と引用発明１とを比較すると、次のことがいえる。 （１）引用発明１の「移動端末２」、「ソフトウエア配信システム１」は、それぞれ、本願補正発明の「クライアント機」、「情報処理装置」に相当し、引用発明１において、移動端末２のスペックや使用状態に応じてプログラムを最適化することから、移動端末２が複数あることは明らかである。 よって、引用発明１の「移動端末２とインターネットを介してデータの送受信を行うソフトウエア配信システム１が、移動端末２に対してソフトウエアを配信する方法」は、本願補正発明と同様の「複数のクライアント機と通信可能な情報処理装置に実行させるプログラム配信方法」であるといえる。 （２）引用発明１の「ソフトウエア配信システム１」の「センター１０」が「移動端末２」から「受信する」「移動端末２のスペックである画像解像度、グラフィック性能、ＣＰＵ性能、記憶媒体空き容量などを含む端末プロファイル」は、本願補正発明の「クライアント機のスペック情報」に相当するから、引用発明１の「ソフトウエア配信システム１」の「センター１０」が「移動端末２」から「移動端末２のスペックである画像解像度、グラフィック性能、ＣＰＵ性能、記憶媒体空き容量などを含む端末プロファイル」を「受信する」ことは、本願補正発明の「前記複数のクライアント機それぞれから当該クライアント機のスペック情報を取得するステップ」に相当する。 （３）引用発明１の「基本ソフトウエア」は、「ソースプログラム、中間プログラム」などの形式で記憶され、コンパイルされることで「特定プログラム」が生成されるから、引用発明１の「基本ソフトウエア」、「特定プログラム」は、それぞれ、本願補正発明の「ソースコード」、「アプリケーションプログラム」に相当する。 そして、引用発明１の「ソフトウエア配信システム１」の「センター１０」が、「端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致する最適なコンパイル引数やリンク引数で基本ソフトウェアをコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成」し、「最適化」とは、「表示画面のサイズが移動端末２の画像解像度よりも小さくなるようにしたり、移動端末２のグラフィック性能が低い場合には表示画面の色数や画像を削減したり」することであるから、引用発明１は、本願補正発明と同様に「アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップ」を有するものである。 （４）引用発明１の「ソフトウエア配信システム１」の「センター１０」が、「生成された特定プログラムを移動端末２に送信」することと、本願補正発明の「前記変換するステップで得たアプリケーションプログラムとして、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を前記複数のクライアント機それぞれに配信するステップ」とは、いずれも「前記変換するステップで得たアプリケーションプログラムとして、アプリケーションプログラムを書き換えるためのデータを前記複数のクライアント機それぞれに配信するステップ」である点で共通する。 （５）引用発明１の「移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成」する際の最適化は「表示画面のサイズが移動端末２の画像解像度よりも小さくなるようにしたり、移動端末２のグラフィック性能が低い場合には表示画面の色数や画像を削減したり、ＣＰＵ性能が低い場合や記憶媒体の空き容量が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりする」ことと、本願補正発明の「前記スペック情報に応じた画像表示処理は、前記複数のクライアント機それぞれの処理に関する時間の差が減少するように、画像の表示に関する処理の少なくとも一部が変更された処理である」こととは、いずれも、「前記スペック情報に応じた画像表示処理は、画像の表示に関する処理の少なくとも一部が変更された処理である」点で共通する。 以上によれば、本願補正発明と引用発明１との間には、次の一致点、相違点があるといえる。 ［一致点］ 「複数のクライアント機と通信可能な情報処理装置に実行させるプログラム配信方法であって、 前記複数のクライアント機それぞれから当該クライアント機のスペック情報を取得するステップと、 アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、 前記変換するステップで得たアプリケーションプログラムとして、アプリケーションプログラムを書き換えるためのデータを前記複数のクライアント機それぞれに配信するステップと、 を有し、 前記スペック情報に応じた画像表示処理は、画像の表示に関する処理の少なくとも一部が変更された処理であるプログラム配信方法。」 ［相違点１］ 複数のクライアント機に配信される「アプリケーションプログラムを書き換えるためのデータ」が、本願補正発明では、「アプリケーションプログラムの一部分を入れ替える又は書き換える指示」であるのに対し、引用発明１では、「アプリケーションプログラム（生成された特定プログラム）」そのものである点。 ［相違点２］ 本願補正発明においては、「前記アプリケーションプログラムの一部分が正常に入れ替え又は書き換えられたことを確認するステップ」を有するのに対し、引用発明１においては、そのような確認するステップを有しない点。 ［相違点３］ 「スペック情報に応じた画像表示処理」における「画像の表示に関する処理の少なくとも一部」の「変更」が、本願補正発明では、「前記複数のクライアント機それぞれの処理に関する時間の差が減少するよう」な変更であるのに対し、引用発明１においては、そのようには特定されていない点。 ４．判断 （１）［相違点１］について 引用発明１、引用発明２は、いずれもプログラムの自動更新方法に関する発明であって、引用発明２は、従来行われていた、「ソースプログラムが提供計算機上にある場合に、ユーザが、ユーザ計算機から、ネットワークを介して提供者計算機にアクセスし、そのソースプログラムを提供者計算機上で翻訳・結合して実行形式にした上で、ダウンロードする」代わりに、ユーザ計算機のソフトウェアを更新するための更新指示情報と、必要な更新版ソフトウェア・モジュールをユーザ計算機に送信することにより、ソフトウェアを更新するものである。 そして、引用発明１は、引用発明２の従来行われていた、ソースプログラムを提供者計算機上で翻訳・結合して実行形式にした上でユーザ計算機に配信するものと同様のものであり、この代わりに、引用発明２の「ユーザ計算機のソフトウェアを更新するための更新指示情報と、必要な更新版ソフトウェア・モジュールをユーザ計算機に送信する」ことにより、ソフトウェアを更新する方法を採用し、相違点１に係る構成を得ることは当業者が容易に想到し得た事項である。 （２）［相違点２］について 情報処理技術分野において、処理が正常に完了したかを確認することは一般に行われる事項であるから、引用発明１において、ソフトウエアの更新が正常に完了したかを確認するための引用発明３を採用して、相違点２に係る構成を得ることは当業者が容易に想到し得た事項である。 （３）［相違点３］について 引用発明１の課題は、引用文献１の段落【０００５】に「移動端末のスペックや使用状態（リソース容量など）に応じたソフトウエアをダウンロードしなければ、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないこともある。」と記載されているように、スペックの低い移動端末において、実用に耐えるべく、動作が遅すぎないようにすることであり、「移動端末２のグラフィック性能が低い場合には表示画面の色数や画像を削減したり」することにより、動作が遅い端末については、動作を速くするものである。 そうすると、グラフィック性能の高い移動端末とグラフィック性能の低い移動端末とでは、グラフィック性能の低い移動端末について表示画面の色数や画像を削減することにより、グラフィック処理の時間の差は減少することになるから、結果的に「前記複数のクライアント機それぞれの処理に関する時間の差が減少する」ような画像表示処理の変更を行っているといえるものである。 この点、請求人は、審判請求書の請求の理由において、「『画像表示処理』は、オンラインゲームにおける同時性を確保するために、スペックが異なる端末における画像表示処理にかかる時間の差を減少させようとするものである」旨主張しているが、本願補正発明において、「アプリケーションプログラム」が「オンラインゲーム」である、「同時性を確保する」とは特定されていないから、請求人の主張は特許請求の範囲の記載に基づかない主張である。 よって、相違点３は、実質的な相違点ではない。 （４）本願補正発明の効果について 本願補正発明の構成によってもたらされる効果は、引用発明１、引用発明２、引用発明３から当業者が予測し得る範囲を超えるものとはいえない。 以上のとおりであるから、本願補正発明は、引用発明１、引用発明２、引用発明３に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。 ５．むすび よって、本件補正は、特許法第１７条の２第６項で準用する同法第１２６条第７項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。 第３　本願発明について 平成２８年５月１８日付の手続補正は上記のとおり却下されたので、本願の請求項４に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成２７年６月２９日付けの手続補正書により補正された特許請求の範囲の請求項４に記載された事項により特定される、以下のとおりのものである。 「クライアント機と通信可能な情報処理装置に実行させるプログラム配信方法であって、 前記クライアント機から当該クライアント機のスペック情報を取得するステップと、 アプリケーションプログラムを生成するための１つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、 前記変換するステップで得たアプリケーションプログラムとして、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を前記クライアント機に配信するステップと、 前記アプリケーションプログラムの一部分が正常に入れ替え又は書き換えられたことを確認するステップと を有するプログラム配信方法。」 １．引用文献 原査定の拒絶の理由に引用された引用文献１、引用文献２、引用文献３は、前記「第２」の「２．引用文献」の欄に記載したとおりである。 ２．対比・判断 本願発明は、前記「第２」で検討した本願補正発明から「情報処理装置」と通信可能な「複数のクライアント機」について、「複数の」との構成を省き、「スペック情報」を取得する「複数のクライアント機それぞれ」及び「アプリケーションプログラムの一部分を入れ替える又は書き換える指示」を配信する「複数のクライアント機それぞれ」の「クライアント機」について「複数の」、「それぞれ」との構成を省き、「スペック情報に応じた画像表示処理」について、「前記複数のクライアント機それぞれの処理に関する時間の差が減少するように、画像の表示に関する処理の少なくとも一部が変更された処理である」との構成を省いたものである。 そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「第２」の「３．」，「４．」に記載したとおり、引用発明１、引用発明２、引用発明３に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明１、引用発明２、引用発明３に基づいて、当業者が容易に発明をすることができたものである。 ３．むすび 以上のとおり、本願発明は、引用発明１、引用発明２、引用発明３に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。