【事件の表示】
　特願２０００−１６９９５１「オブジェクトを管理する方法、システム及びプログラム記憶装置」拒絶査定不服審判事件〔平成１３年　２月　９日出願公開、特開２００１−　３４４７６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願の手続の経緯は次のとおりである。
出願　　　　　　　　　　平成１２年６月７日（優先権主張１９９９年６月　　　　　　　　　　　　１４日、米国）
拒絶理由の通知　　　　　平成１３年１２月２５日（起案日１２月２０日）
意見書、補正書の提出　　平成１４年６月２０日
拒絶査定　　　　　　　　平成１４年８月１９日
同　謄本送達　　　　　　平成１４年８月２２日
審判請求　　　　　　　　平成１４年１１月２０日
補正書の提出　　　　　　平成１４年１１月２０日
　
２．平成１４年１１月２０日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１４年１１月２０日付けの手続補正を却下する。
［理由］
（１）補正後の本願発明
　前記手続補正により、特許請求の範囲の請求項１乃至請求項７について、次のとおり補正された。
「【請求項１】
　
コンテナを含む
　前記１つまたは複数の属性を取得するステップと、ここで前記１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つが、
データベース管理機能を有しかつ
であってコンテナとは異なるリソース・マネージャ
　を含む、コンピューティング環境内でオブジェクトを管理する方法。
【請求項
２
　前記少なくとも１つのリソース・マネージャの１つのリソース・マネージャが、ＤＢ２である、請求項１に記載の方法。
【請求項
３
　前記サーバ・インスタンス内に配置される１つまたは複数の接続オブジェクトを使用して、前記サーバ・インスタンスを、前記少なくとも１つのリソース・マネージャの１つまたは複数のリソース・マネージャに結合するステップをさらに含む、請求項１に記載の方法。
【請求項
４
　
コンテナを含む
　前記１つまたは複数の属性を取得するための手段と、ここで前記１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つが、
データベース管理機能を有しかつ
であってコンテナとは異なるリソース・マネージャ
　を含む、コンピューティング環境内でオブジェクトを管理するシステム。
【請求項
５
　前記サーバ・インスタンス内に配置される１つまたは複数の接続オブジェクトを使用して、前記サーバ・インスタンスを、前記少なくとも１つのリソース・マネージャの１つまたは複数のリソース・マネージャに結合するための手段をさらに含む、請求項４に記載のシステム。
【請求項
６
　コンピューティング環境内でオブジェクトの管理を引き起こすためのプログラムを記録したコンピュータ読み取り可能な記録媒体において
、
が、コンテナを含む
する
が
する
含む処理を実行させ、かつデータベース管理機能を有しかつ
であってコンテナとは異なるリソース・マネージャが、
を
する処理を実行させる
【請求項
７
　コンピュータ
が
する
処理を実行させる
６
　
　前記補正は、補正前の各請求項に係る、「サーバ・インスタンス」を、「コンテナを含むサーバ・インスタンス」とするとともに、
　補正前の「リソース・マネージャ」を、「データベース管理機能を有し、かつ、コンテナとは異なるリソース・マネージャ」とするものであり、請求項に記載した発明を特定するために必要な事項である、「サーバ・インスタンス」、「リソース・マネージャ」に限定を加えるものであると認められるから、特許請求の範囲の減縮を目的とするものにあたる。
　そこで、補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において第４項２号の場合に準用する同法第１２６条第４項の規定に適合するか）について検討する。
　
　以下、前掲の【請求項１】に記載された事項により特定される発明を「本願補正発明」という。
　
（２）引用例の発明
　原審の拒絶の理由に引用された、本願優先権主張日前に頒布された刊行物である、吉川著，”Ｗｅｂアプリケーションの未来を切り開くＥＪＢ”，Ｊａｖａ　ＷＯＲＬＤ，（株）ＪＤＧコミュニケーションズ，１９９９年５月１日，第３巻、第５号，ｐ．48-53（以下「引用例１」という。）には、次の事項が記載されている。
Ａ．「ＣＯＲＢＡに足りなかったもの
　読者の中には、「基幹業務システムで利用する各機能に共通性があるならば、サーバ側で利用されるＡＰＩを共通化すれば、それで問題は解決される」と考える方もおられるだろう。しかし残念ながら、それだけでは不十分である。
　例えば、オブジェクト・テクノロジーの標準化団体OMG(Object Management　Group)のCORBAは、ある意味でシステム・レベル・プログラミングの「混沌」から開発者を解放する共通APIとしてとらえることができる。CORBAが規定する共通オブジェクト・サービスは、トランザクション・サービスやセキュリティ・サービス、永続化オブジェクト・サービスなど、前述した各機能を網羅しており、CORBA仕様を実装した製品が普及すれば、ベンダー各社の独自APIに振り回されることは少なくなるはずだ。
　ところが、サーバ・サイドのコンポーネント・モデルを実現するには、APIの共通化に加えて、もう1つ不可欠な仕組みがある。それは、コンポーネントを包み込むための「コンテナ」だ。
　ここで、Javaの世界になぜJavaBeansというコンポーネント・モデルが必要とされたのか、ということを考えていただきたい。
　例えば、JavaBeansが登場する以前にも、JavaにおけるGUI関連のAPIは完全に標準化されていた。JavaBeans仕様が追加されたからと言って、JavaのGUI機能が高機能になったわけではない。JavaBeansの持つ真の意義は、「プログラム・コードと、その実行環境を提供するコンテナとの間のコントラクト(取り決め)を規定したこと」にあるのだ。
　JavaBeansの登場によって、システム・レベルの処理は完全にコンテナ側(開発ツールや、JavaBeansコンポーネントを組み込んだアプリケーション側)の責任となった。これによりJavaBeansコンポーネント(Bean)の開発者は、オブジェクトの生成や削除をはじめ、「それが画面上のどこに配置されるのか」、「ウィンドウの状態管理はどうするのか」、「アプリケーションの起動や終了時の処理はどうするのか」、といった一連の問題から解放されることになったのである。換言すれば、Beanの開発者は、より抽象度の高いコード、もしくはコンポーネントとしての本質的なコードの記述に専念できることになったわけだ。
　CORBA仕様に足りなかったものは、こうしたコンテナの考え方であった。これに対してEJBは、JavaBeansと同様のコンポーネント・モデルをサーバ・サイドで実現したテクノロジーである。すなわち、「サーバ・コンポーネントとコンテナの間のコントラクトを規定した仕様」なのである。」（第４９頁中欄１１行〜右欄下８行）
Ｂ．「EJBの構成
　それではここで、EJBのメカニズムを簡単に説明することにしよう。EJBでは、以下の３種類の要素が連携し、処理が行われる。
●クライアント・プログラム
●EJBコンテナ
●Enterprise Bean
　これらのうち、開発者が用意すべきものはクライアント・プログラム(JavaアプレットやJavaアプリケーション)とEnterprise Bean(サーバ・コンポーネント)である。
　なお、EJBコンテナはEJBに対応する実行環境にEnterprise Beanをインストールすることで、自動的に生成される。この実行環境のことを「EJBサーバ」と呼ぶ。
　IBMの「WebSphere２．０」やBEAの「WebLogic」、オラクルの「Oracle Application Server」など、最近続けざまにリリースされているEJB対応のWebアプリケーション・サーバ製品は、いずれもこのEJBサーバとして動作する。
　図1と図2は、従来型のアプリケーション・サーバとEJBを対比させたものである。
　この図に示されているとおり、Enterprise Beanには純粋なビジネス・ロジックだけを記述することになる。そしてEJBコンテナは、Enterprise Beanを包み込み、スケーラビリティや信頼性に優れたサーバシステムとしてEnterprise Beanが“ひとり立ち”するのに必要な諸機能を提供する。クライアント・プログラムは、EJBコンテナを通じてEnterprise Beanのビジネス・ロジックにアクセスし、クライアントとEJBコンテナの間の通信にはRMI(下位プロトコルはIIOP)が利用される。」（第４９頁右欄下７行〜第５０頁中欄６行）
Ｃ．「トランザクションの管理
　ここで、EJBの動作メカニズムを用いて「座席を予約する」という処理を実行するケースを考えてみたい。具体的には、クライアントがEnterprise Beanの「yoyaku」メソッドを呼び出すケースを想定する。
　EJBでは、クライアントがEnterprise Beanの機能にアクセスする際、必ずEJBコンテナがメソッド呼び出しを仲介することになる。クライアントからyoyakuメソッドが呼び出されると、EJBコンテナは、まずデータベースに対してトランザクションの開始を伝達し、そのあとでEnterprise Beanのyoyakuメソッドを実際に呼び出す。処理が問題なく完了すると、EJBコンテナはデータベースに対してトランザクションのコミットを実行し、最後にメソッドの処理結果をクライアントに返す。万が一、yoyakuメソッドの実行中に何らかのサーバ障害が発生したときには、それまでに実行した更新処理はすべてロールバックされることになる。
　これが、EJBの提供する「暗黙的トランザクション」と呼ばれるメカニズムである(図３)。クライアントやEnterprise Beanの内部でトランザクション制御のコードを一切記述しなくとも、トランザクションの「原子性」が自動的に確保され、基幹業務システムに求められる信頼性が確保されるという仕組みだ。
　ちなみに、クライアントやEnterprise Beanの内部でJTS(Java Transaction Services)APIを利用して明示的なトランザクション制御を行うことも可能である。（第５０頁中欄７行〜右欄下１２行）
Ｄ．「オブジェクトの永続化
　EJBでは、以下の２種類のEnterprise Beanが規定されている。
●Session Bean
●Entity Bean
　「Session Bean」は、クライアントとの短期的なセッションを表現するためのBeanである。クライアントがEJBサーバにアクセスしている間、セッション状態を保持したり、クライアントの要求に応じてデータベース検索を実行したりするために利用される。例えば、電子ショッピング・カートなどは、Session Beanの機能で簡単に開発できる。　　　　　　　　
　一方、「Entity Bean」は永続的なオブジェクトを表現するためのBeanである。空席情報を保持する「座席オブジェクト」といった具合に、半永久的に記録しておきたい情報をEntity Beanそのものに持たせることができる。
　EJBの仕様では、EJBコンテナが「Entity Beanの永続化(データベースへの記録)に責任を持つこと」と規定されているので、Entity Beanを利用するかぎり、開発者はデータベース・アクセスのコードをまったく記述する必要はない、つまり、データ永続化のためのコーディング作業から完全に解放されるのである(図４)。
　もっとも、現在リリースされているEJB1.0仕様の段階では、このEntity Beanの機能はオプション仕様である。そのため、実際に出荷されたEJBサーバ製品のうち、Entity Beanの機能を実装しているものは少ない。Entity Beanはオブジェクト指向データベース管理システム(ODBMS)的な機能を実装するメカニズムなので、現時点でEntity　Beanの機能を提供しているベンダーはジェムストーンなどのODBMSベンダーや0/Rマッピング・ツール・ベンダーなどに限定されているのだ。
　Entity BeanがサポートされていないEJBサーバを利用する際には、Session Beanの内部でJDBC APIを呼び出すことでデータの保存や更新を行うことになる。
　ちなみに、Entity Beanは、来年第４四半期の正式リリースが予定されているEJB新仕様(開発コード名：Milano）において必須仕様になるようだ。」（第５０頁右欄下１１行〜第５１頁中欄１行）
Ｅ．「DeploymentDescriptorの効用
　EJBのもう1つの特徴は、「DeploymentDescriptor」オブジェクトを利用したセキュリティ属性やトランザクション属性の設定メカニズムを有していることにある。
　DeploymentDescriptorオブジェクトは、Java Beansにおける「BeanInfo」クラスと同等の働きを持つオブジェクトである。すなわち、Enterprise Beanの備える各種の属性値をEJBサーバに伝達する役目を担っている。BeanInfoクラスとの相違点は、DeploymentDescriptorが「Enterprise Beanの利用者が同オブジェクトの内容を操作することで、EJBサーバの動作を自由に制御できる」ことにある。
　DeploymentDescriptorオブジェクトが保持する属性情報の例を以下に紹介しよう。
●EnterpriseBeanが必要とするトランザクション機能の属性(以下参照)
　「REQUIRED」：EJBコンテナが暗黙的トランザクションを実行する。
　「BEAN＿MANAGED」：Enterprise Beanが自らトランザクション制御を行う。
●Enterprise Beanの各メソッドに対するアクセス権を持つユーザーの一覧
●Session Beanのタイムアウト時間
●Session Beanの種類(以下参照)
「STATELESS」：状態を持たないBeanを表す。EJBサーバはBeanのオブジェクトを自由に再利用できる。
「STATEFUL」：状態を持つBeanを表す。
●EntityBeanが持つフィールドの中でEJBコンテナによる永続化を必要とするものの一覧
　以上のような属性情報を保持するDeploymentDescriptorオブジェクトの内容を変更すれば、Enterprise Beanのトランザクションやセキュリティ、永続化といった各機能の動作を変更することが可能になる。したがって、Beanの利用者(Beanを組み合わせてサーバ・アプリケーションを開発する開発者)は、EnterpriseBeanのソース・コードに手を加えることなく、自分のニーズや環境に合わせてサーバ・システムの挙動をチューニングすることができるのである。
　ちなみに、今年第４四半期にリリースされる予定のEJB次期仕様(開発コード名：Moscone)では、DeploymentDescriptorオブジェクトの代わりにXMLファイルを属性情報として利用できるようになる。
　さて、ここでEJBの導入がもたらすメリットをもう一度確認しておこう。
●開発が容易：EnterpriseBeanは抽象度の高いビジネス・ロジックだけを抽出したサーバ・コンポーネントである。従来のサーバ構築につきまとってきたシステム・レベル・プログラミングが劇的に減少し、生産性や再利用性が大幅に向上する。
●優れたポータビリティ：Enterprise Beanを収めたJARファイルは、あらゆるEJBサーバ製品にそのままインストールすることができる。OSの違い、ハードウェアの違い、規模の違いなどに対する依存性はない。また、DeploymentDesdiptorオブジェクトの利用により、ソース・コードを変更することなくトランザクションやセキュリティ機能の挙動を調節することが可能だ。
　以上のように、EJBのテクノロジーは、従来のサーバ・アプリケーション開発における「複雑さ」「コード再利用性の低さ」といったネックを一掃する可能性を秘めている。業務ニーズに合わせてビジネス・ロジックをコンポーネント化したり、市販のEnterprise Beanを購入してEJBサーバにインストールしたりするだけで、短期間かつ容易にWebアプリケーションを構築することができるのである。今後、EJBサーバ製品が、企業におけるイントラネット構築を支える「定番」のサーバ製品となる日もそう遠くはなさそうだ。」（第５１頁中欄２行〜第５２頁左欄１７行）
Ｆ．図２には、EJBコンテナは、Enterprise Beanを包み込み、トランザクション管理、データ永続性の管理、セッション管理、セキュリティ管理、リソース管理、ライフサイクル管理の管理が提供されることが示されている。
図３、図４には、トランザクション管理、データ永続性の管理において、データベースに対してアクセス制御があることが示されている。
　　
（Ａ）引用例１のEJBサーバは、図２に示されたようにEJBコンテナを含み、Ｂ．の記載を参照すると、EJBコンテナを通じてEnterprise Beanのビジネス・ロジックにアクセスする時の該Enterprise Beanオブジェクトは、ロジックだけであるから、EJBサーバ内でディスパッチされるべきEnterprise Beanオブジェクトである。また、Ｅ．の記載を参照すると、Enterprise Beanの備える各種の属性値は設定メカニズムにより設定され、この設定された属性値はEJBサーバに伝達されてEJBサーバの動作の制御に用いられることから、前記属性値が伝達されて制御に用いられる過程において、EJBサーバによって属性を要求するステップ、EJBサーバが該属性を取得するステップが読み取れる。これらの点から、引用例１には、EJBコンテナを含むEJBサーバによって、前記EJBサーバ内でディスパッチされるべきEnterprise Beanオブジェクトの１つまたは複数の属性を要求するステップ、および、前記１つまたは複数の属性を取得するステップ、が示されている。
（Ｂ）引用例１の属性についての例として、Ｅ．の記載を参照すると、トランザクションやセキュリティ、永続化の属性が記載され、属性が動作の制御に用いられることは前記のとおりであり、また、前記トランザクションや永続化に関連するデータベースの制御について、図３（暗黙的なトランザクション制御）と、Ｃ．のトランザクションの管理の記載を参照すると、データベースに対しEJBコンテナからトランザクションの開始が伝達され、そのあとEnterprise Beanのメソッドを実際に呼び出し、この処理が完了すると、EJBコンテナはデータベースに対してトランザクションのコミットを実行する旨記載され、図４と、Ｄ．のオブジェクト永続化オブジェクトの記載を参照すると、永続化においては、オブジェクト指向データベース管理システム(ODBMS)的な機能を実装するメカニズムであるEntity Beanが利用できることが記載され、該データベースないし該データベース管理システム的な機能における、データベース管理システムはリソース・マネージャといえる。
　したがって、引用例１には、１つまたは複数の属性の取得において使用されたトランザクション動作の制御、セキュリティの動作の制御、および永続化の動作の制御の少なくとも１つが、データベース管理機能を有しかつ前記ＥＪＢサーバに仲介される少なくとも１つのリソース・マネージャ（データベースまたはオブジェクト指向データベース管理システム)であって、ＥＪＢコンテナとリソース・マネージャ（データベースまたはオブジェクト指向データベース管理システム）によって実行される、ステップが記載されている。
（Ｃ）引用例１には、Ａ．Ｂ．の記載を参照すると、スケーラビリティや信頼性に優れたサーバシステムを提供することが目的であり、そのため、図２〜図４とＣ．Ｄ．に記載されたように、クライアントがEnterprise Beanの機能にアクセスする場合に、トランザクション管理、データ永続性の管理、セッション管理、セキュリティ管理、リソース管理、ライフサイクル管理を有するEJBコンテナにより、コンピューティング環境内でEnterprise Beanオブジェクトを管理する方法が示されている。
　これら（Ａ）〜（Ｃ）に記載された事項をふまえると、引用例１には、スケーラビリティや信頼性に優れたサーバシステムを提供することを目的とした次の発明（以下、「引用例１の発明」という。）が開示されている。
　コンテナを含むEJBサーバによって、前記EJBサーバ内でディスパッチされるべきEnterprise Beanオブジェクトの１つまたは複数の属性を要求するステップと、
　前記１つまたは複数の属性を取得するステップと、ここで前記１つまたは複数の属性の取得において使用されたトランザクション動作の制御、セキュリティの動作の制御、および永続化の動作の制御の少なくとも１つが、データベース管理機能を有しかつ前記ＥＪＢサーバに仲介された少なくとも１つのリソース・マネージャ（データベースまたはオブジェクト指向データベース管理システム）とEJBコンテナによって実行される、
　を含む、コンピューティング環境内でEnterprise Beanオブジェクトを管理する方法。
　
（３）対比 
  本願補正発明と引用例１の発明とを対比すると、
（ａ）引用例１の発明の、「コンテナを含むEJBサーバによって、前記EJBサーバ内でディスパッチされるべきEnterprise Beanオブジェクトの１つまたは複数の属性を要求するステップ」は、本願補正発明の「コンテナを含むサーバ・インスタンスによって、前記サーバ・インスタンス内でディスパッチされるべきオブジェクトの１つまたは複数の属性を要求するステップ」に対応する。
（ｂ）引用例１の発明の、「前記１つまたは複数の属性を取得するステップ」は、本願補正発明の「前記１つまたは複数の属性を取得するステップ」に対応する。
（ｃ）引用例１の発明の、「セキュリティの動作の制御」「トランザクション動作の制御」（トランザクションがコミット制御を含むことはＣ．の記載参照）は、本願補正発明の「セキュリティ制御」「コミットメント制御」に相当し、
引用例１の発明の「前記１つまたは複数の属性の取得において使用されたトランザクション動作の制御、セキュリティの動作の制御、および永続化の動作の制御の少なくとも１つが、データベース管理機能を有しかつ前記ＥＪＢサーバに仲介された少なくとも１つのリソース・マネージャとEJBコンテナによって実行される、を含む」は、少なくとも１つの制御が実行されるものである点をふまえると、本願補正発明の「前記１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つが、データベース管理機能を有しかつ前記サーバ・インスタンスに結合された少なくとも１つのリソース・マネージャによって実行される、を含む」と実質的な差異はない。
（ｄ）引用例１の発明の「コンピューティング環境内でEnterprise Beanオブジェクトを管理する方法」は、本願補正発明の「コンピューティング環境内でオブジェクトを管理する方法」に対応する。
　したがって、引用例１の発明と本願補正発明とは、次の構成を有する発明である点では一致し、そして、次の点で相違している。
〈一致点〉
　コンテナを含むサーバ・インスタンスによって、前記サーバ・インスタンス内でディスパッチされるべきオブジェクトの１つまたは複数の属性を要求するステップと、
　前記１つまたは複数の属性を取得するステップと、ここで前記１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つが、データベース管理機能を有しかつ前記サーバ・インスタンスに結合された少なくとも１つのリソース・マネージャによって実行される、
　を含む、コンピューティング環境内でオブジェクトを管理する方法
〈相違点〉１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つを、実行するのが、本願補正発明では、リソース・マネージャであってコンテナとは異なるリソース・マネージャによって、実行されるのに対して、引用例１の発明では、データベースないしデータベース管理システム的な機能（リソース・マネージャ）とEJBコンテナによって実行される点。
　
（４）相違点についての当審判断
　ロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つを実行するのが、リソース・マネージャであって、コンテナとは異なるリソース・マネージャによって実行されることは、本願の優先権主張日前に周知の技術である。
　例えば、原審の拒絶の理由に引用された、オブジェクトデザインジャパン（株）著「第２部：オブジェクトデザイン社の戦略−ObjectStoreの概要と適用事例」ビジネスコミュニケーション，（株）ビジネスコミュニケーション社（１９９８年５月１日）第35巻、第５号，Ｐ．６８〜８０（以下、「引用例２」という。）には、
「一般的にＤＢＭＳは２つのレイヤに分けて設計されている。まず、下層レイヤとしてストーレジ機構がある。同レイヤは、ディスク内のストーレジを管理するためのレイヤだ。ここが、データベース内のページ…（中略）…とそのキャッシュを管理する。また、ロック、バックアップ、リカバリなどの処理に対しても責任を持つ。
　同レイヤの上位にあるレイヤとして、検索エンジンが実装される。」（第７１頁右欄５行〜１４行）、
「分散コンピューティング・アーキテクチャ（以下、ＤＣＡ）と呼ぶことにする。…（中略）…ＤＣＡの基本的な構成を図７に示した…（中略）…ＤＣＡシステムは以下のコンポーネントから構成される。
データ・ベース・サーバ：データを管理する
アプリケーション・サーバ：ビジネス・ロジックを実現する
ディスパチャ：アプリケーション・サーバへの処理のディスパッチを行なう」（第７５頁左欄１行〜右欄６行）
と記載されており、
　前記ＤＢＭＳはリソース・マネジャに相当し、ビジネス・ロジックを実現するアプリケーション・サーバ乃至ディスパッチャは、コンテナに相当し、前記ＤＢＭＳは、アプリケーション・サーバ乃至ディスパッチャとは物理的に異なるので、引用例２から、ロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つを実行するのが、リソース・マネージャであって、コンテナとは異なるリソース・マネージャによって実行される技術が読み取れる。
　引用例１の発明において、１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つを、リソース・マネージャとEJBコンテナによって実行されるところを、リソース・マネージャであってコンテナとは異なるリソース・マネージャによって実行されると成すことは、前記周知技術を参酌することにより当業者が容易になし得ることである。
　そして、本願補正発明によって得られる作用効果も、前記引用例１の記載及び前記周知の事項から当然予想される範囲内のものであり、格別顕著なものとは認められない。
　
　したがって、本願補正発明は、引用例１に記載された発明及び前記周知の技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項において、第４項第２号の場合に準用するとしている同法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
（１）平成１４年１１月２０日付の手続補正は前記のとおり却下された。
　本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１４年６月２０日付の手続補正書における特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
「サーバ・インスタンス内でディスパッチされるべきオブジェクトの１つまたは複数の属性を、前記サーバ・インスタンスによって、要求するステップと、
　前記１つまたは複数の属性を取得するステップと、ここで前記１つまたは複数の属性の取得において使用されたロッキング、セキュリティ制御、マルチシステム・キャッシングおよびコミットメント制御の少なくとも１つが、前記サーバ・インスタンスに結合された少なくとも１つのリソース・マネージャによって実行される、ここで前記サーバ・インスタンスはコンテナを含む、
　を含む、コンピューティング環境内でオブジェクトを管理する方法。」
　
（２）引用例
　引用例１とその記載事項、及び周知の技術は、前記２．（２）、２．（４）に記載したとおりである。
（３）対比・判断
　本願発明は、前記２．の（１）乃至２．の（４）で検討した本願補正発明から、補正前の特許請求の範囲の請求項１における、
　サーバ・インスタンスを、コンテナを含むサーバ・インスタンスとするとともに、リソース・マネージャを、データベース管理機能を有し、かつ、コンテナとは異なるリソース・マネージャとする限定を省いたものであり、そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記（２）乃至（４）に記載したとおり、引用例１の発明及び前記周知の技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１及び前記周知の技術に基いて当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用例１に記載された発明、及び、周知の技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。