【事件の表示】
　平成　５年特許願第　３２３４７号「業務仕様ハンドリング装置」拒絶査定に対する審判事件〔平成　６年　９月　９日出願公開、特開平　６−２５０８３４、請求項の数（１）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願発明の要旨
　本願は、平成５年２月２３日の出願であって、その請求項１に係る発明は、平成１０年１２月２１日付け手続補正書によって補正された明細書及び図面の記載からみて、その特許請求の範囲に記載されたとおりの次のものである。
「【請求項１】中央処理装置と，表示装置と，入力装置とを備えたデータ処理装置において，
　データ型として，プログラムで使用するデータの処理単位であるレコード項目と，レコード項目が共通に持つ型であるドメインと，レコード項目があるプログラムで処理されるとき，そのレコード項目とその処理との組み合わせを表す処理項目とを有し，プログラム化する業務の仕様がこれらのデータ型によって与えられ，ドメインの仕様がその下位のレコード項目に継承され，レコード項目の仕様がその下位の処理項目に継承される情報を蓄積し管理する業務仕様データベースと，
　前記個々のデータ型を単位に，その処理内容が入力項目である場合には入力データを制約する制約式，出力項目である場合にはその出力データを得るための計算式の形で表され，かつ必要な条件がある場合には条件式が付与された業務仕様を，前記表示装置に表示して編集処理し，前記業務仕様データベースに格納する業務仕様編集処理手段と，
　前記業務仕様データベースに格納されている業務仕様間に変更が生じた場合に，変更された仕様に該当するデータ型に対応する業務仕様間，および該当するデータ型が継承するデータ型を有する場合には下位のデータ型に対応する業務仕様間に矛盾がないかどうかを，前記業務仕様の項目に付随する制約式，計算式または条件式を含む属性に基づいて調べ，矛盾がある場合に利用者に対しその矛盾の内容を通知する矛盾検出処理手段と，
　前記業務仕様データベースに格納されている業務仕様に基づき，各項目ごとの仕様からプログラム部品を生成し，与えられた制御ロジックと合成することにより，利用者の環境で実行可能な業務プログラムを生成するプログラム合成処理手段とを備えたことを特徴とする業務仕様ハンドリング装置。」
　
２．原査定の理由
　一方、原査定の拒絶の理由は、
「理由１．                               
　この出願の請求項１〜２に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　記
引用例１．「情報処理学会論文誌」Vol.33,No.4(1992-4)P.521-531
引用例２．「情報処理学会研究報告」Vol.92,No.25(1992-3)
　　　　　P.39-48(92-IS-38-5)
引用例３．「情報処理学会研究報告」Vol.91,No.66(1991-7)
　　　　　P.51-58(91-SE-80-7)
引用例４．「情報処理学会第４１回(平成２年後期)全国大会講演論文集」
　　　　　P.5-205〜5-206
引用例５．「情報処理学会第４３回(平成３年後期)全国大会講演論文集」
　　　　　P.5-381〜382
引用例６．特開平４−１７２５２９号公報
　引用例１、２にはデータ部品を構成するデータ項目中にドメイン及び制約を持たせたオブジェクトとして構成することが記載されており、これらの制約により各データ部品をリポジトリ登録時に不具合をチェックを行うことは明らかである。
　この技術思想を引用例３〜６記載のデータ項目部品からプログラムを合成するシステムに適用することで本願発明を想到することは当業者ならば容易になしえたものである。
理由２．
　この出願の請求項１に係る発明は、その出願の日前の特許出願であって、その出願後に出願公開がされた下記の特許出願の願書に最初に添付された明細書又は図面に記載された発明と同一であり、しかも、この出願の発明者がその出願前の特許出願に係る上記の発明をした者と同一ではなく、またこの出願の時において、その出願人が上記特許出願の出願人と同一でもないので、特許法第２９条の２の規定により、特許を受けることができない。
  　　　　　　記
特願平３−２８８３６３号（特開平５−１２７８８１号）
特願平３−２７０７１３号（特開平５−１０８３１９号）」
　というものである。
　
３．各引用例の記載について
（１）引用刊行物の記載
　引用例１には、ＤＯＡ（データ中心アプローチ）では、情報要求定義もシステム仕様定義もデータ中心で行い、制約条件等を設定したカプセル化（データと処理を同時に抽象化する）さらには集約カプセル化された部品を組み合わせて、求められる企業情報システムを記述し、また、データ分析の課題（ドメイン、実体、基本集約物、データライフサイクル、制約）を説明し、プログラムの代替として、メタ情報で設計すること、また、トランザクション分析とカプセル分析の記載がある。
　引用例２には、実データについて、型、ライフサイクル、固有の制約、対応プロセス等をメタデータとして定義し、メタデータを部品としてメタモデル（→システムモデル）を組み立てること、実システムに対応するシステムモデルを構成するオブジェクトの型を表現する応用メタモデルについて説明し、応用メタモデルの設計では、各オブジェクトの機能を継承すること、オブジェクト毎の固有の機能であるクラス機能をシステム全般にわたり洗い出すこと、オブジェクト毎に制約条件を設定すること、制約の継承関係が一意に定まることによりシステムの整合性を保証できること、および、応用メタモデルの設計事例において、設計の検討過程（ドメインの集約オブジェクトとしてカラムを設定し、カラムの集約オブジェクトとしてテーブルを設定し、同じくカラムの集約オブジェクトとして参照制約検証オブジェクトあるいは導出制約検証オブジェクトを設定し、上記２つのオブジェクトはテーブルに集約されるものとした検討過程）と設計結果の記載がある。
　引用例３〜６には、プログラムの骨格として標準パターンを用意し、部品をデータ項目単位に定義して、標準パターンにプログラム仕様情報と画面、帳票等の外部仕様情報とを付加して自動的にプログラムを生成する際に、チェック、入力編集、出力編集に分けてすることの記載がある。
　
（２）先願明細書記載の発明
　特願平３−２８８３６３号（特開平５−１２７８８１号公報）の願書に最初に添付された明細書又は図面には、文字または数値データを書き込むための少なくとも１つのデータ領域を含む帳票を処理するための業務処理情報を生成する業務処理仕様生成方法であって、上記帳票の特徴を検出するステップと、帳票の特徴とその帳票を処理するための帳票処理情報との対応関係を記憶してある業務知識辞書を参照して、上記帳票の特徴からその帳票に対応する帳票処理情報を生成するステップとを備えたことを特徴とする業務処理仕様生成方法の発明が記載されている。
　また、特願平３−２７０７１３号（特開平５−１０８３１９号公報）の願書に最初に添付された明細書又は図面には、ソフトウエアをデータ項目単位にそれぞれのデータ項目に対する単独処理をいくつかの種類に分けてソフトウエア部品として定義し、ディクショナリとよぶファイルに格納する手段と、複数のデータ項目間の相互関係に基づいてデータの妥当性を判定する関連チェック処理をソフトウエア部品として定義し、関連チェック定義書とよぶファイルに格納する手段と、これらディクショナリおよび関連チェック定義書に格納されたソフトウエア部品をデータ項目名に基いて管理する手段と、ファイル、帳票の属性やレイアウトなどの情報を定義し、データ定義書とよぶファイルに格納する手段と、プログラム単位に入出力媒体の情報を定義し、プログラム定義書とよぶファイルに格納する手段と、画面、帳票、ファイル等の処理プログラムを制御構造の特質に着目していくつかの種類に分け、業務個別処理をそれ自身に持たないプログラムスケルトン標準パターンとして部品化し、標準パターンライブラリとよぶファイルに格納する手段と、プログラムスケルトン標準パターン部品に沿った標準機能説明部品を標準機能説明ライブラリとよぶファイルに格納する手段と、ディクショナリ、関連チェック定義書、データ定義書、プログラム定義書、および標準機能説明ライブラリから、対象とする業務プログラムの入出力媒体中のデータ項目名をもとにソフトウエア部品を選択し、いくつかの種類の仕様書から構成されるプログラム仕様書を自動生成する手段と、プログラム仕様書をもとに、プログラムスケルトン標準パターン部品と、ディクショナリ中のソフトウエア部品および関連チェック定義書中のソフトウエア部品とを選択して合成することによりソースプログラムを自動生成する手段とを有することを特徴とするデータ中心型ソフトウエア部品によるプログラム自動生成方式の発明が記載されている。
　
４．対比・判断
（１）理由１について
　本願の請求項１に係る発明と上記引用例１〜６に記載のものとを対比すると、
　請求項１に係る発明は、「データ型として、プログラムで使用するデータの処理単位であるレコード項目と、レコード項目が共通に持つ型であるドメインと、レコード項目があるプログラムで処理されるとき、そのレコード項目とその処理との組み合わせを表す処理項目とを有し、プログラム化する業務の仕様がこれらのデータ型によって与えられ、ドメインの仕様がその下位のレコード項目に継承され、レコード項目の仕様がその下位の処理項目に継承される情報を蓄積し管理する業務仕様データベース」の構成を備えるものであるが、上記引用例１〜６のいずれにも該構成の記載はない。
　そして、請求項１に係る発明は、上記の構成を有することにより、条件等についての仕様間の矛盾の判定・検出が行いやすくなり、下位における固有の処理仕様の変更を他の部分に影響しないようにすることもできるという明細書に記載された効果を奏するものである。
　したがって、請求項１に係る発明は、各引用例に記載された発明に基いて当業者が容易に発明をすることができたものとすることはできない。
（なお、他の公知文献、例えば、「情報処理学会第４５回(平成４年後期)全国大会講演論文集」P.5-381〜382を参照しても、データ項目辞書をリポジトリで管理し、仕様書との関連を複数段階の関連を辿って求めて出力する手段等に関する記載はあるものの、請求項１に係る発明の、上記の、データ型として、レコード項目、ドメインのみならず、そのレコード項目と処理との組み合わせを表す処理項目をも設定し、仕様がデータ型によって与えられ、ドメインの仕様が下位の処理項目に継承されるのみならず、レコード項目の仕様が、その下位の、レコード項目と処理との組み合わせである処理項目まで継承されるようにする構成は、前記文献には記載されておらず、このような構成を採ることの示唆もない。）
　
（２）理由２について
　上記の特願平３−２８８３６３号（特開平５−１２７８８１号公報）又は特願平３−２７０７１３号（特開平５−１０８３１９号公報）の願書に最初に添付された明細書又は図面に記載された発明は、請求項１に係る発明の上記構成を備えておらず、請求項１に係る発明は、上記の各出願の願書に最初に添付された明細書又は図面に記載された発明と同一であるとすることはできない。
　
５．むすび
　以上のとおりであるから、この出願の発明は、特許法第２９条第２項の規定により、あるいは、特許法第２９条の２の規定により特許を受けることができないという原査定の判断は妥当ではない。
　また、他に本願を拒絶すべき理由を発見しない。
  よって、結論のとおり審決する。