【事件の表示】
　特願２００１−３８７７９８「商品受注システム、プログラム、及び記録媒体」拒絶査定不服審判事件〔平成１５年　７月　４日出願公開、特開２００３−１８７１５２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯　　 
　
　本願は、平成１３年１２月２０日に出願された特許出願であって、平成１７年１０月１９日付けで拒絶理由通知が通知され、これに対して同年１２月１２日付けで手続補正書が提出され、平成１８年　５月２６日付けで拒絶査定され、これに対して同年６月２８日付けで拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正書が提出されたものである。
　
２．補正について
　
（１）補正の内容
　
　平成１８年　６月２８日付け手続補正でした特許請求の範囲についてなされた補正（以下、「本件補正」という。）は、以下のとおりである。
　
　本件補正により、特許請求の範囲は、
　
「【請求項１】
　
ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、
　
ユーザと販売業者とで予め該ユーザ用に決定した商品及びサポートの対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、
　
前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、
　
該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報及びサポート依頼情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、
　
前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して、前記データベースを更新する対価更新手段と、
　
前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段と、
　
商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段と、
　
該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段と、
　
該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段と、
　
前記購入依頼情報と共に前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と、を有し、
　
前記商品配送指示手段は、前記配送日決定手段によって決定された配送日に商品を配送するよう指示すること
　
を特徴とする商品受注システム。
　
【請求項２】
　
前記受注処理手段における受注処理の後、前記データベースに格納された前記対価情報と、前記ユーザ個人情報とに基づいて、前記購入依頼情報に含まれる商品及びサポートの代金の情報を、前記ユーザの前記コンピュータにネットワークを介して送信することで請求する代金請求手段を、さらに有すること
　
を特徴とする請求項１に記載の商品受注システム。
　
【請求項３】
　
請求項１又は２に記載の商品受注システムとして機能させるためのプログラム。
　
【請求項４】
　
請求項３に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。」
　
と補正された。
　
（２）補正の適否判断
　
　補正後の請求項１は、補正前の請求項１を引用する請求項３をさらに引用する請求項４に記載の「前記受付手段で前記購入依頼情報」を「前記受付手段で受け付けられた前記購入依頼情報」とする補正を行ったものであり、補正後の請求項２は、補正前の請求項１を引用する請求項２をさらに引用する請求項３をさらに引用する請求項４とする補正を行ったものである。
　なお、補正前の請求項１及び請求項２は削除された。
　
　また、補正後の請求項３及び４は、補正前の請求項５及び６にそれぞれ対応する。
　
　上述した補正前の請求項の対応からみて、本件補正は、請求項１及び請求項２を削除し、上記「前記受付手段で前記購入依頼情報」を「前記受付手段で受け付けられた前記購入依頼情報」の誤記として誤記の訂正を行ったものと認められる。
　
　したがって、本件補正は、特許法第１７条の２第４項第１号及び同項第３号に掲げられた請求項の削除及び誤記の訂正を目的とするものであり、特許法第１７条の２第４項の要件を満たすものである。
　
３．本願の請求項１に係る発明
　
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年　６月２８日付け手続補正書における特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、
　
ユーザと販売業者とで予め該ユーザ用に決定した商品及びサポートの対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、
　
前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、
　
該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報及びサポート依頼情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、
　
前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して、前記データベースを更新する対価更新手段と、
　
前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段と、
　
商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段と、
　
該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段と、
　
該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段と、
　
前記購入依頼情報と共に前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と、を有し、
　
前記商品配送指示手段は、前記配送日決定手段によって決定された配送日に商品を配送するよう指示することを特徴とする商品受注システム。」
　
４．引用文献に記載の発明
　
（引用文献１）
　原査定の拒絶の理由に引用された特開２０００−１３２５９６号公報（以下、「引用文献１」という。）には、
　
　引用文献１に記載の発明が解決しようとする課題に係る記載として、
　
（１ａ）「【０００６】（３）　企業間の商取引では、商品の価格は一律ではなく、商品提供業者と各調達側企業間でネゴシアブルに個別に設定されることが少なくない。しかし、従来のシステムでは、商品価格は一律であり、企業毎にカスタマイズすることはできない。」
　
が記載され、
　
また引用文献１に記載の発明の観点として、
　
（１ｂ）「【００２１】本発明の第２の観点に従う電子商取引センタは、通信ネットワーク上に存在し、複数の商品サプライヤのコンピュータシステムと通信可能に接続された電子商取引用のコンピュータシステムであって、複数の商品サプライヤのコンピュータシステムから取得した商品情報を保持した商品データベースと、この商品データベース内の情報に基づく商品閲覧サービスを通信ネットワークにオンラインで提供する商品閲覧処理部と、商品の受注サービスを通信ネットワークにオンラインで提供する受注処理部と、受注サービスで受けた注文に基づいて複数のサプライヤに発注を行う発注処理部とを備える。
　
・・・
　
【００２７】本発明の第５の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部と、この仮発注データについて、発注承認の通知を通信ネットワークを通じてオンラインで企業内のユーザから受けて、その仮発注データを正発注データにする発注承認処理部とを備える。
　
・・・
　
【００３１】本発明の第７の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受け保存する受注処理部と、発注データに基づいて商品サプライヤに商品を発注する発注処理部と、商品サプライヤから出荷情報を受けて保存する出荷情報受信部と、商品サプライヤから請求データを受けて保存する請求受信部と、企業内のユーザからの照会リクエストに応えて、保存してある発注データ、出荷情報及び請求データの中からリクエストされた情報を検索して通信ネットワークを通じてオンラインで企業内のユーザに提供する取引情報照会部とを備える。
　
・・・
　
【００３３】本発明の第８の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受け保存する受注処理部と、企業の与信情報を保持し、発注データ毎に与信情報に基づき企業の与信枠をチェックする与信処理部とを備える。受注処理部は、与信枠のチェック結果に応じて、ユーザからの発注を受諾するか拒否するかを決定する」
　
が記載され、
　
また引用文献１に記載の発明の実施例に係る一連の記載として、
　
（１ｃ）「【００４０】
【発明の実施の形態】図１は、本発明の一実施形態にかかる電子商取引システムの全体構成を示す。
図１において、オフィシャルサプライネットセンタ（以下、ＯＳＮセンタという）１は、コンピュータネットワークを利用して企業等に対し事務用品等の各種商品のオンライン購買サービスを提供するための施設である。このＯＳＮセンタ１には、複数の商品提供企業（サプライヤ）３Ａ，３Ｂ，…と、多数の調達側企業（以下、ユーザ企業という）５，７，…と、さらに信販会社のような決済機関９とが、インターネット１１を介して（サプライヤによってはＶＡＮ１３を介して）常時または随時に接続されるようになっている。・・・提供する
　
・・・。
　
【００４２】ＯＳＮセンタ１にはＬＡＮ２１が構築され、このＬＡＮ２１上に、受発注や支払請求の業務を行なう受発注センタサーバ２５、商品データベース３５を管理する商品データベースサーバ２７、商品の画像ファイル３７を管理するＷＷＷサーバ２９、及び外部のネットワーク１１，１３と接続するゲートウェイ２３などが存在する。受発注センタサーバ２５は、受発注データ３１や支払請求データ３３を管理している。商品データベース３５には、全てのサプライヤの全商品の名称、識別符号、価格、サプライヤ名、説明など、ユーザ企業が商品の選定を行うために必要な情報及びＯＳＮセンタ１が商品を受注するために必要な情報が登録されている。
　
【００４３】各サプライヤ３Ａ，３Ｂ，…は、それぞれ独自の受発注システム４１Ａ，４１Ｂ，…や、商品データベースシステム４３Ａ，４３Ｂ，…を有している。商品データベースシステム４３Ａ，４３Ｂ，…は、それぞれのサプライヤが提供する商品の名称、識別符号、価格、等が登録された商品マスタデータベース４５Ａ，４５Ｂ，…、及びそれらの商品の画像ファイル４７Ａ，４７Ｂ，…などを有している。すべてのサプライヤ３Ａ，３Ｂ…の商品マスタデータベース４５Ａ，４５Ｂ，…及び商品画像ファイル４７Ａ，４７Ｂ，…の更新内容は、定期的（例えば毎日早朝）にＯＳＮセンタ１に送られて、ＯＳＮセンタ１内の商品データベース３１及び画像ファイル３３に反映される。
　
【００４４】ユーザ企業５、７は、イントラネットを社内に有しているもの（イントラネットユーザ企業）７と、有していない企業（インターネットユーザ企業）５とに大別される。・・・などを行なう。」、
　
（１ｄ）「【００４６】図２は、ＯＳＮセンタ１が行う処理８１〜１１９を示す。なお、ユーザサービスを行う処理（図２中でユーザ企業５、７と矢印で結ばれている処理）は、ユーザ端末５１、６５のＷＷＷブラウザ画面を用いて、ユーザ端末操作者（ユーザ）と情報をやり取りするようになっている。
　
・・・
　
【００４９】商品情報管理８５は、サプライヤ３の商品マスタ４５及び画像ファイル４７の更新データを定期的に取得して、ＯＳＮセンタ１内の商品データベース３５及び画像ファイル３７を更新し管理する処理である。・・・代行する。
　
・・・
　
【００５１】受注８９は、ユーザ企業５、７から商品注文を受ける処理であり、これには仮受注９１と発注承認９３の処理が含まれる。仮受注９１は、特にインターネットユーザ企業５から発注データを受信して仮（未承認）の受注データとして保存及び管理する処理である。発注承認９３は、仮受注９１で保存した仮の受注データに対して、インターネットユーザ企業５から発注承認を受信して、これを正式な受注データにして保存する処理である。・・・ことになる。
　
・・・
　
【００５５】出荷状況受信１０１は、サプライヤ３に発注した商品について、サプライヤ３から納品日などを示す出荷案内を受信して保存する処理である。
　
【００５６】出荷状況照会１０３は、出荷状況受信１０１で保存した出荷案内や、未だ出荷されてない残存の発注内容などを、ユーザ企業５、７からの照会要求に応えてユーザ企業５、７に提供する処理である。」
　
（１ｅ）「【００８５】図７は、ＯＳＮセンタ１内の商品データベースサーバ２７がもつ仕切率テーブルを示す。
　
【００８６】図７に示すように、複数のユーザ企業グループと複数の商品価格グループが定義されており、それらのユーザ企業グループと各商品価格グループとの組み合わせの各々に対してそれぞれ１つの仕切率（つまり、基準価格に対する実際の販売価格の比率）が設定されている。・・・各ユーザ企業に対する各商品の販売価格は、その企業が所属する企業グループに対し各商品グループ毎に設定されている仕切率を適用して決定される。
　
【００８７】図８は、この仕切率テーブルを用いて、ＯＳＮセンタ１の商品情報管理８５が各ユーザ企業別の商品価格を決定する動作を示す。
　
【００８８】図８に示すように、図６に示した更新処理でＯＳＮセンタ１内の商品データベース３５を更新したとき、その更新ログを作成して保存し（Ｓ１１）、続いて、その更新ログから価格切替を行う商品コードを検索する（Ｓ１２）。例えば、新規に追加された商品や、既存商品の中で基準価格が変更になった商品などが価格切替え対象の商品である。次に、価格切替え商品について手動設定フラグが設定されているかチェックする（Ｓ１３）。手動設定フラグは、サプライヤ３から受信した商品データベースの更新データに含まれているもので、バーゲン商品のように通常の仕切率の適用が除外される商品に対して設定されている。
　
【００８９】手動設定フラグが設定されていない商品については、図７に示した仕切率テーブル上の当該商品のグループに適用される仕切率を用いて、当該商品の基準価格から、当該商品の各企業グループ毎の販売価格を計算する（Ｓ１４）。・・・（Ｓ１７）。
　
【００９０】・・・なお、インターネットユーザ企業５のユーザはＯＳＮセンタ１に直接ログインして商品閲覧を行うが、その際、ＯＳＮセンタ１は他企業向けの販売価格を除いた当該企業向けの販売価格しかユーザに送らない。」、
　
（１ｆ）「【００９１】図９は、商品閲覧から受発注そして決済までの全体の動作の流れを示す。なお、この図９及び後続の図面は、インターネットユーザ企業５に対する動作（つまり、ＯＳＮセンタ１が全処理を行う動作）を示しており、以下の動作説明もこれに基づいて行う。一方、イントラネットユーザ企業７に対しては、図９におけるステップＳ２１〜Ｓ２４（商品検索、商品閲覧、発注、与信チェック）をイントラサーバ６３が代行し、それ以降はイントラサーバ６３は通信の仲介を行ないＯＳＮセンタ１が実質的な処理を行う。この点を踏まえれば、以下の説明からイントラネットユーザ企業７に対する動作も十分に理解できるはずである。
　
・・・
　
【００９３】発注を行う場合、ユーザは、ユーザ端末のＷＷＷブラウザ画面上で商品及び個数などを指定して発注データを作成し、ＯＳＮセンタ１に送信する（Ｓ２３）。ＯＳＮセンタ１は、決済機関９から取得した与信情報２０１を参照して、発注を行ったユーザ企業の与信枠が足りなくないかチェックし（Ｓ２４）、与信枠に問題がなければその発注データを仮の受注データとして受け付ける。その後、図示してないが、ユーザから発注承認を受けると、ＯＳＮセンタ１は、その受注データを正式なものとする。
　
【００９４】その後、ＯＳＮセンタ１は、正式な受注データを各サプライヤ３別に振り分け、その受注データを基に各サプライヤ３に対し発注を行う（Ｓ２５）。発注データ２０３は保存される。その後、各サプライヤ３は、その発注にかかる商品の出荷案内又は納期回答をＯＳＮセンタ１に送る（Ｓ２６）。また、各サプライヤ３は、月毎に一括請求をＯＳＮセンタ１に送る（Ｓ２９）。ＯＳＮセンタ１は、サプライヤ３からの請求を発注データ２０３に照らして違算チェックを行い、そして、その請求データ２０５を保存する。」、
　
（１ｇ）「【０１００】各ユーザ企業５、７では、発注担当者が、ＷＷＷブラウザ上で発注データを作成してＨＴＴＰによりＯＳＮセンタ１へ送信する。ＯＳＮセンタ１は、このユーザ発注データを受けると（Ｓ４１）、この発注データに注文番号を付けた上で（Ｓ４２）、ユーザ受注ファイル３０１に保存する（Ｓ４３）。また、ＯＳＮセンタ１は、発注したユーザ企業５、７へ、注文内容確認通知を送り（Ｓ４４）、ユーザ企業５、７からその注文内容の確認結果を受信する（Ｓ４５）。確認結果がキャンセルであれば受注ファイル３０１から当該受注データを削除し（Ｓ４６）、変更であれば変更処理を行って受注ファイル３０１内の当該受注データを変更して再び注文内容確認通知を送り（Ｓ４７）、ＯＫであれば仮受注が成立したものとしてその旨のメッセージをユーザ企業５、７に返す（Ｓ４８）。」、
　
（１ｈ）「【０１２２】図２１は、ユーザ端末のＷＷＷブラウザに表示される購入要求書画面の例を示す。
　
【０１２３】この画面４１３には、購入リストに登録された商品名や金額、及びその他の発注に必要な事項が登録されている。送信ボタン４１５をマウスクリックすると、この購入要求書（発注データ）がＯＳＮセンタ１へ送信される。ユーザとしては、１枚の購入要求書で、つまり１回の発注で、複数のサプライヤの種々の商品を纏めて発注できるので楽である。」
　
がそれぞれ記載されている。
　
（ア）上記摘記事項（１ｃ）からみて、「電子商取引システム」の一実施例として「ＯＳＮセンタ」が記載されているものと解することができること、及び、上記摘記事項（１ｈ）における「購入要求書画面」の具体例である引用文献１の図２１の記載からみて、当該「購入要求書画面」に「納入希望日」が含まれていることから、当該「ＯＳＮセンタ」は、当該「購入要求書画面」を受け取るときに、「商品」の「購入要求」に併せて当該「納入希望日」も受け取るものと推認できる。
　
　したがって、上記摘記事項（１ｃ）に記載の「オフィシャルサプライネットセンタ（以下、ＯＳＮセンタという）１は、コンピュータネットワークを利用して企業等に対し事務用品等の各種商品のオンライン購買サービスを提供する・・・ユーザ企業５、７は、イントラネットを社内に有しているもの（イントラネットユーザ企業）７と、有していない企業（インターネットユーザ企業）５とに大別される。」によれば、引用文献１には「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納品希望日を受け取るオンライン購買サービスを提供するＯＳＮセンタ」が記載されているといえる。
　
（イ）上記摘記事項（１ａ）における「商品の価格は一律ではなく、商品提供業者と各調達側企業間でネゴシアブルに個別に設定される」との記載からみて、当該「価格」は、当該「調達側企業」である「インターネットユーザ企業」と当該「商品提供業者」である「サプライヤ」との間で「ネゴシアブルに個別に設定」された「価格」であるものと解することができる。
　
　また引用文献１の図７の記載及び上記摘記事項（１ｅ）における「図７は、ＯＳＮセンタ１内の商品データベースサーバ２７がもつ仕切率テーブルを示す。図７に示すように、複数のユーザ企業グループと複数の商品価格グループが定義されており、それらのユーザ企業グループと各商品価格グループとの組み合わせの各々に対してそれぞれ１つの仕切率（つまり、基準価格に対する実際の販売価格の比率）が設定されている」との記載からみて、当該「仕切率テーブル」の行定義情報は、「インターネットユーザ企業」を上記「複数のユーザ企業グループ」と同種の行定義情報として含むことを読み取ることができるので、上記「仕切率テーブル」は、「仕切率」を、「インターネットユーザ企業」を含む行定義情報と関連付けて、データベースとして格納したものと解することができる。
　
　また上記摘記事項（１ｃ）における「各サプライヤ・・・は・・・商品データベースシステム・・・を有している」、「商品データベースシステム・・・は、それぞれのサプライヤが提供する商品の・・・価格、等が登録された商品マスタデータベース・・・などを有している。」及び「すべてのサプライヤ・・・の商品マスタデータベース・・・の更新内容は・・・ＯＳＮセンタ１内の商品データベース・・・に反映される。」との各記載からみて、上記「価格」が上記「インターネットユーザ企業」と上記「サプライヤ」との間で「ネゴシアブルに個別に設定」されて、当該「商品マスタデータベース」の内容が更新されれば、その「更新内容」は、当該「商品データベース」として格納した上記「仕切率テーブル」の上記「仕切率」に「反映」されるものと解することができる。
　
　したがって、上記摘記事項（１ａ）、上記摘記事項（１ｅ）及び上記摘記事項（１ｃ）を勘案すれば、引用文献１には、「ＯＳＮセンタが、インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率を、インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブルを備える」ことが記載されているといえる。
　
（ウ）上記摘記事項（１ｈ）における「・・・この画面４１３には、購入リストに登録された商品名や金額、及びその他の発注に必要な事項が登録されている。」により説明される引用文献１の図２１の記載からみて、「商品名」及びその「個数」の情報、「納入希望日」の要求、上記「インターネットユーザ企業を含む行定義情報」の具体例である「担当名」及び「名前」、並びに、「金額」である商品の対価は、いずれも当該「発注に必要な事項」として読み取ることができるが、上記摘記事項（１ｆ）における「・・・発注を行う場合、ユーザは、ユーザ端末のＷＷＷブラウザ画面上で商品及び個数などを指定して発注データを作成し・・・」及び上記摘記事項（１ｅ）における「なお、インターネットユーザ企業５のユーザはＯＳＮセンタ１に直接ログインして商品閲覧を行うが、その際、ＯＳＮセンタ１は他企業向けの販売価格を除いた当該企業向けの販売価格しかユーザに送らない。」の両記載からみて、当該「価格」はＯＳＮセンタからインターネットユーザ企業へ送られるものであるから、上記「発注に必要な事項」の内、インターネットユーザ企業が指定して作成した項目は、上記「商品名」及びその「個数」の情報、「納入希望日」の要求、並びに、「インターネットユーザ企業を含む行定義情報」と解することができる。
　
　また上記摘記事項（１ｄ）における「ＯＳＮセンタ１が行う処理８１〜１１９を示す。・・・受注８９は、ユーザ企業５、７から商品注文を受ける処理であり、これには仮受注９１と発注承認９３の処理が含まれる。仮受注９１は、特にインターネットユーザ企業５から発注データを受信して仮（未承認）の受注データとして保存及び管理する処理である。」における当該「仮（未承認）の受注データとして保存及び管理する処理」は、当該「ＯＳＮセンタ」が行う「仮受注」であって、上記摘記事項（１ｂ）における「・・・電子商取引センタは・・・商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部・・・を備える。」との記載からみて、当該企業内のユーザから受けた「仮発注」は、上記インターネットユーザ企業から「発注データ」を受信した仮（未承認）の「受注」の言い換えに過ぎないから、「電子商取引センタ」の実施例である「ＯＳＮセンタ」が備える当該「仮発注処理部」により行われるものと解することができる。
　
　したがって、上記摘記事項（１ｄ）、上記摘記事項（１ｆ）及び上記摘記事項（１ｄ）において摘示したことを踏まえ、上記摘記事項（１ｇ）を勘案すると、引用文献１には「ＯＳＮセンタが、インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮（未承認）の発注データとして保存する仮発注処理部を備える」ことが記載されているといえる。
　
（エ）また上記摘記事項（１ｄ）における「ＯＳＮセンタ１が行う処理８１〜１１９を示す。・・・発注承認９３は、仮受注９１で保存した仮の受注データに対して、インターネットユーザ企業５から発注承認を受信して、これを正式な受注データにして保存する処理である。」における当該「正式な受注データにして保存する処理」は、当該「ＯＳＮセンタ」が行う「発注承認」であって、上記摘記事項（１ｂ）における「・・・電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部と、この仮発注データについて、発注承認の通知を通信ネットワークを通じてオンラインで企業内のユーザから受けて、その仮発注データを正発注データにする発注承認処理部とを備える。」との記載からみて、「電子商取引センタ」の実施例である「ＯＳＮセンタ」が備える当該「仮発注処理部」により行われるものと解することができる。
　
　また上記（ウ）で摘示したように、「発注に必要な事項」には、商品の対価が含まれるものと解することができ、上記摘記事項（１ｅ）を参酌すると、当該商品の対価は、仕切率を適用して決定されるものである。
　
　したがって、上記（ウ）で摘示したことと上記摘記事項（１ｄ）を勘案すれば、引用文献１には「ＯＳＮセンタが、仮発注処理部で保存した発注データに基づいて、データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し、適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部を備える」ことが記載されているといえる。
　
（オ）上記摘記事項（１ｅ）における「ＯＳＮセンタ１内の商品データベースサーバ２７がもつ仕切率テーブルを示す・・・更新処理でＯＳＮセンタ１内の商品データベース３５を更新」及び上記摘記事項（１ｄ）における「ＯＳＮセンタ１が行う処理８１〜１１９を示す・・・商品情報管理８５は・・・ＯＳＮセンタ１内の商品データベース３５及び画像ファイル３７を更新し管理する処理」との記載からみて、「仕切率テーブル」を更新する「更新処理」は、当該「ＯＳＮセンタ」が行う「商品情報管理」であって、上記摘記事項（１ｃ）における「・・・ＯＳＮセンタ１にはＬＡＮ２１が構築され、このＬＡＮ２１上に・・・商品データベース３５を管理する商品データベースサーバ２７・・・が存在する」との記載からみて、当該「商品情報管理」は、当該「ＯＳＮセンタ」に構築されたＬＡＮ上に存在する当該「商品データベースサーバ」により行われるものと解することができる。
　
　また上記（イ）において摘示したように、引用文献１の図７の記載からみて、「仕切率テーブル」の行定義情報において、「インターネットユーザ企業」を「複数のユーザ企業グループ」と同種の行定義情報として表すことを読み取ることができることから、上記「各ユーザ企業別の商品価格」の情報には、インターネットユーザ企業の個別の商品価格の情報も含まれるものと解することができる。
　
　また上記摘記事項（１ｅ）における「この仕切率テーブルを用いて、ＯＳＮセンタ１の商品情報管理８５が各ユーザ企業別の商品価格を決定する動作を示す」との記載からみて、上記「更新処理」により更新される「仕切率テーブル」の内容は、「各ユーザ企業別の商品価格」の情報であることから、インターネットユーザ企業に対し、仕切率テーブルが個別に更新されるものと解することができる。
　
　したがって、上記摘記事項（１ｃ）、上記摘記事項（１ｄ）、上記摘記事項（１ｅ）及び上記（イ）において摘示したことを勘案すると、引用文献１には「ＯＳＮセンタが、インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバを備える」ことが記載されているといえる。
　
（カ）上記摘記事項（１ｄ）における「・・・ＯＳＮセンタ１が行う処理８１〜１１９を示す・・・発注９９は、受注８９で保存した正式な受注データを各サプライヤ３に振り分け、各サプライヤ３に送信する（発注する）処理である。」からみて、当該「各サプライヤ」に「振り分け」て当該「各サプライヤ」に「送信する」処理は、当該「ＯＳＮセンタ」が行う「発注」であって、上記摘記事項（１ｂ）における「電子商取引センタは・・・受注サービスで受けた注文に基づいて複数のサプライヤに発注を行う発注処理部とを備える・・・」との記載からみて、当該「発注」は、該「電子商取引センタ」の実施例である「ＯＳＮセンタ」が備える当該「発注処理部」により行われるものと解することができる。
　
　したがって、上記摘記事項（１ｂ）及び上記摘記事項（１ｄ）を勘案すると、引用文献１には「ＯＳＮセンタが、発注データに含まれる商品の発送を各サプライヤに振り分けて当該各サプライヤに送信する処理である発注を行う発注処理部を備える」ことが記載されているといえる。
　
（キ）上記摘記事項（１ｃ）における「ユーザ企業５、７は、イントラネットを社内に有しているもの（イントラネットユーザ企業）７と、有していない企業（インターネットユーザ企業）５とに大別される」によれば、「ユーザ企業５」は、「インターネットユーザ企業」を差し示すものと解することができる。
　
　また上記摘記事項（１ｄ）における「・・・ＯＳＮセンタ１が行う処理８１〜１１９を示す。ユーザサービスを行う処理（図２中でユーザ企業５、７と矢印で結ばれている処理）・・・出荷状況受信１０１は、サプライヤ３に発注した商品について、サプライヤ３から納品日などを示す出荷案内を受信して保存する処理である。出荷状況照会１０３は、出荷状況受信１０１で保存した出荷案内・・・を、ユーザ企業５、７からの照会要求に応えてユーザ企業５、７に提供する処理である。」との記載における「納品日」を示す「出荷案内」を「ユーザ企業５」からの「照会要求」に応えて当該「ユーザ企業５」に提供する処理は、当該「ＯＳＮセンタ」が行う「出荷状況照会」であって、上記摘記事項（１ｂ）における「・・・電子商取引センタは・・・企業内のユーザからの照会リクエストに応えて、保存してある発注データ、出荷情報及び請求データの中からリクエストされた情報を検索して通信ネットワークを通じてオンラインで企業内のユーザに提供する取引情報照会部とを備える。」との記載からみて、当該「出荷状況照会」は、該「電子商取引センタ」の実施例である「ＯＳＮセンタ」が備える当該「取引情報照会部」により行われるものと解することができる。
　
　したがって、上記摘記事項（１ｂ）、上記摘記事項（１ｃ）及び上記摘記事項（１ｄ）を勘案すると、引用文献１には、「ＯＳＮセンタが、販売業者から商品の出荷案内又は納期回答を送られた後に、企業内のユーザからの照会リクエストに応えて、出荷案内に示される発注データ及び納品日をインターネットユーザ企業に提供する処理を行う取引情報照会部を備える」ことが記載されているといえる。
　
（ク）上記摘記事項（１ａ）における「・・・電子商取引センタは、通信ネットワーク上に存在し、複数の商品サプライヤのコンピュータシステムと通信可能に接続された電子商取引用のコンピュータシステム」からみて、電子商取引センタの実施例であるＯＳＮセンタは、サプライヤのコンピュータシステムと通信可能に接続されたものであると解することができることから、上記摘記事項（ｆ）における「その後、各サプライヤ３は、その発注にかかる商品の出荷案内又は納期回答をＯＳＮセンタ１に送る」との記載によれば、引用文献１には、「ＯＳＮセンタに、サプライヤのコンピュータシステムから発注にかかる商品の出荷案内又は納期回答を送られる」ことが記載されているといえる。
　
　上記（ア）〜（ク）を考慮して、摘記事項（１ａ）〜（１ｈ）の記載を総合すると、引用文献１には、次の発明（以下、「引用文献１発明」という。）が記載されているといえる。
　
「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納品希望日を受け取るオンライン購買サービスを提供するＯＳＮセンタであって、
　
インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率を、インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブルと、
　
インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮（未承認）の発注データとして保存する仮発注処理部と、
　
仮発注処理部で保存した発注データに基づいて、データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し、適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部と、
　
インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバと、
　
発注データに含まれる商品の発送を各サプライヤに振り分けて当該各サプライヤに送信する処理である発注を行う発注処理部と、
　
販売業者から商品の出荷案内又は納期回答を送られた後に、企業内のユーザからの照会リクエストに応えて、出荷案内に示される発注データ及び納品日をインターネットユーザ企業に提供する処理を行う取引情報照会部と
　
を備え、
　
ＯＳＮセンタに、サプライヤのコンピュータシステムから発注にかかる商品の出荷案内又は納期回答を送られる
　
ことを特徴とするＯＳＮセンタ」
　
（引用文献２）
　
　また原査定で引用された特開平１１−２９６６０１号公報（以下、「引用文献２」という。）には、
　
引用文献２に記載の発明の属する技術分野として、
　
（２ａ）「【０００１】【発明の属する技術分野】この発明は、商品を受注すると商品の納期日を計算する納期管理装置及び納期管理方法に関するものである。」
　
が記載され、
　
また引用文献２に記載の発明の実施例の一連の記載として、
　
（２ｂ）「【００２４】
【発明の実施の形態】以下、この発明の実施の一形態を説明する。・・・である。
　
・・・
　
【００２７】次に動作について説明する。まず、受注部１１が、顧客の注文情報（受注日、商品コード、営業所コード、配送センタコード、配送ルートコード、顧客コード）を入力すると、引当・発注部１３が、顧客の注文情報に含まれる商品コードを用いて、その商品の在庫情報を在庫テーブル１２から検索する。
　
【００２８】そして、引当・発注部１３は、その商品の在庫がある場合には、その商品の引当処理を実施する一方、その商品の在庫がない場合には、製造メーカ等に対して商品の発注処理を実施するが、その際、商品を出荷締め前に引き当てた場合には、受注日に商品を出荷することができるので、出荷予定日設定部１６は、受注日を暫定的に出荷予定日に設定する・・・求める。
　
・・・
　
【００３３】・・・暫定的に設定した出荷予定日が営業所の休日に該当しないので（ステップＳＴ９）、その出荷予定日を配送センタ着日設定部１９に出力する
　
【００３４】そして、配送センタ着日設定部１９は、出荷予定日設定部１６が出荷予定日を出力すると、まず、その出荷予定日を暫定的に配送センタ着日に設定・・・検索する。
　
・・・
　
【００３７】・・・暫定的に設定した配送センタ着日が配送センタの休日に該当しないので、今度は、暫定的に設定した配送センタ着日が配送ルートの配送日に該当するか否かを判断する・・・される。
　
・・・
　
【００３９】・・・配送ルートの配送日として、“９９９９９９”が登録されている場合には、その配送ルートは毎日配送するので、暫定的に設定した配送センタ着日が配送日であると判断・・・ている。
　
・・・
　
【００４１】・・・暫定的に設定した配送センタ着日が配送ルートの配送日に該当するので（ステップＳＴ１６）、その配送センタ着日を納期計算部２１に出力する。
　
【００４２】そして、納期計算部２１は、配送センタ着日設定部１９から配送センタ着日が出力されると、配送ルートコードをキーとする当該配送ルートの配送リードタイムを配送リードタイムテーブル２０から検索し、その配送センタ着日に配送リードタイムを加算して商品の納期日を計算する（ステップＳＴ１８）。
　
・・・
　
【００５０】・・・納期計算部２１から出力された納期日が顧客の休日に該当しないので、その納期日を顧客に通知する（ステップＳＴ２０，ＳＴ２２）。」
　
が記載され、
　
また引用文献２に記載の上記一連の実施例において、通知部のみを変更した実施例に係る一連の記載として、
　
（２ｃ）「【００５４】実施の形態３．上記実施の形態１及び実施の形態２では、納期計算部２１により計算された納期日が顧客の休日に該当しない場合には、通知部２３がその納期日を顧客に通知するものについて示したが、受注部１１が顧客の納入希望日を受け付けた場合には、図１５に示すように、通知部２３が、納期日を顧客に通知する前に、その納期日が顧客の納入希望日と一致するか否かを判断して（ステップＳＴ１０１）、以下に示す処理を実施するようにしてもよい。
　
　【００５５】即ち、通知部２３は、その納期日が顧客の納入希望日と一致する場合には、その納期日を顧客に通知する・・・ＳＴ１０３）。」
　
が記載されている。
　
（ケ）上記摘記事項（２ａ）、上記摘記事項（２ｂ）及び上記摘記事項（２ｃ）によれば、引用文献２には、上記通知部のみを変更した実施例に係り、「納期管理装置において、在庫情報を格納する在庫テーブル、当該在庫テーブルに格納された在庫情報に基づいて在庫の有無を確認する引当・発注部、当該引当・発注部による在庫有無の確認結果及び顧客の注文情報によって、暫定的な出荷予定日を設定し、当該暫定的な出荷予定日が、営業所の休日以外の日、配送センタの休日以外の日、配送ルートの配送日の全ての日該当する場合に配送日を決定し、当該配送日に基づいて計算した納期日が顧客の納入希望日と一致すれば、当該納入希望日を当該納期日として顧客に通知する通知部を備えること」が記載されているといえる。
　
（引用文献３）
　
　また原査定で引用された特開２００１−１６００９７号公報（以下、「引用文献３」という。）には、
　
引用文献３に記載の発明の一実施例に係る記載として、
　
（３ａ）「【００１６】スケジュールの空き具合の重みを高く・・・条件設定して検索を実行する。
　
【００１７】適正人員検索手段（１１）は、前記検索条件記憶手段（１２）から得た検索条件に該当する人員を、前記人事情報記憶手段（１３）および前記スケジュール記憶手段（１４）を用いて検索し、条件に合致したサポート者を選出する。」
　
が記載されている。
　
（コ）上記摘記事項（３ａ）における「スケジュールの空き具合の重みを高く・・・条件設定して検索」との記載からみて、当該「スケジュールの空き具合」に応じてサポートの提供の可能性を高めていることから、当該「検索」の背景には、サポートの提供が可能であるかを確認することが当該「検索」の機能目的として含まれているものと解することができる。
　
　したがって、上記摘記事項（３ａ）によれば、引用文献３には「サポートを行う当たり、サポートを行う人員のスケジュール情報を格納するスケジュール記憶手段と当該スケジュール記憶手段で格納されたスケジュール情報を条件設定した検索によってサポートの提供が可能であるかを確認すること」が記載されているといえる。
　
（引用文献４）
　
　また原査定で引用された「ビズネット，日経Windows，日本，日経ＢＰ社，２０００年７月１日，第40号，130〜132」（以下、「引用文献４」という。）には、
　
（４ａ）『オフィス用品のカタログ販売をしているビズネットは、インターネット上の電子メールを使った受注システム「Ｘｍａｉｌ」を新たに構築した』（第１３０頁第１欄第１行乃至第４行）
　
（４ｂ）「今回の受注処理システムでは，日本アイ・ビー・エムのオフコンAS/400上にすでに存在している販売管理や在庫管理などの基幹システムと同期型で直接連携している。顧客からの注文を受けると，まずは基幹システムのデータベースを参照して在庫があることを確認。在庫が確認できた場合は出荷と引き当ての処理をしてから，顧客に受注確認のメールを返信する。もし在庫がなかった場合は，その旨を電話で連絡する。このため．受注しておきながら後で在庫がないということは発生しない。」（第１３１頁第２欄第４行乃至第１７行）
　
がそれぞれ記載されている。
　
（サ）上記摘記事項（４ａ）及び上記摘記事項（４ｂ）によれば、引用文献４には、慣用技術として、「受注処理システムが、すでに存在している基幹システムと直接連携することにより、顧客に対し受注確認として自動的にメールにて送信する手段を備えること」が記載されているといえる。
　
５．本願発明と引用文献１発明との対比
　
（１）一致点の認定
　
　本願の発明の詳細な説明には、本願発明が備える構成である「サポート依頼情報」について、「サポート依頼情報は・・・注文商品の納品日を指定する納品日指定・・・等の情報を含む」（段落【００３２】）と説明されており、当該「サポート依頼情報」の技術的事項は、引用文献１発明における「納入希望日の要求」を排除するものではないと解するのが相当である。
　
　この点を踏まえて、本願発明と引用文献１発明を対比すると、
　
引用文献１発明における
　
「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納入希望日を受け取るオンライン購買サービスを提供するＯＳＮセンタ」、「インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率」、「インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブル」、「インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮（未承認）の発注データとして保存する仮発注処理部」、「仮発注処理部で保存した発注データに基づいて」、「データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し」、「適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部」、「インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバ」及び「出荷案内に示される発注データ及び納品日をユーザ企業に提供する処理を行う取引情報照会部」は、
　
本願発明における
　
「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システム」、「ユーザと販売業者とで予め該ユーザ用に決定した商品の対価の情報である対価情報」、「該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段」、「前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段」、「該受付手段で受け付けられた前記購入依頼情報に基づいて」、「前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報に係わる対価情報を読み出し」、「該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段」、「ユーザに対し、前記データベースを更新する対価更新手段」及び「前記購入依頼情報と共に配送日を、ユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段」
　
にそれぞれ相当し、
　
両者は、
　
（一致点）
「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、
　
ユーザと販売業者とで予め該ユーザ用に決定した商品の対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、
　
前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、
　
該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、
　
ユーザに対し、前記データベースを更新する対価更新手段と
　
前記購入依頼情報と共に配送日を、ユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と
　
を有することを特徴とする商品受注システム」
　
である点で一致する。
　
（２）相違点の認定
　
　そして、両者は、以下の点で相違する。
　
（相違点１）本願発明では、当該「サポート依頼情報」に係わる対価情報を設定するに当たり、受注処理手段及び対価更新手段が「サポートの対価の情報である対価情報」をユーザ情報格納手段に格納する構成及び「前記購入依頼情報に含まれるサポート依頼情報に係わる対価情報」を更新する構成をそれぞれ備えるのに対し、引用文献１発明では、サポート依頼情報に対して対価を設定することが明記されていないため、受注処理手段及び対価更新手段がそのような構成をそれぞれ備えていない点。
　
（相違点２）ユーザに対する対価更新手段における対価情報の計算方法について、本願発明は、「前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して」当該対価情報を更新する構成を備えるのに対し、引用文献１発明は、対価情報を更新する具体的な計算方法について明記されていないため、そのような構成を備えていない点。
　
（相違点３）配送日の決定とそれに付随する処理を行う各手段について、
　
本願発明は、『商品受注システムが「商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段」』、「該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段」及び「該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段」を備え、
　
そのために、
　
商品受注システムが、
　
「前記配送日決定手段によって決定された配送日に商品を配送するよう指示する」ものとして、「前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段」を備え、
　
受注確認情報送信手段が、
　
「前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又は電子メールにて」送信する構成を備えるのに対し、
　
引用文献１発明は、
　
商品受注システムに、販売業者から発注にかかる商品の出荷案内又は納期回答を送られる構成を備え、
　
そのために、
　
商品受注システムが、前記商品配送指示手段を備えておらず、
　
受注確認送信手段が、
　
商品受注システムが販売業者から商品の出荷案内又は納期回答を送られた後に、ユーザからの照会リクエストに応えて、前記購入依頼情報と共に配送日を、ユーザに提供する処理を行う構成を備える点。
　
６．相違点についての判断
　
（相違点１について）
　
　引用文献１発明において、「サポート依頼情報」である「納入希望日の要求」における「サポート」である「納入」を実施するためには、当該「納入」のための人員を手当てすること、当該手当てした人員の人件費を「納入」に係わる「対価」として賄うこと、及び、当該「サポート」に係わる「対価」についてユーザと販売業者とで予め仕切値を決定することは、いずれも、商取引という技術分野における慣用技術であるから、引用文献１発明において、「サポート依頼情報」における「サポート」を実施するに当たり、当該「サポート」のための人員を手当てし、当該人員の人件費を当該「サポート」に係わる「対価」として賄うこと、及び、当該「対価」についてユーザと販売業者とで予め仕切値を決定することは、慣用技術の単なる適用に過ぎないものと認められる。
　
　そして、引用文献１発明において、当該慣用技術に基づき、「サポート」に係わる「対価」を設定すれば、受注処理手段が「サポートの対価の情報である対価情報」をユーザ情報格納手段に格納すること、及び、ユーザと販売業者とで予め決定する仕切値に応じて、対価更新手段が「前記購入依頼情報に含まれるサポート依頼情報に係わる対価情報」を更新する構成を備えることは、当業者であれば当然なし得る事項と認められる。
　
　したがって、相違点１に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。
　
（相違点２について）
　
　技術常識を参酌すれば、引用文献１発明が備える「仕切率」は、ユーザと販売業者との間の取引量、すなわち商品発注及びサポート依頼の頻度に基づいて、その対価を割り引きすることに他ならないから、引用文献１発明において、対価更新手段における対価更新の計算方法について、前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して」対価情報を更新する構成を採用することは、当業者であれば当然なし得る事項と認められる。
　
　また上記「仕切率」の実施の具体化手段として、当該「前記受付手段で受け付けられた前記購入依頼情報」に係る購入回数を頻度に積算することは、ユーザと販売業者との間で適宜に決める契約内容に過ぎないから、引用文献１発明において、「前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し」て対価情報を更新する構成とすることは、当該ユーザと販売業者との間で適宜に決める契約内容に応じて当業者であれば適宜になし得る設計事項に過ぎない。
　
　したがって、相違点２に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。
　
（相違点３について）
　
　引用文献２に記載の「通知部」は、納入希望日を納期日として顧客に通知する前に、当該納入希望日を当該納期日として決定しているものと推認することができ、また当該「通知部」において当該納入希望日を当該納期日として決定するに際し、「在庫情報を格納する在庫テーブル」及び「当該在庫テーブルに格納された在庫情報に基づいて在庫の有無を確認する引当・発注部」を用いていると解することができるので、引用文献１発明において、商品の納期を得るに当たり、商品受注システムに、販売業者から発注にかかる商品の出荷案内又は納期回答を送られる構成に代えて、『商品受注システムが「商品の在庫情報を格納する在庫情報格納手段」』、「該在庫情報格納手段で格納された在庫情報に基づいて注文された商品の提供が可能であるかを確認する在庫確認手段」及び「該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段」を備える構成を採用することは、引用文献２の記載に基づき当業者であれば適宜になし得るものである。
　
　そして、引用文献１発明は「商品の購入依頼及びサポートの依頼の受注を行う商品受注システム」であることから、引用文献１発明において、商品及びサポートの受注に対応する当該商品及び当該サポートの納期を得るに当たり、上記「在庫テーブル」及び「引当・発注部」がそれぞれ取り扱う情報及び確認内容として、「サポート人員のスケジュール情報」及び「サポートの提供が可能であるかを確認」することを採用し、上記「在庫情報格納手段」及び上記「在庫確認手段」と引用文献３にみられるような周知技術である「サポート人員のスケジュール情報を格納する在庫情報格納手段」及び「該在庫情報格納手段で格納された在庫情報に基づいてサポートの提供が可能であるかを確認する在庫確認手段」とを併用することは、引用文献３の記載に基づき当業者であれば適宜になし得るものである。
　
　また引用文献１発明において、商品受注システムが上記「配送日決定手段」を採用すれば、当該「商品受注システム」が決定した配送日を管理することとなるから、引用文献１発明において、当該商品受注システムが「前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段」を備えること、及び、当該「商品配送指示手段」が前記配送日決定手段によって決定された配送日に商品を配送するよう指示する」構成を備えることは、当業者であれば当然なし得る事項である。
　
　また引用文献１発明において、商品受注システムが上記「配送日決定手段」を採用すれば、当該「商品受注システム」が決定した配送日を管理することとなるから、当該配送日を顧客に通知する具体化手段として、受注確認情報送信手段が「前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又は電子メールにて」送信する構成を採用することは、引用文献４にみられるような慣用技術の単なる選択に過ぎないものである
　
　したがって、相違点３に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。
　
　そして，本願発明の作用効果も，引用文献及び周知技術から当業者が予測できる範囲のものである。
　
　よって、本願発明は、引用文献１発明、引用文献２、引用文献３及び引用文献４に記載の発明並びに周知・慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　
　
７．むすび
　
　上記のとおり、本願の請求項１に係る発明が、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないため、本願の他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。