【事件の表示】
　平成　３年特許願第２８３４０９号「データ変換装置」拒絶査定不服審判事件〔平成　５年　５月１８日出願公開、特開平　５−１１９９５７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成３年１０月３０日の出願であって、その特許請求の範囲の請求項１に係る発明は、平成１５年４月２８日付手続補正書によって補正された明細書の特許請求の範囲の請求項１に記載された事項により特定される次のとおりのもの（以下、「本願発明」という。）である。
　
「入力されたデータを特定のフォーマットのデータに変換するデータ変換部を有するデータ変換装置において、
　入力されるデータの種別に対応する複数の変換処理手順とが登録された変換処理手順登録テーブルを有し、
　前記データ変換部は、
　互いに異なる複数の基本的なデータ変換機能を有し、前記登録テーブルの変換処理手順をコードとして示した複数の変換処理部と、
　入力されたデータの種別を判別し、判別した種別に対応する変換処理手順を前記登録テーブルで検索し、その検索により変換処理手順をコードとして示した複数の変換処理部を組み合せて、入力されたデータのフォーマットを特定のフォーマットへ変換制御する変換処理制御部と、
　からなることを特徴とするデータ変換装置。」
　
２．引用例
　これに対して、原査定の拒絶の理由に引用された、本願の出願日前である平成３年３月１２日に頒布された「特開平３−５７０３９号公報」（以下、「引用刊行物」という。）には、次の事項が記載されている。
（１）「取り得る種々のフォーマットの１つに従ってファイル内に蓄積されている、ファイル内に編成されたデータを処理するためのシステムであって、メモリと、ユーザとの接触を維持する操作モジュール、及びそのためのコマンドに基づいてファイル内のデータを第１のフォーマット（ソースフォーマット）から第２の異なるフォーマット（目標フォーマット）へ変換する変換手段を有する処理ステージとを具備し、前記変換手段が、各々が特定の変換を実行するようにされた複数コンバータと、全ての使用可能なコンバータのリストと、制御モジュールとを具備しており、前記制御モジュールには、前記操作モジュールに接続されていてそこからコマンドを受信し且つそこに変換に関するデータを発信するための入出力手段と、前記受信した変換コマンドに基づいて前記リストから１つのコンバータまたは一連のコンバータを選択する選択手段と、前記選択したコンバータをスタートさせ且つ次いでそれと連絡する連絡手段とを備えていることを特徴とするシステム。」（第１頁左下欄第７行〜右下欄第８行）
（２）「前記リスト内に更に、前記コンバータの組合せによって入手可能な変換と、それに必要なコンバータ及び該コンバータが組み合わされるべき順序とに関するデータが蓄積されていることを特徴とする請求項１または２に記載のシステム。」（第１頁右下欄第１７行〜第２頁左上欄第３行）
（３）「新たなコンバータの導入は著しく単純化され、単にコンバータソフトウェアをメモリにロードし、このコンバータの名前と翻訳仕様とをリストに蓄積すればよい。
　本発明のシステムの他の実施態様では、コンバータの組合せによって入手可能な変換と、それに必要なコンバータ及びそれらが組み合わされるべき順序とに関するデータも前記リスト内に蓄積される。これは更に変換機能の有用性を増大する。」（第３頁左下欄第８〜１７行）
（４）「ユーザは、他のフォーマット（「目標フォーマット」）に変換することを望む特定のデータファイル（保存ファイル内に蓄積されている「ソースフォーマット」の「ソースファイル」）を選択する。選択は、例えばスクリーン上のカーソルでソールファイルを表わす記号（ｉｃｏｎ）を指示することにより行われ得る。
　ユーザは変換コマンドを、例えばスクリーン上のカーソルでかかるコマンドを表わすメニュー領域を指示することにより与える。
　制御モジュールは保存ファイル内のソースファイルをその接続機能１０ｃを介して検索し、ソースフォーマットを決定する。このフォーマットは、例えばソースファイルの名前のなかのファイル拡張によって表示することができる。制御モジュールがソースフォーマットを検出できない場合には、制御モジュール自体が、例えばＡＳＣＩＩフォーマットはかなりよく使用されるのでＡＳＣＩＩフォーマットを含む、予め準備されたプラグラム内デフォルトを選択する。
　次いで制御モジュールの選択機能１０ｂは、構成ファイル内のデータによって、単一のコンバータを用いて及びコンバータの組合わを用いてソースフォーマットから入手可能な全ての目標フォーマットを検索し、それらを、スクリーンに表示するために操作モジュール１１に伝送する。そうするとカーソルによってユーザはこれらの１つを選択できる。」（第５頁左上欄第５行〜右上欄第１４行）
（５）「一旦ソースフォーマット及び目標フォーマットが既知となったならば、制御モジュールの選択機能１０ｂは変換経路を決定する。即ちどのコンバータが続いて作動化されるべきであるかを決定する。このためのデータは構成ファイル内にある。目的のコンバータ、またはコンバータの組合せの場合には最初のコンバータのコマンド及びメッセージを含むリストが構成ファイルから制御モジュールによって読み取られ、このコンバータとの連絡のために準備される。」（第６頁左上欄第１１行〜右上欄第２行）
（６）「新たなコンバータを加えることは上述のシステムにおいては極めて単純である。翻訳テーブルは新たなコンバータに対して一回だけ作成され、コンバータと制御モジュール１０との間の連絡に必要な全てのコマンド及びメッセージを含む。導入時にはコンバータプログラムはシステムメモリ内に蓄積され、コンバータの名前が翻訳テーブルと一緒に構成ファイル１２内に書き込まれる。新たに加えられたコンバータから出発し、新たなコンバータと既存のコンバータとを組み合わせることにより異なる変換を作成することも可能であり、これらもまた構成コンバータを参照して構成ファイル内に包含される。これを自動的に実行することは、新たなコンバータの導入に際して、この新たなコンバータと既存のコンバータとを組み合わせることによりどのような他の変換が可能であるか即座にチェックし、それを構成ファイル１２内に書込む目的でシステム内に存在させる導入プログラムを装備することにより可能となろう。」（第７頁右上欄第１７行〜左下欄第１７行）
　
　上記記載事項及び図面の記載を総合勘案すると、上記引用刊行物には次の発明が記載されている。
「ファイル（ソースファイル）内に蓄積されているファイル内に編成されたデータを第１のフォーマット（ソースフォーマット）から異なるフォーマット（目的フォーマット）のデータに変換する変換手段を有するシステムにおいて、
　前記変換手段は、
　互いに異なる変換を実行するようなされた複数のコンバータと
　全ての使用可能なコンバータ、更に、コンバータの組み合わせによって入手可能な変換とそれに必要なコンバータ及びコンバータが組み合わされるべき順序とに関するデータが蓄積されたリストと、
　ソースファイル（データファイル）のソースフォーマットを判別し、判別したソースフォーマットに対応してリストから変換可能な目標フォーマットを検索・提示し、ユーザが指定した目標フォーマットに対応するリストに基づいて１つのコンバータまたはコンバータを組み合わせた変換経路を決定し、データのフォーマットを目的のフォーマットへ変換制御する制御モジュール
　からなることを特徴とするシステム。」（以下、「引用刊行物記載の発明」という。）
　
３．対比
　
（対比）
　本願発明と引用刊行物記載の発明を対比する。
　引用刊行物に記載された「コンバータ」はデータ変換機能を有しており、本願発明において「基本的なデータ変換機能」がどの程度まで基本的であるのか具体的な限定されておらず、データのフォーマットを目的のフォーマットに変換すること自体は基本的なデータ変換機能であるから、引用刊行物に記載された「コンバータ」は本願発明の「変換処理部」に相当する。
　また、引用刊行物に記載された「コンバータの組み合わせによって入手可能な変換とそれに必要なコンバータ及びコンバータが組み合わされるべき順序とに関するデータ」は、変換処理するための手順であるから、本願発明の「変換処理手順」に相当し、よって、引用刊行物に記載された「リスト」は本願発明の「登録テーブル」に相当する。
　更に、引用刊行物に記載された「変換手段」「制御モジュール」「システム」はそれぞれ本願発明の「データ変換部」「変換処理制御部」「データ変換装置」に相当する。
　よって、両者は、以下のとおりの一致点及び相違点を有するものと認められる。
　
（一致点）
「データを特定のフォーマットのデータに変換するデータ変換部を有するデータ変換装置において、
　データの種別に対応する複数の変換処理手順とが登録された変換処理手順登録テーブルを有し、
　前記データ変換部は、
　互いに異なる複数の基本的なデータ変換機能を有した複数の変換処理部と、
　データの種別を判別し、判別した種別に対応する変換処理手順を前記登録テーブルで検索し、その検索によりデータのフォーマットを特定のフォーマットへ変換制御する変換処理制御部と、
　からなることを特徴とするデータ変換装置。」
　
（相違点）
(1)本願発明においては、入力されたデータに対して変換を行うのに対して、引用刊行物記載の発明においては、ファイル（ソースファイル）内に蓄積されているファイル内に編成されたデータを変換する点。
(2)本願発明においては、入力されたデータの種別に対応する変換処理手順を登録テーブルで検索し、その検索により変換処理手順を複数の変換処理部を組み合せて変換を行うのに対し、引用刊行物記載の発明においては、入力されたデータの種別に対応する変換処理手順を登録テーブルで検索・提示し、ユーザが指定した変換処理手順（リスト）に基づいて１つの変換処理部（コンバータ）または変換処理部（コンバータ）を組み合わせた変換経路を決定し変換を行う点。
(3)本願発明においては、変換処理手順をコードとして示すのに対して、引用刊行物記載の発明においては、そのような記載はなく、特に規定していない点。
　
４．当審の判断
　上記相違点(1)〜(3)について検討する。
　
相違点(1)について
　一般に、データを変換する際に、入力されたデータを変換する構成とするか、ファイルとして蓄積されているデータを指定して変換する構成とするかは、どちらも周知慣用技術であることから、当業者が適宜なし得ることと認められる。
　
相違点(2)について
　変換を行うに際し、引用刊行物記載の発明は、変換処理手順に基づいて１つの変換処理部（コンバータ）または変換処理部（コンバータ）を組み合わせた変換経路としているから、本願発明の複数の変換処理部を組み合わせて変換を行う技術はすでに開示されている。また、本願発明において、常に「複数の変換処理部を組み合わせて変換を行う」ことは、１つの変換処理部の受け持つ変換処理がより細分化されていることに基づくものである。一方、プログラムなど一連の処理を行う際に、各処理をモジュール化・サブルーチン化して処理を行うことは周知慣用技術であり、そのモジュール化した処理を他のプログラムで呼び出して使用することや、そのプログラム全体を他のプログラムが呼び出して使用することも周知慣用技術である。そして、このように処理過程をどのくらいの処理工程でモジュール化するかは、当業者が必要に応じて適宜定める設計的事項である。したがって、引用刊行物記載の発明においても、１つの変換処理部（コンバータ）または変換処理部（コンバータ）を組み合わせて変換を行う構成に代えて、複数の変換処理部を組み合わせて変換を行う構成とすることにより、本願発明のように構成することは、当業者が容易に想到し得たものと認められる。
　また、一般に、入力されたデータに対して処理を行う場合、本願発明のように特定の処理のみを記憶させて自動的に処理を行うか、引用刊行物記載の発明のように複数の処理を記憶しユーザが選択して処理を行うかは、どちらも周知慣用技術であり、当業者が適宜選択する設計的事項であると認められる。
　なお、引用刊行物にも「この実施例においてはユーザは当該変換の前にワードパーフェクトフォーマットからＡＳＣＩＩフォーマットへの変換を実施したので、このフォーマットがデフォルトとして選択されている」（第５頁右下欄第１３〜１７行）と記載されており、以前に選択されたフォーマットを記憶保持することを示しており、フォーマットの選択変更をしない限りは常に特定のフォーマットのデータに変換するものと認められる。
　
相違点(3)について
　一般に、プログラムにおいて、処理手順をモジュール化した際に、各モジュールをコードとして示すことは周知慣用技術である。よって、引用刊行物に記載された構成において、「コンバータ」をコードとして示して処理手順を示す構成とすることは、当業者が適宜なし得ることと認められる。
　また、該構成を加えることにより奏する作用効果も、当業者が予測し得る程度のものであって格別のものとは認められない。
　
　
　なお、請求人が本件審判の請求の理由で付加した構成に基づく主張を加味しても、依然として引用刊行物記載の発明に基づいて当業者が容易に発明し得たものと認められる。
　
５．むすび
　以上のとおり、本願発明は、引用刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができず、本願は拒絶すべきものである。
　よって、結論のとおり審決する。