【事件の表示】
　特願２０１３−２４７５９１「個々のクラスローダを実装するための方法および装置」拒絶査定不服審判事件〔平成２６年　４月　３日出願公開、特開２０１４−　５９９０６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願は、２０００年７月１３日（パリ条約による優先権主張１９９９年７月１３日（以下、「優先日」という。），米国）を国際出願日とする特願２００１−５１００８４号の一部を新たな出願とする特願２０１１−１７４６５１号の一部を、平成２５年１１月２９日を出願日とする新たな出願である特願２０１３−２４７５９１号としたものであって、その後の手続の経緯の概略は次のとおりである。
　
出願審査請求書（提出日）　平成２５年１１月２９日
拒絶理由通知（起案日）　　平成２６年６月２日（６月１０日発送）
意見書（提出日）　　　　　平成２６年９月９日
拒絶査定（起案日）　　　　平成２６年９月２２日（９月３０日謄本発送）
審判請求書（提出日）　　　平成２７年１月２９日
拒絶理由通知（起案日）　　平成２７年５月１４日（５月１９日発送）
意見書（提出日）　　　　　平成２７年８月１８日
手続補正書（提出日）　　　平成２７年８月１８日
　
第２　本願発明
　本願の請求項１ないし３５に係る発明は、平成２７年８月１８日付け手続補正により補正された特許請求の範囲の請求項１ないし３５に記載された事項により特定されるものであると認められるところ、本願の請求項１４に係る発明（以下、「本願発明」という。）は以下のとおりのものと認める。
　
「複数のアプリケーションに関連付けられたクラスをロードしたりアンロードしたりする方法であって、
　複数のアプリケーションのそれぞれに１つずつクラスローダを構築することによって、複数のクラスローダのそれぞれが、前記複数のアプリケーションの１つに関連付けられたクラスをロードするように適合されるようにする処理と、
　前記複数のクラスローダのうち１またはそれ以上のクラスローダを利用して、対応するアプリケーションに関連付けられた１またはそれ以上のクラスをロードすることによって、前記１またはそれ以上のクラスローダのそれぞれが、前記対応するアプリケーションに関連付けられた前記クラスへの参照を維持するようにする処理と、
　前記対応するアプリケーションがその処理を完了した際に、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達および前記複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とし、その結果、前記複数のクラスローダのそれぞれによって参照された前記クラスについて、ガーベッジコレクションの間にアンロード可能にする処理とを備え、
　前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達を不能にする処理は、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記対応するアプリケーションの実行が終了または中断したとき、前記１またはそれ以上のクラスローダへ到達を不能としたことを示すマークを付する処理を含む方法。」
　
第３　引用文献
１．引用文献１
（１）本願の優先日前に既に頒布又は電気通信回線を通じて公衆に利用可能となり、当審の拒絶理由通知において引用された文献である、Sheng Liang and Gilad Bracha，Dynamic Class Loading in the Java Virtual Machine，Proc. of Object-Oriented Programming,Systems,Languages, and Applications，１９９８年１０月，頁１〜９（以下、「引用文献１」という。）には、関連する図面とともに、次の事項が記載されている。 
 （当審注：以下の下線は、参考のために当審で付与した。） 
　
ア．「
Classes from one applet cannot interfere with classes in another, because applets are loaded in separate class loaders
because the browser resides in a separate class loader, applets cannot access the classes used to implement the browser
 
The Java virtual machine
creating the application class loader and using it to load the initial browser class
 Execution of instructions may cause loading of additional classes. In this application, the browser also creates additional class loaders for downloaded applets
 
The garbage collector unloads applet classes that are no longer referenced
 each class loader refers to all the classes it defines
　
当審訳；「
１つのアプレットからのクラスが他の中のクラスに干渉することができない、なぜならアプレットが別個のクラスローダでロードされるから
ブラウザが別個のクラスローダに存在するから、アプレットがブラウザを実装するために使われるクラスにアクセスすることができない
　
Ｊａｖａ仮想マシンが、アプリケーションクラスローダを作成し、それを最初のブラウザクラスをロードするために使う
命令の実行が追加のクラスのローディングを起こしてもよい。このアプリケーションで、ブラウザはダウンロードされたアプレットのために同じく追加のクラスローダを作成する
　
ガーベジ・コレクターはもう参照されないアプレットクラスをアンロードする
それぞれのクラスローダがそれが定義するすべてのクラスを関連付けている
クラスが強固にそれらを定義しているローダと関係している
クラスは、それらを定義しているローダがガーベジによって集められたとき、アンロードされる
　
 イ．「After we call the updateService method, all future requests will be processed by the new Serviceclass. 
The old Service class,
may not have finished processing
all uses of the old class are complete, all references to the old class are dropped, and the old class is unloaded
　
 当審訳；「我々がアップデートサービスメソッドをコールした後、すべての将来のリクエストは新しいサービスクラスによって処理される。
古いサービスクラスは、
処理し終えなくてもよい
古いクラスのすべての使用がコンプリートされ、古いクラスへのすべての参照が落とされ、そして古いクラスがアンロードされる
　
ウ．Ｆｉｇｕｒｅ２には、「Applet 1等・・・Applet ｎに対応するApplet class loadersとBrowser codeに対応するApplicationt class loader とSystem classesに対応するSystem class　loaderとの委任関係（矢印）」が図示されている。
　
（２）引用文献１に記載された事項について検討する。 
（ア）前記ア．の「１つのアプレットからのクラス（ｃｌａｓｓｅｓ）が他の中のクラス（ｃｌａｓｓｅｓ）に干渉することができない、なぜならアプレットが別個のクラスローダでロードされるから…（中略）…ブラウザが別個のクラスローダに存在するから、アプレットがブラウザを実装するために使われるクラスにアクセスすることができない…（中略）…Ｊａｖａ仮想マシンが、アプリケーションクラスローダを作成し、それを最初のブラウザクラスをロードするために使う」旨の記載、前記ウ．の図２に、アプレット１ないしアプレットｎに対応するアプレットクラスローダ（loaders；複数のローダ）と、ブラウザ（Browser code）に対応したアプリケーション・クラス・ローダが示されている点、および前記ア．の「ガーベジ・コレクターはもう参照されないアプレットクラスをアンロードする」旨の記載から、「アプレット１ないしアプレットｎに対応するアプレットクラスローダ（複数）と、ブラウザに対応したアプリケーション・クラス・ローダによりそれぞれ前記アプレットクラスとアプリケーション・クラスをロードし、ガーベジ・コレクターがもう参照されないアプレットクラスをアンロードする方法」をよみとることができる。
 　 
（イ）前記（ア）で言及した前記ア．の「Ｊａｖａ仮想マシンが、アプリケーションクラスローダを作成し、それを最初のブラウザクラスをロードするために使う」旨の記載、「命令の実行が追加のクラスのローディングを起こしてもよい。このアプリケーションで、ブラウザはダウンロードされたアプレットのために同じく追加のクラスローダを作成する」旨の記載から、「ブラウザクラスをロードするために使うアプリケーションクラスローダを作成し、ダウンロードされたアプレットのために同じく追加のクラスローダを作成する」ことをよみとることができ、前記ア．の「それぞれのクラスローダがそれが定義するすべてのクラスを関連付けている」旨の記載を合わせると「ブラウザクラスをロードするために使うアプリケーションクラスローダを作成し、ダウンロードされたアプレットのために同じく追加のクラスローダを作成し、それぞれのクラスローダがそれが定義するすべてのクラスを関連付けている」ことをよみとることができる。
 　 
（ウ）前記ア．の「命令の実行が追加のクラスのローディングを起こしてもよい。このアプリケーションで、ブラウザはダウンロードされたアプレットのために同じく追加のクラスローダを作成する…（中略）…それぞれのクラスオブジェクトがその定義するローダに参照を含んでいる」旨の記載から、「ダウンロードされたアプレットのために同じく追加のクラスローダを作成することにより前記追加のクラスのローディングを行うことができ、それぞれのクラスオブジェクトがその定義するローダに参照を含んでいる」ことをよみとることができる。
  
（エ）前記イ．の「古いサービスクラスは、…（中略）…処理し終えなくてもよい。古いクラスのすべての使用がコンプリートされ、古いクラスへのすべての参照が落とされ、そして古いクラスがアンロードされる」旨の記載において、前記古いクラスと同様にアプレットクラスを含む他のクラスについても同様のアンロードができることをよみとることができ、前記（ア）で言及した前記ア．の「ガーベジ・コレクターはもう参照されないアプレットクラスをアンロードする」旨の記載から、「アプレットクラスのすべての使用がコンプリートされて処理し終え、アプレットクラスへのすべての参照が落とされ、ガーベジ・コレクターはもう参照されないアプレットクラスをアンロードする」ことをよみとることができる。
  
（オ）前記（エ）で言及した前記イ．の「クラスへのすべての参照が落とされ」る旨の記載、前記イ．の「参照されないアプレットクラスをアンロードする」旨の記載から、「クラスへのすべての参照が落とされることにより参照されなくする」ことをよみとることができる。
 　
 　前記（ア）〜（オ）によれば、引用文献１には、クラスをアンロードすることを可能にする次の発明が示されている。（以下、「引用文献１発明」と呼ぶ。） 
 　 
「アプレット１ないしアプレットｎに対応するアプレットクラスローダ（複数）と、ブラウザに対応したアプリケーション・クラス・ローダによりそれぞれ前記アプレットクラスとアプリケーション・クラスをロードし、ガーベジ・コレクターがもう参照されないアプレットクラスをアンロードする方法であって、
　ブラウザクラスをロードするために使うアプリケーションクラスローダを作成し、ダウンロードされたアプレットのために同じく追加のクラスローダを作成し、それぞれのクラスローダがそれが定義するすべてのクラスを関連付け、 
 前記ダウンロードされたアプレットのために同じく追加のクラスローダを作成することにより前記追加のクラスのローディングを行うことができ、それぞれのクラスオブジェクトがその定義するローダに参照を含んでおり、
 前記アプレットクラスのすべての使用がコンプリートされて処理し終え、前記アプレットクラスへのすべての参照が落とされ、ガーベジ・コレクターはもう参照されない前記アプレットクラスをアンロードすることができ、
 クラスへのすべての参照が落とされることにより参照されなくすることを含む方法。」
　
　
２．引用文献２
（１）本願の優先日前に既に頒布又は電気通信回線を通じて公衆に利用可能となり、当審の拒絶理由通知において引用された文献である、C.E.McDowell, and E.A.Baldwin，Unloading Java Classes That Contain Static Fields，ACM SIGPLAN Notices，１９９８年　１月，Vol.33,No.1,頁５６〜６０ （以下、「引用文献２」という。）には次の事項が記載されている。
　 
 Ａ．「In JDKi.I.4, class unloading is done at the same time as garbage collection, although this may not be the best policy」（５８頁１４行〜１５行）
　
当審訳；「ＪＤＫｉ．Ｉ．４では、クラスアンロードは、これが最善策ではないかもしれないけれども、ガーベジ・コレクションと同時にされる」 
  
 Ｂ．「The alternative we propose in this section is to disallow any unloading of system classes (i.e. any classes loaded by the default class loader) and 
use a separate class loader for each application that may load classes that will need to be unloaded
 Java provides a mechanism for a Java program to load classes under the control of a custom class loader.
Two classes with the same name
Once the class loader object is no longer reachable, then the class unloading policy stated in the JLS can safely be applied (i.e. no instances of the class exist and the class object itself is not reachable)
 …（中略）… 
 In this way, if the browser determines, using any criteria it wishes, 
to terminate the execution of all applets loaded from a particular code base, then those classes loaded via that class loader can safely be unloaded
 …（中略）… 
 We then describe a possible solution, specifically, 
a class
 should not be unloaded until the class loader that loaded the class is no longer reachable
　
当審訳；「我々がこのセクションで提案する代案はシステムクラス（すなわちデフォルトクラスローダによってロードされたどんなクラスでも）の如何なるアンロードも拒否することであり、
アンロードされる必要があるであろうクラスをロードしてもよいそれぞれの”アプリケーション”のために別個のクラスローダを用いることである
　Ｊａｖａがカスタムクラスローダの制御の下でクラスをロードするＪａｖａプログラムにメカニズムを提供する。
同一名を持っている２つのクラス
クラスローダオブジェクトがもう到達可能ではなくなる途端に、それでＪＬＳで規定されたクラスアンローディングポリシーは安全に応用されることができる（すなわちクラスのインスタンスが存在せず、そしてクラスオブジェクト自身は到達可能ではない）
 …（中略）…　 
 このようにして、もしブラウザが、それが望む基準を使って、
特定のコードベースからロードされたすべてのアプレットの実行を終了させようと決めるなら、そのクラスローダを経由してロードされたそれらのクラスは安全にアンロードされる
 …（中略）… 
 我々はそれから可能な解決策を説明する、特に、スタティックフィールドと一緒の
クラスが、クラスをロードしたクラスローダがもう到達可能ではないまで、アンロードされるべきではない
 　 
（２）引用文献２に記載された事項について検討する。
（Ａ）前記Ｂ．の「アンロードされる必要があるであろうクラスをロードしてもよいそれぞれの”アプリケーション”のために別個のクラスローダを用いることである…（中略）…クラスローダオブジェクトがもう到達可能ではなくなる途端に、…（中略）…クラスのインスタンスが存在せず、そしてクラスオブジェクト自身は到達可能ではない」旨の記載において、前記「別個のクラスローダ」は、前記Ｂ．の「同一名を持っている２つのクラス」と同様に名を用いる技術によるクラスローダ名（参照）により別個のクラスローダを認識することをよみとることができるとともに、関係やリンクに名（参照）を用いることは慣用技術であり、前記「クラスローダオブジェクトがもう到達可能ではなくなる」ことは前記Ｂ．の「すべてのアプレットの実行を終了させようと決めるなら、そのクラスローダを経由してロードされた」ものである点をふまえると、クラスローダを経由できないことにより、もう到達可能ではなくなるものが含まれ、この経由できない、到達可能ではなくなることは、端的な例でいえば、クラスローダへの関係、リンクに係るクラスローダ名（参照）が消されること（解除、クリア）によって、もう到達可能ではなくなるものが含まれる。してみれば、引用文献２には「複数のクラスローダのうち１またはそれ以上のクラスローダへの到達」を不能とする技術が示されている。
　なお、前記到達可能、名、参照（ポインタ）技術等については、後記「４．参考文献」の「Ｄ．発明の背景」における「ルート参照位置のセットに、記憶領域に対する参照、即ちポインタが残されていないと到達不能になる。このように到達不能であってしかも解放されていないメモリオブジェクトはガーベッジ(garbage)と呼ばれる」との背景技術を合わせて参照されたい。
　
（Ｂ）また、前記（Ａ）での言及によれば、引用文献２には「複数のクラスローダのうち１またはそれ以上のクラスローダへの到達を不能にする処理は、複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記１またはそれ以上のクラスローダへ到達を不能とする」技術が示されている。
　
３．引用文献３
（１）本願の優先日前に既に頒布又は電気通信回線を通じて公衆に利用可能となり、当審の拒絶理由通知において周知技術を示す文献として引用された特開昭６４−３２３４２号公報（以下、「引用文献３」という。）には、関連する図面と共に次の事項が記載されている。 
Ｃ．「１つの実行コマンドを実行中に
ガーベジコレクション
１つの実行コマンドが終了した時点では、データエリアも制御スタックもからになるので、名前表からたどれる節だけを残して他の節はすべて不要として扱うことができる。つまり、このときは第２のマーキングビットも０にしてしまうことができる
　
（２）引用文献３に記載された事項について検討する。
　前記Ｃ．の、「ガーベジコレクション」、「１つの実行コマンドが終了した時点では、データエリアも制御スタックもからになるので、名前表からたどれる節だけを残して他の節はすべて不要として扱うことができる。つまり、このときは第２のマーキングビットも０にしてしまう」の記載によれば、ガーベジコレクションに関連して「マークを付する処理を含む」技術が示されている。
　
４．参考文献
（１）本願の優先日前に既に頒布又は電気通信回線を通じて公衆に利用可能とされた、国際公開第９８／４８３５３号（以下、「参考文献」という。）には、関連する図面とともに、以下の技術的事項が記載されている。（日本語訳は、パテントファミリである特表２０００−５１３８５２号公報から抜粋した。）
Ｄ．「BACKGROUND OF THE INVENTION
…（中略）…
　Unfortunately, dynamically allocated storage may 
become unreachable if no reference, or pointer, to the storage remains in the set of root reference locations for a given computation
Memory objects that are no longer reachable, but have not been freed, are called garbage
　
当審訳；「発明の背景
…（中略）…
残念ながら、動的に割り当てられた記憶領域は、特定の演算過程のための
ルート参照位置のセットに、記憶領域に対する参照、即ちポインタが残されていないと到達不能になる
到達不能であってしかも解放されていないメモリオブジェクトはガーベッジ(garbage)と呼ばれる。
　　
Ｅ．「In contrast, tracing collector methods involve traversal of reference chains through memory to identify live, i.e., referenceable, memory objects. One such tracing collector method is the mark-sweep method in which 
reference chains through 
are traversed to identify and mark live memory objects
Unmarked memory objects are garbage
　
当審訳；「それに対して、トレーシングコレクタ(tracingcollector)法は、生きた即ち参照可能なメモリオブジェクトを特定するために、メモリの参照チェーンを横断することを含む。このようなトレーシングコレクタ法の一つとして、メモリの
参照チェーンを横断して生きたメモリオブジェクトを識別しマークする
マークされていないメモリはガーベッジ
　
（２）参考文献に記載された事項について検討する。
　前記Ｄ．には、ルート参照位置に参照（ポインタ）が残されていないと到達不能となること、ルート以下の到達不能で解放されていないメモリオブジェクトはガーベッジである旨記載されている。前記Ｅ．には「参照チェーンを横断して生きたメモリオブジェクトを識別しマークする…（中略）…マークされていないメモリはガーベッジ」である旨が記載されており、これらから「到達を不能としたことを示すマークを付する処理を含む」技術が示されている。
　
第４　対比
　引用文献１発明と本願発明とを対比する。　
１．引用文献１発明の「アプレット」は、アプレットクラスの小さなアプリケーションとみることができ、「アプレット」が「アプレットクラス…（中略）…をロード」する当該「アプレットクラス」と派生関係にあることから「アプレットクラス」は「アプレット（アプリケーション）」に関連付けられているといえるとともに、「アプレットクラス」が「アプレット」と関連付けられ、さらに、前記ア．の「このアプリケーションで、ブラウザはダウンロードされたアプレットのために同じく追加のクラスローダを作成する」ことからも、「アプレットクラス」は前記ブラウザなどのアプリケーションと関連付けられているとみることができる。これらの点をふまえれば、前記「アプレットクラス」は本願発明の「アプリケーションに関連付けられたクラス」に相当する。してみれば、引用文献１発明の「アプレット１ないしアプレットｎに対応するアプレットクラスローダ（複数）と、ブラウザに対応したアプリケーション・クラス・ローダによりそれぞれ前記アプレットクラスとアプリケーション・クラスをロードし、ガーベジ・コレクターがもう参照されないアプレットクラスをアンロードする方法」と本願発明の「複数のアプリケーションに関連付けられたクラスをロードしたりアンロードしたりする方法」とに実質的な差異はない。
　
２．前記「１．」で言及した引用文献１発明の「アプレット１ないしアプレットｎに対応するアプレットクラスローダ」における各アプレットが対応したアプレットクラスローダにより「ロードされる」ことは自明であり、換言すれば、「ロードするように適合されるようにされている」とみることができる。この点をふまえれば、引用文献１発明の「ブラウザクラスをロードするために使うアプリケーションクラスローダを作成し、ダウンロードされたアプレットのために同じく追加のクラスローダを作成し、それぞれのクラスローダがそれが定義するすべてのクラスを関連付け」および前記「ロードする」ことと、本願発明の「複数のアプリケーションのそれぞれに１つずつクラスローダを構築することによって、複数のクラスローダのそれぞれが、前記複数のアプリケーションの１つに関連付けられたクラスをロードするように適合されるようにする処理」とに実質的な差異はない。
　
３．引用文献１発明のローダに含んでいる「参照」は、前記ア．の「それぞれのクラスローダがそれが定義するすべてのクラスを関連付けている…（中略）…クラスが強固にそれらを定義しているローダと関係している…（中略）…クラスは、それらを定義しているローダがガーベジによって集められたとき、アンロードされる」旨の記載から、前記関連付けの「参照」として強固に維持されていると解される。してみれば、引用文献１発明の「前記ダウンロードされたアプレットのために同じく追加のクラスローダを作成することにより前記追加のクラスのローディングを行うことができ、それぞれのクラスオブジェクトがその定義するローダに参照を含んで」いることと本願発明の「前記複数のクラスローダのうち１またはそれ以上のクラスローダを利用して、対応するアプリケーションに関連付けられた１またはそれ以上のクラスをロードすることによって、前記１またはそれ以上のクラスローダのそれぞれが、前記対応するアプリケーションに関連付けられた前記クラスへの参照を維持するようにする処理」とに実質的な差異はない。
　
４．引用文献１発明の「それぞれのクラスオブジェクトがその定義するローダに参照を含んで」いるところの当該「参照」に関し、「すべての参照が落とされ」ることは、端的な例で言えば、参照が消される等により参照を用いた関係やリンク（接続）が消されて関係や接続を辿れないこと（到達を不能）を意味し、「複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能と」されることであると換言できる。してみれば、引用文献１発明の「前記アプレットクラスのすべての使用がコンプリートされ処理し終え、前記アプレットクラスへのすべての参照が落とされ、ガーベジ・コレクターはもう参照されない前記アプレットクラスをアンロードすることができ」ることと、本願発明の「前記対応するアプリケーションがその処理を完了した際に、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達および前記複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とし、その結果、前記複数のクラスローダのそれぞれによって参照された前記クラスについて、ガーベッジコレクションの間にアンロード可能にする処理」とは「前記対応するアプリケーションがその処理を完了した際に、複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とし、その結果、前記複数のクラスローダのそれぞれによって参照された前記クラスについて、ガーベッジコレクションの間にアンロード可能にする処理」において共通し、本願発明が「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達を不能にする」点で相違する。
　
５．引用文献１発明の前記「４．」で言及した引用文献１発明の「アプレットクラスのすべての使用がコンプリートされ処理し終え、前記アプレットクラスへのすべての参照が落とされ、」および「クラスへのすべての参照が落とされることにより参照されなくすることを含む」ことと本願発明の「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達を不能にする処理は、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記対応するアプリケーションの実行が終了または中断したとき、前記１またはそれ以上のクラスローダへ到達を不能としたことを示すマークを付する処理を含む」こととは「前記対応するアプリケーションの実行が終了または中断したとき、到達を不能としたことを示す」点で共通し、本願発明が「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達を不能にする処理は、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記１またはそれ以上のクラスローダへ」到達を不能としたことを示す「マークを付する処理を含む」点で相違する。
　　
　前記１．〜５．の検討によれば、本願発明と引用文献１発明とは次の事項を有する点では一致し、そして、次の点で相違する。
　
［一致点］
「複数のアプリケーションに関連付けられたクラスをロードしたりアンロードしたりする方法であって、
　複数のアプリケーションのそれぞれに１つずつクラスローダを構築することによって、複数のクラスローダのそれぞれが、前記複数のアプリケーションの１つに関連付けられたクラスをロードするように適合されるようにする処理と、
　前記複数のクラスローダのうち１またはそれ以上のクラスローダを利用して、対応するアプリケーションに関連付けられた１またはそれ以上のクラスをロードすることによって、前記１またはそれ以上のクラスローダのそれぞれが、前記対応するアプリケーションに関連付けられた前記クラスへの参照を維持するようにする処理と、
　前記対応するアプリケーションがその処理を完了した際に、前記複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とし、その結果、前記複数のクラスローダのそれぞれによって参照された前記クラスについて、ガーベッジコレクションの間にアンロード可能にする処理とを備え、
　前記対応するアプリケーションの実行が終了または中断したとき、到達を不能としたことを示すことを含む方法。」
　
〈相違点１〉
　対応するアプリケーションがその処理を完了した際に、複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とする点に関し、本願発明は、「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達」および前記複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とするものであるのに対し、引用文献１発明はそのようであるか特定されていない点。
〈相違点２〉
　対応するアプリケーションの実行が終了または中断したとき、到達を不能としたことを示す点に関し、本願発明は、「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達を不能にする処理は、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記１またはそれ以上のクラスローダへ」到達を不能としたことを示す「マークを付する処理を含む」のに対し、引用文献１発明は、そのようであるか特定されていない点。
　
第５　判断
１．〈相違点１〉について
　引用文献２には、引用文献１発明と共通する複数クラスローダに係る技術である「複数のクラスローダのうち１またはそれ以上のクラスローダへの到達」を不能とする技術が示されており、また、４．参考文献には到達不能とガーベッジ（ガーベジ）との関連する周知技術が示されている。
　引用文献１発明において、前記周知技術を適用し、対応するアプリケーションがその処理を完了した際に、複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とする点に関し、「前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの到達」および前記複数のクラスローダのそれぞれによって参照されたクラスへの到達を不能とすると成すことは当業者が容易になし得ることである。
　
２．〈相違点２〉について
　引用文献２には「複数のクラスローダのうち１またはそれ以上のクラスローダへの到達を不能にする処理は、複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記１またはそれ以上のクラスローダへ到達を不能とする」技術が示されている。また、引用文献３にはガーベジコレクションに関連して「マークを付する処理を含む」周知技術が示され、「第３　引用文献」の「４．参考文献」には「到達を不能としたことを示すマークを付する処理を含む」周知技術が示されている。しかも、これらの技術ないし周知技術は、本願発明と共通する複数のクラスローダに係る技術ないし本願発明と共通するガーベジコレクションを目的とする技術であり、これら技術は当業者が把握しておくべきものであり参酌自在なものである。
　してみれば、引用文献１発明において、対応するアプリケーションの実行が終了または中断したとき、到達を不能としたことを示す点に関し、「複数のクラスローダのうち１またはそれ以上のクラスローダへの到達を不能にする処理は、前記複数のクラスローダのうち前記１またはそれ以上のクラスローダへの参照を解除することを含み、前記１またはそれ以上のクラスローダへの参照の解除は、前記１またはそれ以上のクラスローダへ」到達を不能としたことを示す「マークを付する処理を含む」と成すことは、前記技術を参酌することにより当業者が容易になし得ることである。
　
３．小括
　したがって、本願発明は、前記引用文献１発明、引用文献２ないし３の技術、および参考文献の技術に基いて当業者が容易になし得るものであり、本願発明の奏する作用効果は、前記引用文献１発明ないし前記技術の奏する作用効果から当然予測される範囲内のものにすぎず、格別顕著なものということはできない。
　　
第６　むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、前記結論のとおり審決する。。