• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1201368
審判番号 不服2006-13545  
総通号数 117 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2009-09-25 
種別 拒絶査定不服の審決 
審判請求日 2006-06-28 
確定日 2009-07-30 
事件の表示 特願2001-387798「商品受注システム、プログラム、及び記録媒体」拒絶査定不服審判事件〔平成15年 7月 4日出願公開、特開2003-187152〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続きの経緯

本願は、平成13年12月20日に出願された特許出願であって、平成17年10月19日付けで拒絶理由通知が通知され、これに対して同年12月12日付けで手続補正書が提出され、平成18年 5月26日付けで拒絶査定され、これに対して同年6月28日付けで拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正書が提出されたものである。

2.補正について

(1)補正の内容

平成18年 6月28日付け手続補正でした特許請求の範囲についてなされた補正(以下、「本件補正」という。)は、以下のとおりである。

本件補正により、特許請求の範囲は、

「【請求項1】

ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、

ユーザと販売業者とで予め該ユーザ用に決定した商品及びサポートの対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、

前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、

該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報及びサポート依頼情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、

前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して、前記データベースを更新する対価更新手段と、

前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段と、

商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段と、

該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段と、

該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段と、

前記購入依頼情報と共に前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と、を有し、

前記商品配送指示手段は、前記配送日決定手段によって決定された配送日に商品を配送するよう指示すること

を特徴とする商品受注システム。

【請求項2】

前記受注処理手段における受注処理の後、前記データベースに格納された前記対価情報と、前記ユーザ個人情報とに基づいて、前記購入依頼情報に含まれる商品及びサポートの代金の情報を、前記ユーザの前記コンピュータにネットワークを介して送信することで請求する代金請求手段を、さらに有すること

を特徴とする請求項1に記載の商品受注システム。

【請求項3】

請求項1又は2に記載の商品受注システムとして機能させるためのプログラム。

【請求項4】

請求項3に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。」

と補正された。

(2)補正の適否判断

補正後の請求項1は、補正前の請求項1を引用する請求項3をさらに引用する請求項4に記載の「前記受付手段で前記購入依頼情報」を「前記受付手段で受け付けられた前記購入依頼情報」とする補正を行ったものであり、補正後の請求項2は、補正前の請求項1を引用する請求項2をさらに引用する請求項3をさらに引用する請求項4とする補正を行ったものである。
なお、補正前の請求項1及び請求項2は削除された。

また、補正後の請求項3及び4は、補正前の請求項5及び6にそれぞれ対応する。

上述した補正前の請求項の対応からみて、本件補正は、請求項1及び請求項2を削除し、上記「前記受付手段で前記購入依頼情報」を「前記受付手段で受け付けられた前記購入依頼情報」の誤記として誤記の訂正を行ったものと認められる。

したがって、本件補正は、特許法第17条の2第4項第1号及び同項第3号に掲げられた請求項の削除及び誤記の訂正を目的とするものであり、特許法第17条の2第4項の要件を満たすものである。

3.本願の請求項1に係る発明

本願の請求項1に係る発明(以下、「本願発明」という。)は、平成18年 6月28日付け手続補正書における特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。

「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、

ユーザと販売業者とで予め該ユーザ用に決定した商品及びサポートの対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、

前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、

該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報及びサポート依頼情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、

前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して、前記データベースを更新する対価更新手段と、

前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段と、

商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段と、

該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段と、

該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段と、

前記購入依頼情報と共に前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と、を有し、

前記商品配送指示手段は、前記配送日決定手段によって決定された配送日に商品を配送するよう指示することを特徴とする商品受注システム。」

4.引用文献に記載の発明

(引用文献1)
原査定の拒絶の理由に引用された特開2000-132596号公報(以下、「引用文献1」という。)には、

引用文献1に記載の発明が解決しようとする課題に係る記載として、

(1a)「【0006】(3) 企業間の商取引では、商品の価格は一律ではなく、商品提供業者と各調達側企業間でネゴシアブルに個別に設定されることが少なくない。しかし、従来のシステムでは、商品価格は一律であり、企業毎にカスタマイズすることはできない。」

が記載され、

また引用文献1に記載の発明の観点として、

(1b)「【0021】本発明の第2の観点に従う電子商取引センタは、通信ネットワーク上に存在し、複数の商品サプライヤのコンピュータシステムと通信可能に接続された電子商取引用のコンピュータシステムであって、複数の商品サプライヤのコンピュータシステムから取得した商品情報を保持した商品データベースと、この商品データベース内の情報に基づく商品閲覧サービスを通信ネットワークにオンラインで提供する商品閲覧処理部と、商品の受注サービスを通信ネットワークにオンラインで提供する受注処理部と、受注サービスで受けた注文に基づいて複数のサプライヤに発注を行う発注処理部とを備える。

・・・

【0027】本発明の第5の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部と、この仮発注データについて、発注承認の通知を通信ネットワークを通じてオンラインで企業内のユーザから受けて、その仮発注データを正発注データにする発注承認処理部とを備える。

・・・

【0031】本発明の第7の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受け保存する受注処理部と、発注データに基づいて商品サプライヤに商品を発注する発注処理部と、商品サプライヤから出荷情報を受けて保存する出荷情報受信部と、商品サプライヤから請求データを受けて保存する請求受信部と、企業内のユーザからの照会リクエストに応えて、保存してある発注データ、出荷情報及び請求データの中からリクエストされた情報を検索して通信ネットワークを通じてオンラインで企業内のユーザに提供する取引情報照会部とを備える。

・・・

【0033】本発明の第8の観点に従う電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受け保存する受注処理部と、企業の与信情報を保持し、発注データ毎に与信情報に基づき企業の与信枠をチェックする与信処理部とを備える。受注処理部は、与信枠のチェック結果に応じて、ユーザからの発注を受諾するか拒否するかを決定する」

が記載され、

また引用文献1に記載の発明の実施例に係る一連の記載として、

(1c)「【0040】
【発明の実施の形態】図1は、本発明の一実施形態にかかる電子商取引システムの全体構成を示す。
図1において、オフィシャルサプライネットセンタ(以下、OSNセンタという)1は、コンピュータネットワークを利用して企業等に対し事務用品等の各種商品のオンライン購買サービスを提供するための施設である。このOSNセンタ1には、複数の商品提供企業(サプライヤ)3A,3B,…と、多数の調達側企業(以下、ユーザ企業という)5,7,…と、さらに信販会社のような決済機関9とが、インターネット11を介して(サプライヤによってはVAN13を介して)常時または随時に接続されるようになっている。・・・提供する

・・・。

【0042】OSNセンタ1にはLAN21が構築され、このLAN21上に、受発注や支払請求の業務を行なう受発注センタサーバ25、商品データベース35を管理する商品データベースサーバ27、商品の画像ファイル37を管理するWWWサーバ29、及び外部のネットワーク11,13と接続するゲートウェイ23などが存在する。受発注センタサーバ25は、受発注データ31や支払請求データ33を管理している。商品データベース35には、全てのサプライヤの全商品の名称、識別符号、価格、サプライヤ名、説明など、ユーザ企業が商品の選定を行うために必要な情報及びOSNセンタ1が商品を受注するために必要な情報が登録されている。

【0043】各サプライヤ3A,3B,…は、それぞれ独自の受発注システム41A,41B,…や、商品データベースシステム43A,43B,…を有している。商品データベースシステム43A,43B,…は、それぞれのサプライヤが提供する商品の名称、識別符号、価格、等が登録された商品マスタデータベース45A,45B,…、及びそれらの商品の画像ファイル47A,47B,…などを有している。すべてのサプライヤ3A,3B…の商品マスタデータベース45A,45B,…及び商品画像ファイル47A,47B,…の更新内容は、定期的(例えば毎日早朝)にOSNセンタ1に送られて、OSNセンタ1内の商品データベース31及び画像ファイル33に反映される。

【0044】ユーザ企業5、7は、イントラネットを社内に有しているもの(イントラネットユーザ企業)7と、有していない企業(インターネットユーザ企業)5とに大別される。・・・などを行なう。」、

(1d)「【0046】図2は、OSNセンタ1が行う処理81?119を示す。なお、ユーザサービスを行う処理(図2中でユーザ企業5、7と矢印で結ばれている処理)は、ユーザ端末51、65のWWWブラウザ画面を用いて、ユーザ端末操作者(ユーザ)と情報をやり取りするようになっている。

・・・

【0049】商品情報管理85は、サプライヤ3の商品マスタ45及び画像ファイル47の更新データを定期的に取得して、OSNセンタ1内の商品データベース35及び画像ファイル37を更新し管理する処理である。・・・代行する。

・・・

【0051】受注89は、ユーザ企業5、7から商品注文を受ける処理であり、これには仮受注91と発注承認93の処理が含まれる。仮受注91は、特にインターネットユーザ企業5から発注データを受信して仮(未承認)の受注データとして保存及び管理する処理である。発注承認93は、仮受注91で保存した仮の受注データに対して、インターネットユーザ企業5から発注承認を受信して、これを正式な受注データにして保存する処理である。・・・ことになる。

・・・

【0055】出荷状況受信101は、サプライヤ3に発注した商品について、サプライヤ3から納品日などを示す出荷案内を受信して保存する処理である。

【0056】出荷状況照会103は、出荷状況受信101で保存した出荷案内や、未だ出荷されてない残存の発注内容などを、ユーザ企業5、7からの照会要求に応えてユーザ企業5、7に提供する処理である。」

(1e)「【0085】図7は、OSNセンタ1内の商品データベースサーバ27がもつ仕切率テーブルを示す。

【0086】図7に示すように、複数のユーザ企業グループと複数の商品価格グループが定義されており、それらのユーザ企業グループと各商品価格グループとの組み合わせの各々に対してそれぞれ1つの仕切率(つまり、基準価格に対する実際の販売価格の比率)が設定されている。・・・各ユーザ企業に対する各商品の販売価格は、その企業が所属する企業グループに対し各商品グループ毎に設定されている仕切率を適用して決定される。

【0087】図8は、この仕切率テーブルを用いて、OSNセンタ1の商品情報管理85が各ユーザ企業別の商品価格を決定する動作を示す。

【0088】図8に示すように、図6に示した更新処理でOSNセンタ1内の商品データベース35を更新したとき、その更新ログを作成して保存し(S11)、続いて、その更新ログから価格切替を行う商品コードを検索する(S12)。例えば、新規に追加された商品や、既存商品の中で基準価格が変更になった商品などが価格切替え対象の商品である。次に、価格切替え商品について手動設定フラグが設定されているかチェックする(S13)。手動設定フラグは、サプライヤ3から受信した商品データベースの更新データに含まれているもので、バーゲン商品のように通常の仕切率の適用が除外される商品に対して設定されている。

【0089】手動設定フラグが設定されていない商品については、図7に示した仕切率テーブル上の当該商品のグループに適用される仕切率を用いて、当該商品の基準価格から、当該商品の各企業グループ毎の販売価格を計算する(S14)。・・・(S17)。

【0090】・・・なお、インターネットユーザ企業5のユーザはOSNセンタ1に直接ログインして商品閲覧を行うが、その際、OSNセンタ1は他企業向けの販売価格を除いた当該企業向けの販売価格しかユーザに送らない。」、

(1f)「【0091】図9は、商品閲覧から受発注そして決済までの全体の動作の流れを示す。なお、この図9及び後続の図面は、インターネットユーザ企業5に対する動作(つまり、OSNセンタ1が全処理を行う動作)を示しており、以下の動作説明もこれに基づいて行う。一方、イントラネットユーザ企業7に対しては、図9におけるステップS21?S24(商品検索、商品閲覧、発注、与信チェック)をイントラサーバ63が代行し、それ以降はイントラサーバ63は通信の仲介を行ないOSNセンタ1が実質的な処理を行う。この点を踏まえれば、以下の説明からイントラネットユーザ企業7に対する動作も十分に理解できるはずである。

・・・

【0093】発注を行う場合、ユーザは、ユーザ端末のWWWブラウザ画面上で商品及び個数などを指定して発注データを作成し、OSNセンタ1に送信する(S23)。OSNセンタ1は、決済機関9から取得した与信情報201を参照して、発注を行ったユーザ企業の与信枠が足りなくないかチェックし(S24)、与信枠に問題がなければその発注データを仮の受注データとして受け付ける。その後、図示してないが、ユーザから発注承認を受けると、OSNセンタ1は、その受注データを正式なものとする。

【0094】その後、OSNセンタ1は、正式な受注データを各サプライヤ3別に振り分け、その受注データを基に各サプライヤ3に対し発注を行う(S25)。発注データ203は保存される。その後、各サプライヤ3は、その発注にかかる商品の出荷案内又は納期回答をOSNセンタ1に送る(S26)。また、各サプライヤ3は、月毎に一括請求をOSNセンタ1に送る(S29)。OSNセンタ1は、サプライヤ3からの請求を発注データ203に照らして違算チェックを行い、そして、その請求データ205を保存する。」、

(1g)「【0100】各ユーザ企業5、7では、発注担当者が、WWWブラウザ上で発注データを作成してHTTPによりOSNセンタ1へ送信する。OSNセンタ1は、このユーザ発注データを受けると(S41)、この発注データに注文番号を付けた上で(S42)、ユーザ受注ファイル301に保存する(S43)。また、OSNセンタ1は、発注したユーザ企業5、7へ、注文内容確認通知を送り(S44)、ユーザ企業5、7からその注文内容の確認結果を受信する(S45)。確認結果がキャンセルであれば受注ファイル301から当該受注データを削除し(S46)、変更であれば変更処理を行って受注ファイル301内の当該受注データを変更して再び注文内容確認通知を送り(S47)、OKであれば仮受注が成立したものとしてその旨のメッセージをユーザ企業5、7に返す(S48)。」、

(1h)「【0122】図21は、ユーザ端末のWWWブラウザに表示される購入要求書画面の例を示す。

【0123】この画面413には、購入リストに登録された商品名や金額、及びその他の発注に必要な事項が登録されている。送信ボタン415をマウスクリックすると、この購入要求書(発注データ)がOSNセンタ1へ送信される。ユーザとしては、1枚の購入要求書で、つまり1回の発注で、複数のサプライヤの種々の商品を纏めて発注できるので楽である。」

がそれぞれ記載されている。

(ア)上記摘記事項(1c)からみて、「電子商取引システム」の一実施例として「OSNセンタ」が記載されているものと解することができること、及び、上記摘記事項(1h)における「購入要求書画面」の具体例である引用文献1の図21の記載からみて、当該「購入要求書画面」に「納入希望日」が含まれていることから、当該「OSNセンタ」は、当該「購入要求書画面」を受け取るときに、「商品」の「購入要求」に併せて当該「納入希望日」も受け取るものと推認できる。

したがって、上記摘記事項(1c)に記載の「オフィシャルサプライネットセンタ(以下、OSNセンタという)1は、コンピュータネットワークを利用して企業等に対し事務用品等の各種商品のオンライン購買サービスを提供する・・・ユーザ企業5、7は、イントラネットを社内に有しているもの(イントラネットユーザ企業)7と、有していない企業(インターネットユーザ企業)5とに大別される。」によれば、引用文献1には「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納品希望日を受け取るオンライン購買サービスを提供するOSNセンタ」が記載されているといえる。

(イ)上記摘記事項(1a)における「商品の価格は一律ではなく、商品提供業者と各調達側企業間でネゴシアブルに個別に設定される」との記載からみて、当該「価格」は、当該「調達側企業」である「インターネットユーザ企業」と当該「商品提供業者」である「サプライヤ」との間で「ネゴシアブルに個別に設定」された「価格」であるものと解することができる。

また引用文献1の図7の記載及び上記摘記事項(1e)における「図7は、OSNセンタ1内の商品データベースサーバ27がもつ仕切率テーブルを示す。図7に示すように、複数のユーザ企業グループと複数の商品価格グループが定義されており、それらのユーザ企業グループと各商品価格グループとの組み合わせの各々に対してそれぞれ1つの仕切率(つまり、基準価格に対する実際の販売価格の比率)が設定されている」との記載からみて、当該「仕切率テーブル」の行定義情報は、「インターネットユーザ企業」を上記「複数のユーザ企業グループ」と同種の行定義情報として含むことを読み取ることができるので、上記「仕切率テーブル」は、「仕切率」を、「インターネットユーザ企業」を含む行定義情報と関連付けて、データベースとして格納したものと解することができる。

また上記摘記事項(1c)における「各サプライヤ・・・は・・・商品データベースシステム・・・を有している」、「商品データベースシステム・・・は、それぞれのサプライヤが提供する商品の・・・価格、等が登録された商品マスタデータベース・・・などを有している。」及び「すべてのサプライヤ・・・の商品マスタデータベース・・・の更新内容は・・・OSNセンタ1内の商品データベース・・・に反映される。」との各記載からみて、上記「価格」が上記「インターネットユーザ企業」と上記「サプライヤ」との間で「ネゴシアブルに個別に設定」されて、当該「商品マスタデータベース」の内容が更新されれば、その「更新内容」は、当該「商品データベース」として格納した上記「仕切率テーブル」の上記「仕切率」に「反映」されるものと解することができる。

したがって、上記摘記事項(1a)、上記摘記事項(1e)及び上記摘記事項(1c)を勘案すれば、引用文献1には、「OSNセンタが、インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率を、インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブルを備える」ことが記載されているといえる。

(ウ)上記摘記事項(1h)における「・・・この画面413には、購入リストに登録された商品名や金額、及びその他の発注に必要な事項が登録されている。」により説明される引用文献1の図21の記載からみて、「商品名」及びその「個数」の情報、「納入希望日」の要求、上記「インターネットユーザ企業を含む行定義情報」の具体例である「担当名」及び「名前」、並びに、「金額」である商品の対価は、いずれも当該「発注に必要な事項」として読み取ることができるが、上記摘記事項(1f)における「・・・発注を行う場合、ユーザは、ユーザ端末のWWWブラウザ画面上で商品及び個数などを指定して発注データを作成し・・・」及び上記摘記事項(1e)における「なお、インターネットユーザ企業5のユーザはOSNセンタ1に直接ログインして商品閲覧を行うが、その際、OSNセンタ1は他企業向けの販売価格を除いた当該企業向けの販売価格しかユーザに送らない。」の両記載からみて、当該「価格」はOSNセンタからインターネットユーザ企業へ送られるものであるから、上記「発注に必要な事項」の内、インターネットユーザ企業が指定して作成した項目は、上記「商品名」及びその「個数」の情報、「納入希望日」の要求、並びに、「インターネットユーザ企業を含む行定義情報」と解することができる。

また上記摘記事項(1d)における「OSNセンタ1が行う処理81?119を示す。・・・受注89は、ユーザ企業5、7から商品注文を受ける処理であり、これには仮受注91と発注承認93の処理が含まれる。仮受注91は、特にインターネットユーザ企業5から発注データを受信して仮(未承認)の受注データとして保存及び管理する処理である。」における当該「仮(未承認)の受注データとして保存及び管理する処理」は、当該「OSNセンタ」が行う「仮受注」であって、上記摘記事項(1b)における「・・・電子商取引センタは・・・商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部・・・を備える。」との記載からみて、当該企業内のユーザから受けた「仮発注」は、上記インターネットユーザ企業から「発注データ」を受信した仮(未承認)の「受注」の言い換えに過ぎないから、「電子商取引センタ」の実施例である「OSNセンタ」が備える当該「仮発注処理部」により行われるものと解することができる。

したがって、上記摘記事項(1d)、上記摘記事項(1f)及び上記摘記事項(1d)において摘示したことを踏まえ、上記摘記事項(1g)を勘案すると、引用文献1には「OSNセンタが、インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮(未承認)の発注データとして保存する仮発注処理部を備える」ことが記載されているといえる。

(エ)また上記摘記事項(1d)における「OSNセンタ1が行う処理81?119を示す。・・・発注承認93は、仮受注91で保存した仮の受注データに対して、インターネットユーザ企業5から発注承認を受信して、これを正式な受注データにして保存する処理である。」における当該「正式な受注データにして保存する処理」は、当該「OSNセンタ」が行う「発注承認」であって、上記摘記事項(1b)における「・・・電子商取引センタは、商品の発注データを通信ネットワークを通じてオンラインで企業内のユーザから受けて仮発注データとして保存する仮発注処理部と、この仮発注データについて、発注承認の通知を通信ネットワークを通じてオンラインで企業内のユーザから受けて、その仮発注データを正発注データにする発注承認処理部とを備える。」との記載からみて、「電子商取引センタ」の実施例である「OSNセンタ」が備える当該「仮発注処理部」により行われるものと解することができる。

また上記(ウ)で摘示したように、「発注に必要な事項」には、商品の対価が含まれるものと解することができ、上記摘記事項(1e)を参酌すると、当該商品の対価は、仕切率を適用して決定されるものである。

したがって、上記(ウ)で摘示したことと上記摘記事項(1d)を勘案すれば、引用文献1には「OSNセンタが、仮発注処理部で保存した発注データに基づいて、データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し、適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部を備える」ことが記載されているといえる。

(オ)上記摘記事項(1e)における「OSNセンタ1内の商品データベースサーバ27がもつ仕切率テーブルを示す・・・更新処理でOSNセンタ1内の商品データベース35を更新」及び上記摘記事項(1d)における「OSNセンタ1が行う処理81?119を示す・・・商品情報管理85は・・・OSNセンタ1内の商品データベース35及び画像ファイル37を更新し管理する処理」との記載からみて、「仕切率テーブル」を更新する「更新処理」は、当該「OSNセンタ」が行う「商品情報管理」であって、上記摘記事項(1c)における「・・・OSNセンタ1にはLAN21が構築され、このLAN21上に・・・商品データベース35を管理する商品データベースサーバ27・・・が存在する」との記載からみて、当該「商品情報管理」は、当該「OSNセンタ」に構築されたLAN上に存在する当該「商品データベースサーバ」により行われるものと解することができる。

また上記(イ)において摘示したように、引用文献1の図7の記載からみて、「仕切率テーブル」の行定義情報において、「インターネットユーザ企業」を「複数のユーザ企業グループ」と同種の行定義情報として表すことを読み取ることができることから、上記「各ユーザ企業別の商品価格」の情報には、インターネットユーザ企業の個別の商品価格の情報も含まれるものと解することができる。

また上記摘記事項(1e)における「この仕切率テーブルを用いて、OSNセンタ1の商品情報管理85が各ユーザ企業別の商品価格を決定する動作を示す」との記載からみて、上記「更新処理」により更新される「仕切率テーブル」の内容は、「各ユーザ企業別の商品価格」の情報であることから、インターネットユーザ企業に対し、仕切率テーブルが個別に更新されるものと解することができる。

したがって、上記摘記事項(1c)、上記摘記事項(1d)、上記摘記事項(1e)及び上記(イ)において摘示したことを勘案すると、引用文献1には「OSNセンタが、インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバを備える」ことが記載されているといえる。

(カ)上記摘記事項(1d)における「・・・OSNセンタ1が行う処理81?119を示す・・・発注99は、受注89で保存した正式な受注データを各サプライヤ3に振り分け、各サプライヤ3に送信する(発注する)処理である。」からみて、当該「各サプライヤ」に「振り分け」て当該「各サプライヤ」に「送信する」処理は、当該「OSNセンタ」が行う「発注」であって、上記摘記事項(1b)における「電子商取引センタは・・・受注サービスで受けた注文に基づいて複数のサプライヤに発注を行う発注処理部とを備える・・・」との記載からみて、当該「発注」は、該「電子商取引センタ」の実施例である「OSNセンタ」が備える当該「発注処理部」により行われるものと解することができる。

したがって、上記摘記事項(1b)及び上記摘記事項(1d)を勘案すると、引用文献1には「OSNセンタが、発注データに含まれる商品の発送を各サプライヤに振り分けて当該各サプライヤに送信する処理である発注を行う発注処理部を備える」ことが記載されているといえる。

(キ)上記摘記事項(1c)における「ユーザ企業5、7は、イントラネットを社内に有しているもの(イントラネットユーザ企業)7と、有していない企業(インターネットユーザ企業)5とに大別される」によれば、「ユーザ企業5」は、「インターネットユーザ企業」を差し示すものと解することができる。

また上記摘記事項(1d)における「・・・OSNセンタ1が行う処理81?119を示す。ユーザサービスを行う処理(図2中でユーザ企業5、7と矢印で結ばれている処理)・・・出荷状況受信101は、サプライヤ3に発注した商品について、サプライヤ3から納品日などを示す出荷案内を受信して保存する処理である。出荷状況照会103は、出荷状況受信101で保存した出荷案内・・・を、ユーザ企業5、7からの照会要求に応えてユーザ企業5、7に提供する処理である。」との記載における「納品日」を示す「出荷案内」を「ユーザ企業5」からの「照会要求」に応えて当該「ユーザ企業5」に提供する処理は、当該「OSNセンタ」が行う「出荷状況照会」であって、上記摘記事項(1b)における「・・・電子商取引センタは・・・企業内のユーザからの照会リクエストに応えて、保存してある発注データ、出荷情報及び請求データの中からリクエストされた情報を検索して通信ネットワークを通じてオンラインで企業内のユーザに提供する取引情報照会部とを備える。」との記載からみて、当該「出荷状況照会」は、該「電子商取引センタ」の実施例である「OSNセンタ」が備える当該「取引情報照会部」により行われるものと解することができる。

したがって、上記摘記事項(1b)、上記摘記事項(1c)及び上記摘記事項(1d)を勘案すると、引用文献1には、「OSNセンタが、販売業者から商品の出荷案内又は納期回答を送られた後に、企業内のユーザからの照会リクエストに応えて、出荷案内に示される発注データ及び納品日をインターネットユーザ企業に提供する処理を行う取引情報照会部を備える」ことが記載されているといえる。

(ク)上記摘記事項(1a)における「・・・電子商取引センタは、通信ネットワーク上に存在し、複数の商品サプライヤのコンピュータシステムと通信可能に接続された電子商取引用のコンピュータシステム」からみて、電子商取引センタの実施例であるOSNセンタは、サプライヤのコンピュータシステムと通信可能に接続されたものであると解することができることから、上記摘記事項(f)における「その後、各サプライヤ3は、その発注にかかる商品の出荷案内又は納期回答をOSNセンタ1に送る」との記載によれば、引用文献1には、「OSNセンタに、サプライヤのコンピュータシステムから発注にかかる商品の出荷案内又は納期回答を送られる」ことが記載されているといえる。

上記(ア)?(ク)を考慮して、摘記事項(1a)?(1h)の記載を総合すると、引用文献1には、次の発明(以下、「引用文献1発明」という。)が記載されているといえる。

「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納品希望日を受け取るオンライン購買サービスを提供するOSNセンタであって、

インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率を、インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブルと、

インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮(未承認)の発注データとして保存する仮発注処理部と、

仮発注処理部で保存した発注データに基づいて、データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し、適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部と、

インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバと、

発注データに含まれる商品の発送を各サプライヤに振り分けて当該各サプライヤに送信する処理である発注を行う発注処理部と、

販売業者から商品の出荷案内又は納期回答を送られた後に、企業内のユーザからの照会リクエストに応えて、出荷案内に示される発注データ及び納品日をインターネットユーザ企業に提供する処理を行う取引情報照会部と

を備え、

OSNセンタに、サプライヤのコンピュータシステムから発注にかかる商品の出荷案内又は納期回答を送られる

ことを特徴とするOSNセンタ」

(引用文献2)

また原査定で引用された特開平11-296601号公報(以下、「引用文献2」という。)には、

引用文献2に記載の発明の属する技術分野として、

(2a)「【0001】【発明の属する技術分野】この発明は、商品を受注すると商品の納期日を計算する納期管理装置及び納期管理方法に関するものである。」

が記載され、

また引用文献2に記載の発明の実施例の一連の記載として、

(2b)「【0024】
【発明の実施の形態】以下、この発明の実施の一形態を説明する。・・・である。

・・・

【0027】次に動作について説明する。まず、受注部11が、顧客の注文情報(受注日、商品コード、営業所コード、配送センタコード、配送ルートコード、顧客コード)を入力すると、引当・発注部13が、顧客の注文情報に含まれる商品コードを用いて、その商品の在庫情報を在庫テーブル12から検索する。

【0028】そして、引当・発注部13は、その商品の在庫がある場合には、その商品の引当処理を実施する一方、その商品の在庫がない場合には、製造メーカ等に対して商品の発注処理を実施するが、その際、商品を出荷締め前に引き当てた場合には、受注日に商品を出荷することができるので、出荷予定日設定部16は、受注日を暫定的に出荷予定日に設定する・・・求める。

・・・

【0033】・・・暫定的に設定した出荷予定日が営業所の休日に該当しないので(ステップST9)、その出荷予定日を配送センタ着日設定部19に出力する

【0034】そして、配送センタ着日設定部19は、出荷予定日設定部16が出荷予定日を出力すると、まず、その出荷予定日を暫定的に配送センタ着日に設定・・・検索する。

・・・

【0037】・・・暫定的に設定した配送センタ着日が配送センタの休日に該当しないので、今度は、暫定的に設定した配送センタ着日が配送ルートの配送日に該当するか否かを判断する・・・される。

・・・

【0039】・・・配送ルートの配送日として、“999999”が登録されている場合には、その配送ルートは毎日配送するので、暫定的に設定した配送センタ着日が配送日であると判断・・・ている。

・・・

【0041】・・・暫定的に設定した配送センタ着日が配送ルートの配送日に該当するので(ステップST16)、その配送センタ着日を納期計算部21に出力する。

【0042】そして、納期計算部21は、配送センタ着日設定部19から配送センタ着日が出力されると、配送ルートコードをキーとする当該配送ルートの配送リードタイムを配送リードタイムテーブル20から検索し、その配送センタ着日に配送リードタイムを加算して商品の納期日を計算する(ステップST18)。

・・・

【0050】・・・納期計算部21から出力された納期日が顧客の休日に該当しないので、その納期日を顧客に通知する(ステップST20,ST22)。」

が記載され、

また引用文献2に記載の上記一連の実施例において、通知部のみを変更した実施例に係る一連の記載として、

(2c)「【0054】実施の形態3.上記実施の形態1及び実施の形態2では、納期計算部21により計算された納期日が顧客の休日に該当しない場合には、通知部23がその納期日を顧客に通知するものについて示したが、受注部11が顧客の納入希望日を受け付けた場合には、図15に示すように、通知部23が、納期日を顧客に通知する前に、その納期日が顧客の納入希望日と一致するか否かを判断して(ステップST101)、以下に示す処理を実施するようにしてもよい。

【0055】即ち、通知部23は、その納期日が顧客の納入希望日と一致する場合には、その納期日を顧客に通知する・・・ST103)。」

が記載されている。

(ケ)上記摘記事項(2a)、上記摘記事項(2b)及び上記摘記事項(2c)によれば、引用文献2には、上記通知部のみを変更した実施例に係り、「納期管理装置において、在庫情報を格納する在庫テーブル、当該在庫テーブルに格納された在庫情報に基づいて在庫の有無を確認する引当・発注部、当該引当・発注部による在庫有無の確認結果及び顧客の注文情報によって、暫定的な出荷予定日を設定し、当該暫定的な出荷予定日が、営業所の休日以外の日、配送センタの休日以外の日、配送ルートの配送日の全ての日該当する場合に配送日を決定し、当該配送日に基づいて計算した納期日が顧客の納入希望日と一致すれば、当該納入希望日を当該納期日として顧客に通知する通知部を備えること」が記載されているといえる。

(引用文献3)

また原査定で引用された特開2001-160097号公報(以下、「引用文献3」という。)には、

引用文献3に記載の発明の一実施例に係る記載として、

(3a)「【0016】スケジュールの空き具合の重みを高く・・・条件設定して検索を実行する。

【0017】適正人員検索手段(11)は、前記検索条件記憶手段(12)から得た検索条件に該当する人員を、前記人事情報記憶手段(13)および前記スケジュール記憶手段(14)を用いて検索し、条件に合致したサポート者を選出する。」

が記載されている。

(コ)上記摘記事項(3a)における「スケジュールの空き具合の重みを高く・・・条件設定して検索」との記載からみて、当該「スケジュールの空き具合」に応じてサポートの提供の可能性を高めていることから、当該「検索」の背景には、サポートの提供が可能であるかを確認することが当該「検索」の機能目的として含まれているものと解することができる。

したがって、上記摘記事項(3a)によれば、引用文献3には「サポートを行う当たり、サポートを行う人員のスケジュール情報を格納するスケジュール記憶手段と当該スケジュール記憶手段で格納されたスケジュール情報を条件設定した検索によってサポートの提供が可能であるかを確認すること」が記載されているといえる。

(引用文献4)

また原査定で引用された「ビズネット,日経Windows,日本,日経BP社,2000年7月1日,第40号,130?132」(以下、「引用文献4」という。)には、

(4a)『オフィス用品のカタログ販売をしているビズネットは、インターネット上の電子メールを使った受注システム「Xmail」を新たに構築した』(第130頁第1欄第1行乃至第4行)

(4b)「今回の受注処理システムでは,日本アイ・ビー・エムのオフコンAS/400上にすでに存在している販売管理や在庫管理などの基幹システムと同期型で直接連携している。顧客からの注文を受けると,まずは基幹システムのデータベースを参照して在庫があることを確認。在庫が確認できた場合は出荷と引き当ての処理をしてから,顧客に受注確認のメールを返信する。もし在庫がなかった場合は,その旨を電話で連絡する。このため.受注しておきながら後で在庫がないということは発生しない。」(第131頁第2欄第4行乃至第17行)

がそれぞれ記載されている。

(サ)上記摘記事項(4a)及び上記摘記事項(4b)によれば、引用文献4には、慣用技術として、「受注処理システムが、すでに存在している基幹システムと直接連携することにより、顧客に対し受注確認として自動的にメールにて送信する手段を備えること」が記載されているといえる。

5.本願発明と引用文献1発明との対比

(1)一致点の認定

本願の発明の詳細な説明には、本願発明が備える構成である「サポート依頼情報」について、「サポート依頼情報は・・・注文商品の納品日を指定する納品日指定・・・等の情報を含む」(段落【0032】)と説明されており、当該「サポート依頼情報」の技術的事項は、引用文献1発明における「納入希望日の要求」を排除するものではないと解するのが相当である。

この点を踏まえて、本願発明と引用文献1発明を対比すると、

引用文献1発明における

「インターネットユーザ企業が使用するコンピュータからネットワークを介して商品の購入要求及び納入希望日を受け取るオンライン購買サービスを提供するOSNセンタ」、「インターネットユーザ企業とサプライヤとでネゴシアブルに個別に設定された該インターネットユーザ企業に対する各商品の販売価格を決定する仕切率」、「インターネットユーザ企業を含む行定義情報と関連付けて、データベースとして格納した仕切率テーブル」、「インターネットユーザ企業が作成した商品名及びその個数の情報、納入希望日の要求、並びに、インターネットユーザ企業を含む行定義情報を含む発注データを仮(未承認)の発注データとして保存する仮発注処理部」、「仮発注処理部で保存した発注データに基づいて」、「データベースを参照してインターネットユーザ企業を含む行定義情報に関連づけて格納された仕切率のうち発注データに含まれる商品及びその個数の情報に係わる仕切率を適用し」、「適用した仕切率、インターネットユーザ企業を含む行定義情報、商品及びその個数の情報によって、仮発注データを正発注データにする発注承認処理部」、「インターネットユーザ企業に対し、仕切率テーブルを更新する更新処理である商品情報管理を行う商品データベースサーバ」及び「出荷案内に示される発注データ及び納品日をユーザ企業に提供する処理を行う取引情報照会部」は、

本願発明における

「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システム」、「ユーザと販売業者とで予め該ユーザ用に決定した商品の対価の情報である対価情報」、「該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段」、「前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段」、「該受付手段で受け付けられた前記購入依頼情報に基づいて」、「前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報に係わる対価情報を読み出し」、「該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段」、「ユーザに対し、前記データベースを更新する対価更新手段」及び「前記購入依頼情報と共に配送日を、ユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段」

にそれぞれ相当し、

両者は、

(一致点)
「ユーザが使用するコンピュータからネットワークを介して商品の購入依頼及びサポートの依頼の受注を行う商品受注システムであって、

ユーザと販売業者とで予め該ユーザ用に決定した商品の対価の情報である対価情報を、該ユーザの個人情報であるユーザ個人情報と関連付けて、データベースとして格納したユーザ情報格納手段と、

前記コンピュータからネットワークを介して伝送又は当該商品受注システムのシステムユーザによって入力された、商品発注情報及びサポート依頼情報とユーザ情報とを含む購入依頼情報を受け付ける受付手段と、

該受付手段で受け付けられた前記購入依頼情報に基づいて、前記データベースを参照して前記ユーザ個人情報に関連付けて格納された前記対価情報のうち前記購入依頼情報に含まれる前記商品発注情報に係わる対価情報を読み出し、該読み出した対価情報、前記ユーザ個人情報、前記商品発注情報、及び前記サポート依頼情報によって、受注処理を行う受注処理手段と、

ユーザに対し、前記データベースを更新する対価更新手段と

前記購入依頼情報と共に配送日を、ユーザのファクシミリ装置又はコンピュータに送信する受注確認情報送信手段と

を有することを特徴とする商品受注システム」

である点で一致する。

(2)相違点の認定

そして、両者は、以下の点で相違する。

(相違点1)本願発明では、当該「サポート依頼情報」に係わる対価情報を設定するに当たり、受注処理手段及び対価更新手段が「サポートの対価の情報である対価情報」をユーザ情報格納手段に格納する構成及び「前記購入依頼情報に含まれるサポート依頼情報に係わる対価情報」を更新する構成をそれぞれ備えるのに対し、引用文献1発明では、サポート依頼情報に対して対価を設定することが明記されていないため、受注処理手段及び対価更新手段がそのような構成をそれぞれ備えていない点。

(相違点2)ユーザに対する対価更新手段における対価情報の計算方法について、本願発明は、「前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して」当該対価情報を更新する構成を備えるのに対し、引用文献1発明は、対価情報を更新する具体的な計算方法について明記されていないため、そのような構成を備えていない点。

(相違点3)配送日の決定とそれに付随する処理を行う各手段について、

本願発明は、『商品受注システムが「商品の在庫情報及びサポート人員のスケジュール情報を格納する在庫情報格納手段」』、「該在庫情報格納手段で格納された在庫情報に基づいて注文された商品及びサポートの提供が可能であるかを確認する在庫確認手段」及び「該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段」を備え、

そのために、

商品受注システムが、

「前記配送日決定手段によって決定された配送日に商品を配送するよう指示する」ものとして、「前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段」を備え、

受注確認情報送信手段が、

「前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又は電子メールにて」送信する構成を備えるのに対し、

引用文献1発明は、

商品受注システムに、販売業者から発注にかかる商品の出荷案内又は納期回答を送られる構成を備え、

そのために、

商品受注システムが、前記商品配送指示手段を備えておらず、

受注確認送信手段が、

商品受注システムが販売業者から商品の出荷案内又は納期回答を送られた後に、ユーザからの照会リクエストに応えて、前記購入依頼情報と共に配送日を、ユーザに提供する処理を行う構成を備える点。

6.相違点についての判断

(相違点1について)

引用文献1発明において、「サポート依頼情報」である「納入希望日の要求」における「サポート」である「納入」を実施するためには、当該「納入」のための人員を手当てすること、当該手当てした人員の人件費を「納入」に係わる「対価」として賄うこと、及び、当該「サポート」に係わる「対価」についてユーザと販売業者とで予め仕切値を決定することは、いずれも、商取引という技術分野における慣用技術であるから、引用文献1発明において、「サポート依頼情報」における「サポート」を実施するに当たり、当該「サポート」のための人員を手当てし、当該人員の人件費を当該「サポート」に係わる「対価」として賄うこと、及び、当該「対価」についてユーザと販売業者とで予め仕切値を決定することは、慣用技術の単なる適用に過ぎないものと認められる。

そして、引用文献1発明において、当該慣用技術に基づき、「サポート」に係わる「対価」を設定すれば、受注処理手段が「サポートの対価の情報である対価情報」をユーザ情報格納手段に格納すること、及び、ユーザと販売業者とで予め決定する仕切値に応じて、対価更新手段が「前記購入依頼情報に含まれるサポート依頼情報に係わる対価情報」を更新する構成を備えることは、当業者であれば当然なし得る事項と認められる。

したがって、相違点1に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。

(相違点2について)

技術常識を参酌すれば、引用文献1発明が備える「仕切率」は、ユーザと販売業者との間の取引量、すなわち商品発注及びサポート依頼の頻度に基づいて、その対価を割り引きすることに他ならないから、引用文献1発明において、対価更新手段における対価更新の計算方法について、前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し、前記ユーザの商品発注及びサポート依頼の頻度に基づいて、前記ユーザ情報格納手段で前記データベースに格納された前記対価情報を割り引いた値に変更して」対価情報を更新する構成を採用することは、当業者であれば当然なし得る事項と認められる。

また上記「仕切率」の実施の具体化手段として、当該「前記受付手段で受け付けられた前記購入依頼情報」に係る購入回数を頻度に積算することは、ユーザと販売業者との間で適宜に決める契約内容に過ぎないから、引用文献1発明において、「前記受付手段で受け付けられた前記購入依頼情報に係わるユーザに対し」て対価情報を更新する構成とすることは、当該ユーザと販売業者との間で適宜に決める契約内容に応じて当業者であれば適宜になし得る設計事項に過ぎない。

したがって、相違点2に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。

(相違点3について)

引用文献2に記載の「通知部」は、納入希望日を納期日として顧客に通知する前に、当該納入希望日を当該納期日として決定しているものと推認することができ、また当該「通知部」において当該納入希望日を当該納期日として決定するに際し、「在庫情報を格納する在庫テーブル」及び「当該在庫テーブルに格納された在庫情報に基づいて在庫の有無を確認する引当・発注部」を用いていると解することができるので、引用文献1発明において、商品の納期を得るに当たり、商品受注システムに、販売業者から発注にかかる商品の出荷案内又は納期回答を送られる構成に代えて、『商品受注システムが「商品の在庫情報を格納する在庫情報格納手段」』、「該在庫情報格納手段で格納された在庫情報に基づいて注文された商品の提供が可能であるかを確認する在庫確認手段」及び「該在庫確認手段による在庫の確認結果及び前記購入依頼情報によって該購入依頼情報に含まれる商品の配送日を決定する配送日決定手段」を備える構成を採用することは、引用文献2の記載に基づき当業者であれば適宜になし得るものである。

そして、引用文献1発明は「商品の購入依頼及びサポートの依頼の受注を行う商品受注システム」であることから、引用文献1発明において、商品及びサポートの受注に対応する当該商品及び当該サポートの納期を得るに当たり、上記「在庫テーブル」及び「引当・発注部」がそれぞれ取り扱う情報及び確認内容として、「サポート人員のスケジュール情報」及び「サポートの提供が可能であるかを確認」することを採用し、上記「在庫情報格納手段」及び上記「在庫確認手段」と引用文献3にみられるような周知技術である「サポート人員のスケジュール情報を格納する在庫情報格納手段」及び「該在庫情報格納手段で格納された在庫情報に基づいてサポートの提供が可能であるかを確認する在庫確認手段」とを併用することは、引用文献3の記載に基づき当業者であれば適宜になし得るものである。

また引用文献1発明において、商品受注システムが上記「配送日決定手段」を採用すれば、当該「商品受注システム」が決定した配送日を管理することとなるから、引用文献1発明において、当該商品受注システムが「前記受注処理手段における受注処理に基づいて前記ユーザ情報格納手段に格納された前記ユーザ個人情報を参照し、前記購入依頼情報に含まれる商品の配送及びサポートの提供を、ネットワークを介して外部コンピュータに指示する商品配送指示手段」を備えること、及び、当該「商品配送指示手段」が前記配送日決定手段によって決定された配送日に商品を配送するよう指示する」構成を備えることは、当業者であれば当然なし得る事項である。

また引用文献1発明において、商品受注システムが上記「配送日決定手段」を採用すれば、当該「商品受注システム」が決定した配送日を管理することとなるから、当該配送日を顧客に通知する具体化手段として、受注確認情報送信手段が「前記配送日決定手段によって決定された配送日を、受注確認として自動的にファクシミリ又は電子メールにてユーザのファクシミリ装置又は電子メールにて」送信する構成を採用することは、引用文献4にみられるような慣用技術の単なる選択に過ぎないものである

したがって、相違点3に係る本願発明の構成は、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に想到し得たものである。

そして,本願発明の作用効果も,引用文献及び周知技術から当業者が予測できる範囲のものである。

よって、本願発明は、引用文献1発明、引用文献2、引用文献3及び引用文献4に記載の発明並びに周知・慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものである。


7.むすび

上記のとおり、本願の請求項1に係る発明が、引用文献発明及び周知・慣用技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないため、本願の他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2009-06-01 
結審通知日 2009-06-02 
審決日 2009-06-18 
出願番号 特願2001-387798(P2001-387798)
審決分類 P 1 8・ 121- Z (G06Q)
最終処分 不成立  
前審関与審査官 山下 達也小太刀 慶明  
特許庁審判長 赤穂 隆雄
特許庁審判官 田代 吉成
清田 健一
発明の名称 商品受注システム、プログラム、及び記録媒体  
代理人 高野 明近  
  • この表をプリントする

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