【事件の表示】
　特願２００２−５６３６７７「マルチメディア・メッセージ方法およびシステム」拒絶査定不服審判事件〔平成１４年　８月１５日国際公開、ＷＯ０２／６３８４９、平成１６年１１月１１日国内公表、特表２００４−５３４４１９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２００２年２月８日（パリ条約による優先権主張外国庁受理２００１年２月８日、フィンランド共和国）を国際出願日とする出願であって、平成１８年８月１４日付で手続補正がなされたが、同年９月１５日付で拒絶査定がされ、これに対し、同年１２月２５日に拒絶査定不服審判がなされ、平成１９年１月１８日付で手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成１９年１月１８日付の手続補正を却下する。
　
［理由］
１．補正後の本願発明
　上記手続補正は、平成１８年８月１４日付手続補正書の特許請求の範囲の請求項１に記載された、
　「無線通信におけるマルチメディア・メッセージを受信するための方法であって、
　マルチメディア・メッセージを受信するステップと、
　前記マルチメディア・メッセージから、ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離するステップと、
　前記セッション記述ファイルにより記述された蓄積されているストリーミング可能なメディア構成要素を検索するために、前記セッション記述ファイルによりストリーミング・セッションをスタートするステップと、
を含むことを特徴とする方法。」
という発明を、
　「無線通信におけるマルチメディア・メッセージを受信するための方法であって、
　マルチメディア・メッセージを受信するステップと、
　前記マルチメディア・メッセージから、ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離するステップと、
　前記セッション記述ファイルにより記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記セッション記述ファイルを用いてストリーミング・セッションをスタートするステップと、
を含むことを特徴とする方法。」
という発明（以下、「補正後の発明」という）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１に記載された「ストリーミング・セッションをスタートするステップ」が、「セッション記述ファイルにより記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記セッション記述ファイルを用いて」なされるものであると限定し、特許請求の範囲を減縮するものであるから、特許法第１７条の２第３項（新規事項）及び第４項第２号（補正の目的）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際、独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．補正後の本願発明」の項で認定したとおりである。
　
（２）引用発明及び周知技術
Ａ．原審の拒絶理由に引用された特開平１０−４０１８８号公報（以下、「引用例１」という。）には図面とともに以下の事項（イ）〜（ホ）が記載されている。
　
　イ．「【０００１】
【発明の属する技術分野】この発明はマルチメディアメール送信および受信装置に関し、特に、テキスト情報と一緒に、静止画、音声、動画像等のメディア情報を、電子メールとして送信できるマルチメディアメール送信および受信装置に関する。」（２頁２欄１２行〜１７行）
　
　ロ．「【００１６】図６は、メールの送信および受信システムの概要を示すブロック図であり、５１は送信側のクライアント端末、５２は送信側のメールサーバ、５４は受信側のメールサーバ、５６は受信側のクライアント端末である。メールサーバ５２と５４との間は、ネットワーク５３で接続されている。５５はＷＥＢサーバ、ＶＯＤサーバ等の音声、動画像等のメディア情報を格納するメディア情報格納用サーバである。
…（中略）…
【００２０】次に、受信側のメールサーバ５４、メディア情報格納用サーバ５５およびクライアント端末５６の動作を説明する。送信されたメール中に、テキストとメディア情報を分類するプログラムを起動する情報が含まれている場合には、受信側のメールサーバ５４は音声と動画像を別ファイルとして、メディア情報格納サーバ５５に格納する。該メディア情報格納サーバ５５として、ＷＥＢサーバや、ＶＯＤサーバを用いることができる。また、該受信側のメールサーバ５４は、受信したメールの格納場所、ユーザ情報、そのユーザのみに許可される再生および削除コマンドの付加、および音声、動画像のアイコンの作成を行う。」（４頁５欄３６行〜６欄４３行）
　
　ハ．「【００２２】次に、受信側のクライアント端末５６の動作を説明する。ユーザがメール受信のためにクライアント端末５６で前記システムを起動すると、送信動作時と同様に、図２のユーザ認証画面が表示され、該認証が成立すると、図３の画面が表示される。該画面には、インジケータ３１、送信日時３２、送信者３３、表題３４等の情報を含む受信メールの一覧が表示される。ユーザが該一覧から所望の受信メールを選択すると、受信側メールサーバ５４から、音声、動画像等を分類した後のメール本体が、例えば図９のように表示される。
【００２３】図９は、受信側メールサーバ５４で動画像検索を行って、自動的にインデックスとなるアイコンを作成した時の表示例であり、該インデックスとしての複数の動画像のアイコン７１ａ〜７１ｃが画面上に一覧表示される。７２はテキスト情報、７３は音声アイコンを示している。
【００２４】この複数のアイコン表示により、ユーザはテキストおよび動画像データの内容把握が容易になる。また、送信者のより細かなニュアンスを、メールを受信した当初に把握することができるようになる。また、ユーザがアイコンで表示された動画像および音声を詳細に見たい場合には、所望のアイコンを指定することによって、動画像データの本当に再生したい部分からの再生が可能になる。このため、動画像の再生の際に、無駄な動画像をクライアント端末５６に転送する必要がなくなり、転送するデータ量を最小限に止めることができるようになる。この結果、受信側メールサーバ５４と受信側クライアント端末５６とを結ぶネットワークに大きな負荷をかけることなくなる。」（５頁７欄７行〜３５行）
　
　ニ．「【００２７】図１０は、前記したメールの受信側の装置の動作を示すフローチャートである。ステップＳ１１では、受信側メールサーバ５４は、受信メールにメディア情報を分類するプログラムの起動情報があるか否かの判断がなされる。この判断が肯定の場合には、ステップＳ１２に進んで、受信したメールデータの中から音声と動画像とを分類し、メディア情報格納サーバ５５に格納する。また、受信側メールサーバ５４は、格納場所、ユーザ情報の付加再生、削除コマンドの付加およびアイコンの作成とリンク付けを行う。
【００２８】ステップＳ１３では、ユーザによってメールの再生要求があるか否かの判断がなされ、この判断が肯定の場合にはステップＳ１４に進んで、音声、動画像アイコンを含むメール本体を、クライアント端末へ転送し表示する。ステップＳ１５では、ユーザによって、さらに、音声、動画像の再生の要求があるか否かの判断がなされる。すなわち、ユーザが動画像のアイコンを指定したか否かの判断がなされる。この判断が肯定の場合には、ステップＳ１６に進んで、該アイコンに対応する音声、動画像の再生が実行される。」（５頁７欄４９行〜８欄１８行）
　
　ホ．「【００３０】前記ステップＳ１６のデータ再生の方法としては、例えば、帯域確保型のネットワークプロトコルであるＲＳＶＰプロトコルを用いて動画像や音声を即時リアルタイムで再生することができる。他のデータ再生方法としては、ＴＣＰ／ＩＰ上でデータ転送を行い、図１１のように、時刻ｔ1 でユーザが動画像データの再生を指示したとした場合、図１の再生用バッファ８にある程度のデータが蓄積された時点ｔ2 から再生を開始することにより、確実な帯域確保が困難な状況でも、簡易的なリアルタイム再生を実現することができる。この再生方式によれば、受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく、データを転送しながら再生を行うことができ、リアルタイム再生を実現することができる。なお、従来は、前記再生用バッファ８に全部のデータが蓄積された時刻ｔ3 から再生を開始していたので、本発明の再生方式によれば、（ｔ3 −ｔ2 ）時間の短縮をすることができる。」（５頁８欄２７行〜４３行）
　
　上記摘記事項イ．には、「この発明はマルチメディアメール送信および受信装置に関し」と記載され、また上記摘記事項ニ．、ホ．および図１０には、メールの受信側の装置の動作が複数のステップとして記載されている。送信装置と受信装置との間ではマルチメディアメールの通信がなされていることは明らかであり、上記摘記事項ニ．、ホ．および図１０の記載はマルチメディアメールを受信するための方法を示していることも明らかであるから、引用例１には、マルチメディアメールを送信および受信する装置間の通信における、マルチメディアメールを受信するための方法が開示されているといえる。
　上記摘記事項ニ．の【００２７】には、「ステップＳ１１では、受信側メールサーバ５４は、受信メールにメディア情報を分類するプログラムの起動情報があるか否かの判断がなされる。」と記載されているが、この記載における動作において、受信側メールサーバ５４がメールを受信していることは明らかである。
　上記摘記事項ロ．の「該受信側のメールサーバ５４は、受信したメールの格納場所、ユーザ情報、そのユーザのみに許可される再生および削除コマンドの付加、および音声、動画像のアイコンの作成を行う。」という記載、上記摘記事項ハ．の【００２３】の「図９は、受信側メールサーバ５４で動画像検索を行って、自動的にインデックスとなるアイコンを作成した時の表示例であり、該インデックスとしての複数の動画像のアイコン７１ａ〜７１ｃが画面上に一覧表示される。７２はテキスト情報、７３は音声アイコンを示している。」という記載から、マルチメディアメールから、音声、動画像のインデックスとなるアイコンが作成されることがわかるが、このアイコンは、上記摘記事項ニ．の【００２８】の「ステップＳ１５では、ユーザによって、さらに、音声、動画像の再生の要求があるか否かの判断がなされる。すなわち、ユーザが動画像のアイコンを指定したか否かの判断がなされる。この判断が肯定の場合には、ステップＳ１６に進んで、該アイコンに対応する音声、動画像の再生が実行される。」という記載によれば、ユーザがアイコンを指定することにより、対応する音声、動画像の再生が実行されるようにされているものであることもわかる。この音声、動画像は、上記摘記事項ロ．に「音声と動画像を別ファイルとして、メディア情報格納サーバ５５に格納する。」と記載されているように、個別のファイルとして格納されているから、指定されて再生する際には、メディア情報格納サーバ５５において探し出す動作、すなわち検索が行われることも技術常識から明らかである。
　さらに、上記摘記事項ホ．には、「他のデータ再生方法としては、ＴＣＰ／ＩＰ上でデータ転送を行い、図１１のように、時刻ｔ1 でユーザが動画像データの再生を指示したとした場合、図１の再生用バッファ８にある程度のデータが蓄積された時点ｔ2 から再生を開始することにより、確実な帯域確保が困難な状況でも、簡易的なリアルタイム再生を実現することができる。この再生方式によれば、受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく、データを転送しながら再生を行うことができ、リアルタイム再生を実現することができる。」と記載されているが、「受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく、データを転送しながら再生を行うことができ、リアルタイム再生を実現する」ということは、ストリーミング再生を意味していることは技術常識から明らかである。このストリーミング再生の対象となるのは、音声、動画像などであり、これらはストリーミング可能なメディア構成要素といえる。また、「セッション」とは一般に「一連の通信」の意味であることは技術常識であるが、引用例１においてもアイコンを指定することでストリーミングに係る一連の通信（セッション）がスタートされるということができるので、セッションをスタートするために必要な情報も当然にアイコンに関連づけて作成されており、当該情報中にはアイコンに対応付けられた音声、動画像ファイル（メディア構成要素）が記述されていて、セッションをスタートする際に用いられることも明らかである。
　
　したがって、これらの記載事項によると、引用例１には以下の発明（以下「引用発明１」という。）が記載されていると認められる。
　
「通信におけるマルチメディアメールを受信するための方法であって、
　マルチメディアメールを受信するステップと、
　前記マルチメディアメールから、ストリーミング・セッションをスタートするために必要な情報を作成するステップと、
　前記必要な情報に記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記必要な情報を用いてストリーミング・セッションをスタートするステップと、
を含むことを特徴とする方法。」
　
　Ｂ．原審の拒絶理由に引用された、奥村誠司外，「MPEG-4 over RTP配信システムとQoS制御方式」，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ　２０００）シンポジウム論文集，第２０００巻，第７号，社団法人情報処理学会，第４３３−４３８頁，2000年6月28日（以下、「引用例２」という。）には図面とともに以下の事項（ヘ）が記載されている。
　
　ヘ．「ネットワーク再生では，コンテンツの詳細データや配信サーバ情報をSDP(Session Description Protocol(RFC2327))で記述したMVX(Movie Video eXtention)ファイル(独自)を配信サーバ/Webサーバ/ローカルホストから得る．クライアントはMVXに記述されているコンテンツの詳細データや配信サーバ情報を解析し，配信サーバとセッション確立とコンテンツデータの受信準備を行う．リクエストを受けた配信サーバは，そのコンテンツデータのMP4ファイルをロードして，ビデオデータ(MPEG-4)やオーディオデータ(G.723.1，MP3など)をRTPパケットに乗せて送信する．クライアントはそのRTPパケットを受信し，再生(バッファリング，デコード)を行う．」
　
　上記摘記事項ヘ．において、まず、「RTP」とは「Real-time Transport Protocol」の略語であり、ストリーミング再生のためのプロトコルであることは技術常識である。そうすると、上記摘記事項ヘ．には、動画（ビデオデータ）や音声（オーディオデータ）のようなコンテンツをネットワーク上で通信し、再生する場合において、コンテンツの詳細データや配信サーバ情報をSDP（セッション記述プロトコル）で記述した、元のコンテンツとは分離したファイルの形式でクライアントに送り、クライアントはSDPで記述したファイルを用いて、そこに記述された情報によってストリーミング・セッションをスタートすることが開示されていると認められる。すなわち、ストリーミング・セッションをスタートするために、元のコンテンツから作成して分離したセッション記述ファイルを用いることが開示されているといえるから、引用例２には以下の発明（以下「引用発明２」という。）が記載されていると認められる。
　
「動画や音声のようなコンテンツをネットワーク上で通信し、再生する場合において、ストリーミング・セッションをスタートするために、元のコンテンツから作成して分離したセッション記述ファイルを用いる発明」
　
　Ｃ．また、J. Sevanto, Multimedia Messaging Service for GPRS and UMTS, Wireless Communications and Networking Conference, 1999. WCNC.1999 IEEE, Vol.3, pp.1422-1426, 1999年9月24日（以下、「周知例１」という。）には図面とともに以下の事項（ト）が記載されている。また、特開２０００−３２４１７４号（以下、「周知例２」という。）には図面とともに以下の事項（チ）が記載されている。
　
　ト．「Multimedia Messaging Service allows mobile subscribers to exchange arbitrary types of information in a store-and ?forward manner. Multimedia messages may consist of text, images, audio or video clips, or any combination of these.」（周知例１の１４２２頁左欄１２行〜１７行）
（訳：マルチメディア・メッセージ・サービスは、モバイル加入者が任意のタイプの情報を蓄積転送方法で交換することを可能にする。マルチメディア・メッセージは、テキスト、イメージ、オーディオ、ビデオクリップ、あるいはこれらの任意の組合せから成る。）
　
　チ．「【０００３】ＭＭＳすなわちマルチメディア・メッセージ・サービスは、１つの通信装置から別の通信装置へ、マルチメディア関連情報を含むメッセージの転送を行なうために提案された方法である。“マルチメディア関連”情報という言葉は、提示可能なオブジェクトを表す実際のペイロード・データと、表示装置にペイロード・データの処理方法を教示する制御情報の双方を意味する。前記提案によれば、ＭＭＳは、ＧＰＲＳすなわち一般パケット無線サービス（General Packet Radio Service）のようなパケット交換型セルラー無線ネットワークの端末装置相互間で前記のようなメッセージを伝えるために適用可能であり、ＳＭＳ（ショート・メッセージ・サービス）テキスト・メッセージのような記憶−転送（store-and-forward）方式のＵＭＴＳ（ユニバーサル移動通信システム）のパケット交換型の部分がＧＳＭ（移動通信用広域システム）などの第２世代デジタルセルラーネットワークで伝えられる。」（周知例２の３頁４欄３５行〜４頁５欄１行）
　
　上記摘記事項ト．、チ．に開示されているように、「無線通信におけるマルチメディア・メッセージ・サービス」は周知技術である。
　
（３）対比・判断
　補正後の発明と引用発明１とを対比する。
　ａ．引用発明１の「マルチメディアメール」は、テキスト、静止画、音声、動画を含み、宛先のユーザに送られる「マルチメディア情報」である点で、補正後の発明の「マルチメディア・メッセージ」と一致している。
　ｂ．補正後の発明は、「前記マルチメディア・メッセージから、ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離するステップと、前記セッション記述ファイルにより記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記セッション記述ファイルを用いてストリーミング・セッションをスタートするステップ」と記載されている。
　ここで、まず、マルチメディア・メッセージから分離されるセッション記述ファイルは「ストリーミング・セッションをスタートするために必要な情報」を含むとされている。
　一方、「前記セッション記述ファイルにより記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記セッション記述ファイルを用いてストリーミング・セッションをスタートするステップ」と記載されているが、ストリーミング・セッションをスタートする際に行われる動作（例えばメディア構成要素の検索など）は、実質的にはセッション記述ファイル中の「ストリーミング・セッションをスタートするために必要な情報」という概念に属する情報を用いてなされ、そのための記述も当該「必要な情報」においてなされていると解釈できる。
　そうすると、引用発明１の「必要な情報」は、実質的には補正後の発明の「セッション記述ファイル」と一致しているものの、そのデータの形式において相違している。
　ｃ．補正後の発明は、「前記マルチメディア・メッセージから、ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離する」と記載されているが、「分離する」とは、作成したものを分離するようしていることは当然であるから、マルチメディア情報から必要な情報ないしセッション記述ファイルを作成している点で、引用発明１とは一致している。
　
　したがって、補正後の発明と引用発明１は、以下の点で一致ないし相違している。
　
（一致点）
「通信におけるマルチメディア情報を受信するための方法であって、
　マルチメディア情報を受信するステップと、
　前記マルチメディア情報から、ストリーミング・セッションをスタートするために必要な情報を作成するステップと、
　前記必要な情報に記述されて蓄積されているストリーミング可能なメディア構成要素を検索するために、前記必要な情報を用いてストリーミング・セッションをスタートするステップと、
を含むことを特徴とする方法。」
　
（相違点）
（１）補正後の発明は「無線通信におけるマルチメディア・メッセージを受信するための方法」であるのに対し、引用発明１は「通信におけるマルチメディアメールを受信するための方法」である点。
　
（２）補正後の発明は「セッション記述ファイル」を使用するものであるのに対し、引用発明１は「必要な情報」である点。
　
（３）（２）補正後の発明は、セッション記述ファイルがマルチメディア・メッセージから「分離」されるものであるのに対し、引用発明１は必要な情報がマルチメディアメールから「作成」されるものである点。
　
　上記相違点（１）について検討する。
　上記したとおり、「無線通信におけるマルチメディア・メッセージ・サービス」は周知技術である。引用発明１もマルチメディア情報の一つであるマルチメディアメールを通信するものであって、これを無線通信におけるマルチメディア・メッセージ・サービスに適用することの阻害要因も見あたらないから、引用発明１を「無線通信におけるマルチメディア・メッセージを受信するための方法」に係るものとすることは、当業者であれば適宜なし得たことである。
　
　次に上記相違点（２）、（３）について検討する。
　引用発明１と引用発明２とは、いずれもストリーミング再生を行うことに係り、技術分野が共通しているから、引用発明１に引用発明２を適用し、「必要な情報」を、これを含む「セッション記述ファイル」の形式に替え、また「セッション記述ファイル」をマルチメディア・メッセージから分離するように構成することは、当業者であれば容易に想到し得たものと認められる。
　
　以上のとおり、補正後の発明は引用発明１、引用発明２及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際、独立して特許を受けることができないものである。
　
４．結語
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１９年１月１８日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年８月１４日付手続補正書の特許請求の範囲の請求項１に記載された、「１．補正後の本願発明」で上記したとおりのものと認める。
　
２．引用発明及び周知技術
　引用発明及び周知技術は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明及び周知技術」の項で認定したとおりである。
　
３．対比・判断
　本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明１、引用発明２及び周知技術に基づいて容易に想到できたものであるから、本願発明も同様の理由により、容易に想到できたものである。
　
第４．むすび
　したがって、本願発明は、引用発明１、引用発明２及び周知技術に基づいて、当業者であれば容易に想到し得たものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。