2020-011258

第１ 手続の経緯

本願は、平成３０年８月１日（パリ条約による優先権主張 ２０１７年（平成２９年）１１月１６日、中華人民共和国）の出願であって、令和１年９月１２日付けで拒絶の理由が通知され、令和１年１１月１５日に手続補正がされ、令和２年４月１０日付けで拒絶査定がされたものである。これを不服として令和２年８月１３日に本件審判の請求がされ、同時に手続補正がされた。

第２ 拒絶査定の概要

令和２年４月１０日付け拒絶査定の概要は次のとおりである。

この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

記

請求項１－３、６、８－１０、１３－１６に対して引用文献１

請求項４、１１に対して引用文献１、２

請求項５、１２に対して引用文献１－３

請求項７に対して引用文献１－４

引用文献１ 国際公開第２０１６／１５８７９２号

引用文献２ 特開２０１７－１３８６９８号公報（周知技術を示す文献）

引用文献３ 特表２００７－５３８４３２号公報（周知技術を示す文献）

引用文献４ 米国特許出願公開第２０１０／０２４０４０２号明細書（周知技術を示す文献）

第３ 令和２年８月１３日にされた手続補正の却下の決定

［補正の却下の決定の結論］

令和２年８月１３日にされた手続補正を却下する。

［理由］

１ 補正の内容

令和２年８月１３日にされた手続補正（以下、「本件補正」という。）は、令和１年１１月１５日に補正された特許請求の範囲の請求項１の記載を補正後の請求項１の記載にする補正事項を含むものであり、補正前後の請求項１の記載は、それぞれ、次のとおりである。（下線部は、補正箇所である。）

［補正前の請求項１］

音声対話方法であって、

音声対話シーンで、サーバからプッシュされた通知情報を受信するステップと、

ユーザの音声により、ユーザの制御対象と制御意図を取得するステップと、

制御対象がサーバに予め記憶されたユーザの選択可能な通知情報に属するか否かを判断するステップと、

制御対象がユーザの選択可能な通知情報に属する場合、サーバが制御対象に対して前記制御意図に対応する制御を実行するステップと、を含み、

ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報であることを特徴とする音声対話方法。

［補正後の請求項１］

音声対話方法であって、

音声対話シーンで、サーバからプッシュされた通知情報を受信するステップと、

ユーザの音声により、ユーザの制御対象と制御意図を取得するステップと、

制御対象がサーバに予め記憶されたユーザの選択可能な通知情報に属するか否かを判断するステップと、

制御対象がユーザの選択可能な通知情報に属する場合、サーバが制御対象に対して前記制御意図に対応する制御を実行するステップと、を含み、

ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報であり、

前記サーバが制御対象に対して前記制御意図に対応する制御を実行するステップは、前記制御意図が取得することであるか否かを判断するステップと、前記制御意図が取得することである場合、サーバは制御対象の選定した通知情報を再生データに形成してユーザの使用する端末に送信するステップと、を含み、

ユーザの使用する端末が通知情報の再生データを再生する場合、制御対象の選定した通知情報が変更すれば、サーバは、変更前の制御対象の選定した通知情報に基づいて形成した前記再生データを前記ユーザの使用する端末に送信することを送信途中に停止し、変更後の制御対象の選定した通知情報に基づいて形成した他の再生データを前記ユーザの使用する端末に送信するステップを含むことを特徴とする音声対話方法。

２ 補正の適否

事案に鑑みて、まず、上記補正事項で新たに付加された下線部のうち後半の、

「ユーザの使用する端末が通知情報の再生データを再生する場合、制御対象の選定した通知情報が変更すれば、サーバは、変更前の制御対象の選定した通知情報に基づいて形成した前記再生データを前記ユーザの使用する端末に送信することを送信途中に停止し、変更後の制御対象の選定した通知情報に基づいて形成した他の再生データを前記ユーザの使用する端末に送信するステップ」を付加する補正（以下、「補正事項１」という。）

が、願書に最初に添付された明細書、特許請求の範囲又は図面（以下、「当初明細書等」という。）に記載した事項の範囲内においてしたものであるか否かについて検討する。

補正事項１に関連すると考えられる当初明細書等に記載した事項は、実施例２に関する次のとおりのものである。

「【００３４】

更に、ユーザの使用する端末で通知情報の再生データを再生する場合、ユーザの音声により取得されたユーザの制御対象の選定した通知情報が変更すれば、サーバが変更後の制御対象の選定した通知情報を再生データに形成してユーザの使用する端末に送信する。つまり、ある通知情報の再生データを再生する時に、音声対話によって別の制御対象の選定した通知情報を取得することを実現できる。

【００３５】

１つの例において、例えば、ユーザの使用する端末で天気予報を再生する時に、ユーザが天気予報を聞きたくない場合、「前へ」、「次へ」、「最後へ」等を使用して、ユーザが変更後の制御対象の選定した通知情報を取得することを実現できる。」

段落００３４、段落００３５の記載（特に、下線部）と上記補正事項１とを対比してみると、まず、段落００３４の下線部には、補正事項１のうち「ユーザの使用する端末が通知情報の再生データを再生する場合、制御対象の選定した通知情報が変更すれば、サーバは、」「変更後の制御対象の選定した通知情報に基づいて形成した他の再生データを前記ユーザの使用する端末に送信するステップ」に相当する事項が記載されていると認められる。

次に、段落００３４、段落００３５の記載を併せて考えると、天気予報の再生データが、補正事項１のうち「変更前の制御対象の選定した通知情報に基づいて形成した前記再生データ」に相当し、この天気予報の再生データを聞かないようにすることを、ユーザが制御対象を変更することにより実現できることは記載されていると認められる。

しかしながら、天気予報の再生データを「前記ユーザの使用する端末に送信することを送信途中に停止」することまでは、段落００３４、段落００３５に記載されているとはいえない。また、当初明細書等のその他の記載をみても、このことは記載されていないし、自明な事項であるともいえないから、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものである。

したがって、補正事項１は、当初明細書等に記載した事項の範囲内においてしたものとはいえない。

よって、本件補正は、特許法第１７条の２第３項に規定する要件を満たしていないので、補正の却下の決定の結論のとおり決定する。

第４ 本願発明

令和２年８月１３日にされた手続補正は却下されたので、本願の請求項１～１６に係る発明（以下、それぞれ「本願発明１」～「本願発明１６」という。）は、令和１年１１月１５日の手続補正により補正された特許請求の範囲の請求項１～１６に記載された事項により特定される以下のとおりの発明である。

「【請求項１】

音声対話方法であって、

音声対話シーンで、サーバからプッシュされた通知情報を受信するステップと、

ユーザの音声により、ユーザの制御対象と制御意図を取得するステップと、

続きを表示（全59行）

制御対象がサーバに予め記憶されたユーザの選択可能な通知情報に属するか否かを判断するステップと、

制御対象がユーザの選択可能な通知情報に属する場合、サーバが制御対象に対して前記制御意図に対応する制御を実行するステップと、を含み、

ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報であることを特徴とする音声対話方法。

【請求項２】

前記サーバが制御対象に対して前記制御意図に対応する制御を実行することは、

前記制御意図が取得することであるか否かを判断するステップと、

前記制御意図が取得することである場合、サーバは制御対象の選定した通知情報を再生データに形成してユーザの使用する端末に送信するステップと、を含み、

前記再生データは、ユーザの使用する端末が音声対話シーンでサポートする再生フォーマットのデータを含み、制御対象の選定した通知情報が制御対象に係る通知情報であることを特徴とする請求項１に記載の方法。

【請求項３】

前記サーバが制御対象の選定した通知情報を再生データに形成することは、

サーバが制御対象の選定した通知情報におけるテキストを処理してテキストに対応するオーディオを形成するステップを含むことを特徴とする請求項２に記載の方法。

【請求項４】

ユーザの使用する端末が通知情報の再生データを再生する場合、制御対象の選定した通知情報が変更すれば、サーバは変更後の制御対象の選定した通知情報を再生データに形成してユーザの使用する端末に送信するステップを更に含むことを特徴とする請求項２に記載の方法。

【請求項５】

前記サーバが制御対象に対して前記制御意図に対応する制御を実行することは、

前記制御意図が削除することであるか否かを判断するステップと、

前記制御意図が削除することである場合、サーバは制御対象の選定した通知情報を前記サーバから削除するステップとを更に含むことを特徴とする請求項１に記載の方法。

【請求項６】

各ユーザの選択可能な通知情報は、プッシュ対象がユーザである通知情報、及び/又はプッシュ対象がユーザとプリセット関連を有する他のユーザである通知情報を含むことを特徴とする請求項１～５のいずれかの項に記載の方法。

【請求項７】

前記サーバの記憶装置は、未読通知情報キューと既読通知情報キューを含む複数のキューユニットを含む複数のユーザ記憶ユニットを備え、

１つのユーザ記憶ユニットは、プッシュ対象が同一のユーザである通知情報を記憶し、同一の記憶ユニットの１つのキューユニットは、同一のユーザの同一のソースサービスの通知情報を記憶し、同一のキューユニットの未読情報キューと既読情報キューは、それぞれ同一のユーザの同一のソースサービスの未読通知情報と既読通知情報を記憶するように設置されることを特徴とする請求項１～５の何れかの項に記載の方法。

【請求項８】

音声対話装置であって、

音声対話シーンで、サーバからプッシュされた通知情報を受信する受信モジュールと、

通知情報を記憶する記憶モジュールと、

ユーザの音声により、ユーザの制御対象と制御意図を取得する取得モジュールと、

制御対象がサーバに予め記憶されたユーザの選択可能な通知情報に属するか否かを判断し、制御対象がユーザの選択可能な通知情報に属する場合、サーバが制御対象に対して前記制御意図に対応する制御を実行する制御モジュールとを備え、

ユーザの選択可能な通知情報は、サーバに予め記憶されて、ユーザに対するプリセットルールを有する通知情報であることを特徴とする音声対話装置。

【請求項９】

再生モジュールを更に備え、

前記制御意図が取得することである場合、前記制御モジュールは制御対象の選定した通知情報を再生データに形成して前記再生モジュールに送信するように設置され、

前記再生データは、再生モジュールが音声対話シーンでサポートする再生フォーマットのデータを含み、

制御対象の選定した通知情報が制御対象に係る通知情報であることを特徴とする請求項８に記載の装置。

【請求項１０】

前記制御モジュールは、具体的に制御対象の選定した通知情報におけるテキストを処理して、テキストに対応するオーディオを形成するように設置されることを特徴とする請求項９に記載の装置。

【請求項１１】

前記制御モジュールが通知情報の再生データを再生する場合、制御対象の選定した通知情報が変更すれば、前記制御モジュールは変更後の制御対象の選定した通知情報を再生データに形成して前記再生モジュールに送信するように設置されることを特徴とする請求項９に記載の装置。

【請求項１２】

前記制御意図が削除することである場合、前記制御モジュールは制御対象の選定した通知情報を前記記憶モジュールから削除するように設置されることを特徴とする請求項８に記載の装置。

【請求項１３】

端末であって、

１つ又は複数のプロセッサと、

１つ又は複数のプログラムを記憶する記憶装置と、を備え、

前記１つ又は複数のプログラムが前記１つ又は複数のプロセッサにより実行される場合、前記１つ又は複数のプロセッサに請求項１～７の何れかの項に記載の方法を実現させることを特徴とする端末。

【請求項１４】

サーバであって、

１つ又は複数のプロセッサと、

１つ又は複数のプログラム、及び通知情報を記憶する記憶装置と、を備え、

前記１つ又は複数のプログラムが前記１つ又は複数のプロセッサにより実行される場合、前記１つ又は複数のプロセッサに請求項１～７の何れかの項に記載の方法を実行させることを特徴とするサーバ。

【請求項１５】

コンピュータ可読記憶媒体であって、

コンピュータプログラムを記憶し、該プログラムがプロセッサにより実行される場合、請求項１～７の何れかの項に記載の方法を実現することを特徴とするコンピュータ可読記憶媒体。

【請求項１６】

コンピュータにおいて、プロセッサにより実行される場合、請求項１～７の何れかの項に記載の方法を実現することを特徴とするプログラム。」

第５ 引用文献、引用発明等

１．引用文献１について

拒絶査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている。

「[0048] ＜＜３．動作処理＞＞

次に、本実施形態による音声認識システムの動作処理について図３を参照して具体的に説明する。

[0049] 図３は、本実施形態による音声認識システムの動作処理を示すフローチャートである。図３に示すように、まずステップＳ１０３において、情報処理装置１は、各種センサにより周辺環境をセンシングする。具体的には、情報処理装置１は、マイクロホン１２、カメラ１４、または測距センサ１５により外部音源の存在、周辺に存在する人物（ユーザを含む）の位置、状態等を取得し、また、情報処理装置１に内蔵された時計部（不図示）若しくはネットワーク上の所定サーバから現在時刻を取得し得る。なおＳ１０３に示す周辺環境のセンシングは、後述する処理と並行して継続され得る。

[0050] 次いで、ステップＳ１０６において、情報処理装置１の制御部１０は、マイクロホン１２から収音した音声信号の音声認識および意味解析によりユーザによる発話を検知する。すなわち、制御部１０は、音声認識部１０ａによりマイクロホン１２で収音した音声信号の認識を行い、変換した文字列の意味解析を意味解析部１０ｂにより行い、発話を検知し、検知した発話の意味解析結果を応答生成部１０ｃに出力する。

[0051] 次に、ステップＳ１０９において、レベル算出部１０ｄは、現在の周辺環境に基づいて出力許容レベルを算出する。具体的には、レベル算出部１０ｄは、システム利用環境における様々な要素（外部音源の存在、ユーザ環境、ユーザの振る舞い、ユーザの位置等）に基づいて、音声による応答出力が好ましい（許容される）環境であるか否かを示す出力許容レベルを算出する。

[0052] 次いで、ステップＳ１１２において、決定部１０ｅは、レベル算出部１０ｄにより算出された出力許容レベルに基づいて応答の出力方法を決定する。例えば、音声による応答出力が好ましくない環境であることを示す出力許容レベルが算出された場合、決定部１０ｅは、表示による出力方法に決定する。

[0053] 続いて、ステップＳ１１５において、出力制御部１０ｆは、応答生成部１０ｃが意味解析部１０ｂによる発話の意味解析結果に対して生成したユーザの発話に対する応答を、決定部１０ｅにより決定された出力方法で出力するよう制御する。これにより、本実施形態による音声ＵＩシステムでは、ユーザの発話に対する応答が音声に限定されず、表示出力等、環境に応じて最適な出力方法を自動的に決定して応答することが可能となる。例えば夜間やユーザの隣で赤ちゃんが寝ている場合には、音声による応答は好ましくないため、情報処理装置１は、投影部１６により応答画像を投影して表示することで、最適な出力方法で応答することができる。このような応答出力例について、以下詳細に説明する。」

「[0026] 応答生成部１０ｃは、意味解析結果に基づいて、ユーザの発話に対する応答を生成する。例えば応答生成部１０ｃは、ユーザの発話が「明日の天気」を求めるものである場合、ネットワーク上の天気予報サーバから「明日の天気」に関する情報を取得し、応答を生成する。」

「

［図：0001381324000001.jpg］

」

以上の記載事項（特に、下線部）によれば、引用文献１には、「音声認識システムの動作処理」の方法として、次の発明（以下、「引用発明」という。）が記載されていると認められる。なお、符号ａ～ｇは、当審により付与したものである。

［引用発明］

ａ まずステップＳ１０３において、情報処理装置１は、各種センサにより周辺環境をセンシングし、具体的には、情報処理装置１は、マイクロホン１２、カメラ１４、または測距センサ１５により外部音源の存在、周辺に存在する人物（ユーザを含む）の位置、状態等を取得し、

ｂ 次いで、ステップＳ１０６において、情報処理装置１の制御部１０は、マイクロホン１２から収音した音声信号の音声認識および意味解析によりユーザによる発話を検知し、すなわち、制御部１０は、音声認識部１０ａによりマイクロホン１２で収音した音声信号の認識を行い、変換した文字列の意味解析を意味解析部１０ｂにより行い、発話を検知し、検知した発話の意味解析結果を応答生成部１０ｃに出力し、

ｃ 次に、ステップＳ１０９において、レベル算出部１０ｄは、現在の周辺環境に基づいて出力許容レベルを算出し、具体的には、レベル算出部１０ｄは、システム利用環境における様々な要素（外部音源の存在、ユーザ環境、ユーザの振る舞い、ユーザの位置等）に基づいて、音声による応答出力が好ましい（許容される）環境であるか否かを示す出力許容レベルを算出し、

ｄ 次いで、ステップＳ１１２において、決定部１０ｅは、レベル算出部１０ｄにより算出された出力許容レベルに基づいて応答の出力方法を決定し、例えば、音声による応答出力が好ましくない環境であることを示す出力許容レベルが算出された場合、決定部１０ｅは、表示による出力方法に決定し、

ｅ 続いて、ステップＳ１１５において、出力制御部１０ｆは、応答生成部１０ｃが意味解析部１０ｂによる発話の意味解析結果に対して生成したユーザの発話に対する応答を、決定部１０ｅにより決定された出力方法で出力するよう制御し、これにより、本実施形態による音声ＵＩシステムでは、ユーザの発話に対する応答が音声に限定されず、表示出力等、環境に応じて最適な出力方法を自動的に決定して応答することが可能となり、

ｆ 例えば応答生成部１０ｃは、ユーザの発話が「明日の天気」を求めるものである場合、ネットワーク上の天気予報サーバから「明日の天気」に関する情報を取得し、応答を生成する、

ｇ 音声認識システムの動作処理の方法。

２．その他の文献について

（１）引用文献２

拒絶査定の拒絶の理由に引用された引用文献２には、図面とともに次の技術事項が記載されている。

「【００６８】

図１８～図２３は、天気予報の表示を制御する動作の例を説明するための図である。まず、ユーザ８０は天気予報を閲覧したいと考えた場合、図１８に示すように、「天気予報」と発話する。ユーザ８０がこのように発話すると、図４および図５を参照しながら説明した場合と同様にして、表示制御部１２８は、コマンド「現在地の天気予報の表示」を制御する。図１８には、現在地の天気予報が、コマンド受付画面３０－５Ａとして表示されている。なお、現在地の天気予報は、外部ネットワーク３０を介して図示しないサーバから取得されてよい。

【００６９】

なお、天気予報などのように細かい情報は、大きな画面に表示されるのが見やすさの観点からよいと考えられる。したがって、図１８に示すように、天気予報が制御対象機器（ＴＶ）２０－１の画面に表示されてよい。このとき、図１８に示すように、情報処理装置１０が自律的に制御対象機器（ＴＶ）２０－１の方に向きを変えるようにしてよい。そうすれば、ユーザ８０も制御対象機器（ＴＶ）２０－１に天気予報が表示されることを感覚的により容易に把握しやすくなる。

【００７０】

続いて、ユーザ８０は現在地（東京）の週間天気を閲覧したいと考えた場合、図１８に示すように、「週間天気」と発話する。ユーザ８０がこのように発話すると、図８を参照しながら説明した場合と同様に、実行制御部１２７は、コマンド「現在地の週間天気の表示」が実行されるように制御対象機器（図示しないサーバ）を制御する。図１９を参照すると、制御対象機器（図示しないサーバ）から取得された東京の週間天気がコマンド受付画面３０－５Ｂとして表示されている様子が示されている。

【００７１】

続いて、ユーザ８０は大阪の週間天気を閲覧したいと考えた場合、図２０に示すように、「大阪の週間天気」と発話する。ユーザ８０がこのように発話すると、図８を参照しながら説明した場合と同様に、実行制御部１２７は、コマンド「大阪の週間天気の表示」が実行されるように制御対象機器（図示しないサーバ）を制御する。図２０を参照すると、制御対象機器（図示しないサーバ）から取得された大阪の週間天気がコマンド受付画面３０－５Ｂとして表示されている様子が示されている。

【００７２】

続いて、ユーザ８０はメッシュ天気を閲覧したいと考えた場合、図２１に示すように、「メッシュ天気」と発話する。ユーザ８０がこのように発話すると、図８を参照しながら説明した場合と同様に、実行制御部１２７は、コマンド「メッシュ天気の表示」が実行されるように制御対象機器（図示しないサーバ）を制御する。図２１を参照すると、制御対象機器（図示しないサーバ）から取得されたメッシュ天気がコマンド受付画面３０－５Ｃとして表示されている様子が示されている。」

（２）引用文献３

拒絶査定の拒絶の理由に引用された引用文献３には、図面とともに次の技術事項が記載されている。

「【００２７】

ＰＣまたはサーバの知的エージェントはインターネットやローカルアプリケーションソフトウェアプログラムなどのソースから情報を抽出することができ、その情報は音声サーバに安全に送信され、通話者がその情報を耳で聞けるように情報が発話パターンに変換される。ユーザは、発話コマンドを発することで、ユーザのデスクトップコンピュータまたはサーバ上のサービスおよびプログラムを停止および開始させたり、知的エージェントが参照またはアクセスできる情報を追加し、削除し、転送し、返信することができる。ユーザは発話コマンドを発することで、カレンダへの記入、Ｅメールまたはデータベースへの入力などの新規データオブジェクトをＰＣまたはサーバ上に編集したり作成したりもできる。」

（３）引用文献４

拒絶査定の拒絶の理由に引用された引用文献４には、図面とともに次の技術事項が記載されている。

「[0027] FIGS.3A-3F are screen shots that depict the use of the secondary display 105 to show queue counts and message summaries. FIG.3A is a screen shot associated with a messaging status mode 300 of the secondary display 105. In the messaging status mode 300, the secondary display presents a count of the number of messages contained in queues that are waiting to be accessed by a user. Messages may be email messages, voicemail messages, instant message (IM) messages, SMS or MMS messages, social networking messages (e.g., tweets, pokes), or the like. In the depicted example, the status of four queues is displayed, namely the status of an email queue 305, a voicemail queue 310, a text message queue 315, and a preferred social networking queue 320. Each queue is represented by an icon, such as an envelope icon 325 to represent the email queue and a #thought bubble# icon 330 to represent the text message queue. The status of each queue is indicated by a count 335 which represents the number of messages in the queue that have not yet been accessed (i.e., are currently unopened) by the user. For example, the email queue count indicates that three email messages have not been accessed by the user and the text message queue count indicates that five unread entries are contained in a current instant message thread. A queue count of zero indicates that no messages are currently in the queue for the user.」

（訳：[００２７] 図３Ａ－３Ｆは、待ち行列の数とメッセージのサマリーを示す第二のディスプレイ１０５の使用を示すスクリーンショットです。図３Ａは第二のディスプレイ１０５のメッセージ交換ステータスモード３００に関するスクリーンショットです。メッセージ交換ステータスモード３００で、第二のディスプレイはユーザによってアクセスされるのを待っている待ち行列に含まれたメッセージの数のカウントを提供します。メッセージは、電子メールメッセージ、ボイスメールメッセージ、インスタントメッセージ（ＩＭ）メッセージ、ＳＭＳあるいはＭＭＳメッセージ、ソーシャルネットワーキングメッセージ（例えば、ツイート、ポーク）、あるいは同様のものであるかもしれません。示された例では、４つの待ち行列の状況、すなわち、電子メール待ち行列３０５、ボイスメール待ち行列３１０、メッセージ待ち行列３１５、及び優先のソーシャルネットワーキング待ち行列３２０の状況が表示されています。それぞれの待ち行列は、電子メール待ち行列を表す封筒アイコン３２５、テキストメッセージ待ち行列を表す# ソートバブル # アイコン３３０のような１つのアイコンによって表されます。それぞれの待ち行列の状況は、まだユーザにアクセスされていない（すなわち現在開かれていない）待ち行列のメッセージの数を表すカウント３３５によって示される。例えば、電子メール待ち行列カウントは、３つの電子メールメッセージがユーザによってアクセスされていないことを示し、そして、テキストメッセージ待ち行列カウントは、５つの未読の項目が現在のインスタントメッセージスレッドに含まれることを示します。ゼロの待ち行列カウントは、現在、メッセージがユーザの待ち行列にないことを示します。）

第６ 対比・判断

１．本願発明１について

（１）対比

事案に鑑みて、まず、本願発明１の発明特定事項のうち「ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報であることを特徴とする音声対話方法。」について引用発明と対比する。

引用発明は、ｇ、ｂ、ｅによれば、「音声認識システムの動作処理の方法」であって、「マイクロホン１２から収音した音声信号の音声認識および意味解析によりユーザによる発話を検知し」、「ユーザの発話に対する応答を、決定部１０ｅにより決定された出力方法で出力するよう制御」する方法であり、応答の出力方法には、音声による出力も含まれているから、本願発明１と「音声対話方法」である点で一致する。

また、引用発明は、ｆによれば、例えば応答生成部１０ｃは、ユーザの発話が「明日の天気」を求めるものである場合、ネットワーク上の天気予報サーバから「明日の天気」に関する情報を取得し、応答を生成するから、該応答を生成するための「「明日の天気」に関する情報」は、ネットワーク上の天気予報サーバに記憶されており、本願発明１の「サーバに予め記憶されたユーザの選択可能な通知情報」に相当する。

したがって、本願発明１と引用発明は、「ユーザの選択可能な通知情報は、サーバに予め記憶された通知情報であることを特徴とする音声対話方法。」である点で共通する。

しかしながら、本願発明１と引用発明は、少なくとも次の点で相違する。

（相違点）

「ユーザの選択可能な通知情報」について、本願発明１においては、「ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報である」のに対し、引用発明においては、「「明日の天気」に関する情報」は、「サーバに予め記憶された通知情報」とはいえるものの、「サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報」ではない点。

（２）相違点についての判断

引用発明における、応答を生成するための「「明日の天気」に関する情報」は、ネットワーク上の天気予報サーバに記憶されているが、この情報を、本願発明１のような「ユーザに対するプリセットルールを有する」情報にしようとする動機付けとなる事項は引用文献１には記載されておらず、また、引用文献２～４にも記載されていない。

引用発明は、「出力許容レベル」に基づいて、ユーザの発話に対する応答の出力方法を決定するものであり、該「出力許容レベル」は一種のルールであるとはいえる。しかしながら、該「出力許容レベル」は、各種センサによりセンシングした現在の周辺環境に基づいて算出するものであって、音声認識システムが「「明日の天気」に関する情報」をネットワーク上の天気予報サーバから取得した後に算出されるものであるから、本願発明１の「サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報」の「プリセットルール」に相当するものではなく、本願発明１の「サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報」を導出するための動機付けとなり得るものではない。

したがって、本願発明１は、引用発明に基いて当業者が容易に発明をすることができたものであるということはできない。

２．本願発明２～１６について

本願発明８は、方法に係る発明である本願発明１の発明のカテゴリーを単に装置としたものであり、本願発明２～７、９～１６は、請求項１又は８を直接的又は間接的に引用して本願発明１又は８の発明特定事項を全て含み、さらに発明特定事項を付加するものであるから、本願発明１の「ユーザの選択可能な通知情報は、サーバに予め記憶されてユーザに対するプリセットルールを有する通知情報である」と同じ発明特定事項を有するものである。

したがって、本願発明１と同じ理由により、本願発明２～１６は、引用発明（及び引用文献２～４に記載された周知技術）に基いて当業者が容易に発明をすることができたものであるということはできない。

第７ むすび

以上のとおり、本願発明１～１６は、引用発明に基いて当業者が容易に発明をすることができたものであるということはできない。

したがって、拒絶査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。