• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1367716
審判番号 不服2019-12391  
総通号数 252 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-12-25 
種別 拒絶査定不服の審決 
審判請求日 2019-09-18 
確定日 2020-10-29 
事件の表示 特願2018- 74953「商品情報管理システム」拒絶査定不服審判事件〔令和 1年10月31日出願公開、特開2019-191618〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成30年4月9日の出願であって、その後の手続の概要は、以下のとおりである。
平成31年 1月25日付け:拒絶理由通知書
平成31年 3月29日 :意見書、補正書の提出
令和 元年 6月13日付け:拒絶査定
令和 元年 9月18日 :審判請求書の提出

第2 本願発明
本願の請求項1に係る発明(以下、「本願発明」という。)は、令和元年3月29日付け手続補正書により補正(以下、「本件補正」という。)された特許請求の範囲の請求項1に記載された事項より特定される次のとおりのものと認める。
「【請求項1】
商品の仕入情報と前記商品の納品情報とを比較する情報比較部と、
前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え、
前記情報比較部は前記情報変換部が変換した前記納品情報と前記仕入情報とを比較する商品情報管理システム。」

第3 原査定の概要
原査定の拒絶の理由は、この出願の請求項1に係る発明は、本願の出願日前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1及び引用文献2に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない、というものである。

引用文献1.特開2005-258568号公報
引用文献2.特開2009-245373号公報

第4 引用文献の記載及び引用発明
(1)引用文献1の記載
引用文献1には、以下の事項が記載されている。(下線は、当審で付した。)
「【発明が解決しようとする課題】
【0013】
しかしながら、従来の図書館情報管理システムにおける発注受入機能は、その受入側において、次のような問題がある。すなわち、従来の受入処理プログラムにおいては、発注先である書店からの納品データを図書館側のローカルシステムに受け入れる際に、納品データをそのままデータベースに登録する処理を行っていたために、図書館員の意図していないデータがデータベースに登録されてしまうことがある。そして、一度間違ってデータベースに登録してしまうと、そのデータの発見、修正には非常に手間がかかることとなる。
【0014】
本発明は、上述のごとき実情に鑑みてなされたものであり、図書館側で発注した図書のデータを図書館側のローカルデータベース等の記憶装置に登録する際に、不正なデータの登録を事前に防ぐことが可能な、発注図書受入システム、該システムにおける各手段としてコンピュータを機能させるためのプログラム、及び該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供すること、をその目的とする。
【0015】
本発明は、上述の課題を解決するために、以下の各技術手段によって構成される。第1の技術手段は、図書館において発注した図書の受入に関する業務を支援するための発注図書受入システムであって、前記図書館における図書の所蔵データを記憶する所蔵データ記憶手段と、前記図書館側から発注した図書に関する発注データを記憶した発注データ記憶手段と、前記図書館に納品された図書に関する納品データを入力する納品データ入力手段と、該入力された納品データが前記所蔵データ記憶手段に登録可能なデータ形式であるか否かを判定する形式判定手段と、前記納品データと前記発注データ記憶手段に記憶された発注データとを照合し、前記納品データに整合する発注データが前記発注データ記憶手段に存在するか否かを判定する整合性判定手段と、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定され、且つ、前記整合性判定手段により前記納品データに整合する発注データが前記発注データ記憶手段に存在すると判定された場合にのみ、前記納品データを所蔵データの一部として前記所蔵データ記憶手段に記憶することで、前記納品データを登録する納品データ登録手段と、を有することを特徴としたものである。」
「【0018】
第4の技術手段は、第1乃至第3のいずれかの技術手段において、前記整合性判定手段は、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定された場合にのみ、判定を行うことを特徴としたものである。」
「【0030】
本発明に係る発注図書受入システムは、図書館における各種情報を管理する業務を支援するための図書館情報管理システムの一部として、或いは図書館における図書の発注及び受入に関する業務を支援するための発注受入システムの一部として、或いはそれらとは独立して構成されるシステムであり、以下に、その詳細を図書館情報管理システムの一部として各実施形態で説明する。
【0031】
本発明に係る発注図書受入システム(以下、本システムという)は、図書館で書店等に発注した図書に対し、納品された図書を図書館において受け入れる受入業務を支援するシステムであり、発注した図書の受入時に発注先(納品元)である書店等から送られてきたデータを登録前にチェックすることが可能なシステムである。ここで、図書とは、所謂図書(単行書)だけでなく雑誌(逐次刊行物)等も含み、無論、それらには図書館で取り扱うCD,DVD等のメディアや写真集などの視聴覚資料も含まれるものとする。但し、以下の説明では、本システムを、図書(単行書)と雑誌(逐次刊行物)とを区別して取り扱う図書館情報管理システムの一部として説明しているため、基本的に図書と雑誌とを区別して説明し、且つ本発明の特徴部分を図書と雑誌のうちの図書(単行書)のみに対して説明しているが、区別したうちの雑誌(逐次刊行物)に対しても本発明の特徴部分は同様に適用可能であり、簡略化のため説明を省略している。」
「【0039】
また、購入依頼情報は、図書目録DB12bには登録されない。これは、購入依頼情報に含まれる不完全な目録情報が図書目録DB12bに蓄積されるのを防ぐためで、この購入依頼情報に基づいて、図書館員が発注受入サブシステム11aで発注情報を作成することにより、購入する図書の書誌データ、発注データが図書目録DB12bに登録される。発注受入サブシステム11aによって、最終的に発注データが所蔵データとして格納されることとなるが、本発明に係る発注図書受入システムにおいては、さらにこの図書目録DB12bに登録された発注データの登録時のミスなどによって、所蔵データが意図していないデータで登録されてしまうことを鑑み、書店から図書の納品時に届く納品データを、発注データの代わりに所蔵データとして登録する。」
「【0054】
本システムは、後述する所蔵データ記憶手段,発注データ記憶手段,納品データ入力手段,形式判定手段,整合性判定手段,納品データ登録手段を備え、図書館で書店等に発注した図書に対し、納品された図書を図書館において受け入れる受入業務を支援するシステムである。本システムにおいては、上述の各手段によって、発注した図書の受入時に発注先(納品元)である書店等から送られてきたデータを、図書館のローカルな記憶装置(例えばローカルデータベース)に登録する際に、その登録前にそのデータをチェックすることを可能とする。」
「【0056】
ここで、所蔵データは図書館における図書の所蔵に関するデータであり、所蔵データ記憶手段はその所蔵データを記憶する手段である。また、発注データは図書館側から発注した図書に関するデータであり、発注データ記憶手段はその発注データを記憶した手段である。図4では、これら各記憶手段を、図書の書誌データと関連付けて格納する目録DB13として図示している。目録DB13は、図書の目録情報をデータベース形式で記憶装置に記憶するものである。なお、図書の書誌データとの関連付けに関する説明は、他の実施形態で後述する。
【0057】
また、形式判定手段,整合性判定手段,納品データ登録手段は、サーバ装置11に実行可能に格納されたプログラムで構成される。ここでも実際にはプログラムを記憶しておく記憶装置や演算装置やメモリ装置などによって実行可能となる。
【0058】
さらに、納品データ入力手段は、図書館員用クライアント装置14における入力装置、例えばキーボード及びポインティングデバイスやメディア駆動装置などと、サーバ装置11との間のネットワークにおける通信手段とで構成されるが、基本的にその入力支援用のGUI等をサーバ装置11のプログラムとして備えるようにすればよい。納品データ入力手段の別の形態としては、サーバコンピュータにおけるネットワーク30等を介した通信を行うネットワーク通信手段で構成されるものであってもよい。
【0059】
図4で説明する発注図書受入プログラム2は、これら各手段(形式判定手段,整合性判定手段,納品データ登録手段)としてサーバコンピュータを機能させるための上述のプログラムを指し、各手段毎にそれぞれ形式判定プログラム4,整合性判定プログラム5,納品データ登録プログラム6として図示している。なお、納品データ入力に関するサーバ装置11側のプログラムを納品データ入力プログラム3として図示し、上述のデータベース管理プログラムについては図示していない。また、図4で説明するサーバ装置11には、本発明に係る発注図書受入プログラム2の他に、その前段階である図書の発注業務を支援するための図書発注プログラム1が、実行可能に(特に図書館員用クライアント装置14から実行可能に)格納されているものとする。
【0060】
本システムにおける発注図書の受入処理について、順を追って説明する。
本システムにおける発注図書受入処理は、事前に図書を発注し、その発注データを発注データ記憶手段に記憶しておくことを前提とする。なお、図書受入時に発注データがみつからない場合には、発注していない図書として、別途登録するか、その図書を返品するかの作業が加わることとなる。なお、図書(図書資料)を購入するための発注データは、すでにローカルデータベースに登録されている書誌データやNIIのデータベースの書誌を検索して利用したり、利用者から受け付けた購入申し込みの情報を利用して作成するようにしてもよいし、書誌情報を全て新規に入力して作成することも勿論可能である。いずれにせよ、本発明を適用せずに従来通り、図書の納品時に発注データをそのまま所蔵データの一部として登録するようにすると、ミスが多くなる。
【0061】
図書の発注が行われ、発注した図書が書店等から納品データを伴って届いたとき、本システムにおける発注図書受入処理が実行される。なお、納品データは、納品された図書と同時に届かなくともよく、また、上述したようにFDやCD等の記録媒体に格納されて届かなくてもネットワークを介した伝送によって届けられる形態も採用可能である。
【0062】
まず、納品データ入力手段は、上述したように、図書館員用クライアント装置14の入力装置や通信装置などによって、図書館に納品された図書に関する納品データを入力する手段であり、好ましくはサーバ装置11に搭載された納品データ入力プログラム3によって、図書館員の入力を支援するようにするとよい。
【0063】
形式判定プログラム4は、納品データ入力手段によって入力された納品データが、所蔵データ記憶手段に登録可能なデータ形式(フォーマット等)であるか否かを判定する。すなわち、ここでの判定では、納品データのデータ形式が所定のデータ形式であるか否かを判定するものであり、判定のタイミングは、納品データ登録の前であればいつでもよい。
【0064】
本システムにおいてはさらに、整合性判定プログラム5によって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する。換言すると、整合性判定プログラム5では、納品データと発注データとの整合性をみることとなる。
【0065】
整合性判定プログラム5では、納品データに含まれる発注番号に基づいて、納品データに対応する発注データを検索して抽出し、抽出した発注データとその納品データとの整合性を判定するようにするとよい。但し、発注データ及び納品データが、1つの発注又は1つの発注図書に対し、双方のデータで共通の発注番号を含む規定としておく必要がある。また、ここでの整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよい。」
「【0068】
また、整合性判定プログラム5による整合性チェックの際に、発注データと納品データとの整合性がないと判定された場合には、エラーの内容を、図書館員用クライアント装置14の表示装置等にテキストファイル等によってファイル出力/画面出力するエラー出力プログラムも、同様にサーバ装置11に搭載しておくことが好ましい。そして、図書館員が発注データと納品データとのうちどちらのデータが間違っているかを判断して、誤りを訂正して、訂正後登録を行うことが可能なようなプログラムも、同様にサーバ装置11に搭載しておくことが好ましい。さらに、整合性チェックだけでなく、形式判定プログラム4による形式チェックの結果が否であった場合にも、そのエラー出力プログラムはエラーの内容を、図書館員用クライアント装置14に同様に出力するようにしておくとよい。」
「【0070】
従来、受入の際、単に予め記憶した発注データを所蔵データの一部としてそのまま登録していたので、意図しないデータが登録されることがあったが、本システムによれば、書店からの納品データを登録の対象とし、さらにそれに対応する発注データと登録前に照合することで、より正確なデータを所蔵データの一部として登録することが可能となる。」
「【0083】
ステップS3におけるチェックの処理例の詳細を図6及び図7に基づいて説明する。
チェックが開始されると、まず、形式判定プログラムが、書店データの形式が指定された形式と合っているか調べる(ステップS11)。ここでは、(a)書店データが所定のフォーマットであること、(b)項目(フィールド)の型が目録DB13におけるデータベースの型と合うこと、などによって、書店データの形式が指定された形式と合っていると判定する。ステップS11で合っていないと判定された場合には(ステップS12でNO)、エラー出力プログラムが、エラー内容を表示し処理を終了する(ステップS13)。このとき、書店データをそのまま登録することはできないので、手入力するなど行って登録することとなる。また、ここでの表示は、図7のエラーと警告の項目の一覧表Hに従うものとし、(a)に対しては「書店データは指定されたフォーマットではありません。」と表示され、(b)に対しては「○○(ｘｘｘｘｘｘ)はデータベースの型と異なります。」と表示される。複数の書店データに対応する処理であっても、指定されたデータの形式と合わないデータがあれば、そこまでのデータを一覧に表示し、エラーメッセージを表示するようにするとよい。このことは以下のエラー表示や警告表示の際も同様である。
【0084】
ステップS11で合っていると判定された場合には(ステップS12で YES)、整合性判定プログラムが、ステップS14以降の処理、すなわち指定されたデータの形式に基づき、1件ずつデータの解析を行う。このデータの解析には、図7のエラーと警告の項目の一覧表Hにおける「原因」に該当するかを判定していくことで行う。但し、データの形式が合わないものはステップS12でNOとなり、既にはじかれている。
【0085】
ステップS14では、整合性判定プログラムが、書店データ中の指定された項目をキーにして発注データの検索を行なう。すなわち、指定された検索キー(例えば 発注番号)を元に該当する発注データを検索する。そして、そのような該当する発注データが存在するか否かを判定し(ステップS15)、存在しなければ、エラー出力プログラムが、エラー内容「○○に一致する発注データが存在しません。(○○:ｘｘｘｘｘｘｘ)」を表示して処理を終了する(ステップS16)。このとき、書店データをそのまま登録することはできないので、手入力など行って登録することとなる。存在していれば、ステップS17へと進む。
【0086】
ステップS17では、整合性判定プログラムが必須指定の項目の値を調べる。そして、整合性判定プログラムが、必須指定の項目の値が存在するか否か(必須項目が空値であるか)を判定し(ステップS18)、存在しなければエラー出力プログラムがエラー内容「必須項目○○の値が空です。」を表示し(ステップS19)、ステップS20へ進む。このとき、書店データをそのまま登録することはできないので、手入力で修正するなど行って登録することとなる(以下の場合も、エラー/警告表示が出力される場合には同様)。存在していればそのままステップS20へ進む。
【0087】
ステップS20では、整合性判定プログラムが、書店データがローカルに登録できるデータであるかどうか調べる。ここでは、(c)状態が発注中であること、(d)購入冊数を超えていないこと、(e)発注先が同じであること、(f)MARCID(書店側で設定している本につける番号)が合うこと、などによって、登録可能なデータとする。但し、(f)のMARICIDによる比較は、オンラインでの書店データのやり取りの場合でなく、記録媒体による送付でのやり取りの場合には、このデータは登録には使わないで済むので、行わないでよい。
【0088】
そして、整合性判定プログラムが登録できるか否かを判定し(ステップS21)、登録不可能なものであればエラー出力プログラムがエラー内容を表示し(ステップS22)、ステップS23へ進む。登録可能なものであれば、そのままステップS23へ進む。ステップS22におけるエラー表示としては、(c)の比較に対しては、「状態が○○のデータは受け入れできません。」とエラー表示し、(d)の比較に対しては、「発注データの冊数(ｘ)を超えています。」とエラー表示し、(e)の比較に対しては、「書店データの発注先(ｘｘｘｘｘｘ)と発注データの発注先(ｘｘｘｘｘｘ)が一致しません。」とエラー表示し、(f)の比較に対しては、「書店データのMARCID(ｘｘｘｘｘｘ)と発注データのMARCID(ｘｘｘｘｘｘ)が一致しません。」とエラー表示する。
【0089】
ステップS23では、整合性判定プログラムが発注データと書店データを比較する。そして、整合性判定プログラムが、発注データと書店データの値が合っているか否かを判定する(ステップS24)。ステップS24で合っていないと判定された場合、エラー出力プログラムが警告内容「書店データの○○(ｘｘｘｘｘｘ)と発注データの○○(ｘｘｘｘｘｘ)が一致しません。」を表示し(ステップS25)、ステップS26へ進む。ステップS24で合っていると判定された場合には、そのままステップS26へ進む。このように、書店データの各項目の値と発注データの該当する項目の値を比較し、違うときは結果欄を警告にし、理由欄に項目と状況を表示する。」
「【0091】
ここで、「データが発注番号、発注先、書名という順番であること」、且つ、「指定された形式が「,(カンマ)」区切り」であること」、が条件であった場合、上述のごときデータチェックによって、エラーになるデータは、「12345:○○書店:Windｏｗｓ(R)入門」といったものである。さらに、「必須指定の項目が発注先であること」が条件として加わった場合、「12345,,Windｏｗｓ(R)入門」といったデータもエラーとなる。」

(2)引用発明
したがって、引用文献1には、以下の発明(以下「引用発明」という。)が記載されている。
「図書館において発注した図書の受入に関する業務を支援するための発注図書受入システムであって、
所蔵データ記憶手段,発注データ記憶手段,納品データ入力手段,形式判定手段,整合性判定手段,納品データ登録手段を備え、
発注図書受入プログラムは、これら各手段(形式判定手段,整合性判定手段,納品データ登録手段)としてサーバコンピュータを機能させるためのプログラムを指し、
事前に図書を発注し、その発注データを発注データ記憶手段に記憶しておくことを前提とし、
図書の発注が行われ、発注した図書が書店等から納品データを伴って届いたとき、本システムにおける発注図書受入処理が実行されるものであって、
納品データは、FDやCD等の記録媒体に格納されて届く形態やネットワークを介した伝送によって届けられる形態が採用可能であり、
納品データ入力手段は、図書館員用クライアント装置の入力装置や通信装置などによって、図書館に納品された図書に関する納品データを入力する手段であり、
整合性判定プログラムによって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定するものであって、
整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよい、
発注図書受入システム。」

(3)引用文献2の記載
引用文献2には、以下の事項が記載されている。
「【0001】
本発明は、複数の発注者と複数の受注者との間で発注および受注を共通に管理することのできる方法、当該方法を実行可能なコンピュータソフトウェアおよび当該コンピュータソフトウェアを記憶した記憶媒体に関し、特に、発注に関して複数の発注者がそれぞれ異なるフォーマットを用い、受注に関して複数の受注者がそれぞれ異なるフォーマットを用いているような場合であっても効率よく、かつ漏れなく対応可能な方法等に関するものである。
【0002】
コンピュータ通信による受発注が普及した今日では、発注者(企業または個人)は、物品またはサービスの発注に際して特定の発注フォーマットを使用して、発注票等を電子的に受注者(企業または個人)に送信することが行われている。当該特定の発注フォーマットを利用することは、発注者の側の関連処理(工程管理、経理処理、税務処理等)上は便宜である。しかし、一般に、発注フォーマットは発注者ごとに異なっている。
【0003】
一方受注者(企業または個人)の側でも、受注に際して特定の受注フォーマットを使用してコンピュータによって関連処理(納期管理、在庫管理、経理処理等)を行っている。受注者の側でも、一般に、受注フォーマットは受注者(企業、個人)ごとに異なっている。
【0004】
同一業種の企業間で異なる発注フォーマットおよび受注フォーマットを統一して効率化を図る動きも無いではないが、一般に発注側からみた受注側企業(つまり、1つの発注企業にとって物品またはサービスを発注する可能性のある相手企業)は極めて他業種にわたり、受注側からみた発注側企業(1つの受注企業が受注する可能性のある相手企業)についても同様であるために、業種間を越えて受発注フォーマットをすべて統一することは困難な状況である。
【0005】
一方、発注者と受注者の間で発注フォーマットで記載された発注情報を受注フォーマットに変換して受注者に送付するサービスも存在しえる。しかし、発注者側の複数の企業または個人が合計M種類のフォーマットを利用しており、受注者側の複数の企業または個人が合計N種類のフォーマットを利用しているとすれば、M×N通りの変換が必要となり、非常に多くの変換を可能にする必要がある。仮にこれらの変換をコンピュータに行わせるものとすれば、コンピュータが変換に要する時間そのものはごく短時間である可能性も有るが、それぞれの変換プログラムにバグは無いか等を確認する作業の負荷は非常に大きい。まして、発注者側と受注者側のデータ変換を行うのが、データ変換のための専門業者であったとすれば、発注者側のフォーマットにも受注者側のフォーマットにも不慣れなために、デバッグ作業の付加は一層大きなものになる。
【0006】
発注側は取引を管理するために特定のパラメータを必要としているが(例えば、発注担当者の社内コード等)、受注者の側に当該パラメータを管理する用意が無い場合、発注情報を発注フォーマットから受注フォーマットに変換した際に当該パラメータは失われ、以後の出荷情報、納品情報には当該パラメータは含まれないことになる。発注者の側としては、納品情報に当該パラメータが含まれていることを予定しているので、納品管理上支障を生じることになる。」
「【0007】
本発明は、従来技術が有する上記の問題を解決することを目的としたものであって、より具体的には、複数の発注者と複数の受注者の間の発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に変換方法のデバッグを容易にする受発注データ変換方法、受発注管理コンピュータソフトウェアおよび記憶媒体を提供することを目的とする。」
「【課題を解決するための手段】
【0009】
上記の目的を達成するために、本発明は、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程と、
発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程を有する受発注データ変換方法を提案する。
【0010】
本明細書に於いて「フォーマット」とは、データの記載形式を指す言葉として用いており、CSV、XML等の言語形式、特定の言語形式の下でのデータ構造等を表す意味で用いる。発注フォーマットは、いわば発注者が用いる発注票の形式に対応する概念である。パラメータとは、例えば、取引番号、商品コード、発注日、発注数量等の項目である。「発注情報」とは、発注の具体的な内容、例えば、取引番号としての値「200803310451」、商品コードとしての値「AB0324」等である。」
「【0023】
図1は、説明を簡略化するために、2つの発注企業と1つの受注企業間での受発注を例にとって本発明の働きを説明するための流れ図である。 発注企業の発注情報(発注データ)にはパラメータA1、B1、CX1が含まれているとする。これに対して、受注企業の受注情報にはA1とB1のみが必要とされている。また、受注企業の出荷情報にはA1とD1が含まれているが、発注企業の納品情報には、パラメータA1、D1、C1が必要である。このような状況では、従来方法によって発注情報を受注情報に変換しただけでは発注情報に含まれていたパラメータC1が受注情報から欠落し、結果的にC1は納品情報にも含まれないことになる。そこで、本発明の場合は、発注フォーマットから受注フォーマットへの変換を行う際にC1を一次保存し、出荷フォーマットから納品フォーマットへの変換を行う際に、保存していたC1を挿入することで納品フォーマットに適合した納品情報を作成する。
【0024】
C1は、発注企業が受発注処理に常に使用するパラメータであってもよいし、特定の期間のみ使用するようなパラメータであってもよい。フォーマット変換を行った後は、フォーマットチェックを行うことが望ましい。」

第5 対比
1.本願発明と引用発明とを対比すると、以下のとおりとなる。
(1)引用発明における「図書館側から発注した図書」は、書店から図書館に納品される商品といえるから、本願発明の「商品」に相当する。

(2)本願発明の「仕入れ情報」、「納品情報」は、本願明細書の発明の詳細な説明を参酌すると、【0012】に「仕入情報は取引商品の仕入れに関する情報であり、ユーザが取引商品を仕入先に発注することにより発生する情報である。仕入情報は例えば、取引商品の仕入日、取引商品の商品名、取引商品の数量、取引商品の単価、および、取引商品の仕入金額に関する項目が含まれる。納品情報は取引商品の納品に関する情報であり、ユーザが発注した取引商品が仕入先から納品されることにより発生する情報である。納品情報は例えば、取引商品の納品日、取引商品の商品名、取引商品の数量、取引商品の単価、および、取引商品の納品金額に関する項目が含まれる。」と記載されているから、それぞれ、「ユーザが取引商品を仕入先に発注することにより発生する情報」、「ユーザが発注した取引商品が仕入先から納品されることにより発生する情報」であるといえる。
一方、引用発明の「発注データ」、「納品データ」は、それぞれ、引用文献1の「発注データは図書館側から発注した図書に関するデータであり」(【0056】)、「書店から図書の納品時に届く納品データ」(【0039】)の記載からみて、「ユーザが取引商品を仕入先に発注することにより発生する情報」、「ユーザが発注した取引商品が仕入先から納品されることにより発生する情報」と相違がなく、引用発明の「発注データ」、「納品データ」は、それぞれ、本願発明の「仕入れ情報」、「納品情報」に相当する。

(3)引用発明では、
「所蔵データ記憶手段,発注データ記憶手段,納品データ入力手段,形式判定手段,整合性判定手段,納品データ登録手段を備え」、
「発注図書受入プログラムは、これら各手段(形式判定手段,整合性判定手段,納品データ登録手段)としてサーバコンピュータを機能させるためのプログラムを指し」、
「整合性判定プログラムによって、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する」
から、引用発明の「整合性判定手段」は、その納品データと発注データ記憶手段に記憶された発注データとを照合し、その納品データに整合する発注データが発注データ記憶手段に存在するか否かを判定する整合性判定プログラムを実行しているサーバコンピュータであるといえる。
そして、引用発明では、整合性の判定は、納品データと発注データとの照合時に、納品データの各項目に対して、発注データの該当する項目と比較して整合性を判定するようにしてもよく、また、(2)で検討したように、引用発明の「発注データ」、「納品データ」は、それぞれ、本願発明の「仕入れ情報」、「納品情報」に相当するから、引用発明の「整合性判定手段」は、本願発明の「商品の仕入情報と前記商品の納品情報とを比較する情報比較部」に相当する。

(4)引用発明の「発注図書受入システム」は、発明の詳細な説明の【0030】に「本発明に係る発注図書受入システムは、図書館における各種情報を管理する業務を支援するための図書館情報管理システムの一部として、或いは図書館における図書の発注及び受入に関する業務を支援するための発注受入システムの一部として、或いはそれらとは独立して構成されるシステムであり、以下に、その詳細を図書館情報管理システムの一部として各実施形態で説明する」と記載されているから、情報管理システムの一部であることを含み、(3)で検討したように、整合性判定手段が、図書(商品)の「発注データ」、「納品データ」を比較し、図書の受注発注を管理しているといえるから、「前記情報比較部は前記納品情報と前記仕入情報とを比較する商品情報管理システム」である点で、本願発明と対応している。
もっとも、引用発明は、「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」ておらず、したがって、前記仕入情報とを比較する納品情報が、本願発明では「前記情報変換部が変換した前記納品情報」であるのに対し、引用発明では、「前記情報変換部が変換した前記納品情報」ではない点で相違する。

2.したがって、本願発明と引用発明との間には、次の一致点、相違点があるといえる。

(一致点)
「商品の仕入情報と前記商品の納品情報とを比較する情報比較部を備え、前記情報比較部は前記納品情報と前記仕入情報とを比較する商品情報管理システム。」

(相違点)
本願発明は「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」、「前記情報比較部は前記情報変換部が変換した前記納品情報と前記仕入情報とを比較する」のに対し、引用発明は「前記納品情報のデータ形式を前記仕入情報のデータ形式に適合させる情報変換部とを備え」ず、また、「前記情報比較部は前記納品情報と前記仕入情報とを比較する」、すなわち、比較する「納品情報」が、「前記情報変換部が変換した前記納品情報」ではない点。

第6 判断
(1)相違点について
引用文献1の発明の詳細な説明には、
「形式判定手段」を備え(【0015】)、
「前記整合性判定手段は、前記形式判定手段により前記納品データが前記所蔵データ記憶手段に登録可能なデータ形式であると判定された場合にのみ、判定を行い」、(【0018】)
「まず、形式判定プログラムが、書店データの形式が指定された形式と合っているか調べる(ステップS11)。ここでは、(a)書店データが所定のフォーマットであること、(b)項目(フィールド)の型が目録DB13におけるデータベースの型と合うこと、などによって、書店データの形式が指定された形式と合っていると判定する。ステップS11で合っていないと判定された場合には(ステップS12でNO)、エラー出力プログラムが、エラー内容を表示し処理を終了する(ステップS13)。このとき、書店データをそのまま登録することはできないので、手入力するなど行って登録すること」(【0083】)
が記載されている。
すなわち、引用文献1に記載された商品情報管理システムでも、納品情報を受け入れるに際して、仕入れ情報と比較して、それぞれのデータフォーマットが異なることまでは想定している。しかしながら、これに対する対処として、わざわざデータ形式の変換までは行わず、異なるフォーマットである場合、整合性の判定を行わず手入力により処理する構成を採用している。
これに対して、引用文献2の【0002】、【0003】の記載を見ると、各社のデータフォーマットが異なることは普通のことであり、【0005】の記載からみて、上記異なるフォーマットに対処するため、各社のデータフォーマットをコンピュータを用いて変換させることは、課題はあるものの従来行われていたことが理解できる。また、引用文献2の【0023】などの記載からみて、引用文献2記載の発明は、上記従来技術の課題を解決して、各社のデータフォーマットをコンピュータを用いて変換し、他社でも利用可能とすることであるといえる。
してみると、引用文献1ではデータフォーマットの相違について想定はしているものの、そのフォーマット変換を行わせることは行っていないところ、引用文献2の記載を見ると、発注する側が受注者に送信する発注データのフォーマットと、受注する側が送信する納品データのフォーマットとが異なることは普通に想定されることであって、これらのフォーマットを変換して互いに利用可能とすることは本願出願前よく知られたことであるといえるから、上記想定されるフォーマットの相違に対する対処として、引用発明に対して引用文献2記載の技術を転用し、本願発明の構成とすることは当業者が容易になしえたことといえる。

(2)効果について
本願発明の奏する作用効果は、引用発明及び引用文献2に記載された技術の奏する作用効果から予測される範囲内のものに過ぎず、格別顕著なものということはできない。

(3)請求人の主張について
請求人は、審判請求書の「3.本願発明が特許されるべき理由」において「引用文献1の上記記載から把握できますように、引用発明1では、納品データと発注データとが一致した場合、納品データが所蔵データとして登録され、以降は所蔵データに登録されている納品データを利用して図書の管理が実施されます。一方、納品データのデータ形式が指定された形式と異なるとき、田川審査官が指摘するように、例えば、引用文献2に記載の受発注データ変換方法(以下では、「引用発明2」という)を適用して納品データを変換した場合、納品データの誤変換のリスクが存在します。例えば、図書Aの発注数が3冊である場合、納品元から送られる納品データ(以下では、「元の納品データ」という)に含まれる図書Aの納品数が2冊であり、実際に納品された図書Aの数も2冊であるとします。元の納品データのデータ形式が発注データのデータ形式と異なる場合に元の納品データのデータ形式を変換した結果、納品数が誤って3冊と変換された場合、変換された納品データと発注データとが一致したものと判定されます。このため、実際に納品された図書Aの数が2冊であるにも関わらず、納品された図書Aが3冊であるとする誤った納品データが所蔵データとして登録されます。このように、実際には誤りを含む元の納品データが正しい納品データであると誤変換された場合、誤った納品データが所蔵データとして登録されます。換言すれば、引用文献1の段落0039に記載されていますように、「所蔵データが意図していないデータで登録されてしまう」ことになります。このような納品データの誤変換のリスクが存在する以上、引用発明1のように、所蔵データに登録する対象である元の納品データのデータ形式を引用発明2を適用して変換しようと当業者が試みることはありません。このため、当業者が引用文献1、2を把握していたとしましても、その結果から本件発明1、および、これに関連する請求項2?5に係る発明(以下では、それぞれ「本件発明2?5」という)が容易に導きだされることはありません。このため、本件発明1?5は進歩性を有しています。」と主張する。
しかしながら、引用文献1の商品情報管理システムでは、整合性判定プログラムが、発注データと書店データの該当する項目の値を比較し、違うときは結果欄を警告にし、理由欄に項目と状況を表示する構成が開示されており、比較する項目の値として購入冊数も例示されている。
また、引用文献2に開示された受発注データ変換の構成においても、変換されるのは受発注データのフォーマットであって、受発注データの各項目の値ではない。
そうすると、引用発明に引用文献2の技術を適用しても、発注データに記録された図書の発注数が3冊であるにも関わらず、納品データに含まれる当該図書の納品数が2冊である場合には、整合性判定プログラムにより警告表示がなされるものであって、データ形式を変換した結果納品数を3冊と変換することはない。
したがって、「実際に納品された図書Aの数が2冊であるにも関わらず、納品された図書Aが3冊であるとする誤った納品データが所蔵データとして登録され」るとの主張は採用することができない。また、当該主張を前提とする「このような納品データの誤変換のリスクが存在する以上、引用発明1のように、所蔵データに登録する対象である元の納品データのデータ形式を引用発明2を適用して変換しようと当業者が試みることはありません。」なる主張についても採用することができない。

第7 むすび
以上のとおり、本願発明は、引用文献1、2に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。
したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。
よって、結論のとおり審決する。

 
審理終結日 2020-08-19 
結審通知日 2020-08-25 
審決日 2020-09-10 
出願番号 特願2018-74953(P2018-74953)
審決分類 P 1 8・ 121- Z (G06Q)
最終処分 不成立  
前審関与審査官 田川 泰宏  
特許庁審判長 佐藤 聡史
特許庁審判官 岡 裕之
渡邊 聡
発明の名称 商品情報管理システム  
代理人 恩田 誠  
代理人 恩田 博宣  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ