• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1344558
審判番号 不服2017-17559  
総通号数 227 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-11-30 
種別 拒絶査定不服の審決 
審判請求日 2017-11-28 
確定日 2018-10-16 
事件の表示 特願2016-241004「プログラム及びプログラム配信方法」拒絶査定不服審判事件〔平成29年 4月 6日出願公開、特開2017- 68866、請求項の数(4)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成24年10月26日に出願した特願2012-237191号の一部を平成27年2月12日に新たな出願とした特願2015-25396号の一部を平成28年5月18日に新たな出願とした特願2016-99783号の一部を平成28年12月13日に新たな出願としたものであって、平成29年4月4日付けで拒絶理由通知がされ、同年6月8日付けで手続補正がされ、同年8月23日付けで拒絶査定(原査定)がされ、これに対し、同年11月28日に拒絶査定不服審判の請求がされると同時に、手続補正がされ、平成30年2月14日に前置報告がされ、同年5月9日に審判請求人から前記報告に対する上申がされたものである。

第2 原査定の概要
原査定(平成29年8月23日付け拒絶査定)の概要は次のとおりである。

この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。



・請求項 1-4
・引用文献等 1-5

<引用文献等一覧>

1.特開2004-362090号公報
2.特開平8-214285号公報
3.特開2012-196424号公報
4.特開平7-225724号公報
5.特開2011-154513号公報

第3 本願発明
本願請求項1-4に係る発明(以下、それぞれ「本願発明1」-「本願発明4」という。)は、平成29年11月28日付けの手続補正書で補正された特許請求の範囲の請求項1-4に記載された事項により特定される発明であり、以下のとおりの発明である。

「【請求項1】
クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記クライアント機は、所定のスペックを有する第1クライアント機と、前記所定のスペックより高いスペックを有する第2クライアント機とを含み、
前記画像表示処理の少なくとも一部を相違させて、前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム。
【請求項2】
前記クライアント機に配信するステップにおいて、前記アプリケーションプログラムの一部分を入れ替える又は書き換える指示を配信する、請求項1に記載のプログラム。
【請求項3】
前記アプリケーションプログラムは、前記指示を受け入れる機能を備え、
前記受け入れる機能が、前記指示に従って、前記アプリケーションプログラムの一部分を入れ替える又は書き換える、請求項2に記載のプログラム。
【請求項4】
クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に実行させるプログラム配信方法であって、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を有し、
前記クライアント機は、所定のスペックを有する第1クライアント機と、前記所定のスペックより高いスペックを有する第2クライアント機とを含み、
前記画像表示処理の少なくとも一部を相違させて、前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる
プログラム配信方法。」

第4 引用文献1の記載事項
原査定の拒絶の理由に引用された引用文献1には、図面とともに以下の事項が記載されている。

1.「【0001】
【発明の属する技術分野】
本発明は、車載端末などの移動端末に対してソフトウエアを配信する技術に関する。
【0002】
【従来の技術】
携帯電話やPHS(Personal Handy-phone System)を利用してインターネットに接続可能な移動端末が登場している。最近では、DSRC(Dedicated Short Range Communication)や無線LAN(Local Area Network)などの狭域無線通信を利用した移動端末向けの狭域通信サービスの検討も始まっている。
【0003】
この種の移動端末では、インターネット上のソフトウエア配信システムにアクセスし、ソフトウエアをダウンロードすることで、新たな機能を追加することが可能となる。移動端末にソフトウエアを配信するシステムとしては、特許文献1、2などが提案されている。
【0004】
【特許文献1】
特開2003-87837号公報
【特許文献2】
特開2003-65785号公報
【0005】
【発明が解決しようとする課題】
しかしながら、移動端末は、一般に携帯性を重視した構成となっており、CPU性能、画面解像度、グラフィック性能、メモリやハードディスクの容量などは通常のパーソナルコンピュータに比べて貧弱であることが多い。したがって、移動端末のスペックや使用状態(リソース容量など)に応じたソフトウエアをダウンロードしなければ、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないこともある。
【0006】
特に、車両に設置された車載端末にあっては、この問題が顕著となる。車載端末は、車両に設置されるという構成上、モバイルパソコンなどの移動端末に比べてスペックやリソース容量の制限が大きいこと、また、買い換え周期が長く、古いスペックの端末がいつまでも使用され続ける可能性が高いこと、などがその理由である。しかも、新たに追加したソフトウエアにより、車両の運転に必要な他の機能(たとえば、ナビゲーション機能やラジオ機能など)の動作が阻害されては、運転に支障がでるおそれもある。
【0007】
とはいえ、移動端末の個々のスペックや使用状態に合わせて、網羅的に何十?何百種類ものバージョンのソフトウエアを予め用意しておくとすれば、ソフトウエア配信システム側に膨大なディスクスペースが必要となるため、とても現実的ではない。
【0008】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供することにある。」(下線は当審で付与。以下、同様。)

2.「【0032】
(第1の実施形態)
図1は、本発明の一実施形態に係るソフトウエア配信システムの構成を示す図である。
【0033】
ソフトウエア配信システム1は、移動端末2に対してソフトウエアを配信し、移動端末2の機能追加を行うシステムである。ソフトウエア配信システム1は、広域ネットワークであるインターネット3に接続されており、インターネット3を介して移動端末2とデータの送受信を行う。
【0034】
ソフトウエア配信システム1が対象とする移動端末2には、車載端末、モバイルパソコン、情報携帯端末(PDA)、携帯電話などが含まれる。図1では、移動体である車両20に設置され、DSRCもしくは無線LANの基地局4を介してインターネット3に接続する車載端末2aと、やはり車両20に設置され、携帯電話基地局5を介してインターネット3に接続する車載端末2bと、携帯電話基地局5を介してインターネット3に接続する情報携帯端末2cとが例示されている。このように、移動端末2の種類は多岐にわたり、個々の端末によってスペックや使用状態が異なる。
【0035】
本実施形態のソフトウエア配信システム1では、センター10が移動端末2のスペックなどに合わせて最適なソフトウエアを生成し、配信する処理を行う。ここで、配信するソフトウエアの元となる基本ソフトウエアは、ソフトウエア記憶手段である基本ソフトウエアDB(データベース)11が記憶し管理している。
【0036】
基本ソフトウエアDB11には、移動端末上で種々のサービス機能を実現するためのソフトウエアが格納されている。サービス機能としては、たとえば、ナビゲーション機能、VoIP(Voice on Internet Protocol)機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定される。基本ソフトウエアDB11では、これらのサービス機能を実現するソフトウエアを、ソースプログラム、中間プログラム、汎用ソフトウエアなどの基本ソフトウエアの形式で記憶している。
【0037】
基本ソフトウエアとしてのソースプログラムや中間プログラムは、移動端末2が採り得るスペックや使用状態を考慮して冗長的かつ汎用的にコーディングされている。センター10がソースプログラムや中間プログラムをコンパイル引数やリンク引数を変えてコンパイルすることで、移動端末2のスペックや使用状態に合わせて最適化された特定プログラムを生成することができる。
【0038】
また、基本ソフトウエアとしての汎用ソフトウエアは、移動端末2が採り得るスペックや使用状態を考慮して冗長的かつ汎用的な機能を有している。通常は、動作オプションなどが記述された設定ファイルとセットで用いられる。汎用ソフトウエアはその起動時などに設定ファイルを読み込み、それにしたがって動作態様を切り替え可能に作成されている。センター10は、移動端末2のスペックや使用状態に合わせて汎用ソフトウエアの動作態様が最適化されるように、設定ファイルを生成することができる。
【0039】
ソフトウエア配信システム1の各機能は、基本ハードウエアとして、CPU(中央演算処理装置)、メモリ、ハードディスク、通信IF(インターフェース)などを備える汎用のコンピュータシステムにおいて、ハードディスクに記憶されたプログラムがCPUに読み込まれ実行されることにより実現されるものである。センター10と基本ソフトウエアDB11は一台のコンピュータにより構成することもできるし、ネットワークで接続された複数台のコンピュータで構成することもできる。
【0040】
次に、ソフトウエア配信システム1の各機能の具体的な構成および処理の流れについて詳しく説明する。
【0041】
センター10は、配信可能なソフトウエアの一覧を移動端末2に通知する一覧通知手段として機能する。センター10では、図2のフローチャートに示すプロセスが常に動作しており、移動端末2から「サービス確認メッセージ」を受信すると(ステップS1)、その移動端末2に「サービス一覧メッセージ」を送信する(ステップS2)。サービス一覧メッセージは、たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などのサービス機能の名称がリストになっている情報である。ここでセンター10は、「サービス一覧メッセージ」を作成するため、基本ソフトウエアDB11に問い合せてもよい。
【0042】
図3(a)?(c)は、移動端末2のユーザが追加機能を選択する際の処理シーケンスを表している。移動端末2は、(a)?(c)のうちいずれのシーケンスを用いてもよい。
【0043】
(a)のシーケンスでは、移動端末2が、一定時間ごとにセンター10に「サービス確認メッセージ」を送信し、「サービス一覧メッセージ」を受け取ることで、常に最新のサービス機能一覧を保有している。そして、ユーザから「機能確認メッセージ」を受け取ったときに、サービス機能一覧を画面に表示する。ユーザは、一覧を閲覧することにより、追加可能なソフトウエアを知ることでできるので、システムの利便性が向上する。ユーザがサービス機能一覧画面において追加機能を選択すると、移動端末2に「機能追加メッセージ」が入力されることになる。
【0044】
(b)のシーケンスでは、ユーザから「機能確認メッセージ」の入力があったときに、移動端末2がセンター10にサービス機能一覧を取得しにいく。このシーケンスでは、移動端末2とセンター10の間の通信が必要なときにしか行われないため、通信コストを削減することができるという利点がある。通信IFとして従量制の携帯電話を用いている場合には、通信コストを抑えることのできる(b)のシーケンスを利用することが好ましい。
【0045】
(c)のシーケンスでは、(a)のシーケンスと同様、移動端末2が自動的にサービス機能一覧を更新する。そして、新しいサービス機能を見つけた場合に、移動端末2からユーザに対してサービス機能一覧が表示される。このシーケンスでは、ユーザが明示的に機能確認を行わなくても新しいサービス機能の一覧が表示されるので、操作性が向上する。
【0046】
上記(a)?(c)のうちいずれかのシーケンスによって、ユーザから「機能追加メッセージ」が入力された後の処理について、図4?図7を参照して説明する。図4は、ソフトウエア配信処理のシーケンスを表すタイミングチャートであり、図5は、サービス追加要求メッセージのデータ構造を表す図であり、図6は、ソフトウエア配信処理に係る移動端末側の処理を表すフローチャートであり、図7は、ソフトウエア配信処理に係るセンター側の処理を表すフローチャートである。
【0047】
移動端末2は、ユーザから「機能追加メッセージ」の入力を受けると(ステップS10)、「サービス追加要求メッセージ」を生成し、センター10に送信する(ステップS11)。そして、サービス実現ソフトウエアを受信するまで待機する(ステップS12)。
【0048】
「サービス追加要求メッセージ」は、図5に示すように、ソフトウエア配信要求である「要求サービス」と、移動端末2のスペックである「画面解像度」、「グラフィック性能」、「CPU性能」、「記憶媒体空き容量」などを含む「端末プロファイル」とから構成される。「要求サービス」には、サービス機能を一意に特定可能な識別記号などが記述される。
【0049】
センター10は、移動端末2から「サービス追加要求メッセージ」を受信すると(ステップS20)、要求サービスに対応した基本ソフトウエアを基本ソフトウエアDB11から取得する(ステップS21)。たとえば、要求サービスとして「ナビゲーション機能」が指定された場合には、ナビゲーション機能を実現するための基本ソフトウエアとして、ソースプログラム、中間プログラムもしくは汎用ソフトウエア、または、それらの組み合わせが取り出される。
【0050】
続いて、センター10は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末2に配信するためのサービス実現ソフトウエアを生成する(ステップS22)。
【0051】
基本ソフトウエアがソースプログラムや中間プログラムの場合には、センター10は、端末プロファイルに含まれる移動端末2の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする。また、汎用ソフトウエアの場合には、センター10は、端末プロファイルに含まれる移動端末2の各種スペックを参照し、それらのスペックに合致した最適な設定ファイルを生成するのである。これにより、汎用的な基本ソフトウエアから、移動端末のスペックに合わせて最適化された特定ソフトウエア(サービス実現ソフトウエア)を得ることができる。
【0052】
ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末2の「画面解像度」よりも小さくなるようにしたり、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「CPU性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう。
【0053】
センター10は、このようにして生成されたサービス実現ソフトウエアを、移動端末2に送信する(ステップS23)。このとき、サービス実現ソフトウエアが利用する設定ファイルも併せて送信する。
【0054】
移動端末2では、センター10からサービス実現ソフトウエアを受信すると(ステップS12)、それの組み込み(インストール)を実行する(ステップS13)。そして、組み込みが完了すると、「機能追加完了メッセージ」を画面表示してユーザに通知する(ステップS14)。
【0055】
本実施形態のソフトウエア配信システム1では、1つないし少数の汎用的な基本ソフトウエアを保有しておけば足りるので、移動端末2の個々のスペックなどに合わせて数多くのバージョンのソフトウエアを用意しておく必要がなくなり、ディスクスペースの削減、ひいては、システムコストの削減を図ることができる。
【0056】
また、基本ソフトウエアから移動端末2のスペックに合致した最適なサービス実現ソフトウエアを得ることができ、移動端末2上で最適な動作を保証し得るソフトウエアを配信することが可能となる。
【0057】
すなわち、従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、本実施形態のシステムでは、移動端末2のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証されるのである。」

第5 当審の判断
1.引用文献1に記載された発明
引用文献1には、個々の端末によってスペックが異なる複数の移動端末2(2a、2b、2c)に対してソフトウエアを配信し、移動端末2の機能追加を行うソフトウエア配信システム1が記載されており(【図1】、【0032】、【0033】、【0034】)、このソフトウエア配信システム1の機能は、プログラムが実行されることにより実現されるものである(【0039】)。また、このソフトウエア配信システム1が配信するソフトウエアは、移動端末上で種々のサービス機能を実現するためのソフトウエアであり、たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定されている(【0035】、【0036】)。
したがって、引用文献1には、「個々の端末によってスペックが異なる複数の移動端末2と通信可能であり、種々のサービス機能(たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現するソフトウエア配信システム1で実行されるプログラム」が記載されているといえる。

引用文献1のソフトウエア配信システム1で実行されるプログラムは、以下のステップS20-S23を有するものである(【図5】、【図7】、【0048】-【0053】)。

(ステップS20)
ソフトウエア配信システム1のセンター10は、移動端末2から「サービス追加要求メッセージ」を受信する(【0049】)。「サービス追加要求メッセージ」は、「要求サービス」と、移動端末2のスペックを含む「端末プロファイル」とから構成される(【0048】)。
(ステップS21)
要求サービスに対応した基本ソフトウエアを基本ソフトウエアDB11から取得する(【0049】)。
(ステップS22)
センター10は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末2に配信するためのサービス実現ソフトウエアを生成する(【0050】)。基本ソフトウエアがソースプログラムの場合には、センター10は、端末プロファイルに含まれる移動端末2の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする(【0051】)。ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末2の「画面解像度」よりも小さくなるようにしたり、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「CPU性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう(【0052】)。
(ステップS23)
センター10は、このようにして生成されたサービス実現ソフトウエアを、移動端末2に送信する(【0053】)。

上記各ステップS20-S23は、換言すれば、次のようなステップを含んでいるといえる。
「移動端末2から「要求サービス」と、移動端末2のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップと、
前記「要求サービス」に対応したソースプログラムを基本ソフトウエアDB11から取得するステップと、
前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップと、
生成されたサービス実現ソフトウエアを、移動端末2に送信するステップ」

引用文献1のソフトウエア配信システム1に実行させるプログラムは、「従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末2のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される」(【0057】)ものである。

以上によれば、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。

[引用発明]
個々の端末によってスペックが異なる複数の移動端末2と通信可能であり、種々のサービス機能(たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現するソフトウエア配信システム1で実行されるプログラムであって、
該プログラムは、
移動端末2から「要求サービス」と、移動端末2のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップと、
前記「要求サービス」に対応したソースプログラムを基本ソフトウエアDB11から取得するステップと、
前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップと、
生成されたサービス実現ソフトウエアを、移動端末2に送信するステップと、
を有し、
従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末2のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される
プログラム。

2.請求項1について
(1)対比
本願発明1と引用発明とを対比する。

ア.引用発明の「移動端末2」は、「ソフトウエア配信システム1」からプログラムが送信され、サービス機能を実現するものであるから、「クライアント機」といえるものであり、また、実現されるサービス機能は、「たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など」であるから、「オンラインサービス機能」を含むものである。さらに、「ソフトウエア配信システム1」が「情報処理装置」といえるのは明らかである。
本願発明1の「複数の前記クライアント機で同時に進行する対戦ゲーム」は、「オンラインサービス機能」といえるから、引用発明と本願発明1の「クライアント機と通信可能であり、複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、」「実行させ」る「プログラム」とは、「クライアント機と通信可能であり、オンラインサービス機能を実現する情報処理装置に、」「実行させ」る「プログラム」である点で共通するものである。

イ.引用発明のプログラムが有する、『移動端末2から「要求サービス」と、移動端末2のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップ』は、本願発明1の「前記クライアント機から当該クライアント機のスペック情報を取得するステップ」に相当する。

ウ.引用発明のプログラムが有する『前記「要求サービス」に対応したソースプログラムを基本ソフトウエアDB11から取得するステップと、前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップ』は、本願発明1の「前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」と、「前記オンラインサービス機能のためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップ」である点で共通するものである。

エ.引用発明のプログラムが有する「生成されたサービス実現ソフトウエアを、移動端末2に送信するステップ」は、本願発明1の「前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップ」に相当する。

オ.引用発明の「移動端末2」が「個々の端末によってスペックが異なる複数の移動端末」であることは、本願発明1の「前記クライアント機は、所定のスペックを有する第1クライアント機と、前記所定のスペックより高いスペックを有する第2クライアント機とを含」むことに相当する。

カ.引用発明のプログラムは、「たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、」コンパイルするものであるから、「グラフィック性能」が低い移動端末と「グラフィック性能」が低くない移動端末などのスペックの異なる移動端末の間で、「画像表示処理の少なくとも一部を相違させ」るものであるといえ、本願発明1の「前記画像表示処理の少なくとも一部を相違させて、前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させるプログラム」と「前記画像表示処理の少なくとも一部を相違させるプログラム」である点で共通するものである。

してみると、本願発明1と引用発明とは、以下の点で一致し、以下の点で相違する。

〈一致点〉
クライアント機と通信可能であり、オンラインサービス機能を実現する情報処理装置に、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記オンラインサービス機能のためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じて、前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記クライアント機は、所定のスペックを有する第1クライアント機と、前記所定のスペックより高いスペックを有する第2クライアント機とを含み、
前記画像表示処理の少なくとも一部を相違させる
プログラム。

〈相違点〉
本願発明1は、「複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させ、「前記画像表示処理の少なくとも一部を相違させて、前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ものであるのに対し、引用発明は、「オンラインサービス機能を実現する情報処理装置に、…前記オンラインサービス機能のためのアプリケーションプログラムを生成するための1つのソースコードを、…前記オンラインサービス機能に係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させ、「前記画像表示処理の少なくとも一部を相違させる」ものとはいえるものの、該オンラインサービス機能が「複数の前記クライアント機で同時に進行する対戦ゲーム」ではなく、「前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ものとは特定されていない点。

(2)相違点についての検討
引用文献2(段落【0016】、【0038】、【0043】)には、処理能力の高い端末に対しては、視覚的な効果の高い演出機能をより多く使用したプログラムを使用することがてき、処理能力の低い端末に対しては、プログラムを簡素化することにより処理時間を短縮したり、利用者に待ち時間を感じさせないような演出機能をもったプログラムを使用すること、端末がサーバに対して自己の演算処理能力及びグラフィックの処理能力を通知し、サーバ側ではこれに応じて最適な処理手順を表したプログラムをサーバからその端末に送信するようにして、それぞれの端末の演算処理能力やグラフィック処理能力に最適の情報を用いて処理を行わせることが、引用文献3(段落【0145】)には、対戦ゲームは、ゲームサーバからのウェブサービスの提供に基づき、プレイヤの通信端末のウェブブラウザにより表示されるウェブページによってゲームが進行すること、対戦ゲームは、ゲーム用ソフトウェアで実現される一部機能を通信端末にダウンロードあるいはインストールして実行する携帯とすることもできることが、引用文献4(段落【0041】?【0058】)には、ユーザの計算機には、ユーザ計算機上のソフトウェアを自動更新するためのクライアント・プログラムが置かれ、提供者の計算機には、ユーザ計算機上のソフトウェアを自動更新するためのサーバ・プログラムと、サーバ・プログラムに管理されるソフトウェア・ライブラリが置かれており、提供者の計算機上のサーバ・プログラムは、ユーザ計算機上のクライアント・プログラムから、ユーザにおける現有ソフトウェア構成の情報を受けると、対象となるソフトウェア・ライブラリと比較し、ユーザのソフトウェアを更新するための更新指示情報と、必要な最新版ソフトウェア・モジュールを、クライアント・プログラムに自動的に送信し、ユーザの計算機上に置かれたクライアント・プログラムはユーザの計算機上での管理の対象となるソフトウェアの構成と実行を管理し、サーバ・プログラムから返信を受けると、その指示に従って必要ならば、ユーザ計算機上での対象ソフトウェアの更新をすることが、引用文献5(段落【0032】)には、プリンター本体部の全体の動作を制御する制御プログラムは、更新用プログラムを用いてインストールされている制御プログラム(自分自身)を更新する処理を制御するための制御プログラムを含んでいることが記載され、また、前置報告において周知技術を示す文献として引用された引用文献6(特開2004-357968号公報)の段落【0018】には、ISPは、ゲーム‘カーレース’をゲーム会社のサーバからダウンロードして、情報通信端末41と情報通信端末48にゲーム‘カーレース’のソフトを転送して、情報通信端末41と情報通信端末48との間でP2Pでのネットワーク対戦ゲームを開始することが記載されている。

引用文献3、引用文献6に記載されるように、サーバから通信端末へプログラムをダウンロードし対戦ゲームを行うことは普通に行われていることであるから、ソフトウエア配信システム1から移動端末2にサービス実現ソフトウエアを送信して、種々のサービス機能(たとえば、ナビゲーション機能、VoIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現する引用発明において、ソフトウエア配信システム1が移動端末2にサービス実現ソフトウエアを送信して実現するサービス機能として、対戦ゲームを採用すること、すなわち、「対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を実行させることは、当業者が容易に想到し得ることである。

しかしながら、「複数のクライアント機で同時に進行する対戦ゲーム」において、「前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」ために、「第1クライアント機」と「第2クライアント機」に配信する「アプリケーションプログラム」を「画像表示処理の少なくとも一部を相違」させたものとすることは、引用文献2-6にも記載されておらず、本願の優先日前において周知技術であるともいえない。
また、引用発明には、第1クライアント機における画像の表示に関する時間と第2クライアント機における画像の表示に関する時間との差を減少させるように、クライアント機に配信されるアプリケーションプログラムの画像表示処理の少なくとも一部を相違させる動機もない。

したがって本願発明1は、当業者であっても引用発明、引用文献2-6に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.請求項2-3について
本願発明2-3は、本願発明1を引用して限定するものであり、上記「2.請求項1について」にて述べたのと同様の理由により、引用発明及び引用文献2-6に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

4.請求項4について
本願発明4は、実質的に、本願発明1を「プログラム配信方法」として記載たものであるから、上記「2.請求項1について」にて述べたのと同様の理由により、引用発明及び引用文献2-6に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第6 原査定について
本願発明1-4は、

「複数の前記クライアント機で同時に進行する対戦ゲームを実現する情報処理装置に、…前記対戦ゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、…前記対戦ゲームに係る画像表示処理を行うアプリケーションプログラムに変換するステップ」を有し、「前記画像表示処理の少なくとも一部を相違させて、前記第1クライアント機と前記第2クライアント機との間で処理に関する時間の差を減少させ、前記第1クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間と前記第2クライアント機における前記対戦ゲームの進行に必要な画像の表示に関する時間との差を減少させる」という技術的事項を有し、当該技術的事項は、原査定における引用文献1-5には記載されておらず、本願の優先日前における周知技術でもないので、本願発明1-4は、当業者であっても、原査定における引用文献1-5に基づいて容易に発明できたものではない。
したがって、原査定を維持することはできない。

第7 むすび
以上のとおり、本願発明1-4は、当業者が引用発明及び引用文献2-5に記載された技術的事項に基づいて容易に発明することができたものではない。
したがって、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2018-10-01 
出願番号 特願2016-241004(P2016-241004)
審決分類 P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 小林 義晴  
特許庁審判長 千葉 輝久
特許庁審判官 山田 正文
稲葉 和生
発明の名称 プログラム及びプログラム配信方法  
代理人 杉村 憲司  
代理人 内海 一成  
代理人 岡野 大和  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ