【事件の表示】
　平成　８年特許願第１７９２６１号「ＥＤＩシステムにおける受信データの管理方式及びその管理方法」拒絶査定不服審判事件〔平成１０年　１月２７日出願公開、特開平１０−　２７１１９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
（手続の経緯、本件発明）
　本願は、平成８年７月９日の出願であって、その請求項１乃至５に係るそれぞれの発明は、平成１０年５月８日付け、平成１４年１１月１４日付けの各手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲に記載されたとおりのものであるところ、その請求項５に係る発明（以下、本件発明という。）は、次のとおりのものである。
「データを格納するファイル名をデータ送信元から事前に受け取り、受信データをそのファイル名で格納するＥＤＩシステムにおける受信データの管理方法において、
　データ送信元から送られてくるファイル名から、送られてくるデータがＣＩＩ標準フォーマットに準拠しているか否かを判断するデータフォーマット判断ステップと、
　送られてくるデータがＣＩＩ標準フォーマットに準拠している場合は、当該データを指定された区分単位に仕分けて格納し、ＣＩＩ標準フォーマットに準拠していない場合は、加入者情報データベースに格納されているデータ送受信先の識別コードが前記ファイル名に指定されていることを確認した後に当該データを格納するデータ格納ステップと、
　を含み、送られてくるデータがＣＩＩ標準フォーマットに準拠している場合としていない場合との両方を同時に取り扱えることを特徴とするＥＤＩシステムにおける受信データの管理方法。」
（刊行物記載の発明）
　これに対し、原審において拒絶の理由に引用された「ＨＩ−ＵＸ／ＷＥ２ ＥＤＩ集配信システムパッケージ　ＣＯＳＭＥＤＩＣ，日本，株式会社日立製作所，１９９５年１１月１日，第２版」（以下、刊行物１という。）には、ＥＤＩシステムに関し次のように説明されている。
(i)「１．６処理概要」（第７〜８頁）には、
「【送信処理】
・業務処理で作成した業務出力ファイルを入力して、送信データ振分け処理　でユーザ指定の接続先コード／データ種別のデータ識別子をもとにデータ　ファイルの振分けを行う。（本処理は必要に応じて選択可能である。）
　この時、振分け処理終了後、振分けファイル毎に処理する後続のプロセス　を起動することができる。
・業務出力ファイルまたは、変換前送信データファイルを送信データ変換処　理で入力して、ユーザ指定のデータ識別子をもとに、フォーマット変換、　コード変換を行う。（本処理はＣＯＳＭＥＤＩＣでの必須処理である。）
　この時、ＣＩＩシンタックスルールに対応したデータ変換を行うＥＤＩＦ　Ｔ／ＣＩＩとの連携処理が可能である。また、ユーザ独自の変換処理を可能と　するため、ユーザ・オウン・コーディング（Ｕ・Ｏ・Ｃ）とのインターフ　ェースも提供する。
・送信データ登録処理では、変換済送信データファイルを入力して、送信対　象となるＸＦＩＴ／Ｓ送信ファイルへの出力処理を行う。（本処理は、Ｃ　ＯＳＭＥＤＩＣでの必須処理である。）
　この時、当該ＸＦＩＴ／Ｓ送信ファイルに対して、常に追加書き処理を行　う。
【受信処理】
・受信データ変換処理では、ＸＦＩＴ／Ｓ受信ファイルを入力して、送信デ　ータ変換処理と同様な処理を行う。
　本処理の起動は、ＸＦＩＴ／Ｓでデータ受信完了後にプロシジャを起動す　る機能が利用できる。
・受信データ振分／統合処理では、送信データ振分け処理と同様な処理を行　い、業務処理の形式に合わせて、データの振分けまたは、統合を行う。こ　の処理の終了後に、振分けファイルを処理する後続のプロセスの起動がで　きる。」　
と記載されている。
(ii)「２．１．１データ識別子」（第９〜１０頁）中には、
「データ識別子の種類は、次の３種類である。
◎接続先コード・・・相手先とのデータ変換を行うために、相手先を識別で　　　　　　　　　　きるユニークな文字列を選択する。
◎データ種別　・・・接続先コードに対してデータの種類（注文データ、請　　　　　　　　　　求データ等）を識別できるユニークな文字列を選択す　　　　　　　　　　る。
◎レコード区分・・・同一接続先コード／データ種別に属するデータにおい　　　　　　　　　　て、レコードフォーマットが異なるレコードが存在す　　　　　　　　　　るファイル形式（同一データ種別にヘッダ・レコード　　　　　　　　　　とデータレコードが存在または、同一ファイルに別種　　　　　　　　　　のデータ種別が存在）で、そのレコードを識別できる　　　　　　　　　　ユニークな文字列を選択する。
　ＣＯＳＭＥＤＩＣでは接続先コードが主キー情報になり、データ種別、レコード区分が副キー情報になる。
　これらのデータ識別子をキーにしてＣＯＳＭＥＤＩＣのデータ変換処理または、データ振分／統合処理を実行する。
　データ変換処理では、データ識別子で指定されたキーに対応する変換情報マスタ、業務コード変換マスタを参照して、指定キーと同一レコードの内容を変換する。
　データ振分／統合処理では、データ識別子で指定されたキーに対応する接続先管理マスタを参照し、指定されたキー（本処理のキーは、接続先コード、データ種別である）と同一のレコードを振分け先ファイルに出力する。
　利用者は、ＣＯＳＭＥＤＩＣ実行時にこのデータ種別子を入力パラメタで与えることで実行可能になるが、・・・」
と記載されている。
(iii)「２．３．６データ変換Ｕ・Ｏ・Ｃインタフェース」（第２４〜２５頁）には、
「データ変換方法には、業務特有な処理が含まれている場合もあり、ＣＯＳＭＥＤＩＣが持つデータ変換機能は対応できないことがある。
　このような場合、ＣＯＳＭＥＤＩＣではデータ変換の前処理と後処理にユーザ出口ルーチンのインターフェースを提供しているのでユーザの特有処理をＵ・Ｏ・Ｃを作成することで対応できる。
　Ｕ・Ｏ・Ｃの使用有無は、接続先コード／データ種別単位に設定可能であり、接続先管理マスタにそのＵ・Ｏ・Ｃ名称を指定する。
（１）データ変換Ｕ・Ｏ・Ｃの位置付け
　データ変換処理とデータ変換Ｕ・Ｏ・Ｃの関連を図２．３−７に示す。
　　　　　・・・
　　　　  ・・・
・データ変換処理で入力ファイルからレコードの入力を行うと、データ変換　前Ｕ・Ｏ・Ｃに１レコード毎に制御を渡す。
・データ変換Ｕ・Ｏ・Ｃでユーザ固有の処理を行った後、再度データ変換処　理に制御を戻す。
・データ変換処理の送信データ変換プログラム、受信データ変換プログラム　は、データ変換Ｕ・Ｏ・Ｃで処理したレコードを変換情報マスタおよび、　業務コード変換マスタの変換内容にもとづいて変換処理を行いデータ変換　後Ｕ・Ｏ・Ｃに制御を渡す。
・データ変換後Ｕ・Ｏ・Ｃで再びＵ・Ｏ・Ｃ固有の処理を行った後、データ　変換処理に制御を戻すことにより、最終形のデータ変換内容が出力ファイ　ルに出力される。」
と記載されている。
(iv)「２．２受信データ振分／統合プログラム（ＣＢＡ１００）」（第７５〜７６頁）には、
「本モジュールは、受信データ変換終了後の受信ファイルを入力し、接続先コード・データ種別単位に振分／統合を行う。
２．２．１機能
　　・・・
    ・・・
（３）エラー処理
　処理実行中にエラーが発生した場合には、下記の様な処理を行う。
　・データ識別方法で使用した、接続先コード・データ種別が接続先管理マ　　スタに未登録であった場合、データのまとまり単位に受信データエラー　　ファイルに出力する（・・・）。
　　・・・」
と記載されている。
　上記(i)〜(iv)の記載を整理すると、
(a)上記刊行物１記載のＥＤＩシステムは、ＣＩＩシンタックスルールに基づくフォーマットを採用するものであり、その受信データ管理方法においては、受信データは、当該データの前に付加された接続先情報、データ種別等により振分け先ファイルに出力されるようになっている。
　換言すれば、上記刊行物１には、データを格納するファイル名をデータ送信元から事前に受け取り、受信データをそのファイル名で格納するＥＤＩシステムにおける受信データの管理方法において、送られてくるデータがＣＩＩ標準フォーマットに準拠している場合は、当該データを指定された区分単位に仕分けて格納ステップを有することが記載されている。
(b)上記刊行物１記載のＥＤＩシステムにおいては、ユーザの特有処理を行うＵ・Ｏ・Ｃとのインターフェースも提供され、受信したＣＩＩ標準フォーマットに準拠していないデータも受信ファイルに出力されている。
(c)上記刊行物１記載のＥＤＩシステムは、接続先コードを記憶した接続先管理マスタを備えており、送られてくるデータをこの接続先コードにより相手先を識別している。
　換言すれば、上記刊行物１においては、ＣＩＩ標準フォーマットに準拠したデータあるいはＣＩＩ標準フォーマットに準拠していないデータが送られてきた場合に、加入者情報データベースに格納されているデータ受信先の識別コードがファイル名に指定されていることを確認するようにしている。
　以上の点をまとめると、上記刊行物１には次の発明が記載されている。
　データを格納するファイル名をデータ送信元から事前に受け取り、受信データをそのファイル名で格納するＥＤＩシステムにおける受信データの管理方法において、
　送られてくるデータがＣＩＩ標準フォーマットに準拠している場合は、当該データを指定された区分単位に仕分けて格納し、ＣＩＩ標準フォーマットに準拠していない場合は、加入者情報データベースに格納されているデータ受信先の識別コードがファイル名に指定されていることを確認した後に当該データを格納するデータ格納ステップと、
　を含み、送られてくるデータがＣＩＩ標準フォーマットに準拠している場合としていない場合との両方を同時に取り扱えることを特徴とするＥＤＩシステムにおける受信データの管理方法。
（対比）
　本件発明と上記刊行物１記載の発明とを対比すると、次に点で相違し、その余では一致する。
（ア）本件発明においては、データ送信元から送られてくるファイル名から　　、送られてくるデータがＣＩＩ標準フォーマットに準拠しているか否か　　を判断するデータフォーマット判断ステップを有するとしているのに対　　し、上記刊行物１にはその旨の記載がない点
（イ）ファイル名に関し、本件発明においては、送信元の識別コードが含ま　　れているのに対し、上記刊行物１にはその点のついての記載が見当たら　　ない。
（相違点についての判断）
　しかるに、上記(iii)に「Ｕ・Ｏ・Ｃの使用有無は、接続先コード／データ種別単位に設定可能であり、接続先管理マスタにそのＵ・Ｏ・Ｃ名称を指定する。」とあるように、上記刊行物１記載のＥＤＩシステムにおいては、Ｕ・Ｏ・Ｃの指定の有無をみて、送られてくるデータがＣＩＩ標準フォーマットに準拠しない（逆の言い方をすれば、ＣＩＩ標準フォーマットに準拠している）ものであるか否かを判断できるようになっている。
　したがって、上記刊行物１記載のＥＤＩシステムにおいて、データ送信元から送られてくるファイル名から、送られてくるデータがＣＩＩ標準フォーマットに準拠しているか否かを判断するデータフォーマット判断ステップを有するとすることは、当業者が適宜なし得ることである。
　また、データを送信するに際し、送信元の識別コードを送るとすることは本件出願前普通に行われていることであるから、上記刊行物１記載の発明において、送信元の識別コードを送るようにすることは、当業者が適宜なし得ることにすぎない。
（まとめ）
  したがって、本件発明は、上記刊行物１記載の発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。