【事件の表示】
　平成　９年特許願第２８７３４８号「業務処理装置」拒絶査定不服審判事件〔平成１０年　７月２１日出願公開、特開平１０−１８７８５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成９年１０月２０日（優先権主張　平成８年１０月２２日）の出願であって、平成１５年５月２８日付けで拒絶査定がなされ、これに対し、同年７月３日に拒絶査定に対する審判が請求され、同年８月４日付けで手続補正がなされ、その後、当審において平成１５年８月４日付けの手続補正について補正却下の決定がなされ、当審の平成１８年１１月１日付けの拒絶理由通知に対して平成１９年１月１１日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は、平成１９年１月１１日付け手続補正で補正された明細書の特許請求の範囲の請求項１に記載されている次のとおりのものである。
　
「ファイアウォールの外側及び内側に存在する複数の計算機と接続される業務処理装置であって、
　前記複数の計算機のいずれかからの要求に応じて、業務処理を行う前記複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータを生成し、ワークフローファイルに格納する手段と、
　ワークフローに関連付けられ、図面識別子と版数の情報を含む伝票データを格納する伝票データファイルと、
　ワークフローに関連付けられた図面情報を格納する図面情報ファイルと、
　ファイアウォール内の計算機に対してワークフローデータを転送する手段と、
　ファイアウォール内の計算機からの要求に応じてワークフローに関連する伝票データまたは、図面情報を要求元の計算機に送信する手段と、
　ファイアウォール外の計算機に対してワークフローとともに、関連する伝票データ及び図面情報を一括送信する手段と、
　図面識別子と版数の組み合わせとファイル名とを対応付けて格納する版数管理ファイルと、
　図面識別子と表示のためのプログラム名とを対応付けて格納する参照管理ファイルと、
　を有することを特徴とする業務処理装置。」
　
３．当審の拒絶の理由
　平成１８年１１月１日付けの拒絶理由通知（以下「当審の拒絶理由通知」という。）の拒絶の理由の概要は以下のとおりである。
「理由１：（略）
理由２：
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号（略）に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
（１）「ワークフローデータを生成」する点について、請求項１乃至１３に係る発明と、発明の詳細な説明に発明として記載したものとが対応しておらず、（略）
　すなわち、特許請求の範囲の記載からみて、上記「ワークフローデータを生成」する機能や処理は、業務処理装置が有する機能手段又はコンピュータが実現する機能或いはコンピュータが実行する処理ステップの要件として、請求項に係る発明の発明特定事項から把握されるものである。
　その一方、発明の詳細な説明において、例えば第３９，４２，７２，７７段落等を参照すれば、「ワークフローデータを生成」するワークフロー生成部４２は、サーバ４０を構成する機能要素を意味していると把握されるものである。
　しかしながら、発明の詳細な説明には、「図６は、本発明のワークフロー作成画面の例である。」（第４９段落）、「ワークフロー生成部４２は、図１５に示すワークフロー作成画面を用いて、技術部１０の計算機から受信したプロセス情報を表示する。このとき、当該画面において、処理予定日（９６．０６．０１）を設定する。」（第６１段落）という記載も存在しているところ、上記「ワークフロー生成部４２」は、所定の作成画面を見ながらサーバ４０を操作して作業を行う人間（例えば明細書第７１段落に記載された「サーバ４０の管理者」）を意味しているとも把握されるものである。
　このように、発明の詳細な説明において、ワークフロー生成部４２が明確に記載されていないため、上記各請求項の記載事項との対応関係が明確でなく、（略）
　
（２）（略）
　
理由３：（略）
　
理由４：
　この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
（１）クライアントとしての各計算機１０，２０，３０はそれぞれ入出力部１５，２５，３５を具備しているが、サーバ４０は入出力部を具備していないところ、前記サーバ４０が有する、「ワークフローデータを生成」するためのワークフロー生成部４２が、「ワークフロー作成画面」をどこにどのようにして「表示する」のか不明であり、また、「（ワークフロー作成）画面において」処理予定日を「設定」することが、どのように実現されるのかも不明であるところ、（略）当該表示や当該設定がどのように実現されているのかを示すための開示が、本願明細書の発明の詳細な説明及び図面の記載において、明確且つ十分とはいえない。
（２）（略）当該ワークフローデータを規定する「業務処理を行う該複数の計算機のルート」を生成することを、どのようにして実現したのかが、本願明細書の発明の詳細な説明及び図面の記載において、明確且つ十分に開示されていない。
　すなわち、当該部門において行うべき業務プロセスを特定するための情報が各部門の計算機それぞれから得られたとしても、それらは「各計算機で行う業務処理」を規定しているにすぎないのだから、個々の業務プロセスについて当該業務プロセスと他の業務プロセスとの間の関係、すなわち、上記「業務処理を行う該複数の計算機のルート」を規定するものではない。
　そして、本願第６図の上部に記載されたような各業務プロセスに係る情報群が入力されると、サーバ４０というコンピュータがどのような仕組みを用いて各業務プロセスの間の関係を把握して、本願第６図の下部に記載されたような順番に並び替えた結果を自動的に得ることを実現しているのかが不明であるところ、当業者が当該仕組みを有するコンピュータを構築して使用できる程度に、明確且つ十分に開示されていない。
　
理由５：
　請求項１乃至１３に関しては、上記理由１乃至４で指摘したような瑕疵があるが明細書全体から把握できる範囲で新規性及び進歩性についての判断を行う。
　この出願の請求項に係る発明は、その出願前において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　記
［刊行物一覧］
引用例１：「ＴｅａｍＷＡＲＥ Ｆｌｏｗ Ｖ１．０ 使用手引書 Ｂ２ＷＷ−０２６１−０１−００」，１９９６．７．３１，富士通株式会社，ｐ，４，５，７
引用例２：小林暢子，「特集 ワークフローで仕事を変える」，１９９６．０３．０４，日経コンピュータ，日経ＢＰ社，ｎｏ．３８６，ｐ．１２８〜１３７
引用例３：新井義夫、桂木真一郎，「企業間協調プロセス支援環境の構築技術」，１９９６．０３．１０，ＮＴＴ Ｒ＆Ｄ，日本電信電話株式会社，第４５巻，第３号，ｐ．２５５〜２６０
引用例４：「特集 ＣＡＬＳ／ＥＤＩのビジネス展開」，１９９６．０４．０１，ビジネスコミュニケーション，株式会社ビジネスコミュニケーション社，第３３巻，第４号，ｐ．３４〜４１
引用例５：特開平７−３１９８２０号公報
引用例６：特開平８−１５３００９号公報」
　
４．当審の判断
（４−１）特許法第３６条第６項第１号について
　本願発明の「前記複数の計算機のいずれかからの要求に応じて、業務処理を行う該複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータを生成し、ワークフローファイルに格納する手段」は、「業務処理装置」が「有する」手段であるのだから、「ワークフローデータを生成」する機能は、該装置の機能として、本願明細書の特許請求の範囲の請求項１の記載から把握されるものである。
　
　これに対し、本願明細書の発明の詳細な説明では、前記「ワークフローデータを生成」することに関して、
「【００３９】サーバ４０は、（略）アクセス受付部４１、アクセス受付部４１により取得した各部門の計算機１０、２０、３０からの業務内容、伝票データに基づいてワークフローを生成するワークフロー生成部４２、（略）ワークフロー生成部４２で生成されたワークフローを格納するワークフローファイル４５、（略）から構成される。」（第３９段落）
「【００４２】ステップ２）  サーバ４０は、各部門の計算機１０、２０、３０から受信した伝票情報、及び当該伝票情報に関連する付随情報、図面情報等に基づいて、業務処理を行う複数の計算機のルート及び各計算機で行う業務処理とを規定したワークフローを定義し、ワークフローファイル４５に格納する。（以下略）」（第４２段落）
「【００７２】（略）ステップ４０２）  サーバ４０は、当該プロセス情報を受信すると、ワークフロー作成部４２において、ワークフローを定義し、当該内容をワークフローファイル４５に格納する。」（第７２段落）
と記載されているものの、ワークフロー生成部４２がワークフローを生成する具体的な処理が記載されていない。そして、ワークフローを生成する具体的な処理については、
「【００４９】（略）図６は、本発明のワークフロー作成画面の例である。（以下略）」（第４９段落）
「【００６１】（略）ワークフロー生成部４２は、図１５に示すワークフロー作成画面を用いて、技術部１０の計算機から受信したプロセス情報を表示する。このとき、当該画面において、処理予定日（９６．０６．０１）を設定する。」（第６１段落）
と記載されている。
　
　そうすると、本願明細書の発明の詳細な説明では、「ワークフローデータを生成」するワークフロー生成部４２が、「サーバ４０を構成する機能要素」を意味しているとしているものの、具体的処理の内容からみると、実質的には「所定の作成画面を見ながらサーバ４０を操作して作業を行う人間」を含むものと解される。
　したがって、本願明細書において、請求項及び発明の詳細な説明に記載された事項の対応関係が整合していないため、特許を受けようとする発明が発明の詳細な説明に記載したものであるということはできないから、本願は、特許法第３６条第６項第１号の規定に適合していない。
　
（４−２）特許法第３６条第４項について
　本願発明が有する「前記複数の計算機のいずれかからの要求に応じて、業務処理を行う該複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータを生成し、ワークフローファイルに格納する手段」の開示が明確かつ十分かどうかを検討する。
　
　該ワークフローデータを生成することについて、本願明細書の発明の詳細な説明には、以下の記載が存在する。
「【００４７】（略）まず、上記のステップ１における各部門におけるプロセスの作成について説明する。図５は、本発明のワークフロー用のプロセス作成画面の例である。
【００４８】各部門の計算機において、入出力部のディスプレイに同図に示されるようなプロセス作成画面が表示される。当該部門の操作者は、当該画面より、各部門で行うべきプロセス（業務）名、当該業務の工数、伝票データを必要とするか否か、承認が必要か否かの情報を各プロセス毎に設定する。このようにして、プロセス画面からの入力が終了すると、業務登録部よりサーバ４０に転送する。
【００４９】（略）図６は、本発明のワークフロー作成画面の例である。サーバ４０は、（略）各部門の計算機から取得したプロセス情報をアクセス受付部４１で取得すると、ワークフロー生成部４２において、各部門毎に、プロセス名、当該プロセスの工数、伝票の要否、承認の要否、予定日等を設定する。このようにして設定されたワークフロー定義情報は、図７に示すようなワークフローデータ構造を有するワークフローファイル４５に格納する。（以下略）」（第４７〜４９段落）
「【００６０】まず、技術部１０がプロセス作成を行い、サーバ４０に登録する処理を説明する。
ステップ２０１）  技術部１０の計算機において、操作者は、入出力部１５のディスプレイに図５に示すプロセス作成用の画面を表示する。
ステップ２０２）  技術部１０の操作者は、当該画面より、部門名『技術部』とプロセス名『見積依頼』、当該業務の工数として『４日』、伝票−要、承認−要を入力する。（略）
【００６１】ステップ２０３）  これにより、当該データは、業務登録部１１からサーバ４０に転送される。
ステップ２０４）  サーバ４０のアクセス受付部４１が、技術部１０の計算機から登録要求が発行されているプロセス情報をワークフロー生成部４２に転送する。ワークフロー生成部４２は、図１５に示すワークフロー作成画面を用いて、技術部１０の計算機から受信したプロセス情報を表示する。このとき、当該画面において、処理予定日（９６．０６．０１）を設定する。
【００６２】ステップ２０５）  さらに、サーバ４０のワークフロー生成部４２において、ステップ２０４により設定されたプロセス情報に基づいて、図１６に示すように登録される。（以下略）
【００６３】（略）
【００６４】（略）上記のような方法により、図１７に示すようなワークフローファイルが構成される。」（第６０〜６４段落）
　
　本願発明の前記手段によって生成される「ワークフローデータ」は、「業務処理を行う該複数の計算機のルート」及び「各計算機で行う業務処理」を規定したものであるが、上記の記載において、各部門側からサーバへ転送されたデータは、「各計算機で行う業務処理」を規定しているにすぎないものであって、個々の業務プロセスについての当該業務プロセスと他の業務プロセスとの間の関係、すなわち、「業務処理を行う該複数の計算機のルート」を規定するものではない。
　とはいえ、各業務プロセスそれぞれの処理予定日を決定すれば、該処理予定日の時間的前後関係に基づいて各業務プロセス間の前後関係を間接的に規定することができると考えられるので、次に、前記サーバがどのように該処理予定日を決定しているのかについて検討する。
　上記の記載によれば、サーバ４０が有するワークフロー生成部４２が、受信したプロセス情報を表示するワークフロー作成画面において処理予定日を設定する旨が記載されている。
　ところが、本願明細書及び図面を全体として参照しても、前記サーバ４０は入出力部を具備していないことは明らかであるところ、上記の記載において、前記サーバが有する、「ワークフローデータを生成」するためのワークフロー生成部４２が、「ワークフロー作成画面」をどこにどのようにして「表示する」のか不明であり、また、「（ワークフロー作成）画面において」処理予定日を「設定」することが、人間の行為ではなく、前記サーバの自律的な機能として、どのように実現されるのかも不明である。
　そのため、各業務プロセスの処理予定日を決定する機能を前記サーバにどのように実現したのかは不明であるから、各部門側から得ることのできない「業務処理を行う該複数の計算機のルート」をどうやってサーバ側で生成するのかは不明である。
　そうすると、第６図の上部に記載されたような各業務プロセスに係る情報群が入力されると、サーバ４０というコンピュータがどのような仕組みを用いて各業務プロセスの間の関係を把握し、第６図の下部に記載されたような順番に並び替えた結果を自動的に得たり、或いは、第１７図に記載されたような処理予定日を自動的に設定したりすることをどのようにして実現しているのかは、上記の記載からは明確かつ十分に把握できないものであって、本願明細書及び図面のその余の記載を参照しても、明確かつ十分に把握できるものではない。
　したがって、本願明細書の発明の詳細な説明は、本願発明の「前記複数の計算機のいずれかからの要求に応じて、業務処理を行う該複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータを生成し、ワークフローファイルに格納する手段」を有する「業務処理装置」を当業者が実施することができる程度に明確かつ十分に記載されていないから、本願は、特許法第３６条第４項の規定に適合していない。
　
（４−３）特許法第２９条第２項について
［引用例の記載事項］
（１）当審の拒絶理由通知にて引用した、「ＴｅａｍＷＡＲＥ Ｆｌｏｗ Ｖ１．０ 使用手引書 Ｂ２ＷＷ−０２６１−０１−００」，１９９６．７．３１，富士通株式会社，ｐ，４，５，７（以下「引用例１」という。）には、下記（ａ）及び（ｂ）の事項が記載されている。
（ａ）「業務に関する様々な情報（データ）をサーバー上のデータベースを利用して集中的に管理します。TeamWARE Flowでは、情報が管理されているデータベースと連携することで、データの共有化を図ります。
　業務の流れ（ワークフロー）の中で発生する作業の内容・作業の担当者・作業で使用する業務アプリケーション・作業の処理手順などの定義（ワークフロー定義）は、TeamWARE Flowのデータベースで管理します。また、業務アプリケーションで扱う顧客管理データ・製品管理データ・在庫管理データなどは、サーバー上のデータベースで管理します。」（第４頁下から４行目〜第５頁第４行）
（ｂ）「複数のクライアントコンピュータと接続されるサーバーコンピュータであって、ワークフロー管理用のデータベースと業務データ用のデータベースを有するサーバーコンピュータ。」（第７頁第１．４図）
　
　ここで、前記（ａ）に記載された「TeamWARE Flowのデータベース」は、前記（ｂ）に記載された「ワークフロー管理用のデータベース」を意味しており、同様に、前記（ａ）に記載された「サーバー上のデータベース」は、前記（ｂ）に記載された「業務データ用のデータベース」を意味していることは、明らかである。
　また、技術常識に照らしてみれば、前記（ａ）に記載されたような、共有データベースを用いた複数の者による通常の業務遂行の態様を考慮するに、前記（ｂ）に記載されたサーバーコンピュータが有する当該各データベースは、複数のクライアントコンピュータからの要求に応じて読み書きされるものであることは明らかであって、具体的には、各クライアントコンピュータにおいてワークフロー定義に従うように業務を実行させるためには、該各クライアントコンピュータは、サーバーコンピュータを介して、少なくとも前記ワークフロー定義を前記ワークフロー管理用のデータベースから読み出していることは当然であり、また、業務データ用のデータベースで管理される顧客管理データ・製品管理データ・在庫管理データなどの各種データは、ワークフローの中で発生する作業で使用する業務アプリケーションで扱われるものであるのだから、該各種データは、該クライアントコンピュータからの要求に基づいて読み書きされるものであることも明らかである。
　さらに、サーバーコンピュータには、上述した種々の機能を実現するための機能手段を有していることも明らかである。
　
　してみれば、引用例１には、
「複数のクライアントコンピュータと接続されるサーバーコンピュータであって、
　ワークフローの中で発生する作業の内容及び作業の処理手順を定義したワークフロー定義をワークフロー管理用のデータベースで管理する手段と、
　ワークフローの中で発生する作業で使用する業務アプリケーションで扱う各種データを管理する業務データ用のデータベースと、
　クライアントコンピュータに対してワークフロー定義を読み出させる手段と、
　クライアントコンピュータからの要求に応じて前記各種データを要求元のクライアントコンピュータに読み出させる手段と、
を有することを特徴とするサーバーコンピュータ。」
という発明（以下「引用発明」という。）が開示されていると認められる。
　
（２）当審の拒絶理由通知にて引用した、小林暢子，「特集 ワークフローで仕事を変える」，１９９６．０３．０４，日経コンピュータ，日経ＢＰ社，ｎｏ．３８６，ｐ．１２８〜１３７（以下「引用例２」という。）には、下記（ｃ）の事項が記載されている。
（ｃ）「（略）ＮＴＴの施設用の通信機器などを全世界のメーカーから調達する国際調達部門は，調達までに公告文書の作成や翻訳，申請書の受け付けなど約３０の手続きが必要で，１つの案件に２〜３ヵ月かかる。（略）
　そこで作業の流れを標準化してワークフロー・システムに載せることにした。各作業の所要時間を見積もって，スケジュールの標準モデルを作成した。このモデルを基に，実際に案件が発生すると，ワークフロー・システムが作業スケジュールを自動的に生成する仕組みだ。
　案件の責任者が調達の締め切り日などのデータを入力するだけで，公告文書の作成や翻訳など約３０種類の手続きごとに締め切り日を設定する。
　このスケジュール・データを基に，担当者のパソコンのワーク・リストには必要な作業と締め切り日が表示される。担当者はワークリストの指示に従って，文書を作成したり，印刷や翻訳などの手続きを進める。（以下略）」（第１３３頁「複数の案件の進行管理が容易に」の項）
　
（３）当審の拒絶理由通知にて引用した、新井義夫、桂木真一郎，「企業間協調プロセス支援環境の構築技術」，１９９６．０３．１０，ＮＴＴ Ｒ＆Ｄ，日本電信電話株式会社，第４５巻，第３号，ｐ．２５５〜２６０（以下「引用例３」という。）には、下記（ｄ）〜（ｈ）の事項が記載されている。
（ｄ）「企業間のプロセス管理は，企業間の協調開発が円滑に進むように，各企業が実施するプロセスのマイルストーン（例えば，中間成果物の提供など）を１つのプロセスとして，仮想企業全体のプロセスを定義し，プロセス実働を制御する．（略）
　上述のプロセス管理を実現するには，プロセス情報として作業名と企業名が必要である．この情報はオブジェクトとして定義し，中間成果物（もしあれば）と関連付けて情報管理支援機構により企業間共有空間で管理する．」（第２５７頁右欄の下から１行目〜第２５８頁左欄第１０行）
（ｅ）「企業内空間は，その企業のノウハウを駆使して開発作業を行っている空間であり，絶対に他企業からのぞかれない高いセキュリティが必要である．これに対しては，企業のネットワークをサブネットに分け，企業間共有空間は外部ネットと直接接続されたサブネットに置くが，企業内空間は，ファイヤウォールにより隔絶されたサブネットに置くようにする．ファイヤウォールは，安全なプロトコル（電子メールなど）を除いて，外部からの接続を禁止するように設定する．このようにすることにより，他企業からは企業間共有空間にはアクセスできるが，企業内空間にはアクセスできないようになる．」（第２５８頁右欄第１５〜２４行）
（ｆ）「開発過程の技術情報，例えば企画書，設計図面などをネットワーク上で交換するための情報管理支援，企業間のプロセス制御を行うプロセス支援を実現した．」（第２５９頁左欄第１３〜１５行）
（ｇ）「(c) 企業間ファイル転送機能
　情報管理機構に登録されている技術情報を許可された他企業に転送する．」（第２５９頁左欄第２３〜２５行）
（ｈ）「(2) ファイル転送機能
　開発過程の技術情報の場合，テキストデータ中にグラフィックやイメージの図表を含んだいわゆるマルチメディア形式の情報が多い．この情報はメディアごとに別々のファイルとなり，その間でリンク付けされる．ファイル転送ではこのような複数のファイルを一括して転送することが必要である．そこで本システムでは，１つの技術情報に関連する複数のファイルを１つのファイルにまとめてｔａｒ形式で管理し， ＷＷＷのファイル転送により一括転送可能にした．」（第２５９頁右欄第３０行〜第２６０頁左欄第３行）
　
（４）当審の拒絶理由通知にて引用した、「特集 ＣＡＬＳ／ＥＤＩのビジネス展開」，１９９６．０４．０１，ビジネスコミュニケーション，株式会社ビジネスコミュニケーション社，第３３巻，第４号，ｐ．３４〜４１（以下「引用例４」という。）には、下記（ｉ）及び（ｊ）の事項が記載されている。
（ｉ）「調達・商取引システム
　生産工程で調達する物品はその性格によって次の二通りのやり方に分けられる。
ａ．一般部品
　工業規格等に準じた部品や部材の調達は、広く業者を募り、その中から低コスト高品質のものが入手できる仕組みが必要である。このためインターネットなどの開かれたネットワークを用いて、仕様書、図面、購入部品情報を提供できるシステムを提供する。（ＣＩＴＩＳ）
ｂ．特注の部品やユニット
　製品の生産に必要となる特注の部品やユニット等は、設計段階から協力会社が参画しているので、生産段階ではこれらの協力会社に対して生産管理と直結した部品表の補充システムとして実現する（図４）。
また、引き合い、在庫確認、見積もり、受発注、納品検品、決済といった情報のやり取りには高機能ＥＤＩパッケージを採用する。」（第３７頁右欄第１０行〜第３８頁左欄第８行）
（ｊ）「調達・商取引システムにおいて、生産技術部のコンピュータ及び購買部のコンピュータが各種ファイルとコンピュータネットワークで接続されており、特注部品に係る協力会社のコンピュータや一般部品に係る部品メーカー及び資材メーカーのコンピュータと前記各種データベースとはセキュリティ管理及びＥＤＩを介して接続されている調達・商取引システム。」（第４図）
　
（５）当審の拒絶理由通知にて引用した特開平７−３１９８２０号公報（以下「引用例５」という。）には、下記（ｋ）〜（ｎ）の事項が記載されている。
（ｋ）「【００３３】システム部１０は、ファイル管理装置を内蔵する例えばサーバー装置の構成とすることができる。また、ユーザインターフェース部２０は、例えばワークステーションなどの情報処理端末装置により構成することができ、そのディスプレイに各作業段階の作業環境を表示することができる。ユーザインターフェース部２０は、（略）担当者毎に設ける構成とすることもできる。そして、システム部１０とユーザインターフェース部２０とを、例えばＬＡＮなどのネットワークにより接続して、分散処理環境を構築することができる。（略）
【００３４】システム部１０は、（略）参照情報管理部１００とを備える。（以下略）」（第３３，３４段落）
（ｌ）「【００６２】参照情報管理部１００は、例えば図１に示すように構成される。すなわち、参照情報管理部１００は、処理部１１０と、記憶部１２０とからなり、処理部１１０は、（略）情報マスター管理部１１２と、（略）構成情報管理部１１５と（略）を備えている。
【００６３】（略）情報マスター管理部１１２は、作業対象情報を一意に識別するための情報マスターを管理する。情報マスターは、記憶部１２０の情報マスター格納部１２１に格納されている。図８は、この格納部１２１の情報マスターテーブルの構成の一例を示すものである。すなわち、情報マスターテーブルは、作業対象情報をシステム内で一意に識別するための情報番号と、仕様書、図面、コスト計算書など当該情報のユーザに対する名称である情報名と、当該情報が削除されているかどうかを示す削除フラグからなる。（以下略）」（第６２，６３段落。第６２段落の「情報番号管理部１１２」は「情報マスター管理部１１２」の誤記と認めた。）
（ｍ）「【００７０】構成情報管理部１１５は、ワークフローの各ステップに対するフォルダーの内容、つまり実体情報ファイルと、その参照ポインターを管理する。参照ポインターとしては、（略）フォルダーのバージョン毎の内容構成（略）を管理する。」（第７０段落）
（ｎ）「【００７２】また、フォルダーのバージョン毎の内容構成の情報は、構成管理テーブルとして構成情報格納部１２５に格納されている。この構成情報格納部１２５の格納情報である構成管理テーブルの例を図１２に示す。すなわち、この構成管理テーブルは、ワークフロー識別子と、ステップ番号と、バージョン番号と、情報番号と、実体管理部１１６で管理されている情報のファイル名である実体ファイル名とからなる。」（第７２段落）
　
（６）当審の拒絶理由通知にて引用した特開平８−１５３００９号公報（以下「引用例６」という。）には、下記（ｏ）〜（ｑ）の事項が記載されている。
（ｏ）「【００７４】（略）本発明はデータベースを中心とした非同期型データ共有システムに対しても適用可能である。ここではデータベースを利用したマルチメディア・データ検索システムへの実施例について説明する。」（第７４段落）
（ｐ）「【００８０】このようなマルチメディア・データ検索システムを、さまざまなクライアントからアクセス可能な分散システムとして実現するに当たり、各クライアントがまったく同じ環境(すなわちデータ・ビューア)をもっていると仮定することはできない。」（第８０段落）
（ｑ）「【００８７】本実施例では、このビューア・パスをデータベース１２０５中の各データに対するデータ・ビューア指定情報として使用する。ビューア・パスはデータベース１２０５の各データに付加され、データベース１２０５で管理される。（略）
【００８８】ここで、ビューア・パスと実際のビューアとの対応関係を管理するサーバとして、DesktopMgrを導入する。（略）
【００８９】図１３は、ビューア・パスとDesktopMgrを用いた、本実施例２におけるデータ参照処理の様子を示した図である。また、図１４は、この処理の中心となるDesktopMgrの動作を示すフローチャートである。
【００９０】図１３では、ユーザ１３０１がデータベース検索アプリ１３０２において、アイコン１３０３を指定してデータの参照を要求したという状況での処理をあらわしている。（略）DesktopMgr１３０８にアイコン１３０３の本体であるデータ１３０７の表示要求を適切なビューアに配送する要求を発行する。
【００９１】DesktopMgr１３０８は、この要求を受け取ると（ステップＳ１４０１）、データ１３０７に付加されているビューア・パスをデータベース１３０６から取り出す（ステップＳ１４０２）。DesktopMgr１３０８は、次に、ビューア・パスに対応する（略）データ・ビューアを起動する(ステップＳ１４０４）。図１３においては、データ・ビューア１３０９が起動される。（以下略）」（第８７〜９１段落）
　
［対比］
　本願発明（以下「前者」という。）と、引用発明（以下「後者」という。）とを対比すれば、後者の「クライアントコンピュータ」及び「ワークフロー管理用のデータベース」はそれぞれ、前者の「計算機」及び「ワークフローファイル」に相当する。
　また、後者の「ワークフローの中で発生する作業の内容及び作業の処理手順を定義したワークフロー定義」は、前者の「業務処理を行う前記複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータ」に相当するといえる。
　また、後者の「管理する」は、少なくともデータベース内にて情報を保持することを意味しているといえるのだから、前者の「格納する」に相当するといえる。
　また、後者の「読み出させる」は、複数のコンピュータ間を情報が移動することを意味しているといえるのだから、前者の「転送する」や前者の「送信する」に相当するといえる。
　また、後者の「各種データ」は、業務遂行のために業務アプリケーションが扱うデータを意味しているのだから、該「各種データ」と前者の「伝票データ及び図面情報」とは、「業務に係るデータ」という概念で共通する。
　そして、引用発明の「サーバーコンピュータ」は、業務に関する処理を実行する装置であることは明らかであるところ、以下の相違点があるものの、本願発明の「業務処理装置」に相当する。
　
　そうすると、両者は、
「複数の計算機と接続される業務処理装置であって、
　業務処理を行う前記複数の計算機のルート及び各計算機で行う業務処理を規定したワークフローデータをワークフローファイルに格納する手段と、
　計算機に対してワークフローデータを転送する手段と、
　計算機からの要求に応じて業務に係るデータを要求元の計算機に転送する手段と、
を有することを特徴とする業務処理装置。」
である点で一致し、以下の点で相違している。
　
［相違点１］前者のワークフローファイルに格納する手段は、「前記複数の計算機のいずれかからの要求に応じて、」ワークフローデータを「生成し」ているのに対し、後者のワークフローファイルに格納する手段は、そうでない点。
　
［相違点２］前者の業務に係るデータは、「ワークフローに関連する伝票データまたは、図面情報」であり、前者は、「ワークフローに関連付けられ（た）伝票データを格納する伝票データファイルと、ワークフローに関連付けられた図面情報を格納する図面情報ファイルと」を有するのに対し、後者の業務に係るデータは、ワークフローの中で発生する作業で使用する業務アプリケーションで扱う各種データであり、後者は、伝票データファイル及び図面データファイルを有さない点。
　
［相違点３］前者の複数の計算機は、「ファイアウォールの外側及び内側に存在する」ものであり、ワークフローデータを転送する手段及び業務に係るデータを送信する手段は、「ファイアウォール内の」計算機に対して転送、送信し、前者は、「ファイアウォール外の計算機に対してワークフローとともに、関連する伝票データ及び図面情報を一括送信する手段」を有するのに対し、後者が、ファイアウォールを有するかは明らかでなく、ファイアウォール内外の計算機に対する送信態様も明らかでない点。
　
［相違点４］前者の業務に係るデータである「伝票データ」は、「図面識別子と版数の情報を含む」ものであり、前者は、「図面識別子と版数の組み合わせとファイル名とを対応付けて格納する版数管理ファイル」を有するのに対し、後者の業務に係るデータが図面識別子と版数の情報を含むかは明らかでなく、後者は、版数管理ファイルを有さない点。
　
［相違点５］前者は、「図面識別子と表示のためのプログラム名とを対応付けて格納する参照管理ファイル」を有するのに対し、後者は参照管理ファイルを有さない点。
　
［判断］
［相違点１について］
　引用例２の摘記事項（ｃ）には、案件の責任者によるデータ入力に応じてワークフロー・システムが作業スケジュールを自動的に生成する思想が記載されており、また、通常、クライアントからの要求によりサーバが動作することは当業者に周知の事項であるところ、任意の計算機からの要求に応じてワークフローデータを業務処理装置にて生成させるようにすることに格別の困難性は認められない。
　そうすると、相違点１に係る前者の構成は、当業者が容易に想到することができたものというべきである。
　
［相違点２について］
　一般に、業務に係るデータとして、どのような種類の情報やデータを格納しておくかは業務の内容に応じて適宜決定しうる設計的事項にすぎないものであって、また、引用例４の摘記事項（ｉ）には見積もりや受発注に関する情報をやりとりする思想が記載されており、引用例３の摘記事項（ｆ）には設計図面の情報をネットワーク上で交換する思想が記載されているところ、伝票データと図面情報を採用した点に格別性は見いだせない。
　そして、例えば引用例４の摘記事項（ｊ）にみられるように格納データの種類に応じてファイルを設けることも当業者に自明な事項であって、引用例３の摘記事項（ｄ）には中間成果物を業務プロセスに関連付けて共有空間で管理する思想が記載されているところ、伝票データと図面情報を、それぞれ伝票データファイルと図面情報ファイルに格納するようにした点や、これらをワークフローに関連づけた点に格別の困難性を見いだすこともできない。
　そうすると、相違点２に係る前者の構成も、当業者が容易に想到することができたものというべきである。
　
［相違点３について］
　例えば引用例３の摘記事項（ｅ）及び引用例４の摘記事項（ｊ）にみられるように、ファイアウォールのようなセキュリティ機構を必要に応じて設けることは、当業者に周知であるところ、ファイアウォールの内側に存在する計算機とファイアウォールの外側に存在する計算機と設けた点に格別性は見いだせない。
　そして、引用例３の摘記事項（ｇ）及び（ｈ）には、自社内の記憶手段からファイアウォールの外側に存在する計算機へのファイル転送において、互いに関連づけられた複数のファイルを一括して転送する思想が記載されている。
　その一方、自社内の計算機から自社内の記憶手段へのアクセスにおいては、同一ドメイン内で完結するのだから外部の計算機との間ほどの高いセキュリティは要求されず、また、データ交換のための形式変換も要しないことを踏まえれば、当業者にとって、任意に指定されたファイルを必要に応じて適宜読み書きできるような通常のアクセス態様で構成することは自然な選択である。
　そうすると、相違点３に係る前者の構成も、当業者が容易に想到することができたものというべきである。
　
［相違点４について］
　引用例５の摘記事項（ｋ）〜（ｎ）には、ワークフローのステップ、図面等の情報番号とバージョン番号とファイル名とを対応付けて格納する構成管理テーブルをサーバー装置の記憶部に格納する思想が記載されているところ、前者のように、図面識別子と版数の組合せとファイル名とを対応付けて格納する版数管理ファイルを設けることによって図面識別子と版数の情報を含むデータを扱えるように構成させることも、格別の技術的困難を伴うことなくなし得ることである。
　そして、図面識別子と版数の情報を伝票データに含ませることも容易である。
　そうすると、相違点４に係る前者の構成も、当業者が容易に想到することができたものというべきである。
　
［相違点５について］
　引用例６の摘記事項（ｏ）〜（ｑ）には、クライアントコンピュータの操作者が参照を要求したデータに基づいて、サーバ側のデータベースにより管理された当該データとビューアとの対応関係を示す情報を当該データベースから取り出して当該ビューアを起動して当該データを表示させる思想が記載されているところ、前者のように、図面識別子と表示のためのプログラム名とを対応付けて格納した参照管理ファイルを設けることも、格別の技術的困難を伴うことなくなし得ることである。
　そうすると、相違点５に係る前者の構成も、当業者が容易に想到することができたものというべきである。
　
［作用効果について］
　本願発明の奏する作用効果についてみても、引用例１〜６に記載された発明から、当業者が予測し得る程度のものであり、格別のものとはいえない。
　
５．むすび
　以上のとおり、本願は、特許を受けようとする発明が発明の詳細な説明に記載したものでないから、特許法第３６条第６項第１号に規定する要件を満たしていない。
　また、本願明細書の発明の詳細な説明は、当業者がその実施をすることができる程度に明確かつ十分に記載されていないから、この出願は、特許法第３６条第４項に規定する要件を満たしていない。
　また、本願の請求項１に係る発明は、引用例１〜６に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。