【事件の表示】
　平成　５年特許願第１７０５０１号「帳票送受信システムおよび帳票送受信システムにおける帳票送受信方法」拒絶査定不服審判事件〔平成　７年　１月３１日出願公開、特開平　７−　２８９１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成５年７月９日の出願であって、平成１５年１月１５日付で拒絶査定がなされ、これに対し、同年２月２０日に拒絶査定に対する審判請求がなされるとともに、同年３月２４日付で手続補正がなされ、平成１８年１０月１６日付で拒絶理由通知がなされ、これに対し、平成１８年１２月２２日付で手続補正がなされたものである。
　
２．当審の拒絶の理由の概要
　平成１８年１０月１６日付の拒絶理由通知で通知した当審の拒絶の理由の概要は以下のとおりである。
（Ａ）特許法第３６条第４項の規定について（以下「理由Ａ」という。）
「本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項に規定する要件を満たしていない。 
　
 　　　　　　　　　　　　　　　　記 
　
 １．発明の詳細な説明の記載、例えば、段落【００３９】の「１５は変換手段（Ａ）であって，受信側装置(2) のデータ処理体系（コード体系等）に変換するものである（変換手段（Ａ）は受信側装置(2) に変換手段が備えられている場合には不要である）。」の記載、段落【００４９】の「変換手段（Ａ）１５は受信側装置２のデータ処理体系に変換する（この変換は受信側装置２の変換手段（Ｂ）２１において行ってもよい）。」、段落【００７３】の「７１は変換手段（Ａ）であって，中間データ（データα）を中間データ（データβ）に変換する変換手段である。」、及び段落【００８４】の「９０は変換手段（Ｂ）であって，送信側装置のデータコード（データα）を受信側装置５１のデータコード（データβ）に変換するものである。」の記載では、データコード変換するのにどのような情報処理を行うのか不明りょうであるので、変換前後で異なるものをどのように対応づけて変換するのか不明りょうである。 
　よって、当業者が請求項１−４に係る発明を容易に実施できる程度に発明の詳細な説明に記載されているとは認められない。」
 　 
（Ｂ）特許法第３６条第５項第２号の規定について（以下「理由Ｂ」という。）
「本件出願は、特許請求の範囲の記載が下記の点で不備のため、特許法第３６条第５項第２号に規定する要件を満たしていない。 
　
 　　　　　　　　　　　　　　　　　記 
　
１．請求項１について 
（１）「送信側装置は，帳票をもとに属性データを付加して中間データを作成する中間データ作成手段を備え」の記載では、帳票のどのようなデータから属性データをどのように作成するのか不明りょうであり、中間データがどのようなデータであるか不明りょうであるので、中間データを作成するのにどのような情報処理を行なうのか不明りょうである。
　
（２）「受信側装置は，中間データをもとに帳票データを生成する帳票作成手段と，帳票データの作成支援を行なう帳票作成支援手段とを備え，帳票出力をするものであって」の記載では、中間データをどのように情報処理して帳票データを生成しているのか不明りょうであり、また、どのような情報処理を行なって帳票データの作成支援を行うのか不明りょうである。
　
（３）「送信側装置もしくは受信側装置の一方に送信側の中間データのコードを受信側装置のコードに変換する変換手段」では、コードを変換するのにどのような情報処理を行なうのか不明りょうであるので、変換前後で異なるものをどのように対応付けて変換するのか不明りょうである。 
（以下省略する。）」
（なお、上記の指摘した（１）〜（３）の事項をそれぞれ、以下、「指摘事項１」、「指摘事項２」、「指摘事項３」という。）
　
（Ｃ）特許法第２９条第１項柱書の規定について（以下「理由Ｃ」という。）
「本件出願の下記の請求項に記載されたものは、下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないから、特許を受けることができない。
　
 　　　　　　　　　　　　　　　　　記
　
 ・請求項１，３ 
 ・備考 
（中略）
　本願発明は、ハードウエア資源がどのように用いられてソフトウエアによる処理がなされるかを示す具体的な事項を提示しているとはいえないから、特許法第２条で定義される「発明」、すなわち「自然法則を利用した技術的思想の創作」に該当しない。
（以下省略する。）」
　
（Ｄ）特許法第２９条第２項の規定について（以下「理由Ｄ」という。）
「本件出願の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　
 　　　　　　　　　　　　　　　　　記 
　
　１．特開平２−３５５７５号公報 
　２．特開平３−１１９４６８号公報 
　３．「明らかになり始めたデータ交換の将来像」日経バイト，
　　　Ｎｏ．８５，ｐ．２１０−２４０（１９９１．０５．０１）
　
・請求項　　１
・引用文献　１−３
（以下省略する。）」
　
３．理由Ａについて
　審判請求人は、「送信側、受信側が異機種であっても、テキストデータ形式（もしくはバイナリデータ形式）の形式の違いだけであり、その形式が異なる場合には、変換手段でその形式の違いを認識して、変換手段で変換することにより送受信できます。」と主張しているが、変換手段でその形式の違いを認識することは、発明の詳細な説明に記載されておらず、その記載からみて、自明な事項とも認められないので、発明の詳細な説明の記載に基づかない主張であり採用することができない。
　そして、発明の詳細な説明の記載、例えば、段落【００３９】の「１５は変換手段（Ａ）であって，受信側装置(2) のデータ処理体系（コード体系等）に変換するものである（変換手段（Ａ）は受信側装置(2) に変換手段が備えられている場合には不要である）。」の記載、段落【００４９】の「変換手段（Ａ）１５は受信側装置２のデータ処理体系に変換する（この変換は受信側装置２の変換手段（Ｂ）２１において行ってもよい）。」、段落【００７３】の「７１は変換手段（Ａ）であって，中間データ（データα）を中間データ（データβ）に変換する変換手段である。」、及び段落【００８４】の「９０は変換手段（Ｂ）であって，送信側装置のデータコード（データα）を受信側装置５１のデータコード（データβ）に変換するものである。」の記載では、データコードを変換するために変換前後のコード体系の相違を認識することは記載されておらず、またそれらの記載からみて自明な事項とも認められないので、変換前後で相違するコード体系の相違をどのように認識して変換前後で異なるコードをどのように対応づけて変換するのか不明りょうである。 
　よって、当業者が請求項１に係る発明を容易に実施できる程度に発明の詳細な説明が記載されているとは認められないので、本件出願は特許法第３６条第４項の規定を満たしていない。
　
４．理由Ｂについて
（１）指摘事項（１）について
　平成１８年１２月２２日付の手続補正（以下「本件補正」という。）後の「送信側装置は，帳票作成手段により作成された帳票の内容データをもとに属性データを付加して中間データを作成する中間データ作成手段を備え，」の記載について検討すると、当該記載に係る本件補正は、単に、帳票の内容データが帳票作成手段により作成されたことを特定したにすぎず、依然として、帳票の内容データがどのようなデータであり、属性データがどのようなデータあるのか不明りょうであるので、どのようにして帳票の内容データに基づいて属性データを付加した中間データを作成するのか不明りょうであり、作成された中間データがどのようなデータであるのか不明りょうである。
　したがって、当該記載では、依然として、どのような情報処理を行って帳票の内容データをもとに中間データを作成するのか不明りょうである。
　
（２）指摘事項２について
　本件補正後の「受信側装置は，中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する帳票作成手段と，帳票データを加工して帳票出力条件の変更を行なう帳票作成支援手段とを備え，帳票出力をするものであって，」について検討すると、当該記載に関する本件補正は、単に、生成する「帳票データ」を「受信側のフォーマットに帳票の内容データを重合した帳票データ」に特定したにすぎず、依然として「中間データ」がどのようなデータか不明りょうであるので、どのようにして中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成するのか不明りょうであり、帳票データをどのように加工して帳票出力条件の変更を行うのか不明りょうである。
　したがって、当該記載では、依然として、どのような情報処理を行って中間データをもとに帳票データを生成しているのか不明りょうであり、また、どのような情報処理を行って帳票データの作成支援を行うのか不明りょうである。
　
（３）指摘事項３について
　本件補正後の「送信側装置もしくは受信側装置の一方に送信側の中間データである帳票の内容データ及び属性データのコードを受信側装置のコードに変換する変換手段を備える」の記載を検討すると、当該記載に関する本件補正は、単に、「中間データ」が「帳票の内容データ」と「属性データ」からなることを特定したにすぎず、変換前後のコード体系の相違をどのようにして認識するのか不明りょうであり、コードを変換するのにどのような情報処理を行なうのか不明りょうであるので、依然として、変換前後で異なるものをどのように対応付けて変換するのか不明りょうである。
　したがって、当該記載では、依然として、どのような情報処理を行って送信側の中間データである帳票の内容データ及び属性データのコードを受信側のコードに変換するのか不明りょうである。
　
（４）まとめ
　以上のとおり、依然として、上記指摘事項１−３に関して記載の内容が不明りょうであるため、請求項１に係る発明が明確であるとは認められないので、本件出願は、特許法第３６条第５項第２号に規定する要件を満たしていない。
　
５．理由Ｃについて
　請求項１に係る発明が明確でないことは明らかであるが、仮に、請求項１に係る発明が明確であるとして、上記の理由Ｃについて検討する。
　請求項１に係る発明は、発明の詳細な説明からみて送信側装置及び受信側装置は実質的にコンピュータであり、その発明の実施にソフトウエアを必要とするところの、いわゆるコンピュータ・ソフトウエア関連発明である。
　そして、こうしたソフトウエアを利用するコンピュータ・ソフトウエア関連発明が、「自然法則を利用した技術的思想の創作」であるためには、発明はそもそもが一定の技術的課題の解決手段になっていなければならないことから、ハードウエア資源を利用したソフトウエアによる情報処理によって、所定の技術的課題を解決できるような特有の構成が具体的に提示されている必要があるというべきである。 
　そして、本願発明は、発明の詳細な説明の項の段落【００２９】の記載からみて、「異機種間で帳票データの受け渡しを行うことができるようにするとともに，プリンタの指定，印刷帳票の種類，部数，印刷頁の指定等の印刷出力条件の変更も受信側で行うことのできる帳票送受信システムを提供する」という技術的課題を解決しようとするものであって、「帳票を作成して受信側装置に送信する送信側装置と帳票の送信データを受信して帳票を出力する受信側装置とが接続された帳票送受信システム」において、送信側装置及び受信側装置に以下の４つの手段を備えていると認められる。 
（ａ）「帳票作成手段により作成された帳票の内容データをもとに属性データを付加して中間データを作成する中間データ作成手段」
（ｂ）「中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する帳票作成手段」
（ｃ）「帳票データを加工して帳票出力条件の変更を行なう帳票作成支援手段」
（ｄ）「送信側の中間データである帳票の内容データ及び属性データのコードを受信側装置のコードに変換する変換手段」 
　そして、本願発明において技術的課題の解決手段は、上記（ａ）〜（ｄ）の手段であるので、本願発明が、特許法第２条でいう特許法上の「発明」、すなわち「自然法則を利用した技術的思想の創作」に該当するか否かについて、上記（ａ）〜（ｄ）の手段を順次検討する。
　
　上記（ａ）の手段について検討すると、ハードウエア資源として「帳票作成手段」が記載されているものの、「帳票作成手段」に関する記載は、帳票の内容データの作成元を特定しているにすぎず、また、帳票内容データをどのように用いてどのような属性データを付加して中間データを作成するのか具体的に提示されていないので、上記（ａ）の手段に関する記載は、「帳票送受信システム」の送信側装置の機能を、「帳票作成手段により作成された帳票の内容データをもとに属性データを付加して中間データを作成する」ことに特定するに留まり、上記（ａ）の手段に関する記載では、帳票をもとに属性データを付加して中間データを作成する機能が、ハードウェア資源をどのように用いて実現されるか具体的に提示されているとは認められない。
　
　上記（ｂ）の手段について検討すると、ハードウエア資源については記載されておらず、また、中間データをどのように用いて受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成するのか具体的に提示されていないので、上記（ｂ）の手段に関する記載は、「帳票送受信システム」の受信側装置の機能を「中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する」ことに特定するに留まり、上記（ｂ）の手段に関する記載では、中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する機能が、ハードウェア資源をどのように用いて実現されるか具体的に提示されているとは認められない。 
 　 
　上記（ｃ）の手段について検討すると、ハードウエア資源については記載されておらず、また、中間データをどのように用いるか具体的に提示されていないので、上記（ｃ）の手段に関する記載は、「帳票送受信システム」の受信側装置の機能を「帳票データを加工して帳票出力条件の変更を行なう帳票作成支援手段」ことに特定するに留まり、上記（ｃ）の手段に関する記載では、帳票データの作成支援を行なう機能が、ハードウェア資源をどのように用いて実現されたか具体的に提示しているとは認められない。
　
　上記（ｄ）の手段について検討すると、ハードウエア資源として「受信側装置」が記載されているものの、「受信側装置」に関する記載は単に「コード」を限定しているにすぎず、また、どのようにしてコードを変換するのか具体的に提示されているとは認められないので、上記（ｄ）の手段に関する記載は、「帳票送受信システム」の送信側装置もしくは受信側装置の一方の装置の機能を「送信側の中間データのコードを受信側装置のコードに変換する」ことに特定するに留まり、上記（ｄ）の手段に関する記載では、送信側装置もしくは受信側装置の一方が実行する送信側の中間データのコードを受信側装置のコードに変換する機能が、ハードウェア資源をどのように用いて実現されたか具体的に提示しているとは認められない。 
　
　また、全体としてみても、ハードウエア資源がどのように用いられるのか具体的に記載されておらず、各手段に関する記載は、送信側装置と受信側装置の機能を特定するに留まり、各手段に関する記載では、各機能がハードウェア資源をどのように用いて実現されたか具体的に提示しているとは認められない。
　
　以上のとおり、各手段に関する記載は、本願発明の帳票送受信システムを構成する送信側装置及び受信側装置の機能を単に特定しているに留まるので、各手段に関する記載では、各機能がハードウェア資源をどのように用いて実現されるのか具体的に提示されているとは認められない。
　そして、上記の（ａ）〜（ｄ）の手段を含む請求項１に係る発明は、その技術的課題を解決できるような特有の構成を具体的に提示するものではなく、一定の技術的課題の解決手段とはいえないから、特許法第２条でいう「発明」、すなわち「自然法則を利用した技術的思想の創作」に該当しない。
　したがって、請求項１に係る発明は、「自然法則を利用した技術的思想の創作」に該当しないので、特許法第２９条１項柱書の規定により特許を受けることができない。
　
６．理由Ｄについて
　請求項１に係る発明が、「自然法則を利用した技術的思想の創作」に該当しないことは明らかであるが、仮に、請求項１に係る発明が、「自然法則を利用した技術的思想の創作」に該当するとして、上記の理由Ｄについても検討する。
（１）本願発明
　請求項１に係る発明（以下「本願発明」という。）は、平成１８年１２月２２日付の手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。 
「帳票を作成して受信側装置に送信する送信側装置と帳票の送信データを受信して帳票を出力する受信側装置とが接続された帳票送受信システムにおいて，
　送信側装置は，帳票作成手段により作成された帳票の内容データをもとに属性データを付加して中間データを作成する中間データ作成手段を備え，
　受信側装置は，中間データをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する帳票作成手段と，帳票データを加工して帳票出力条件の変更を行なう帳票作成支援手段とを備え，帳票出力をするものであって，
　送信側装置もしくは受信側装置の一方に送信側の中間データである帳票の内容データ及び属性データのコードを受信側装置のコードに変換する変換手段を備えることを特徴とする帳票送受信システム。」
　
（２）引用例 
（２−１）引用例１
　当審で拒絶の理由として引用された特開平２−３５５７５号公報（以下「引用例１」という。）には、図面とともに、以下の事項が記載されている。
（ａ）「１．帳票ＣＡＤシステムで作成されたＣＡＤデータ及びフォームオーバーレイ記述言語を、予め変換データが格納されている変換テーブルを用いて所定の仕様フォームオーバーレイ記述言語に変換するようにしたことを特徴とする帳票ＣＡＤシステムにおけるフォームオーバーレイ記述言語への変換方法。
 ２．前記変換データが属性データである請求項１に記載の帳票ＣＡＤシステムにおけるフォームオーバーレイ記述言語への変換方法。」（第１頁左下欄第６行−同頁同欄第１５行）
　
（ｂ）「この発明は、帳票ＣＡＤシステムで作成されたＣＡＤデータ等を所定のフォームオーバーレイ記述言語に変換するための帳票ＣＡＤシステムにおけるフォームオーバーレイ記述言語への変換方法に関するものである。」（第１頁右下欄第２行−同頁同欄第６行）
　
（ｃ）「従来におけるフォームオーバーレイ記述言語の作成方法を第１図を用いて説明する。
　従来、フォームオーバーレイデザインを作成する為には、そのデザインを出力させるプリンタ毎に定められたフォームオーバーレイ記述言語を用い、例えばＡ社、Ｂ社といった各プリンタ（１２Ａ，１２Ｂ）毎に異なる制約事項等について高度な知識を有するシステムエンジニア等により、フォームオーバーレイ記述言語を用いてコーディングをする必要があった。また、記述言語自体もプリンタ（１２Ａ，１２Ｂ）を製造しているメーカ毎に異なり、さらに同一メーカであっても個々のプリンタにより若干の相違がある。この様なことからコーディングミスも発生し易く、１つの制御プログラムを作成するのに多大な労力を必要としていた。さらにまた、コーディングが正しく行なわれているかどうかを調べる為、出力テストを何度も行なう必要があった。
　この様な問題点を解決すべく、帳票ＣＡＤシステム１を用いて画面対話方式でフォームオーバーレイのデザインを行なう。帳票ＣＡＤシステム１により作成されたＣＡＤデータを、変換対象となるプリンタ名称及びプリンタに搭載されているフォントセット情報等の補足事項６と共に変換システム５に入力する。変換システム５では、これら補足事項６を元に、人力されたＣＡＤデータ２を順次該当するフォ−ムオーバーレイ記述言語７へ変換する。さらに、作成されたフォームオーバーレイ記述言語７をフロッピーディスク９又は磁気テープ１０に格納して、プリンタ１２Ａ，１２Ｂを制御するホストコンピュータ１１Ａ，１１Ｂに与えるか、若くしは通信回線８を介してホストコンピュータ１１Ａ，１１Ｂに与える。ホストコンピュータ１１Ａ，１１Ｂでは与えられたフォームオーバーレイ記述言語７を元に、プリンタ１２Ａ，１２Ｂを制御して可変データ１３Ａ，１３Ｂと共にフォームオーバーレイ帳票１４Ａ，１４Ｂを出力する。」（第１頁右下欄第８行−第２頁右上欄第４行）
　
（ｄ）「この発明について、以下に実施例を挙げて詳細に説明する。 
　第２図はこの発明の原理を示しており、各社毎、各属性毎の変換テーブル２０には帳票ＣＡＤシステム１で生成されたＣＡＤデータ、フォームオーバーレイ記述言語等が人力されると共に、名称等の補助データがオペレータ等によって入力され、変換テーブル２０に予め格納されている各社オーバーレイ記述言語が読出されて出力される。これは、帳票ＣＡＤシステム１の属性データと各社オーバーレイ記述言語の属性データとは完全に１対１の対応関係が成立せず、このために各社毎、各属性毎に対応した変換テーブル２０を準備しておき、この変換テーブル２０を参照しながらデータ変換を行なう。属性データとしては色版、スクリーン濃度、第４図（Ａ）〜（Ｃ）で示すようなラインプレイスメントがあり、スクリーン濃度はたとえば表１のようになっており、ラインプレイスメントは線幅の厚みが指定座標値に対してどのように付せられるかを指示するもので、通常は第４図（Ａ）〜（Ｃ）の如く３種類の指定がある。 
　上記表１のスクリーン濃度の変換テーブルでは、入力値が１６％の場合には記述言語Ａではｌ０％として、記述言語Ｂでは１５％として変換される。更に属性データとしては、実線１点線、二重線といった線の種類、明朝体、ゴシック体といった書体、第５図（Ａ）で示す長体文字、同図（Ｂ）で示す平体文字、第６図（Ａ）〜（Ｃ）で示すような角丸形状、角丸半径その他がある。 
　第３図はこの発明の動作例を示すフローチャートであり、上述したような属性データがＡ社の仕様及びＢ社の仕様として予め格納されている例である。変換する属性が人力されると、（ステップＳｌ）、Ａ社仕様かＢ社仕様かを判断し（ステップＳ２．Ｓ３）、例えばＡ社仕様の場合にはＡ社テーブルの各言語、各属性から該当するテーブルを参照し（ステップ５４）、Ｂ社仕様の場合にはＢ社テーブルの各言語、各層性から該当するテーブルを参照する（ステップＳ５）、その後に変換された属性データを出力して（ステップＳ６）、動作終了となる。なお、上述の実施例ではＡ社、Ｂ社の２種の属性がある場合について説明したが、その数は任意である。」（第２頁右下欄第１２行−第３頁左下欄第１４行）
　
　また、引用例１に記載された事項において、「帳票ＣＡＤシステム（１）」は「ＣＡＤデータ」を作成しているので、ＣＡＤデータ作成手段を有していることは明らかであり、また、「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」は変換された「ＣＡＤデータ」を受信しているので、「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」が受信手段を有していることは明らかである。
　また、引用例１に記載された事項において、「帳票ＣＡＤシステム（１）」側のＣＡＤデータは「帳票ＣＡＤシステム」の記述言語のコード体系でコーディングされたコードからなり、「Ａ社ホスト（１１Ａ）」側のＣＡＤデータは「Ａ社ホスト（１１Ａ）」の記述言語のコード体系でコーディングされたコードからなり、「Ｂ社ホスト（１１Ｂ）」側のＣＡＤデータは「Ｂ社ホスト（１１Ｂ）」の記述言語のコード体系でコーディングされたコードからなり、記述言語の変換の際に、ＣＡＤデータのコードが変換されることは明らかである。
　さらに、上記摘記事項（ｃ）からみて、引用例発明において、「帳票ＣＡＤシステム（１）」から送られてきた「ＣＡＤデータ」をもとに「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」のフォーマットに「可変データ（１３Ａ）（１３Ｂ）」を重合していることは明らかである。
　してみれば、引用例１には、 
『帳票を作成して「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」に送信する「帳票ＣＡＤシステム（１）」と、帳票の送信データを受信して帳票を出力する「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」とが接続されたシステムにおいて、
　「帳票ＣＡＤシステム（１）」は、ＣＡＤデータ作成手段を備え、
　「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」は、前記「ＣＡＤデータ」をもとに「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」側の帳票フォーマットに「可変データ（１３Ａ）（１３Ｂ）」を重合した帳票のデータを生成する帳票作成手段を備え、帳票出力するものであって、
　「帳票ＣＡＤシステム（１）」に「帳票ＣＡＤシステム（１）」側の「ＣＡＤデータ」の記述言語でコーディングされたコードを「Ａ社ホスト（１１Ａ）」及び「Ｂ社ホスト（１１Ｂ）」の「ＣＡＤデータ」の記述言語でコーディングされたコードに変換する「変換システム（５）」を備えるシステム』
との発明（以下「引用例発明」という。）が記載されている。 
　
（２−２）引用例２ 
　同じく、当審で拒絶の理由として引用された特開平３−１１９４６８号公報（以下「引用例２」という。）には、図面とともに、以下の事項が記載されている。 
（ｅ）「第１図は、本発明の伝票処理方式の一実施例の構成を示すブロック図である。本実施例の伝票処理方式は、伝票処理を行うために必要な命令を集大成したプログラミング言語（伝票処理に適したプログラミング言語）である伝票処理記述言語によって記述された伝票処理記述１と、伝票処理記述１を中間形式伝票処理記述３にコンパイルするパーサ２と、中間形式伝票処理記述３と、中間形式伝票処理記述３をインタプリットして伝票処理を実行する制御部４と、伝票処理の対象の伝票を格納するメールボックス５と、伝票処理の対象の伝票に関する入出力を行う端末６と、伝票処理の基礎データ（台帳）を表として有する各種マスタファイルを格納するＲＤＢ（Ｒｅｌａｔｉｏｎａｌ　Ｄａｔａ　Ｂａｓｅ）７と、伝票処理で使用される帳票の形式に関するデータを有する帳票マスタファイル８とを含んで構成されている。」（第２頁右上欄第８行−同頁左下欄第４行）
　
（ｆ）「次に、このように構成された本実施例の伝票処理方式の動作について説明する。
　パーサ２は、専用の伝票処理記述言語によって記述された伝票処理記述１を入力し、上述のような特徴を有する（例えば、第２図に示すような内部構造を有する）中間形式伝票処理記述３を生成（コンパイル）する。
　この生成に際して、パーサ２は、伝票処理記述ｌにおける表および帳票の項目の論理的なアドレスを実際の表および帳票の項目の物理的アドレス（ＲＤＢ７および帳票マスタファイル８における物理的アドレス）に変換する（この変換における副次的な効果として、実行環境との整合を実現することができる）。 
　制御部４は、中間形式伝票処理記述３をインタプリットして所定の伝票処理を実行する。 
　この実行に際しては、制御部４は、中間形式伝票処理記述３内の表および帳票の項目の物理的アドレスによってＲＤＢ７内のデータを直接に参照して中間形式伝票処理記述３内の命令中の式を評価し、メールボックス５または端末６（あるいは、メールボックス５および端末６の両者）に対する伝票に関するデータの入出力を行う（ＲＤＢ７内のデータは制御部４による伝票処理の実行により必要に応じて更新される。当該伝票処理において帳票の形式に関するデータを知得するためには、帳票マスタファイル８が参照される）。」（第２頁左下欄第１５行−第３頁左上欄第１行） 
 　 
　してみれば、引用例２には、 
『伝票処理方式において、伝票処理の対象の伝票に関する入出力を行う「端末（６）」が備えられている』 
との事項が記載されている。 
 　 
（３）対比 
　本願発明と引用例発明とを比較すると、引用例発明の「帳票ＣＡＤシステム（１）及び変換システム（５）」は、本願発明の「送信側装置」に、同じく、「Ａ社ホスト（１１Ａ）及びＢ社ホスト（１１Ｂ）」は「受信側装置」に、同じく、「変換システム（５）」は「変換手段」に、同じく「可変データ（１３Ａ）（１３Ｂ）」は「帳票の内容データ」に、同じく「システム」は「帳票送受信システム」に相当し、引用例発明の「ＣＡＤデータ」と本願発明の「中間データ」は、帳票に関するデータという点で共通するので、両者は、 
「帳票を作成して受信側装置に送信する送信側装置と帳票の送信データを受信して帳票を出力する受信側装置とが接続された帳票送受信システムにおいて， 
　受信側装置は、送信側からのデータをもとに受信側の帳票フォーマットに帳票の内容データを重合した帳票データを生成する帳票作成手段を備え，帳票出力をするものであって， 
　送信側装置に送信側の帳票に関するデータのコードを受信側装置の帳票に関するデータのコードに変換する変換手段を備えることを特徴とする帳票送受信システム。」 
 の点で一致し、以下の点で相違する。 
（相違点１） 
　本願発明では、送信側装置に帳票の内容データをもとに属性データを付加して中間データを作成する中間データ作成手段を設け、この中間データのコードを変換するのに対して、引用例発明では、ＣＡＤデータを作成して、このＣＡＤデータのコードを変換しており、帳票の内容データをもとに属性データを付加して中間データを作成しておらず、中間データのコードを変換していない点。
　
（相違点２） 
　本願発明では、帳票データを加工して帳票出力条件の変更を行なう帳票作成支援手段を備えているのに対し、引用例発明では、そのような帳票作成支援手段を備えていない点。
　
　
（４）判断 
（相違点１について） 
　帳票データの作成時に帳票のイメージデータをもとに帳票ＩＤを付加することは周知事項であり（例えば、特開昭６３−２２８２６８号公報参照。）、また、帳票の内容データを装置間で送受することは周知事項であるので、引用例発明において、帳票データを作成する送信側装置に、帳票の内容データに帳票ＩＤ等の属性データを付加して中間データを作成する中間データ作成手段を設けて中間データを作成て受信側装置に送信することは当業者が容易に考えられる事項であり、その際、帳票の内容データに属性データを付加した中間データを変換するとすることは当業者が当然に考える事項である。
　したがって、上記相違点１に係る本願発明の構成は引用文献発明及び周知事項に基づいて当業者が容易に考えられる事項である。 
 　 
（相違点２について） 
　引用例２に記載された事項の「伝票」、「方式」、「データの入出力を行う」、「端末（６）」は、本願発明の「帳票」、「システム」、「データの作成支援を行う」、「帳票作成支援手段」に相当するので、引用例２には、帳票処理システムに帳票データの作成支援を行う帳票作成支援手段を備えることが開示されている。 
　そして、この引用例２に開示された事項を引用例発明に適用して、引用例発明において、受信側装置に帳票データの作成支援を行なう帳票作成支援手段を備えることは当業者が容易に考えられる事項である。 
　したがって、上記相違点２に係る本願発明の構成は引用例発明及び引用例２に記載された事項に基づいて当業者が容易に考えられる事項である。
　
　また、本願発明の効果は、引用例１、引用例２、及び上記周知事項に基づいて当業者が容易に推測できる事項である。 
　よって、本願発明は、引用例発明、引用例２に記載された事項、及び上記周知事項に基づいて当業者が容易に発明できたものである。 
　
８．結び
　上記の４．で述べたとおり、当業者が請求項１に係る発明を容易に実施できる程度に発明の詳細な説明が記載されているとは認められないので、本件出願は特許法第３６条第４項の規定を満たしていない。
　また、上記の５．で述べたとおり、請求項１に係る発明が明確であるとは認められないので、本件出願は、特許法第３６条第５項第２号に規定する要件を満たしていない。
　また、仮に、請求項１に係る発明が明確であるとしても、上記の６．で述べたとおり、請求項１に係る発明は、請求項１に係る発明は、「自然法則を利用した技術的思想の創作」に該当しないので、特許法第２９条１項柱書の規定により特許を受けることができない。
　さらに、仮に、請求項１に係る発明が、「自然法則を利用した技術的思想の創作」に該当するとしても、上記の７．で述べたとおり、請求項１に係る発明は、引用例発明、引用例２に記載された事項、及び上記周知事項に基づいて当業者が容易に発明できたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。