【事件の表示】
　特願２００６−　７３２２５「動的にリンクするプログラムのオーバーレイのための方法及び装置」拒絶査定不服審判事件〔平成１８年１１月３０日出願公開、特開２００６−３２３８２９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１８年３月１６日（パリ条約による優先権主張２００５年３月１８日、米国）の出願であって、平成２１年３月１９日付けで拒絶理由が通知され、同年５月２５日付けで手続補正がなされ、同年６月１９日付けで拒絶査定がなされ、これに対し、同年９月１８日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。そして、同年１１月４日付けで審査官から前置報告がなされ、平成２２年１２月２２日付けで当審より審尋がなされ、平成２３年３月３日付けで回答書が提出されたものである。
　
第２．平成２１年９月１８日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２１年９月１８日付けの手続補正を却下する。
　
［理由］
１．本件補正
　平成２１年９月１８日付けの手続補正（以下、「本件補正」という。）の内容は、
　平成２１年５月２５日付けの手続補正により補正された特許請求の範囲の請求項２９及び３０の記載
「【請求項２９】
　少なくとも１つのソフトウェアプログラムモジュールを、前記ソフトウェアプログラムのメインモジュール及び複数のサブモジュールを格納している記憶媒体から、プロセッサのローカルメモリにロードするステップと、
　前記記憶媒体及び前記ローカルメモリの少なくとも一方に存在するアドレステーブルを更新するステップであって、前記アドレステーブルは前記モジュールの各々に対応する少なくとも１つのエントリを有し、各エントリは、
　（ｉ）プロセッサのローカルメモリ内での、対応するモジュールが配置された先のアドレスを表すデスティネーションアドレスと、
　（ｉｉ）前記記憶媒体内での、前記対応するモジュールの元のアドレスを表すソースアドレスと、
　の少なくとも１つを含むものであり、かつ、前記アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応するモジュールがコピーされた先のアドレスを表すように更新されるものであるステップと、
　をコンピュータに実行させるためのコンピュータプログラム。
　　【請求項３０】
　請求項２９に記載のコンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体。」（以下、この特許請求の範囲に記載された請求項２９及び３０をそれぞれ「補正前の請求項２９」及び「補正前の請求項３０」という。）を、
　
「【請求項２６】
　第１のソフトウェアプログラムモジュールを、前記ソフトウェアプログラムのメインモジュール及び複数のサブモジュールを格納している記憶媒体から、第１のプロセッサのローカルメモリにロードするステップと、
　前記記憶媒体及び前記ローカルメモリの少なくとも一方に存在するアドレステーブルを更新するステップであって、前記アドレステーブルは前記モジュールの各々に対応する少なくとも１つのエントリを有し、各エントリは、
　（ｉ）前記第１のプロセッサのローカルメモリ内での、対応するモジュールが配置された先のアドレスを表すデスティネーションアドレスと、
　（ｉｉ）前記記憶媒体内での、前記対応するモジュールの元のアドレスを表すソースアドレスと、
　の少なくとも１つを含むものであり、かつ、前記アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応するモジュールがコピーされた先のアドレスを表すように更新されるものであるステップと、
　前記第１のソフトウェアプログラムモジュールから第２のソフトウェアプログラムモジュールを第２のプロセッサのローカルメモリ内に呼び出すステップと、
　前記第１のソフトウェアプログラムモジュールから第２のプロセッサのローカルメモリ内の前記第２のソフトウェアプログラムモジュールを値により呼び出すステップであって、前記第２のプロセッサの前記ローカルメモリは前記モジュールの各々に対応する少なくとも１つのエントリを有するアドレステーブルを有し、各エントリは、
　（ｉ）対応するローカルメモリ内で、対応するモジュールが配置された先のアドレスを表すデスティネーションアドレスと、
　（ｉｉ）前記記憶媒体内での、前記対応するモジュールの元のアドレスを表すソースアドレスと、を有するものであるステップと、
　をコンピュータに実行させるためのコンピュータプログラム。
　　【請求項２７】
　請求項２６に記載のコンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体。」（以下、この特許請求の範囲に記載された請求項２６及び２７をそれぞれ「補正後の請求項２６」及び「補正後の請求項２７」という。）
　に補正することを含むものである。
　　
２．補正の適否 
（１）補正の目的要件
　補正後の請求項２６及び補正後の請求項２７は、その記載からして、それぞれ補正前の請求項２９及び補正前の請求項３０に対応したものである。
　
　そこで、補正前の請求項２９についてする補正（補正後の請求項２６）が、特許法第１７条の２第４項に規定する要件を満たすかどうか、検討する。
　
　補正後の請求項２６は、その記載からして、少なくとも次の発明特定事項（ａ）及び（ｂ）を含んでいる。
　  
（ａ）「前記第１のソフトウェアプログラムモジュールから第２のソフトウェアプログラムモジュールを第２のプロセッサのローカルメモリ内に呼び出すステップ」。
　
（ｂ）前記第１のソフトウェアプログラムモジュールから第２のプロセッサのローカルメモリ内の前記第２のソフトウェアプログラムモジュールを値により呼び出すステップ」。
　
　（ａ）及び（ｂ）について検討する。  
　補正後の請求項２６の含む発明特定事項（ａ）「前記第１のソフトウェアプログラムモジュールから第２のソフトウェアプログラムモジュールを第２のプロセッサのローカルメモリ内に呼び出すステップ」及び（ｂ）前記第１のソフトウェアプログラムモジュールから第２のプロセッサのローカルメモリ内の前記第２のソフトウェアプログラムモジュールを値により呼び出すステップ」は、いずれも、補正前の請求項２９の発明特定事項である「少なくとも１つのソフトウェアプログラムモジュールを、前記ソフトウェアプログラムのメインモジュール及び複数のサブモジュールを格納している記憶媒体から、プロセッサのローカルメモリにロードするステップ」及び「前記記憶媒体及び前記ローカルメモリの少なくとも一方に存在するアドレステーブルを更新するステップ」を限定するものでなく、また概念的に下位にしたものでもない。
　
　そして、新たな発明特定事項（ａ）及び（ｂ）を追加することで、補正後の請求項２６に記載された発明は、第１のプロセッサのローカルメモリ内の第１のソフトウェアプログラムモジュールから第２のプロセッサのローカルメモリ内の第２のソフトウェアプログラムモジュールをどのように呼び出すかという課題を解決するものであって、補正前の請求項２９に記載された発明特定事項である「ソフトウェアプログラムのメインモジュール及び複数のサブモジュールを格納している記憶媒体から、プロセッサのローカルメモリにロードするステップ」及び「前記記憶媒体及び前記ローカルメモリの少なくとも一方に存在するアドレステーブルを更新するステップ」が解決しようとする課題（すなわち、少なくとも１つのソフトウェアプログラムモジュールを、記憶媒体から、プロセッサのローカルメモリにどのようにロードするかという課題）とは異なる新たな課題を解決しようとするものである。
　
　よって、補正前の請求項２９についてする補正は、補正前の請求項２９に記載した発明を特定するために必要な事項を限定したものではなく、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものとは認められない。
　また、補正前の請求項２９についてする補正が、特許法第１７条の２第４項第１号の請求項の削除、第３号の誤記の訂正、第４号の明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）に該当するものとも認められない。  
　以上のとおり、補正前の請求項２９についてする補正は、特許法第１７条の２第４項の規定に違反するものであり、したがって、前記補正前の請求項２９についてする補正を含む本件補正は、特許法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。 
　
３．結語
　本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項（補正の目的）の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２１年９月１８日付けの手続補正は上記のとおり却下されたので、本願の請求項２９に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成２１年５月２５日付け手続補正書の特許請求の範囲の請求項２９に記載された事項により特定される、以下のとおりのものである。  
　
「少なくとも１つのソフトウェアプログラムモジュールを、前記ソフトウェアプログラムのメインモジュール及び複数のサブモジュールを格納している記憶媒体から、プロセッサのローカルメモリにロードするステップと、
　前記記憶媒体及び前記ローカルメモリの少なくとも一方に存在するアドレステーブルを更新するステップであって、前記アドレステーブルは前記モジュールの各々に対応する少なくとも１つのエントリを有し、各エントリは、
　（ｉ）プロセッサのローカルメモリ内での、対応するモジュールが配置された先のアドレスを表すデスティネーションアドレスと、
　（ｉｉ）前記記憶媒体内での、前記対応するモジュールの元のアドレスを表すソースアドレスと、
　の少なくとも１つを含むものであり、かつ、前記アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応するモジュールがコピーされた先のアドレスを表すように更新されるものであるステップと、
　をコンピュータに実行させるためのコンピュータプログラム。」
　
２．引用文献
　原査定の拒絶の理由に引用された特開平７−３６７８３号公報（以下、「引用文献」という）には、図面とともに次の事項が記載されている。
　 
（ア）「【０００３】
【発明が解決しようとする課題】ユーザーメモリエリアの容量が大きい場合は、必要なユーザープログラムを全てユーザーメモリエリアにロードしておくことができるが、ユーザーメモリエリアが小さい場合には、複数のユーザープログラムを処理が終了する度に順次ユーザーメモリエリアにロードしなおさなくてはならず、従って、このような場合には、プログラムを記憶するディスク装置等の二次記憶装置に対するアクセスが頻繁に起こり、プログラムロードのための処理時間が非常に長くなるという課題があった。」
　
（イ）「【０００９】
【実施例】本システムは、複数のユーザーＡ，Ｂ，…‥，Ｍが、各々、同時に異なる業務を実行するマルチタスク処理が可能なシステムであって、図１にそのシステム構成を示す。図示のように、複数のユーザーＡ，Ｂ，…‥，Ｍに対して、各々、ユーザープログラムをロードするためのユーザーメモリエリア２ａ，２ｂ，…‥，２ｍが用意され、利用される複数種類のユーザープログラムは二次記憶装置としてのハードディスク装置１に格納されている。このユーザープログラムは、各々異なる業務を遂行するためのアプリケーションプログラムであって特定の言語で記述されており、このため、各ユーザーごとにインタプリタ等の言語プロセッサ３ａ，３ｂ，…‥，３ｍが用意され、このプログラムを介して処理が実行される。
【００１０】…
【００１１】ところで、本実施例では、ディスク装置１から読み出したユーザープログラムを蓄える所謂キャッシュメモリとして、拡張メモリ４を設けており、ユーザープログラム自体を記憶するセグメントメモリ５と、そのインデックス情報を記憶するセグメントインデックステーブル６より構成されている。そして、このようなセグメントの管理はセグメント管理プログラムＳＭＲ８によって行われている。
【００１２】…
【００１３】次に、セグメントインデックステーブル６とセグメントメモリ５の内容について、図６，７を用いて説明する。セグメントメモリ５は、図７に示すように、１セグメントが、ユーザープログラム自体を記憶するセグメント部と、セグメントインデックスＮＯ（ＳＩＮＯ）等の管理情報を記憶するメモリ管理部とより成り、１つのユーザープログラムを記憶するのに用いられる。セグメントメモリ５には、このようなセグメントが複数用意されており、従って、複数のユーザープログラムを記憶することが可能である。
【００１４】一方、セグメントインデックステーブル６は、図６のように、インデックス番号順に各セグメントのインデックス情報を記憶するものであり、インデックス情報としては、セグメントインデックスＮＯ（ＳＩＮＯ），ディスクアドレス，セグメントメモリオフセット，ロードメモリアドレス，ロードセグメントサイズを含む。ここで、セグメントメモリオフセットとは、対応するユーザープログラムが記憶されたセグメントメモリ５上の位置を示す値である。…」
　
（ウ）「【００１５】以下、本システムの動作を図２，３，４のフローチャートを参照しながら説明する。まず、ユーザーＡが、新たなユーザープログラムＰＲ１を電源投入後初めて必要になったとする。この場合、言語プロセッサ３ａは、新たなユーザープログラムＰＲ１をロードするためのロード要求を、システムインターフェースプログラムＡＣＲ９に発する。
【００１６】…
【００１７】…
【００１８】そこで、ＡＣＲ９は、セグメントインデックステーブル６から、変換したディスクアドレスを含むセグメントインデックスをサーチし、存在するときは、セグメントメモリオフセットに基づき、セグメントメモリ５の対応するセグメントから目的のユーザープログラムＰＲ１を読み出し、ユーザーメモリエリア２ａにロードする。サーチの結果、変換したディスクアドレスを含むセグメントインデックスがないときは、ＡＣＲ９はセグメント管理プログラムＳＭＲ８に新たなセグメントの登録を要求する。
【００１９】登録の要求を受けたＳＭＲ８は、図４に示すように、空きポインタＥＰに基づきセグメントインデックステーブル６に空きがあるか調べ、空きがあるときはその領域を新たなユーザープログラムの登録のために確保し、空きがないときは、使用中ポインタＵＰに基づき最も古いセグメントを解放し、その領域を新たなユーザープログラムの登録のために確保する。
【００２０】次に、ＳＭＲ８は、ロード要求中のディスクアドレスに基づき目的のユーザープログラムＰＲ１をディスク装置１から読み出し、セグメントメモリ５の確保したセグメントに書き込む。また、ＳＭＲ８は、そのときの内部のカウント値ｎを登録番号として付与し、この登録番号と確保したセグメントのインデックス番号からＳＩＮＯを生成して、そのＮＯをセグメントインデックステーブル６に書き込む。セグメントインデックステーブル６には、さらに、ユーザープログラムを記憶したセグメントメモリ５上のオフセットと、ディスク装置１からユーザープログラムと共に読み出したディスクアドレス及びロードメモリアドレス，ロードセグメントサイズを書き込む。そして、最後に、登録したＳＩＮＯをＡＣＲ９に返送し、且つ、カウント値ｎをインクリメントする。
【００２１】このようにしてセグメントの登録が終了すると、ＡＣＲ９は、返送されたＳＩＮＯをロード要求を発した言語プロセッサ３ａに送出し、且つ、そのＳＩＮＯに基づき新たに登録したセグメントから目的のユーザープログラムＰＲ１を読み出し、ユーザーメモリエリア２ａにロードする。ロードするときは、セグメントインデックステーブル６のロードメモリアドレスが参照され、ユーザーメモリエリア２ａのそのアドレスにプログラムがロードされる。
【００２２】以上のように、要求されたユーザープログラムは、要求元のユーザーメモリエリアにロードされると共に、キャッシュメモリとしてのセグメントメモリ５に蓄えられることとなる。…」
　
（エ）「【図１】」を参照すると、引用文献記載のシステムにおいて、ユーザーに対応して、言語プロセッサ及び該言語プロセッサに対応するユーザーメモリエリアが用意されている。
　
　（イ）の段落【００１１】における記載「ユーザープログラムを蓄える所謂キャッシュメモリとして、拡張メモリ４を設けており、ユーザープログラム自体を記憶するセグメントメモリ５と、そのインデックス情報を記憶するセグメントインデックステーブル６より構成されている。」、（イ）の段落【００１３】における記載「セグメントメモリ５には、このようなセグメントが複数用意されており、従って、複数のユーザープログラムを記憶することが可能である。」、（ウ）の段落【００１５】における記載「言語プロセッサ３ａは、新たなユーザープログラムＰＲ１をロードするためのロード要求を、システムインターフェースプログラムＡＣＲ９に発する。」、（ウ）の段落【００１８】における記載「…セグメントインデックスをサーチし、存在するときは、セグメントメモリオフセットに基づき、セグメントメモリ５の対応するセグメントから目的のユーザープログラムＰＲ１を読み出し、ユーザーメモリエリア２ａにロードする。」、（ウ）の段落【００２１】における記載「このようにしてセグメントの登録が終了すると、ＡＣＲ９は、…新たに登録したセグメントから目的のユーザープログラムＰＲ１を読み出し、ユーザーメモリエリア２ａにロードする。」、及び（ウ）の段落【００２２】における記載「以上のように、要求されたユーザープログラムは、要求元のユーザーメモリエリアにロードされる…」から、引用文献には、少なくとも１つのユーザープログラムを、複数のユーザープログラムを格納している拡張メモリから、言語プロセッサのユーザーメモリエリアにロードするステップを、システムインターフェースプログラムＡＣＲ９が、コンピュータに実行させることが記載されている。
　
　（イ）の段落【０００９】における記載「複数のユーザーＡ，Ｂ，…‥，Ｍに対して、各々、ユーザープログラムをロードするためのユーザーメモリエリア２ａ，２ｂ，…‥，２ｍが用意され、…」、（イ）の段落【０００９】における記載「各ユーザーごとにインタプリタ等の言語プロセッサ３ａ，３ｂ，…‥，３ｍが用意され、…」及び（エ）の【図１】に関する説明「ユーザーに対応して、言語プロセッサ及び該言語プロセッサに対応するユーザーメモリエリアが用意されている」から、前記ユーザーメモリエリアは前記言語プロセッサが前記ユーザーメモリエリア内にあるユーザープログラムを実行するように、前記言語プロセッサに対応して用意されたユーザーメモリエリアであると解される。
　
　（イ）の段落【００１１】における記載「拡張メモリ４を設けており、ユーザープログラム自体を記憶するセグメントメモリ５と、そのインデックス情報を記憶するセグメントインデックステーブル６より構成されている。」、（イ）の段落【００１４】における記載「セグメントインデックステーブル６は、図６のように、インデックス番号順に各セグメントのインデックス情報を記憶するものであり、インデックス情報としては、セグメントインデックスＮＯ（ＳＩＮＯ），ディスクアドレス，セグメントメモリオフセット，ロードメモリアドレス，ロードセグメントサイズを含む。ここで、セグメントメモリオフセットとは、対応するユーザープログラムが記憶されたセグメントメモリ５上の位置を示す値である。」、及び（ウ）の段落【００２１】における記載「ロードするときは、セグメントインデックステーブル６のロードメモリアドレスが参照され、ユーザーメモリエリア２ａのそのアドレスにプログラムがロードされる。」から、前記拡張メモリはセグメントインデックステーブルを有し（すなわち、セグメントインデックステーブルは前記拡張メモリに存在し）、前記セグメントインデックステーブルは前記ユーザープログラムの各々に対応する少なくとも１つのインデックス情報を有し、各インデックス情報は、
　（ｉ）言語プロセッサのユーザーメモリエリア内での、対応するユーザープログラムが配置された先のアドレスを表すロードメモリアドレスと、
　（ｉｉ）前記拡張メモリ内での、前記対応するユーザープログラムの記憶されたセグメントメモリ上の位置を表すセグメントメモリオフセットと、
　の少なくとも１つを含む、と解される。
　
　（ウ）の段落【００１８】における記載「ＡＣＲ９はセグメント管理プログラムＳＭＲ８に新たなセグメントの登録を要求する。」、（ウ）の段落【００１９】における記載「登録の要求を受けたＳＭＲ８は、…空きポインタＥＰに基づきセグメントインデックステーブル６に空きがあるか調べ、空きがあるときはその領域を新たなユーザープログラムの登録のために確保し、空きがないときは、使用中ポインタＵＰに基づき最も古いセグメントを解放し、その領域を新たなユーザープログラムの登録のために確保する。」、（ウ）の段落【００２０】における記載「次に、ＳＭＲ８は、ロード要求中のディスクアドレスに基づき目的のユーザープログラムＰＲ１をディスク装置１から読み出し、セグメントメモリ５の確保したセグメントに書き込む。また、ＳＭＲ８は、そのときの内部のカウント値ｎを登録番号として付与し、この登録番号と確保したセグメントのインデックス番号からＳＩＮＯを生成して、そのＮＯをセグメントインデックステーブル６に書き込む。セグメントインデックステーブル６には、さらに、ユーザープログラムを記憶したセグメントメモリ５上のオフセットと、ディスク装置１からユーザープログラムと共に読み出したディスクアドレス及びロードメモリアドレス，ロードセグメントサイズを書き込む。」、及び（ウ）の段落【００２１】における記載「ＡＣＲ９は、…そのＳＩＮＯに基づき新たに登録したセグメントから目的のユーザープログラムＰＲ１を読み出し、ユーザーメモリエリア２ａにロードする。ロードするときは、セグメントインデックステーブル６のロードメモリアドレスが参照され、ユーザーメモリエリア２ａのそのアドレスにプログラムがロードされる。」からすると、引用文献には、前記拡張メモリに存在するセグメントインデックステーブルを更新するステップであって、前記セグメントインデックステーブルの前記ロードメモリアドレスが、前記ユーザーメモリエリア内で前記対応するユーザープログラムのロード先（すなわち、コピー先）アドレスを表すように更新されるものであるステップを、システムインターフェースプログラムＡＣＲ９及びセグメント管理プログラムＳＭＲ８が、コンピュータに実行させることが記載されている。
　
　なお、システムインターフェースプログラムＡＣＲ９及びセグメント管理プログラムＳＭＲ８を、簡単のため、以下「管理プログラム」という。
　
　したがって、引用文献には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
　少なくとも１つのユーザープログラムを、複数のユーザープログラムを格納している拡張メモリから、言語プロセッサのユーザーメモリエリアにロードするステップであって、前記ユーザーメモリエリアは前記言語プロセッサが前記ユーザーメモリエリア内にあるユーザープログラムを実行するように、前記言語プロセッサに対応して用意されたユーザーメモリエリアである、前記ロードするステップと、
　前記拡張メモリに存在するセグメントインデックステーブルを更新するステップであって、前記セグメントインデックステーブルは前記ユーザープログラムの各々に対応する少なくとも１つのインデックス情報を有し、各インデックス情報は、
　（ｉ）言語プロセッサのユーザーメモリエリア内での、対応するユーザープログラムが配置された先のアドレスを表すロードメモリアドレスと、
　（ｉｉ）前記拡張メモリ内での、前記対応するユーザープログラムの記憶されたセグメントメモリ上の位置を表すセグメントメモリオフセットと、
　の少なくとも１つを含むものであり、かつ、前記セグメントインデックステーブルの前記ロードメモリアドレスが、前記ユーザーメモリエリア内で前記対応するユーザープログラムのコピー先アドレスを表すように更新されるものであるステップと、
　をコンピュータに実行させるための管理プログラム。
　　 
３．対比 
　ここで、本願発明と引用発明とを比較する。 
　引用発明の「拡張メモリ」、「言語プロセッサ」、及び「ユーザーメモリエリア」は、それぞれ本願発明の「記憶媒体」、「プロセッサ」、及び「ローカルメモリ」に相当する。
　引用発明の「セグメントインデックステーブル」、「インデックス情報」、「ロードメモリアドレス」、及び「セグメントメモリオフセット」は、それぞれ本願発明の「アドレステーブル」、「エントリ」、「デスティネーションアドレス」、及び「ソースアドレス」に相当する。
　引用発明の「セグメントインデックステーブル」は「拡張メモリに存在する」ことから、前記「セグメントインデックステーブル」が、拡張メモリ及びユーザーメモリエリアの少なくとも一方に存在することは自明であるから、引用発明の「拡張メモリに存在するセグメントインデックステーブル」は、本願発明の「記憶媒体及びローカルメモリの少なくとも一方に存在するアドレステーブル」に相当する。
　引用発明の「管理プログラム」は、本願発明の「コンピュータプログラム」に相当する。
　
　引用発明の「ユーザープログラム」と本願発明の「ソフトウェアプログラムモジュール」とはともに、メモリにロードされてプロセッサにより実行される実行形式プログラムである点で共通する。
　引用発明の「セグメントインデックステーブルの前記ロードメモリアドレスが、前記ユーザーメモリエリア内で前記対応するユーザープログラムのコピー先アドレスを表すように更新される」ことと本願発明の「アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応するモジュールがコピーされた先のアドレスを表すように更新される」こととはともに、アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応する実行形式プログラムのアドレスを表すように更新される点で共通する。
　　
　よって、本願発明と引用発明とは、以下の点で一致し、また、相違している。 
　 
（一致点） 
　少なくとも１つの実行形式プログラムを、複数の実行形式プログラムを格納している記憶媒体から、プロセッサのローカルメモリにロードするステップと、
　前記記憶媒体に存在するアドレステーブルを更新するステップであって、前記アドレステーブルは前記実行形式プログラムの各々に対応する少なくとも１つのエントリを有し、各エントリは、
　（ｉ）プロセッサのローカルメモリ内での、対応する実行形式プログラムが配置された先のアドレスを表すデスティネーションアドレスと、
　（ｉｉ）前記記憶媒体内での、前記対応する実行形式プログラムの元のアドレスを表すソースアドレスと、
　の少なくとも１つを含むものであり、かつ、前記アドレステーブルの前記デスティネーションアドレスが、前記ローカルメモリ内で前記対応する実行形式プログラムのアドレスを表すように更新されるものであるステップと、
　をコンピュータに実行させるためのコンピュータプログラム。
　
（相違点１）
　「実行形式プログラム」について、本願発明は「ソフトウェアプログラムモジュール」であるのに対して、引用発明は、「ユーザープログラム」である点。
　
（相違点２）
　「複数の実行形式プログラム」について、本願発明は「ソフトウェアプログラムのメインモジュール及び複数のサブモジュール」であるのに対して、引用発明は、「複数のユーザープログラム」である点。
　
（相違点３）
　本願発明は、アドレステーブルのデスティネーションアドレスが、ローカルメモリ内で対応するモジュールがコピーされた先のアドレスを表すように更新されるのに対して、引用発明は、セグメントインデックステーブルのロードメモリアドレスが、ユーザーメモリエリア内で対応するユーザープログラムのコピー先アドレスを表すように更新される点。
　
４．判断 
　相違点１〜相違点３について検討する。
　プログラムをメインモジュールと複数のサブモジュールとして構成して、メインモジュールとサブモジュールとを個別にメモリにロードして、各モジュールのロードアドレスをアドレステーブルで管理すること、そして、モジュールをメモリにロードする際に、前記アドレステーブルの前記モジュールのロードアドレスを前記ロード先アドレスを表すように動的に更新することは、当業者にとって周知の事項（以下、「周知技術」という）である。
（例えば、特開昭６１−２０４７４０号公報における記載
「プログラムを実行中に命令「ＣＡＬＬ　Ｘ」により、サブルーチンＸの実行を開始する。…　該当ルーチンがメモリ上にロードされているか否かを調べる。具体的には第１図の１０のアドレス管理テーブルを参照する。１０には各サブルーチンのメモリ上のロードアドレスが格納されており、もし未ロードならば０などの特殊な値が設定されている。
　未ロードと判断された時は、メモリ上の空きエリアの先頭をロードアドレスとし、…プログラムライブラリより該当ルーチンをメモリ上にロードする。同時にロードアドレスを１０に登録する。」（２頁左下欄１５行目〜右下欄１６行目）、及び特開平４−２６７４３６号公報における記載
「【００１１】図２はＲＡＭ６上にロードされるアプリケーションプログラムやデータの配置を示す。図において、９はシステムプログラムにより使用されるシステム作業域、１０はロードモジュールのロードアドレス，大きさを管理するロードモジュールテーブル、１１は最初に起動されるメインモジュール、１２〜１４は各業務処理を行う業務モジュール、１５はデータ領域、１６は空き領域である。」、
「【００１６】一般に、プログラムは業務毎にモジュールに分割して作成、ロードされる。本実施例によるロード方式では図２のようにロードされる。最初に起動されるメインモジュール１１は、図のように他のモジュールより下位アドレス側にロードされる。　…　業務１モジュール１２は本発明によるプログラムロードをシステムプログラムに要求するプログラムで、図２のようにメインモジュール１１の次にロードしておく。業務２，業務３モジュール１３，１４は任意の業務処理プログラムである。」、
「【００１８】また、図４図示フローチャートの…ステップＳ２１で…追加モジュールであると判断された時も、あらかじめロードモジュールテーブルに追加用エントリを設けておくことにより、業務モジュールの追加にも容易に対応できる。」等参照。）
　そして、引用文献に「【０００３】…ユーザーメモリエリアの容量が大きい場合は、必要なユーザープログラムを全てユーザーメモリエリアにロードしておくことができるが、ユーザーメモリエリアが小さい場合には、複数のユーザープログラムを処理が終了する度に順次ユーザーメモリエリアにロードしなおさなくてはならず、…」と記載されているように、ユーザーメモリエリアに複数のプログラムをロードすることが示唆されていることを勘案すると、引用発明の「ユーザープログラム」に前記周知技術を適用することで、ユーザープログラムをメインモジュール及び複数のサブモジュールで構成し、メインモジュールとサブモジュールとを個別にユーザーメモリエリアにロード（すなわち、モジュール単位でユーザーメモリエリアにロード）して、各モジュールのロードメモリアドレスをセグメントインデックステーブルで管理し、前記セグメントインデックステーブルの前記モジュールのロードメモリアドレスを、前記ロード先アドレスを表すように動的に更新するように構成することは、当業者であれば、容易に想到し得たことである。
　そうすることで、引用発明において、セグメントインデックステーブルのロードメモリアドレスが、ユーザーメモリエリア内で対応するモジュールがコピーされた先のアドレスを表すように更新されることは、論理的に明らかである。
　よって、相違点１〜相違点３は格別のものではない。
　
　上記で検討したごとく、相違点１〜相違点３は格別のものではなく、そして、本願発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、本願発明は、引用発明及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許を受けることができないものである。
　
５．むすび 
　以上のとおり、本願の請求項２９に係る発明は、その出願前日本国内又は外国において頒布された刊行物又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。