【事件の表示】
　特願２０１４−１７１０４３「音声を利用できるテルネットインターフェイス」拒絶査定不服審判事件〔平成２７年　２月２６日出願公開、特開２０１５−　３８７３２、請求項の数（１）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，平成２０年（２００８年）８月１５日（パリ条約による優先権主張２００７年８月１６日，米国）を国際出願日とする特願２０１０−５２１０４２号の一部を，平成２６年８月２６日に新たな出願としたものであって，平成２６年８月２６日に手続補正書が提出され，平成２７年１０月６日付けで拒絶理由が通知され，平成２８年４月１２日に意見書及び手続補正書が提出され，平成２８年７月１５日付けで最後の拒絶理由が通知され，平成２９年１月１６日に意見書及び手続補正書が提出されたが，平成２９年２月２３日付けで拒絶査定がなされ，これに対し，平成２９年６月２７日に拒絶査定不服審判の請求がされると同時に手続補正書が提出されたものである。
第２　原査定の概要
　原査定（平成２９年２月２３日付け拒絶査定）の概要は次のとおりである。
　本願請求項１に係る発明は，下記の引用文献１に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
１．特開２００１−２９６９９１号公報
第３　本願発明
　本願請求項１に係る発明（以下，「本願発明１」という。）は，平成２９年６月２７日に提出された手続補正書による手続補正で補正された特許請求の範囲の請求項１に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。
「【請求項１】
　テルネットクライアントを操作するための方法であって，
　ａ．前記テルネットクライアントにおいて，１つ以上のスクリプトを実行することを備え，
　前記１つ以上のスクリプトが，前記テルネットクライアントに，
　　ｉ．音声入力を受信させるとともに，
　　ｉｉ．音声入力を入力テキストに変換させるようになっており，
　さらに，
　ｂ．テルネットセッションを介して，サーバーに対して前記入力テキストを送信し，
　前記変換された入力テキストは，単語またはフレーズを含み，前記単語またはフレーズは，現時点において前記テルネットクライアントのスクリーンに表示されている情報を含む入力パラメータ及び前記テルネットセッションの状態に基づいて音声入力から変換されたものであり，
　前記現時点において前記テルネットクライアントのスクリーンに表示されている情報は，（１）前記テルネットクライアントの前記スクリーンに表示されているテキスト，（２）前記テルネットクライアントのスクリーンに表示されている，１つ以上の入力フィールド，および，（３）カーソルの位置，を含む，前記方法。」
第４　引用文献，引用発明等
　原査定の拒絶の理由に引用された引用文献１には，図面とともに次の事項が記載されている（なお，下線は重要箇所に対して当審が付した。以下，同様。）。
１　段落【０００１】−【０００５】
「【０００１】
【発明の属する技術分野】本発明は，ネットワーク上で提供されるＨＴＭＬデータなどのマークアップ言語で記述されたデータの処理に関し，特に，ブラウザからの音声入力に関する。
【０００２】
【従来の技術】情報検索，アンケート，商品の注文などを目的として利用できるＷｅｂページには，テキスト入力フォームや選択メニュー，ボタンなどを配置して，キーボードやマウスなどで操作可能なＧＵＩ(Graphical User Interface)を用意したものが多く見られる。
【０００３】一方，近年，キーボードやマウスなどに加えて，音声がインタフェースとして用いられるようになってきた。例えば，ブラウザ上に表示されたWebページのテキスト入力フォームへ音声で情報を入力したり，選択メニューから項目を音声で選択する方法がある。これらの方法では，テキスト入力フォームには，最も尤度の高い認識結果を入力し，選択メニューでは，最も尤度の高い項目を選択している。しかし，音声認識で１００％の認識率を達成するのは困難である。そこで，複数の認識候補を画面上で，音声入力したテキスト入力フォーム，あるいは，選択メニューとは別の領域に表示し，その中から利用者に正しい結果を選択させ，テキスト入力フォームでは選択された結果を入力し，選択メニューでは選択された結果の項目を選択する方法等が採用されている。
【０００４】
【発明が解決しようとする課題】しかし，従来の手法では，音声入力における複数の認識候補が，ブラウザ上で表示されたWebページのテキスト入力フォームや選択メニューとは別の領域に表示されるため，使い勝手が必ずしもよくなかった。
【０００５】従って，本発明の目的は，ブラウザ上で表示されたWebページのテキスト入力フォームや選択メニュー上で，音声入力における複数の認識候補を表示可能なデータ処理装置，データ処理方法，及び，記録媒体を提供することにある。」
２　段落【００１９】−【００４５】
「【００１９】
図２は，本発明の一実施形態に係るブラウザ装置の機能ブロック図であり，
【００２０】
２０７は音声入力処理部であり，ＨＴＭＬデータの内容を表示するブラウザ上に含まれる入力欄，すなわち入力フォームに，ユーザが情報の入力又は項目の選択を行うために発声した音声を計算機上に取り込む
音声情報２０１は入力された音声情報を示している。
音声入力があると，音声入力された入力フォーム（例えば，フォーカスのあっている入力フォーム）の識別子が取得され，保存される。
【００２１】
２０８は音声認識部であり，音声情報２０１に対して音声認識処理を実行し，その認識候補を作成する。
認識候補２０２は，音声認識の確からしさを示す尤度の高い順に複数得ることもできる。
【００２２】
２０９は，入力フォーム処理部であり，ＨＴＭＬデータの入力フォーム情報を取得したり，格納したりする。
【００２３】
２１１は，ＨＴＭＬデータ処理部であり，表示されているページが異なるページになった時に，新たなＨＴＭＬデータ２０６を取得し，保存する。
ＨＴＭＬデータ処理部２１１は，ＨＴＭＬデータ２０６がＨＴＭＬデータ作成部２１０で変更された時に，ＨＴＭＬデータ２０６をブラウザにPushして，ディスプレイに表示させる。
【００２４】
２１０はＨＴＭＬデータ作成部であり，認識候補２０２，音声入力された入力フォームの識別子２０３，入力フォーム情報（現在値）２０４，入力フォーム情報（初期値）２０５，ＨＴＭＬデータ２０６等に基づいて，ＨＴＭＬデータ２０６を変換，保存等する。
【００２５】次に，
ＨＴＭＬデータ作成部２１０の動作をフローチャートを用いて説明する。
【００２６】
ステップＳ３００では，ＨＴＭＬデータ２０６から入力フォームの記述を検出し，見つけた入力フォームを現在処理対象としている入力フォームとする。
【００２７】
ステップＳ３０１では，音声入力された入力フォームの識別子２０３と現在処理対象としている入力フォームの識別子とを比較し，現在処理対象としている入力フォームに対して，音声入力がされたか否か判定する。
【００２８】ステップＳ３０５では，入力フォーム情報（現在値）２０４から，現在処理対象としている入力フォームに対応する入力フォームの設定値を取得し，現在処理対象としている入力フォームの設定値と比較する。入力フォームの設定値が異なっていた場合には，現在処理対象としている入力フォームの設定値を，前記取得した設定値に変更する。
【００２９】一方，
ステップＳ３０１で，現在処理対象としている入力フォームが音声入力された入力フォームであると判定された時は，ステップＳ３０２に進む。
【００３０】
ステップＳ３０２では，入力フォーム情報（初期値）２０５より，現在処理対象としている入力フォームのタイプを取得する。そして，取得したタイプに応じて，テキスト入力タイプの場合にはステップＳ３０３に進み，選択候補からの１つの選択タイプの場合にはステップＳ３０４に進む。
【００３１】
ステップＳ３０３では，現在対象としている入力フォーム（テキスト入力タイプの入力フォーム）を，選択候補からの１つの選択タイプの入力フォームに変更し，認識候補２０２を埋め込む。認識候補として，音声認識の確からしさを示す尤度の高い順に複数得られる場合には，尤度が高い候補が表示される優先順位を高くするように記述を変更する。
【００３２】
例えば，現在処理対象としている入力フォームの記述が，
＜ＩＮＰＵＴ type=textname=word＞
であった時（ブラウザ上での表示例を図４（ａ）に示す。）に，認識候補として，尤度順に中山，和歌山，高山，岡山と得られた場合には，
＜ＳＥＬＥＣＴ  name=word＞
＜ＯＰＴＩＯＮ  ＳＥＬＥＣＴＥＤ＞  中山
＜ＯＰＴＩＯＮ＞  和歌山
＜ＯＰＴＩＯＮ＞  高山
＜ＯＰＴＩＯＮ＞  岡山
＜／ＳＥＬＥＣＴ＞
と記述を変換する（ブラウザ上での表示例を図４（ｂ）に示す。）。
ＣＧＩ等で，サーバへ返送する変数であるname=xxxの部分はそのままとする。
【００３３】ここでは，第一位の認識候補に対しては，OPTIONタグの中でSELECTEDを記述したが，SELECTEDの記述が１つも存在しない時に，ブラウザがデフォルトで選択候補の最上位にあるものを設定値としてもつ時には，SELECTEDの記述は省略しても良い。
【００３４】なお，認識候補が１つしかない場合には，選択候補からの１つの選択タイプのフォームに変更せずに，テキスト入力タイプのフォームにしても良い。
【００３５】例えば，認識候補が中山だけの場合には，
＜ＳＥＬＥＣＴ  name=word＞
＜ＯＰＴＩＯＮ  ＳＥＬＥＣＴＥＤ＞  中山
＜／ＳＥＬＥＣＴ＞
と記述を変換しても良いし，
＜ＩＮＰＵＴ type=textname=wordvalue=中山＞
と記述を変換しても良い（ブラウザ上での表示例を図４（ｃ）に示す。）。
【００３６】また，認識候補が１つもなかった場合には，認識に失敗したことをユーザに知らせるために，認識失敗などを埋め込むように記述を変換しても良いし（ブラウザ上での表示例を図４（ｄ）に示す。），何も埋め込まないで，なんらかの方法によってユーザに認識が失敗したことを提示しても良い。例えば，スピーカから，認識に失敗しましたと音声を出力すれば良い。
【００３７】ただし，SELECTタグの中には最低１つのOPTIONタグが必要なため，何も埋め込まない場合は，選択候補から１つの選択タイプは使用できず，テキスト入力タイプのフォームにする必要がある。
【００３８】一方，
ステップＳ３０４では，現在対象としている入力フォーム（予め設定された項目である選択候補から１つを選択するタイプの入力フォーム）において，予め設定された項目である選択候補中で，認識候補２０２と一致する選択候補が表示される優先順位を高くするように記述を変換する。
【００３９】例えば，現在処理対象としている入力フォームの記述が，
＜ＳＥＬＥＣＴ name=city＞
＜ＯＰＴＩＯＮ＞  東京
＜ＯＰＴＩＯＮ＞  横浜
＜ＯＰＴＩＯＮ＞  大阪
＜ＯＰＴＩＯＮ＞  岡山
＜ＯＰＴＩＯＮ＞  名古屋
：
：
：
＜／ＳＥＬＥＣＴ＞
であった時（ブラウザ上での表示例を図５に示す。）に，認識候補として，尤度順に中山，和歌山，高山，岡山と得られた場合には，
＜ＳＥＬＥＣＴ name=city＞
＜ＯＰＴＩＯＮ  ＳＥＬＥＣＴＥＤ＞  中山
＜ＯＰＴＩＯＮ＞  和歌山
＜ＯＰＴＩＯＮ＞  高山
＜ＯＰＴＩＯＮ＞  岡山
＜ＯＰＴＩＯＮ＞  東京
＜ＯＰＴＩＯＮ＞  横浜
＜ＯＰＴＩＯＮ＞  大阪
＜ＯＰＴＩＯＮ＞  名古屋
：
：
：
＜／ＳＥＬＥＣＴ＞
と記述を変更する（ブラウザ上での表示例を図６に示す）。
【００４０】ここでは，第一位の認識候補に対しては，OPTIONタグの中でSELECTEDを記述したが，SELECTEDの記述が１つも存在しない時に，ブラウザがデフォルトで選択侯補の最上位にあるものを設定値としてもつ時には，SELECTEDの記述は省略しても良い。
【００４１】なお，認識候補が１つしかない場合には，並べ替えを行わず，認識結果のOPTIONタグをSELECTEDにするのみでも良い。
【００４２】例えば，認識候補が岡山だけの場合には，
＜ＳＥＬＥＣＴ name=city＞
＜ＯＰＴＩＯＮ＞  東京
＜ＯＰＴＩＯＮ＞  横浜
＜ＯＰＴＩＯＮ＞  大阪
＜ＯＰＴＩＯＮ  ＳＥＬＥＣＴＥＤ＞  岡山
＜ＯＰＴＩＯＮ＞  名古屋
：
：
：
＜／ＳＥＬＥＣＴ＞
と記述を変換しても良い（ブラウザ上での表示例を図７に示す。）。
【００４３】認識候補が１つもなかった場合には，認識に失敗したことをユーザに知らせるために，認識失敗などを埋め込むように記述を変換してよい。認識失敗を埋め込む位置は，最上位でもよいし（ブラウザ上での表示例を図８に示す。），最下位でもよい（ブラウザ上での表示例を図９に示す。）。
【００４４】また，並べ替えを行わず，何も埋め込まないで，なんらかの方法によってユーザに認識が失敗したことを提示しても良い。例えば，スピーカから，認識に失敗しましたと音声を出力すれば良い。
【００４５】ステップＳ３０６では，全入力フォームに対して処理を終了したか否か判定し，終了していた場合には，ＨＴＭＬデータの変換作業を終了する。終了していない場合には，ステップＳ３００に戻り，処理を繰り返す。」
３　段落【００５８】−【００５９】
「【００５８】以上説明した実施形態によれば，
ユーザが入力しようとしているブラウザ上の入力フォームに，音声入力における認識候補を表示し，GUI等で選択する
【００５９】また，選択候補から1つを選択するタイプの入力フォームにおいて，選択候補が多くある場合には，GUIなどでの選択に時間がかかるが，以上説明した実施形態によれば，音声入力における認識候補が尤度順に選択候補の上位に配置されるので，認識候補の中に正解がある場合には，第一位でなくても上位にあるため，GUIにより短時間で選択でき，かつ，第二位以下の認識候補に正解があった場合に，発声し直す必要がなくなる。また，同音異表記の認識候補があった場合には，GUIを用いて選択できるようになる。」
　上記記載及び図面並びにこの分野における技術常識を考慮すると，引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
「ＨＴＭＬデータの内容を表示するブラウザ上に含まれる入力欄，すなわち入力フォームに，ユーザが情報の入力又は項目の選択を行うために発声した音声を計算機上に取り込み，また，音声入力があると，音声入力された入力フォーム（例えば，フォーカスのあっている入力フォーム）の識別子を取得し，保存する音声入力処理部２０７と，
　入力された音声情報２０１に対して音声認識処理を実行し，その認識候補を作成し，認識候補２０２は，音声認識の確からしさを示す尤度の高い順に複数得ることもできる，音声認識部２０８と，
　ＨＴＭＬデータの入力フォーム情報を取得したり，格納したりする入力フォーム処理部２０９と，
　表示されているページが異なるページになった時に，新たなＨＴＭＬデータ２０６を取得し，保存し，また，ＨＴＭＬデータ２０６がＨＴＭＬデータ作成部２１０で変更された時に，ＨＴＭＬデータ２０６をブラウザにPushして，ディスプレイに表示させるＨＴＭＬデータ処理部２１１と，
　認識候補２０２，音声入力された入力フォームの識別子２０３，入力フォーム情報（現在値）２０４，入力フォーム情報（初期値）２０５，ＨＴＭＬデータ２０６等に基づいて，ＨＴＭＬデータ２０６を変換，保存等するＨＴＭＬデータ作成部２１０と，
　を有するブラウザ装置において，
　上記ＨＴＭＬデータ作成部２１０が，
　ステップＳ３００では，ＨＴＭＬデータ２０６から入力フォームの記述を検出し，見つけた入力フォームを現在処理対象としている入力フォームとし，
　ステップＳ３０１では，音声入力された入力フォームの識別子２０３と現在処理対象としている入力フォームの識別子とを比較し，現在処理対象としている入力フォームに対して，音声入力がされたか否か判定し，
　ステップＳ３０１で，現在処理対象としている入力フォームが音声入力された入力フォームであると判定された時は，ステップＳ３０２に進み，入力フォーム情報（初期値）２０５より，現在処理対象としている入力フォームのタイプを取得し，取得したタイプに応じて，テキスト入力タイプの場合にはステップＳ３０３に進み，選択候補からの１つの選択タイプの場合にはステップＳ３０４に進み，
　ステップＳ３０３では，現在対象としている入力フォーム（テキスト入力タイプの入力フォーム）を，選択候補からの１つの選択タイプの入力フォームに変更し，認識候補２０２を埋め込み，ここで，認識候補として，音声認識の確からしさを示す尤度の高い順に複数得られる場合には，尤度が高い候補が表示される優先順位を高くするように記述を変更し，例えば，現在処理対象としている入力フォームの記述が，
＜ＩＮＰＵＴ type=textname=word＞
であった時に，認識候補として，尤度順に中山，和歌山，高山，岡山と得られた場合には，
＜ＳＥＬＥＣＴ  name=word＞
＜ＯＰＴＩＯＮ  ＳＥＬＥＣＴＥＤ＞  中山
＜ＯＰＴＩＯＮ＞  和歌山
＜ＯＰＴＩＯＮ＞  高山
＜ＯＰＴＩＯＮ＞  岡山
＜／ＳＥＬＥＣＴ＞
と記述を変換し，ここで，ＣＧＩ等で，サーバへ返送する変数であるname=xxxの部分はそのままとし，
　ステップＳ３０４では，現在対象としている入力フォーム（予め設定された項目である選択候補から１つを選択するタイプの入力フォーム）において，予め設定された項目である選択候補中で，認識候補２０２と一致する選択候補が表示される優先順位を高くするように記述を変換し，
　ユーザが入力しようとしているブラウザ上の入力フォームに，音声入力における認識候補を表示し，GUI等で選択する方法。」
第５　対比・判断
１　対比
　本願発明１と引用発明とを対比すると，次のことがいえる。
（１）引用発明では，「ブラウザ装置」の「ＨＴＭＬデータ作成部２１０」が「入力フォーム（テキスト入力タイプの入力フォーム）を，選択候補からの１つの選択タイプの入力フォームに変更し，認識候補２０２を埋め込」むと共に「ＣＧＩ等で，サーバへ返送する変数であるname=xxxの部分はそのままとし」，且つ，「ブラウザ上の入力フォームに，音声入力における認識候補を表示し，GUI等で選択する」から，この「GUI等で選択」された「認識候補」を「変数であるname=xxx」とともに「サーバ」へ返送することは明らかである。したがって，引用発明における「ブラウザ装置」は，サーバへ情報の返送を行なう「クライアント」であるといえる。
　また，引用発明では，「ＨＴＭＬデータの内容を表示するブラウザ上に含まれる入力欄，すなわち入力フォームに，ユーザが情報の入力又は項目の選択を行うために発声した音声を計算機上に取り込」むことができ，この「音声を計算機上に取り込」むこと（すなわち，「音声入力」）や，上記「GUI等で選択」することは，「ブラウザ装置」に対する操作であるといえる。
　そうすると，引用発明と本願発明１とは，「クライアントを操作するための方法」である点で共通するといえる。
（２）上記（１）で述べたとおり，引用発明では，「音声を計算機上に取り込」むこと，すなわち，「音声入力」ができ，このことは，本願発明１における「クライアント」に「音声入力を受信させる」点で共通する。
（３）引用発明において，「音声入力における認識候補」として例示される「中山，和歌山，高山，岡山」は，いずれもテキストであるといえるから，引用発明の「認識候補」は，本願発明１の「入力テキスト」に相当する。
　そうすると，引用発明と本願発明１とは，「クライアント」に「音声入力を入力テキストに変換させる」点で一致するといえる。
（４）上記（１）で述べたとおり，引用発明では，「GUI等で選択」された「認識候補」を「変数であるname=xxx」とともに「サーバ」へ返送することが明らかであり，また，上記（３）で述べたとおり，引用発明の「認識候補」は，本願発明１の「入力テキスト」に相当する。
　そうすると，引用発明と本願発明１とは，「サーバーに対して前記入力テキストを送信」する点で一致するといえる。
（５）引用発明において，「音声入力における認識候補」として例示される「中山，和歌山，高山，岡山」は，いずれも「単語」であるから，引用発明の「認識候補」は，本願発明１の「入力テキスト」と「前記変換された入力テキストは，単語またはフレーズを含む」点で一致するといえる。
　よって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
（一致点）
「クライアントを操作するための方法であって，
　ａ．前記クライアントにおいて，
　　ｉ．音声入力を受信させるとともに，
　　ｉｉ．音声入力を入力テキストに変換させるようになっており，
　さらに，
　ｂ．サーバーに対して前記入力テキストを送信し，
　前記変換された入力テキストは，単語を含む，前記方法。」
（相違点）
（相違点１）本願発明１と引用発明は共に，「クライアントを操作するための方法」であるが，本願発明１の「クライアント」は「テルネットクライアント」であるのに対して，引用発明の「クライアント」は「ブラウザ装置」であって「テルネットクライアント」ではない点。
（相違点２）本願発明１では，「１つ以上のスクリプトを実行すること」によって，「ｉ．音声入力を受信させるとともに，ｉｉ．音声入力を入力テキストに変換させるようになって」いるのに対して，引用発明では，「ブラウザ装置」に「音声入力を受信させ」，且つ，「音声入力を入力テキストに変換させ」ているものの，これらの処理が「スクリプトを実行すること」によって行なわれているのかが不明である点。
（相違点３）本願発明１と引用発明は共に，「サーバーに対して前記入力テキストを送信」するものであるが，本願発明１は，「ｂ．テルネットセッションを介して，サーバーに対して前記入力テキストを送信し」ているのに対して，引用発明では，「テルネットセッションを介して」いない点。
（相違点４）本願発明１と引用発明は共に，「前記変換された入力テキストは，単語を含む」ものであるが，本願発明１の「前記単語またはフレーズ」は，「現時点において前記テルネットクライアントのスクリーンに表示されている情報を含む入力パラメータ及び前記テルネットセッションの状態に基づいて音声入力から変換されたものであり，前記現時点において前記テルネットクライアントのスクリーンに表示されている情報は，（１）前記テルネットクライアントの前記スクリーンに表示されているテキスト，（２）前記テルネットクライアントのスクリーンに表示されている，１つ以上の入力フィールド，および，（３）カーソルの位置，を含む」のに対して，引用発明の「前記単語」は，「現時点において前記テルネットクライアントのスクリーンに表示されている情報を含む入力パラメータ及び前記テルネットセッションの状態に基づいて音声入力から変換されたものであり，前記現時点において前記テルネットクライアントのスクリーンに表示されている情報は，（１）前記テルネットクライアントの前記スクリーンに表示されているテキスト，（２）前記テルネットクライアントのスクリーンに表示されている，１つ以上の入力フィールド，および，（３）カーソルの位置，を含む」ものではない点。
２　判断
　事案に鑑み，まず上記相違点４について検討する。
　相違点４に係る本願発明１の「前記変換された入力テキストは，単語またはフレーズを含み，前記単語またはフレーズは，現時点において前記テルネットクライアントのスクリーンに表示されている情報を含む入力パラメータ及び前記テルネットセッションの状態に基づいて音声入力から変換されたものであり，前記現時点において前記テルネットクライアントのスクリーンに表示されている情報は，（１）前記テルネットクライアントの前記スクリーンに表示されているテキスト，（２）前記テルネットクライアントのスクリーンに表示されている，１つ以上の入力フィールド，および，（３）カーソルの位置，を含む」という構成は，引用文献１には記載されておらず，本願出願前において周知技術であるともいえない。
　したがって，本願発明１は，当業者であっても引用発明に基づいて容易に発明できたものであるとはいえない。
　よって，本願発明１は，相違点１−３を検討するまでもなく，当業者であっても引用発明に基づいて容易に発明できたものであるとはいえない。
第６　原査定について
　理由（特許法第２９条第２項）について
　本願発明１は，「前記変換された入力テキストは，単語またはフレーズを含み，前記単語またはフレーズは，現時点において前記テルネットクライアントのスクリーンに表示されている情報を含む入力パラメータ及び前記テルネットセッションの状態に基づいて音声入力から変換されたものであり，前記現時点において前記テルネットクライアントのスクリーンに表示されている情報は，（１）前記テルネットクライアントの前記スクリーンに表示されているテキスト，（２）前記テルネットクライアントのスクリーンに表示されている，１つ以上の入力フィールド，および，（３）カーソルの位置，を含む」という事項を有しており，当業者であっても，拒絶査定において引用された引用文献１に基づいて，容易に発明できたものとはいえない。
　したがって，原査定の理由を維持することはできない。
第７　むすび
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。