• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
管理番号 1366847
審判番号 不服2019-6859  
総通号数 251 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-11-27 
種別 拒絶査定不服の審決 
審判請求日 2019-05-27 
確定日 2020-10-27 
事件の表示 特願2016-533808「使用量データを収集して複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法、システム、およびコンピュータ・プログラム」拒絶査定不服審判事件〔平成27年 2月19日国際公開、WO2015/021935、平成28年 9月23日国内公表、特表2016-529622、請求項の数(13)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2014年(平成26年)8月14日(パリ条約による優先権主張 外国庁受理2013年8月16日、米国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
平成30年 4月 3日付け:拒絶理由通知書
平成30年 7月 2日 :意見書、手続補正書の提出
平成30年 9月19日付け:拒絶理由(最後の拒絶理由)通知書
平成30年11月19日 :意見書、手続補正書の提出
平成31年 3月14日付け:拒絶査定(原査定)
令和 元年 5月27日 :審判請求書、手続補正書の提出
令和 元年 8月 9日付け:前置報告書
令和 元年12月11日 :上申書の提出
令和 2年 6月 4日付け:拒絶理由(当審拒絶理由)通知書
令和 2年 9月 8日 :意見書、手続補正書の提出

第2 原査定の概要
原査定(平成31年3月14日付け拒絶査定)の概要は次のとおりである。

本願請求項1、2、5ないし10及び13ないし17に係る発明は、以下の引用文献Aに記載の発明に基づいて、また、本願請求項3、4、11及び12に係る発明は、以下の引用文献A及びBに記載の発明に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
A 特開2008-131418号公報
B 特開2003-134194号公報

第3 当審拒絶理由の概要
当審拒絶理由の概要は次のとおりである。

●理由1(明確性要件違反)
本願請求項1ないし15に係る発明は、明確でないから、特許法36条6項2号に規定する要件を満たしていない。
●理由2(進歩性欠如)
本願請求項1及び8に係る発明は、以下の引用文献1ないし3に記載された発明に基づいて、本願請求項2ないし7及び9ないし15に係る発明は、以下の引用文献1ないし4に記載された発明に基づいて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

[引用文献等一覧]
1 特開2008-131418号公報(拒絶査定時の引用文献A)
2 特開2005-216128号公報(当審において新たに引用した文献)
3 特開2004-343543号公報(当審において新たに引用した文献)
4 特開2003-134194号公報(拒絶査定時の引用文献B)

第4 本願発明
本願請求項1ないし13に係る発明(以下、それぞれ「本願発明1」ないし「本願発明13」という。)は、令和2年9月8日に提出された手続補正書により手続補正された特許請求の範囲の請求項1ないし13に記載された事項により特定される発明であり、本願発明1ないし13は以下のとおりの発明である。(なお、下線は、補正された箇所を示す。)

「 【請求項1】
複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法であって、
プロセッサが下記のステップを実行することを含み、前記方法が、
一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含む、前記収集するステップと、
収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間と、前記信号強度とを使用して生成される、前記生成するステップと、
送信側から前記複数のデバイスの少なくとも1つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、
前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップと、
前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも1つのデバイスに、前記メッセージを経路設定するステップと、
受信者が応答するまで、優先順位付けアルゴリズムに基づいて、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定するステップと、
を含む、前記方法。
【請求項2】
前記複数のデバイスが、ラップトップ、タブレット、携帯電話を含み、前記デバイスがそれぞれのメッセージング・システムと通信し、前記メッセージング・システムが、テキスト・インスタント・メッセージングまたはショート・メッセージング・サービス(SMS)を含む、請求項1に記載の方法。
【請求項3】
前記予測アベイラビリティ・モデルが、デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングをさらに使用して生成される、請求項1又は2に記載の方法。
【請求項4】
前記デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングが、最も頻繁に使用されるデバイス又はある場所で最も頻繁に使用されるデバイスの統計的結論を含むアベイラビリティ・レーティングである、請求項3に記載の方法。
【請求項5】
前記選択が、前記複数のデバイスの優先順位及び業務ポリシーを考慮して行われる、請求項1?4のいずれか一項に記載の方法。
【請求項6】
前記メッセージが個人的なメッセージである場合に、前記選択が、前記優先順位を考慮して前記複数のデバイスのうちの該ユーザの個人的なデバイスを選択することによって行われる、請求項1?5のいずれか一項に記載の方法。
【請求項7】
複数の通信デバイス上でのユーザのアベイラビリティを決定するためのシステムであって、
コンピュータのプロセッサによって実行可能なプログラムを使用して、以前に収集されたアベイラビリティ・データに基づいて、一人のユーザによって使用される複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成する第1のアルゴリズムであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含み、前記予測アベイラビリティ・モデルが、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを使用して生成される、前記第1のアルゴリズムと、
前記プログラムを使用して、送信側から前記複数のデバイスの少なくとも1つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けする第2のアルゴリズムと、
前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すように構成されたインターフェースと、
前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも1つのデバイスに、前記メッセージを経路設定するように構成された経路設定論理であって、受信者が応答するまで、前記第2のアルゴリズムに基づいて、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定する、前記経路設定論理と、
を備える、前記システム。
【請求項8】
前記複数のデバイスが、ラップトップ、タブレット、セル電話を含み、前記デバイスがそれぞれのメッセージング・システムと通信し、前記メッセージング・システムが、テキスト・インスタント・メッセージングまたはショート・メッセージング・サービス(SMS)を含む、請求項7に記載のシステム。
【請求項9】
前記予測アベイラビリティ・モデルが、デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングをさらに使用して生成される、請求項7又は8に記載のシステム。
【請求項10】
前記デバイスの使用頻度に関連付けられたアベイラビリティ・レーティングが、最も頻繁に使用されるデバイス又はある場所で最も頻繁に使用されるデバイスの統計的結論を含むアベイラビリティ・レーティングである、請求項9に記載のシステム。
【請求項11】
前記選択が、前記複数のデバイスの優先順位及び業務ポリシーを考慮して行われる、請求項7?10のいずれか一項に記載のシステム。
【請求項12】
前記メッセージが個人的なメッセージである場合に、前記選択が、前記優先順位を考慮して前記複数のデバイスのうちの該ユーザの個人的なデバイスを選択することによって行われる、請求項7?11のいずれか一項に記載のシステム。
【請求項13】
複数の通信デバイス上でのユーザのアベイラビリティを決定するためのコンピュータ・プログラムであって、プロセッサに請求項1?6のいずれか一項に記載の方法を実行させる、前記コンピュータ・プログラム。」

第5 当審拒絶理由の理由1(明確性要件違反)について
1 請求項1及び15に記載の「使用量データ」がいかなる量のデータであるのか明確でないとの指摘に対し、令和2年9月8日に提出された手続補正書による手続補正(以下、単に「本件補正」という。)により、「使用量データ」に関する事項は削除された。
2 請求項1及び8に記載の「アベイラビリティ時間」の意味が明確でないとの指摘に対し、本件補正により、「アベイラビリティ時間又は期間」と補正され、「期間」の概念である場合を含むことが明らかとされた。
3 請求項1及び8に記載の「リアルタイムで」の意味が明確でないとの指摘に対し、本件補正により、「リアルタイムで」との記載は削除された。
4 請求項1の「経路設定」と「経路指定」との関係が明確でないとの指摘に対し、本件補正により、「経路指定」が「経路設定」に補正され、用語が統一された。
5 請求項2記載の「アベイラビリティを含む」における「アベイラビリティ」と、請求項2が引用する請求項1に記載の「アベイラビリティを決定する」における「アベイラビリティ」との関係が明確でないとの指摘に対し、本件補正により、請求項2は削除された。
6 請求項9に記載の「ユーザ応答回数/アベイラビリティ」の意味が明確でないとの指摘に対し、本件補正により、請求項9は削除された。

以上の1ないし6より、当審拒絶理由の理由1(明確性要件違反)は解消した。

第6 当審拒絶理由の理由2(進歩性欠如)について
1 引用文献、引用発明等
(1)引用文献1について
ア 引用文献1記載事項
当審拒絶理由に引用された引用文献1には、図面とともに次の事項が記載されている。(下線は、強調のため当審が付与した。以降の記載においても同様。)

「【特許請求の範囲】
【請求項1】
…(中略)…
とを備えた通信端末。
…(中略)…
【請求項8】
…(中略)…
ことを特徴とする相手先アドレス提示方法。
…(中略)…
【請求項15】
1人の通信相手に対して複数個の相手先アドレスが登録可能な相手先アドレス格納部を備えた通信端末で使用される相手先アドレス提示方法をコンピュータで実行可能なプログラムであり、このプログラムは下記(a)-(c)のステップを備える。
…(後略)」

「【背景技術】
【0002】
近年、携帯電話の保有率が増加し、携帯電話を複数個保有しているユーザの数も増加している。この理由の1つとしては、私用・社用で電話番号やメールアドレスを使い分けするユーザが増加していることが挙げられる。自宅の電話や勤務先の電話なども含めると、通信相手に対する接続先は、今後も増加すると予想される。」

「【0018】
したがって、ユーザは、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できる。
【発明を実施するための最良の形態】
【0019】
次に、本発明の実施例について図面を参照しながら説明する。なお、以下では、携帯電話を例として、本発明の実施例を説明するが、本発明は、通信機能を有する通信端末全般、例えば、固定電話機にも適用できることは、以下の説明から、当業者には明らかであろう。
【0020】
[実施例1]
図1は、本発明に係る携帯電話の構成例を示すブロック図である。
【0021】
この携帯電話は、キー入力部10と、表示部20と、無線通信部30と、制御部40と、メーラ50と、電話帳60とを含む。
【0022】
ユーザは、表示部20の表示を見ながら、キー入力部10を操作することにより、無線通信部30、制御部40、メーラ50を使用する。
【0023】
電話帳60は、後述されるように、通信相手毎に複数個の送信先アドレス(電話番号、メールアドレス等)を登録している。また、電話帳60は、相手先アドレス毎に、過去にこの相手先アドレスからの着信回数を、曜日及び時間帯毎にカウントした値を、利用頻度情報として、利用頻度情報部に格納している。なお、この電話帳は、通常の電話帳と同様に、通信相手の自宅住所や勤務先住所等を合わせて記録していてもよい。また、この電話帳は、携帯電話内部に設けられていてもよいし、SIMカード内に設けされていてもよい。」

「【0026】
携帯電話に着信があると、着信制御部42は、図2のステップS111において、送信元。即ち、送信元電話番号を確認する。次に、着信制御部42は、ステップS112において、送信元電話番号が、電話帳(ｐhｏne bｏｏk;PB)に登録されているか否かを判定する。この判定結果が”Nｏ”の場合は、着信制御部42は、ステップS120で、通常の着信処理を行う。なお、この通常の着信処理は、当業者にはよく知られているので、詳細な説明は、省略される。
【0027】
ステップS112での判定結果が”Yeｓ”の場合、携帯電話はステップS113で、電話帳60内でのデータ保存場所を確認を確認する。即ち、送信元の電話帳データの格納場所が携帯電話内部か、SIMカード内かを確認する。
【0028】
次に、携帯電話は、ステップS114で、送信元電話番号が保存されたロケーションの番号、即ちロケーション番号を確認する。そして、携帯電話は、ステップS115で、送信元のロケーション番号に登録された電話番号から登録している電話帳の項目番号.を確認する。
【0029】
後述されるとおり、本実施例では、電話帳60は、項目番号毎に、着信した曜日をカウントする着信曜日カウンタと、着信した時間をカウントする着信時間カウンタとを有する。
【0030】
ステップS116では、携帯電話のカウンタ制御部44は、受信時の曜日を取得する。この曜日は、携帯電話内に設けられたタイマから得られる。ステップS117では、カウンタ制御部44は、該当する項目番号の該当曜日の曜日カウンタ欄に、値”1”を積算する。
【0031】
ステップS118では、カウンタ制御部44は、受信した時間帯を示す値を取得する。この値も、タイマから得られる。ステップS119では、カウンタ制御部44は、該当する項目番号、該当時間帯の時間カウンタ欄に、値”1”を積算する。このようにして、カウンタ制御部44は、電話帳の利用頻度情報を、着信毎に、更新する。
【0032】
ステップS119が終了すると、着信制御部42は、通常の着信処理を行う。
【0033】
次に、図3を参照して、図1の携帯電話の発信時の動作、特に、利用頻度制御部45の動作につき説明される。 図3は、図1の携帯電話の発信時の動作を説明するためのフローチャートである。
【0034】
携帯電話ユーザが、電話帳に登録している相手と通話する場合、送信先を選択する。この選択は、電話帳からの選択、リダイアルでの名前検索により行われてもよい。
【0035】
ステップS311では、利用頻度制御部45は、は、送信相手を示す情報を取得する。ステップS312では、利用頻度制御部45は、携帯電話内の時計情報から、当日の曜日を取得する。また、利用頻度制御部45は、ステップS313で、現在の時間帯を示す値を取得する。なお、この値の例は、図5に示されている。
【0036】
後述されるように、本実施例では、電話帳60内で、電話番号を登録している項目は、項目番号3から8である。したがって、本実施例では、1通信相手につき、最大6個までの電話番号が登録可能である。このため、ステップS314では、ループパラメータ(N)の初期値は、”3”にセットされる。
【0037】
これら最大6候補からの選択は、6候補につき登録された利用頻度情報に基づいて、次のように行われる。
【0038】
ステップS315では、利用頻度制御部45は、ステップS312で取得された曜日に対応する、項目番号Nの着信曜日カウンタの値をレジスタAに読み込む。次に、ステップS316では、利用頻度制御部45は、ステップS312で取得された時間帯情報に対応する、項目番号Nの着信時間カウンタの値を、レジスタBに読み込む。
【0039】
ステップS317では、利用頻度制御部45は、レジスタAとレジスタBの値を加算し、項目番号Nの利用頻度情報値を求め、加算結果をレジスタN_Cに保存する。なお、レジスタA,BおよびレジスタN_C(N=3、4、・・・、8)は、利用頻度制御部45に内蔵されたレジスタである。
【0040】
ステップS318では、利用頻度制御部45は、ループパラメータNの値が8か否かを判定する、この判定結果が”Nｏ”の場合、利用頻度制御部45は、ステップS319で、ループパラメータNの値を、1だけ増加させる。この後、利用頻度制御部45の処理は、ステップS315に戻る。
【0041】
これらステップS315からS319までの処理により、項目番号3から8に対する利用頻度情報値N_C(N=3、4、・・・、8)が求められる。
【0042】
ステップS318の判定結果が”Yeｓ”の場合、利用頻度制御部45は、ステップS320で、利用頻度情報値N_C(N=3、4、・・・、8)を比較し、最大値を検出する。
【0043】
ステップS321では、利用頻度制御部45は、この最大値に対応する項目番号の電話番号を、表示部に表示する。
【0044】
携帯電話ユーザは、Sendキーを押すことで表示された電話番号に対して発信する(ステップS322)。」

「【0057】
前述した実施例1は、携帯電話の電話機能に限って本発明を説明したが、この実施例2は、携帯電話の電子メール機能に限って、本発明を説明する。
【0058】
なお、この実施例2の装置構成は、図1と同様である。
【0059】
この実施例2の動作は、図6と図7とを参照して、説明される。図6は、実施例2の説明に使用される電話帳の例を示す。図7は、実施例2の発信時の動作を説明するためのフローチャートである。なお、図7のフローチャートにおいて、図3のフローチャートの参照符号と同一の符号を付したステップは、図3で説明したステップと同一内容である。なお、実施例2の着信時の動作は、、実施例1と同様であるので、この動作についての説明は、省略される。
【0060】
図6は、電話帳のZZZさんに関わる部分を示している。このZZZさんの個人情報として、電話帳は、項目番号9と10に、メールアドレスを2つ登録している。
【0061】
ユーザは、ZZZさんにメールを送る時には、図1のメーラ50を立ち上げる。ユーザは、キー入力部10を操作して、件名とメール本文を作成するそして、このメールのあて先にはZZZさんを指定する(ステップS711)。
【0062】
この指定に応答して、利用頻度制御部45は、ステップS312、S313で、現時間の曜日情報と時間情報(詳しくは、時間帯情報)を取得する。ここでは、現時刻は、火曜の20時(即ち、時間帯5)とする。
【0063】
図6に示されたとおり、ZZZさんの電話帳情報は、電話帳のPhｏneロケーション番号2に登録されている。電話帳では。メールアドレスは、項目番号9と10に登録されている。このため、ステップS714では、ループパラメータNの初期値は、値”9”にセットされる。
【0064】
ステップS315では、利用頻度制御部45は、項目番号Nの利用頻度情報から、火曜日の欄の値を読み込む。また、ステップS316では、時間帯5の欄の値を読み取る。ステップS317では、両者の値を合計し、項目番号Nの利用頻度値N_C(N=9,10)を得る。ステップS714、S314、S315、S316、S317、」S718、S719の処理により、ZZZさんの2つのメールアドレスにつき、次の2つの利用頻度値が得られる。
9_C=30、 10_C=0
ステップS320では、利用頻度制御部45は、これらの数値の最大値を検出する。そして、ステップS321では、利用頻度制御部45は、最大値に対応するメールアドレス「zzz1@xxx.xxx」を表示部に表示すると共に、このメールアドレスをメーラに伝える。メーラは、このメールアドレスを送信先アドレス欄にセットする。
【0065】
ユーザが、Sendキーを押し下げすると、メーラは、このメールを送信する(ステップS722)。
【0066】
このように実施例2は、相手がすぐに受けとる確率が高いメールアドレスを選択することができる。よって、ユーザは、簡単な操作で、相手が直ちに受け取る可能性が高いアドレスへメールを送信できる。」

「【0067】
図8は、第3の実施例で使用される電話帳内の1個の電話番号の利用頻度情報部の内容の一例を示す図である。図9は、第3の実施例の受信時の動作を説明するためのフローチャートである。図10は、第3の実施例の発信時の動作を説明するためのフローチャートである。
【0068】
図8は、特定の着信相手の電話番号からの利用頻度情報を示している。即ち、第2の実施例(当審注:「第3の実施例」の誤記と認める。)の電話帳は、特定着信相手からの利用頻度情報を、電話番号毎に持つ。図8に示されたとおり、第2の実施例(当審注:「第3の実施例」の誤記と認める。)における電話帳の利用頻度情報部は、時間帯と曜日に関する2次元カウンタ構成である。この利用頻度情報部は、着信してからの過去の着信回数を、着信曜日と着信時間帯の2次元情報として蓄積する。この第3の実施例では、図8は、図4の項目番号4の電話番号の利用頻度情報に対応する。
【0069】
次に、図9を参照して、第3の実施例の受信時の動作が説明される。なお、図9の各ステップにおいて、図2と同一のステップ番号を付されたステップは、図2で説明されたステップと同一の動作を行うので、図2と同一動作を行うステップについての説明は、省略される。図9では、図2の破線部Aが、破線部A’に置き換えられている。
【0070】
図9では、カウンタ制御部44は、ステップS901で、携帯電話に内蔵されたタイマから着信時の曜日情報を取得する。また、カウンタ制御部44は、ステップS902で、タイマから着信時の時間帯情報を取得する。そして、カウンタ制御部44は、ステップS903で、ステップS116で確認された項目番号の利用頻度情報を格納する2次元カウンタに、1を加算する。即ち、この利用頻度情報の、ステップS901で取得された曜日情報とステップS902で取得された時間帯情報に相当する欄に、値”1”を加算する。
【0071】
例えば、相手先の発信電話番号に相当する利用頻度情報が図8に示されたものであり、また、着信曜日が土曜日、着信時間帯が時間帯6であった場合を考えてみる。この場合には、図8の土曜日ん時間帯6の欄の値は、”8”であるので、カウンタ制御部44は、この欄の値を、”9”に変更する。
【0072】
このようにして、実施例3の利用頻度情報が」生成される。この実施例1,2では、利用頻度情報は、着信曜日と着信時間帯とを個別にカウントしていた。この実施例1、2は、実施例3に対して、利用頻度情報を蓄積するためのメモリが小容量でよいという利点を有する。
【0073】
次に、図10を参照して、第3の実施例の発信時の動作が説明される。なお、図10の各ステップにおいて、図3と同一のステップ番号を付されたステップは、図3で説明されたステップと同一の動作を行うので、図3と同一動作を行うステップについての説明は、省略される。図10では、図3の破線部Bが、破線部B’に置き換えられている。
【0074】
図10において、利用頻度制御部45は、ステップS1101において、ステップS311で取得された現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータNに対応する利用頻度値を読み出す。即ち、このループパラメータの値に相当する電話番号の利用頻度情報が図8であり、現時点の曜日が日曜日であり、現時間帯が時間帯4である場合を考えてみる。この場合には、利用頻度制御部45は、日曜日の時間帯4の値”5”を、読み出す。他のループパラメータに対応する電話番号についても同様である。
【0075】
実施例1、2は、発信の際に、曜日カウンタの値と時間帯カウンタの値を加算することにより、発信曜日、発信時間帯の利用頻度値を、相手先電話番号毎に得ている。このため、通信相手先が、特定の曜日にのみ、大部分の発信を行う癖を持つ場合には、この利用頻度値は、この特定の曜日に時間帯情報により、事実上決定されてしまうこのが起こりうる。また、通信相手先が、特定の時間帯にのみ、大部分の発信を行う癖を持つ場合には、この利用頻度値は、この特定時間帯の時間帯情報により、事実上決定されてしまうこのが起こりうる。したがって、第3の実施例は、第1、第2の実施例と比較すれば、利用頻度情報を蓄積するためのメモリの容量が大きくなるが、第1、第2の実施例よりも、発信時に、適時かつ適切な相手先アドレスを、ユーザに提供する。」

「【0076】
なお、以上で説明した実施例1から3では、利用頻度値が最大となる相手先アドレスを1個のみ提示する例について説明した。本発明は、この利用頻度値が高い順に複数個提示するように修正されてもよい。この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、1つのアドレスを選択して発信することが出きる。また、この提示の際に、利用頻度値を電話番号とともに表示すれば、ユーザは、相手先アドレスの選択が容易となる。」

「【図8】

」

イ 引用発明
したがって、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「 一人のユーザが携帯電話を複数個所有し、私用・社用でアドレスを使い分けるユーザが増加していることを背景として、ユーザが、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できるようにするための方法、携帯電話又はコンピュータで実行可能なプログラムであって、
携帯電話の電話帳は、通信相手毎に複数個の送信先アドレス(電話番号、メールアドレス等)を登録しており、相手先アドレス毎に、過去にこの相手アドレスからの着信回数を、曜日及び時間帯毎にカウントした値を、利用頻度情報として、利用頻度情報部に格納したものであり、
携帯電話に着信があると、着信制御部は、送信元電話番号が電話帳に登録されているか否かを判定し、判定結果が”Yeｓ”の場合、カウンタ制御部は、受信時の曜日と受信した時間帯を表す値を取得して、該当する項目番号の該当曜日の曜日カウンタ欄と該当する項目番号の該当時間帯の時間カウンタ欄に値”1”を積算することにより、電話帳の利用頻度情報を更新し、
ユーザが電話帳に登録している相手と通話する場合、送信先を選択すると、利用頻度制御部は、送信相手を示す情報と当日の曜日と現在の時間帯を示す値とを取得し、
電話帳内で、電話番号を登録している項目が、項目番号3から8までの最大6個までの電話番号が登録可能な場合、利用頻度制御部は、取得された曜日に対応する、項目番号Nの着信曜日カウンタの値をレジスタAに読み込み、取得された時間帯情報に対応する、項目番号Nの着信時間カウンタの値を、レジスタBに読み込み、レジスタAとレジスタBの値を加算し、項目番号Nの利用頻度情報値を求め、加算結果をレジスタN_Cに保存する処理により、項目番号3?8に対する利用頻度情報値N_C(N=3、4、…8)を求め、
利用頻度制御部は、利用頻度情報値N_C(N=3、4、…8)を比較し、最大値を検出し、この最大値に対応する項目番号の電話番号を表示部に表示し、
前述した実施例1では携帯電話の電話機能に限って説明したが、実施例2では、携帯電話の電子メール機能に限って説明し、ユーザが、メールを送る時に、このメールのあて先にZZZさん(電話帳には、ZZZさんの個人情報として、メールアドレスを2つ登録している。)を指定すると、利用頻度制御部は、ZZZさんの2つのメールアドレスにつき、2つの利用頻度値を得て、これらの数値の最大値を検出し、最大値に対応するメールアドレスを表示部に表示し、
第3の実施例では、電話帳の利用頻度情報部は、時間帯と曜日に関する2次元カウンタ構成であり、
受信時に、カウンタ制御部は、着信時の曜日情報と時間帯情報とを取得し、確認された項目番号の利用頻度情報を格納する2次元カウンタの、取得された曜日情報と時間帯情報に相当する欄に1を加算し、
発信時に、利用頻度制御部は、現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータNに対応する利用頻度値を読み出し、他のループパラメータについても同様であり、
相手先アドレスを、利用頻度値が高い順に複数個提示するように修正してもよく、この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、1つのアドレスを選択して発信することが出きる、
方法、携帯電話又はコンピュータ・プログラム。」

(2)引用文献2?4について
ア 引用文献2について
当審拒絶理由に引用された引用文献2には、図面とともに、次の事項が記載されている。

「【0006】 本発明は、上記した点に鑑みてなされたものであり、より簡易な構成でかつ低コストで携帯情報端末装置を使った緊急事態通知のサービスを実現できる緊急通知を提供することを目的とする。」

「【0044】 図3は、特定情報記憶メモリ14aに記憶される特定情報の例を示す図である。図示した例では、特定情報である電話番号を、発呼の優先順位及び電話番号に関する情報(名前、電話番号が勤務先である等)と共に記憶している。実施形態1の緊急通知装置は、緊急事態の発生を検出すると、優先順位の高いものから順に電話番号を発呼する。したがって、図3の例では、緊急事態発生検出により先ず「山田太郎」の電話が発呼される。この際、「山田太郎」の電話への発呼に対する応答がなかった場合、次に優先順位が高い「勤務先」の電話に対して発呼する。さらに、実施形態1の緊急通知装置は、この発呼にも応答がなかった場合には次に優先順位が高い電話に対して発呼する、というように通信が成立するまで順次優先順位に従って電話を発呼する。」

上記記載からみて、当該引用文献2には、「携帯情報端末装置を使った緊急事態通知のサービスにおいて、緊急事態の発生を検出すると、通信が成立するまで、優先順位の高いものから順に電話番号を発呼すること」という技術的事項が記載されていると認められる。

イ 引用文献3について
当審拒絶理由に引用された引用文献3には、図面とともに、次の事項が記載されている。

「【0005】このようなシステムであれば、汎用のコードレス無線電話システムを利用することで、新たにシステムを構築する場合にシステムを安価に提供できる利点がある。また、既設のナースコールシステムにコードレス無線電話システムを増設する場合にも、変換装置を追加するだけで容易に接続することができる。」

「【0054】図6は、この発明の第2の実施形態に係わるアダプタ装置の発呼制御処理手順とその内容を示すフローチャートである。なお、ナースコールシステム及びアダプタ装置のハードウエア構成については、前記第1の実施形態と同一なので前記図1及び図2を引用して説明を行う。」

「【0057】一方、発呼モードとして順次呼出モードが設定されていたとする。この場合アダプタ装置8は、ステップ6eに移行して記憶部83から緊急呼出先として予め記憶されている複数の携帯端末の電話番号のうちの1つを読み出す。読み出し順序は予め設定した優先順位に従う。続いてアダプタ装置8は、ステップ6fにより、上記読み出された携帯端末に対し発呼するための構内PHS対応の呼設定メッセージを作成する。このとき、呼設定メッセージの発番号を表す情報要素エリアには、上記一斉呼出モードの場合と同様に、「緊急呼出」であることを示す“001”と、呼出元の患者の識別番号「0123」とが挿入される。そして、ステップ6gにより、上記作成された呼設定メッセージを通信インタフェース85からPBX4へ向け送信する。
【0058】次にアダプタ装置8は、ステップ6iにより一定時間の経過を監視しながら、ステップ6hにより上記呼設定メッセージの着信先となる携帯端末からの着呼応答を監視する。そして、上記一定時間内に着呼応答が検出されると、緊急呼出処理を終了する。
【0059】これに対し、上記一定時間内に着呼応答が検出されない場合には、アダプタ装置8はステップ6jに移行して未選択の緊急呼出先がまだ残っているか否かを判定する。この判定の結果、未選択の緊急呼出先がまだ残っている場合にはステップ6eに戻り、記憶部83から優先順位が次の携帯端末の電話番号を読み出す。そして、この読み出された携帯端末の電話番号に従いステップ6fにより呼設定メッセージを作成し、この作成された呼設定メッセージをステップ6gによりPBX4に向け送信する。以後、携帯端末からの着信応答が検出されるまで、上記ステップ6e?ステップ6jによる順次発呼制御を繰り返す。」

上記記載からみて、当該引用文献3には、「汎用の携帯端末を利用した自動ナースコールシステムにおいて、複数の携帯端末の電話番号を緊急呼出先とあらかじめ記憶しておき、順次呼出しモードが設定されている場合、前記電話番号を優先順位に従って読み出し、着呼応答が検出されるまで、順次発呼制御を繰り返すこと。」という技術的事項が記載されていると認められる。

ウ 引用文献4について
当審拒絶理由に引用された引用文献4には、図面とともに次の事項が記載されている。

「【請求項1】 通信時刻情報と通信種別と通信が成立したか否かを示す正否情報とを通信先に対応させた通信履歴情報を記憶する通信履歴部と、前記通信履歴部からの前記通信履歴情報に基づいて、予め定めた時間間隔の時間帯毎の各々の通信種別毎に接続成立回数と発呼回数との比に対応する通信応答率を解析し、現時刻に対応した時間帯における所定の通信種別の前記通信応答率、または現時刻に対応した時間帯における前記通信応答率の順位に応じて選択された通信の種別、または前記通信応答率の順位に応じて選択された時間帯と対応する通信種別の少なくとも1つを推薦通信情報として出力する解析部とを備えたことを特徴とする通信端末装置。」

「【請求項5】 通信先に対応した通信履歴情報を取得するステップと、前記通信履歴に基づいて、通信先へ通信すべき時間帯及び/または通信種別及び/または通信先が現時刻に受信する期待値を解析するステップと、前記解析された前記時間帯及び/または前記通信種別及び/または前記期待値を表示するために出力するステップと、を備えたことを特徴とする通信情報提示方法。」

「【0027】本実施例の携帯電話では、通信種別として電話、チャット、インスタント・メッセージの3種類の通信を行なう場合を例とし、各々、電話機能部52、チャット機能部53、及びインスタント・メッセージ機能部54とによって通信可能に構成されている。電話機能部52の主要機能部は、電話での通信を行なうための通信部52-1、電話での通信履歴を記憶する通信履歴記憶部52-2、この通信履歴を後述する通信履歴処理部55に通知する通信履歴通知部52-3である。同様に、チャット機能部53およびインスタント・メッセージ機能部54の主要機能部も、チャット、インスタント・メッセージ通信を行なう通信部53-1、54-1、通信履歴を記憶する通信履歴記憶部53-2、54-2、この通信履歴を通信履歴処理部55に通知する通信履歴通知部53-3、54-3である。」

上記記載からみて、当該引用文献4には、「通信時刻情報と通信種別(電話、チャット、インスタント・メッセージ)と通信が成立したか否かを示す正否情報とを通信先に対応させた通信履歴情報を記憶しておき、この通信履歴情報に基づいて、予め定めた時間間隔の時間帯毎の各々の通信種別毎に接続成立回数と発呼回数との比に対応する通信応答率を解析し、現時刻に対応した時間帯における所定の通信種別の通信応答率、または現時刻に対応した時間帯における通信応答率の順位に応じて選択された通信の種別、または通信応答率の順位に応じて選択された時間帯と対応する通信種別の少なくとも1つを推薦通信情報として出力するようにした通信端末装置又はその方法。」という技術的事項が記載されている。

2 対比・判断
(1)本願発明1について
ア 対比
以下、本願発明1と引用発明とを対比する。

(ア)引用発明は、「利用頻度情報」に基づいて、「ユーザ」が「通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレス」を選択できるようにするためのものであることから、送信先である通信相手、すなわち、送信先であるユーザがメッセージを受け取れる可能性すなわち「アベイラビリティ」を「決定」するためのものであるといえる。
また、引用発明では、一人のユーザが携帯電話を複数個所有し、私用・社用でアドレスを使い分けるユーザが増加していることを背景として、一つの送信先(ユーザ)ごとに複数のアドレスが存在することを前提とするものであるから、引用発明においては、「アドレス」と「携帯電話」である「デバイス」とは同一視することができる。
そうすると、引用発明は、本願発明1の「複数の通信デバイス上でのユーザのアベイラビリティ」を決定するものといい得る。
よって、引用発明に係る方法は、本願発明1の「複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法。」に相当する。

(イ)コンピュータで実行可能なプログラムは、一般的に、コンピュータに搭載された「プロセッサ」によって実行されることが技術常識であることから、引用発明に係る方法は、「プロセッサ」が「プログラム」を実行することにより、「着信制御部」、「カウンタ制御部」、「利用頻度制御部」による各処理を実行する態様を含んでいる。また、各処理を「ステップ」と称することは任意である。
そうすると、引用発明は、以下の相違点を除いて、本願発明1の「プロセッサが下記のステップを実行することを含む」との構成を備える点において共通する。

(ウ)引用発明は、「携帯電話の電話帳は、通信相手毎に複数個の送信先アドレス(電話番号、メールアドレス等)を登録」するものであり、また、「電話帳内で、項目番号3から8までの最大6個までの電話番号が登録可能な場合」があるから、「項目」は、通信相手の個々の「アドレス」(電話番号、メールアドレス等)に対応しているといえる。
引用発明は、着信があると(すなわち着信時に)、当日の曜日と現在の時間帯を示す値を取得し、送信元電話番号に該当する項目番号の該当曜日(すなわち、着信時の曜日に対応する)曜日カウンタ欄と該当時間帯(すなわち、着信時の時間帯に対応する)時間カウンタ欄に1を加算するものであり、また、相手先アドレス毎に、過去にこの相手アドレスからの着信回数を、曜日及び時間毎にカウントした値を、利用頻度情報(利用頻度値)として、利用頻度情報部に格納するものであり、また、通話またはメールを送るとき(発信時)に、利用頻度値が最も高い相手先アドレス、または、利用頻度値が高い順に複数の相手先アドレスを提示(表示)することにより、「ユーザが、通信相手がすぐにメッセージを受け取れる可能性の高い送信先アドレスを、特別な事前設定や操作を行うことなく、選択できるようにする」ものといえる。
ここで、引用発明において、「通信相手がすぐにメッセージを受け取れる可能性」は、本願発明1の「アベイラビリティ」に相当し、着信時に取得する「当日の曜日と現在の時間帯を示す値」は、当該「着信」の送信元となるユーザにとって「アベイラビリティ」がある「時間」又は「期間」を意味する。
よって、引用発明において、着信時に取得される「当日の曜日と現在の時間帯を示す値」は、本願発明1の「アベイラビリティ時間又は期間」に相当し、引用発明において、着信時に「当日の曜日と現在の時間帯を示す値」を取得することは、本願発明1において、「アベイラビリティ時間又は期間」を「収集」することに相当し、これら「収集」された「曜日と時間帯を表す値」を総称して「以前のアベイラビリティ・データ」と称することは任意である。
また、引用発明は、着信時に「曜日と時間帯を表す値」を取得すると、該当する項目番号、すなわち、送信元アドレスの該当曜日の曜日カウンタ欄と該当時間帯の時間カウンタ欄に1を積算することにより、あるいは、利用頻度情報部が2次元カウンタ構成である場合は、該当曜日と該当時間帯に相当する欄に1を加算することにより、「利用頻度情報」を更新するものであるから、前記(ア)を参酌すれば、「当日の曜日と現在の時間帯を示す値」は、「一人のユーザによって使用される複数のデバイスのそれぞれについての」ものである。
そうすると、本願発明1の「一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間と、信号強度とを含む、前記収集するステップ」と引用発明とは、「一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間を含む、前記収集するステップ」に相当する構成を備える点において共通する。

(エ)本願発明1における「予測アベイラビリティ・モデル」は、「収集された前記以前のアベイラビリティ・データ」を使用して生成され、かつ、複数のデバイスを優先順位付けするために使用されるものであれば足りる。
一方、引用発明は、収集された、送信元のアドレスについての着信時の「当日の曜日と現在の時間帯を表す値」に基づいて、送信元のアドレスに対応する利用頻度値を1積算ないし加算することにより、利用頻度情報を更新(生成)し、また、当該利用頻度情報は、ユーザがアドレス(デバイス)を選択できるように利用頻度値が高い順に複数個のアドレスを提示するために使用することも可能とされている。
以上からすれば、引用発明の「利用頻度情報」又は「利用頻度(情報)値」は、「収集された前記以前のアベイラビリティ・データ」を使用して生成され、かつ、複数のデバイスを優先順位付けするために使用するものである点において、本願発明1の「予測アベイラビリティ・モデル」と共通する。
そうすると、前記(ウ)を参酌すれば、本願発明1の「収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間と、前記信号強度とを使用して生成される、前記生成するステップ」と引用発明とは、「収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間を使用して生成される、前記生成するステップ」を備える点において共通する。

(オ)所定のアドレス(電話番号又はメールアドレス)に対して発信をすると、当該アドレスに基づいて、発信の内容であるメッセージが送信先のデバイスに到達するようにネットワーク上で経路設定がなされることは自明なことであるから、前記発信は、経路設定と同一視できる処理といえる。
引用発明は、「発信時に、利用頻度制御部は、現時点の曜日情報と現時点の時間帯情報に基づいて、ループパラメータNに対応する利用頻度値を読み出し、他のループパラメータについても同様であり、相手先アドレスを、利用頻度値が高い順に複数個提示するように修正してもよく、この修正された実施例では、ユーザは、提示された複数個の相手先アドレスから、1つのアドレスを選択して発信することが出きる」との構成を備えるものであるから、引用発明は、ユーザの携帯電話(送信側)から複数のアドレス(デバイス)の少なくとも1つにメール又は電話(メッセージ)を「発信」(経路設定)するために、「利用頻度情報」(予測アベイラビリティ・モデル)を使用して、複数のアドレス(デバイス)を優先順位付けするものといえる。
よって、引用発明は、本願発明1の「送信側から前記複数のデバイスの少なくとも1つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、」との構成を備えている。

(カ)引用発明において、「相手先アドレスを、利用頻度値が高い順に複数個提示」して、「ユーザは、提示された複数個の相手先アドレスから、1つのアドレスを選択」できるようにすることは、通信相手がすぐにメッセージを受け取れる可能性の高いアドレス(デバイス)を選択できるようにすることに等しい。そうすると、引用発明は、利用頻度情報の利用頻度に基づいて、アドレス(デバイス)を順位付けし、優先順位の高い方から複数のアドレス(デバイス)を提示するものといえる。
また、引用発明において、利用頻度値が高い順に複数個のアドレスを提示する場合には、最も利用頻度値すなわち優先順位が高いアドレス(デバイス)を表示することを含む。また、この表示の場所が、送信側の携帯電話に表示画面、すなわち、送信側によって使用されるインターフェース上であることは自明である。
よって、前記(ア)を参酌すれば、引用発明は、本願発明1の「前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップ」との構成を備えている。

(キ)引用発明において、選択されたアドレスに対して発信を行うことと、本願発明1の「前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、プライバシ問題を考慮してユーザにより選択されたデバイスを含む少なくとも1つのデバイスに、前記メッセージを経路設定するステップ」とは、「前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、ユーザにより選択されたデバイスを含む少なくとも1つのデバイスに、前記メッセージを経路指定するステップと」の部分において共通する。

イ 一致点・相違点
したがって、本願発明1と引用発明との間には、次の一致点、相違点があるといえる。
[一致点]
「 複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法であって、プロセッサが下記のステップを実行することを含み、前記方法が、
一人のユーザによって使用される複数のデバイスについての以前のアベイラビリティ・データを収集するステップであって、収集された前記以前のアベイラビリティ・データは、前記複数のデバイスのそれぞれについての、アベイラビリティ時間又は期間を含む、前記収集するステップと、
収集された前記以前のアベイラビリティ・データに基づいて前記複数のデバイスのそれぞれに関して、前記ユーザのアベイラビリティの予測アベイラビリティ・モデルを生成するステップであって、前記予測アベイラビリティ・モデルが、前記アベイラビリティ時間又は期間を使用して生成される、前記生成するステップと、
送信側から前記複数のデバイスの少なくとも1つにメッセージを経路設定するために、前記予測アベイラビリティ・モデルを使用して前記複数のデバイスを優先順位付けするステップと、
前記複数のデバイスのうち、前記ユーザの最もアベイラビリティが高いデバイスを前記送信側によって使用されるインターフェース上で示すステップと、
前記優先順位付けするステップで決定された前記複数のデバイスの優先順位に基づいて、ユーザにより選択されたデバイスを含む少なくとも1つのデバイスに、前記メッセージを経路設定するステップと、
を含む、前記方法。」

[相違点]
＜相違点1＞
「以前のアベイラビリティ・データ」が、本願発明1においては、「アベイラビリティ時間又は期間」に加えて「信号強度」をも含み、「予測アベイラビリティ・データ」が、「アベイラビリティ時間又は期間」に加えて「信号強度」をも使用して生成されるのに対し、引用発明は、これら「信号強度」に関する構成を有さない点。

＜相違点2＞
ユーザによるデバイスの選択が、本願発明1は、「プライバシ問題を考慮して」なされるものに限定されているのに対し、引用発明1は、そのような限定が付されていない点。

＜相違点3＞
本願発明1は、
「 受信者が応答するまで、優先順位付けアルゴリズムに基づいて、リアルタイムで、前記送信側から前記複数のデバイスのうちのより優先順位の高いデバイスからより優先順位の低いデバイスに前記メッセージを順次、経路設定するステップと、」との構成を備えるのに対し、
引用発明は、当該構成を備えない点。

ウ 相違点についての判断
まず、上記相違点1について検討するに、相違点1に係る本願発明1の構成、すなわち、「以前のアベイラビリティ・データ」が「アベイラビリティ時間又は期間」に加えて「信号強度」をも含み、「予測アベイラビリティ・データ」が、「アベイラビリティ時間又は期間」に加えて「信号強度」をも使用して生成されることは、上記引用文献1ないし4には記載されておらず、かつ、本願優先日前において周知技術であったともいえない。
また、引用文献1の記載内容からすれば、引用発明において、「着信時の曜日と時間帯を表す値」を取得する携帯電話が、送信元のアドレス(デバイス)上でのユーザのアベイラビリティを決定するための「信号強度」(例えば、着信の送信元のデバイスが送信した信号の強度等)を取得して、利用頻度情報または利用頻度値(「予測アベイラビリティ・データ」)を更新(生成)するために使用することは、想定しておらず、また、携帯電話が、着信時にそのような「信号強度」を取得することが本願優先日前における技術常識であったともいえないから、引用発明において、着信時の「当日の曜日と現在の時間帯を示す値」を取得するにあたり、当該値に加えて、「信号強度」を取得するとともに、当該「信号強度」を使用して「利用頻度情報」又は「利用頻度値」(予測アベイラビリティ・モデル)を更新(生成)することが、当業者にとって設計的な事項であるともいえない。
したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用発明、引用文献2ないし4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

(2)本願発明2ないし13について
本願発明2ないし13も、相違点1に係る本願発明1の構成と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、引用文献2ないし4に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3 理由2(進歩性欠如)についてのまとめ
以上のとおり、当審拒絶理由の理由2(進歩性欠如)は解消した。

第7 原査定についての判断
本件補正により、補正後の請求項1ないし13は、上記相違点1に係る本願発明1の構成を有するものとなった。当該構成は、原査定における引用文献A及びB(当審拒絶理由における引用文献1及び4)には記載されておらず、本願優先日前における周知技術でもないので、本願発明1ないし13は、当業者であっても、原査定における引用文献A及びBに基づいて容易に発明できたものではない。したがって、原査定を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2020-10-12 
出願番号 特願2016-533808(P2016-533808)
審決分類 P 1 8・ 121- WY (G06F)
P 1 8・ 537- WY (G06F)
最終処分 成立  
前審関与審査官 小林 義晴  
特許庁審判長 稲葉 和生
特許庁審判官 太田 龍一
林 毅
発明の名称 使用量データを収集して複数の通信デバイス上でのユーザのアベイラビリティを決定するための方法、システム、およびコンピュータ・プログラム  
代理人 太佐 種一  
代理人 上野 剛史  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ