【事件の表示】
　特願２０００−１７４５５８「処理コード情報を有するデータベース・システムおよび情報処理システム」拒絶査定不服審判事件〔平成１３年１２月２６日出願公開、特開２００１−３５６９０７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明 
　本願は、平成１２年６月９日の出願であって、平成１６年１１月４日付けで拒絶査定がなされ、これに対し、同年１２月３日に審判請求及び手続補正がなされたが、平成１９年６月６日付けで当審より前記手続補正の却下の決定がなされると共に拒絶理由が通知され、これに対し、同年８月７日に手続補正がなされたものであり、特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成１９年８月７日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「業務に対応する複数のプロセスを実行し、業務データベースから情報を取得して入出力部に表示するプレゼンテーションロジック手段と、入出力手段からの入力結果に応じて業務データベースを更新するビジネスロジック手段とを含むアプリケーションからの呼出しに応じて、ビジネスロジック手段から実行しようとする処理の情報を受け取り、各プロセスの実行の可否を判断する判定手段と、
　前記判定手段によりチェックされ、前記複数のプロセスの識別情報と、各プロセスごとに、当該プロセスの開始条件および実行結果の状態を処理コードとして保持するデータベースとを具備し、
　前記判定手段は、前記複数のプロセスを実行する前記アプリケーションからの呼出しに応じて、前記データベース中の対応するプロセスと前記業務の系列の状態とにより指定される前記データベース中の開始条件の処理コードをチェックし、当該プロセスの実行の可否を判定し、判定により実行後に更新するべき処理状態を前記ビジネスロジック手段に通知する、情報処理システム。」 
　
２．当審の拒絶理由 
 　平成１９年６月６日付けで、当審から通知した拒絶理由は、以下のとおりである。
 　 
 「【理由１】　・・・（中略）・・・
　
【理由２】この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記  
 　 
（１）発明の詳細な説明において、 
 段落【００３５】に 
「図８は、実際に開発したシステムの各業務アプリケーションが処理コード管理データベースを参照する仕組みを説明する図である。本発明の情報処理システムにおいては、ＤＢ化されたデシジョンテーブル（条件判定テーブル）８４に対し、業務アプリケーション（８６、８７）と独立した判定部として判定エンジン８８を組込む。この判定エンジン８８は、各業務アプリケーション（８６、８７）から起動され、要求された処理に対応して、必要な遷移系列の状態から、その処理が実行可能か判定するとともに、その処理が正常に終了した場合の次の状態を通知することができる。」とある。 
　しかしながら、状態を判定エンジンによって遷移させるためには、現在の業務の状態を特定することが必須であり、現在の業務の状態を特定して始めて、該プロセスが開始条件を満たすかどうか、上記のようなＤＢ化されたデシジョンテーブル（条件判定テーブル）から、判定できるものである。 
　しかしながら、現在の業務の状態をどこで、そのように管理しているのか、そして、現在の業務の状態をどのようにして特定するのか、その具体的な構成について、記載がなく、不明である。 
　よって、当業者が本願発明を実施することができる程度に、具体的な構成が明確かつ十分に記載されていない。
　
【理由３】この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
（１）請求項１について 
　請求項１において「複数のプロセスを実行する前記アプリケーションからの呼出しに応じて、前記データベース中の対応するプロセスの開始条件に関する処理コードを参照することにより、当該プロセスの実行の可否を判定する」とあるが 
　上記【理由２】において指摘したように、現在の状態を特定できなければ、当該プロセスの実行の可否を判定することはできない。 
　よって、請求項１は、単に達成すべき機能を希望的に記載しているに過ぎず、具体的にどのような構成で、現在の状態を特定するのか、不明であり、発明の構成を特定できない。
　
　よって、請求項１に係る発明は明確でない。 
 　 
（２）請求項２について 
　・・・（中略）・・・」
　
３．検討 
 　前記拒絶理由において、【理由２】の指摘事項（１）並びに【理由３】の指摘事項（１）が解消したか否かについて検討する。
　
 （１）【理由２】の指摘事項（１）について 
　発明の詳細な説明の記載について検討する。
　まず、発明の詳細な説明の段落【００１０】には、「この判定手段は、アプリケーションからの呼出しに応じてデータベース・システム中の対応するプロセスの処理コード情報を参照することにより、当該プロセスの実行の可否を判定する。」と記載されているが、現在の業務の状態をどこで、そのように管理しているのか、そして、現在の業務の状態を判定手段がどのようにして特定するのか、その具体的な構成について記載も示唆もない。
　同様に、発明の詳細な説明の段落【００１３】には、「処理コード管理データベース１４は、好適にはテーブルの形式で、各プロセスの識別情報、プロセスごとに設定される各プロセスの開始条件としての処理コード（現状コード）およびその実行結果としての処理コードに関する情報を保持する。」とあり、段落【００１４】には「処理条件判定部１８は、業務アプリケーション１６から呼出され、処理コード管理データベース１４を参照して、そのプロセスの実行の可否の判定を行い、その実行結果としての処理コードに関するデータを業務アプリケーション１６に通知する。すなわち、判定部１８を介して、処理コードをやり取りすることによって、業務アプリケーション１６において対応する事務プロセスが実行される。」と記載されているが、現在の業務の状態をどこで、そのように管理しているのか、そして、現在の業務の状態を判定手段がどのようにして特定するのか、その具体的な構成について記載も示唆もない。
　同様に、発明の詳細な説明の段落【００１５】には、「現在進められているプロセスの開始条件としての処理コードを現状コードとすると、起案前の現状コードＢに対し、プロセス「起案」が対応する業務アプリケーションで実行され、その結果、プロセス中の現状コードがＢからＣに変更される（書き換えられる）。」と記載されていることからすると、あるプロセスが実行されると、前記プロセス中の現状コードがＢからＣに変更される（書き換えられる）と解される。
　ここで、「プロセス中の現状コード」は、プロセスの変数と解されるが、前記の記載は、単に業務プロセス中の現状コード変数が変更される（書き換えられる）ことを示唆するのみであって、前記業務プロセス中の現状コード変数が変更される（書き換えられる）という態様が、具体的に各プロセスの実行の可否を判断する「判定手段」とどのように関係するのか、不明である。
　そして、前記判定手段が、現在の業務の状態をどのような構成で、どのようにして特定するのか、その具体的な構成について記載も示唆もない。
　同様に、発明の詳細な説明の段落【００３３】には、「図７は、処理コード管理データベースで管理されるテーブルを表す図である。縦軸には、それぞれの遷移系列の状態および各プロセス（処理）後の次の状態を順にとり、横軸には、それぞれの処理がどの状態で実行可能であり、処理結果としてどの系列の状態を更新するかが示されている。」とあり、段落【００３５】には、「本発明の情報処理システムにおいては、ＤＢ化されたデシジョンテーブル（条件判定テーブル）８４に対し、業務アプリケーション（８６、８７）と独立した判定部として判定エンジン８８を組込む。この判定エンジン８８は、各業務アプリケーション（８６、８７）から起動され、要求された処理に対応して、必要な遷移系列の状態から、その処理が実行可能か判定するとともに、その処理が正常に終了した場合の次の状態を通知することができる。」と記載されているが、現在の業務の状態をどこで、そのように管理しているのか、そして、現在の業務の状態を判定手段がどのようにして特定するのか、その具体的な構成について記載も示唆もない。
　同様に発明の詳細な説明の段落【００３６】には「この業務アプリケーションは、業務データベース８０から必要な情報を取得し入出力部８２に表示するプレゼンテーションロジック８６と、入出力部８２からの入力結果に応じて業務データベース８０を更新するビジネスロジック８７から構成されているものとする。」とあり、段落【００３７】に、「プレゼンテーションロジック部分８６では、まず表示データを検索する前に、判定エンジン８８に対し、その処理の実行可否を問い合わせる。判定エンジン８８は、処理条件判定テーブル８４を参照して、アプリケーションの要求する処理が可能であるか判断し、結果を返す。処理可能と判定された場合、プレゼンテーションロジック８６は、業務データベースより表示に必要な情報を取得し、入出力部８２へ出力する。」とあり、段落【００３８】に、「ビジネスロジック部分８７では、まず入出力部８２から入力されたデータを受け取り、チェックを行い、実行しようとする処理の情報を判定エンジン８８に渡す。判定エンジン８８は、状態をチェックし、処理の実行可否を判定するとともに、実行後に更新すべき処理状態をビジネスロジック８７に通知する。ビジネスロジック８７は、つぎの処理状態を含めた業務データを更新する。」と記載されている。
　したがって、前記発明の詳細な説明の段落【００３６】〜【００３８】の記載によると、業務アプリケーションは、業務データベースから必要な情報を取得し入出力部に表示するプレゼンテーションロジック部分と入出力部からの入力結果に応じて業務データベースを更新するビジネスロジック部分とからなり、プレゼンテーションロジック部分は、実行しようとする処理（業務データベースの検索処理）の実行可否を判定エンジンに対し問い合わせ、処理可能との応答があれば業務データベースの検索処理を行い、そしてビジネスロジック部分は、実行しようとする処理（業務データベースの更新処理）の実行可否を判定エンジンに対し問い合わせ、処理可能との応答があれば業務データベースの更新処理を行うものと解される。
　そして、上記説明は、単に判定エンジンが、状態をチェックし、処理の実行可否を判定することを希望的に記載するのみであって、現在の業務の状態をどこで、そのように管理しているのか、また判定エンジンが、現在の業務の状態をどのような構成で、どのようにチェックするのか、その具体的な構成について記載も示唆もない。
　なお、段落【００３８】に「判定エンジン８８は、状態をチェックし、処理の実行可否を判定するとともに、実行後に更新すべき処理状態をビジネスロジック８７に通知する。ビジネスロジック８７は、つぎの処理状態を含めた業務データを更新する。」と記載されていることからすると、ビジネスロジックは判定エンジンから通知されたつぎの処理状態を業務データベースに更新記録するようにも解釈される。
　しかしながら、業務データベースに現在の業務の状態を記録して管理するという構成は、発明の詳細な説明には、そもそも、記載も無く、示唆もない。さらに、現在の業務の状態を業務データベースから検索して、判定手段に渡すような構成についても、発明の詳細な説明には、記載も無く、示唆もない。
　また、仮に前記段落【００３８】の記載がビジネスロジックが判定エンジンから通知されたつぎの処理状態を業務データベースに更新記録することを示唆すると仮定しても、該処理状態は、ビジネスロジックの処理の実行後の次の処理状態に過ぎず、段落【００３７】に記載されているように、プレゼンテーションロジックの処理の実行後の次の処理状態については、判定エンジンがビジネスロジックに通知することも、またビジネスロジックが業務データベースに更新記録することも、発明の詳細な説明には記載もなく、示唆もなく、プレゼンテーションロジックの処理の実行後の次の処理状態が業務データベースに更新記録されるとは認められない。
　さらに、仮に、現在の業務の状態を業務データベースに記録することで、現在の状態を業務データベースを検索して、判定手段に提供すると仮定した場合、業務データベースを検索する機能を有するのは、プレゼンテーションロジックであって、ビジネスロジックでない。しかしながら、プレゼンテーションロジックが、業務データベースから現在の業務の状態を検索することは、発明の詳細な説明に記載もなく、示唆もない。
　してみれば、前記段落【００３８】の記載から、業務データベースが、現在の業務の状態を更新記録して管理するような構成が示唆されていると解釈することはできない。
　そして、発明の詳細な説明の段落【００３９】には、
「２）ビジネスロジックの外部テーブル化
Ｗｅｂ環境などのようにビジネスロジックとプレゼンテーションロジックが分離された形態では、ビジネスロジックの主要部分を判定エンジンに委ねることが可能で、状態に応じたプレゼンテーションロジックに開発作業を集中化させることが可能となる。」と記載されていることからすると、プレゼンテーションロジック部分の状態に応じた処理の開発が開発作業の中心になると解される。
　してみれば、プレゼンテーションロジック部分の状態に応じた処理の実行可否の判定を判定部分に問い合わせる処理の開発が開発作業の中心になることになるが、前記段落【００３７】によると、プレゼンテーションロジック部分の現在の業務の状態をどこで、そのように管理しているのか、また前記判定エンジンが、現在の業務の状態をどのような構成で、どのようにチェックするのか、その具体的な構成について記載も示唆もない。
　
　以上のとおり、当審における平成１９年６月６日付けの拒絶理由の【理由２】（１）において「状態を判定エンジンによって遷移させるためには、現在の業務の状態を特定することが必須であり、現在の業務の状態を特定して始めて、該プロセスが開始条件を満たすかどうか、上記のようなＤＢ化されたデシジョンテーブル（条件判定テーブル）から、判定できるものである。
　しかしながら、現在の業務の状態をどこで、そのように管理しているのか、そして、現在の業務の状態をどのようにして特定するのか、その具体的な構成について、記載がなく、不明である。」と指摘したとおり、プレゼンテーションロジック手段とビジネスロジック手段から、それぞれ、実行しようとする処理（業務データベースの検索処理、または更新処理）の実行可否を判定エンジンに対し問い合わせた際に、判定エンジンが、現在の業務の状態をどのような構成で、どのように特定するのか、また現在の業務の状態をどこで、どのように管理しているのか、この出願の発明の詳細な説明には、当業者が本願発明を実施することができる程度に明確かつ十分に記載されていないから、本件出願は、特許法第３６条第４項に規定する要件を満たしていない。
　したがって、【理由２】の指摘事項（１）に係る拒絶理由は依然として解消していない。
　 
（２）【理由３】の指摘事項（１）について 
 　請求項１の記載によると、「判定手段」は、プレゼンテーションロジック手段とビジネスロジック手段とを含むアプリケーションからの呼出しに応じて、ビジネスロジック手段から実行しようとする処理の情報を受け取り、各プロセスの実行の可否を判断するものであって、「複数のプロセスの識別情報と、各プロセスごとに、当該プロセスの開始条件および実行結果の状態を処理コードとして保持するデータベース」中の「対応するプロセスと前記業務の系列の状態とにより指定される前記データベース中の開始条件の処理コードをチェックし、当該プロセスの実行の可否を判定」するものである。
　したがって、前記判定手段は、プレゼンテーションロジック手段とビジネスロジック手段とを含むアプリケーションからの呼出しに応じて、ビジネスロジック手段から受け取った「実行しようとする処理の情報」を受け取り、データベース上のプロセスと前記業務の系列の状態とにより指定される開始条件の処理コードをチェックし、前記ビジネスロジック手段が「実行しようとする処理」の実行の可否を判定すると解される。
　しかしながら、請求項１には、「前記データベース中の対応するプロセスと前記業務の系列の状態とにより指定される前記データベース中の開始条件の処理コードをチェックし、当該プロセスの実行の可否を判定」としか記載がなく、現在の業務の状態が前記開始処理条件の処理コードに対応する状態にあるかどうかをチェックする際に、判定手段が現在の業務の状態をどのような構成でどのようにして、特定するのか、依然として不明確である。
　さらに、本願発明は、請求項１の記載によると、「プレゼンテーションロジック手段」のこれから実行しようとする処理の実行の可否を問い合わせる際にも、判定手段が「ビジネスロジック手段」から「プレゼンテーションロジック手段」の実行しようとする処理の情報を受け取る態様を含むものであるが、発明の詳細な説明の段落【００３７】に明記されているように、プレゼンテーションロジック部分（プレゼンテーションロジック手段）が、判定エンジン（判定手段）に対し、その業務データベースの検索処理の実行可否を問い合わせた際に、判定エンジンが、ビジネスロジック部分（ビジネスロジック手段）から、プレゼンテーションロジック部分の「実行しようとする処理の情報」を受け取ることは行っていない。また、段落【００３８】に明記されているようにビジネスロジック部分（ビジネスロジック手段）から判定エンジン（判定手段）に渡すのは、ビジネスロジック部分の「実行しようとする処理の情報」であって、プレゼンテーションロジック部分の「実行しようとする処理の情報」ではない。
　したがって、この点からも、請求項１の記載は、「プレゼンテーションロジック手段」のこれから実行しようとする処理の実行の可否を判定する判定手段が、現在の業務の状態を、どのような構成でどのようにして、特定するのか、を含めて不明確である。
　さらに、請求項１記載の判定手段がビジネスロジック手段から受け取るとされる「実行しようとする処理の情報」が具体的に何を意味するか、についても、発明の詳細な説明の段落【００３７】〜【００３８】を参酌しても、不明確である。
　
　以上のとおり、当審における平成１９年６月６日付けの拒絶理由の【理由３】（１）において「請求項１は、単に達成すべき機能を希望的に記載しているに過ぎず、具体的にどのような構成で、現在の状態を特定するのか、不明であり、発明の構成を特定できない。」と指摘したとおり、発明の詳細な説明を参酌しても、本願発明における判定手段が、具体的にどのような構成でどのようにして、現在の業務の状態を、特定するのか、依然として不明確であるから、本件出願は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　したがって、【理由３】の指摘事項（１）に係る拒絶理由は依然として解消していない。
　
４．請求人の主張について
　請求人は、平成１９年８月７日付けの意見書において、【理由２】の指摘事項（１）及び【理由３】の指摘事項（１）に関して、次の主張（以下、主張１という。）を行っている。 
　「判定手段が当該プロセスの実行状態を特定するためには、本願出願時においても種々の方法が考えられ、例えばＵＮＩＸ、ＬＩＮＵＸでは、シェルコマンドとしてｐｓコマンドを実装しており、プロセスＩＤ（ＰＩＤ）を指定してその実行状態をモニタすることが可能であって、ＵＮＩＸにおいてはプロセス通信を使用してプロセス制御を行うことは常套手段であり、判定手段が例えば、ビジネスロジック手段からの通知を受けて、通知されたＰＩＤを指定してｐｓコマンドを発行することにより、その実行状態を知ることが可能であります。また、他の常套手段としては、対象とされるプロセスが終了する直前に、killコマンドなどを使用して判定手段に対し、プロセス終了を通知するシグナルを送付し、当該プロセスの終了を判定手段に通知することも可能であります。」
　しかしながら、本願発明が、請求人の主張するように「判定手段」が、ビジネスロジック手段からの通知を受けて、通知されたＰＩＤを指定してｐｓコマンドを発行することにより、その実行状態を知るという構成を備えること、または「判定手段」に対して、対象とされるプロセスが終了する直前に、killコマンドなどを使用して、プロセス終了を通知するシグナルを送付し、当該プロセスの終了を通知するという構成を備えることは、ともに、明細書に記載も示唆もなく、自明な構成でもなく、明細書に基づいた主張ではない。
　よって、請求人の前記主張１は、採用することはできない。
　
　また、請求人は、平成１９年８月７日付けの意見書において、次の主張を行っている。
 「すなわち、本願では、判定手段は、ビジネスロジックが実行しようとするプロセスの実行可否を判断させ、実行後に更新するべき処理状態をビジネスロジックに通知する処理を実行するのであります。
　本願では、上記処理を実行させることにより、ビジネスロジックは、その時点で処理を開始させたプロセスが終了時に判定手段に対して判定を依頼するための情報が取得可能となる　・・・（中略）・・・」
　
　してみれば、請求人は、「ビジネスロジックは、その時点で処理を開始させたプロセスが終了時に判定手段に対して判定を依頼するための情報が取得可能となる」ことで、ビジネスロジック部分が、次に実行しようとする業務処理の実行可否を判定手段に対して判定を依頼する際に、現在の業務の状態を判定手段に対して提供すると主張（以下、主張２という。）しているようにも、推測される。
　そこで、前記主張２を検討する。
　発明の詳細な説明の段落【００３８】に、「ビジネスロジック部分８７では、まず入出力部８２から入力されたデータを受け取り、チェックを行い、実行しようとする処理の情報を判定エンジン８８に渡す。判定エンジン８８は、状態をチェックし、処理の実行可否を判定するとともに、実行後に更新すべき処理状態をビジネスロジック８７に通知する。」とあるが、ここに記載された「実行しようとする処理の情報」が、そもそも、「現在の業務の状態」を含むかどうかは、記載も示唆もない。
　さらに、発明の詳細な説明の段落【００３７】に、「プレゼンテーションロジック部分８６では、まず表示データを検索する前に、判定エンジン８８に対し、その処理の実行可否を問い合わせる。判定エンジン８８は、処理条件判定テーブル８４を参照して、アプリケーションの要求する処理が可能であるか判断し、結果を返す。処理可能と判定された場合、プレゼンテーションロジック８６は、業務データベースより表示に必要な情報を取得し、入出力部８２へ出力する。」と記載されているように、プレゼンテーションロジック部分のこれから実行しようとする処理の実行可否についてはプレゼンテーションロジック部分が、判定部分に問い合わせていることからも、明らかなように、段落【００３８】に記載された「実行しようとする処理の情報」は、単にビジネスロジック部分の「実行しようとする処理の情報」であって、プレゼンテーションロジック部分のこれから実行しようとする処理の情報を含むとは解されない。
　してみれば、本願発明が、請求人の主張しているようにも推測される「ビジネスロジックは、その時点で処理を開始させたプロセスが終了時に判定手段に対して判定を依頼するための情報が取得可能となる」ことで、ビジネスロジック部分が、次に実行しようとする業務処理の実行可否を判定手段に対して判定を依頼する際に、現在の業務の状態を判定手段に対して提供するという構成を備えることは、そもそも、明細書に記載も示唆もなく、自明な構成でもなく、さらには、明細書に開示された構成と矛盾するものであり、明細書に基づいた主張ではない。
　よって、請求人の前記主張２は、採用することはできない。
　
５．むすび 
 　したがって、本件出願は、明細書及び図面の記載が、特許法第３６条第４項及び第６項第２号に規定する要件を満たしていない。 
 　よって、結論のとおり審決する。