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