ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04N |
|---|---|
| 管理番号 | 1284069 |
| 審判番号 | 不服2010-25131 |
| 総通号数 | 171 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2014-03-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2010-11-08 |
| 確定日 | 2014-02-20 |
| 事件の表示 | 特願2007- 9247「マルチメディア・メッセージ方法およびシステム」拒絶査定不服審判事件〔平成19年 8月 2日出願公開、特開2007-195188〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、2002年2月8日(パリ条約による優先権主張外国庁受理2001年2月8日、フィンランド共和国)を国際出願日とする特願2002-563677号の一部を、平成19年1月18日に新たな特許出願(特願2007-9247号)としたものであって、平成22年7月1日付けで拒絶査定がなされ、これに対し、平成22年11月8日に拒絶査定に対する審判請求がなされたものである。 2.本願発明 本願の請求項3に係る発明(以下、「本願発明」という。)は、平成22年3月1日付け手続補正書の請求項3に記載された以下のとおりのものと認める。 「無線通信でマルチメディア・メッセージを送信する装置の動作方法であって、 受信ユーザ・エージェントのための第1のマルチメディア・メッセージを受信し、前記受信ユーザ・エージェントに、前記第1のマルチメディア・メッセージが使用できることを応答可能に通知することと、 ストリーミング可能なメディア構成要素を含む前記第1のマルチメディア・メッセージを記憶することと、 前記ストリーミング可能なメディア構成要素をセッション記述ファイルに置き換えること、ただし前記セッション記述ファイルは、前記受信ユーザ・エージェントが、ストリーミング・セッションをスタートして、前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む、前記置き換えることと、 前記セッション記述ファイルを含む第2のマルチメディア・メッセージを前記受信ユーザ・エージェントに送信することと、 を含むことを特徴とする方法。」 3.引用例発明 原査定の拒絶の理由に引用された特開平10-40188号公報(以下、「引用例」という。)には、図面とともに以下の記載がある。 イ.「【0001】 【発明の属する技術分野】この発明はマルチメディアメール送信および受信装置に関し、特に、テキスト情報と一緒に、静止画、音声、動画像等のメディア情報を、電子メールとして送信できるマルチメディアメール送信および受信装置に関する。」 ロ.「【0016】図6は、メールの送信および受信システムの概要を示すブロック図であり、51は送信側のクライアント端末、52は送信側のメールサーバ、54は受信側のメールサーバ、56は受信側のクライアント端末である。メールサーバ52と54との間は、ネットワーク53で接続されている。55はWEBサーバ、VODサーバ等の音声、動画像等のメディア情報を格納するメディア情報格納用サーバである。 【0017】次に、クライアント端末51で作成されたメールの送信方法について説明する。メールサーバ52から送出されるメールの送信時のデータの形としては、図7(a) に示されているように、テキスト、静止画と、動画像、音声等のメディア情報をメール本体中に一体にした一体型メール61と、同図(b) に示されているように、テキスト、静止画62aに、動画像、音声データ62bを添付ファイルとする添付型メール62がある。該添付型メール62においては、メールの本体中に、前記テキストと動画像、音声データ62bのリンク情報が入れられている。 【0018】これらのメールは、いずれも、送信側のメールサーバ52から受信側のメールサーバ54へ、一時に送信される。音声、動画像等のメディア情報を圧縮して送信する場合には、例えば圧縮符号化の国際標準方式である、MPEG1(ISO/IEC11172)、H263(ITU-T)、H261(ITU-T)、G722(ITU-T)等を用いることができる。 【0019】図8は、前記したメールの作成処理および送信処理の概要を示したフローチャートである。ステップS1では、図4の画面上で、宛先、表題等をメールヘッダ部分41に入力する動作、およびテキストをテキスト入力部42に書込む動作が行われる。ステップS2では、図4のアイコンが選択されたか否かの判断がなされる。この判断が肯定の場合にはステップS3に進む。ステップS3では、カメラ2、マイク3又は作成プログラムによりメディア情報を新規に作成するか、あるいは既に格納されているメディア情報を採用するかの選択が行われる。そして、この選択に従がった方法で、メディア情報の取り込みが行われる。ステップS4では、取り込んだメディア情報の確認を行うか否かの判断がなされ、この判断が肯定の場合には、ステップS5に進んで、再生プログラムが起動され、これによって取り込んだメディア情報の確認がなされる。続いて、ステップS6に進んで、作成したメールを送信するか否かの判断がなされる。この判断が肯定の場合には、ステップS7に進んで、メールヘッダ、メールの内容が作成され、ステップS8では、図7の(a) 又は(b) の形態で送信される。 【0020】次に、受信側のメールサーバ54、メディア情報格納用サーバ55およびクライアント端末56の動作を説明する。送信されたメール中に、テキストとメディア情報を分類するプログラムを起動する情報が含まれている場合には、受信側のメールサーバ54は音声と動画像を別ファイルとして、メディア情報格納サーバ55に格納する。該メディア情報格納サーバ55として、WEBサーバや、VODサーバを用いることができる。また、該受信側のメールサーバ54は、受信したメールの格納場所、ユーザ情報、そのユーザのみに許可される再生および削除コマンドの付加、および音声、動画像のアイコンの作成を行う。 【0021】該メールサーバ54は、音声、動画像のアイコンの作成を、次の動画像検索技術を用いて行うことができる。すなわち、例えば、氏原等の「動画像のカット点画像検出装置および方法」情報処理学会第51回大会6S-9(1995)、特開平7-263681号公報、特開平5-216895号公報、あるいは特開平6-46561号公報等に開示されている画像のカット点検出技術と、中島等の「類似画像検索装置および方法」画像電子学会研究会予稿(1994-06)または特開平7-77098号公報等に記されている類似画像検索技術を用いて、画像のカット点画像や類似画像を検出し、これを時間順にインデックス画像、すなわちアイコンとして表示することができる。 【0022】次に、受信側のクライアント端末56の動作を説明する。ユーザがメール受信のためにクライアント端末56で前記システムを起動すると、送信動作時と同様に、図2のユーザ認証画面が表示され、該認証が成立すると、図3の画面が表示される。該画面には、インジケータ31、送信日時32、送信者33、表題34等の情報を含む受信メールの一覧が表示される。ユーザが該一覧から所望の受信メールを選択すると、受信側メールサーバ54から、音声、動画像等を分類した後のメール本体が、例えば図9のように表示される。 【0023】図9は、受信側メールサーバ54で動画像検索を行って、自動的にインデックスとなるアイコンを作成した時の表示例であり、該インデックスとしての複数の動画像のアイコン71a?71cが画面上に一覧表示される。72はテキスト情報、73は音声アイコンを示している。 【0024】この複数のアイコン表示により、ユーザはテキストおよび動画像データの内容把握が容易になる。また、送信者のより細かなニュアンスを、メールを受信した当初に把握することができるようになる。また、ユーザがアイコンで表示された動画像および音声を詳細に見たい場合には、所望のアイコンを指定することによって、動画像データの本当に再生したい部分からの再生が可能になる。このため、動画像の再生の際に、無駄な動画像をクライアント端末56に転送する必要がなくなり、転送するデータ量を最小限に止めることができるようになる。この結果、受信側メールサーバ54と受信側クライアント端末56とを結ぶネットワークに大きな負荷をかけることなくなる。 【0025】次に、図9の画面で、ユーザが受信したメールを不必要なメールと判断してメールの削除を行う場合には、画面中の削除を指定することによって、このメールおよび表示されたアイコンに対応する受信側メールサーバ上にある音声、動画像データを同時に削除することができる。 【0026】一方、ユーザがアイコンを選択することによって、さらに音声、動画像の再生を要求する場合には、クライアント端末中に搭載されている再生プログラムをさらに起動する。そうすると、再生画面が別に表示されて、再生が即時に開始される。なお、これに代えて、図中のアイコンをそのまま再生画面として、再生を即座に開始させるようにしてもよい。 【0027】図10は、前記したメールの受信側の装置の動作を示すフローチャートである。ステップS11では、受信側メールサーバ54は、受信メールにメディア情報を分類するプログラムの起動情報があるか否かの判断がなされる。この判断が肯定の場合には、ステップS12に進んで、受信したメールデータの中から音声と動画像とを分類し、メディア情報格納サーバ55に格納する。また、受信側メールサーバ54は、格納場所、ユーザ情報の付加再生、削除コマンドの付加およびアイコンの作成とリンク付けを行う。 【0028】ステップS13では、ユーザによってメールの再生要求があるか否かの判断がなされ、この判断が肯定の場合にはステップS14に進んで、音声、動画像アイコンを含むメール本体を、クライアント端末へ転送し表示する。ステップS15では、ユーザによって、さらに、音声、動画像の再生の要求があるか否かの判断がなされる。すなわち、ユーザが動画像のアイコンを指定したか否かの判断がなされる。この判断が肯定の場合には、ステップS16に進んで、該アイコンに対応する音声、動画像の再生が実行される。 【0029】ステップS17では、ユーザによってメールの削除の要求があったか否かの判断がなされる。すなわち、図9の画面において、削除のボタンが選択されたか否かの判断がなされる。この判断が肯定の場合にはステップS18に進んでメールの削除を行う。なお、ステップS11の判断が否定の時には、ステップS13に進む。また、ステップS13およびステップS15の判断が否定の時には、ステップS17に進む。 【0030】前記ステップS16のデータ再生の方法としては、例えば、帯域確保型のネットワークプロトコルであるRSVPプロトコルを用いて動画像や音声を即時リアルタイムで再生することができる。他のデータ再生方法としては、TCP/IP上でデータ転送を行い、図11のように、時刻ｔ1 でユーザが動画像データの再生を指示したとした場合、図1の再生用バッファ8にある程度のデータが蓄積された時点ｔ2 から再生を開始することにより、確実な帯域確保が困難な状況でも、簡易的なリアルタイム再生を実現することができる。この再生方式によれば、受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく、データを転送しながら再生を行うことができ、リアルタイム再生を実現することができる。なお、従来は、前記再生用バッファ8に全部のデータが蓄積された時刻ｔ3 から再生を開始していたので、本発明の再生方式によれば、(ｔ3 -ｔ2 )時間の短縮をすることができる。 【0031】図9に示されているように、動画像アイコンがその動画像のインデックスとして複数個表示される場合には、ユーザが選択したアイコンの位置から動画像の再生が行われ、該アイコンが指定するタイムコードによってサーバ内のファイルポインタを算出し、そのポインタからデータを転送する。なお、該ファイルポインタfp (バイト)は、下記の式を用いて求めることができる。」 ハ.「【0035】 【発明の効果】以上の説明から明らかなように、本発明によれば、マルチメディアメール送信装置が、メール本体中に、テキストおよびメディア情報を分類させるプログラムを起動させる情報を付加するプログラム起動情報付加手段を有しているので、受信側メールサーバにおいて、テキストとメディア情報を別ファイルで蓄積できる。このため、メディア情報にアイコンを付ける等の加工を自由かつ簡単に施すことができる。 【0036】また、本発明によれば、データ量の多い音声、動画像等のメディア情報を受信側メールサーバに別ファイルで格納し、該メディア情報にインデックスとなる1個又は複数個のアイコンを付けるようにしているので、受信側のクライアント端末にアイコンを一覧表示させることができ、受信側ユーザはその内容を容易に把握できるようになる。また、データ量の少ない、テキスト、静止画、アイコンのみを一体にして、先に受信側クライアント端末に送信するようにしているので、迅速かつ効率的に、メールを受信側クライアント端末に送ることができ、ネットワークの負荷の軽減を図ることができる。 【0037】また、本発明によれば、動画像のデータ転送も、最初はインデックス画面だけをクライアント端末に送信するだけでよいから、少ないデータ転送量で、ユーザは動画像データの内容の概略を把握することができる。また、動画像の詳細内容をインデックス画面を通して要求された場合に、該インデックス画面から動画像の再生を開始することができ、ネットワークの負荷の軽減と、リアルタイム再生を実現できる。また、メール読出時間の短縮が可能になる。 【0038】例えば、50kバイトのテキストデータと500kバイトの動画像データをもつメールは、従来方式では、5kバイト/秒の回線でメールの読出に110秒かかたが、本発明の方式によれば、約10秒でテキストデータの読出と、動画像のリアルタイム再生とをすることができた。」 引用例の段落【0001】、段落【0016】、図6を参照すると、引用例は、送信側のメールサーバと受信側のメールサーバとの間をネットワークで接続したマルチメディアメールの送受信システムに関するものである。 引用例の段落【0027】?【0031】、図10には、受信側のメールサーバの動作方法について記載されている。引用例のマルチメディアメールは、音声と動画像を含むものであり、受信側のメールサーバは、マルチメディアメールを受信したときに、そのマルチメディアメールを記憶することは自明である。 引用例の段落【0027】、段落【0036】等を参照すると、受信側のメールサーバは、マルチメディアメールに含まれる音声と動画像からアイコンを作成して、音声と動画像をアイコンに置き換えるものである。 アイコンを含むメール本体はクライアント端末に転送され、アイコンがユーザにより指定されるとアイコンに対応する音声、動画像が再生されるものであるので、アイコンには音声と動画像を検索できるようにする情報が含まれているといえる。また、再生方式として、段落【0030】には、リアルタイム再生を行うことが示されており、リアルタイム再生を行う場合には、アイコンを含むメール本体にはリアルタイム再生を行うために必要な情報が含まれていることは技術常識であるから、この情報とアイコンとをまとめて、「アイコン等の情報」と呼ぶことにする。 したがって、引用例には、技術常識を考慮すると、 「ネットワークでマルチメディアメールを送受信するシステムにおける受信側のメールサーバの動作方法であって、 受信側のクライアント端末へのマルチメディアメールを受信することと、 音声と動画像を含む前記マルチメディアメールを記憶することと、 前記音声と動画像をアイコン等の情報に置き換えること、ただし前記アイコン等の情報は、ユーザにより指定されることによりリアルタイム再生を行い、前記音声と動画像を検索できるようにする情報を含む、前記置き換えることと、 前記アイコン等の情報を含むメール本体を前記受信側のクライアント端末に転送することと、 を含む方法。」 の発明(以下、「引用例発明」という。)が開示されていると認めることができる。 4.対比 本願発明と引用例発明とを対比すると次のことが認められる。 引用例発明の「ネットワーク」と本願発明の「無線通信」とは、「ネットワーク」である点で共通している。 引用例発明の「マルチメディアメール」と本願発明の「マルチメディア・メッセージ」とは、「マルチメディア情報」である点で共通している。 したがって、引用例発明の「ネットワークでマルチメディアメールを送信するシステムにおける受信側のメールサーバ」と、本願発明の「無線通信でマルチメディア・メッセージを送信する装置」とは、「ネットワークでマルチメディア情報を送信する装置」である点で共通している。 引用例発明の「受信側のクライアント端末」は、本願発明の「受信ユーザ・エージェント」に相当する。 したがって、引用例発明の「受信側のクライアント端末へ送信されたマルチメディアメール」と、本願発明の「受信ユーザ・エージェントのための第1のマルチメディア・メッセージ」とは、「受信ユーザ・エージェントのための第1のマルチメディア情報」である点で共通している。 引用例発明の「リアルタイム再生」は、「ストリーミング」による再生を意味することは技術常識である。 したがって、引用例発明の「音声と動画像」は、本願発明の「ストリーミング可能なメディア構成要素」に相当する。 引用例発明の「ユーザにより指定されることによりリアルタイム再生を行」うことは、本願発明の「受信ユーザ・エージェントが、ストリーミング・セッションをスタート」することに実質的に一致している。 引用例発明の「アイコン等の情報」と本願発明の「セッション記述ファイル」とは、「所定の情報」である点で共通している。 したがって、引用例発明の「アイコン等の情報を含むメール本体」と本願発明の「セッション記述ファイルを含む第2のマルチメディア・メッセージ」とは、「所定の情報を含む第2のマルチメディア情報」である点で共通している。 引用例発明の「受信側のクライアント端末に転送する」は、本願発明の「受信ユーザ・エージェントに送信する」に相当する。 したがって、本願発明と引用例発明とは、 「ネットワークでマルチメディア情報を送信する装置の動作方法であって、 受信ユーザ・エージェントのための第1のマルチメディア情報を受信することと、 ストリーミング可能なメディア構成要素を含む前記第1のマルチメディア情報を記憶することと、 前記ストリーミング可能なメディア構成要素を所定の情報に置き換えること、ただし前記所定の情報は、前記受信ユーザ・エージェントが、ストリーミング・セッションをスタートして、前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む、前記置き換えることと、 前記所定の情報を含む第2のマルチメディア情報を前記受信ユーザ・エージェントに送信することと、 を含む方法。」 の点で一致し、以下の点で相違している。 [相違点1] 「ネットワーク」について、本願発明では、「無線通信」であるのに対して、引用例発明では、特定されていない点。 [相違点2] 「マルチメディア情報」が、本願発明では、「マルチメディア・メッセージ」であるのに対して、引用例発明では、「マルチメディアメール」である点。 [相違点3] 「第1のマルチメディア情報を受信」したときに、本願発明では、「受信ユーザ・エージェントに、第1のマルチメディア情報が使用できることを応答可能に通知する」のに対して、引用例発明は、そのように特定されていない点。 [相違点4] 「所定の情報」について、本願発明では、「セッション記述ファイル」であるのに対して、引用例発明では、「アイコン等の情報」である点。 5.当審の判断 [相違点1]、[相違点2]について 無線通信でマルチメディア・メッセージを送信することは、国際公開99/66746号、特開2000-324174号公報等に示されているように周知技術である。 引用例発明もマルチメディア情報の一つであるマルチメディアメールを送信するものであって、これを無線通信でマルチメディア・メッセージを送信することに適用することに何らの困難性は認められないから、相違点1、2に係る構成を採用することは当業者が適宜なし得たものである。 [相違点3]について メールサーバ等の装置がメールを受信したときに、ユーザ端末にメールが使用できることを応答可能に通知することは、特開2000-13433号公報、特開平11-46195号公報、特開昭63-292847号公報等に示されているように、周知技術である。 当該周知技術をマルチメディア・メッセージを受信したときに適用することにより、相違点3に係る構成を採用することは当業者が適宜なし得たものである。 [相違点4]について ストリーミング可能なメディア構成要素を送信する際に、セッション記述プロトコルで記述されたセッションを開始するための情報を送信することは、拒絶理由に引用された、「奥村誠司,MPEG-4 ｏｖeｒ RTP配信システムとQｏS制御方式,マルチメディア,分散,協調とモバイル(DICOMO 2000)シンポジウム論文集 Vｏl.2000 Nｏ.7,社団法人情報処理学会,433-438頁,2000年6月28日」の434頁左欄、「吉村健,モバイルマルチメディア信号処理技術特集,NTT DｏCｏMｏテクニカル・ジャーナル Vｏl.8 Nｏ.4,社団法人電気通信協会,43-50頁,2001年1月1日」の46頁右欄等に示されているように周知技術である。 「所定の情報」は、ストリーミング・セッションをスタートするための情報であるから、「所定の情報」をセッション記述プロトコル等で記述した「セッション記述ファイル」として構成することは、当該周知技術を考慮すれば、当業者が容易になし得たものというべきである。 そして、本願発明の作用効果も、引用例発明及び周知技術から当業者が予測できる範囲のものである。 6.むすび 以上のとおり、本願発明は、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-06-04 |
| 結審通知日 | 2012-06-12 |
| 審決日 | 2012-06-26 |
| 出願番号 | 特願2007-9247(P2007-9247) |
| 審決分類 |
P
1
8・
121-
Z
(H04N)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 脇岡 剛 |
| 特許庁審判長 |
竹井 文雄 |
| 特許庁審判官 |
萩原 義則 遠山 敬彦 |
| 発明の名称 | マルチメディア・メッセージ方法およびシステム |
| 代理人 | 川守田 光紀 |