【事件の表示】
　特願２００８−５３２６２４「ブラウザ・ウィンドウの制御方法」拒絶査定不服審判事件〔平成１９年　４月１２日国際公開、ＷＯ２００７／０３９０４８、平成２１年　３月１２日国内公表、特表２００９−５１０５７０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　
　本件審判請求に係る出願（以下、「本願」という。）は、２００６年９月１２日（パリ条約による優先権主張外国庁受理２００５年９月２６日（以下、「本願の優先日」という。）、アメリカ合衆国）を国際出願日とする出願であって、平成２０年３月２６日に特許法第１８４条の５第１項に規定される書面が提出され、同年５月９日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書、請求の範囲、及び要約の翻訳文が提出され、同日付けで審査請求がなされ、平成２３年９月２６日付けで拒絶理由通知（同年９月２８日発送）がなされ、平成２４年３月２８日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年８月２４日付けで拒絶査定（同年８月２８日謄本送達）がなされたものである。
　これに対して、「原査定を取り消す、本願は特許をすべきものであるとの審決を求める」ことを請求の趣旨として、平成２４年１２月２８日付けで本件審判請求がなされるとともに、同日付けで手続補正がなされたものである。
　そして、平成２５年３月４日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ、同年４月１５日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年４月１６日発送）がなされ、同年１０月１５日付けで回答書の提出があったものである。
　
　
第２　平成２４年１２月２８日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　
　平成２４年１２月２８日付けの手続補正を却下する。
　
［理由］
　
１．補正の内容
　
　平成２４年１２月２８日付けの手続補正（以下、「本件補正」という。）の内容は、平成２４年３月２８日付けの手続補正により補正された特許請求の範囲の請求項１ないし請求項１１の記載
　
「　【請求項１】
　ブラウザ・ウィンドウの制御方法であって、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、方法。
　　【請求項２】
　請求項１記載の方法であって、更に、
　−前記個人用特別セッションからのログアウトにトリガーされて、前記トークンを削除するステップを備えている、方法。
　　【請求項３】
　請求項１記載の方法であって、更に、
　−前記トークンの有効性についての検証を繰り返し実行するためのフレームを発生するステップと、
　無効である前記トークンを検出すると前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、方法。
　　【請求項４】
　請求項３記載の方法において、前記フレームは見えないフレームである、方法。
　　【請求項５】
　請求項１記載の方法であって、更に、
　−前記個人用特別セッションの開始時に前記トークンを発生するステップを備えている、方法。
　　【請求項６】
　請求項１記載の方法において、別のブラウザ・ウィンドウにおいて前記トークンを発生し、該別のブラウザ・ウィンドウから前記ブラウザ・ウィンドウを発生するときに、前記ブラウザ・ウィンドウを、前記別のブラウザ・ウィンドウにおいて発生したトークンと関連付ける、方法。
　　【請求項７】
　クライアント・デバイス（４０２）と通信するように構成され、前記クライアント・デバイス上においてブラウザ・ウィンドウの制御を可能にするように適合されるサーバ・デバイス（４０４）であって、該サーバ・デバイス（４０４）は、個人用特別セッションを開始することを可能にする第１プログラムと、前記クライアント・デバイス（４０２）上の前記ブラウザ・ウィンドウ内において実行する第２プログラムとを収容する記憶ユニット（４１０）を備えており、前記第１プログラムは、個人用特別セッションを示すトークンを発生するように構成され、前記第２プログラムは、前記ブラウザ・ウィンドウを制御する方法を実行するように構成されており、前記方法が、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、サーバ・デバイス（４０４）。
　　【請求項８】
　請求項７記載のサーバ・デバイス（４０４）において、前記第１プログラムは、前記クライアント・デバイス（４０２）のメモリ・ユニット（４０８）に前記トークンを格納することを可能にする、サーバ・デバイス（４０４）。
　　【請求項９】
　請求項７記載のサーバ・デバイスにおいて、前記第１プログラムは、前記サーバ・デバイス（４０４）の記憶ユニット（４１０）に前記トークンを格納することを可能にする、サーバ・デバイス。
　　【請求項１０】
　サーバ・デバイス（４０４）と通信するように構成され、ブラウザ・ウィンドウを制御するように適合されるクライアント・デバイス（４０２）であって、前記サーバ・デバイス（４０４）は、個人用特別セッションを開始することを可能にする第１プログラムと、前記クライアント・デバイス（４０２）上の前記ブラウザ・ウィンドウ内において実行する第２プログラムとを収容する記憶ユニット（４１０）を備えており、前記第１プログラムは、個人用特別セッションを示すトークンを発生するように構成され、前記第２プログラムは、前記ブラウザ・ウィンドウを制御する方法を実行するように構成されており、前記方法が、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、クライアント・デバイス（４０２）。
　　【請求項１１】
　コンピュータ実行可能命令を備えたコンピュータ・プログラムであって、
　前記命令をコンピュータ・システム上で実行すると、ブラウザ・ウィンドウの制御方法を実行し、該方法が、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、コンピュータ・プログラム。」（以下、この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。）
　
を、
　
「　【請求項１】
　ブラウザ・ウィンドウの制御方法であって、
　
−個人用特別セッションの開始時に、少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいてトークンを発生するステップと、
　−前記
少なくとも１つの
前記
前記
　−前記トークンの有効性について繰り返し検証するステップと、
　−
前記ブラウザ・ウィンドウのいずれかにおいて
全ての
を備えている、方法。
　　【請求項２】
　請求項１記載の方法であって、更に、
　−前記個人用特別セッションからのログアウトにトリガーされて、前記トークンを削除するステップを備えている、方法。
　　【請求項３】
　請求項１記載の方法であって、更に、
　−前記トークンの有効性についての検証を繰り返し実行するためのフレームを発生するステップと、
　
−前記ブラウザ・ウィンドウのいずれかにおいて
、全ての
を備えている、方法。
　　【請求項４】
　請求項３記載の方法において、前記フレームは見えないフレームである、方法。
　　【請求項５】
　請求項１記載の方法において、
前記
少なくとも１つの
少なくとも１つの
　　【請求項６】
　クライアント・デバイス（４０２）と通信するように構成され、前記クライアント・デバイス上においてブラウザ・ウィンドウの制御を可能にするように適合されるサーバ・デバイス（４０４）であって、該サーバ・デバイス（４０４）は、個人用特別セッションを開始することを可能にする第１プログラムと、前記クライアント・デバイス（４０２）上の前記ブラウザ・ウィンドウ内において実行する第２プログラムとを収容する記憶ユニット（４１０）を備えており、前記第１プログラムは、個人用特別セッションを示すトークンを発生するように構成され、前記第２プログラムは、前記ブラウザ・ウィンドウを制御する方法を実行するように構成されており、前記方法が、
　−
少なくとも１つの
であって、前記トークンが前記第１プログラムにより前記クライアント・デバイス上の別のブラウザ・ウィンドウにおいて発生されたものである、ステップ
　−前記トークンの有効性について繰り返し検証するステップと、
　−
前記ブラウザ・ウィンドウのいずれかにおいて
全ての
を備えている、サーバ・デバイス（４０４）。
　　【請求項７】
　請求項
６
　　【請求項８】
　請求項
６
サーバ・デバイス。
　　【請求項９】
　サーバ・デバイス（４０４）と通信するように構成され、ブラウザ・ウィンドウを制御するように適合されるクライアント・デバイス（４０２）であって、前記サーバ・デバイス（４０４）は、個人用特別セッションを開始することを可能にする第１プログラムと、前記クライアント・デバイス（４０２）上の前記ブラウザ・ウィンドウ内において実行する第２プログラムとを収容する記憶ユニット（４１０）を備えており、前記第１プログラムは、個人用特別セッションを示すトークンを発生するように構成され、前記第２プログラムは、前記ブラウザ・ウィンドウを制御する方法を実行するように構成されており、前記方法が、
　−
少なくとも１つの
であって、前記トークンが前記第１プログラムにより前記クライアント・デバイス上の別のブラウザ・ウィンドウにおいて発生されたものである、ステップ
　−前記トークンの有効性について繰り返し検証するステップと、
　−
前記ブラウザ・ウィンドウのいずれかにおいて
全ての
を備えている、クライアント・デバイス（４０２）。
　　【請求項１０】
　コンピュータ実行可能命令を備えたコンピュータ・プログラムであって、
　前記命令をコンピュータ・システム上で実行すると、ブラウザ・ウィンドウの制御方法を実行し、該方法が、
　−
少なくとも１つの
であって、前記トークンが前記少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいて発生されたものである、ステップ
　−前記トークンの有効性について繰り返し検証するステップと、
　−
前記ブラウザ・ウィンドウのいずれかにおいて
全ての
を備えている、コンピュータ・プログラム。」（以下、この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。なお、下線は、補正箇所を示すものとして、出願人が付与したものである。）
　
に補正するものである。
　
２．新規事項の有無 
　
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第１７条の２第３項の規定に適合している。
　
３．補正の目的要件
　
（１）補正後の請求項１について
　
　補正後の請求項１は、その記載からして、次の発明特定事項（ａ）を含んでいる。
　
（ａ）「個人用特別セッションの開始時に、少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいてトークンを発生するステップ」
　
　しかしながら、補正後の請求項１が含む上記発明特定事項（ａ）は、補正前の請求項１が含むいずれかのステップを概念的に下位のステップにする補正であると認められず、補正前の請求項１に記載された「ブラウザ・ウィンドウの制御方法」に無い作用を有する発明特定事項を新たに加えたものであるといえるから、当該補正は、補正前の請求項１における発明特定事項を、概念的に下位の発明特定事項にする補正であると認められるものではない。
　
（２）ここで、請求人が、平成２４年１２月２８日付け審判請求書において、「本補正は、補正前の請求項１〜１１について、補正前の請求項５，６に係る発明特定事項の全部または一部を請求項１に組み込んで補正後の請求項１とし、・・・これに伴い補正前の請求項５を削除し、各請求項の従属関係を整理している。」と主張していることから、補正後の請求項１が、補正前の請求項５を限定的に減縮したものであると仮定した場合について検討する。
　
　すなわち、補正後の請求項１は、補正前の請求項５
　
「　【請求項１】
　ブラウザ・ウィンドウの制御方法であって、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、方法。」
「　【請求項５】
　請求項１記載の方法であって、更に、
　−前記個人用特別セッションの開始時に前記トークンを発生するステップを備えている、方法。」
　
において、
　
「前記個人用特別セッションの開始時に前記トークンを発生するステップ」を「個人用特別セッションの開始時に
、少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいて
「無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップ」を「
前記ブラウザ・ウィンドウのいずれかにおいて
全ての
（当審注：下線は、参考のために当審で付与したものである。）
　
　この場合、補正後の請求項１は、補正前の請求項５に記載した発明を特定するために必要な事項を限定したものであると認められる。
　
　しかしながら、この場合、補正後の請求項１に従属する補正後の請求項２ないし請求項５は、補正前の請求項２ないし請求項４、及び請求項６に対応し、上記（１）に記載された上記発明特定事項（ａ）を含むことになるが、補正前の請求項２ないし請求項４、及び請求項６は、直接・間接に、補正前の請求項１に従属したものであって、補正前の請求項５に従属したものではないから、補正後の請求項２ないし請求項５が含む上記発明特定事項（ａ）は、補正前の請求項２ないし請求項４、及び請求項６が含むいずれかのステップを概念的に下位のステップにする補正であると認められず、補正前の請求項２ないし請求項４、及び請求項６に記載された「ブラウザ・ウィンドウの制御方法」に無い作用を有する発明特定事項を新たに加えたものであるといえるから、当該補正は、補正前の請求項２ないし請求項４、及び請求項６における発明特定事項を、概念的に下位の発明特定事項にする補正であると認められるものではない。
　
（３）補正後の請求項６、請求項９、及び請求項１０について
　
　補正後の請求項６及び請求項９は、その記載からして、次の発明特定事項（ｂ）を含んでいる。
　
（ｂ）「少なくとも１つの前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップであって、前記トークンが前記第１プログラムにより前記クライアント・デバイス上の別のブラウザ・ウィンドウにおいて発生されたものである、ステップ」
　
　また、補正後の請求項１０は、その記載からして、次の発明特定事項（ｃ）を含んでいる。
　
（ｃ）「少なくとも１つの前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップであって、前記トークンが前記少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいて発生されたものである、ステップ」
　
　そして、前記発明特定事項（ｂ）は、その記載からして、
　
（ｂ１）「前記トークンが前記第１プログラムにより前記クライアント・デバイス上の別のブラウザ・ウィンドウにおいて発生されたものである」態様
　
を含み、前記発明特定事項（ｃ）は、その記載からして、
　
（ｃ１）「前記トークンが前記少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいて発生されたものである」態様
　
　を含んでいる。
　
　しかしながら、補正後の請求項６及び請求項９が含む上記（ｂ１）の態様、及び補正後の請求項１０が含む上記（ｃ１）の態様は、「トークン」を限定したものとも認められるが、それぞれ、補正前の請求項７及び請求項１０に対して“トークンを第１プログラムによりクライアント・デバイス上の別のブラウザ・ウィンドウにおいて発生させる”という補正前の請求項７及び請求項１０に無い新たな作用を有する発明特定事項を加え、補正前の請求項１１に対して“トークンを少なくともブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいて発生させる”という補正前の請求項１１に無い新たな作用を有する発明特定事項を加えたものであるといえるから、当該補正は、補正前の請求項７、請求項１０、及び請求項１１における発明特定事項を、概念的に下位の発明特定事項にする補正であると認められるものではない。
　
（４）小括
　
　以上のとおり、本件補正は、補正前の請求項１ないし請求項４、請求項６、請求項７、請求項１０、及び請求項１１に記載した発明を特定するために必要な事項を限定したものではなく、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの（以下、単に「限定的減縮」という。））を目的とするものとは認められない。
　
　また、本件補正は、特許法第１７条の２第４項第１号の請求項の削除、同条同項第３項の誤記の訂正、同条同項第４項の明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）を目的とするものに限られるものではない。
　
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものである。
　
４．独立特許要件
　
　以上のように、補正前の請求項１についてする補正は、「３．補正の目的要件」で指摘したとおり、特許法第１７条の２第４項第２号の限定的減縮に該当せず、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものであるが、仮に、本件補正が、特許法第１７条の２第４項第２号の限定的減縮に該当すると仮定した場合に、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）検討する。
　
（１）補正後の発明
　
　本件補正により、本願補正発明は、前記「１．補正の内容」において、補正後の請求項１として引用した、次の記載のとおりのものである。
　
「ブラウザ・ウィンドウの制御方法であって、
　−個人用特別セッションの開始時に、少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいてトークンを発生するステップと、　
　−前記少なくとも１つのブラウザ・ウィンドウを、前記個人用特別セッションを示す前記トークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−前記ブラウザ・ウィンドウのいずれかにおいて無効である前記トークンを検出すると、全ての前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、方法。」
　
（２）引用文献に記載されている技術的事項及び引用発明の認定
　
　本願の優先日前に頒布され、原審の拒絶の査定の理由である上記平成２３年９月２６日付けの拒絶理由通知において引用された刊行物である、特表２００５−５１８０１４号公報（平成１７年６月１６日出願公開。以下、「引用文献」という。）には、図面とともに、以下の技術的事項が記載されている。
（当審注：下線は、参考のために当審で付与したものである。）
　
Ａ　「【請求項１】
  アプリケーション・ウインドウの
親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じる方法であって、
  前記アプリケーション・ウインドウの
前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、
前記アプリケーション・ウインドウを閉じるステップ
を備えた
方法。
　
Ｂ　「【００２０】
  本発明によれば、次に示す方法が提供される。アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じる方法であって、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じるステップを備えた方法。本発明は子アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して当該子アプリケーション・ウインドウを自動的に閉じる方法を提供する。本発明では、親アプリケーション・ウインドウがもはや存在しない場合、子アプリケーション・ウインドウを閉じる。
表示済みの各アプリケーション・ウインドウは当該表示済みの各アプリケーション・ウインドウに付随するアプリケーション・ウインドウ制御によって親および子の役割を演じる。ウインドウ制御を表示済みの各アプリケーション・ウインドウに関連付けることにより、表示済みのアプリケーション・ウインドウはそれが表示される元を成すアプリケーション・ウインドウが存在するか否かを検出することができる
　
Ｃ　「【００３６】
  次に図３を参照する。ポータル環境内またはポータル環境外の他のサービスへのハイパーテキスト・リンクを表示した
ポータル・ホームページ・アプリケーションを表示する
表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する
ポータル・ホームページ１からハイパーテキスト・リンクを選択して従属アプリケーション・ウインドウを表示する
【００３７】
  表示したアプリケーション・ウインドウのｈｔｍｌページの＜body＞タグはonLoad () 関数を含んでいる。onLoad () 関数は初期関数を呼び出す。この初期関数はアプリケーションの
親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する
・・・（中略）・・・
【００４０】
  初期関数は当該初期関数が
「偽」値を返すまで
このプロセスを続ける
「KeepOpen」変数が存在しない場合には「偽」値を返す
そして、子ウインドウを閉じる
　
Ｄ　「【００４２】
  
次に本発明の図４を参照する。ポータル環境内から複数のアプリケーション・ウインドウを表示することができる
・・・（中略）・・・
【００４５】
  
ポータル・ホームページ・ウインドウ５０を閉じると、金融アプリケーション・ウインドウ５１、個人銀行口座アプリケーション・ウインドウ５２、および現在の口座アプリケーション・ウインドウ５３が閉じられる
　
　ここで、上記引用文献に記載されている事項を検討する。
　
（ア）上記Ａの記載からすると、引用文献には、
“親アプリケーション・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法であって、
  前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウを閉じるステップ
を備えている、方法。”
が記載されている。
　
（イ）上記（ア）の検討内容、上記Ｃの「表示したポータル・ホームページ・ウインドウ・・・ポータル・ホームページ１からハイパーテキスト・リンクを選択して従属アプリケーション・ウインドウを表示する」との記載からすると、上記Ｃ記載の「ポータル・ホームページ・ウインドウ」は上記（ア）記載の「親アプリケーション」に対応するといえる。
　
（ウ）上記Ｃの「ポータル・ホームページ・アプリケーションを表示する・・・表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する」との記載からすると、引用文献には、
“ポータル・ホームページ・アプリケーションの表示時に、ポータル・ホームページ・ウインドウでKeepOpen変数をインスタンス化するステップ”
が記載されていると解される。
　
（エ）上記（ア）及び（イ）の検討内容、上記Ｂの「表示済みの各アプリケーション・ウインドウは当該表示済みの各アプリケーション・ウインドウに付随するアプリケーション・ウインドウ制御によって親および子の役割を演じる。ウインドウ制御を表示済みの各アプリケーション・ウインドウに関連付けることにより、表示済みのアプリケーション・ウインドウはそれが表示される元を成すアプリケーション・ウインドウが存在するか否かを検出することができる」との記載、上記Ｃの「表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する・・・親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する」との記載からすると、引用文献には、
“アプリケーション・ウインドウを、ポータル・ホームページ・ウインドウが存在するか否かを示すKeepOpen変数と関連付けるステップ”
が記載されていると解される。
　
（オ）上記（ア）及び（イ）の検討内容、上記Ｃの「親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する・・・「偽」値を返すまで・・・このプロセスを続ける・・・「KeepOpen」変数が存在しない場合には「偽」値を返す・・・そして、子ウインドウを閉じる」との記載からすると、上記（ア）記載の「前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウを閉じるステップ」とは、
“KeepOpen変数の存在の有無を繰り返しチェックするステップ” 、
“チェック結果として偽値が返ってきた場合、アプリケーション・ウインドウを閉じるステップ”
を意味するものと解される。
　
（カ）上記Ｄの「次に本発明の図４を参照する。ポータル環境内から複数のアプリケーション・ウインドウを表示することができる・・・ポータル・ホームページ・ウインドウ５０を閉じると、金融アプリケーション・ウインドウ５１、個人銀行口座アプリケーション・ウインドウ５２、および現在の口座アプリケーション・ウインドウ５３が閉じられる」との記載から、ポータル・ホームページ・ウインドウを閉じると、全てのウインドウが閉じられる態様が読み取れる。
　してみると、上記（オ）の“チェック結果として偽値が返ってきた場合、アプリケーション・ウインドウを閉じるステップ”の一態様として、引用文献には、
“ポータル・ホームページ・ウインドウにおいて、チェック結果として偽値が返ってきた場合、全てのアプリケーション・ウインドウを閉じるステップ”
が記載されているものと解される。
　
　以上、（ア）ないし（カ）で指摘した事項を踏まえると、引用文献には、次の発明（以下、「引用発明１」という。）が記載されているものと認められる。
　
「ポータル・ホームページ・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法であって、
　ポータル・ホームページ・アプリケーションの表示時に、前記ポータル・ホームページ・ウインドウでKeepOpen変数をインスタンス化するステップと、
　前記アプリケーション・ウインドウを、前記ポータル・ホームページ・ウインドウが存在するか否かを示す前記KeepOpen変数と関連付けるステップと、
　前記KeepOpen変数の存在の有無を繰り返しチェックするステップと、
　前記ポータル・ホームページ・ウインドウにおいて、チェック結果として偽値が返ってきた場合、全ての前記アプリケーション・ウインドウを閉じるステップと、
を備えている、方法。」
　
（３）本願補正発明と引用発明１との対比
　
（３−１）引用発明１の「ポータル・ホームページ・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法」は、上位概念でみると、「ウインドウの制御方法」といえるものである。そして、本願補正発明の「ブラウザ・ウィンドウの制御方法」も、上位概念でみると、「ウインドウの制御方法」といえるものである。
　してみると、本願補正発明と引用発明１は、「ウインドウの制御方法」である点で共通する。
　
（３−２）引用発明１の「ポータル・ホームページ・ウインドウ」は、個人用の特別なホームページ・ウインドウといえるものであるから、引用発明１の「ポータル・ホームページ・アプリケーションの表示時」は、本願補正発明の「個人用特別セッションの開始時」に対応するといえる。
　また、引用発明１の「ポータル・ホームページ・ウインドウ」は、アプリケーション・ウインドウとは別のウインドウであることから、本願補正発明の「少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウ」に対応している。
　そして、引用発明１の「KeepOpen変数」は、個人用の特別なホームページ・ウインドウである「ポータル・ホームページ・ウインドウ」が存在するか否か（「ポータル・ホームページ・ウインドウ」のセッションが存在するか否か）を確認するためのものであるから、本願補正発明の「トークン」に対応するといえる。
　してみると、引用発明１の「ポータル・ホームページ・アプリケーションの表示時に、前記ポータル・ホームページ・ウインドウでKeepOpen変数をインスタンス化するステップ」と、本願補正発明の「個人用特別セッションの開始時に、少なくとも１つのブラウザ・ウィンドウとは別のブラウザ・ウィンドウにおいてトークンを発生するステップ」とは、“個人用特別セッションの開始時に、少なくとも１つのウインドウとは別のウインドウにおいてトークンを発生するステップ”である点で共通するといえる。
　
（３−３）引用発明１の「アプリケーション・ウインドウ」は、本願補正発明の「少なくとも１つのブラウザ・ウィンドウ」に対応する。
　そして、上記（３−２）の検討内容からすると、引用発明１の「前記アプリケーション・ウインドウを、前記ポータル・ホームページ・ウインドウが存在するか否かを示す前記KeepOpen変数と関連付けるステップ」と、本願補正発明の「前記少なくとも１つのブラウザ・ウィンドウを、前記個人用特別セッションを示す前記トークンと関連付けるステップ」とは、“前記少なくとも１つのウインドウを、前記個人用特別セッションを示す前記トークンと関連付けるステップ”である点で共通するといえる。
　
（３−４）上記（３−３）の検討内容からすると、引用発明１の「前記KeepOpen変数の存在の有無を繰り返しチェックするステップ」は、本願補正発明の「前記トークンの有効性について繰り返し検証するステップ」に相当するといえる。
　
（３−５）引用発明１の「ポータル・ホームページ・ウインドウ」は、引用発明１に記載されている複数のウインドウのいずれかのウインドウといえるから、引用発明の「ポータル・ホームページ・ウインドウ」は、本願補正発明の「ブラウザ・ウィンドウのいずれか」に対応するといえる。
　そして、引用発明１の「チェック結果として偽値が返ってきた場合」は、本願補正発明の「無効である前記トークンを検出すると」に相当する。
　してみると、引用発明１の「前記ポータル・ホームページ・ウインドウにおいて、チェック結果として偽値が返ってきた場合、全ての前記アプリケーション・ウインドウを閉じるステップ」と、本願補正発明の「前記ブラウザ・ウィンドウのいずれかにおいて無効である前記トークンを検出すると、全ての前記ブラウザ・ウィンドウを閉じるステップ」とは、“前記ウインドウのいずれかにおいて無効である前記トークンを検出すると、全ての前記ウインドウを閉じるステップ”である点で共通する。
　
　以上から、本願補正補明と引用発明１とは、以下の点で一致し、また、以下の点で相違する。
　
（一致点）
　
「ウインドウの制御方法であって、
　個人用特別セッションの開始時に、少なくとも１つのウインドウとは別のウインドウにおいてトークンを発生するステップと、
　前記少なくとも１つのウインドウを、前記個人用特別セッションを示す前記トークンと関連付けるステップと、
　前記トークンの有効性について繰り返し検証するステップと、
　前記ウインドウのいずれかにおいて無効である前記トークンを検出すると、全ての前記ウインドウを閉じるステップと、
を備えている、方法。」
　
（相違点）
　
　ウインドウに関して、本願補正発明が、「ブラウザ・ウィンドウ」であるのに対して、引用発明１は、「ポータル・ホームページ・ウインドウ」及び「アプリケーション・ウインドウ」である点。
　
（４）当審の判断
　
　上記相違点について検討する。
　
　当該技術分野において、「ブラウザ・ウィンドウ」は、グラフィカル・ユーザ・インタフェースとして慣用的に用いられている周知技術にすぎない。してみれば、引用発明１の「ポータル・ホームページ・ウインドウ」及び「アプリケーション・ウインドウ」においても、「ブラウザ・ウィンドウ」として構成することは、当業者が容易に想到し得たものである。
　
　よって、上記相違点は、格別のものではない。
　
　そして、本願補正発明の奏する作用効果は、上記引用発明１及び周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　
　したがって、本願補正発明は、上記引用発明１及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができない。　
　
５．むすび
　
　以上のように、上記「３．補正の目的要件」で指摘したとおり、補正前の請求項１ないし請求項４、請求項６、請求項７、請求項１０、及び請求項１１についてする補正を含む本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　また、仮に、本件補正が、特許法第１７条の２第４項第２号の限定的減縮に該当すると仮定した場合であっても、本件補正は、上記「４．独立特許要件」で指摘したとおり、補正後の請求項１に記載された発明は、特許出願の際独立して特許を受けることができるものではないから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、補正却下の決定の結論のとおり決定する。
　
　
第３　本件審判請求の成否について 
　
１．本願発明の認定
　
　平成２４年１２月２８日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２４年３月２８日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「ブラウザ・ウィンドウの制御方法であって、
　−前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　−前記トークンの有効性について繰り返し検証するステップと、
　−無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップと、
を備えている、方法。」
　
２．引用文献に記載されている技術的事項及び引用発明の認定
　
　本願の優先日前に頒布され、原審の拒絶の査定の理由である上記平成２３年９月２６日付けの拒絶理由通知において引用された、引用文献およびその記載事項は、前記「第２　平成２４年１２月２８日付けの手続補正についての補正却下の決定」の「４．独立特許要件」の「（２）引用文献に記載されている技術的事項及び引用発明の認定」において、上記ＡないしＣとして引用したとおりのものである。
　
　ここで、上記引用文献に記載されている事項を検討する。
　
（ア）上記Ａの記載からすると、引用文献には、
“親アプリケーション・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法であって、
  前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウを閉じるステップ
を備えている、方法。”
が記載されている。
　
（イ）上記（ア）の検討内容、上記Ｃの「表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する・・・ポータル・ホームページ１からハイパーテキスト・リンクを選択して従属アプリケーション・ウインドウを表示する」との記載からすると、上記Ｃ記載の「ポータル・ホームページ・ウインドウ」は上記（ア）記載の「親アプリケーション」に対応するといえる。
　
（ウ）上記（ア）及び（イ）の検討内容、上記Ｂの「表示済みの各アプリケーション・ウインドウは当該表示済みの各アプリケーション・ウインドウに付随するアプリケーション・ウインドウ制御によって親および子の役割を演じる。ウインドウ制御を表示済みの各アプリケーション・ウインドウに関連付けることにより、表示済みのアプリケーション・ウインドウはそれが表示される元を成すアプリケーション・ウインドウが存在するか否かを検出することができる」との記載、上記Ｃの「表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する・・・親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する」との記載からすると、引用文献には、
“アプリケーション・ウインドウを、ポータル・ホームページ・ウインドウが存在するか否かを示すKeepOpen変数と関連付けるステップ”、
を意味するものと解される。
　
（エ）上記（ア）及び（イ）の検討内容、上記Ｃの「親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する・・・「偽」値を返すまで・・・このプロセスを続ける・・・「KeepOpen」変数が存在しない場合には「偽」値を返す・・・そして、子ウインドウを閉じる」との記載からすると、上記（ア）記載の「前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウを閉じるステップ」とは、
“KeepOpen変数の存在の有無を繰り返しチェックするステップ” 、
“チェック結果として偽値が返ってきた場合、アプリケーション・ウインドウを閉じるステップ”
を意味するものと解される。
　
　以上、（ア）ないし（エ）で指摘した事項を踏まえると、引用文献には、次の発明（以下、「引用発明２」という。）が記載されているものと認められる。
　
「ポータル・ホームページ・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法であって、
　前記アプリケーション・ウインドウを、前記ポータル・ホームページ・ウインドウが存在するか否かを示すKeepOpen変数と関連付けるステップと、
　前記KeepOpen変数の存在の有無を繰り返しチェックするステップと、
　チェック結果として偽値が返ってきた場合、前記アプリケーション・ウインドウを閉じるステップと、
を備えている、方法。」
　
３．本願発明と引用発明２との対比
　
（１）引用発明２の「ポータル・ホームページ・ウインドウに付随するイベントに応答してアプリケーション・ウインドウを閉じる方法」は、上位概念でみると、「ウインドウの制御方法」といえるものである。そして、本願発明の「ブラウザ・ウィンドウの制御方法」も、上位概念でみると、「ウインドウの制御方法」といえる。
　してみると、本願発明と引用発明２は、「ウインドウの制御方法」である点で共通する。
　
（２）引用発明２の「ポータル・ホームページ・ウインドウ」は、個人用の特別なホームページ・ウインドウといえるものである。そして、引用発明２の「KeepOpen」変数は、個人用の特別なホームページ・ウインドウである「ポータル・ホームページ・ウインドウ」が存在するか否か（「ポータル・ホームページ・ウインドウ」のセッションが存在するか否か）を確認するためのものであるから、本願発明の「トークン」に対応するといえる。
　してみると、引用発明２の「前記アプリケーション・ウインドウを、前記ポータル・ホームページ・ウインドウが存在するか否かを示すKeepOpen変数と関連付けるステップ」と、本願発明の「前記ブラウザ・ウィンドウを、個人用特別セッションを示すトークンと関連付けるステップ」とは、“前記ウインドウを、個人用特別セッションを示すトークンと関連付けるステップ”である点で共通するといえる。
　
（３）上記（２）の検討内容からすると、引用発明２の「前記KeepOpen変数の存在の有無を繰り返しチェックするステップ」は、本願発明の「前記トークンの有効性について繰り返し検証するステップ」に相当するといえる。
　
（４）引用発明２の「チェック結果として偽値が返ってきた場合」は、本願発明の「無効である前記トークンを検出すると」に相当する。
　してみると、引用発明２の「チェック結果として偽値が返ってきた場合、前記アプリケーション・ウインドウを閉じるステップ」と、本願発明の「無効である前記トークンを検出すると、前記ブラウザ・ウィンドウを閉じるステップ」とは、“無効である前記トークンを検出すると、前記ウインドウを閉じるステップ”である点で共通する。
　
　以上から、本願補明と引用発明２とは、以下の点で一致し、また、以下の点で相違する。
　
（一致点）
　
「ウインドウの制御方法であって、
　前記ウインドウを、個人用特別セッションを示すトークンと関連付けるステップと、
　前記トークンの有効性について繰り返し検証するステップと、
　無効である前記トークンを検出すると、前記ウインドウを閉じるステップと、
を備えている、方法。」
　
（相違点）
　
　ウインドウに関して、本願発明が、「ブラウザ・ウィンドウ」であるのに対して、引用発明２は、「ポータル・ホームページ・ウインドウ」及び「アプリケーション・ウインドウ」である点。
　
４．当審の判断
　
　上記相違点について検討する。
　
　当該技術分野において、「ブラウザ・ウィンドウ」は、グラフィカル・ユーザ・インタフェースとして慣用的に用いられている周知技術にすぎない。してみれば、引用発明２の「ポータル・ホームページ・ウインドウ」及び「アプリケーション・ウインドウ」においても、「ブラウザ・ウィンドウ」として構成することは、当業者が容易に想到し得たものである。
　
　よって、上記相違点は、格別のものではない。
　
　そして、本願発明の奏する作用効果は、上記引用発明２及び周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　
　したがって、本願発明は、上記引用発明２及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
５．むすび
　
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものであるから、その余の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。
　
　よって、結論のとおり審決する。