【事件の表示】
　特願２０００−３７９０６０「建築設備資材に係る商品の流通システム」拒絶査定不服審判事件〔平成１４年　６月２８日出願公開、特開２００２−１８３５５８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続きの経緯
　
　本願は，平成１２年１２月１３日の出願であって， 平成１７年１１月１８日付けで拒絶理由通知が通知され，平成１８年１月２０日に意見書と手続補正書が提出され，同年９月２５日付けで拒絶査定がされたところ，同年１１月２日に拒絶査定に対する審判が請求されるとともに，同年１１月２９日に手続補正書が提出され，これに対して当審により，平成２１年７月１７日付けで，当該平成１８年１１月２９日付けの手続補正に対する補正却下の決定がされるとともに拒絶理由通知が通知され，これに対して平成２１年９月１１日に意見書と手続補正書が提出されたものである。
　
第２　本願の特許請求の範囲
　
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２１年９月１１日付けの手続補正書により補正された明細書及び図面の記載内容からみて以下のとおりのものである。 
 　
「建築設備資材に係る商品を製造販売するメーカーが管理するサーバの情報通信手段と、メーカーから購入する商品を使用して工事を行う複数の現場の事業所に設置される情報通信手段と、それら事業所を管理する本部に設置される情報通信手段とが通信回線を介して情報通信可能とされ、
　前記サーバには、事業所からの商品の注文のために商品情報を提供する情報提供手段と、メーカーが商品販売を承認した本部及び事業所に対して付与した識別コードを記憶管理する識別コード管理手段と、事業所側からの商品の注文情報に含まれる前記識別コードと前記識別コード管理手段に予め記憶された識別コードとを照合して一致又は不一致を判別する判別手段と、事業所からの商品の注文情報を本部の情報通信手段に通知する通知手段とを備え、
　事業所の情報通信手段から商品の注文情報が送信されると、前記サーバにおいて、前記注文情報に含まれる識別コードを判別手段により照合し、同事業所がメーカーに承認されたものであると判別された場合に、
　前記サーバは、メーカー側へ前記注文情報に基づく商品を前記注文情報に含まれる納入先情報に従って直接納入する旨の情報を送信し、本部の情報通信手段へ前記注文情報を通知するとともに事業所からの商品の注文情報に基づく商品納入手続きが完了したことを通知して、前記商品の代金決済する旨の情報を送信するように構成した建築設備資材に係る商品の流通システム。」
　
第３　引用刊行物について
　
１　引用刊行物
　
引用例１　特開２０００−１３２５９６号公報（平成１２年５月１２日出願公開）
引用例２　「三菱オフィスサーバシステム　Ｍ−ＬＩＮＫＡＧＥ　ＭＥＬＣＯＭ８０　ＳＴＲＡＴＥＧＩＣ　ＳＡシリーズ　ＳＡ−Ｈ３システム説明書（発注情報管理システム），三菱電機株式会社　コンピュータ製作所，第１版，ｐ．１−１００」（１９９３年９月２０日発行）
引用例３　特開２０００−２４２７２１号公報（平成１２年９月８日出願公開）
　
２　引用例１の記載内容と引用発明
　
（１）引用例１には，図とともに，次の記載がある。なお，下線は，当審で付加したものである。
　
（ア）「【００４０】【発明の実施の形態】図１は、本発明の一実施形態にかかる電子商取引システムの全体構成を示す。
【００４１】図１において、
オフィシャルサプライネットセンタ（以下、ＯＳＮセンタという）１は、コンピュータネットワークを利用して企業等に対し
各種商品のオンライン購買サービスを提供するための施設である。このＯＳＮセンタ１には、複数の商品提供企業（サプライヤ）３Ａ，３Ｂ，…と、多数の調達側企業（以下、ユーザ企業という）５，７，…と、
インターネット１１を介して（サプライヤによってはＶＡＮ１３を介して）常時または随時に接続されるようになっている。
 【００４２】ＯＳＮセンタ１にはＬＡＮ２１が構築され、このＬＡＮ２１上に、受発注や支払請求の業務を行なう受発注センタサーバ２５、商品データベース３５を管理する商品データベースサーバ２７、商品の画像ファイル３７を管理するＷＷＷサーバ２９、及び外部のネットワーク１１，１３と接続するゲートウェイ２３などが存在する。受発注センタサーバ２５は、受発注データ３１や支払請求データ３３を管理している。商品データベース３５には、全てのサプライヤの全商品の名称、識別符号、価格、サプライヤ名、説明など、ユーザ企業が商品の選定を行うために必要な情報及びＯＳＮセンタ１が商品を受注するために必要な情報が登録されている。
【００４３】各サプライヤ３Ａ，３Ｂ，…は、それぞれ独自の受発注システム４１Ａ，４１Ｂ，…や、商品データベースシステム４３Ａ，４３Ｂ，…を有している。商品データベースシステム４３Ａ，４３Ｂ，…は、それぞれのサプライヤが提供する商品の名称、識別符号、価格、等が登録された商品マスタデータベース４５Ａ，４５Ｂ，…、及びそれらの商品の画像ファイル４７Ａ，４７Ｂ，…などを有している。すべてのサプライヤ３Ａ，３Ｂ…の商品マスタデータベース４５Ａ，４５Ｂ，…及び商品画像ファイル４７Ａ，４７Ｂ，…の更新内容は、定期的（例えば毎日早朝）にＯＳＮセンタ１に送られて、ＯＳＮセンタ１内の商品データベース３１及び画像ファイル３３に反映される。」
　
 （イ）「【００４６】図２は、ＯＳＮセンタ１が行う処理８１〜１１９を示す。なお、ユーザサービスを行う処理（図２中でユーザ企業５、７と矢印で結ばれている処理）は、
ユーザ端末
【００４７】
ユーザ情報管理８１は、ユーザ企業５、７の属性情報（名称、所在地、社内の組織や部門や担当などの情報、後述する各種のＩＤなど）を、ユーザ企業５、７からの入力でユーザ情報データベース（図示せず）に登録したり更新したりする処理である
　
（ウ）「【００７７】このようにユーザの職務権限に応じて利用できる業務を分ける必要性から、ＯＳＮセンタ１及びイントラサーバ６３はユーザ情報データベース上で、図４に示すように企業の組織構成を定義し、業務権限を識別するための各種ＩＤを設定している。そして、図５に示すように、各ＩＤに応じて利用できる業務範囲を制限している。
【００７８】すなわち、図４に示すように、１つの企業１６１の下に、請求書を送付する単位としての１つ以上の組織（例えば、支社や事業部など）１６３Ａ，１６３Ｂ，…を定義する。各組織の下に１つ以上の部門１６５Ａ，１６５Ｂ，…を定義し、各部門の下に１つ以上の担当１６７Ａ，１６７Ｂ，…を定義する。各担当には一人以上のユーザ１６９、１７１、１７３、…が所属する。そして、企業１６１に対して、その企業全体のシステム管理者としての権限を表す総合管理者ＩＤを割り当てる。各組織１６３Ａ，１６３Ｂ，…に対しては、
その組織の検収者としての権限を表す検収者ＩＤを割り当てる。
各ユーザＩＤに対して発注者１６９、承認者１７１、支払担当者１７３などの権限を付与する。
【００７９】図５に示すように、ＯＳＮセンタ１及びイントラサーバ６３は、総合管理者ＩＤを入力してログインしたユーザに対しては、図２、３に示したユ−ザ情報管理８１、１３１を利用して当該企業全体に関するユーザ情報の登録や更新を行うことを許可する。担当管理者ＩＤでログインしたユーザに対しては、その担当に関するユーザ情報の登録や更新を行うことだけを許可する。
検収者ＩＤでログインしたユーザに対しては、取引情報（発注データ、出荷状況、請求明細など）照会９７、１０３、１０７、１４７、１４９、１５１と検収１０９、１５３と検収状況紹介１１１の利用を許可する。発注者のユーザＩＤでログインしたユーザに対しては、商品閲覧８７、１３７と仮発注９１、１４１と取引情報照会９７、１０３、１０７、１４７、１４９、１５１の利用を許可する。
【００８０】以上のような
ＩＤによる利用業務の制限は、図２、３に示したユーザ認証８３、１３３の処理で行い、ログイン時にユーザ入力されたＩＤとユーザ情報データベースに登録されているＩＤとを対照して、そのＩＤに付与されている権限に応じてユーザ端末のＷＷＷブラウザ画面に表示する業務メニュー中の選択可能な業務の種類を制限することにより実現する
　
（エ）「【００９２】図９に示すように、
各ユーザ企業５、７内のユーザは、商品閲覧をする場合、ユーザ端末のＷＷＷブラウザから、閲覧したい商品の検索をＯＳＮセンタ１に依頼する（Ｓ２１）。ＯＳＮセンタ１は、要求された商品の情報と画像ファイルを商品データベース３５及び画像ファイル３７から検索してユーザ企業５、７に返し、それにより、その商品の情報と画像がユーザ端末のＷＷＷブラウザ画面に表示される（Ｓ２２）。
【００９３】発注を行う場合、ユーザは、ユーザ端末のＷＷＷブラウザ画面上で商品及び個数などを指定して発注データを作成し、ＯＳＮセンタ１に送信する（Ｓ２３）。ＯＳＮセンタ１は、決済機関９から取得した与信情報２０１を参照して、発注を行ったユーザ企業の与信枠が足りなくないかチェックし（Ｓ２４）、与信枠に問題がなければその発注データを仮の受注データとして受け付ける。その後、図示してないが、ユーザから発注承認を受けると、ＯＳＮセンタ１は、その受注データを正式なものとする。
【００９４】その後、ＯＳＮセンタ１は、正式な受注データを各サプライヤ３別に振り分け、その受注データを基に各サプライヤ３に対し発注を行う（Ｓ２５）。発注データ２０３は保存される。その後、各サプライヤ３は、その発注にかかる商品の出荷案内又は納期回答をＯＳＮセンタ１に送る（Ｓ２６）。また、各サプライヤ３は、月毎に一括請求をＯＳＮセンタ１に送る（Ｓ２９）。ＯＳＮセンタ１は、サプライヤ３からの請求を発注データ２０３に照らして違算チェックを行い、そして、その請求データ２０５を保存する。
【００９５】ユーザは随時に商品の出荷状況や請求明細をＯＳＮセンタ１に問い合わせて確認する（Ｓ２７）。商品が納品されると、ユーザはそれを検収し、検収結果をＯＳＮセンタ１へ送る（Ｓ２８）。また、ユーザは、月毎に取引明細をＯＳＮセンタ１から取得し確認し（Ｓ３１）、支払い通知をＯＳＮセンタ１へ送る（Ｓ３６）。」
　
（オ）「【０１００】各ユーザ企業５、７では、発注担当者が、ＷＷＷブラウザ上で発注データを作成してＨＴＴＰによりＯＳＮセンタ１へ送信する。ＯＳＮセンタ１は、このユーザ発注データを受けると（Ｓ４１）、この発注データに注文番号を付けた上で（Ｓ４２）、ユーザ受注ファイル３０１に保存する（Ｓ４３）。また、ＯＳＮセンタ１は、発注したユーザ企業５、７へ、注文内容確認通知を送り（Ｓ４４）、ユーザ企業５、７からその注文内容の確認結果を受信する（Ｓ４５）。確認結果がキャンセルであれば受注ファイル３０１から当該受注データを削除し（Ｓ４６）、変更であれば変更処理を行って受注ファイル３０１内の当該受注データを変更して再び注文内容確認通知を送り（Ｓ４７）、ＯＫであれば仮受注が成立したものとしてその旨のメッセージをユーザ企業５、７に返す（Ｓ４８）。」
　
（カ）「【０１０４】各ユーザ企業５、７では、発注担当者又は承認権者などが随時に、発注した件について取引情報（出荷状況、請求明細など）の照会リクエストをＷＷＷブラウザからＯＳＮセンタ１に送る。ＯＳＮセンタ１は、そのリクエストに応えてユーザ出荷状況・請求明細ファイル３０３から要求された取引情報を検索し（Ｓ５５）、ユーザ企業５、７へ返信する（Ｓ５６）。それにより、ユーザはＷＷブラウザ画面上で取引情報を見ることができる。」
　
（キ）「【０１１２】
ＯＳＮセンタ１は、サプライヤ３から出荷案内を受信した後、随時に、ユーザ出荷状況・請求明細ファイル３０３からユーザ毎の出荷状況・請求明細のデータを読み出して各ユーザ企業５、７に送る（Ｓ９１）。各ユーザ企業５、７では、検収者がその状況・請求明細のデータを確認し
【０１１３】図１７は、支払い通知受信（図２の参照番号１１５）の流れを示す。
【０１１４】ＯＳＮセンタ１は、毎月、ユーザの締め日にユーザ出荷状況・請求明細ファイル３０３に基づいて取引明細データを作成してユーザ企業５、７に送る（Ｓ１０１）。各ユーザ企業５、７では、支払い担当者がその取引明細データを確認し、そして、自社の支払いファイル３１５内にある当該月の支払いデータを一括してＯＳＮセンタ１へ送る（Ｓ１０２）。ＯＳＮセンタ１は、その一括支払いデータを受けると、それとユーザ請求ファイル３１１内の対応する請求データとを照合して違算チェックを行い（Ｓ１０３）、その結果を違算管理表に登録する（Ｓ１０４）。」
　
（２）以上によれば，引用例１には，
　
「ＯＳＮセンタと、サプライヤと、購入する商品を使用するユーザ企業に設置されるユーザ端末とが、通信ネットワークを介して情報通信可能とされ、
前記ＯＳＮセンタには、ユーザ企業内の発注者のユーザ端末からの依頼に基づいて商品の情報を提供する手段と、発注者及び検収者に割当てられたユーザＩＤを登録するユーザ情報データベースと、ユーザ企業から送信されるユーザＩＤと前記ユーザ情報データベースに登録されているＩＤとを対照する手段と、検収者のユーザ端末に発注データを照会させる手段とを備え、
ＯＳＮセンタが、発注者のログインを受付け、発注者のユーザ端末から発注データを受注データとして受信すると、
ＯＳＮセンタは、検収者のユーザ端末に発注データを照会させるとともに、検収者が確認可能なように、出荷状況、請求明細を読み出して送信し、
前記出荷状況は、サプライヤから出荷案内を受信した後に送信される
電子商取引システム。」（以下「引用発明」という。）
　
 　が記載されている。
　
３　引用例２の記載内容
　引用例２には，図とともに，次の記載がある。なお，下線は，当審で付加したものである。
　
（ク）「１．システムの概要
１． １ 目的と特長
発注情報管理システムは、店舗のグロッサリ定番発注処理を、発注／検収処理を標準化することによって業務を簡素化しミスを防止するとともに、省力化することを目的としています。
また、 「ＳＡ−Ｈ３基本編」の企画情報と連携し、企画発注処理も可能です。
「ＳＡ−Ｈ３発注編」の特徴は次のとおりです。
（１）
店舗のハンデイターミナル（以下ＨＴと省略）から発注できます。
（２）本部でワークステーション（以下ＷＳと省略）から、初回発注、定番発注ができます。
（３）取引先への発注方法は、次の二つの方法があります。
○１（審決注：実際の表記は丸数字の１であるが，都合によりこのように表記する。以下同様。）ＪＣＡオンライン発注
本システムは１次局で、発注先から発呼します。
○２チェーンストア統一伝票による発注
ターンアラウンド（以下ＴＡと省略）伝票の１、２、３、４型に対応しています。タイプ用には対応していません。
（４）店舗のＨＴから、ＴＡ伝票一括（明細行の修正なし）又はＴＡ伝票個別（明細行修正あり）に納品検収ができます。
（５）
本部の複数のＷＳから、伝票単位に納品検収ができます。
（６）発注オーダブックが発行されますので、計画的に発注数量を決められます。
（７）発注先、仕入先、支払先を商品ごとに個々に指定できます。」（第１頁）
　
４　引用例３の記載内容
　
　引用例３には，図とともに，次の記載がある。なお，下線は，当審で付加したものである。
　
（ケ）「【０００８】受発注委託管理システム１は、図１に示すように、ウェブサーバセンター２、情報システムセンター３及び物流システムセンター４からなる。
【０００９】ウェブサーバセンター２は、インターネツト５に接続した中央処理装置６及びプログラム、データ等を格納した記憶装置７を有しており、インターネツト５上にウェブページを開設し、そのウェブページを介して需要者Ａと商品に関する各種情報を交換するようになっている。例えば、ウェブサーバセンター２はウェブページ上で各種商品を紹介する。これを閲覧した需要者Ａは希望商品の在庫状況をウェブページで確認し、ウェブサーバセンター２に希望商品を注文する。又、需要者Ａが出荷、配送状況等をウェブページで確認してくれば、ウェブサーバセンター２は注文商品の出荷、配送状況を案内する。」
　
（コ）「【００３０】又、情報システムセンター３は、物流システムセンター４からの出荷状況に関する情報に基づいて、物流システムセンター４における各種商品の在庫状況に関する情報を蓄積し、
委託者Ｂに出荷状況、在庫状況に関する情報をリアルタイムで提供する。
　
（サ）「【００４７】【発明の効果】本発明の受発注委託管理システムは、
需要者から商品を購入する注文を受け、需要者に商品を配送する指示を出すという受発注処理を、商品の製造者又は販売者等の委託者に代わって実行する
　
第４　対比・判断
　
１　対比 
　
　本願発明と引用発明とを比較すると
　
ア　引用発明のＯＳＮセンタは，受発注センタサーバ，商品データベースサーバ，ＷＷＷサーバとしての機能を備えるから，本願発明の「サーバ」に相当する。
イ　引用発明のユーザ端末は，ＯＳＮセンタと通信を行う機能を有するコンピュータ装置であるから，本願発明の事業所若しくは本部に設置される「情報通信手段」に相当する。
ウ　引用発明のユーザＩＤは，ＯＳＮセンタの利用者に対して割り当てられている識別情報であるから，本願発明の「識別コード」に相当する。
エ　引用発明のユーザ情報データベースは，識別情報を登録・管理するデータベースであるから，本願発明の「識別コード管理手段」に相当する。
オ　引用発明における，ユーザ企業から送信されるユーザＩＤとユーザ情報データベースに登録されているＩＤとを対照する処理は，ユーザ企業から送信されるユーザＩＤが正当なものかを判断する処理であるから，本願発明の「発注者からの前記識別コードと前記識別コード管理手段に予め記憶された識別コードとを照合して一致又は不一致を判別する」処理に相当する。
カ　引用発明の発注データは，商品を注文するための情報であるから，本願発明の「注文情報」に相当する。
キ　検収者のユーザ端末に発注データを照会させる機能は，発注データを検収者のユーザ端末に送信するための機能であるから，本願発明の「通知手段」に相当する。
ク　引用発明において，ＯＳＮセンタが，発注者のログインを受付けることは，本願発明の「識別コードを判別手段により照合し」，発注者がＯＳＮセンタに「承認されたものであると判断」されたことに相当する。
ケ　引用発明の請求明細データは，本願発明の「商品の代金決済する旨の情報」に相当する。
コ　引用発明の出荷状況は，サプライヤが発注した商品を出荷したことを受けて，ＯＳＮセンタが，検収者のユーザ端末に送信するものであるから，かかる出荷情報の送信は，本願発明の「商品の注文情報に基づく商品納入手続きが完了したことを通知」することに相当する。
　
２　一致点と相違点
　
　以上によれば，本願発明と引用発明の一致点と相違点は，次のとおりと認められる。
　
ア　一致点
　
「サーバの情報通信手段と、購入する商品を使用するユーザ企業に設置される情報通信手段とが通信回線を介して情報通信可能とされ、
　前記サーバには、ユーザ企業内の発注者の情報通信手段からの商品の注文ために商品情報を提供する情報提供手段と、オンライン購買サービスを提供する者が商品販売を承認した発注者及び検収者に付与した識別コードを記憶管理する識別コード管理手段と、発注者からの前記識別コードと前記識別コード管理手段に予め記憶された識別コードとを照合して一致又は不一致を判別する判別手段と、発注者による商品の注文情報を検収者の情報通信手段に通知する通知手段とを備え、
　前記サーバにおいて、発注者の情報通信手段から送信された識別コードを判別手段により照合し、発注者がサーバに承認されたものであると判断された場合に、発注者から商品の注文情報を受信し、
　前記サーバは、検収者のユーザ端末へ注文情報を通知するとともに発注者からの商品の注文情報に基づく商品納入手続きが完了したことを通知して、前記商品の代金決済をする旨の情報を送信するように構成した商品の流通システム。」
　
イ　相違点
　
［相違点１］　本願発明では，販売の対象となる商品が「建築設備資材に係る商品」であるが，引用発明では，それが明らかでない点。
　
［相違点２］　本願発明では，サーバの管理主体が「商品を製造販売するメーカー」であるが，引用発明では，ＯＳＮセンタの管理主体が，商品の販売のみならず製造を行う者であるのかが，明らかでない点。
　
［相違点３］　本願発明では，注文情報を送信する情報通信手段が「複数の現場の事業所に設置され」，注文情報と商品の代金決済する旨の情報が送信される情報通信手段が「それら事業所を管理する本部に設置され」ているのに対し，引用発明では，発注データ（注文情報）を送信する発注者のユーザ端末と，発注データ（注文情報），出荷状況（発注者からの商品の注文情報に基づく商品納入手続きが完了したこと）及び請求明細データ（商品の代金決済する旨の情報）が送信される検収者のユーザ端末が，ユーザ企業内のどこに設置されているのかが，明らかでない点。
　
［相違点４］　本願発明では，識別コードが，「本部及び事業所に対して付与」されているが，引用発明では，発注者及び検収者に対して付与されている点。
　
［相違点５］　本願発明では，事業所の情報通信手段からサーバに送信される識別コードが，「注文情報に含まれる」形で送信されるのに対し，引用発明では，ユーザＩＤ（識別コード）が，注文データ（注文情報）の送信に先立って送信される点。
　
［相違点６］　本願発明では，注文情報を受信すると，サーバが「メーカー側へ前記注文情報に基づく商品を前記注文情報に含まれる納入先情報に従って直接納入する旨の情報を送信」するのに対し，引用発明では，それが明らかでない点。
　
３　判断
　
ア　相違点１について
　
　販売の対象となる商品をどのようなものにするかは，当業者が必要に応じて適宜選択し得ることであるから，これを「建築設備資材に係る商品」とし，相違点１にかかる構成とすることは，当業者が適宜なし得たことといえる。
　
 イ　相違点２について
　
　商品の販売者が商品の製造を行うことも周知の販売・製造形態であるから，引用発明において，ＯＳＮセンタの管理者がサプライヤを兼ねるようにし，サーバの管理主体を「商品を製造販売するメーカー」として相違点２にかかる構成とすることは，当業者が必要に応じて適宜なし得たことといえる。 
　
ウ　相違点３について
　
　前記第３，３に見るように，引用例２には，商品の発注を，現場である店舗のハンディターミナルから行い，商品の検収を，店舗を管理する本部のワークステーションで行うという技術的事項が記載されている。また，引用例２では，現場である店舗が，複数存在しているのは，自明である。
　そうすると，引用発明において，引用例２に記載のかかる技術的事項を適用し，発注者のユーザ端末を，「複数の現場の事業所に設置され」るものとするとともに，検収者のユーザ端末を「それら事業所を管理する本部に設置され」るものとし，相違点３にかかる構成とすることは，当業者が適宜なし得たことといえる。
　
エ　相違点４について
　
　ユーザＩＤを組織に対応して発行するか，人に対して発行するかは，当業者が必要に応じて適宜取り決められる事項といえる。
　そうすると，引用発明において，ユーザＩＤを組織に対応して発行するようにし，ユーザＩＤを，組織である「本部及び事業所に対して付与」して相違点４にかかる構成とすることは，当業者が適宜なし得たことといえる。
　
オ　相違点５について
　
　電子商取引システムにおいて，サーバに注文者を識別させるにあたり，送信される注文情報に注文者の識別子を含ませるようにすることは，本願の出願日前に周知の技術的事項であったといえる（例えば，特開平１０−２２２５７４号公報（段落【００１０】））。
　そうすると，引用発明において，ユーザＩＤを「注文情報に含まれる」形で送信するようにし，相違点５にかかる構成とすることは，当業者が適宜なし得たことといえる。
　
カ　相違点６について
　
　前記第３，４に見るように，引用例３には，電子商取引システムにおいて，製造者・販売者に対して出荷状況を提供する技術が記載されている。ここで，出荷情報とは，出荷先に商品を納入する旨の情報である。
　また，注文情報に配送先情報（本願発明の「納品先情報」に相当。）を含ませ，配送先情報にて示される配送先に直接商品を配送させることは，本願の出願日前に周知の技術的事項であったといえる（例えば，特開平１０−２２２５７４号公報（段落【００１０】））。
　そうすると，引用発明において，相違点６にかかる構成を採用することは，当業者が適宜なし得たことといえる。
　
４　まとめ
　
　以上のとおり，本願発明は，引用発明，引用例２，３に記載された技術的事項及び周知の技術的事項から，当業者が容易に想到し得たものである。
　
第５　本願発明の効果について
　
　審判請求人は，平成２１年９月１１日付け提出の意見書において，以下の主張を行っている。
　
「即ち、本願発明は、工事現場で使用される建築設備資材に係る商品流通の迅速化を図ることができるというものであります。特に、サーバは、本部の情報通信手段へ工事を行う複数の現場に設置される各事業所からの商品の注文情報を通知するとともに当該注文情報に基づく商品納入手続きが完了したことを通知して、商品の代金決済する旨の情報を送信しているため、本部は各事業所からメーカーへ商品の注文があったことや各事業所への商品納入状況を即座に認識することができます。このことから本部では、各事業所へ直接出向いたり問い合わせたりすることなく、各事業所における発注状況及び工事進捗状況を的確に把握することができるというメリットを有しています。」（第２頁第１６−２３行）
　
　そこで，審判請求人のかかる主張について検討する。
　
　引用発明も，検収者のユーザ端末に発注データを照会させるとともに，検収者が確認可能なように，出荷状況，請求明細を読み出して送信するものであり，検収者が発注者に問い合わせをすることなく，発注者における発注状況を的確に把握することを可能にするものであるから，かかる点において，引用発明と本願発明とは，異なるものではない。
　また，本願の請求項には，本部の情報通信手段に「注文情報」，「事業所からの商品の注文情報に基づく商品納入手続きが完了したこと」及び「商品の代金決済する旨の情報」を通知することは記載されているものの，工事進捗状況を通知することについては，なんら記載されておらず，本願発明が「各事業所における工事進捗状況を的確に把握することができる」というメリットを有するという審判請求人の主張は，請求項の記載に基づくものであるとは認められない。
　
　よって，審判請求人の主張を格別のものとは，認めることができない。
　
　そうすると，本願発明の効果も，引用発明，引用例２，３に記載された技術的事項及び周知の技術的事項から，当業者が予測できる範囲のものである。
　
第６　結論
　
　以上の次第で，本願発明は，引用発明，引用例２，３に記載された技術的事項及び周知の技術的事項に基づいて，当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により，特許を受けることができない。
　
　よって，結論のとおり審決する。