【事件の表示】
　特願２０００−５９８９４９「メッセージの送受信を行う装置」拒絶査定不服審判事件〔平成１２年　８月１７日国際公開、ＷＯ００／４８０９９、平成１４年１０月２９日国内公表、特表２００２−５３６７６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１２年２月９日（パリ条約による優先権主張１９９９年２月１１日、英国）を国際出願日とする出願であって、平成１５年７月１５日付けで拒絶理由が通知され、平成１６年１月１９日付けで手続補正がなされ、同年２月１０日付けで最後の拒絶理由が通知され、同年８月１６日付けで手続補正がなされたが、前記平成１６年８月１６日付け手続補正書による補正は同年９月２日付けで補正却下の決定がなされるとともに、同日付けで拒絶査定がなされ、これに対し、同年１２月６日に審判請求がなされるとともに、平成１７年１月５日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成１７年１月５日付けの手続補正を却下する。
　
［理由］
１．補正の内容
　平成１７年１月５日付けの手続補正（以下、「本件補正」という。）は、平成１６年１月１９日付けの手続補正により補正された特許請求の範囲（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）に記載された
「【請求項１】　セルラ電話やＰＤＡのような電子的に生成されたメッセージの送受信を行うモバイルコンピュータ装置であって、
　電子的に生成されたメッセージに対するユーザインタフェースを提供すると共に、複数のタイプのメッセージで共通に使用される汎用的な属性データを前記ユーザインタフェースに表示させるコアユニットと、
　サポートしているメッセージのタイプ、各タイプのメッセージに含まれる属性データ、及び各タイプのメッセージの属性データに対して実行可能な処理の情報を関連付けて記憶するレジストリユニットと、
　各タイプのメッセージの属性データに対して実際の処理を実行する複数の処理実行モジュールと、を備えており、
　前記コアユニットは、前記ユーザインタフェースを介して前記属性データに対して所定の処理が指示されたときに、前記レジストリユニットを参照して当該処理が実行可能であるか否かを判定し、実行可能である場合には前記処理実行モジュールを呼び出して当該処理を実行させ、実行可能でない場合には対応する処理実行モジュールを前記レジストリユニットにロードさせて当該処理を実行させるように構成されていることを特徴とするモバイルコンピュータ装置。
　【請求項２】　前記属性データは、件名／説明、日付、サイズ、メッセージのタイプ、本文、発信者、第１受信者、優先度及び添付フラグの少なくともいずれかを含むことを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項３】　前記所定の処理は、編集、表示、送信、受信、コピー、移動、削除及び印刷のいずれかであることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項４】　前記メッセージのタイプが、ｅメール、ファクシミリ、ビデオ、ページャ、ＳＭＳ、ボイスメール、音楽ファイル及びビデオクリップの少なくとも２つを含むことを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項５】　前記コアユニットは、受信した全てのタイプのメッセージを、単一のウインドウ内に表示することを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項６】　前記コアユニットは、前記メッセージに特有の属性データが含まれている場合、該属性データに関連した処理実行モジュールを前記レジストリユニットにロードさせるように構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項７】　前記コアユニットは、前記メッセージに対して特有の処理が必要な場合、該処理に関連した処理実行モジュールを前記レジストリユニットにロードさせるように構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項８】　前記処理実行モジュールは、ロードされた後に、前記装置を再起動させずに実行可能に構成されていることを特徴とする請求項６又は７に記載のモバイルコンピュータ装置。
　【請求項９】　前記処理実行モジュールは、
　　（ａ）ロード可能な処理実行モジュールの機能の前記コアユニットへの通知、
　　（ｂ）前記ユーザインタフェースに表示すべきテキストの提供、
　　（ｃ）メッセージの生成、編集及び表示の少なくともいずれか、
　　（ｄ）送受信されるメッセージのプロトコル及びフォーマットの少なくとも一方の変換、の少なくとも１つの処理を実行することを特徴とする、請求項６又は７に記載のモバイルコンピュータ装置。
　【請求項１０】　前記処理実行モジュールは、前記処理を実際に実行するオブジェクトを生成するオブジェクト指向のコードからなることを特徴とする、請求項９に記載のモバイルコンピュータ装置。
　【請求項１１】　前記処理実行モジュールが、前記装置の外部からロードされることを特徴とする請求項６又は７に記載のモバイルコンピュータ装置。」
を、
　
「【請求項１】　セルラ電話やＰＤＡのような電子的に生成されたメッセージの送受信を行うモバイルコンピュータ装置であって、
　表示手段と、
　ユーザが指示を入力するための入力手段と、
　電子的に生成されたメッセージに対するユーザインタフェースを提供すると共に、複数のタイプのメッセージで共通に使用される汎用的な属性データを前記表示手段上で処理するように構成されており、前記装置内にインストールされているコアメッセージ送信アプリケーションと、
　各メッセージを記憶するメッセージ格納部と、
　各タイプのメッセージについて前記装置内にロード可能な形式で格納されており、汎用的でない各タイプのメッセージに特有の属性データを処理するように構成されている複数の処理実行モジュールと、を備えており、
　前記表示手段に表示されるべき所与のタイプのメッセージが前記汎用的な属性データだけを処理することを要求する場合、当該タイプのメッセージについての処理実行モジュールをロードせずに、前記コアメッセージ送信アプリケーションに、前記メッセージ格納部から対応する汎用的な属性データを抽出して表示させることができ、前記所与のタイプのメッセージが前記汎用的でない特有の属性データを処理することを要求する場合、当該タイプのメッセージについての処理実行モジュールがロードされるように構成されていることを特徴とするモバイルコンピュータ装置。
　【請求項２】　前記属性データは、件名／説明、日付、サイズ、メッセージのタイプ、本文、発信者、第１受信者、優先度及び添付フラグの少なくともいずれかを含むことを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項３】　前記コアメッセージ送信アプリケーションは、ユーザが異なるタイプのメッセージに対して、編集、送信、受信、コピー、移動、削除及び印刷の少なくとも１つの操作を可能とするように構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項４】　前記メッセージのタイプが、ｅメール、ファクシミリ、ビデオ、ページャ、ＳＭＳ、ボイスメール、音楽ファイル及びビデオクリップの少なくとも２つを含むことを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項５】　前記コアメッセージ送信アプリケーションは、受信したタイプの異なる全てのメッセージ内の汎用的な属性データを、単一のボックス型ウインドウ内に表示するように構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項６】　前記コアメッセージ送信アプリケーションが、前記所与のタイプのメッセージに特有の属性データを処理できない場合、該属性データを処理できる処理実行モジュールを、必要に応じて必要なときに呼び出すように構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項７】　新たなタイプのメッセージに特有の新たな処理実行モジュールが、前記装置に追加可能に構成されていることを特徴とする請求項１に記載のモバイルコンピュータ装置。
　【請求項８】　前記新たな処理実行モジュールは、前記装置に動的に追加可能であり、前記装置を再起動させずに実行可能に構成されていることを特徴とする請求項７に記載のモバイルコンピュータ装置。
　【請求項９】　各処理実行モジュールは、
　　（ａ）１つ以上のロード可能な処理実行モジュールの機能的能力の前記コアメッセージ送信アプリケーションへの通知、
　　（ｂ）前記表示手段に表示すべきテキストの提供、
　　（ｃ）メッセージの生成、編集及び表示の少なくともいずれか、
　　（ｄ）前記コアメッセージ送信アプリケーションによって送信されるメッセージの外部の受信者によって要求されるプロトコル及びフォーマットへの変換、及び前記コアメッセージ送信アプリケーションによって受信されたメッセージの該コアメッセージ送信アプリケーションによって要求されるプロトコル及びフォーマットへの変換、
　の少なくとも１つの処理を実行すべく個別に構成されていることを特徴とする、請求項７又は８に記載のモバイルコンピュータ装置。
　【請求項１０】　各処理実行モジュールは、タスクを実行する実際のオブジェクトを生成するオブジェクト指向のコードからなることを特徴とする、請求項１に記載のモバイルコンピュータ装置。」（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
　に補正するものである。
　そして、補正後の請求項１が、補正前の請求項１に対応したものである。
　
２．補正の適否
（１）新規事項の有無についての判断
　補正後の請求項１は、その記載からして、次の発明特定事項を含んでいる。
　
（イ）表示手段に表示されるべき所与のタイプのメッセージが、汎用的な属性データだけを処理することを要求する場合と、汎用的でない特有の属性データを処理することを要求する場合とがあること。
　
　したがって、補正後の請求項１に係る発明は、
　「所与のタイプのメッセージ」自体が、「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」ための構成を有する態様を含んでいる。
　
　しかしながら、出願当初の明細書の段落番号【０００７】には「単一のメッセージ送信アプリケーションは、サポートされる全てのメッセージタイプに共有されるメッセージのいくつかの属性を処理し、サポートされる全てのメッセージタイプに適用可能ないくつかの動作をメッセージの属性に適用又は呼出す。」と記載されているに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　同様に、出願当初の明細書の段落番号【０００８】には「転送に特有の全ての属性及び動作（すなわち、これらの属性及び動作はファクシミリメッセージタイプ、又はｅメールメッセージタイプ等に特有）は、一つの実施形態では、メッセージ送信アプリケーションから完全に分離されているが必要に応じて必要なときにメッセージ送信アプリケーションから呼出されるＭＴＭ（メッセージタイプモジュール）として知られているコンポーネントによって処理される。」と記載されているが、これは、コアメッセージ送信アプリケーションが、前記所与のタイプのメッセージに特有の属性データを処理できる処理実行モジュールを、必要に応じて必要なときに呼び出すことに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　また、出願当初の明細書の段落番号【００３１】には「アプリケーション１はこのビューを、メッセージサーバ２でのセッション３を最初に生成すること−これはアプリケーション１が格納されたメッセージのリストを大まかに処理して各メッセージから格納された汎用的データを表示するのを可能とする、によって生成する。」と記載されているに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　また、出願当初の明細書の段落番号【００３２】には「ボックス外及びあらゆるローカルフォルダも全く同様な方法で描画される−ユーザはこれらのビューで汎用的データフィールド（メッセージの説明や題名、日付、サイズ、優先度及びその他など）だけを見ることができるので、アプリケーション１は登録されたＭＴＭ内のタイプに特有の機能をいずれも呼出す必要はない。」と記載されているに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　また、出願当初の明細書の段落番号【００３３】には「この機能は個々のメッセージタイプの知識を必要とするので、コアアプリケーション１によって提供することはできない。これにより我々は登録されたＭＴＭコンポーネントの第１の例であるＵＩカスタム化部５を必要とする。」と記載されているに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　また、出願当初の明細書の段落番号【００３９】には「ユーザがフォルダビューから関連するメニュー項目を選択すると、アプリケーション１は関連するＭＴＭの呼出し機能ＡＰＩを呼び戻し、元々メニューのテキストストリングと共に供給された機能番号を送り返す。この点で、アプリケーション１はＵＩデータレジストリ１３と相互作用するだけでなく、ユーザインタフェースレジストリ１２とも相互作用し、適切なＭＴＭに対するＵＩコンポーネントをアップロードする。」と記載されているに過ぎず、「所与のタイプのメッセージ」自体が、どのようにして「汎用的な属性データだけを処理する」こと、もしくは、「汎用的でない特有の属性データを処理する」ことを主体的、自律的、かつ明示的に「要求する」のか、その具体的な構成は記載も示唆もない。
　また、当該構成が当初明細書等の記載から自明な構成であるとも認められない。
　したがって、本件補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものではないから、特許法第１７条の２第３項（新規事項）の規定に適合していない。
　
（２）独立特許要件についての検討 
　仮に、本件補正が、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであり、また仮に、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものであると仮定した場合に、本件補正後の請求項に記載された発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
　１）特許法第３６条第６項第２号に規定する要件についての検討
　補正後の請求項１に
「前記表示手段に表示されるべき所与のタイプのメッセージが前記汎用的な属性データだけを処理することを要求する場合、当該タイプのメッセージについての処理実行モジュールをロードせずに、前記コアメッセージ送信アプリケーションに、前記メッセージ格納部から対応する汎用的な属性データを抽出して表示させることができ、前記所与のタイプのメッセージが前記汎用的でない特有の属性データを処理することを要求する場合、当該タイプのメッセージについての処理実行モジュールがロードされる
ように構成されている
　具体的に、どのような構成で「所与のタイプのメッセージが前記汎用的な属性データだけを処理することを要求する」と判断するのか、また、「前記所与のタイプのメッセージが前記汎用的でない特有の属性データを処理することを要求する」と判断するのか、不明であり、発明の構成を特定できない。
　そして、具体的に、どのような構成で「前記コアメッセージ送信アプリケーションに、前記メッセージ格納部から対応する汎用的な属性データを抽出して表示させる」ことができるのか、また具体的に、どのような構成で「当該タイプのメッセージについての処理実行モジュールがロードされる」のか、不明であり、発明の構成を特定できない。
　以上のように、補正後の請求項１に記載された発明は特許を受けようとする発明が明確でない。
　したがって、補正後の請求項１に記載された発明は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　また、補正後の請求項６に
「前記コアメッセージ送信アプリケーションが、前記所与のタイプのメッセージに特有の属性データを処理できない場合、該属性データを処理できる処理実行モジュールを、必要に応じて必要なときに呼び出す
ように構成されている
　具体的に、どのような構成で「コアメッセージ送信アプリケーションが、前記所与のタイプのメッセージに特有の属性データを処理できない」と判断するのか、また、具体的に、どのような構成で「必要に応じて必要なときに」「該属性データを処理できる処理実行モジュール」を「呼び出す」ことができるのか、不明であり、発明の構成を特定できない。
　
　以上のように、補正後の請求項６に記載された発明は特許を受けようとする発明が明確でない。
　したがって、補正後の請求項６に記載された発明は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　また、補正後の請求項７に「新たなタイプのメッセージに特有の新たな処理実行モジュールが、前記装置に
追加可能に構成されている
　具体的に、どのような構成で「新たなタイプのメッセージに特有の新たな処理実行モジュールが、前記装置に追加可能」とすることができるのか、不明であり、発明の構成を特定できない。
　以上のように、補正後の請求項７に記載された発明は特許を受けようとする発明が明確でない。
　したがって、補正後の請求項７に記載された発明は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　同じく補正後の請求項８に「前記新たな処理実行モジュールは、前記装置に動的に追加可能であり、前記装置を再起動させずに
実行可能に構成されている
　具体的に、どのような構成で「新たな処理実行モジュールは、前記装置に動的に追加可能」とすることができるのか、また、具体的に、どのような構成で「前記装置を再起動させずに実行可能」とすることができるのか、不明であり、発明の構成を特定できない。
　以上のように、補正後の請求項８に記載された発明は特許を受けようとする発明が明確でない。
　したがって、補正後の請求項８に記載された発明は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　よって、補正後の請求項１、６、７、８に記載された発明が特許出願の際独立して特許を受けることができるものではないから、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。 
　
３．結語
　以上のとおり、本件補正は、特許法第１７条の２第３項（新規事項）の規定に適合していないから、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　また、仮に、本件補正が、特許法第１７条の２第３項（新規事項）の規定、及び同法同条第４項（補正の目的）の規定のいずれにも適合してると仮定した場合においても、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができるものではないから、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。  
　したがって、いずれにしても、本件補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願について
１．本願明細書
　平成１７年１月５日付けの手続補正は上記のとおり却下されたので、本願の明細書は平成１６年１月１９日付け手続補正書により補正された明細書となり、図面は出願当初のものとなる。
　
２．原審の拒絶理由
　原審における平成１６年２月１０日付けの拒絶理由の概要は以下のとおりである。
　
「１．平成１６年１月１９日付けでした手続補正は、下記の点で願書に最初に添付した明細書又は図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
（１）補正後の請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された個々の属性データに対して、さまざまな所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいる（例えば、”サイズ”に対する”編集”を実行するための「実行処理モジュール」がメッセージのタイプ毎に用意されており、ユーザインタフェースに表示された”サイズ”に対してユーザが”編集”を指示すると、対応する「実行処理モジュール」をロード又は呼び出して実行する態様を含んでいる。）が、そのような実施例は、出願当初の明細書及び図面には記載されていない。明細書の段落【０００５】【００４０】を参照しても、複数の処理が可能となっているのは、メッセージ本体であり、その他の属性については、どのように処理するのか記載がない。
　・・・（中略）・・・
　
２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
（１）請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された属性データに対して、所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいるが、そのような実施例は、発明の詳細な説明及び図面には記載されていない。
　・・・（中略）・・・　
　よって、請求項１−１１に係る発明は、発明の詳細な説明に記載したものでない。
　
３．この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
　請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された属性データに対して個別に所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいるが、そのような実施例は記載されていない。
　　・・・（中略）・・・
　よって、この出願の発明の詳細な説明は、当業者が請求項１−１１に係る発明を実施することができる程度に明確かつ十分に記載されていない。
　
４．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
　・・・（中略）・・・
（６）請求項５の記載において、「コアユニット」が、どのようにして「全てのタイプのメッセージを単一のウインドウ内に表示する」ことを実現しているのか具体的に想定することができない。
（７）請求項１の記載において、「コアユニット」は、「実行可能でない」ことを何に基づいて判断するのか不明である。同様に、請求項７の記載において、「特有の処理が必要」であることを何に基づいて判断するのか不明である。
　また、請求項１に記載の「実行可能でない場合」の処理と、請求項６及び７に記載された「特有の属性データが含まれている場合」又は「特有の処理が必要な場合」の処理との関係が不明である。
　・・・（中略）・・・
　よって、請求項１−１１に係る発明は明確でない。」
　
３．当審の判断
　上記拒絶理由について検討する。
（１）理由１．（１）について
　ここで、願書に最初に添付した明細書又は図面を参照すると、その発明の詳細な説明（注意：下線は、当審で便宜上付与した。）には、
「【０００５】
　このため本発明は、単一のメッセージ送信アプリケーションだけを備えるメッセージ送信アーキテクチャが、現在及びおそらく将来の全ての範囲の
メッセージタイプ
「【０００７】
　一つの実施形態では、単一のメッセージ送信アプリケーションは、サポートされる全てのメッセージタイプに共有されるメッセージのいくつかの属性を処理し、サポートされる全てのメッセージタイプに適用可能ないくつかの動作をメッセージの属性に適用又は呼出す。このため、
メッセージ送信アプリケーション自身を、「汎用的」属性を処理し、「汎用的」動作を適用又は呼出す
「【００１１】
　メッセージ送信アプリケーションは、
メッセージタイプに特有の属性及び／又は動作に関するロード可能なソフトウェアコードモジュール
データベースとのインタフェース
「【００１２】
　例として、ファクシミリメッセージの転送に特有な要素をファクシミリＭＴＭ（メッセージタイプモジュール）によって処理される好適な実施形態で示すが、全ての汎用的部分もメッセージ送信アプリケーションによって処理される。　・・・（中略）・・・　ファクシミリＭＴＭはメッセージ送信アプリケーションに特定のＭＴＭ（すなわち、ファクシミリＭＴＭ）が
処理するメッセージのタイプを知らせる
メッセージ送信アプリケーションに着信メッセージを適切に処理させるように、レジストリはＤＬＬコードをアップロードする。
「【００１４】
　
メッセージタイプに特有の行動に対するＤＬＬ
「【００１５】
　第２の態様では、単一のメッセージ送信アプリケーションとインタフェース可能な１つ以上のロード可能なソフトウェアコードモジュールを備える、
所与のタイプのメッセージを操作するソフトウェアプログラムが提供され
「【００１６】
　そのようなソフトウェアプログラムは、メッセージ送信プログラムに動的にロードしてプラグイン可能であろう。ロード可能なソフトウェアコードモジュールそれぞれは、以下に記載するタスクのリストから１つ以上のタスクを個々に実行させることができる。すなわち、
　　（ａ）１つ以上のロード可能なソフトウェアコードモジュールの機能的能力のメッセージ送信アプリケーションへの報告、
　　（ｂ）スクリーン上の
メニューにテキストを供給
　　（ｃ）メッセージの生成、及び／又は編集及び／又は表示、
　　（ｄ）アプリケーションによって送信されるメッセージの外部受信者によって要求される
プロトコル及びフォーマットへの変換
「【００３５】
　・・・（中略）・・・アプリケーションフレームワーク、特にレジストリ（すなわち、ＵＩレジストリ１２、ＵＩデータレジストリ１３及びサーバ側レジストリ１４）は、この機能及びデータのずれを
全てのメッセージをタイプと関連付ける
「【００３６】
　（あらゆるタイプの）レジストリの一般的動作は、
所与のタイプのメッセージオブジェクトを操作できるコードを含むＤＬＬをロード
「【００３８】
　　・・・（中略）・・・　アプリケーション１が登録された
メッセージタイプそれぞれに対して、
特定の能力を知る必要があるとき、ＵＩレジストリ１３を呼出す
「【００３９】
　上記で示したように、ＭＴＭのＵＩデータコンポーネント１３はコアアプリケーション１に完全なメニューコマンドを供給することもできる。」、
「【００４０】
　　・・・（中略）・・・　アプリケーションはレジストリにＩＤ（アプリケーションには意味がない単純な数）を与え、ＵＩレジストリ１２はどのＤＬＬをロードするのかを捜すのにＩＤを使う。この調査はインストールされたメッセージタイプのデータベース−メッセージタイプの登録は（とりわけ）、
人間に読める名前とどのＤＬＬが必要なメッセージタイプに特有の行動を達成する適切なコードを含んでいるのかの定義
「【００４７】
　・・・（中略）・・・　その後で（メッセージの内部格納部と装置外で最初に認識されるべき外観との間の）
ソフトウェアの結合をメッセージタイプに特有の形式で適切にロードされる
「【００４９】
　ＵＩデータレジストリ１３は、ボックス内（又は他のフォルダビューワ）にメニューを生成するのに使用する
メッセージ送信できるメッセージタイプの人間に読める名前のテキストストリングを、アプリケーション１に渡す。
　
　前記発明の詳細な説明には、所与のタイプのメッセージに対して、該メッセージの汎用的な属性データを表示すること、及び所与のタイプのメッセージオブジェクトに係る処理を処理タイプ毎に対応するＤＬＬを呼び出しもしくはロードして、実行することは、記載されているが、
　請求項１−１１に係る発明で特定された「属性データに対して所定の処理を指示」するような構成、及び「レジストリユニットを参照して当該処理（「属性データに対して指示した所定の処理」）が実行可能であるか否かを判定」するような構成については、記載もないし、示唆もない。
　そして、請求項１−１１に係る発明で特定された「実行可能である場合には前記処理実行モジュールを呼び出して当該処理（「属性データに対して指示した所定の処理」）を実行させ、実行可能でない場合には対応する処理実行モジュールを前記レジストリユニットにロードさせて当該処理（「属性データに対して指示した所定の処理」）を実行させる」ような、「
実行可能である場合には
実行可能でない場合には
　
　してみれば、前記原審における平成１６年２月１０日付けの拒絶理由の理由１．（１）において「補正後の請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された個々の属性データに対して、さまざまな所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいる（例えば、”サイズ”に対する”編集”を実行するための「実行処理モジュール」がメッセージのタイプ毎に用意されており、ユーザインタフェースに表示された”サイズ”に対してユーザが”編集”を指示すると、対応する「実行処理モジュール」をロード又は呼び出して実行する態様を含んでいる。）が、そのような実施例は、出願当初の明細書及び図面には記載されていない。明細書の段落【０００５】【００４０】を参照しても、複数の処理が可能となっているのは、メッセージ本体であり、その他の属性については、どのように処理するのか記載がない。」と指摘したとおり、
　平成１６年１月１９日付けでした手続補正は願書に最初に添付した明細書又は図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　
（２）理由２．（１）について
　平成１６年１月１９日付け手続補正書により補正された、発明の詳細な説明においても、所与のタイプのメッセージに対して、該メッセージの汎用的な属性データを表示すること、及び所与のタイプのメッセージオブジェクトに係る処理を処理タイプ毎に対応するＤＬＬを呼び出しもしくはロードして、実行することは、記載されているが、
　請求項１−１１に係る発明で特定された「属性データに対して所定の処理を指示」するような構成、及び「レジストリユニットを参照して当該処理（「属性データに対して指示した所定の処理」）が実行可能であるか否かを判定」するような構成については、記載もないし、示唆もない。
　そして、請求項１−１１に係る発明で特定された「実行可能である場合には前記処理実行モジュールを呼び出して当該処理（「属性データに対して指示した所定の処理」）を実行させ、実行可能でない場合には対応する処理実行モジュールを前記レジストリユニットにロードさせて当該処理（「属性データに対して指示した所定の処理」）を実行させる」ような、「
実行可能である場合には
実行可能でない場合には
　してみれば、前記原審における平成１６年２月１０日付けの拒絶理由の理由２．（１）において「請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された属性データに対して、所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいるが、そのような実施例は、発明の詳細な説明及び図面には記載されていない。　・・・（中略）・・・　
　よって、請求項１−１１に係る発明は、発明の詳細な説明に記載したものでない。」と指摘したとおり、
　請求項１−１１に係る発明は、発明の詳細な説明に記載したものではないから、特許法第３６条第６項第１号に規定する要件を満たしていない。
　
（３）理由３について
　平成１６年１月１９日付け手続補正書により補正された、発明の詳細な説明においても、所与のタイプのメッセージに対して、該メッセージの汎用的な属性データを表示すること、及び所与のタイプのメッセージオブジェクトに係る処理を処理タイプ毎に対応するＤＬＬを呼び出しもしくはロードして、実行することは、記載されているが、
　請求項１−１１に係る発明で特定された「属性データに対して所定の処理を指示」するような構成、及び「レジストリユニットを参照して当該処理（「属性データに対して指示した所定の処理」）が実行可能であるか否かを判定」するような構成については、記載もないし、示唆もない。
　そして、請求項１−１１に係る発明で特定された「実行可能である場合には前記処理実行モジュールを呼び出して当該処理（「属性データに対して指示した所定の処理」）を実行させ、実行可能でない場合には対応する処理実行モジュールを前記レジストリユニットにロードさせて当該処理（「属性データに対して指示した所定の処理」）を実行させる」ような、「
実行可能である場合には
実行可能でない場合には
　してみれば、前記原審における平成１６年２月１０日付けの拒絶理由の理由３において「請求項１−１１に係る発明は、メッセージ本体だけではなく、件名／説明、日付、サイズ、メッセージのタイプ、発信者、第１受信者、優先度及び添付フラグといった属性データをユーザインタフェースに表示し、ユーザインタフェースを介して表示された属性データに対して個別に所定の処理（編集、表示、送信、受信、コピー、移動、削除及び印刷）が指示されたときに、指示対象の属性データに対応する処理実行モジュールをロード又は呼び出して実行する態様を含んでいるが、そのような実施例は記載されていない。
　・・・（中略）・・・
　よって、この出願の発明の詳細な説明は、当業者が請求項１−１１に係る発明を実施することができる程度に明確かつ十分に記載されていない。」と指摘したとおり、
　この出願の発明の詳細な説明は、当業者が請求項１−１１に係る発明を実施することができる程度に明確かつ十分に記載されていないから、特許法第３６条第４項に規定する要件を満たしていない。
　
（４）理由４．（６）について
　請求項５の記載「前記コアユニットは、受信した全てのタイプのメッセージを、単一のウインドウ内に表示する」とあるが、単に達成すべき機能を希望的に記載しているに過ぎず、どのような構成でどのようにして、
受信した全てのタイプのメッセージ
　してみれば、前記原審における平成１６年２月１０日付けの拒絶理由における理由４．（６）において「請求項５の記載において、「コアユニット」が、どのようにして「全てのタイプのメッセージを単一のウインドウ内に表示する」ことを実現しているのか具体的に想定することができない。」と指摘したとおり、
　請求項５に係る発明は明確でないから、この出願は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
（５）理由４．（７）について
　請求項１に
「複数のタイプのメッセージで共通に使用される汎用的な属性データを前記ユーザインタフェースに表示させるコアユニットと、
　サポートしているメッセージのタイプ、各タイプのメッセージに含まれる属性データ、及び各タイプのメッセージの属性データに対して実行可能な処理の情報を関連付けて記憶するレジストリユニットと、
　・・・（中略）・・・　
　前記コアユニットは、前記ユーザインタフェースを介して前記属性データに対して所定の処理が指示されたときに、前記レジストリユニットを参照して当該処理が実行可能であるか否かを判定し、・・・（中略）・・・　実行可能でない場合には対応する処理実行モジュールを前記レジストリユニットにロードさせて・・・」とある。
　ここで、「当該処理」とは、ユーザインタフェースを介して前記属性データに対して指示された所定の処理を意味する。
　また、「前記属性データ」は、ユーザインタフェースを介している（すなわち、表示されている）ことから、「コアユニット」が「ユーザインタフェース」に表示させる「複数のタイプのメッセージで共通に使用される汎用的な属性データ」であると解される。
　また、「前記レジストリユニット」は、「サポートしているメッセージのタイプ、各タイプのメッセージに含まれる属性データ、及び各タイプのメッセージの属性データに対して実行可能な処理の情報を関連付けて記憶する」ものである。
　そして、実行可能でない場合の「対応する処理実行モジュール」とは、レジストリユニットに記憶された「各タイプのメッセージの属性データに対して実行可能な処理の情報」であると推定される。
　したがって、前記請求項１に記載された事項は、
　「サポートしているメッセージのタイプ、各タイプのメッセージに含まれる属性データ、及び各タイプのメッセージの属性データに対して実行可能な処理の情報を関連付けて記憶する」レジストリユニットを参照して、「コアユニット」が「ユーザインタフェース」に表示させた「複数のタイプのメッセージで共通に使用される汎用的な属性データ」に対して指示された所定の処理が、実行可能か実行可能でないと判断するものであり、実行可能でないと判断した場合には、レジストリユニットを参照して「対応する処理実行モジュール」を特定してロードさせていると認められる。
　しかるに、「レジストリユニット」には、「実行可能な処理の情報を関連付けて」いる以上、レジストリユニットに関連づけて記憶されていない場合に実行可能でないと判断すると解される。
　他方、実行可能でない場合には「対応する処理実行モジュール」を特定してロードすることから、レジストリユニットに関連づけて記憶されているとも解される。
　よって、どのようにして、「実行可能でない」ことを判断して、「対応する処理実行モジュール」を特定してロードさせるのか、その具体的な構成が不明であり、発明の構成を特定できないから、前記請求項１に係る発明は明確でない。
　
　また、請求項７に「コアユニットは、前記メッセージに対して特有の処理が必要な場合、該処理に関連した処理実行モジュールを前記レジストリユニットにロードさせる」とあるが、単に「前記メッセージに対して特有の処理が必要な場合、」と達成すべき機能を希望的に記載するに過ぎず、コアユニットはどのような構成でどのようにして、前記メッセージに対して特有の処理が必要かどうかを判断するのか、不明であり、発明の構成を特定できないから、前記請求項７に係る発明は明確でない。
　
　そして、請求項６に記載された「コアユニットは、前記メッセージに特有の属性データが
含まれている場合
必要な場合
　他方、請求項６、及び７が引用する請求項１においては、「コアユニットは、前記ユーザインタフェースを介して前記属性データに対して所定の処理が
指示されたとき
実行可能でない場合
　したがって、請求項６においては、「コアユニット」は、「前記ユーザインタフェースを介して前記属性データに対して所定の処理が
指示されたとき
実行可能でない場合
含まれている場合
　そして、「属性データに対して所定の処理が指示されたときに・・・（中略）・・・
実行可能でない場合
含まれている場合
　
　同様に、請求項７においては、「コアユニット」は、「前記ユーザインタフェースを介して前記属性データに対して所定の処理が指示されたときに、前記レジストリユニットを参照して当該処理が実行可能であるか否かを判定し、・・・（中略）・・・　
実行可能でない場合
特有の処理が必要な場合
　そして、「属性データに対して所定の処理が指示されたときに・・・（中略）・・・
実行可能でない場合
特有の処理が必要な場合
　
　してみれば、前記原審における平成１６年２月１０日付けの拒絶理由の理由４．（７）において「請求項１の記載において、「コアユニット」は、「実行可能でない」ことを何に基づいて判断するのか不明である。同様に、請求項７の記載において、「特有の処理が必要」であることを何に基づいて判断するのか不明である。
　また、請求項１に記載の「実行可能でない場合」の処理と、請求項６及び７に記載された「特有の属性データが含まれている場合」又は「特有の処理が必要な場合」の処理との関係が不明である。」と指摘したとおり、
　請求項１、６、及び７に係る発明は明確でないから、この出願は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
４．むすび
　以上のとおり、平成１６年１月１９日付けでした手続補正は願書に最初に添付した明細書又は図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　また、本願明細書は、特許法第３６条第６項第１号、特許法第３６条第６項第２号、及び特許法第３６条第４項に規定する要件を満たしていないから、特許を受けることができない。
　よって、結論のとおり審決する。