【事件の表示】
　特願２００２−１６８１６４「通信端末装置とその診断システム」拒絶査定不服審判事件〔平成１６年　１月１５日出願公開、特開２００４−　１５５９１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本願は、平成１４年６月１０日の出願であって、平成１７年５月２４日付け拒絶理由通知に対して平成１７年７月１２日付けで手続補正がなされ、これに対して平成１７年１０月２７日に拒絶査定がされ、これに対して平成１７年１１月２２日に拒絶査定不服審判が請求されたものである。 
　
２．本願発明の認定
　
  本願の発明は、平成１７年７月１２日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１から請求項５までに記載した事項により特定されるとおりのものと認められるところ、そのうち、請求項１に係る発明は、下記のとおりである。
　
　【請求項１】　自機の状況を示す診断用データを、外部診断装置に送信するようにした通信端末装置において、診断用データの各データ項目に対するデータ名とデータサイズとを記憶するようにして、データ名とデータサイズ並びに診断用データから成るレコードを外部診断装置へ送信するようにしたことを特徴とする、通信端末装置。
　（以下、これを「本願発明」という。
　なお、「レコード」の意味については、「５．相違点の判断 」において　判断する。）　
　
３．引用刊行物記載の発明 
　
　原査定の拒絶の理由で引用された刊行物１（特開２０００−２３６４０９号公報）には、以下（ア）から（オ）に示す事項が記載されている。
　
（ア）「ファクシミリ装置のリモートメンテナンス方法」
　　　（発明の名称）
　
（イ）「【課題】　分析が必要とされる当該呼の通信管理情報のみを相手ファクシミリ装置から入手する方法を実現すること。
【解決手段】　送信側ファクシミリ装置が前記サービスセンタ側装置に対して通信管理情報の分析が必要とされる該当呼についての通信管理情報をバイナリ信号および画信号として送信する第１の工程と、前記サービスセンタ側装置が前記送信側ファクシミリ装置より送られてきた通信管理情報に示される被呼側ファクシミリ装置に対して発呼を行い、ＤＴＭＦ信号により該当呼の通信管理情報を自己宛てに送信する旨のリモートメンテナンス指示を行う第２の工程と、前記被呼側ファクシミリ装置が前記通信管理情報を記憶する手段に記憶している該当呼の通信管理情報を前記サービスセンタ側装置へ送信する第３の工程と、からなる。」
　　（要約）
　
（ウ）「この場合、各ファクシミリ装置間でのファクシミリの送受信を行う際に、送信側ファクシミリ装置は、呼を同定するための識別コードを生成し、Ｇ３プロトコル上のＮＳＣバイナリ信号によって受信側ファクシミリ装置に当該識別コードを通知し、送信側のファクシミリ装置と受信側ファクシミリ装置のそれぞれが、当該呼についての通信管理情報として、前記識別コードに対応して相手電話番号、通信開始終了日時、送受信枚数、送受信エラー内容およびプロトコルデータを記憶することとしてもよい。」
　（段落０００７）
　
（エ）「　「作用」
　本発明によれば、通信管理情報により該当呼が同定される。送信側ファクシミリ装置からサービスセンタ側装置に対しては、分析が必要とされる該当呼についての通信管理情報が送られ、これを受けてサービスセンタ側装置は被呼側（受信側）ファクシミリ装置に対して該当呼の通信管理情報を送信させるので、サービスセンタ側装置には、分析が必要とされる該当呼についてのみ受信側ファクシミリ装置の通信管理情報が集められることとなる。  」
　　（段落０００９）　
　
　これらの記載は、発明の名称が「ファクシミリ装置のリモートメンテナンス方法」であることから、工程、方法として記載されているものであるが、方法の対象はファクシミリ装置であるから、当該刊行物には、当該工程、方法を実行するファクシミリ装置として、以下の発明が記載されているものと認められる。
　
（オ）サービスセンタ側装置が、分析が必要とされる呼について、被呼側（受信側）ファクシミリ装置に対して該当呼の通信管理情報を送信させる場合において、
　受信側ファクシミリ装置は、通信管理情報を記憶する手段に記憶している、相手電話番号、通信開始終了日時、送受信枚数、送受信エラー内容およびプロトコルデータを該当呼の通信管理情報として、サービスセンタ側装置へ送信するものである。
　
４．本願発明と刊行物１に記載の発明との対比
　
　本願発明における構成要件と刊行物１に記載の発明における構成要件を対比すると、「診断」と「分析」は等価であり、そのために用いるデータとして「診断用データ」は「通信管理情報」に相当する。
　そして、刊行物１に記載の発明における「サービスセンタ側装置」は送られてきたデータにより、分析（診断）を行うための装置であるから、本願発明における「外部診断装置」に相当する。
　また、「ファクシミリ装置」が「通信端末装置」の一種であることは自明である。
（本願発明における「通信端末装置」も、発明の詳細な説明において記載されている実施例は「ファクシミリ装置」である。）
　
　したがって、本願発明と刊行物１に記載の発明とを対比すると、 
　両者は、
　
（カ）自機の状況を示す診断用データを、外部診断装置に送信するようにした通信端末装置において、診断用データを記憶するようにして、当該データを外部診断装置へ送信するようにしたことを特徴とする、通信端末装置。 
　
 である点で一致し、次の（キ）の点で一応の相違がある。 
　
（キ）本願発明が、「診断用データの各データ項目に対するデータ名とデータサイズ」を記憶するようにして、「データ名とデータサイズ並びに診断用データから成るレコード」を外部診断装置に送信するものであるのに対し、刊行物１に記載の発明では、その点が明確でない点。　
　
５．相違点の判断 
　
　上記相違点（キ）について検討する前に、本願発明における「レコード」とは何かについて検討する。
　
　「データ名とデータサイズ並びに診断用データから成るレコード」を送信する点について、本願明細書の段落００２７には、次の（ク）の如く記載されている。　
　
（ク）「ステップ４で送信データのテーブル(診断用テーブル)の先頭の行に記載のアドレスを参照し、この行のデータ名とデータサイズとを識別符号と共に送信バッファにコピーする(ステップ４，ステップ５)。参照したアドレスを用いて、送信用データ中のこの項目のデータを読み出し、これを送信バッファにコピーする。このようにして、各データ項目毎に、データ名とそのサイズ並びにデータ自体のセット(１レコード)が得られ、これを外部診断機器に送信する(ステップ７)。以上の作業を、診断用テーブルの全項目に渡って処理し、診断用テーブルの全項目を外部診断装置へ送信するまで、ループで処理する(ステップ８，ステップ９)。なお図４の結合子（１）は、図６のアルゴリズムでステップ１１〜ステップ４を処理した後、図４の結合子（１）からステップ５以降の処理を行うためのものである。  」
　（ただし、丸付き数字を括弧付き数字に置き換えてある。）
　
　当該記載によれば、本願発明における項目毎の診断用データの各々は、データ名とデータサイズとを識別符号と共に送信バッファにコピーされ、送信は、この項目毎のデータをセットとして、セット毎に送信されるものであって、個々に送信されるデータのセットを１レコードと称している。
　
　したがって、本願発明で「レコード」と称しているデータセットは通常「ファイル」と称されているデータセットと変わるものではない。
　
　そして、拒絶理由通知書で提示した刊行物２（特開２００１−２６５６９２号公報）には、管理対象となる設備機器の状態をデータ通信する設備管理システムにおいて、データを通信する際に、「データを区別するためのデータ名をデータに付加して」送信することにより中央管理装置でデータの種別を判断する発明が記載されている。
　
　管理対象となる設備機器の状態は管理情報に他ならないから、刊行物１に記載の管理情報（上記したように診断データと等価である）において、刊行物２に記載の発明のごとく、送信するデータにデータ名を付加して送信し、サービスセンタ（刊行物２に記載の発明における中央管理装置に相当）で、各データ識別を可能にすることは、当業者が容易に想到し得ることである。　　
　ここで、レコードにデータ名、データサイズが付加されていることは、単なる設計的事項にすぎない。
　
　すなわち、一般にデータを送信する場合においは、ファイルという単位で実行され、ファイルは、データ名、データサイズがセットで付加されているものである。例えば、一太郎（商標）における文書データにも、エクセル（商標）における表計算データにも、データ名、データサイズが付加されていることは、よく知られている。
　また、拒絶査定において周知例として提示した特開２０００−２７２１７８号公報には、画像データの属性情報としてデータ名、データサイズが含まれていることが記載されている。（段落０１００）
　したがって、データファイルにデータ名、データサイズを付加することは周知技術である。
  上記したように本願発明における「レコード」は通常の「ファイル」の意味と変わるものではないから、「レコード」と称される送信されるデータに、データ名とデータサイズを付加することは単なる設計的事項にすぎない。
　
　一方、審判請求人は審判請求書において、「６）本願発明を特許すべき理由」として次の主張をしている。 
　
（ケ）「本願の請求項１，３の発明は「データ名とデータサイズ並びに診断用データとから成るレコードを外部診断装置へ送信する」との特徴を有するが、このような特徴は周知ではない。例えば特開２０００−２７２１７８号は、画像ファイルにそのデータ名とデータサイズとを付加して送信することを記載している。ところでレコードは一般に１つのファイル内に複数有るものであり、各レコードにデータ名、データサイズを記載することと、ファイルの名称やサイズを記載することは別のことである。従って拒絶査定は、本発明の「データ名とデータサイズ並びに診断用データとから成るレコードを外部診断装置へ送信する」との構成を誤って周知技術と認定している。 
 　次に上記の構成により、外部診断装置は自己が管理する通信端末装置の診断用データを解釈するためのテーブルを記憶する必要がなく、また外部診断装置の設置後に導入された通信端末装置の機種に対しても対応できる、との効果が得られる。この効果は、上記の構成により得られる請求項１，３の発明に特有の効果で、周知技術からは予期できないものと言うべきである。 
 　以上のように、「データ名とデータサイズ並びに診断用データとから成るレコードを外部診断装置へ送信する」点は、構成の面でも効果の面でも単なる周知技術ではなく、拒絶査定は取り消されるべきである。 」
　
　審判請求人は、ここで、「ところでレコードは一般に１つのファイル内に複数有るものであり、各レコードにデータ名、データサイズを記載することと、ファイルの名称やサイズを記載することは別のことである。」と述べている。
　
　確かに、１つのファイル内の個々のデータをレコードと称することは一般に行われている。しかしながら、本願発明おけるレコードをそのように解釈することはできない。段落００２７（上掲）に記載されているように、個々のレコードは別々に送信されるものである。また、複数のレコードが１つのファイルとして成っているものではない。
　当該段落００２７に記載されているように、送信データのテーブル（診断用テーブル）に存在するものは参照アドレスであって、各項目のデータは都外テーブルには存在しない。送信すべき個々のデータは参照アドレスの一に別個に存在するものである。
　送信は診断用テーブルの全項目に渡って処理されるが、個々のレコードは個々に送信されるものである。
　したがって、本願発明における「レコード」を一般的な意味での「レコード」として解釈するこはできない。個々に送信されるデータは通常の「ファイル」と同様に扱われている。
　そして、本願発明を特定する請求項１においても、単に「レコードを送信する」としているだけであって、複数のレコードが１ファイルを形成していることは記載されておらず、複数のレコードが１ファイルを形成していることは発明の構成要件ではないから、当該審判請求人の主張は、これを認めることができない。
　
　結局、本願発明は、刊行物１に記載の発明に刊行物２に記載の発明を適用したものにおいて、周知のデータファイルのごとく単にデータサイズをも付加したものにすぎず、本願発明は、刊行物１、２に記載された発明及び周知技術により容易に想到し得たものにすぎない。　
　
６．むすび
　
　以上のとおりであるから、本願発明は、刊行物１、２に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、残る請求項に係る各発明について特に検討するまでもなく、本願は拒絶をすべきものである。 
　よって、結論のとおり審決する。