【事件の表示】
　特願２００６−５４０５９５「コンピューティング装置における資源の割振り」拒絶査定不服審判事件〔平成１７年　６月　９日国際公開、ＷＯ２００５／０５２７８７、平成１９年　５月２４日国内公表、特表２００７−５１３４０９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　　
　本願は，
　２００３年１１月２１日（以下「優先日」という。）の英国特許庁への出願を基礎とするパリ条約による優先権主張をともない，
　２００４年１１月１９日を国際出願日とする出願（（国際出願番号：ＰＣＴ／ＧＢ２００４／００４８８６）であって，
平成１８年５月１９日付けで特許法第１８４条の５第１項の規定による書面が提出され，
平成１８年７月１１日付けで特許法第１８４条の４第１項の規定による特許請求の範囲，明細書，要約書の翻訳文が提出され，
平成１９年１１月１２日付けで審査請求がなされ，
平成２２年１１月１２日付けで拒絶理由通知（同年１１月１６日発送）がなされ，
平成２３年２月４日付けで意見書が提出されるとともに，同日付けで手続補正書が提出され，
同年３月７日付けで拒絶査定（同年同月１４日謄本送達）がなされ，
同年６月１６日付けで審判請求がされるとともに，同日付けで手続補正書が提出されたものである。
　
　なお，平成２３年７月７日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ，
同年１２月１２日付けで当該報告に対する意見を求める旨の審尋（同年同月１６日発送)がなされたが，これに対する回答はなされなかった。
　
 　　 
２．本願発明
　
　本願の請求項１に係る発明は，平成２３年６月１６日付けの手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。（以下「本願発明」という。）
　
　「プロセッサがコンピュータ・ソフトウェアを実行することによりコンピューティング装置を動作させる方法であって，
　第２のプロセスに割り振られた資源を第１のプロセスが利用できるようにするために，前記第１のプロセスに一時的な識別子を割り振ることと，
　前記第１のプロセスにおいて，前記資源の識別情報ではなく前記割り振られた前記一時的な識別子を用いて前記資源を利用することと，
　前記一時的な識別子を用いた前記第１のプロセスにおける前記資源の利用が終了した後は，前記第１のプロセスによる前記資源への更なるアクセスを禁止することと，
を有することを特徴とする方法。」
　
　
３．先行技術 
　　
３．１　引用文献１に記載されている技術的事項及び引用発明の認定
　
　本願の出願前であって，上記優先日よりも前の日に頒布され，原審の拒絶の査定の理由である上記平成２２年１１月１２日付けの拒絶理由通知で引用された，特表２００２−５１９７６４号公報（平成１４年７月２日公表，以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。 
　（当審注：下線は，参考のために当審で付与したものである。） 
　　　
　Ａ「【請求項１】複数のリソース（２１８−２２２）へのアクセスを必要とするリクエスタ（２１２−２１６）を有するシステムにおいて，
アクセスメディエータ（２００）と複数のリソース（２１８−２２２）との間の通信を提供する方法において，
　複数のハンドルを記憶するための領域を割り当て（１１０２），
　リクエスタがリソースの少なくとも１つにアクセスすることを要求した時，そのリクエスタに対して，固有の数値を持つ新しいハンドルを発行し（３１０），
　一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタとし（３１２），
　発行されたハンドルを解除し，各々のハンドル値が，リクエスタにとって不要となったハンドルに対して割り当てられていないとみなす（３１４）
　ことを特徴とする方法
　　
　Ｂ「【０００８】
  本発明は，ハンドル・アドミニストレータを有するリソースマネージャーと，複数のコンシューマーと，複数のリソースを含む。以下の記述において，「コンシューマー」とは，特に，リソースへのアクセスを求めるソフトウエア・モジュール（例えば，ダイナミック・リンク・ライブラリー・ファイルへのアクセスを求めるプリンター・ドライバー）を指す。
「リソースマネージャー」という用語は，リソースを管理する，又は少なくともリソースへのコンシューマーのアクセスを仲介する，ソフトウエア・モジュールを指す。
　【００１０】
  本発明の一つの特徴は，ハンドル割り当ておよび解除が一定時間（ｃｏｎｓｔａｎｔ−ｔｉｍｅ）オペレーションであるということであり，これは特に同時に活動するハンドルの数が大きい場合に重要である。もう一つの特徴は，
本発明のハンドル・アドミニストレータは，マルチスレッド環境で効果的に働く効率的な割り当て，解除，デリファレンス・ルーチンを有しているということである。
　
　Ｃ「【００１４】
    概観
    動作環境の例
  図１およびそれに続く議論は，本発明を実施できる適当なコンピューティング環境を簡単に，一般的に記述することを意図している。必要ではないが，
本発明は，パーソナル・コンピュータによって実行される
プログラム・モジュールなど
で記述される。
本発明は，他のコンピュータ・システム形態，例えば，
マイクロプロセッサ・ベースの又はプログラム可能なコンシューマー用エレクトロニクス，ネットワークＰＣ，ミニコンピュータ
等，によっても実施できる
　
　Ｄ「【００１９】
    基本システム
  図２は，本発明の主なコンポーネントの間の相互作用を示す一般的なブロック図である。本発明は，
リソースマネージャー２００
リソースマネージャー２００はまた，２００ハンドル・アドミニストレータ２３０を有する。
　【００２０】
　・・・（中略）・・・ハンドル・アドミニストレータ２３０は，あるコンシューマーがある特定のリソースへのアクセスを求めたとき，参照ハンドルによって仲介する。仲介は，コンシューマーにある特定のリソースへの直接ポインターを許可することではなく，その特定のリソースへのハンドルをそのコンシューマーに発行するということである。コンシューマーは，そのハンドルを用いてそのリソースに直接アクセスすることはできない。そうではなく，コンシューマーは，そのハンドルをハンドル・アドミニストレータ２３０に提示し，ハンドル・アドミニストレータはまず最初にそのハンドルが有効であることを検証し，
次にハンドルをデリファレンスしてそのコンシューマーのためにそのリソースへのポインターを取得する。すなわち，仲介によって，特定リソースがまだ存在することが確認されてから，その特定リソースへのアクセスがコンシューマーに認められる。
　
　Ｅ「【００２２】
  図３は，本発明のハンドル・アドミニストレータの一般的動作を説明するフローチャートである。図３と合わせて図２を参照して説明すると，
ハンドル・アドミニストレータ２３０は，
割り当てルーチン３１０
解除ルーチン３１２
デリファレンス・ルーチン３１４，によって上述の動作を実行する。本発明は，これらの動作の各々を，リソースマネージャー２００においてコードで呼び出される関数という形で設けている。
　
　　Ｆ「【００２４】
  理論的にはハンドルはどんなタイプの値であっても良い。何故なら，それは，リソースマネージャー２００にも，コンシューマー２１２，２１４，２１６にも不透明であるからである。本発明では，ハンドルは，無署名の整数である。その最も基本では，本発明のデータ構造はレコード（記録）のアレーからなり，その各々が表１に記述されているフィールドを含んでいる。
　・・・（中略）・・・　
【００２７】
  最初は，各レコードのハンドル値は，
表２
現在，有効な各ハンドルはそのアレーのレコードに対応する。」　
　
　Ｇ「【０１１３】
    マルチスレッド
  
ハンドル・アドミニストレータは，割り当て，解除，デリファレンスルーチン３１０，３１４，３１２それぞれについてマルチスレッドサブルーチン４２６，４３７，４３８のあるマルチスレッド環境で展開される。マルチスレッド環境での衝突の可能性があるため，異なるスレッドが共通のデータ構造を利用する場合に互いに干渉することを防ぐロックを採用するのが一般的である。
本発明には，さらに制約の少ない形のロックが可能なメカニズムが含まれる。この場合，１つのスレッドのみ読み書き特権でデータベースにアクセスできるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセスできる。
　【０１１４】
　特に，システムにはロックが含まれる。
ａｓｓｉｇｎ  ｈａｎｄｌｅ（）ルーチンを呼び出すため，まずこのロックを取る。ｒｅｌｅａｓｅ  ｈａｎｄｌｅ（）ルーチンを呼び出すため，まずこのロックを取る。しかし，ロックはｄｅｒｅｆｅｒｅｎｃｅ  ｈａｎｄｌｅ（）を呼び出すため取る必要はない。
　【０１１５】
   まず，マルチスレッドによって問題が生じるかもしれない状況を考える。
ある状況下ではｄｅｒｅｆｅｒｅｎｃｅ  ｈａｎｄｌｅ（）ルーチンが，他のスレッドで発生しているｒｅｌｅａｓｅ  ｈａｎｄｌｅ（）の呼出によって無効にされるプロセス内にあるハンドルを有効にしようとすることが発生する。・
・レコードからポインタの値を読み取り，ローカルに保存する。
・レコードからハンドルの値を読み取り，パスしたハンドルに対して検証する。
・ハンドルが有効な場合，保存したポインタをローカルに戻し，そうでない場合，ヌルポインタを返す。」
　　
　以下に，上記引用文献１の記載事項について検討する。
　
（ア）引用文献１の記載は，上記Ａに記載の請求項１に記載されているごとく，
　「アクセスメディエータ（２００）と複数のリソース（２１８−２２２）との間の通信を提供する方法において，複数のハンドルを記憶するための領域を割り当て（１１０２），リクエスタがリソースの少なくとも１つにアクセスすることを要求した時，そのリクエスタに対して，固有の数値を持つ新しいハンドルを発行し（３１０），一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタとし（３１２），発行されたハンドルを解除し，各々のハンドル値が，リクエスタにとって不要となったハンドルに対して割り当てられていないとみなす（３１４）ことを特徴とする方法」の発明について説明するものであるところ，
　上記「アクセスメディエータ（２００）」は，上記Ｄの「リソースマネージャー２００」との記載，上記Ｂの「「リソースマネージャー」という用語は，リソースを管理する，又は少なくともリソースへのコンシューマーのアクセスを仲介する，ソフトウエア・モジュールを指す。」との記載を参照すると，「リソースマネージャー」を指しているものであると認められ，また，上記Ｄに「リソースマネージャー２００はまた，２００ハンドル・アドミニストレータ２３０を有する。」との記載，上記Ｂに「本発明のハンドル・アドミニストレータは，マルチスレッド環境で効果的に働く効率的な割り当て，解除，デリファレンス・ルーチンを有しているということである。」との記載があり，これらの記載から，リソースマネージャーが有するハンドル・アドミニストレータは，マルチスレッド環境で実行される割り当て，解除，デリファレンス・ルーチンを有すること，がよみとれる。
　したがって，引用文献１には，
　“リソースマネージャーと複数のリソースとの間の通信を提供する方法において，
　前記リソースマネージャーが有するハンドル・アドミニストレータは，マルチスレッド環境で実行される割り当て，解除，デリファレンス・ルーチンを有し，
　リクエスタがリソースの少なくとも１つにアクセスすることを要求した時，そのリクエスタに対して，固有の数値を持つ新しいハンドルを発行し，
  一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタとし，
  発行されたハンドルを解除し，各々のハンドル値が，リクエスタにとって不要となったハンドルに対して割り当てられていないとみなす，ことを特徴とする方法”
　が記載されていると言える。 
　
（イ）上記（ア）での検討結果における「リソースマネージャーと複数のリソースとの間の通信を提供する方法」に関して，
　上記Ｃに「本発明は，パーソナル・コンピュータによって実行される・・・プログラム・モジュールなど・・・で記述される。」との記載があり，これより，引用文献１に記載の発明である「方法」が，コンピュータで実行できるプログラム・モジュールで記述されることがよみとれ，また，同上記Ｃに「本発明は，他のコンピュータ・システム形態，例えば，・・・マイクロプロセッサ・ベースの又はプログラム可能なコンシューマー用エレクトロニクス，ネットワークＰＣ，ミニコンピュータ・・・等，によっても実施できる」との記載があり，これより，引用文献１に記載の発明である「方法」が，マイクロプロセッサ・ベースのコンピュータにより実施されるものであることがよみとれる。
　したがって，引用文献１には，“リソースマネージャーと複数のリソースとの間の通信を提供する方法”が，“コンピュータで実行できるプログラム・モジュールで記述され，マイクロプロセッサ・ベースのコンピュータにより実施されるものである”ことが記載されていると言える。
　
（ウ）上記（ア）での検討結果における「リクエスタがリソースの少なくとも１つにアクセスすることを要求した時，そのリクエスタに対して，固有の数値を持つ新しいハンドルを発行し」に関して，
　まず，上記Ｅに「ハンドル・アドミニストレータ２３０は，・・・割り当てルーチン３１０，・・・解除ルーチン３１２，・・・デリファレンス・ルーチン３１４，によって上述の動作を実行する。」，「発明は，これらの動作の各々を，リソースマネージャー２００においてコードで呼び出される関数という形で設けている。」との記載があり，これより，上記「リクエスタがリソースの少なくとも１つにアクセスすることを要求した時，そのリクエスタに対して，固有の数値を持つ新しいハンドルを発行」することが，「ハンドル・アドミニストレータ」の有する「ルーチン」により関数を呼び出して実行されるものと認められる。
　次に，当該「ハンドル・アドミニストレータの有するルーチン」が「マルチスレッド環境」で実行される場合について，上記Ｇに「割り当て，解除，デリファレンスルーチン３１０，３１４，３１２それぞれについてマルチスレッドサブルーチン４２６，４３７，４３８のあるマルチスレッド環境で展開される。」，「この場合，１つのスレッドのみ読み書き特権でデータベースにアクセスできるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセスできる。」，「ａｓｓｉｇｎ  ｈａｎｄｌｅ（）ルーチンを呼び出すため，まずこのロックを取る。ｒｅｌｅａｓｅ  ｈａｎｄｌｅ（）ルーチンを呼び出すため，まずこのロックを取る。しかし，ロックはｄｅｒｅｆｅｒｅｎｃｅ  ｈａｎｄｌｅ（）を呼び出すため取る必要はない。」との記載があり，この記載によれば，「マルチスレッド環境」において「ハンドル・アドミニストレータの有するルーチン」が実行される場合には，「スレッド」による「データベース」への「アクセス」を対象として「ルーチン」により関数を呼び出して処理を実行していることから，当該「スレッド」とは，「マルチスレッド環境」での「ハンドル・アドミニストレータの有するルーチン」実行時における「リクエスタ」を意味する実施例として記載されたものと認められる。
　これらを合わせると，引用文献１には，
　“マルチスレッド環境においてハンドル・アドミニストレータの有するルーチンが実行される場合に”，“スレッドがリソースの少なくとも１つにアクセスすることを要求した時，そのスレッドに対して，固有の数値を持つ新しいハンドルを発行し”が記載されていると言える。
　
（エ）上記（ア）での検討結果における「一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタとし」に関して，
　上記（ウ）での検討内容と同様に，上記「一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタと」することも，「ハンドル・アドミニストレータ」の有する「ルーチン」により関数を呼び出して実行されているものと認められる。
　なお，上記「デリファレンスしてアクセスを必要とするリソースのポインタとし」に関して，上記Ｄに「次にハンドルをデリファレンスしてそのコンシューマーのためにそのリソースへのポインターを取得する。すなわち，仲介によって，特定リソースがまだ存在することが確認されてから，その特定リソースへのアクセスがコンシューマーに認められる。」との記載があり，これより，「デリファレンスしてアクセスを必要とするリソースのポインタと」することは，“デリファレンスしてアクセスを必要とするリソースのポインタを取得して，リソースへのアクセスが許可される”ことであると認められる。
　以上のことから，引用文献１には，
　“マルチスレッド環境においてハンドル・アドミニストレータの有するルーチンが実行される場合に”，“一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタを取得して，リソースへのアクセスが許可される”が記載されていると言える。
　
（オ）上記（ア）での検討内容における「発行されたハンドルを解除し，各々のハンドル値が，リクエスタにとって不要となったハンドルに対して割り当てられていないとみなす」に関して，
　上記（ウ）での検討内容と同様に，上記「発行されたハンドルを解除し，各々のハンドル値が，リクエスタにとって不要となったハンドルに対して割り当てられていないとみなす」ことも，「ハンドル・アドミニストレータ」の有する「ルーチン」により関数を呼び出して実行されているものと認められることから，これより，引用文献１には，
　“マルチスレッド環境においてハンドル・アドミニストレータの有するルーチンが実行される場合に”，“発行されたハンドルを解除し，各々のハンドル値が，スレッドにとって不要となったハンドルに対して割り当てられていないとみなし”が記載されていると言える。
　
（カ）上記Ｇに「ハンドル・アドミニストレータは，割り当て，解除，デリファレンスルーチン３１０，３１４，３１２それぞれについてマルチスレッドサブルーチン４２６，４３７，４３８のあるマルチスレッド環境で展開される。」，「マルチスレッド環境での衝突の可能性があるため，異なるスレッドが共通のデータ構造を利用する場合に互いに干渉することを防ぐロックを採用するのが一般的である。」，「本発明には，さらに制約の少ない形のロックが可能なメカニズムが含まれる。この場合，１つのスレッドのみ読み書き特権でデータベースにアクセスできるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセスできる。」との記載があり，これより，引用文献１には，“マルチスレッド環境においてハンドル・アドミニストレータの有するルーチンが実行される場合に”，“異なるスレッドが共通のデータ構造を利用する場合の干渉を防ぐロックにより，１つのスレッドのみ読み書き特権でデータベースにアクセス可能となるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能となる”が記載されていると言える。
　
　以上，（ア）〜（カ）を踏まえると，引用文献１には，次の発明（以下，「引用文献１発明」という。）が記載されているものと認める。
　
　コンピュータで実行できるプログラム・モジュールで記述され，マイクロプロセッサ・ベースのコンピュータにより実施されるものである，リソースマネージャーと複数のリソースとの間の通信を提供する方法において，
　前記リソースマネージャーが有するハンドル・アドミニストレータは，マルチスレッド環境で実行される割り当て，解除，デリファレンス・ルーチンを有し，
　マルチスレッド環境においてハンドル・アドミニストレータの有するルーチンが実行される場合に，
　複数のハンドルを記憶するための領域を割り当て，
　スレッドがリソースの少なくとも１つにアクセスすることを要求した時，そのスレッドに対して，固有の数値を持つ新しいハンドルを発行し，
　一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタを取得して，リソースへのアクセスが許可され，
　発行されたハンドルを解除し，各々のハンドル値が，スレッドにとって不要となったハンドルに対して割り当てられていないとみなし，
　異なるスレッドが共通のデータ構造を利用する場合の干渉を防ぐロックにより，１つのスレッドのみ読み書き特権でデータベースにアクセス可能となるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能となることを特徴とする方法。
　
　
３．２  引用文献２に記載されている技術的事項
　
　本願の出願前であって，上記優先日よりも前の日に頒布され，原審の拒絶の査定の理由である上記平成２２年１１月１２日付けの拒絶理由通知で引用された，特開平１０−３０１８５６号公報（平成１０年１１月１３日出願公開，以下，「引用文献２」という。）には，図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。）
　
　Ｈ「【００５４】図７のフローチャートに示す順序に従い，図１のクローズ処理を詳細に説明する。図７は，本発明のクローズ処理フローチャートを示す。
【００５５】図７において，Ｓ８１は，アプリケーション１がクローズ関数を発行する。Ｓ８２は，
ファイルシステム３がクローズ処理を行う。
【００５６】・ファイル名：
・ファイル属性：
・ファイルシステムへの復帰アドレス：
・その他
Ｓ８４は，フォルダのチェックがＯＫか判別する。ＹＥＳの場合（クローズ対象のファイルが存在するなどの場合）には，Ｓ８６に進む。ＮＯの場合には，Ｓ８５で復帰アドレスへ復帰し，通常のクローズ処理をする。
【００５７】Ｓ８６は，オープン処理時に更新した属性テーブルに当該要求のファイルハンドルがあるか否かをチェックする。ＹＥＳの場合には，Ｓ８９に進む。ＮＯの場合には，Ｓ８７で復帰アドレスへ復帰し，通常のクローズ処理をする。
【００５８】・システムファイル：
・隠しファイル：
・ドライバファイル：
・その他
Ｓ８９は，
属性テーブルに保存していたファイルハンドルを消去
　
　
４．対比・判断
　
４．１　本願発明と引用文献１発明との対比 
 　 
 　本願発明と引用文献１発明とを対比する。
　
（ア）引用文献１発明の「コンピュータで実行できるプログラム・モジュール」，「コンピュータ」は，本願発明の「コンピュータ・ソフトウェア」，「コンピューティング装置」にそれぞれ相当する。また，引用文献１発明における「プログラム・モジュール」を実行する「コンピュータ」は「マイクロプロセッサ・ベース」であることから，該「プログラム・モジュール」の実行に当たっては「マイクロプロセッサ」により実行されていると言うことができ，よって，引用文献１発明の「コンピュータ」が「プログラム・モジュール」を「実行」することは，本願発明の「プロセッサがコンピュータ・ソフトウェアを実行する」に相当する。
　
（イ）引用文献１発明の「方法」は「リソースマネージャーと複数のリソースとの間の通信を提供する」ものであるところ，これは「マイクロプロセッサ・ベース」の「コンピュータ」が「プログラム・モジュール」を「実行」することで実現しており，またこれは「コンピュータ」の「動作」に他ならない。
　したがって，引用文献１発明と本願発明とは，“プロセッサがコンピュータ・ソフトウェアを実行することによりコンピューティング装置を動作させる方法”である点で共通すると言える。
　
（ウ）
　ア．引用文献１発明の「リソース」は，本願発明の「資源」に相当し，また，引用文献１発明の「データべース」についても「スレッド」により「アクセス」されるものであることから「リソース」であり，同じく本願発明の「資源」に相当する。
　
　イ．引用文献１発明の「スレッド」は，本願発明の「プロセス」に対応するものであるが，いずれもプログラムがプロセッサにより実行される際の実行単位であることから，両者は，“プログラム実行単位”である点で共通する。
　
　ウ．引用文献１発明の「１つのスレッド」は，本願発明の「第２のプロセス」に対応するものであるところ，引用文献１発明における「１つのスレッドのみ読み書き特権でデータベースにアクセス可能とする」中の「データベース」は，「１つのスレッドのみ読み書き特権で」「アクセス可能と」されているものであることから，「１つのスレッド」に割り振られたものであると言え，したがって，引用文献１発明の「１つのスレッドのみ」「アクセス可能」とした「データベース」と，本願発明の「第２のプロセスに割り振られた資源」とは，“第２のプログラム実行単位に割り振られた資源”である点で共通すると言える。　
　
　エ．引用文献１発明の「他のスレッド」は，本願発明の「第１のプロセス」に対応するものであるところ，引用文献１発明における「あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能となる」中の「データベース」は，「他のスレッド」により「読み取りアクセスで」「アクセス可能と」なっている一方で，「書きこみアクセスの途中」でもあることから，「他のスレッド」以外の「スレッド」すなわち「読み書き特権」を有する「１つのスレッド」によって「書きこみアクセスの途中」になっているものと解され，したがって，引用文献１発明における「書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能とする」の「データベース」は，「１つのスレッド」に割り振られた「データベース」であると言える。
　また，本願発明の「プロセス」による「資源」の「利用」については，「利用」のために「資源」への「アクセス」が必要であることから，上位概念において「アクセス」に当たるものであると言える。
　以上のことから，引用文献１発明の「１つのスレッドのみ読み書き特権でデータベースにアクセス可能となるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能となる」ことと，本願発明の「第２のプロセスに割り振られた資源を第１のプロセスが利用できるようにする」ことは，“第２のプログラム実行単位に割り振られた資源を第１のプログラム実行単位がアクセスできるようにする”ことである点で共通すると言える。
　
　オ．引用文献１発明の「ハンドル」は，「１つのスレッド」や「他のスレッド」を含む「スレッド」に「発行」されるものであり，本願発明の「識別子」に対応するものであるところ，当該「ハンドル」は「一定時間有効な」ものであることから「一時的な」ものであると言え，一方，本願発明の「識別子」は，詳細な説明を参酌するに「ハンドル」を指すものであることから，引用文献１発明の「一定時間有効な」「ハンドル」は，本願発明の「一時的な識別子」に相当するものであり，また，引用文献１発明の「ハンドル」の「発行」は，「複数のハンドル」を複数の「スレッド」に分けて与えていることから，本願発明の「識別子」を「割り振ること」に相当する。
　したがって，引用文献１発明の「他のスレッド」である「スレッドに対して，固有の数値を持つ新しいハンドルを発行」することと，本願発明の「第１のプロセスに一時的な識別子を割り振ること」とは，“第１のプログラム実行単位に一時的な識別子を割り振ること”である点で共通すると言える。
　
　カ．これらを合わせると，引用文献１発明の「他のスレッド」「に対して，固有の数値を持つ新しいハンドルを発行」することにより「１つのスレッドのみ読み書き特権でデータベースにアクセス可能となるが，あらゆる数の他のスレッドは，書きこみアクセスの途中でも読み取りアクセスでデータベースにアクセス可能となる」ことと，本願発明の「第２のプロセスに割り振られた資源を第１のプロセスが利用できるようにするために，前記第１のプロセスに一時的な識別子を割り振ること」とは，“第２のプログラム実行単位に割り振られた資源を第１のプログラム実行単位がアクセスできるようにするために，前記第１のプログラム実行単位に一時的な識別子を割り振ること”である点で共通すると言える。
　
　（エ）引用文献１発明の「一定時間有効なハンドルをデリファレンスしてアクセスを必要とするリソースのポインタとし」における「ハンドル」は，「１つのスレッド」や「他のスレッド」を含む「スレッド」に対して「発行」されるものであり，また「スレッド」は当該「ハンドル」をもとに「リソースへのアクセスが許可され」，「データベースにアクセス可能」となっていることから，「スレッド」は「ハンドル」を用いて「データベースにアクセス可能」となっていると言える。
　また，引用文献１発明の「リソース」を示す「ポインタ」は資源を識別する情報であると言うことができるとともに，「ハンドル」を「デリファレンス」して「取得」できるものであり，また，引用文献１における上記Ｆに記載の表２についての説明及び表２の記載からして，「ハンドル」と「リソース」を示す「ポインタ」とは異なるものであると言える。
　したがって，引用文献１発明の「他のスレッド」である「スレッド」において，「リソース」を示す「ポインタ」とは異なるものである「発行」された「一定時間有効なハンドル」によって「データベースにアクセス」することと，本願発明の「第１のプロセスにおいて，前記資源の識別情報ではなく前記割り振られた前記一時的な識別子を用いて前記資源を利用すること」とは，“第１のプログラム実行単位において，前記資源の識別情報ではなく割り振られた前記一時的な識別子を用いて前記資源にアクセスすること”である点で共通すると言える。
　
　以上の対比から，本願補明と引用文献１発明とは，以下の点で一致し，また，以下の点で相違する。
　
〈一致点〉
　　
　プロセッサがコンピュータ・ソフトウェアを実行することによりコンピューティング装置を動作させる方法であって，
　第２のプログラム実行単位に割り振られた資源を第１のプログラム実行単位がアクセスできるようにするために，前記第１のプログラム実行単位に一時的な識別子を割り振ることと，
　前記第１のプログラム実行単位において，前記資源の識別情報ではなく割り振られた前記一時的な識別子を用いて前記資源にアクセスすることと，
を有する方法。　
　
〈相違点１〉　
　資源にアクセスするプログラム実行単位について，本願発明が「プロセス」であるのに対し，引用文献１発明は「スレッド」であるとしている点。
　
〈相違点２〉　
　プログラム実行単位による資源へのアクセス内容について，本願発明が「利用」であるとしているのに対し，引用文献１発明は「アクセス」であり，「利用」であるとまでは明確にしていない点。
　
〈相違点３〉
　資源利用終了後の処理について，本願発明が「第１のプロセスにおける前記資源の利用が終了した後は，前記第１のプロセスによる前記資源への更なるアクセスを禁止する」としているのに対し，引用文献１発明はそのような構成になっていない点。
　
　
４．２　当審判断
　
　〈相違点１〉について
　情報処理装置におけるプログラムの実行単位として，プロセス及びスレッドはいずれも普通に用いられるものであり（引用文献１の上記Ｇの【０１１５】における記載でも，プロセス及びスレッドが情報処理の実行対象として扱われている），いずれをプログラムの実行単位とするかは，適宜決める設計的事項である。
　してみると，引用文献１発明において，データベースにアクセスするプログラムの実行単位をプロセスとすること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１は格別なものではない。　 
　　
　〈相違点２〉について
　情報処理装置においてデータ集合へアクセスする際に，当該データの「利用」を前提として行うことは，通常よく行われている技術事項（引用文献１発明においても，「読み書き特権」で「アクセス」を行ったり，「書きこみアクセス」を行っていることから，データベースを読む又は書き込む，という「利用」を前提にアクセスを行っている）である。
　してみると，引用文献１発明において，データベースへアクセスし利用すること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点２は格別なものではない。　 
　　
　〈相違点３〉について
　ファイルへアクセスするためのシステムにおいて，ファイルへのクローズ処理が行われた後に，アプリケーションに割り当てられたファイルのハンドルを消去することは，引用文献２（特に上記Ｈの記載を参照。）に記載されており，ファイルへのクローズ処理が実施される時とはすなわちファイルへの利用が終了した後にほかならず，また，ファイルのハンドルを消去することは，それにより，ファイルへのアクセスは実質的に行えなくなることから，ファイルへのアクセスを禁止することに等しいということができる。
　してみると，引用文献１発明においてアクセスを一定期間だけ有効なものとする際に，上記引用文献２に記載の事項を適用し，スレッドによるデータベースへのアクセスが終了した後は，スレッドによるデータベースへの更なるアクセスを禁止するようにすること，すなわち，相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点３は格別なものではない。　 
　　
　そして，本願発明により奏する効果も，引用文献１発明及び引用文献２に記載された事項から当然予想される範囲内のものにすぎず，格別顕著なものとは認められない。
　
　
５．むすび
　
　以上のとおり，本願発明は，引用文献１発明及び引用文献２に記載された事項に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができないものであり，他の請求項についての検討をするまでもなく，本願は拒絶されるべきものである。
　
　よって，結論のとおり審決する。