【事件の表示】
　特願２０１８−　７４９５３「商品情報管理システム」拒絶査定不服審判事件〔令和　１年１０月３１日出願公開、特開２０１９−１９１６１８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成３０年４月９日の出願であって、その後の手続の概要は、以下のとおりである。
平成３１年　１月２５日付け：拒絶理由通知書
平成３１年　３月２９日　　：意見書、補正書の提出
令和　元年　６月１３日付け：拒絶査定
令和　元年　９月１８日　　：審判請求書の提出
第２　本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、令和元年３月２９日付け手続補正書により補正（以下、「本件補正」という。）された特許請求の範囲の請求項１に記載された事項より特定される次のとおりのものと認める。
「【請求項１】
　商品の仕入情報と前記商品の納品情報とを比較する情報比較部と、
　前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え、
　前記情報比較部は前記情報変換部が変換した前記納品情報と前記仕入情報とを比較する商品情報管理システム。」
第３　原査定の概要
　原査定の拒絶の理由は、この出願の請求項１に係る発明は、本願の出願日前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１及び引用文献２に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない、というものである。
引用文献１．特開２００５−２５８５６８号公報
引用文献２．特開２００９−２４５３７３号公報　　　
　
第４　引用文献の記載及び引用発明　　
（１）引用文献１の記載　　　
　引用文献１には、以下の事項が記載されている。（下線は、当審で付した。）　　　
「【発明が解決しようとする課題】
【００１３】
　しかしながら、従来の図書館情報管理システムにおける発注受入機能は、その受入側において、次のような問題がある。すなわち、従来の受入処理プログラムにおいては、発注先である書店からの納品データを図書館側のローカルシステムに受け入れる際に、納品データをそのままデータベースに登録する処理を行っていたために、図書館員の意図していないデータがデータベースに登録されてしまうことがある。そして、一度間違ってデータベースに登録してしまうと、そのデータの発見、修正には非常に手間がかかることとなる。
【００１４】
　本発明は、上述のごとき実情に鑑みてなされたものであり、図書館側で発注した図書のデータを図書館側のローカルデータベース等の記憶装置に登録する際に、不正なデータの登録を事前に防ぐことが可能な、発注図書受入システム、該システムにおける各手段としてコンピュータを機能させるためのプログラム、及び該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供すること、をその目的とする。
【００１５】
　本発明は、上述の課題を解決するために、以下の各技術手段によって構成される。第１の技術手段は、
図書館において発注した図書の受入に関する業務を支援するための発注図書受入システム
前記図書館側から発注した図書に関する発注データを記憶した発注データ記憶手段と、前記図書館に納品された図書に関する納品データを入力する納品データ入力手段と、該入力された納品データが前記所蔵データ記憶手段に登録可能なデータ形式であるか否かを判定する形式判定手段と、前記納品データと前記発注データ記憶手段に記憶された発注データとを照合し、前記納品データに整合する発注データが前記発注データ記憶手段に存在するか否かを判定する整合性判定手段と、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定され、且つ、前記整合性判定手段により前記納品データに整合する発注データが前記発注データ記憶手段に存在すると判定された場合にのみ、前記納品データを所蔵データの一部として前記所蔵データ記憶手段に記憶することで、前記納品データを登録する納品データ登録手段と、を有することを特徴としたものである
「【００１８】
　第４の技術手段は、第１乃至第３のいずれかの技術手段において、前記整合性判定手段は、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定された場合にのみ、判定を行うことを特徴としたものである。」
「【００３０】
　
本発明に係る発注図書受入システムは、図書館における各種情報を管理する業務を支援するための図書館情報管理システムの一部として、或いは図書館における図書の発注及び受入に関する業務を支援するための発注受入システムの一部として、或いはそれらとは独立して構成されるシステムであり、以下に、その詳細を図書館情報管理システムの一部として各実施形態で説明する
【００３１】 
　
本発明に係る発注図書受入システム（以下、本システムという）は、図書館で書店等に発注した図書に対し、納品された図書を図書館において受け入れる受入業務を支援するシステムであり、発注した図書の受入時に発注先（納品元）である書店等から送られてきたデータを登録前にチェックすることが可能なシステムである
「【００３９】  
　また、購入依頼情報は、図書目録ＤＢ１２ｂには登録されない。これは、購入依頼情報に含まれる不完全な目録情報が図書目録ＤＢ１２ｂに蓄積されるのを防ぐためで、この購入依頼情報に基づいて、図書館員が発注受入サブシステム１１ａで発注情報を作成することにより、購入する図書の書誌データ、発注データが図書目録ＤＢ１２ｂに登録される。発注受入サブシステム１１ａによって、最終的に発注データが所蔵データとして格納されることとなるが、本発明に係る発注図書受入システムにおいては、さらにこの図書目録ＤＢ１２ｂに登録された発注データの登録時のミスなどによって、所蔵データが意図していないデータで登録されてしまうことを鑑み、書店から図書の納品時に届く納品データを、発注データの代わりに所蔵データとして登録する。」
「【００５４】
　
本システムは、後述する所蔵データ記憶手段，発注データ記憶手段，納品データ入力手段，形式判定手段，整合性判定手段，納品データ登録手段を備え、図書館で書店等に発注した図書に対し、納品された図書を図書館において受け入れる受入業務を支援するシステムである。本システムにおいては、上述の各手段によって、発注した図書の受入時に発注先（納品元）である書店等から送られてきたデータを、図書館のローカルな記憶装置（例えばローカルデータベース）に登録する際に、その登録前にそのデータをチェックすることを可能とする
「【００５６】
　ここで、所蔵データは図書館における図書の所蔵に関するデータであり、所蔵データ記憶手段はその所蔵データを記憶する手段である。また、
発注データは図書館側から発注した図書に関するデータであり、発注データ記憶手段はその発注データを記憶した手段である
【００５７】
　また、形式判定手段，整合性判定手段，納品データ登録手段は、サーバ装置１１に実行可能に格納されたプログラムで構成される。ここでも実際にはプログラムを記憶しておく記憶装置や演算装置やメモリ装置などによって実行可能となる。
【００５８】
　さらに、納品データ入力手段は、図書館員用クライアント装置１４における入力装置、例えばキーボード及びポインティングデバイスやメディア駆動装置などと、サーバ装置１１との間のネットワークにおける通信手段とで構成されるが、基本的にその入力支援用のＧＵＩ等をサーバ装置１１のプログラムとして備えるようにすればよい。納品データ入力手段の別の形態としては、サーバコンピュータにおけるネットワーク３０等を介した通信を行うネットワーク通信手段で構成されるものであってもよい。
【００５９】
　図４で説明する発注図書受入プログラム２は、これら各手段（形式判定手段，整合性判定手段，納品データ登録手段）としてサーバコンピュータを機能させるための上述のプログラムを指し、各手段毎にそれぞれ形式判定プログラム４，整合性判定プログラム５，納品データ登録プログラム６として図示している。なお、納品データ入力に関するサーバ装置１１側のプログラムを納品データ入力プログラム３として図示し、上述のデータベース管理プログラムについては図示していない。また、図４で説明するサーバ装置１１には、本発明に係る発注図書受入プログラム２の他に、その前段階である図書の発注業務を支援するための図書発注プログラム１が、実行可能に（特に図書館員用クライアント装置１４から実行可能に）格納されているものとする。
【００６０】
　本システムにおける発注図書の受入処理について、順を追って説明する。
　
本システムにおける発注図書受入処理は、事前に図書を発注し、その発注データを発注データ記憶手段に記憶しておくことを前提とする
【００６１】
　
図書の発注が行われ、発注した図書が書店等から納品データを伴って届いたとき、本システムにおける発注図書受入処理が実行される。なお、納品データは、納品された図書と同時に届かなくともよく、また、上述したようにＦＤやＣＤ等の記録媒体に格納されて届かなくてもネットワークを介した伝送によって届けられる形態も採用可能である
【００６２】
　まず、
納品データ入力手段は、上述したように、図書館員用クライアント装置１４の入力装置や通信装置などによって、図書館に納品された図書に関する納品データを入力する手段であり
【００６３】
　
形式判定プログラム４は、納品データ入力手段によって入力された納品データが、所蔵データ記憶手段に登録可能なデータ形式（フォーマット等）であるか否かを判定する
【００６４】
　本システムにおいてはさらに、
整合性判定プログラム５によって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する。換言すると、整合性判定プログラム５では、納品データと発注データとの整合性をみることとなる
【００６５】
　整合性判定プログラム５では、納品データに含まれる発注番号に基づいて、納品データに対応する発注データを検索して抽出し、抽出した発注データとその納品データとの整合性を判定するようにするとよい。但し、発注データ及び納品データが、１つの発注又は１つの発注図書に対し、双方のデータで共通の発注番号を含む規定としておく必要がある。また、ここでの
整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよい
「【００６８】
　また、整合性判定プログラム５による整合性チェックの際に、発注データと納品データとの整合性がないと判定された場合には、エラーの内容を、図書館員用クライアント装置１４の表示装置等にテキストファイル等によってファイル出力／画面出力するエラー出力プログラムも、同様にサーバ装置１１に搭載しておくことが好ましい。そして、図書館員が発注データと納品データとのうちどちらのデータが間違っているかを判断して、誤りを訂正して、訂正後登録を行うことが可能なようなプログラムも、同様にサーバ装置１１に搭載しておくことが好ましい。さらに、整合性チェックだけでなく、形式判定プログラム４による形式チェックの結果が否であった場合にも、そのエラー出力プログラムはエラーの内容を、図書館員用クライアント装置１４に同様に出力するようにしておくとよい。」
「【００７０】
　従来、受入の際、単に予め記憶した発注データを所蔵データの一部としてそのまま登録していたので、意図しないデータが登録されることがあったが、本システムによれば、書店からの納品データを登録の対象とし、さらにそれに対応する発注データと登録前に照合することで、より正確なデータを所蔵データの一部として登録することが可能となる。」
「【００８３】
　ステップＳ３におけるチェックの処理例の詳細を図６及び図７に基づいて説明する。
　チェックが開始されると、まず、形式判定プログラムが、書店データの形式が指定された形式と合っているか調べる（ステップＳ１１）。ここでは
、（ａ）書店データが所定のフォーマットであること、（ｂ）項目（フィールド）の型が目録ＤＢ１３におけるデータベースの型と合うこと、などによって、書店データの形式が指定された形式と合っていると判定する。ステップＳ１１で合っていないと判定された場合には（ステップＳ１２でＮＯ）、エラー出力プログラムが、エラー内容を表示し処理を終了する（ステップＳ１３）。このとき、書店データをそのまま登録することはできないので、手入力するなど行って登録することとなる。
【００８４】
　
ステップＳ１１で合っていると判定された場合には（ステップＳ１２で　ＹＥＳ）、整合性判定プログラムが、ステップＳ１４以降の処理、すなわち指定されたデータの形式に基づき、１件ずつデータの解析を行う
【００８５】
　ステップＳ１４では、整合性判定プログラムが、書店データ中の指定された項目をキーにして発注データの検索を行なう。すなわち、指定された検索キー（例えば　発注番号）を元に該当する発注データを検索する。そして、そのような該当する発注データが存在するか否かを判定し（ステップＳ１５）、存在しなければ、エラー出力プログラムが、エラー内容「○○に一致する発注データが存在しません。（○○：ｘｘｘｘｘｘｘ）」を表示して処理を終了する（ステップＳ１６）。このとき、書店データをそのまま登録することはできないので、手入力など行って登録することとなる。存在していれば、ステップＳ１７へと進む。
【００８６】
　ステップＳ１７では、整合性判定プログラムが必須指定の項目の値を調べる。そして、整合性判定プログラムが、必須指定の項目の値が存在するか否か（必須項目が空値であるか）を判定し（ステップＳ１８）、存在しなければエラー出力プログラムがエラー内容「必須項目○○の値が空です。」を表示し（ステップＳ１９）、ステップＳ２０へ進む。このとき、書店データをそのまま登録することはできないので、手入力で修正するなど行って登録することとなる（以下の場合も、エラー／警告表示が出力される場合には同様）。存在していればそのままステップＳ２０へ進む。
【００８７】
　ステップＳ２０では、整合性判定プログラムが、書店データがローカルに登録できるデータであるかどうか調べる。ここでは、（ｃ）状態が発注中であること、（ｄ）購入冊数を超えていないこと、（ｅ）発注先が同じであること、（ｆ）ＭＡＲＣＩＤ（書店側で設定している本につける番号）が合うこと、などによって、登録可能なデータとする。但し、（ｆ）のＭＡＲＩＣＩＤによる比較は、オンラインでの書店データのやり取りの場合でなく、記録媒体による送付でのやり取りの場合には、このデータは登録には使わないで済むので、行わないでよい。
【００８８】
　そして、整合性判定プログラムが登録できるか否かを判定し（ステップＳ２１）、登録不可能なものであればエラー出力プログラムがエラー内容を表示し（ステップＳ２２）、ステップＳ２３へ進む。登録可能なものであれば、そのままステップＳ２３へ進む。ステップＳ２２におけるエラー表示としては、（ｃ）の比較に対しては、「状態が○○のデータは受け入れできません。」とエラー表示し、（ｄ）の比較に対しては、「発注データの冊数（ｘ）を超えています。」とエラー表示し、（ｅ）の比較に対しては、「書店データの発注先（ｘｘｘｘｘｘ）と発注データの発注先（ｘｘｘｘｘｘ）が一致しません。」とエラー表示し、（ｆ）の比較に対しては、「書店データのＭＡＲＣＩＤ（ｘｘｘｘｘｘ）と発注データのＭＡＲＣＩＤ（ｘｘｘｘｘｘ）が一致しません。」とエラー表示する。
【００８９】
　ステップＳ２３では、整合性判定プログラムが発注データと書店データを比較する。そして、整合性判定プログラムが、発注データと書店データの値が合っているか否かを判定する（ステップＳ２４）。ステップＳ２４で合っていないと判定された場合、エラー出力プログラムが警告内容「書店データの○○（ｘｘｘｘｘｘ）と発注データの○○（ｘｘｘｘｘｘ）が一致しません。」を表示し（ステップＳ２５）、ステップＳ２６へ進む。ステップＳ２４で合っていると判定された場合には、そのままステップＳ２６へ進む。このように、書店データの各項目の値と発注データの該当する項目の値を比較し、違うときは結果欄を警告にし、理由欄に項目と状況を表示する。」
「【００９１】
　ここで、「データが発注番号、発注先、書名という順番であること」、且つ、「指定された形式が「，（カンマ）」区切り」であること」、が条件であった場合、上述のごときデータチェックによって、エラーになるデータは、「１２３４５：○○書店：Ｗｉｎｄｏｗｓ（Ｒ）入門」といったものである。さらに、「必須指定の項目が発注先であること」が条件として加わった場合、「１２３４５，，Ｗｉｎｄｏｗｓ（Ｒ）入門」といったデータもエラーとなる。」
（２）引用発明
　したがって、引用文献１には、以下の発明（以下「引用発明」という。）が記載されている。
「図書館において発注した図書の受入に関する業務を支援するための発注図書受入システムであって、
　所蔵データ記憶手段，発注データ記憶手段，納品データ入力手段，形式判定手段，整合性判定手段，納品データ登録手段を備え、
　発注図書受入プログラムは、これら各手段（形式判定手段，整合性判定手段，納品データ登録手段）としてサーバコンピュータを機能させるためのプログラムを指し、
　事前に図書を発注し、その発注データを発注データ記憶手段に記憶しておくことを前提とし、
　図書の発注が行われ、発注した図書が書店等から納品データを伴って届いたとき、本システムにおける発注図書受入処理が実行されるものであって、
　納品データは、ＦＤやＣＤ等の記録媒体に格納されて届く形態やネットワークを介した伝送によって届けられる形態が採用可能であり、
　納品データ入力手段は、図書館員用クライアント装置の入力装置や通信装置などによって、図書館に納品された図書に関する納品データを入力する手段であり、
　整合性判定プログラムによって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定するものであって、
　整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよい、
　発注図書受入システム。」
　
（３）引用文献２の記載　　　
　引用文献２には、以下の事項が記載されている。　　　　　
「【０００１】
　本発明は、複数の発注者と複数の受注者との間で発注および受注を共通に管理することのできる方法、当該方法を実行可能なコンピュータソフトウェアおよび当該コンピュータソフトウェアを記憶した記憶媒体に関し、特に、発注に関して複数の発注者がそれぞれ異なるフォーマットを用い、受注に関して複数の受注者がそれぞれ異なるフォーマットを用いているような場合であっても効率よく、かつ漏れなく対応可能な方法等に関するものである。
【０００２】
　
コンピュータ通信による受発注が普及した今日では、発注者（企業または個人）は、物品またはサービスの発注に際して特定の発注フォーマットを使用して、発注票等を電子的に受注者（企業または個人）に送信することが行われている
しかし、一般に、発注フォーマットは発注者ごとに異なっている
【０００３】 
　
一方受注者（企業または個人）の側でも、受注に際して特定の受注フォーマットを使用してコンピュータによって関連処理（納期管理、在庫管理、経理処理等）を行っている。受注者の側でも、一般に、受注フォーマットは受注者（企業、個人）ごとに異なっている
【０００４】
　同一業種の企業間で異なる発注フォーマットおよび受注フォーマットを統一して効率化を図る動きも無いではないが、一般に発注側からみた受注側企業（つまり、１つの発注企業にとって物品またはサービスを発注する可能性のある相手企業）は極めて他業種にわたり、受注側からみた発注側企業（１つの受注企業が受注する可能性のある相手企業）についても同様であるために、
業種間を越えて受発注フォーマットをすべて統一することは困難な状況である
【０００５】
　
一方、発注者と受注者の間で発注フォーマットで記載された発注情報を受注フォーマットに変換して受注者に送付するサービスも存在しえる
非常に多くの変換を可能にする必要がある。仮にこれらの変換をコンピュータに行わせるものとすれば、コンピュータが変換に要する時間そのものはごく短時間である可能性も有るが、それぞれの変換プログラムにバグは無いか等を確認する作業の負荷は非常に大きい。まして、発注者側と受注者側のデータ変換を行うのが、データ変換のための専門業者であったとすれば、発注者側のフォーマットにも受注者側のフォーマットにも不慣れなために、デバッグ作業の付加は一層大きなものになる
【０００６】
　発注側は取引を管理するために特定のパラメータを必要としているが（例えば、発注担当者の社内コード等）、受注者の側に当該パラメータを管理する用意が無い場合、発注情報を発注フォーマットから受注フォーマットに変換した際に当該パラメータは失われ、以後の出荷情報、納品情報には当該パラメータは含まれないことになる。発注者の側としては、納品情報に当該パラメータが含まれていることを予定しているので、納品管理上支障を生じることになる。」　　　
「【０００７】
　
本発明は、従来技術が有する上記の問題を解決することを目的としたものであって、より具体的には、複数の発注者と複数の受注者の間の発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に変換方法のデバッグを容易にする受発注データ変換方法、受発注管理コンピュータソフトウェアおよび記憶媒体を提供することを目的とする
「【課題を解決するための手段】
【０００９】
　
上記の目的を達成するために、本発明は、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
　発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程と、
　発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程を有する受発注データ変換方法を提案する
【００１０】
　本明細書に於いて「フォーマット」とは、データの記載形式を指す言葉として用いており、ＣＳＶ、ＸＭＬ等の言語形式、特定の言語形式の下でのデータ構造等を表す意味で用いる。発注フォーマットは、いわば発注者が用いる発注票の形式に対応する概念である。パラメータとは、例えば、取引番号、商品コード、発注日、発注数量等の項目である。「発注情報」とは、発注の具体的な内容、例えば、取引番号としての値「２００８０３３１０４５１」、商品コードとしての値「ＡＢ０３２４」等である。」
「【００２３】
　図１は、説明を簡略化するために、
２つの発注企業と１つの受注企業間での受発注を例にとって本発明の働きを説明するための流れ図である。 発注企業の発注情報（発注データ）にはパラメータＡ１、Ｂ１、ＣＸ１が含まれているとする。これに対して、受注企業の受注情報にはＡ１とＢ１のみが必要とされている。また、受注企業の出荷情報にはＡ１とＤ１が含まれているが、発注企業の納品情報には、パラメータＡ１、Ｄ１、Ｃ１が必要である。このような状況では、従来方法によって発注情報を受注情報に変換しただけでは発注情報に含まれていたパラメータＣ１が受注情報から欠落し、結果的にＣ１は納品情報にも含まれないことになる。そこで、本発明の場合は、発注フォーマットから受注フォーマットへの変換を行う際にＣ１を一次保存し、出荷フォーマットから納品フォーマットへの変換を行う際に、保存していたＣ１を挿入することで納品フォーマットに適合した納品情報を作成する
【００２４】
　Ｃ１は、発注企業が受発注処理に常に使用するパラメータであってもよいし、特定の期間のみ使用するようなパラメータであってもよい。フォーマット変換を行った後は、フォーマットチェックを行うことが望ましい。」　　　
　
第５　対比　　　
１．本願発明と引用発明とを対比すると、以下のとおりとなる。
（１）引用発明における「図書館側から発注した図書」は、書店から図書館に納品される商品といえるから、本願発明の「商品」に相当する。
（２）本願発明の「仕入れ情報」、「納品情報」は、本願明細書の発明の詳細な説明を参酌すると、【００１２】に「
仕入情報は取引商品の仕入れに関する情報であり、ユーザが取引商品を仕入先に発注することにより発生する情報である
納品情報は取引商品の納品に関する情報であり、ユーザが発注した取引商品が仕入先から納品されることにより発生する情報である
　一方、引用発明の「発注データ」、「納品データ」は、それぞれ、引用文献１の「発注データは図書館側から発注した図書に関するデータであり」（【００５６】）、「書店から図書の納品時に届く納品データ」（【００３９】）の記載からみて、「ユーザが取引商品を仕入先に発注することにより発生する情報」、「ユーザが発注した取引商品が仕入先から納品されることにより発生する情報」と相違がなく、引用発明の「発注データ」、「納品データ」は、それぞれ、本願発明の「仕入れ情報」、「納品情報」に相当する。
　
（３）引用発明では、
「所蔵データ記憶手段，発注データ記憶手段，納品データ入力手段，形式判定手段，整合性判定手段，納品データ登録手段を備え」、
「発注図書受入プログラムは、これら各手段（形式判定手段，整合性判定手段，納品データ登録手段）としてサーバコンピュータを機能させるためのプログラムを指し」、
「整合性判定プログラムによって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する」
から、引用発明の「整合性判定手段」は、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する整合性判定プログラムを実行しているサーバコンピュータであるといえる。
　そして、引用発明では、整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよく、また、（２）で検討したように、引用発明の「発注データ」、「納品データ」は、それぞれ、本願発明の「仕入れ情報」、「納品情報」に相当するから、引用発明の「整合性判定手段」は、本願発明の「商品の仕入情報と前記商品の納品情報とを比較する情報比較部」に相当する。
　
（４）引用発明の「発注図書受入システム」は、発明の詳細な説明の【００３０】に「本発明に係る発注図書受入システムは、図書館における各種情報を管理する業務を支援するための
図書館情報管理システムの一部として、或いは図書館における図書の発注及び受入に関する業務を支援するための発注受入システムの一部として
構成されるシステム
　もっとも、引用発明は、「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」ておらず、したがって、前記仕入情報とを比較する納品情報が、本願発明では「前記情報変換部が変換した前記納品情報」であるのに対し、引用発明では、「前記情報変換部が変換した前記納品情報」ではない点で相違する。
２．したがって、本願発明と引用発明との間には、次の一致点、相違点があるといえる。　　
　
（一致点）
「商品の仕入情報と前記商品の納品情報とを比較する情報比較部を備え、前記情報比較部は前記納品情報と前記仕入情報とを比較する商品情報管理システム。」
　
（相違点）
　本願発明は「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」、「前記情報比較部は前記情報変換部が変換した前記納品情報と前記仕入情報とを比較する」のに対し、引用発明は「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」ず、また、「前記情報比較部は前記納品情報と前記仕入情報とを比較する」、すなわち、比較する「納品情報」が、「前記情報変換部が変換した前記納品情報」ではない点。
　
第６　判断　　
（１）相違点について　
　引用文献１の発明の詳細な説明には、
「形式判定手段」を備え（【００１５】）、
「前記整合性判定手段は、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定された場合にのみ、判定を行い」、（【００１８】）
「まず、形式判定プログラムが、書店データの形式が指定された形式と合っているか調べる（ステップＳ１１）。ここでは、（ａ）書店データが所定のフォーマットであること、（ｂ）項目（フィールド）の型が目録ＤＢ１３におけるデータベースの型と合うこと、などによって、書店データの形式が指定された形式と合っていると判定する。ステップＳ１１で合っていないと判定された場合には（ステップＳ１２でＮＯ）、エラー出力プログラムが、エラー内容を表示し処理を終了する（ステップＳ１３）。このとき、書店データをそのまま登録することはできないので、手入力するなど行って登録すること」（【００８３】）
が記載されている。
　すなわち、引用文献１に記載された商品情報管理システムでも、納品情報を受け入れるに際して、仕入れ情報と比較して、それぞれのデータフォーマットが異なることまでは想定している。しかしながら、これに対する対処として、わざわざデータ形式の変換までは行わず、異なるフォーマットである場合、整合性の判定を行わず手入力により処理する構成を採用している。
　これに対して、引用文献２の【０００２】、【０００３】の記載を見ると、各社のデータフォーマットが異なることは普通のことであり、【０００５】の記載からみて、上記異なるフォーマットに対処するため、各社のデータフォーマットをコンピュータを用いて変換させることは、課題はあるものの従来行われていたことが理解できる。また、引用文献２の【００２３】などの記載からみて、引用文献２記載の発明は、上記従来技術の課題を解決して、各社のデータフォーマットをコンピュータを用いて変換し、他社でも利用可能とすることであるといえる。
　してみると、引用文献１ではデータフォーマットの相違について想定はしているものの、そのフォーマット変換を行わせることは行っていないところ、引用文献２の記載を見ると、発注する側が受注者に送信する発注データのフォーマットと、受注する側が送信する納品データのフォーマットとが異なることは普通に想定されることであって、これらのフォーマットを変換して互いに利用可能とすることは本願出願前よく知られたことであるといえるから、上記想定されるフォーマットの相違に対する対処として、引用発明に対して引用文献２記載の技術を転用し、本願発明の構成とすることは当業者が容易になしえたことといえる。
　
（２）効果について　　　
　本願発明の奏する作用効果は、引用発明及び引用文献２に記載された技術の奏する作用効果から予測される範囲内のものに過ぎず、格別顕著なものということはできない。　　
　
（３）請求人の主張について　　　
　請求人は、審判請求書の「３．本願発明が特許されるべき理由」において「引用文献１の上記記載から把握できますように、引用発明１では、納品データと発注データとが一致した場合、納品データが所蔵データとして登録され、以降は所蔵データに登録されている納品データを利用して図書の管理が実施されます。一方、納品データのデータ形式が指定された形式と異なるとき、田川審査官が指摘するように、例えば、引用文献２に記載の受発注データ変換方法（以下では、「引用発明２」という）を適用して納品データを変換した場合、納品データの誤変換のリスクが存在します。例えば、図書Ａの発注数が３冊である場合、納品元から送られる納品データ（以下では、「元の納品データ」という）に含まれる図書Ａの納品数が２冊であり、実際に納品された図書Ａの数も２冊であるとします。元の納品データのデータ形式が発注データのデータ形式と異なる場合に元の納品データのデータ形式を変換した結果、納品数が誤って３冊と変換された場合、変換された納品データと発注データとが一致したものと判定されます。このため、実際に納品された図書Ａの数が２冊であるにも関わらず、納品された図書Ａが３冊であるとする誤った納品データが所蔵データとして登録されます。このように、実際には誤りを含む元の納品データが正しい納品データであると誤変換された場合、誤った納品データが所蔵データとして登録されます。換言すれば、引用文献１の段落００３９に記載されていますように、「所蔵データが意図していないデータで登録されてしまう」ことになります。このような納品データの誤変換のリスクが存在する以上、引用発明１のように、所蔵データに登録する対象である元の納品データのデータ形式を引用発明２を適用して変換しようと当業者が試みることはありません。このため、当業者が引用文献１、２を把握していたとしましても、その結果から本件発明１、および、これに関連する請求項２〜５に係る発明(以下では、それぞれ「本件発明２〜５」という)が容易に導きだされることはありません。このため、本件発明１〜５は進歩性を有しています。」と主張する。　　　
　しかしながら、引用文献１の商品情報管理システムでは、整合性判定プログラムが、発注データと書店データの該当する項目の値を比較し、違うときは結果欄を警告にし、理由欄に項目と状況を表示する構成が開示されており、比較する項目の値として購入冊数も例示されている。
　また、引用文献２に開示された受発注データ変換の構成においても、変換されるのは受発注データのフォーマットであって、受発注データの各項目の値ではない。
　そうすると、引用発明に引用文献２の技術を適用しても、発注データに記録された図書の発注数が３冊であるにも関わらず、納品データに含まれる当該図書の納品数が２冊である場合には、整合性判定プログラムにより警告表示がなされるものであって、データ形式を変換した結果納品数を３冊と変換することはない。　　　
　したがって、「実際に納品された図書Ａの数が２冊であるにも関わらず、納品された図書Ａが３冊であるとする誤った納品データが所蔵データとして登録され」るとの主張は採用することができない。また、当該主張を前提とする「このような納品データの誤変換のリスクが存在する以上、引用発明１のように、所蔵データに登録する対象である元の納品データのデータ形式を引用発明２を適用して変換しようと当業者が試みることはありません。」なる主張についても採用することができない。　　
第７　むすび　　　
　以上のとおり、本願発明は、引用文献１、２に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。　　　
　したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。　　　
　よって、結論のとおり審決する。