【事件の表示】
　平成　７年特許願第５０９１４９号「オブジェクト指向オーディオ・システム」拒絶査定不服審判事件〔平成　７年　３月２３日国際公開、ＷＯ９５／０８１４６、平成　９年　３月１８日国内公表、特表平　９−５０２８２１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、１９９４年１月６日（パリ条約による優先権主張１９９３年９月１３日、米国）を国際出願日とする出願であって、平成１６年８月１３日付で拒絶査定がなされ、これに対し、同年１１月２２日に拒絶査定に対する審判請求がなされるとともに、同年１２月２２日付で手続補正がなされたものである。
　
２．平成１６年１２月２２日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　　平成１６年１２月２２日付の手続補正を却下する。
［理由］
（１）補正後の本願発明
　本件補正により、特許請求の範囲の請求項１は、
　
「記憶装置、ディスプレイおよびマウスを有するコンピュータシステムにおいて使用するオーディオコンポーネント間のデジタルオーディオデータを視覚的にルーチングする装置であって、
　メンバ関数を有する第１オーディオコンポーネントオブジェクトを前記記憶装置に生成し、出力ポートオブジェクトを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第１オーディオプロセッサオブジェクトをサウンドサーバタスクに生成し、出力オーディオポートに前記デジタルオーディオデータを生成する手段と、
　メンバ関数を有する第２オーディオコンポーネントオブジェクトを前記記憶装置に生成し、入力ポートオブジェクトを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第２オーディオプロセッサオブジェクトを前記サウンドサーバタスクに生成し、入力オーディオポートに前記デジタルオーディオデータを提供する手段と、
　前記マウスによって制御され、前記ディスプレイ上で前記出力ポートオブジェクトアイコンと前記入力ポートオブジェクトアイコンとの間に幾何学図形を伸張する手段と、
　前記幾何学図形の伸張に応じて、前記サウンドサーバタスクにおいて前記出力オーディオポートを前記入力オーディオポートに接続して、前記第１オーディオプロセッサオブジェクトにより生成された前記デジタルオーディオデータを、前記第２オーディオプロセッサオブジェクトにルーチングする手段と
　を備えたことを特徴とする装置。」
　
と補正された。
　上記補正は、請求項１に記載した発明を特定するために必要な事項である「オーディオ情報」について「デジタルオーディオデータ」と限定するものであって、特許法第１７条の２第３項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第４項において準用する同法第１２６条第３項の規定に適合するか）について以下に検討する。
　
（２）引用例
　原査定の拒絶の理由に引用された、阿部倫之外，”交換サービスモデリングシステムの一検討”，電子情報通信学会技術研究報告，第９０巻，第３８９号，１９９１．１．１８，ｐ．１〜６（以下、「引用例１」という。）には、次の事項が記載されている。
　
(a)「３．オブジェクト指向の導入
３．１　オブジェクト
　オブジェクトの基本構造を図２に示す．オブジェクトは、スロットに格納されたデータとそれを操作する手続きから成る．この手続きをメソッドと呼ぶ．我々が考える交換サービス仕様においては，図１に示した各アイコンをオブジェクトとして扱う．これらのアイコンは，図３に示す様に互いにメッセージをやりとりしながら処理が進められるため，本質的にオブジェク指向的な振る舞いをしている．従って，オブジェクト指向を用いると，サービス仕様が直接的に表現できるとともに，その仕様を実際に動作させることが可能である。この動作きは，交換機の動作そのものであることから，この仕様自身が実際の交換ソフトウエアになる可能性を持っている。
　各アイコンは，
　（１）視覚表現のための手続きとデータ
　（２）交換処理のための手続きとデータ
の２つのオブジェクトから成る．これらを１つのオブジェクトとしてまとめると，本質的な交換処理の中に視覚表現用の処理が埋め込まれるため，処理の追加，変更がしにくくなるとともにプログラムの可読性が悪くなる．そこで，（１）を表示オブジェクト，（２）を処理オブジェクトと呼び，別々のオブジェクトとして構成し，後でリンケージする方法を用いる．」（２頁右欄１２行〜３頁左欄１３行）
　
(b)「４．　プロトタイプ試作
４．１　試作範囲
　交換サービスをモデル化し，交換サービスの振舞いを実際の動作イメージに近い形式で図式表示する交換サービスモデリングシステムのプロトタイプを試作した．試作には，Ｌｉｓｐ系オブジェクト指向言語ＣＬＯＳ（Ｃｏｍｍｏｎ　Ｌｉｓｐ　Ｏｂｊｅｃｔ　Ｓｙｓｔｅｍ）（５）（６）を用いてＷＳ２０５０／３２Ｅ上にインプリメントした．」（４頁左欄１３行〜２０行）
　
(c)「３．３インスタンス
　クラス定義によって定義されたオブジェクトは，クラス定義から生成された’オブジェクト’となることで実行の対象となりえる．このオブジェクトをインスタンスと呼ぶ．」（４頁左欄１行〜５行）
　
(d)「４．３　表示クラス
　表示クラスを構成する場合，まず記述対象の図形を設計してから，その図形をウインドウ表示できるような情報をもつクラスを定義する．図７に記述対象の図形を示す．記述対象の図形を，線（ｌｉｎｅ），折れ線（ｐｏｌｙｌｉｎｅ），長方形（ｂｏｘ）などの基本図形の組合せで表現する．図形を変化させたり表示したりするメソッドは表示オブジェクトのメソッドとして定義する．」（５頁左欄１行〜８行）
　
(e)「４．４　メッセージの流れ
　表示オブジェクトと処理オブジェクト間のメッセージの流れを図８に示す．主なメッセージの流れは，処理オブジェクト相互間および表示オブジェクトと処理オブジェクト間である．表示オブジェクト相互間でメッセージがやりとりされるのは，表示図形の移動や削除などの図形処理の場合である．例えば，ノードの移動時にアークも追従させたりするような場合がある．」（５頁左欄９行〜右欄２行）
　
(f)「４．５　動作イメージ
　プロトタイプシステムによる３者通話サービスのモデリング例を図９に示す．交換サービスを構成するための部品ウインドウと，部品を転記して交換サービスモデルを組み立てるモデルウインドウがある．部品ウインドウ中のオブジェクトはクラスであり，モデルウインドウ中のオブジェクトはインスタンスである．部品ウインドウからモデルウインドウへの転記は，クラスからインスタンスを生成することに相当する．」（５頁右欄３行〜６行左欄２行）
　
(g)「動作イメージを図１０の動作例を思いて説明する．図において，一般利用者からポップアップメニューの’受話器を上げる’を選択すると，この処理は時計オブジェクトのスケジューラに登録され，時計オブジェクトから端末ユーザインタフェースを介して多機能電話機に処理結果のメッセージが伝えられる（この場合，’受話器を上げる’メッセージの送信）．これに続いて多機能電話機から’オフフック’メッセージが内線オブジェクトを介して交換機に伝えられるが，この処理もまず時計のスケジューラに登録されて，スケジューラから処理結果が交換機に伝えられる．交換機にメッセージが流れるとそれに対する応答がプロトタイピングしたシナリオに従って送出されるが，この処理も時計のスケジューラから起動される．」（６頁左欄７行〜２１行）
　
(h)図７を参照すると、交換サービス仕様記述対象の図形が描かれ、そのうち、「多機能電話機」及び「交換機」を示す図形の左右には、「・」様のものが記載されている。
　
(i)図８を参照すると、「デイジタル多機能電話機」、「内線」、「複合ＰＢＸ」などの「処理オブジェクト」間において、「メッセージ」を示す矢印が相互に接続されており、これらの処理オブジェクト間において、メッセージがやりとりされることが記載されている。
　
(j)図９を参照すると、モデルウインドウ（図面上部のウィンドウ）において、多機能電話機（ＭＦＴ　１）を示す図形と交換機（ＣＸ　１）を示す図形とが、内線（ｉｌｉｎｅ　１）を示す線で結合されていることが記載されている。
　
　同じく、原査定の拒絶の理由に引用された、Anderson D. P. et al., COMET:A TOOLKIT FOR MULTIUSER AUDIO/VIDEO APPLICATIONS, Distributed Computing Systems, 1992., Proceedings of the 12th International Conference, IEEE, 1992.6, ISBN:0-8186-2865-0, p.555-562（以下、引用例２という。）には、次の事項が記載されている。
　
(k)Comet is a UNIX/C++ toolkit for writing programs, like teleconferencing systems and collaborative editors, that involve multiple users and use digital audio and video.
（審決仮訳：）「Cometは、電子会議システムや協調編集のような、複数のユーザを含み、デジタルオーディオ、映像を使用するプログラムを記述するためのUNIXのC++ツールキットである。」（５５５頁左欄２行〜５行）
　
(l)2.1. Master/Slave Architecture
　Comet applications have a master/slave structure. Each participant runs a separate instance of the slave program, and there is a single instance of the master program. The master program can run as a daemon at a well-known host, or can be run on demand by the slave program.
（審決仮訳：）「2.1. マスタ/スレーブ・アーキテクチャ 
　Cometアプリケーションはマスタ/スレーブ・ストラクチャーを有している。個々の参加者は、スレーブプログラムの個々に分かれたインスタンスとして実行され、マスタ・プログラムの単一のインスタンスがある。マスタ・プログラムは周知のホストにおいてデーモンとして実行される。つまり、スレーブプログラムによってオンデマンドで実行される。」（同頁右欄下から４行〜５５６頁左欄上から３行）
　
(m)2.2. Continuous Media Objects
　The master program manages the continuous media (audio/video) components of the application.
（審決仮訳：）「2.2. 連続メディアオブジェクト 
　マスタ・プログラムは、アプリケーションの連続メディア（オーディオ／ビデオ）コンポーネントを管理する。」（５５６頁左欄２８行〜３０行）
　
(n)The Comet toolkit on the master side provides a set of C++ classes, derived from a base class CM_NODE, that represent these components. The current set of CM_NODE types is as follows:
・MICROPHONE and SPEAKER represent CM I/O devices. These devices are abstract in the sense that several of them (perhaps from different Comet applications) may be mapped simultaneously to the same physical I/O device.
（審決仮訳：）「マスタ側のCometツールキットは、基底クラスCM_NODEに由来する、C++クラスのセットを提供する。そのクラスは、前記連続メディアコンポーネントを表わすものである。現時点のCM_NODEタイプは以下のとおりである。: 
・MICROPHONEとSPEAKERはCM入出力デバイスを表わす。（恐らく異なるCometアプリケーションからの）これらのいくつかが、同時に同じ物理入出力デバイスに割り当てられるかもしれないという意味で、これらのデバイスは「抽象的」である。」（同頁同欄３１行〜４０行）
　
(o)A PORT object represents a connection point of a CM NODE; each CM_NODE has one or more associated PORTs. The operation
　p-link (PORT* q)
creates an (abstract) connection from output port p to input port q.
（審決仮訳：）「PORTオブジェクトは、ある１つのCM_NODEの接続点を表わす。それぞれのCM_NODEは１以上の関連したPORTを有する。オペレーション、
 p-link(PORT* q)
は、出力ポートｐから、入力ポートｑへの１つの（抽象）接続を作る。」（同頁右欄１行〜６行）
　
(p)The master program builds a directed graph of CM_NODES, then calls the setup() operation on any node of the graph (if the graph consists of multiple disjoint subgraphs, setup() must be called on at least one node of each subgraph). This call causes Comet to realize the graph (see Section 3) and starts the flow of data between the devices, processes, and files represented by the graph.
　For example, a teleconference application might construct the CM_NODE graph shown in Figure 1.
（審決仮訳：）「マスタ・プログラムは、（複数の）CM_NODE（間）の有向グラフを構築し、そして、そのグラフの何れかのノードでsetup()関数を呼ぶ。(グラフが分離した複数のサブグラフから成る場合、setup()関数はそのそれぞれのサブグラフの最低１つのノードで呼びだされなければならない。）この呼び出しはCometにグラフ(セクション3を参照)を実体化させ、グラフによって表わされる、デバイス、プロセス、およびファイルの間のデータのフローを開始する。
　例えば、電子会議アプリケーションは、図１で示されるCM_NODEグラフを構築するであろう。」（同頁同欄８行〜１８行）
　
(q)For example, as new participants join a conference, new MICROPHONE and SPEAKER objects are created and connected to the AUDIO_MIXER.
（審決仮訳：）「例えば、新しい参加者が会議に参加すると、新しいMICROPHONEおよびSPEAKERオブジェクトが生成され、AUDIO_MIXERに接続される。」（５５６頁右欄２１行〜２４行）
　
（３）対比
　本願補正発明と引用例１に記載された発明（以下「引用例１発明」という。）とを比較する。
　
　摘記事項(b)の記載から、引用例１発明は、「記憶装置、ディスプレイおよびマウスを有するコンピュータシステム」であることは明らかである。また、「多機能電話機」や「交換機」といったコンポーネント間のメッセージのやりとりを視覚的に定義しており（摘記事項(f)、図９）、当該メッセージは、「データ」であることは明らかであるから、引用例１発明は、「記憶装置、ディスプレイおよびマウスを有するコンピュータシステムにおいて使用するコンポーネント間のデータを視覚的にルーチングする装置」であるということができる。
　引用例１の「表示オブジェクト」は、視覚表現のための手続きとデータとからなるものである（摘記事項(a)）。ここで、「手続き」とは、C++などのオブジェクト指向言語において、「メンバ関数」を意味することは技術常識であるから、引用例１発明は、「メンバ関数を有するコンポーネントオブジェクト」を備えていると認める。
　また、引用例１の「処理オブジェクト」は、交換処理のための手続きとデータとからなり（摘記事項(a)）、デイジタル多機能電話機や複合ＰＢＸなどを表す処理オブジェクトは、メッセージを生成するものと認められるから（記載事項(i)）、引用例１発明は、「メンバ関数を有するプロセッサオブジェクト」を備えていると認める。
　一方、記載事項(j)及び摘記事項(f)を参照して、モデルウィンドウ中の、多機能電話機、交換機、及び内線などを示す部品は、部品ウインドウ中の部品をモデルウインドウに転記して、インスタンスとなったオブジェクトであることが読み取れるから、引用例１の、「多機能電話機（ＭＦＴ　１）」及び「交換機（ＣＸ　１）」の表示オブジェクトは、本願補正発明の「第１コンポーネントオブジェクト」及び「第２コンポーネントオブジェクト」に、「多機能電話機（ＭＦＴ　１）」及び「交換機（ＣＸ　１）」の処理オブジェクトは、本願補正発明の「第１プロセッサオブジェクト」及び「第２プロセッサオブジェクト」に、「内線（ＩＬＩＮＥ　１）」を表す線分は、本願補正発明の「幾何学図形」にそれぞれ相当するものと認める。
　記載事項(h)を参照して、多機能電話機の図形及び交換機の図形の両側の「・」は、多機能電話機と交換機との間を内線で結ぶための「接続点」であるものと認められ、図９を参照して、多機能電話機と交換機との間は、当該接続点を介して内線にて接続されていることが読み取れるので、多機能電話機右側の「・」および交換機左側の「・」は、それぞれ「出力ポートを表すアイコン」および「入力ポートを表すアイコン」であるということができる。
　
　引用例１において、クラス定義から生成され、実行の対象となったオブジェクトをインスタンスと呼び（摘記事項(c)）、「部品ウインドウと、部品を転記して交換サービスモデルを組み立てるモデルウインドウ」があり、「部品ウインドウ中のオブジェクトはクラスであり、モデルウインドウ中のオブジェクトはインスタンス」であり、「部品ウインドウからモデルウインドウへの転記は、クラスからインスタンスを生成することに相当する」（摘記事項(f)）ものである。つまり、部品ウィンドウにある「部品」は、クラス定義の状態の「オブジェクト」であり、そのものだけでは実行の対象とはならず、当該「部品」をモデルウィンドウへ転記すると、実行対象である「オブジェクト」（インスタンス）となることを示しており、当該「転記」することは、クラスからオブジェクト（インスタンス）を生成することに相当することが引用例１に記載されているものと認める。
　而して、クラス定義からインスタンスたる「オブジェクト」が生成される際には、「記憶装置に生成」されることは技術常識であり、図７及び図９並びに摘記事項(d)及び記載事項(h)を参照して、「出力ポートを表すアイコン」及び「入力ポートを表すアイコン」がディスプレイに生成されていることも明らかであるから、引用例１発明は、「メンバ関数を有する第１コンポーネントオブジェクトを記憶装置に生成し、出力ポートを表すアイコンをディスプレイに生成する手段」及び「メンバ関数を有する第２コンポーネントオブジェクトを記憶装置に生成し、入力ポートを表すアイコンをディスプレイに生成する手段」を備えていると認める。
　また、引用例１発明は、処理オブジェクト相互間でメッセージが流れるものである（摘記事項(e)）から、「メンバ関数を有する第１プロセッサオブジェクトを生成し、出力ポートにデータを生成する手段」及び「メンバ関数を有する第２プロセッサオブジェクトを生成し、入力ポートにデータを提供する手段」を備えていると認める。
　
　引用例１において、部品ウィンドウから部品を転記するにあたり、マウス等の操作によって転記されることは当業者に自明である。また、図９を参照すると、多機能電話機（ＭＦＴ　１）と交換機（ＣＸ　１）との間には、内線（ＩＬＩＮＥ　１）が設けられ、摘記事項(f)を参照して、当該内線（ＩＬＩＮＥ　１）は、部品ウィンドウにある、（ｉｌｉｎｅ）と記載された線分が伸張されたものであると推定されるので、引用例１発明は、「マウスによって制御され、ディスプレイ上で出力ポートアイコンと入力ポートアイコンとの間に幾何学図形を伸張する手段」を備えていると認める。
　さらに、多機能電話機の出力ポートアイコン及び交換機の入力ポートアイコンを接続することによって、多機能電話機（第１プロセッサオブジェクト）と交換機（第２プロセッサオブジェクト）とが接続され、多機能電話機と交換機の間ではデータがルーチングされている（摘記事項(g)「多機能電話機から’オフフック’メッセージが内線オブジェクトを介して交換機に伝えられる」参照。）ことから、引用例１発明は、「幾何学図形の伸張に応じて、出力ポートを入力ポートに接続して、第１プロセッサオブジェクトにより生成されたデータを、第２プロセッサオブジェクトにルーチングする手段」を備えていると認める。
　
　したがって、本願補正発明と引用例１発明とは、
　
「記憶装置、ディスプレイおよびマウスを有するコンピュータシステムにおいて使用するコンポーネント間のデータを視覚的にルーチングする装置であって、
　メンバ関数を有する第１コンポーネントオブジェクトを前記記憶装置に生成し、出力ポートを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第１プロセッサオブジェクトを生成し、出力ポートに前記データを生成する手段と、
　メンバ関数を有する第２コンポーネントオブジェクトを前記記憶装置に生成し、入力ポートを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第２プロセッサオブジェクトを生成し、入力ポートに前記データを提供する手段と、
　前記マウスによって制御され、前記ディスプレイ上で前記出力ポートアイコンと前記入力ポートアイコンとの間に幾何学図形を伸張する手段と、
　前記幾何学図形の伸張に応じて、前記出力ポートを前記入力ポートに接続して、前記第１プロセッサオブジェクトにより生成された前記データを、前記第２プロセッサオブジェクトにルーチングする手段と
　を備えた装置。」
　
で一致し、以下の点で相違している。
　
［相違点１］本願補正発明のコンポーネントは、オーディオコンポーネントであり、デジタルオーディオデータをルーチングする装置であるのに対し、引用例１発明のコンポーネントは、多機能電話機や交換機などであり、メッセージをルーチングする装置である点。
　
［相違点２］本願補正発明は、「出力ポート」及び「入力ポート」を「オブジェクト」として扱っているのに対し、引用例１発明は、出力ポート及び入力ポートをどのようにして扱うか明記されていない点。
　
［相違点３］本願補正発明は、「サウンドサーバタスク」を有し、該「サウンドサーバタスク」にプロセッサオブジェクトを生成するものであるのに対し、引用例１発明は、プロセッサオブジェクトがどこに生成されるのかが明らかでない点。
　
（４）判断
［相違点１］について
　引用例２は、摘記事項(k)に記載のとおり、「デジタルオーディオ」データを取り扱う、「Comet」アプリケーションに関するものと認められる。
　摘記事項(n)の記載によれば、物理入出力デバイスに割り当てられる、MICROPHONEオブジェクトとSPEAKERオブジェクトが生成され（摘記事項(q)）、これらは「オーディオコンポーネント」であるということができる。
　そして、引用例２には、Cometアプリケーションのマスタ・プログラムは、これらのオーディオコンポーネント間に有向グラフを構築すること、および、setup()関数を呼び出すことによってこれらコンポーネント間においてデータフローが開始されることが記載されている（摘記事項(p)）ことから、「オーディオコンポーネント間のデジタルオーディオデータをルーチングする装置」が記載されているということができる。
　引用例２は、摘記事項(k)や(n)から当業者に明らかな如く、オブジェクト指向プログラミングによって、オーディオデータを扱うものであり、一方、引用例１も同じくオブジェクト指向プログラミングによって、データのやりとりを扱うもので共通するから、引用例１発明において、対象を多機能電話機や交換機に代えてオーディオコンポーネントとし、デジタルオーディオデータをルーチングするよう構成することは当業者にとって容易である。
　
［相違点２］について
　出力ポートや入力ポートをオブジェクトとして取り扱うことは引用例２に記載（摘記事項(o)）されており、オブジェクト指向プログラミングにおいて、どの部分をどのようなオブジェクトとしてインプリメントするかは単なる設計的事項に過ぎないので、出力ポート及び入力ポートをオブジェクトとして扱うことは当業者が適宜なし得ることである。
　
［相違点３］について
　引用例２には、Cometアプリケーションのマスタ・プログラムは、デーモンとして実行されることが記載されている（摘記事項(l)）。ここで、「デーモン」とは、サーバにてサービスを提供するために実行されるプログラム（タスク）であることは技術常識であり、Cometアプリケーションのマスタ・プログラムは、「サーバタスク」であるということができる。
　また、摘記事項(m)によると、上記「MICROPHONEオブジェクト」、「SPEAKERオブジェクト」などは、「マスタ・プログラム」において生成されることが示唆されていることから、引用例２において、これらオブジェクトをサーバタスクに「生成する手段」を有するものと認める。そして、上記「サーバタスク」は、「サウンドサーバタスク」であるということができる。さらにこれらオブジェクトがメンバ関数を有することも技術常識である。
　したがって、引用例２には「メンバ関数を有するオーディオプロセッサオブジェクトをサウンドサーバタスクに生成する手段」が開示されているものと認める。
　してみれば、先に相違点１において検討したとおり、引用例１、引用例２共オブジェクト指向プログラミングを行うことで技術関連性を有するから、引用例１発明に引用例２記載の技術を転用し、サウンドサーバタスクにプロセッサオブジェクトを生成することは当業者にとって容易である。
　
　そして、本願補正発明の作用効果も、引用例１及び引用例２から当業者が予測できる範囲内のものである。
　
　したがって、本願補正発明は、引用例１及び引用例２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、特許法第１７条の２第４項で準用する同法第１２６条第３項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
　平成１６年１２月２２日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１６年６月３０日付手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「記憶装置、ディスプレイおよびマウスを有するコンピュータシステムにおいて使用するオーディオコンポーネント間のオーディオ情報を視覚的にルーチングする装置であって、
　メンバ関数を有する第１オーディオコンポーネントオブジェクトを前記記憶装置に生成し、出力ポートオブジェクトを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第１オーディオプロセッサオブジェクトをサウンドサーバタスクに生成し、出力オーディオポートに前記オーディオ情報を生成する手段と、
　メンバ関数を有する第２オーディオコンポーネントオブジェクトを前記記憶装置に生成し、入力ポートオブジェクトを表すアイコンを前記ディスプレイに生成する手段と、
　メンバ関数を有する第２オーディオプロセッサオブジェクトを前記サウンドサーバタスクに生成し、入力オーディオポートに前記オーディオ情報を提供する手段と、
　前記マウスによって制御され、前記ディスプレイ上で前記出力ポートオブジェクトアイコンと前記入力ポートオブジェクトアイコンとの間に幾何学図形を伸張する手段と、
　前記幾何学図形の伸張に応じて、前記サウンドサーバタスクにおいて前記出力オーディオポートを前記入力オーディオポートに接続して、前記第１オーディオプロセッサオブジェクトにより生成された前記オーディオ情報を、前記第２オーディオプロセッサオブジェクトにルーチングする手段とを備えたことを特徴とする装置。」
　
（１）引用例
　原査定の拒絶の理由に引用された引用例、および、その記載事項は、前記「２．（２）」に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明の「デジタルオーディオデータ」を「オーディオ情報」と上位概念化するものである。
　そうすると、本願発明の構成要件を全て含み、さらに下位概念化したものに相当する本願補正発明が、前記「２．（４）」に記載したとおり、引用例１及び引用例２に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１及び引用例２に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用例１及び引用例２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。