【事件の表示】
　特願２０１０−５４７６６４「一時的編集面を使用したドキュメントの編集」拒絶査定不服審判事件〔平成２１年　９月　３日国際公開、ＷＯ２００９／１０８４１７、平成２３年　５月１２日国内公表、特表２０１１−５１４９９３、請求項の数（７）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
　
第１．手続の経緯　
　
　本件審判請求に係る出願（以下、「本願」という。）は、２００９年１月２１日（パリ条約に基づく優先権主張外国庁受理　２００８年２月２５日、米国）を国際出願日とする出願であって、平成２２年８月２０日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書、請求の範囲、図面（図面の中の説明に限る。）及び要約の翻訳文が提出され、平成２３年１０月３１日付けで審査請求がなされ、平成２５年１月８日付けで拒絶理由通知（同年１月１１日発送）がなされ、これに対して同年４月９日付けで意見書が提出されると共に手続補正書が提出されたが、同年４月２６日付けで拒絶査定（同年５月１０日謄本送達）がなされた。
　これに対して、『「原査定を取り消す。本願の発明は特許すべきものとする。」、との審決を求める。』ことを請求の趣旨として、平成２５年９月１０日付けで審判請求がなされた。
　
　
第２　本願発明　
　
　本願の特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、上記平成２５年４月９日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「コンピュータ装置が実行する方法であって、ＨＴＭＬ（Hypertext Markup Language）ドキュメントのコンテンツのテキスト部分を、前記コンピュータ装置のディスプレイに表示されるＷｅｂブラウザのウィンドウ内でユーザが編集するための方法であって、
　前記ＨＴＭＬドキュメントを前記Ｗｅｂブラウザのウィンドウ内に表示するステップと、
　前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を編集するリクエストを受信するステップと、
　前記リクエストに応答して、前記ウィンドウに表示されたとおりの前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の位置およびサイズを判断するステップと、
　前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なる編集面を作成するステップであって、前記編集面は、前記Ｗｅｂブラウザにレンダリングされる際に、前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の前記位置において前記サイズで前記ウィンドウに表示される前記編集面を生じさせるためのサイズおよび位置の属性を有するＨＴＭＬエレメントを、前記ＨＴＭＬドキュメントに追加することにより作成される、ステップと、
　前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を前記編集面にコピーするステップと、
　前記ウィンドウ内で前記ユーザの入力操作による入力を受信するステップと、
　前記入力を受信する際に、前記編集面が前記入力を処理するかどうかを判断するステップと、
　前記編集面が前記入力を処理すると判断された場合には、前記入力を、処理のために前記編集面エレメントに渡し、前記編集面に対しリフローオペレーションを実行するステップと、
　前記編集面が前記入力を処理しないと判断された場合には、すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を前記ＨＴＭＬドキュメントから除去し、前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を見えるようにするステップと、
　前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の編集を停止するリクエストを受信するステップと、
　前記リクエストを受信したことに応答して、前記すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を破棄するステップとを備え、
　前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を編集するリクエストを受信するステップは、
　　挿入ポインタが前記ウィンドウ内のある位置に置かれたことを検出するステップと、
　　前記挿入ポインタが置かれた場所で前記ウィンドウ内に表示された前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を判断するステップと、を含み、さらに、
　前記ウィンドウ内に表示された前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を判断する際に、前記挿入ポインタの前記位置に対応する前記ＨＴＭＬドキュメントのコンテンツのテキスト部分に置かれているテキスト内の文字位置を判断するステップと、
　前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なる前記編集面を作成する際に、前記編集面内の前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の前記テキスト内の前記文字位置にカーソルを位置づけるステップと
をさらに備えることを特徴とする方法。」
　
　
第３　原査定の理由の概要
　
１．平成２５年１月８日付け拒絶理由通知 
　
　平成２５年１月８日付けで拒絶理由が通知されたが、その内容は下記のとおりである。
　
『【理由１】
　この出願は、下記の点で特許法第３７条に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
　請求項１に係る発明は、下記【理由３】に記載したとおり、新規性を有さない。
　したがって、請求項１に係る発明と、請求項２−２０に係る発明は、同一の又は対応する特別な技術的特徴を有しない。
　ただし、請求項２−３に係る発明については、審査基準に基づき、例外的に発明の単一性の要件を問わないこととする（「特許・実用新案　審査基準」第１部第２章４．２を参照）。
　以上のように、請求項１に係る発明と請求項４−２０に係る発明とは、発明の単一性の要件を満たす一群の発明に該当しないから、この出願は特許法第３７条に規定する要件を満たさない。
　
　この出願は特許法第３７条の規定に違反しているので、請求項１−３以外の請求項に係る発明については特許法第３７条以外の要件についての審査を行っていない。
　なお、この出願は出願日が平成１９年４月１日以降であるから、特許法第１７条の２第４項の「発明の特別な技術的特徴を変更する補正」の規定が適用される。補正に当たっては、発明の特別な技術的特徴を変更する補正とならないよう、注意されたい。
　
【理由２】
　この出願の下記の請求項に係る発明は、下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないので、特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
　
　請求項１−３には、方法としての発明が記載されている。しかしながら、請求項１−３に記載された発明は、具体的にどのようにハードウェア資源と協働して実現されるものであるのかが不明であるため、請求項１−３に係る発明は自然法則を利用した技術的思想の創作とはいえない。
　
　よって、請求項１−３に係る方法は、特許法上の「発明」に該当するものとみることができない。
　
【理由３】
　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
　
　この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
請求項：１−３
引用文献：１
　備考：
　引用文献１には、文書や画像を含むＰＤＦをウィンドウに表示し、文書（テキスト）を編集したい場合、「Ｔｏｕｃｈ　Ｕｐ」というツールを起動し「Ｔｏｕｃｈ　Ｕｐテキスト・ツール」を用いてテキストの編集を行い、編集結果は自動的にＰＤＦに書き戻されるものが記載されている。（特にｐ．８２、図１−図２、各図の説明の部分を参照されたい。）
　なお、引用文献１には、ドキュメントの一部を編集面にコピーすることや、編集面を破棄すること、挿入ポインタによる位置の把握等については明確に記載されていないが、ＰＤＦを表示するアプリケーションとは異なる「Ｔｏｕｃｈ　Ｕｐテキスト・ツール」が起動され、該ツール上でテキストが編集されること、テキスト編集が終了するとＰＤＦに書き戻されるという記載から、引用文献１においてもドキュメントの一部を編集面（ツール）にコピーすることや、編集面を破棄すること、挿入ポインタによる位置の把握等が行われていることは明らかである。
　
　したがって、本願請求項１−３に係る発明は、引用文献１から把握される発明と相違せず、引用文献１に記載された発明である。
　
　　　　　　　　　　　引　用　文　献　等　一　覧
１．星野  純，デジタル文書革命に備えよ！Ａｃｒｏｂａｔ４．０実力大検
　証，日経ＭＡＣ  第７巻  第８号，日本，日経ＢＰ社，１９９９年７月
　１８日，第7巻　第8号，p.80-p.87』
　
２．平成２５年４月２６日付け拒絶査定 
　
　平成２５年４月２６日付けで拒絶査定がなされたが、その内容は下記のとおりである。
　
『この出願については、平成２５年１月８日付け拒絶理由通知書に記載した理由３によって、拒絶をすべきものです。
　なお、意見書並びに手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
備考
　出願人は、平成２５年４月９日付け意見書において、概略「
（１）補正後の本願発明は、Ｗｅｂブラウザで実行されることを前提としており、上述した引用文献１との差異がより明確になったものと思料致します。さらに、上記補正後の本願発明においては、ドキュメントはＷｅｂブラウザに表示されるＨＴＭＬドキュメントであり、編集面はＷｅｂブラウザにレンダリングされる際に、ＨＴＭＬドキュメントのコンテンツのテキスト部分の当該位置で、かつ当該サイズで編集面を生じさせるためのサイズおよび位置の属性を有するＨＴＭＬエレメントを、ＨＴＭＬドキュメントに追加することにより作成されること、を特徴としています。本願発明が備えるこのような構成については、引用文献１には何ら開示もなく、その旨の示唆もありません。
（２）さらに、上記補正後の本願発明は、補正前の元請求項７の特徴を含んでおり、『編集面に対しリフローオペレーションを実行する』という特徴を備えています。
　しかしながら、引用文献１には、『テキストは文字の挿入・削除が可能だが、行単位での編集となる。テキスト・ボックス内でのリフローという概念がない・・・』（８２ページ本文）との記載があります。これらの記載に鑑みれば、引用文献１ではリフロー処理を行うという発想そのものが存在せず、よって、いわゆる当業者が引用文献１に基づいて本願発明に想到することは困難です。
」と主張し、そのことを理由として、本願発明の特許性を主張する。
　
　以下、出願人が意見書において主張する上記２点についてそれぞれ検討する。
（１）本願出願当時の技術常識として、ブラウザ上でドキュメントを編集するツール、例えば「Ｚｏｈｏ　Ｗｒｉｔｅｒ」は周知の技術でありこのようなツールの提供は増え続けている。（必要であれば、引用文献等一覧２−３を参照されたい。）また、このようなツールをより有用なものとするべく機能追加や機能改善を行うことは、ソフトウェア開発では一般的に行われている事項である。そして引用文献１に記載されている機能もドキュメントを編集する一機能であることには変わりないし、ツールに実装されていない機能を別のアプリケーションを立ち上げることによって編集し、編集結果を本文に取り込むということ自体も以前から行われている事項であるから、ドキュメント編集を行うベースとなる部分をＷｅｂベースのものとすることに特段の困難性は認められず、Ｗｅｂベースのものとする際に発生する課題を解決することは、当業者の通常の創作能力の発揮である。
（２）編集された部分等に対し、リフローという処理を行うこと自体は、周知の技術である。（必要であれば、引用文献等一覧４−６を参照されたい。）
　一方、引用文献１には「テキスト・ボックス内でのリフローという概念がないので、長文の編集には向かない。」ことが明記されており、当該記載は換言すれば、長文の編集を行いたいという要望自体はＰＤＦ化された文書に対しても存在するが、該機能を用いた長文の編集には向かないことを伝えるための記載であると言い得、当該記載は該機能の一課題であるとも言える。そして、存在する課題を改善し有用なものとすることは、当業者の通常の創作能力の発揮である。
（３）そして、相違点は上記の点のみであるし、他に進歩性の存在を推認できる根拠もないから、本願発明は当業者が容易に想到することができたものである。
　
　したがって、上記出願人の主張はいずれも採用することができず、請求項１−７に係る発明は、引用文献１記載の技術から当業者が容易に想到し得たものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
引用文献等一覧
１.星野  純，デジタル文書革命に備えよ！Ａｃｒｏｂａｔ４．０実力大検証，日経ＭＡＣ  第７巻  第８号，日本，日経ＢＰ社，１９９９年　７月１８日，第7巻　第8号，p.80-p.87
２.水野  貴明，［ＳａａＳ］大研究　Ｐａｒｔ４  Ｗｅｂ２．０系ＳａａＳ［オフィス・アプリケーション編］  「オフィスＳａａＳ」の使い勝手をチェックする，ＣＯＭＰＵＴＥＲＷＯＲＬＤ  Ｇｅｔ  Ｔｅｃｈｎｏｌｏｇｙ  Ｒｉｇｈｔ  第３巻  第１０号，日本，（株）ＩＤＧジャパン，２００６年１０月　１日，第3巻　第10号，p.78-p.84
３.tokix，Ｗｅｂサイトエクスプローラー　オンラインで利用できるＷｅｂアプリを多数揃えた「Ｚｏｈｏ」，ＰＣ  Ｊａｐａｎ  第１２巻  第１１号，日本，ソフトバンククリエイティブ株式会社，２００７年１１月　１日，第12巻　第11号，p.112-p.115
４.井村  克也，Ｉｌｌｕｓｔｒａｔｏｒ  ＣＳ３  スーパーリファレンス  ｆｏｒ  Ｗｉｎｄｏｗｓ  初版，日本，株式会社ソーテック社，２００７年　７月１５日，第1版　ISBN:　978-4-88166-603-6，p.290
５.霜田  憲一，ついに登場！  待ちにまった日本語対応  「Ａｄｏｂｅ  Ｒｅａｄｅｒ  ｆｏｒ  Ｐａｌｍ  ＯＳ  ３．０  日本語版」の実力を探る，Ｐａｌｍ  Ｍａｇａｚｉｎｅ  ｖｏｌ．２０，日本，株式会社アスキー，２００３年１１月１４日，第20巻，p.54-p.55
６.特表２００７−５０６９８７号公報　』
　
　
第４　当審の判断
　
１．引用文献　
　
　本願の優先権主張日前に頒布され、原審の平成２５年１月８日付けの拒絶理由通知において引用された刊行物である、「星野純，デジタル文書革命に備えよ！Ａｃｒｏｂａｔ４．０実力大検証，日経ＭＡＣ，日本，日経ＢＰ社，１９９９年７月１８日，第７巻　第８号，第８０−８７頁」（以下、「引用文献１」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ａ　「Ｗｉｎは一般向け，マックはＤＴＰ
　こうしたＰＤＦの進化に加え，４．０ではそれを取り扱うソフトウエア群の機能も向上している。
特にＰＤＦを編集する「Ａｃｒｏｂａｔ　４．０」（後述）で，テキストや画像データの直接編集が可能になった点が注目される（従来はページ単位編集のみ）。
　
Ｂ　「ＰＤＦ作成・編集の効率を上げる新機能
　
Ａｃｒｏｂａｔ ４．０ の市販パッケージには，４種類のソフトウエアが含まれる。無償配布もされているＰＤＦ閲覧・印刷専用ソフト「Ａｃｒｏｂａｔ　Ｒｅａｄｅｒ４．０ 」のほかに， ＰＤＦの編集も可能なＲｅａｄｅｒの上位版「Ａｃｒｏｂａｔ４．０」（図１）がある。
　
Ｃ　「内容の直接編集が可能に
　ＰＤＦの編集ソフトであるＡｃｒｏｂａｔ ４．０ は大幅な機能強化を果たした。中でも，ＰＤＦの内容を直接編集できるようになった点は大きい。これまでは，いったん作成したＰＤＦに対しては，ページの入れ替えやサイズ変更，あるいはリンク，マルチメディア・データの追加といったオーサリング作業しか行えなかった。文字や画像などＰＤＦの内容自体は修正できないため，必要なら元の書類に戻ってＰＤＦを作り直さねばならなかった。
　
４．０では「Ｔｏｕｃｈ Ｕｐ 」というツールでテキストとグラフィックスを編集できる（図２，３）。ただし，グラフィックスはオブジェクトの位置変更のみで，内容を編集する場合はほかのソフトが必要となる。ベクトル・データなら「Ｉｌｌｕｓｔｒａｔｏｒ ８．０ 」，ビットマップ画像では「Ｐｈｏｔｏｓｈｏｐ ５．０」を用いる。Ｔｏｕｃｈ Ｕｐツールからこれらのソフトを呼び出して内容を変更する。変更した結果は，自動的にＰＤＦに書き戻される。
　
Ｄ　「
テキストは文字の挿入・削除が可能だが，行単位での編集となる。テキスト・ボックス内でのリフローという概念がないので，長文の編集には向かない。製版フィルムのストリップ校正のように，最終段階でほんの数文字直すための機能と考えた方がよい。
　
　ここで、上記引用文献１に記載されている事項を検討する。　
　
（ア）上記Ａの「特にＰＤＦを編集する「Ａｃｒｏｂａｔ　４．０」（後述）で，テキストや画像データの直接編集が可能になった点が注目される（従来はページ単位編集のみ）。」との記載、上記Ｂの「Ａｃｒｏｂａｔ ４．０の市販パッケージには，４種類のソフトウエアが含まれる。無償配布もされているＰＤＦ閲覧・印刷専用ソフト「Ａｃｒｏｂａｔ　Ｒｅａｄｅｒ４．０」のほかに， ＰＤＦの編集も可能なＲｅａｄｅｒの上位版「Ａｃｒｏｂａｔ４．０」（図１）がある。」との記載からすると、Ａｃｒｏｂａｔ ４．０の市販パッケージに含まれるソフトウエアである「Ａｃｒｏｂａｔ　４．０」を利用すれば、ＰＤＦのテキストや画像データの直接編集が可能であると解され、また、図１の「Ａｃｒｏｂａｔ４．０」の画面表示からすると、コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集することは明らかであるから、引用文献１には、　
「Ａｃｒｏｂａｔ ４．０の市販パッケージに含まれるソフトウエアである「Ａｃｒｏｂａｔ　４．０」を利用して、ＰＤＦのテキストや画像データを、コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するための方法」　
が記載されていると解される。
　
（イ）上記Ｃの「４．０では「Ｔｏｕｃｈ Ｕｐ」というツールでテキストとグラフィックスを編集できる（図２，３）。ただし，グラフィックスはオブジェクトの位置変更のみで，内容を編集する場合はほかのソフトが必要となる。ベクトル・データなら「Ｉｌｌｕｓｔｒａｔｏｒ ８．０」，ビットマップ画像では「Ｐｈｏｔｏｓｈｏｐ ５．０」を用いる。Ｔｏｕｃｈ Ｕｐツールからこれらのソフトを呼び出して内容を変更する。変更した結果は，自動的にＰＤＦに書き戻される。」との記載からすると、「Ｔｏｕｃｈ Ｕｐ」というツールは、グラフィックスの内容変更の場合には必要なソフトを呼び出して編集を行うと解されるから、引用文献１には、　
「「Ａｃｒｏｂａｔ　４．０」の「Ｔｏｕｃｈ Ｕｐ」というツールを用いて、グラフィックスの内容変更の場合には必要なソフトを呼び出して、グラフィックスを編集するステップ、変更した結果は、自動的にＰＤＦに書き戻されるステップ」　
が記載されていると解される。　
　
（ウ）上記Ｄの「テキストは文字の挿入・削除が可能だが，行単位での編集となる。テキスト・ボックス内でのリフローという概念がないので，長文の編集には向かない。製版フィルムのストリップ校正のように，最終段階でほんの数文字直すための機能と考えた方がよい。」との記載からすると、「Ｔｏｕｃｈ Ｕｐ」というツールは、リフローを実行することなく、行単位でのテキスト編集を可能とすると解されるから、引用文献１には、　
「「Ｔｏｕｃｈ Ｕｐ」というツールを用いて、テキストの内容変更の場合には、テキスト・ボックス内でのリフローを実行することなく、行単位での文字の挿入・削除といった編集を行うステップ」　
が記載されていると解される。　
　
　以上、（ア）乃至（ウ）で指摘した事項から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認める。
　
「Ａｃｒｏｂａｔ ４．０の市販パッケージに含まれるソフトウエアである「Ａｃｒｏｂａｔ　４．０」を利用して、ＰＤＦのテキストや画像データを、コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するための方法であって、
　前記「Ａｃｒｏｂａｔ　４．０」の「Ｔｏｕｃｈ Ｕｐ」というツールを用いて、
　テキストの内容変更の場合には、テキスト・ボックス内でのリフローを実行することなく、行単位での文字の挿入・削除といった編集を行うステップと、
　グラフィックスの内容変更の場合には、必要なソフトを呼び出して、グラフィックスを編集するステップと、
　変更した結果は、自動的にＰＤＦに書き戻されるステップと、
を備える方法。」
　
　
２．参考文献
　
（２−１）参考文献１に記載されている技術的事項
　
　本願の優先権主張日前に頒布され、原審の平成２５年４月２６日付けの拒絶査定において引用された刊行物、「tokix，Ｗｅｂサイトエクスプローラー　オンラインで利用できるＷｅｂアプリを多数揃えた「Ｚｏｈｏ」，ＰＣ  Ｊａｐａｎ，日本，  ソフトバンククリエイティブ株式会社，２００７年１１月１日，第１２巻　第１１号，第１１２−１１５頁」（以下、「参考文献１」という。）には、関連する図面とともに、以下の技術的事項が記載されている。　
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ｅ　「Ｚｏｈｏは，オンラインで利用できるＷｅｂアプリケーションを多数公開しているＷｅｂサイトだ（表１）。
ワープロや
オフィスツールや顧客管理ツールなど，通常ならハードディスクにインストールしてから実行するローカルアプリケーションを，Ｗｅｂブラウザ上の操作だけで利用できる。
　
　
Ｆ　「
Ｚｏｈｏ  Ｗｒｉｔｅｒ　：　ワープロソフト。Ｗｏｒｄ形式やＨＴＭＬ，ＰＤＦ形式などでエクスポートが可能
　
Ｇ　「ＭｉｃｒｏｓｏｆｔＯｆｆｉｃｅや　ＯｐｅｎＯｆｆｉｃｅ．ｏｒｇのファイルを開ける　　
　
ＺｏｈｏＷｒｉｔｅｒは，マイクロソフトのＷｏｒｄに近い，Ｗｅｂブラウザ上で利用するワープロソフトだ。
　
（２−２）参考文献２に記載されている技術的事項
　
　本願の優先権主張日前に頒布され、原審の平成２５年４月２６日付けの拒絶査定において引用された、特表２００７−５０６９８７号公報（平成１９年３月２２日出願公開、以下、「参考文献２」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ｈ　「【０００５】
　視覚障害者を援助するための既存のシステムは幾つかの欠点を持っている。通常のＳＡＭシステムでは、一旦１つのページが最終的な表示領域よりも大きく拡大されると、ユーザは、各ラインについて、単調な実際の混乱するような処理をすべて見るためにイメージを前後に滑らせなければならない。
或るツールは、表示領域を適合させるために、フォントをサイズ変更することおよび必要に応じてページをリフローすることを可能にするＨＴＭＬのようなフォーマットを使用する。
例えば、典型的なインターネット・ブラウザでは、ＨＴＭＬテキストをリフローすることが可能である。
　
（２−３）参考文献３乃至５
　
　上記参考文献１，２のほか、原審の平成２５年４月２６日付けの拒絶査定において引用された、本願の優先権主張日前に頒布された刊行物は以下のとおりである。
　
・水野貴明，［ＳａａＳ］大研究　Ｐａｒｔ４  Ｗｅｂ２．０系ＳａａＳ［オフィス・アプリケーション編］  「オフィスＳａａＳ」の使い勝手をチェックする，ＣＯＭＰＵＴＥＲＷＯＲＬＤ  Ｇｅｔ  Ｔｅｃｈｎｏｌｏｇｙ  Ｒｉｇｈｔ，日本，（株）ＩＤＧジャパン，２００６年１０月１日，第３巻　第１０号，第７８−８４頁（以下、「参考文献３」という。）
　
・井村克也，Ｉｌｌｕｓｔｒａｔｏｒ  ＣＳ３  スーパーリファレンス  
ｆｏｒ  Ｗｉｎｄｏｗｓ，日本，株式会社ソーテック社，２００７年７月１５日，第１版　ISBN:　978-4-88166-603-6，第２９０頁（以下、「参考文献４」という。）
　
・霜田憲一，ついに登場！  待ちにまった日本語対応  「Ａｄｏｂｅ  Ｒｅａｄｅｒ  ｆｏｒ  Ｐａｌｍ  ＯＳ  ３．０  日本語版」の実力を探る，Ｐａｌｍ  Ｍａｇａｚｉｎｅ，日本，株式会社アスキー，２００３年１１月１４日，第２０巻，第５４−５５頁（以下、「参考文献５」という。）
　
３．対比
　
　本願発明と引用発明とを対比する。
　
（３−１）引用発明の「Ａｃｒｏｂａｔ ４．０の市販パッケージに含まれるソフトウエアである「Ａｃｒｏｂａｔ　４．０」」はコンピュータ装置が実行するソフトウエアであること、引用発明の「ＰＤＦ」はドキュメントのコンテンツであることは明らかであるから、引用発明の「Ａｃｒｏｂａｔ ４．０の市販パッケージに含まれるソフトウエアである「Ａｃｒｏｂａｔ　４．０」を利用して、ＰＤＦのテキストや画像データを、コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するための方法」と、本願発明の「コンピュータ装置が実行する方法であって、ＨＴＭＬ（Hypertext Markup Language）ドキュメントのコンテンツのテキスト部分を、前記コンピュータ装置のディスプレイに表示されるＷｅｂブラウザのウィンドウ内でユーザが編集するための方法」は、ともに、“コンピュータ装置が実行する方法であって、ドキュメントのコンテンツのテキスト部分を、前記コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するための方法”である点で共通するといえる。　
　
（３−２）引用発明の「行単位での文字の挿入・削除といった編集」は、コンピュータ装置のディスプレイに表示されるウィンドウ内でのユーザの入力操作による入力に応じて実行されることは明らかであり、一方、本願発明における「ウィンドウ内で前記ユーザの入力操作による入力」は、コンテンツのテキスト部分の編集のための入力を含むものであるといえる。
　そうすると、引用発明の「前記「Ａｃｒｏｂａｔ　４．０」の「Ｔｏｕｃｈ Ｕｐ」というツールを用いて、テキストの内容変更の場合には、テキスト・ボックス内でのリフローを実行することなく、行単位での文字の挿入・削除といった編集を行うステップ」と、本願発明の「前記ウィンドウ内で前記ユーザの入力操作による入力を受信するステップと、前記入力を受信する際に、前記編集面が前記入力を処理するかどうかを判断するステップと、前記編集面が前記入力を処理すると判断された場合には、前記入力を、処理のために前記編集面エレメントに渡し、前記編集面に対しリフローオペレーションを実行するステップ」は、ともに、“ウィンドウ内でユーザの入力操作による入力を受信するステップと、前記入力に応じてコンテンツのテキスト部分の編集を行うステップ”である点で共通するといえる。　
　
（３−３）引用発明の「ＰＤＦ」は本願発明の「ＨＴＭＬドキュメント」に対応し、両者は“ドキュメントのコンテンツ”である点で共通することは明らかである。また、引用発明の「変更した結果」は、「ＰＤＦ」のテキスト部分などの編集を停止する時に確定するものであるといえる。
　そうすると、引用発明の「変更した結果は、自動的にＰＤＦに書き戻されるステップ」と、本願発明の「前記編集面が前記入力を処理しないと判断された場合には、すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を前記ＨＴＭＬドキュメントから除去し、前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を見えるようにするステップと、前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の編集を停止するリクエストを受信するステップと、前記リクエストを受信したことに応答して、前記すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を破棄するステップ」は、ともに、“コンテンツのテキスト部分の編集を停止する時には、すべての変更をドキュメントのコンテンツに適用するステップ”である点で共通するといえる。　
　
　以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。 
　
（一致点） 
　
「コンピュータ装置が実行する方法であって、ドキュメントのコンテンツのテキスト部分を、前記コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するための方法であって、
　前記ウィンドウ内で前記ユーザの入力操作による入力を受信するステップと、
　前記入力に応じてコンテンツのテキスト部分の編集を行うステップと、
　前記コンテンツのテキスト部分の編集を停止する時には、すべての変更をドキュメントのコンテンツに適用するステップと、
を備える方法。」　
　
（相違点１）
　
　コンピュータ装置のディスプレイに表示されるウィンドウ内でユーザが編集するドキュメントのコンテンツの種類に関して、本願発明では「ＨＴＭＬ（Hypertext Markup Language）ドキュメント」のテキスト部分を編集するのに対して、引用発明では「ＰＤＦのテキスト」を編集する点。
　
（相違点２）
　
　ドキュメントのコンテンツを編集するリクエスト受信時の処理に関して、本願発明では、「前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を編集するリクエストを受信するステップと、前記リクエストに応答して、前記ウィンドウに表示されたとおりの前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の位置およびサイズを判断するステップと、前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なる編集面を作成するステップであって、前記編集面は、前記Ｗｅｂブラウザにレンダリングされる際に、前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の前記位置において前記サイズで前記ウィンドウに表示される前記編集面を生じさせるためのサイズおよび位置の属性を有するＨＴＭＬエレメントを、前記ＨＴＭＬドキュメントに追加することにより作成される、ステップと、前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を前記編集面にコピーするステップ」を実行し、「前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を編集するリクエストを受信するステップ」は、「挿入ポインタが前記ウィンドウ内のある位置に置かれたことを検出するステップと、前記挿入ポインタが置かれた場所で前記ウィンドウ内に表示された前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を判断するステップと、を含み、さらに、前記ウィンドウ内に表示された前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を判断する際に、前記挿入ポインタの前記位置に対応する前記ＨＴＭＬドキュメントのコンテンツのテキスト部分に置かれているテキスト内の文字位置を判断するステップと、前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なる前記編集面を作成する際に、前記編集面内の前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の前記テキスト内の前記文字位置にカーソルを位置づけるステップ」を含むのに対して、引用発明では、ドキュメントのコンテンツを編集するリクエスト受信時の処理については詳細が不明である点。
　
（相違点３）
　
　ウィンドウ内でのユーザの入力操作による入力を受信した時の処理に関して、本願発明では、「前記ウィンドウ内で前記ユーザの入力操作による入力を受信するステップと、前記入力を受信する際に、前記編集面が前記入力を処理するかどうかを判断するステップと、前記編集面が前記入力を処理すると判断された場合には、前記入力を、処理のために前記編集面エレメントに渡し、前記編集面に対しリフローオペレーションを実行するステップと、前記編集面が前記入力を処理しないと判断された場合には、すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を前記ＨＴＭＬドキュメントから除去し、前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を見えるようにするステップ」を実行するのに対して、引用発明では、「「Ａｃｒｏｂａｔ　４．０」の「Ｔｏｕｃｈ Ｕｐ」というツールを用いて、テキストの内容変更の場合には、テキスト・ボックス内でのリフローを実行することなく、行単位での文字の挿入・削除といった編集を行うステップ」を実行するものの、編集面が入力を処理するかどうかを判断することについては特に記載されていない点。
　
（相違点４）
　
　ドキュメントのコンテンツの編集を停止する時の処理に関して、本願発明では、「前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の編集を停止するリクエストを受信するステップと、前記リクエストを受信したことに応答して、前記すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用し、前記編集面を破棄するステップ」を実行するのに対して、引用発明では、「変更した結果は、自動的にＰＤＦに書き戻されるステップ」を実行するものの編集面の表示処理については特に記載されていない点。
　
　
４．判断
　
　上記相違点１乃至相違点４について検討する。
　
（４−１）相違点１について　
　
　引用発明は、「Ａｃｒｏｂａｔ　４．０」を利用して、ＰＤＦのテキストを、コンピュータ装置のディスプレイに表示されるウィンドウ内で編集可能とするものであるが、参考文献１（上記Ｅ，Ｆ，Ｇ参照），参考文献３に記載されているように、Ｗｅｂブラウザ上で利用可能なワープロソフトを利用して、ＨＴＭＬ形式のドキュメントを編集する旨の技術は、本願優先権主張日前にはテキスト編集技術の分野における周知の技術的事項であった。
　そして、引用発明においても、ドキュメントのテキストをコンピュータ装置のディスプレイに表示されるウィンドウ内で編集可能としているいるところ、上記周知技術に基づき「ＰＤＦ」の編集に代えて「ＨＴＭＬドキュメント」を編集可能とすること、すなわち、上記相違点１に係る構成とすることは、当業者が容易に想到し得たことである。 
　
　したがって、この相違点１には格別の技術的進歩性があるものではない。
　
　よって、相違点１は格別なものではない。　
　
（４−２）相違点２について
　
　本願発明は、ドキュメントのコンテンツを編集するリクエストを受信すると、「リクエストに応答して、前記ウィンドウに表示されたとおりの前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の位置およびサイズを判断するステップ」、「前記ウィンドウに表示されたように前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なる編集面を作成するステップ」、「前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を前記編集面にコピーするステップ」などを実行するものであり、「編集面」に編集対象のテキスト部分をコピーし、当該テキスト部分の位置およびサイズを合わせて、ＨＴＭＬドキュメントの上に重ねて表示するという特徴を有している。
　また、本願発明は、ＨＴＭＬドキュメントのコンテンツのテキスト部分を編集するリクエストの受信を、「挿入ポインタが前記ウィンドウ内のある位置に置かれたことを検出するステップと、前記挿入ポインタが置かれた場所で前記ウィンドウ内に表示された前記ＨＴＭＬドキュメントのコンテンツのテキスト部分を判断するステップ」で実行しており、「挿入ポインタ」のウィンドウ内での位置検出により編集対象のテキスト部分をリクエストとともに受信するという特徴を有している。
　上記の本願発明の特徴に関して、引用発明では詳細が不明であるが、「行単位での文字の挿入・削除といった編集を行う」ことからすると、編集対象のテキスト部分である「行」の位置を特定するための何らかの手段を備えていることは自明である。また、挿入ポインタによりテキスト上の編集位置を特定する旨の技術は、本願優先権主張日前にはテキスト編集技術の分野における周知の技術的事項であった。
　しかしながら、ウィンドウ内でテキスト部分の編集を行うための「編集面」を作成するための具体的手順については、引用文献１には記載されておらず、特に、ＨＴＭＬドキュメントを編集するための「編集面」を本願発明のように、Ｗｅｂブラウザにレンダリングされる際に、ＨＴＭＬドキュメントのコンテンツのテキスト部分と同じ位置およびサイズでウィンドウに表示させるための属性を有するＨＴＭＬエレメントを、前記ＨＴＭＬドキュメントに追加することにより、前記ＨＴＭＬドキュメントのコンテンツのテキスト部分の上に重なるように作成することは、本願優先権主張日前に当該技術分野の周知技術と認めることはできない。
　してみると、引用発明に上記周知の技術的事項を適用しても、「挿入ポインタ」のウィンドウ内での位置検出により編集対象のテキスト部分を特定する情報をリクエストとともに受信する構成を得るにとどまり、本願発明の相違点２に係る構成とすることはできないものである。
　
　したがって、上記相違点２に係る構成が容易に想到しえたものであるとはいえない。
　
（４−３）相違点３について　
　
　本願発明は、ウィンドウ内でのユーザの入力操作による入力を受信した時の処理に関して、「入力を受信する際に、前記編集面が前記入力を処理するかどうかを判断するステップ」を実行し、「編集面が前記入力を処理すると判断された場合には、前記入力を、処理のために前記編集面エレメントに渡し」、「編集面が前記入力を処理しないと判断された場合には、すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用」する処理を実行するという特徴を有している。
　上記の本願発明の特徴に関して、確かに、ブラウザに表示されるＨＴＭＬテキストやＰＤＦのテキストにリフローを実行する旨の技術は、例えば、参考文献２（上記Ｈ参照），参考文献４，参考文献５に記載されているように、本願優先権主張日前にはテキスト編集技術の分野における周知の技術的事項であり、この周知技術をディスプレイのウィンドウ内でのテキスト編集に適用することについては格別困難性があったとは認められない。
　しかしながら、ユーザの入力操作による入力を受信する際に、前記編集面が前記入力を処理するかどうかを判断し、編集面が前記入力を処理しないと判断された場合に、すべての変更を前記ＨＴＭＬドキュメントのコンテンツに適用する点については、引用発明には特に記載がなく、また、それに伴う編集面の表示処理を本願発明のように実行することも、本願優先権主張日前に当該技術分野の周知技術と認めることはできない。
　してみると、引用発明に上記周知の技術的事項を適用しても、編集対象範囲のリフローを実行して、ＨＴＭＬテキストの文字の挿入・削除といった編集を行う構成を得るにとどまり、本願発明の相違点３に係る構成とすることはできないものである。
　
　したがって、上記相違点３に係る構成が容易に想到しえたものであるとはいえない。
　
（４−４）相違点４について　
　
　引用文献１（図２）にも記載されているように、ドキュメントの編集対象範囲が枠囲いなどにより識別可能に表示され、編集終了時に編集対象範囲の指定が解除されるとともに編集対象範囲の表示が消去される旨の技術は、本願優先権主張日前にはテキスト編集技術の分野における周知の技術的事項であった。
　そして、引用発明においても、編集により変更された結果を自動的にＰＤＦドキュメントに書き戻す処理が実行されるところ、上記周知技術に基づき、ドキュメントのコンテンツの編集を停止する時に、それまでの編集対象範囲の指定を解除すること、すなわち、上記相違点４に係る構成とすることは、当業者が容易に想到し得たことである。 
　
　したがって、この相違点４には格別の技術的進歩性があるものではない。
　
　よって、相違点４は格別なものではない。
　
　
５．まとめ
　
　以上のとおりであるから、本願の請求項１に係る発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものとすることができないものである。
　
　
６．請求項２乃至７に係る発明について
　
　請求項２乃至３は請求項１を引用するものであるから、上記５．で示した理由により当業者が容易に発明をすることができたものとすることができないものである。
　
　また、請求項４及び請求項７に係る発明は、請求項１に記載の発明を、それぞれ、記憶媒体の発明及び装置の発明に変えたものであり、さらに、請求項５乃至６は請求項４を引用するものであるから、これら請求項４乃至７に係る発明についても、上記５．で示した理由により当業者が容易に発明をすることができたものとすることができないものである。
　
　
７．むすび
　
　以上のとおり、本願の請求項１乃至７に係る発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
　
　また、他に本願を拒絶すべき理由を発見しない。
　
　
　よって、結論のとおり審決する。