【事件の表示】
　特願２００７−　　９２４７「マルチメディア・メッセージ方法およびシステム」拒絶査定不服審判事件〔平成１９年　８月　２日出願公開、特開２００７−１９５１８８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００２年２月８日（パリ条約による優先権主張外国庁受理２００１年２月８日、フィンランド共和国）を国際出願日とする特願２００２−５６３６７７号の一部を、平成１９年１月１８日に新たな特許出願（特願２００７−９２４７号）としたものであって、平成２２年７月１日付けで拒絶査定がなされ、これに対し、平成２２年１１月８日に拒絶査定に対する審判請求がなされたものである。
　
２．本願発明
　本願の請求項３に係る発明（以下、「本願発明」という。）は、平成２２年３月１日付け手続補正書の請求項３に記載された以下のとおりのものと認める。
　「無線通信でマルチメディア・メッセージを送信する装置の動作方法であって、
　受信ユーザ・エージェントのための第１のマルチメディア・メッセージを受信し、前記受信ユーザ・エージェントに、前記第１のマルチメディア・メッセージが使用できることを応答可能に通知することと、
　ストリーミング可能なメディア構成要素を含む前記第１のマルチメディア・メッセージを記憶することと、
　前記ストリーミング可能なメディア構成要素をセッション記述ファイルに置き換えること、ただし前記セッション記述ファイルは、前記受信ユーザ・エージェントが、ストリーミング・セッションをスタートして、前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む、前記置き換えることと、
　前記セッション記述ファイルを含む第２のマルチメディア・メッセージを前記受信ユーザ・エージェントに送信することと、
を含むことを特徴とする方法。」
　　
３．引用例発明
　原査定の拒絶の理由に引用された特開平１０−４０１８８号公報（以下、「引用例」という。）には、図面とともに以下の記載がある。
　
　イ．「【０００１】
【発明の属する技術分野】この発明はマルチメディアメール送信および受信装置に関し、特に、テキスト情報と一緒に、静止画、音声、動画像等のメディア情報を、電子メールとして送信できるマルチメディアメール送信および受信装置に関する。」
　
　ロ．「【００１６】図６は、メールの送信および受信システムの概要を示すブロック図であり、５１は送信側のクライアント端末、５２は送信側のメールサーバ、５４は受信側のメールサーバ、５６は受信側のクライアント端末である。メールサーバ５２と５４との間は、ネットワーク５３で接続されている。５５はＷＥＢサーバ、ＶＯＤサーバ等の音声、動画像等のメディア情報を格納するメディア情報格納用サーバである。
【００１７】次に、クライアント端末５１で作成されたメールの送信方法について説明する。メールサーバ５２から送出されるメールの送信時のデータの形としては、図７(a) に示されているように、テキスト、静止画と、動画像、音声等のメディア情報をメール本体中に一体にした一体型メール６１と、同図(b) に示されているように、テキスト、静止画６２ａに、動画像、音声データ６２ｂを添付ファイルとする添付型メール６２がある。該添付型メール６２においては、メールの本体中に、前記テキストと動画像、音声データ６２ｂのリンク情報が入れられている。
【００１８】これらのメールは、いずれも、送信側のメールサーバ５２から受信側のメールサーバ５４へ、一時に送信される。音声、動画像等のメディア情報を圧縮して送信する場合には、例えば圧縮符号化の国際標準方式である、ＭＰＥＧ１（ＩＳＯ／ＩＥＣ１１１７２）、Ｈ２６３（ＩＴＵ−Ｔ）、Ｈ２６１（ＩＴＵ−Ｔ）、Ｇ７２２（ＩＴＵ−Ｔ）等を用いることができる。
【００１９】図８は、前記したメールの作成処理および送信処理の概要を示したフローチャートである。ステップＳ１では、図４の画面上で、宛先、表題等をメールヘッダ部分４１に入力する動作、およびテキストをテキスト入力部４２に書込む動作が行われる。ステップＳ２では、図４のアイコンが選択されたか否かの判断がなされる。この判断が肯定の場合にはステップＳ３に進む。ステップＳ３では、カメラ２、マイク３又は作成プログラムによりメディア情報を新規に作成するか、あるいは既に格納されているメディア情報を採用するかの選択が行われる。そして、この選択に従がった方法で、メディア情報の取り込みが行われる。ステップＳ４では、取り込んだメディア情報の確認を行うか否かの判断がなされ、この判断が肯定の場合には、ステップＳ５に進んで、再生プログラムが起動され、これによって取り込んだメディア情報の確認がなされる。続いて、ステップＳ６に進んで、作成したメールを送信するか否かの判断がなされる。この判断が肯定の場合には、ステップＳ７に進んで、メールヘッダ、メールの内容が作成され、ステップＳ８では、図７の(a) 又は(b) の形態で送信される。
【００２０】次に、受信側のメールサーバ５４、メディア情報格納用サーバ５５およびクライアント端末５６の動作を説明する。送信されたメール中に、テキストとメディア情報を分類するプログラムを起動する情報が含まれている場合には、受信側のメールサーバ５４は音声と動画像を別ファイルとして、メディア情報格納サーバ５５に格納する。該メディア情報格納サーバ５５として、ＷＥＢサーバや、ＶＯＤサーバを用いることができる。また、該受信側のメールサーバ５４は、受信したメールの格納場所、ユーザ情報、そのユーザのみに許可される再生および削除コマンドの付加、および音声、動画像のアイコンの作成を行う。
【００２１】該メールサーバ５４は、音声、動画像のアイコンの作成を、次の動画像検索技術を用いて行うことができる。すなわち、例えば、氏原等の「動画像のカット点画像検出装置および方法」情報処理学会第５１回大会６Ｓ−９（１９９５）、特開平７−２６３６８１号公報、特開平５−２１６８９５号公報、あるいは特開平６−４６５６１号公報等に開示されている画像のカット点検出技術と、中島等の「類似画像検索装置および方法」画像電子学会研究会予稿（１９９４−０６）または特開平７−７７０９８号公報等に記されている類似画像検索技術を用いて、画像のカット点画像や類似画像を検出し、これを時間順にインデックス画像、すなわちアイコンとして表示することができる。
【００２２】次に、受信側のクライアント端末５６の動作を説明する。ユーザがメール受信のためにクライアント端末５６で前記システムを起動すると、送信動作時と同様に、図２のユーザ認証画面が表示され、該認証が成立すると、図３の画面が表示される。該画面には、インジケータ３１、送信日時３２、送信者３３、表題３４等の情報を含む受信メールの一覧が表示される。ユーザが該一覧から所望の受信メールを選択すると、受信側メールサーバ５４から、音声、動画像等を分類した後のメール本体が、例えば図９のように表示される。
【００２３】図９は、受信側メールサーバ５４で動画像検索を行って、自動的にインデックスとなるアイコンを作成した時の表示例であり、該インデックスとしての複数の動画像のアイコン７１ａ〜７１ｃが画面上に一覧表示される。７２はテキスト情報、７３は音声アイコンを示している。
【００２４】この複数のアイコン表示により、ユーザはテキストおよび動画像データの内容把握が容易になる。また、送信者のより細かなニュアンスを、メールを受信した当初に把握することができるようになる。また、ユーザがアイコンで表示された動画像および音声を詳細に見たい場合には、所望のアイコンを指定することによって、動画像データの本当に再生したい部分からの再生が可能になる。このため、動画像の再生の際に、無駄な動画像をクライアント端末５６に転送する必要がなくなり、転送するデータ量を最小限に止めることができるようになる。この結果、受信側メールサーバ５４と受信側クライアント端末５６とを結ぶネットワークに大きな負荷をかけることなくなる。
【００２５】次に、図９の画面で、ユーザが受信したメールを不必要なメールと判断してメールの削除を行う場合には、画面中の削除を指定することによって、このメールおよび表示されたアイコンに対応する受信側メールサーバ上にある音声、動画像データを同時に削除することができる。
【００２６】一方、ユーザがアイコンを選択することによって、さらに音声、動画像の再生を要求する場合には、クライアント端末中に搭載されている再生プログラムをさらに起動する。そうすると、再生画面が別に表示されて、再生が即時に開始される。なお、これに代えて、図中のアイコンをそのまま再生画面として、再生を即座に開始させるようにしてもよい。
【００２７】図１０は、前記したメールの受信側の装置の動作を示すフローチャートである。ステップＳ１１では、受信側メールサーバ５４は、受信メールにメディア情報を分類するプログラムの起動情報があるか否かの判断がなされる。この判断が肯定の場合には、ステップＳ１２に進んで、受信したメールデータの中から音声と動画像とを分類し、メディア情報格納サーバ５５に格納する。また、受信側メールサーバ５４は、格納場所、ユーザ情報の付加再生、削除コマンドの付加およびアイコンの作成とリンク付けを行う。
【００２８】ステップＳ１３では、ユーザによってメールの再生要求があるか否かの判断がなされ、この判断が肯定の場合にはステップＳ１４に進んで、音声、動画像アイコンを含むメール本体を、クライアント端末へ転送し表示する。ステップＳ１５では、ユーザによって、さらに、音声、動画像の再生の要求があるか否かの判断がなされる。すなわち、ユーザが動画像のアイコンを指定したか否かの判断がなされる。この判断が肯定の場合には、ステップＳ１６に進んで、該アイコンに対応する音声、動画像の再生が実行される。
【００２９】ステップＳ１７では、ユーザによってメールの削除の要求があったか否かの判断がなされる。すなわち、図９の画面において、削除のボタンが選択されたか否かの判断がなされる。この判断が肯定の場合にはステップＳ１８に進んでメールの削除を行う。なお、ステップＳ１１の判断が否定の時には、ステップＳ１３に進む。また、ステップＳ１３およびステップＳ１５の判断が否定の時には、ステップＳ１７に進む。
【００３０】前記ステップＳ１６のデータ再生の方法としては、例えば、帯域確保型のネットワークプロトコルであるＲＳＶＰプロトコルを用いて動画像や音声を即時リアルタイムで再生することができる。他のデータ再生方法としては、ＴＣＰ／ＩＰ上でデータ転送を行い、図１１のように、時刻ｔ1 でユーザが動画像データの再生を指示したとした場合、図１の再生用バッファ８にある程度のデータが蓄積された時点ｔ2 から再生を開始することにより、確実な帯域確保が困難な状況でも、簡易的なリアルタイム再生を実現することができる。この再生方式によれば、受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく、データを転送しながら再生を行うことができ、リアルタイム再生を実現することができる。なお、従来は、前記再生用バッファ８に全部のデータが蓄積された時刻ｔ3 から再生を開始していたので、本発明の再生方式によれば、（ｔ3 −ｔ2 ）時間の短縮をすることができる。
【００３１】図９に示されているように、動画像アイコンがその動画像のインデックスとして複数個表示される場合には、ユーザが選択したアイコンの位置から動画像の再生が行われ、該アイコンが指定するタイムコードによってサーバ内のファイルポインタを算出し、そのポインタからデータを転送する。なお、該ファイルポインタｆp （バイト）は、下記の式を用いて求めることができる。」
　
　ハ．「【００３５】
【発明の効果】以上の説明から明らかなように、本発明によれば、マルチメディアメール送信装置が、メール本体中に、テキストおよびメディア情報を分類させるプログラムを起動させる情報を付加するプログラム起動情報付加手段を有しているので、受信側メールサーバにおいて、テキストとメディア情報を別ファイルで蓄積できる。このため、メディア情報にアイコンを付ける等の加工を自由かつ簡単に施すことができる。
【００３６】また、本発明によれば、データ量の多い音声、動画像等のメディア情報を受信側メールサーバに別ファイルで格納し、該メディア情報にインデックスとなる１個又は複数個のアイコンを付けるようにしているので、受信側のクライアント端末にアイコンを一覧表示させることができ、受信側ユーザはその内容を容易に把握できるようになる。また、データ量の少ない、テキスト、静止画、アイコンのみを一体にして、先に受信側クライアント端末に送信するようにしているので、迅速かつ効率的に、メールを受信側クライアント端末に送ることができ、ネットワークの負荷の軽減を図ることができる。
【００３７】また、本発明によれば、動画像のデータ転送も、最初はインデックス画面だけをクライアント端末に送信するだけでよいから、少ないデータ転送量で、ユーザは動画像データの内容の概略を把握することができる。また、動画像の詳細内容をインデックス画面を通して要求された場合に、該インデックス画面から動画像の再生を開始することができ、ネットワークの負荷の軽減と、リアルタイム再生を実現できる。また、メール読出時間の短縮が可能になる。
【００３８】例えば、５０ｋバイトのテキストデータと５００ｋバイトの動画像データをもつメールは、従来方式では、５ｋバイト／秒の回線でメールの読出に１１０秒かかたが、本発明の方式によれば、約１０秒でテキストデータの読出と、動画像のリアルタイム再生とをすることができた。」　
　
　引用例の段落【０００１】、段落【００１６】、図６を参照すると、引用例は、送信側のメールサーバと受信側のメールサーバとの間をネットワークで接続したマルチメディアメールの送受信システムに関するものである。
　引用例の段落【００２７】〜【００３１】、図１０には、受信側のメールサーバの動作方法について記載されている。引用例のマルチメディアメールは、音声と動画像を含むものであり、受信側のメールサーバは、マルチメディアメールを受信したときに、そのマルチメディアメールを記憶することは自明である。
　引用例の段落【００２７】、段落【００３６】等を参照すると、受信側のメールサーバは、マルチメディアメールに含まれる音声と動画像からアイコンを作成して、音声と動画像をアイコンに置き換えるものである。
　アイコンを含むメール本体はクライアント端末に転送され、アイコンがユーザにより指定されるとアイコンに対応する音声、動画像が再生されるものであるので、アイコンには音声と動画像を検索できるようにする情報が含まれているといえる。また、再生方式として、段落【００３０】には、リアルタイム再生を行うことが示されており、リアルタイム再生を行う場合には、アイコンを含むメール本体にはリアルタイム再生を行うために必要な情報が含まれていることは技術常識であるから、この情報とアイコンとをまとめて、「アイコン等の情報」と呼ぶことにする。
　
　したがって、引用例には、技術常識を考慮すると、
　「ネットワークでマルチメディアメールを送受信するシステムにおける受信側のメールサーバの動作方法であって、
　受信側のクライアント端末へのマルチメディアメールを受信することと、
　音声と動画像を含む前記マルチメディアメールを記憶することと、
　前記音声と動画像をアイコン等の情報に置き換えること、ただし前記アイコン等の情報は、ユーザにより指定されることによりリアルタイム再生を行い、前記音声と動画像を検索できるようにする情報を含む、前記置き換えることと、
　前記アイコン等の情報を含むメール本体を前記受信側のクライアント端末に転送することと、
を含む方法。」
の発明（以下、「引用例発明」という。）が開示されていると認めることができる。
　
４．対比
　本願発明と引用例発明とを対比すると次のことが認められる。
　引用例発明の「ネットワーク」と本願発明の「無線通信」とは、「ネットワーク」である点で共通している。
　引用例発明の「マルチメディアメール」と本願発明の「マルチメディア・メッセージ」とは、「マルチメディア情報」である点で共通している。
　したがって、引用例発明の「ネットワークでマルチメディアメールを送信するシステムにおける受信側のメールサーバ」と、本願発明の「無線通信でマルチメディア・メッセージを送信する装置」とは、「ネットワークでマルチメディア情報を送信する装置」である点で共通している。
　引用例発明の「受信側のクライアント端末」は、本願発明の「受信ユーザ・エージェント」に相当する。
　したがって、引用例発明の「受信側のクライアント端末へ送信されたマルチメディアメール」と、本願発明の「受信ユーザ・エージェントのための第１のマルチメディア・メッセージ」とは、「受信ユーザ・エージェントのための第１のマルチメディア情報」である点で共通している。
　引用例発明の「リアルタイム再生」は、「ストリーミング」による再生を意味することは技術常識である。
　したがって、引用例発明の「音声と動画像」は、本願発明の「ストリーミング可能なメディア構成要素」に相当する。
　引用例発明の「ユーザにより指定されることによりリアルタイム再生を行」うことは、本願発明の「受信ユーザ・エージェントが、ストリーミング・セッションをスタート」することに実質的に一致している。
　引用例発明の「アイコン等の情報」と本願発明の「セッション記述ファイル」とは、「所定の情報」である点で共通している。
　したがって、引用例発明の「アイコン等の情報を含むメール本体」と本願発明の「セッション記述ファイルを含む第２のマルチメディア・メッセージ」とは、「所定の情報を含む第２のマルチメディア情報」である点で共通している。
　引用例発明の「受信側のクライアント端末に転送する」は、本願発明の「受信ユーザ・エージェントに送信する」に相当する。
　　
　したがって、本願発明と引用例発明とは、
　「ネットワークでマルチメディア情報を送信する装置の動作方法であって、
　受信ユーザ・エージェントのための第１のマルチメディア情報を受信することと、
　ストリーミング可能なメディア構成要素を含む前記第１のマルチメディア情報を記憶することと、
　前記ストリーミング可能なメディア構成要素を所定の情報に置き換えること、ただし前記所定の情報は、前記受信ユーザ・エージェントが、ストリーミング・セッションをスタートして、前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む、前記置き換えることと、
　前記所定の情報を含む第２のマルチメディア情報を前記受信ユーザ・エージェントに送信することと、
を含む方法。」
の点で一致し、以下の点で相違している。
　　
［相違点１］
　「ネットワーク」について、本願発明では、「無線通信」であるのに対して、引用例発明では、特定されていない点。
　
［相違点２］
　「マルチメディア情報」が、本願発明では、「マルチメディア・メッセージ」であるのに対して、引用例発明では、「マルチメディアメール」である点。
　
［相違点３］
　「第１のマルチメディア情報を受信」したときに、本願発明では、「受信ユーザ・エージェントに、第１のマルチメディア情報が使用できることを応答可能に通知する」のに対して、引用例発明は、そのように特定されていない点。
　
［相違点４］
　「所定の情報」について、本願発明では、「セッション記述ファイル」であるのに対して、引用例発明では、「アイコン等の情報」である点。
　
５．当審の判断
［相違点１］、［相違点２］について
　無線通信でマルチメディア・メッセージを送信することは、国際公開９９／６６７４６号、特開２０００−３２４１７４号公報等に示されているように周知技術である。
　引用例発明もマルチメディア情報の一つであるマルチメディアメールを送信するものであって、これを無線通信でマルチメディア・メッセージを送信することに適用することに何らの困難性は認められないから、相違点１、２に係る構成を採用することは当業者が適宜なし得たものである。
　
［相違点３］について
　メールサーバ等の装置がメールを受信したときに、ユーザ端末にメールが使用できることを応答可能に通知することは、特開２０００−１３４３３号公報、特開平１１−４６１９５号公報、特開昭６３−２９２８４７号公報等に示されているように、周知技術である。
　当該周知技術をマルチメディア・メッセージを受信したときに適用することにより、相違点３に係る構成を採用することは当業者が適宜なし得たものである。
　
［相違点４］について
　ストリーミング可能なメディア構成要素を送信する際に、セッション記述プロトコルで記述されたセッションを開始するための情報を送信することは、拒絶理由に引用された、「奥村誠司，ＭＰＥＧ−４  ｏｖｅｒ  ＲＴＰ配信システムとＱｏＳ制御方式，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ  ２０００）シンポジウム論文集  Ｖｏｌ．２０００  Ｎｏ．７，社団法人情報処理学会，４３３−４３８頁，２０００年６月２８日」の４３４頁左欄、「吉村健，モバイルマルチメディア信号処理技術特集，ＮＴＴ　ＤｏＣｏＭｏテクニカル・ジャーナル　Ｖｏｌ．８　Ｎｏ．４，社団法人電気通信協会，４３−５０頁，２００１年１月１日」の４６頁右欄等に示されているように周知技術である。
　「所定の情報」は、ストリーミング・セッションをスタートするための情報であるから、「所定の情報」をセッション記述プロトコル等で記述した「セッション記述ファイル」として構成することは、当該周知技術を考慮すれば、当業者が容易になし得たものというべきである。
　　
　そして、本願発明の作用効果も、引用例発明及び周知技術から当業者が予測できる範囲のものである。
　　　
６．むすび
　以上のとおり、本願発明は、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。