【事件の表示】
　特願２０００−　３４０９３「取引支援設備」拒絶査定不服審判事件〔平成１３年　８月１７日出願公開、特開２００１−２２２６１６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明 
　本願は、平成１２年２月１０日の出願であって、その請求項１に記載された発明は、平成１５年１月６日付けの手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。（以下、「本願発明」という。）
　「【請求項１】複数の荷主と複数の物流業者との間で交わされる荷物配送に係る取引を、コンピュータシステムを介して支援するための取引支援設備であって、
　荷主の希望する配送場所、荷物内容等の発注条件を含む発注依頼を受け付け、発注依頼データとして当該荷主に関連付けて記憶する荷主用入力支援手段と、
　物流業者の希望する価格提示等の受注条件を含む受注希望を受け付け、受注希望データとして当該物流業者に関連付けて記憶する物流業者用入力支援手段と、
　これら発注依頼データ及び受注希望データを基に、前記発注依頼データ毎に、その発注条件を満たす受注条件を含んだ前記受注希望データを自動検索し抽出する自動検索手段と、
　この自動検索手段により抽出した受注希望データのなかから、最も好受注条件を含むものを選択し、この選択した受注希望データを、当該発注依頼データに対する受注決定データとしてデータベースに記憶させる受注決定手段と、
　前記発注依頼データが所定期間以上先であって予約受注を指定したものである場合には、所定期間以上先の受注を希望する受注条件を含む受注希望データを抽出し、この抽出した受注希望データのみを対象に自動検索手段及び受注決定手段による受注決定が行われるようにするスケジュラーと、
　前記受注決定手段により選択されなかった受注希望データを、まだ受注が決定していない発注依頼データに対して前記自動検索手段が受注希望データを検索する際の検索対象に自動的に加える繰越手段とを具備することを特徴とする取引支援設備。」
　
２．引用例 
（１）原査定の拒絶の理由に引用された特開平１１−２３２３５３号公報（以下、「引用例１」という。）には、
　ア　「【発明の属する技術分野】本発明は、例えば、花卉や青果物等のライフサイクルの短い生鮮商品や、有効期限のあるチケット等のサービス商品、使用日が限れた航空チケットのように、ある期間が過ぎてしまうと商品価値がなくなる或いは減少する各種商品の売買取引に用いられる商品取引装置、商品取引システム、及び該取引を行うための処理ステップをコンピュータが読出可能に格納した記憶媒体に関するものである。」（２頁２欄４２行〜４９行）、
　イ　「そこで、本発明は、上記の欠点を除去するために成されたもので、計画的な商品の生産及び販売、計画的な商品の調達を画面上で容易に効率的に可能とすることで、商品の売買取引の効率を飛躍的に向上させることを可能とする商品取引装置、商品取引システム、及び該取引を行うための処理ステップをコンピュータが読出可能に格納した記憶媒体を提供することを目的とする。」（３頁３欄４３行〜５０行）、
　ウ　「生花取引システム１００では、上記図１に示すように、生花の市場管理を行うサーバ側の端末装置１０１と、複数の売手業者側の端末装置１１１〜１１４及び１４１、複数の買手業者側の端末装置１２１〜１２３及び１５１、及び中卸業者側の端末装置１３１とが、ＷＡＮ１６１を介して互いに通信可能に接続された構成としている。ここで、複数の売手業者の中には、大手業者（大手売手）や小口の業者（小口売手）も含まれており、また、複数の買手業者の中にも大手業者（大手買手）や小口の業者（小口買手）も含まれているものとする。そして、サーバ側、売手業者側、買手業者側、及び中卸業者側の各端末装置は、例えば、中央処理装置（ＣＰＵ）、キーボード、マウス、表示器、通信器、及び本システムの処理プログラムが予め格納されたメモリ等を備えたパーソナルコンピュータ（パソコン）からなり、該メモリの処理プログラムをＣＰＵにより読み出して実行することで、後述する種々の処理を行うようになされている。」（４頁５欄４４行〜６欄１２行）、
　エ　「上記図２に示すように、サーバ側の端末装置３００は、種々の情報の受信及び送信（配信）を行うための情報受信配信機能３１０と、アプリケーション機能（ＡＰＰ機能）としての取引処理及び価格形成機能３２１、価格予想機能３２２、システム運用管理機能３２３、個人別マーケット分析機能３２４、及び個人別データ配信管理機能３２５と、トランザクションデータやマスターデータを記憶すると共に各種処理に必要なデータを記憶するための記憶機能（データベースメモリ：ＤＢＭ）３３０とを有している。」（４頁６欄４５行〜５頁７欄４行）
　オ　「（Ｂ）販売情報に基づいた取引処理
（第２の取引：販売情報に基づく予約相対取引）本取引処理は、例えば、図８（Ｂ）に示すような流れに従って実行される。売手業者は、自端末装置のトップ画面（上記図５）上で「予約」の項目を選択し指定する。これにより、装置は、販売情報入力可能状態とな。そして、売手業者は、希望する生花の品目、品種、色、着荷日、等階級、産地、生産者名、箱数、及び価格等の販売希望情報である販売情報（出荷情報）をキーボード入力する。この結果、例えば、図９に示すような出荷情報一覧が作成され、上述した結果表示部２０２に画面表示される。この出荷情報一覧は、上述の入力された販売情報の他、未成約の選定の箱数（残箱数）の情報も含む。そして、このような販売情報は、サーバ側に送られる。このようにして、売手業者は、自端末装置上で生花の販売を行う。買手業者は、自端末装置にて、例えば、図１０に示すような、売手業者が発した販売情報を画面上で希望商品を検索し参照することで、希望する品の箱数等を購入登録情報としてキーボード入力する。このとき、希望する箱数の一部の登録も行うことができる。例えば、出荷情報の残箱数が５０箱であり、買手業者が本来希望する箱数は２０箱であるが、そのうちの１０箱のみを登録することもできる。そして、このような購入登録情報は、サーバ側に送られる。このようにして、買手業者は、売手業者が発した出荷情報に対して、自端末装置上で購入登録する（タイプ１）。売手業者は、自端末装置にて、買手業者の登録状況を画面上で参照して判断し、買手業者と成約する。尚、買手業者側において、上述したような購入登録を行う際（タイプ１）、購入価格の指定を行って、これを購入登録情報とすることもできる（タイプ２）。この場合、例えば、売手業者側の端末装置において、複数の買手業者から指定された各購入価格に基づいて、適切な買手業者、例えば、最も購入価格の高い買手業者を自動的に決定するようなアルゴリズムを実行させるようにしてもよい。また、販売情報で残数１０箱に対し、買手業者は、購入登録情報として、例えば、６箱とし、且つ、６箱以下でも購入する旨の情報を登録することもできる。これにより、残数１０箱に対して、甲乙２名の買手業者が各々６箱の購入登録しても、甲が６箱以下でも購入するという情報であれば、乙に６箱、甲に４箱、という成約も可能となる。」（７頁１１欄４７行〜１２欄４１行）
　カ　「（Ｃ）複数の購入情報及び複数の販売情報に基づいた取引処理
（第３の取引：複数の購入情報と複数の販売情報を同時に双方の条件の折り合うものから順次成約決定する取引）本取引処理は、例えば、上記図８（Ｃ）に示すような流れに従って実行される。ここで、本取引処理は、２つの取引処理（Ｃ１の取引処理、Ｃ２の取引処理とする）に分けられ、これらの２つの取引処理が、買手となる場合のトップ画面（上記図４）の「一般Ｉ」と「一般ＩＩ」に対応する。そして、Ｃ１の取引処理とＣ２の取引処理は、例えば、買手業者が上述したような購入登録する際に、詳細は後述するが、売手業者側が発した販売情報に対して行う購入登録の方法が異なる。そこで、売手業者は、上述した（Ｂ）の取引処理の結果、販売情報として発した数量を全て裁ききれなかった場合、具体的には、ある生花を１００箱、販売希望したにも関わらず、そのうちの６０箱しか買手業者と成約できなかった場合、４０箱が残ってしまう。このような販売漏れの生花（未成約の生花）がある場合には、売手業者は、自端末装置にて、未成約の生花を検索し、その情報を得て、トップ画面（上記図５）の「複写」項目を選択し指定することで、販売漏れの生花、すなわち（Ｂ）の取引処理での生花のうち販売漏れの生花についてを、本取引処理に移行する。そして、売手業者は、販売漏れの生花について、（Ｂ）の取引処理と同様にして、販売情報をキーボード入力する。また、このとき、新規に販売希望する生花があれば、それについての販売情報も入力する。このときに、下限価格情報（販売下限価格値）も入力する。そして、このような販売情報は、サーバ側に送られる。また、他の売手業者も同様にして各々、自端末装置にて、販売希望する生花の販売情報を入力する。そして、各売手業者の販売情報も、サーバ側に送られる。したがって、サーバ側には、複数の売手業者の販売情報が存在することになる。尚、トップ画面（上記図５）の「複写」による処理についての詳細は後述する。買手業者は、自端末装置にて、複数の売手業者が発した販売情報を画面上にて参照し、希望する条件に合った販売情報に対して、（Ｂ）の取引処理と同様にして、購入登録するが、このとき、上述のＣ１の取引処理、或いは、Ｃ２の取引処理で購入登録する。すなわち、Ｃ１の取引処理で購入登録する場合、買手業者は、自端末装置のトップ画面（上記図４）上で「一般Ｉ」を選択し指定する。これにより、装置は、上述のように、複数の売手業者が発した販売情報の参照可能状態となり、購入登録可能状態となる。ここでの購入登録は、例えば、希望する生花の”品目”及び”色”のみの条件を特定できるようになされている。一方、Ｃ２の取引処理で購入登録する場合、買手業者は、自端末装置のトップ画面（上記図４）上で「一般ＩＩ」を選択し指定する。これにより、装置は、Ｃ１の取引処理と同様に、複数の売手業者が発した販売情報の参照可能状態となり、購入登録可能状態となるが、ここでの購入登録は、例えば、希望する生花の”品目”及び”色”のみならず、”品種”や”等階級”等、その他の詳細な条件を特定できるようになされている。また、買手業者は、このような詳細な条件を複数の販売情報に対して特定できるようになされている。そして、このような購入登録情報は、サーバ側に送られる。また、他の買手業者も同様にして各々、自端末装置にて、複数の売手業者が発した販売情報を参照して、Ｃ１或いはＣ２の取引処理で購入登録する。したがって、サーバ側には、複数の売手業者が発した販売情報と、複数の買手業者が発した購入登録情報とが存在することになる。尚、このときの画面の結果表示部２０２に表示される販売情報には、”下限値”の情報は含まれない。サーバ側では、所定の成約決定アルゴリズムによる成約決定処理により、複数の売手業者が発した販売情報と、複数の買手業者が発した購入登録情報とに対して、双方の条件の折り合うものから順次成約（価格）を決定する。尚、ここでの成約決定アルゴリズムは、例えば、販売下限価格の条件を満たし、且つ、購入価格の高い順、購入情報の入力時間の早い順等により成約を決定するものである。この成約決定についての情報は、売手業者側及び買手業者側に通知される。これにより、売手業者及び買手業者は各々、自端末装置にて、成約決定について認識する。尚、上述した成約決定アルゴリズムでは、購入希望価格の高い順や情報入力の早い順に成約決定するようにしたが、これに限らず、例えば、購入希望数量の多い順や過去の取引規模などの因子により予め決められた優先順位に従って成約決定するようにしてもよい。或いは、購入希望数量の一部でも販売残数があれば購入したいという要求をも許容して、これを優先順位決定に反映させて成約決定してもよい。したがって、例えば、購入希望価格の高い順に成約決定する場合で、同じ価格の購入情報が存在した場合、それらの中でさらに数量の多い順や、情報入力の早い順、或いは上述の購入希望数量に欠けが存在した場合の購入許可など、買手業者側の購入条件に許容範囲の広いもの、などの一部或いはこれらの組み合わせのアルゴリズムを用いるようにしてもよい。また、対象商品の条件許容度が高い（条件が緩い）場合に、（Ｃ）の取引処理へ移行し、許容度が低い（条件が厳しい）場合には、（Ｃ）の取引処理に移行しない、というようなアルゴリズムを付加するようにしてもよい。また、売手業者が発する販売情報中に下限価格情報（販売下限価格値）を含むようにしたが、下限価格情報を”０”（ゼロ）とし、完全な販売委託方式にしてもよし、下限価格情報の代わりに別のパラメータを用いるようにしてもよい。例えば、販売最低本数の情報を用いるようにしてもよい。また、Ｃ１及びＣ２の取引処理での条件入力（Ｃ２では詳細は条件入力、Ｃ１では該条件を緩和した条件入力）を、買手業者が決定して行うものとしたが、例えば、システム内で予め各々の項目（「品種」、「品目」、「色」等）及びその内容（例えば、項目「品目」であれば、「菊」、「バラ」等の内容）を設定しておき、その中から買手業者が所望する項目及びその内容（条件）を指定するようにしてもよい。具体的には例えば、取引対象商品が野菜であった場合、「品種」、「規格」のみの条件と、この「品種」、「規格」に産地・生産者名の条件とを予めテーブル等で用意しておく。また、航空チケットの場合には、フライト日と区間のみの条件と、これに航空会社名或いは具体的な便名（複数も可）等の複数の条件を予め用意しておく。これにより、買手業者は、多様な条件の設定を行うことができる。」（７頁１２欄４２行〜９頁１５欄９行）、
　キ　「「複写」による処理（複写処理）は、上述したように、売手側において、（Ｂ）の取引処理の結果、販売漏れがあった場合に行われる処理であり、この複写処理を実行することで、（Ｂ）の取引処理が（Ｃ）の取引処理に移行される。すなわち、図１２に示すように、（Ｂ）の取引処理の結果、成約された生花（成約出荷商品）と、未成約となった生花（未成約出荷商品）とが発生する。このときの商品の価格（販売価格）を”ｘ”、下限価格（最低希望価格）を”ｙ”とする。これらの成約出荷商品及び未成約出荷商品の各情報は、サーバ側の端末装置に送られ、そのＤＢＭに記憶される。売手側は、自端装置にて、サーバ側のＤＢＭの記憶情報から生成された、例えば、図１３に示すような、未成約出荷一覧の画面を参照することで、複写処理を実行するか否かを判断し、上記図５に示した画面の「複写」を選択し指定する。そして、売手側は、複写する商品を個別に選択し、複写するものを指定する。尚、このとき、未成約商品を全て一括して指定できるようにしてもよい。また、売手側は、販売価格ｘを販売価格ｘ’（ｘ≠ｘ’）、下限価格ｙを下限価格ｙ’（ｙ≠ｙ’）に各々変更する指定も行うことができる。これにより、サーバ側のＤＢＭに記憶された不成立出荷商品の情報は、価格変更も含めて、（Ｃ）の取引処理での商品の情報とされる。また、このとき、売手側が新たに商品の登録（新規登録）を、販売価格ｘ1 ’、下限価格をｙ1 ’として行った場合には、これらの情報も含めて、（Ｃ）の取引処理での商品の情報とされる。」（９頁１５欄３８行〜１６欄１０行）
 が記載されている。  
　これらの記載ア〜キ及び図面図１〜図１５によれば、引用例１には、「ある期間が過ぎてしまうと商品価値がなくなる或いは減少する各種商品の売買取引に用いられる商品取引装置において、サーバ側の端末装置３００は、種々の情報の受信及び送信（配信）を行うための情報受信配信機能３１０と、アプリケーション機能（ＡＰＰ機能）としての取引処理及び価格形成機能３２１と、トランザクションデータやマスターデータを記憶すると共に各種処理に必要なデータを記憶するための記憶機能（データベースメモリ：ＤＢＭ）３３０とを有し、サーバ側には、複数の売手業者が発した販売情報と、複数の買手業者が発した購入登録情報とが存在し、所定の成約決定アルゴリズムによる成約決定処理により、複数の売手業者が発した販売情報と、複数の買手業者が発した購入登録情報とに対して、双方の条件の折り合うものから順次成約（価格）を決定するものであって、ここでの成約決定アルゴリズムは、例えば、販売下限価格の条件を満たし、且つ、購入価格の高い順、購入情報の入力時間の早い順等により成約を決定するものであり、例えば、生花の市場管理を行うサーバ側の端末装置１０１と、複数の売手業者側の端末装置１１１〜１１４及び１４１、複数の買手業者側の端末装置１２１〜１２３及び１５１、及び中卸業者側の端末装置１３１とが、ＷＡＮ１６１を介して互いに通信可能に接続された構成とし、サーバ側、売手業者側、買手業者側、及び中卸業者側の各端末装置は、中央処理装置（ＣＰＵ）、キーボード、マウス、表示器、通信器、及び本システムの処理プログラムが予め格納されたメモリ等を備えたパーソナルコンピュータ（パソコン）からなり、該メモリの処理プログラムをＣＰＵにより読み出して実行することで、種々の処理を行うようになされている商品取引装置。」の発明（以下、「引用発明１」という。）が記載されている。
（２）原査定の拒絶の理由に引用された湯浅和夫ら，ＥＣを支える物流ビジネス−デジタルロジスティクス革命，Internet magazine 1999/12，株式会社インプレス，１９９９年１２月　１日発行，No.59，pp.232-243 （以下、「引用例２」という。）には、
　ア　「スケジューリング／ブッキング　ビジネス向けのサービスになるが、輸送船や航空機の輸送スケジュールや空きキャパシティーに関する情報提供、及び予約を行うサービス。主に船会社や航空会社が提供することが多い。」（２３６頁左欄）、
　イ　「求車／求貨情報サービス　行きは荷物を満載したトラック（船）でも帰りは満載となるとは限らない。それどころか空の場合もあるだろう。そうした「空き容量」をなくしたい運送側と、少しでも安く荷物を輸送したい出荷側のニーズを取り持つのが求車／求貨情報サービスだ。実際は、同じ運送会社内の荷物のやりくりするのに使われることが多いが、トラック１台で営業している個人事業主と荷主を取り持つ全日本トラック協会の「ＫＩＴ」（ただしパソコン通信ベースの会員制）のようなサービスもある。」（２３６頁右欄）、
　ウ　「そのほかにも、ビジネスユーザー向けの話として、物流関連のインフォメディアリー（情報仲介業者）The　National　Transportation　Exchage,Inc（NTE)では、荷物を運びたいトラック業者（個人事業主を含む）と少しでも運送費を安くしたい依頼人のニーズをマッチさせる本格的な求車／求貨情報サービスを稼働させ、評判となっている。・・・NTEの求貨情報システムでは、荷物を運びたいという運送事業主がトラックの出発地と目的地、空き床面積と搭載可能重量をホームページに入力すると、利益率なども算出したうえでベストと見られる仕事をいくつかリストアップしてくれる。気に入った仕事があれば、電話で申し込む仕組みだ。」（２４０頁下欄）が記載されている。
（３）原査定の拒絶の理由に引用された特開平１１−３５３３６１号公報（以下、「引用例３」という。）には、「【発明が解決しようとする課題】ところが、上記のオークション形式による販売では、例えば、商品がパーソナルコンピュータの場合でも、通常、一度に販売する個数は少数個に限定されており、購入者側には通常の店頭販売価格や通信販売価格等より低めの価格で購入できる機会が与えられる利点があっても、販売個数が少数であるから販売者側の利益は比較的乏しいものであった。なお、よく知られているように、販売者にとっては、同一商品を一括して多数販売する場合、商品一個当たりの単価は、少数個を販売する際の価格よりかなり低めでも差し支えがないことが多いものである。
【課題を解決するための手段】本発明は前記の課題を解決して、ネットワーク上の仲介者の仲介により、購入希望者にとっては自らが希望する出来るだけ低い価格で商品を購入する機会が得られやすくなるとともに、販売者にとっては同一商品を出来るだけ多数販売する機会が得られやすくなる、通信ネットワークによる商品販売システムを提供することを目的としている。そのため、本発明の請求項１の通信ネットワークによる商品販売システムは、通信ネットワーク上で仲介者が商品を提示して所定期間内に購入希望者から上記商品に対する任意の希望購入価格の入札を受け付け、上記所定期間経過後、入札結果に基づき上記仲介者が上記商品に対し所定の基準価格以上の入札があった各件について入札価格を入札件数で加重平均した加重平均価格と当該基準価格以上の入札件数に対応する購入希望数量とを一又は複数の販売者に提示し、上記商品を上記加重平均価格で上記購入希望数量だけ販売することに合意した販売者が販売権を獲得した後、上記基準価格以上の入札をした購入希望者から商品１個毎に各々自らの入札価格を徴収し、徴収した金額の所定割合を上記仲介者が手数料として受領するとともに残部を上記販売権を獲得した販売者が受領するようにしたことを特徴とするものである。すなわち、請求項１のシステムでは、販売価格を一定価格に限定することなく、所定の基準価格以上の入札を行った購入希望者につき、各購入希望者の入札価格を入札件数で加重平均して加重平均価格を求め、この加重平均価格で上記基準価格以上の入札件数に対応する数量だけ当該商品を販売することを希望する販売者が存在するかどうかを上記仲介者が打診し、いずれかの販売者が販売を希望する場合、売買を成立させるものである。この場合、売買が成立すると、上記基準価格以上の入札を行った各購入希望者は、自らの入札価格を支払うことになるが、当該基準価格以上の入札を行った各購入希望者の支払い額の総額は、上記加重平均価格と上記購入希望数量とを掛け合わせた値と等しくなる。」（２頁２欄３７行〜３頁３欄３４行）が記載されている。
　 
３．対比 
　そこで、本件発明と引用発明１とを対比すると、引用発明１の「商品の取引」と本願発明の「荷物配送に係る取引」は、何れも上位概念での「取引」に含まれるものである。
　引用発明１の「サーバ側端末装置」、「売手業者側の端末装置」及び「買手業者側の端末装置」は、各々パーソナルコンピュータから構成され、これらを総合したシステムは、取引を支援しているシステムといえるから、本願発明の「コンピュータシステムを介して支援するための取引支援設備」に相当する。
　引用発明１では、売手業者側の端末装置及び買手業者側の端末装置でそれぞれ販売情報及び購入登録情報を入力し、これら情報をサーバに送っており、サーバ側には、複数の売手業者が発した販売情報と、複数の買手業者が発した購入登録情報とが存在するように構成しているのであるから、情報を入力し記憶する手段を備えているといえる。
　引用発明１は、所定の成約決定アルゴリズムによる成約決定処理を行っており、該処理を行っている手段は、本願発明の「決定手段」に相当する。 
　したがって、本願発明と引用発明１は、「取引を、コンピュータシステムを介して支援するための取引支援設備であって、情報を入力し記憶する手段と、決定手段と具備することを特徴とする取引支援設備。」の点で一致し、以下の点１〜４で相違する。
　相違点１
　本願発明は、「複数の荷主と複数の物流業者との間で交わされる荷物配送に係る取引を、コンピュータシステムを介して支援するための取引支援設備」であるのに対して、引用発明１は、「複数の売り手業者と複数の買い手業者間の商品取引を、コンピュータシステムを介して支援するための取引支援設備」である点。 
　相違点２
　本願発明は、「荷主の希望する配送場所、荷物内容等の発注条件を含む発注依頼を受け付け、発注依頼データとして当該荷主に関連付けて記憶する荷主用入力支援手段と、物流業者の希望する価格提示等の受注条件を含む受注希望を受け付け、受注希望データとして当該物流業者に関連付けて記憶する物流業者用入力支援手段と、これら発注依頼データ及び受注希望データを基に、前記発注依頼データ毎に、その発注条件を満たす受注条件を含んだ前記受注希望データを自動検索し抽出する自動検索手段と、この自動検索手段により抽出した受注希望データのなかから、最も好受注条件を含むものを選択し、この選択した受注希望データを、当該発注依頼データに対する受注決定データとしてデータベースに記憶させる受注決定手段と、」を備えるのに対して、引用発明１では、情報を入力し記憶する手段と、決定手段を備えるものの、荷主用入力支援手段、物流業者用入力支援手段、自動検索手段及び受注決定手段についての記載がない点。 
　相違点３
　本願発明は、「前記発注依頼データが所定期間以上先であって予約受注を指定したものである場合には、所定期間以上先の受注を希望する受注条件を含む受注希望データを抽出し、この抽出した受注希望データのみを対象に自動検索手段及び受注決定手段による受注決定が行われるようにするスケジュラー」を備えるのに対して、引用発明１では、その構成について記載がない点。
　相違点４
　本願発明は、「前記受注決定手段により選択されなかった受注希望データを、まだ受注が決定していない発注依頼データに対して前記自動検索手段が受注希望データを検索する際の検索対象に自動的に加える繰越手段」を備えるのに対して、引用発明１では、その構成について記載がない点。
  
４．当審の判断 
　以下、相違点１〜４について検討する。 
　相違点１について 
　取引として、荷主と物流業者との間で交わされる荷物配送に係る取引が行われていることは周知の事実であって、この取引をコンピュータシステムを介して支援するための取引支援設備で行う「求車／求貨情報サービス」は、同じ電子商取引の技術分野に属する引用例２に記載されており、引用発明１において、複数の売り手業者と複数の買い手業者間の商品取引に代え、その取引を荷主と物流業者との間で交わされる荷物配送に係る取引とすることに格別困難な事情は認められない。
　してみると、引用発明１の取引支援設備に代え、引用例２に記載された事項を採用し、「複数の荷主と複数の物流業者との間で交わされる荷物配送に係る取引を、コンピュータシステムを介して支援するための取引支援設備」とすることは、当業者が、容易になし得たことである。 
　相違点２について 
　一般に、荷主と物流業者との間で交わされる荷物配送に係る取引において、荷主は希望する配送場所、荷物内容等の発注条件を示し、物流業者は希望する価格提示等の受注条件を示し、両者の条件により、取引の成否が決まるものであるが、引用例２の「求車／求貨情報サービス」を見ると、求車側で該発注条件を含む発注依頼をし、求貨側で該受注条件を含む受注希望を出し、サービスを行っているといえ、そのための手段を備えているといえる。
　そして、引用発明１の取引を、複数の荷主と複数の物流業者との間で交わされる荷物配送に係る取引とすることに際し、引用発明１の売手業者、買手業者を荷主、物流業者に対応させることとする場合、販売情報は発注条件を含む発注依頼データ、注文情報は受注条件を含む受注希望データに対応するといえる。
　コンピュータに端末から情報を入力させ、該情報を記憶させる構成は、コンピュータへの入力を支援しているということができ、それを入力支援手段ということは、その機能から見て、不自然ではない。
　また、電子商取引の分野において、売手業者の販売情報毎に、買手業者の注文情報を検索して抽出し、その中から注文情報を決定することは、慣用手段といえ、また、ここにおいて、検索は、システムにおいて自動化して行われるものであるから、自動検索ということは不自然ではない。
　引用発明１は、所定の成約決定アルゴリズムによる成約決定処理を行っており、具体的には、購入希望価格の高い順や情報入力の早い順に成約決定するのであり、これは、最も好条件を含むものを抽出しているといえ、また、抽出したものをデータベースに記憶することは電子商取引の分野では、普通のことである。
　してみると、引用発明１に引用例２に記載された事項を採用する際、上記検討した事項、慣用手段を踏まえ、引用発明１に、情報を入力し記憶する手段と、決定手段に代え、「荷主の希望する配送場所、荷物内容等の発注条件を含む発注依頼を受け付け、発注依頼データとして当該荷主に関連付けて記憶する荷主用入力支援手段と、物流業者の希望する価格提示等の受注条件を含む受注希望を受け付け、受注希望データとして当該物流業者に関連付けて記憶する物流業者用入力支援手段と、これら発注依頼データ及び受注希望データを基に、前記発注依頼データ毎に、その発注条件を満たす受注条件を含んだ前記受注希望データを自動検索し抽出する自動検索手段と、この自動検索手段により抽出した受注希望データのなかから、最も好受注条件を含むものを選択し、この選択した受注希望データを、当該発注依頼データに対する受注決定データとしてデータベースに記憶させる受注決定手段」の構成としたことは、当業者は、容易になし得たものである。 
　相違点３について 
　一般に、荷主と物流業者との間で交わされる荷物配送に係る取引において、復路空車率の低減は、周知な課題（北澤博、「物流情報システム」、株式会社白桃書房、１９９１年２月１６日、第２版，ｐ．２９−４５，　久住正一郎、「コンピュータで成功する物流情報システムの進め方」、株式会社日本実業出版社、１９９８年１０月１０日、第１版，ｐ．２１６−２１７）であり、この課題解決のためには、所定期間以上先の発注依頼、受注希望についての情報を利用することは、当業者であれば、普通に推考できる。
　引用発明１は、第８図（Ｂ）（第２の取引：販売情報に基づく予約相対取引）とあるように、予約の取引を開示しているとともに、第９図出荷情報一覧図面に９月から１２月までのデータが表示され、所定期間以上先のデータを含めることが理解できる。
　検索において、検索時間を短縮するため、キーとなるデータで予め検索対象範囲を絞っておくこと（そのためにデータを抽出すること）は、慣用手段にすぎず、例えば、キーとなるデータが期間であれば、所定期間以上か否かで検索範囲を分けておくこと（そのためにデータを抽出すること）は、当業者が普通に推考できることである。
　スケジュールについて、引用例２にも予約に関して記載（上記２．（２）記載ア）されており、予約受注の指定・受注決定に関る手段を「スケジュラー」と表現することは、格別なこととは認められない。
　してみると、引用発明１に引用例２に記載された事項を採用する際、上記検討した事項、慣用手段を踏まえ、引用発明１に、復路空車率の低減の課題を解決させるため、「前記発注依頼データが所定期間以上先であって予約受注を指定したものである場合には、所定期間以上先の受注を希望する受注条件を含む受注希望データを抽出し、この抽出した受注希望データのみを対象に自動検索手段及び受注決定手段による受注決定が行われるようにするスケジュラー」を備えることは、当業者は、容易になし得たものであ
る。 
　相違点４について 
　引用発明１において、複数の購入情報は、Ｃ１での緩和した条件入力ができ、販売情報では、同一条件のものが複数ある場合が図９に記載されているから、販売情報に対し順次成約する中で、成約するまで検索対象となっていると考えるのが自然であり、また、一般に、情報を必要な期間に渡って検索対象とするために、検索対象情報を繰越すことは、慣用手段にすぎないといえる。
　してみると、引用発明１に引用例２に記載された事項を採用する際、上記検討した事項、慣用手段を踏まえ、引用発明１に、「前記受注決定手段により選択されなかった受注希望データを、まだ受注が決定していない発注依頼データに対して前記自動検索手段が受注希望データを検索する際の検索対象に自動的に加える繰越手段」を備えることは、当業者は、容易になし得たものである。 
 　 
５．むすび 
　以上のとおり、本願発明は、引用例１〜３に記載された発明に基づき当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項に係る発明について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する