【事件の表示】
　特願２００４−５０６２６１「マルチメディアメッセージの伝送効率化準備処理のための方法および無線通信装置」拒絶査定不服審判事件〔平成１５年１１月２７日国際公開、ＷＯ０３／９８８９４、平成１７年１０月　６日国内公表、特表２００５−５３０３８１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明
　本件出願は、２００３年５月８日（パリ条約による優先権主張外国庁受理２００２年５月１７日、ドイツ連邦共和国）を国際出願日とする出願であって、平成２０年１０月１０日付けで拒絶査定がなされ、これに対し平成２１年１月１５日付け拒絶査定不服の審判請求がなされたものであって、その特許請求の範囲の請求項１に係る発明(以下、「本願発明」という。)は、平成１６年１１月１７日付けの特許協力条約第３４条補正の翻訳文提出書により補正された特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された事項により特定される以下のとおりのものであると認める。
　
「マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
　ａ）送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求め、
　ｂ）送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を、有効データ容量に関して段階づけられている料金体系（ＧＴＭ）の１つの価格クラス（Ｐｘ）に割り当て、
　ｃ）送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）に対してまえもって設定可能な価格上限および／または有効データ容量上限（ＳＰｘ，ＳＧｘ）を場合によっては超過したときには、送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）においてもともと生じていた有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを提供して、送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）を有効データ容量に関して段階づけられている前記料金体系（ＧＴＭ）においていっそう低い価格クラス（Ｐｘ）に属させることを特徴とする、
　マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法。」
　
２．引用発明
　原審の拒絶の理由に引用された特開２００２−９８１８号公報(以下、「引用例」という。)には、「電子メール処理方法およびメールサーバ」に関し、図面とともに以下の事項が記載されている。
　
ア．「【００１０】しかしながら、特定の通信端末、特にデータ記憶容量が比較的小さい携帯電話のような通信端末では、受信できるデータ量に上限を設けているものがある。このような通信端末では、その上限を超えた文書部分は欠落してしまい内容を認識することができない、という問題があった。返信者の返信の仕方にもよるが、返信メールの本文の最初に引用文を配置し、それに続けて自分の返答文を記載しているような場合、引用文の存在のためにデータ容量が増加し、肝心の返信の内容が途中で途切れるというような事態が生じうる。
【００１１】また、携帯電話の種類によっては、メールの受信時にもデータ量や時間に応じて課金される場合がある。このような場合には、受信データ量は小さいことが好ましい。
【００１２】本発明は、このような背景においてなされたものであり、その目的は、電子メールを受信する側の通信端末に対して送信されたメールのデータ量を縮小することができる電子メールの処理方法を提供することにある。
【００１３】本発明の他の目的は、電子メールを受信する側の通信端末において受信データ量の制限がある場合に、その制限に合わせてデータ量を縮小することができる電子メールの処理方法、およびこの方法を実施するメールサーバ、並びに通信端末を提供することにある。」（第３頁第４欄第２２−４５行）
　
イ．「【００２５】
【発明の実施の形態】以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００２６】図１に、本発明が適用されるシステム全体の概略構成を示す。このシステムでは、前述した携帯電話２等の通信端末はメールサーバ１０と接続され、このメールサーバ１０が、インターネットのような通信媒体２０を介してパソコン３０等の他の通信端末と電子メールの授受を行うことができるようになっている。携帯電話２とメールサーバ１０との間は、本実施の形態では、パケット通信網により接続され、メールの送受信ともにデータ量で課金される場合を想定している。但し、本発明はこれに限定されるものではない。図１では、パソコン３等の通信端末をインターネット２０に直接接続して示しているが、インターネットプロバイダ等のメールサーバ（図示せず）を介して接続されてもよい。
【００２７】本実施の形態では、メールサーバ１０において受信された携帯電話２宛のメールに対して、後に詳述するデータ縮小処理を必要に応じて行う。」（第４頁第６欄第３０−４８行）
　
　ウ．「【００２８】図２は、図１に示したシステム内のメールサーバ１０の概略の構成を示すブロック図である。この図において、主制御部１１０は、メールサーバ１０の全体の制御を司る部位である。メール受信部１１１は、ある携帯電話２から他の携帯電話２宛へ送信された電子メール、および、外部のパソコン３０等から携帯電話２宛に送信された電子メールを受信する部位である。メール記憶部１１２は、この受信された電子メールを一時的に記憶する部位である。縮小ルール記憶部１１３は、本発明のデータ縮小を行うための縮小ルールを記憶する部位である。この縮小ルールの詳細については、後述する。機種依存情報記憶部１１４は、縮小処理を必要とする携帯電話２等の機種毎の縮小処理関連の情報を記憶する部位である。サイズ管理部１１５は、携帯電話２宛のメールのデータ量が、当該携帯電話２の機種の受信メールの上限値（またはユーザによる設定値）を超えているか否かをチェックする部位である。縮小処理部１１６は、所定の場合に、上記縮小ルールに従ってデータの縮小処理を行う部位である。このデータの縮小処理は、後述するように、当該データ量が目標のデータ量に収まるまで段階的に行うことができる。メール送信部１１７は、一旦受信したメールを送信相手先に送信する部位である。ネットワーク部１２０は、通信媒体２０との間の電子メールの送受信の通信制御部である。」（第４頁第６欄第４９行−第５頁第７欄第２２行）
　
エ．「【００３２】ユーザ設定上限サイズ１１３５は、当該携帯電話２の上限サイズの範囲内で自己の携帯電話２の受信メールサイズの上限をユーザが自由に設定可能とするものである。初期的には当該機種のデフォルトの上限サイズ値（例えば全角２５０文字：５００バイト）が設定される。個別ルール１１３６は、当該ユーザが任意の設定した縮小ルールを記憶しておく部位である。アクセス許可メンバーリスト１１３７は、自分の個別ルールにアクセス可能なメンバーを登録したリストである。このリストの載っているメンバーは、このリストの所有者の個別ルール１１３６を参照して、その全部または一部を自己の個別ルールに追加することができる。その際、個別ルールを一覧表示してユーザに選択させるようにしてもよい。このようにして、あるグループのメンバーが同じ個別ルールを共有することができる。」（第５頁第８欄第８−２２行）
　
オ．「【００５５】図６は、メールサーバ１０における基本的な縮小処理の概略手順を示すフローチャートである。
【００５６】図６の処理において、メールサーバ１０は、中継すべきメールを受信したとき、まず、そのメールの宛先が携帯電話２か否かをチェックする（Ｓ１１）。パソコン２等の通信端末宛であれば縮小処理は不要なので、後述するステップＳ１５の処理へ移行する。
【００５７】宛先が携帯電話２であれば、その携帯電話２についての機種依存情報を参照して、メールの上限サイズをチェックする（Ｓ１２）。受信したメールのサイズ（データ量）が上限サイズ以内に収まれば、何もせずに後述するステップＳ１５へ移行する。
【００５８】収まらなければ、段階的にデータ縮小処理を行い（Ｓ１４）、収まるまでこれを繰り返す。収まったら、ステップＳ１５へ進む。最終的に、上限サイズ以内に収まらなければ、メールの一部を削除する。その具体的な方法については後述する。
【００５９】ステップＳ１５では、当該メールを当該送信先の相手（の携帯電話）に送信する。ここでは、ユーザによる指示なしにメール内容を当該携帯電話に送信する。この代わりに、ユーザの指示に応じてこのメールを送信してもよい。
【００６０】図７は、図６の処理をさらに具体化した処理例を示すフローチャートである。この処理では、まず、図５の場合と同様、携帯電話２へのメールについて（Ｓ２１，Ｙｅｓ）、メールのサイズがその上限内に収まっているか否かを調べ、収まっていない場合に（Ｓ２２，Ｎｏ）、初期縮小処理を行う（Ｓ２３）。この初期縮小処理は、例えば上述した共通縮小ルールによるものである。これによって、サイズＯＫとなった場合（Ｓ２４，Ｙｅｓ）、ステップＳ２８へ進む。
【００６１】初期縮小処理によってもサイズＯＫと成らない場合（Ｓ２４，Ｎｏ）、領域判定を行うか否かを前記領域判定可否１１３２により確認する（Ｓ２５）。領域判定を行う場合には、当該領域（例えば引用文領域）の存否および位置をチェックする（Ｓ２６）。これは、メール中の引用を示す記号（例えば””）を見つけることにより行える。次の追加の縮小処理Ｓ２７では、上記Ｓ２６で領域判定した後は当該領域内のみのデータに縮小処理を適用する。この追加の縮小処理は、上述した個別ルールを予め定めた順に適用するものである。特に図示はしないが、この順序もユーザが指定できるようにしてもよい。
【００６２】追加の縮小処理によりサイズＯＫとならなければ（Ｓ２８，Ｙｅｓ）、順次別の個別ルールについてステップＳ２７を繰り返す。適用すべき個別ルールがなくなれば、やむを得ないので上限を超えるメールデータを削除する。この場合には、引用文領域があれば、まず、その領域を対象とする。引用文領域がなければ、あるいは、引用文領域の削除で足りなければ、本文の予め定めた部分を必要量だけ削除する。この予め定めた部分は、例えば最後部部分である。但し、発信者を特定するための情報としての電話番号や電子メールアドレスは削除の対象から外すことが好ましい。
【００６３】その後、メールを送信先の携帯電話へ送信する（Ｓ２９）。
００６４】図６，図７の処理では、受信メールのサイズがＯＫであれば、縮小処理は行わないこととしたが、サイズに関わらず縮小処理を行うようにすることもできる。図８にそのような処理の手順例を示す。この図は、図７のステップＳ２２を削除したものである。すなわち、最初にサイズをチェックすることなく、初期縮小処理を行う点で図７の処理と異なる。他の点は、図７の処理を同様である。これにより、データ量の軽減が図れ、メール受信時に課金されるような場合にデータ量の低減および受信時間の低減によるコストを削減できる。」（第７頁第１１欄第２９行−同頁第１２欄第４４行）
　
　上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると、
・上記電子メール処理方法は、電子メールの宛先である携帯電話２にパケット通信網で接続されたメールサーバ１０における処理方法であり（摘記事項イ．，【図１】）、データ量や時間に応じた課金、すなわち従量制の課金に対応して電子メールのデータ量を縮小することを目的とした処理方法であるから（摘記事項ア．）、電子メールの送信前または受信前に伝送効率化準備処理するための方法と言い得るものであり、
・上記メールサーバ１０は、受信した電子メールのサイズを求めているが（摘記事項オ．）、このサイズは、従量制課金の観点からは、占有有効データ容量とも言い得るものであり、また、メールサーバ１０が受信する電子メールは発信者により編集された後のものであることは技術常識であるから、上記処理方法では、送信または受信すべき個々の電子メールの編集後、該電子メールにおいて生じている占有有効データ容量を求めており、
・上記メールサーバ１０では、サイズ管理部１１５が、宛先である携帯電話２についての機種依存情報を参照して、電子メールの上限サイズ（上限メール容量１１４２）をチェックし、送信または受信すべき電子メールのサイズがこれを超過したときには、縮小処理部１１６が縮小ルールを用いて初期縮小処理や追加縮小処理を行うが（摘記事項ウ．，オ．，【図２】−【図８】）、上記上限サイズは有効データ容量上限と言い得るものであり、また、上記縮小ルールを用いて縮小処理が行われることは、電子メールにおいてもともと生じていた有効データ容量を低減するための低減アプリケーションが提供されていることを意味し、
・電子メールはデータ量や時間に応じて課金される（摘記事項イ．）が、このようないわゆる従量制の課金システムが通信データ量に関連した料金体系を備えることは通常のことであり、また、上記低減アプリケーションの縮小処理によるデータ量の低減でコスト削減ができる（摘記事項オ．）から、上記低減アプリケーションが提供されることで、送信または受信すべき個々の電子メールを有効データ容量に関して関連付けられている料金体系においていっそう低い価格にしている、と言え、
　
　結局、上記引用例には、以下の発明（以下、「引用発明」という。）が開示されている。
「電子メールをその送信前または受信前に伝送効率化準備処理するための方法において、
　ａ）送信または受信すべき個々の電子メールの編集後、該電子メールにおいて生じている占有有効データ容量を求め、
　ｃ）送信または受信すべき個々の電子メールに対して有効データ容量上限を場合によっては超過したときには、送信または受信すべき個々の電子メールにおいてもともと生じていた有効データ容量を低減するための少なくとも１つの低減アプリケーションを提供して、送信または受信すべき個々の電子メールを有効データ容量に関して関連付けられている料金体系においていっそう低い価格にしている、
　電子メールをその送信前または受信前に伝送効率化準備処理するための方法。」
　
３．対比
　本願発明と引用発明とを対比するに、
・引用発明の「電子メール」は宛先へのメッセージと言い得るものであるから、本願発明の「マルチメディアメッセージ」とは「メッセージ」である点で共通し、
・引用発明の「編集後」は、本願発明の「編集前、編集後および／または編集中」に含まれ、
・引用発明の「有効データ容量上限」は、本願発明の「価格上限および／または有効データ容量上限」に含まれるから、
　両者は以下の点で一致ないし相違している。
　
（一致点）
「メッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
　ａ）送信または受信すべき個々のメッセージの編集前、編集後および／または編集中、該メッセージにおいて生じている占有有効データ容量を求め、
　ｃ）送信または受信すべき個々のメッセージに対して価格上限および／または有効データ容量上限を場合によっては超過したときには、送信または受信すべき個々のメッセージにおいてもともと生じていた有効データ容量を低減するための少なくとも１つの低減アプリケーションを提供して、送信または受信すべき個々のメッセージを有効データ容量に関して関連付けられている料金体系においていっそう低い価格にしている、
　メッセージをその送信前または受信前に伝送効率化準備処理するための方法。」
　　
（相違点１）
　「メッセージ」が、本願発明では「マルチメディアメッセージ」であるのに対し、引用発明では「電子メール」である点。
（相違点２）
　「料金体系」に関し、
　本願発明では「有効データ容量に関して段階づけられて」おり、「ｂ）送信または受信すべき個々のマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を、有効データ容量に関して段階づけられている料金体系（ＧＴＭ）の１つの価格クラス（Ｐｘ）に割り当て、」ているのに対し、
　引用発明では「有効データ容量に関して関連付けられて」はいるものの、「段階づけ」る点及び上記ｂ）の構成を有しない点。
（相違点３）
　「価格上限および／または有効データ容量上限」が、本願発明では「まえもって設定可能な」ものであるのに対し、引用発明ではそのような限定が無い点。
　
４．検討
　そこで、上記相違点につき以下に検討する。
　
（相違点１）について
　電子メールに写真や画像データを埋め込んでマルチメディアメッセージとすることは普通に行われていることであり、また、マルチメディアメッセージを送受信する、Multimedia Messaging Service（ＭＭＳ）も周知のものであることを勘案すれば、引用発明の「電子メール」を本願発明の「マルチメディアメッセージ」とすることは当業者であれば容易になし得たものと認められる。
（相違点２）について
　まず、パケット通信などのデジタル通信における従量制課金システムにおいて、通信データ量を段階的に料金と関連付ける料金体系は、例えば、特開平４−２８４７４６号公報、特開平６−８５９７０号公報等に示されているように、普通に採用されている料金体系に過ぎず、引用例には課金対象の通信網としてパケット通信網が記載されている（摘記事項イ．）から、引用発明の料金体系として、「有効データ容量に関して段階づけられて」いる料金体系を採用することは適宜なし得ることに過ぎない。
　また、引用発明における電子メールのデータ量の低減は、コスト削減をその目的のひとつとしていると認められるが（摘記事項オ．）、コスト削減の効果を知るためにも、データ量を低減する前の価格について調べることが必要であることは明らかであるから、引用発明において「送信または受信すべき個々のマルチメディアメッセージにおいてもともと生じていた占有有効データ容量を、有効データ容量に関して段階づけられている料金体系の１つの価格クラスに割り当て、」る構成を具備させることは当業者であれば容易になし得たものと認められる。
（相違点３）について
　引用例には、メールサーバ１０のサイズ管理部１１５がメールデータ量をチェックするときの基準として、携帯電話２の機種の受信メールの上限値（上限メール容量１１４２）か、または、ユーザによる設定値（ユーザ設定上限サイズ１１３５）を用いることが記載されており（摘記事項ウ．）、この記載に基づけば、引用発明の「有効データ容量上限」をまえもって設定可能なものと限定することは当業者であれば容易になし得たものと認められる。
　
　そして、本願発明が奏する効果も引用発明から容易に予測出来る範囲内のものである。
　
５．他の引用例についての検討
　原審の拒絶の理由に引用された特開平１１−２７２６１号公報(以下、「引用例１」という。)には、「情報伝達システム及びそれに用いる情報処理装置」に関し、図面とともに以下の事項が記載されている。
　
ア．「【００１３】
【発明の実施の形態】以下、図１〜図３を用いて、本発明の一実施形態による情報伝達システムの構成について説明する。
【００１４】最初に、図１を用いて、本実施形態による情報伝達システムであるインターネットのＷＷＷの情報検索システムのネットワークシステムの全体構成について説明する。
【００１５】コンピュータ端末１００は、ネットワーク１０とネットワーク２０を接続し、ネットワーク１０に接続されたコンピュータ端末２００の使用者に、ネットワーク２０及びネットワーク３０などへの接続サービスを行うネットワークサーバ機能を有するものであり、以下、ネットワークサーバと称する。また、コンピュータ端末２００は、以下、ネットワーククライアントと称する。
【００１６】ネットワーク１０は、通常の電話回線のように使用時間に応じて課金されるものや、ＩＳＤＮのパケット通信回線のように伝送したデータ量に応じて課金されるもののように、従量制の課金が行われるネットワークである。ネットワーク２０，３０は、ＬＡＮなど課金のないネットワーク、あるいは専用線のように課金が定額であるネットワークである。なお、ネットワーク２０，３０は、従量制の課金が行われるネットワークであってもよいものである。
【００１７】ネットワーク接続端末４００は、複数のネットワークを相互に接続するルータなどであり、ネットワーク２０，３０は、ネットワーク接続端末４００によって次々に接続され、インターネットのような世界的規模のネットワークを形成する。
【００１８】コンピュータ端末３００，３１０は、それぞれ、ネットワーク２０及びネットワーク３０に接続されており、ＷＷＷを形成する情報を保持しており、以下、ＷＷＷサーバと称する。ＷＷＷサーバ３００上には、ハイパーテキストマークアップランゲージ（ＨＴＭＬ：Ｈｉｐｅｒ  Ｔｅｘｔ  Ｍａｒｋ−ｕｐ  Ｌａｎｇａｇｅ）という書式に従い作成された情報データファイル３０２，３０４や、情報データファイル３０２，３０４に関連付けられた静止画データ３０６や音声データ３０８などが格納されている。また、ＷＷＷサーバ３１０上には、ＨＴＭＬ形式に従い作成された情報データファイル３１２や、情報データファイル３１２に関連付けられた動画データ３１４などが格納されている。なお、ＷＷＷサーバ３００上には、格納される情報データファイルとの関連で動画ファイルが格納される場合もあり、ＷＷＷサーバ３１０上には、格納される情報データファイルとの関連で静止画ファイルや音声ファイルが格納される場合もある。
【００１９】通常、ネットワーククライアント２００の使用者は、ネットワークサーバ１００を介してネットワーク２０にアクセスし、ＷＷＷのリンクをたどりながら、ＷＷＷサーバ３００，３１０上のデータをブラウジングする。」（第３頁第４欄第１行〜第４頁第５欄第３行）
　
イ．「【００２４】以下、ネットワーククライアント２００の使用者が、ＷＷＷの情報をブラウジングする手順にそって、各機能部の動作について説明する。ネットワーククライアント２００の使用者が、ネットワーククライアント２００を用いて、ＷＷＷの情報をブラウジングするとき、ネットワーククライアント２００の使用者は、情報収集の条件をキーボード等の入力手段を用いて、情報収集要求機能部２１０に入力する。情報収集要求機能部２１０は、ネットワーククライアント２００をネットワーク１０を介してネットワークサーバ１００に接続し、要求受付け機能部１１０に情報収集の条件を伝える。なお、すでにネットワーク１０を介してネットワークサーバ１００とネットワーククライアント２００が接続されている場合は、改めて接続を行う必要はないものである。
【００２５】情報収集の条件としては、例えば、収集する情報の起点，情報の階層数や情報の内容種別，回線使用料金上限等である。例えば、情報が、図２に示したようなリンク関係にある場合には、情報の起点は、ＨＴＭＬ３０２となる。そして、情報の階層数としては、１階層目はＨＴＭＬ３０４と静止画データ３０６となり、２階層目はＨＴＭＬ３１２とステレオ音声データ３０８となり、３階層目は動画データ３１４とＨＴＭＬ３０２ということになる。情報の内容種別としては、例えば、静止画３０６のような静止画ばかりを集めるとか、動画３１４のような動画は集めないといった指定が可能である。回線使用料金の上限は、収集した情報をネットワーク１０を介して伝送するのに要する時間に依存する値であり、収集する情報量の上限を制限するパラメータで、この回線使用料金によって、接続時間が割り出され、接続時間とネットワーク１０の伝送速度より、収拾する情報量の上限を算出することができる。」（第４頁第５欄第３３行〜同頁第６欄第１４行）
　
ウ．「【００２８】収集した情報量の総計が、指定された回線使用量上限に対応する情報量の上限を超える場合は、情報圧縮機能部１３０は、収集した情報の情報量を削減する。情報量の削減された情報は、返答機能部１４０によって、再度、ネットワーク１０を介してネットワーククライアント２００と接続し、ネットワーククライアント２００へ送信する。なお、本実施形態においては、情報を圧縮しても、圧縮された情報の情報量が回線使用量上限に対応する情報量の上限を超えたとしても、そのままネットワーククライアント２００に送るようにしている。しかしながら、情報を圧縮しても、圧縮された情報の情報量が回線使用量上限に対応する情報量の上限を超えた場合には、ネットワークサーバ１００からネットワーククライアント２００に対して、上限値を超えた旨を通知し、ネットワーククライアント２００の使用者の要望に答えて、そのままネットワーククライアント２００に送るようにしたり、上限値を超えた部分についてはカットした上で、送るようにしてもよいものである。」（第４頁第６欄第３２〜４９行）
　
エ．「【００３０】なお、情報収集機能部１２０によって収集された情報の中には、予め圧縮されているものもある。このような圧縮されている収集した情報に対しては、情報圧縮機能部１３０は、一旦情報を伸長した上で、再度、上述したような可逆圧縮方式，非可逆圧縮方式若しくは可逆的な圧縮方式を用いて圧縮する。また、情報圧縮機能部１３０は、静止画データや音声データや動画データについては、圧縮されている情報を、圧縮されたままの状態で再度圧縮することも可能である。」（第５頁第７欄第２４〜３２行）
　
　上記引用例１の記載及び図面ならびにこの分野における技術常識を考慮すると、上記情報伝達システムのネットワークサーバ１０が収集する情報は、ＷＷＷサーバ上のＨＴＭＬデータ、静止画データ、音声データ等を含むマルチメディアデータであって、ＷＷＷサーバで公開されるデータは情報公開者からのメッセージとも言い得るものであり、データが伝送されるネットワーク１０としてデータ量に応じた従量制の課金が行われるパケット通信回線が例示され、収集された情報はネットワークサーバ１０において圧縮伸張などの操作が行われるが、このような操作は編集と言い得るものであり、また、回線使用料の低減を目的として、指定された回線使用料上限に対応する情報量の上限を超える場合には、情報圧縮機能部１３０により情報量が圧縮・削減されるが、この情報圧縮機能部１３０は低減アプリケーションとも言い得るものであり、
　
　結局、上記引用例１には、以下の発明（以下、「引用発明１」という。）が開示されている。
「マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
　ａ）送信または受信すべき個々のマルチメディアメッセージの編集前、編集後および／または編集中、該マルチメディアメッセージにおいて生じている占有有効データ容量を求め、
　ｃ）送信または受信すべき個々のマルチメディアメッセージに対してまえもって設定可能な価格上限および／または有効データ容量上限を場合によっては超過したときには、送信または受信すべき個々のマルチメディアメッセージにおいてもともと生じていた有効データ容量を低減するための少なくとも１つの低減アプリケーションを提供して、送信または受信すべき個々のマルチメディアメッセージを有効データ容量に関して関連づけられている料金体系においていっそう低い価格にしている、
　マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法。」
　
　本願発明と引用発明１を比較するに、本願発明では、有効データ容量に関して段階づけられている料金体系を採用し、データ容量低減の前後でそれぞれの価格クラスに割り当てる点で相違する。
　しかしながら、上記「４．検討　（相違点２）について」の欄に記したように、パケット通信などのデジタル通信における従量制課金システムにおいて、通信データ量を段階的に料金と関連付ける料金体系は普通に採用されている料金体系に過ぎないところ、引用例１には課金対象の通信網としてパケット通信回線が記載されているから、引用発明１の料金体系として、「有効データ容量に関して段階づけられて」いる料金体系を採用することは適宜なし得ることに過ぎない。
　また、引用発明１におけるマルチメディアデータのデータ量の低減は、コスト削減をその目的のひとつとしており、コスト削減の効果を知るためにも、データ量を低減する前の価格について調べることが必要であることは明らかであることを勘案すれば、引用発明１において「送信または受信すべき個々のマルチメディアメッセージにおいてもともと生じていた占有有効データ容量を、有効データ容量に関して段階づけられている料金体系の１つの価格クラスに割り当て、」る構成を具備させることは当業者であれば容易になし得たものと認められる。
　したがって、上記本願発明と引用発明１の上記相違点に係る構成は当業者が容易に想到し得たものと認められる。
　
６．むすび
　以上のとおり、本願発明は、上記引用例に記載された発明あるいは引用例１に記載された発明に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。