2022-018106

第１ 手続の経緯

本願は、２０１８年（平成３０年）２月２８日（優先権主張 ２０１７年３月５日）を出願日とする特許出願であって、その後の手続の概要は、以下のとおりである。

第２ 本願発明

本願請求項１ないし２０に係る発明は、令和４年２月１５日に提出された手続補正書に係る手続補正で補正された特許請求の範囲の請求項１ないし２０に記載された事項により特定される発明であり、このうち請求項２０に係る発明（以下、単に「本願発明」という。）は、以下のとおりの発明である。

「 少なくとも１つのハードウェアプロセッサによって、ジャストインタイム（ＪＩＴ）でコードを生成する方法であって、

ＪＩＴ実行プロセスとＪＩＴコンパイルプロセスとは異なるプロセスであり、前記ＪＩＴ実行プロセスと前記ＪＩＴコンパイルプロセスは、単一の共有メモリを使用し、

前記ＪＩＴ実行プロセスは、前記共有メモリへの書込みアクセス権を持たず、

前記ＪＩＴコンパイルプロセスは、前記共有メモリからの実行アクセス権を持たない、方法。」

第３ 原査定の拒絶の理由

令和４年７月４日付け拒絶査定（以下、「原査定」という。）の拒絶の理由は、この出願の請求項１ないし２０に係る発明は、本願の優先権主張の日（以下「優先日」という。）前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１及び２に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものである。

第４ 引用文献の記載及び引用発明

１ 引用文献１について

（２）引用発明

前記（１）アの「ＪａｖａＶＭなど、プログラムを実行時にコンパイルする言語処理系」より、引用文献１には、「ＪａｖａＶＭ」により「プログラムを実行時にコンパイルする」方法が記載されているといえる。

したがって、前記（１）の特に下線部を着目すると、引用文献１には、以下の発明（以下「引用発明」という。）が記載されているといえる。

「 ＪａｖａＶＭによりプログラムを実行時にコンパイルする方法であって、

ＪａｖａＶＭ１０１はハードディスク１０２にインストールされており、実行時にバス１０３を通じて主記憶１０４に読み込まれ、プロセッサ１０５で実行され、

ＪａｖａＶＭ１０１は、バス１０３を通じてハードディスク１０２からＪａｖａアプリケーション１０６を読み込み、動的コンパイラでコンパイルして実行し、

ＪａｖａＶＭ１０１は、Ｊａｖａアプリケーションの実行を担当するプロセス１０７と動的コンパイラ１０８の、２つのプロセスに分かれて動作し、

それぞれのプロセスは共有メモリ領域１０９によって接続され、

共有メモリ領域１０９の中には、通信用領域１１０と、保護領域１１１があり、通信用領域１１０には、２つのプロセスが通信をおこなうために用いるデータ構造を配置し、保護領域１１１には、動的コンパイラ１０８が生成したコンパイル済コード１１２や、コンパイル済コードのアドレス１１３を登録する表であるディスパッチ表１１４を配置し、

保護領域１１１はＪａｖａアプリケーションの実行を担当するプロセス１０７から書込不可に指定される、

方法。」

２ 引用文献２について

引用文献２には、図面とともに以下の事項が記載されている。

（１）「【００２５】

どのような場合でも、図１Ａは、アプリケーションプログラム１１０がより低い特権モード（たとえば、「ユーザー」モード）で実行され、一方ＪＩＴコンパイラ１０５はより高い特権モード（たとえば、「カーネル」モード）で動作していることも示す。たとえば、図１Ａは、アプリケーションプログラム１１０がユーザー特権を有するユーザーモード１１３で動作し、一方ＪＩＴコンパイラ１０５は対応するカーネル特権を有するカーネルモード１０３で動作していることを示す。さらに、図１Ａは、中間言語コード１１５が、カーネル１０３レベルの特権を有する１つまたは複数の構成要素によってアクセスされることを示す。反対に、また本明細書でより完全に理解されるように、実行コードは、ユーザー１１３レベルの特権で動作する構成要素によってのみ実行されることになる。」

（２）「【００３３】

どのような場合でも、図１Ｂは、ページテーブル１８０が、メモリロケーション１６０および１６５をアドレス空間１７０、１７５、１９０、および１９５に相互に関連付けることを示す。たとえば、メモリロケーション１６０は共有メモリヒープであり、メモリロケーション１６５は、アプリケーションプログラム１１０が実行のためにロードされるロケーションである。さらに、ページテーブル１８０は、アドレス空間１７０および１９０がそれぞれロケーション１６０または１６５への「読み取り／書き込み」アクセスを有するように、メモリロケーション１６０および１６５のアクセス許可をマップする。同様に、ページテーブル１８０は、アドレス空間１７５または１９５についてのメモリロケーション１６０および１６５の許可を「読み取り／実行」としてそれぞれマップする。したがって、セキュリティ構成要素１５５（図１Ａ）がユーザーモード１１３の構成要素から要求（たとえば、１４３）を受け取る場合、セキュリティ構成要素１５５は、要求（たとえば、１４３）を発生した構成要素のアドレス空間を、ＪＩＴコンパイラの出力（たとえば、１２３）のアドレス空間に相互に関連付けることができる。」

（３）「【００４０】

さらに、図２は、その方法が、第２アドレス空間で中間言語命令をコンパイルする動作２２０を含むことを示す。動作２２０は、第２アドレス空間で実行するＪＩＴコンパイラを使用して、１組または複数組の中間言語命令を新規にコンパイルされたコードにコンパイルすることを含む。たとえば、要求１４３の検証時に、セキュリティ構成要素１５５は、１つまたは複数の要求１４７を準備および実行して、要求された中間言語コードをＪＩＴコンパイラ１０５に渡す。ＪＩＴコンパイラ１０５は、次いで、この図では共有メモリヒープ１６０への読み取り／書き込み許可を与えられている、第２アドレス空間１７０で中間言語コード１２０をコンパイルする。

【００４１】

さらに、図２は、その方法が、コンパイルされたコードを共有メモリヒープに渡す動作２３０を含むことを示す。動作２３０は、新規にコンパイルされたコードを、アプリケーションプログラムが新規にコンパイルされたコードを第１アドレス空間に取得できる、共有メモリヒープに渡すことを含む。たとえば、図１Ａおよび図１Ｂは、ＪＩＴコンパイラ１０５およびアプリケーションプログラム１１０が、メモリヒープ１６０へのアクセスを有することを示す。特に、ＪＩＴコンパイラ１０５は、メモリヒープ１６０に書き込める（しかしそこでの実行はできない）が、アプリケーションプログラム１１０は、メモリヒープ１６０からの読み取りおよび実行のみ可能である。したがって、ＪＩＴコンパイラ１０５がコード１２３をコンパイルおよび作成する場合、アプリケーションプログラム１１０用のランタイムは、コンパイルされたコード１２３をアドレス空間１７５に取得でき、そのコードをユーザーモードで実行できる。」

（４）「【図１Ｂ】

［図：0001401443000005.jpg］

」

以上の（１）ないし（４）の特に下線部に着目すると、引用文献２には、次の技術事項（以下、「引用文献２記載事項」という。）が記載されているといえる。

「 アプリケーションプログラム１１０がより低い特権モード（たとえば、「ユーザー」モード）で実行され、一方ＪＩＴコンパイラ１０５はより高い特権モード（たとえば、「カーネル」モード）で動作し、

メモリロケーション１６０は共有メモリヒープであり、メモリロケーション１６５は、アプリケーションプログラム１１０が実行のためにロードされるロケーションであり、

ページテーブル１８０は、アドレス空間１７０および１９０がそれぞれロケーション１６０または１６５への「読み取り／書き込み」アクセスを有するように、メモリロケーション１６０および１６５のアクセス許可をマップし、アドレス空間１７５または１９５についてのメモリロケーション１６０および１６５の許可を「読み取り／実行」としてそれぞれマップし、

ＪＩＴコンパイラ１０５は、共有メモリヒープ１６０への読み取り／書き込み許可を与えられている、第２アドレス空間１７０で中間言語コード１２０をコンパイルし、ＪＩＴコンパイラ１０５は、メモリヒープ１６０に書き込める（しかしそこでの実行はできない）が、アプリケーションプログラム１１０は、メモリヒープ１６０からの読み取りおよび実行のみ可能であり、ＪＩＴコンパイラ１０５がコード１２３をコンパイルおよび作成する場合、アプリケーションプログラム１１０用のランタイムは、コンパイルされたコード１２３をアドレス空間１７５に取得でき、そのコードをユーザーモードで実行できる、こと。」

第５ 当審の判断

１ 対比

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

（１）「ジャストインタイム」とは、“実行時”との意味であり、また、「コンパイル」とは、情報処理の技術分野においては、ソースコードから機械語のコードを生成することであるから、引用発明の「プログラムを実行時にコンパイルする方法」は、本願発明の「ジャストインタイム（ＪＩＴ）でコードを生成する方法」に相当する。

また、引用発明において、「ＪａｖａＶＭ１０１」は、「プロセッサ１０５」で実行されるものであるから、「ＪａｖａＶＭ１０１」による処理は、「プロセッサ１０５」による処理に含まれる。

そして、引用発明の「プロセッサ１０５」は、本願発明の「少なくとも１つのハードウェアプロセッサ」に相当する。

よって、引用発明の「ＪａｖａＶＭ１０１によりプログラムを実行時にコンパイルする方法」は、本願発明の「少なくとも１つのハードウェアプロセッサによって、ジャストインタイム（ＪＩＴ）でコードを生成する方法」に相当する。

（２）引用発明の「ＪａｖａＶＭ１０１は、バス１０３を通じてハードディスク１０２からＪａｖａアプリケーション１０６を読み込み、動的コンパイラでコンパイルして実行し」及び「ＪａｖａＶＭ１０１は、Ｊａｖａアプリケーションの実行を担当するプロセス１０７と動的コンパイラ１０８の、２つのプロセスに分かれて動作し」との構成によれば、「動的コンパイラ１０８」は、「Ｊａｖａアプリケーション１０６」を実行時（ＪＩＴ）にコンパイルする機能を備え、また、「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」は、「動的コンパイラ１０８」によりコンパイルされた「Ｊａｖａアプリケーション」を実行する機能を備え、かつ、「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」と「動的コンパイラ１０８」とは、互いに異なるプロセスといえる。

そして、引用発明の「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」及び「動的コンパイラ１０８」はそれぞれ、本願発明の「ＪＩＴ実行プロセス」及び「ＪＩＴコンパイルプロセス」に相当する。

以上から、引用発明は、本願発明の「ＪＩＴ実行プロセスとＪＩＴコンパイルプロセスとは異なるプロセスであり」に相当する構成を備えているといえる。

（３）本願明細書の【００５０】には、「共有メモリ２０４－１などの１つまたは複数の共有メモリ領域が、記憶装置２０４内に画定される、構築される、初期化される、等があり得る。例えば、共有メモリ２０４－１は、記憶装置２０４内の１つまたは複数のメモリページ、セクタ、等を利用することができる。共有メモリ２０４－１は、実行可能なコードセグメント２２２を格納するために使用されることがある。共有メモリ２０４－１は、異なるアクセス権を用いてプロセス２１０および２１２の各々にマッピングされることがある。」と記載されていることからすれば、本願発明における「共有メモリ」は、それ単独で独立した装置である必要はなく、記憶装置等の一部のメモリ領域である場合を含み、「実行可能なコードセグメント」を格納し、プロセスにアクセス権が設定されるものと認められる。

一方、引用発明の「それぞれのプロセスは共有メモリ領域１０９によって接続され」及び「共有メモリ領域１０９の中には、通信用領域１１０と、保護領域１１１があり」、「保護領域１１１には、動的コンパイラ１０８が生成したコンパイル済コード１１２や、コンパイル済コードのアドレス１１３を登録する表であるディスパッチ表１１４を配置し」、及び、「保護領域１１１はＪａｖａアプリケーションの実行を担当するプロセス１０７から書込不可に指定される」との構成によれば、「保護領域１１１」は、「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」と「動的コンパイラ１０８」とに使用される「共有メモリ領域１０９」の一部のメモリ領域であり、「コンパイル済コード１１２」を格納し、さらに、「書込不可」等のアクセス権が設定されるものであるから、本願発明の「共有メモリ」に相当する。

よって、引用発明と、本願発明の「前記ＪＩＴ実行プロセスと前記ＪＩＴコンパイルプロセスは、単一の共有メモリを使用し」とは、「前記ＪＩＴ実行プロセスと前記ＪＩＴコンパイルプロセスは、共有メモリを使用し」という共通の構成を有しているといえる。

（４）引用発明の「保護領域１１１はＪａｖａアプリケーションの実行を担当するプロセス１０７から書込不可に指定される」ことは、本願発明の「前記ＪＩＴ実行プロセスは、前記共有メモリへの書込みアクセス権を持たず」との構成に相当する。

２ 一致点、相違点

本願発明と引用発明は、以下の点において一致ないし相違する。

（１）一致点

「 少なくとも１つのハードウェアプロセッサによって、ジャストインタイム（ＪＩＴ）でコードを生成する方法であって、

ＪＩＴ実行プロセスとＪＩＴコンパイルプロセスとは異なるプロセスであり、前記ＪＩＴ実行プロセスと前記ＪＩＴコンパイルプロセスは、共有メモリを使用し、

前記ＪＩＴ実行プロセスは、前記共有メモリへの書込みアクセス権を持たない、方法。」

（２）相違点

（相違点１）

一致点に含まれる「共有メモリ」が、本願発明においては、「単一の共有メモリ」であるのに対し、引用発明の「保護領域１１１」は、「単一の」ものであることを具体的に特定していない点。

（相違点２）

本願発明は、「前記ＪＩＴコンパイルプロセスは、前記共有メモリからの実行アクセス権を持たない」との構成を備えるのに対し、引用発明において、「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」及び「動的コンパイラ１０８」のいずれについても、「保護領域１１１」からの実行アクセス権を有するか否かを具体的に特定していない点。

３ 相違点についての判断

（１）相違点１について

引用文献１には、「保護領域１１１」が、複数存在していることは記載ないし示唆されておらず、また、引用文献１の【図１】及び【図３】（上記第４の１（３）及び（５））の記載からは、「保護領域１１１」が１つであることを見て取れる。

また、この技術分野（ＪＩＴコンパイラ）において、引用文献１の「保護領域１１１」と同等のものが複数存在しなければならないことが本願優先日前における技術常識であるとも認められない。

さらに、本願発明における「単一のメモリ」に関し、「単一の」との語を付加する補正は、令和４年２月１５日に提出された手続補正書によりなされたが、同日に提出された意見書において、当該補正の根拠は具体的に示されておらず、また、出願当初の明細書、特許請求の範囲及び図面には、「単一の共有メモリ」は明記されておらず、出願当初の【図２】及び【図３】に、「共有メモリ２０４－１」が１つある例が提示されているのみであるところ、本願発明において、「単一の共有メモリ」すなわち「共有メモリ」が１つのみであることに、格別な技術的意義はないと認められる。

したがって、引用発明における「保護領域１１１」は、本願発明の「単一の共有メモリ」に相当する場合を含むと理解できるから、相違点１は実質的なものではない。

（２）相違点２について

引用文献２記載事項にあるように、「ＪＩＴコンパイラ１０５」は、コンパイル済のコードを「共有メモリヒープ１６０」に書き込めるが「そこでの実行はできない」ように制御すること、すなわち、ＪＩＴコンパイラに、コンパイル済のコードを格納する共有メモリからの「実行アクセス権」を持たないようにアクセス権を設定することは、本願優先日前における公知技術である。

そして、引用発明において、「動的コンパイラ１０８」は、「コンパイル済コード１１２」を生成する機能を有するものであって、当該「コンパイル済コード１１２」を実行することは想定されていないことは明らかである。また、想定外の動作が、不正又は誤動作の原因となることは本願優先日前における技術常識であるところ、引用発明において、「動的コンパイラ１０８」が想定外の動作をすることを防止することは、引用発明における潜在的な課題といえる。そして、この課題を解決するために、引用文献２記載事項のうち、ＪＩＴコンパイラに、コンパイル済のコードを格納する共有メモリからの「実行アクセス権」を持たないようにアクセス権を設定する、との技術事項を、引用発明の「動的コンパイラ１０８」の「保護領域１１１」に対するアクセス権の設定に適用し、上記相違点２に係る本願発明の構成とすることは、当業者が容易に想到し得たことである。

（３）作用効果について

上記相違点を総合的に勘案しても、本件補正発明の奏する作用効果は、引用発明及び引用文献２に記載された周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

（４）請求人の主張について

請求人は、審判請求書において

「 元の拒絶理由通知書の中で（拒絶査定の中でも）審査官殿は、

「引用文献１には、保護領域１１１について、動的コンパイラ１０８が実行アクセス権を与えられないことは記載されていない。

しかしながら、引用文献２の段落［００１７］－［００４７］には、ＪＩＴコンパイラ１０５は、メモリヒープ１６０に書き込める（しかしそこでの実行はできない）こと（段落［００４１］）が記載されている。

引用文献１に記載された発明に引用文献２に記載された発明を適用し、動的コンパイラ１０８に保護領域１１１の実行アクセス権を与えないことは当業者であれば容易に想到し得たものである。」を述べられています。

これに対して、前回の意見書において、

＜主張１＞「先ず、引用文献２に記載の発明では、アプリケーションプログラムはオペレーティングシステムの「ユーザーモード」（低い特権モード）で実行し、一方、ＪＩＴコンパイラはオペレーティングシステムの別のモード、すなわち「カーネルモード」（高い特権モード）で実行されています（引用文献２の明細書の段落「００２５」参照）。これに対して、引用文献１に記載の発明ではオペレーティングシステムの２種類以上の実行モードは記載されていませんので、そのようなモードの遷移はありません。よって引用文献２に記載の発明を引用文献１に記載の発明に適用することはできません。」

＜主張２＞「また、引用文献２を参照すると、図１Ｂには、ＪＩＴコンパイラ１０５から読み取り／書き込みでき、且つアプリーションプログラム１１０からは読み取りのみである「メモリロケーション１６５」と、ＪＩＴコンパイラ１０５から読み取り／書き込みでき、且つアプリケーションプログラム１１０からは読み取り／実行できる「メモリヒープ１６０」という２種類のメモリが必要となります。

これに対して本願発明の場合は、ＪＩＴコンパイラプロセル（当審注：原文ママ）及びＪＩＴコンパイラ実行プロセスが、共有メモリを使用している点で構成上顕著に相違します。

また、引用文献２に記載の発明では、ＪＩＴコンパイラ１０５は、メモリヒープ１６０に対する読み取り／書き込み権が与えられている点、及び本願のポインタについて具体的な記載がない点でも、本願発明と異なります。

従って、引用文献１に記載された発明に引用文献２に記載された発明を適用したとしても、本願発明のような構成にはならず、当業者であってもこれらの引用文献の記載から本願発明に想到することは困難であると思料します。」

と主張したところ、拒絶査定において審査官殿から、

＜主張１＞に対して、

「上記主張は、「引用文献１に記載の発明ではオペレーティングシステムの２種類以上の実行モードは記載されていません」ことによって、なぜ「引用文献２に記載の発明を引用文献１に記載の発明に適用することはできません」となるのか不明である。

引用文献１にユーザーモード及びカーネルモードが記載されていないのは、引用文献１に記載された発明において、ユーザーモード及びカーネルモードの遷移は設計的事項であるからだと解される。例えば、引用文献１に記載された発明において、「Ｊａｖａアプリケーションの実行を担当するプロセス１０７」及び「動的コンパイラ１０８」を実行するモードをいずれのモードとしたとしても、引用文献１に記載された発明がその目的に反するものとなるわけでもないし、引用文献１に記載された発明が機能しなくなるわけでもない。

そもそも、引用文献１にはＪａｖａＶＭ１０１がプロセッサ１０５で実行されること（段落［００１２］）が記載されているが、ユーザーモードとカーネルモードとを遷移しながらプロセスを実行するプロセッサは技術常識である。引用文献１に記載された発明のプロセッサ１０５が、ユーザーモードとカーネルモードとを遷移しながらプロセスを実行するものであることは、引用文献１に記載されているに等しい。

よって、上記主張は採用できない。」

と言われ、

＜主張２＞に対して、

「引用文献１には、保護領域１１１について、動的コンパイラ１０８が実行アクセス権を与えられないことは記載されていない。すなわち、引用文献１に記載された発明を実現するに当たって、保護領域１１１について動的コンパイラ１０８のアクセス権が設定されることは明らかであり、その際、実行アクセス権を与えるか、与えないかのどちらかに決定しなければならないことは明らかであるものの、そのどちらとするかが、引用文献１の記載からは必ずしも明らかではない。

引用文献２に「２種類のメモリ」が開示されている点、「ＪＩＴコンパイラ１０５は、メモリヒープ１６０に対する読み取り／書き込み権が与えられている点、及び本願のポインタについて具体的な記載がない点」は、引用文献１に記載された発明において、動的コンパイラ１０８に実行アクセス権を与えるか、与えないかを、当業者が決定することができない理由にはならない。

よって、上記主張は採用できない。」

と言われております。

しかしながら、出願人の＜主張１＞の「引用文献１に記載の発明ではオペレーティングシステムの２種類以上の実行モードは記載されていませんので、そのようなモードの遷移はありません。」は審査官殿が認められる通り、引用文献１にはこのような記載がなく、これは事実であります。

したがって、引用文献１にはＯＳの複数のモードが記載されていないので、「引用文献１に記載された発明において、ユーザーモード及びカーネルモードの遷移は設計的事項である」と直ちに言うことはできないと思料いたします。

さらに、出願人の＜主張２＞の「引用文献２に記載の発明では、ＪＩＴコンパイラ１０５は、メモリヒープ１６０に対する読み取り／書き込み権が与えられている点、及び本願のポインタについて具体的な記載がない点」については、審査官殿も認めておられるように事実であり、審査官殿が言われるような「引用文献２に「２種類のメモリ」が開示されている点、「ＪＩＴコンパイラ１０５は、メモリヒープ１６０に対する読み取り／書き込み権が与えられている点、及び本願のポインタについて具体的な記載がない点」は、「引用文献１に記載された発明において、動的コンパイラ１０８に実行アクセス権を与えるか、与えないかを、当業者が決定することができない」こととは関係ありません。

このような状況ですので、そもそも引用文献１に引用文献２を適用すること自体が出願当時の技術常識を勘案しても技術的に無理があります。」

と主張する。

上記主張は、令和４年２月１５日に提出された意見書における主張を参酌すれば、引用文献２の

（技術事項Ａ）

アプリケーションプログラムは、オペレーティングシステムの「ユーザーモード」（低い特権モード）で実行し、一方、ＪＩＴコンパイラは、オペレーティングシステムの別のモード、すなわち「カーネルモード」（高い特権モード）で実行されている点、

及び、

（技術事項Ｂ）

ＪＩＴコンパイラから読み取り／書き込みができ、且つアプリケーションプログラム１１０からは読み取りのみである「メモリロケーション１６５」と、ＪＩＴコンパイラからは読み取り／書き込みができ、且つアプリケーションプログラムからは読み取り／実行できる「メモリヒープ１６０」という２種類のメモリが必要になる点、

との２つの技術事項において、引用文献１に記載された発明とは前提となる構成が異なるため、引用文献１に記載された発明に、引用文献２に記載された、ＪＩＴコンパイラに、コンパイル済のコードを格納する共有メモリからの「実行アクセス権」を持たないようにアクセス権を設定する、との技術事項（以下、「技術事項Ｃ」という。）を適用することには技術的な阻害要因がある、との趣旨と理解することができる。

しかしながら、主たる引用発明に、他の引用文献に記載された技術事項を適用するにあたり、当該他の引用文献に記載された技術事項のすべてを適用する必要はなく、引用発明における問題又は課題を解決したり、あるいは、引用発明が対象とする物や方法の機能又は性能を向上させたりするために必要な技術事項のみを適用すれば足りるところ、引用発明の「動的コンパイラ１０８」が想定外の動作をすることを防止することを目的として、引用発明の「保護領域１１１」に対する「動的コンパイラ１０８」のアクセス権の設定に、技術事項Ｃのみを適用しようとすることには合理性がある。

加えて、引用文献２には、技術事項Ｃと技術事項Ａ又は技術事項Ｂとの間の技術的な因果関係（例えば、技術事項Ａ又はＢのために技術事項Ｃを採用しているといった事情等）については何ら記載がなく、よって、引用発明が、技術事項Ａ又は技術事項Ｂ又はこれらに対応する構成を備えないことは、引用発明に技術事項Ｃを適用することができない理由にはならない。

また、技術事項Ｂについては、引用文献２に記載の「メモリロケーション１６５」は、「アプリケーションプログラム１１０が実行のためにロードされるロケーション」であり、引用発明の「ＪａｖａＶＭによりプログラムを実行時にコンパイルする方法」とはそもそも無関係である。

加えて、引用文献１の【００１７】には「すなわち、処理３０１は、従来の処理４０１とは異なり、動的コンパイラが参照しうる領域を、ただのヒープ領域４０２ではなく、共有メモリ領域１０９として確保する。」と記載され、また、当該記載に関し、引用発明に関する【図３】及び引用文献１における従来技術を示す【図４】とを参酌すれば、引用発明の「共有メモリ領域１０９」は、従来技術における「ヒープ領域４０２」のうち、「コンパイル済コードやそのアドレスを記憶する」領域を、プロセス毎にアクセスを制限することが可能な「保護領域１１１」として設定したものにすぎず、当該「保護領域１１１」も、実質的には、「ヒープ領域」（ヒープメモリ）の一部であるから、引用文献２記載事項の「共有ヒープメモリ１６０」と何ら変わるところはない。

したがって、請求人が主張するような技術的な阻害要因は存在しないから、請求人による上記主張は採用しない。

第６ むすび

以上のとおり、本願発明は、引用文献１及び２に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。

したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。

よって、結論のとおり審決する。