ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F |
---|---|
管理番号 | 1377081 |
審判番号 | 不服2020-4516 |
総通号数 | 262 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2021-10-29 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2020-04-03 |
確定日 | 2021-08-31 |
事件の表示 | 特願2017-523991「ユーザー端末装置のHTMLページでローカルキーボードを呼び出すための方法及びその装置」拒絶査定不服審判事件〔平成28年 5月12日国際公開、WO2016/070753、平成29年11月24日国内公表、特表2017-534991、請求項の数(13)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は、2015年(平成27年)10月30日(パリ条約による優先権主張外国庁受理 2014年11月7日 中国)を国際出願日とする出願であって、その手続の経緯は次のとおりである。 平成31年 2月26日付け:拒絶理由通知 令和 元年 6月12日 :意見書、手続補正書の提出 令和 元年11月25日付け:拒絶査定(原査定) 令和 2年 4月 3日 :審判請求書、手続補正書の提出 令和 3年 4月14日付け:拒絶理由(当審拒絶理由)通知 令和 3年 6月22日 :意見書、手続補正書の提出 第2 本願発明 本願請求項1ないし13に係る発明(以下、それぞれ「本願発明1」ないし「本願発明13」という。)は、令和3年6月22付けの手続補正(以下、「本件補正」という。)で補正された特許請求の範囲の請求項1ないし13に記載された事項により特定される発明であり、このうち本願発明1は以下のとおりの発明である。 「 ユーザー端末装置のHTMLページでローカルキーボードを呼び出すための方法であって、 ユーザー端末装置がHTMLページをロードするとき前記HTMLページを解析するステップと、 前記HTMLページの認識識別子を有するページ入力フィールドを、前記ページ入力フィールドの同じ場所にローカル入力フィールドを生成することによってカバーするステップであって、前記認識識別子は、前記ページ入力フィールドがローカルキーボードを呼び出す必要があることを示す、ステップと、 前記ローカル入力フィールドによって呼び出される前記ローカルキーボードのタイプを設定するステップであって、 前記ローカルキーボードのタイプは、前記ページ入力フィールドのキーボードタイプの識別子に基づいている、ステップと、 前記ローカルキーボードを介して前記ローカル入力フィールドによって受信される入力情報を前記HTMLページに送信するステップと、 を含む、前記方法。」 なお、本願発明2ないし7は、本願発明1を減縮した発明であり、本願発明8ないし13のそれぞれは、本願発明1ないし6のそれぞれを装置の発明として特定したものであり、本願発明1ないし6とはカテゴリ表現が異なるだけの発明である。 第3 原査定の概要 原査定(令和元年11月25日付け拒絶査定)の概要は次のとおりである。 本願請求項1ないし13に係る発明は、以下の引用文献1ないし3に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 [引用文献等一覧] 1 中国特許出願公開第103902057号明細書 2 Mark Pilgrim,入門HTML5, 株式会社オライリー・ジャパン,2011年 4月21日, 第1版,p.169-187(周知技術を示す文献) 3 特開2011-254358号公報 第4 当審拒絶理由の概要 当審拒絶理由の概要は次のとおりである。 本願請求項1ないし13に係る発明は、以下の点において発明の詳細な説明に記載したものではないから、特許法第36条第6項第1号に規定する要件を満たしていない。 (1)請求項1に記載の「複数の認識識別子を有する第一の入力フィールド」、請求項8に記載の「第一の入力フィールドが複数の認識識別子を有する」は、発明の詳細な説明には記載されていない。 (2)請求項1及び8に記載の「前記認識識別子は、さらにローカルキーボードのタイプを含む」は、発明の詳細な説明に記載したものではない。 第5 原査定についての判断 1 引用文献1について (1)引用文献1記載事項 原査定で引用された引用文献1には、図面とともに次の事項が記載されている。 [当審訳] 「[0001] 本発明は入力法技術分野に関し、具体的には移動端末装置においてウェブページ入力を行う方法及び装置に関する。」 [当審訳] 「[0061] 図1に示すとおり、本発明の実施例が提供する移動端末装置においてウェブページ入力を行う方法のフローチャートを示し、図1に示すとおり、該方法は以下のステップを含むことができる。 [0062] Sl10:ユーザが移動端末装置においてウェブページ入力を行う時、サードパーティキーボードビューオーバーレイシステムを使用してキーボードビューを予め設定する; [0063] 移動端末装置におけるオペレーティングシステム又はいくつかのアプリケーションの密閉性に起因して、移動端末装置のいくつかのアプリケーションにおいて入力する場合、サードパーティ入力方法を直接呼び出すことができない。例えば移動端末装置のブラウザアプリケーションにおいて、ユーザがウェブページ入力を行う時、オペレーティングシステムはサードパーティ入力法を呼び出すことができず、システム内の入力法のみを呼び出し、従ってシステムはサードパーティキーボードビューをポップアップせず、システムのプリセットキーボードビューのみをポップアップする。サードパーティ入力法を用いてウェブページ入力を行う場合、移動端末装置において入力を行うプロセスに対して特殊な処理を行う必要がある。本発明の実施例が提供する方法において、ユーザが移動端末装置を使用してウェブページを入力する時、まずサードパーティのキーボードビューを利用し、システムの予め設定されたキーボードビューをカバーすることができる。 [0064] 移動端末装置に搭載されたオペレーティングシステムにおいて、通常少なくとも1つの入力法が予めインストールされ、このような予めインストールされた入力法はシステムに内蔵された入力法であってもよく、システムに内蔵された入力法は移動端末装置におけるほとんど全てのアプリケーションにおいて呼び出すことができる。移動端末装置は一般的に物理キーボード装置に外付けされず、タッチスクリーン等の表示装置に仮想キーボードをシミュレートして提供し、移動端末装置に入力機能を使用する時、スクリーンに仮想キーボードのビューを表示し、システム内の入力法はシステムが予め設定したキーボードビューに対応する。サードパーティ入力法は一般的にそれに対応するものを呼び出し、システムがキーボードビューをプリセットするサードパーティキーボードビューとは異なる。サードパーティ入力を使用してウェブページ入力を行う時、サードパーティキーボードビュー置換システムを使用してキーボードビューを予め設定することができ、ユーザはサードパーティキーボードビューを操作することによってウェブページ入力を行うことができる。 [0065] ブラウザを用いてウェブページを閲覧する時、入力機能をトリガーしなければ、キーボードビューを表示せず、それによりユーザはより多くのスクリーン空間閲覧情報を使用することができる。入力機能を使用するとき、キーボードビューは、リアルタイムでポップアップされ、表示される。具体的にはサードパーティキーボードビューオーバーレイシステムを使用してキーボードビューを予め設定する時、まずユーザのモバイル機器のウェブページにおける入力トリガを監視することができ、例えばユーザがウェブページの入力ボックスにおいてクリックする時、通常キーボードポップアップのシステム通知をトリガし、キーボードポップアップのシステム通知を監視することができ、キーボードポップアップの通知を監視することにより、ユーザが入力を開始することを知る。同様の入力トリガ動作が発生したことが監視されると、サードパーティキーボードビューオーバーレイシステムを使用してキーボードビューが事前設定される。また、具体的にサードパーティのキーボードビューを使用してシステムのプリセットキーボードビューをカバーする時、移動端末装置におけるプログラムビューをトラバースすることができ、移動端末装置のすべてのプログラムビューにおいてシステムのプリセットキーボードビューを決定し、且つシステムのプリセットキーボードビューを非表示に設定する。具体的には、再帰関数によって移動端末装置におけるプログラムビューをトラバースし、且つ各ビューのタイプ又は属性情報に基づいてそのうちのシステムプリセットキーボードビューを決定することができる。さらに、サードパーティ入力法のサードパーティ入力法ソフトウェア開発ツールキットSDKによってサードパーティキーボードビューを開き、且つ該サードパーティキーボードビューをシステムプリセットキーボードビューの上層に配置し、この時ユーザはサードパーティのキーボードビューのみを見て、それによりサードパーティキーボードビューでシステムプリセットキーボードビューをカバーする。 [0066] このプロセスにおいて、サードパーティのキーボードビューの表示位置は元のシステムのプリセットされたキーボードビューと一致することができ、又はシステムのプリセットされたキーボードビューの位置に基づいて取得することができる。具体的には、ウェブページ入力がトリガされたことを監視し、且つシステムのプリセットキーボードビューを決定すると同時に、システムのプリセットキーボードビューの座標をキャプチャし、それによりシステムのプリセットキーボードビューの座標にサードパーティキーボードビューを表示し、又はシステムのプリセットキーボードビューの座標を調整して計算した後、サードパーティキーボードビューの表示座標を生成し、更にサードパーティキーボードビューの表示位置を決定することができる。 [0067] S1320:移動端末装置において非表示の属性を有するシステム入力ボックスを作成し、且つ前記サードパーティキーボードビューを前記システム入力ボックスに関連付ける; [0068] 従来技術においてはウェブページを入力する時、透明なシステム入力ボックスを用いてウェブページ入力ボックスをカバーする。従来技術と異なり、本発明の実施例が提供する方法においては、サードパーティキーボードビューでシステムのプリセットキーボードビューをカバーした後、モバイル端末装置に非表示の属性を有するシステム入力ボックスを作成し、且つサードパーティキーボードビューを作成されたシステム入力ボックスに関連付け、キーボードビューが受信した入力文字を作成された非表示の属性のシステム入力ボックスに入力することができる。従来技術において透明なシステム入力ボックスを使用してウェブページ入力ボックスをカバーし、入力する過程において、ウェブページ入力ボックスの入力フォーカスは透明なシステム入力ボックスに強制的に変換され、入力が完了した後、入力フォーカスはウェブページ入力ボックスに移行し、このようにサードパーティ入力法キーボードビューのフラッシュ問題を引き起こし、ユーザの入力に影響を与える。従来技術に比べて、本発明の実施例が提供する方法では非表示の属性を有するシステム入力ボックスを作成し、該非表示の属性の入力ボックスをユーザが文字を入力するための容器とし、ウェブページ入力ボックスの焦点を奪わず、焦点を変えずに切り替えるという問題がなく、それにより入力法のキーボードビューが再びポップアップしてキーボードビューがフラッシュするという問題を回避する。 [0069] S1330:ユーザが前記サードパーティキーボードビューによって入力した文字を受信し、サードパーティ入力法ソフトウェア開発ツールキットによって受信したユーザ入力文字を処理し、且つ処理後に得られたターゲット文字を前記システム入力ボックスに入力する; [0070] 携帯端末装置に非表示の属性を有するシステム入力ボックスを作成し、且つサードパーティキーボードビューに関連付けた後、該非表示の属性を有するシステム入力ボックスを利用して、ユーザの入力を受信し且つ記録することができる。このようにユーザがサードパーティキーボードビューによって入力した文字を受信し、サードパーティ入力法ソフトウェア開発ツールキットSDK処理によって受信したユーザ入力文字を処理し、処理によって取得したターゲット文字を該非表示の属性を有するシステム入力ボックスに入力することができる。サードパーティSDK処理によって受信されたユーザ入力文字は、受信されたユーザ入力文字をターゲット言語のターゲット文字に変換するプロセスであってもよく、例えば使用されるサードパーティ入力法がピンイン入力法であり、ターゲット言語が中国語である場合、サードパーティSDKによってユーザが入力した文字を中国語言語に対応する漢字に変換することができる。サードパーティSDKによってユーザのキーを識別し、キーに対応するユーザ入力文字を受信し、且つそれを対応する文字入力結果、即ちターゲット文字に変換し、更にターゲット文字をサードパーティキーボードビューに関連付けたいシステム入力ボックスに入力する。 [0071] S1140:ウェブページのフォーカス入力ボックスを取得し、且つ前記システム入力ボックスにおける前記ターゲット文字を、前記ウェブページのフォーカス入力ボックスに注入する。 [0072] 上記非表示の属性を有するシステム入力ボックスにおいてターゲット文字を受信した後、該システム入力ボックスによってユーザ入力を取得し、さらにシステム入力ボックスにおけるターゲット文字をウェブページに対応するウェブページフォーカス入力ボックスに注入することに相当する。具体的には、予め設定されたスクリプトコードを利用してウェブページのフォーカス入力ボックスを取得し、且つスクリプトコードによってシステム入力ボックスにおけるターゲット文字を、ウェブページのフォーカス入力ボックスに注入することができる。使用されるスクリプトコードは、端末モバイル機器がサポートする言語で作成されたスクリプトコードであってもよく、例えばアップル社のiOSオペレーティングシステムにおいてjavascriptスクリプトコードをサポートすることができる。」 (2)引用発明 前記(1)より、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。 「 移動端末装置においてウェブページ入力を行う方法であって、 該方法は以下のステップを含む。 ユーザが移動端末装置においてウェブページ入力を行う時、サードパーティキーボードビューオーバーレイシステムを使用してキーボードビューを予め設定するステップであって、 具体的にはサードパーティキーボードビューオーバーレイシステムを使用してキーボードビューを予め設定する時、まずユーザのモバイル機器のウェブページにおける入力トリガを監視することができ、例えばユーザがウェブページの入力ボックスにおいてクリックする時、通常キーボードポップアップのシステム通知をトリガし、キーボードポップアップのシステム通知を監視することができ、キーボードポップアップの通知を監視することにより、ユーザが入力を開始することを知り、入力トリガ動作が発生したことが監視されると、サードパーティキーボードビューオーバーレイシステムを使用してキーボードビューが事前設定され、このプロセスにおいて、サードパーティのキーボードビューの表示位置は元のシステムのプリセットされたキーボードビューと一致することができるステップ、 移動端末装置において非表示の属性を有するシステム入力ボックスを作成し、且つ前記サードパーティキーボードビューを前記システム入力ボックスに関連付けるステップ、 ユーザが前記サードパーティキーボードビューによって入力した文字を受信し、サードパーティ入力法ソフトウェア開発ツールキットによって受信したユーザ入力文字を処理し、且つ処理後に得られたターゲット文字を前記システム入力ボックスに入力するステップ、 ウェブページのフォーカス入力ボックスを取得し、且つ前記システム入力ボックスにおける前記ターゲット文字を、前記ウェブページのフォーカス入力ボックスに注入するステップ。」 2 引用文献2について 原査定の引用文献2には、図面とともに次の事項が記載されている。 (第174ページ?第175ページ) 「 しかし、HTML5では新しいフィールド形式がいくつか定義されており、理由はこの後すぐ説明するが、今すぐ使い始めることができる。 新しい入力形式のひとつが、メールアドレスだ。以下のように指定する。 …(中略)… iPhoneは、物理的なキーボードを持たない。すべての入力は、必要に応じて(例えばWebページのフォームフィールドにフォーカスがある場合に)ポップアップするオンスクリーンキーボードをタップすることによって行われる。Appleは、非常に賢い機能をiPhoneのWebブラウザに実装した。いくつかの新しいHTML5入力方式を認識し、そして入力の種類に応じて動的にスクリーンキーボードを変更するという機能だ。例えば、電子メールはテキストだが、特別な種類のテキストだ。つまり、実質的にすべての電子メールアドレスは@マークと少なくとも1個のピリオド(.)を含むが、スペースが含まれることはまずない。したがって、iPhoneユーザが要素にフォーカスすると、図9-3に示すように通常よりも小さなスペースバーと@および、専用のキーを持つオンスクリーンキーボードが表示される。」 「図9-3 電子メールアドレスの入力に適したキーボード 」 したがって、上記引用文献2には、以下の技術的事項(以下、「引用文献2記載事項」という。)が記載されていると認められる。 「 HTML5では新しいフィールド形式がいくつか定義されており、 iPhoneは、物理的なキーボードを持たず、すべての入力は、必要に応じて(例えばWebページのフォームフィールドにフォーカスがある場合に)ポップアップするオンスクリーンキーボードをタップすることによって行われ、 Appleは、非常に賢い機能として、いくつかの新しいHTML5入力方式を認識し、そして入力の種類に応じて動的にスクリーンキーボードを変更するという機能をiPhoneのWebブラウザに実装し、例えば、iPhoneユーザが要素にフォーカスすると、通常よりも小さなスペースバーと@および、専用のキーを持つオンスクリーンキーボードが表示されること。」 3 引用文献3について 原査定の引用文献3には、図面とともに次の事項が記載されている。 「【0072】 一方、制御部102は、タッチパネル114に表示された画面領域に含まれるテキスト入力域とキーボード画面表示(予定)位置とが重なると判定した場合(ステップSC-3:Yes)、テキスト入力域とキーボード画面表示(予定)位置とが重ならない方向および画面移動量を計算する(ステップSC-4)。 【0073】 そして、キーボード表示部102bは、ステップSC-4にて計算した方向および画面移動量に合わせてテキスト入力域を含む画面領域の一部をタッチパネル114の上端側に移動表示させる(ステップSC-5)。」 「【0080】 図10に戻り、テキスト入力域更新部102cは、ステップSC-6にてタッチパネル114を介してキーボード画面を用いて文字列が入力された場合、文字列入力イベントの完了を検知し(ステップSC-7)、テキスト入力域の表示を当該文字列に更新する。 【0081】 そして、制御部102は、キーボード画面の表示を消去する(ステップSC-8)。 【0082】 そして、制御部102は、タッチパネル114に表示された画面領域に含まれるテキスト入力域とキーボード画面表示位置とが重なっていたか否かを判定する(ステップSC-9)。 【0083】 そして、制御部102は、ステップSC-9にて画面領域に含まれるテキスト入力域とキーボード画面表示位置とが重なっていなかったと判定した場合(ステップSC-9:No)、処理を終了する。 【0084】 一方、画面表示部102aは、ステップSC-9にて画面領域に含まれるテキスト入力域とキーボード画面表示位置とが重なっていたと判定した場合(ステップSC-9:Yes)、保持していた画面移動量(例えば、ステップSC-5にてキーボード表示部102bにより移動表示させられた画面移動量等)にあわせて画面領域を元の位置へ戻すようにタッチパネル114に移動表示させ(ステップSC-10)、処理を終了する。つまり、文字列入力後、キーボード画面を消すと共にドロアアイコンの表示も元の位置に移動させられる。」 したがって、上記引用文献3には、以下の技術的事項が記載されていると認められる。 「 タッチパネル114に表示された画面領域に含まれるテキスト入力域とキーボード画面表示(予定)位置とが重なると判定した場合、テキスト入力域とキーボード画面表示(予定)位置とが重ならない方向および画面移動量を計算し、計算した方向および画面移動量に合わせてテキスト入力域を含む画面領域の一部をタッチパネル114の上端側に移動表示させ、 タッチパネル114を介してキーボード画面を用いて文字列が入力された場合、画面領域に含まれるテキスト入力域とキーボード画面表示位置とが重なっていたと判定した場合、保持していた画面移動量にあわせて画面領域を元の位置へ戻すようにタッチパネル114に移動表示させること。」 4 本願発明1について (1)対比 本願発明1と引用発明とを対比する。 ア 引用発明は、「移動端末装置」において、「例えばユーザがウェブページの入力ボックスにおいてクリックする時」に通常生じる「キーボードポップアップの通知」を監視することにより「サードパーティキーボードビュー」を表示するものである。 ここで、引用発明の「移動端末装置」は、本願発明1の「ユーザー端末装置」に含まれ、また、引用発明の「サードパーティキーボードビュー」は、本願発明1の「ローカルキーボード」に相当し、また、「サードパーティキーボードビュー」を表示することは、本願発明1の「ローカルキーボード」を「呼び出す」ことに相当する。 また、引用発明は、「ウェブページ入力を行う方法」に関するものであり、「ウェブページ」は、通常「HTML」により記述されることは本願優先日前の技術常識であるから、本願発明1の「HTMLページ」に相当するといえるものの、引用発明は、前記「サードパーティキーボードビュー」が「ウェブページ」により呼び出されるものとは特定されていない。 よって、引用発明の「移動端末装置においてウェブページ入力を行う方法」と、本願発明1の「ユーザー端末装置のHTMLページでローカルキーボードを呼び出すための方法」とは、「ユーザー端末装置でローカルキーボードを呼び出すための方法」である点において共通する。 イ 引用発明は、「ユーザが移動端末装置においてウェブページ入力を行う時」を前提とするものであるため、「ウェブページ」(HTMLページ)が「移動端末装置」に表示される際に、「移動端末装置」は、「ウェブページ」をロードし、その記述内容を解析することは本願優先日前の技術常識であり、当該解析処理を「解析するステップ」と称することは任意である。 よって、引用発明は、本願発明1の「ユーザー端末装置がHTMLページをロードするとき前記HTMLページを解析するステップ」に対応する構成を備える。 ウ 引用発明の「ウェブページの入力ボックス」は、ウェブページに入力を行うための領域(フィールド)であるから、「ページ入力フィールド」といい得るものである。 また、前記アで述べたように、「ウェブページ」は、通常「HTML」により記述され、かつ、「HTML」においては、入力を行うための入力ボックス(入力フィールド)は、「input」のような「タグ」により記述されることは本願優先日前の技術常識であり、当該「タグ」は、「認識識別子」といい得るものである。 よって、引用発明の「ウェブページの入力ボックス」は、本願発明1の「前記HTMLページの認識識別子を有するページ入力フィールド」に相当する。 引用発明は、「前記サードパーティキーボードビューを前記システム入力ボックスに関連付けるステップ」との構成を備えることからすると、「前記システム入力ボックス」すなわち「非表示の属性を有するシステム入力ボックス」は、「サードパーティキーボードビュー」(ローカルキーボード)に関連付けられたものであるから、「ローカル入力フィールド」といい得るものである。 また、引用発明の「前記システム入力ボックス」に入力される「ターゲット文字」は、「ウェブページのフォーカス入力ボックス」(「ウェブページの入力ボックス」の中でフォーカスがされているもの。)に注入されるから、「非表示の属性を有するシステム入力ボックス」は、「ウェブページの入力ボックス」に応じて生成されるものといえる。 もっとも、引用発明の「非表示の属性を有するシステム入力ボックス」は、「非表示」であるから、前記「ウェブページの入力ボックス」を「カバー」するものではない。 また、引用発明において想定されるHTMLの「タグ」(認証識別子)は、「サードパーティキーボードビュー」(ローカルキーボード)を呼び出す必要があることを示すものではない。 さらに、本願発明1の「ローカル入力フィールド」は、「ページ入力フィールド」と同じ場所に生成される(カバーする)ものであるから、「ページ入力フィールド」に応じて生成されているといえる。 以上より、引用発明と、本願発明1の「前記HTMLページの認識識別子を有するページ入力フィールドを、前記ページ入力フィールドの同じ場所にローカル入力フィールドを生成することによってカバーするステップであって、前記認識識別子は、前記ページ入力フィールドがローカルキーボードを呼び出す必要があることを示す、ステップ」とは、「前記HTMLページの認識識別子を有するページ入力フィールドに応じてローカル入力フィールドを生成するステップ」との構成を備える点において共通する。 エ 引用発明において、「ユーザが前記サードパーティキーボードビューによって入力した文字を受信し、サードパーティ入力法ソフトウェア開発ツールキットによって受信したユーザ入力文字を処理し、且つ処理後に得られたターゲット文字を前記システム入力ボックスに入力するステップ」及び「ウェブページのフォーカス入力ボックスを取得し、且つ前記システム入力ボックスにおける前記ターゲット文字を、前記ウェブページのフォーカス入力ボックスに注入するステップ」は、本願発明1の「前記ローカルキーボードを介して前記ローカル入力フィールドによって受信される入力情報を前記HTMLページに送信するステップ」に相当する。 (2)一致点、相違点 前記(1)より、本願発明1と引用発明は、次の点において一致ないし相違する。 [一致点] 「 ユーザー端末装置でローカルキーボードを呼び出すための方法であって、 ユーザー端末装置がHTMLページをロードするとき前記HTMLページを解析するステップと、 前記HTMLページの認識識別子を有するページ入力フィールドに応じてローカル入力フィールドを生成するステップと、 前記ローカルキーボードを介して前記ローカル入力フィールドによって受信される入力情報を前記HTMLページに送信するステップと、 を含む、前記方法。」 [相違点] <相違点1> 本願発明1は、「HTMLページでローカルキーボードを呼び出す」という構成を備えるのに対し、引用発明は、「ウェブページの入力ボックス」に対する「入力トリガ」(クリック)を監視することにより、「サードパーティキーボードビュー」を呼び出す点。 <相違点2> 本願発明1は、「ページ入力フィールド」が有する「認識識別子」が「前記ページ入力フィールドがローカルキーボードを呼び出す必要があることを示す」ものであり、「ページ入力フィールド」の「キーボードタイプの識別子」に基づいて、呼び出される「ローカルキーボード」の「タイプ」を設定するステップを備えるのに対し、引用発明は、このような構成を備えない点。 <相違点3> 本願発明1の「ローカル入力フィールド」は、「ページ入力フィールド」の同じ場所に生成され、当該「ページ入力フィールド」を「カバー」するのに対し、引用発明の「システム入力ボックス」は「非表示の属性」を有するため、このような構成を備えていない点。 (3)相違点についての判断 事案に鑑みて先に上記相違点2及び相違点3について検討する。 ア 相違点2について 引用文献2記載事項にあるように、iPhoneが、といったHTML5の記述を含むフォームフィールドにフォーカスがあるときに、「type」によって指定される入力の種類("email")に応じて動的にスクリーンキーボードを変更する(呼び出す)機能を備えることは、本願優先日前の周知技術といえる。 しかしながら、上記の機能は、iPhoneを製造・販売するApple社が「非常に賢い機能」として提供するもの、すなわちiPhoneのシステムに備えられた機能であるから、引用文献2記載事項の「スクリーンキーボード」は、相違点2に係る本願発明1の「ローカルキーボード」に相当するものではない。 よって、引用文献2記載事項は、相違点2に係る本願発明1の構成を開示するものではない。 イ 相違点3について 引用文献1には、次の記載(当審訳のみ摘記)(以降、「0068記載」という。)がある。 「[0068] 従来技術においてはウェブページを入力する時、透明なシステム入力ボックスを用いてウェブページ入力ボックスをカバーする。従来技術と異なり、本発明の実施例が提供する方法においては、サードパーティキーボードビューでシステムのプリセットキーボードビューをカバーした後、モバイル端末装置に非表示の属性を有するシステム入力ボックスを作成し、且つサードパーティキーボードビューを作成されたシステム入力ボックスに関連付け、キーボードビューが受信した入力文字を作成された非表示の属性のシステム入力ボックスに入力することができる。従来技術において透明なシステム入力ボックスを使用してウェブページ入力ボックスをカバーし、入力する過程において、ウェブページ入力ボックスの入力フォーカスは透明なシステム入力ボックスに強制的に変換され、入力が完了した後、入力フォーカスはウェブページ入力ボックスに移行し、このようにサードパーティ入力法キーボードビューのフラッシュ問題を引き起こし、ユーザの入力に影響を与える。従来技術に比べて、本発明の実施例が提供する方法では非表示の属性を有するシステム入力ボックスを作成し、該非表示の属性の入力ボックスをユーザが文字を入力するための容器とし、ウェブページ入力ボックスの焦点を奪わず、焦点を変えずに切り替えるという問題がなく、それにより入力法のキーボードビューが再びポップアップしてキーボードビューがフラッシュするという問題を回避する。」 0068記載によれば、「ウェブページ入力ボックス」を「透明なシステム入力ボックス」を用いて「カバー」することは、本願優先日前の周知技術といえる。 しかしながら、0068記載の「従来技術において透明なシステム入力ボックスを使用してウェブページ入力ボックスをカバーし、入力する過程において、ウェブページ入力ボックスの入力フォーカスは透明なシステム入力ボックスに強制的に変換され、入力が完了した後、入力フォーカスはウェブページ入力ボックスに移行し、このようにサードパーティ入力法キーボードビューのフラッシュ問題を引き起こし、ユーザの入力に影響を与える。従来技術に比べて、本発明の実施例が提供する方法では非表示の属性を有するシステム入力ボックスを作成し、該非表示の属性の入力ボックスをユーザが文字を入力するための容器とし、ウェブページ入力ボックスの焦点を奪わず、焦点を変えずに切り替えるという問題がなく、それにより入力法のキーボードビューが再びポップアップしてキーボードビューがフラッシュするという問題を回避する。」からすれば、引用発明は、前記した周知技術における問題点を回避するために「非表示の属性を有するシステム入力ボックス」を採用したものと理解することができる。 よって、引用発明において、「非表示の属性を有するシステム入力ボックス」に替えて、周知技術である、「ウェブページ入力ボックス」を「透明なシステム入力ボックス」を用いて「カバー」する構成を採用することには、技術的な阻害要因がある。 また、引用文献3にも、上記相違点2又は相違点3に係る本願発明1の構成は記載されていない。 以上より、上記相違点1について判断するまでもなく、本願発明1は、当業者であっても引用発明並びに引用文献2及び3に記載された技術的事項に基いて容易に発明をすることができたものであるとはいえない。 2 本願発明2ないし7について 本願発明2ないし7も、上記相違点2及び相違点3に係る本願発明1の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明並びに引用文献2及び3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。 3 本願発明8ないし13について 本願発明8ないし13は、本願発明1ないし6に対応する装置の発明であり、上記相違点2及び相違点3に係る本願発明1の構成に対応する技術的事項を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明並びに引用文献2及び3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。 以上より、原査定を維持することはできない。 第6 当審拒絶理由についての判断 (1)本件補正前の請求項1に記載されていた「複数の認識識別子を有する第一の入力フィールド」は、本件補正により、「認識識別子を有するページ入力フィールド」と補正され、本件補正前の請求項8に記載されていた「第一の入力フィールドが複数の認識識別子を有する」は、本件補正により、「ページ入力フィールドが認識識別子を有する」と補正された。 (2)本件補正前の請求項1及び8に記載されていた「前記認識識別子は、さらにローカルキーボードのタイプを含む」は削除され、代わりに、「前記ローカルキーボードのタイプは、前記ページ入力フィールドのキーボードタイプの識別子に基づいている」との記載が追加され、「ローカルキーボードのタイプ」が、「キーボードタイプの識別子」に基づくことが明確となった。 以上より、請求項1ないし13に係る発明は明確となり、当審拒絶理由は解消した。 第7 むすび 以上のとおり、本願発明1ないし13は、当業者が引用発明並びに引用文献2及び3に記載された技術的事項に基いて容易に発明をすることができたものではない。 したがって、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
審決日 | 2021-08-10 |
出願番号 | 特願2017-523991(P2017-523991) |
審決分類 |
P
1
8・
537-
WY
(G06F)
P 1 8・ 121- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 三吉 翔子、萩島 豪、円子 英紀 |
特許庁審判長 |
▲吉▼田 耕一 |
特許庁審判官 |
北川 純次 林 毅 |
発明の名称 | ユーザー端末装置のHTMLページでローカルキーボードを呼び出すための方法及びその装置 |
代理人 | 特許業務法人 谷・阿部特許事務所 |