2019-006859

特願２０１６－５３３８０８「使用量データを収集して複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法、システム、およびコンピュータ・プログラム」拒絶査定不服審判事件〔平成２７年　２月１９日国際公開、ＷＯ２０１５／０２１９３５、平成２８年　９月２３日国内公表、特表２０１６－５２９６２２、請求項の数（１３）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は、２０１４年（平成２６年）８月１４日（パリ条約による優先権主張　外国庁受理２０１３年８月１６日、米国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。 平成３０年　４月　３日付け：拒絶理由通知書 平成３０年　７月　２日　　：意見書、手続補正書の提出 平成３０年　９月１９日付け：拒絶理由（最後の拒絶理由）通知書 平成３０年１１月１９日　　：意見書、手続補正書の提出 平成３１年　３月１４日付け：拒絶査定（原査定） 令和　元年　５月２７日　　：審判請求書、手続補正書の提出 令和　元年　８月　９日付け：前置報告書 令和　元年１２月１１日　　：上申書の提出 令和　２年　６月　４日付け：拒絶理由（当審拒絶理由）通知書 令和　２年　９月　８日　　：意見書、手続補正書の提出 第２　原査定の概要 原査定（平成３１年３月１４日付け拒絶査定）の概要は次のとおりである。 本願請求項１、２、５ないし１０及び１３ないし１７に係る発明は、以下の引用文献Ａに記載の発明に基づいて、また、本願請求項３、４、１１及び１２に係る発明は、以下の引用文献Ａ及びＢに記載の発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 Ａ　特開２００８－１３１４１８号公報 Ｂ　特開２００３－１３４１９４号公報 第３　当審拒絶理由の概要 当審拒絶理由の概要は次のとおりである。 ●理由１（明確性要件違反） 本願請求項１ないし１５に係る発明は、明確でないから、特許法３６条６項２号に規定する要件を満たしていない。 ●理由２（進歩性欠如） 本願請求項１及び８に係る発明は、以下の引用文献１ないし３に記載された発明に基づいて、本願請求項２ないし７及び９ないし１５に係る発明は、以下の引用文献１ないし４に記載された発明に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 ［引用文献等一覧］ １　特開２００８－１３１４１８号公報（拒絶査定時の引用文献Ａ） ２　特開２００５－２１６１２８号公報（当審において新たに引用した文献） ３　特開２００４－３４３５４３号公報（当審において新たに引用した文献） ４　特開２００３－１３４１９４号公報（拒絶査定時の引用文献Ｂ） 第４　本願発明 本願請求項１ないし１３に係る発明（以下、それぞれ「本願発明１」ないし「本願発明１３」という。）は、令和２年９月８日に提出された手続補正書により手続補正された特許請求の範囲の請求項１ないし１３に記載された事項により特定される発明であり、本願発明１ないし１３は以下のとおりの発明である。（なお、下線は、補正された箇所を示す。） 「　　【請求項１】 複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法であって、 プロセッサが下記のステップを実行することを含み、前記方法が、 一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含む、前記収集するステップと、 収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間と、前記信号強度とを使用して生成される、前記生成するステップと、 送信側から前記複数のデバイスの少なくとも１つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、 前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップと、 前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも１つのデバイスに、前記メッセージを経路設定するステップと、 受信者が応答するまで、優先順位付けアルゴリズムに基づいて、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定するステップと、 を含む、前記方法。 【請求項２】 前記複数のデバイスが、ラップトップ、タブレット、携帯電話を含み、前記デバイスがそれぞれのメッセージング・システムと通信し、前記メッセージング・システムが、テキスト・インスタント・メッセージングまたはショート・メッセージング・サービス（ＳＭＳ）を含む、請求項１に記載の方法。 【請求項３】 前記予測アベイラビリティ・モデルが、デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングをさらに使用して生成される、請求項１又は２に記載の方法。 【請求項４】 前記デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングが、最も頻繁に使用されるデバイス又はある場所で最も頻繁に使用されるデバイスの統計的結論を含むアベイラビリティ・レーティングである、請求項３に記載の方法。 【請求項５】 前記選択が、前記複数のデバイスの優先順位及び業務ポリシーを考慮して行われる、請求項１～４のいずれか一項に記載の方法。 【請求項６】 前記メッセージが個人的なメッセージである場合に、前記選択が、前記優先順位を考慮して前記複数のデバイスのうちの該ユーザの個人的なデバイスを選択することによって行われる、請求項１～５のいずれか一項に記載の方法。 【請求項７】 複数の通信デバイス上でのユーザのアベイラビリティを決定するためのシステムであって、 コンピュータのプロセッサによって実行可能なプログラムを使用して、以前に収集されたアベイラビリティ・データに基づいて、一人のユーザによって使用される複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成する第１のアルゴリズムであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含み、前記予測アベイラビリティ・モデルが、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを使用して生成される、前記第１のアルゴリズムと、 前記プログラムを使用して、送信側から前記複数のデバイスの少なくとも１つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けする第２のアルゴリズムと、 前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すように構成されたインターフェースと、 前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも１つのデバイスに、前記メッセージを経路設定するように構成された経路設定論理であって、受信者が応答するまで、前記第２のアルゴリズムに基づいて、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定する、前記経路設定論理と、 を備える、前記システム。 【請求項８】 前記複数のデバイスが、ラップトップ、タブレット、セル電話を含み、前記デバイスがそれぞれのメッセージング・システムと通信し、前記メッセージング・システムが、テキスト・インスタント・メッセージングまたはショート・メッセージング・サービス（ＳＭＳ）を含む、請求項７に記載のシステム。 【請求項９】 前記予測アベイラビリティ・モデルが、デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングをさらに使用して生成される、請求項７又は８に記載のシステム。 【請求項１０】 前記デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングが、最も頻繁に使用されるデバイス又はある場所で最も頻繁に使用されるデバイスの統計的結論を含むアベイラビリティ・レーティングである、請求項９に記載のシステム。 【請求項１１】 前記選択が、前記複数のデバイスの優先順位及び業務ポリシーを考慮して行われる、請求項７～１０のいずれか一項に記載のシステム。 【請求項１２】 前記メッセージが個人的なメッセージである場合に、前記選択が、前記優先順位を考慮して前記複数のデバイスのうちの該ユーザの個人的なデバイスを選択することによって行われる、請求項７～１１のいずれか一項に記載のシステム。 【請求項１３】 複数の通信デバイス上でのユーザのアベイラビリティを決定するためのコンピュータ・プログラムであって、プロセッサに請求項１～６のいずれか一項に記載の方法を実行させる、前記コンピュータ・プログラム。」 第５　当審拒絶理由の理由１（明確性要件違反）について １　請求項１及び１５に記載の「使用量データ」がいかなる量のデータであるのか明確でないとの指摘に対し、令和２年９月８日に提出された手続補正書による手続補正（以下、単に「本件補正」という。）により、「使用量データ」に関する事項は削除された。 ２　請求項１及び８に記載の「アベイラビリティ時間」の意味が明確でないとの指摘に対し、本件補正により、「アベイラビリティ時間又は期間」と補正され、「期間」の概念である場合を含むことが明らかとされた。 ３　請求項１及び８に記載の「リアルタイムで」の意味が明確でないとの指摘に対し、本件補正により、「リアルタイムで」との記載は削除された。 ４　請求項１の「経路設定」と「経路指定」との関係が明確でないとの指摘に対し、本件補正により、「経路指定」が「経路設定」に補正され、用語が統一された。 ５　請求項２記載の「アベイラビリティを含む」における「アベイラビリティ」と、請求項２が引用する請求項１に記載の「アベイラビリティを決定する」における「アベイラビリティ」との関係が明確でないとの指摘に対し、本件補正により、請求項２は削除された。 ６　請求項９に記載の「ユーザ応答回数／アベイラビリティ」の意味が明確でないとの指摘に対し、本件補正により、請求項９は削除された。 以上の１ないし６より、当審拒絶理由の理由１（明確性要件違反）は解消した。 第６　当審拒絶理由の理由２（進歩性欠如）について １　引用文献、引用発明等 （１）引用文献１について ア　引用文献１記載事項 当審拒絶理由に引用された引用文献１には、図面とともに次の事項が記載されている。（下線は、強調のため当審が付与した。以降の記載においても同様。） 「【特許請求の範囲】 【請求項１】 …（中略）… とを備えた通信端末。 …（中略）… 【請求項８】 …（中略）… ことを特徴とする相手先アドレス提示方法。 …（中略）… 【請求項１５】 １人の通信相手に対して複数個の相手先アドレスが登録可能な相手先アドレス格納部を備えた通信端末で使用される相手先アドレス提示方法をコンピュータで実行可能なプログラムであり、このプログラムは下記（ａ）－（ｃ）のステップを備える。 …（後略）」 「【背景技術】 【０００２】 近年、携帯電話の保有率が増加し、携帯電話を複数個保有しているユーザの数も増加している。この理由の１つとしては、私用・社用で電話番号やメールアドレスを使い分けするユーザが増加していることが挙げられる。自宅の電話や勤務先の電話なども含めると、通信相手に対する接続先は、今後も増加すると予想される。」 「【００１８】 したがって、ユーザは、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できる。 【発明を実施するための最良の形態】 【００１９】 次に、本発明の実施例について図面を参照しながら説明する。なお、以下では、携帯電話を例として、本発明の実施例を説明するが、本発明は、通信機能を有する通信端末全般、例えば、固定電話機にも適用できることは、以下の説明から、当業者には明らかであろう。 【００２０】 ［実施例１］ 図１は、本発明に係る携帯電話の構成例を示すブロック図である。 【００２１】 この携帯電話は、キー入力部１０と、表示部２０と、無線通信部３０と、制御部４０と、メーラ５０と、電話帳６０とを含む。 【００２２】 ユーザは、表示部２０の表示を見ながら、キー入力部１０を操作することにより、無線通信部３０、制御部４０、メーラ５０を使用する。 【００２３】 電話帳６０は、後述されるように、通信相手毎に複数個の送信先アドレス（電話番号、メールアドレス等）を登録している。また、電話帳６０は、相手先アドレス毎に、過去にこの相手先アドレスからの着信回数を、曜日及び時間帯毎にカウントした値を、利用頻度情報として、利用頻度情報部に格納している。なお、この電話帳は、通常の電話帳と同様に、通信相手の自宅住所や勤務先住所等を合わせて記録していてもよい。また、この電話帳は、携帯電話内部に設けられていてもよいし、ＳＩＭカード内に設けされていてもよい。」 「【００２６】 携帯電話に着信があると、着信制御部４２は、図２のステップＳ１１１において、送信元。即ち、送信元電話番号を確認する。次に、着信制御部４２は、ステップＳ１１２において、送信元電話番号が、電話帳（ｐｈｏｎｅ　ｂｏｏｋ；ＰＢ）に登録されているか否かを判定する。この判定結果が”Ｎｏ”の場合は、着信制御部４２は、ステップＳ１２０で、通常の着信処理を行う。なお、この通常の着信処理は、当業者にはよく知られているので、詳細な説明は、省略される。 【００２７】 ステップＳ１１２での判定結果が”Ｙｅｓ”の場合、携帯電話はステップＳ１１３で、電話帳６０内でのデータ保存場所を確認を確認する。即ち、送信元の電話帳データの格納場所が携帯電話内部か、ＳＩＭカード内かを確認する。 【００２８】 次に、携帯電話は、ステップＳ１１４で、送信元電話番号が保存されたロケーションの番号、即ちロケーション番号を確認する。そして、携帯電話は、ステップＳ１１５で、送信元のロケーション番号に登録された電話番号から登録している電話帳の項目番号.を確認する。 【００２９】 後述されるとおり、本実施例では、電話帳６０は、項目番号毎に、着信した曜日をカウントする着信曜日カウンタと、着信した時間をカウントする着信時間カウンタとを有する。 【００３０】 ステップＳ１１６では、携帯電話のカウンタ制御部４４は、受信時の曜日を取得する。この曜日は、携帯電話内に設けられたタイマから得られる。ステップＳ１１７では、カウンタ制御部４４は、該当する項目番号の該当曜日の曜日カウンタ欄に、値”１”を積算する。 【００３１】 ステップＳ１１８では、カウンタ制御部４４は、受信した時間帯を示す値を取得する。この値も、タイマから得られる。ステップＳ１１９では、カウンタ制御部４４は、該当する項目番号、該当時間帯の時間カウンタ欄に、値”１”を積算する。このようにして、カウンタ制御部４４は、電話帳の利用頻度情報を、着信毎に、更新する。 【００３２】 ステップＳ１１９が終了すると、着信制御部４２は、通常の着信処理を行う。 【００３３】 次に、図３を参照して、図１の携帯電話の発信時の動作、特に、利用頻度制御部４５の動作につき説明される。　図３は、図１の携帯電話の発信時の動作を説明するためのフローチャートである。 【００３４】 携帯電話ユーザが、電話帳に登録している相手と通話する場合、送信先を選択する。この選択は、電話帳からの選択、リダイアルでの名前検索により行われてもよい。 【００３５】 ステップＳ３１１では、利用頻度制御部４５は、は、送信相手を示す情報を取得する。ステップＳ３１２では、利用頻度制御部４５は、携帯電話内の時計情報から、当日の曜日を取得する。また、利用頻度制御部４５は、ステップＳ３１３で、現在の時間帯を示す値を取得する。なお、この値の例は、図５に示されている。 【００３６】 後述されるように、本実施例では、電話帳６０内で、電話番号を登録している項目は、項目番号３から８である。したがって、本実施例では、１通信相手につき、最大６個までの電話番号が登録可能である。このため、ステップＳ３１４では、ループパラメータ（Ｎ）の初期値は、”３”にセットされる。 【００３７】 これら最大６候補からの選択は、６候補につき登録された利用頻度情報に基づいて、次のように行われる。 【００３８】 ステップＳ３１５では、利用頻度制御部４５は、ステップＳ３１２で取得された曜日に対応する、項目番号Ｎの着信曜日カウンタの値をレジスタＡに読み込む。次に、ステップＳ３１６では、利用頻度制御部４５は、ステップＳ３１２で取得された時間帯情報に対応する、項目番号Ｎの着信時間カウンタの値を、レジスタＢに読み込む。 【００３９】 ステップＳ３１７では、利用頻度制御部４５は、レジスタＡとレジスタＢの値を加算し、項目番号Ｎの利用頻度情報値を求め、加算結果をレジスタＮ＿Ｃに保存する。なお、レジスタＡ，ＢおよびレジスタＮ＿Ｃ（Ｎ＝３、４、・・・、８）は、利用頻度制御部４５に内蔵されたレジスタである。 【００４０】 ステップＳ３１８では、利用頻度制御部４５は、ループパラメータＮの値が８か否かを判定する、この判定結果が”Ｎｏ”の場合、利用頻度制御部４５は、ステップＳ３１９で、ループパラメータＮの値を、１だけ増加させる。この後、利用頻度制御部４５の処理は、ステップＳ３１５に戻る。 【００４１】 これらステップＳ３１５からＳ３１９までの処理により、項目番号３から８に対する利用頻度情報値Ｎ＿Ｃ（Ｎ＝３、４、・・・、８）が求められる。 【００４２】 ステップＳ３１８の判定結果が”Ｙｅｓ”の場合、利用頻度制御部４５は、ステップＳ３２０で、利用頻度情報値Ｎ＿Ｃ（Ｎ＝３、４、・・・、８）を比較し、最大値を検出する。 【００４３】 ステップＳ３２１では、利用頻度制御部４５は、この最大値に対応する項目番号の電話番号を、表示部に表示する。 【００４４】 携帯電話ユーザは、Sendキーを押すことで表示された電話番号に対して発信する（ステップＳ３２２）。」 「【００５７】 前述した実施例１は、携帯電話の電話機能に限って本発明を説明したが、この実施例２は、携帯電話の電子メール機能に限って、本発明を説明する。 【００５８】 なお、この実施例２の装置構成は、図１と同様である。 【００５９】 この実施例２の動作は、図６と図７とを参照して、説明される。図６は、実施例２の説明に使用される電話帳の例を示す。図７は、実施例２の発信時の動作を説明するためのフローチャートである。なお、図７のフローチャートにおいて、図３のフローチャートの参照符号と同一の符号を付したステップは、図３で説明したステップと同一内容である。なお、実施例２の着信時の動作は、、実施例１と同様であるので、この動作についての説明は、省略される。 【００６０】 図６は、電話帳のＺＺＺさんに関わる部分を示している。このＺＺＺさんの個人情報として、電話帳は、項目番号９と１０に、メールアドレスを２つ登録している。 【００６１】 ユーザは、ＺＺＺさんにメールを送る時には、図１のメーラ５０を立ち上げる。ユーザは、キー入力部１０を操作して、件名とメール本文を作成するそして、このメールのあて先にはＺＺＺさんを指定する（ステップＳ７１１）。 【００６２】 この指定に応答して、利用頻度制御部４５は、ステップＳ３１２、Ｓ３１３で、現時間の曜日情報と時間情報（詳しくは、時間帯情報）を取得する。ここでは、現時刻は、火曜の２０時（即ち、時間帯５）とする。 【００６３】 図６に示されたとおり、ＺＺＺさんの電話帳情報は、電話帳のＰｈｏｎｅロケーション番号２に登録されている。電話帳では。メールアドレスは、項目番号９と１０に登録されている。このため、ステップＳ７１４では、ループパラメータＮの初期値は、値”９”にセットされる。 【００６４】 ステップＳ３１５では、利用頻度制御部４５は、項目番号Ｎの利用頻度情報から、火曜日の欄の値を読み込む。また、ステップＳ３１６では、時間帯５の欄の値を読み取る。ステップＳ３１７では、両者の値を合計し、項目番号Ｎの利用頻度値Ｎ＿Ｃ（Ｎ＝９，１０）を得る。ステップＳ７１４、Ｓ３１４、Ｓ３１５、Ｓ３１６、Ｓ３１７、」Ｓ７１８、Ｓ７１９の処理により、ＺＺＺさんの２つのメールアドレスにつき、次の２つの利用頻度値が得られる。 ９＿Ｃ＝３０、　　１０＿Ｃ＝０ ステップＳ３２０では、利用頻度制御部４５は、これらの数値の最大値を検出する。そして、ステップＳ３２１では、利用頻度制御部４５は、最大値に対応するメールアドレス「[email protected]」を表示部に表示すると共に、このメールアドレスをメーラに伝える。メーラは、このメールアドレスを送信先アドレス欄にセットする。 【００６５】 ユーザが、Ｓｅｎｄキーを押し下げすると、メーラは、このメールを送信する（ステップＳ７２２）。 【００６６】 このように実施例２は、相手がすぐに受けとる確率が高いメールアドレスを選択することができる。よって、ユーザは、簡単な操作で、相手が直ちに受け取る可能性が高いアドレスへメールを送信できる。」 「【００６７】 図８は、第３の実施例で使用される電話帳内の１個の電話番号の利用頻度情報部の内容の一例を示す図である。図９は、第３の実施例の受信時の動作を説明するためのフローチャートである。図１０は、第３の実施例の発信時の動作を説明するためのフローチャートである。 【００６８】 図８は、特定の着信相手の電話番号からの利用頻度情報を示している。即ち、第２の実施例（当審注：「第３の実施例」の誤記と認める。）の電話帳は、特定着信相手からの利用頻度情報を、電話番号毎に持つ。図８に示されたとおり、第２の実施例（当審注：「第３の実施例」の誤記と認める。）における電話帳の利用頻度情報部は、時間帯と曜日に関する２次元カウンタ構成である。この利用頻度情報部は、着信してからの過去の着信回数を、着信曜日と着信時間帯の２次元情報として蓄積する。この第３の実施例では、図８は、図４の項目番号４の電話番号の利用頻度情報に対応する。 【００６９】 次に、図９を参照して、第３の実施例の受信時の動作が説明される。なお、図９の各ステップにおいて、図２と同一のステップ番号を付されたステップは、図２で説明されたステップと同一の動作を行うので、図２と同一動作を行うステップについての説明は、省略される。図９では、図２の破線部Ａが、破線部Ａ’に置き換えられている。 【００７０】 図９では、カウンタ制御部４４は、ステップＳ９０１で、携帯電話に内蔵されたタイマから着信時の曜日情報を取得する。また、カウンタ制御部４４は、ステップＳ９０２で、タイマから着信時の時間帯情報を取得する。そして、カウンタ制御部４４は、ステップＳ９０３で、ステップＳ１１６で確認された項目番号の利用頻度情報を格納する２次元カウンタに、１を加算する。即ち、この利用頻度情報の、ステップＳ９０１で取得された曜日情報とステップＳ９０２で取得された時間帯情報に相当する欄に、値”１”を加算する。 【００７１】 例えば、相手先の発信電話番号に相当する利用頻度情報が図８に示されたものであり、また、着信曜日が土曜日、着信時間帯が時間帯６であった場合を考えてみる。この場合には、図８の土曜日ん時間帯６の欄の値は、”８”であるので、カウンタ制御部４４は、この欄の値を、”９”に変更する。 【００７２】 このようにして、実施例３の利用頻度情報が」生成される。この実施例１,２では、利用頻度情報は、着信曜日と着信時間帯とを個別にカウントしていた。この実施例１、２は、実施例３に対して、利用頻度情報を蓄積するためのメモリが小容量でよいという利点を有する。 【００７３】 次に、図１０を参照して、第３の実施例の発信時の動作が説明される。なお、図１０の各ステップにおいて、図３と同一のステップ番号を付されたステップは、図３で説明されたステップと同一の動作を行うので、図３と同一動作を行うステップについての説明は、省略される。図１０では、図３の破線部Ｂが、破線部Ｂ’に置き換えられている。 【００７４】 図１０において、利用頻度制御部４５は、ステップＳ１１０１において、ステップＳ３１１で取得された現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータＮに対応する利用頻度値を読み出す。即ち、このループパラメータの値に相当する電話番号の利用頻度情報が図８であり、現時点の曜日が日曜日であり、現時間帯が時間帯４である場合を考えてみる。この場合には、利用頻度制御部４５は、日曜日の時間帯４の値”５”を、読み出す。他のループパラメータに対応する電話番号についても同様である。 【００７５】 実施例１、２は、発信の際に、曜日カウンタの値と時間帯カウンタの値を加算することにより、発信曜日、発信時間帯の利用頻度値を、相手先電話番号毎に得ている。このため、通信相手先が、特定の曜日にのみ、大部分の発信を行う癖を持つ場合には、この利用頻度値は、この特定の曜日に時間帯情報により、事実上決定されてしまうこのが起こりうる。また、通信相手先が、特定の時間帯にのみ、大部分の発信を行う癖を持つ場合には、この利用頻度値は、この特定時間帯の時間帯情報により、事実上決定されてしまうこのが起こりうる。したがって、第３の実施例は、第１、第２の実施例と比較すれば、利用頻度情報を蓄積するためのメモリの容量が大きくなるが、第１、第２の実施例よりも、発信時に、適時かつ適切な相手先アドレスを、ユーザに提供する。」 「【００７６】 なお、以上で説明した実施例１から３では、利用頻度値が最大となる相手先アドレスを１個のみ提示する例について説明した。本発明は、この利用頻度値が高い順に複数個提示するように修正されてもよい。この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、１つのアドレスを選択して発信することが出きる。また、この提示の際に、利用頻度値を電話番号とともに表示すれば、ユーザは、相手先アドレスの選択が容易となる。」 「【図８】 」 イ　引用発明 したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。 「　一人のユーザが携帯電話を複数個所有し、私用・社用でアドレスを使い分けるユーザが増加していることを背景として、ユーザが、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できるようにするための方法、携帯電話又はコンピュータで実行可能なプログラムであって、 携帯電話の電話帳は、通信相手毎に複数個の送信先アドレス（電話番号、メールアドレス等）を登録しており、相手先アドレス毎に、過去にこの相手アドレスからの着信回数を、曜日及び時間帯毎にカウントした値を、利用頻度情報として、利用頻度情報部に格納したものであり、 携帯電話に着信があると、着信制御部は、送信元電話番号が電話帳に登録されているか否かを判定し、判定結果が”Ｙｅｓ”の場合、カウンタ制御部は、受信時の曜日と受信した時間帯を表す値を取得して、該当する項目番号の該当曜日の曜日カウンタ欄と該当する項目番号の該当時間帯の時間カウンタ欄に値”１”を積算することにより、電話帳の利用頻度情報を更新し、 ユーザが電話帳に登録している相手と通話する場合、送信先を選択すると、利用頻度制御部は、送信相手を示す情報と当日の曜日と現在の時間帯を示す値とを取得し、 電話帳内で、電話番号を登録している項目が、項目番号３から８までの最大６個までの電話番号が登録可能な場合、利用頻度制御部は、取得された曜日に対応する、項目番号Ｎの着信曜日カウンタの値をレジスタＡに読み込み、取得された時間帯情報に対応する、項目番号Ｎの着信時間カウンタの値を、レジスタＢに読み込み、レジスタＡとレジスタＢの値を加算し、項目番号Ｎの利用頻度情報値を求め、加算結果をレジスタＮ＿Ｃに保存する処理により、項目番号３～８に対する利用頻度情報値Ｎ＿Ｃ（Ｎ＝３、４、…８）を求め、 利用頻度制御部は、利用頻度情報値Ｎ＿Ｃ（Ｎ＝３、４、…８）を比較し、最大値を検出し、この最大値に対応する項目番号の電話番号を表示部に表示し、 前述した実施例１では携帯電話の電話機能に限って説明したが、実施例２では、携帯電話の電子メール機能に限って説明し、ユーザが、メールを送る時に、このメールのあて先にＺＺＺさん（電話帳には、ＺＺＺさんの個人情報として、メールアドレスを２つ登録している。）を指定すると、利用頻度制御部は、ＺＺＺさんの２つのメールアドレスにつき、２つの利用頻度値を得て、これらの数値の最大値を検出し、最大値に対応するメールアドレスを表示部に表示し、 第３の実施例では、電話帳の利用頻度情報部は、時間帯と曜日に関する２次元カウンタ構成であり、 受信時に、カウンタ制御部は、着信時の曜日情報と時間帯情報とを取得し、確認された項目番号の利用頻度情報を格納する２次元カウンタの、取得された曜日情報と時間帯情報に相当する欄に１を加算し、 発信時に、利用頻度制御部は、現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータＮに対応する利用頻度値を読み出し、他のループパラメータについても同様であり、 相手先アドレスを、利用頻度値が高い順に複数個提示するように修正してもよく、この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、１つのアドレスを選択して発信することが出きる、 方法、携帯電話又はコンピュータ・プログラム。」 （２）引用文献２～４について ア　引用文献２について 当審拒絶理由に引用された引用文献２には、図面とともに、次の事項が記載されている。 「【０００６】 本発明は、上記した点に鑑みてなされたものであり、より簡易な構成でかつ低コストで携帯情報端末装置を使った緊急事態通知のサービスを実現できる緊急通知を提供することを目的とする。」 「【００４４】 図３は、特定情報記憶メモリ１４ａに記憶される特定情報の例を示す図である。図示した例では、特定情報である電話番号を、発呼の優先順位及び電話番号に関する情報（名前、電話番号が勤務先である等）と共に記憶している。実施形態１の緊急通知装置は、緊急事態の発生を検出すると、優先順位の高いものから順に電話番号を発呼する。したがって、図３の例では、緊急事態発生検出により先ず「山田太郎」の電話が発呼される。この際、「山田太郎」の電話への発呼に対する応答がなかった場合、次に優先順位が高い「勤務先」の電話に対して発呼する。さらに、実施形態１の緊急通知装置は、この発呼にも応答がなかった場合には次に優先順位が高い電話に対して発呼する、というように通信が成立するまで順次優先順位に従って電話を発呼する。」 上記記載からみて、当該引用文献２には、「携帯情報端末装置を使った緊急事態通知のサービスにおいて、緊急事態の発生を検出すると、通信が成立するまで、優先順位の高いものから順に電話番号を発呼すること」という技術的事項が記載されていると認められる。 イ　引用文献３について 当審拒絶理由に引用された引用文献３には、図面とともに、次の事項が記載されている。 「【０００５】このようなシステムであれば、汎用のコードレス無線電話システムを利用することで、新たにシステムを構築する場合にシステムを安価に提供できる利点がある。また、既設のナースコールシステムにコードレス無線電話システムを増設する場合にも、変換装置を追加するだけで容易に接続することができる。」 「【００５４】図６は、この発明の第２の実施形態に係わるアダプタ装置の発呼制御処理手順とその内容を示すフローチャートである。なお、ナースコールシステム及びアダプタ装置のハードウエア構成については、前記第１の実施形態と同一なので前記図１及び図２を引用して説明を行う。」 「【００５７】一方、発呼モードとして順次呼出モードが設定されていたとする。この場合アダプタ装置８は、ステップ６ｅに移行して記憶部８３から緊急呼出先として予め記憶されている複数の携帯端末の電話番号のうちの１つを読み出す。読み出し順序は予め設定した優先順位に従う。続いてアダプタ装置８は、ステップ６ｆにより、上記読み出された携帯端末に対し発呼するための構内ＰＨＳ対応の呼設定メッセージを作成する。このとき、呼設定メッセージの発番号を表す情報要素エリアには、上記一斉呼出モードの場合と同様に、「緊急呼出」であることを示す“００１”と、呼出元の患者の識別番号「０１２３」とが挿入される。そして、ステップ６ｇにより、上記作成された呼設定メッセージを通信インタフェース８５からＰＢＸ４へ向け送信する。 【００５８】次にアダプタ装置８は、ステップ６ｉにより一定時間の経過を監視しながら、ステップ６ｈにより上記呼設定メッセージの着信先となる携帯端末からの着呼応答を監視する。そして、上記一定時間内に着呼応答が検出されると、緊急呼出処理を終了する。 【００５９】これに対し、上記一定時間内に着呼応答が検出されない場合には、アダプタ装置８はステップ６ｊに移行して未選択の緊急呼出先がまだ残っているか否かを判定する。この判定の結果、未選択の緊急呼出先がまだ残っている場合にはステップ６ｅに戻り、記憶部８３から優先順位が次の携帯端末の電話番号を読み出す。そして、この読み出された携帯端末の電話番号に従いステップ６ｆにより呼設定メッセージを作成し、この作成された呼設定メッセージをステップ６ｇによりＰＢＸ４に向け送信する。以後、携帯端末からの着信応答が検出されるまで、上記ステップ６ｅ～ステップ６ｊによる順次発呼制御を繰り返す。」 上記記載からみて、当該引用文献３には、「汎用の携帯端末を利用した自動ナースコールシステムにおいて、複数の携帯端末の電話番号を緊急呼出先とあらかじめ記憶しておき、順次呼出しモードが設定されている場合、前記電話番号を優先順位に従って読み出し、着呼応答が検出されるまで、順次発呼制御を繰り返すこと。」という技術的事項が記載されていると認められる。 ウ　引用文献４について 当審拒絶理由に引用された引用文献４には、図面とともに次の事項が記載されている。 「【請求項１】 通信時刻情報と通信種別と通信が成立したか否かを示す正否情報とを通信先に対応させた通信履歴情報を記憶する通信履歴部と、前記通信履歴部からの前記通信履歴情報に基づいて、予め定めた時間間隔の時間帯毎の各々の通信種別毎に接続成立回数と発呼回数との比に対応する通信応答率を解析し、現時刻に対応した時間帯における所定の通信種別の前記通信応答率、または現時刻に対応した時間帯における前記通信応答率の順位に応じて選択された通信の種別、または前記通信応答率の順位に応じて選択された時間帯と対応する通信種別の少なくとも１つを推薦通信情報として出力する解析部とを備えたことを特徴とする通信端末装置。」 「【請求項５】 通信先に対応した通信履歴情報を取得するステップと、前記通信履歴に基づいて、通信先へ通信すべき時間帯及び／または通信種別及び／または通信先が現時刻に受信する期待値を解析するステップと、前記解析された前記時間帯及び／または前記通信種別及び／または前記期待値を表示するために出力するステップと、を備えたことを特徴とする通信情報提示方法。」 「【００２７】本実施例の携帯電話では、通信種別として電話、チャット、インスタント・メッセージの３種類の通信を行なう場合を例とし、各々、電話機能部５２、チャット機能部５３、及びインスタント・メッセージ機能部５４とによって通信可能に構成されている。電話機能部５２の主要機能部は、電話での通信を行なうための通信部５２－１、電話での通信履歴を記憶する通信履歴記憶部５２－２、この通信履歴を後述する通信履歴処理部５５に通知する通信履歴通知部５２－３である。同様に、チャット機能部５３およびインスタント・メッセージ機能部５４の主要機能部も、チャット、インスタント・メッセージ通信を行なう通信部５３－１、５４－１、通信履歴を記憶する通信履歴記憶部５３－２、５４－２、この通信履歴を通信履歴処理部５５に通知する通信履歴通知部５３－３、５４－３である。」 上記記載からみて、当該引用文献４には、「通信時刻情報と通信種別（電話、チャット、インスタント・メッセージ）と通信が成立したか否かを示す正否情報とを通信先に対応させた通信履歴情報を記憶しておき、この通信履歴情報に基づいて、予め定めた時間間隔の時間帯毎の各々の通信種別毎に接続成立回数と発呼回数との比に対応する通信応答率を解析し、現時刻に対応した時間帯における所定の通信種別の通信応答率、または現時刻に対応した時間帯における通信応答率の順位に応じて選択された通信の種別、または通信応答率の順位に応じて選択された時間帯と対応する通信種別の少なくとも１つを推薦通信情報として出力するようにした通信端末装置又はその方法。」という技術的事項が記載されている。 ２　対比・判断 （１）本願発明１について ア　対比 以下、本願発明１と引用発明とを対比する。 （ア）引用発明は、「利用頻度情報」に基づいて、「ユーザ」が「通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレス」を選択できるようにするためのものであることから、送信先である通信相手、すなわち、送信先であるユーザがメッセージを受け取れる可能性すなわち「アベイラビリティ」を「決定」するためのものであるといえる。 また、引用発明では、一人のユーザが携帯電話を複数個所有し、私用・社用でアドレスを使い分けるユーザが増加していることを背景として、一つの送信先（ユーザ）ごとに複数のアドレスが存在することを前提とするものであるから、引用発明においては、「アドレス」と「携帯電話」である「デバイス」とは同一視することができる。 そうすると、引用発明は、本願発明１の「複数の通信デバイス上でのユーザのアベイラビリティ」を決定するものといい得る。 よって、引用発明に係る方法は、本願発明１の「複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法。」に相当する。 （イ）コンピュータで実行可能なプログラムは、一般的に、コンピュータに搭載された「プロセッサ」によって実行されることが技術常識であることから、引用発明に係る方法は、「プロセッサ」が「プログラム」を実行することにより、「着信制御部」、「カウンタ制御部」、「利用頻度制御部」による各処理を実行する態様を含んでいる。また、各処理を「ステップ」と称することは任意である。 そうすると、引用発明は、以下の相違点を除いて、本願発明１の「プロセッサが下記のステップを実行することを含む」との構成を備える点において共通する。 （ウ）引用発明は、「携帯電話の電話帳は、通信相手毎に複数個の送信先アドレス（電話番号、メールアドレス等）を登録」するものであり、また、「電話帳内で、項目番号３から８までの最大６個までの電話番号が登録可能な場合」があるから、「項目」は、通信相手の個々の「アドレス」（電話番号、メールアドレス等）に対応しているといえる。 引用発明は、着信があると（すなわち着信時に）、当日の曜日と現在の時間帯を示す値を取得し、送信元電話番号に該当する項目番号の該当曜日（すなわち、着信時の曜日に対応する）曜日カウンタ欄と該当時間帯（すなわち、着信時の時間帯に対応する）時間カウンタ欄に１を加算するものであり、また、相手先アドレス毎に、過去にこの相手アドレスからの着信回数を、曜日及び時間毎にカウントした値を、利用頻度情報（利用頻度値）として、利用頻度情報部に格納するものであり、また、通話またはメールを送るとき（発信時）に、利用頻度値が最も高い相手先アドレス、または、利用頻度値が高い順に複数の相手先アドレスを提示（表示）することにより、「ユーザが、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できるようにする」ものといえる。 ここで、引用発明において、「通信相手がすぐにメッセージを受け取れる可能性」は、本願発明１の「アベイラビリティ」に相当し、着信時に取得する「当日の曜日と現在の時間帯を示す値」は、当該「着信」の送信元となるユーザにとって「アベイラビリティ」がある「時間」又は「期間」を意味する。 よって、引用発明において、着信時に取得される「当日の曜日と現在の時間帯を示す値」は、本願発明１の「アベイラビリティ時間又は期間」に相当し、引用発明において、着信時に「当日の曜日と現在の時間帯を示す値」を取得することは、本願発明１において、「アベイラビリティ時間又は期間」を「収集」することに相当し、これら「収集」された「曜日と時間帯を表す値」を総称して「以前のアベイラビリティ・データ」と称することは任意である。 また、引用発明は、着信時に「曜日と時間帯を表す値」を取得すると、該当する項目番号、すなわち、送信元アドレスの該当曜日の曜日カウンタ欄と該当時間帯の時間カウンタ欄に１を積算することにより、あるいは、利用頻度情報部が２次元カウンタ構成である場合は、該当曜日と該当時間帯に相当する欄に１を加算することにより、「利用頻度情報」を更新するものであるから、前記（ア）を参酌すれば、「当日の曜日と現在の時間帯を示す値」は、「一人のユーザによって使用される複数のデバイスのそれぞれについての」ものである。 そうすると、本願発明１の「一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含む、前記収集するステップ」と引用発明とは、「一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間を含む、前記収集するステップ」に相当する構成を備える点において共通する。 （エ）本願発明１における「予測アベイラビリティ・モデル」は、「収集された前記以前のアベイラビリティ・データ」を使用して生成され、かつ、複数のデバイスを優先順位付けするために使用されるものであれば足りる。 一方、引用発明は、収集された、送信元のアドレスについての着信時の「当日の曜日と現在の時間帯を表す値」に基づいて、送信元のアドレスに対応する利用頻度値を１積算ないし加算することにより、利用頻度情報を更新（生成）し、また、当該利用頻度情報は、ユーザがアドレス（デバイス）を選択できるように利用頻度値が高い順に複数個のアドレスを提示するために使用することも可能とされている。 以上からすれば、引用発明の「利用頻度情報」又は「利用頻度（情報）値」は、「収集された前記以前のアベイラビリティ・データ」を使用して生成され、かつ、複数のデバイスを優先順位付けするために使用するものである点において、本願発明１の「予測アベイラビリティ・モデル」と共通する。 そうすると、前記（ウ）を参酌すれば、本願発明１の「収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間と、前記信号強度とを使用して生成される、前記生成するステップ」と引用発明とは、「収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間を使用して生成される、前記生成するステップ」を備える点において共通する。 （オ）所定のアドレス（電話番号又はメールアドレス）に対して発信をすると、当該アドレスに基づいて、発信の内容であるメッセージが送信先のデバイスに到達するようにネットワーク上で経路設定がなされることは自明なことであるから、前記発信は、経路設定と同一視できる処理といえる。 引用発明は、「発信時に、利用頻度制御部は、現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータＮに対応する利用頻度値を読み出し、他のループパラメータについても同様であり、相手先アドレスを、利用頻度値が高い順に複数個提示するように修正してもよく、この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、１つのアドレスを選択して発信することが出きる」との構成を備えるものであるから、引用発明は、ユーザの携帯電話（送信側）から複数のアドレス（デバイス）の少なくとも１つにメール又は電話（メッセージ）を「発信」（経路設定）するために、「利用頻度情報」（予測アベイラビリティ・モデル）を使用して、複数のアドレス（デバイス）を優先順位付けするものといえる。 よって、引用発明は、本願発明１の「送信側から前記複数のデバイスの少なくとも１つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、」との構成を備えている。 （カ）引用発明において、「相手先アドレスを、利用頻度値が高い順に複数個提示」して、「ユーザは、提示された複数個の相手先アドレスから、１つのアドレスを選択」できるようにすることは、通信相手がすぐにメッセージを受け取れる可能性の高いアドレス（デバイス）を選択できるようにすることに等しい。そうすると、引用発明は、利用頻度情報の利用頻度に基づいて、アドレス（デバイス）を順位付けし、優先順位の高い方から複数のアドレス（デバイス）を提示するものといえる。 また、引用発明において、利用頻度値が高い順に複数個のアドレスを提示する場合には、最も利用頻度値すなわち優先順位が高いアドレス（デバイス）を表示することを含む。また、この表示の場所が、送信側の携帯電話に表示画面、すなわち、送信側によって使用されるインターフェース上であることは自明である。 よって、前記（ア）を参酌すれば、引用発明は、本願発明１の「前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップ」との構成を備えている。 （キ）引用発明において、選択されたアドレスに対して発信を行うことと、本願発明１の「前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも１つのデバイスに、前記メッセージを経路設定するステップ」とは、「前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、ユーザにより選択されたデバイスを含む少なくとも１つのデバイスに、前記メッセージを経路指定するステップと」の部分において共通する。 イ　一致点・相違点 したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。 ［一致点］ 「　複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法であって、プロセッサが下記のステップを実行することを含み、前記方法が、 一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間を含む、前記収集するステップと、 収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間を使用して生成される、前記生成するステップと、 送信側から前記複数のデバイスの少なくとも１つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、 前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップと、 前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、ユーザにより選択されたデバイスを含む少なくとも１つのデバイスに、前記メッセージを経路設定するステップと、 を含む、前記方法。」 ［相違点］ ＜相違点１＞ 「以前のアベイラビリティ・データ」が、本願発明１においては、「アベイラビリティ時間又は期間」に加えて「信号強度」をも含み、「予測アベイラビリティ・データ」が、「アベイラビリティ時間又は期間」に加えて「信号強度」をも使用して生成されるのに対し、引用発明は、これら「信号強度」に関する構成を有さない点。 ＜相違点２＞ ユーザによるデバイスの選択が、本願発明１は、「プライバシ問題を考慮して」なされるものに限定されているのに対し、引用発明１は、そのような限定が付されていない点。 ＜相違点３＞ 本願発明１は、 「　受信者が応答するまで、優先順位付けアルゴリズムに基づいて、リアルタイムで、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定するステップと、」との構成を備えるのに対し、 引用発明は、当該構成を備えない点。 ウ　相違点についての判断 まず、上記相違点１について検討するに、相違点１に係る本願発明１の構成、すなわち、「以前のアベイラビリティ・データ」が「アベイラビリティ時間又は期間」に加えて「信号強度」をも含み、「予測アベイラビリティ・データ」が、「アベイラビリティ時間又は期間」に加えて「信号強度」をも使用して生成されることは、上記引用文献１ないし４には記載されておらず、かつ、本願優先日前において周知技術であったともいえない。 また、引用文献１の記載内容からすれば、引用発明において、「着信時の曜日と時間帯を表す値」を取得する携帯電話が、送信元のアドレス（デバイス）上でのユーザのアベイラビリティを決定するための「信号強度」（例えば、着信の送信元のデバイスが送信した信号の強度等）を取得して、利用頻度情報または利用頻度値（「予測アベイラビリティ・データ」）を更新（生成）するために使用することは、想定しておらず、また、携帯電話が、着信時にそのような「信号強度」を取得することが本願優先日前における技術常識であったともいえないから、引用発明において、着信時の「当日の曜日と現在の時間帯を示す値」を取得するにあたり、当該値に加えて、「信号強度」を取得するとともに、当該「信号強度」を使用して「利用頻度情報」又は「利用頻度値」（予測アベイラビリティ・モデル）を更新（生成）することが、当業者にとって設計的な事項であるともいえない。 したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用発明、引用文献２ないし４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 （２）本願発明２ないし１３について 本願発明２ないし１３も、相違点１に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明、引用文献２ないし４に記載された技術的事項に基づいて容易に発明できたものとはいえない。 ３　理由２（進歩性欠如）についてのまとめ 以上のとおり、当審拒絶理由の理由２（進歩性欠如）は解消した。 第７　原査定についての判断 本件補正により、補正後の請求項１ないし１３は、上記相違点１に係る本願発明１の構成を有するものとなった。当該構成は、原査定における引用文献Ａ及びＢ（当審拒絶理由における引用文献１及び４）には記載されておらず、本願優先日前における周知技術でもないので、本願発明１ないし１３は、当業者であっても、原査定における引用文献Ａ及びＢに基づいて容易に発明できたものではない。したがって、原査定を維持することはできない。 第８　むすび 以上のとおり、原査定の理由によって、本願を拒絶することはできない。 他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。