【事件の表示】
　平成　７年特許願第５０９１４６号「マルチメディア・データ・ルーチング・システム」拒絶査定不服審判事件〔平成　７年　３月２３日国際公開、ＷＯ９５／０８１４８、平成　９年　３月２５日国内公表、特表平　９−５０３０８０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　国際出願日　　　　　平成６年１月３日（パリ条約による優先権主張１９　　　　　　　　　　　９３年９月１３日、米国） 
　拒絶査定　　　　　　平成１６年８月３日付 
　審判請求　　　　　　平成１６年１１月８日 
　手続補正　　　　　　平成１６年１２月８日 
　拒絶理由通知　　　　平成１９年１月１５日付 
　意見書、手続補正　　平成１９年４月１６日 
　 
２．本願発明 
　本願の特許請求の範囲の請求項１に係る発明は、補正された明細書及び図面の記載からみて、平成１９年４月１６日付け手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。 
　 
「ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用される、複数のメディアコンポーネント間でマルチメディアコンテンツデータを視覚的にルーチングする装置であって、 
　第１メディアコンポーネントにおいて、ゼロ個又は１個以上の出力ポートを生成するための出力ポートオブジェクトと、該各出力ポートに対応し、前記マルチメディアコンテンツデータを処理するメンバ関数とを有する第１メディアコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　第２メディアコンポーネントにおいて、ゼロ個又は１個以上の入力ポートを生成するための入力ポートオブジェクトと、該各入力ポートに対応し、前記マルチメディアコンテンツデータを処理するメンバ関数とを有する第２メディアコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　前記生成された出力ポートおよび入力ポートを有する複数のメディアコンポーネントを前記ディスプレイ上に表示する手段と、 
　前記表示された複数のメディアコンポーネント内で、前記マルチメディアコンテンツデータがルーチングされるように、前記ディスプレイ上で前記マウスを用いて、前記第１メディアコンポーネントの所定の出力ポートと前記第２メディアコンポーネントの所定の入力ポートとの間の結合又は切り離しを前記メンバ関数を使用して制御する手段とを具えたことを特徴とする装置。」 
　 
３．引用刊行物 
　原査定の拒絶の理由に引用された、本願優先権主張日前に頒布された刊行物である、Ａｎｄｅｒｓｏｎ　Ｄ．Ｐ．ｅｔ　ａｌ．，”ＣＯＭＥＴ：ＡＴＯＯＬＫＩＴ　ＦＯＲ　ＭＵＬＴＩＵＳＥＲ　ＡＵＤＩＯ／ＶＩＤＥＯ　ＡＰＰＬＩＣＡＴＩＯＮＳ”，Ｄｉｓｔｒｉｂｕｔｅｄ　Ｃｏｍｐｕｔｉｎｇ　Ｓｙｓｔｅｍｓ，１９９２．，Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　１２ｔｈ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｃｏｍｐｕｔｉｎｇ　Ｓｙｓｅｍｓ，ＩＥＥＥ，１９９２．６，ＩＳＢＮ：０−８１８６−２８６５−０，ｐ．５５５−５６２（以下、「刊行物１」という。）には、次の事項が記載されている。 
　 
（Ａ）「Ｃｏｍｅｔ　ｉｓ　ａ　ＵＮＩＸ／Ｃ＋＋　ｔｏｏｌｋｉｔ　ｆｏｒ　ｗｒｉｔｉｎｇ　ｐｒｏｇｒａｍｓ，ｌｉｋｅ　ｔｅｌｅｃｏｎｆｅｒｅｎｃｉｎｇ　ｓｙｓｔｅｍｓ　ａｎｄ　ｃｏｌｌａｂｏｒａｔｉｖｅ　ｅｄｉｔｏｒｓ，ｔｈａｔ　ｉｎｖｏｌｖｅ　ｍｕｌｔｉｐｌｅ　ｕｓｅｒｓ　ａｎｄ　ｕｓｅ　ｄｉｇｉｔａｌ　ａｕｄｉｏ　ａｎｄ　ｖｉｄｅｏ．Ｃｏｍｅｔ　ｐｒｏｖｉｄｅｓ　ａ　ｓｉｍｐｌｅ　ｐｒｏｇｒａｍｍｉｎｇ　ｉｎｔｅｒｆａｃｅ：ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ｂｕｉｌｄｓ　ａ　ｇｒａｐｈ　ｏｆ　ｏｂｊｅｃｔｓ　ｒｅｐｒｅｓｅｎｔｉｎｇ　ｓｐｅａｋｅｒｓ　ａｎｄ　ｍｉｃｒｏｐｈｏｎｅｓ，ｍｉｘｅｒｓ，ｆｉｌｅｓ，ａｎｄ　ｓｏ　ｏｎ．Ｃｏｍｅｔ　ｔｈｅｎ　ｒｅａｌｉｚｅｓ　ｔｈｅ　ｇｒａｐｈ　ｂｙ　ｃｒｅａｔｉｎｇ　ａｎｄ　ｉｎｔｅｒｃｏｎｎｅｃｔｉｎｇ　ｐｒｏｃｅｓｓｅｓ　ａｎｄ　ａｕｄｉｏ／ｖｉｄｅｏ　Ｉ／Ｏ　ｓｅｒｖｅｒｓ．Ｉｔ　ｈａｎｄｌｅｓ　ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｄｅｔａｉｌｓ　ｓｕｃｈ　ａｓ　ｐｒｏｃｅｓｓ　ｐｌａｃｅｍｅｎｔ，ｄａｔａ　ｔｙｐｅ　ｃｏｎｖｅｒｓｉｏｎ，ａｎｄ　ｒｅｓｏｕｒｃｅ　ｒｅｓｅｒｖａｔｉｏｎ．」（５５５頁左欄２行〜１２行） 
（訳）「Ｃｏｍｅｔは、電子会議システムや協調編集のような、複数のユーザを含み、デジタルオーディオ、映像を使用するプログラムを記述するためのＵＮＩＸのＣ＋＋ツールキットである。Ｃｏｍｅｔは簡単なプログラミングインターフェースを提供する：アプリケーションはスピーカ、マイク、ミキサ、ファイルなどを表すオブジェクトのグラフを構築する。それから、Ｃｏｍｅｔは、プロセスとオーデオ／ビデオのＩ／Ｏサーバを生成し接続することによりそのグラフを実現する。プロセスの配置、データタイプの変換、リソース確保のような実装の詳細がハンドルされる。」 
　 
（Ｂ）「２．１．Ｍａｓｔｅｒ／Ｓｌａｖｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ 
　Ｃｏｍｅｔ　ａｐｐｌｉｃａｔｉｏｎｓ　ｈａｖｅ　ａ　ｍａｓｔｅｒ／ｓｌａｖｅ　ｓｔｒｕｃｔｕｒｅ．Ｅａｃｈ　ｐａｒｔｉｃｉｐａｎｔ　ｒｕｎｓ　ａ　ｓｅｐａｒａｔｅ　ｉｎｓｔａｎｃｅ　ｏｆ　ｔｈｅ　ｓｌａｖｅ　ｐｒｏｇｒａｍ，ａｎｄ　ｔｈｅｒｅ　ｉｓ　ａ　ｓｉｎｇｌｅ　ｉｎｓｔａｎｃｅ　ｏｆ　ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ．Ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ　ｃａｎ　ｒｕｎ　ａｓ　ａ　ｄａｅｍｏｎ　ａｔ　ａ　ｗｅｌｌ−ｋｎｏｗｎ　ｈｏｓｔ，ｏｒ　ｃａｎ　ｂｅ　ｒｕｎ　ｏｎ　ｄｅｍａｎｄ　ｂｙ　ｔｈｅ　ｓｌａｖｅ　ｐｒｏｇｒａｍ．」（同頁右欄下４行〜５５６頁左欄３行） 
　（訳）「２．１．マスタ／スレーブ・アーキテクチャ 
　Ｃｏｍｅｔアプリケーションはマスタ／スレーブ・ストラクチャーを有している。個々の参加者は、スレーブプログラムの個々に分かれたインスタンスとして実行され、マスタプログラムの単一のインスタンスがある。マスタプログラムは周知のホストにおいてデーモンとして実行されるか、スレーブプログラムによるオンデマンドで実行され得る。」 
　 
（Ｃ）「Ｔｈｅ　ｓｌａｖｅ　ｐｒｏｇｒａｍ　ｐｒｏｖｉｄｅｓ　ｔｈｅ　ｕｓｅｒ　ｉｎｔｅｒｆａｃｅ（ｈａｎｄｌｉｎｇ　ｍｏｕｓｅ／ｋｅｙｂｏａｄ　ｅｖｅｎｔｓ　ａｎｄ　ｇｅｎｅｒａｔｉｎｇ　ｗｉｎｄｏｗ　ｓｙｓｔｅｍ　ｒｅｑｕｅｓｔｓ）ｗｈｉｌｅ　ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ　ｍａｉｎｔａｉｎｓ　ｇｌｏｂａｌ　ｓｔａｔｅ　ａｎｄ　ｉｓｓｕｅｓ　ＣＭ−ｒｅｌａｔｅｄ　ｃｏｍａｎｄｓ　ｔｏ　Ｃｏｍｅｔ．」（５５６頁左欄７行〜１１行） 
（訳）「スレーブプログラムはユーザインターフェース（マウス／キーボードイベントのハンドルとウインドウシステム要求の生成）を提供し、一方、マスタープログラムがグローバル状態を維持しＣｏｍｅｔにＣＭ−関連コマンドを発行する。」 
　 
（Ｄ）「２．２．Ｃｏｎｔｉｎｕｏｕｓ　Ｍｅｄｉａ　Ｏｂｊｅｃｔｓ 
　Ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ　ｍａｎａｇｅｓ　ｔｈｅ　ｃｏｎｔｉｎｕｏｕｓ　ｍｅｄｉａ（ａｕｄｉｏ／ｖｉｄｅｏ）ｃｏｍｐｏｎｅｎｔｓ　ｏｆ　ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ．Ｔｈｅ　Ｃｏｍｅｔ　ｔｏｏｌｋｉｔ　ｏｎ　ｔｈｅ　ｍａｓｔｅｒ　ｓｉｄｅ　ｐｒｏｖｉｄｅｓ　ａ　ｓｅｔ　ｏｆ　Ｃ＋＋　ｃｌａｓｓｅｓ，ｄｅｒｉｖｅｄ　ｆｒｏｍ　ａ　ｂａｓｅ　ｃｌａｓｓ　ＣＭ＿ＮＯＤＥ，ｔｈａｔ　ｒｅｐｒｅｓｅｎｔ　ｔｈｅｓｅ　ｃｏｍｐｏｎｅｎｔｓ．Ｔｈｅ　ｃｕｒｒｅｎｔ　ｓｅｔ　ｏｆ　ＣＭ＿ＮＯＤＥ　ｔｙｐｅｓ　ｉｓ　ａｓ　ｆｏｌｌｏｗｓ： 
・ＭＩＣＲＯＰＨＯＮＥ　ａｎｄ　ＳＰＥＡＫＥＲ　ｒｅｐｒｅｓｅｎｔ　ＣＭ　Ｉ／Ｏ　ｄｅｖｉｃｅｓ．Ｔｈｅｓｅ　ｄｅｖｉｃｅｓ　ａｒｅ“ａｂｓｔｒａｃｔ”ｉｎ　ｔｈｅ　ｓｅｎｓｅ　ｔｈａｔ　ｓｅｖｅｒａｌ　ｏｆ　ｔｈｅｍ（ｐｅｒｈａｐｓ　ｆｒｏｍ　ｄｉｆｆｅｒｅｎｔ　Ｃｏｍｅｔ　ａｐｐｌｉｃａｔｉｏｎｓ）ｍａｙ　ｂｅ　ｍａｐｐｅｄ　ｓｉｍｕｌｔａｎｅｏｕｓｌｙ　ｔｏ　ｔｈｅ　ｓａｍｅ　ｐｈｙｓｉｃａｌ　Ｉ／Ｏ　ｄｅｖｉｃｅ．…（中略）… 
・ＡＵＤＩＯ＿ＭＩＸＥＲ　ｒｅｐｒｅｓｅｎｔｓ　ａ　ｃｏｍｐｏｎｅｎｔ　ｔｈａｔ　ｔａｋｅｓ　ｉｎ　Ｎ　ａｕｄｉｏ　ｓｔｒｅａｍｓ　ａｎｄ　ｇｅｎｅｒａｔｅｓ　ａｓ　ｏｕｔｐｕｔ　ｔｈｅ　ｓｕｍｓ　ｏｆ　ｅａｃｈ　Ｎ−１　ｏｆ　ｔｈｅｓｅ　ｓｔｒｅａｍｓ，ａｓ　ｗｅｌｌ　ａｓ　ｔｈｅ　ｓｕｍ　ｏｆ　ａｌｌ　Ｎ．」（５５６頁左欄２８行〜４６行） 
（訳）「２．２．連続メディアオブジェクト 
　マスタプログラムは、アプリケーションの連続メディア（オーディオ／ビデオ）コンポーネントを管理する。マスタ側のＣｏｍｅｔツールキットは、基底クラスＣＭ＿ＮＯＤＥから導き出される、Ｃ＋＋クラスのセットを提供する。そのクラスは、前記連続メディアコンポーネントを表わす。現時点のＣＭ＿ＮＯＤＥタイプは以下のとおりである。： 
・マイクとスピーカはＣＭ入出力デバイスを表わす。（おそらく異なるＣｏｍｅｔアプリケーションからの）これらのいくつかが、同時に同じ物理入出力デバイスに割り当てられるかもしれないという意味で、これらのデバイスは「抽象的」である。 
…（中略）… 
・オーデオミキサはＮ個のオーディオストリームを取込みそしてＮ個のすべての合成と同様にＮ−１個のそれぞれのストリームの合成を出力として生成するコンポーネントを表す。」 
　 
（Ｅ）「Ａ　ＰＯＲＴ　ｏｂｊｅｃｔ　ｒｅｐｒｅｓｅｎｔｓ　ａ　ｃｏｎｎｅｃｔｉｏｎ　ｐｏｉｎｔ　ｏｆ　ａ　ＣＭ＿ＮＯＤＥ；ｅａｃｈ　ＣＭ＿ＮＯＤＥ　ｈａｓ　ｏｎｅ　ｏｒ　ｍｏｒｅ　ａｓｓｏｃｉａｔｅｄ　ＰＯＲＴｓ．Ｔｈｅ　ｏｐｅｒａｔｉｏｎ 
　ｐ−＞ｌｉｎｋ（ＰＯＲＴ＊ｑ） 
ｃｒｅａｔｅｓ　ａｎ（ａｂｓｔｒａｃｔ）ｃｏｎｎｅｃｔｉｏｎ　ｆｒｏｍ　ｏｕｔｐｕｔ　ｐｏｒｔ　ｐ　ｔｏ　ｉｎｐｕｔ　ｐｏｒｔ　ｑ．」（５５６頁右欄１行〜６行） 
（訳）「ポートオブジェクトは、ＣＭ＿ＮＯＤＥの接続点を表す。それぞれのＣＭ＿ＮＯＤＥは１つあるいはそれ以上の関連したポートを有する。オペレーション、ｐ−＞ｌｉｎｋ（ＰＯＲＴ＊ｑ）は、出力ポートｐから、入力ポートｑへの１つの（抽象）接続を生成する。」 
　 
（Ｆ）「Ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ　ｂｕｉｌｄｓ　ａ　ｄｉｒｅｃｔｅｄ　ｇｒａｐｈ　ｏｆ　ＣＭ＿ＮＯＤＥＳ，ｔｈｅｎ　ｃａｌｌｓ　ｔｈｅ　ｓｅｔｕｐ（）ｏｐｅｒａｔｉｏｎ　ｏｎ　ａｎｙ　ｎｏｄｅ　ｏｆ　ｔｈｅ　ｇｒａｐｈ（ｉｆ　ｔｈｅ　ｇｒａｐｈ　ｃｏｎｓｉｓｔｓ　ｏｆ　ｍｕｌｔｉｐｌｅ　ｄｉｓｊｏｉｎｔ　ｓｕｂｇｒａｐｈｓ，ｓｅｔｕｐ（）ｍｕｓｔ　ｂｅ　ｃａｌｌｅｄ　ｏｎ　ａｔ　ｌｅａｓｔ　ｏｎｅ　ｎｏｄｅ　ｏｆ　ｅａｃｈ　ｓｕｂｇｒａｐｈ）．Ｔｈｉｓ　ｃａｌｌ　ｃａｕｓｅｓ　Ｃｏｍｅｔ　ｔｏ　ｒｅａｌｉｚｅ　ｔｈｅ　ｇｒａｐｈ（ｓｅｅ　Ｓｅｃｔｉｏｎ　３）ａｎｄ　ｓｔａｒｔｓ　ｔｈｅ　ｆｌｏｗ　ｏｆ　ｄａｔａ　ｂｅｔｗｅｅｎ　ｔｈｅ　ｄｅｖｉｃｅｓ，ｐｒｏｃｅｓｓｅｓ，ａｎｄ　ｆｉｌｅｓ　ｒｅｐｒｅｓｅｎｔｅｄ　ｂｙ　ｔｈｅ　ｇｒａｐｈ． 
　Ｆｏｒ　ｅｘａｍｐｌｅ，ａ　ｔｅｌｅｃｏｎｆｅｒｅｎｃｅ　ａｐｐｌｉｃａｔｉｏｎ　ｍｉｇｈｔ　ｃｏｎｓｔｒｕｃｔ　ｔｈｅ　ＣＭ＿ＮＯＤＥ　ｇｒａｐｈ　ｓｈｏｗｎ　ｉｎ　Ｆｉｇｕｒｅ　１．」（５５６頁右欄８行〜１８行） 
（訳）「マスタプログラムは、（複数の）ＣＭ＿ＮＯＤＥ（間）の有向グラフを構築し、そして、そのグラフの何れかのノードでｓｅｔｕｐ（）関数を呼ぶ。（グラフが分離した複数のサブグラフから成る場合、ｓｅｔｕｐ（）関数はそのそれぞれのサブグラフの最低１つのノードで呼びだされなければならない。）この呼び出しはＣｏｍｅｔにグラフ（セクション３を参照）を実体化させ、グラフによって表わされる、デバイス、プロセス、およびファイルの間のデータのフローを開始する。 
　例えば、電子会議アプリケーションは、第１図で示されるＣＭ＿ＮＯＤＥグラフを構築するであろう。」 
　 
（Ｇ）「Ｔｈｅ　ＣＭ＿ＮＯＤＥ　ｇｒａｐｈ　ｍａｙ　ｂｅ　ｍｏｄｉｆｉｅｄ（ｂｙ　ａｄｄｉｎｇ　ｏｒ　ｒｅｍｏｖｉｎｇ　ｎｏｄｅｓ　ｏｒ　ｌｉｎｋｓ）ｄｕｒｉｎｇ　ｐｒｏｇｒａｍ　ｅｘｅｃｕｔｉｏｎ．Ｆｏｒ　ｅｘａｍｐｌｅ，ａｓ　ｎｅｗ　ｐａｒｔｉｃｉｐａｎｔｓ　ｊｏｉｎ　ａ　ｃｏｎｆｅｒｅｎｃｅ，ｎｅｗ　ＭＩＣＲＯＰＨＯＮＥ　ａｎｄ　ＳＰＥＡＫＥＲ　ｏｂｊｅｃｔｓ　ａｒｅ　ｃｒｅａｔｅｄ　ａｎｄ　ｃｏｎｎｅｃｔｅｄ　ｔｏ　ｔｈｅ　ＡＵＤＩＯ＿ＭＩＸＥＲ．Ａｆｔｅｒ　ｅａｃｈ　ａｄｄｉｔｉｏｎ　ｉｓ　ｃｏｍｐｌｅｔｅ，ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ｍｕｓｔ　ｃａｌｌ　ｓｅｔｕｐ（）ｏｎ　ａ　ＣＭ＿ＮＯＤＥ　ｉｎ　ｅａｃｈ　ｍｏｄｉｆｉｅｄ　ｓｕｂｇｒａｐｈ．」（５５６頁右欄１９行〜５５７頁左欄２行） 
（訳）「ＣＭ＿ＮＯＤＥグラフはプログラム実行の間に（ノード又はリンクの追加又は移動により）修正される。例えば、新しい参加者が会議に参加すると、新しいマイクおよびスピーカオブジェクトが生成され、オーデオミキサに接続される。各追加が完成したあとで、アプリケーションは各修正されたサブグラフのＣＭ＿ＮＯＤＥにおいてｓｅｔｕｐ（）関数を呼ばねばならない。」 
　 
（Ｈ）「Ｆｉｇｕｒｅ１：Ｃｏｍｅｔ　ｐｒｏｖｉｄｅｓ　ＣＭ＿ＮＯＤＥ　ｃｌａｓｓｅｓ　ｓｕｃｈ　ａｓ　ＭＩＣＲＯＰＨＯＮＥ，ＡＵＤＩＯ＿ＭＩＸＥＲ，ａｎｄ　ＳＰＥＡＫＥＲ．Ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ　ｃｒｅａｔｅｓ　ａ　ｇｒａｐｈ　ｏｆ　ｔｈｅｓｅ　ｏｂｊｅｃｔｓ　ｔｏ　ｄｅｓｃｒｉｂｅ　ｔｈｅ　ｉｎｔｅｎｄｅｄ　ｆｌｏｗ　ｏｆ　ＣＭ　ｄａｔａ．Ｔｈｉｓ　ｅｘａｍｐｌｅ　ｓｈｏｗｓ　ａ　ｐｏｓｓｉｂｌｅ　ｇｒａｐｈ　ｆｏｒ　ａ　ｔｅｌｅｃｏｎｆｅｒｅｎｃｅ　ａｐｐｌｉｃａｔｉｏｎ．」（５５６頁のＦｉｇｕｒｅ１） 
（訳）「第１図：Ｃｏｍｅｔは、マイク、オーデオミキサ、スピーカといったＣＭ＿ＮＯＤＥクラスを提供する。マスタプログラムは、それらのオブジェクトのグラフを生成し、意図したＣＭデータのフローを表示する。この例はテレビ会議のアプリケーションために可能なグラフを示す。」 
　 
（Ｉ）「３．ＩＭＰＬＥＭＥＮＴＡＴＩＯＮ 
　Ｃｏｍｅｔ　ｍｕｓｔ　ｃｏｎｖｅｒｔ　ａ　ｇｒａｐｈ　ｏｆ　ＣＭ＿ＮＯＤＥｓ（ｗｈｉｃｈ　ａｒｅ　ｓｉｍｐｌｙ　Ｃ＋＋　ｏｂｊｅｃｔｓ　ｉｎ　ｔｈｅ　ｍａｓｔｅｒ　ｐｒｏｇｒａｍ）ｔｏ　ａ　ｓｅｔ　ｏｆ　ｐｒｏｃｅｓｓｅｓ　ａｎｄ　ｎｅｔｗｏｒｋ　ｃｏｎｎｅｃｔｉｏｎｓ　ｔｈａｔ　ｒｅａｌｉｚｅ　ｔｈｅ　ｇｒａｐｈ．Ｔｏ　ｆａｃｉｌｉｔａｔｅ　ａｄｄｉｎｇ　ｎｅｗ　ＣＭ＿ＮＯＤＥ　ｔｙｐｅｓ，ｗｅ　ｕｓｅ　ａ　ｍｏｄｕｌａｒ　ａｐｐｒｏａｃｈ：ｅａｃｈ　ＣＭ＿ＮＯＤＥ　ｍａｎａｇｅｓ　ｉｔｓ　ｏｗｎ　ｉｍｐｌｅｍｅｎｔａｔｉｏｎ．Ｔｏ　ｄｏ　ｔｈｉｓ，ａ　ＣＭ＿ＮＯＤＥ　ｎｅｅｄｓ　ｉｎｆｏｒｍａｔｉｏｎ　ａｂｏｕｔ　ｉｔｓ　ｎｅｉｇｈｂｏｒｓ．Ｆｏｒ　ｔｈｉｓ　ｐｕｒｐｏｓｅ，Ｃｏｍｅｔ　ｄｅｆｉｎｅｓ　ａ　Ｃ＋＋ｉｎｔｅｒｆａｃｅ　ｂｅｔｗｅｅｎ　ＣＭ＿ＮＯＤＥｓ．ｗｈｉｃｈ　ｗｅ　ｃａｌｌ　ｔｈｅ“ＣＭ＿ＮＯＤＥ　Ｐｒｏｔｏｃｏｌ”（ｗｅ　ｕｓｅ　ｔｈｅ　ｔｅｒｍ“ｐｒｏｔｏｃｏｌ”ｎｏｔ　ｉｎ　ｔｈｅ　ｓｅｎｓｅ　ｏｆ　ａ　ｎｅｔｗｏｒｋ　ｐｒｏｔｏｃｏｌ，ｂｕｔ　ｒａｔｈｅｒ　ｂｅｃａｕｓｅ　ｆｕｎｃｔｉｏｎ　ｃａｌｌｓ　ｍｕｓｔ　ｂｅ　ｍａｄｅ　ｉｎ　ｃｅｒｔａｉｎ　ｏｒｄｅｒ）． 
３．１　Ｔｈｅ　ＣＭ＿ＮＯＤＥ　Ｐｒｏｔｏｃｏｌ 
　Ｔｈｅ　ＣＭ＿ＮＯＤＥ　Ｐｒｏｔｏｃｏｌ　ａｄｄｒｅｓｓｅｓ　ｆｏｕｒ　ｉｓｓｕｅｓ：１）ｗｈｅｔｈｅｒ　ｄａｔａ　ｓｔｒｅａｍｓ　ｒｅｑｕｉｒｅ　ｌｏｗ　ｄｅｌａｙ 
…（中略）… 
４）ｃｏｎｎｅｃｔｉｏｎ　ｅｓｔａｂｌｉｓｈｍｅｎｔ．Ｔｈｅ　ｐｒｏｔｏｃｏｌ　ｄｅｆｉｎｅｓ　ａ　ｓｅｔ　ｏｆ　ｆｕｎｃｔｉｏｎｓ　ｔｈａｔ　ｅａｃｈ　　ＣＭ＿ＮＯＤＥ　ｍｕｓｔ　ｐｒｏｖｉｄｅ： 
　ＢＯＯＬＥＡＮ　ｆｒｏｍ＿ｒｔ＿ｓｏｕｒｃｅ（ＰＯＲＴ＊）； 
　ＢＯＯＬＥＡＮ　ｔｏ＿ｒｔ＿ｓｉｎｋ（ＰＯＲＴ＊）； 
　ＴＹＰＥ＿ＳＥＴ　ｆｅａｓｉｂｌｅ＿ｔｙｐｅｓ（ＰＯＲＴ＊ｐ）； 
　…（中略）… 
　ｖｏｉｄ　ｂｉｎｄ（）； 
　ｖｏｉｄ　ｃｏｎｎｅｃｔ（）； 
　ｖｏｉｄ　ａｃｃｅｐｔ（）；」（５５７頁左欄３行〜下１５行） 
（訳）「３．実装 
　Ｃｏｍｅｔは、ＣＭ＿ＮＯＤＥｓのグラフ（これはマスタプログラムの中では単にＣ＋＋オブジェクトである）を、プロセスとネットワーク接続の集合に変換しグラフを実体化する。新たなＣＭ＿ＮＯＤＥタイプの追加を容易にするためモジュラアプローチを用いる。：各ＣＭ＿ＮＯＤＥが自身の実装を管理する。これをするため、あるＣＭ＿ＮＯＤＥは自身の隣のＣＭ＿ＮＯＤＥについての情報を必要とする。この目的のため、ＣｏｍｅｔはＣＭ＿ＮＯＤＥ間のＣ＋＋インタフェースを定義する。これを「ＣＭ＿ＮＯＤＥプロトコル」と呼ぶ。（この用語「プロトコル」は、ネットワークプロトコルの意味においてではなく、関数呼び出しがある順序においてなされなければならないという理由で用いる。） 
３．１　ＣＭ＿ＮＯＤＥプロトコル 
　ＣＭ＿ＮＯＤＥプロトコルは４つの問題を扱う。１）データストリームが低遅延を要求するかどうか。…（中略）…４）接続確立。このプロトコルは各ＣＭ＿ＮＯＤＥが提供しなければならない関数のセットを定義する。 
　ＢＯＯＬＥＡＮ　ｆｒｏｍ＿ｒｔ＿ｓｏｕｒｃｅ（ＰＯＲＴ＊）； 
　ＢＯＯＬＥＡＮ　ｔｏ＿ｒｔ＿ｓｉｎｋ（ＰＯＲＴ＊）； 
　ＴＹＰＥ＿ＳＥＴ　ｆｅａｓｉｂｌｅ＿ｔｙｐｅｓ（ＰＯＲＴ＊ｐ）； 
　…（中略）… 
　ｖｏｉｄ　ｂｉｎｄ（）； 
　ｖｏｉｄ　ｃｏｎｎｅｃｔ（）； 
　ｖｏｉｄ　ａｃｃｅｐｔ（）；」 
　 
（Ｊ）「３．１．４．Ｃｏｎｎｅｃｔｉｏｎ　Ｅｓｔａｂｌｉｓｈｍｅｎｔ 　Ｃｏｍｅｔ　ｕｓｅｓ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎｓ　ｔｏ　ｃｏｎｖｅｙ　ＣＭ　ｄａｔａ．Ｅａｃｈ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎ　ｉｓ　ｕｓｅｄ　ａｓ　ａ　ｓｉｍｐｌｅｘ　ｃｈａｎｎｅｌ．Ｂｙ　ｃｏｎｖｅｎｔｉｏｎ，ｔｈｅ　ｓｅｎｄｉｎｇ　ｅｎｄ　ｐｌａｙｓ　ｔｈｅ　ａｃｔｉｖｅ　ｒｏｌｅ　ｉｎ　ｃｏｎｎｅｃｔｉｏｎ　ｅｓｔａｂｌｉｓｈｍｅｎｔ（ｉｎ　ＢＳＤ　ＵＮＩＸ　ｔｅｒｍｉｎｏｌｏｇｙ，ｔｈｅ　ｓｅｎｄｅｒ　ｄｏｅｓ　ｔｈｅ　ｃｏｎｎｅｃｔ（）ａｎｄ　ｔｈｅ　ｒｅｃｅｉｖｅｒ　ｄｏｅｓ　ｔｈｅ　ｌｉｓｔｅｎ（）ａｎｄ　ａｃｃｅｐｔ（））．Ｅａｃｈ　ＰＯＲＴ　ｏｂｊｅｃｔ　ｉｎｃｌｕｄｅｓ　ａ　ｎｅｔｗｏｒｋ　ａｄｄｒｅｓｓ（ｈｏｓｔ　ｉｎｔｅｒｎｅｔ　ａｄｄｒｅｓｓ　ａｎｄ　ｐｏｒｔ　ｎｕｍｂｅｒ）ｆｏｒ　ｔｈｅ　ｃｏｒｒｅｓｐｏｎｄｉｎｇ　ＴＣＰ　ｓｏｃｋｅｔ． 
　Ｔｈｅ　ＣＭ＿ＮＯＤＥ　ｐｒｏｔｏｃｏｌ　ｄｏｅｓ　ｃｏｎｎｅｃｔｉｏｎ　ｅｓｔａｂｌｉｓｈｍｅｎｔ　ｉｎ　ｔｈｒｅｅ　ｓｔａｇｅｓ．　ｂｉｎｄ（）ｃｒｅａｔｅｓ　ｌｉｓｔｅｎｉｎｇ　ｓｏｋｅｔｓ　ｆｏｒ　ａｌｌ　ｉｎｐｕｔ　ＰＯＲＴｓ，ａｎｄ　ｆｉｌｌｓ　ｉｎ　ｔｈｅｉｒ　ａｄｄｒｅｓｓｅｓ．　ｃｏｎｎｅｃｔ（）ｓｅｔｓ　ｕｐ　ｏｕｔｇｏｉｎｇ　ｃｏｎｎｅｃｔｉｏｎｓ　ｆｏｒ　ｔｈｅ　ｏｂｊｅｃｔｓ’ｓ　ｏｕｔｐｕｔ　ｐｏｒｔｓ　ａｎｄ　ｆｉｌｌｓ　ｉｎ　ｔｈｅｉｒ　ａｄｄｒｅｓｓｅｓ．　ａｃｃｅｐｔ（）　ａｃｃｅｐｔｓ　ｉｎｃｏｍｉｎｇ　ｃｏｎｎｅｃｔｉｏｎｓ，ｆｉｎｉｓｈｅｓ　ｓｅｔｕｐ　ｉｎ　ａ　ｃｌａｓｓ−ｓｐｅｃｉｆｉｃ　ｗａｙ．Ｅａｃｈ　ｆｕｎｃｔｉｏｎ　ｔｈｅｎ　ｐｅｒｆｏｒｍｓ　ｔｈｅ　ｓａｍｅ　ｏｐｅｒａｔｉｏｎ　ｏｎ　ａｌｌ　ｎｅｉｇｈｂｏｒｉｎｇ　ｏｂｊｅｃｔｓ・Ｔｈｅ　ｓｅｔｕｐ（）ｆｕｎｃｔｉｏｎ（ｃａｌｌｅｄ　ｂｙ　ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ｔｏ　“ａｃｔｉｖａｔｅ”ａ　ＣＭ＿ＮＯＤＥ　ｇｒａｐｈ）ｓｉｍｐｌｙ　ｃａｌｌｓ　ｂｉｎｄ（），ｃｏｎｎｅｃｔ（）　ａｎｄ　ａｃｃｅｐｔ（）ｏｎ　ｔｈｅ　ｔａｒｇｅｔ　ＣＭ＿ＮＯＤＥ．」（５５９頁左欄７行〜２８行） 
（訳）「３．１．４．接続確立 
　ＣｏｍｅｔはＣＭデータを運ぶためにＴＣＰ接続を用いる。各ＴＣＰ接続は一方向チャンネルとして用いられる。通常、送り手側は接続確立において能動的な役割を演ずる。（ＢＳＤ　ＵＮＩＸ技術においては、送り手はｃｏｎｎｅｃｔ（）を行い、受け手はｌｉｓｔｅｎ（）とａｃｃｅｐｔ（）を行う。）各ポートオブジェクトは対応するＴＣＰソケットのためのネットワークアドレス（ホストのインターネットアドレスとポート番号）を含める。 
　ＣＭ＿ＮＯＤＥプロトコルは３段階で接続確立を行う。ｂｉｎｄ（）は全ての入力ポートのためのリスニングソケットを生成し、それらのアドレスで満たす。ｃｏｎｎｅｃｔ（）はオブジェクトの出力ポートのために出て行く接続を設定しそれらのアドレスで満たす。ａｃｃｅｐｔ（）は入ってくる接続を受け、クラス特有の方法で設定を終える。各関数はそれから全ての隣接するオブジェクトにおいて同様のオペレーションを行う。ｓｅｔｕｐ（）関数（ＣＭ＿ＮＯＤＥグラフを「活性化」するためにアプリケーションにより呼ばれる）は単にｂｉｎｄ（）、ｃｏｎｎｅｃｔ（）、ａｃｃｅｐｔ（）を目標ＣＭ＿ＮＯＤＥ上で呼び出す。」 
　 
（Ｋ）「Ｔｈｅ　ｍｉｘｅｒ　ｐｒｏｇｒａｍ　ｔａｋｅｓ　ａｎ　ａｒｂｉｔｒａｒｙ　ｎｕｍｂｅｒ　Ｎ　ｏｆ　ｄｉｇｉｔａｌ　ａｕｄｉｏ　ｉｎｐｕｔ　ｓｔｒｅａｍｓ，ａｎｄ　ｐｒｏｄｕｃｅｓ　ｏｕｔｐｕｔ　ｓｔｒｅａｍｓ　ｆｏｒ　ｔｈｅ　ｔｏｔａｌ　ｓｕｍ　ａｎｄ　ｆｏｒ　ｅａｃｈ　Ｎ−１　ｓｕｍ．Ｉｔ　ｐｅｒｆｏｒｍｓ　ｃｏｎｖｅｒｓｉｏｎｓ　ｂｅｔｗｅｅｎ　ｄｉｆｆｅｒｅｎｔ　ｄａｔａ　ｔｙｐｅｓ，ａｎｄ　ｉｔ　ｄｉｓｔｉｎｇｕｉｓｈｅｓ　ｂｅｔｗｅｅｎ　ｌｏｗ−ａｎｄ　ｈｉｇｈ−ｄｅｌａｙ　ｓｔｒｅａｍｓ，ｄｅａｌｉｎｇ　ｗｉｔｈ　ｅａｃｈ　ｔｙｐｅ　ａｐｐｒｏｐｒｉａｔｅｌｙ」（５５９頁右欄下３行〜５６０頁左欄４行） 
（訳）「ミキサプログラムはデジタルオーデオ入力ストリームのＮの任意の数を取り込み、そして全部の合成と各Ｎ−１の合成の出力ストリームを生成する。異なるデータタイプの間の変換が達成され、それぞれのタイプを適切に操作して、低−高遅延のストリームが区別される。」 
　 
（Ｌ）「Ｃｏｍｅｔ　ｗａｓ　ｉｎｓｐｉｒｅｄ　ｂｙ　ＧＵＩ　ｔｏｏｌｋｉｔｓ　ｓｕｃｈ　ａｓ　ＩｎｔｅｒＶｉｅｗｓ［６］．Ｔｈｅｓｅ　ｔｏｏｌｋｉｔｓ　ｐｒｏｖｉｄｅ　ａｂｓｔｒａｃｔｉｏｎｓ（ｍｅｎｕｓ，ｅｄｉｔｏｒｓ，ｅｔｃ．）ｆｏｒ　ｄｉｓｐｌａｙｉｎｇ　ａｎｄ　ｉｎｔｅｒａｃｔｉｎｇ　ｗｉｔｈ　ｄｉｓｃｒｅｔｅ　ｄａｔａ　ｓｕｃｈ　ａｓ　ｇｒａｐｈｉｃｓ　ａｎｄ　ｔｅｘｔ．Ｃｏｍｅｔ　ｉｓ　ｃｏｎｃｅｒｎｅｄ　ｐｕｒｅｌｙ　ｗｉｔｈ　ｃｏｎｔｉｎｕｏｕｓ　ｍｅｄｉａ． 
　Ａ　ｃｅｎｔｒａｌｉｚｅｄ　ＣＭ　ｔｏｏｌｋｉｔ　ｐｒｏｖｉｄｅｓ　ａｃｃｅｓｓ　ｔｏ　ＣＭ　I/O　ａｔ　ａ　ｓｉｎｇｌｅ　ｗｏｒｋｓｔａｔｉｏｎ．Ｓｕｃｈ　ａ　ｔｏｏｌｋｉｔ，ｉｎ　ｃｏｍｂｉｎａｔｉｏｎ　ｗｉｔｈ　ａｎ　ｅｘｉｓｔｉｎｇ　ｗｉｎｄｏｗ−ｓｙｓｔｅｍ　ｔｏｏｌｋｉｔ，ｍａｋｅｓ　ｉｔ　ｅａｓｙ　ｔｏ　ｄｅｆｉｎｅ　ｏｂｊｅｃｔｓ　ｆｏｒ　ａｃｑｕｉｒｉｎｇ　ａｎｄ　ｐｌａｙｉｎｇ　ｓｏｕｎｄ；ｔｈｅｓｅ　ｏｂｊｅｃｔｓ　ｃａｎ　ｔｈｅｎ　ｂｅ　ａｄｄｅｄ　ｔｏ　ｍａｉｌ　ｏｒ　ｄｏｃｕｍｅｎｔ　ｓｙｓｔｅｍｓ．」（５６０頁左欄下１２行〜下２行） 
（訳）「ＣｏｍｅｔはＩｎｔｅｒＶｉｅｗｓのようなＧＵＩツールキットによって着想を得ている。これらのツールキットは図形やテキストのような別々のデータと会話したり表示するための抽象概念（メニューや編集など）を提供する。Ｃｏｍｅｔは純粋に連続メディアと関係する。 
　中央に位置するＣＭツールキットは１つのワークステーションでＣＭ　I/Oへのアクセスを提供する。ウインドウシステムツールキットと結合したツールキットは、音を獲得しそして再生するためのオブジェクトを定義するのを容易にする。これらのオブジェクトはそれからメイルや文書システムに付け加えることができる。」 
　 
［刊行物１の発明］ 
　刊行物１には次の発明が開示されている。 
（ａ）第１図に示されたマイク、ミキサ、スピーカは（Ｄ）の記載によれば、それぞれ連続メディア（ＣＭ）コンポーネントである。（Ａ）の記載によれば、Ｃ＋＋ツールキットであるＣｏｍｅｔは、電子会議システムなどのアプリケーションを記述する簡単なプログラミングインターフェースを提供する旨あり、（Ｃ）（Ｌ）の記載によれば、ユーザインターフェースとして、マウス／キーボード、ウィンドウシステム、ＧＵＩツールキットが用いられる。（Ｅ）の記載によれば、ポートの接続がされ、（Ｆ）（Ｈ）の記載によれば、マスタプログラムは、ＣＭ−ＮＯＤＥ間の有向グラフを構築し、Ｃｏｍｅｔにグラフを実体化させ、グラフによって表されるデバイス、プロセス、及びファイル間のＣＭデータのフローを表示する旨あり、前記実体化は、（Ｉ）（Ｊ）の記載によれば、グラフはプロセスとネットワーク接続の集合に変換され、ＣＭデータを転送するための接続確立がされる。 
　前記ポートの接続がされ、接続確立がされることは、ＣＭデータの経路決定をすることであり、ＧＵＩを用いること、グラフを構築しグラフによって表されるデバイス、プロセス、及びファイル間のＣＭデータのフローを表示すること、（Ｇ）に記載された、グラフが修正され新しいマイク及びスピーカオブジェクトがオーディオミキサに接続されることをふまえると、前記ポートの接続、グラフの構築、接続確立は、デスプレイやマウスを有するＧＵＩを用いて、複数のＣＭコンポーネント間でＣＭデータをグラフ表示により視覚的に経路決定（ルーチング）するものが読み取れる。 
　また、前記ツールキットであるＣｏｍｅｔやＧＵＩなどのプログラムが、ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用されることは、プログラミングインターフェース、ＧＵＩ（ＧＵＩについては刊行物２参照）、ウィンドウシステム、マウスなどの記載から読み取れる。 
（ｂ）マイク、ミキサ、スピーカなどのＣＭコンポーネントは、（Ｄ）の記載によれば基底クラスのＣＭ＿ＮＯＤＥから導出されたクラスであり、（Ｈ）の記載によれば、ＣＭ＿ＮＯＤＥクラスのオブジェクトのグラフが生成され意図したＣＭデータのフローが表示される。オブジェクト指向技術におけるオブジェクトは、データとそれを操作する手続き（メソッド）から成るので（刊行物２の（ア）参照）、前記マイク、ミキサ、スピーカなどのＣＭコンポーネントのオブジェクトは、データとそれを操作する手続き（メソッド）から成る。 
　また、（Ｅ）の記載によれば、ポートオブジェクトは、ＣＭ＿ＮＯＤＥの接続点を表わし、各ＣＭ＿ＮＯＤＥは、１つあるいはそれ以上の関連したポートを有し、ｌｉｎｋ（）により出力ポートｐから、入力ポートｑへの１つの（抽象）接続を生成することから、ＣＭ＿ＮＯＤＥ基底クラスから導出されたマイク、ミキサ、スピーカなどのＣＭコンポーネントにおいても、ポートオブジェクトの機能を実質的に有することが読み取れる。また、ｌｉｎｋ（）は、ポートオブジェクトのメンバ関数であることが読み取れる。 
（ｃ）ミキサを第１のＣＭコンポーネント、スピーカを第２のＣＭコンポーネントとすると、（Ｅ）（Ｊ）のポートオブジェクトに係る記載から、第１のＣＭコンポーネントと第２のＣＭコンポーネントを接続するために、各ＣＭコンポーネントにおいて、出力ポート及び入力ポートが生成されるものと解される。 
（ｄ）（Ｇ）（Ｈ）（Ｌ）の記載によれば、ＣＭコンポーネントを表すＣＭ＿ＮＯＤＥのグラフが生成され、意図したグラフのＣＭデータのフローがディスプレイ上に表示される（ウインドウは通常ディスプレイ上に表示される）のが読み取れるから、前記（ｃ）における、生成された出力ポートおよび入力ポートを有する第１、第２の（複数の）ＣＭコンポーネントをディスプレイ上に表示する手段があるものと解される。 
（ｅ）（Ｆ）（Ｇ）の記載によれば、ＣＭ＿ＮＯＤＥグラフはノード又はリンクの追加又は移動により修正される。この追加又は移動による修正は、前記（ａ）のユーザインターフェースに係る、マウス、ウィンドウの記載から、マウス、ディスプレイを用いるものが読み取れ、このグラフの修正に応じて、前記ポートオブジェクトに係る、メンバー関数ｌｉｎｋ（）により出力ポートｐから、入力ポートｑへの１つの（抽象）接続が生成されると解される。 
　グラフのＣＭ＿ＮＯＤＥにおいてｓｅｔｕｐ（）関数が呼ばれると、グラフが実体化され、データのフローが開始する。（Ｉ）（Ｊ）の記載によれば、前記ｓｅｔｕｐ（）関数により、ＣＭ＿ＮＯＤＥが提供しなければならないＣＭ＿ＮＯＤＥプロトコルにおける関数（例えば、ｂｉｎｄ（）、ｃｏｎｎｅｃｔ（）、ａｃｃｅｐｔ（））がＣＭ＿ＮＯＤＥ上で呼び出され接続確立が行われる。 
　（ａ）〜（ｅ）をふまえると、刊行物１には、電子会議システムや協調編集のような、複数のユーザを含み、デジタルオーディオ、映像を使用するプログラムを記述するための簡単なプログラミングインターフェースを提供することを目的とした次の発明（以下「刊行物１の発明」という。）が開示されている。 
　 
　ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用される、複数の連続メディア（ＣＭ）コンポーネント間でＣＭデータを視覚的にルーチングする装置であって、 
　第１ＣＭコンポーネントにおいて、１個以上の出力ポートを生成するためのポートオブジェクトを有する、第１ＣＭコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　第２ＣＭコンポーネントにおいて、１個以上の入力ポートを生成するためのポートオブジェクトを有する、第２ＣＭコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　前記生成された出力ポートおよび入力ポートを有する複数のＣＭコンポーネントを前記ディスプレイ上に表示する手段と、 
　前記表示された複数のＣＭコンポーネント内で、前記ＣＭデータがルーチングされるように、前記ディスプレイ上で前記マウスを用いて、前記第１ＣＭコンポーネントの所定の出力ポートと前記第２ＣＭコンポーネントの所定の入力ポートとの間の結合をメンバ関数を使用して制御する手段とを具えたことを特徴とする装置。 
　 
　原査定の拒絶の理由に引用された、本願優先権主張日前に頒布された刊行物である、阿部倫之外，”交換サービスモデリングシステムの一検討”，電子情報通信学会技術研究報告，第９０巻，第３８９号，１９９１．１．１８，ｐ．１〜６（以下、「刊行物２」という。）には、次の事項が記載されている。 
(ア)「３．　オブジェクト指向の導入 
３．１　オブジェクト 
　オブジェクトの基本構造を図２に示す．オブジェクトは、スロットに格納されたデータとそれを操作する手続きから成る．この手続きをメソッドと呼ぶ．我々が考える交換サービス仕様においては，図１に示した各アイコンをオブジェクトとして扱う．これらのアイコンは，図３に示す様に互いにメッセージをやりとりしながら処理が進められるため，本質的にオブジェク指向的な振る舞いをしている．従って，オブジェクト指向を用いると，サービス仕様が直接的に表現できるとともに，その仕様を実際に動作させることが可能である。この動作きは，交換機の動作そのものであることから，この仕様自身が実際の交換ソフトウエアになる可能性を持っている。 
　各アイコンは， 
　（１）視覚表現のための手続きとデータ 
　（２）交換処理のための手続きとデータの２つのオブジェクトから成る．これらを１つのオブジェクトとしてまとめると，本質的な交換処理の中に視覚表現用の処理が埋め込まれるため，処理の追加，変更がしにくくなるとともにプログラムの可読性が悪くなる．そこで，（１）を表示オブジェクト，（２）を処理オブジェクトと呼び，別々のオブジェクトとして構成し，後でリンケージする方法を用いる．このイメージを図４に示す．例えば，処理オブジェクトにおいて’受話器を上げる’や’ランプを点灯する’などの処理をする時，対応する表示オブジェクトにメッセージを送って表示に反映させたり，その逆で，動作指示などのマウスセンス情報を表示するオブジェクトが受け取り，それを対応する処理オブジェクトに反映させ，処理を継続させていくことができる． 
３．２　記述対象とクラス 
　ここでまず，交換サービスの記述対象を以下の５つに大別する． 
…（中略）… 
この５つの記述対象をオブジェクトとして扱う．オブジェクト指向におけるオブジェクトの定義はクラス定義と呼ばれる手段でなされる．このクラス定義においてスロットやメソッドを定義する．」（２頁右欄１２行〜３頁右欄１２行） 
（イ）「３．３　インスタンス 
　クラス定義によって定義されたオブジェクトは，クラス定義から生成された’オブジェクト’となることで実行の対象となりえる．このオブジェクトをインスタンスと呼ぶ．」（４頁左欄１行〜５行） 
（ウ）「４．　プロトタイプ試作 
４．１　試作範囲 
　交換サービスをモデル化し，交換サービスの振舞いを実際の動作イメージに近い形式で図式表示する交換サービスモデリングシステムのプロトタイプを試作した．試作には，Ｌｉｓｐ系オブジェクト指向言語ＣＬＯＳ（Ｃｏｍｍｏｎ　Ｌｉｓｐ　Ｏｂｊｅｃｔ　Ｓｙｓｔｅｍ）（５）（６）を用いてＷＳ２０５０／３２Ｅ上にインプリメントした．」（４頁左欄１３行〜２０行） 
（エ）「４．２　処理クラス 
　プロトタイプシステムでは，図５に示したクラス階層を処理クラスの階層とした． 
…（中略）… 
　処理クラスのメソッドの内，複合ＰＢＸのメソッドには，ＣＬＯＳで記述した交換処理のシナリオが組み込まれている．このメソッドを使用して，多機能電話機からのメッセージに対して応答メッセージを送出したり，メッセージの履歴を保存したりする．このシナリオの一部を図６に示す．クラス定義に続いて交換機のメソッドが定義されており，’オフフック’信号を受け取ると’ダイヤル音’を送出したり，’ダイヤル’を受け取ると数字分析メソッドを起動したりするシナリオがＣＬＯＳで記述されている．」（４頁左欄下１７行〜右欄１０行） 
（オ）「４．３　表示クラス 
　表示クラスを構成する場合，まず記述対象の図形を設計してから，その図形をウインドウ表示できるような情報をもつクラスを定義する．図７に記述対象の図形を示す．記述対象の図形を，線（ｌｉｎｅ），折れ線（ｐｏｌｙｌｉｎｅ），長方形（ｂｏｘ）などの基本図形の組合せで表現する．図形を変化させたり表示したりするメソッドは表示オブジェクトのメソッドとして定義する．」（５頁左欄１行〜８行） 
（カ）「４．４　メッセージの流れ 
　表示オブジェクトと処理オブジェクト間のメッセージの流れを図８に示す．主なメッセージの流れは，処理オブジェクト相互間および表示オブジェクトと処理オブジェクト間である．表示オブジェクト相互間でメッセージがやりとりされるのは，表示図形の移動や削除などの図形処理の場合である．例えば，ノードの移動時にアークも追従させたりするような場合がある．」（５頁左欄９行〜右欄２行） 
（キ）「４．５　動作イメージ 
　プロトタイプシステムによる３者通話サービスのモデリング例を図９に示す．交換サービスを構成するための部品ウインドウと，部品を転記して交換サービスモデルを組み立てるモデルウインドウがある．部品ウインドウ中のオブジェクトはクラスであり，モデルウインドウ中のオブジェクトはインスタンスである．部品ウインドウからモデルウインドウへの転記は，クラスからインスタンスを生成することに相当する．転記する際に端末番号や識別名などをスロットに設定する． 
　操作は複数の一般利用者から要求されるため，非同期に処理するためにはスケジューラを用意する必要がある．このスケジューラを，プロトタイプシステムでは時計に組み込んでいる．動作イメージを図１０の動作例を用いて説明する．図において，一般利用者からポップアップメニューの’受話器を上げる’を選択すると，この処理は時計オブジェクトのスケジューラに登録され，時計オブジェクトから端末ユーザインタフェースを介して多機能電話機に処理結果のメッセージが伝えられる（この場合，’受話器を上げる’メッセージの送信）．これに続いて多機能電話機から’オフフック’メッセージが内線オブジェクトを介して交換機に伝えられるが，この処理もまず時計のスケジューラに登録されて，スケジューラから処理結果が交換機に伝えられる．交換機にメッセージが流れるとそれに対する応答がプロトタイピングしたシナリオに従って送出されるが，この処理も時計のスケジューラから起動される．」（５頁右欄３行〜６行左欄２１行） 
（ク）図７を参照すると、交換サービス仕様記述対象の図形が描かれ、そのうち、「多機能電話機」及び「交換機」を示す図形の左右には、「・」様のものが記載されている。 
（ケ）図８を参照すると、「デイジタル多機能電話機」、「内線」、「複合ＰＢＸ」などの「処理オブジェクト」間において、「メッセージ」を示す矢印が相互に接続されており、これらの処理オブジェクト間において、メッセージがやりとりされることが記載されている。 
（コ）図９を参照すると、モデルウインドウ（図面上部のウィンドウ）において、多機能電話機（ＭＦＴ　１）を示す図形と交換機（ＣＸ　１）を示す図形とが、内線（ＩＬＩＮＥ　１）を示す線で結合されており、その線の下には「ｍｅｓｓａｇｅ」と記載されている。 
　 
４．対比 
　本願請求項１の発明と刊行物１の発明とを対比する。 
（４．１）刊行物１の発明の「ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用される、複数の連続メディア（ＣＭ）コンポーネント間でＣＭデータを視覚的にルーチングする装置」において、当該ＣＭデータは、オーディオ／ビデオデータ（（Ｄ）の記載と、第１図参照）であるから本願請求項１の発明の「マルチメディアコンテンツデータ」と実質的な差異はない。よって、刊行物１の発明の前記事項は、本願請求項１の発明の「ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用される、複数のメディアコンポーネント間でマルチメディアコンテンツデータを視覚的にルーチングする装置」と実質的な差異はない。
（４．２）本願請求項１の発明における第１メディアコンポーネントに関し、「ゼロ個又は１個以上の出力ポート」は「ゼロ個の出力ポート」又は「１個以上の出力ポート」のいずれかが特定事項であるので、刊行物１の発明の「１個以上の出力ポート」と実質的な差異はなく、また、本願請求項１の発明の「出力ポートオブジェクト」「マルチメディアコンテンツデータを処理するメンバ関数とを有する第１メディアコンポーネントオブジェクト」は、それぞれ上位概念では「ポートオブジェクト」「第１メディアコンポーネントオブジェクト」である。 
　したがって、刊行物１の発明の「第１ＣＭコンポーネントにおいて、１個以上の出力ポートを生成するためのポートオブジェクトを有する、第１ＣＭコンポーネントオブジェクトを前記メモリ内に作成する手段」と、本願請求項１の発明の「第１メディアコンポーネントにおいて、ゼロ個又は１個以上の出力ポートを生成するための出力ポートオブジェクトと、該各出力ポートに対応し、マルチメディアコンテンツデータを処理するメンバ関数とを有する第１メディアコンポーネントオブジェクトを前記メモリ内に作成する手段」とは、いずれも「第１メディアコンポーネントにおいて、ゼロ個又は１個以上の出力ポートを生成するためのポートオブジェクトを有する、第１メディアコンポーネントオブジェクトを前記メモリ内に作成する手段」である点では一致する。 
（４．３）同様に、本願請求項１の発明における第２メディアコンポーネントに関し、「入力ポートオブジェクト」「マルチメディアコンテンツデータを処理するメンバ関数とを有する第２メディアコンポーネントオブジェクト」は、それぞれ上位概念では「ポートオブジェクト」「第２メディアコンポーネントオブジェクト」であるから、刊行物１の発明の「第２ＣＭコンポーネントにおいて、１個以上の入力ポートを生成するためのポートオブジェクトを有する、第２ＣＭコンポーネントオブジェクトを前記メモリ内に作成する手段」と、本願請求項１の発明の「第２メディアコンポーネントにおいて、ゼロ個又は１個以上の入力ポートを生成するためのポートオブジェクトと、該各入力ポートに対応し、マルチメディアコンテンツデータを処理するメンバ関数とを有する第２メディアコンポーネントオブジェクトを前記メモリ内に作成する手段」とは、いずれも「第２メディアコンポーネントにおいて、ゼロ個又は１個以上の出力ポートを生成するためのポートオブジェクトを有する、第２メディアコンポーネントオブジェクトを前記メモリ内に作成する手段」である点では一致する。 
（４．４）刊行物１の発明と本願請求項１の発明とは、「前記生成された出力ポートおよび入力ポートを有する複数のメディアコンポーネント（ＣＭコンポーネント）を前記ディスプレイ上に表示する手段」を有する点では差異はない。 
（４．５）刊行物１の発明のポートオブジェクトに係る「メンバ関数を使用して制御する手段」と本願請求項１の発明の「前記メンバ関数を使用して制御する手段」とは、いずれも、メンバ関数を使用して制御する手段であるので実質的な差異はない。また、刊行物１の発明の「結合」と本願請求項１の発明の「結合又は切り離し」とは、「結合」「切り離し」のいずれかが特定事項であるので実質的な差異はない。 
　したがって、刊行物１の発明の「前記表示された複数のＣＭコンポーネント内で、前記ＣＭデータがルーチングされるように、前記ディスプレイ上で前記マウスを用いて、前記第１ＣＭコンポーネントの所定の出力ポートと前記第２ＣＭコンポーネントの所定の入力ポートとの間の結合をメンバ関数を使用して制御する手段」と、本願請求項１の発明の「前記表示された複数のメディアコンポーネント内で、前記マルチメディアコンテンツデータがルーチングされるように、前記ディスプレイ上で前記マウスを用いて、前記第１メディアコンポーネントの所定の出力ポートと前記第２メディアコンポーネントの所定の入力ポートとの間の結合又は切り離しを前記メンバ関数を使用して制御する手段」とは、実質的な差異はない。 
　 
　これらの点をふまえると、刊行物１の発明と、本願請求項１の発明とは次の事項により特定される発明である点では一致し、そして、次の点で相違が認められる。 
　 
〈一致点〉ＣＰＵ、メモリ、ディスプレイ、マウスを有するコンピュータシステム内で使用される、複数のメディアコンポーネント間でマルチメディアコンテンツデータを視覚的にルーチングする装置であって、 
　第１メディアコンポーネントにおいて、ゼロ個又は１個以上の出力ポートを生成するためのポートオブジェクトを有する、前記第１メディアコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　第２メディアコンポーネントにおいて、ゼロ個又は１個以上の入力ポートを生成するためのポートオブジェクトを有する、前記第２メディアコンポーネントオブジェクトを前記メモリ内に作成する手段と、 
　前記生成された出力ポートおよび入力ポートを有する複数のメディアコンポーネントを前記ディスプレイ上に表示する手段と、 
　前記表示された複数のメディアコンポーネント内で、前記マルチメディアコンテンツデータがルーチングされるように、前記ディスプレイ上で前記マウスを用いて、前記第１メディアコンポーネントの所定の出力ポートと前記第２メディアコンポーネントの所定の入力ポートとの間の結合又は切り離しをメンバ関数を使用して制御する手段と 
を具えたことを特徴とする装置。 
　 
〈相違点１〉第１メディアコンポーネントにおいて、ポートオブジェクトが、本願請求項１の発明は、出力ポートオブジェクトであるのに対し、刊行物１の発明は、ポートオブジェクトである点。 
〈相違点２〉第２メディアコンポーネントにおいて、ポートオブジェクトが、本願請求項１の発明は、入力ポートオブジェクトであるのに対し、刊行物１の発明は、ポートオブジェクトである点。 
〈相違点３〉第１メディアコンポーネント、及び、第２メディアコンポーネントが、本願請求項１の発明は、それぞれ各出力ポート、及び、各入力ポートに対応し、マルチメディアコンテンツデータを処理するメンバ関数を有するメディアコンポーネントであるのに対し、刊行物１の発明の第１ＣＭコンポーネントオブジェクトと、第２のＣＭコンポーネントオブジェクトが、そのような関数を有することについては不明である点。 
　 
５．当審判断 
〈相違点１〉〈相違点２〉について 
　刊行物１の（Ｅ）（Ｊ）の記載によれば、ポートオブジェクトは、２つのＣＭ＿ＮＯＤＥの接続において出力ポートｐから入力ポートｑへの接続のオペレーションをするが、出力ポートｐのＣＭ＿ＮＯＤＥに係るポートオブジェクトを出力ポートオブジェクト、入力ポートｑのＣＭ＿ＮＯＤＥに係るポートオブジェクトを入力ポートオブジェクトと呼ぶことは技術的に格別なものではなく、第１メディアコンポーネントと第２メディアコンポーネントの接続において、第１メディアコンポーネントにおいて、ポートオブジェクトを出力ポートオブジェクトとし、第２メディアコンポーネントにおいて、ポートオブジェクトを入力ポートオブジェクトとすることは当業者が容易になし得ることである。 
〈相違点３〉について 
　（Ｋ）（Ｌ）の記載によれば、ミキサプログラムは、ＣＭデータのストリームであることが明らかなデジタルオーデオ入力ストリームの任意の数Ｎをとり、そして全部の合成と各Ｎ−１の合成の出力ストリームを生成し、それぞれのタイプを適切に扱い、異なるデータタイプの間の変換を達成し、低−高遅延ストリームを区別する旨、また、ＣＭ　I/Oについては、ＣＭ　I/Oへのアクセスにより音を獲得し、再生（ＰＬＡＹ）するためのオブジェクトを定義する旨あることから、ＣＭ＿ＮＯＤＥがミキサコンポーネントである場合にはＣＭデータであることが明らかなデジタルオーデオストリームを合成し、出力ポートに出力する処理を行うことが、また、ＣＭ＿ＮＯＤＥがＣＭI/O（例えば、マイクやスピーカのコンポーネント）である場合には、入力ポートから音を獲得したり音の再生に係る処理を行うことが読み取れる。 
　そして、オブジェクト指向技術における各オブジェクトのデータ処理は通常そのオブジェクトのメソッドとして定義されるものであるから、前記ＣＭ＿ＮＯＤＥにおける処理を対応するメディアコンポーネントのメソッドとして実現し、刊行物１の発明において、第１メディアコンポーネント、及び、第２メディアコンポーネントが、それぞれ各出力ポート、及び、入力ポートに対応し、マルチメディアコンテンツデータを処理するメンバ関数とを有するメディアコンポーネントであると成すことは、格別なことではなく、前記事項を参酌することにより当業者が容易になし得ることである。 
　しかも、本願請求項１の発明の奏する効果は、刊行物１の発明において奏する効果にくらべて格別顕著なものとも認められない。 
　 
６．むすび 
　以上のとおり、本願請求項１の発明は、刊行物１及び刊行物２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　よって、結論のとおり審決する。