【事件の表示】
　特願２０１３−１７５３１７「ユーザインターフェース提供方法、機械可読保存媒体及び携帯端末」拒絶査定不服審判事件〔平成２６年　３月１３日出願公開、特開２０１４−　４４７２５、請求項の数（１４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２５年８月２７日（パリ条約による優先権主張２０１２年８月２７日、韓国）の出願であって、平成２９年６月２７日付けで拒絶理由が通知され、平成２９年１０月２日付けで手続補正がされるとともに意見書が提出され、平成３０年２月２８日付けで拒絶理由（最後）が通知され、平成３０年６月７日付けで手続補正がされるとともに意見書が提出され、平成３０年１０月３１日付けで平成３０年６月７日に提出された手続補正書による手続補正が却下されるとともに拒絶査定がされ、これに対し、平成３１年３月１２日に拒絶査定不服審判の請求がされると同時に手続補正がされ、その後、令和２年５月１５日付けで当審より拒絶理由が通知され（以下、「当審拒絶理由（１）」という。）、令和２年８月１８日に手続補正がされるとともに意見書が提出され、令和２年１１月３０日付けで当審より拒絶理由（最後）（以下、「当審拒絶理由（２）」という。）が通知され、令和３年３月８日に手続補正がされるとともに意見書が提出されたものである。
第２　原査定の概要
　原査定（平成３０年１０月３１日付け拒絶査定）の概要は次のとおりである。
　本願請求項１−１４に係る発明は、以下の引用文献Ａ−Ｄに基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
　Ａ．特表２００７−５１１０００号公報
　Ｂ．ｄｏｃｏｍｏ　ＮＥＸＴ　ｓｅｒｉｅｓ　ＭＥＤＩＡＳ　ＰＰ　Ｎ−０１Ｄ取扱説明書、株式会社ＮＴＴドコモ、２０１１年１１月３０日、第１．２版、ｐ．１０９　
　Ｃ．知らないと損する！パソコン／インターネットの「新」常識、株式会社アスキー・メディアワークス、後藤靖彦、２０１０年５月２４日、ｐ．１４９　
　Ｄ．金子寛人、最新Ｗｅｂブラウザーの力を１００％引き出す　快適！ＩＥ９使いこなし術、日経パソコン、Ｎｏ．６３３、日経ＢＰ社、２０１１年９月１２日、第６３３号、ｐ．６６
第３　当審拒絶理由の概要
１　当審拒絶理由（１）の概要
　本願請求項１−１４に係る発明は、引用文献１−３に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
　１．特開２０１０−２６６８６号公報
　２．特表２００７−５１１０００号公報（拒絶査定時の引用文献Ａ）
　３．特開２０００−１０６９０号公報
２　当審拒絶理由（２）の概要
理由１（新規事項）　令和２年８月１８日付け手続補正書でした補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
理由２（サポート要件）　この出願は、特許請求の範囲の請求項１−１４の記載が、特許法第３６条第６項第１号に規定する要件を満たしていない。
理由３（明確性）　この出願は、特許請求の範囲の請求項１−１４の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。
理由４（進歩性）　本願請求項１−１４に係る発明は、引用文献１−３に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
　１．特開２０１０−２６６８６号公報
　２．特表２００７−５１１０００号公報（拒絶査定時の引用文献Ａ）
　３．特開２０００−１０６９０号公報
第４　本願発明
　本願請求項１−１４に係る発明（以下、それぞれ「本願発明１」−「本願発明１４」という。）は、令和３年３月８日付けの手続補正で補正された特許請求の範囲の請求項１−１４に記載された事項により特定される発明であって、本願発明１は以下のとおりの発明である。
　「【請求項１】
　携帯端末のユーザインターフェース提供方法であって、
　音声認識アプリケーションの音声入力受信のための第１の画面を表示するステップと、
　ユーザのモード転換要請によって、前記第１の画面が表示された少なくとも一部の間、筆記入力モードのための
領域を、第１の画面の一部に
　前記筆記入力モードで前記
領域
　前記
領域
識す
　前記ユーザによる追加の音声データを受信するステップと、
　前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得するステップと、ここで、前記組み合わせデータは、テキストデータまたは音声データのうちの少なくとも一つであり、
　前記組み合わせされたデータを前記入力された筆記データの代わりに前記第１の画面に表示するステップと、
　前記音声認識アプリケーションにより前記
組み合わせ
　前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、
　前記音声認識アプリケーションの前記第１の画面に、前記
組み合わせ
　なお、本願発明２−１４の概要は以下のとおりである。
　本願発明２−６は、本願発明１を減縮した発明である。
　本願発明７は、本願発明１−６に対応する機械可読保存媒体の発明であり、本願発明１−６とカテゴリ表現が異なるだけの発明である。
　本願発明８は、本願発明７に対応する携帯端末の発明であり、本願発明７とカテゴリ表現が異なるだけの発明である。
　本願発明９は、本願発明１に対応する携帯端末の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。
　本願発明１０-１４は、本願発明９を減縮した発明である。
第５　引用文献、引用発明等
１　引用文献１及び引用発明
（１）　引用文献１
　当審拒絶理由（２）の理由４において引用した引用文献１には、図面とともに、以下の記載がある（下線は、特に着目した箇所を示す。以下同様。）。
ア　段落【０００５】
「【発明が解決しようとする課題】
【０００５】
　本発明は上述のような事情に鑑み為されたものであり、操作者の発する音声を認識・解析し、ナビゲーション用キャラクタによる対話型のコミュニケーションを可能とするとともに、
タッチパネル入力を併用することにより、音声認識による対話型コミュニケーションを補完した統合的インタフェースを有する対話型コミュニケーション端末
イ　段落【００１４】
「【００１４】
　図２は端末の内部の各部の相互関係を示す図である。
音声入力部（マイク）１０１で入力されたユーザの音声は音声認識辞書１０６により音声認識エンジン１０７で認識され
音声認識には、例えばワードスポッティング法が用いられる。ワードスポッティング法とは、話し言葉（入力音声）から必要な言葉（単語や音節）を拾いだしていく方式である。ワードスポッティング法は、発話を一字一句文字に置き換える方法ではなく、意味理解に必要なキーワードだけを抜き出して認識する手法である。
　
音声認識エンジン１０７によって認識された入力命令は統合インタフェース制御部１１１送られ、統合インタフェース制御部１１１が関連する各制御部（１０８〜１１０、１１４〜１１９）に命令を送り、命令が実行され
また、タッチパネル入力部１０２又は手書き入力部１０３から入力された命令も統合インタフェース制御部１１１送られ、同様の処理がなされ
　音声・画面表示出力は図１のモニタ１０４、スピーカ１０５に対応するものであり、
入力された命令に応じて対話シナリオ制御部１０９で応答文が決定され、キャラクタ制御部１０８でキャラクタに発話させて音声とともに画面に表示する
　このようにユーザ側では
音声入力を主として、それをタッチパネルと手書き入力で補完する形の統一された入力インタフェースであり
Ｗｅｂブラウザ制御、ＩＰ電話制御、電子メール等のメッセージ送受信をシームレスに制御することが可能
ウ　段落【００１６】−【００１９】
「【００１６】
　図４は統合インタフェース動的処理の概念及び
統合インタフェース制御の処理フロー
　入力された命令に応じてどのインタフェースが必要なのかを識別する「統合的インタフェース識別」段階と、選択されたインタフェースに基づいて処理を行う「インタフェース動的処理」段階と、結果を出力する「出力」段階に大きく分けられる。
　
まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別され
何らかの理由で音声認識が不成功の場合は、キャラクタが再度の音声入力を求めるべく同じ質問を繰り返すとともに、タッチパネルに質問に対する回答が選択可能なように表示し、いずれかの手段をユーザが選択でき
　図５は音声による動的処理操作の実施例を示す図である。すなわち、ユーザが音声入力してＷｅｂブラウザを操作する処理の流れを説明するための図である。
　マイクから入力された音声（アナログ信号）はＡ／Ｄ変換部でデジタル信号に変換され、音響解析部において単語や音節として抽出され、照合処理部から認識辞書生成部に問い合わせがなされる。認識辞書生成部は問い合わせがあった単語等が基本命令辞書あるいは可変辞書にあるか否かを調べ、結果を照合処理部に返す。
【００１７】
　可変辞書は、実際には単なる文字列から成る一時的な辞書である。認識させたい単語（場合によっては短文）をコンマで区切りながら連結し、一つの文字列にする。これが可変辞書である。そして、これを引数として音声認識エンジンの特定の関数を呼び出すことで、認識語彙を音声認識エンジンの照合処理部に登録する。
　認識辞書生成部は、コンテクストによって認識語彙を動的に生成・差し替える。コンテクストによって認識語彙を動的に生成・差し替えるとは、例えば、Ｗｅｂページの遷移が発生した場合を考えると、ここで実行される処理は以下のものとなる。図６のフローチャートを参照しつつ説明する。
(1)ページ遷移と同時に、現在登録してある語彙を音声認識エンジンから削除する（ステップＳ１）。
(2)新しいページのＨＴＭＬコードをオブジェクトとして解析し、リンクタグを抽出する。
(3)リンクタグ内の文字列（ユーザにリンク文字として表示されるもの）を抽出する（ステップＳ２）。これは半角英数漢字かな混じり文であることが多いので、これを全角カタカナに変換する（ステップＳ３）。
(4)全角カタカナに変換した文字列を、コンマを挟みながら連結する。こうして「可変辞書」を生成し（ステップＳ４）、音声認識エンジンに登録する（ステップＳ５）。（音声認識エンジンには、平仮名もしくは片仮名の文字列しか登録できない。）
(5)他方、リンク索引作成部は、それぞれのリンクタグオブジェクトへのポインタと、そのカナ変換した認識語彙とをペアとして記憶しておく。具体的には、タグへのポインタを値、対応するカナ文字列をキーとする連想配列を作る。この連想配列を「リンク索引」と呼ぶこととする。
(6)表示されたページ内のリンク文字列をユーザが選び、読み上げる。すなわち、音声入力を行う。音声認識エンジンはこれを解析し、登録されている語彙のいずれかを返す（全く認識できない場合は、エラー値を返すことになる。）。この認識結果をキーとして、先の「リンク索引」から該当するリンクタグを特定し、このリンクタグにおいてクリックイベントを発生させる。イベント発生後、このイベントを処理するのはＷｅｂブラウザである。Ｗｅｂブラウザは、そのリンクがクリックされたものとしてページを遷移させる。これ以降は、(1)から(6)までの繰り返しになる。
　ちなみに、「ＨＴＭＬコードをオブジェクトとして解析」とは、ＨＴＭＬソースコードを文字列として解析するのではなく、ＤＯＭオブジェクトとして解析することである。また、「基本辞書」と「可変辞書」との違いであるが、前者は、コンテクストに関わらず変化しない辞書であり、このソフトのごく基本的な操作を音声で行うためのものである。
【００１８】
　音声操作機能における「命令実行部」の具体的な動作は、音声認識エンジンからの認識結果に基づく。これを図７のフローチャートに基づいて説明する。まず、音声認識が正常にできたことが前提となるが、音声認識ができなかった場合は、音声出力や画面表示を通じて、ユーザにその旨を知らせ、マイク音量の再設定を促す等の処理が行われる。その結果、音声認識が正常に行われた場合は、音声認識の結果を出力する（ステップＳ１１）。具体的には、音声出力や画面表示を通じて、ユーザの操作命令を通知（反復）する。
　認識された語彙を基本命令辞書から探しだす（ステップＳ１２）。基本命令辞書に含まれている場合は、該当する処理を担当するモジュールを、適切なパラメータを設定しながら呼び出す（ステップＳ１３）。例えば、手書き入力によってディスプレイに描画される線の色や太さを変更する、ディスプレイの輝度を変更する、等である。認識された語彙が基本命令辞書に含まれていない場合は、可変辞書から探す（ステップＳ１４）。
　認識された語彙が可変辞書に含まれていない場合は、操作失敗をユーザに伝える（ステップＳ１５）。認識された語彙が可変辞書に含まれている場合であって、リンク文字が一つだけの場合は、「リンク索引」を使用して、Ｗｅｂページの遷移をおこす（ステップＳ１６）。
含まれているリンクが複数ある場合は、該当するリンク文字のすべてを目立たせ、ユーザに音声による特定を促す（ステップＳ１７）。
【００１９】
　図８は図４における出力段階のうちの、文字・画像出力制御の実施例を示す図である。
　手書き入力装置から手書き入力によって文字や図形が入力されたときは、モニタの汎用表示領域（図９参照）のフォアグランド（前景）に描画する。また、Ｗｅｂブラウザが操作されたときは、汎用表示領域のバックグランド（背景）に描画する。従って、Ｗｅｂページの上に手書き入力装置によって文字、イラスト等を描くことも可能になる。
　ＩＰ電話を利用する場合、Ｗｅｂカメラによる動画を使用しない場合は音声通話を行い、動画を使用する場合、汎用表示領域に描画データ（手書き文字、図形等）が既にある場合は、その描画データを保存して、動画表示パネルに自動的にきりかえ、動画を表示する。汎用表示領域に描画データが存在しない場合はすぐに表示パネルを切り換えて動画を表示する。表示パネルの切り換えは、汎用表示領域の上に動画用表示領域を重ねることによって行う。」
エ　段落【００２０】−【００２３】
「【００２０】
　図９は本発明に係るコミュニケーション端末のモニタに表示される初期画面の一例である。画面上部がコントロールパネルになっており、Ｗｅｂページ表示ボタン、ＩＰ電話機能起動ボタン、手書き入力機能のパラメータ設定（ペンの太さ、色等）ボタン等を含む。
　また、その下の余白部分は汎用表示領域であり、Ｗｅｂページや手書き入力されたデータを表示する。
　
たとえば、手書きでメモを取る場合、音声入力で「メモ」と入力すると音声認識され（あるいはメニューの「メモを取る」をタッチペンでタッチしてもよい。）、統合インタフェース制御部が手書き入力制御部を起動し、ユーザが手書き入力装置から入力した文字、イラスト等をイメージとしてモニタの汎用表示領域に表示
【００２１】
　この後、図９の画面の左側の「メモの一覧」をタッチすると、図１０のような「メモ一覧」が表示され、今までに作成したメモが一覧表示される。これは「ユーザドキュメント格納手段」に格納されている。ここで、メモのどれかを友達に送ったり、ブログに貼り付けたりする場合は、「誰かに送る」あるいは「ブログに貼り付ける」をペンでタッチすればよい。
　
また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの？」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力すると、入力された相手の名前がすでにシステムに登録されていれば、その人のアドレスを呼び出し、画面に表示
【００２２】
　図１１は「メールボックス」を選択した場合に表示される画面の一例を示すものであり、受信メールの一覧が表示されている。図１２は「アドレス一覧」を選択した場合の表示画面の一例を示すものであり、各個人ごとのメールアドレス、電話番号、ブログのＵＲＬ等が後述の「ユーザ別相手先管理２０６」に格納されている。
【００２３】
　図１３は端末１００とインターネット３００を介して接続されたサーバ２００の構成を示す図である。
端末１００は常にサーバ２００とインターネット３００を介して接続された状態で使用され
各ユーザの相手先の氏名、電話番号、メールアドレス等の情報や、メールボックス、作成したメモなどの情報は端末内部ではなく、それぞれサーバ２００内にユーザごとに設けられた「ユーザ別相手先管理２０６」、「ユーザドキュメント格納手段」に格納されている
　サーバ２００には、ユーザの端末１００から送られた要求を解析する要求解析部２０１、アクセスした端末の認証をユーザ情報２０２に基づいて行う認証・セッション管理部２０３、ユーザ情報に基づいてユーザ個人のホームページを生成し保存したり、ユーザの個人情報を管理するユーザ管理手段２０４と、端末情報に基づいて端末１００の管理用ホームページを生成し保存する端末管理手段２０５と、各ユーザの相手先の氏名、電話番号、メールアドレス等の情報を格納するユーザ別相手先管理２０６を備えている。その他、図示したような各種サービスの提供のためのデータが格納されている。」
（２）　引用発明
　よって、引用文献１には、次の発明（以下、「引用発明」という。）が開示されているものと認められる。
「タッチパネル入力を併用することにより、音声認識による対話型コミュニケーションを補完した統合的インタフェースを有する対話型コミュニケーション端末において、
　音声入力部（マイク）１０１で入力されたユーザの音声は音声認識辞書１０６により音声認識エンジン１０７で認識され、
　音声認識エンジン１０７によって認識された入力命令は統合インタフェース制御部１１１送られ、統合インタフェース制御部１１１が関連する各制御部（１０８〜１１０、１１４〜１１９）に命令を送り、命令が実行され、また、タッチパネル入力部１０２又は手書き入力部１０３から入力された命令も統合インタフェース制御部１１１送られ、同様の処理がなされ、
　入力された命令に応じて対話シナリオ制御部１０９で応答文が決定され、キャラクタ制御部１０８でキャラクタに発話させて音声とともに画面に表示する、
　音声入力を主として、それをタッチパネルと手書き入力で補完する形の統一された入力インタフェースであり、Ｗｅｂブラウザ制御、ＩＰ電話制御、電子メール等のメッセージ送受信をシームレスに制御することが可能となる統合的インタフェースであって、
　統合的インタフェース制御の処理は、
　まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別され、
　何らかの理由で音声認識が不成功の場合は、キャラクタが再度の音声入力を求めるべく同じ質問を繰り返すとともに、タッチパネルに質問に対する回答が選択可能なように表示し、いずれかの手段をユーザが選択でき、
　たとえば、手書きでメモを取る場合、音声入力で「メモ」と入力すると音声認識され（あるいはメニューの「メモを取る」をタッチペンでタッチしてもよい。）、統合インタフェース制御部が手書き入力制御部を起動し、ユーザが手書き入力装置から入力した文字、イラスト等をイメージとしてモニタの汎用表示領域に表示し、
　また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの？」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力すると、入力された相手の名前がすでにシステムに登録されていれば、その人のアドレスを呼び出し、画面に表示し、
　端末１００は常にサーバ２００とインターネット３００を介して接続された状態で使用され、各ユーザの相手先の氏名、電話番号、メールアドレス等の情報や、メールボックス、作成したメモなどの情報は端末内部ではなく、それぞれサーバ２００内にユーザごとに設けられた「ユーザ別相手先管理２０６」、「ユーザドキュメント格納手段」に格納されている、
統合的インタフェース制御の処理方法。」
２　引用文献２、引用文献３
（１）　引用文献２
　当審拒絶理由（２）の理由４において引用した引用文献２には、図面とともに、以下の記載がある。
ア　段落【０００２】（【背景技術】欄）
「ユーザ入力装置およびインターフェースは、コンピューティング装置についての新たなタイプの要求を満たすように急速に発展している。
最近では、タブレット・ベースのパソコンおよびハンドヘルド・コンピュータが普及しつつある
これらの装置は典型的に、その面上のスタイラスの動きを電子インクに変換する書き込み面を有する
このインクは、認識してテキストに変換するか、または電子インク・フォーマットに格納することができる
イ　段落【００２６】
「上述のように、
ユーザのスタイラス２０４は、タイムアウトになるまでの期間ホバリングしてもよいし
ステップ３０４に示したアクションのいずれかが発生すると、これに応答してステップ３０６において入力パネルがユーザに提示される
入力パネルは、スタイラス２０４からの電子インク入力
など、ユーザ入力を受けることができる
（２）　引用文献３
　当審拒絶理由（２）の理由４において引用した引用文献３には、図面とともに、段落【００１８】−【００２２】に、以下の記載がある。
「【００１７】図２は第１の実施形態による音声データ送信の手順を示すフローチャートである。以下、
図２のフローチャートを参照して
【００１８】】いま、
音声による通信を行っているときに、座標入力部５０３より手書き文字入力が行われたとする（ステップＳ１０１，Ｓ１０２）
　　　・・・（中略）・・・
【００２１】次に、認識データと大きさのデータをデータ変換部２０１へ送り、上記
認識された文章を音声データへ変換する
認識された文字列に基づいて、通信制御部５０６で処理可能なデータ形式を有する音声データ
を生成する
尚、音声入力に基づく符号化音声データと文字入力に基づく音声データ（符号化音声データ）の送信切替は、通信制御部５０６が行う
【００２２】以上、説明したように第１の実施形態によれば、
手書き入力した文字によって音声送信を行える
音声通信中において手書き入力された文字を音声として送信できるので、たとえば、他人に聞かれたくない部分のみをペン入力により送信することも可能である
（３）　周知技術１
　上記（１）引用文献２のイの記載から、一般に、ユーザの要請によって、手書き入力モードを開始することは、周知技術（以下、「周知技術１」と呼ぶ。）であると認められる。
（４）　周知技術２
　上記（１）引用文献２のア、（２）引用文献３の記載から、一般に、手書き入力データを文字認識した結果を、テキストや音声など別の所定のフォーマットに変換することは、周知技術（以下、「周知技術２」と呼ぶ。）であると認められる。
２．対比・判断
（１）　本願発明１について
　本願請求項１に係る発明（以下、「本願発明１」という。）と引用発明とを対比すると、次のことがいえる。
ア　引用発明の「統合的インタフェース制御の処理方法」は、対話型コミュニケーション
端末
インタフェース
携帯
イ　引用発明において、「また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの？」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力する」ことは、本願発明１において、「音声認識アプリケーションの音声入力受信のための第１の画面を表示するステップ」に相当する。
ウ　引用発明において、「たとえば、手書きでメモを取る場合、
音声入力で「メモ」と入力すると
ユーザが手書き入力装置から入力した文字
をイメージとしてモニタの汎用表示領域に表示
、前記領域を通して入力された筆記データを認識するステップと
エ　引用発明において、「まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別され、何らかの理由で音声認識が不成功の場合は、
キャラクタが再度の音声入力を求めるべく同じ質問を繰り返す
いずれかの手段をユーザが選択でき
前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び
組み合わせして組み合わせデータを
組み合わせ
前記組み合わせされたデータを前記入力された筆記データの代わりに前記第１の画面に表示するステップと
オ　　「タッチパネル入力部１０２」を備える、引用発明の「対話型コミュニケーション端末」において、メールを送る場合に、「ここで送りたい
相手の名前を音声入力すると
その人のアドレスを呼び出し、画面に表示し
各ユーザの相手先の氏名
メールアドレス等の情報
サーバ２００内にユーザごとに設けられた「ユーザ別相手先管理２０６」
に格納されている
組み合わせされた
前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に
　よって、本願発明１と引用発明との一致点・相違点は次のとおりであるといえる。
［一致点］
「端末のユーザインターフェース提供方法であって、
　音声認識アプリケーションの音声入力受信のための第１の画面を表示するステップと、
　ユーザのモード転換要請によって、前記第１の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第１の画面の一部に表示するステップと、
　前記筆記入力モードで前記領域を通して入力された筆記データを前記領域に表示するステップと
　前記ユーザによる追加の音声データを受信するステップと、
　前記追加の音声データを獲得するステップと、ここで、前
記デ
　前記音声認識アプリケーションにより前
記デ
　前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、
　前記音声認識アプリケーションの前記第１の画面に
、前
［相違点１］
　本願発明１は、「
携帯
［相違点２］
　筆記入力がされた時に、本願発明１では、さらに、「前記領域を通して入力された筆記データを認識するステップ」を備えるのに対して、引用発明では、筆記入力の認識について特定されていない点。
［相違点３］
　追加の音声データが入力された時に、本願発明１では、さらに、「
前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び
組み合わせして組み合わせデータを
組み合わせ
前記組み合わせされたデータを前記入力された筆記データの代わりに前記第１の画面に表示するステップ
［相違点４］
　検索結果を表示する時に、本願発明１では、「前記音声認識アプリケーションの前記第１の画面に、
前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に
３．当審の判断
　事案に鑑みて、上記［相違点３］について先に検討すると、本願発明１の上記［相違点３］に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」ことについては、上記引用文献１−３には記載されておらず、本願優先日前において周知技術であるともいえない。
　よって、当業者といえども、引用発明及び引用文献２−３に記載された技術的事項から、本願発明１の上記［相違点３］に係る構成を容易に想到することはできない。
　したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用発明及び引用文献２−３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
（２）　請求項２−１４について
　本願発明２−１４も、本願発明１の上記［相違点３］に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」ことと、同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明、引用文献２−３に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。
第６　当審拒絶理由（２）の理由１−３について
　令和３年３月８日付けの補正により、補正後の請求項１−１４は、「前記第１の画面が表示された少なくとも一部の間、
筆記入力モードのための第２の画面
筆記入力モードのための領域を、第１の画面の一部に
第７　当審拒絶理由（１）について
　令和３年３月８日付けの補正により、補正後の請求項１−１４は、本願発明１の上記［相違点３］に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」という技術的事項を有するものとなった。当該技術的事項は、当審拒絶理由（１）における引用文献１−３には記載されておらず、本願優先日前における周知技術でもないので、本願発明１−１４は、当業者であっても、当審拒絶理由（１）における引用文献１−３に基づいて容易に発明をすることができたものではない。したがって、この拒絶の理由は解消した。
第８　原査定についての判断
　令和３年３月８日付けの補正により、補正後の請求項１−１４は、本願発明１の上記［相違点３］に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」という技術的事項を有するものとなった。当該技術的事項は、原査定における引用文献Ａ−Ｄには記載されておらず、本願優先日前における周知技術でもないので、本願発明１−１４は、当業者であっても、原査定における引用文献Ａ−Ｄに基づいて容易に発明をすることができたものではない。したがって、原査定を維持することはできない。
第９　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。