• ポートフォリオ機能


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

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

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

[本願発明]
「クライアント機と通信可能であり、オンラインゲームを実現する情報処理装置に、
前記クライアント機から当該クライアント機のスペック情報を取得するステップと、
前記オンラインゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、前記取得するステップで取得した前記スペック情報に応じた画像表示処理を行うアプリケーションプログラムに変換するステップと、
前記変換するステップで得たアプリケーションプログラムを前記クライアント機に配信するステップと
を実行させ、
前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で処理に関する時間の差を減少させる
プログラム。」

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

記
1.特開2004-362090号公報
2.特開平8-214285号公報(周知技術を示す文献)
3.特開平7-225724号公報
4.特開2011-154513号公報(周知技術を示す文献)
5.特開2010-9207号公報(周知技術を示す文献;新たに引用された文献)
6.国際公開第2008/016063号(周知技術を示す文献;新たに引用された文献)

第4 引用文献の記載事項
1.引用文献1
原査定の拒絶の理由で引用された特開2004-362090号公報(以下、「引用文献1」という。)には、以下の事項が記載されている。なお、下線は当審により付与したものである。

「【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には、移動端末上で種々のサービス機能を実現するためのソフトウエアが格納されている。サービス機能としては、たとえば、ナビゲーション機能、VｏIP(Vｏice ｏn Inｔeｒneｔ Pｒｏｔｏcｏl)機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定される。基本ソフトウエア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)。サービス一覧メッセージは、たとえば、ナビゲーション機能、VｏIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などのサービス機能の名称がリストになっている情報である。ここでセンター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に対してソフトウエアを配信し、移動端末2の機能追加を行うソフトウエア配信システム1が記載されており(【図1】、【0032】、【0033】)、このソフトウエア配信システム1の機能は、プログラムが実行されることにより実現されるものである(【0039】)。また、このソフトウエア配信システム1が配信するソフトウエアは、移動端末上で種々のサービス機能を実現するためのソフトウエアであり、たとえば、ナビゲーション機能、VｏIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定されている(【0035】、【0036】)。
したがって、引用文献1には、「移動端末2と通信可能であり、種々のサービス機能(たとえば、ナビゲーション機能、VｏIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現するソフトウエア配信システム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と通信可能であり、種々のサービス機能(たとえば、ナビゲーション機能、VｏIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現するソフトウエア配信システム1で実行されるプログラムであって、
該プログラムは、
移動端末2から「要求サービス」と、移動端末2のスペックを含む「端末プロファイル」とから構成される「サービス追加要求メッセージ」を受信するステップと、
前記「要求サービス」に対応したソースプログラムを基本ソフトウエアDB11から取得するステップと、
前記スペックに合致した最適なコンパイル引数やリンク引数で、たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、前記ソースプログラムをコンパイルしてサービス実現ソフトウエアを生成するするステップと、
生成されたサービス実現ソフトウエアを、移動端末2に送信するステップと、
を有し、
従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末2のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される
プログラム。

2.本願発明と引用発明との対比
本願発明と引用発明とを対比する。

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

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

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

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

引用発明のプログラムは、「たとえば、移動端末2の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したりして、」コンパイルするものであるから、「グラフィック性能」が低い移動端末と「グラフィック性能」が低くない移動端末などのスペックの異なる移動端末の間で、「画像表示処理の少なくとも一部を相違させ」るものであるといえる。このことにより、引用発明のプログラムは、「従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、移動端末2のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証される」ようにできるものであるから、たとえば、「グラフィック性能」が低く動作が遅すぎた移動端末の動作を遅すぎないようにすることができるものであり、結果として、「グラフィック性能」が低くない移動端末との間の画像表示処理にかかる時間の差は小さくなると考えられる。
したがって、本願発明と引用発明は、「前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で処理に関する時間の差を減少させる」点で一致する。

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

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

＜相違点＞
本願発明は、「オンラインゲームを実現する情報処理装置に、…前記オンラインゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、…アプリケーションプログラムに変換するステップと、…アプリケーションプログラムを…配信するステップとを実行させ」るものであるのに対し、引用発明は、「オンラインサービス機能を実現する情報処理装置に、…前記オンラインサービス機能のためのアプリケーションプログラムを生成するための1つのソースコードを、…アプリケーションプログラムに変換するステップと、…アプリケーションプログラムを…配信するステップとを実行させ」るものとはいえるものの、該オンラインサービス機能が「オンラインゲーム」ではない点。

3.相違点についての検討
引用発明は、ソフトウエア配信システム1から移動端末2にサービス実現ソフトウエアを送信して、種々のサービス機能(たとえば、ナビゲーション機能、VｏIP機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能など)を実現するものであるが、この移動端末2には、モバイルパソコンや携帯電話などが含まれる(引用文献1の【0034】を参照)。モバイルパソコンや携帯電話などにおいて、配信されたソフトウェアによりオンラインゲームを行うことは普通に行われていることであるから、引用発明において、ソフトウエア配信システム1が移動端末2にサービス実現ソフトウエアを送信して実現するサービス機能として、オンラインゲームを採用すること、すなわち、「オンラインゲームを実現する情報処理装置に、…前記オンラインゲームのためのアプリケーションプログラムを生成するための1つのソースコードを、…アプリケーションプログラムに変換するステップと、…アプリケーションプログラムを…配信するステップとを実行させ」ることは、当業者が容易に想到し得ることである。

よって、本願発明は、引用発明及び周知技術に基いて、当業者が容易に発明をすることができたものである。

4.請求人の主張について
(1)請求人の主張
請求人は、審判請求書において、次の主張をしている。

『引用文献1には、「移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供する」(〔0008〕)及び「汎用的な基本ソフトウエアから、移動端末のスペックに合わせて最適化された特定ソフトウエア(サービス実現ソフトウエア)を得る」(〔0051〕)等と記載されているものの、これらの記載は、あくまでも各端末における処理時間が個別に設定されることを示唆しているにすぎません。
また、引用文献1に記載される構成においては、本願発明の「オンラインゲーム」のように複数の端末で同時にソフトウエア処理を行う状況は想定されていません。
つまり、引用文献1においては、端末間の処理時間の差を減少させる必要がなく、端末間の処理時間の差を減少させるという構成を採用する動機づけとなる記載が存在しないものと思料致します。
以上のことから、引用文献1は、オンラインゲームにおいて端末間の処理時間の差を減少させる構成について開示も示唆もしていないものと思料致します。
また、引用文献1には、本願発明の「オンラインゲームにおける同時性を確保できる」(〔0065〕)という効果についての記載も示唆もないものと思料致します。』

(2)当審の判断
しかしながら、請求人の上記主張は、以下の理由により採用できない。
すなわち、上記2.で検討したとおり、引用発明は、「前記画像表示処理の少なくとも一部を相違させて、前記クライアント機間で処理に関する時間の差を減少させる」点で本願発明と一致するものである。
「オンラインゲーム」とは、単に、オンラインで行うゲームとの意味であって、請求人の主張するような、複数の端末で同時にソフトウエア処理を行い、複数の端末間での同時性を確保する必要のあるものも含まれるが、そうでないものも含まれ、本願請求項1には、前者に限定する旨の記載はない。
したがって、請求人の上記主張は、請求項の記載に基づかないものであって、当を得ないものである。

第6 むすび
以上のとおり、本願発明は、引用文献1に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができないものである。
したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2017-07-13 
結審通知日 2017-07-18 
審決日 2017-08-07 
出願番号 特願2016-99783(P2016-99783)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 小林 義晴  
特許庁審判長 高瀬 勤
特許庁審判官 土谷 慎吾
千葉 輝久
発明の名称 プログラム及びプログラム配信方法  
代理人 杉村 憲司  
代理人 岡野 大和  

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