【事件の表示】
　平成　８年特許願第　９８５５６号「コンピュータファイルの生成手段」拒絶査定不服審判事件〔平成　８年１１月２２日出願公開、特開平　８−３０５６１８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　この出願（以下、「本願」という。）は、平成８年４月１９日（優先権主張平成７年４月２０日、米国）に出願したものであって、平成１８年９月１５日付けで拒絶理由が通知され、これに対して平成１９年３月２２日付けで手続補正がなされたが、同年４月２０日付けで拒絶査定がなされ、これに対して同年８月６日に拒絶査定不服審判が請求されたものである。
 　
　
２．本願発明
　本願の請求項に係る発明は、平成１９年３月２２日付け手続補正書により補正された明細書の特許請求の範囲の請求項１に記載されたとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
「【請求項１】
　ソフトウェアプログラムによって生成され異なるコンピュータシステム間で相互に使用されるファイルを、データフィールド及びヘッダにより構成するコンピュータファイルの生成手段であって、
　前記ヘッダは、オペレーティングシステムにより生成される前記ファイルの識別情報を含むシステムヘッダと、応用プログラムヘッダと、から構成され、
　前記応用プログラムヘッダは、
（１）前記ファイルの自然言語、（２）前記ファイルの暗号情報、（３）前記ファイルの圧縮情報、（４）前記ファイルを生成したプログラムの識別情報、（５）前記生成手段が動くオペレーティングシステムの識別情報、（６）前記ファイルが必要とする通信プロトコル、の各情報を含み、
　前記応用プログラムヘッダ及び前記情報の夫々は、前記ヘッダ領域内における予め設定された所定の区切り記号により確保された領域に格納されることを特徴とするコンピュータファイルの生成手段。」
　
　
３．引用例・周知例
（１）引用例１
　これに対し、原査定の拒絶理由で引用文献１として引用した、特開平６−１３１２２８号公報（以下、「引用例１」という。）には、図面と共に以下の記載がある。
　
（あ）「【要約】
【目的】  データファイルの格納時に、当該データファイルの作成元のアプリケーションの識別情報を登録し、ファイル名の指定により作成元のアプリケーションを自動的に起動するようにし、ファイル操作の効率を向上する。
【構成】  例えば、文書処理用アプリケーションにより作成されたデータファイルはデータ格納エリア２３に格納される。このデータファイル格納時に、ファイルヘッダー部２１に当該データファイルを作成したアプリケーションを識別するためのアプリケーション識別情報が格納される。データファイルのオープン時にデータファイル名を指定すると、ファイルヘッダー部２１が検索され、データファイル名の一致するファイルヘッダー部２１よりアプリケーション識別情報を獲得し、これにより指定されるアプリケーションプログラムを起動する。そして、指定されたデータファイル名のデータ格納エリア２３よりデータを読み出す。」
　
（い）「【０００８】
【実施例】図１は本実施例における情報処理装置の概略構成を表すブロック図である。同図において、１はＣＰＵであり、本情報処理装置における各種制御を実行する。２はＲＯＭであり、本情報処理装置の立ち上げ時における処理プログラム等が格納されている。３はＲＡＭであり、ＣＰＵ１が実行するオペレーティングシステム（ＯＳ）やＯＳ上で実行されるアプリケーションプログラムが格納される。また、ＲＡＭ３には、アプリケーションプログラムが生成し、或いは処理をおこなうデータが格納される。４はキーボードであり、各種制御命令や文書データの入力を行う。５は磁気ディスクであり、種々のアプリケーションプログラムや、各種アプリケーションにより作成されたデータがデータファイルとして格納される。尚、ＣＰＵ１により実行されるアプリケーションプログラムはこの磁気ディスク５よりＲＡＭ３にロードされ、ＣＰＵ１はこのＲＡＭ３上にロードされたプログラムを実行する。また、本実施例では磁気ディスクを用いているが、これは例えばフロッピーディスクのような他の記憶媒体であってもよい。６はディスプレイであり、文書データの表示など各種表示を実行する。
【０００９】図２は、磁気ディスク５に格納されたデータファイルの構成を表す図である。同図において、２１はファイルヘッダー部であり、ここにはオペレーティングシステムや各アプリケーション等が解読可能な共通データ形式により以下の情報が格納される。即ち、データファイルの名称であるデータファイル名、当該データを作成したアプリケーションを識別するための情報（アプリケーション識別情報）、データファイルの一覧表示等の際にファイル名とともに作成もとアプリケーション名を表示するための情報（アプリケーション名表示情報）が格納される。２２はキーワード格納エリアであり、キーワードとしての文字列データと、その文字列が存在する位置を表す行番号とが格納される。２３はデータ格納エリアであり、アプリケーションにより作成されたデータが格納される。図２においては１例として文書処理用のアプリケーションにより作成されたデータを格納した状態が示されており、データエリア２３には文字コードにより構成されるテキストデータとその属性情報（文字飾り等の情報など）が格納されている。」
　
（う）「【００１０】以上のような情報処理装置におけるデータ格納時の処理手順について以下に説明する。図３は本実施例の情報処理装置におけるデータ格納時の手順を表すフローチャートである。尚、本フローチャートはデータ格納を実行するコマンドが入力された時点で起動するものとする。
（中略）
【００１３】また、ステップＳ２０にて、すべてのキーワードについて検索を終えていればステップＳ２１へ進む。ステップＳ２１では、作成ものとのアプリケーションに関して、アプリケーション識別情報及びアプリケーション表示情報をファイルヘッダー部２１に格納する。そしてステップＳ２２で作成データをデータエリア２３へ格納して、本処理を終了する。」
　
（え）「【００２０】まず、ステップＳ５１において、ファイルオープン指示をキーボード４より入力する。そして、ステップＳ５２で、オープンするデータファイルのファイル名をキーボード４より入力する。ステップＳ５３〜ステップＳ５６では、入力されたファイル名を用いて、磁気ディスク５に格納された各データファイルのファイルヘッダー部２１を検索する。まず、ステップＳ５３で、ファイルヘッダー部２１のデータファイル名と上記ステップＳ５２で入力された入力ファイル名とを比較する。ステップＳ５４で、ファイルヘッダー部２１に格納されているファイル名が入力ファイル名と一致した場合はステップＳ５７へ、一致しない場合はステップＳ５５へ進む。」
　
　引用例１の記載（あ）には、文書処理用アプリケーションにより作成されたデータファイルはデータ格納エリア２３に格納され、このデータファイル格納時に、ファイルヘッダー部２１に当該データファイルを作成したアプリケーションを識別するためのアプリケーション識別情報が格納されることが記載されている。
　引用例１の記載（い）、及び、図２の記載によれば、引用例１におけるデータファイルの構成は、データファイルの名称であるデータファイル名、当該データを作成したアプリケーションを識別するための情報であるアプリケーション識別情報、データファイルの一覧表示等の際にファイル名とともに作成もとアプリケーション名を表示するための情報であるアプリケーション名表示情報を含む「ファイルヘッダ部２１」、キーワードとしての文字列データとその文字列が存在する位置を表す行番号とが格納される「キーワード格納エリア２２」、及び、アプリケーションにより作成されたデータが格納される「データ格納エリア２３」の３つの部分からなるといえる。
　また、引用例１の記載（う）、及び、図３の記載によれば、情報処理装置がデータを格納する際に、作成もと（審決注：「作成ものと」と記載されているが、「作成もと」の誤記と解される。）のアプリケーションに関して、アプリケーション識別情報及びアプリケーション表示情報をファイルヘッダー部２１に格納するといえる。
　また、引用例１の記載（え）及び、図５の記載によれば、ファイルをオープンする際に、ファイルヘッダー部のデータファイル名と入力された入力ファイル名を比較しているといえる。
　以上のことから、引用例１には、以下の発明（以下、「引用発明」という。）が記載されているといえる。
　
　「情報処理装置のアプリケーションにより作成されたデータファイルを、ファイルヘッダ部、キーワード格納エリア、データ格納エリアからなるデータファイルに格納する情報処理装置において、
　ファイルヘッダ部は、データファイルの名称であるデータファイル名、当該データを作成したアプリケーションを識別するためのアプリケーション識別情報、アプリケーション名表示情報を含み、
　データ格納時にアプリケーション識別情報及びアプリケーション表示情報をファイルヘッダー部に格納する、
情報処理装置。」
　
　
（２）引用例２
　また、原査定の拒絶理由で引用文献２として引用した、特開平５−２３３７７１号公報（以下、「引用例２」という。）には、図面と共に以下の記載がある。
　
（お）「【０００２】
【従来の技術】近年、情報記録媒体であるＩＣメモリカード（以下、メモリカードと称する）を用いる画像情報再生機能付きのカメラであるＳＭＣ（SOLIDSTATE MEMORY CAMERA) 、あるいは、メモリカード用の画像情報再生装置の各種のものが商品化されつつあり、いろいろな用途にも使用されるようになってきた。このメモリカードは、同一仕様のものが各種のコンピュータ内蔵の機器、例えば、パーソナルコンピュータ（以下、パソコンと称する），ワードプロセッサ，電子手帳等においても利用されている。そこで、当然ながらそれらのメモリカードをＳＭＣとパソコン等の双方で利用することが考えられる。例えば、あるメモリカードを用いて上記ＳＭＣで画像記録を行い、そのメモリカードの画像情報をパソコン上で分類，整理、あるいは、画像合成等の処理を行い、再度、ＳＭＣ上で画像再生をするといった使い方がある。または、一枚のメモリカードがＳＭＣとパソコンの両方で使用することもできる。
【０００３】上述のようにメモリカードがＳＭＣとパソコン等の双方で利用されることになると、当然、ＳＭＣに使用されるメモリカードのフォーマットをパソコンのＤＯＳ（DISK OPERATING SYSTEM ）に合致させる必要がある。現在、上記メモリカードの標準化規格としてＪＥＩＤＡのｖｅｒ．４．１があり、ＳＭＣにもその標準化メモリカードが使用される。図１３は、パソコン用と共用可能な上記標準化のカードに準拠したＳＭＣ用メモリカードの論理フォーマットを示す。これはパソコン用ＤＯＳのフォーマットと同一のものである。（中略）そして、データ領域５４には、撮像された画像情報がファイルの形式で書き込まれる外に、ディレクトリにサブディレクトリが作成された場合には、そのサブディレクトリのディレクトリエントリも書き込まれる。また、このデータ領域５４は、パソコン上では、ファイルデータ領域が対応することになる。
【０００５】（中略）上記画像データのデータ領域に記録されるメモリ構造は、図１８に示すようには、その先頭部にヘッダーが記録される。このヘッダーには、図１９に示すファイル情報が書き込まれる。即ち、「ＳＭＣver.1.0」 などのファイル属性情報であるファイル識別子６３，記録日時６４，データ圧縮処理に用いた画像データ圧縮パラメータ６５，シャッタ速度等の撮影条件６６，文字列のオプション６７などが書き込まれる。なお、上記ディレクトリエントリにファイル名として書き込まれる番号は、図２０に示すように撮影コマ番号に対応させるものとする。」
　
　引用例２の上記記載（お）及び図１８，図１９の記載によれば、画像データファイルの先頭部のヘッダー６１には、「ＳＭＣver.1.0」 などのファイル属性情報であるファイル識別子６３，記録日時６４，データ圧縮処理に用いた画像データ圧縮パラメータ６５，シャッタ速度等の撮影条件６６，文字列のオプション６７などのファイル情報が書き込まれることが記載されているといえる。
　また、メモリカードは、パソコンのDOSに合致させることが記載されており、上記記載（お）におけるメモリカード上の画像データファイルは、コンピュータのファイルとして取扱可能であることは明らかである。
　
　
（３）引用例３
　また、原査定の拒絶理由で引用文献３として引用した、特開平５−３３４１４９号公報（以下、「引用例３」という。）には、図面と共に以下の記載がある。
　
（か）「【０００９】本発明は叙上の問題点を解消するために成されたもので、その目的とするところは汎用ＯＳやＤＯＳ等の立ち上げ時に日本語ワープロ等のアプリケーションレベルのファイル管理が可能なファイル管理装置及びその管理方法を提供するにある。
【００１０】
【課題を解決するための手段】本発明のファイル管理装置はその例が図１に示されている様に予めファイル管理用の管理ファイルがファイルと同形式で記録されたディスク１０と、システムの汎用ディスクオペレーションシステム７の立ち上げ時にディスク１０から記録内容をアクセスして格納する記憶手段６と、システムの入力手段１によるファイル選択時に記録内容を表示する表示手段５とを具備し、表示手段５に表示されたファイル選択時に選択ファイルの内容の一部を表示させて成るものである。
【００１１】本発明のファイル管理方法はその例が図１及び図４に示されている様にアプリケーションレベルのファイル属性情報２９を汎用ディスクオペレーションシステム７を介して読み出される管理ファイル２８と共に記録媒体６に格納し、選択時に管理ファイル２８と共ファイル属性情報２９を表示させて成るものである。」
　
（き）「【００１６】本例では例えばワープロ等のアプリケーションレベルのマシン専用ディスク１０例えば、文章ディスクを用いて初期化する時に、ファイル属性管理用のファイルを作成する。即ち、ファイル名等の格納されたテレクトリと、実際の文章の内容を示す属性情報を一体としたファイル属性管理ファイルを作って汎用ＯＳやＤＯＳで管理する様に成す。この場合のファイル構成は夫々の汎用ＯＳやＤＯＳに準拠し、フォーマット時にそのディスク１０で管理可能な図２に示す様にファイルブロック分の大きさに作成する。このファイル管理属性用ファイルを用いてアクセスが行われる。
【００１７】この様にすれば専用のＯＳを作成することなく汎用ＯＳを用いてアプリケーションレベルのファイル管理が可能となる。
【００１８】図２はこのファイル属性管理用ファイルの構成の一例を示すもので、ファイルの全体的構成としては冒頭に専用フォーマットの日付、システム名等を管理するファイルヘッダー部２１があり、その後に複数ファイルブロック（１）（２）‥‥（Ｎ）２２が設けられている。
【００１９】この複数のファイルブロック２２は例えば１つのファイルブロック（１）で１つのアプリケーションで使用する論理的なファイル単位で管理される。例えば文章ファイル等ではユーザが選択する単位での管理が成される。
【００２０】このファイル属性管理用ファイル内の複数のファイルブロック２２は各々が図３の様に構成されている。
【００２１】図３に於いて、ファイルブロック２２はファイル名（Ａ）２３、ファイル名（Ｂ）２４、ファイル名（Ｃ）２５、‥‥属性情報領域２６並にリザーブ領域２７から構成される。
【００２２】ファイル名（Ａ）２３はファイル選択時に表示装置５に表示する汎用のＯＳやＤＯＳで管理されない実際のファイル名を格納する。例えば日本語ワープロならば文字保存時にユーザが指定したファイル名である。
【００２３】ファイル名（Ｂ）２４には実際のＯＳ又はＤＯＳで管理しているファイル名が格納される。例えば文書ファイルの場合のテキストファイル番号等で自動的にＯＳやＤＯＳで決められる。
【００２４】ファイル名（Ｃ）２５は、文章ファイルの属性情報で、実際のＯＳで管理しているファイル名として格納される。例えば、文章ファイルの行属性や文字属性（全角：半角）等のファイル名であり、図形、カルク等では“０”としファイル名（Ｃ）２５の項はなくなる。
【００２５】属性情報領域２６は文書ファイルなら書式情報や暗証番号、文章の冒頭の文字列等が格納される。
【００２６】書式情報やテキストの文章の先頭からの文字列を格納する場合には、これら文章の先頭からのスペースや制御記号を削除した３２バイト程度の文字列とし、例えば後述する図４の表示例の文字列２９の様に格納する。即ち、文頭にはファイルの作成更新日付でない発行日付や、仕様書等の管理番号、宛先人、タイトル等の文章の内容を示す情報をスペースや制御記号を削除して格納する。
【００２７】又、後述するもキー入力部１の特定キーの入力によって、暗証番号による非表示指定がユーザから行われた場合は、ウィンドをオープンして数桁の暗証番号の入力を行わせるために、属性情報領域２６に暗証番号を格納する様にすることも出来る。又、リザーブ領域２７は従来の拡張領域である。」
　
　上記引用例３の記載（か）、（き）、及び、関連する図２〜４の記載によれば、引用例３には、ワープロ等のアプリケーションレベルのファイル管理が可能なファイル管理装置において、ファイル属性管理用のファイルを作成し、該ファイル属性管理用ファイルには、複数のファイルブロック２２が設けられ、各ファイルブロックは、アプリケーションで使用する論理的なファイル単位で管理され、また、各ファイルブロック２２は、ファイル名（Ａ）２３、ファイル名（Ｂ）２４、ファイル名（Ｃ）２５，属性情報領域２６並にリザーブ領域２７から構成されること、及び、属性情報領域２６は文書ファイルなら書式情報や暗証番号、文章の冒頭の文字列等が格納されることが記載されているといえる。
　
　
（４）引用例４
　原査定で周知の技術の例として提示した、特開昭６３−１９０６４号公報（以下、「引用例４」という。）には、図面と共に以下の記載がある。
　
（く）「特許請求の範囲
１．テキストを構成する文字コード及び制御コードの配列に、ファイルの区切りを示すコードを付加し、さらにファイルの区切りコードにはそのファイルの属性が示される様に構成したテキストの文書処理を行う文書処理装置。」（１頁左欄４〜９行目）
　
（け）「一方、ファイル−ネームやディレクトリを使用しないファイル管理方法も提案されている。第６図にこの一例を示す。
　第６図において、フアイル（ＦＩＬＥ）内の文書は、改行、ＴＡＢ、スペースを含む一連の文字列によって構成されている。又、ファイルの区切りを示す記号によって、各々のファイルに分割された一連のファイルが一つのテキスト（ＴＥＸＴ）を構成している。」（１頁右欄下から３行目〜２頁左欄６行目）
　
　引用例４の記載（く）及び（け）には、区切りを示すコードや記号を用いてファイルを区分することが記載されているといえる。
　
　
（５）周知例１〜８
　この出願の出願前における周知の事項に関し、この出願の出願前に頒布された刊行物である下記の文献を当審で周知例として追加的に提示する。
　
（ア）ファイル中の自然言語を識別する情報に関するもの
（周知例１）特開平７−９３３３５号公報（要約頁における「例えば英語やドイツ語のような国語が混ざったテキストのために、言語フラグ・フィールドは、特定のテキスト文字列の国語を識別する付加情報を含むことができる。」との記載を参照。）
（周知例２）特開平６−２３６２５１号公報（段落００１８〜００２０、００５７の記載を参照。）
　
（イ）暗号化の方法を識別する情報に関するもの
（周知例３）満保雅浩、岡本栄司、情報制御技術としての暗号２　ＵＮＩＸにおけるメールの暗号化−ＰＥＭ、インターフェース、ＣＱ出版株式会社、１９９５年０４月０１日、第２１巻、第４号、１６８〜１７２頁（特に、１７０頁左欄１７行〜同頁右欄末尾の記載及び１７１頁の図２の「Ｐｒｏｃ−Ｔｙｐｅ：」、「ＤＥＫ−Ｉｎｆｏ」についての記載を参照）
（周知例４）特開平４−１０４５５９号公報（第６頁右上欄下から３行目〜同頁右下欄６行、特に「（４）暗号方式識別」についての記載を参照。）
（周知例５）ＩＴＵ−Ｔ　ホワイトブック　オーディオビジュアル／マルチメディア関連（Ｈシリーズ）勧告集、財団法人新日本ＩＴＵ協会、１９９５年０２月１８日、２４６〜２５２頁（特に２５１頁の「アルゴリズム識別子」についての記載を参照。）、
（周知例６）特表平６−５００２１８号公報（９頁右下欄１５〜１９行の「メッセージ・ヘッダ５０２は、データ・ブロック長，ＦＡＸプロトコル・タイプおよび確実なＦＡＸメッセージング・システムで用いるための暗号化タイプに関する情報を含むことができる。」との記載を参照。）
　
（ウ）ファイル圧縮の方法を識別する情報、及び、ファイルを作成したオペレーティングシステムを識別する情報に関するもの
（周知例７）吉崎栄泰、圧縮ユーティリティ新ＬＨの全貌、ＣＭＡＧＡＺＩＮＥ、ソフトバンク株式会社、１９９１年０１月０１日、第３巻、第１号、５９〜６８頁（特に６０頁の表「Ｔａｂｌｅ１」における「圧縮法の種類」との記載及び関連する本文の記載を参照。）
　
（エ）伝送されるデータの可読文字へのエンコード方式を識別する情報に関するもの
（周知例８）円地救、インターネットのハイパーマルチメディア　Ｗｏｒｌｄ−Ｗｉｄｅ　Ｗｅｂ、Ｃｏｍｐｕｔｅｒ　Ｔｏｄａｙ、株式会社サイエンス社、１９９５年０３月０１日、第１２巻、第２号、３２〜４８頁（特に、３３頁左欄７行〜同頁右欄９行、表１、表２を参照。）
　
　
４．対比
　本願発明と引用発明とを対比する。
　引用発明における「情報処理装置」、「アプリケーション」は、それぞれ、本願発明における「コンピュータシステム」、「ソフトウェアプログラム」に相当する。
　引用発明における、「データファイル」は、本願発明における「ファイル」及び「コンピュータファイル」に相当する。なお、請求項１には、「ファイル」、「コンピュータファイル」という異なる表記が用いられているが、発明の詳細な説明の記載を参酌すると、実質的に同じものを指すと解されるので、そのように認定した。
　引用発明における、「データファイル名」は、データファイルを識別するために用いられる情報であるから、本願発明における「ファイルの識別情報」に相当する。
　引用発明における「ファイルヘッダー部」は、本願発明における「ヘッダ」に相当する。
　引用発明における「データエリア」は、本願発明における「データフィールド」に相当する。
　引用発明における、「アプリケーション識別情報」は、格納される当該データを作成したアプリケーションを識別するための情報であるから、本願発明における「ファイルを生成したプログラムの識別情報」に相当する。
　「作成」と「生成」とは、情報処理の技術分野において格別の差異を有しない概念といえるから、引用発明における、「データファイル」を「作成」することは、引用発明における「コンピュータファイルの生成」に相当する。してみれば、引用発明における「情報処理装置」は、「データファイル」を「作成」する手段といえるから、本願発明における「コンピュータファイルの生成手段」に相当する。
　
　してみると、本願発明と引用発明とは，以下の一致点で一致し、また、以下の相違点１〜４でそれぞれ相違する。
　
（一致点）
　「ソフトウェアによって生成されるファイルをデータフィールド及びヘッダにより構成するコンピュータファイルの生成手段であって、
　前記ヘッダは、ファイルの識別情報と、ファイルを生成したプログラムの識別情報とを含む、
　コンピュータファイルの生成手段。」である点。
　
（相違点１）
本願発明におけるファイルは「異なるコンピュータ間で相互に使用されるファイル」であるのに対して、引用発明はそのようになっていない点。
　
（相違点２）
本願発明におけるヘッダは、「オペレーティングシステムにより生成される前記ファイルの識別情報を含むシステムヘッダ」と、「応用プログラムヘッダ」とから構成され、また、「ファイルを生成したプログラムの識別情報」が「応用プログラムヘッダ」に含まれるようになっているのに対して、引用発明はそのようになっていない点。
　
（相違点３）
本願発明における「応用プログラムヘッダ」は、ヘッダ領域内における予め設定された所定の区切り記号により確保された領域に格納されるものであるのに対して、引用発明はそのようになっていない点。
　
（相違点４）
　本願発明におけるヘッダは、「応用プログラムヘッダ」として、（「ファイルを生成したプログラムの識別情報」の他に）「ファイルの自然言語」、「ファイルの暗号情報」、「ファイルの圧縮情報」、「生成手段が動くオペレーティングシステムの識別情報」、及び、「ファイルが必要とする通信プロトコル」の各情報を含むものであるのに対して、引用発明はそのようになっていない点。
　なお、請求項１における、
「前記応用プログラムヘッダは、
（１）前記ファイルの自然言語、（２）前記ファイルの暗号情報、（３）前記ファイルの圧縮情報、（４）前記ファイルを生成したプログラムの識別情報、（５）前記生成手段が動くオペレーティングシステムの識別情報、（６）前記ファイルが必要とする通信プロトコル、の各情報を含み、」
との記載と、
「前記応用プログラムヘッダ及び前記情報の夫々は、前記ヘッダ領域内における予め設定された所定の区切り記号により確保された領域に格納される」
との記載とでは、前者の記載は、（１）〜（６）の各情報が応用プログラムヘッダに含まれるように記載されているのに対して、後者の記載は、応用プログラムヘッダと「前記情報」（（１）〜（６）の各情報。）とが、別のものとして「領域」に含まれるように記載されている点で記載の内容が矛盾しているが、発明の詳細な説明の記載を参酌して、（１）〜（６）の各情報が応用プログラムヘッダに含まれ、該応用プログラムヘッダが所定の区切り記号により確保された領域に含まれるものであると認定した。
　
５．判断
　相違点１〜４について、それぞれ判断する。
　
（相違点１について）
　ソフトウェアプログラムによって生成されたファイルが、異なるコンピュータシステム間で相互に使用されることは、この出願の出願前においてごく普通に行われている周知の事項である。
　そして、コンピュータシステムである引用発明において、ファイルを異なるコンピュータシステム間で相互に使用することを阻害する特段の事情はないから、引用発明において、ソフトウェアプログラムによって生成されたファイルを、異なるコンピュータシステム間で相互に使用されるように構成することは、当業者が容易になし得たことである。
　
（相違点２について）
　本願発明における、「システムヘッダ」に関し、「オペレーティングシステムにより生成される前記ファイルの識別情報」との記載は、その技術的意義が明確でないため、発明の詳細な説明の記載を参酌し、検討する。
　該「ファイルの識別情報」は、この出願の願書に最初に添付された明細書における、請求項１及び段落０００８の、「ファイルが、データフィールド及びヘッダからなり、このヘッダには、識別情報の他に、該データフィールドに記憶されるいかなるデータのコンピュータ表示スクリーン上への提示に必要とされる情報が記憶される」との記載における「ファイル」の「ヘッダ」に記憶される「識別情報」であると解される。そして、「識別情報」についての他の具体的な記載はされていない。
　また、「システムヘッダ」については、段落００１４における「（実際は、「システムヘッダ」も作られるが、図示しない。システムヘッダは、実際にビットを書き込みディスク上にファイルを作り上げる物理的なエージェント（agent）であるオペレーティングシステムによって生成され、用いられる。）」との記載、及び、段落００３７における、「オペレーティングシステムは、システムヘッダ（ここでは図示せず）を挿入するので、第３のパーディーであると考える。」（審決注：「パーディー」は「パーティー」の誤記と解される。）
　以上の記載から、本願発明における「オペレーティングシステムにより生成される前記ファイルの識別情報」とは、オペレーティングシステムがファイルに書き込むなんらかの識別情報であるといえる。
　また、「システムヘッダ」とは、オペレーティングシステムがファイルのヘッダ部分に生成・記憶・挿入する情報であるといえる。
　
　一方、引用発明における、「ファイルヘッダ部」に含まれる「データファイル名」は、該データファイルを識別するための情報といえるものの、該「データファイル名」を生成する主体がオペレーティングシステムであるかどうかは引用例１には記載されていないところ、オペレーティングシステムがファイルに対して種々の識別情報を付することは、この出願の出願前においてごく普通に行われていることである。そして、引用発明も、オペレーティングシステム（ＯＳ）上でアプリケーションプログラムを実行するものである（段落０００８の記載を参照。）ことから、引用発明においても、前記普通に行われていることを採用し、アプリケーションによって生成されるファイルのシステムヘッダに、オペレーティングシステムにより生成されるファイルの識別情報を含むように構成することは、当業者が容易になし得たことである。
　また、本願発明における「ヘッダ」が「システムヘッダ」、「応用プログラムヘッダ」から構成される点に関し、引用発明は、「テキストデータ」以外の情報、即ちヘッダ部を「ファイルヘッダ部」、「キーワード格納エリア」、「（データ格納エリアの）属性情報」というように複数の領域に分け、名前をつけて区別していることから、本願発明のようにヘッダ部を複数部分で構成し、「システムヘッダ」、「応用プログラムヘッダ」という名前をつけて区別することは、当業者が必要に応じて適宜決定して実施すべき程度のことである。
　そして、そのように区別した際に、どの部分にどのデータを格納するかは、当業者が必要に応じて適宜決定すべき事項であるから、「ファイルを生成したプログラムの識別情報」を「応用プログラムヘッダ」に格納するように構成することは、当業者が必要に応じて適宜決定して実施すべき程度のことである。
　
（相違点３について）
　区切りコードによって確保される領域に情報を格納することは、引用例４に記載されているようにこの出願の出願前における周知の手段である。
　してみると、（相違点２について）で検討したように、引用発明において、ヘッダ部を複数部分で構成し、「システムヘッダ」、「応用プログラムヘッダ」という名前をつけて区別した際に、「応用プログラムヘッダ」を、ヘッダ領域内における予め設定された所定の区切り記号により確保された領域に格納するように構成することは、当業者が必要に応じて適宜採用すべき程度のことである。
　
（相違点４について）
　まず、ファイルに関する種々の属性情報をヘッダ部に格納することは、引用例１の他、引用例２，３に記載されているようにこの出願の出願前において周知の事項であり、どのような属性情報を格納するかは所望される情報処理の内容等を考慮して当業者が適宜選択すべき程度のことである。
　そこで、相違点４として挙げた、本願発明の「応用プログラムヘッダ」に含まれる「ファイルの自然言語」、「ファイルの暗号情報」、「ファイルの圧縮情報」、「生成手段が動くオペレーティングシステムの識別情報」、及び、「ファイルが必要とする通信プロトコル」の各情報についてそれぞれ判断する。
　
（１）「ファイルの自然言語」について
　コンピュータシステム間で相互に使用されるファイルにおいて、テキストファイルは自然言語で記述された情報を格納可能なことは、この出願の出願前において周知の事項である。また、日本語、英語、ドイツ語といった種々の自然言語でテキストファイルをそれぞれ作成することは、この出願の出願前において、普通に行われている周知の事項である。
　そして、情報処理のために、ファイル中のテキスト文字列の自然言語を識別する情報を、該ファイルに付加的に記憶することは、例えば、周知例１，２に記載されているように、この出願の出願前において周知の手段である。
　
　引用例１には、例としてテキストデータをデータ格納エリアに記憶することが記載されており、上記周知の事項とは自然言語で記述されたファイルの処理という同一技術分野に属するといえるから、上記周知の手段を引用発明に付加し、自然言語を識別する情報をヘッダ部に含むように構成することは、当業者が必要に応じて適宜付加すべき程度のことである。
　
（２）「ファイルの暗号情報」について
　請求項１における「ファイルの暗号情報」なる情報は、その技術的意義が明確ではないため、発明の詳細な説明の記載を参酌する。
　発明の詳細な説明の段落００１６に、「ブロック２は、「ファイルデータ」が経験したか又は経験するべきである暗号化（encryption）の型の情報（もしあれば）を含む。」とあるから、請求項１における「ファイルの暗号情報」は、「ファイルデータ」に対する暗号化の型の情報であると解される。
　
　一方、データを暗号化する際に、暗号化の方法（アルゴリズム等）を識別するための情報を付加することは、例えば、周知例３〜６に記載されているように、この出願の出願前において、周知の手段である。
　また、テキストファイルを暗号化することは、この出願の出願前において、普通に行われていることである。
　そして、異なるコンピュータシステム間で情報をやりとりする際に、秘密の漏洩を防ぐことは、当業者が当然考慮すべき自明の課題である。
　してみると、（相違点１について）で検討した、引用発明において、ソフトウェアプログラムによって生成されたファイルを、異なるコンピュータシステム間で相互に使用されるように構成した際に、ファイルを暗号化すること、そしてファイルを暗号化した際に暗号の型の情報をヘッダ部に付加することは、当業者が必要に応じて適宜付加すべき程度のことである。
　
（３）「ファイルの圧縮情報」及び「生成手段が動くオペレーティングシステムの識別情報」について
　請求項１における「ファイルの圧縮情報」なる情報は、その技術的意義が明確ではないため、発明の詳細な説明の記載を参酌する。
　発明の詳細な説明の段落００１７に、「ブロック３は、「ファイルデータ」が経験したか又は経験するべきである圧縮の型の情報（もしあれば）を含む。」とあるから、請求項１における「ファイルの圧縮情報」は、「ファイルデータ」に対する圧縮の型の情報であると解される。
　一方、コンピュータシステムにおいてファイルの圧縮を行うことは、この出願の出願前において周知の事項である。
　また、異なるコンピュータシステム間でファイルをやりとりする際に、データ量を（圧縮等で）小さくするべきであることは、この出願の出願前において当業者にとって自明の課題である。
　
　そして、ファイルを圧縮する際に、圧縮法の種類（本願における「圧縮の型」に相当する。）を識別する情報をファイルのヘッダ部に付加することは、例えば周知例７に記載されているように、この出願の出願前における周知の手段である。
　
　してみると、（相違点１について）で検討した、引用発明において、ソフトウェアプログラムによって生成されたファイルを、異なるコンピュータシステム間で相互に使用されるように構成した際に、ファイルを圧縮すること、そしてファイルを暗号化した際にファイルの圧縮情報（圧縮の型の情報）をヘッダ部に付加することは、当業者が必要に応じて適宜付加すべき程度のことである。
　
　また、周知例７には、書庫を作成したＯＳの種類もヘッダに書き込むことが記載されており（６０頁の表「Ｔａｂｌｅ１」における「作成したＯＳの識別文字」との記載及び関連する本文の記載を参照。）、同様に、当業者が必要に応じて適宜付加すべき程度のことである。
　
（４）「ファイルが必要とする通信プロトコル」について
　請求項１における「ファイルが必要とする通信プロトコル」なる情報は、その技術的意義が明確ではないため、発明の詳細な説明の記載を参酌する。
　発明の詳細な説明の段落００２０に、「ブロック６は、ある位置から他の位置まで電子工学的にファイルを伝送するためにその後使われるであろう通信プロトコルによって必要とされる情報を含む。例として、７ビット情報だけを伝送する通信プロトコルがある。このようなプロトコルでは、コンパイルされたコンピュータプログラム、及びある種のビットマップデータの型のような８ビットデータは、伝送できない。図３のブロック６は、ファイルに含まれたデータの型（８ビット又は７ビット）を指示し、このようにどのプロトコルが必要とされるかを指示する。」とあるから、「ファイルが必要とする通信プロトコル」とは、伝送されるファイルに含まれるデータが、８ビットの情報、あるいは、７ビットの情報で表現されているということを示す情報（その表現形式に対応した通信プロトコルが必要であるという情報）であると解される。
　
　一方、周知例８には、メール（電子メール）に、バイナリ・データ、グラフィックス、オーディオ、短いムービー、alphabet以外の文字、複数のフォントなどを一通のメールに混在させるためのＭＩＭＥについて「また、含まれるデータをどういう可読文字にencodeするかなどの方式を，やはりヘッダのContent-Transfer-Encodingで指定する（表２）」との記載があり、表２には、Content-Transfer-Encodingとして、base64、quoted-printable、8bit、7bit、binary、x-my-encodingが列挙されている。
　これは、本願における、「ファイルに含まれたデータの型（８ビット又は７ビット）」を示す情報に対応するといえるから、請求項１における「ファイルが必要とする通信プロトコル」の情報に相当する。
　そして、上記周知例８に記載されたMIME(Multipurpose Internet Mail Extension)は、周知例８に記載されているように、１９９２年に合意されたインターネットの新しい提案の一つ（ＲＦＣ１３４１，１５２１，１５２２）であることから、この出願の出願前である周知の事項であるといえる。したがって、含まれるデータをどういう可読文字にencodeするかなどの方式に関する情報をメッセージのヘッダに含めることは、この出願の出願前において、周知の手段である。
　　
　してみると、（相違点１について）で検討した、引用発明において、ソフトウェアプログラムによって生成されたファイルを、異なるコンピュータシステム間で相互に使用されるように構成した際に、ファイルを可読文字でエンコードすること、そしてファイルをエンコードした際にどのような方式で可読文字にしたかという、「ファイルが必要とする通信プロトコル」の情報をヘッダ部に付加することは、当業者が必要に応じて適宜付加すべき程度のことである。
　
（５）相違点４についての小まとめ
　以上のとおり、相違点４で挙げた本願発明の「応用プログラムヘッダ」に含まれる各情報は、いずれも、データのヘッダ部に付加する情報として周知のものである。
　そして、引用発明において、データのヘッダ部に付加する情報として周知の事項であるこれらの情報を寄せ集めてすべて含めるように構成することに格別の困難性はなく、当業者が容易になし得たことである。
　
（効果について）
　また、本願発明の効果は引用例１〜４及び周知の事項から当業者が予想可能な範囲内のものであり、格別のものではない。
　
（まとめ）
　以上のとおり、本願発明は、引用例１〜４に記載された発明及び周知の事項に基づいて当業者が容易に発明をすることができたものである。
　
　
６．むすび
　以上のとおり、本願の請求項１に係る発明は特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、本願は拒絶すべきものである。
　よって、結論のとおり審決する。