【事件の表示】
　特願２００２−５４５３３９「商業的な取引のために用いられるのに適合した方法」拒絶査定不服審判事件〔平成１４年　５月３０日国際公開、ＷＯ０２／４２８８０、平成１６年　７月１５日国内公表、特表２００４−５２１５３０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２００１年１０月２５日（パリ条約による優先権主張　２０００年１０月２５日　（ＵＳ）アメリカ合衆国）を国際出願日とする出願であって、平成１６年１０月２５日付けで手続補正がなされたが、平成１９年７月１３日付けで拒絶理由が通知され、同年１１月２２日付けで拒絶査定がされ、これに対し、平成２０年２月２９日に拒絶査定に対する審判請求がなされ、同年３月３０日付けで審判請求時の手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成２０年３月３０日付けの手続補正を却下する。
　
［理由］
１．補正の内容
　上記審判請求時の手続補正（以下、「本件補正」という。）は、請求項１乃至３として、
　「【請求項１】　商業的な取引のために用いられるのに適合した方法において、
　少なくとも一つの買い手側ユーザから少なくとも一つの売り手側ユーザに対して、利用可能な第１群個人プロフィールを生成するステップであって、該第１群個人プロフィール中の各個人プロフィールは複数の情報フィールドに対する第１の値の第１群を含み、該複数の情報フィールドは商業的な取引に関係するものであるステップと、
　前記少なくとも一つの売り手側ユーザからの第２群個人プロフィールを前記少なくとも一つの買い手側ユーザにおいて受信するステップであって、該第２群個人プロフィール中の各個人プロフィールは前記複数の情報フィールドに対する第２の値群を含むものであるステップと、
　前記第１群個人プロフィールの少なくとも一部及び前記第２群個人プロフィールの少なくとも一部に基づき、前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対しての利用可能な前記第２群個人プロフィールの少なくとも一部を生成するステップと、
　前記第１群個人プロフィールの前記少なくとも一部及び前記第２群個人プロフィールの前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、
　一群の信頼関係情報を受信するステップと、
　前記利用可能な一群の信頼関係情報を生成するステップであって、前記少なくとも一つの売り手側ユーザと前記少なくとも一つの買い手側ユーザとの間で商業的な取引が促進され信頼関係が生成され、該関係は１以上のユーザが利用できる基盤の機能量に影響を与えるさまざまなレベルの信頼性を含み、該さまざまなレベルの信頼性は第１のレベルの信頼性及び第２のレベルの信頼性を具備し、該第１のレベルの信頼性は前記少なくとも一つの買い手側ユーザによって設定され、該第２のレベルの信頼性は前記少なくとも一つの売り手側ユーザによって設定されるステップと
　を具備する方法。
　　【請求項２】　少なくとも一つの買い手側ユーザから少なくとも一つの売り手側ユーザに対して、利用可能な個人プロフィール群を生成するステップであって、該個人プロフィール群中の各個人プロフィールは複数の情報フィールドに対する第１の値の第１群を含み、該複数の情報フィールドは商業的な取引に関係するものであるステップと、
　前記個人プロフィール群の前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、
　前記少なくとも一つの売り手側ユーザからの一群の信頼関係情報を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、
　前記少なくとも一つの売り手側ユーザと前記少なくとも一つの買い手側ユーザとの間で商業的な取引を促進し信頼関係を形成するために、前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対して前記一群の信頼関係情報を送信するステップであって、該関係は１以上のユーザが利用できる基盤の機能量に影響を与えるさまざまなレベルの信頼性を含み、該さまざまなレベルの信頼性は第１のレベルの信頼性及び第２のレベルの信頼性を具備し、該第１のレベルの信頼性は前記少なくとも一つの買い手側ユーザによって設定され、該第２のレベルの信頼性は前記少なくとも一つの売り手側ユーザによって設定されるステップと
　を具備する方法。
　　【請求項３】　一群の将来の商業的な諸取引において用いられるべく適合されたネットワークを提供するステップと、
　少なくとも一つの買い手側ユーザから少なくとも一つの売り手側ユーザに対して、利用可能な個人プロフィール群を生成するステップであって、該個人プロフィール群は一群の過去の商業的諸取引に関係するものであるステップと、
　前記個人プロフィール群の前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、
　前記少なくとも一つの売り手側ユーザからの一群の信頼関係情報を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、
　前記少なくとも一つの売り手側ユーザと前記少なくとも一つの買い手側ユーザとの間で前記一群の将来の商業的な諸取引中の少なくとも一つの商業的な取引を促進し信頼関係を形成するために、前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対して前記一群の信頼関係情報を送信するステップであって、該関係は１以上のユーザが利用できる基盤の機能量に影響を与えるさまざまなレベルの信頼性を含み、該さまざまなレベルの信頼性は第１のレベルの信頼性及び第２のレベルの信頼性を具備し、
該第１のレベルの信頼性は前記少なくとも一つの買い手側ユーザによって設定され、該第２のレベルの信頼性は前記少なくとも一つの売り手側ユーザによって設定されるステップと
　を具備する方法。」
と記載することを含むものである。
　
２．補正の適否
　請求項１には、 
（ａ）「前記第１群個人プロフィールの少なくとも一部及び前記第２群個人プロフィールの少なくとも一部に基づき、前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対しての利用可能な前記第２群個人プロフィールの少なくとも一部を生成するステップ」 
（ｂ）「前記第１群個人プロフィールの前記少なくとも一部及び前記第２群個人プロフィールの前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップ」 
（ｃ）「一群の信頼関係情報を受信するステップ」 
（ｄ）「前記利用可能な一群の信頼関係情報を生成するステップ」、 
という発明特定事項が記載され、
　請求項２には、
（ｅ）「前記個人プロフィール群の前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップと、」 
（ｆ）「前記少なくとも一つの売り手側ユーザからの一群の信頼関係情報を前記少なくとも一つの買い手側ユーザにおいて受信するステップ」 
（ｇ）「前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対して前記一群の信頼関係情報を送信するステップ」、 
という発明特定事項が記載され、
　請求項３には、
（ｈ）「前記個人プロフィール群の前記少なくとも一部に基づき、前記少なくとも一つの売り手側ユーザからの信頼関係構築要求を前記少なくとも一つの買い手側ユーザにおいて受信するステップ」 
（ｉ）「前記少なくとも一つの売り手側ユーザからの一群の信頼関係情報を前記少なくとも一つの買い手側ユーザにおいて受信するステップ」 
（ｊ）「前記少なくとも一つの買い手側ユーザから前記少なくとも一つの売り手側ユーザに対して前記一群の信頼関係情報を送信するステップ」 
という発明特定事項が記載されている。
　
　まず上記（ａ）について検討すると、願書に最初に添付した明細書及び図面（以下、「当初明細書等」という）の発明の詳細な説明の段落００３７には、情報束用の複数の情報領域のための値を含むプロフィールを規定し、該情報領域の値に関する情報束を受信し、該受信した束に含まれる情報に基づき該プロフィールを修正することが記載されているが、買い手側ユーザからの第１群個人プロフィールと売り手側ユーザからの第２群個人プロフィールに基づき第２群個人プロフィールを生成することまでは当初明細書等には記載されておらず、またこのことが自明な事項ともいえない。
　次に上記（ｂ）、（ｅ）、（ｈ）について検討すると、当初明細書等の発明の詳細な説明の段落０１１３には、信頼相において、束がユーザのプロフィール設定にかなう場合、ユーザはその束を受信すると記載されているが、段落０１１４には、非信頼相の間、ユーザは勧誘を通して情報交換を行うと記載され、段落０１２０や段落０１２２には束は勧誘状の一種とみなされないと記載されており、（ｂ）、（ｅ）、（ｈ）に記載のような、プロフィールに基づき信頼関係構築要求（当初明細書等の「勧誘状」のことと解される）を受信することは当初明細書等には記載されておらず、またこのことが自明な事項ともいえない。
　次に上記（ｃ）、（ｄ）、（ｆ）、（ｇ）、（ｉ）、（ｊ）について検討すると、（ｃ）、（ｄ）、（ｆ）、（ｇ）、（ｉ）、（ｊ）に記載の「信頼関係情報」が当初明細書等の記載の何に対応するのか不明であるため、売り手側ユーザから信頼関係構築要求（当初明細書等の「勧誘状」のことと解される）を受信した買い手側ユーザが、売り手側ユーザから信頼関係情報を受信し、売り手側ユーザに信頼関係情報を送信することは、当初明細書等には記載されておらず、またこのことが自明な事項ともいえない。
　したがって、上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものではないから、特許法第１７条の２第３項（新規事項）の規定に適合していない。
　
３．結語
　以上のとおり、上記本件補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願について
１．本願の明細書、特許請求の範囲及び図面
　平成２０年３月３０日付けの手続補正は上記のとおり却下されたので、本願の明細書の発明の詳細な説明及び図面は出願当初に開示されたとおりであり、一方、本願の明細書の特許請求の範囲は平成１６年１０月２５日付け手続補正書により補正されたとおりである。
　特許請求の範囲は、請求項２及び２９として、
「【請求項２】　ネットワーク上の地点からプログラム命令を受信する手段と、
　前記ネットワークを通じて複数のデータ束を配信する手段と、
　前記束向けの内容属性記述子中の所定の状況の検出に応答して動作を実行する手段と
　を具備することを特徴とする商取引管理のためのネットワーク化システム。」
「【請求項２９】　ネットワーク上の複数地点からプログラミング命令を受信し、
　前記ネットワークを通じて複数のデータ束を配信し、
　前記束向けの内容属性記述子中の所定の状況の検出に応答して動作を実行する
　ことを特徴とするネットワーク化商取引管理方法。」
と記載することを含むものである（以下、請求項２に係る発明を「本願発明１」、請求項２９に係る発明を「本願発明２」という）。
　
２．原審の拒絶理由
　原審における平成１９年７月１３日付けの拒絶理由の「理由Ａ」の概要は以下のとおりである。
　
「【理由Ａ】
　この出願は、特許請求の範囲及び発明の詳細な説明の記載が下記の点で、特許法第３６条第４項及び第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　
■発明の詳細な説明について
（１）【０００４】には、「本発明は、ネットワーク上のユーザ間で情報を広く共有すること」と記載されているが、出願内容が全体的に不明であるため、上記の目的を実現するための具体的な技術事項を把握できない。
　特に、ネットワーク上のどの装置が、どのような場合に、どのようにして【図２】の束を構築し、どの装置が、どのような場合に、ネットワーク上に束を配信するのか？
（中略）
　束又はメタデータを、どの装置が、どのような場合に受信し、受信した後それをどう利用するのか？
　結局、【図２】の束を用いると、どのようなことが実現できるのか？
　意見書において、（実施形態の説明）中の記載箇所を示しつつ説明されたい。
　
■特許請求の範囲について
（（１）〜（３）略）
　
（４）ネットワーク化システムに関する各請求項１−１４に係る発明、及び、「請求項１、・・・１４記載のシステムに係る装置」に関する各請求項１５−２８に係る発明において、各請求項の発明特定事項が、ネットワーク上のどの装置において実現されているのかが不明であり、発明特定事項同士の対応関係も不明であり、結果として各請求項に係る発明がそれぞれどのような発明なのか（何を実現する発明なのか）を把握できない。
　例えば、
（中略）
　請求項２においては、「・・・プログラム命令を受信する手段」「・・・データ束を配信する手段」「・・・動作を実行する手段」がそれぞれネットワーク上のどの装置において実現されているのか不明である。
　さらに、「・・・プログラム命令を受信する手段」と「・・・データ束を配信する手段」と「・・・動作を実行する手段」との対応関係の記載がなくそれぞれの手段が独立に記載されているため、結果として請求項２に係る発明がどのような発明なのか（何を実現するための発明なのか）を把握できない。
（以下略）
　
（（５）略）
　
（６）上記（４）と同様であるが、ネットワーク化商取引管理方法に関する各請求項２９−５７に係る発明において、各請求項の発明特定事項の動作主体が不明であり、発明特定事項同士の対応関係も不明であり、結果として各請求項に係る発明がそれぞれどのような発明なのか（何を実現するための発明なのか）を把握できない。
　
（（７）以下略）」
　
３．当審の判断
　請求人は上記の拒絶理由に対し、平成２０年６月１９日付けの手続補正書に記載した「請求の理由」において、
　
「（Ｃ）理由Ａ：発明の詳細な説明に係る拒絶理由通知に係る各項目について
（１）―ａ
・特に、ネットワーク上のどの装置が、どのような場合に、どのようにして【図２】の束を構築し、どの装置が、どのような場合に、ネットワーク上に束を配信するのか？
・束又はメタデータを、どの装置が、どのような場合に受信し、受信した後それをどう利用するのか？
・結局、【図２】の束を用いると、どのようなことが実現できるのか？
の諸点に関して。
図１は、「一連の売り手側ユーザ端末」と「一連の買い手側ユーザ端末」を含むシステムを例示するものである（明細書【００４４】）。束は、たとえば図２における束を例にとると、これらの端末のうちのいずれの上においても、構築することができるものである。たとえば図２における束は、「図1のシステムのための」ものであるとして記述されている（明細書の【図面の簡単な説明】のうち【図２】）。
束は様々な方法によって構築することができるが、その一例としてはたとえば明細書に次の記述がある。
「本システムは、ボイスメール・メッセージ、テキスト、及び、様々な種類のサブドキュメントを含みうる多種形式の電子文書を含む全種メッセージ、即ち、例えばテキスト・ベースのHTMLファイル、アドビ（登録商標）pdfファイル、グラフィカルチャート、オーディオ・ファイルおよび映画といったファイル用の単一電子チャネルを有するインフラストラクチャを提供する。各々のメッセージは「束」と呼ばれている。束は、その束の内容を表現し、受信権限を持つ者を特定する、ユーザによる拡張可能な多種メタデータ・セットによって分類される。ツールは、任意の束を構築するための管理組織によって提供されうる。」（明細書【００４８】）
すなわち、束は様々なタイプのメッセージを含むことができて、適切なツールを用いることでこの束を解釈することができることになる。たとえば図１６は束作成ウィンドウを例示するものであるが、このウィンドウを用いれば束を作成することができる。これは次のように記載されている。
「図16を参照する。束作成ウインドウは、その下部に添付セクションを有する。該セクションは左側に、転送させている束か応答されている束かを表すアイコンと共に、各添付ファイル用アイコン（ボイスメールおよび文書）を有する。ユーザは、消去したい添付ファイルを選んで、消去ボタンを押下することによってボイスメール添付ファイルまたは文書添付ファイルを削除することができる。」（明細書【０１４０】）
図２の束は様々な状況において構築することができるが、たとえばその一例としては明細書に次のように記載されている。
「他の例では、売り手側会社の販売員は、オンライン・オークション・サイトについて買い手側会社のための束を作成する。彼女は、束に5つの普通株を付け加えて、最直近の評価およびそれらの普通株の推奨が束において表示されなければならないことを示す。売り手側会社がXIAを通してそれらの調査データベースを自社の集約サーバに接続したので、単に束を開けることで、束内部の調査データベースから得る推測および推奨情報へのアクセスが提供される。」（明細書【００６６】）
上記の例では、束はたとえば図１のシステムによって生成することができることになる。
こうして生成された束は図１のネットワークを通じて移動し、（図１の）システムＡ２に到着する。そこでは束は様々な方法で用いられることができる。一例としては、束を用いることで「見積書及び推薦情報」を提供するものが挙げられる。本例によれば、こうして束によって「実現される」のは、特定の様式の正札（下げ札）がついた束を開くと自動的に情報が提供されるような自動化システムである。
束は集約サーバによって配信される。たとえば、明細書にあるように、「ルーティング・データは、束のための終点アドレスを特定し、このアドレスによって、集約サーバが束を配信することが可能となる。」（明細書【００４９】補正後）
（中略）
（Ｅ）理由Ａ：特許請求の範囲に係る拒絶理由通知に係る各項目について
（１）「束」について
束には２つの主要部分である束ヘッダとコンテンツが含まれる。このヘッダにはルーティング・データとメタデータが含まれる。このルーティング・データは、束のための目的アドレスを特定するものであり、これにより集約サーバは束を配信することが可能となる。
一方当該メタデータには、一連の項目記述子と当該諸項目の値とが含まれる。このメタデータ項目の中には必須のものもあるが、オプションとすることのできるものもある。このコンテンツは、相異なる様々なタイプのドキュメント、或いはネットワーク内のこれらドキュメントへの参照を含むことができる。なお、「束」とは「bundle」の訳語であり、「バンドル」とも指標する。手続補正１に係る特許請求の範囲（補正後）では「バンドル」と称している。
（中略）
ｆ．請求項２に関して。
ｆ−１．「ネットワーク上の地点からプログラム命令を受信する手段」
　これは、ｓ１，Ｓ２，ａ１，ａｐｐ１，及び／又は、ＡＰＰ２を含み得るものである。
ｆ−２．「ネットワークを通じて複数のデータ束を配信する手段」
　これは、図１のネットワーク全体にわたってデータを配信することのできるソフトウェア、及び／又は、ルーティング機器を含み得るものである。
ｆ−３．「束向けの内容属性記述子中の所定の状況の検出に応答して動作を実行する手段」
　これは、集約サーバｓ１及び／又はＳ１で走るソフトウェアを含み得るものである。
（中略）
（６）に関して。手続補正１に係る特許請求の範囲の補正により当該表現は削除されたため、かかる拒絶理由は解消するものと思料するが、補正前の内容については上記回答（４）に述べたとおりである。」
　
と説明しているが、これらの主張を考慮しても依然として、本願発明１、２の発明特定事項の具体的な要素自体が不明である上、それら要素間の関係も明らかではないため、１つのまとまった技術思想として発明を理解することができない。また当然に、発明の外延も不明確であり、発明を明確に把握することができない。
　例えば、「ネットワーク上の地点からプログラム命令を受信」、「ネットワーク上の複数地点からプログラミング命令を受信」という記載については、プログラム命令（プログラミング命令）とはどこから発せられるどのようなものであるのかが不明であるため、結果としてそのプログラム命令（プログラミング命令）を受信することにどのような意義があるのかが把握できない。ここで、「請求の理由」において、請求人は「プログラム命令」を「一連の指令群」に補正する意思がある旨述べているが、このように読み替えて考えても同様である。
　また、「束向けの内容属性記述子中の所定の状況の検出に応答して動作を実行する」という記載については、ネットワーク中にそのような機能を実行する手段があることは理解できるとしても、どこで生成された束が、どのような仕組みで当該手段まで配信され、当該手段ではどのような動作がなされるのかが不明である。
　
　上記の点に関して発明の詳細な説明を参酌しても、「プログラム命令（プログラミング命令）」については何に対応するのかが不明であり、「束向けの内容属性記述子中の所定の状況の検出に応答して動作を実行する」については、束の内容や処理の具体例の記載は見られるものの（段落００４９、００６５〜００６９等）、どのような仕組みで束の配信を行って、ネットワーク中のどの装置（サーバ）においてどのような処理をさせるものであるのかまでは理解することができないため、結果として本願発明１、２に係る「商取引管理のためのネットワーク化システム」や「ネットワーク化商取引管理方法」が何を実現するためのものなのかが不明である。
　
　以上のとおりであるから、本願発明１、２はそれぞれどのような発明なのか、何を実現する発明なのかを把握することができず、依然として明確でない。
　
４．むすび
　以上のとおり、本願明細書の特許請求の範囲に記載された発明は依然として明確でなく、特許法第３６条第６項第２号に規定する要件を満たしていないから、特許を受けることができない。
　よって、結論のとおり審決する。
　
　なお、本件については平成２１年４月１７日に面接を行い、その後数回にわたって補正案の提出を受けて検討を行ったが、明確な記載には至っていない。