【事件の表示】
　特願２０００−１２８０１３「代理購入方法とその代理購入システム、及び取引管理プログラムを記録した記録媒体」拒絶査定不服審判事件〔平成１３年１１月　２日出願公開、特開２００１−３０６８６４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　この出願は、平成１２年４月２７日の出願であって、平成１６年７月２３日付けで拒絶査定がなされ、これに対し、同年８月３０日に拒絶査定に対する審判請求がなされて、当審における審理の結果、平成２０年１２月２２日付けで拒絶理由が通知され、これに対し、平成２１年２月２３日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２．本件発明
　本件の請求項１に係る発明（以下「本件発明」という。）は、平成２１年２月２３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「【請求項１】
　利用者のユーザ端末から通信回線を介して販売者の購入先サーバにアクセスして商品の購入を行う電子商取引システム上で、前記通信回線を介して前記ユーザ端末及び購入先サーバと接続されるサーバ装置が電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法であって、
　前記サーバ装置に、前記販売者に関し、販売する商品と信用度を示す点数を含む取引の実績のデータを記録する取引管理データベースを備え、
　前記サーバ装置が、
　前記利用者のユーザ端末から、購入する商品の指定と、前記商品の購入先である通信回線を介して前記商品を販売する販売者の指定とを受信することにより、当該商品の代理購入の依頼を受け付けるステップと、
　前記利用者のユーザ端末から、購入する商品の指定により当該商品の代理購入の依頼を受け付けた場合に、依頼された商品を販売する前記販売者の信用度を示す点数を、前記取引管理データベースのデータから検索するステップと、
　指定された商品を販売する前記指定された販売者の前記取引管理データベースに記録された点数が定められた規定以上であるかどうかにより、代理購入可能かを判定するステップと、
　代理購入可能と判定された前記販売者の前記購入先サーバに対して、前記商品の購入のための処理を行うステップと、
　商品の配送業者に対し、前記販売者の前記購入先サーバから購入した商品と前記商品の前記利用者への配送先を指定して、前記購入先サーバから購入した商品の配送を指示する処理を行うステップと、
　前記利用者に提供する代理購入サービスに対する課金を管理するステップを備え、
　さらに、前記通信回線を介して商品を販売する前記販売者の前記利用者からの評価に基づいて、前記取引管理データベースに記録された前記販売者の信用度を示す点数を更新するステップと
　を有することを特徴とする代理購入方法。」
　
３．引用文献に記載された事項
（３−１）当審における拒絶の理由で引用した国際公開第００／１７８３４号（以下「引用文献１」という。）には、図面と共に、以下の記載がある。
　
（ア）「Electronic commerce is based on the electronic exchange of items, one of the typical exchanges is an electronic payment but it may also be a digitally signed contract. An important requirement for security in the exchange of items is fairness. An exchange is fair if, at the end of the transaction, either party receives the item he expected, neither party receives it, or each party obtains a legally binding receipt of the transaction which can be submitted to a third party for resolution, in the event that the received item does not meet expectations. At present, such commerce is typically conducted directly between a user and a merchant (of course, with the intervention of a bank in obtaining payment), representing a direct point-to-point contact on the Internet. 」（第１ページ第１２行〜同ページ第２０行） 
（仮訳：電子商取引は、物品の電子的交換に基づいており、典型的交換の１つに、電子支払があるが、これはデジタルで署名された契約であるかもしれない。物品の交換におけるセキュリティについての重要な要件は公正性である。取引終了時に、どちらの当事者も自分が期待した物品を受取るか、どちらの当事者もそれを受取らないか、または受け取った物品が期待に合わない場合に、解決を求めて第三者に提出することができる法的拘束力のある取引のレシートをそれぞれの当事者が得る場合に、交換は公正である。現在、そのような商取引は通常、ユーザと商人の間で直接的に行われ（もちろん支払を得る際には、銀行が仲介し）、インターネット上の直接的なポイント・ツー・ポイント・コンタクトになる。） 
（イ）「An object of the invention is to provide support for fair exchange and anonymity of the user with respect to the merchant. 」（第４ページ第２８行〜同ページ第２９行） 
（仮訳：本発明の一目的は、公正交換のサポート、および商人に対するユーザの匿名性を提供することである。） 
（ウ）「In an insurance context, representing a first embodiment of the invention, the method 10 operates on and between merchants 20a-20d who sell insurance and a user 18 which has established a commercial relationship with a trusted third party broker (TTP) 22 of insurance policies (i. e., an insurance broker).」（第６ページ第１行〜同ページ第４行） 
（仮訳：本発明の第１実施形態である保険取引の文脈において、方法１０は、保険を販売する商人２０ａ〜２０ｄと、保険証券の信用ある第三者ブローカ（「ＴＴＰ」）２２（すなわち、保険ブローカ）と取引関係を確立したユーザ１８との間で動作する。） 
（エ）「The TTP 22 is a trusted server which receives and processes requests for information about products or services, such as insurance policies, on the insecure network 12 such as the Internet. The method 10 achieves improved security in payments by splitting the payment into two parts: (1) that associated with the network link 14 between the user 18 and the TTP 22, and (2) that associated with the network link 24 between the TTP and the merchants 20a-20d.」（第６ページ第６行〜同ページ第１２行） 
（仮訳：ＴＴＰ２２は、保険証券などの商品またはサービスについての情報に対する要求を、インターネットなどの安全でないネットワーク１２上で受取り処理する、信用あるサーバである。方法１０は、（１）ユーザ１８とＴＴＰ２２の間のネットワーク・リンク１４に関連付けられた支払いと、（２）ＴＴＰと商人２０ａ〜２０ｄの間のネットワーク・リンク２４に関連付けられた支払い、の２つの部分に支払いを分けることにより、支払いのセキュリティ改善を達成する。） 
（オ）「Further, because the transaction is made through the TTP 22, the identify of the user 18 need not be revealed to the merchant 20d, thus making the transaction untraceable against observers and providing anonymity (with respect to the merchant) in the payment transaction for the user as well. Thus, only the TTP 22 need know the identity of the user 18. 」（第６ページ第２９行〜第７ページ第４行） 
（仮訳：さらに取引がＴＴＰ２２を介してなされるので、ユーザ１８の識別を商人２０ｄに明らかにする必要がなく、したがって、取引をオブザーバに対して追跡不能にし、ユーザに対する支払い処理においても（商人に対して）匿名性を提供する。したがって、ＴＴＰ２２だけしか、ユーザ１８の識別情報を知る必要がない。） 
（カ）「In addition, the TTP 22 itself may serve as a secondary certification authority. The TTP 22 accomplishes this secondary certification role in part by maintaining a list of infringers, merchants 20a-20d, and users 18 which have previously misbehaved, e. g., those who have not fulfilled an agreement established after a dispute was resolved. 」（第８ページ第７行〜同ページ第１１行） 
（仮訳：さらにＴＴＰ２２自体が、２次的な認可当局として役割を果たすことができる。ＴＴＰ２２は、違反者、すなわち過去に不正を行った商人２０ａ〜２０ｄ、およびユーザ１８、例えば紛争が解決された後に確立された合意を履行しなかった者のリストを維持管理することにより、この２次的認可の部分的な役割を達成する。） 
（キ）「Referring now to Figs. 1 and 3, the computerized method of the invention includes the following steps.  
　　In an accessing step 100, the method enables the user 18, preferably using a JAVA-enabled browser 102 (shown in Fig. 1) and a low resource-intensive secure communication protocol (i. e., a secure communications protocol demanding lesser computer resources than SET), such as SSL, to access the TTP 22 in order to request broker services (JAVA is a trademark, registered to Sun Microsystems, which identifies a programming language designed for creating small program objects for operation in a distributed environment such as the Internet 12).」（第１０ページ第１行〜同ページ第１０行） 
（仮訳： 次に図１および３を参照すると、本発明のコンピュータによる方法は次の諸ステップを含む。 
　アクセスするステップ１００において、本方法は、ユーザ１８が、好ましくはＪＡＶＡイネーブルのブラウザ１０２（図１に示す）およびＳＳＬなどのリソース低集約的な安全な通信プロトコル（すなわち、ＳＥＴより少ないコンピュータ・リソースを要求する安全な通信プロトコル）を用いて、ブローカ・サービスを要求するためにＴＴＰ２２にアクセスすることを可能にする（ＪＡＶＡは、Sun Microsystemsに登録された登録商標であり、インターネット１２のような分散環境において動作する小さいプログラム・オブジェクトを作成するために設計されたプログラム言語を表す）。） 
（ク）「In an information gathering step 106, the TTP 22 gathers information from web servers of the merchants 20a-20d which offer competitive products which the TTP believes may satisfy the request of the user 18. Any gathering process may be used. For example, the TTP 22 may access its own database in which the TTP maintains information about all merchants.」（第１０ページ第２０行〜同ページ第２４行） 
（仮訳：情報収集ステップ１０６において、ＴＴＰ２２は、ユーザ１８の要求を満足させることができるとＴＴＰが考える競合的商品を提案する商人２０ａ〜２０ｄのウェブ・サーバから情報を収集する。任意の収集処理を使用することができる。例えばＴＴＰ２２は、ＴＴＰがすべての商人についての情報を維持管理する自分自身のデータベースにアクセスすることができる。） 
（ケ）「In a comparing step 108, the browser 102 presents interactive windows or applets 110 and 112, shown in Figs. 4 and 5, respectively, to the user 18 which allows the user to compare differences between the products offered by competing merchants 20a-20d and choose between the competitive products. 」（第１１ページ第１行〜同ページ第４行） 
（仮訳：比較ステップ１０８においてブラウザ１０２は、ユーザが、競争する商人２０ａ〜２０ｄによって提案される商品間の相違を比較し、競合する商品間で選択できるようにする対話型ウィンドウ、または図４および５にそれぞれ示されたアプレット１１０および１１２をユーザ１８に提示する。）
（コ）「In a selecting step 120, the user 18 chooses between the competitive products, thus selecting a merchant 20d. 」（第１１ページ第１９行〜同ページ第２０行） 
（仮訳：選択ステップ１２０において、ユーザ１８は、競合商品の間で選択し、その結果として、商人２０ｄを選択する。） 
（サ）「In a first payment step 130, the user 18 activates thepayfunction 114, thus issuing a payment order to the TTP 22. 」（第１１ページ第２２行〜同ページ第２３行） 
（仮訳：第１の支払いステップ１３０において、ユーザ１８は、「支払い」機能１１４を活性化し、それによって、支払い指図をＴＴＰ２２に発行する。） 
（シ）「In a second payment step 140, the TTP 22 decrypts the payment information and transmits the payment order to the merchant 20d using a highly secure payment protocol, thus paying the merchant on behalf of the user 18.」（第１２ページ第１行〜同ページ第３行） 
 （仮訳：第２の支払いステップ１４０において、ＴＴＰ２２は、支払い情報を復号化し、高度に安全な支払いプロトコルを用いて商人２０ｄに支払い指図を送信し、それ故、ユーザ１８に代わって商人に支払う。） 
（ス）「In a third payment step 150, the merchant 20d and an associated bank 26 cooperate, again using the SET protocol, to enable the merchant to receive payments from the bank.」（第１２ページ第１２行〜同ページ第１４行） 
（仮訳：第３の支払いステップ１５０において、商人２０ｄと関連付けられた銀行２６は、再びＳＥＴプロトコルを用いて連携し、商人が銀行から支払いを受け取ることを可能にする。） 
（セ）「In addition, the TTP 22 verifies the merchant's certificate (identity) of the merchant 20d and sends its own certificate in the payment order. 」（第１２ページ第１７行〜同ページ第１８行） 
（仮訳：加えて、ＴＴＰ２２は、商人２０ｄの商人認可（識別）を検証し、支払い指図に自分自身の認可を出す。） 
（ソ）「 The merchant 20d then decrypts the message and sends the encrypted credit card information to the bank 26. The bank 26 processes the payment order, and issues a positive authorization for payment only if the balance on the bank account of the user 18 allows the payment. 」（第１２ページ第２０行〜同ページ第２３行） 
（仮訳：次いで商人２０ｄは、メッセージを復号化し、暗号化されたクレジット・カード情報を銀行２６に送る。銀行２６は、支払い指図を処理し、ユーザ１８の銀行口座上の残高が支払い可能である場合に限り、肯定的な支払い権限を発行する。） 
（タ）「In another feature of the invention, the computerized method 10 includes the additional step 160 of providing confirmation of payment on the payment order to the user 18 prior to delivery of the product purchased. In this step, the merchant 20d returns a message to the TTP 22 indicating whether or not the payment was successful. The TTP 22 then transmits this information to the user 18. When the payment is successful, this message can be used to prove legal liabilities, i. e., it can be considered as the receipt of the purchase. This receipt, once signed by all parties involved in the transaction, can be used as evidence in resolving the dissatisfaction of the user 18 with respect to the service received, thus helping guarantee a fair exchange in the electronic transaction. The TTP 22 is now able to return a detailed report to the user 18 about the transaction via the browser 102.」（第１３ページ第１行〜同ページ第１１行） 
（仮訳：本発明の他の機能では、コンピュータによる方法１０は、購入した商品の配達前に、支払い指図に対する支払い確認をユーザ１８に提供する追加ステップ１６０を含む。このステップにおいて、商人２０ｄは、支払いが正常であったかどうかを示すメッセージをＴＴＰ２２に戻す。次いでＴＴＰ２２は、この情報をユーザ１８に送信する。支払いが正常であるとき、このメッセージは、法的債務を証明するために使用することができる、すなわちこれを、購入のレシートと考えることができる。このレシートは、取引に関与するすべての当事者により署名されると、受け取ったサービスに関するユーザ１８の不満を解決する際に、証拠として使用することができ、したがって電子取引において公正交換を保証する助けとなる。次にＴＴＰ２２は、ブラウザ１０２を介して取引についての詳細な報告をユーザ１８に戻すことができる。） 
（チ）「In step 202, using a low resource-intensive secure communication protocol, the TTP 22 receives a request of a user 18 for information concerning products of interest. In step 204, the TTP 22 gathers the requested information from the merchants 20a-20d. In step 206, the TTP 22 transmits this requested information to the user 18 via an interactive window 110. In step 208, the user 18 selects a product offered by a merchant 20d and generates a payment order which the TTP 22 receives. In step 210, using a highly secure payment protocol, the TTP 22 transmits the payment order to the selected merchant 20d who may then receive payment thereon, and, subsequently, transmit confirmation of the payment to the TTP. In step 212, the TTP 22 transmits confirmation of payment to the user 18.」（第１４ページ第６行〜同ページ第１６行） 
（仮訳：ステップ２０２では、リソース低集約的な安全な通信プロトコルを用いて、ＴＴＰ２２が、関心のある商品に関する情報を求めるユーザ１８の要求を受け取る。ステップ２０４においてＴＴＰ２２は、要求された情報を商人２０ａ〜２０ｄから収集する。ステップ２０６において、ＴＴＰ２２は、この要求された情報を対話型ウィンドウ１１０を介してユーザ１８に送信する。ステップ２０８において、ユーザ１８は、商人２０ｄによって提案された商品を選択し、ＴＴＰ２２が受け取る支払い指図を生成する。ステップ２１０では、高度に安全な支払いプロトコルを用いて、ＴＴＰ２２が、選択された商人２０ｄに支払い指図を送信し、次いでこの商人は、それに対する支払いを受け取り、その後、支払い確認をＴＴＰに送信する。ステップ２１２においてＴＴＰ２２は、支払い確認をユーザ１８に送信する。） 
 　 
　上記摘記事項（ウ）及び（エ）の記載は、ユーザのユーザ端末からネットワークを介して商人の商人サーバにアクセスして商品の購入を行う電子商取引システム上で、前記ネットワークを介して前記ユーザ端末及び前記商人サーバと接続されるＴＴＰが電子商取引を仲介することを示し、上記摘記事項（シ）には、「paying the merchant on behalf of the user」（仮訳：ユーザに代わって商人に支払う）と記載されているので、引用文献１は、商品の代理購入のサービスを提供する代理購入方法を開示している。 
　上記摘記事項（ク）の記載は、ＴＴＰに、商人に関し、販売する商品のデータを記録するデータベースを備えることを示しており、上記摘記事項（カ）の記載は、ＴＴＰに、商人に関し、違反者のリストを維持管理する手段を備え、当該違反者のリストを維持管理することを示している。 
　上記摘記事項（コ）の記載は、ユーザのユーザ端末から、購入する商品の指定と、前記商品の購入先であるネットワークを介して前記商品を販売する商人の指定とを受信することを示しており、また、上記摘記事項（シ）の「paying the merchant on behalf of the user」（仮訳：ユーザに代わって商人に支払う）という記載が、ＴＴＰが、商品の代理購入を行うことを示していることを考慮すると、上記摘記事項（コ）の記載はその依頼を受け付けることを意味している。したがって、引用文献１には、ＴＴＰが、ユーザのユーザ端末から、購入する商品の指定と、前記商品の購入先であるネットワークを介して前記商品を販売する商人の指定とを受信することにより、当該商品の代理購入の依頼を受け付けることを開示している。 
　上記摘記事項（シ）及び（セ）の記載は、上記摘記事項（カ）の記載を踏まえると、ＴＴＰが、前記ユーザのユーザ端末から、購入する商品の指定により該商品の代理購入の依頼を受け付けた場合に、依頼された商品を販売する指定された商人を、違反者のリストから検索し、指定された商品を販売する前記指定された商人に関し、前記違反者のリストに基づいて、支払い指図を送信可能かを検証し、送信可能と検証された商人の商人サーバに対して、前記支払い指図を送信することを示している。 
　
　してみれば、引用文献１には、  
「ユーザのユーザ端末からネットワークを介して商人の商人サーバにアクセスして商品の購入を行う電子商取引システム上で、前記ネットワークを介して前記ユーザ端末及び前記商人サーバと接続されるＴＴＰが電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法であって、 
　前記ＴＴＰに、商人に関し、販売する商品のデータを記録するデータベースと、商人に関し、違反者のリストを維持管理する手段とを備え、 
　前記ＴＴＰが、 
　ユーザのユーザ端末から、購入する商品の指定と、前記商品の購入先であるネットワークを介して前記商品を販売する商人の指定とを受信することにより、当該商品の代理購入の依頼を受け付けるステップと、
　前記ユーザのユーザ端末から、購入する商品の指定により該商品の代理購入の依頼を受け付けた場合に、依頼された商品を販売する前記商人を、違反者のリストから検索するステップと、
　指定された商品を販売する前記指定された商人に関し、前記違反者のリストに基づいて、支払い指図を送信可能かを検証するステップと、 
　支払い指図を送信可能と検証された商人の商人サーバに対して、前記支払い指図を送信するステップを備え、
　さらに、前記違反者のリストを維持管理するステップと
　を有する代理購入方法。」の発明（以下「引用発明」という。）が記載されていると認められる。  
 　 
（３−２）当審における拒絶の理由で引用した特開平１０−２６１０１６号公報（以下「引用文献２」という。）には、図面と共に以下の事項が記載されている。  
 　 
（ツ）「【発明が解決しようとする課題】以上のようにネットワークを用いた商取引においてもその基礎となる信用を取り扱うメカニズムが必要となるが、従来の技術では買い手に対する売り手の信用を照会することが困難であった。」（第３ページ左欄第４５行〜同欄第４９行）  
（テ）「【発明の実施の形態】以下、図面を参照しながら発明の実施の形態を説明する。最初に、売り手の信用度、その求め方等について説明する。まず、複数の「売り手」と複数の「買い手」が存在し、それぞれネットワーク接続された端末装置を用いて、ネットワークを通じて相互に情報を交換して商取引を行うものとする。例えば、インターネットビジネスがこの商取引に該当する。 
【００２８】本実施形態では、上記のような場合において、複数の事業者などの買い手が集まって、売り手の信用照会を相互に行うためのグループを形成する。グループに属する買い手は、売り手との商取引の履歴に基づいて売り手ごとに信用の評価を行い、その結果を数値化する。そして、各買い手は、自身が直接評価した売り手の信用度だけではなく、グループ内の他の買い手の評価した当該売り手の信用度に自身からみた当該他の買い手に対する当該評価の信用度を表す重みを付けた間接的な信用度をも考慮し、これによって得た総合的な売り手の信用度を利用するもので、グループ内において総合的な売り手の信用照会を相互に行うようにする。」（第６ページ左欄第１７行〜同欄第３５行） 
（ト）「【００３１】売り手ｙの公的信用度を、ｐｕｂｌｉｋ（ｙ）で表すこととする。取引信用度とは、売り手と買い手の間の取引の履歴により決まる信用度と定義する。これは取引金額の規模や、顧客満足度に相当する。取引信用度には、直接取引信用度と間接取引信用度がある。 
【００３２】「直接取引信用度」は、ある買い手が、当該買い手自身と売り手との間の過去の直接取引により決定する信用度である。買い手ｘと売り手ｙとの間の直接取引信用度（買い手ｘからみた売り手ｙの直接取引信用度）を、ｄｉｒｅｃｔ（ｘ，ｙ）で表すこととする。 
【００３３】「間接取引信用度」は、買い手自身と売り手との間での取引とは独立し、第３者を通じて決まる信用度である。ここで第３者とは、信用照会を行うためにあらかじめ設定されたグループに属する他の買い手とする。
【００３４】買い手ｘから仲介する第３者を介した売り手ｙの間接取引信用度を、ｉｎｄｉｒｅｃｔｓ（ｘ，ｙ）で表すものとする。本実施形態では、買い手ｘからみた売り手ｙの間接取引信用度ｉｎｄｉｒｅｃｔｓ（ｘ，ｙ）を次のようにして求めるものとする。 
【００３５】ｉｎｄｉｒｅｃｔｓ（ｘ，ｙ）＝Σ ｗｅｉｇｈｔ（ｘ，ｚ）×ｄｉｒｅｃｔ（ｚ，ｙ） 
 ｚについて総和を取る範囲はグループ内の他の買い手 
 ここで、ｗｅｉｇｈｔ（ｘ，ｚ）は、「買い手ｘからみた買い手ｚの評価結果に対する信用度」であり、仲介する第３者ｚの売り手ｙに対する評価結果すなわち直接取引信用度ｄｉｒｅｃｔ（ｚ，ｙ）の自分にとっての信用度を重みとして表したものである。 
【００３６】さて、本実施形態では、総合信用度を、公的信用度と取引信用度の和として表すものとする。買い手ｘからみた売り手ｙの総合的な信用度ｃｒｅｄｉｔ（ｘ，ｙ）は、次のようにして求める。 
 ｃｒｅｄｉｔ（ｘ，ｙ）＝Ｋ×ｐｕｂｌｉｋ（ｙ）＋Ｌ×ｉｎｄｉｒｅｃｔｓ（ｘ，ｙ）＋Ｍ×ｄｉｒｅｃｔ（ｘ，ｙ） 
 ｉｎｄｉｒｅｃｔｓ（ｘ，ｙ）＝Σ ｗｅｉｇｈｔ（ｘ，ｚ）×ｄｉｒｅｃｔ（ｚ，ｙ）
 ただし、Ｋ，Ｌ，Ｍは定数 
 ｚについて総和を取る範囲はグループ内の他の買い手」（第６ページ左欄第４９行〜同ページ右欄第３７行） 
（ナ）「【００４２】ところで、直接取引信用度ｄｉｒｅｃｔや買い手ｘからみた買い手ｚの評価結果に対する信用度ｗｅｉｇｈｔは個々の買い手（上記した例における事業者の機密に関するものであり、これらのデータを公開しないことが前提となる。
【００４３】ｄｉｒｅｃｔやｗｅｉｇｈｔについて機密の保持し、かつ各買い手が上記の総合信用度を得ることができるようにする第１の方法は、ｄｉｒｅｃｔやｗｅｉｇｈｔのデータ全てを安全な公的サイトに格納し、公的サイトが各買い手の問い合わせに対して総合信用度のみを返す方法である。
【００４４】第２の方法は、機密データであるｄｉｒｅｃｔやｗｅｉｇｈｔは各買い手が自サイトに保持し、あらかじめグループを設定した買い手間でこのデータ自体が開示されないように、マジックナンバーを含んだ途中計算結果をリレーすることにより、総合信用度ｃｒｅｄｉｔ（ｘ，ｙ）を求める方法である。
【００４５】すなわち、買い手ｘが売り手ｙの総合信用度を求めるものとすると、ｗｅｉｇｈｔ（ｘ，ｙ）の情報を買い手ｘより他の各買い手ｚに直接個別に送信し、ｉｎｄｉｒｅｃｔ（ｘ，ｙ）の計算は買い手ｘを起点として他の各買い手ｚを巡回しながら和を加え、最後に買い手ｘに戻ることにより行う。このとき、ｗｅｉｇｈｔやｄｉｒｅｃｔの内容を開示しないようにするため、買い手ｘではｃｒｅｄｉｔの初期値にマジックナンバーｍ１を送り、ｗｅｉｇｈｔにはマジックナンバーｍ２を掛けて送る。ｘでは各ｚを一巡して受け取った結果からｍ１を減じ、ｍ２で割ることにより、正しい結果を得ることができる。
【００４６】本実施形態によれば、買い手の機密情報を開示することなく、該機密情報をもとにした買い手からみた売り手の信用度を求めることができる。また、直接取引のない売り手についても信用度の指標を得ることができる。」（第８ページ左欄第１３行〜同欄第４６行）
（ニ）「まず、各クライアント装置からサーバ装置へのデータの通知について説明する。 
【００５５】グループに属する各買い手側のクライアント装置２は、所定のタイミングで直接取引信用度ｄｉｒｅｃｔや重みｗｅｉｇｈｔのデータをサーバ装置６に通知する（ステップＳ１２）。 
【００５６】例えば、図４のように、サーバ装置を宛先とし、自装置を送信元とし、自身の買い手ＩＤと、データの通知を示すコードと、各売り手に対するｄｉｒｅｃｔやｗｅｉｇｈｔのデータとを含む通知メッセージを作成して、通信網４を通じてサーバ装置６に送信する。」（第８ページ右欄第４７行〜第９ページ左欄第８行） 
（ヌ）「【００６２】もし受信したメッセージが通知メッセージであった場合（ステップＳ２２）、通知されたデータを格納する（ステップＳ２３）。本実施形態では、サーバ装置６は、ｄｉｒｅｃｔ（ｘ，ｙ）とｗｅｉｇｈｔ（ｘ，ｚ）を図８に示すようなテーブルで管理するものとする。図８（ａ）はｉｎｄｉｒｅｃｔ（ｘ，ｙ）のテーブルの一例であり、図８（ｂ）はｗｅｉｇｈｔ（ｘ，ｚ）のテーブルの一例を示す。」（第９ページ左欄第３７行〜同欄第４４行） 
（ネ）「【００６７】次に、クライアント装置からサーバ装置への総合信用度の問い合わせと、これに応答してのサーバ装置からクライアント装置への返答について説明する。グループに属する各買い手は、クライアント装置２により、所望のタイミングで、サーバ装置６へ、買い手の総合信用度を問い合わせるための要求メッセージを送信する（ステップＳ１３）。 
【００６８】例えば、図５のように、サーバ装置を宛先とし、自装置を送信元とし、自身の買い手ＩＤと、信用度情報の要求を示すコードと、信用度情報を得たい１または複数の売り手の売り手ＩＤとを含む要求メッセージを作成して、通信網４を通じてサーバ装置６に送信する。 
【００６９】例えば、買い手Ｅは、売り手ＩＤとして、Ａ、Ｂ、Ｃ、Ｄを要求する。一方、サーバ装置６は、受信したメッセージが通知メッセージであった場合（ステップＳ２２）、通知メッセージ中に記載された買い手ＩＤの買い手ｘからみた各売り手ＩＤの売り手ｙの総合信用度ｃｒｅｄｉｔ（ｘ，ｙ）それぞれを、前述したようにして求め、要求元のクライアント装置２に送信する。」（第９ページ右欄第３０行〜同欄第４９行）
（ノ）「【発明の効果】本発明によれば、買い手の機密情報を開示することなく、該機密情報をもとにした買い手からみた売り手の信用度を求めることができる。」（第１３ページ右欄第２行〜同欄第４行）
 　 
　上記摘記事項（ヌ）の「本実施形態では、サーバ装置６は、ｄｉｒｅｃｔ（ｘ，ｙ）とｗｅｉｇｈｔ（ｘ，ｚ）を図８に示すようなテーブルで管理するものとする」という記載は、上記摘記事項（ト）の【００３２】の「買い手ｘと売り手ｙとの間の直接取引信用度（買い手ｘからみた売り手ｙの直接取引信用度）を、ｄｉｒｅｃｔ（ｘ，ｙ）で表す」という記載を踏まえると、サーバ装置に、売り手に関し、信用度を示す数値を記録するテーブルを備えることを示している。
　上記摘記事項（ニ）の「各売り手に対するｄｉｒｅｃｔやｗｅｉｇｈｔのデータとを含む通知メッセージを作成して、通信網４を通じてサーバ装置６に送信する」という記載、及び、上記摘記事項（ヌ）の「もし受信したメッセージが通知メッセージであった場合（ステップＳ２２）、通知されたデータを格納する」という記載は、通信網を介してサーバ装置のテーブルに記録された売り手の信用度を更新することを示しており、上記摘記事項（テ）の「グループに属する買い手は、売り手との商取引の履歴に基づいて売り手ごとに信用の評価を行い、その結果を数値化する。」という記載、及び、上記摘記事項（ト）の【００３２】の「「直接取引信用度」は、ある買い手が、当該買い手自身と売り手との間の過去の直接取引により決定する信用度である。」という記載から、テーブルに記録された信用度が、商品を販売する売り手の買い手からの評価に基づく数値であることは明らかである。したがって、引用文献２には、通信網を介して商品を販売する売り手の買い手からの評価に基づいて、テーブルに記録された売り手の信用度を示す数値を更新することが開示されている。
　
　してみれば、引用文献２には、 
「サーバ装置に、売り手に関し、信用度を示す数値を記録するテーブルを備え、通信網を介して商品を販売する売り手の買い手からの評価に基づいて、前記テーブルに記録された売り手の信用度を示す数値を更新すること。」が記載されていると認められる。  
 　 
（３−３）当審における拒絶の理由で引用した特開平１１−２５０１２９号公報（以下「引用文献３」という。）には、図面と共に以下の事項が記載されている。  
 　 
（ハ）「例えば、顧客からある通販業者の商品について受注情報が寄せられた場合、システム制御部は当該通販業者が委託した外部の倉庫業者から寄せられた在庫状況に関する情報を分析し、在庫切れの場合には同通販業者が委託した外部の生産業者に商品を発注し、商品納入の情報が入力された後には、同通販業者が委託した外部の配送業者に指令を発し、当該商品を顧客に届けさせるといったことが可能となる。また、顧客からある通販業者の商品についてクレーム情報が寄せられた場合にも、データベース群内の所定のデータベースに一旦これを格納しておき、所定の形に加工した上で通販業者はもちろん、外部の生産業者や配送業者にいち早く伝え、クレームの原因究明が実現される。」（第４ページ左欄第１４行〜同欄第２６行） 
（ヒ）「【発明の実施の態様】以下に本発明を、図示の実施例に基づいて説明する。図１は、この通販管理システム10の典型的な構成例を示すブロック図である。この通販管理システム10は、通販管理センタ12を中心に構成されている。通販管理センタ12は、このシステムを利用する複数の通販業者13からなる通販業者群14と、各通販業者13の顧客15の集合よりなる顧客群16、各通販業者13の指定（委託）する配送業者17の集合よりなる配送業者群18、各通販業者13の指定する生産業者19の集合よりなる生産業者群20、各通販業者13の指定する信販会社21の集合よりなる信販会社群22、各通販業者13の指定する倉庫業者23の集合よりなる倉庫業者群24との間に介在し、各通販業者13の通販事業の一部又は大部分を代行する機能を果たすものである。なお、各通販業者13の指定する外部受託業者の集合としては、上記配送業者群18、生産業者群20、信販会社群22、倉庫業者群24の他に、図示は省略したが銀行などの金融機関群、問屋などの流通業者群、カタログ制作業者群、あるいはコンサルタント業者群なども存在する。 
【００１５】上記通販管理センタ12は、通販事業を遂行する上で必要とされる様々な情報を、一定の基準に従って分類・整理して蓄積したデータベースの集合体としてのデータベース群25と、このデータベース群25を管理すると共に、この通販管理システム10全体の運用を統制するシステム制御部26と、各顧客15からの注文や問い合わせ、クレーム等の情報を処理するための受注処理部27と、各生産業者19に商品を発注したり、各配送業者17に配送指令を発し、あるいは各倉庫業者23に棚卸や倉移動の指令を発するす物流処理部28と、顧客15に請求書や督促状を発行したり、外部の信販会社21との間で債権譲渡等の交信を行う債権処理部29と、各通販業者13との間で情報交換を行う通販事業支援処理部30を備えている。 
【００１６】上記通販業者群14を構成する個々の通販業者13同士は、特に関連付けられている必要はなく、通常は相互に無関係である。ただし、この通販管理システム10を一定の資格要件を満たす通販業者13（例えば特定の業界団体に所属する業者）にのみ開放するよう運用することもできる。また、顧客群16を構成する多数の顧客15も、各通販業者13毎に類型化されてはいるが、個々の顧客15同士は相互に無関係である。 
【００１７】図２は、この通販管理システム10の具体的な構成例を示すイメージ図である。上記システム制御部26は、パーソナルコンピュータ（以下「パソコン」と称する）よりなるシステム管理サーバ31によって構成されており、このシステム管理サーバ31には通販システム全体を制御するためのシステム管理プログラム及びデータベース管理プログラムがセットアップされている。」（第４ページ右欄第１６行〜第５ページ左欄第１２行） 
（フ）「【００２０】例えば、顧客15から電話が受注処理部27に掛かってきた場合、管理センタ所属のオペレータが通販業者13に代わってこれを受け、注文や問い合わせ、クレームに応対すると共に、その結果生じた情報を入力端末36を使って入力する。入力された情報は、システム管理サーバ31を介してデータベース群25の所定のデータベース内に即時登録される。顧客15から郵便38やＦＡＸを通じて注文等が寄せられる場合も、受注処理部27において必要な対応がなされた後、一定の情報が所定のデータベース内に登録される。この場合、情報が発生する都度、入力端末36を使って入力することもできるが、一定時間毎にまとめてバッチ入力することもできる。パソコン通信を経由して顧客15からオンラインで注文等が寄せられた場合にも、一旦受注処理部27の通信専用端末35で受信し、様式チェック等の必要な処理を行った後、システム管理サーバ31に送信され、所定のデータベースに登録される。」（第５ページ左欄第２６行〜同欄第４２行）
（ヘ）「また、説明を容易にするため、通販管理センタ12の各処理部が独立して存在している例を示したが、各処理部の区別はその機能に着目した観念上のものであり、実際には各処理部間が明確に区別できない場合もある。例えば、受注処理部27を構成している端末が、同時に通販事業支援処理部30や債権処理部29の端末を兼ねていてもよい。」（第６ページ左欄第１７行〜同欄第２３行） 
（ホ）「【００６０】つぎに、図７のフローチャートに基づき、受注処理部27における処理の流れについて説明する。まず、顧客15から特定の通販業者13宛に注文を目的とした電話が掛かると（Ｓ１）、オペレータは相手方の語る顧客番号やカナ氏名、電話番号等を端末36ａに入力し、顧客マスタ60にアクセスして該当者が登録されているか否かを検索する（Ｓ２）。端末の画面上に「該当者なし」の表示がなされた場合（Ｓ３）には、その場で相手方の氏名や住所等の属性を入力し、顧客ＤＢに新規登録する（Ｓ４）。その後、相手方の指定したカタログの申込番号を入力して申込番号マスタ52にアクセスし、画面上に表示された商品名で間違いないかを確認する（Ｓ５）。他に注文したい商品がある場合には、全ての注文が終了するまで上記作業を繰り返し（Ｓ６）、最終的な数量の確認をする（Ｓ７）。その後、在庫ＤＢ67にアクセスして当該商品の在庫状況を画面上に表示させ、お届け予定日を案内する（Ｓ８）。つぎに、支払金額及び支払方法の確認（Ｓ11）、届け先の確認（Ｓ13）を行った後、受注情報として受注ＤＢ62及び受注明細ＤＢ63等に登録される（Ｓ14）。 
【００６１】システム管理サーバ31は、この受注ＤＢ62及び受注明細ＤＢ63に登録された受注情報を管理し、在庫ＤＢ67や入庫ＤＢ66のデータと照らしながら物流処理部28に必要な処理を指令する。例えば、在庫がある場合には、直ちに梱包してし配送する旨の指示を物流処理部28の端末画面に表示すると共に、配送業者用の伝票をプリンタ41から出力する。また、配送業者17の端末44にアクセスして回収予約を登録する。在庫がない場合には、直ちにその商品を生産する業者19の端末44にアクセスし、商品の発注を指示する。通販業者13自身が商品を供給することとなっている場合には、通販業者13の端末44に対して商品の発注がなされる。その商品が外部の倉庫業者23が保管している場合には、当該倉庫業者23の端末44にアクセスし、直ちに発送あるいは倉移動の指令が発せられる。 
【００６２】以上のようにして、受注案件は速やかに処理され、商品の出荷処理が実現される（Ｓ16）。また、上記のように一定の処理が行われる都度、在庫ＤＢ67や出荷累積ＤＢ70など関係データベース内のデータが更新されることはいうまでもない。」（第９ページ左欄第６行〜同欄第４５行） 
（マ）「【００６４】上記の物流処理と前後して、債権処理も実行される。例えば、顧客15が支払方法としてクレジットカードによる決済を選択した場合には、システム管理サーバ31は債権処理部29の端末46を通じて該当信販会社21の端末44にアクセスし、氏名やクレジットカード番号、支払回数等の必要なデータを送信して債権譲渡手続を行うと共に、入金情報が入金ＤＢ74に登録される。 
【００６５】顧客15が銀行振込を選択した場合には、システム管理サーバ31は受注ＤＢ62や請求累積ＤＢ73を参照し、請求書作成に必要なデータを債権処理部29の端末46に送信し、プリンタ47から請求書を出力させる。この請求書は、郵送によって顧客15のもとに届けられる。振込先が通販管理センタ12の管理する銀行口座である場合には、支援処理部30の端末48を介して通販業者13に対して入金報告がなされる。また、振込先が通販業者13の管理する銀行口座の場合には、通販業者13が入金を確認した後、支援処理部30の端末48を経由して入金ＤＢ74に入金情報が登録される。 
【００６６】一定期間経過後も顧客15からの入金が滞っている場合には、システム管理サーバ31から債権処理部29の端末46に督促状発行に必要なデータが送信され、プリンタ47から出力された督促状は顧客に送付される。同時に、督促ＤＢ75や督促履歴ＤＢ76のデータが更新される。」（第９ページ右欄第１９行〜同欄第４２行） 
 　 
　上記摘記事項（フ）の「パソコン通信を経由して顧客15からオンラインで注文等が寄せられた場合にも、一旦受注処理部27の通信専用端末35で受信し、様式チェック等の必要な処理を行った後、システム管理サーバ31に送信され、所定のデータベースに登録される」という記載は、電子商取引であることを示しているので、上記摘記事項（ハ）、（フ）及び（ホ）の記載から、引用文献３は、顧客からパソコン通信を介して通販業者の商品の購入を行う電子商取引システム上で、公衆回線を介して顧客の端末及び通販業者の端末と接続されるシステム管理サーバが電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法を開示している。 
　また、上記摘記事項（フ）の「パソコン通信を経由して顧客15からオンラインで注文等が寄せられた場合にも、一旦受注処理部27の通信専用端末35で受信し、様式チェック等の必要な処理を行った後、システム管理サーバ31に送信され」という記載は、上記摘記事項（ヒ）の「このシステムを利用する複数の通販業者13からなる通販業者群14」という記載を踏まえると、システム管理サーバが、顧客から購入する商品の指定と商品の購入先である通販業者の指定とを受信することにより、当該商品の代理購入の依頼を受け付けることを示している。 
　上記摘記事項（フ）の「システム管理サーバ31に送信され、所定のデータベースに登録される」という記載及び上記摘記事項（ホ）の「受注情報として受注ＤＢ62及び受注明細ＤＢ63等に登録される」という記載は、システム管理サーバが、商品の購入のための処理を行うことを示している。 
　そして、上記摘記事項（ホ）の「在庫がある場合には、直ちに梱包してし配送する旨の指示を物流処理部28の端末画面に表示すると共に、配送業者用の伝票をプリンタ41から出力する」、「通販業者13自身が商品を供給することとなっている場合には、通販業者13の端末44に対して商品の発注がなされる」という記載は、システム管理サーバが、商品の配送業者に対し、通販業者の端末から購入した商品と前記商品の顧客への届け先を指定して、前記通販業者の端末から購入した商品の配送を指示する処理を行うことを示している。 
 　 
　したがって、引用文献３には、 
 「顧客からパソコン通信を介して通販業者の商品の購入を行う電子商取引システム上で、公衆回線を介して顧客の端末及び通販業者の端末と接続されるシステム管理サーバが電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法であって、 
　システム管理サーバが、 
　顧客から、購入する商品の指定と商品の購入先である通販業者の指定とを受信することにより、当該商品の代理購入の依頼を受け付けるステップと、
　前記商品の購入のための処理を行うステップと、 
　商品の配送業者に対し、前記通販業者の端末から購入した商品と前記商品の前記顧客への届け先を指定して、前記通販業者の端末から購入した商品の配送を指示する処理を行うステップと 
　を有する代理購入方法。」が記載されていると認められる。
　
４．対比
　そこで、本件発明と引用発明とを対比する。 
 　 
　まず、引用発明の「ユーザ」、「ネットワーク」、「商人」、「商人サーバ」、「ＴＴＰ」、「支払い指図を送信可能」、「検証」、「前記支払い指図を送信する」が、それぞれ、本件発明の「利用者」、「通信回線」、「販売者」、「購入先サーバ」、「サーバ装置」、「代理購入可能」、「判定」、「前記商品の購入のための処理を行う」に相当する。 
　また、引用発明の「違反者のリスト」は、信用情報を含む取引の実績のデータである点で、本件発明の「信用度を示す点数を含む取引の実績のデータ」と共通し、引用発明の「データベース」と「リストを維持管理する手段」は共に記憶手段という概念に包摂される点で、本件発明の「取引管理データベース」と共通する。 
　そして、引用発明の「検証するステップ」と本件発明の「判定するステップ」とは、指定された商品を販売する前記指定された販売者の記憶手段に記録された信用情報に基づいて、代理購入可能かを判定するステップである点では共通する。 
 　 
　そうすると、本件発明と引用発明とは、 
「利用者のユーザ端末から通信回線を介して販売者の購入先サーバにアクセスして商品の購入を行う電子商取引システム上で、前記通信回線を介して前記ユーザ端末及び購入先サーバと接続されるサーバ装置が電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法であって、 
　前記サーバ装置に、前記販売者に関し、販売する商品と信用情報を含む取引の実績のデータを記録する記憶手段を備え、 
　前記サーバ装置が、 
　前記利用者のユーザ端末から、購入する商品の指定と、前記商品の購入先である通信回線を介して前記商品を販売する販売者の指定とを受信することにより、当該商品の代理購入の依頼を受け付けるステップと、 
　前記利用者のユーザ端末から、購入する商品の指定により当該商品の代理購入の依頼を受け付けた場合に、依頼された商品を販売する前記販売者の信用情報を、前記記憶手段のデータから検索するステップと、
　指定された商品を販売する前記指定された販売者の記憶手段に記録された信用情報に基づいて、代理購入可能かを判定するステップと、 
　代理購入可能と判定された前記販売者の前記購入先サーバに対して、前記商品の購入のための処理を行うステップ
　を有する代理購入方法。」 
 である点で一致し、以下の点で相違している。  
 　 
相違点１  
　本件発明では、信用情報を点数で示して、当該点数が定められた規定以上であるかどうかにより、代理購入可能かを判定し、かつ、通信回線を介して商品を販売する販売者の利用者からの評価に基づいて、当該点数を更新するのに対し、引用発明では、違反者のリストを用いて判定している点。 
 　 
相違点２  
　本件発明では、販売する商品と取引の実績データとを同一の取引管理データベースに記録しているのに対し、引用発明では、販売する商品と取引の実績データとを別々の記憶手段に記録している点。 
 　 
相違点３  
　本件発明では、商品の配送業者に対し、前記販売者の前記購入先サーバから購入した商品と前記商品の前記利用者への配送先を指定して、前記購入先サーバから購入した商品の配送を指示する処理を行うステップを有するのに対し、引用発明では、そのようなステップを有するか否かは明らかでない点。 
 　 
相違点４ 
　本件発明では、利用者に提供する代理購入サービスに対する課金を管理するステップを有するのに対し、引用発明では、そのようなステップを有するか否かは明らかでない点。 
　
５．判断
（５−１）相違点１について 
　引用文献２記載の「売り手」、「数値」、「テーブル」、「通信網」、「買い手」が、それぞれ、本件発明の「販売者」、「点数」、「取引管理データベース」、「通信回線」、「利用者」に相当するから、引用文献２には、「サーバ装置に、販売者に関し、信用度を示す点数を記録する取引管理データベースを備え、通信回線を介して商品を販売する販売者の利用者からの評価に基づいて、前記取引管理データベースに記録された販売者の信用度を示す点数を更新すること。」という技術が示されている。 
　そして、引用発明の「違反者のリスト」と引用文献２記載の技術の「信用度を示す点数」とは、販売者の信用情報である点で共通しているので、当業者であれば、引用発明の「違反者のリスト」に代えて、引用文献２記載の技術の「信用度を示す点数」を採用することは、容易に想起し得た事項である。 
　したがって、引用文献２記載の技術に基づいて、引用発明においても、信用情報を点数で示して、当該点数が定められた規定以上であるかどうかにより、代理購入可能かを判定し、かつ、通信回線を介して商品を販売する販売者の利用者からの評価に基づいて、当該点数を更新する構成とすることは、当業者が容易に想起した事項である。
　
　ところで、審判請求人は、平成２１年２月２３日付けの意見書において、引用文献２の段落００６５には、「サーバ装置６は、・・・公的信用度ｐｕｂｌｉｋ（ｙ）が更新された場合、そのテーブルにおいて該当するデータを更新する」と記載され、段落００３０には、「公的信用度」とは、「何らかの公的機関が認定した個々の事業者の信用度」と記載されていることから、引用文献２に記載の公的信用度が、買い手からの評価に基づいた信用度ではないことが明らかであり、また、引用文献２に記載の公的信用度が、買い手からの評価に基づいた信用度でないことは、引用文献２の段落０００７の「買い手が連合して相互に過去の取引に基づいて信用情報を交換する方法も考えられるが、企業間では過去の取引情報は機密であり、それを全面的に開示することがマイナス面が大きいため、現実的ではない。」と記載されていることからも分かり、相違点１に係る本件発明の構成が、引用文献２記載の技術に基づいて、当業者が容易に想起し得るとは到底言えないと主張している。
　しかし、上記「３．（３−２）」で述べたとおり、引用文献２記載の技術では、信用情報として、公的信用度以外に直接取引信用度も用いており、サーバ装置に格納された直接取引信用度は買い手からの評価に基づいて更新されるものである。信用情報として、公的信用度以外に直接取引信用度を用いることは、上記摘記事項（ト）の【００３１】の「取引信用度とは、売り手と買い手の間の取引の履歴により決まる信用度と定義する。これは取引金額の規模や、顧客満足度に相当する。取引信用度には、直接取引信用度と間接取引信用度がある。」という記載、及び、同じく摘記事項（ト）の【００３６】の「本実施形態では、総合信用度を、公的信用度と取引信用度の和として表すものとする。」という記載によっても示されており、また、直接取引信用度が買い手からの評価に基づいた信用度であることは、上記摘記事項（テ）の「買い手は、売り手との商取引の履歴に基づいて売り手ごとに信用の評価を行い」という記載、及び、上記摘記事項（ト）の【００３２】の「「直接取引信用度」は、ある買い手が、当該買い手自身と売り手との間の過去の直接取引により決定する信用度である」という記載が示している。
　そして、上記摘記事項（ナ）及び（ノ）には、買い手の機密情報を開示することなく、該機密情報をもとにした買い手からみた売り手の信用度を求めることができることが示されている。
　一方、審判請求人が主張の根拠としている段落００６５、段落００３０、段落０００７は、いずれも、平成２０年１２月２２日付けの拒絶理由通知書の［請求項１について］（１−２）において摘記した事項ではなく、また、審判請求人は、上記意見書において、信用情報として、引用文献２に開示された取引信用度を採用することができない理由を明らかにしていない。
　それ故、「相違点１に係る本件発明の構成が、引用文献２記載の技術に基づいて、当業者が容易に想起し得るとは到底言えない」という審判請求人の主張は、採用することができない。
　
　よって、相違点１に係る本件発明の構成は、当業者ならば容易に想到した事項である。
　
（５−２）相違点２について 
　複数種類のデータを１つの記憶手段に記録するか、１つの記憶手段に１種類ずつのデータを記録するかは、技術の具体的適用に際して適宜に設計すべき事項にすぎないので、当業者ならば、引用発明において、販売する商品と取引の実績データとを同一の取引管理データベースに記録する構成とすることは、当業者が適宜に為し得た事項である。 
　よって、相違点２に係る本件発明の構成は、当業者ならば容易に想到した事項である。
 　 
（５−３）相違点３について 
　引用文献３記載の「顧客」、「顧客の端末」、「公衆回線」、「通販業者」、「通販業者の端末」、「システム管理サーバ」、「届け先」が、それぞれ、本件発明の「利用者」、「ユーザ端末」、「通信回線」、「販売者」、「購入先サーバ」、「サーバ装置」、「配送先」に相当するので、引用文献３記載の技術は、通信回線を介してユーザ端末及び購入先サーバと接続されるサーバ装置が電子商取引を仲介して商品の代理購入のサービスを提供する代理購入方法である点で、引用発明と共通している。 
　そして、引用文献３の上記摘記事項（ハ）の「顧客からある通販業者の商品についてクレーム情報が寄せられた場合にも、データベース群内の所定のデータベースに一旦これを格納しておき、所定の形に加工した上で通販業者はもちろん、外部の生産業者や配送業者にいち早く伝え、クレームの原因究明が実現される」という記載は、引用文献３記載の発明の解決しようとする課題が、引用文献１の上記摘記事項（イ）に記載された「support for fair exchange」（仮訳：公正交換のサポート）という引用発明の解決しようとする課題と共通することを示しており、また、引用文献１の上記摘記事項（タ）の「prior to delivery of the product purchased」（仮訳：購入した商品の配達前に）という記載は、引用発明においても、購入した商品は配達されることを前提としていることを示している。
　それ故、引用発明に引用文献３記載の「商品の配送業者に対し、通販業者の端末から購入した商品と前記商品の顧客への届け先を指定して、前記通販業者の端末から購入した商品の配送を指示する処理を行う」という技術、すなわち、「商品の配送業者に対し、販売者の購入先サーバから購入した商品と前記商品の前記利用者への配送先を指定して、前記購入先サーバから購入した商品の配送を指示する処理を行う」という技術を付加することは、当業者が容易に想起し得た事項である。 
　よって、相違点３に係る本件発明の構成は、当業者ならば容易に想到した事項である。  
 　 
（５−４）相違点４について 
　提供したサービスを有償として課金を行うことは広く行われている周知事項であり、無償で代理購入サービスを提供するか、有償で代理購入サービスを提供するかは、適宜に決定すべきビジネス上の戦略にすぎないから、引用発明に当該周知事項を適用して、利用者に提供する代理購入サービスに対する課金を管理する構成を引用発明のサーバ装置に付加することは当業者が容易に想起し得た事項である。 
　よって、相違点４に係る本件発明の構成は、当業者ならば容易に想到した事項である。  
 　 
（５−５）まとめ  
　そして、本件発明の効果は、引用文献１〜３に記載された事項及び周知事項から当業者が予測できる範囲内のものである。  
　したがって、本件発明は、引用文献１〜３に記載された発明及び周知事項に基づいて、当業者が容易に発明することができたものである。 
　
６．むすび
　以上のとおり、本件発明は、引用文献１〜３に記載された発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本件の他の請求項について検討するまでもなく、本件出願は拒絶されるべきものである。 
　
　よって、結論のとおり審決する。