知財高等裁判所 平成24年(行ケ)10386号 判決 2013年8月28日
原告
コア ワイヤレス ライセンシング エス.アー.エール.エル.
訴訟代理人弁理士
川守田光紀
被告
特許庁長官
指定代理人
竹井文雄
同
萩原義則
同
田部元史
同
堀内仁子
主文
1 原告の請求を棄却する。
2 訴訟費用は原告の負担とする。
3 この判決に対する上告及び上告受理申立てのための付加期間を30日と定める。
事実及び理由
第1請求
特許庁が不服2010-25131号事件について平成24年6月26日にした審決を取り消す。
第2前提となる事実
1 特許庁における経緯
発明の名称を「マルチメディア・メッセージ方法およびシステム」とする発明に係る特許出願(特願2007-9247号。請求項の数27。以下「本願」といい,本願に係る明細書を図面を含めて「本願明細書」という。)は,平成14年2月8日を国際出願日とする特願2002-563677号(パリ条約による優先権主張2001年(平成13年)2月8日 フィンランド共和国)の一部について,平成19年1月18日に,分割出願されたものである(甲9,10)。本願については,平成22年3月1日に請求項の数を25にするとともに,特許請求の範囲を変更する旨の手続補正(以下「本件補正」という。)がされ(甲12),同月30日付けで拒絶理由通知(以下「本件拒絶理由通知」という。)が出され(甲14),同年7月1日付けで拒絶査定(以下「拒絶査定」という。)がされ(甲16),同年11月8日,拒絶査定不服審判(不服2010-25131号事件。以下「本件審判」という。)が請求された(甲17)。
特許庁は,平成24年6月26日,請求不成立の審決をし,その謄本は,同年7月10日,出願人に送達された。
本願の出願人は,フィンランド共和国の法律に基づく法人である「ノキア コーポレイション」であったが,平成24年4月17日付けでアメリカ合衆国の法律に基づく法人である「ノキア 2011 パテント トラスト」(その後「2011インテレクチュアル プロパティ アセット トラスト」に名称変更)に変更され,同年9月19日付けで原告に変更された(甲18ないし21)。
2 特許請求の範囲
本件補正による補正後の,本願に係る特許請求の範囲の請求項3は以下のとおりである(以下,同請求項に係る発明を「本願発明」という。)(甲12)。
「【請求項3】無線通信でマルチメディア・メッセージを送信する装置の動作方法であって,
受信ユーザ・エージェントのための第1のマルチメディア・メッセージを受信し,前記受信ユーザ・エージェントに,前記第1のマルチメディア・メッセージが使用できることを応答可能に通知することと,
ストリーミング可能なメディア構成要素を含む前記第1のマルチメディア・メッセージを記憶することと,
前記ストリーミング可能なメディア構成要素をセッション記述ファイルに置き換えること,ただし前記セッション記述ファイルは,前記受信ユーザ・エージェントが,ストリーミング・セッションをスタートして,前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む,前記置き換えることと,
前記セッション記述ファイルを含む第2のマルチメディア・メッセージを前記受信ユーザ・エージェントに送信することと,
を含むことを特徴とする方法。」
3 審決の理由
審決の理由は,別紙審決書写しに記載のとおりであり,その要旨は,本願発明と特開平10-40188号公報(甲1。以下「引用例」という。)に記載された発明(以下「引用例発明」という。)との相違点1ないし3に係る構成を採用することは,文献(甲2ないし6)に示された周知技術に基づいて,相違点4に係る構成を採用することは,文献(甲7及び8)に記載された周知技術に基づいて,当業者が容易になし得たものであり,本願発明は,引用例発明及び周知技術に基づいて,当業者が容易に発明をすることができたとするものである。
審決が認定した引用例発明の内容,本願発明と引用例発明との一致点及び相違点は,以下のとおりである。
(1) 引用例発明の内容
「ネットワークでマルチメディアメールを送受信するシステムにおける受信側のメールサーバの動作方法であって,
受信側のクライアント端末へのマルチメディアメールを受信することと,
音声と動画像を含む前記マルチメディアメールを記憶することと,
前記音声と動画像をアイコン等の情報に置き換えること,ただし前記アイコン等の情報は,ユーザにより指定されることによりリアルタイム再生を行い,前記音声と動画像を検索できるようにする情報を含む,前記置き換えることと,
前記アイコン等の情報を含むメール本体を前記受信側のクライアント端末に転送することと,
を含む方法。」
(2) 一致点
「ネットワークでマルチメディア情報を送信する装置の動作方法であって,
受信ユーザ・エージェントのための第1のマルチメディア情報を受信することと,
ストリーミング可能なメディア構成要素を含む前記第1のマルチメディア情報を記憶することと,
前記ストリーミング可能なメディア構成要素を所定の情報に置き換えること,ただし前記所定の情報は,前記受信ユーザ・エージェントが,ストリーミング・セッションをスタートして,前記ストリーミング可能なメディア構成要素を検索できるようにする情報を含む,前記置き換えることと,
前記所定の情報を含む第2のマルチメディア情報を前記受信ユーザ・エージェントに送信することと,
を含む方法。」である点。
(3) 相違点
ア 相違点1
「ネットワーク」について,本願発明では,「無線通信」であるのに対して,引用例発明では,特定されていない点。
イ 相違点2
「マルチメディア情報」が,本願発明では,「マルチメディア・メッセージ」であるのに対して,引用例発明では,「マルチメディアメール」である点。
ウ 相違点3
「第1のマルチメディア情報を受信」したときに,本願発明では,「受信ユーザ・エージェントに,第1のマルチメディア情報が使用できることを応答可能に通知する」のに対して,引用例発明は,そのように特定されていない点。
エ 相違点4
「所定の情報」について,本願発明では,「セッション記述ファイル」であるのに対して,引用例発明では,「アイコン等の情報」である点。
第3取消事由に関する当事者の主張
1 原告の主張
審決には,手続違背(取消事由1),引用例発明の認定の誤り,及び一致点・相違点の認定の誤り(取消事由2),相違点4の容易想到性の判断の誤り(取消事由3)があり,違法であるから,取り消されるべきである。
(1) 手続違背(取消事由1)
本件審判では,審判請求人に平成18年法律第55号による改正前の特許法(以下,単に「特許法」という。)50条に基づく意見書提出の機会を与えることなく審決を行っており,本件審判手続には以下のとおり手続違背がある。
審決は,本願発明は,引用例発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであると判断した。ところが,拒絶査定では,本願発明は引用文献1ないし5に基づいて当業者が容易に想到できたと判断しており,審決とは容易想到であると判断した根拠となる引用文献の組合せが異なる。
また,拒絶査定書にも,拒絶査定において引用されている本件拒絶理由通知書にも,本願発明と引用文献との具体的な対比検討については,何ら記載されていない。引用文献1が主たる引用文献であるとの記載もない。本願発明に係る特許請求の範囲は本件補正による補正がなされているが,この補正に対する判断も行っていない。
したがって,審決に記載の拒絶理由は拒絶査定の理由と異なり,同法159条2項で準用される同法50条に基づいて,審判官は,審判請求人に対し,意見書,補正書を提出する機会を与えるべきであった。そのような機会を与えずになされた審決には,同法159条2項違反の手続違背がある。
(2) 引用例発明の認定の誤り,及び一致点・相違点の認定の誤り(取消事由2)
ア 引用例発明の認定の誤り
審決は,引用例発明の「アイコン等の情報」について,「音声と動画像を検索できるようにする情報が含まれるアイコン」「アイコンを含むメール本体に含まれている情報であって,リアルタイム再生を行うために必要な情報」を含み,「クライアント端末に転送される情報」であると認定した。しかし,審決の同認定には,以下のとおり,誤りがある。
(ア) 引用例には,「(受信側のクライアント端末が)音声と動画像を検索できるようにする情報が含まれるアイコン」は記載されていない。
アイコンがユーザーにより指定されるとアイコンに対応する音声,動画像が再生されるとしても,当該アイコンに音声と動画像を検索できるようにする情報が含まれていなければならないわけではない。
引用例に記載されているのは,受信側メールサーバ54がアイコンと音声・動画像とを関連づける情報と,当該アイコンがユーザーに指定されたかどうかを判断する手段とを備えていることであり,「アイコンがユーザーにより指定されるとアイコンに対応する音声,動画像が再生される」には,そのような構成で十分である。引用例には,受信側クライアント端末56が音声・動画像ファイルの検索を行うことについては,何の記載も示唆もない。
なお,引用例において,受信側メールサーバ54から受信側クライアント端末56に送信される「音声・動画像アイコン」として記載されているのは,動画像のカット画像等からなる単なるアイコンであり,「音声と動画像を検索できるようにする情報が含まれるアイコン」ではない。
(イ) また,引用例には「アイコンを含むメール本体に含まれている情報であって,リアルタイム再生を行うために必要な情報」は記載されていない。
引用例に記載されているのは,受信側クライアント端末56が,メール中のアイコンを指定したことを受信側メールサーバ54に通知し,受信側メールサーバ54は,その通知に基づいて動画等の再生を行うことである。クライアント端末中の再生プログラムを起動する主体は,クライアント端末自身であり,リアルタイム再生を行うために,メールサーバから再生プログラムの起動に用いられる情報を送ってもらう必要はない。
イ 一致点・相違点の認定の誤り
上記のとおり,審決には引用例発明の認定に誤りがあり,したがって,本願発明と引用例発明との一致点・相違点の認定にも誤りがある。審決は,本願発明の「セッション記述ファイル」が引用例発明の「アイコン等の情報」と「所定の情報」である点で共通していると認定するが,「アイコン等の情報」は引用例に記載されていないから,「所定の情報」の内容も不明である。
(3) 相違点4の容易想到性の判断の誤り(取消事由3)
審決は,「所定の情報」を本願発明における「セッション記述ファイル」として構成することは,当業者が容易になし得たと判断する。審決には,引用例発明の「アイコン等の情報」の認定に誤りがあるので,これを,引用例に記載された,メディア情報から作成されるインデックスとなる音声・動画像アイコンであると解するとすると,審決の容易想到性の判断には,以下のとおりの誤りがある。
引用例には,上記音声・動画像アイコンには,動画像の内容把握を容易にしたり,送信者の細かなニュアンスを伝えたり,所望の箇所から動画像データを再生したりする能力があるとの記載があるが,「セッション記述ファイル」にこのような能力があるか否かは明らかではない。したがって,引用例に接した当業者において,上記音声・動画像アイコンを本願発明の「セッション記述ファイル」に置換することの動機付けが生じたとは考えられず,そのような置換が当業者に容易想到であったとはいえない。
また,上記音声・動画像アイコンと共に,本願発明の「セッション記述ファイル」を作成・送信するような構成を採ることが,当業者に容易想到であったかについては,引用例に記載された,アイコンが指定されたか否かの判断や,アイコンと動画像等との関連性の調査に,「セッション記述ファイル」が技術的に役立つか否か明らかでない。したがって,引用例の上記音声・動画像アイコンと共に本願発明の「セッション記述ファイル」を作成・送信するような構成を採ることにより解決される技術的課題はなく,このような構成を採ることが当業者に容易想到であったとはいえない。
2 被告の反論
(1) 手続違背(取消事由1)に対して
本件拒絶理由通知及び拒絶査定は,本件補正後の請求項1ないし25に係る発明は,引用文献1ないし5に記載された発明に基づいて,当業者が容易に発明をすることができたものであると判断したものである。本件拒絶理由通知及び拒絶査定の引用文献1が主たる引用文献であり,審決における引用例と同一の文献である。
したがって,審決,本件拒絶理由通知及び拒絶査定は,いずれも引用例を主たる引用文献として,本願発明の容易想到性を判断したものであり,手続違反はない。
なお,審判請求人は,意見書及び審判請求書を提出することにより,十分な反論の機会が与えられていた。
したがって,審決に手続違背があるとする原告の主張は失当である。
(2) 引用例発明の認定の誤り,及び一致点・相違点の認定の誤り(取消事由2)に対して
ア 引用例においては,アイコンがユーザに指定されると,当該アイコンに対応する音声や動画像の再生が実行される。また,メデイア情報格納サーバには音声や動画像が多数格納されており,当該アイコンに対応する音声や動画像を再生するためには,多数の音声や動画像から当該アイコンに対応する音声や動画像を検索するための情報が,アイコンに関連づけされていなければならない。
したがって,引用例の「アイコン」は,「音声と動画像を検索できるようにする情報が含まれるアイコン」であるといえる。
一般に,パソコン等のプログラムを起動するためには,例えばプログラム名やパラメータを指定する必要があることは周知である。したがって,起動するプログラムがリアルタイム再生のプログラムの場合は,そのプログラム名やパラメータは,メールサーバからクライアント端末に転送されて再生プログラムの起動に用いられることになる。このメールサーバからクライアント端末に転送される情報は,「リアルタイム再生を行うために必要な情報」であって,「アイコンを含むメール本体」に含まれている。
審決は,「リアルタイム再生を行うために必要な情報」と「アイコン」とをまとめて「アイコン等の情報」と表記したものであり,審決の引用例発明の認定に誤りはない。
イ 「リアルタイム再生を行うために必要な情報」は「受信ユーザ・エージェントがストリーミングをスタート」するために必要な情報であるから,「受信ユーザ・エージェントが,ストリーミング・セッションをスタートして,ストリーミング可能なメディア構成要素を検索できるようにする情報を含む」ものである。したがって,引用例発明の「アイコン等の情報」と本願発明の「セッション記述ファイル」とは,「所定の情報」,すなわち「受信ユーザ・エージェントが,ストリーミング・セッションをスタートして,ストリーミング可能なメディア構成要素を検索できるようにする情報」を含む点で共通している。
(3) 相違点4の容易想到性の判断の誤り(取消事由3)に対して
相違点4につき,「所定の情報」は,ストリーミング・セッションをスタートさせるための情報であるから,周知技術を考慮すれば,「所定の情報」をセッション記述プロトコル等で記述した「セッション記述ファイル」として構成することは,当業者が容易に想到できたというべきであり,審決の判断に誤りはない。
ストリーミングを行う際には,セッション情報をユーザに送信する必要があることは技術常識であるから,セッション情報,すなわち「セッション記述ファイル」をユーザに送信するようにすることは,当業者であれば当然のことである。
第4当裁判所の判断
当裁判所は,審決の引用例発明の認定,相違点の認定には誤りがあるが,同認定の誤りは,本願発明が容易に想到することができるものであるとした審決に影響を与えるものではないと判断する。その理由は,以下のとおりである。
1 認定事実
(1) 本願明細書の記載
本件補正後の本願に係る特許請求の範囲の請求項1は以下のとおりであり,また,本願明細書には,以下の記載がある。本願明細書の図2及び図4は,別紙1【図2】及び同【図4】のとおりである。(甲9,10,12)
「【請求項1】受信ユーザ・エージェントの動作方法であって,
無線通信によりマルチメディア・メッセージを受信することと,
前記マルチメディア・メッセージを受信する前に,マルチメディア・メッセージ通知を受信し,前記通知メッセージを受信するとほぼ同時に,前記マルチメディア・メッセージをダウンロードすることと,
前記マルチメディア・メッセージから,ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離することと,
前記セッション記述ファイルが記述する記憶しているストリーミング可能なメディア構成要素を検索するために,前記セッション記述ファイルによりストリーミング・セッションをスタートすることと,
を含むことを特徴とする方法。」
「【0001】本発明は,データ伝送に係り,特に,マルチメディア・メッセージ・サービスにおけるメディア・コンテンツのストリーミングに関する。」
「【0010】図2について説明すると,マルチメディア・メッセージ・サービス環境A 210で提供されるマルチメディア・メッセージ・サービスに加入しているMMSユーザ・エージェントA 110Aは,MMSE B 220が提供するマルチメディア・メッセージ・サービスに加入しているMMSユーザ・エージェントB 110Bに,あるメディア・コンテンツを送信したがっていると仮定する。一般的に,マルチメディア・メッセージの内容は,種々の構成要素を含んでいて,そのうちのいくつかは,ストリーミングに適していて,他の構成要素は,通常は,テキストまたは静止画のようにストリーミングに適していない。」
「【0018】最近,ストリーミングを提案の第三世代マルチメディア・メッセージ・サービスに内蔵させることへの関心も高まっている。しかし,すでに説明したように,MMSサービスは,メディア・コンテンツ,メッセージ記述およびアドレス指定情報を1つのメッセージに封入することをベースとしている。この種の封入は,メディア・コンテンツのストリーミングと互換性を持っていないので,メディア・コンテンツのストリーミング・ダウンロードを収容するには,MMSサービス勧告をある程度変更しなければならない。3GPPTS23.140,リリース4を使用すれば,受信ユーザ・エージェントと受信MMSリレーとの間にストリーミング・セッションを確立することができるが,受信MMSリレーから受信MMSユーザ・エージェントへ送信する通知メッセージをある程度変更しなければならない。」
「【発明が解決しようとする課題】
【0021】しかし,このような変更にもかかわらず,ストリーミング可能なマルチメディア構成要素とストリーミング不能なマルチメディア構成要素を矛盾しない方法でダウンロードすることができる機構は,MMS仕様には存在しない。このような機能の開発が待望されている。何故なら,静止画およびテキストまたはプログラム・アプレットのようなストリーミング不能なマルチメディア構成要素を,音響,音声またはビデオ・ストリームのようなストリーミング可能なマルチメディア構成要素と一緒に受信できれば非常に役に立つからである。」
「【課題を解決するための手段】・・・
【0023】第2の態様によれば,本発明は,マルチメディア・メッセージを送信するための方法を提供する。この方法は,通信ネットワーク・エンティティ内にストリーミング可能なメディア構成要素を含むマルチメディア・メッセージを記憶するステップと,ネットワーク・エンティティから受信ユーザ・エージェントにマルチメディア・メッセージを送信するステップと,上記マルチメディア・メッセージ内に,受信ユーザ・エージェントが,ストリーミング可能なメディア構成要素を検索するために,ストリーミング・セッションをスタートすることができるようにする情報を供給する記述子を内蔵させるステップと,を含む。」
「【0026】好適には,ストリーミング不能なメディア構成要素とストリーミング可能なメディア構成要素の両方を備えるマルチメディア・メッセージのストリーミング可能なメディア構成要素を,ストリーミング不能な構成要素と記述子とを含むように,マルチメディア・メッセージが変更されるように,上記記述子で置き換えることが好ましい。それ故,ストリーミング不能な構成要素および記述子を含む変更したメッセージが,受信ユーザ・エージェントにダウンロードされると,ユーザ・エージェントは,ストリーミング可能なメディア構成要素をダウンロードする目的で,ストリーミング・セッションをスタートするために,記述子が供給する情報を使用することができる。」
「【0028】好適には,この置換は,受信MMSリレーまたはMMSサーバにより行うことが好ましい。すなわち,好適には,置換は,受信ユーザ・エージェントに関連するMMSリレー,またはMMSサーバにより行うことが好ましい。別の方法としては,代理サーバのような他の通信ブロックが置換を行うことができる。
好適には,記述子を,セッション記述ファイル,ユニフォーム・リソース・ロケータ(URL),およびユニバーサル・リソース識別子(URI)からなるグループから選択することが好ましい。
好適には,セッション記述ファイルは,セッション記述プロトコル(SDP)ファイルであることが好ましい。
好適には,セッション記述ファイルは,ストリーミング可能なメディア構成要素をダウンロードする目的で,ストリーミング・セッションをスタートするのに必要なすべてのデータを含んでいることが好ましい。
【0029】マルチメディア・メッセージに記述子を挿入すると,ストリーミング・セッションをスタートする目的で,データを別々に送信する必要がなくなる。そのため,通信帯域幅を節約することができ,メッセージ送信を加速することができる。何故なら,過度のメッセージ送信を避けることができるからである。さらに,受信ユーザ・エージェントがそのメッセージを拒否した場合には,無駄に記述子を送信する必要がなくなる。」
「【0037】本発明の好ましい実施形態は,受信MMSユーザ・エージェント110Bが,ストリーミング・セッションを開始して,ストリーミング可能な構成要素をダウンロードできるようにする情報を供給する記述子に,マルチメディア・メッセージのストリーミング可能なマルチメディア構成要素を置き換えることをベースとしている。すでに説明したように,今迄,MMSに関連するストリーミングは,MMS通知メッセージ310を変更することによってだけ可能であった。本発明の好ましい実施形態の場合には,記述子はマルチメディア・メッセージに埋設されていて,受信ユーザ・エージェントにより,MMS検索応答の任意の他のマルチメディア構成要素として受信される。ユーザ・エージェントは,記述子が供給する情報を抽出するが,次に,この情報はストリーミング可能な構成要素をダウンロードする目的で,ストリーミング・セッションをスタートするために使用することができる。このことは,MMS通知メッセージ310をもはや変更する必要がないことを意味する。
【0038】図4は,本発明の好ましい実施形態による,受信MMSCと受信MMSユーザ・エージェントとの間で行われるメッセージの流れを示す。MMSCにマルチメディア・メッセージが到着した後で,最初に,メッセージ310乃至330が交換される。この交換は,受信したマルチメディア・メッセージにストリーミング可能な構成要素が存在していない場合には,従来のMMSシステムで行われたのと同じ方法で行われる。本発明による変更を行うと,MMS検索要求330の後で行われる信号送信が影響を受ける。好ましい実施形態の場合には,受信したマルチメディア・メッセージが,ストリーミング不能なメディア構成要素の他に,ストリーミング可能なメディア構成要素を含んでいる場合,MMS検索応答340は,ストリーミング不能なマルチメディア・メッセージ構成要素と,ストリーミング可能なマルチメディア構成要素を記述している記述子とを含む。好ましい実施形態の場合には,マルチメディア・メッセージが2つ以上のストリーミング可能なメディア構成要素を含んでいる場合,ストリーミング可能な各メディア構成要素は,受信ユーザ・エージェント110Bが,問題のストリーミング可能なメディア構成要素を受信するためのストリーミング・セッションを開始することができるのに十分な情報を含む別々の記述子に置換される。」
(2) 引用例の記載
引用例には,以下の記載があり,図9及び図10は別紙2【図9】及び同【図10】のとおりである(甲1)。
「【0001】
【発明の属する技術分野】この発明はマルチメディアメール送信および受信装置に関し,特に,テキスト情報と一緒に,静止画,音声,動画像等のメディア情報を,電子メールとして送信できるマルチメディアメール送信および受信装置に関する。」
「【0007】この発明の目的は,前記した従来技術の問題点を除去し,受信側端末に,短時間に,送信者の送信データに関する細かなニュアンスまで伝達できる動画像データを送ることのできるマルチメディアメール送信および受信装置を提供することにある。また,他の目的は,受信側端末と動画像用サーバとを結ぶネットワークに大きな負荷をかけることなく,クライアント端末への動画像データのダウンロードを短時間に行うことのできるマルチメディアメール送信および受信装置を提供することにある。
【0008】
【課題を解決するための手段】前記した目的を達成するために,この発明は,テキストおよび音声,静止画,動画像等のメディア情報をメールとして送受信するマルチメディアメール送信装置において,前記テキストおよびメディア情報を送信側クライアント端末に取り込んでメールを作成するメール作成手段と,該メール本体中に,受信側メールサーバにおいて前記テキストおよびメディア情報を分類させるプログラムを起動させる情報を付加するプログラム起動情報付加手段とを具備した点に第1の特徴がある。
【0009】また,この発明は,テキストおよび音声,静止画,動画像等のメディア情報をメールとして送受信するマルチメディアメール受信装置において,受信したメールに,テキストとメディア情報とを分類するプログラムを起動する情報が存在する場合に,メール本体とメディア情報とを別ファイルとして蓄積するメール蓄積手段と,前記メディア情報にそのインデックスとなるアイコン情報を付加する手段とを具備した点に第2の特徴がある。さらに,受信側クライアント端末は前記複数のアイコンからなる動画像のインデックスの一覧データを表示する手段と,該一覧データの任意の場所からデータ再生を指示する手段とを具備した点に第3の特徴がある。」
「【0020】次に,受信側のメールサーバ54,メディア情報格納用サーバ55およびクライアント端末56の動作を説明する。送信されたメール中に,テキストとメディア情報を分類するプログラムを起動する情報が含まれている場合には,受信側のメールサーバ54は音声と動画像を別ファイルとして,メディア情報格納サーバ55に格納する。該メディア情報格納サーバ55として,WEBサーバや,VODサーバを用いることができる。また,該受信側のメールサーバ54は,受信したメールの格納場所,ユーザ情報,そのユーザのみに許可される再生および削除コマンドの付加,および音声,動画像のアイコンの作成を行う。」
「【0022】次に,受信側のクライアント端末56の動作を説明する。ユーザがメール受信のためにクライアント端末56で前記システムを起動すると,送信動作時と同様に,図2のユーザ認証画面が表示され,該認証が成立すると,図3の画面が表示される。該画面には,インジケータ31,送信日時32,送信者33,表題34等の情報を含む受信メールの一覧が表示される。ユーザが該一覧から所望の受信メールを選択すると,受信側メールサーバ54から,音声,動画像等を分類した後のメール本体が,例えば図9のように表示される。
【0023】図9は,受信側メールサーバ54で動画像検索を行って,自動的にインデックスとなるアイコンを作成した時の表示例であり,該インデックスとしての複数の動画像のアイコン71a~71cが画面上に一覧表示される。72はテキスト情報,73は音声アイコンを示している。」
「【0026】一方,ユーザがアイコンを選択することによって,さらに音声,動画像の再生を要求する場合には,クライアント端末中に搭載されている再生プログラムをさらに起動する。そうすると,再生画面が別に表示されて,再生が即時に開始される。・・・
【0027】図10は,前記したメールの受信側の装置の動作を示すフローチャートである。ステップS11では,受信側メールサーバ54は,受信メールにメディア情報を分類するプログラムの起動情報があるか否かの判断がなされる。この判断が肯定の場合には,ステップS12に進んで,受信したメールデータの中から音声と動画像とを分類し,メディア情報格納サーバ55に格納する。また,受信側メールサーバ54は,格納場所,ユーザ情報の付加再生,削除コマンドの付加およびアイコンの作成とリンク付けを行う。
【0028】ステップS13では,ユーザによってメールの再生要求があるか否かの判断がなされ,この判断が肯定の場合にはステップS14に進んで,音声,動画像アイコンを含むメール本体を,クライアント端末へ転送し表示する。ステップS15では,ユーザによって,さらに,音声,動画像の再生の要求があるか否かの判断がなされる。すなわち,ユーザが動画像のアイコンを指定したか否かの判断がなされる。この判断が肯定の場合には,ステップS16に進んで,該アイコンに対応する音声,動画像の再生が実行される。」
「【0030】前記ステップS16のデータ再生の方法としては,例えば,帯域確保型のネットワークプロトコルであるRSVPプロトコルを用いて動画像や音声を即時リアルタイムで再生することができる。・・・この再生方式によれば,受信側クライアント端末に一旦データをダウンロードしてから再生を開始するのではなく,データを転送しながら再生を行うことができ,リアルタイム再生を実現することができる。」
2 手続違背(取消事由1)について
(1) 拒絶査定の理由等
本願に対し,平成21年11月25日付けで拒絶理由通知がされ(甲11),平成22年3月1日に本件補正がされたが,同月30日付けで本件拒絶理由通知がされた。本件拒絶理由通知書には,請求項1ないし25に係る発明は,引用文献1ないし5に記載された発明に基づいて,当業者が容易に発明をすることができたものであると記載されており,その備考欄には,引用文献1に記載された発明に引用文献2に記載された構成を組み合わせて,(請求項1における)「必要な情報」を,これを含む「セッション記述ファイル」の形式に替えること等,また,引用文献3ないし5に記載された周知技術から,引用文献1に記載された発明を「無線通信におけるメッセージサービス」とすること等は,当業者が容易に想到できたことである旨の記載がある(甲14)。本件拒絶理由通知における引用文献1は,本件訴訟における引用例と同一の文献であり,引用文献2は本件訴訟における甲7と同一の文献である(甲14)。
本件拒絶理由通知に対し,同年6月15日付けで,出願人から意見書が提出されたが(甲15),同年7月1日,拒絶査定がされた。拒絶査定書には,①上記引用文献1に記載された発明と請求項1に係る発明との相違点(ア)及び(イ),②上記引用文献1に記載された発明に上記引用文献3及び4に記載された周知技術を組み合わせることにより,相違点(ア)に係る構成とすること,また,同発明に上記引用文献2に記載された構成を用いることにより,相違点(イ)に係る構成とすることは,いずれも当業者が容易に想到できたこと,③したがって,請求項1ないし25に係る発明は,上記引用文献1ないし5に基づいて当業者が容易に想到できたものであること,が記載されていた(甲16)。なお,相違点(ア)と(イ)は,以下のとおりである(甲16)。
ア 相違点(ア)
請求項1に係る発明が「無線通信によりマルチメディア・メッセージを受信する前に,マルチメディア・メッセージ通知を受信し,前記通知メッセージを受信するとほぼ同時に,前記マルチメディア・メッセージをダウンロードする」ものであるのに対して,文献1に記載された発明は「通信におけるマルチメディア情報を受信する」ものである点。
イ 相違点(イ)
請求項1に係る発明が「マルチメディア・メッセージから,ストリーミング・セッションをスタートするために必要な情報を含むセッション記述ファイルを分離する」ものであるのに対して,文献1に記載された発明は「ストリーミングセッションをスタートするために必要な情報を作成する」ものである点。
(2) 手続違背の有無
拒絶査定の理由は上記のとおりであり,審決の理由は,第2,3に記載のとおりである。
拒絶査定において容易想到性の判断に用いた主引用例は,本件拒絶理由通知における引用文献1と同一の文献であり,審決における主引用例と同一の文献である。また,拒絶査定においては,副引用例として本件拒絶理由通知における引用文献2に記載された構成並びに引用文献3及び4に記載された周知技術に基づいて,容易想到性の判断を行っているところ,審決では,上記引用文献2及びその他の文献に記載された周知技術に基づいて,容易想到性の判断を行っている。
拒絶査定では,本願発明を含む請求項1ないし25に係る発明の容易想到性について判断するに当たり,主引用例との相違点に関して,請求項1に係る発明との相違点を摘示するのみである。しかし,本願発明は,「マルチメディア・メッセージ・サービスにおけるメディア・コンテンツのストリーミングに関するシステム」における受信側マルチメディア・メッセージ・サービス・リレー/サーバの動作方法に関する発明であるのに対し,請求項1に係る発明は,受信側マルチメディア・メッセージ・サービス・ユーザ・エージェントの動作方法に関する発明であり,両者の基本的な動作方法は共通していることから,請求項1に係る発明との相違点の摘示によって,本願発明と主引用例との相違点の内容も示されていると解される。
以上によると,審決が,拒絶査定と異なる理由で容易想到性の判断を行ったものとはいえず,本件審判の手続が特許法159条2項,50条に違反しているとはいえない。
3 引用例発明の認定の誤り,及び一致点・相違点の認定の誤り(取消事由2)について
(1) 本願発明について
本願発明は,マルチメディア・メッセージ・サービスにおけるメディア・コンテンツのストリーミングに関する,受信側マルチメディア・メッセージ・サービス・リレー/サーバの動作方法に関する発明である。本願発明では,受信側マルチメディア・メッセージ・サービス・リレー/サーバは,受信したマルチメディア・メッセージにストリーミング可能なメディア構成要素とストリーミング不能なメディア構成要素とが含まれている場合には,ストリーミング可能なメディア構成要素を記述子(セッション記述ファイル)に置き換え,受信側ユーザ・エージェントに対するマルチメディア・メッセージ・サービス通知に対し,検索要求があった場合には,これに対する検索応答として,ストリーミング不能なマルチメディア構成要素と,ストリーミング可能なマルチメディア構成要素の記述子(セッション記述ファイル)を含んだマルチメディア・メッセージを受信側ユーザ・エージェントに送信する。セッション記述ファイルは,ストリーミング・セッションをスタートするのに必要なデータ,ストリーミング可能なメディア構成要素を検索できるようにするのに必要なデータが含まれている。
(2) 引用例発明について
ア 引用例には,テキスト情報と一緒に,静止画,音声,動画像等のメディア情報を,電子メールとして送信できるマルチメディアメール送信及び受信装置に関する発明が記載されており,その目的は,受信側端末に,短時間に,送信者の送信データに関する細かなニュアンスまで伝達できる動画像データを送ることのできるマルチメディアメール送信及び受信装置を提供すること,及び,受信側端末と動画像用サーバとを結ぶネットワークに大きな負荷をかけることなく,クライアント端末への動画像データのダウンロードを短時間に行うことのできるマルチメディアメール送信及び受信装置を提供することである。
イ 前記のとおり,引用例には,①送信されたメール中に,テキストとメディア情報を分類するプログラムを起動する情報が含まれている場合には,受信側のメールサーバは,受信したメールデータの中から音声と動画像を別ファイルとして,メディア情報格納サーバに格納し,受信したメールの格納場所・ユーザ情報の付加,そのユーザのみに許可される再生及び削除コマンドの付加,音声,動画像のアイコンの作成及び音声,動画像とアイコンのリンク付けを行うこと,②受信側のユーザがメールの再生要求をすると,音声,動画像アイコンを含むメール本体がクライアント端末へ転送,表示されること,③ユーザが,クライアント端末において音声,動画像アイコンを選択することにより,音声,動画像の再生を要求すると,クライアント端末中に搭載されている再生プログラムが起動し,当該アイコンに対応する音声,動画像の再生が即時に開始されること,④受信側メールサーバから受信側クライアント端末にデータを転送しながら再生を行うことができるので,リアルタイム再生を実現することができること,が開示されている。
以上によると,受信側のメールサーバは,音声,動画像をメディア情報格納サーバに格納する際,アイコンの作成とともに,このアイコンと受信した音声,動画像の格納場所等の情報とのリンク付けを行っていることが認められる。しかし,引用例には,受信側のユーザがメールの再生要求をした場合に,音声,動画像アイコンを含むメール本体がクライアント端末へ転送されることは記載されているものの,メール本体に音声,動画像に関わる何らかの情報も含まれているか否か,それがどのような情報であるかについては,明確な記載はない。また,引用例に係る特許出願がされた平成8年7月当時,引用例に記載されたマルチメディアメール送信及び受信において,音声・動画像アイコンと共に,「ユーザにより指定されることによりリアルタイム再生を行い,音声と動画像を検索できるようにする情報」がメール本体に含まれており,受信側のクライアント端末に転送されるという方法が当業者に周知の技術であったと認めるに足りる証拠はない。
したがって,引用例発明においては,音声・動画像アイコンと共に「ユーザにより指定されることによりリアルタイム再生を行い,音声と動画像を検索できるようにする情報」がメール本体に含まれており,受信側のクライアント端末に転送されるとした審決の認定には,誤りがある。
引用例に記載されている発明は,以下のとおりの技術内容の範囲で,認定されるのが相当である。
「ネットワークでマルチメディアメールを送受信するシステムにおける受信側のメールサーバの動作方法であって,
受信側のクライアント端末へのマルチメディアメールを受信することと,
音声と動画像を含む前記マルチメディアメールを記憶することと,
前記音声と動画像をアイコンに置き換え,前記アイコンとリンク付けすることと,
前記アイコンを含むメール本体を前記受信側のクライアント端末に転送することと,
を含む方法。」
(3) 相違点の認定
引用例発明の内容は上記のとおりであるから,相違点4は,以下のとおりと認定されるのが相当である。
「相違点4
本願発明では,ストリーミング可能なメディア構成要素をセッション記述ファイルに置き換え,「ただし前記セッション記述ファイルは,受信ユーザ・エージェントが,ストリーミング・セッションをスタートして,ストリーミング可能なメディア構成要素を検索できるようにする情報を含」んでおり,このセッション記述ファイルは第2のマルチメディア・メッセージに含まれて,受信ユーザ・エージェントに送信されるのに対し,引用例発明では,音声,動画像をアイコンに置き換え,このアイコンとリンク付けし,アイコンはメール本体に含まれて受信側のクライアント端末に転送されるが,アイコンと共に何らかの情報も転送されるかが不明であり,また,それがどのような情報であるかが特定されていない点。」
4 相違点4の容易想到性の判断の誤り(取消事由3)について
(1) 相違点4の容易想到性の判断
以上のとおり,審決のした相違点4の認定には誤りがあり,相違点4は上記3(3)のとおり認定されるべきであるが,このような認定を前提とする相違点4も,容易想到であったと解される。その理由は,以下のとおりである。
ア 本願優先日前に刊行された文献である「MPEG-4over RTP配信システムとQoS制御方式」(奥村誠司ほか著。「マルチメディア,分散,協調とモバイル(DICOMO 2000)シンポジウム」平成12年6月)(甲7)の434頁「3.MPEG-4over RTP配信システムの構成」には,「ネットワーク再生では,コンテンツの詳細データや配信サーバ情報をSDP(Session Description Protocol(RFC2327))で記述したMVX(Movie VideoeXtention)ファイル(独自)を配信サーバ/Webサーバ/ローカルホストから得る。クライアントはMVXに記述されているコンテンツの詳細データや配信サーバ情報を解析し,配信サーバとセッション確立とコンテンツデータの受信準備を行う。リクエストを受けた配信サーバは,そのコンテンツデータのMP4ファイルをロードして,ビデオデータ(MPEG-4)やオーディオデータ(G.723.1,MP3など)をRTPパケットに乗せて送信する。クライアントはそのRTPパケットを受信し,再生(バッファリング,デコード)を行う。また,ネットワーク再生時の配信サーバとのセッション管理や再生・停止・一時停止等のストリーミング制御は,標準化されているRTSP(Real-Time Streaming Protocol)[5]を用いており,RTSP標準のサーバやクライアントへの相互接続を可能にしている。」との記載がある。
また,本願優先日前に刊行された文献である「モバイルマルチメディア信号処理技術特集 マルチメディア配信技術」(吉村健ほか著。NTT DoCoMo テクニカル・ジャーナルVol.8 No.4)(甲8)の46頁「3.マルチメディア配信制御技術 3.1 セッション制御」には,「そのようなマルチメディアセッションの制御を可能とするプロトコルとしてRTSP(Real Time Streaming Protocol)[5]がIETFのRFC2326で規定されている。」「図5にRTSPのシーケンス例を示す。クライアントはDESCRIBEメソッドを含むリクエストメッセージを送信すると,サーバは対象となるメディアのセッション記述をSDP(Session Description Protocol)[6]などを用いて返送する。そして,クライアントがSETUPメッセージを送信することにより,サーバのリソースが確保され,同時にセッションが開始する。続いてPLAYメッセージによりメディアデータの伝送が開始され,PAUSEメッセージによりメディアデータ伝送が中断される。最後に,TEARDOWNメッセージによりサーバのリソースが開放され,セッションが終了する。」との記載がある。
また,RTSPは,連続メディアの制御ができる代表的なプロトコルであり,平成10年(1998年)4月にRFC(Standards Track)になっていること,クライアントは,サーバにDESCRIBEメソッドを送り,サーバに要求されたURLによって識別されたプレゼンテーションやメディアオブジェクトの記述を取り寄せること,SDPは,RTSPにおいて,セッション記述のためのプロトコルとして使用されており,RTSPとほぼ同じ時期にRFCとなったことが認められる(乙3)。
イ 上記文献の記載によると,本願優先日当時,ストリーミングにおいては,RTSPのプロトコルが標準化されており,RTSPでは,クライアントからのDESCRIBEメソッドに応じて,サーバから,SDPなどを用いて,ストリーミング可能なメディアのURL等のセッション記述がクライアントに送信され,これに対して,クライアントがSETUPメソッド,PLAYメソッドを送信することにより,ストリーミング・セッションが開始され,指定されたメディアが検索され,そのデータの伝送が開始されて,再生が開始されると認められる。そして,上記「セッション記述」は,ストリーミング可能なメディアを送信するために作成されるものであり,ストリーミング・セッションを開始させ,また,該当するメディアを検索できるようにする情報を含むものであると認められ,本願発明の「セッション記述ファイル」に相当するといえる。
前記のとおり,引用例発明は,リアルタイム再生(ストリーミング)に関する発明であり,引用例発明では,音声,動画像のデータの代わりに,音声,動画像とリンク付けされたアイコンが含まれたメール本体が受信側のクライアント端末に転送されるが,ユーザが再生要求の対象となる音声,動画像のアイコンを指定することにより,再生プログラムが起動し,当該音声,動画像が検索され,リアルタイム再生が行われる。そして,上記アイコンは,ユーザがアイコンを指定した際,音声,動画像の検索を可能にするために音声,動画像とリンク付けされているものである。
したがって,引用例に接した当業者が,ストリーミングにおける本願優先日当時の上記周知技術に基づいて,音声,動画像アイコンをメール本体に含めて受信側クライアント端末に転送するとともに,音声,動画像の検索情報等を含んだ上記「セッション記述」をメール本体に含めて転送することにより,本願発明の相違点4に係る構成を採用することは容易であると認められる。
(2) 原告の主張に対して
原告は,引用例における,音声,動画像アイコンが有する,動画像の内容把握を容易にする能力が,「セッション記述ファイル」にあるかは不明であり,また,アイコンが指定された否かの判断等に「セッション記述ファイル」が技術的に役立つか否かは不明であるから,当業者が相違点4に係る構成を採ることが容易であったとはいえないと主張する。
しかし,前記周知技術は,引用例に記載されたリアルタイム再生に関する,本願優先日当時において標準化されていた技術であり,当業者が引用例発明に前記周知技術を組み合わせることは容易であるといえる。
5 結論
以上のとおり,原告主張の取消事由は理由がなく,審決に誤りはない。その他,原告は縷々主張するが,いずれも理由がない。よって,原告の請求を棄却することとして,主文のとおり判決する。
(裁判長裁判官 飯村敏明 裁判官 八木貴美子 裁判官 小田真治)
file_2.jpg別紙