【事件の表示】
　平成　８年特許願第２７３２４１号「マルチメディア情報通信システム及びサーバ装置」拒絶査定不服審判事件〔平成１０年　５月１５日出願公開、特開平１０−１２４４２９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成８年１０月１６日の出願であって，平成１８年５月３１日付けで拒絶をすべき旨の査定をされ，これに対し，同年７月３日に拒絶査定不服審判の請求がなされるとともに，同月７日付けで手続補正がなされ，その後，当審において，平成１８年７月７日付けの手続補正は平成２１年１０月２８日付けの決定をもって却下され，同日付けの拒絶の理由の通知に対して，平成２２年１月８日付けで意見書が提出されるとともに，同日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２２年１月８日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「画像や音声等の情報であり、且つ、圧縮方式、符号化方式等の形式を表すデータ形式に対応するソフトウエアにて処理されるマルチメディア情報を、前記データ形式に対応するソフトウエアにて処理して再生する手段を有するクライアント装置と、
前記クライアント装置からの要求に応じた前記マルチメディア情報を前記クライアント装置に送信するサーバ装置とから構成されるマルチメディア情報通信システムにおいて、
　前記クライアント装置は、
　前記マルチメディア情報を特定可能なロケーション情報と、自装置においてソフトウエアによって処理可能な前記マルチメディア情報の前記データ形式を特定可能な情報化方式情報と、を共に前記サーバ装置に送信する要求情報送信手段と、
　前記サーバ装置より前記マルチメディア情報を受信し、再生する受信再生手段とを備え、
　前記サーバ装置は、
　前記クライアント装置より、前記ロケーション情報と、前記情報化方式情報を受信する要求情報受信手段と、
　前記要求情報受信手段より得られた前記ロケーション情報に応じたマルチメディア情報を読み出す読み出し手段と、
　前記読み出し手段で読み出したマルチメディア情報を前記要求情報受信手段より得られた前記情報化方式情報に対応したデータ形式に変換する変換手段と、
　前記変換手段により変換されたマルチメディア情報を前記クライアント装置に送信する送信手段と
を備えたことを特徴とするマルチメディア情報通信システム。」
　
３．当審の拒絶理由
　当審において平成２１年１０月２８日付けで通知した拒絶の理由の概要は，本願発明は，特開平８−２０４７０３号公報（平成８年８月９日出願公開。以下「引用例」という。）に記載された発明に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。
　
４．引用例の記載
　引用例には，図面とともに次の事項が記載されている。
　
Ａ．「【０００８】
【課題を解決するための手段】本発明によれば、前述の目的は、文字、画像、図形、音声及び音楽データを含む情報を送受信する通信装置であって、データを処理するためのハードウエア及びソフトウエアからなるリソースに関する情報を記憶するリソース情報記憶手段と、データの送信に先立って、受信側の他の通信装置が同じリソースを有するか否かを判定すべく前記受信側の他の通信装置と通信するネゴシエーション手段と、前記受信側の他の通信装置が同じリソースを有さない場合に、送信すべきデータを前記受信側の他の通信装置のリソースで処理可能なデータに変換するための変換手段を記述した変換テーブルに基づいてデータ変換を行うデータ変換手段とを具備する請求項１の通信装置によって達成される。」（第３頁第３欄第２４行目〜同頁同欄第３７行目）
　
Ｂ．「【００２２】
【実施例】以下、請求項１の通信装置の実施例を図を参照しながら説明する。
【００２３】本実施例の通信装置は、図１に示すように、各部を制御する制御手段としての制御部４を有しており、制御部４にはバスライン２０を介してテキストで静止画、動画などを表示する画像表示手段としての表示部１と、音楽や音声を出力する音声出力手段としての音声出力部２と、公衆回線、ＬＡＮ、赤外線通信などを通じて他の装置と通信を行う通信手段としての通信部３と、指示等を入力する選択手段としての入力部２１とが接続されている。更に、バスライン２０には、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶手段としてのリソース情報記憶部５と、通信を行うデータを記憶する記憶部６と、通信相手が解釈できるようにデータの変換を行うデータ変換手段としてのデータ変換部７とが接続されており、かつ現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル手段としての変換テーブル８と、実際の変換手段を記憶する変換手段格納手段としての変換手段格納部９と、相手の装置のリソース情報がどのようなどのようなものかしるためのネゴシエーション手段としてのネゴシエーション部１０とが接続されている。
【００２４】なお、上述構成では受信したデータは人が見るあるいは聞くことを想定したものであるが、特に人に対して出力する必要はなく、出力部の代わりに処理部であっても構わない。また、受信されるデータは音声、音楽、画像、文字に限らず、形式が決まつているデジタルの数値列であれば表計算ソフトのデータやＣＡＤ（Ｃｏｍｐｕｔｅｒ  Ａｉｄｅｄ  Ｄｅｓｉｇｎ）やＬＳＩ配線のデータであっても構わない。このようにする場合には、図１のブロック図において音声出力部のところをデータ処理部と置き換える。
【００２５】次に、本実施例の動作を図２のフローチャートに沿って説明する。
【００２６】ステップＳ１でにおいて、送信するデータが設定され、ステップＳ２において、送信先が設定される。ステップＳ３において、ステップＳ２で設定された送信相手に送信要求が出され、ステップＳ４において、接続が成功したかどうかが判定される。接続が失敗した場合、通信が終了される。接続が成功した場合、ステップＳ５において、送信相手の端末の持つリソース情報が受信され、ステップＳ６において、ユーザは変換テーブル８を参照して入力部２１により任意の変換手法を選択する。ステップＳ７において、選択された変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップＳ８において、変換する手段がなかった場合、その旨が表示部１に表示されて通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが使用されている場合、例えば文字と静止画が混在する場合などには、一部を通信する（文字だけ通信する）ことも考えられる。この場合には、通信を終了せず、通信できるものだけを送ることも考えられる。選択された変換手法があった場合、ステップＳ９において、受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップＳ１０において、変換したデータが送信され、ステップＳ１１において、通信が終了される。
【００２７】受信側では、ステップＳ１２において、送信要求が待機され、ステップＳ１３において、送信要求が受理され、接続が確立したか判断される。接続が確立しない場合には再び受信待ちになる。ステップＳ１４において、受信側端末の持つリソース情報が送信され、ステップＳ１５において、受信側で解釈できる形のデータが受信され、ステップＳ１６において、通信が終了される。
【００２８】上述したフローでは送信側でデータ変換を行ったが、受信側で変換を行う場合も考えられる。またここでのフローでは呼びを発生する側がデータを送るように記述されているが、当然呼びを発生させる側がデータ受信を行ってもよい。これは以下の実施例でも同様である。なお通信相手のリソース情報を通信終了後も記憶しておくと、次回からネゴシエーションを行わずに済む。この場合に何らかの理由で相手のリソースが変更されたときには、それを通知することが必要である。また、他機種の出力の形態を模擬する機能があり、相手側のリソース情報を記憶していると、送信する前もしくは送信後に相手側でどのような形態で出力されるかを確認することが可能になる。
【００２９】図３に送信データの例を示す。この例では、文章（ＴＥＸＴ１，ＴＥＸＴ２）、静止画（ＩＭＡＧＥ１）、音楽（ＳＯＵＮＤ１）が含まれている。この場合には、例えば表１のような形式で送信される。この例では＃＃というキーに続いてフォーマットが指定されている。この例の最初のデータはＥＵＣ  ＴＥＸＴと記述されていてＥＵＣコードで書かれた文章が存在する。次にはＪＰＥＧの静止画データが、その次にはＭＩＤＩ形式の音楽データが、最後に再びＥＵＣ形式の文章が格納されている。
【００３０】
【表１】
　　　　　　＃＃ＥＵＣ　ＴＥＸＴ
　　　　　　これはテストです。
　
　　　　　　＃＃ＪＰＥＧ
　　　　　　（ＪＰＥＧデータ）
　
　　　　　　＃＃ＭＩＤＩ　ＳＯＵＮＤ
　　　　　　（ＭＩＤＩデータ）
　
　　　　　　＃＃ＥＵＣ　ＴＥＸＴ
　　　　　　テストの終わりです。
　
【００３１】上述した変換方法により変換された後の例は、表２に示すように、文章はＥＵＣコードからＳＪＩＳ（シフトＪＩＳ）コードに変換され、ＪＰＥＧデータはビットマップデータに変換されている。ＭＩＤＩはそのままであり、変換されていない。
【００３２】
【表２】
　　　　　　＃＃ＳＪＩＳ　ＴＥＸＴ
　　　　　　これはテストです。
　
　　　　　　＃＃ＢＩＴＭＡＰ
　　　　　　（ＢＩＴＭＡＰデータ）
　
　　　　　　＃＃ＭＩＤＩ　ＳＯＵＮＤ
　　　　　　（ＭＩＤＩデータ）
　
　　　　　　＃＃ＳＪＩＳ　ＴＥＸＴ
　　　　　　テストの終わりです。
　　　　　　　
【００３３】表３に装置が持つリソース情報ファイルの例を示す。この例では、ＥＵＣの文章、ＢＩＴＭＡＰ、ＭＩＤＩなどを解釈可能であることを示している。すなわち、解釈可能なものしか通信できない。この例で上げられているように、アドレスデータやスケジュールデータなどもリソース情報として登録することが望ましい。変換プログラムを作成することで、機種により異なる住所やスケジュールフォーマットなどが、ユーザに意識させることなく変換が可能になる。
【００３４】
【表３】
　　　　　　ＥＵＣ　ＴＥＸＴ
　　　　　　ＢＩＴＭＡＰ（６４０ｘ４８０）
　　　　　　ＭＩＤＩ
　　　　　　ＪＰＥＧ
　　　　　　ＴＩＦＦ
　　　　　　ＺＡＵＲＵＳ　ＡＤＤＲＥＳＳ
　　　　　　ＺＡＵＲＵＳ　ＳＣＨＥＤＵＬＥ
　　　　　　ＺＡＵＲＵＳ　ＭＥＭＯ
　　　　　　ＬＯＴＵＳ１−２−３
　　　　　　ＳＨＯＩＮ　ＷＰ
　　　　　　　　　　：
　　　　　　　　　　：
【００３５】表４に変換テーブルの例を示す。この例では、変換前フォーマット：変換可能フォーマット１、変換可能フォーマット２、・・・・という形で記述されている。
【００３６】
【表４】
　　　　　　ＥＵＣ　ＴＥＸＴ：ＳＪＩＳ　ＴＥＸＴ、ＪＩＳ　ＴＥＸＴ
　　　　　　ＳＪＩＳ　ＴＥＸＴ：ＥＵＣ　ＴＥＸＴ、ＪＩＳ　ＴＥＸＴ
　　　　　　ＪＩＳ　ＴＥＸＴ：ＥＵＣ　ＴＥＸＴ、ＪＩＳ　ＴＥＸＴ
　　　　　　ＴＩＦＦ：ＢＩＴＭＡＰ、＊ＪＰＥＧ
　　　　　　ＪＰＥＧ：ＢＩＴＭＡＰ、ＴＩＦＦ
　　　　　　ＢＩＴＭＡＰ：＊ＪＰＥＧ、ＴＩＦＦ
　
【００３７】尚、フォーマット名の前に「＊」がついているのは非可逆変換を示している。非可逆変換とは、ＡをＢに変換し、再びＢをＡに変換しようとしたとき、元のＡが完全には復元できない変換を示している。言い換えると、変換を行ったときに元の情報の一部が失われる変換のことを指す。なお、請求項１の発明では、この非可逆変換かどうかは関係しない。ここで変換という言葉は元のデータもしくはそれに付険する情報、例えばファイル名、作成日時、作成装置アドレスなどを用いて別のデータを作り出す作業をいう。もとのデータはイメージであるものを、そのオリジナルデータがあるマシンのアドレスとそのイメージのファイル名とそのイメージの縦横の大きさだけに置き換えてしまうような操作も変換と呼んでいる。同様に動画データから１枚ないしは数枚の静止画を抜き出したデータを作る操作も変換である。」（第４頁第５欄第３８行目〜第６頁第９欄第２２行目）
　
Ｃ．「【００７７】
【発明の効果】請求項１の通信装置によれば、装置の持つハードウエア、ソフトウエア情報（リソース情報）を通信に先立ち送ることで、現在通信を行いたいデータフォーマットと受信側でのリソース情報を比較し、変換が必要であるならばデータ変換を施してから送信するので、データフォーマットが異なっても通信を行うことができる。
【００７８】例えば、携帯端末とパーソナルコンピュータ（ＰＣ）を公衆電話回線を通じて結ぶことを考える。ＰＣ側で保持する音楽がＭＩＤＩフォーマットであるが、携帯端末側ではＭＩＤＩのデータフォーマットを解釈できず、ＷＡＶＥフォーマットしか出力できないとする。本発明によると、この場合にもそれぞれのリソースを判定することで、ＰＣ側（もしくは携帯端末側）でＭＩＤＩフォーマットをフォーマットに変換して送ることが可能になる。
【００７９】同様に、ＰＣ側で保持するスケジュールデータのフォーマットが携帯端末のスケジュールフォーマットと合わない場合であっても、変換プログラムを用意するだけで、自動的にそれぞれの機械がどのフォーマットを扱えるかを自動判別して変換し、ユーザはその変換を意識することなく、データを送受信することができる。」（第１０頁第１８欄第２７行目〜同頁同欄第４９行目）
　
　以上の記載によれば，引用例には，次の発明（以下「引用発明」という。）が記載されている。
　
「公衆回線，ＬＡＮ，赤外線通信などを通じてＥＵＣ　ＴＥＸＴ，ＳＪＩＳ　ＴＥＸＴ若しくはＪＩＳ　ＴＥＸＴなどの文章のフォーマット，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマットの文字，画像，図形，音声及び音楽データを含む情報を受信側端末へ送信する通信装置であって，
　受信側端末は，送信要求を受信し，通信装置と接続を確立した場合，受信側端末のデータを処理するためのハードウエア及びソフトウエアからなるリソースで処理可能な，ＥＵＣ　ＴＥＸＴ，ＳＪＩＳ　ＴＥＸＴ若しくはＪＩＳ　ＴＥＸＴなどの文章のフォーマット名，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット名又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマット名で構成されるリソース情報を送信し，通信装置から送信されたデータを受信し，そのデータを出力し，
　通信装置は，送信するデータを設定し，送信要求を送信し，接続が成功した場合，受信側端末からリソース情報を受信し，ユーザが変換を意識することなく自動的に受信側端末がどのフォーマットを扱えるかを自動判別して，受信側端末のリソースで処理可能なようにデータを変換し，その変換したデータを送信する通信装置。」
　
５．対比
　本願発明と引用発明を対比する。
　引用発明の「受信側端末」及び「通信装置」と本願発明の「クライアント装置」及び「サーバ装置」は，それぞれ「第１の装置」及び「第２の装置」において共通する。
　引用発明の「文字，画像，図形，音声及び音楽データを含む情報」は，本願発明の「マルチメディア情報」に相当する。すると，引用発明において，通信装置から送信された文字，画像，図形，音声及び音楽データを含む情報を受信する受信側端末と前記情報を送信する通信装置を備えた構成は，本願発明の「マルチメディア情報通信システム」に相当するものである。
　引用発明において，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマットは，本願発明の「圧縮方式，符号化方式等の形式を表すデータ形式」に相当する。
　引用発明において，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマットの画像及び音楽データを含む情報は，それらのフォーマットに対応するソフトウエアにて処理・再生できることは明らかであるから，引用発明において，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマットの画像及び音楽データを含む情報は，本願発明の「画像や音声等の情報であり，且つ，圧縮方式，符号化方式等の形式を表すデータ形式に対応するソフトウエアにて処理されるマルチメディア情報」に相当し，また，引用発明において，ＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマットの画像及び音楽データを含む情報を受信側端末において出力する構成は，本願発明の「画像や音声等の情報であり、且つ、圧縮方式、符号化方式等の形式を表すデータ形式に対応するソフトウエアにて処理されるマルチメディア情報を、前記データ形式に対応するソフトウエアにて処理して再生する手段」を含んでいることは明らかである。
　引用発明において，受信側端末の持つ受信側端末が解釈可能なＴＩＦＦ，ＢＩＴＭＡＰ，ＪＰＥＧなどの静止画のフォーマット名又はＭＩＤＩ若しくはＷＡＶＥなどの音楽のフォーマット名で構成されるリソース情報は，本願発明の「自装置においてソフトウエアによって処理可能な前記マルチメディア情報の前記データ形式を特定可能な情報化方式情報」に相当し，引用発明において，前記リソース情報を受信側端末から通信装置に送信する構成は，本願発明と，「情報化方式情報を前記第２の装置に送信する要求情報送信手段」において共通する。
　引用発明において，受信側で解釈できる形の画像及び音楽データを含むデータを受信し，出力する構成は，本願発明と，「前記第２の装置より前記マルチメディア情報を受信し、再生する受信再生手段」において共通する。
　引用発明において，受信側端末の持つリソース情報を受信する構成は，本願発明と，「前記第１の装置より，前記情報化方式情報を受信する要求情報受信手段」において共通する。
　引用発明において，送信する画像及び音楽データを含むデータを受信側で解釈可能なように変換する構成は，受信側端末より受信したリソース情報に記載されたフォーマット名のフォーマットに変換していることは明らかであるから，引用発明の上記構成は，本願発明の「マルチメディア情報を前記要求情報受信手段より得られた前記情報化方式情報に対応したデータ形式に変換する変換手段」に相当する。
　引用発明において，変換した画像及び音楽データを含むデータを受信側端末に送信する構成は，本願発明と，「前記変換手段により変換されたマルチメディア情報を前記第１の装置に送信する送信手段」において共通する。
　
　すると，本願発明と引用発明とは，次の点で一致する。
＜一致点＞
「画像や音声等の情報であり，且つ，圧縮方式，符号化方式等の形式を表すデータ形式に対応するソフトウエアにて処理されるマルチメディア情報を，前記データ形式に対応するソフトウエアにて処理して再生する手段を有する第１の装置と，
前記マルチメディア情報を前記第１の装置に送信する第２の装置とから構成されるマルチメディア情報通信システムにおいて，
　前記第１の装置は，
　自装置においてソフトウエアによって処理可能な前記マルチメディア情報の前記データ形式を特定可能な情報化方式情報を，前記第２の装置に送信する要求情報送信手段と，
　前記第２の装置より前記マルチメディア情報を受信し，再生する受信再生手段とを備え，
　前記第２の装置は，
　前記第１の装置より，前記情報化方式情報を受信する要求情報受信手段と，
　マルチメディア情報を前記要求情報受信手段より得られた前記情報化方式情報に対応したデータ形式に変換する変換手段と，
　前記変換手段により変換されたマルチメディア情報を前記第１の装置に送信する送信手段と
を備えたことを特徴とするマルチメディア情報通信システム。」
　
　一方，両者は次の点で相違する。
＜相違点＞
　本願発明では，第１の装置がクライアント装置であり，第２の装置がサーバ装置であり，マルチメディア情報がクライアント装置からの要求に応じたものであり，クライアント装置が，マルチメディア情報を特定可能なロケーション情報を，情報化方式情報と共にサーバ装置に送信する要求情報送信手段を有し，サーバ装置が，クライアント装置よりロケーション情報を受信する要求情報受信手段及び要求情報受信手段より得られたロケーション情報に応じたマルチメディア情報を読み出す読み出し手段を有し，要求情報受信手段より得られた情報化方式情報に対応したデータ形式に変換するマルチメディア情報が読み出し手段で読み出したものであるのに対し，引用発明では，第１の装置が受信側端末であり，第２の装置が通信装置であり，初めに通信装置が送信要求を送信している点。
　
６．当審の判断
　上記相違点について検討する。
　上記３．Ｂ．【００２８】には，「またここでのフローでは呼びを発生する側がデータを送るように記述されているが、当然呼びを発生させる側がデータ受信を行ってもよい。」と記載されているから，引用例１には，受信側端末から通信装置へ送信要求を送信する構成についての示唆がある。
　また，クライアント装置がある情報を得るために特定可能なＵＲＬ（本願発明の「ロケーション情報」に相当。）を含んだ要求をプロキシーサーバ装置（本願発明の「サーバ装置」に相当。）に送信し，そのプロキシーサーバ装置は，そのＵＲＬを受信し，そのＵＲＬに応じた情報を別のサーバ装置から読み出し，その読み出した情報をクライアント装置に送信する構成を有するＷＷＷシステムは，高木浩光，より快適なＷＷＷアクセスのための「プロキシーサーバー」効果的活用法，ＩＮＴＥＲＮＥＴ　ｍａｇａｚｉｎｅ，株式会社インプレス，平成８年３月１日，第１４巻，第２０１頁〜第２０７頁（特に，第２０２頁の左欄の「プロキシーサーバーの仕組み」の項及び図３−ｃ参照。）及び吉村伸，インターネットの利用と仕組み（１６）　ファイアウォールとｐｒｏｘｙ，ＵＮＩＸ　ＭＡＧＡＺＩＮＥ，株式会社アスキー，平成６年８月１日，第９巻，第８号，第５５頁〜第６３頁（特に，第５９頁右欄の「Ｐｒｏｘｙサーバーによる中継」の項及び第６０頁右欄〜第６１頁左欄の「ＨＴＴＰ　ｐｒｏｘｙ」の項参照。）に記載されているように，本件出願前周知である。
　さらに，複数種類の情報を同時に送ることは，当業者が適宜なし得ることである。
　したがって，引用発明において，周知技術を適用することにより，受信側端末をクライアント装置，通信装置をサーバ装置とし，マルチメディア情報がクライアント装置からの要求に応じたものとし，クライアント装置が，マルチメディア情報を特定可能なロケーション情報を，情報化方式情報と共にサーバ装置に送信する要求情報送信手段を有し，サーバ装置が，クライアント装置よりロケーション情報を受信する要求情報受信手段及び要求情報受信手段より得られたロケーション情報に応じたマルチメディア情報を読み出す読み出し手段を有し，要求情報受信手段より得られた情報化方式情報に対応したデータ形式に変換するマルチメディア情報が読み出し手段で読み出したものとするように構成することは，当業者が容易に想到し得ることである。
　
　また，本願発明の構成によって生じる効果も，当業者が予測できるものである。
　したがって，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
　なお，請求人は，平成２２年１月８日付け意見書において，本願発明はｐｕｌｌ型のデータ送信であるのに対し，引用発明はｐｕｓｈ型のデータ送信である点で異なる旨主張しているが，上記６．当審の判断に記載したとおり，ｐｕｌｌ型のデータ送信であるＷＷＷシステムは本件出願前周知であるから，上記主張は採用できない。
　
７．むすび
　以上のとおり，本願発明は，特許法２９条２項の規定により特許を受けることができないものである。
　よって，結論のとおり審決する。