【事件の表示】
　平成１１年特許願第３５５９２０号「インターフェースを修正する方法、インターフェースを付加する方法、記録媒体、及びコンピュータシステム」拒絶査定不服審判事件〔平成１２年　７月　４日出願公開、特開２０００−１８７５９４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明 
　本願は、平成１１年１２月１５日（パリ条約による優先権主張１９９８年１２月１８日、米国）の出願であって、平成２１年７月２１日付けで拒絶理由通知がなされ、同年１２月２６日付けで意見書が提出されるとともに手続補正がなされたが、平成２２年１月２０日付けで拒絶査定がなされ、これに対し、同年５月２６日に審判請求がなされるとともに同日付けで手続補正がなされたものである。そして、同年６月１８日付けで審査官から前置報告がなされ、平成２３年３月２４日付けで当審より審尋がなされたものである。
　そして、特許請求の範囲は、平成２２年５月２６日付け手続補正書により補正された明細書の記載からみて、その特許請求の範囲に記載された以下のとおりのものと認める。
　
「【請求項１】　１つ又はそれ以上のインターフェースを包含しており且つ各インターフェースが対応するインプリメンテーションクラスを持っているボスオブジェクトに対する１組の使用可能なインターフェースを修正する方法において、コンピュータが、
　第一ソフトウエアコンポーネントで定義されている第一インターフェースを持っており記憶装置内に格納されている第一ボスクラスを読取る手順、
　別の第二ソフトウエアコンポーネントで定義されており前記記憶装置内に格納されている第二インターフェースを読取る手順、
　前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含する第一ボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドする手順、
を実行することを特徴とする方法。
　　【請求項２】　請求項１において、前記バインドする手順がランタイムにおいて行われることを特徴とする方法。
　　【請求項３】　請求項２において、前記第一ボスオブジェクトに対する１組の使用可能なインターフェースが前記第一インターフェースと前記第二インターフェースとを包含していることを表わすことが可能なメソッドを前記第一ボスオブジェクトが有していることを特徴とする方法。
　　【請求項４】　請求項２において、更に、前記コンピュータが、
　使用可能なインターフェースについて前記第一ボスオブジェクトに対して質問する手順、
　前記第一ボスオブジェクトが前記第一ボスクラス内に包含されている使用可能なインターフェースと前記第一ボスクラスにバインドされているインターフェースとを有することを表わす前記質問に対する応答を受取る手順、
を実行することを特徴とする方法。
　　【請求項５】　請求項２において、更に、前記コンピュータが、
　前記第一ボスオブジェクトに対して使用可能なインターフェースのリストであって前記第一ボスクラス内に包含しているインターフェースと前記第一ボスクラスへバインドされているインターフェースとを包含しているリストを形成する手順、
を実行することを特徴とする方法。
　　【請求項６】　請求項５において、更に、前記コンピュータが、
　前記使用可能なインターフェースのリストに対する参照を包含する前記第一ボスクラスのインスタンス化によって前記第一ボスオブジェクトを形成する手順、
を実行することを特徴とする方法。
　　【請求項７】　請求項２において、前記第二インターフェースが前記第一インターフェースの少なくとも１部をオーバーライドすることを特徴とする方法。
　　【請求項８】　請求項２において、前記第二インターフェースが前記第一インターフェースの少なくとも１部をディスエーブルさせることを特徴とする方法。
　　【請求項９】　請求項２において、更に、前記コンピュータが、
　前記第一ボスクラスから継承する第二ボスクラスを読取る手順、
　前記第二ボスクラスをインスタンス化することによって前記第一インターフェースと前記第二インターフェースとを包含している第二ボスオブジェクトを形成する手順、
を実行することを特徴とする方法。
　　【請求項１０】　請求項２において、更に、前記コンピュータが、
　前記第一インターフェースに対応する第一インプリメンテーションクラスであって前記第一ボスクラスとは別のソフトウエアコンポーネントで定義されている第一インプリメンテーションクラスを読取る手順、
を実行することを特徴とする方法。
　　【請求項１１】　請求項２において、更に、前記コンピュータが、
　前記第二インターフェースに対応する第二インプリメンテーションクラスであって前記第二インターフェースとは別のソフトウエアコンポーネントで定義されている第二インプリメンテーションクラスを読取る手順、
を実行することを特徴とする方法。
　　【請求項１２】　請求項２において、前記第二インターフェースがアドインクラスで定義されていることを特徴とする方法。
　　【請求項１３】　１つ又はそれ以上のインターフェースを包含しており且つ各インターフェースが対応するインプリメンテーションクラスを持っているボスオブジェクトに対する１組の使用可能なインターフェースを修正する方法において、コンピュータが、
　第一ソフトウエアコンポーネントで定義されている第一インターフェースを持っており記憶装置内に格納されているボスクラスを読取る手順、
　別の第二ソフトウエアコンポーネントで定義されており前記記憶装置内に格納されている第二インターフェースを読取る手順、
　前記第二インターフェースを前記ボスクラスへバインドする手順、
　前記ボスクラスをインスタンス化して前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを作成する手順、
を実行することを特徴とする方法。
　　【請求項１４】　１つ又はそれ以上のインターフェースを包含しており且つ各インターフェースが対応するインプリメンテーションクラスを持っているボスクラスに対してインターフェースを動的に付加するコンピュータによって実現される方法において、コンピュータが、
　第一インターフェースを持っており記憶装置内に格納されている第一ボスクラスを読取る手順、
　前記第一ボスクラスとは別のソフトウエアコンポーネントで定義されており前記記憶装置内に格納されている第二インターフェースを読取る手順、
　前記第一ボスクラスをインスタンス化することによって前記第一インターフェースを包含している第一ボスオブジェクトを形成する手順、
　前記第二インターフェースを前記第一ボスクラスへバインドする手順、
　前記第二インターフェースを前記第一ボスクラスへバインドした後に前記第二インターフェースを包含するために前記第一ボスオブジェクトをアップデートする手順、
　前記第一ボスクラスをインスタンス化することによって前記第一インターフェースと前記第二インターフェースとを包含している第二ボスオブジェクトを形成する手順、
を実行することを特徴とする方法。
　　【請求項１５】　請求項１４において、更に、前記コンピュータが、
　第三インターフェースを持っており且つ前記第一ボスオブジェクトのいずれかのインターフェースを継承する第二ボスクラスであって前記第一ボスクラスとは別のソフトウエアコンポーネント内に存在しており前記記憶装置内に格納されている第二ボスクラスを読取る手順、
　前記第二インターフェースを前記第一ボスクラスへバインドする前に前記第二ボスクラスをインスタンス化することによって前記第一インターフェースと前記第三インターフェースとを包含している第三ボスオブジェクトを形成する手順、
　前記第二インターフェースを前記第一ボスクラスへバインドした後に前記第二ボスクラスをインスタンス化することによって前記第一インターフェースと、前記第二インターフェースと、前記第三インターフェースとを包含している第四ボスオブジェクトを形成する手順、
を実行することを特徴とする方法。
　　【請求項１６】　請求項１５において、前記第一ボスクラス及び前記第二ボスクラスが別のソフトウエアコンポーネント内に存在していることを特徴とする方法。
　　【請求項１７】　１つ又はそれ以上のインターフェースを包含しており且つ各インターフェースが対応するインプリメンテーションクラスを持っているボスオブジェクトを修正するためのコンピュータプログラムを記録したコンピュータによって読取可能な記録媒体において、前記コンピュータプログラムが、コンピュータをして、
　第一ソフトウエアコンポーネント内に定義されている第一インターフェースを持っている第一ボスオブジェクトを読取らせる手順、
　別の第二ソフトウエアコンポーネント内に定義されている第二インターフェースを読取らせる手順、
　前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドさせる手順、
を実行させることを特徴とする記録媒体。
　　【請求項１８】　１つ又はそれ以上のインターフェースを包含しており且つ各インターフェースが対応するインプリメンテーションクラスを持っているボスオブジェクトを修正するコンピュータシステムにおいて、
　前記コンピュータシステムの記憶装置内に格納されている第一ソフトウエアコンポーネント内に定義されている第一インターフェースを持っている第一ボスクラスを読取る手段、
　前記記憶装置内に格納されている別の第二ソフトウエアコンポーネント内に定義されている第二インターフェースを読取る手段、
　前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドさせる手段、
を有していることを特徴とするコンピュータシステム。」
　
２．原査定の拒絶理由 
　平成２１年７月２１日付けで通知された拒絶理由は、次のとおりである。 
　 
「　　　　　　　　　　　　　　　　理　由
　・・・（中略）・・・
３．この出願は、明細書の記載が下記の点で、特許法第３６条第４項並びに第６項第１号及び第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
　・・・（中略）・・・
（４）発明の詳細な説明及び図面には、例えば段落【００３６】乃至【００３８】に通常のコンピュータの構成が通常のレベルで記載されている程度であり、実質的にはソフトウェアのプログラミングモデルが開示されているのみであり、各請求項に係る発明をコンピュータ上でどのように実現しているのかについて明確かつ十分に記載していない。
（５）請求項１、１３、１４、１６乃至１８、２１、２３乃至２６の記載において、「バインド」とはどのような処理であるのか不明である。
　発明の詳細な説明の記載においても、「バインド」がどのような処理であり、どのように実現しているのかについて、明確かつ十分に記載していない。
　また、図２乃至５において、ＩＮＴ３（１３０）とＩＭＰ３（１２５）との間、及び、ボスオブジェクト（１１０）と補充的インターフェース定義（１１５）との間が波線の矢印で接続され、かつ、ＩＮＴ３（１３０）が波線のボックスで表現されているが、これらがどのような意味であり、前記の「バインド」とどのような関係にあり、かつ、プログラムコードとしてはどのように実現されているのか不明である。
　・・・（後略）」
　
３．当審の判断 
　前記拒絶理由の「理由３」の「（５）」において挙げた理由が解消したか否かについて検討する。
　なお、前記平成２２年５月２６日付け手続補正書で補正された請求項１、請求項１３、請求項１４、請求項１７、及び請求項１８（以下、「新請求項」という）は、それぞれ、前記拒絶理由で指摘した請求項１、請求項１４、請求項１８、請求項２３、及び請求項２５（以下、「旧請求項」という）に対応する。
　
　新請求項１（旧請求項１に対応）について検討する。
　新請求項１における発明特定事項「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含する第一ボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドする手順」における「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含する第一ボスオブジェクトを形成するように、…」は、単に本願発明が解決しようとする課題を記載しているに過ぎない。（発明の詳細な説明の段落【０００５】における記載「本発明は、オブジェクトマネージャを介してランタイムでボスオブジェクトへインターフェースを付加する技術を実現する方法及び装置を提供することを目的とする。」を参照。）
　そして、前記課題を解決するための構成として、「前記第二インターフェースを前記第一ボスクラスへバインドする手順」を実行するようにしたものである。
　しかしながら、前記構成「前記第二インターフェースを前記第一ボスクラスへバインドする手順」について、新請求項１には、これ以上の記載はなく、新請求項１に係る発明の「バインド」とはどのような処理を意味するのか、依然として不明であり、また、「コンピュータ」が、具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、依然として不明であり、発明が明確でない。
　
　新請求項１３（旧請求項１４に対応）について検討する。
　新請求項１３における記載
「別の第二ソフトウエアコンポーネントで定義されており前記記憶装置内に格納されている第二インターフェースを読取る手順、
　前記第二インターフェースを前記ボスクラスへバインドする手順、
　前記ボスクラスをインスタンス化して前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを作成する手順、…」においても、「第二インターフェースを前記ボスクラスへバインドする手順」について、新請求項１３には、これ以上の記載はなく、新請求項１３に係る発明の「バインド」とはどのような処理を意味するのか、依然として不明であり、また、「コンピュータ」が、具体的にどのような手順で、どのようにして、ボスクラスへ前記第二インターフェースを「バインド」するのか、依然として不明であり、発明が明確でない。
　
　新請求項１４（旧請求項１８に対応）について検討する。
　新請求項１４における記載
「前記第一ボスクラスとは別のソフトウエアコンポーネントで定義されており前記記憶装置内に格納されている第二インターフェースを読取る手順、
　…　
　前記第二インターフェースを前記第一ボスクラスへバインドする手順、
　前記第二インターフェースを前記第一ボスクラスへバインドした後に前記第二インターフェースを包含するために前記第一ボスオブジェクトをアップデートする手順、
　前記第一ボスクラスをインスタンス化することによって前記第一インターフェースと前記第二インターフェースとを包含している第二ボスオブジェクトを形成する手順、…」においても、「前記第二インターフェースを前記第一ボスクラスへバインドする手順」について、新請求項１４には、これ以上の記載はなく、新請求項１４に係る発明の「バインド」とはどのような処理を意味するのか、依然として不明であり、また、「コンピュータ」が、具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、依然として不明であり、発明が明確でない。
　
　新請求項１７（旧請求項２３に対応）について検討する。
　新請求項１７において、「コンピュータプログラムが、コンピュータをして、」「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドさせる手順」「を実行させる」と記載されている。
　しかしながら、前記「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように…」は、単に、本願発明が解決しようとする課題を記載しているに過ぎない。（発明の詳細な説明の段落【０００５】における記載「本発明は、オブジェクトマネージャを介してランタイムでボスオブジェクトへインターフェースを付加する技術を実現する方法及び装置を提供することを目的とする。」を参照）
　そして、前記課題を解決するために、「前記第二インターフェースを前記第一ボスクラスへバインドする手順」を実行するようにしたものである。
　しかしながら、前記構成「前記第二インターフェースを前記第一ボスクラスへバインドする手順」について、新請求項１７には、これ以上の記載はなく、新請求項１７に係る発明の「バインド」とはどのような処理を意味するのか、依然として不明であり、また、「コンピュータプログラムが、コンピュータをして、」具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、依然として不明であり、発明が明確でない。
　
　新請求項１８（旧請求項２５に対応）について検討する。
　新請求項１８において、「コンピュータシステムにおいて、」「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように前記第二インターフェースを前記第一ボスクラスへバインドさせる手段」「を有している」と記載されている。
　しかしながら、前記「前記第一ボスクラスのインスタンス化が前記第一インターフェースと前記第二インターフェースとを包含するボスオブジェクトを形成するように…」は、単に、本願発明が解決しようとする課題を記載しているに過ぎない。（発明の詳細な説明の段落【０００５】における記載「本発明は、オブジェクトマネージャを介してランタイムでボスオブジェクトへインターフェースを付加する技術を実現する方法及び装置を提供することを目的とする。」を参照）
　そして、前記課題を解決するために、「コンピュータシステムにおいて、」「前記第二インターフェースを前記第一ボスクラスへバインドさせる手段」「を有している」ようにしたものである。
　しかしながら、前記「前記第二インターフェースを前記第一ボスクラスへバインドさせる手段」について、新請求項１８には、これ以上の記載はなく、新請求項１８に係る発明の「バインド」とはどのような処理を意味するのか、依然として不明であり、また、「前記第二インターフェースを前記第一ボスクラスへバインドさせる手段」は、具体的にどのような構成で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、依然として不明であり、発明が明確でない。
　
　以上のように、「理由３」の「（５）」で「請求項１、１３、１４、１６乃至１８、２１、２３乃至２６の記載において、「バインド」とはどのような処理であるのか不明である。」と指摘した拒絶理由は依然として解消していない。
　
　そして、発明の詳細な説明には、
「【００１３】
　
ボスクラスは通常のＯＯＰ意味におけるクラスではない
ボスクラスはボスオブジェクト１１０とインプリメンテーションオブジェクト１２５の組合せ
「【００１４】
　…ボスオブジェクト１１０はオブジェクトマネージャ１０５からボスオブジェクト１１０に対して使用可能な１組のインターフェース１２０に対する参照を受取る。…ボスオブジェクト１１０は
インプリメンテーションオブジェクト１２５に対する参照のリスト
「【００１５】
　…
インプリメンテーションクラスが以下に説明するようにインスタンス化される
インプリメンテーションオブジェクト１２５が形成
参照がボスオブジェクト１１０のリストへ付加
「【００１６】
　…オブジェクトマネージャ１０５は、ボスクラスが上述した如くにインスタンス化される場合に、使用可能なインターフェース１２０のリストに対する参照をボスオブジェクト１１０へ供給するからである。」、
「【００１７】
　
アドインクラス１１５は
インターフェース１２０を定義
アドインクラス１１５はインスタンス化されることはない
オブジェクトマネージャ１０５が
インターフェース１２０をボスオブジェクト１１０へ供給
アドインクラス１１５は
インプリメンテーションクラスを定義
「【００１８】
　オブジェクトマネージャ１０５は各ボスクラスに対して使用可能なインターフェース１２０の履歴を維持する。
オブジェクトモデル１００を使用するアプリケーションプログラム
オブジェクトマネージャ１０５は各使用可能なボスクラスを登録し且つ使用可能なインターフェース１２０のリスト１０７を形成
オブジェクトマネージャ１０５は使用可能なインターフェースのリスト１０７をランタイムで形成するので
オブジェクトモデル１００はボスクラスに対してインターフェース１２０のランタイム付加を与える
「【００１９】
　
オブジェクトマネージャ１０５がリスト１０７を形成した後に
ボスクラスをインスタンス化する
ボスオブジェクト１１０に対して使用可能なインターフェース１２０の組がランタイムで形成されるオブジェクトマネージャ１０５のリスト１０７に従って決定される
「【００２８】
　図６に示したように、ランタイムでボスオブジェクトに対して使用可能な１組のインターフェースに対してインターフェースを付加するプロセス６００において、ボスクラスが定義される（ステップ６０５）。アドインクラスがボスクラスへ付加されるべき１つ又はそれ以上のインターフェースを定義する（ステップ６１０）。ランタイムにおいて、オブジェクトマネージャがボスクラス及びアドインクラスの定義を読取り且つアドインクラスのインターフェースを対応するボスクラスに対してバインド即ち結び付ける（ステップ６１５）。
オブジェクトマネージャはアドインクラスからのインターフェースを上述した如くリスト内のボスクラスにおいて定義されているインターフェースと関連付けすることによって、インターフェースをボスクラスに対してバインド
オブジェクトマネージャは該リストを使用してボスクラスのインスタンス化を行う
ボスオブジェクトは使用可能なインターフェースに対応するインプリメンテーションオブジェクトに対する参照のリストを包含
　
　しかしながら、段落【００２８】における記載「オブジェクトマネージャはアドインクラスからのインターフェースを上述した如くリスト内のボスクラスにおいて定義されているインターフェースと関連付けすることによって、インターフェースをボスクラスに対してバインド即ち結び付ける。」を参照しても、新請求項１（旧請求項１に対応）に係る発明の「コンピュータ」が、具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、不明であり、当該バインド手順がどのような処理であり、どのように実現しているのかについて、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　また、当該段落【００２８】に先行する段落【００１３】における記載「ボスクラスは通常のＯＯＰ意味におけるクラスではない。…ボスクラスはボスオブジェクト１１０とインプリメンテーションオブジェクト１２５の組合せによって表わされる。」、段落【００１５】における記載「インプリメンテーションクラスが以下に説明するようにインスタンス化されると、別のインプリメンテーションオブジェクト１２５が形成され且つそのインプリメンテーションオブジェクト１２５に対する参照がボスオブジェクト１１０のリストへ付加される。」、段落【００１７】における記載「アドインクラス１１５はボスクラスを特定し且つそのボスクラスへ付加すべき１つ又はそれ以上のインターフェース１２０を定義する。アドインクラス１１５は同様の態様でボスクラスとしてインターフェース１２０を定義するが、アドインクラス１１５はインスタンス化されることはない。」、段落【００１７】における記載「オブジェクトマネージャ１０５がボスクラス内で定義されたインターフェース１２０及びそのボスクラスと関連する任意のアドインクラス１１５において定義されているインターフェース１２０をボスオブジェクト１１０へ供給する。」、段落【００１８】における記載「オブジェクトマネージャ１０５は各ボスクラスに対して使用可能なインターフェース１２０の履歴を維持する。オブジェクトモデル１００を使用するアプリケーションプログラムが初期的に実行を行う場合には、オブジェクトマネージャ１０５は各使用可能なボスクラスを登録し且つ使用可能なインターフェース１２０のリスト１０７を形成する。」、及び段落【００１９】における記載「ボスオブジェクト１１０に対して使用可能なインターフェース１２０の組がランタイムで形成されるオブジェクトマネージャ１０５のリスト１０７に従って決定されるので… 」を参照しても、バインド手順が具体的にどのような処理を行っているのか、不明であり、新請求項１（旧請求項１に対応）に係る発明の「コンピュータ」が、具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、不明であり、当該バインド手順がどのような処理であり、どのように実現しているのかについて、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　そして、新請求項１（旧請求項１に対応）に係る発明をコンピュータ上でどのように実現しているのかについても、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　
　同様に、新請求項１３（旧請求項１４に対応）に係る発明の「コンピュータ」が、具体的にどのような手順で、どのようにして、ボスクラスへ前記第二インターフェースを「バインド」するのか、また、新請求項１４（旧請求項１８に対応）に係る発明の「コンピュータ」が、具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、また、新請求項１７（旧請求項２３に対応）に係る発明の「コンピュータプログラムが、コンピュータをして、」具体的にどのような手順で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、また、新請求項１８（旧請求項２５に対応）に係る発明の「前記第二インターフェースを前記第一ボスクラスへバインドさせる手段」は、具体的にどのような構成で、どのようにして、第一ボスクラスへ前記第二インターフェースを「バインド」するのか、について、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　また、新請求項１３（旧請求項１４に対応）に係る発明、新請求項１４（旧請求項１８に対応）に係る発明、新請求項１７（旧請求項２３に対応）に係る発明、及び新請求項１８（旧請求項２５に対応）に係る発明をコンピュータ上でどのように実現しているのかについても、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　
　なお、請求人は、平成２２年５月２６日付け審判請求書において、
『…「バインド」という処理はＩＴ技術者にとっては自明な技術であり、本願発明においては、どのように「バインド」されるかということは問題ではなく、例えば、図１に示されているように、
アドインクラス内のインターフェースを
インターフェースと
関連付けさせること
『本願発明によれば、ボスクラスの機能拡張を行う場合に、アドインクラス（第二ソフトウエアコンポーネント）内に定義されている
第二インターフェースを
第一インターフェースと「バインド」させる
『「バインドとは、束縛（する）、拘束（する）、結びつける、関連付けする、などの意味を持つ英単語。ＩＴの分野では、何らかの要素やデータ、ファイルなどが相互に関連付けられている状態や、
そのような状態を実現する機能
『そして、更に、 
　「キーボードで、個々のキーへの記号や機能の割り当てのことを「キーバインド」という。 
　データベース管理システム（ＤＢＭＳ）で、データベースを操作するプログラムを作成する際に、ＳＱＬ文にプログラムの変数を埋め込むことをバインド変数という。」 
と説明されている。』（４頁１０行目〜１６行目）（以下、「主張４」という）、
『更に、インターネット上の「［ＡＰＳ．ＮＥＴ］ＧｒｉｄＶｉｅｗコントロールにオブジェクトをバインドするには？［２．０、３．０、３．５、Ｃ＃、ＶＢ］」という表題の「．ＮＥＴ　ＴＩＰＳ」に関する技術文献においては、 
　「そのようなケースでは、やはりデータソースの接続からデータの取得、データアクセス・コントロールへのバインドを一からコーディングしなければならないのだろうか。　否、そのようなことはない。ObjectDataSourceコントロールを利用すれば、自作のデータアクセス・オブジェクト（データアクセス・コンポーネント）を介して、データソースを操作できようになる。 
　ObjectDataSourceコントロールとは、GridViewコントロールと自作のクラス（データアクセス・コンポーネント）を結び付けるための接着剤のようなものだと考えても良いだろう。」 
 と記載されている。即ち、オブジェクト指向プログラミングにおいて、「バインド」という処理を行う場合には、初めからコーディングを行うことも可能であるが、
「．ＮＥＴ」を使用する場合には、ObjectDataSourceという予め定められている手順を実装する
『更に、インターネット上の「シングルインスタンスをWindowsフォームにデータバインドする方法」という表題の技術文献においては、 
 　「
．ＮＥＴプラットフォームのデータバインディング機能は強力な開発ルール
　…　手作業でコードを書いて、オブジェクトのプロパティとＧＵＩ要素（テキストボックス、データグリッド、チェックボックスなど）の間でデータをマーシャリングしてきました。しかし、．ＮＥＴ　Ｆｒａｍｅｗｏｒｋには、これまでにない豊富な機能が備わっています。特に、アプリケーションでデータバインディングを使うことには、大きな魅力があります。」 
 と記載されている。即ち、「バインド」という処理自体はアプリケーションの基本的な部分として従来から存在しており、それが従来は手作業によってコーディングされていたものであるが、
．ＮＥＴ　Ｆｒａｍｅｗｏｒｋによれば、予め準備された特定のコードを使用して簡単にプログラミングすることが可能である
『更に、オープンソースの汎用スクリプト言語であるＰＨＰにおいては、たとえば、「mysqli_stmt::bind_param」というパラメータに変数をバインドさせるスクリプトが用意されている。この点については、たとえば、インターネット上の「プリペアドステートメントのパラメータに変数をバインドする」という表題の技術文献中に記載されている。』（５頁２７行目〜６頁２行目）（以下、「主張７」という）、
『更に、インターネット上の「バインドとモデルクラス−［Ｊａｖａプログラミング］Ａｌｌ　Ａｂｏｕｔ」においては、 
　「JavaFX Scriptには、ある値と別の値を関連付ける「バインド」という機能が用意されているのです。これを利用し、ウイジェットやアトリビュートを別の値（変数など）に関連付け、操作することができるのです。」 
　と記載されている。この技術文献においても、「バインド」という処理がＪａｖａプログラミングにおいても或る値と別の値とを関連付ける機能として用意されていることが記載されている。』（６頁３行目〜１０行目）（以下、「主張８」という）、
『更に、インターネット上の「メッセージとバインド」という表題の技術文献においても、
　「メッセージを特定のメソッドと結びつけ、それを具体的なインタスタンスの挙動として特定することをバインド（束縛などと訳されます）といいます。」 
 と記載されている。』（６頁１１行目〜１５行目）（以下、「主張９」という）、
『本願発明においても、図面中の点線（１１７，１３０，１３２）はインターフェースをバインドさせた状態を示すものであるが、そのバインド自体をどのように具体的に実現させるかは使用するプログラミング言語などによって多種多様な形態を取りえるものであることは当業者には自明な事項である。本願発明においては、どのように具体的にバインドさせるかということが問題なのではなく（何故ならば、バインドという処理自体は使用するプログラミング言語などによって異なる態様を取りえるものであるから）、どのような形態をとろうとも「バインド」という処理によってアドインクラス内の
インターフェースを
インターフェースと
関連付けを行う
と主張する。
　
　上記主張のうち、主張１（「
アドインクラス内のインターフェースを
インターフェースと
関連付けさせること
第二インターフェースを
第一インターフェースと「バインド」させる
インターフェースを
インターフェースと
関連付けを行う
第二インターフェースを
第一インターフェースと「バインド」させる
そのような状態を実現する機能
　さらに、新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８における「バインド」手順または「バインド」手段について、発明の詳細な説明に、当業者がその実施をすることができる程度に明確かつ十分に記載していることを説明するものでもない。
　
　上記主張のうち、主張３（『「バインドとは、束縛（する）、拘束（する）、結びつける、関連付けする、などの意味を持つ英単語。ＩＴの分野では、何らかの要素やデータ、ファイルなどが相互に関連付けられている状態や、
そのような状態を実現する機能
　さらに、新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８における「バインド」手順または「バインド」手段について、発明の詳細な説明に、当業者がその実施をすることができる程度に明確かつ十分に記載していることを説明するものでもない。
　
　上記主張のうち、主張４（『「キーボードで、個々のキーへの記号や機能の割り当てのことを「キーバインド」という。 
　データベース管理システム（ＤＢＭＳ）で、データベースを操作するプログラムを作成する際に、ＳＱＬ文にプログラムの変数を埋め込むことをバインド変数という。」 
と説明されている。』）における「キーバインド」及び「ＳＱＬ文にプログラムの変数を埋め込むこと」は、いずれも新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８の「バインド」とは関係がないから、前記請求人の主張４は採用することができない。
　
　上記主張のうち、主張５及び主張６については、ともに「．ＮＥＴ」において「バインディング」機能を実現していることを主張するものである。さらに、主張５においては、「データソースの接続からデータの取得、データアクセス・コントロールへのバインドを一からコーディング」しないで、「オブジェクト指向プログラミングにおいて、「バインド」という処理を行う場合には、初めからコーディングを行うことも可能であるが、
「．ＮＥＴ」を使用する場合には、ObjectDataSourceという予め定められている手順を実装する
ＮＥＴ　Ｆｒａｍｅｗｏｒｋによれば、
簡単にプログラミングすることが可能である
　さらに、新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８における「バインド」手順または「バインド」手段について、発明の詳細な説明に、当業者がその実施をすることができる程度に明確かつ十分に記載していることを説明するものでもない。
　
　上記主張のうち、主張７については「オープンソースの汎用スクリプト言語であるＰＨＰ」の備える「「mysqli_stmt::bind_param」というパラメータに変数をバインドさせるスクリプト」を、主張８については「Ｊａｖａプログラミング」の備える「ウイジェットやアトリビュートを別の値（変数など）に関連付け、操作することができる」「JavaFX Script」を説明するに過ぎず、いずれも新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８の記載に基づかない主張であるから、前記請求人の主張７及び主張８は採用することができない。
　さらに、新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８における「バインド」手順または「バインド」手段について、発明の詳細な説明に、当業者がその実施をすることができる程度に明確かつ十分に記載していることを説明するものでもない。
　
　上記主張のうち主張９については、単に「メッセージ」を「特定のメソッド」と結びつけ、それを具体的なインタスタンスの挙動として特定することを主張するに過ぎず、新請求項１、新請求項１３、新請求項１４、新請求項１７、及び新請求項１８の「バインド」とは関係がないから、前記請求人の主張４は採用することができない。
　（なお、請求人は、インターネット上の文献を挙げて主張しているが、前記文献についてのＵＲＬ及び公知となった日付についての記載がなく、本願発明の優先日（１９９８年１２月１８日）において、前記文献が当業者にとって周知であったかどうか、不明である。）
　
　以上のように、前記審判請求の理由を参照しても、特許請求の範囲の新請求項１（旧請求項１に対応）、新請求項１３（旧請求項１４に対応）、新請求項１４（旧請求項１８に対応）、新請求項１７（旧請求項２３に対応）、及び新請求項１８（旧請求項２５に対応）の記載は、特許を受けようとする発明が、依然として明確でない。
　また、新請求項１（旧請求項１に対応）、新請求項１３（旧請求項１４に対応）、新請求項１４（旧請求項１８に対応）、新請求項１７（旧請求項２３に対応）、及び新請求項１８（旧請求項２５に対応）における「バインド」手順または「バインド」手段について、発明の詳細な説明に、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　また、各請求項に係る発明を、コンピュータ上でどのように実現しているのかについても、発明の詳細な説明には、当業者がその実施をすることができる程度に明確かつ十分に記載していない。
　
　以上のとおりであるから、本件出願は、「理由３」の指摘事項「（４）」及び「（５）」に係る拒絶理由が依然として解消しておらず、特許法第３６条第４項及び特許法第３６条第６項第２号に規定する要件を満たしていない。
　
４．むすび 
　以上のとおり、本願の出願は、特許法第３６条第４項及び特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　よって、結論のとおり審決する。