【事件の表示】
　平成　３年特許願第２６３６１８号「ファイル資源獲得装置」拒絶査定に対する審判事件［平成　５年　４月３０日出願公開、特開平　５−１０８４５０］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明　
　本願は、平成３年１０月１１日の出願であって、その請求項１に係る発明は、平成１４年９月５日付で補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載されたとおりの次のもの（以下、本願発明という。）である。
　
「【請求項１】ジョブが処理を実行するためにファイルを獲得するファイル資源獲得装置であって、　
　ファイルのファイル識別子、および、該ファイルを獲得しているジョブのジョブ識別子が対応づけて管理される資源管理テーブルと、　
　前記ジョブの資源事前獲得要求が通知されると、該ジョブを構成する個々のタスクが必要とするファイルについて、前記資源管理テーブルに当該ファイルの識別子が他ジョブ識別子と対応づけて登録されているか判定し、登録されていなければ、該資源管理テーブルに該資源事前獲得要求を通知したジョブを該ファイルと対応づけて登録する資源事前獲得手段と　
　を備えることを特徴とするファイル資源獲得装置。」　
　
２．刊行物　
　これに対して、原査定の拒絶の理由に引用された特開平２−１９５４５３号公報（平成２年８月２日出願公開、以下、刊行物１という。）、本願出願前に頒布された刊行物である特開平１−２８０８４５号公報（平成１年１１月１３日出願公開、以下、刊行物２という。）、特開昭６４−７０８３８号公報（昭和６４年３月１６日出願公開、以下、刊行物３という。）には、それぞれ図面とともに、以下のことが記載されている。　
　
［刊行物１］　
（Ａ）「（従来の技術）　
　従来、マルチプログラミング環境に於いて、ファイルやレコードなどの共有資源を共有制御する場合には、・・・。　
　・・・　
　この第２図に示すファイルアクセス制御機構の動作は、先ずユーザのメインタスク０１がファイルアクセス要求を実行すると、ファイルアクセス制御機構０３は要求されたレコードがファイルアクセス制御表０５に登録されているか否かを調べる。ここでファイルアクセス制御表０５に登録されていなければ、リソース名とタスク番号を設定し、そのレコードをロックした後、ファイル０４に対しＩ／Ｏアクセスを行なう。また要求されたレコードがファイルアクセス制御表０５に登録されていれば、そのレコードをロックしているタスク番号が自分のタスク番号と同じであるかを調べ、同じであればファイル０４のＩ／Ｏアクセスを実行し、異なっていればレコードが解放されるまで待（ＷＡＩＴ）状態となる。」（・・・は引用個所の省略を意味し、以下、同様とする。）（公報１頁左下欄１８行〜２頁左上欄１６行）　
　
（Ｂ）「（課題を解決するための手段及び作用）　
　本発明によるファイルアクセス制御方式は、ノード内もしくはノード間をまたがって複数のタスクまたはプロセスなどの実行単位が連動しつつ一つの機能を分担遂行するとき、この連動処理関係そのものに固有のＩＤ（これをプロセシングＩＤと称す）を付与することにより、複数の実行単位からの要求を同一要求者と見做して、資源の排他制御および共有制御を行なう機構をもつ構成としたもので、これにより効率の良いデータ処理機構を容易に実現できる。　
（実施例）　
　・・・　
　図中、１はユーザのメインタスク、２はユーザのサブタスク、３はファイルアクセス制御機構、４はファイルである。５はファイルアクセス制御機構３により参照されるファイルアクセス制御表であり、ここではソース名（リソース名の誤記と認められる。）とプロセシングＩＤが登録の対象となる。　
　・・・　
　そして、このプロセシングＩＤをパラメータとしてファイルアクセス要求が実行される。ファイルアクセス制御機構３はこのファイルアクセス要求を受けて上述した第２図の場合と同様にレコードの排他制御を行なうが、ここではタスク番号による排他制御ではなく、プロセシングＩＤに従って排他制御を行なう。ファイルアクセス制御表５に登録されるのは、リソース名とプロセシングＩＤである。」（公報第２頁左下欄２行〜３頁左上欄２行）
　
　上記（Ａ）、（Ｂ）及び図面を勘案すると、刊行物１には、　
　
　連動しつつ一つの機能を分担遂行する複数のタスクからなる連動処理関係を実行するためにファイルやレコードのリソースをロックするファイルアクセス制御方式であって、　
　リソース名、及び、該リソースをロックしている連動処理関係の固有のＩＤであるプロセシングＩＤが登録されるファイルアクセス制御表と、　
　上記連動処理関係を構成するメインタスクのファイルアクセス要求が実行されると、該メインタスクが要求したリソースについて、上記ファイルアクセス制御表に当該リソース名が登録されているか否か、及び、そのリソースをロックしているプロセシングＩＤが自分のプロセシングＩＤと同じであるか否かを調べ、登録されていなければ、該ファイルアクセス制御表に該ファイルアクセス要求をした連動処理関係のプロセッシングＩＤと該リソース名を登録するファイルアクセス制御機構と　
を備えるファイルアクセス制御方式（以下、刊行物１発明という。）　
　
が記載されていると認められる。　
　
［刊行物２］　
（Ｃ）「最初の例えばＡＳＳＩＧＮコマンドが発行されると、ファイルオープン機構２は排他管理機構３にコマンドの実行を要求するので、排他管理機構３はコマンドのファイル名パラメータで指定されたファイルの割当状況を、保持する排他制御情報を検索して識別し、使用されていないか又は共用可能な状況であれば、アクセス制御機構４を経て記憶装置５に格納されているファイル管理簿６から、指定のファイルに関するレコード長、ファイル形式、その他の制御データを読み出しファイル制御情報７とする。　
　ファイル制御情報７によりコマンドのその他のパラメータで指定された条件をチェックし、アクセスを許容できる場合には、そのファイル名の排他制御情報を登録すると共に、コマンドの完了をファイルオープン機構２を経て利用者プログラム１に通知する。　
　こゝでファイルオープン機構２は割当済のファイルごとに設けるオープン制御表８を新設し、所定の情報を設定する。オープン制御表８は例えば第２図（ｂ）に示すように、ファイル名欄９、その他の制御情報の欄１０と、所定数の項１１を持ち、各項に当該ファイルをオープンしているプログラムを示すオープン主体者名が設定される欄からなる制御表であり、項１１にある有効なオープン主体者名によって、そのファイルについてアクセス制御パスが設定されていることを示している。　
　次に例えばＯＰＥＮコマンドが発行されると、オープン制御表８の内容を参照して、オープンの権限のある利用者プログラムからの正当な内容のコマンドか判定し、オープン可能と判定した場合にはオープン制御表を更新して、現オープンに関する情報を設定する。」（公報２頁右上欄１５行〜右下欄７行）　
　
　上記（Ｃ）及び図面を勘案すると、刊行物２には、　
　
　オープンの権限のある利用者プログラムからの正当な内容のコマンドか判定するためのオープン制御表に、ファイル名と利用者プログラムを示すオープン主体者名を設定することにより、ファイルのアクセス制御を行うという技術　
　
が開示されていると認められる。　
　
［刊行物３］　
（Ｄ）「・・・ロッキング方式とは、プログラムがある一連のデータベース処理を行う際、アクセスしようとするデータ群を前もって占有（ロック）し、アクセスが終了した時点で、占有していたデータ群を解放（アンロック）する、・・・」（公報２頁左上欄１１行〜１６行）　
　
（Ｅ）「（１）一括ロック方式　
　アクセスしようとするすべてのデータを一括して占有し、アクセスが終了したら、占有したデータを解放する方法である。　
　すなわち、この方式は、占有の回数をただ一度だけに限定することによって、デッドロックの発生可能性を完全になくしたことが特長である。」（公報２頁左下欄１行〜８行）　
　
（Ｆ）「（１）一括ロック方式　
　この方式の欠点は、プログラムがある意味ある処理単位内で必要とするすべてのデータに対して、そのうちの少なくとも１つのデータをアクセスしようとした時点で、一括してデータを占有しなくてはばらない（ならないの誤記と認められる。）ため、共有データ部分をもつ複数のプログラム同士のデータ・アクセスは、すべてシリアルに実行されることになる。」（公報２頁右下欄１６行〜３頁左上欄３行）
　
　上記（Ｄ）〜（Ｆ）及び図面を勘案すると、刊行物３には、　
　
　アクセスしようとするデータ群を前もって占有（ロック）する場合に、ある処理単位内で必要とするすべてのデータに対して、一括して占有（ロック）する一括ロック方式という技術　
　
が開示されていると認められる。　
　
３．対比　
（ア）本願発明と刊行物１発明を対比すると、刊行物１発明の「連動処理関係」と本願発明の「ジョブ」は、連動しつつ一つの機能を分担遂行する個々のタスクから構成される所定の処理単位である点で対応する。　
　
（イ）刊行物１発明の「リソース」と本願発明の「ファイル」はファイルやレコードの資源である点で対応し、　
　又、刊行物１発明の「ファイルやレコードのリソースをロックする」ことと、本願発明の「ファイルを獲得する」ことは、資源を獲得することである点で対応する。　
　
（ウ）刊行物１発明の「リソース名」と本願発明の「ファイル識別子」は、ファイルやレコードの資源を識別するための識別情報である点で対応し、　
　又、刊行物１発明の「プロセシングＩＤ」と本願発明の「ジョブ識別子」は、上記処理単位を識別するための識別情報である点で対応する。　
　
（エ）刊行物１発明の「ファイルアクセス制御表」と本願発明の「資源管理テーブル」は、資源の識別情報及び当該資源を獲得している処理単位の識別情報を登録して管理するものである点で対応する。　
　
（オ）本願請求項１には「資源事前獲得要求」とのみ記載されており上記「事前」に関してそれ以上の記載がないので、上記「資源事前獲得要求」は記載通り資源を所定の処理より事前に獲得するための要求の意味と解される。
　一方、刊行物１発明の「ファイルアクセス要求」は、当該ファイルアクセス要求によってＩ／Ｏアクセスを行うのに先立って事前にロックを行うものであるから、刊行物１発明の「ファイルアクセス要求」と本願発明の「資源事前獲得要求」は、資源を所定の処理より事前に獲得するものである点で対応する。　
　
（カ）刊行物１発明の「上記ファイルアクセス制御表に当該リソース名が登録されているか否か、及び、そのリソースをロックしているプロセシングＩＤが自分のプロセシングＩＤと同じであるか否かを調べ」ることと、本願発明の「前記資源管理テーブルに当該ファイルの識別子が他ジョブ識別子と対応づけて登録されているか判定」することは、資源管理テーブルに資源の識別情報が他の処理単位の識別情報と対応づけて登録されているか判定する点で対応する。　
　
　してみれば、刊行物１発明の「ファイルアクセス制御機構」と本願発明の「資源事前獲得手段」は、上記処理単位の資源事前獲得要求が通知されると、必要とする資源について、資源管理テーブルに資源の識別情報が他の処理単位の識別情報と対応づけて登録されているか判定し、登録されていなければ、該資源管理テーブルに該資源事前獲得要求を通知した処理単位を該資源と対応づけて登録するものである点で対応する。　
　
　　したがって、本願発明と刊行物１発明は、　
　
　個々のタスクで構成される処理単位が処理を実行するために資源を獲得する資源獲得装置であって、　
　資源の識別情報、及び、該資源を獲得している処理単位の識別情報が対応づけて管理される資源管理テーブルと、　
　前記処理単位の資源事前獲得要求が通知されると、必要とする資源について、前記資源管理テーブルに当該資源の識別情報が他の処理単位と対応づけて登録されているか判定し、登録されていなければ、該資源管理テーブルに該資源事前獲得要求を通知した処理単位を該資源と対応づけて登録する資源事前獲得手段と　
　を備える資源獲得装置　
　
である点で一致し、次の点で相違する。　
　
［相違点１］　
　上記個々のタスクで構成される処理単位が、　
　本願発明では、ジョブであるのに対して、　
　刊行物１発明では、連動しつつ一つの機能を分担遂行する複数のタスクからなる連動処理関係である点。　
　
［相違点２］　
　本願発明では、上記資源がファイルであって、上記資源の識別情報がファイルの識別情報であるところのファイル識別子であるのに対して、　
　刊行物１発明では、上記資源がファイルやレコードであって、上記資源の識別情報がレコードの識別情報である点。　　
　
［相違点３］　
　処理単位の資源事前獲得要求が通知されると、必要とする資源について、判定及び登録の処理を行う場合に、　
　本願発明では、処理単位の資源事前獲得要求が通知されると、該処理単位を構成する個々のタスクが必要とする資源について、判定及び登録の処理を行うのに対して、　
　刊行物１発明では、処理単位を構成するメインタスクの資源事前獲得要求が通知されると、該メインタスクが必要とする資源について、判定及び登録の処理を行う点。　
　
４．相違点についての判断　
　上記相違点について検討する。　
　
［相違点１について］　
　個々のタスクが連動しつつ一つの機能を分担遂行するものをジョブとして構成することは当業者が設計時に適宜選択し得る設計的事項にすぎず、刊行物１発明において、処理単位をジョブとすることは当業者が容易になし得るものである。　
　
［相違点２について］　
　例えば刊行物２に記載されているように、ファイル単位で、ファイルの識別情報であるところのファイル名を用いてファイルのアクセス制御を行うことは本願出願前周知の技術であり、かつ、刊行物１発明の資源もファイルやレコードであるから、刊行物１発明において、上記周知の技術を参酌して、上記資源をファイルとし、上記資源の識別情報をファイルのファイル識別子とすることは、当業者が容易になし得るものである。　
　
［相違点３について］　
　例えば刊行物３に記載されているように、アクセスしようとするデータ群を前もって占有（ロック）する場合に、ある処理単位内で必要とするすべてのデータに対して、一括して占有（ロック）することは本願出願前周知の技術である。　
　してみれば、刊行物１発明において、上記周知の技術を参酌して、メインタスクだけではなく、メインタスクを含む連動処理関係が必要とするすべてのデータに対して、一括して占有（ロック）するようにすること、すなわち、処理単位の資源事前獲得要求が通知されると、該処理単位を構成する個々のタスクが必要とする資源について、判定及び登録の処理を行うようにすることは、当業者が容易になし得るものである。　
　
５．むすび　
　したがって、本願発明は、刊行物１〜３に記載された発明及び周知の技術に基き、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。　
　
　よって、結論のとおり審決する。