【事件の表示】
　特願２００１−１４６５２９「検索サービスの配信方法」拒絶査定不服審判事件〔平成１４年　２月　８日出願公開、特開２００２−　４１５６９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年５月１６日（優先権主張平成１２年５月１９日）に出願したものであって、平成１６年８月１０日付で拒絶査定がなされ（発送日同年８月１７日）、これに対し、同年９月１６日に拒絶査定不服審判の請求がなされるとともに、同年１０月１８日付で手続補正がなされたものである。
　
２．平成１６年１０月１８日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１６年１０月１８日付の手続補正を却下する。
［理由］
（１）平成１６年１０月１８日付の手続補正書により補正された本願発明
　本件補正により、特許請求の範囲の請求項１は、下記のように補正された。
「検索鍵を用いて蓄積された情報を検索し、検索結果を提示する検索サービスの配信方法において、
　時系列データの名称および該時系列データに関連する情報を蓄積する情報蓄積過程と、
　前記時系列データの一部または全部の特徴時系列を蓄積する時系列信号特徴蓄積過程と
、
　前記検索鍵を受理する検索鍵時系列信号入力過程と、
　受理された前記検索鍵から該検索鍵を表現する特徴を導く特徴計算過程と、
　前記時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し、該注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合する特徴照合過程と、
　前記特徴照合過程における照合結果に基づいて前記情報蓄積過程で蓄積された情報の中から出力すべき情報を選択する検索情報選択過程と、
　前記検索情報選択過程における検索情報選択結果に基づいて検索結果を提示する情報提示過程と
　を備えることを特徴とする検索サービスの配信方法。」
　
　上記補正は、旧請求項１の発明特定事項である「特徴照合過程」について、「注目窓を設定し」を「前記時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し」と技術的に限定し、「該注目窓内の特徴と、特徴計算過程にて導かれた特徴の時系列とを、注目窓を移動させながら照合する」を「該注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合する」と技術的に限定するものである。
　したがって、本件補正は、特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。
　
（２）引用発明の認定
　原査定の拒絶の理由に引用された特開平１１−１２０１９８号公報（以下、「引用例１」という。）には、図面とともに、以下（ア）〜（オ）の事項が記載されている。
　　　
（ア）
「【０００１】
【発明の属する技術分野】 本発明は、使用者が曲名を知りたいと思っている楽曲を、例えばうろ覚えのメロディなどから簡易に検索できるようにする楽曲検索装置に関するものである。
【０００２】
【従来の技術】 テレビ番組、コマーシャル、ラジオ放送その他で耳にした楽曲について、メロディの一部を記憶しており、その曲の曲名や演奏者が知りたいという場合が多い。このような場合、一般には、或る程度音楽に詳しい人に聞いたりするなどしかその曲名等を知り得る方法はない。ところがこのような方法では聞いた人の楽曲知識に左右され、必ずしも知りたい曲名がわかるものではない。
【０００３】 一方、何らかの手がかりに基づいて楽曲を検索する技術として、特開平７−２７２４６２号公報や、特開平８−１２３８１８号公報により提案された技術、及びこれらの公報に従来技術として記載された技術などがある。 例えば楽曲とともに曲名、演奏者名、作曲者名その他の書誌的事項をキーワードとして検索する方式や、知りたい楽曲の全部又は一部のメロディを楽譜として入力し、それに基づいて楽曲を検索する方式がある。さらに楽譜として入力するには音楽的専門知識が必要になることに鑑みて、より視覚的に簡易に旋律を入力できるようにしたものもある。 また歌詞の出だしの一部を入力する方式や、メロディの一部をハミング等の音声で入力する方式もある。
【０００４】
【発明が解決しようとする課題】ところで、上述のようにメロディの一部を記憶していてその曲が知りたいような場合としては、特にその人が歌、口笛、ハミング等の音声でそのメロディを入力し、その入力音声に基づいて検索が行われるようにすることは、特に楽譜記入等のような専門知識は必要ないため、好適なものとなる。」
　
（イ）
「【０００８】
【発明の実施の形態】 以下、本発明の第１、第２の実施の形態としての楽曲検索装置を順に説明する。 図１は実施の形態の楽曲検索装置としてのシステム構成を示すものである。本例の楽曲検索装置は、複数の検索端末１と、検索センタ３とがネットワーク２により通信可能に接続されて構成される。ネットワーク２は例えばＬＡＮ（LOCAL AREA NETWORK）として当該楽曲検索装置の専用ネットワークとして構築されてもよいし、例えばＩＳＤＮなどの公衆ネットワークが利用されてもよい。また、楽曲検索装置は、ＰＨＳ等の無線システムを用いて基地局を中継して形成される公衆ネットワークを利用してもよい。
【０００９】検索端末１は、ＣＤショップやコンビニエンスストア、ホテル、スーパーマーケットなどの店頭など、各所に配置され、不特定多数のユーザーが有料もしくは無料で利用できるものとする。また、一般家庭に配置されても良い。もちろん会社や学校などの特定の組織内において或る程度限定された人のみが利用できるようにすることも考えられる。また、上記のように無線システムを利用する場合は、検索端末１を携帯型として各ユーザーが持ち歩くようにしてもよい。
【００１０】検索センタ３は、検索端末１から送信される検索情報に基づいて、検索動作を行い、検索端末１のユーザーが求める楽曲の曲名等を検索する。そしてその検索結果を検索端末１に送信し、検索端末１がユーザーに提示する。検索センタ３は、検索動作のために、検索処理やネットワーク送受信処理を行うサーバ４と、検索動作対象となる検索データベース５、楽曲データベース６を備える。検索データベース５は、多数の楽曲について、その曲名、演奏者名、作詞作曲者名などの書誌的情報とともに、その楽曲の旋律に関する情報が格納されている。またさらに楽曲のリズム情報や、歌詞、さらにはその楽曲の付属情報を格納してもよい。楽曲の付属情報とは、例えばその楽曲が使用されているテレビ番組やコマーシャル名などの情報などが考えられる。
【００１１】検索端末１から送信される検索情報は、本例の場合、基本的には検索したい楽曲の旋律の一部又は全部に関する情報であり、特にこの第１の実施の形態の例では旋律の楽律の変化量の情報となる。従って、検索データベース５においては旋律に関する情報として、旋律の楽律の変化量の情報が格納されていることで、サーバ４は検索情報に基づいた曲名検索が可能となる。なお、必ずしも変化量自体を格納しておかなくとも、旋律としての情報を格納しておいて、サーバ４が検索時に各楽曲について格納されている旋律の音律から変化量を求め、それと送信されてきた検索情報の照合をとって検索を行うようにすることもできる。
【００１２】楽曲データベースは、検索データベース５に格納されている各曲名に対応して、実際の楽曲としての音楽情報（オーディオデータ）が格納されている。サーバ４は検索データベース５から検索した曲名に応じて楽曲データベースを検索し、音楽としての情報を取り出すことができる。」
　
（ウ）
「【００１３】図２、図３に検索端末１としての構成例を示す。図２は検索端末１の外観例を示している。検索端末１にはユーザーに対する表示出力部として、楽音番号表示部１１、表示部１２が、例えば液晶パネルなどの部材により形成される。表示部１２は、ユーザーに対する入力ガイド表示や検索結果としての曲名等の表示を実行する部位である。  楽音番号表示部１１は、入力された旋律の楽音の１つ１つに順に付される番号を表示する部位であり、主に後述する修正動作の際のガイド表示として用いられる。
【００１４】またマイク／スピーカ部１３が設けられ、ユーザーの発する音声として歌、ハミング、口笛等の音声を入力できるマイクロホンや、ユーザーに対するメッセージ出力や、修正動作の際の入力旋律の再生、検索結果確認の際の楽曲の出力などに用いられるスピーカが配されている。」
　
（エ）
「【００１６】 図３は検索端末１の内部構成例を示す。マイクロホン２５は、図２のマイク／スピーカ部１３内に配されるマイクロホンであり、ユーザーの音声を集音する。マイクロホン２５で得られた音声信号はマイクアンプ２６で所定レベル増幅され、Ａ／Ｄ変換器２７でデジタルデータに変換されてバス２８に出力される。バス２８に接続された各ブロックは相互にデータやコマンドの送受信が可能とされる。
【００１７】メモリ２９は例えばＤ−ＲＡＭ、Ｓ−ＲＡＭ、フラッシュメモリなどの半導体メモリにより形成され、一連の検索動作に必要な情報を記憶する。また本例ではオーディオデータなどを記憶することで大容量化が必要になることなどの事情からハードディスク、光磁気ディスクなどをメモリ２９の一部として用いるように搭載してもよい。記憶する情報は、Ａ／Ｄ変換器２７から出力される入力音声データ、旋律解析部３８での解析結果としての解析データ、修正処理部３９での修正結果としての修正解析データ、検索情報として検索センタ３に送信するための送信データ、検索結果として検索センタ３から送信されてきた曲名や音楽情報などの受信データなどとなる。
【００１８】コントローラ３０は、検索端末１の全体の制御を行う部位とされ、操作部３１からのユーザーの操作に応じた必要な処理が実行されるように各部の制御を行う。また表示部３２に対する表示制御も行う。操作部３１とは図２に示した各種操作キー（１４〜２４）に相当する。また表示部３２とは楽音番号表示部１１及び表示部１２に相当する。
【００１９】音源部３３は、例えば修正動作時などに入力された旋律の音声の発音などに用いる音源情報（例えばＦＭ音源情報、ＰＣＭ音源情報など）を保持する部位である。  Ｄ／Ａ変換器３４は、音源部３３から出力される音声データもしくはメモリ２９から供給される音声データをアナログ音声信号に変換する。Ｄ／Ａ変換器３４から出力されるアナログ音声信号はスピーカアンプ３５で増幅された後、図２のマイク／スピーカ部１３内に配されるスピーカ３６から音声としてユーザーに対して出力される。
【００２０】送受信部３７は、ネットワーク２を介した検索センタ３との情報通信を行う部位となる。即ちユーザーの入力した旋律に基づいて生成される検索情報を検索センタ３に送信するとともに、検索センタ３からの検索結果としての曲名等の情報や、オーディオデータとしての音楽情報の受信を行う。なお、上記のように無線システムを利用する場合は、この送受信部３７は、無線通信装置とする。すなわちその場合は、検索センタ３側にも無線通信装置を備えるか、もしくは基地局を中継してネットワークと通信可能とすることで、検索端末１と検索センタ３が各種情報を無線通信でやりとりできるようにする。
【００２１】旋律解析部３８は、ユーザーが音声入力した旋律に対して各楽音の音律を解析する処理や、解析した音律から検索情報としての音律の変化量の情報を生成する処理などを行う。」
　
（オ）
「【００２２】このような構成の検索端末１と、検索センタ３によって行われる楽曲検索処理を図４、図５、図６で説明する。図４は検索の際の検索端末１の処理をステップＦ１０１〜Ｆ１０７で示し、また検索センタ３側の処理をステップＦ２０１〜Ｆ２０４で示している。検索の際には、ユーザーはまず検索したい曲の旋律の一部を口笛やハミング等でマイクロホン２５から入力する。これに応じて検索端末１ではステップＦ１０１の旋律入力処理が行われる。
【００２３】例えばユーザーは主旋律としての旋律の一部を入力することになるが、このために主旋律キー１５を押す。するとコントローラ３０はステップＦ１０１として主旋律の入力対応モードに入り、旋律入力キー１４の操作を監視する。例えば本例ではコントローラ３０は、ユーザーが旋律入力キー１４を押しながらマイクロホン２５に向かって発した音声を、入力音声と判断する。従って旋律入力キー１４が押されたことが検出されたら、コントローラ３０はその時点から入力される音声、つまりＡ／Ｄ変換器２７から出力される音声データを、メモリ２９に記憶していく処理を実行させる。この動作は、旋律入力キー１４の押圧操作が終わる時点まで継続される。従ってユーザーは、ハミング等で旋律を歌う際に、旋律入力キー１４を押していればよい。
【００２４】旋律入力キー１４が押されている期間の旋律入力処理（ステップＦ１０１）を終えると、続いてコントローラ３０はステップＦ１０２として入力旋律解析処理を旋律解析部３８に実行させる。この解析処理は、メモリ２９に記憶された入力音声データとしての旋律に対し、まずその旋律を時系列で所要の単位に分割する処理を行う。そして分割された各時間毎の旋律の音声（楽音）毎にフーリエ変換を行い、基本となる周波数を調べることで、旋律を構成する楽音の音律を求める処理となる。
【００２５】例えば入力された旋律の楽律は図５のようになる。なお、図５においては横軸は時間、縦軸は周波数、色の濃さがパワースペクトルの強さを示している。そしてこの図５はある旋律をユーザーが口笛で入力した場合に、その旋律を時系列にある単位で分割し、各時間毎の旋律のフーリエ変換を行った周波数スペクトルとなる。ここで周波数が誤差と認められない程度以上に変化しほぼ周波数が一定になったところから、次に誤差と認められない程度以上に変化したところまでを１楽音とする。またその期間の時間を音長とする。各楽音について代表する周波数を求め、例えば平均化して、その周波数をその楽音を表す周波数とする。解析された各楽音の周波数の情報及び音長の情報はメモリ２９に記憶される。以上のような旋律解析処理がステップＦ１０２として行われる。
【００２６】次に、入力され解析された旋律が正しいか否かの確認及び必要に応じた修正を行う処理としてステップＦ１０３の修正入力処理が行われる。このために、コントローラ３０はメモリ２９に記憶された各楽音の周波数の情報に基づいて旋律の再生を行い、ユーザーはそれを聞いて入力した旋律が正しいか否かを判断するとともに、修正操作があった場合は、修正処理部３９にメモリ２９に記憶されている周波数情報もしくは音長の修正を実行させる。
【００２７】例えばユーザーが入力再生キー１７を押す毎に、１楽音づつ音を発生させる。即ちコントローラ３０は入力再生キー１７の操作に応じて、記憶されている１楽音毎の周波数情報による音律及び音長で、音源部３３からの音声信号発生処理を実行させ、Ｄ／Ａ変換器３４，スピーカアンプ３５を介してスピーカ３６から音を出力させる。ユーザーは入力再生キー１７を押していくことで、入力した旋律の音を順次聞くことができ、これによって旋律が正しいか否かを判断できる。このとき旋律の最初の楽音から何番目の楽音であるかは、コントローラ３０が楽音番号表示部１１に表示を実行させることでユーザーに提示する。
【００２８】このように１楽音毎に音を聞いていき、ユーザーは誤った音律もしくは音長の楽音があると判断した場合は、その楽音についての修正操作を行う。例えば音律を修正したい楽音が出力された時点で、ユーザーは周波数修正キー１８を操作する。例えば周波数修正キー１８は、その上下ボタンの一方を１回押すことで音律を高音又は低音側に半音だけ変化できるようにする。つまり修正処理部３９は半音の修正操作に応じて半音の上下に相当する分だけ周波数情報を更新する。半音の周波数とは、修正したい楽音の周波数を１２で割った値である。周波数修正は半音以外にも変化できるようにしてもよい。また音長を修正したい楽音が出力された時点で、ユーザーは音長修正キー１９を操作する。例えば音長修正キー１９は、その左右ボタンの一方を１回押すことで音長を、所定長（例えば８分音符の長さ）だけ長短に変化できるようにする。つまり修正処理部３９は音長の修正操作に応じて、相当する分だけ音長情報を更新する。
【００２９】修正操作方法としてはこれ以外にも、修正したい楽音の出力の際に、消去キー２０を押した後、追加キー２１を押して正しい音を入力するという方法もある。即ち修正個所としての楽音の際にユーザーは消去キー２０を押すことで、修正処理部３９はその楽音の周波数情報及び音長情報を修正対象としてオミットする。ユーザーは、消去キー２０を押した後、入力再生キー１７で逆方向再生操作を数回行って旋律を前にさかのぼり、次に順方向再生操作を行って旋律を聴いていく。そして修正すべき楽音の箇所に来たら、追加キー２１を押して正しい音律又は音長の音声を入力する。即ちハミングや口笛等で入力する。なお、順方向再生操作で旋律を聞いている際に修正すべき個所にきたことがユーザーにわかりやすいように、追加キー２１に発光部を設け、消去キー２０が押された楽音箇所に相当する部分で追加キー２１の発光部を点滅させるなどの動作を行うようにしてもよい。もちろん表示部１２でのメッセージ表示などでユーザーに提示してもよい。このように追加キーの押圧とともに入力された音声は、旋律解析部３８の処理により上記同様に周波数情報と音長が判別される。そして修正処理部３９はその周波数情報と音長情報を、旋律内の１つの楽音の情報として追加する。
【００３０】音程もしくは音長が間違っていた場合だけでなく、旋律内の楽音として１つの音が抜けていた場合も、同様にその楽音があるべきタイミングで追加キー２１を押して音声入力することで、その楽音の周波数情報及び音長情報を旋律に追加できる。
【００３１】ユーザーは旋律の確認又は必要な修正操作を終えたら、主旋律キー１５、副旋律キー１６、エンターキー２３のいづれかを操作する。主旋律キー１５が押された場合は、コントローラ３０は他の主旋律が入力されるモードに移り、ステップＦ１０１に戻って、旋律入力処理を行う。そして上記同様に音声による旋律入力処理、旋律解析処理、修正入力処理がステップＦ１０１，Ｆ１０２，Ｆ１０３で行われる。例えばユーザーが楽曲の最初のメロディと、さびのメロディの両方を入力したい場合は、このように主旋律キー１５を押した後の音声入力を複数回行えばよい。
【００３２】ステップＦ１０３の終了時点でユーザーが副旋律キー１６を操作した場合は、コントローラ３０は副旋律が入力されるモードに移り、ステップＦ１０１に戻って、旋律入力処理を行う。そして上記同様に音声による旋律入力処理、旋律解析処理、修正入力処理がステップＦ１０１，Ｆ１０２，Ｆ１０３で行われる。ここで入力、解析、修正されてメモり２９に保持される周波数情報及び音長情報は、副旋律の情報とされる。例えばユーザーが楽曲のハーモニーを入力したい場合は、例えば主旋律の入力した後に、このように副旋律の入力を行えばよい。
【００３３】以上のように、ステップＦ１０１〜Ｆ１０３での入力は、ユーザーの操作に従って繰り返され、従って、１つの主旋律入力で終了される場合もあれば、複数の主旋律や１又は複数の副旋律が入力される場合もある。ステップＦ１０３の段階でユーザーがエンターキー２３を押した場合は、入力は終了したとしてコントローラ３０は処理をステップＦ１０４に進める。
【００３４】ステップＦ１０４では旋律解析部３８に、音律の変化量を求めさせ、それを検索情報として検索センタ３送信する情報を生成する処理を実行させる。即ち図５下段に示すように、旋律の楽律の中で最大の音律と最小の音律を何分割かし、旋律の楽律を数値化する。さらに、求めた数値において楽律間の変化量を求める。例えば入力された旋律の楽譜を図６に示すが、この楽譜においてＣ（ド）の音を「１」としてＣ＃、Ｄ、Ｄ＃・・・という半音毎に２，３，４・・・という数値を設定し、かつその各音の変化量を図６下段に示す。この図６からわかるように旋律を構成している楽音の音律の変化量を求め、この変化量の情報「０，３，０，４，０，−２」を、検索情報とする。つまり相対的な音程変化の情報である。
【００３５】このように検索情報を生成したら、ステップＦ１０５でその検索情報を検索センタ３に送信する。即ちメモリ２９上で構築した検索情報を送受信部３７に送り、所定の送信フォーマット形態としてネットワーク２に出力する。　　　　　　　　　　　　　
【００３６】一方検索センタ３側では、ステップＦ２０１で検索情報の受信が行われることに応じて、ステップＦ２０２で検索処理を行う。本例においては、検索データベース５には各楽曲の曲名とともに、その曲の旋律の変化量情報が格納されている。従ってサーバ４は受信した検索情報と検索データベース５内の変化量情報を照合していき、旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する。
【００３７】そのような検索で１又は複数の曲名が検索結果として検出されたら、ステップＦ２０３で検索結果データとして検索端末１に送信する情報を生成する。例えば曲名とともに、検索データベース５内に記憶されている演奏者や作詞作曲者などの書誌的な情報を盛り込んだり、さらに曲名に基づいて楽曲データベース６から音楽情報（実際に音として聞けるオーディオデータ）を読み出して、検索結果の送信情報とする。そしてステップＦ２０４でサーバ４は検索結果としての各種データの送信を行う。
【００３８】このようにしてサーバ４から送信されてきた情報は、ステップＦ１０６の送受信部３７での受信処理により検索端末１に取り込まれ、メモリ２９に格納される。ステップＦ１０６として受信処理を終えたら、コントローラ３０はステップＦ１０７で検索結果の提示及び確認処理を行う。即ち、検索センタ３から送信されてきた１又は複数の曲名を表示部１２に表示させてユーザーに提示する。」
　
　以上の引用例１の記載によれば、引用例１には以下の事項が開示されていると認められる。
　
（ａ） 引用例１の上記（イ）の「検索センタ３は、検索端末１から送信される検索情報に基づいて、検索動作を行い、検索端末１のユーザーが求める楽曲の曲名等を検索する。そしてその検索結果を検索端末１に送信し、検索端末１がユーザーに提示する。検索センタ３は、検索動作のために、検索処理やネットワーク送受信処理を行うサーバ４と、検索動作対象となる検索データベース５、楽曲データベース６を備える。検索データベース５は、多数の楽曲について、その曲名、演奏者名、作詞作曲者名などの書誌的情報とともに、その楽曲の旋律に関する情報が格納されている。またさらに楽曲のリズム情報や、歌詞、さらにはその楽曲の付属情報を格納してもよい。楽曲の付属情報とは、例えばその楽曲が使用されているテレビ番組やコマーシャル名などの情報などが考えられる。（中略）楽曲データベースは、検索データベース５に格納されている各曲名に対応して、実際の楽曲としての音楽情報（オーディオデータ）が格納されている。」（段落００１０〜００１２）という記載から、引用例１には、検索情報に基づいて（データベースに）格納された情報を検索し、検索結果を提示する検索方法が開示されていると認められる。
　
（ｂ）引用例１の上記（イ）の「検索センタ３は、検索動作のために、検索処理やネットワーク送受信処理を行うサーバ４と、検索動作対象となる検索データベース５、楽曲データベース６を備える。検索データベース５は、多数の楽曲について、その曲名、演奏者名、作詞作曲者名などの書誌的情報とともに、その楽曲の旋律に関する情報が格納されている。またさらに楽曲のリズム情報や、歌詞、さらにはその楽曲の付属情報を格納してもよい。楽曲の付属情報とは、例えばその楽曲が使用されているテレビ番組やコマーシャル名などの情報などが考えられる。」という記載から、引用例１に記載の検索方法では、楽曲の曲名および楽曲に関連する書誌的情報及び付属情報が検索データベースに格納されていると認められる。
　
（ｃ）引用例１の上記（イ）の「検索端末１から送信される検索情報は、本例の場合、基本的には検索したい楽曲の旋律の一部又は全部に関する情報であり、特にこの第１の実施の形態の例では旋律の楽律の変化量の情報となる。従って、検索データベース５においては旋律に関する情報として、旋律の楽律の変化量の情報が格納されていることで、サーバ４は検索情報に基づいた曲名検索が可能となる。」という記載から、引用例１に記載の検索方法では、楽曲の旋律の楽律の変化量の情報が検索データベースに格納されているものと認められる。
　
（ｄ）引用例１の上記（オ）の「検索の際には、ユーザーはまず検索したい曲の旋律の一部を口笛やハミング等でマイクロホン２５から入力する。これに応じて検索端末１ではステップＦ１０１の旋律入力処理が行われる。」（段落００２２）という記載及び図４から、引用例１に記載の検索方法は、検索したい曲の旋律の一部を入力する旋律入力処理ステップを備えているものと認められる。
　
（ｅ）引用例１の上記（エ）の「旋律解析部３８は、ユーザーが音声入力した旋律に対して各楽音の音律を解析する処理や、解析した音律から検索情報としての音律の変化量の情報を生成する処理などを行う。」（段落００２１）という記載、引用例１の上記（オ）の「ステップＦ１０４では旋律解析部３８に、音律の変化量を求めさせ、それを検索情報として検索センタ３送信する情報を生成する処理を実行させる。即ち図５下段に示すように、旋律の楽律の中で最大の音律と最小の音律を何分割かし、旋律の楽律を数値化する。さらに、求めた数値において楽律間の変化量を求める。例えば入力された旋律の楽譜を図６に示すが、この楽譜においてＣ（ド）の音を「１」としてＣ＃、Ｄ、Ｄ＃・・・という半音毎に２，３，４・・・という数値を設定し、かつその各音の変化量を図６下段に示す。この図６からわかるように旋律を構成している楽音の音律の変化量を求め、この変化量の情報「０，３，０，４，０，−２」を、検索情報とする。つまり相対的な音程変化の情報である。」（段落００３４）という記載、及び図３ないし図６から、引用例１に記載の検索方法は、入力された曲の旋律から曲の旋律の相対的な変化量を表す楽音の音律の変化量を検索情報として求める処理ステップを備えているものと認められる。
　
（ｆ）引用例１の上記（オ）の「検索情報を生成したら、ステップＦ１０５でその検索情報を検索センタ３に送信する。（中略）検索センタ３側では、ステップＦ２０１で検索情報の受信が行われることに応じて、ステップＦ２０２で検索処理を行う。本例においては、検索データベース５には各楽曲の曲名とともに、その曲の旋律の変化量情報が格納されている。従ってサーバ４は受信した検索情報と検索データベース５内の変化量情報を照合していき、旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する。」（段落００３５〜００３６）という記載及び図４から、引用例１に記載の検索方法は、検索データベースに格納されている曲の旋律の変化量情報と、楽音の音律の変化量を検索情報として求める処理ステップで生成した楽音の音律の変化量とを照合する処理ステップを備えているものと認められる。
　
（ｇ）引用例１の上記（オ）の「検索センタ３側では、ステップＦ２０１で検索情報の受信が行われることに応じて、ステップＦ２０２で検索処理を行う。本例においては、検索データベース５には各楽曲の曲名とともに、その曲の旋律の変化量情報が格納されている。従ってサーバ４は受信した検索情報と検索データベース５内の変化量情報を照合していき、旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する。」（段落００３６）という記載及び図４から、引用例１に記載の検索方法は、曲の旋律の変化量を照合する処理ステップにおける照合結果に基づいて、検索データベースに格納された楽曲から、旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する処理ステップを備えているものと認められる。
　
（ｈ）引用例１の上記（オ）の「ステップＦ２０４でサーバ４は検索結果としての各種データの送信を行う。（中略）サーバ４から送信されてきた情報は、ステップＦ１０６の送受信部３７での受信処理により検索端末１に取り込まれ、メモリ２９に格納される。ステップＦ１０６として受信処理を終えたら、コントローラ３０はステップＦ１０７で検索結果の提示及び確認処理を行う。即ち、検索センタ３から送信されてきた１又は複数の曲名を表示部１２に表示させてユーザーに提示する。」（段落００３７〜００３８）という記載から、引用例１に記載の検索方法は、検索する処理ステップにおける検索結果に基づいて検索結果を提示する処理ステップを備えているものと認められる。
　
　以上の引用例の記載によれば、引用例１には下記の発明（以下、「引用例１発明」という。）が開示されていると認められる。
　
「検索情報に基づいて格納された情報を検索し、検索結果を提示する検索方法であって、
楽曲の曲名および楽曲に関連する書誌的情報及び付属情報が検索データベースに格納されており、
楽曲の旋律の楽律の変化量の情報が検索データベースに格納されており、
検索したい曲の旋律の一部を入力する旋律入力処理ステップと、
入力された曲の旋律から曲の旋律の相対的な変化量を表す楽音の音律の変化量を検索情報として求める処理ステップと、
検索データベースに格納されている曲の旋律の変化量情報（楽曲の旋律の楽律の変化量の情報）と、検索情報を求める処理ステップで生成した楽音の音律の変化量とを照合する処理ステップと、
照合する処理ステップにおける照合結果に基づいて、検索データベースに格納された楽曲から、旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する処理ステップと、
検索する処理ステップにおける検索結果に基づいて検索結果を提示する処理ステップと
を備えた検索方法。」
　
（３）対比
　そこで、本願補正発明と引用例１発明とを対比する。
　
（Ａ）引用例１発明の「検索情報に基づいて格納された情報を検索し」、「検索方法」は、本願補正発明の「検索鍵を用いて蓄積された情報を検索し」、「検索サービス」に、それぞれ相当するから、引用例１発明も、本願補正発明と同様に、検索鍵を用いて蓄積された情報を検索し、検索結果を提示する検索サービスを提供しているといえる。
　ただし、本願補正発明が、検索サービスの配信方法であるのに対し、引用例１発明では、検索サービスを配信していない点で、一応相違している。
　
（Ｂ）引用例１発明の「楽曲の曲名」、「楽曲に関連する書誌的情報及び付属情報」、「格納」は、本願補正発明の「時系列データの名称」、「時系列データに関連する情報」、「蓄積」に、それぞれ相当することから、引用例１発明も、本願補正発明と同様に、時系列データの名称および該時系列データに関連する情報を蓄積しているといえる。
　ただし、本願補正発明では、時系列データの名称および該時系列データに関連する情報を蓄積する情報蓄積過程を備えているのに対して、引用例１発明では、時系列データの名称および該時系列データに関連する情報が蓄積されているものの、蓄積する情報蓄積過程が開示されていない点で一応相違している。
　
（Ｃ）楽曲の旋律の楽律の変化量の情報は、楽曲の特徴を表す時系列の特徴量に他ならないから、引用例１発明の「楽曲の旋律の楽律の変化量の情報」、「格納」は、本願補正発明の「時系列データの一部または全部の特徴時系列」、「蓄積」に、それぞれ相当する。
　よって、引用例１発明も、本願補正発明と同様に、時系列データの一部または全部の特徴時系列を蓄積しているといえる。
　ただし、本願補正発明では、時系列データの一部または全部の特徴時系列を蓄積する時系列信号特徴蓄積過程を備えているのに対して、引用例１発明では、時系列データの一部または全部の特徴時系列を蓄積する時系列信号特徴蓄積過程が蓄積されているものの、蓄積する時系列信号特徴蓄積過程が開示されていない点で一応相違している。
　
（Ｄ）引用例１発明の「検索したい曲の旋律の一部」、「入力する」は、本願補正発明の「検索鍵」、「受理する」に、それぞれ相当するから、引用例１発明も、本願補正発明と同様に、検索鍵を受理する検索鍵時系列信号入力過程を備えているといえる。
　
（Ｅ）引用例１発明の「入力された曲の旋律」、「曲の旋律の相対的な変化量を表す楽音の音律の変化量」、「検索情報として求める」は、本願補正発明の「受理された前記検索鍵」、「検索鍵を表現する特徴」、「導く」に、それぞれ相当するから、引用例１発明も、本願補正発明と同様に、受理された前記検索鍵から該検索鍵を表現する特徴を導く特徴計算過程を備えているといえる。
　
（Ｆ）引用例１発明の「検索データベースに格納されている曲の旋律の変化量情報（楽曲の旋律の楽律の変化量の情報）」、「検索情報を求める処理ステップで生成した楽音の音律の変化量」は、本願補正発明の「特徴」、「前記特徴計算過程にて導かれた前記検索鍵を表現する特徴」に、それぞれ相当するから、引用例１発明も、本願補正発明と同様に、時系列信号特徴蓄積過程で蓄積された特徴時系列上の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、照合する過程を備えているといえる。
　ただし、本願補正発明では、時系列信号特徴蓄積過程で蓄積された特徴時系列上の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、照合する際に、時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し、注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合しているのに対して、引用例１発明では、注目窓を設定したり、注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合していることは開示されていない点で一応相違している。
　
（Ｇ）引用例１発明の「照合する処理ステップにおける照合結果」、「検索データベースに格納された楽曲」、「旋律の変化量が一致する楽曲、もしくは旋律の変化量が類似する楽曲を検索する」は、本願補正発明の「前記特徴照合過程における照合結果」、「蓄積された情報」、「出力すべき情報を選択する」に、それぞれ相当するから、引用例１発明も、本願補正発明と同様に、前記特徴照合過程における照合結果に基づいて前記情報蓄積過程で蓄積された情報の中から出力すべき情報を選択する検索情報選択過程を備えているといえる。
　
（Ｈ）引用例１発明の「検索する処理ステップにおける検索結果」は、本願補正発明の「検索情報選択過程における検索情報選択結果」に相当するから、引用例１発明も、本願補正発明と同様に、前記検索情報選択過程における検索情報選択結果に基づいて検索結果を提示する情報提示過程を備えているといえる。
　
　したがって、両者は、
「検索鍵を用いて蓄積された情報を検索し、検索結果を提示する検索サービスであって、
時系列データの名称および該時系列データに関連する情報を蓄積しており、
時系列データの一部または全部の特徴時系列を蓄積しており、
検索鍵を受理する検索鍵時系列信号入力過程と、
受理された前記検索鍵から該検索鍵を表現する特徴を導く特徴計算過程と、
時系列信号特徴蓄積過程で蓄積された特徴時系列上の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、照合する過程と、
前記特徴照合過程における照合結果に基づいて前記情報蓄積過程で蓄積された情報の中から出力すべき情報を選択する検索情報選択過程と、
前記検索情報選択過程における検索情報選択結果に基づいて検索結果を提示する情報提示過程と
を備えた検索サービス」
の点で一致し、以下の点で相違している。
　
（相違点１）本願補正発明が、検索サービスの配信方法であるのに対し、引用例１発明では、検索サービスを配信していない点。
　
（相違点２）本願補正発明では、時系列データの名称および該時系列データに関連する情報を蓄積する情報蓄積過程や、時系列データの一部または全部の特徴時系列を蓄積する時系列信号特徴蓄積過程を備えているのに対して、引用例１発明では、時系列データの名称および該時系列データに関連する情報や、時系列データの一部または全部の特徴時系列をが蓄積されているものの、時系列データの名称および該時系列データに関連する情報を蓄積する時系列信号特徴蓄積過程や、時系列データの一部または全部の特徴時系列を蓄積する情報蓄積過程が開示されていない点。
　
（相違点３）本願補正発明では、時系列信号特徴蓄積過程で蓄積された特徴時系列上の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、照合する際に、時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し、注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合しているのに対して、引用例１発明では、注目窓を設定したり、注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合していることは開示されていない点。
　
（４）判断
　
（相違点１について）
　情報検索装置の技術分野において、インターネット接続機能を持つ検索端末向けに、インターネットを介した検索サービスを提供する検索用ウェブページを配信する検索サイト技術は、本願の優先日前に周知である（例えば、根本佳子、ｉモードとｃｄｍａＯｎｅでインターネット−メールにウェブに！携帯電話を賢く使う−、日経ＰＣ２１、第４巻、第９号、日経ＢＰ社、１９９９年９月１日、ｐｐ．２００−２０４．や、ｉモードの仕組み−世界も注目するビジネスモデル−、ｍｏｂｉｌｅ　ｍｅｄｉａ　ｍａｇａｚｉｎｅ、第８巻、第２号、株式会社シーメディア、２０００年１月１３日、ｐｐ．１２−１９．などには、ｉモードのようなインターネット接続機能を持つ携帯電話向けの検索サイトについて記載されている。）。
　したがって、引用例１発明において、当該周知技術を採用して、検索サービスを配信する検索サイトの構成とすることにより、検索サービスの配信方法とすることは、当業者が容易に想到し得たものである。
　
（相違点２について）
　一般に、情報がデータベース等に蓄積されているためには、準備段階として、当該情報を蓄積する処理過程が必要となることは、明らかであるから、引用例１発明において、準備段階として、時系列データの名称および該時系列データに関連する情報を蓄積する時系列信号特徴蓄積過程や、時系列データの一部または全部の特徴時系列を蓄積する情報蓄積過程を設ける構成とすることは、当業者が容易に想到し得たものである。
　
（相違点３について）
　画像・音響時系列信号の検索技術の分野において、スペクトルや波形等の時系列の特徴量を抽出し、検索対象の時系列の特徴量に時間窓（注目窓に相当）を設定して、時間窓内の時系列の特徴量と検索したい時系列の特徴量とをずらし照合する技術は、本願の優先日前に周知であり（例えば、柏野　邦夫，マルチモーダルアクティブ探索を用いた画像・音響時系列の高速探索，電子情報通信学会技術研究報告，日本，社団法人　電子情報通信学会，１９９８年９月１７日，第９８巻　第２７４号，ｐｐ．５１〜５８．、あるいは、柏野　邦夫，マルチモーダルアクティブ探索を用いた画像・音響時系列の高速探索，電子情報通信学会技術研究報告，日本，社団法人　電子情報通信学会，１９９８年９月１７日，第９８巻　第２７４号，ｐｐ．５１〜５８．を参照されたい。）、引用例１発明の特徴量も、楽曲のスペクトルに基づいて生成した特徴時系列に他ならないから、引用例１発明において、当該周知技術を採用して、時系列信号特徴蓄積過程で蓄積された特徴時系列上の特徴と、前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、照合する際に、時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し、注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合する構成とすることは、当業者が容易に想到し得たものである。
　
　また、本願補正発明の効果についてみても、上記構成の採用に伴って、当然に予測される程度のものに過ぎず、格別顕著なものがあるとは認められない。
　
　したがって、本願補正発明は、引用例１に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１６年１０月１８日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１６年７月２０日付の手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「検索鍵を用いて蓄積された情報を検索し、検索結果を提示する検索サービスの配信方法において、
　時系列データの名称および該時系列データに関連する情報を蓄積する情報蓄積過程と、
　前記時系列データの一部または全部の特徴時系列を蓄積する時系列信号特徴蓄積過程と、
　前記検索鍵を受理する検索鍵時系列信号入力過程と、
　受理された前記検索鍵から該検索鍵を表現する特徴を導く特徴計算過程と、
　注目窓を設定し、該注目窓内の特徴と、特徴計算過程にて導かれた特徴の時系列とを、注目窓を移動させながら照合する特徴照合過程と、
　前記特徴照合過程における照合結果に基づいて前記情報蓄積過程で蓄積された情報の中から出力すべき情報を選択する検索情報選択過程と、
　前記検索情報選択過程における検索情報選択結果に基づいて検索結果を提示する情報提示過程と
　を備えることを特徴とする検索サービスの配信方法。」
　
　（１）引用例
　原査定の拒絶の理由に引用された引用例１の記載事項は、前記「２．（２）」に記載したとおりである。　
　
　（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、請求項１の発明特定事項である「特徴照合過程」について、「注目窓を設定し」を「前記時系列信号特徴蓄積過程で蓄積された特徴時系列上に注目窓を設定し」とする技術的限定を削除し、「該注目窓内の特徴と、特徴計算過程にて導かれた特徴の時系列とを、注目窓を移動させながら照合する」を「該注目窓内の特徴と前記特徴計算過程にて導かれた前記検索鍵を表現する特徴とを、注目窓をずらしながら照合する」とする技術的限定を削除したものである。
　そうすると、本願発明に技術的限定を付加した本願補正発明が、前記２．（４）に記載したとおり、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願補正発明から技術的限定を取り除いた本願発明も同様の理由により、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。　
　
　（３）むすび
　以上のとおりであるから、本願発明は、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について特に検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。