【事件の表示】
　特願２００４−２１０５１８「動的光発信者番号通知」拒絶査定不服審判事件〔平成１７年　３月　３日出願公開、特開２００５−　５７７４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は，平成１６年７月１６日（パリ条約による優先権主張　２００３年８月７日　米国）の出願であって，平成２２年８月１３日付けで拒絶査定がなされ，これに対し，同年１２月１７日に拒絶査定に対する審判請求がなされたものである。
　その請求項６に係る発明は，明細書，特許請求の範囲及び図面の記載からみて，平成２１年１１月２４日付け手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次のものと認める（以下，「本願発明」という。）。
「【請求項６】
　発呼側デバイス，外部装置および被呼側デバイスを有するシステムであって，前記被呼側のデバイスで，発呼側の呼び出しの識別情報を出力し，前記呼び出しの識別情報は予め前記外部装置から前記被呼側のデバイスに送られるシステムにおいて，
　前記外部装置は，
　１つの発呼側デバイスについて，タイプが異なる複数の呼び出しの識別情報と，当該複数の呼び出しの識別情報のそれぞれを出力すべき日時を示す複数のカレンダー情報とを被呼側のデバイスに送信する手段を有し，
　前記被呼側のデバイスは，
　受信した前記複数の呼び出し情報および前記複数のカレンダー情報を格納する格納デバイスと，
　前記複数のカレンダー情報のいずれか１つに対応するタイプの呼び出しの識別情報を，前記発呼側のデバイスが被呼側のデバイスを呼び出したときに，出力する手段と
　を備えたことを特徴とするシステム。」
　
　
２．引用発明
　原査定の拒絶の理由に引用された特開２００１−３０９０４６号公報（以下，「引用例」という。）には，「着呼者呼び出し方法，通信機器，発呼者情報サーバおよび呼び出し制御装置」として図面とともに以下の事項が記載されている。
　
（１）「【００４０】
【発明の実施の形態】〔第１の実施形態〕本発明の一実施形態について図１および図２に基づいて説明すると以下の通りである。すなわち，本実施形態に係る通信システム１は，通話などの通信に先立って，着呼側機器がユーザに着呼を報知する際，例えば，メロディやアニメーションなどの発呼者情報を再生するシステムであって，図１に示すように，発呼側機器および着呼側機器（通信機器）となる端末３・５と，例えば，公衆電話回線網やパケット通信網など，両端末３・５間を接続する通信網７と，予め，発呼者が設定した発呼者情報を格納すると共に，発呼側の端末３が着呼側の端末５を発呼する際，設定された発呼者情報を着呼側の端末５に送信して，着呼報知時に再生させる発呼者情報サーバ９とを備えている。
【００４１】当該構成では，着呼側の端末５がユーザに着呼を報知する際に再生する発呼者情報は，発呼者情報サーバ９から伝送された発呼者情報，すなわち，発呼者が予め設定した発呼者情報になる。したがって，着呼者が何ら設定することなく，着呼側の端末５は，着呼時に再生する発呼者情報を，発呼者に応じて変更できる。
【００４２】なお，本発明は，携帯電話システムなどの無線通信システムに限らず，有線の通信システムにも広く適用できるが，以下では，好適な例として，各端末３・５が例えば，携帯電話など，携帯可能な端末装置の場合を例にして説明する。また，上記発呼者情報は，着呼を報知する際，すなわち，着呼者が応呼する前に，発呼者を識別できるように，複数種類設定可能であれば，メロディ（着メロ）などの音として再生されてもよいし，アニメーション（着アニメーション）などの動画や静止画のような画像として再生されてもよい。また，ライトの明滅などの光，あるいは，振動などとして再生されてもよいが，以下では，発呼者情報がアニメーションの場合を例にして説明する。
【００４３】すなわち，本実施形態に係る着呼側の端末５は，例えば，無線通信路などを介して図示しない基地局と通信するなどして，通信網７と接続可能な送受信部５１と，発呼側の端末３による発呼が通信網７から送受信部５１に通知された場合に，予め定められる発呼者情報を再生して，ユーザに着呼を報知する発呼者情報再生部（着呼報知手段）５２と，ユーザが応呼した場合に，発呼側の端末３との通話を処理する通話処理部（通信手段）５３とを備えている。なお，本実施形態では，発呼者情報がアニメーションであり，上記発呼者情報再生部５２は，発呼者情報受信部５４が受信した発呼者情報を，例えば，液晶表示装置などの表示部へアニメーションとして表示して，ユーザに着呼を報知する。」（５頁８欄〜６頁９欄）
　
（２）「【００５８】上記構成の通信システム１において，発呼側の端末３が着呼側の端末５を呼び出す際の動作を，図２に示すフローチャートに基づき説明すると，以下の通りである。すなわち，ステップ１（以下では，Ｓ１のように略称する）において，例えば，着呼側端末番号を入力するなどして，ユーザが発呼指示部３３へ発呼を指示すると，発呼指示部３３は，Ｓ２において，通信網７の呼出制御部７１へ，着呼側端末番号を通知して，着呼側の端末５と接続を準備するように指示する。なお，呼出制御部７１は，後述するように，準備が完了すると，待機状態となり，着呼側の端末５から指示があるまで，着呼側の端末５への呼び出しを遅延させる。
【００５９】さらに，上記Ｓ１にて，発呼指示部３３が発呼指示を検出すると，Ｓ３において，発呼側端末番号送信部３４は，送受信部３１へ指示して，図示しないメモリに記憶されている自機器の番号（発呼側端末番号）を発呼者情報サーバ９へ送信する。また，着呼側端末番号送信部３５は，発呼指示部３３から着呼側端末番号を受け取り，発呼者情報サーバ９へ送信する。
【００６０】一方，発呼者情報サーバ９では，Ｓ４において，番号受信部９２は，上記両端末番号送信部３４・３５から発呼側端末番号および着呼側端末番号を受け取り，Ｓ５において，発呼者情報取得部９３は，発呼者情報ＤＢ９１を参照して，両番号に対応する発呼者情報を取得する。さらに，発呼者情報送信部９４は，Ｓ６およびＳ７において，上記Ｓ４で受け取った着呼側端末番号を発呼し，着呼側の端末５で，予め発呼者情報を受け取ると設定されていた場合（Ｓ６にてYES の場合），上記Ｓ５で取得した発呼者情報を送信する（Ｓ７）。
【００６１】当該発呼者情報が通信網７を介して伝送され，着呼側の端末５において，発呼者情報受信部５４が受信すると（Ｓ８），待ち受け解除指示部５５は，通信網７の呼出制御部７１へ，待ちうけ解除を指示する（Ｓ９）。なお，着呼側の端末５が発呼者情報の受信を拒否した場合（上記Ｓ６にてNOの場合）は，通信網７を発呼者情報が伝送されることなく，上記Ｓ９にて，待ちうけ解除が指示される。
【００６２】ここで，上記呼出制御部７１は，上記Ｓ２での指示を受けて，着呼側の端末５との接続を準備した後，Ｓ１１に示す待ち受け状態に移行しているが，上記待ち受け解除指示部５５からの指示を受けると，Ｓ１２において，待ち受け状態を解除し，着呼側の端末５を呼び出す。
【００６３】一方，着呼側の端末５の発呼者情報再生部５２は，発呼者情報受信部５４から，上記Ｓ７で受信した発呼者情報を受け取って，発呼者情報の再生を準備しており，呼出制御部７１からの呼び出しを検出すると，発呼者情報を再生するように予め設定されている場合（Ｓ１３にてYES の場合），発呼者情報を再生して，ユーザに着呼を報知する（Ｓ１４）。」（８頁１３〜１４欄）
　
（３）「【００７２】ここで，発呼者情報は，発呼側の端末３から着呼側の端末５に直接送信してもよいが，本実施形態では，発呼側の端末３とは別に発呼者情報サーバ９が設けられており，発呼者情報は，当該発呼者情報サーバ９から送信される。この結果，発呼毎に発呼側の端末３が発呼者情報を送信する場合に比べて，発呼側の端末３と通信網７との間のトラフィックを削減できる。ここで，発呼者情報サーバ９の数は，発呼側の端末３よりも少ない数に設定できるので，発呼者情報サーバ９と通信網７との間の通信容量は，発呼側の端末３と通信網７との間の通信容量よりも向上しやすい。また，発呼者情報サーバ９は，設置場所が固定されており，有線で接続できるので，無線通信路を介して通信網７と接続される発呼側の端末３に比べて，さらに，通信容量を向上しやすい。この結果，発呼者情報サーバ９から発呼者情報を送信することで，通信網７の負担を軽減できる。」（９頁１５〜１６欄）
　
（４）「【００７６】〔第２の実施形態〕ところで，上記第１の実施形態では，発呼者情報サーバ９が発呼側端末番号と着呼側端末番号とに基づいて発呼者情報を特定する場合について説明した。これに対して，本実施形態では，発呼する際に，発呼側の端末で発呼者情報を選択する場合について，図３〜図５に基づき説明する。
【００７７】すなわち，図３に示すように，本実施形態に係る通信システム１ａの発呼側の端末３ａでは，着呼側端末番号送信部３５に代えて，予め定められた発呼者情報の中から，現発呼で使用する発呼者情報を選択する発呼者情報選択部３６と，選択された発呼者情報を示す選択情報を発呼者情報サーバ９ａに送信する選択情報送信部３７とが設けられている。さらに，発呼側の端末３ａには，発呼者情報サーバ９ａに登録した発呼者情報の概要を示す画像やテキストなどを記憶する発呼者情報サマリＤＢ３８が設けられており，上記発呼者情報選択部３６は，ユーザに発呼者情報の概要を提示して選択を促すことができる。
【００７８】一方，図４に示すように，発呼者情報サーバ９ａには，発呼側端末番号および着呼側端末番号と発呼者情報との組み合わせを記憶する発呼者情報ＤＢ９１に代えて，発呼側端末番号および選択情報と発呼者情報との組み合わせが格納された発呼者情報ＤＢ９１ａが設けられている。さらに，発呼者情報サーバ９ａには，上記選択情報を受信する選択情報受信部９６が追加されており，発呼者情報取得部９３は，番号受信部９２が受信した発呼側端末番号と，選択情報受信部９６が受信した選択情報とに基づいて，発呼者情報ＤＢ９１ａを参照して，着呼側の端末５に送信する発呼者情報を特定する。なお，発呼側端末番号および選択情報と発呼者情報との組み合わせは，第１の実施形態と同様に，発呼に先立って，発呼側の端末３ａまたは端末３ａのユーザが使用する他の情報機器から，発呼者情報サーバ９ａの発呼者情報ＤＢ９１ａに登録される。
【００７９】上記構成では，図５に示すように，図２に示す各工程に先立って行われるＳ２１において，発呼者情報選択部３６は，発呼者情報サマリＤＢ３８を参照して，発呼者情報サーバ９ａに登録されている発呼者情報の概要を提示し，ユーザの指示や予め定められた条件などに基づいて，現発呼で使用する発呼者情報を選択する。さらに，Ｓ３〜Ｓ５に代えて設けられたＳ２２〜Ｓ２４において，発呼側の端末３ａの発呼側端末番号送信部３４および選択情報送信部３７から，発呼者情報サーバ９ａの番号受信部９２および選択情報受信部９６へ，現発呼で使用する発呼者情報を示す選択情報と発呼側端末番号とが伝送され，発呼者情報取得部９３は，選択情報および発呼側端末番号に対応する発呼者情報を発呼者情報ＤＢ９１ａから読み出す。なお，以降は，図２と同様の動作が行われる。
【００８０】上記構成によれば，予め発呼者情報サーバ９ａに登録された複数の発呼者情報の中から，発呼毎に，当該発呼で使用する発呼者情報が選択される。これにより，第１の実施形態のように，発呼側端末番号と着呼側端末番号とに対応する発呼者情報が決められている場合とは異なり，発呼時点で発呼者情報を決定できるので，発呼側の端末３ａは，より発呼者の状況に合った発呼者情報の送信を指示できる。この結果，着呼側の端末５は，より発呼時の状況に応じた発呼者情報を再生して，着呼側の端末５のユーザに，より的確に発呼時の状況を伝えることができる。
【００８１】また，本実施形態に係る発呼側の端末３ａには，発呼者情報サマリＤＢ３８が設けられており，発呼者情報選択部３６が選択可能な発呼者情報の概要を提示してユーザに選択を促すので，選択時の手間を削減できる。」（９頁１６欄〜１０頁１８欄）
　
（５）「【０１０３】〔第６の実施形態〕本実施形態では，第２および第４の実施形態と同様に，発呼者情報が発呼側端末番号と選択情報との組み合わせで特定される構成において，第５の実施形態と同様に，着呼側の端末に受信済発呼者情報ＤＢを設けた場合について，図１６〜図１８に基づき説明する。
【０１０４】すなわち，図１６に示すように，本実施形態に係る通信システム１ｅでは，発呼側端末番号と選択情報との双方が，発呼側の端末３ｃから着呼側の端末５ｅに通知され，着呼側の端末５ｅの受信済発呼者情報ＤＢ５９ｅに，双方に対応する発呼者情報が格納されていないときに限って，着呼側の端末５ｅが発呼者情報サーバ９ａに発呼者情報の送信を指示するように構成されている。
【０１０５】具体的には，本実施形態に係る着呼側の端末５ｅには，図１７に示すように，図１２の構成に加えて，これまで受信した発呼者情報を発呼側端末番号および選択情報と関連付けて蓄積する受信済発呼者情報ＤＢ５９ｅと，発呼側の端末３ｅの選択情報送信部３７（図１１参照）から，選択情報を受け取る選択情報受信部６１と，発呼側端末番号および選択情報の組み合わせに基づいて，受信済発呼者情報ＤＢ５９ｅを参照し，組み合わせに対応する発呼者情報が格納されていない場合に，発呼側端末番号送信部５７および選択情報送信部６２へ，発呼側の端末３ｅから通知された発呼側端末番号および選択情報の送信を指示する発呼者情報取得部６０ｅとが設けられている。なお，本実施形態では，発呼側端末番号受信部５６および選択情報受信部６１が特許請求の範囲に記載の受信手段に対応する。
【０１０６】上記構成では，図１８に示すように，図１３と略同様の処理が行われるが，Ｓ３１〜Ｓ３３に代えて設けられたＳ６１〜Ｓ６３において，発呼側の端末３ｅは，発呼側端末番号と選択情報との双方を着呼側の端末５ｅに送信する。また，双方の受信に成功すると（Ｓ３４にて，YES の場合），着呼側の端末５ｅの発呼者情報取得部６０は，受信済発呼者情報ＤＢ５９ｅを参照して，双方に対応する発呼者情報が既に格納されている場合（Ｓ６４にて，YES の場合），図１５と同様，図２に示すＳ９以降の処理を行い，当該発呼者情報を再生して，着呼を報知する。一方，対応する発呼者情報が格納されていない場合（Ｓ６４にて，NOの場合），発呼者情報取得部６０は，Ｓ６５において，発呼側端末番号送信部５７および選択情報送信部６２へ指示して，発呼者情報サーバ９ａへ，発呼側端末番号および選択情報を通知して，発呼者情報の送信を指示する。その後は，図１３のＳ２４以降の処理が行われ，着呼側の端末５ｅは，発呼者情報サーバ９ａから通知された発呼者情報を再生して，着呼を報知する。
【０１０７】上記構成では，第５の実施形態と同様に，発呼者情報が既に着呼側の端末５ｅに蓄積されている場合，発呼者情報サーバ９ａから着呼側の端末５ｅへの発呼者情報の送信を中止する。この結果，第２および第４の実施形態の効果に加えて，通信網７ｂから着呼側の端末５ｅへのトラフィックを削減でき，より通信網７ｂの負担を軽減できる。
【０１０８】なお，上記第５および第６の実施形態では，受信済発呼者情報ＤＢ（５９・５９ｅ）に格納した発呼者情報を再利用する。したがって，発呼側で発呼者情報が変更されたとしても，着呼側の端末（５ｄ・５ｅ）が更新前の発呼者情報を再生する虞れがある。したがって，発呼側の端末（３ｄ・３ｅ）や発呼者情報サーバ（９・９ａ）は，例えば，発呼者情報の更新時刻や有効期間あるいは識別符号など，更新の有無を識別可能な情報を着呼側の端末へ送信すると共に，着呼側の端末は，受信済発呼者情報ＤＢに当該情報も併せて記憶しておき，更新の有無を確認する方が望ましい。なお，更新時における発呼者情報の管理方法は，ユーザの指示に応じて，新たな発呼者情報を再生するか否かと，双方を保存するか否かとの組み合わせのうち，いずれかを採用すればよい。」（１２頁２２欄〜１３頁２３欄）
　
　上記記載及び当該技術分野の技術常識を考慮すると，
ア．上記（１）の【００４０】および図１記載によれば，引用例に示される通信システムは発呼側機器，発呼者情報サーバ及び着呼側機器を備える通信システムといえ，同【００４０】の「通話などの通信に先立って，着呼側機器がユーザに着呼を報知する際，例えば，メロディやアニメーションなどの発呼者情報を再生する」の記載によれば，着呼側機器で発呼者情報を再生するといえる。
　また，同【００４０】の「予め，発呼者が設定した発呼者情報を格納すると共に，発呼側の端末３が着呼側の端末５を発呼する際，設定された発呼者情報を着呼側の端末５に送信して，着呼報知時に再生させる発呼者情報サーバ９とを備えている。」，上記（２）の「ユーザが発呼指示部３３へ発呼を指示すると，・・・着呼側の端末５から指示があるまで，着呼側の端末５への呼び出しを遅延させる。」（【００５８】），「一方，発呼者情報サーバ９では，・・・上記Ｓ５で取得した発呼者情報を送信する（Ｓ７）。」（【００６０】），「当該発呼者情報が通信網７を介して伝送され，着呼側の端末５において，・・・受信すると（Ｓ８），・・・待ちうけ解除を指示する」（【００６１】），「上記待ち受け解除指示部５５からの指示を受けると，Ｓ１２において，待ち受け状態を解除し，着呼側の端末５を呼び出す。」（【００６２】），「呼出制御部７１からの呼び出しを検出すると，・・・発呼者情報を再生して，ユーザに着呼を報知する（Ｓ１４）」（【００６３】）及び図２の記載によれば，発呼者情報は着呼側の端末が呼び出される前に発呼者情報サーバから着呼側機器に送信されるものであるといえる。
　したがって，引用例には，『発呼側機器，発呼者情報サーバ及び着呼側機器を有する通信システムであって，前記着呼側機器で，発呼者が設定した発呼者情報を再生し，前記発呼者情報は着呼側の端末が呼び出される前に発呼者情報サーバから着呼側機器に送られる通信システム』について記載されていると認められる。
　
イ．上記（２）の【００６０】の「さらに，発呼者情報送信部９４は，Ｓ６およびＳ７において，上記Ｓ４で受け取った着呼側端末番号を発呼し，着呼側の端末５で，予め発呼者情報を受け取ると設定されていた場合（Ｓ６にてYES の場合），上記Ｓ５で取得した発呼者情報を送信する（Ｓ７）。」，及び上記（４）の【００７６】の記載に基づき，「予め定められた発呼者情報の中から，現発呼で使用する発呼者情報を選択する発呼者情報選択部３６と，・・・とが設けられている。」（【００７７】），「発呼者情報サーバ９ａには・・・発呼側端末番号および選択情報と発呼者情報との組み合わせが格納された発呼者情報ＤＢ９１ａが設けられている。」（【００７８】），「ユーザの指示や予め定められた条件などに基づいて，現発呼で使用する発呼者情報を選択する。・・・現発呼で使用する発呼者情報を示す選択情報と発呼側端末番号とが伝送され，発呼者情報取得部９３は，選択情報および発呼側端末番号に対応する発呼者情報を発呼者情報ＤＢ９１ａから読み出す。なお，以降は，図２と同様の動作が行われる。」（【００７９】），「予め発呼者情報サーバ９ａに登録された複数の発呼者情報の中から，発呼毎に，当該発呼で使用する発呼者情報が選択される。・・・より発呼者の状況に合った発呼者情報の送信を指示できる。」（【００８０】）の記載によれば，発呼者情報サーバには１つの発呼側機器について複数の発呼者情報が格納されており，予め定められた発呼者情報の中からユーザの指示や予め定められた条件などに基づいて現発呼で使用する発呼者情報が選択され，発呼者情報送信部９４により選択された発呼者情報が着呼側機器に送信されるといえる。ここで，送信される発呼者情報は発呼毎に発呼者の状況に合ったものであるからタイプが異なる発呼者情報といえる。
　したがって，引用例には，『１つの発呼側機器について，ユーザの指示や予め定められた条件などに基づいて選択されたタイプが異なる発呼者情報を着呼側機器に送信する発呼者情報送信部』を有する発呼者情報サーバが記載されていると認められる。
　
ウ．上記（５）の【０１０３】の記載に基づき，「これまで受信した発呼者情報を発呼側端末番号および選択情報と関連付けて蓄積する受信済発呼者情報ＤＢ５９ｅ」（【０１０５】），「発呼側端末番号と選択情報との双方が，発呼側の端末３ｃから着呼側の端末５ｅに通知され，着呼側の端末５ｅの受信済発呼者情報ＤＢ５９ｅに，双方に対応する発呼者情報が格納されていないときに限って，着呼側の端末５ｅが発呼者情報サーバ９ａに発呼者情報の送信を指示する」（【０１０４】）の記載によれば，着呼側機器はこれまで受信した発呼者情報を発呼側端末番号および選択情報と関連付けて格納する受信済発呼者情報ＤＢを備えているといえる。
　したがって，引用例には，『これまで受信した発呼者情報を格納する受信済発呼者情報ＤＢ』を備えた着呼側機器が記載されていると認められる。
　
エ．上記（１）の【００４３】の「本実施形態に係る着呼側の端末５は，・・・予め定められる発呼者情報を再生して，ユーザに着呼を報知する発呼者情報再生部（着呼報知手段）５２と，・・・とを備えている。なお，本実施形態では，発呼者情報がアニメーションであり，上記発呼者情報再生部５２は，発呼者情報受信部５４が受信した発呼者情報を，例えば，液晶表示装置などの表示部へアニメーションとして表示して，ユーザに着呼を報知する。」の記載によれば，引用発明には『着呼報知手段』が記載されている。
　また，上記（５）の【０１０３】の記載に基づき，「発呼側の端末３ｅは，発呼側端末番号と選択情報との双方を着呼側の端末５ｅに送信する。・・・着呼側の端末５ｅの発呼者情報取得部６０は，受信済発呼者情報ＤＢ５９ｅを参照して，双方に対応する発呼者情報が既に格納されている場合（Ｓ６４にて，YES の場合），図１５と同様，図２に示すＳ９以降の処理を行い，当該発呼者情報を再生して，着呼を報知する。・・・着呼側の端末５ｅは，発呼者情報サーバ９ａから通知された発呼者情報を再生して，着呼を報知する。」（【０１０６】）及び図１５，図２の記載によれば，発呼側の端末から着呼側の端末への発呼側端末番号と選択情報との双方の送信は発呼側機器が着呼側機器を呼び出したときになされることは明らかであり，受信済発呼者情報ＤＢに発呼側端末番号と選択情報との双方に対応する発呼者情報が既に格納されている場合に当該発呼者情報を再生して着呼を報知するのであるから，いずれか１つに対応するタイプの発呼者情報を再生するといえる。
　したがって，引用例には，『いずれか１つに対応するタイプの発呼者情報を，前記発呼側機器が着呼側機器を呼び出したときに，再生する着呼報知手段』を備えた着呼側機器が記載されていると認められる。
　
　したがって，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。
「発呼側機器，発呼者情報サーバ及び着呼側機器を有する通信システムであって，前記着呼側機器で，発呼者が設定した発呼者情報を再生し，前記発呼者情報は着呼側の端末が呼び出される前に発呼者情報サーバから着呼側機器に送られる通信システムにおいて，
　前記発呼者情報サーバは，
　１つの発呼側機器について，ユーザの指示や予め定められた条件などに基づいて選択されたタイプが異なる発呼者情報を着呼側機器に送信する発呼者情報送信部を有し，
　前記着呼側機器は，
　これまで受信した発呼者情報を格納する受信済発呼者情報ＤＢと，
　いずれか１つに対応するタイプの発呼者情報を，前記発呼側機器が着呼側機器を呼び出したときに，再生する着呼報知手段と
　を備えたことを特徴とする通信システム。」
　
　
３．対比・判断
（１）引用発明の「発呼側機器」，「着呼側機器」はそれぞれ「発呼側デバイス」，「被呼側デバイス」といえる。また，引用発明の「発呼者情報」は着呼側機器がユーザに着呼を報知する際に再生されるメロディやアニメーションなどであるから本願発明の「発呼側の呼び出しの識別情報」に相当し，引用発明の「発呼者情報サーバ」は発呼者情報を着呼側機器に送信するものであるから本願発明の「外部装置」に相当する。また，引用発明の「前記着呼側機器で，発呼者が設定した発呼者情報を再生」することは本願発明の「前記被呼側のデバイスで，発呼側の呼び出しの識別情報を出力」することと差異はない。更に，引用発明は「前記発呼者情報は着呼側の端末が呼び出される前に発呼者情報サーバから着呼側機器に送られる」ものであり，「呼び出される前に」は「予め」に包含される概念であるから，本願発明の「前記呼び出しの識別情報は予め前記外部装置から前記被呼側のデバイスに送られる」ことと差異はない。
　したがって，両者は「発呼側デバイス，外部装置および被呼側デバイスを有するシステムであって，前記被呼側のデバイスで，発呼側の呼び出しの識別情報を出力し，前記呼び出しの識別情報は予め前記外部装置から前記被呼側のデバイスに送られるシステム」の点で差異はない。
　
（２）引用発明の発呼者情報送信部はタイプが異なる発呼者情報を着呼側機器に送信する手段であるから，引用発明と本願発明とは，下記の相違点１，２は別として，「前記外部装置は，１つの発呼側デバイスについて，タイプが異なる呼び出しの識別情報を被呼側のデバイスに送信する手段を有」する点で一致している。
　
（３）引用発明の「受信済発呼者情報ＤＢ」はこれまで受信した発呼者情報を格納するものであるから，本願発明の「格納デバイス」とは，下記の相違点２は別として，「受信した前記呼び出し情報を格納する格納デバイス」の点で一致している。
　
（４）引用発明の「着呼報知手段」と本願発明の「出力する手段」とは，下記の相違点２は別として，「いずれか１つに対応するタイプの呼び出しの識別情報を，前記発呼側のデバイスが被呼側のデバイスを呼び出したときに，出力する手段」の点で一致している。
　
　したがって，本願発明と引用発明とを対比すると，両者は，以下の点で一致し，また，相違している。
（一致点）
「発呼側デバイス，外部装置および被呼側デバイスを有するシステムであって，前記被呼側のデバイスで，発呼側の呼び出しの識別情報を出力し，前記呼び出しの識別情報は予め前記外部装置から前記被呼側のデバイスに送られるシステムにおいて，
　前記外部装置は，
　１つの発呼側デバイスについて，タイプが異なる呼び出しの識別情報を被呼側のデバイスに送信する手段を有し，
　前記被呼側のデバイスは，
　受信した前記呼び出し情報を格納する格納デバイスと，
　いずれか１つに対応するタイプの呼び出しの識別情報を，前記発呼側のデバイスが被呼側のデバイスを呼び出したときに，出力する手段と
　を備えたことを特徴とするシステム。」
　
（相違点１）
　本願発明ではタイプが異なる「複数の」呼び出しの識別情報が送信され格納デバイスには「複数の」呼び出し情報が格納されるのに対し，引用発明は「ユーザの指示や予め定められた条件などに基づいて選択されたタイプが異なる発呼者情報」が送信され格納されるものであり，「複数の」呼び出しの識別情報（発呼者情報）の送信及び格納については明らかにされていない点。
　
（相違点２）
　本願発明では，「被呼側のデバイスに送信する手段」は，１つの発呼側デバイスについて，「タイプが異なる複数の呼び出しの識別情報」のみならず「当該複数の呼び出しの識別情報のそれぞれを出力すべき日時を示す複数のカレンダー情報」をも送信し，「格納デバイス」には「前記複数の呼び出し情報および前記複数のカレンダー情報」を格納し，「出力する手段」が出力するものが「前記複数のカレンダー情報のいずれか１つに対応するタイプの呼び出しの識別情報」であるのに対し，引用発明は上記「当該複数の呼び出しの識別情報のそれぞれを出力すべき日時を示す複数のカレンダー情報」についての構成を有しない点。
　
　以下，上記各相違点について検討する。
（相違点１についての検討）
　引用発明の受信済発呼者情報ＤＢはこれまで受信した発呼者情報を格納するものであるから，上記「２．引用発明」の項の「（５）」の項の【０１０５】の「受信済発呼者情報ＤＢ５９ｅを参照し，組み合わせに対応する発呼者情報が格納されていない場合に，・・・送信を指示する」の記載に照らせば，引用発明においても，一度に送信するものが現発呼で使用されるもののみであっても，１つの発呼側機器について過去に選択された異なる発信者情報が格納されることにより，結果的にタイプが異なる「複数の」発信者情報が送信され格納され得るものであることは明らかである。そして，本願発明はタイプが異なる複数の呼び出しの識別情報が同時に送信されるのか否かについてまでは規定していないから，相違点１には実質的な相違はない。
　また，上記「２．引用発明」の項の「（４）」の項の【００７８】の記載に照らせば，発呼側機器−発呼者情報サーバ間については選択され得る複数の発呼者情報情報は予め発呼側機器から発呼者情報サーバに全て送信されていると解される。そして，上記「２．引用発明」の項の「（３）」の項及び上記「２．引用発明」の項の「（５）」の項の【０１０７】の記載に照らせば，引用発明における発呼者情報の送信の態様はトラフィックの軽減を意図したものであるから，引用発明において周知のバックグラウンドでの伝送（例えば，特表平１１−５１１５７４号公報の１２頁６〜８行，１５頁１〜１１行参照。）を適用して通信網の負担を軽減することにより，発呼者情報サーバ−着呼側機器間においても発呼側機器−発呼者情報サーバ間と同様に，現発呼で使用する発呼者情報のみならず全ての発呼者情報を予め発呼者情報サーバから着呼側機器に送るようにすることは，当業者が容易になし得ることにすぎない。
　
（相違点２についての検討）
　被呼側の機器における着呼時の呼び出しにおいて，元旦，クリスマス，結婚記念日，誕生日などの特定日に通常とは異なる着信表示，着信音を出力するようにすることは普通に行われている（例えば，特開２００１−３２０４４８号公報の【００２１】，図２，図３，実願平０３−１１１１９１号（実開平０５−０５５６４４号）のＣＤ−ＲＯＭの【０００６】参照。）ことであり，このような要請は被呼側のみならず発呼側にもあることも明らか（例えば，特開２０００−００４２７６号公報の【００１７】，【００１９】，【００２３】，特開平１０−３２７４４７号公報の【００２８】〜【００３３】，図４参照。）であるから，引用発明の発呼者情報の選択に係る「予め定められた条件」をカレンダー情報とし得ることは明らかである。
　また，上記「２．引用発明」の項の「（５）」の項の【０１０８】には，着呼側機器に発呼者情報の有効期間等の情報も送信し，受信済発呼者情報ＤＢに発呼者情報と共に発呼者情報の有効期間等の情報も併せて記憶しておくことが記載されており，有効期間は「呼び出しの識別情報のそれぞれが出力可能である日時を示す」ものであるから，引用発明において受信済発呼者情報ＤＢに発呼者情報と発呼者情報のそれぞれを出力すべき日時を規定するカレンダー情報とを格納することに阻害要因はない。そして，「前記複数のカレンダー情報のいずれか１つに対応するタイプの呼び出しの識別情報を，前記発呼側のデバイスが被呼側のデバイスを呼び出したときに，出力する」ことは，引用発明において受信済発呼者情報ＤＢに発呼者情報と発呼者情報のそれぞれを出力すべき日時を規定するカレンダー情報とを格納することに伴い，自ずと導出されることに過ぎない。
　したがって，相違点２は，引用発明に周知技術を適用することにより当業者が容易になし得ることである。
　
　そして，本願発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測し得る範囲のものであり，格別なものではない。
　
　
４．むすび
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものと認められるから，特許法第２９条第２項の規定により，特許を受けることができない。
　
　よって，結論のとおり審決する。