【事件の表示】
　特願２００６−２０３８３９「マルチメディア・メッセージ送信方法、マルチメディア・メッセージ・システム、マルチメディア・メッセージ・システムのサーバおよび無線端末」拒絶査定不服審判事件〔平成１８年１１月１６日出願公開、特開２００６−３１４１３５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年１１月６日（パリ条約による優先権主張外国庁受理１９９９年１１月５日、フィンランド；１９９９年１２月２３日、フィンランド）を国際出願日とする特願２００１−５３４８１３号の一部を平成１８年７月２６日に新たな特許出願としたものであって、平成２３年１月１１日付けで拒絶査定がなされ、同年５月１８日付けで拒絶査定不服審判の請求がなされ、当審において、平成２４年６月１２日付けで拒絶理由通知がなされ、同年１２月１９日付けで手続補正がなされたものである。 
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」と呼ぶ。）は、平成２４年１２月１９日付けの手続補正書の請求項１に記載された、次のとおりのものである。
「　　【請求項１】
　マルチメディア・メッセージを受信して記憶し、
　サーバに記憶された無線端末についてのユーザ・プロファイルから、該無線端末の特性についての情報を読み出すことであって、該情報が、ある形式のマルチメディア構成要素を処理するための前記無線端末の能力についての情報を含む、ことと、
　読み出された前記無線端末の特性にしたがって前記無線端末が処理できるマルチメディア・メッセージの少なくとも一つの構成要素を識別し、
　前記少なくとも一つの構成要素を前記無線端末へ送信する、
ことを含む方法。」
　
３．理由Ａ（拡大先願）
（１）先願明細書等記載発明 
　平成２４年６月１２日付けの拒絶理由通知に引用した、本願の優先日前の他の出願であって、本願の優先日後に出願公開された特願平１１−２８０９９５号（特開２００１−１０３５７１号公報）の願書に最初に添付した明細書及び図面（以下、「先願明細書等」と呼ぶ。）には、次の事項が記載されている。 
　
「【０００１】
【発明の属する技術分野】この発明は、移動体通信サービスシステムにおける各端末に対して適切なサービスを提供するシステムに関するものである。
【０００２】
【従来の技術】図１は一般的な移動体通信サービスを行うシステムの構成を示した図である。従来は、携帯端末１０１からの各種サービスの要求があると、移動体通信交換機１１０３は、ホームメモリ１０４内に確保された加入者情報図２を読み出し、サービスプロバイダ１０７との情報サービス加入契約２１１をチェックした上で、サービスプロバイダへのアクセスが許されている場合には、携帯端末１０１がサービスプロバイダ１０７との間で直接サービスを受けるようになっている。即ち、交換機１０３は、ＧＷサーバ１１０５との接続を行った上で、各携帯端末に対してＩＰアドレスの割り当てを行ない、以後、携帯端末とプロバイダとの間での情報交換を可能としていた。このようなシステムにおいては、各携帯端末は、それぞれの携帯端末に適した情報入手を行なうために、プロバイダ上で情報検索を行なう必要があり、必要な情報を見つけるまでに多大な時間を要する。また、必要な情報を見つけた場合においても、静止画、動画等携帯端末では処理できない情報を含んでいるため情報を取出すことができずエラーとなってしまう、あるいは、これら情報に対応している場合においてもデータ量が非常に大きいために多大な通信時間を要する。
【０００３】さらには、情報を取り出す端末は、携帯電話、携帯端末（携帯電話よりも大きな表示画面、あるいは、動画等の表示機能を持つもの）だけではなく、オフィスあるいは家庭で使用するＰＣ端末までを含め、多種多様な端末が対象となる。ユーザは、様々な情報へアクセスを行う際に、これら自身が使用する端末を意識して、その端末に応じて、自らが取り出す情報を取捨選択しなければならない。」
　
「【０００７】
【発明が解決しようとする課題】従来の移動体通信用交換機は、以上のように構成されており、端末毎のサービスは各端末に任せていた。従って各端末では、提供されるサービスの内容や、自身の端末が持つ制約を自分で把握して、適切な内容を端末側で選択して、交換機側に要求する手順になっている。従って先ず、必要な情報を見つけ出すまでに多大の時間がかかり、また交信のデータ量が過大になることも多いことがあるという課題があった。更に、移動体端末はメモリ容量の制約から、交信データ量が小さくなりがちで、詳細を見る他の端末との選択の整合性をユーザが検討しなくてはならず、データの重複が生じたり、ユーザの負荷が過大になるという課題もあった。
【０００８】この発明は上記の課題を解決するためになされたもので、端末側はプログラムのダウンロードを行わないパッシブな一般的な端末であっても、サーバ例から周囲条件に応じて適切なデータを上記各端末に選択して、送信するシステムに関するものである。また更に、同一データを異なる端末間で扱う際の整合性を高め、かつデータの重複を少なくすることも目的とする。
【０００９】
【課題を解決するための手段】この発明に係る移動体通信サービス提供システムは、受動動作をする携帯端末を接続する移動体通信ネットワークと、パーソナルコンピュータ（ＰＣ）とサーバとを接続するインターネットとを結合したシステムにおいて、移動体通信ネットワークとインターネットとを結合するゲートウエイ（ＧＷ）サーバ相当に、携帯端末毎の特性を記憶する端末特性情報テーブルと、各携帯端末毎にサービスを行う条件を規定したフィルタリングポリシィ情報テーブルとを備えて、携帯端末またはＰＣからのサービス要求を受けると、端末特性情報テーブルとフィルタリングポリシィ情報テーブルとを参照して、必要データを選択・加工して、要求元の携帯端末またはＰＣに送信するようにした。」
　
「【００１５】以後、実際にフィルタリングを行う過程について、メール配信サービスを例として動作内容を説明する。メール通信サービスの場合、ユーザは個人ＰＣ上でメールの送受信を行うために、通常、インターネットサービス・プロバイダとの間で契約を持ち、そのプロバイダによってメールアドレスが割り当てられる。例えば、ｓｕｚｕｋｉ＠ａｂｃ−ｐｒｏｖｉｄｅｒ．ｎｅ．ｊｐのメールアドレスが割り当てられる。また、移動体携帯電話網におけるメール通信サービスは、携帯電話の電話番号をユーザ名として、メールアドレスが割り当てられる。例えば、０１２３４５６７８９＠ｄｏｃｏｍｏ．ｎｅ．ｊｐのメールアドレスが割り当てられる。このため、通常ユーザは、インターネットサービス・プロバイダのメールアドレスに届くメールを、移動体携帯電話網にて受け取れるようにするため、ｓｕｚｕｋｉ＠ａｂｃ−ｐｒｏｖｉｄｅｒ．ｎｅ．ｊｐのメール設定ファイルを変更して、０１２３４５６７８９＠ｄｏｃｏｍｏ．ｎｅ．ｊｐへメールのフォワードの設定を行う（ＵＮＩＸの場合には、．ｆｏｒｗａｒｄファイルにフォワードすべきメールアドレスを記述する）。あるいは、携帯電話サービス網からプロバイダ内メールサーバに対して、定期的にアクセスを行い、メールを取り出す。しかし、いづれの場合にも、移動体携帯電話網内メール配信システムは、単にフォワードされた情報を、携帯電話網で定められたルールに従い、予め決められたサイズで切り捨てるものとなっている。
【００１６】以後のステップでは、本実施の形態でのフィルタリング方式を説明する。まずは、フィルタリングを実際に行う際に必要となる３つの情報（端末特性情報１０６１図６、端末状態情報１０５０図５、フィルタリングポリシィ情報１０６２図７）を取り出すまでの手順を説明する。メール配信サービス動作の場合、アプリケーションとして指定されているメール内容フィルタリングプログラム１０１１によってサービスプロバイダ内メールサーバソフト１０１２に、携帯端末を使用しているユーザ（ユーザＩＤ＝携帯電話番号）のメールアドレス８０２に、他ＰＣ等からメールが届いているかどうかを図１１のステップＳ１０１で、定期的に確認する。メールが届いている場合、ステップＳ１０３でフィルタリングプログラム１０１１によって、端末特性情報１０６１図６を読み込む。更に、Ｓ１０４でフィルタリングプログラム１０１１によってフィルタリングポリシィ情報１０６２図６を読み込む。
【００１７】その後、Ｓ１０５でフィルタリングプログラム１０１１は、端末特性情報１０６１と、フィルタリングポリシィ情報１０６２からメール用フィルタリングテーブル１０６３図８を作成する。以下、具体的な作成方法につき、具体例を使用して説明を行う。フィルタリングプログラム１０１１は、端末特性情報１０６１内のマルチメディア対応性４０８を確認し、端末に送付するデータタイプ７０１を決定する。即ちＳ１０６で、フィルタリングポリシィ情報１０６２上、情報コンテンツの種類６０１には、静止画が指定されているが、端末の特性ではテキスト４０８しか受け取れないため、結果として、データタイプとしてはテキストを選択し、データタイプ７０１へ格納する。フィルタリングプログラム１０１１は、Ｓ１０７で、フィルタリングポリシィ情報１０６２内のデータのサイズ６０２と、端末特性情報１０６１内のデータサイズ４０１を確認し、実際に、携帯端末に送付するデータサイズを決定する。この例の場合には、１０文字×４列＝４０文字＝８０ｂｙｔｅとなり、これをデータのサイズとして７０２へ格納する。
【００１８】フィルタリングプログラム１０１１は、Ｓ１０８でプロバイダ内メールサーバからメールを取り出す。この場合のプロトコルは、（Ｐ０Ｐ３あるいは、ＩＭＡＰ４）等の、メールアプリケーションに依存して決定される。フィルタリングプログラム１０１１は、添付があれば、Ｓ１０９でメールに添付されているＭＩＭＥ情報などのデータタイプを確認する。それが、テキスト以外であれば図１２のＳ１１１で、例えばＭＩＭＥデータをメールと分離し、ＭＩＭＥデータ部分にデータタイプとサイズを書き込み、ユーザにＭＩＭＥデータが添付されていたことを通知するための情報とする。
【００１９】フィルタリングプログラム１０１１は、メール内容にフィルタリングポリシィ情報１０６２内のフィルタリングキーワード６０４として、この場合”Ｗ−ＣＤＭＡ”が含まれているので、Ｓ１１３でメール送信順番を変更し、優先度を上げる。もし、フィルタリングポリシィ情報１０６２内のフィルタリングキーワード６０４が含まれている場合で、かつ、メールのデータサイズが８０ｂｙｔｅを越える場合には、Ｓ１１５でテキストサイズが８０ｂｙｔｅ以下に収まるように複数メールに分割する処理を行う。またもし、フィルタリングポリシィ情報１０６２内のフィルタリングキーワード６０４が含まれていない場合で、かつ、メールのデータサイズが８０ｂｙｔｅを越える場合には、Ｓ１１６でテキストサイズが８０ｂｙｔｅ以下に収まるように切り捨て処理を行う。
【００２０】フィルタリングプログラム１０１１は、移動体携帯電話網メール配信システムのメールサーバソフト１０１０に対して、Ｓ１１８でフィルタリングされた結果のメールを送信する。尚、フィルタリングプログラム１０１１は、メールクライアントソフト１００２からのメール取り出し要求とは別のタイミングで、定期的にフィルタリングの処理を行う。フィルタリングの結果としてのメールは、メールクライアントソフト１００２が、ＧＷサーバ１０５上のメールサーバソフト１０１０にアクセスすることにより、携帯端末１０１へ送信されることになる。携帯端末１０１上メールクライアントソフト１００２は、メール送受信を行うために、ブラウザ１００３から得た処理結果を表示する。
【００２１】上述したように、フィルタリングプログラム１０１１により、携帯端末１０９には、端末特性情報１０６１図６に従い、かつ、その内容の要点のみを簡潔にした情報を表示することが可能である。また、現時点で使用していた端末特性情報に応じた情報を提供するために、情報のフィルタリングを行うこと、この場合には、静止画ではなく、テキスト情報を提供した。同じユーザが、別の時点で、静止画の表示可能な携帯端末を使用した場合には、フィルタリングポリシィ情報１０６２図７に従った、即ちユーザの欲する静止画の情報を提供できる。こうして、ユーザの要求と、その時点で使用している携帯端末の特定とを独立させて情報の提供が行えて、ユーザが要求する条件に応じた適切な情報を提供できる。尚、移動通信交換機１０３が、ＧＷサーバ１０５を兼ねる構成とすることもできる。」
　
　そして、上記記載事項を関連図面と技術常識に照らせば、以下のことがいえる。
ア．先願明細書等に示される「ＧＷサーバ１０５」は、プロバイダ内メールサーバからメールを取り出し、予め記憶された「端末特性情報テーブル」と「フィルタリングポリシィ情報テーブル」を参照して、必要データを選択・加工し、要求元の携帯端末に送信する機能を有するものである（段落【０００９】、【００１８】、【００２０】の記載を特に参照）。
　そして、その「端末特性情報テーブル」内に「マルチメディア対応性４０８」の欄がある（図６参照）こと等からも明らかなように、上記「メール」は、当然に「マルチメディア・メッセージ」である。
　また、上記「ＧＷサーバ１０５」がプロバイダ内メールサーバからメールを取り出すことは、上記「ＧＷサーバ１０５」が上記「メール」を受信することに他ならず、上記「ＧＷサーバ１０５」が「必要データを選択・加工し、要求元の携帯端末に送信する」ために上記「メール」を記憶していることは明らかである。
イ．上記「ＧＷサーバ１０５」が、上記のように「端末特性情報テーブル」と「フィルタリングポリシィ情報テーブル」を参照して、必要データを選択・加工するに当たり、上記「端末特性情報テーブル」から上記「マルチメディア対応性４０８」の欄の情報を読み出すことも明らかである。
　また、上記「マルチメディア対応性４０８」の欄の情報は、「携帯端末の特性についての情報」の一種であり、「ある形式のマルチメディア構成要素を処理するための携帯端末の能力についての情報」の一種でもある。
ウ．先願明細書の段落【００１８】に示される「ＭＩＭＥデータを分離されたメール」は、「携帯端末が処理できるマルチメディア・メッセージの構成要素」の一種であり、上記「ＧＷサーバ１０５」において上記「マルチメディア対応性４０８」の欄の情報にしたがって識別され、上記「携帯端末」へ送信されるものである。
　
　したがって、先願明細書等には、以下の発明（以下、「先願明細書等記載発明」と呼ぶ。）が記載されているといえる。
「マルチメディア・メッセージを受信して記憶し、
　ＧＷサーバに記憶された端末特性情報テーブルから、携帯端末の特性についての情報を読み出すことであって、該情報が、ある形式のマルチメディア構成要素を処理するための前記携帯端末の能力についての情報を含む、ことと、
　読み出された前記携帯端末の特性にしたがって前記携帯端末が処理できるマルチメディア・メッセージの少なくとも一つの構成要素を識別し、
　前記少なくとも一つの構成要素を前記無線端末へ送信する、
ことを含む方法。」
　
（２）対比
　先願明細書等記載発明と本願発明とを対比すると、以下のことがいえる。
ア．先願明細書等記載発明の「ＧＷサーバ」、「携帯端末」は、それぞれ、本願発明の「サーバ」、「無線端末」に相当する。
イ．本願明細書の段落【００１４】の記載等を参酌すると、本願発明でいう「無線端末についてのユーザ・プロファイル」は、「無線端末ごとの情報であって、無線端末の特性についての情報を含む情報」といった程度の意味に解されるのに対し、先願明細書等の段落【０００９】等の記載によれば、先願明細書等記載発明の「端末特性情報テーブル」も「携帯端末（無線端末）ごとの情報であって、携帯端末（無線端末）の特性についての情報を含む情報」であると解されるから、先願明細書等記載発明の「端末特性情報テーブル」は、本願発明の「無線端末についてのユーザ・プロファイル」に相当する。
　なお、この相当関係は、平成２４年６月１２日付けの拒絶理由通知で示し、審判請求人も異論を唱えていない相当関係である。
　
　したがって、先願明細書記載発明と本願発明とは、
「マルチメディア・メッセージを受信して記憶し、
　サーバに記憶された無線端末についてのユーザ・プロファイルから、該無線端末の特性についての情報を読み出すことであって、該情報が、ある形式のマルチメディア構成要素を処理するための前記無線端末の能力についての情報を含む、ことと、
　読み出された前記無線端末の特性にしたがって前記無線端末が処理できるマルチメディア・メッセージの少なくとも一つの構成要素を識別し、
　前記少なくとも一つの構成要素を前記無線端末へ送信する、
ことを含む方法。」
である点で一致し、両者の間に相違点はないといえる。
　
（３）まとめ  
　以上のとおりであるから、本願発明は、先願明細書等記載発明と同一の発明である。
　また、本願発明の発明者は先願明細書等記載発明の発明者と同一でなく、本願の出願時に、その出願人は上記他の出願の出願人と同一でない。
　したがって、本願発明は、特許法第２９条の２の規定により特許を受けることができないものである。
　
　なお、上記理由Ａに関し、審判請求人は、平成２４年１２月１９日付けの意見書において、先願明細書等は「マルチメディア・メッセージの少なくとも一つの構成要素を無線端末へ送信する」ことを開示するものではない旨主張しているが、上記（１）のウ．で検討したところによれば、先願明細書等には「マルチメディア・メッセージの少なくとも一つの構成要素を無線端末へ送信する」ことも開示されているといえる。
　したがって、審判請求人の上記主張は採用できない。
　
４．理由Ｂ−１（進歩性欠如その１）
（１）引用文献２記載発明
　平成２４年６月１２日付けの拒絶理由通知に「引用文献２」として引用した特開平１１−２０３２１６号公報（本審決においても、上記拒絶理由通知に合わせ、以下、「引用文献２」と呼ぶ。）には、次の事項が記載されている。
　
「【０１０７】上記説明では、ユーザ自身が使用機種を選択して、サーバシステム２に通知したが、予め記憶部１３等に機種コードを登録しておき、ステップＳ８２でＩＤコードとパスワードを送信する際に、或いは、Ｓｕｂｊｅｃｔ要求信号を送信する際に、記憶されている機種コードを読み出して、自動的に送信するようにしてもよい。機種コードとしては、前述の機種のタイプを示すものに限定されず、機種そのもの、例えば、製造会社と機種名等を指定するようにしてもよい。この場合、サーバシステム２の機種テーブルには、機種とその表示サイズを登録する。また、クライアントからサーバに機種コードを送信する代わりに、１行当たりの表示文字数をサーバシステム２に通知するようにしてもよい。
【０１０８】上記説明では、メールの１行当たりの表示文字数を使用機種の表示形態に応じて変換したが、使用機種に応じて加工する対象は任意である。電子メールに添付されている添付ファイルのデータ形式がクライアント１−１が処理できない形式の場合、添付ファイルを、削除してもよい。この場合、機種テーブルには、使用機種毎に、処理できるファイル形式の一覧を登録しておき、この一覧に登録されていない形式のデータからなる添付ファイルは削除する。」
　
　そして、上記記載事項を引用文献２のその他の記載箇所の説明と技術常識に照らせば、以下のことがいえる。
ア．引用文献２でいう「電子メール」は、「メッセージ」の一種である。
イ．引用文献２でいう「サーバシステム２」は、「サーバ」の一種である。
ウ．引用文献２でいう「機種テーブル」は、「端末についてのプロファイル」の一種であって、メッセージ構成要素を処理するための端末の能力についての情報を含む端末の特性についての情報を含むものである。
エ．引用文献２でいう「添付ファイル」は、「メッセージ構成要素」の一種である。
　
　したがって、引用文献２には、実質的に以下の発明（以下、「引用文献２記載発明」という。）が記載されているといえる。 
「メッセージを受信して記憶し、 
　サーバに記憶された端末についてのプロファイルから、該端末の特性についての情報を読み出すことであって、該情報が、ある形式のメッセージ構成要素を処理するための前記端末の能力についての情報を含む、ことと、 
　読み出された前記端末の特性にしたがって前記端末が処理できるメッセージの少なくとも一つの構成要素を識別し、 
　前記少なくとも一つの構成要素を前記端末へ送信する、ことを含む方法。」 
　
（２）対比
　本願発明と引用文献２記載発明を対比すると、両者の間には、以下の一致点、相違点があるといえる。
　
＜一致点＞
「メッセージを受信して記憶し、 
　サーバに記憶された端末についてのプロファイルから、該端末の特性についての情報を読み出すことであって、該情報が、ある形式のメッセージ構成要素を処理するための前記端末の能力についての情報を含む、ことと、 
　読み出された前記端末の特性にしたがって前記端末が処理できるメッセージの少なくとも一つの構成要素を識別し、 
　前記少なくとも一つの構成要素を前記端末へ送信する、ことを含む方法。」
である点。
　
＜相違点1＞ 
　本願発明の方法が取り扱う「メッセージ」は「マルチメディア・メッセージ」であるのに対し、引用文献２記載発明が取り扱う「メッセージ」は「マルチメディア・メッセージ」と呼び得るものとは限らない点。
　
＜相違点２＞ 
　本願発明の「端末」は「無線端末」であるのに対し、引用文献２記載発明の「端末」は「無線端末」ではない点。 
　
＜相違点３＞ 
　本願発明の「端末についてのプロファイル」は、「ユーザ・プロファイル」と呼ばれるものであって、端末の機種毎ではなく端末毎に設定される情報であると解されるものであるのに対し、引用文献２記載発明の「端末についてのプロファイル」は、端末の機種毎に設定されるものと解される「機種テーブル」である点。
　
（３）判断
ア．＜相違点１＞＜相違点２＞について 
 　「マルチメディア・メッセージ」と呼び得るメッセージや、それを「無線端末」へ送信する方法自体は周知であり、引用文献２記載発明の方法をそのような周知の「マルチメディア・メッセージ」を「無線端末」に送信するものとできない理由もないから、引用文献２記載発明が取り扱う「メッセージ」を「マルチメディア・メッセージ」とするとともに引用文献２記載発明の「端末」を「無線端末」とすることは、当業者が容易に想到し得たことである。 
イ.＜相違点３＞について
　サーバにおいて端末毎に異なる処理を実行させるべく、本願発明でいう「ユーザ・プロファイル」に相当するものをサーバに記憶させておくことは、平成２４年６月１２日付けの拒絶理由通知に「引用文献３」として引用した国際公開第９９／５６４３１号（本願明細書に【特許文献２】として引用された文献である。）（本審決においても、上記拒絶理由通知に合わせ、以下、「引用文献３」と呼ぶ。）に載されていること、引用文献２記載発明において実現されているサーバの処理内容に照らすと、引用文献２記載発明においても、サーバにおける処理を「機種毎」ではなく「端末毎」とするのが望ましい場合があることは容易に想定されること、そのような場合に引用文献２記載発明の「端末についてのプロファイル」（機種テーブル）を引用文献３に示されるような「ユーザ・プロファイル」と呼ばれるものにすべきことは当然のことであること、等の事情を勘案すると、引用文献２記載発明の「端末についてのプロファイル」（機種テーブル）を、本願発明でいう「ユーザ・プロファイル」に相当するものとすることも、当業者が容易に想到し得たことである。 
ウ．本願発明の効果について
　本願発明によりもたらされる効果は、引用文献２、３に記載された事項から当業者が予測し得る程度のものであり、本願発明の進歩性を肯定する根拠となり得るものではない。
　
（４）まとめ  
　以上のとおりであるから、本願発明は、引用文献２記載発明及び引用文献３に記載された事項に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものである。
　
　なお、上記理由Ｂ−１に関し、審判請求人は、平成２４年１２月１９日付けの意見書において、下記ア．、イ．の趣旨の主張をしているが、下記（ア）、（イ）の理由で採用できない。
ア．引用文献２は、「ユーザ・プロファイルから無線端末の特性についての情報を読み出すこと」を開示していない。
イ．引用文献２は、「読み出された特性に基づいて、前記無線端末が処理できるマルチメディア・メッセージの少なくとも一つの構成要素を識別」すること、「マルチメディア・メッセージの少なくとも一つの構成要素を無線へ送信する」ことを開示していない。
　
（ア）上記ア．の主張について
　上記ア．の主張は、平成２４年６月１２日付けの拒絶理由通知でも取り上げた上記＜相違点３＞が本願発明と引用文献２記載発明の間に存在していることを主張するに過ぎないものであって、上記＜相違点３＞についての当審の判断が誤っていることを主張するものではないから、上記理由Ｂ−１についての当審の判断を左右するものではない。
　
（イ）上記イ．の主張は、平成２４年６月１２日付けの拒絶理由通知にも示した上記引用文献２記載発明についての認定が誤っていることを主張するものと解されるが、同拒絶理由通知にも示した上記（１）記載の認定根拠（上記（１）の項の「したがって、・・・」の前の記載内容）を踏まえたものではない。
　上記（１）記載の認定根拠を踏まえれば、引用文献２には上記引用文献２記載発明についての開示があるといえる。
　審判請求人は、上記イ．の主張に関連し、「引用文献２は、『メールを．．．ブラウザが読むことができるＨＴＭＬ文フォーマットに』変換することを開示しています。引用文献２は、前記無線端末で処理することができる少なくとも一つの構成要素を送信すること、ではなく、メッセージを異なる状態に変換することを開示していると考えられます。」とも主張しているが、引用文献２にメッセージを異なる状態に変換することの開示があることは、引用文献２に上記引用文献記載発明の開示がないことを何ら意味しないから、この主張は、上記引用文献２記載発明についての認定が誤っていることの根拠にはならない。
　
５．理由Ｂ−２（進歩性欠如その２）
（１）引用文献２記載発明
　平成２４年６月１２日付けの拒絶理由通知に「引用文献４」として引用した国際公開第９８／１９４３８号（本審決においても、上記拒絶理由通知に合わせ、以下、「引用文献４」と呼ぶ。）の特に第４ページ第１０行〜第５ページ第２行の記載を参照すると、そこでいう「If limitation in the presentation capabilities of the user terminal make it necessary to exclude one or more parts of a certain multimedia message」（第４ページ第２６〜２９行）中の「exclude」は、「端末が表示できないマルチメディア・メッセージの構成要素を端末へ転送することから排除すること」を意味していると解するのが妥当で、該「端末が表示できないマルチメディア・メッセージの構成要素を端末へ転送することから排除すること」は、逆に見れば、「端末が処理できると識別されたマルチメディア・メッセージの構成要素を端末に転送するようにする」ことに他ならない。 
　したがって、引用文献４には、実質的に以下の発明（以下、「引用文献４記載発明」という。）が記載されているといえる。 
「マルチメディア・メッセージを受信して記憶し、 
　動的ダイアログにより取得された、ある形式のマルチメディア構成要素を処理するための無線端末の能力についての情報を含む前記無線端末の特性にしたがって前記無線端末が処理できるマルチメディア・メッセージの少なくとも一つの構成要素を識別し、 
　前記少なくとも一つの構成要素を前記無線端末へ送信する、 
ことを含む方法。」
　
（２）対比
　本願発明と引用文献４記載発明を対比すると、両者は以下の点で相違し、その余の点で一致する。 
 ＜相違点＞ 
 　本願発明の方法は、「無線端末の特性」を「サーバに記憶された無線端末についてのユーザ・プロファイルから読み出す」ことによって得るのに対し、引用文献４記載発明の方法は、「無線端末の特性」を「サーバに記憶された無線端末についてのユーザ・プロファイルから読み出す」ことによってではなく、動的ダイアログによって得る点。 
　
（３）判断
ア．上記＜相違点＞について
　以下の事情を考慮すると、引用文献４記載発明において動的ダイアログによって得ている「無線端末の特性」を「サーバに記憶された無線端末についてのユーザ・プロファイルから読み出す」ことによって得るようにすることは、当業者が容易に推考し得たことというべきである。 
（ア）上記４．の（３）のイ．でも述べたように、本願発明の「ユーザ・プロファイル」に相当するものをサーバに記憶させておくことは、引用文献３に載されている。 
（イ）引用文献４記載発明において動的ダイアログにより取得される「無線端末の特性」と、引用文献３に示されるサーバ上に記憶される「ユーザ・プロファイル」は、共に、サーバにおいて端末毎に異なる処理を実行させるさせるための情報であって、ある形式のマルチメディア構成要素を処理するための無線端末の能力についての情報を含む情報であるという意味において共通するものである。 
（ウ）引用文献４記載発明において動的ダイアログにより取得される「無線端末の特性」を引用文献３に示されるようにサーバ上に記憶される「ユーザ・プロファイル」から読み出すことにより得るようにすることが有用な場合があり、かつそのようにできない理由がないことは、当業者に自明である。（エ）以上のことは、引用文献４記載発明において動的ダイアログによって得ている「無線端末の特性」を「サーバに記憶された無線端末についてのユーザ・プロファイルから読み出す」ことによって得るようにすることが当業者が容易に推考し得たことであることを意味している。 
　
イ．本願発明の効果について
　本願発明によりもたらされる効果は、引用文献４、３に記載された事項から当業者が予測し得る程度のものであり、本願発明の進歩性を肯定する根拠となり得るものではない。
　
（４）まとめ  
　以上のとおりであるから、本願発明は、引用文献４記載発明及び引用文献３に記載された事項に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものである。
　
　なお、上記理由Ｂ−２も平成２４年６月１２日付けの拒絶理由通知で通知した理由であり、審判請求人はそれに対する反論の機会を十分に有していたはずであるが、審判請求人は何ら反論していない。
　
６．むすび 
　以上のとおり、本願発明は、特許法第２９条の２の規定により特許を受けることができないものであると共に、特許法第２９条第２項の規定によっても特許を受けることができないものである。  
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。  
　よって、結論のとおり審決する。