【事件の表示】
　特願２０００−　６８０２５「呼び出しを識別する方法」拒絶査定不服審判事件〔平成１２年１０月２０日出願公開、特開２０００−２９３３７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯と本願発明
　本願は平成１２年３月１３日（パリ条約による優先権主張　１９９９年３月１６日　米国）の出願であって、原審において平成１４年１１月５日付けで拒絶理由通知がなされ、平成１５年４月８日付けで意見書が提出されるとともに手続補正がなされ、同年７月１日付けで拒絶査定がなされた。
　これに対して、同年９月２６日付け拒絶査定不服の審判請求がなされるとともに、手続補正がなされ、前置審査において同年１２月１６日付けで拒絶理由通知がなされたところ、請求人より何らの応答がなかったものである。
　
２．平成１５年９月２６日付けの手続補正について却下の決定
［補正却下の決定の結論］
　平成１５年９月２６日付けの手続補正を却下する。
　
［理由］
（１）補正後の本願発明
　本件手続補正により、特許請求の範囲は、
「【請求項１】
　Ｊａｖａ封印パッケージにおいてそのターゲットが前記パッケージに属することが保証されている呼び出しを識別する方法であって、
　（１）前記パッケージが封印され署名されていることを検証するステップと、
　（２）そうである場合に、前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップと、
　（３）前記パッケージ内のそれぞれのコンポーネントのアクセス許可を得るステップと、
　（４）前記呼び出しのすべてのターゲットが前記パッケージに属することが保証されているかどうかを判定するために、前記クラス階層グラフおよびアクセス許可を使用するステップとを含む方法。
【請求項２】
　ステップ（４）が、
　ａ）呼び出されたメソッドを、前記パッケージ外部のメソッドによって直接オーバーライドまたは実装することができるかどうかを判定するステップと、
　ｂ）そうである場合に、前記呼び出しを、そのターゲットがすべて同じパッケージに属することが保証されているのではない呼び出しとして識別するステップとを含む、請求項１記載の方法。
【請求項３】
　ｃ）呼び出されたメソッドを、前記パッケージ内部のメソッドによって直接または間接的にオーバーライドまたは実装することができ、それによって前記パッケージ外部のメソッドによって間接的にオーバーライドまたは実装できるかどうかを判定するステップと、　ｄ）そうである場合に、前記呼び出しを、そのターゲットがすべて同じパッケージに属することが保証されているのではない呼び出しとして識別するステップとをさらに含む、請求項２記載の方法。
【請求項４】
　ステップａ）が、
　前記呼び出されたメソッドの前記クラスまたはインタフェースから開始して、前記クラス階層グラフを走査するステップと、
　前記呼び出されたメソッドを非finalでpublicまたはprotectedとして宣言するか、あるいは前記クラスまたはインタフェースの親からこのような宣言を継承するpublicで非finalのサブクラスを探索するステップと、
　このようなサブクラスが発見された場合に、前記呼び出しを、そのターゲットがすべて同じパッケージに属することが保証されているのではない呼び出しとして識別するステップとを含む、請求項３記載の方法。
【請求項５】
　前記クラスが、前記パッケージ外部の１つ以上のクラスを介して、別の継承ツリーのクラスによってサブクラス化できるかどうか、および前記クラスが前記呼び出されたメソッドを別の継承ツリーのクラスに渡すことができるかどうかを判定するステップと、
　そうである場合に、前記クラスのメソッドを考慮する際に、請求項４記載の前記呼び出されたメソッドを、前記別の継承ツリーの前記クラスにも適用するステップとをさらに含む、請求項４記載の方法。」
と補正された。
　
　上記本件手続補正の前後における各請求項の対応関係は、上記本件手続補正前の請求項１−５が、上記本件手続補正後の請求項１−５にそれぞれ対応していると認められる。
　請求項１の補正は、請求項１に記載した発明を特定するために必要な事項である「前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」について「そうである場合に、」との限定を付加したものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものである。
　また、請求項１の補正は、出願当初の明細書に記載された事項の範囲内でなされており、特許法第１７条の２第３項の規定に合致するものである。
　
　そこで、上記本件手続補正後の特許請求の範囲第１項に記載されている事項により特定される発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか）について以下に検討する。
　
（２）平成１５年１２月１６日付けの拒絶理由について
　
「理由１：　　　・・・（　省　略　）・・・
　
理由２：この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　（１）請求項１には、「Ｊａｖａ封印パッケージにおいてそのターゲットが前記パッケージに属することが保証されている呼び出しを識別する」という記載があるが、「Ｊａｖａ封印パッケージ」というのは既に封印されているから、そのターゲットは当然同じパッケージに属していることになる（理由１で引用した明細書コラム【００１６】の記載参照）。したがって、「保証されている呼び出しを識別」するまでもなく、すべての呼び出しのターゲットは同じパッケージに属していることが最初から保証されているにもかかわらず、それを識別するという記載になっており、矛盾した記載であり、明確ではない。請求項１を引用する請求項２〜５についても同様。
　（２）請求項１の（１）ではパッケージが封印されていることを検証し、そうであることが確認されているから、この時点で封印されているパッケージに属する呼び出しのターゲットはすべて同じパッケージに属することが保証される筈である。したがって、同請求項１の（４）における処理は、既に判定が済んで保証されている事項を再度判定する旨の記載になっており、無駄な動作の繰り返しに過ぎず、その必要性が不明であり、明確な記載になっていない。請求項１を引用する請求項２〜５についても同様。
　（３）請求項１には「Ｊａｖａ」という商品名が記載されているが、この記載によって特定しようとしている事項が明確ではない（同じＪａｖａでも、バージョンによって機能や内部構成は異なる）。商品名を使用せずに、技術的事項を特定するようにされたし。請求項１を引用する請求項２〜５についても同様。
　　　　　　　・・・（　中　略　）・・・
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由２）
　
理由３：　　　　・・・（　省　略　）・・・
　
理由４：この出願の下記の請求項に係る発明は、下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないので、特許を受けることができない。
　　　　　　　　　　　　　　　　　記
　（１）請求項１〜５は、自然法則を利用したような記載になっていない。審査基準第VII部第１章（コンピュータ・ソフトウェア関連発明）参照。特に２．２．２（３）の記載を参考にされたし。
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由４）
　
理由５：この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　　記
・請求項１〜４に対し、
引用文献：
Ａ．リッチー・ティム、「Ｊａｖａ環境入門」、株式会社プレンティスホール出版、１９９７年１月３１日、初版、pp.157-180,370-374（特許庁CSDB文献番号：単行本199900144001、ISBN:4-88735-000-7）
Ｂ．国際公開第９８／５４６３３号パンフレット（１９９８）
Ｃ．その他、先の拒絶理由通知書及び拒絶査定において挙げた文献
　
備考：
　（１）請求項１について
　引用文献Ａの第１６４頁第２〜３行には、「修飾子を指定しないと、同じパッケージ内のクラスからのみアクセスできるようになります」という記載がある。引用文献Ａの第１６４頁第１５〜１８行には「何も指定しない（packageレベル）と同じパッケージ内のクラスからはアクセスできるようになりますし、protectedと指定すると加えてパッケージ外のクラスでもサブクラスからはアクセスできるようになります」という記載がある。引用文献Ａの第１７１頁第６〜９行には、「パッケージを使うと、クラスへの参照が整理できますし、クラスや変数やメソッドのアクセス範囲を限定させることもできます。public, private, protected のいずれとも指定されていない（packageレベル）クラスのインスタンスやメソッドは、同じパッケージに属するクラスからのみアクセスを許すことになります」という記載がある。
　デバッグ目的でプログラムを解析したり、或いはコンパイルの前処理としてソースコードの記述ミスを探すためにプログラムを解析する際に、クラスやインタフェースの階層グラフを作成してそれを参照しつつ解析を行うことは周知技術であり、そのようなプログラムの解析時に引用文献Ａに記載されている上述の特性（public, private, protected などのアクセス許可）をすべてのメソッドについてチェックすることは、当業者が必要に応じて適宜行えばよい事項に過ぎず、これによって請求項１の（１）を除く構成を得ることができる。
　次に請求項１の（１）について検討するが、パッケージが署名されているか否かを確認することは、ターゲットがパッケージに属するか否かという判定とは無関係であるから、発明の目的とは無関係な構成であり、そのような無関係な構成を採用することは、当業者が必要に応じて適宜行えばよい事項に過ぎず、署名を確認すること自体は例えば引用文献Ａの第３７３頁末行〜第３７４頁第１行（公開鍵を用いてデコードさせることで署名の有効性を確認させることは周知技術）や、引用文献ＢのＦＩＧ．６にあるように周知技術に過ぎない。
　また、請求項１の（１）の「封印」されていることを検証する旨の記載は、理由１において述べたように、その真に意味するところが不明（具体的に何をチェックして「封印」されていると検証しているのか不明）であるが、請求項１の（２）〜（４）のようなチェックが別途行われていることからみて、請求項１の（１）における「封印」の検証とは、単にパッケージが存在しているか否かを確認しているという程度の意味にしか解することができず、そのようなことは、引用文献Ａにおいても当然行われている（引用文献Ａの第１７１頁ではパッケージの宣言が行われているので、それの確認を行うようなことは、当然行われている）。
　　　　　　　・・・（　中　略　）・・・
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由５）」
　
（３）当審の判断
　
ａ．理由２（特許法第３６条第６項第２号）に関して
ａ−１．本願補正後の請求項１には、「Ｊａｖａ封印パッケージにおいてそのターゲットが前記パッケージに属することが保証されている呼び出しを識別する」という記載があるが、「Ｊａｖａ封印パッケージ」というのは既に封印されているから、そのターゲットは当然同じパッケージに属していることになる（段落番号【００１６】の記載参照）。したがって、「保証されている呼び出しを識別」するまでもなく、すべての呼び出しのターゲットは同じパッケージに属していることが最初から保証されているにもかかわらず、それを識別するという記載になっており、矛盾した記載であり、明確ではない。
　
ａ−２．本願補正後の請求項１（１）ではパッケージが封印されていることを検証し、そうであることが確認されているから、この時点で封印されているパッケージに属する呼び出しのターゲットはすべて同じパッケージに属することが保証される筈である。したがって、本願補正後の請求項１（４）における処理は、既に判定が済んで保証されている事項を再度判定する旨の記載になっており、無駄な動作の繰り返しに過ぎず、その必要性が不明であり、明確な記載になっていない。
　
ａ−３．本願補正後の請求項１には「Ｊａｖａ」という商品名が記載されているが、この記載によって特定しようとしている事項が明確ではない。何故ならば、Ｊａｖａは、バージョンによって機能や内部構成は異なっており、この記載だけでは、本願補正後の請求項１に記載された発明を特定することはできない。
　
　したがって、本願補正後の請求項１の記載では、特許法第３６条第６項第２号に規定する要件を満たしていないから、本願補正発明は特許出願の際独立して特許を受けることができないものである。
　
ｂ．理由４（特許法第２９条第１項柱書）に関して
　
　本願補正発明が、特許法第２条でいう特許法上の「発明」すなわち「自然法則を利用した技術的思想の創作」に該当するか否かについて検討する。
　
　本願補正発明は、「Ｊａｖａ封印パッケージにおいてそのターゲットが前記パッケージに属することが保証されている呼び出しを識別する方法」に関するものであるが、Ｊａｖａ自体はコンピュータ上で実行されるオブジェクト指向のプログラム言語の一種であり、また、当該方法自体も、物理的な対象を制御するものでもなく、且つ、対象の物理的な性質に基づいた処理を行うものでもない。
　また、当該方法の内容は、「（１）前記パッケージが封印され署名されていることを検証するステップ」と、「（２）そうである場合に、前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」と、「（３）前記パッケージ内のそれぞれのコンポーネントのアクセス許可を得るステップ」と、「（４）前記呼び出しのすべてのターゲットが前記パッケージに属することが保証されているかどうかを判定するために、前記クラス階層グラフおよびアクセス許可を使用するステップ」とで構成されているが、これらのステップはいずれも、人為的な取決めであって、自然法則を利用した技術的思想の創作に該当しない。
　
　したがって、本願補正発明は、特許法第２条でいう、特許法上の「発明」に該当せず、特許法第２９条第１項柱書の規定により、特許出願の際独立して特許を受けることができないものである。
　
ｃ．理由５（特許法第２９条第２項）に関して
ｃ−１．引用例
　平成１５年１２月１６日付けの拒絶の理由に引用された各引用例には以下の事項が記載されている。
　
引用例１．国際公開第９８／５４６３３号パンフレット（１９９８）
（イ）「An object-oriented runtime environment includes objects that contain both behavior and state. An object's state at runtime evolves in the runtime environment. Because a runtime object evolves, it is considered to be live.」（第１頁８行〜１０行）
（訳：オブジェクト指向実行時環境には、挙動と状態の両方を含むオブジェクトが含まれる。実行時のオブジェクトの状態は、実行時環境で展開される。この実行時オブジェクトは展開されるので、「生きている」とみなされる。）
　
（ロ）「A sealedObject class is used to encrypt a live object. A snapshot of the live object is generated and stored in the sealedObject. The snapshot is encrypted using a public key. The encrypted snapshot is stored in the sealedObject. Once the snapshot is encrypted, the plaintext version of the snapshot is deleted from the sealedObject. To retrieve the encrypted object, the encrypted snapshot is retrieved from the sealedObject. A private key is used to decrypt the encrypted snapshot. The decrypted snapshot is used to reconstruct the live object. Like the signedObject class, the member fields, or variables, of the sealedObject class are publicly accessible its member methods.
 A combination of signing and sealing an object is possible using embodiments of the invention. For example, the snapshot of a live object is sealed by storing the snapshot and signature in a sealedObject instance. The snapshot is encrypted and the plaintext version of the snapshot is deleted from the sealedObject. Before the snapshot is used to reconstruct the live object, the signature is used for authentication. To authenticate the object, the snapshot is decrypted to yied the plaintext. The plaintext is authenticated using DSS and DSA, forexample. If authentic, the plaintext is used to reconstruct the live object.」（第８頁５行〜２３行）
（訳：ｓｅａｌｅｄＯｂｊｅｃｔクラスは、「生きている」オブジェクトの暗号化に使用される。「生きている」オブジェクトのスナップショットが生成され、ｓｅａｌｅｄＯｂｊｅｃｔに格納される。このスナップショットは、公開鍵を使用して暗号化される。暗号化されたスナップショットが、ｓｅａｌｅｄＯｂｊｅｃｔに格納される。スナップショットが暗号化された後に、スナップショットの平文版は、ｓｅａｌｅｄＯｂｊｅｃｔから削除される。暗号化されたオブジェクトを取り出すためには、暗号化されたスナップショットをｓｅａｌｅｄＯｂｊｅｃｔから取り出す。私有鍵を使用して、暗号化されたスナップショットを解読する。解読されたスナップショットを使用して、「生きている」オブジェクトを再構築する。ｓｉｇｎｅｄＯｂｊｅｃｔクラスと同様に、ｓｅａｌｅｄＯｂｊｅｃｔクラスのメンバ・フィールドまたはメンバ変数は、そのメンバ・メソッドを介してｐｕｂｌｉｃにアクセス可能である。
　オブジェクトの署名と封印の組合せは、本発明の実施態様を使用することによって可能になる。たとえば、「生きている」オブジェクトのスナップショットは、スナップショットと署名をｓｅａｌｅｄＯｂｊｅｃｔインスタンスに格納することによって封印される。このスナップショットは、暗号化され、スナップショットの平文版は、ｓｅａｌｅｄＯｂｊｅｃｔから削除される。スナップショットを使用して「生きている」オブジェクトを再構築する前に、認証のために署名が使用される。オブジェクトを認証するために、スナップショットを解読して平文を得る。平文は、たとえばＤＳＳおよびＤＳＡを使用して認証される。真正である場合には、平文を使用して、「生きている」オブジェクトを再構築する。）
　
（ハ）「SealedObject Class Definition
 The sealedObjcet class is a class that represents a sealed document. The sealed document is the runtime object (e.g., a Java runtime object). A constructor constructs an instance of sealedObject from the runtime, or content, object. The sealedObject class is a subclass of the signedObject class and inherits the member variables and methods of the signedObject class. Like the signedObject class, variables of the sealedObject class are all private and are publicly accessible using member methods.」（第２３頁１０行〜１７行）
（訳：ｓｅａｌｅｄＯｂｊｅｃｔクラス定義
  ｓｅａｌｅｄＯｂｊｅｃｔクラスは、封印された文書を表すクラスである。封印された文書は、実行時オブジェクト（たとえばＪａｖａ実行時オブジェクト）である。コンストラクタが、実行時オブジェクトまたは「内容」オブジェクトからｓｅａｌｅｄＯｂｊｅｃｔのインスタンスを構築する。ｓｅａｌｅｄＯｂｊｅｃｔクラスは、ｓｉｇｎｅｄＯｂｊｅｃｔクラスのサブクラスであり、ｓｉｇｎｅｄＯｂｊｅｃｔクラスのメンバ変数とメソッドを継承する。ｓｉｇｎｅｄＯｂｊｅｃｔクラスと同様に、ｓｅａｌｅｄＯｂｊｅｃｔクラスの変数は、すべてがｐｒｉｖａｔｅであり、メンバ・メソッドを使用してｐｕｂｌｉｃにアクセス可能である。）
　
（ニ）「Signig and Sealing an Object
 An object can be both signed and sealed using embodiments of the invention. figure 5 provides an example of a process flow for serializing and signing a live object. Figure 8 can be used to seal an object. A signed, sealed object is unsigned and unsealed before it is used. Figure 10 provides an example of a process flow for unsigning and unsealing a signed, sealed object according to an embodiment of the invention.
 A signed, sealed object is unsealed and the plaintext is used to unsign the object. Alternatively, a signed, sealed object can be unsealed and then unsigned. At step 1002 (i.e., sealed?), a determination is made whether the sealed flag indicates that the object is sealed. If not, processing continues at step 1008 to unsign the object. If so, processing continues at steps 1004 and 1006 to decrypt the ciphertext of the object and store the plaintext in the sealedObject instance.
 At step 1008, the signature associated with the object is retrieved. The signature is verified at step 1010. At step 1012 (i.e., valid signature?), a determination is made whether the signature is authentic. If not, processing ends at step 1018. If the signature is authentic, processing continues at step 1014 to retrieve the plaintext version of the object that is used in step 1016 to reconstruct the object.」（第２５頁２０行〜第２６頁１５行）
（訳：オブジェクトの署名と封印
  オブジェクトには、本発明の実施形態を使用して、署名と封印の両方を行うことができる。第５図に、「生きている」オブジェクトのシリアライズと署名のための処理の流れの例を示す。第８図を使用して、オブジェクトを封印することができる。署名され封印されたオブジェクトは、使用する前に署名を解除され、封印を解除される。第１０図に、本発明の実施形態による、署名され封印されたオブジェクトの署名解除および封印解除のための処理の流れの例を示す。
　署名され封印されたオブジェクトは、封印を解除され、平文が、オブジェクトの署名解除に使用される。その代わりに、署名され封印されたオブジェクトを、封印解除の後に署名解除することができる。ステップ１００２（すなわち、「封印されているか」）で、ｓｅａｌｅｄフラグからそのオブジェクトが封印されていることが示されるかどうかの判定を行う。そうでない場合には、処理はステップ１００８で継続され、オブジェクトの署名を解除する。そうである場合には、処理はステップ１００４および１００６で継続され、オブジェクトの暗号文が解読され、平文がｓｅａｌｅｄＯｂｊｅｃｔインスタンスに格納される。
  ステップ１００８で、オブジェクトに関連する署名を取り出す。この署名は、ステップ１０１０で検証される。ステップ１０１２（すなわち、「有効な署名か」）で、その署名が真正であるかどうかの判定を行う。そうでない場合には、処理はステップ１０１８で終了する。署名が真正である場合には、処理はステップ１０１４で継続されて、オブジェクトの平文版が取り出され、この平文版は、ステップ１０１６でオブジェクトの再構築に使用される。）
　
　上記（イ）の記載、及び、上記（ロ）「A sealedObject class is used to encrypt a live object.」の記載より、ｓｅａｌｅｄＯｂｊｅｃｔは実行時において実行時環境で展開される。また、上記（ハ）「The sealedObjcet class is a class that represents a sealed document. The sealed document is the runtime object (e.g., a Java runtime object).」の記載から、ｓｅａｌｅｄＯｂｊｅｃｔクラスはＪａｖａ実行時オブジェクトであることが示されている。加えて、上記（ロ）「A snapshot of the live object is generated and stored in the sealedObject. 」の記載から、ｓｅａｌｅｄＯｂｊｅｃｔは、オブジェクトのスナップショットが格納されていることが示されている。さらに、上記（ハ）「The sealedObject class is a subclass of the signedObject class and inherits the member variables and methods of the signedObject class.」の記載から、ｓｅａｌｅｄＯｂｊｅｃｔクラスはｓｉｇｎｅｄＯｂｊｅｃｔクラスのサブクラスであることから、ｓｉｇｎｅｄＯｂｊｅｃｔはＪａｖａ実行時オブジェクトであり、且つ、オブジェクトのスナップショットが格納されている。
　これらの記載から、ｓｅａｌｅｄＯｂｊｅｃｔ及びｓｉｇｎｅｄＯｂｊｅｃｔはＪａｖａ実行時オブジェクトであり、且つ、オブジェクトのスナップショットが格納されており、実行時に実行環境で展開されると認められる。
　
　また、上記（ニ）「At step 1002 (i.e., sealed?), a determination is made whether the sealed flag indicates that the object is sealed. ・・・（中　略）・・・The signature is verified at step 1010. At step 1012 (i.e., valid signature?), a determination is made whether the signature is authentic.」の記載から、オブジェクトが封印され署名されているのかを判定するステップが示されている。
　
　加えて、上記（ニ）「If the signature is authentic, processing continues at step 1014 to retrieve the plaintext version of the object that is used in step 1016 to reconstruct the object.」の記載から、上記判定で、署名が真正であるなら、オブジェクトの平文版が取り出され、オブジェクトの再構築がなされること（ステップ）が記載されており、当然、再構築されたオブジェクトにアクセス可能であると認められる。
　また、上記（イ）の記載、及び、上記（ロ）「If authentic, the plaintext is used to reconstruct the live object.」の記載より再構築は、オブジェクトを実行するために行われる。
　
　以上（イ）〜（ニ）の記載から、引用例１には以下の発明（以下「引用例１発明」という。）が記載されている。
　
　Ｊａｖａ実行時オブジェクトであり、且つ、オブジェクトのスナップショットが格納されており、オブジェクトを実行するために、実行環境で展開されるｓｅａｌｅｄＯｂｊｅｃｔの再構築を行う方法であって、
（１）前記ｓｅａｌｅｄＯｂｊｅｃｔが封印され署名されていることを判定するステップと、
（２）該判定が真正である場合に、オブジェクトの再構築を行うステップと、
（３）再構築されたオブジェクトにアクセスするステップ
とを含む方法。
　
引用例２．リッチー・ティム、「Ｊａｖａ環境入門」、株式会社プレンティスホール出版、１９９７年１月３１日、初版、pp.157-180
　
（ホ）「メソッドｇｅｔＡｒｅａ（）とｄｒａｗＲｅｃｔ（）の前に，それぞれ修飾子ｐｒｏｔｅｃｔｅｄとｐｕｂｌｉｃが付いていることに注意してください．修飾子ｐｒｏｔｅｃｔｅｄは，このメソッドがＲｅｃｔａｎｇｌｅクラスとそのサブクラスからのみ呼び出せることを意味します．修飾子ｐｕｂｌｉｃは，どのクラスからでもこのメソッドを呼び出して矩形を描画できることを意味します． この他にｐｒｉｖａｔｅという修飾子があります．これは，そのメソッドが宣言されているクラスからのみ呼び出せることを意味します．サブクラスからでもそのメソッドを呼び出すことはできません．これらの修飾子は変数にも付けることができます．インスタンス変数を他のクラスから隠したい場合には，次のようにｐｒｉｖａｔｅとして宣言します．
ｐｒｉｖａｔｅ　ｉｎｔ　ｓｅｃｒｅｔＶａｒｉａｂｌｅ；」（第１６３頁２７行〜３５行）
　
　（ホ）の記載から、引用例２には以下の発明（以下「引用例２発明」という。）が記載されている。
　
　修飾子を用いて、Ｊａｖａのメソッド呼び出しを制御する方法。
　
ｃ−２．対比
　本願補正発明と引用例１発明とを対比すると、
　
　引用例１発明の「Ｊａｖａ実行時オブジェクト」である「ｓｅａｌｅｄＯｂｊｅｃｔ」は、「オブジェクトのスナップショットを格納し」、また、「封印され署名されていることを判定するステップ」があることから、本願補正発明の「Ｊａｖａ封印パッケージ」に相当すると認められる。
　
　してみると両者は次の点で一致する。
　
　Ｊａｖａ封印パッケージにおいて、
　（１）前記パッケージが封印され署名されていることを検証するステップと、
を有する方法。
　
　一方、両者は次の点で相違する。
　
（相違点１）
　本願補正発明が「前記パッケージ内のそれぞれのコンポーネントのアクセス許可を得るステップ」を有しているのに対して、引用例１発明には「パッケージ内のそれぞれのコンポーネントのアクセス許可」について明示がない点。
　
（相違点２）
　本願補正発明が「前記パッケージが封印され署名されていることを検証するステップ」を行った後に、「そうである場合に、前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」を有し、「前記呼び出しのすべてのターゲットが前記パッケージに属することが保証されているかどうかを判定するために」、該「クラス階層グラフ」と該「アクセス許可」を使用し、「ターゲットが前記パッケージに属することが保証されている呼び出しを識別」しているのに対して、引用例１発明は、「前記パッケージが封印され署名されていることを検証するステップ」を行った後に「オブジェクトの再構築を行」い、「再構築されたオブジェクトにアクセス」している点。
　
ｃ−３．判断
（相違点１）に関して
　引用例２発明に記載されているように、Ｊａｖａにおいて修飾子を用いてメソッド（本願補正発明の、「コンポーネント」に相当する。）の呼び出しを管理する（本願補正発明の、「アクセス許可を得る」に相当する。）ことは、当然なされている事項である。
　したがって、引用例１発明においても、各スナップショット（引用例２発明の、「メソッド」に相当する。）にアクセスする際に、そのスナップショットのアクセス許可を得た上でアクセスすることは、明示されていなくとも当業者において自明である。
　
（相違点２）に関して
　松岡聡、「Ｊａｖａにおける高速化の動向」、計測と制御、第３７巻　第９号、社団法人計測と自動制御学会、１９９８年９月１０日、ｐ．６２７−６３２に、
　
（ヘ）「もう１つの有効な高速化手法は，メソッドのインライニングである．これは，呼び出されるメソッドを呼び出し側に直接展開（インライン化）してしまい，呼び出し自身を削除してしまう，というものである．単純に呼び出しのコードを除去するのでは効果が薄いが，これによってメソッドの本体が大きくなり，通常の手続き内最適化の範囲を広げられ，それによって大幅な速度向上が見込める．インライニングはＣ，Ｆｏｒｔｒａｎでも広く使われてきた最適化技術であるが，オブジェクト指向言語では，小さいメソッドがコールチェイン（一連のメソッド呼び出しの動的な連鎖）上の枝葉で多数実行されることが多いので，そのようなメソッドをインライニングすることは絶大な効果がある．一方，動的呼び出しを行う必要があるので，インライン化するメソッドが特定できない，という問題がある．これに対し，動的型テストを行うコードもインライニングする［Ｓｅｌｆ８９］，後述のようにクラス解析を行い，メソッドがユニークに決定した場合のみ，インライニングを行う，などの手段がある．」（第６２８頁右欄３９行〜第６２９頁左欄８行）
　
（ト）「最も簡便な解析法としては，Ｃｈａｍｂｅｒｓらによるクラス階層解析（Ｃｌａｓｓ　Ｈｉｅｒａｒｃｈｙ　Ａｎａｌｙｓｉｓ：ＣＨＡ）がある．これは，クラス階層を構成するＤＡＧ（非循環グラフ）のみに着目し，それぞれのコールサイトにおいて宣言された変数および式の型からＤＡＧ上で可能なクラスを絞り込む手法である．手続き間解析を行わないので，大変高速であるが，いくつかのベンチマークでは大変有効であることが報告されている１８）． 」（第６２９頁右欄２３行〜３０行）
　
　と開示されているごとく、メソッドがユニークに決定した場合のみインライン化を行うために、グラフを用いてクラス階層解析を行い非循環グラフに着目することは、周知の技術であると認められる。
　また、該周知技術において、非循環グラフであることに着目するためには、クラス階層解析において対象となるメソッドのクラス階層グラフを作成する必要があること、非循環グラフであるか否かを判定するためには対象となるメソッドは全て参照可能である必要があることから、呼び出されるメソッド及び呼び出すメソッドを含む全てのメソッドがパッケージに属することが保証されているかどうか判定すること、及び、この判定の結果として、パッケージに属すると判定された各々のメソッドを識別することは、該周知技術においても、当然行われていると認められる。
　
　また、その際、上記（相違点１）で述べたように、Ｊａｖａにおいては、各スナップショットにアクセスするために、そのアクセス許可を得ることは、当然なされる事項である。
　
　引用例１発明のＪａｖａ実行時に、「前記パッケージが封印され署名されていることを検証するステップ」を行った後に、最適化技術を適用することは、当業者であれば当然考慮すべき事項であることから、上記周知技術を用い、グラフを用いたクラス階層解析の手法を適用し、
　
　パッケージのクラスおよびインタフェースのクラス階層グラフを得て（上記周知技術に記載されている、「クラス階層解析を行い」に相当する。）、
　呼び出しの全てのスナップショット（上記周知技術に記載されている、「メソッド」に相当する。）がパッケージに属することが保証されているかどうかを判定するために、クラス階層グラフおよびアクセス許可を使用し、
　Ｊａｖａ封印パッケージにおいてそのスナップショットが前記パッケージに属することが保証されている呼び出しを識別する
　
ことは、適宜為し得ることである。
　
　そして、本願補正発明の作用効果も、引用例１発明、引用例２発明及び周知技術から当業者が予測できる範囲のものである。
　したがって、本願補正発明は、引用例１発明、引用例２発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件手続補正は、平成１５年改正前特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に違反するので、特許法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１５年９月２６日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１５年４月８日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「Ｊａｖａ封印パッケージにおいてそのターゲットが前記パッケージに属することが保証されている呼び出しを識別する方法であって、
　（１）前記パッケージが封印され署名されていることを検証するステップと、
　（２）前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップと、
　（３）前記パッケージ内のそれぞれのコンポーネントのアクセス許可を得るステップと、
　（４）前記呼び出しのすべてのターゲットが前記パッケージに属することが保証されているかどうかを判定するために、前記クラス階層グラフおよびアクセス許可を前記パッケージが封印され署名されているという知識と組み合わせて使用するステップとを含む方法。」
　
（１）特許法第３６条第６項第２号について
　本願請求項１の記載は、本願補正後の請求項１の記載から「前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」の限定事項である「そうである場合に、」を省いたものであるが、該限定事項を省いたものも、前記「２．（３）ａ．」に記載した理由と同様の理由により、特許法第３６条第６項２号の規定する要件を満たしていない。
　
（２）特許法第２９条第１項柱書について
　本願発明は、本願発明の構成要件を全て含み、さらに特定の限定を施したものに相当する本願補正発明から、「前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」の限定事項である「そうである場合に、」を省いたものであるが、該限定事項を省いたものも、前記「２．（３）ｂ．」に記載した理由と同様の理由により、特許法第２９条第１項柱書の規定により特許を受けることができない。
　
（３）特許法第２９条第２項について
ａ．引用例
　引用例とその記載事項、及び、周知技術は、前記「２．（３）ｃ．」に記載した通りである。
　
ｂ．対比・判断
　本願発明は、前記「２．（３）ｃ．」で検討した本願補正発明から「前記パッケージのクラスおよびインタフェースのクラス階層グラフを得るステップ」の限定事項である「そうである場合に、」を省いたものである。
　
　そうすると、本願発明の構成要件を全て含み、さらに特定の限定を施したものに相当する本願補正発明が、前記「２．（３）ｃ．」に記載したとおり、引用例１発明、引用例２発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１発明、引用例２発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
（４）むすび
　以上の通り、本件出願は、特許請求の範囲の記載に不備があり、特許法第３６条第６項第２号に規定する要件を満たしていない。また、本願発明は、特許法第２９条第１項柱書及び特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。