• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特174条1項 取り消して特許、登録 G06F
管理番号 1373036
審判番号 不服2019-3423  
総通号数 258 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-06-25 
種別 拒絶査定不服の審決 
審判請求日 2019-03-12 
確定日 2021-05-10 
事件の表示 特願2013-175317「ユーザインターフェース提供方法、機械可読保存媒体及び携帯端末」拒絶査定不服審判事件〔平成26年 3月13日出願公開、特開2014- 44725、請求項の数(14)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成25年8月27日(パリ条約による優先権主張2012年8月27日、韓国)の出願であって、平成29年6月27日付けで拒絶理由が通知され、平成29年10月2日付けで手続補正がされるとともに意見書が提出され、平成30年2月28日付けで拒絶理由(最後)が通知され、平成30年6月7日付けで手続補正がされるとともに意見書が提出され、平成30年10月31日付けで平成30年6月7日に提出された手続補正書による手続補正が却下されるとともに拒絶査定がされ、これに対し、平成31年3月12日に拒絶査定不服審判の請求がされると同時に手続補正がされ、その後、令和2年5月15日付けで当審より拒絶理由が通知され(以下、「当審拒絶理由(1)」という。)、令和2年8月18日に手続補正がされるとともに意見書が提出され、令和2年11月30日付けで当審より拒絶理由(最後)(以下、「当審拒絶理由(2)」という。)が通知され、令和3年3月8日に手続補正がされるとともに意見書が提出されたものである。

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

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

引用文献等一覧
A.特表2007-511000号公報
B.docomo NEXT series MEDIAS PP N-01D取扱説明書、株式会社NTTドコモ、2011年11月30日、第1.2版、p.109
C.知らないと損する!パソコン/インターネットの「新」常識、株式会社アスキー・メディアワークス、後藤靖彦、2010年5月24日、p.149
D.金子寛人、最新Webブラウザーの力を100%引き出す 快適!IE9使いこなし術、日経パソコン、No.633、日経BP社、2011年9月12日、第633号、p.66

第3 当審拒絶理由の概要
1 当審拒絶理由(1)の概要
本願請求項1-14に係る発明は、引用文献1-3に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特開2010-26686号公報
2.特表2007-511000号公報(拒絶査定時の引用文献A)
3.特開2000-10690号公報

2 当審拒絶理由(2)の概要
理由1(新規事項) 令和2年8月18日付け手続補正書でした補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから、特許法第17条の2第3項に規定する要件を満たしていない。

理由2(サポート要件) この出願は、特許請求の範囲の請求項1-14の記載が、特許法第36条第6項第1号に規定する要件を満たしていない。

理由3(明確性) この出願は、特許請求の範囲の請求項1-14の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。

理由4(進歩性) 本願請求項1-14に係る発明は、引用文献1-3に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特開2010-26686号公報
2.特表2007-511000号公報(拒絶査定時の引用文献A)
3.特開2000-10690号公報

第4 本願発明
本願請求項1-14に係る発明(以下、それぞれ「本願発明1」-「本願発明14」という。)は、令和3年3月8日付けの手続補正で補正された特許請求の範囲の請求項1-14に記載された事項により特定される発明であって、本願発明1は以下のとおりの発明である。

「【請求項1】
携帯端末のユーザインターフェース提供方法であって、
音声認識アプリケーションの音声入力受信のための第1の画面を表示するステップと、
ユーザのモード転換要請によって、前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第1の画面の一部に表示するステップと、
前記筆記入力モードで前記領域を通して入力された筆記データを前記領域に表示するステップと、
前記領域を通して入力された筆記データを認識するステップと、
前記ユーザによる追加の音声データを受信するステップと、
前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得するステップと、ここで、前記組み合わせデータは、テキストデータまたは音声データのうちの少なくとも一つであり、
前記組み合わせされたデータを前記入力された筆記データの代わりに前記第1の画面に表示するステップと、
前記音声認識アプリケーションにより前記組み合わせされたデータを検索語としてサーバに送信するステップと、
前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、
前記音声認識アプリケーションの前記第1の画面に、前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に前記検索結果を表示するステップと、を含むことを特徴とする携帯端末のユーザインターフェース提供方法。」

なお、本願発明2-14の概要は以下のとおりである。
本願発明2-6は、本願発明1を減縮した発明である。
本願発明7は、本願発明1-6に対応する機械可読保存媒体の発明であり、本願発明1-6とカテゴリ表現が異なるだけの発明である。
本願発明8は、本願発明7に対応する携帯端末の発明であり、本願発明7とカテゴリ表現が異なるだけの発明である。
本願発明9は、本願発明1に対応する携帯端末の発明であり、本願発明1とカテゴリ表現が異なるだけの発明である。
本願発明10-14は、本願発明9を減縮した発明である。

第5 引用文献、引用発明等
1 引用文献1及び引用発明
(1) 引用文献1
当審拒絶理由(2)の理由4において引用した引用文献1には、図面とともに、以下の記載がある(下線は、特に着目した箇所を示す。以下同様。)。

ア 段落【0005】
「【発明が解決しようとする課題】
【0005】
本発明は上述のような事情に鑑み為されたものであり、操作者の発する音声を認識・解析し、ナビゲーション用キャラクタによる対話型のコミュニケーションを可能とするとともに、タッチパネル入力を併用することにより、音声認識による対話型コミュニケーションを補完した統合的インタフェースを有する対話型コミュニケーション端末を提供し、デジタルデバイドの解消に寄与することを目的とする。」

イ 段落【0014】
「【0014】
図2は端末の内部の各部の相互関係を示す図である。音声入力部(マイク)101で入力されたユーザの音声は音声認識辞書106により音声認識エンジン107で認識される。
音声認識には、例えばワードスポッティング法が用いられる。ワードスポッティング法とは、話し言葉(入力音声)から必要な言葉(単語や音節)を拾いだしていく方式である。ワードスポッティング法は、発話を一字一句文字に置き換える方法ではなく、意味理解に必要なキーワードだけを抜き出して認識する手法である。
音声認識エンジン107によって認識された入力命令は統合インタフェース制御部111送られ、統合インタフェース制御部111が関連する各制御部(108?110、114?119)に命令を送り、命令が実行される。また、タッチパネル入力部102又は手書き入力部103から入力された命令も統合インタフェース制御部111送られ、同様の処理がなされる。
音声・画面表示出力は図1のモニタ104、スピーカ105に対応するものであり、入力された命令に応じて対話シナリオ制御部109で応答文が決定され、キャラクタ制御部108でキャラクタに発話させて音声とともに画面に表示する。
このようにユーザ側では音声入力を主として、それをタッチパネルと手書き入力で補完する形の統一された入力インタフェースでありながら、Webブラウザ制御、IP電話制御、電子メール等のメッセージ送受信をシームレスに制御することが可能となる。」

ウ 段落【0016】-【0019】
「【0016】
図4は統合インタフェース動的処理の概念及び統合インタフェース制御の処理フローを説明するための図である。
入力された命令に応じてどのインタフェースが必要なのかを識別する「統合的インタフェース識別」段階と、選択されたインタフェースに基づいて処理を行う「インタフェース動的処理」段階と、結果を出力する「出力」段階に大きく分けられる。
まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別される。何らかの理由で音声認識が不成功の場合は、キャラクタが再度の音声入力を求めるべく同じ質問を繰り返すとともに、タッチパネルに質問に対する回答が選択可能なように表示し、いずれかの手段をユーザが選択できるようにする。
図5は音声による動的処理操作の実施例を示す図である。すなわち、ユーザが音声入力してWebブラウザを操作する処理の流れを説明するための図である。
マイクから入力された音声(アナログ信号)はA/D変換部でデジタル信号に変換され、音響解析部において単語や音節として抽出され、照合処理部から認識辞書生成部に問い合わせがなされる。認識辞書生成部は問い合わせがあった単語等が基本命令辞書あるいは可変辞書にあるか否かを調べ、結果を照合処理部に返す。
【0017】
可変辞書は、実際には単なる文字列から成る一時的な辞書である。認識させたい単語(場合によっては短文)をコンマで区切りながら連結し、一つの文字列にする。これが可変辞書である。そして、これを引数として音声認識エンジンの特定の関数を呼び出すことで、認識語彙を音声認識エンジンの照合処理部に登録する。
認識辞書生成部は、コンテクストによって認識語彙を動的に生成・差し替える。コンテクストによって認識語彙を動的に生成・差し替えるとは、例えば、Webページの遷移が発生した場合を考えると、ここで実行される処理は以下のものとなる。図6のフローチャートを参照しつつ説明する。
(1)ページ遷移と同時に、現在登録してある語彙を音声認識エンジンから削除する(ステップS1)。
(2)新しいページのHTMLコードをオブジェクトとして解析し、リンクタグを抽出する。
(3)リンクタグ内の文字列(ユーザにリンク文字として表示されるもの)を抽出する(ステップS2)。これは半角英数漢字かな混じり文であることが多いので、これを全角カタカナに変換する(ステップS3)。
(4)全角カタカナに変換した文字列を、コンマを挟みながら連結する。こうして「可変辞書」を生成し(ステップS4)、音声認識エンジンに登録する(ステップS5)。(音声認識エンジンには、平仮名もしくは片仮名の文字列しか登録できない。)
(5)他方、リンク索引作成部は、それぞれのリンクタグオブジェクトへのポインタと、そのカナ変換した認識語彙とをペアとして記憶しておく。具体的には、タグへのポインタを値、対応するカナ文字列をキーとする連想配列を作る。この連想配列を「リンク索引」と呼ぶこととする。
(6)表示されたページ内のリンク文字列をユーザが選び、読み上げる。すなわち、音声入力を行う。音声認識エンジンはこれを解析し、登録されている語彙のいずれかを返す(全く認識できない場合は、エラー値を返すことになる。)。この認識結果をキーとして、先の「リンク索引」から該当するリンクタグを特定し、このリンクタグにおいてクリックイベントを発生させる。イベント発生後、このイベントを処理するのはWebブラウザである。Webブラウザは、そのリンクがクリックされたものとしてページを遷移させる。これ以降は、(1)から(6)までの繰り返しになる。
ちなみに、「HTMLコードをオブジェクトとして解析」とは、HTMLソースコードを文字列として解析するのではなく、DOMオブジェクトとして解析することである。また、「基本辞書」と「可変辞書」との違いであるが、前者は、コンテクストに関わらず変化しない辞書であり、このソフトのごく基本的な操作を音声で行うためのものである。
【0018】
音声操作機能における「命令実行部」の具体的な動作は、音声認識エンジンからの認識結果に基づく。これを図7のフローチャートに基づいて説明する。まず、音声認識が正常にできたことが前提となるが、音声認識ができなかった場合は、音声出力や画面表示を通じて、ユーザにその旨を知らせ、マイク音量の再設定を促す等の処理が行われる。その結果、音声認識が正常に行われた場合は、音声認識の結果を出力する(ステップS11)。具体的には、音声出力や画面表示を通じて、ユーザの操作命令を通知(反復)する。
認識された語彙を基本命令辞書から探しだす(ステップS12)。基本命令辞書に含まれている場合は、該当する処理を担当するモジュールを、適切なパラメータを設定しながら呼び出す(ステップS13)。例えば、手書き入力によってディスプレイに描画される線の色や太さを変更する、ディスプレイの輝度を変更する、等である。認識された語彙が基本命令辞書に含まれていない場合は、可変辞書から探す(ステップS14)。
認識された語彙が可変辞書に含まれていない場合は、操作失敗をユーザに伝える(ステップS15)。認識された語彙が可変辞書に含まれている場合であって、リンク文字が一つだけの場合は、「リンク索引」を使用して、Webページの遷移をおこす(ステップS16)。
含まれているリンクが複数ある場合は、該当するリンク文字のすべてを目立たせ、ユーザに音声による特定を促す(ステップS17)。
【0019】
図8は図4における出力段階のうちの、文字・画像出力制御の実施例を示す図である。
手書き入力装置から手書き入力によって文字や図形が入力されたときは、モニタの汎用表示領域(図9参照)のフォアグランド(前景)に描画する。また、Webブラウザが操作されたときは、汎用表示領域のバックグランド(背景)に描画する。従って、Webページの上に手書き入力装置によって文字、イラスト等を描くことも可能になる。
IP電話を利用する場合、Webカメラによる動画を使用しない場合は音声通話を行い、動画を使用する場合、汎用表示領域に描画データ(手書き文字、図形等)が既にある場合は、その描画データを保存して、動画表示パネルに自動的にきりかえ、動画を表示する。汎用表示領域に描画データが存在しない場合はすぐに表示パネルを切り換えて動画を表示する。表示パネルの切り換えは、汎用表示領域の上に動画用表示領域を重ねることによって行う。」

エ 段落【0020】-【0023】
「【0020】
図9は本発明に係るコミュニケーション端末のモニタに表示される初期画面の一例である。画面上部がコントロールパネルになっており、Webページ表示ボタン、IP電話機能起動ボタン、手書き入力機能のパラメータ設定(ペンの太さ、色等)ボタン等を含む。
また、その下の余白部分は汎用表示領域であり、Webページや手書き入力されたデータを表示する。
たとえば、手書きでメモを取る場合、音声入力で「メモ」と入力すると音声認識され(あるいはメニューの「メモを取る」をタッチペンでタッチしてもよい。)、統合インタフェース制御部が手書き入力制御部を起動し、ユーザが手書き入力装置から入力した文字、イラスト等をイメージとしてモニタの汎用表示領域に表示する。ここで、画面上部の「保存する」ボタンを押すと、サーバにあるユーザごとに確保された後述の「ユーザドキュメント格納手段」にあるメモ帳に保存される。なお、表示する手書き文字等の線の太さや色などを変える場合は、画面上部のコントロールパネルを操作して変更する。
【0021】
この後、図9の画面の左側の「メモの一覧」をタッチすると、図10のような「メモ一覧」が表示され、今までに作成したメモが一覧表示される。これは「ユーザドキュメント格納手段」に格納されている。ここで、メモのどれかを友達に送ったり、ブログに貼り付けたりする場合は、「誰かに送る」あるいは「ブログに貼り付ける」をペンでタッチすればよい。
また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの?」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力すると、入力された相手の名前がすでにシステムに登録されていれば、その人のアドレスを呼び出し、画面に表示する。ユーザは表示された画面を確認して間違いがなければ、「送る」と音声入力することによって送信が実行される。これは電話をかける場合も同様である。
【0022】
図11は「メールボックス」を選択した場合に表示される画面の一例を示すものであり、受信メールの一覧が表示されている。図12は「アドレス一覧」を選択した場合の表示画面の一例を示すものであり、各個人ごとのメールアドレス、電話番号、ブログのURL等が後述の「ユーザ別相手先管理206」に格納されている。
【0023】
図13は端末100とインターネット300を介して接続されたサーバ200の構成を示す図である。端末100は常にサーバ200とインターネット300を介して接続された状態で使用される。各ユーザの相手先の氏名、電話番号、メールアドレス等の情報や、メールボックス、作成したメモなどの情報は端末内部ではなく、それぞれサーバ200内にユーザごとに設けられた「ユーザ別相手先管理206」、「ユーザドキュメント格納手段」に格納されているので、端末100自体には大きな記憶容量は必要としない。
サーバ200には、ユーザの端末100から送られた要求を解析する要求解析部201、アクセスした端末の認証をユーザ情報202に基づいて行う認証・セッション管理部203、ユーザ情報に基づいてユーザ個人のホームページを生成し保存したり、ユーザの個人情報を管理するユーザ管理手段204と、端末情報に基づいて端末100の管理用ホームページを生成し保存する端末管理手段205と、各ユーザの相手先の氏名、電話番号、メールアドレス等の情報を格納するユーザ別相手先管理206を備えている。その他、図示したような各種サービスの提供のためのデータが格納されている。」

(2) 引用発明
よって、引用文献1には、次の発明(以下、「引用発明」という。)が開示されているものと認められる。

「タッチパネル入力を併用することにより、音声認識による対話型コミュニケーションを補完した統合的インタフェースを有する対話型コミュニケーション端末において、
音声入力部(マイク)101で入力されたユーザの音声は音声認識辞書106により音声認識エンジン107で認識され、
音声認識エンジン107によって認識された入力命令は統合インタフェース制御部111送られ、統合インタフェース制御部111が関連する各制御部(108?110、114?119)に命令を送り、命令が実行され、また、タッチパネル入力部102又は手書き入力部103から入力された命令も統合インタフェース制御部111送られ、同様の処理がなされ、
入力された命令に応じて対話シナリオ制御部109で応答文が決定され、キャラクタ制御部108でキャラクタに発話させて音声とともに画面に表示する、
音声入力を主として、それをタッチパネルと手書き入力で補完する形の統一された入力インタフェースであり、Webブラウザ制御、IP電話制御、電子メール等のメッセージ送受信をシームレスに制御することが可能となる統合的インタフェースであって、
統合的インタフェース制御の処理は、
まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別され、
何らかの理由で音声認識が不成功の場合は、キャラクタが再度の音声入力を求めるべく同じ質問を繰り返すとともに、タッチパネルに質問に対する回答が選択可能なように表示し、いずれかの手段をユーザが選択でき、
たとえば、手書きでメモを取る場合、音声入力で「メモ」と入力すると音声認識され(あるいはメニューの「メモを取る」をタッチペンでタッチしてもよい。)、統合インタフェース制御部が手書き入力制御部を起動し、ユーザが手書き入力装置から入力した文字、イラスト等をイメージとしてモニタの汎用表示領域に表示し、
また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの?」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力すると、入力された相手の名前がすでにシステムに登録されていれば、その人のアドレスを呼び出し、画面に表示し、
端末100は常にサーバ200とインターネット300を介して接続された状態で使用され、各ユーザの相手先の氏名、電話番号、メールアドレス等の情報や、メールボックス、作成したメモなどの情報は端末内部ではなく、それぞれサーバ200内にユーザごとに設けられた「ユーザ別相手先管理206」、「ユーザドキュメント格納手段」に格納されている、
統合的インタフェース制御の処理方法。」

2 引用文献2、引用文献3
(1) 引用文献2
当審拒絶理由(2)の理由4において引用した引用文献2には、図面とともに、以下の記載がある。

ア 段落【0002】(【背景技術】欄)
「ユーザ入力装置およびインターフェースは、コンピューティング装置についての新たなタイプの要求を満たすように急速に発展している。最近では、タブレット・ベースのパソコンおよびハンドヘルド・コンピュータが普及しつつある。これらの装置は典型的に、その面上のスタイラスの動きを電子インクに変換する書き込み面を有する。このインクは、認識してテキストに変換するか、または電子インク・フォーマットに格納することができる。」

イ 段落【0026】
「上述のように、ユーザのスタイラス204は、タイムアウトになるまでの期間ホバリングしてもよいし、またはユーザが呼出しターゲット403を選択してもよい。ユーザは、呼出しターゲット403を、表示された呼出しターゲット403をスタイラス204で叩くなど、様々な方法のいずれを選択してもよい。ステップ304に示したアクションのいずれかが発生すると、これに応答してステップ306において入力パネルがユーザに提示される。入力パネルは、スタイラス204からの電子インク入力、キーボードからのタイプ書き込みみ入力、および/またはその他の入力など、ユーザ入力を受けることができる。」

(2) 引用文献3
当審拒絶理由(2)の理由4において引用した引用文献3には、図面とともに、段落【0018】-【0022】に、以下の記載がある。

「【0017】図2は第1の実施形態による音声データ送信の手順を示すフローチャートである。以下、図2のフローチャートを参照して第1の実施形態による音声データ出力の手順を説明する。
【0018】】いま、音声による通信を行っているときに、座標入力部503より手書き文字入力が行われたとする(ステップS101,S102)。ここで、一文字の入力が終了すると、該文字について文字認識を行う(ステップS103)。文字認識処理技術に関しては既知の技術を適用できるので、ここでは説明を省略する。また、一文字の検出方法については文字枠を設ける方法やストロークの入力時間間隔に基づいて区切る方法などが知られている。文字認識の結果得られた認識データはRAM513へ蓄積される。

・・・(中略)・・・

【0021】次に、認識データと大きさのデータをデータ変換部201へ送り、上記認識された文章を音声データへ変換する(ステップS106)。このとき、上記文章の大きさに比例して音声の大きさを設定する。尚、変換された音声データはこの時点でデジタル音声データとなっており、そのまま通信制御部506へ送られる。すなわち、データ変換部201は、認識された文字列に基づいて、通信制御部506で処理可能なデータ形式を有する音声データ、例えば音声符号化部502で生成されるデータと同じ形態の音声データを生成する。そして、該音声データを通信制御部506へ送り、送信部507を経て送信する(ステップS107)。尚、音声入力に基づく符号化音声データと文字入力に基づく音声データ(符号化音声データ)の送信切替は、通信制御部506が行う。
【0022】以上、説明したように第1の実施形態によれば、手書き入力した文字によって音声送信を行えるので、周囲の状況に関わらず、音声による送信を実行できるようになる。また、上記実施形態では、音声通信中において手書き入力された文字を音声として送信できるので、たとえば、他人に聞かれたくない部分のみをペン入力により送信することも可能である。さらに、手書き入力された文字の大きさに基づいて音量を調整できるので、入力ペンにより直感的な音量の操作が可能となる。」

(3) 周知技術1
上記(1)引用文献2のイの記載から、一般に、ユーザの要請によって、手書き入力モードを開始することは、周知技術(以下、「周知技術1」と呼ぶ。)であると認められる。

(4) 周知技術2
上記(1)引用文献2のア、(2)引用文献3の記載から、一般に、手書き入力データを文字認識した結果を、テキストや音声など別の所定のフォーマットに変換することは、周知技術(以下、「周知技術2」と呼ぶ。)であると認められる。

2.対比・判断
(1) 本願発明1について

本願請求項1に係る発明(以下、「本願発明1」という。)と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「統合的インタフェース制御の処理方法」は、対話型コミュニケーション端末のユーザに対して、「タッチパネル入力を併用することにより、音声認識による対話型コミュニケーションを補完した統合的インタフェース」を提供する方法であるから、本願発明1の「携帯端末のユーザインターフェース提供方法」と、「端末のユーザインターフェース提供方法」である点で共通するといえる。

イ 引用発明において、「また、音声入力で「メール」と入力すると、キャラクタが反応して「誰に送るの?」と聞いてくるように設定されているので、ここで送りたい相手の名前を音声入力する」ことは、本願発明1において、「音声認識アプリケーションの音声入力受信のための第1の画面を表示するステップ」に相当する。

ウ 引用発明において、「たとえば、手書きでメモを取る場合、音声入力で「メモ」と入力すると音声認識され(あるいはメニューの「メモを取る」をタッチペンでタッチしてもよい。)、統合インタフェース制御部が手書き入力制御部を起動し、ユーザが手書き入力装置から入力した文字、イラスト等をイメージとしてモニタの汎用表示領域に表示し」ていることは、本願発明1において、「ユーザのモード転換要請によって、前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第1の画面の一部に表示するステップと、前記筆記入力モードで前記領域を通して入力された筆記データを前記領域に表示するステップと、前記領域を通して入力された筆記データを認識するステップと」を含むことと、「ユーザのモード転換要請によって、前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第1の画面の一部に表示するステップと、前記筆記入力モードで前記領域を通して入力された筆記データを前記領域に表示するステップと」を含む点で共通するといえる。

エ 引用発明において、「まず、ユーザの入力した音声に基づいて音声認識が行われ、認識が成功すると、命令が識別され、何らかの理由で音声認識が不成功の場合は、キャラクタが再度の音声入力を求めるべく同じ質問を繰り返すとともに、タッチパネルに質問に対する回答が選択可能なように表示し、いずれかの手段をユーザが選択でき」ることは、質問に回答するための「いずれかの手段」として「再度の音声入力」を選択した場合には、本願発明1において、「前記ユーザによる追加の音声データを受信するステップと、前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得するステップと、ここで、前記組み合わせデータは、テキストデータまたは音声データのうちの少なくとも一つであり、前記組み合わせされたデータを前記入力された筆記データの代わりに前記第1の画面に表示するステップと」を含むことと、「前記ユーザによる追加の音声データを受信するステップと、前記追加の音声データを獲得するステップと、ここで、前記データは、テキストデータまたは音声データのうちの少なくとも一つであ」ることを含む点で共通するといえる。

オ 「タッチパネル入力部102」を備える、引用発明の「対話型コミュニケーション端末」において、メールを送る場合に、「ここで送りたい相手の名前を音声入力すると、入力された相手の名前がすでにシステムに登録されていれば、その人のアドレスを呼び出し、画面に表示し、端末100は常にサーバ200とインターネット300を介して接続された状態で使用され、各ユーザの相手先の氏名、電話番号、メールアドレス等の情報や、メールボックス、作成したメモなどの情報は端末内部ではなく、それぞれサーバ200内にユーザごとに設けられた「ユーザ別相手先管理206」、「ユーザドキュメント格納手段」に格納されている」ことは、本願発明1において、「前記音声認識アプリケーションにより前記組み合わせされたデータを検索語としてサーバに送信するステップと、前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、前記音声認識アプリケーションの前記第1の画面に、前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に前記検索結果を表示するステップ」を含むことと、「前記音声認識アプリケーションにより前記データを検索語としてサーバに送信するステップと、前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、前記音声認識アプリケーションの前記第1の画面に、前記検索結果を表示するステップ」を備える点で共通するといえる。

よって、本願発明1と引用発明との一致点・相違点は次のとおりであるといえる。

[一致点]
「端末のユーザインターフェース提供方法であって、
音声認識アプリケーションの音声入力受信のための第1の画面を表示するステップと、
ユーザのモード転換要請によって、前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第1の画面の一部に表示するステップと、
前記筆記入力モードで前記領域を通して入力された筆記データを前記領域に表示するステップと
前記ユーザによる追加の音声データを受信するステップと、
前記追加の音声データを獲得するステップと、ここで、前記データは、テキストデータまたは音声データのうちの少なくとも一つであり、
前記音声認識アプリケーションにより前記データを検索語としてサーバに送信するステップと、
前記音声認識アプリケーションにより前記サーバから前記検索語に対する検索結果を受信するステップと、
前記音声認識アプリケーションの前記第1の画面に、前記検索結果を表示するステップと、を含むことを特徴とする、端末のユーザインターフェース提供方法。」

[相違点1]
本願発明1は、「携帯端末」のユーザインターフェース提供方法に係るのに対して、引用発明の「対話型コミュニケーション端末」は、「携帯端末」であることが特定されていない点。

[相違点2]
筆記入力がされた時に、本願発明1では、さらに、「前記領域を通して入力された筆記データを認識するステップ」を備えるのに対して、引用発明では、筆記入力の認識について特定されていない点。

[相違点3]
追加の音声データが入力された時に、本願発明1では、さらに、「前記追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得するステップと、ここで、前記組み合わせデータは、テキストデータまたは音声データのうちの少なくとも一つであり、前記組み合わせされたデータを前記入力された筆記データの代わりに前記第1の画面に表示するステップと」を含むのに対して、引用発明では、「再度の音声入力」時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得するステップ」、及び、「組み合わされたデータを前記入力された筆記データの代わりに前記第1の画面に表示するステップ」を含むことが特定されていない点。

[相違点4]
検索結果を表示する時に、本願発明1では、「前記音声認識アプリケーションの前記第1の画面に、前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に前記検索結果を表示するステップ」を備えるのに対して、引用発明では、「前記組み合わせされたデータに対応する予め設定されたフォーマットのテキストデータと共に」検索結果を表示することが特定されていない点。

3.当審の判断
事案に鑑みて、上記[相違点3]について先に検討すると、本願発明1の上記[相違点3]に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」ことについては、上記引用文献1-3には記載されておらず、本願優先日前において周知技術であるともいえない。
よって、当業者といえども、引用発明及び引用文献2-3に記載された技術的事項から、本願発明1の上記[相違点3]に係る構成を容易に想到することはできない。
したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用発明及び引用文献2-3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

(2) 請求項2-14について
本願発明2-14も、本願発明1の上記[相違点3]に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」ことと、同一の構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明、引用文献2-3に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

第6 当審拒絶理由(2)の理由1-3について
令和3年3月8日付けの補正により、補正後の請求項1-14は、「前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための第2の画面を表示する」に替えて、「前記第1の画面が表示された少なくとも一部の間、筆記入力モードのための領域を、第1の画面の一部に表示するステップ」という技術的事項を有するものとなった。したがって、請求項1の「第1の画面」と「第2の画面」とを構成として有する発明は、発明の詳細な説明に記載したものではないことに基づく、当審拒絶理由(2)の理由1-3は解消した。

第7 当審拒絶理由(1)について
令和3年3月8日付けの補正により、補正後の請求項1-14は、本願発明1の上記[相違点3]に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」という技術的事項を有するものとなった。当該技術的事項は、当審拒絶理由(1)における引用文献1-3には記載されておらず、本願優先日前における周知技術でもないので、本願発明1-14は、当業者であっても、当審拒絶理由(1)における引用文献1-3に基づいて容易に発明をすることができたものではない。したがって、この拒絶の理由は解消した。

第8 原査定についての判断
令和3年3月8日付けの補正により、補正後の請求項1-14は、本願発明1の上記[相違点3]に係る、追加の音声データが入力された時に、「追加の音声データが前記筆記データの入力後、設定された時間内に入力された場合は、前記認識された筆記データ及び前記追加の音声データを組み合わせして組み合わせデータを獲得する」という技術的事項を有するものとなった。当該技術的事項は、原査定における引用文献A-Dには記載されておらず、本願優先日前における周知技術でもないので、本願発明1-14は、当業者であっても、原査定における引用文献A-Dに基づいて容易に発明をすることができたものではない。したがって、原査定を維持することはできない。

第9 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。

 
審決日 2021-04-13 
出願番号 特願2013-175317(P2013-175317)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
P 1 8・ 55- WY (G06F)
最終処分 成立  
前審関与審査官 酒井 優一  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 太田 龍一
稲葉 和生
発明の名称 ユーザインターフェース提供方法、機械可読保存媒体及び携帯端末  
代理人 木内 敬二  
代理人 実広 信哉  
代理人 崔 允辰  
代理人 阿部 達彦  
  • この表をプリントする

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