【事件の表示】
　平成１０年特許願第２９６４３１号「ソフトウェア・モジュール転送方法、データ処理ネットワークおよびシステム」拒絶査定に対する審判事件［平成１１年　８月２７日出願公開、特開平１１−２３２１１５］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯、本願発明
　本願は、平成１０年１０月１９日の出願（パリ条約による優先権主張１９９７年１１月１９日、英国）であって、その請求項１に係る発明は、平成１２年７月１２日付け手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
    
「データ処理ネットワーク中でソフトウェア・モジュールをターゲット・データ処理システム上で実行するためにホスト・データ処理システムからプリエンプティブに転送する方法であって、それぞれ前記ターゲット・システムのところで異なるサービスを提供する複数のタイプのソフトウェア・モジュールがあり、
　前記ホスト・システムのところで、ターゲット・システムに転送される第１のソフトウェア・モジュールのタイプを決定するステップと、
　前記ホスト・システムのところで、各ターゲット・システムにおけるソフトウェア・モジュール使用の履歴をコンパイルするステップと、
　前記第１のモジュールのタイプの決定および前記コンパイルされた履歴に基づいて、次に前記ターゲット・システムのところで必要とされるであろう第２のソフトウェア・モジュールのタイプを予測するステップと、
　前記第２のタイプのモジュールを前記ターゲット・システムに自動的に転送するステップとを含む方法。」
　
２．引用例
　これに対し、原査定の拒絶の理由に引用された特開平２−２４７７６８号公報（以下、引用例１という。）には、以下の事項が図面と共に記載されている。
　
（１）「Ａ．産業上の利用分野
　本発明は、分散処理に関し、特に複数の知能端末やワークステーションと連携するよう接続された１つ以上のホスト・プロセッサを有する通信システムのデータ交換に関する。
Ｂ．従来技術
　連携方式の処理についてはよく知られており、第４図に示した装置は代表的なものである。この図で、ホスト・プロセッサは、接続された端末やワークステーションからのオブジェクト（データや処理ルーチン）要求に対して全くのリアクティブ（反応）モードで作動する。
（中略）
また、ここに述べるタイプのシステムでは、時間と機器の利用効率をさらに高めることが望まれる。すなわち、ホスト・コンピュータ内に先行モードを実現して、ホストがワークステーション側で一定のタイプのデータや処理情報（以下、”オブジェクト”と呼ぶ）の必要なことを予想し、これをワークステーションに自発的に供給することにより、ユーザからオブジェクトの要求があって、これをワークステーション側で利用（表示／処理）できるようにすることで、時間を有効に用い、機器の利用効率を高めることができる。」（公報２頁左上欄５行〜左下欄６行）
　
（２）「第２図は、一般の利用者が維持する２種類のオブジェクト、電子メールとカレンダーを示す。記憶装置７７の少なくとも一部がこれら２タイプの情報を格納するために割り当てられる。
　電子メール９０は、新たに到着して選択されたメール項目を格納するもので、利用者が保管を指定するか、または所定期間あるいは不定期間だけワークステーション側に保管される。
　カレンダー９１は、会議、約束、休日、旅行の予定など、利用者がそれらの調整や実行に必要または有益と考えるスケジュール情報を指定する。
　上述したように、電子メールの記憶装置９０は、所定期間または不定期間に、ワークステーションで保管することが選択された項目を格納しやすい構造を持つ。」（公報４頁右下欄７行〜５頁左上欄１行）
　
（３）「上述のとおり、カレンダー部９３は、将来の事象に関係し、時間に依存する項目を格納するためのものである。利用者がチェックする可能性の高いのは、今週、次の週あるいはその２週間であるため、このカレンダーは特に、その期間に関係する情報を格納・更新する構造になっている。」（公報５頁右上欄１３行〜１８行）
　
（４）「まとめると、ここで述べた事前発見的手法により、利用者のニーズや希望を予測した上でオブジェクトを自発的にあるいは事前に送信できるため、効率を高めたホストと複数のワークステーションを含む事前選択システムが提供され、処理速度、並びに時間と機器の利用効率を高めることができる。」（公報５頁右下欄６行〜１２行）
　
　以上の記載より、引用例１には以下の発明が記載されている。
ホストプロセッサとワークステーションが接続された分散処理システム中で、ホストからワークステーションに必要なオブジェクトを事前に送信する方法であって、
事前発見的手法により、利用者のニーズや希望を予測した上でワークステーションで必要とされるであろうオブジェクトを予測するステップと、
予測したオブジェクトを前記ワークステーションに自発的に送信するステップとを含む方法
　
　また、原査定の拒絶の理由に引用された特開平３−２２８１６６号公報（以下、引用例２という。）には、以下の事項が図面と共に記載されている。
　
　（５）「本発明は、１つ以上の端末装置を、それぞれ通信回線を介して収容し、端末装置の処理要求に応じて処理を行ない処理結果を通信回線を介して返送する端末主導型マイクロメインフレームリンクのセンター装置に関する。
（中略）
本発明の目的は、過去の実績から任意の処理要求の次に発生する処理要求を予想し先行処理することにより処理速度の速い端末主導型マイクロメインフレームリンクのセンター装置を提供することである。」（公報２頁左上欄１３行〜左下欄５行）
　
（６）「また、端末管理部７は端末装置１１．１2．〜１ｎ．の任意の端末装置からあるセションにおける１つ目の処理要求を受けると、処理推論部８に該端末装置の識別コードと該処理要求を通知し、その後、該処理要求を処理実行部１０に通知し、処理実行部１０よりの処理結果が情報交換領域１１2 に通知されると、その処理結果を要求元の端末装置に返送し、また処理推論部８から、推論された次に入力が予想される処理要求（以下予想処理要求と称す）が通知されると、その処理要求を予想要求記憶領域１１１に書込むとともに処理実行部１０に通知し、それに対する処理実行部１０からの処理結果を情報交換領域１１2に格納する。さらに、端末管理部７は前記要求元の端末装置からの２つ目以降の処理要求を受信すると、該端末装置の識別コードと該処理要求を処理推論部８へ転送するとともに予報要求憶領域１１１に格納されている予想処理要求と比較し、一致したものがあると情報交換領域１１2に格納されている該処理要求の処理結果を要求元の端末装置に応答として返送する。」（公報３頁左下欄１４行〜右下欄１４行）
                              
（７）「処理推論部８は端末管理部７よりの端末装置コードと処理要求の転送に基づき、処理推論データベース９の該コードの端末装置の領域内の同一処理要求を検索し、なければ新に登録し、あれば該処理要求の予想処理要求として登録されている処理要求の中から最も登録回数の多い処理要求から例えば３件を検出して端末管理部７へ出力し、その後、続いて端末管理部７から転送を受けた同一端末装置のコードの処理要求については、処理推論データベース９内の該コードの端末装置の領域内の同一処理要求を検索し、無ければ新に登録し、あればその処理要求の予想処理要求中から最も登録回数の多い処理要求から順に３件を検出して端末管理部７へ出力するとともに直前の処理要求の予想処理要求として登録する。」（公報４頁左上欄２行〜１７行）
　
（８）「次に、本実施例の処理推論部８と端末管理部７の動作について説明する。
　端末管理部７より要求元の端末装置の識別結果が通知されると、処理推論部８は処理推論データベース９の識別レコード１２を検索する。次に、端末管理部７より要求内容が通知されると、その識別レコード１２から検索された端末装置に関する要求内容レコード１３を検索する。そして、その要求内容レコード１３から検索された処理要求に関する予想処理要求を予想要求内容レコード１４（このレコードは発生頻度の高い順にソートされている）から高頻度の順位に従って順次読取り、それを逐次端末管理部７へ推論結果として通知する。」（公報４頁右上欄９行〜左下欄２行）
　
　以上より、引用例２には処理要求の予測手法として以下の事項が記載されている。
　
　過去の実績から任意の処理要求の次に発生する処理要求を予測し先行処理するものであって、
　（Ａ）１つ目の処理要求を受けると、該処理要求を処理推論部に通知し、
　（Ｂ）１つ目の処理要求及び次に同一端末装置からの処理要求を予想要求内容レコードとしてソートして処理推論データベースに登録し、
　（Ｃ）１つ目の処理要求に基づき、処理推論データベースを検索し、予想処理要求として最も登録回数の多い処理要求から出力するもの
　
　また、原査定の拒絶の理由に引用された「日経コンピュータ　１９９５．７．１０（ｎｏ．３６９）（１９９５年）、ｐ７５−ｐ７６」（以下、引用例３という。）には、以下の事項が図面と共に記載されている。
　
（９）「ＷＷＷを機能拡張するソフトプログラムの転送・実行が可能に
（中略）
クライアントでプログラムを実行
　Javaの最大の特徴はデータとプログラムを一体化し、プログラムそのものをクライアント上で実行できることだ。
　現在のＷＷＷはサーバー上でしかプログラムを実行できない。クライアント側は転送されてきたデータを表示するか、ファイルとしてダウンロードするしかなかった。
　（中略）
これに対し、Javaを使う環境では、データとプログラムを一体化した「アプレット」と呼ぶオブジェクトをやり取りする（７５ページの図１）。(1)クライアントはＷＷＷサーバーをアクセスし、(2)必要なアプレットをクライアント側に転送し、(3)クライアントのJavaインタプリタが転送されたアプレットを実行する、という仕組みだ。」
　
３．対比
   本願発明（以下、前者という）と引用文献１に記載された発明（以下、後者という）とを比較すると、
前者の「データ処理ネットワーク」「ホストデータ処理システム」「ターゲット・データ処理システム」「前記ターゲット・システムに自動的に転送するステップ」は、それぞれ、後者の「ホストプロセッサとワークステーションが接続された分散処理システム」「ホスト」「ワークステーション」「前記ワークステーションに自発的に送信するステップ」に相当する。
　また、前者の「ソフトウエア・モジュール」と後者の「オブジェクト」とは、ターゲットシステムへの転送対象という点で対応している。
また、両者とも、ホストシステムにおいて、事前に転送対象を予測する手法を用いる点で一致している。
　してみると、両者は次の点で一致している。
　
　データ処理ネットワーク中で転送対象をホスト・データ処理システムからターゲット・データ処理システムにプリエンプティブに転送する方法であって、
　前記ホスト・システムのところで、転送対象を予測する手法を用いて前記ターゲット・システムのところで必要とされるであろう転送対象を予測するステップと、
　前記転送対象を前記ターゲット・システムに自動的に転送するステップとを含む方法
　
　一方、両者は以下の点で相違している。
　
相違点１
  ホスト・データ処理システムからターゲット・システムへの転送対象が、後者ではオブジェクトであるのに対し、前者ではターゲット・システム上で実行するためのソフトウエア・モジュールである点
　
相違点２
　ホスト・データ処理システムで行われる転送対象を予測する手法が、後者では、事前発見的手法により利用者のニーズや希望を予測するものであるのに対し、前者では、第１のソフトウエア・モジュールのタイプを決定するステップと各ターゲット・システムにおけるソフトウエア・モジュール使用の履歴をコンパイルするステップと、前記第１のモジュールのタイプの決定および前記コンパイルされた履歴に基づいて、次に前記ターゲット・システムのところで必要とされるであろう第２のソフトウェア・モジュールのタイプを予測するステップを有するものである点
　
４．相違点についての検討
 （１）相違点１について
　後者における「オブジェクト」とは、上記２．（１）に「オブジェクト（データや処理ルーチン）」という記載があり、処理プログラムを含むものかどうか明確ではないが、上記２．（２）ではオブジェクトの例として、電子メールとカレンダーが示されているから、一応データと解釈するのが妥当と思われる。これに対し、前者においては転送対象は「ターゲット・システムのところで異なるサービスを提供する複数のタイプのソフトウェア・モジュール」と明確に規定されているから、「ソフトウエア・モジュール」とは処理プログラムのことである。
このように前者と後者では、転送対象が「処理プログラム」か「データ」という違いがある。しかしながら、分散処理システムでは処理をホスト側で行うかクライアント側で行うかはホスト側、クライアント側の処理装置や通信のの能力等に応じて適宜決定すべき設計的事項に属することであり、上記２．（９）に「Javaの最大の特徴はデータとプログラムを一体化し、プログラムそのものをクライアント上で実行できることだ。
　現在のＷＷＷはサーバー上でしかプログラムを実行できない。クライアント側は転送されてきたデータを表示するか、ファイルとしてダウンロードするしかなかった。」と記述されているように、従来ホストで行っていた処理をクライアント側で行う趨勢にあり、その場合にはクライアント側で処理を行うための処理プログラムをクライアント側に転送することになる。
　このように、分散システムの進展に伴い、転送対象がデータから処理プログラムになってきているから、相違点１を格別のものということはできない。
　
 （２） 相違点２について
　後者における「事前発見的手法」は利用者のニーズや希望を取り入れたものではあるが、具体的な予測の構成は明確ではない。上記２．（２）（３）に示される電子メールやカレンダーの例を見ても電子メールでは新たに到着したメール、カレンダーでは利用者がチェックする可能性が高い今週、次の週或はその２週間を事前にワークステーション側に送信しておけば効率がよいということが伺えるだけであり、結局のところ、事前に転送する対象は設計段階で予め決められていると見るのが妥当である。
これに対し、後者と同じ課題を解決するものとして、２．引用例で認定したように、引用例２には処理要求を予測する手法として以下の事項が記載されている。
　過去の実績から任意の処理要求を予測し先行処理するものであって、
　（Ａ）１つ目の処理要求を受けると、該処理要求を処理推論部に通知し、
　（Ｂ）１つ目の処理要求及び次に同一端末装置からの処理要求を予想要求内容レコードとしてソートして処理推論データベースに登録し、
　（Ｃ）１つ目の処理要求に基づき、処理推論データベースを検索し、予想処理要求として最も登録回数の多い処理要求から出力するもの
　
　一方、前者における転送対象を予測する手法では、以下のステップを持つ（説明の都合上、分節して番号を付ける）。
（ア）第１のソフトウエア・モジュールのタイプを決定するステップと
（イ）各ターゲット・システムにおけるソフトウエア・モジュール使用の履歴をコンパイルするステップと、
（ウ）前記第１のモジュールのタイプの決定および前記コンパイルされた履歴に基づいて、次に前記ターゲット・システムのところで必要とされるであろう第２のソフトウェア・モジュールのタイプを予測するステップ
　
　ここで、（ア）では「タイプを決定する」とされているが、実施例を詳細に見ても、クライアントが最初に要求するソフトウエア・モジュール（例えば、カレンダ・ソフトウエア・モジュールや電子メール・モジュール）から、次のソフトウエア・モジュールを予測しているのであるから、ここにおけるソフトウエア・モジュールのタイプとは、ソフトウエア・モジュールそのものと相違しないものと考えられる。また、実施例を見ると、最初のソフトウエア・モジュールはクライアントに要求により決定されているから、その点でも引用例２のものと変わるところがない。さらに、引用例２の処理要求を予測する手法における「処理要求」とは、処理プログラムからなるルーチンを要求することであるから、結局のところ、前者の（ア）のステップは、引用例２の処理要求を予測する手法の（Ａ）と実質的に同等のものである。
また、引用例２の処理要求を予測する手法の（Ｂ）における「予想要求内容レコードをソートすること」は、前者の手法の（イ）における「履歴をコンパイルする」に相当するものであるから、前者の手法の（イ）のステップと、引用例２の処理要求を予測する手法の（Ｂ）とは実質的に同等のものである。
　従って、引用例２の処理要求を予測する手法は、前者の転送対象を予測する手法と実質的に同等のものである。そして、後者において、事前発見的手法として、課題を同じくする引用例２の上記処理要求を予測する手法を適用することは当業者が容易に為し得ることであるから、相違点２を格別のものということはできない。
　
５．むすび
　したがって、本願発明は引用例１−３に記載された発明に基いて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。