【事件の表示】
　特願２００６−　１９７３７「ネットワーク内の単一使用承認方法及びシステム」拒絶査定不服審判事件〔平成１８年　８月２４日出願公開，特開２００６−２２２９４６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１８年１月２７日（パリ条約による優先権主張２００５年２月１１日　アメリカ合衆国）の出願であって，
　平成２０年１２月１５日付けで審査請求がなされ，平成２３年７月８日付けで審査官により拒絶理由が通知され，これに対して平成２３年１１月１１日付けで意見書が提出されると共に手続補正がなされたが，平成２３年１１月２８日付けで審査官により拒絶査定がなされ，これに対して平成２４年４月６日付けで審判請求がなされると共に手続補正がなされ，平成２４年６月２９日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２４年９月２４日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２４年１２月２５日付けで回答書が提出され，平成２５年１０月１８日付けで当審により平成２４年４月６日付けの手続補正が却下される（発送；平成２５年１１月５日）と共に拒絶理由が通知され（発送；平成２５年１０月２２日），これの対して平成２６年１月２２日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２．本願発明について
　本願の請求項各項に係る発明は，平成２６年１月２２日付けの手続補正（以下，これを「本件手続補正」という）により補正された特許請求の範囲の請求項（以下，これを「補正後の請求項」という）１〜１８に記載された，次の事項により特定されるものである。
　
「　【請求項１】
　一つ以上の装置が装置固有認証制御を備えている装置からなるネットワーク内の多様な装置間の単一使用承認のユーザ認証方法において，
　前記ネットワーク内の多様な装置のうち装置固有認証制御を行う装置にユーザが入力した装置固有ユーザＩＤに基づいて，前記装置固有認証制御を行う装置上で該装置に対応する所定の装置固有ユーザＩＤ認証情報を用いてユーザを認証するステップと，
　前記装置固有認証制御を行う装置上でユーザが認証されたならば，ユーザ認証に用いられた前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用されるネットワーク全域ユーザＩＤに転換するステップと，
　前記ネットワーク全域ユーザＩＤを，前記装置固有認証制御を行う装置を除いた他の装置の他の装置固有ユーザＩＤに転換するステップとを含み，
　前記他の装置は，前記ネットワーク全域ユーザＩＤから転換された前記他の装置固有ユーザＩＤに基づいて前記ユーザを認証でき，
　前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップは，前記多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換し，前記システムＩＤマップは，前記多様な装置のうちの１つ以上にて具現化される制御器にて設定される，ことを特徴とする単一使用承認のユーザ認証方法。
　　【請求項２】
　前記装置固有認証制御を行う装置上でユーザを認証するステップは，
　前記装置固有認証制御を行う装置で，ユーザに装置固有ユーザＩＤの入力を要請するステップと，
　前記装置固有認証制御を行う装置の装置固有認証制御を利用して前記装置固有ユーザＩＤを検証するステップとをさらに含むことを特徴とする請求項１に記載の単一使用承認のユーザ認証方法。
　　【請求項３】
　前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換するステップは，
　前記システムＩＤマップから他の装置の装置固有ユーザＩＤを照会するステップをさらに含むことを特徴とする請求項１又は２に記載の単一使用承認のユーザ認証方法。
　　【請求項４】
　前記他の装置で前記他の装置内の装置固有認証制御を利用して，前記照会された装置固有ユーザＩＤを認証するステップをさらに含むことを特徴とする請求項３に記載の単一使用承認のユーザ認証方法。
　　【請求項５】
　一装置がユーザを認証する能力がない場合，ユーザ認証のために装置固有認証制御を行う他の装置に認証を委任するステップをさらに含み，
　該一装置から該他の装置に認証を委任するステップは，
　　該一装置の認証エージェントが，前記制御器を介して，該他の装置に認証要請を送信するステップと，
　　該他の装置が，前記認証要請を受けて，ユーザに装置固有ユーザＩＤの入力を要求するステップと，
　　該他の装置が，ユーザが入力した装置固有ユーザＩＤを該他の装置の装置固有認証制御を利用して検証するステップと，
　　ユーザが入力した装置固有ユーザＩＤが承認されると，該他の装置が前記制御器を介して該一装置の認証エージェントに承認メッセージを送信するステップと
　を含む，ことを特徴とする請求項１に記載の単一使用承認のユーザ認証方法。
　　【請求項６】
　アプリケーションの一つのセッションや色々なセッションにわたって単一使用承認のユーザ認証を提供するステップをさらに含むことを特徴とする請求項１に記載の単一使用承認のユーザ認証方法。
　　【請求項７】
　前記他の装置固有ユーザＩＤを前記制御器から前記他の装置に提供するステップと，
　前記他の装置が保有した装置固有認証制御を通じて，前記提供された装置固有ユーザＩＤに基づいて，前記他の装置がユーザを認証するステップとをさらに含むことを特徴とする請求項１に記載の単一使用承認のユーザ認証方法。
　　【請求項８】
　一つ以上の装置が装置固有認証制御を含む多様な装置からなるネットワークでユーザを認証するためのシステムにおいて，
　前記ネットワーク内の多様な装置のうち装置固有認証制御を行う一装置内で，該装置に対応する所定の装置固有ユーザＩＤ認証情報を用いて，ユーザが入力した装置固有ユーザＩＤに基づいてユーザを認証する認証エージェントと，
　前記ユーザが認証されたならば，前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用されるネットワーク全域ユーザＩＤに転換し，前記ネットワーク全域ユーザＩＤを，前記装置固有認証制御を行う一装置を除いた他の装置の他の装置固有ユーザＩＤに転換する制御器とを備え，
　前記他の装置は前記他の装置固有ユーザＩＤに基づいてユーザを認証でき，それにより，システムが前記多様な装置の間で単一使用承認のユーザ認証を提供し，
　前記制御器は，前記多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップを設定し，該システムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換する，ことを特徴とするネットワーク内のユーザ認証システム。
　　【請求項９】
　前記認証エージェントは，ユーザに装置固有ユーザＩＤの入力を要請し，装置固有認証制御を通じて前記装置固有ユーザＩＤを検証することによってユーザを認証することを特徴とする請求項８に記載のネットワーク内のユーザ認証システム。
　　【請求項１０】
　前記制御器は，前記システムＩＤマップから他の装置の装置固有ユーザＩＤを照会することによって，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換することを特徴とする請求項８又は９に記載のネットワーク内のユーザ認証システム。
　　【請求項１１】
　一装置がユーザを認証する能力がない場合，該一装置は，ユーザの認証のために装置固有認証制御を行う他の装置に，該一装置の認証エージェントから前記制御器を介して認証要請を送信することによって認証を委任し，
　該他の装置は，前記認証要請を受けて，ユーザに装置固有ユーザＩＤの入力を要求し，ユーザが入力した装置固有ユーザＩＤを該他の装置の装置固有認証制御を利用して検証し，ユーザが入力した装置固有ユーザＩＤが承認されると，前記制御器を介して該一装置の認証エージェントに承認メッセージを送信する，ことを特徴とする請求項８に記載のネットワーク内のユーザ認証システム。
　　【請求項１２】
　前記制御器は，前記他の装置に前記他の装置固有ユーザＩＤを提供し，前記他の装置は，自身の装置固有認証制御を利用して前記提供された他の装置固有ユーザＩＤに基づいて前記ユーザを認証することによって，多様な装置の間で単一使用承認のユーザ認証を提供することを特徴とする請求項８に記載のネットワーク内のユーザ認証システム。
　　【請求項１３】
　一つ以上が装置固有認証制御を行うネットワーク内の多様な装置と，
　前記ネットワーク内の多様な装置のうち装置固有認証制御を行う一装置内で，該装置に対応する所定の装置固有ユーザＩＤ認証情報を用いて，ユーザが入力した装置固有ユーザＩＤに基づいてユーザを認証する認証エージェントと，
　前記ユーザが認証されたならば，前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用されるネットワーク全域ユーザＩＤに転換し，前記ネットワーク全域ユーザＩＤを，前記装置固有認証制御を行う一装置を除いた他の装置の他の装置固有ユーザＩＤに転換する制御器とを備え，
　前記他の装置は前記他の装置固有ユーザＩＤに基づいて前記ユーザを認証でき，それによって，前記多様な装置の間で単一使用承認のユーザ認証を提供し，
　前記制御器は，前記多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップを設定し，該システムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換する，ことを特徴とするネットワーク。
　　【請求項１４】
　前記認証エージェントは，ユーザに装置固有ユーザＩＤの入力を要請し，装置固有認証制御を通じて前記装置固有ユーザＩＤを検証することによって，前記ユーザを認証することを特徴とする請求項１３に記載のネットワーク。
　　【請求項１５】
　前記制御器は，前記システムＩＤマップから他の装置の装置固有ユーザＩＤを照会することによって，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換することを特徴とする請求項１３又は１４に記載のネットワーク。
　　【請求項１６】
　一装置がユーザを認証する能力がないとき，該一装置は，ユーザ認証のために装置固有認証制御を行う他の装置に，該一装置の認証エージェントから前記制御器を介して認証要請を送信することによって認証を委任し，
　該他の装置は，前記認証要請を受けて，ユーザに装置固有ユーザＩＤの入力を要求し，ユーザが入力した装置固有ユーザＩＤを該他の装置の装置固有認証制御を利用して検証し，ユーザが入力した装置固有ユーザＩＤが承認されると，前記制御器を介して該一装置の認証エージェントに承認メッセージを送信する，ことを特徴とする請求項１３に記載のネットワーク。
　　【請求項１７】
　前記ユーザ認証のために装置固有認証制御を行う前記一装置は，前記ユーザに装置固有ユーザＩＤを要請し，前記装置固有認証制御を利用して前記装置固有ユーザＩＤを検証することを特徴とする請求項１６に記載のネットワーク。
　　【請求項１８】
　前記制御器は，前記他の装置に前記他の装置固有ユーザＩＤを提供し，前記他の装置は，自身の装置固有認証制御を利用して前記提供された他の装置固有ユーザＩＤに基づいて前記ユーザを認証することによって，多様な装置の間で単一使用承認のユーザ認証を提供することを特徴とする請求項１３に記載のネットワーク。」
　
第３．当審拒絶理由
　当審による平成２５年１０月１８日付けの拒絶理由（以下，これを「当審拒絶理由」という）は，概略，以下のとおりである。
　
「第４．拒絶理由 
 １）この出願は，明細書，特許請求の範囲及び図面の記載が下記の点で不備であるから，特許法第３６条第４項第１号及び第６項第１号，第２号に規定する要件を満たしていない。 
 ２）本件出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　 
 　　　　　　　　　　　　　　　　記 
 　 
１．３６条６項１号について 
（１）省略
（２）省略
　
２．３６条６項２号について 
（１）上記「１．３６条６項１号について」で指摘した，本願の請求項１，請求項１２，及び，請求項２１に記載された， 
「ユーザが提供した装置固有のＩＤ」， 
 に関して，本願の請求項３の， 
「ユーザに装置固有のユーザＩＤを要請する」， 
 本願の請求項１４及び，本願の請求項２３の， 
「ユーザに装置固有のユーザＩＤを要請し」， 
 という記載を考慮して，上記引用の請求項１，請求項１２，及び，請求項２１に記載の「提供」が，“認証のためにユーザＩＤを，装置に入力すること”と解釈した場合，“ユーザＩＤを提供される装置”は，“提供されたユーザＩＤを認証するための情報を，何時，どのように，誰，或いは，何によって設定されたのか”，本願の全ての請求項，発明の詳細な説明，及び，図面に記載された内容を加味しても，不明である。 
（「ユーザＩＤ，パスワードの初期設定は周知である」といった主張では，上記指摘の拒絶理由は解消しない。各装置に対しての設定方法が周知であっても，ユーザＩＤの変換と言った構成まで踏まえると，本願の場合は，ユーザＩＤの設定は重要な意味を持つことに留意されたい。） 
 　 
（２）本願の請求項１に， 
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップ」， 
「ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換するステップ」， 
 　と記載され，本願の請求項１２に， 
「装置固有ユーザＩＤをネットワーク全域のユーザＩＤに転換し，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換する」， 
　と記載され，更に，本願の請求項２１に， 
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換し，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換する」， 
 と記載され，本願の請求項２に， 
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに，そしてその逆にも転換するマップを活用する」， 
 　本願の請求項１３，及び，請求項２２に， 
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するか，またはその逆にも転換するマップを活用する」， 
と記載され，更に，本願の請求項４に， 
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップは，システムＩＤマップを利用して，前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤにマッピングする」， 
　本願の請求項１５に， 
「システムＩＤマップを利用して前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤにマッピングすることによって，前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換する」， 
　本願の請求項２４に， 
「システムＩＤマップを利用して装置固有ユーザＩＤをネットワーク全域ユーザＩＤにマッピングすることによって，前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換する」， 
　と記載され，本願の請求項５に， 
「ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換するステップは，前記システムＩＤマップから他の装置の装置固有ユーザＩＤを照会する」， 
　と記載され，本願の請求項１６に， 
「システムＩＤマップから他の装置の装置固有ユーザＩＤを照会することによって，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換する」， 
　本願の請求項２５に， 
「システムＩＤマップから他の装置の装置固有ＩＤを照会することによって，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換する」， 
　と記載されていて，該記載中の「ネットワーク全域ユーザＩＤ」とは，“個々のユーザに対して設定される，ネットワーク全域で共通のユーザＩＤ”といったものを表現するものであると解される。 
　では，この「ネットワーク全域ユーザＩＤ」とは，“誰”，或いは，“何”によって，どのように設定されたものであるか，そして，各「装置固有ユーザＩＤ」との間で，相互変換するための関係，即ち，「システムＩＤマップ」を，どのように構築しているのか，本願の請求項各項の記載を参酌しても不明である。 
 　 
（３）省略
　
（４）本願の請求項３，請求項６，請求項１０，請求項１１，請求項１４，請求項２０，請求項２３，請求項２９は，本願の請求項１，請求項１２，及び，請求項２１の何れかを，直接・間接に引用するものであるから，上記（１），及び，（２）で指摘の明確でない構成を内包し，且つ，本願の請求項３，請求項６，請求項１０，請求項１１，請求項１４，請求項２０，請求項２３，請求項２９に記載の事項を加味しても，上記指摘の明確でない構成が明確になるものでもない。 
　よって，本願の請求項１〜請求項２９に係る発明は，明確ではない。 
　
３．３６条４項１号について
（１）本願の請求項１等に記載された， 
「ユーザが提供した装置固有のＩＤ」， 
　及び，本願の請求項２等に記載された， 
「装置固有のＩＤをネットワーク全域ユーザＩＤに，そしてその逆に転換するマップを活用する」， 
　並びに，本願の請求項４等に記載された， 
「システムＩＤマップ」， 
　に関して，本願明細書の発明の詳細な説明においては，特に重要な「システムＩＤマップ」に関して，本願明細書の段落【０００９】に， 
「ＳＳＯシステムは，装置固有のユーザＩＤをシステム全域のユーザＩＤに転換し，また，その逆にも転換するマップを活用する」， 
　同段落【００１６】に， 
「ＳＳＯシステムは，装置固有のユーザＩＤをシステム全体的ユーザＩＤに，そしてその逆にも転換するマップを利用する」， 
　同段落【００１８】に， 
「ソフトウェアとして具現されるシステム全域ユーザ識別マップ１１６」，
「システム全域ユーザ識別マップ１１６は，ネットワーク１０内の各装置からの固有ユーザＩＤをシステム全域ユーザＩＤにマッピングする」， 
　同段落【００１９】に， 
「ステップ２１０：認証プラグイン１１２が装置固有のユーザＩＤを認証ディレクトリ１１０に伝達する。認証ディレクトリ１１０は，システムＩＤマップ１１６を使用してその装置固有のユーザＩＤをシステムユーザＩＤにマッピングする。 
ステップ２１２：認証ディレクトリ１１０は，システムＩＤマップ１１６から装置１０４の装置固有ＩＤを照会してそれを認証プラグイン１１４に送る」， 
　同段落【００２１】に， 
「システム全域ユーザ識別マップ３１６を含む認証ディレクトリ３１０」，
「システム全域ユーザ識別マップ３１６は，ネットワーク１０内のそれぞれの装置から装置固有のユーザＩＤをシステム全域ユーザＩＤにマッピングする」， 
　同段落【００２４】に， 
「システム全域ユーザ識別マップ５１６を含む認証ディレクトリ５１０」，
「システム全域ユーザ識別マップ５１６は，ネットワーク１０内のそれぞれの装置から装置固有のユーザＩＤをシステム全域ユーザＩＤにマッピングする」， 
　同段落【００２５】に， 
 「ステップ６１４：認証プラグイン５１２が認証ディレクトリ５１０にシステムＩＤマップ５１６から装置固有ユーザＩＤをシステムＩＤにマッピングすることを要請する」， 
　同段落【００３４】に， 
「１１６　システム識別マップ」， 
　という記載が存在するものの，上記引用の記載からでは，「全域ユーザＩＤ」がどのようなもので，“誰”，或いは，“何”によって，どのように，各ユーザ毎に設定され，どのようにして，各装置に個別に設定されている装置固有ユーザＩＤとの対応関係を生成し「システムＩＤマップ」を生成し得るのか，全く不明である。 
　本願明細書，及び，図面の記載を全て勘案しても，上記指摘の不明点は解消しない。 
 　 
（２）本願の請求項７等に記載された， 
「一装置がユーザを認証する能力がなければ，ユーザ認証のために他の装置に認証を委任する」， 
　に関して，本願明細書の発明の詳細な説明には，例えば，その段落【００２２】，及び，【図３】において， 
“認証機能を有しない装置３００が，認証を，認証機能を有している装置３０４に依頼する”一連の処理過程が記載されているが， 
　「装置３０４」が，「装置３００」を認証するために用いる「装置３００」固有のユーザＩＤは，何時，“誰”，或いは，“何”によって，どのように設定されたのか，本願明細書の発明の詳細な説明，及び，図面に記載された事項からは不明である。 
（装置３００は，認証機能を有していない。即ち，装置に，ユーザを認証するための，ユーザＩＤ，及び，パスワードを設定するための機能も有してないと考えるのが妥当である。
　すると，装置３００については，他の何らかの手法によって，個別のユーザＩＤを設定しなければならないが，そのような構成に関しては，本願明細書中には，何ら記載されていない。） 
 　 
　よって，本願明細書の発明の詳細な説明な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。 
　
４．２９条２項について 
　上記１．〜３．に指摘したとおり，本願の請求項１〜請求項２９は，発明の詳細な説明に記載されていない事項を含み，明確でなく，発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものではないが， 
　本願の請求項１〜請求項２９を，一応，その字句どおりのものとして，以下の検討を行う。 
 　
（１）請求項１，請求項１２，及び，請求項２１に関して 
ア．引用刊行物に記載の発明 
　本願の第１国出願前に既に公知である，米国特許第６６２９２４６号明細書（２００３年９月３０日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。 
　
Ａ．「A single sign-on mechanism is provided which allows a user to provide different passwords to different sites while still only having to remember a single “master” password. In general, the user enters the master password into a client-side module that is responsible for providing passwords to restricted sites. When a restricted site requests a password, the client-side module generates a site-specific password that is derived from (1) the master password and (2) site-specific information. According to one embodiment, the techniques used to derive the site-specific password are such that the master password cannot be determined based on the site-specific password. 
　After deriving the site-specific password, the client-side module provides the site-specific password to the restricted site to authenticate the user at the restricted site.」（５欄３１行〜４５行） 
（まだ一つの「マスター」パスワードを覚えなければならないだけの間，ユーザーが異なるパスワードを異なるサイトに提供することができる，シングル−サインオン・メカニズムが提供される。普通，ユーザは，制限されたサイトに，パスワードを提供することに責任を負っている，クライアント−サイド・モジュールに，マスタ・パスワードを入力する。制限されたサイトが，パスワードを要求すると，クライアント−サイド・モジュールは，（１）マスタ・パスワードと，（２）サイトに特有の情報から，導出される，サイトに特有のパスワードを生成する。一実施例に従って，サイトに特有のパスワードを導出するために用いられる手法は，マスタ・パスワードが，サイトに特有のパスワードに基づいて決定することができないようなものである。
　サイト特有のパスワードが導出されると，クライアント−サイド・モジュールは，制限されたサイトで，ユーザを認証するために，制限されたサイトに，サイトに特有のパスワードを提供する。当審にて訳出。以下，同じ。） 
　
Ｂ．「At step 204 , the sign-on applet determines whether there is another instance of the sign-on applet already running on the client. If another instance of the sign-on applet is not already running on the client, then control passes to step 208 where the sign-on applet requests the master password from the user. If, on the other hand, another instance of the sign-on applet is already running on the client, then the user would have already entered the master password into the previously-existing sign-on applet, and control passes to step 206 . At step 206 , the newly-arrived sign-on applet obtains the master password from the previously-existing sign-on applet.  
　At step 210 , the sign-on applet obtains site-specific data. The site-specific data may be any data that specifically identifies the site to which the user is seeking access. For example, site-specific data may be the URL of the web site that the user is attempting to access. Alternatively, the site-specific data may the IP address of the site the user is attempting to access, or a combination of the URL and the IP address of the site. Various other forms of site-specific data may be used. Consequently, the present invention is not limited to any particular type of site-specific data.  
　According to one embodiment, the site-specific data is encoded in the CodeBase of the applet. In such an embodiment, the site-specific data may be obtained in step 210 by extracting the CodeBase of the applet.  
　At step 212 , the applet derives a site-specific password based on the master password and the site-specific data.」（６欄４６行〜７欄６行） 
（ステップ２０４において，サイン−オン・アプレットは，クライアント上で，既に動作している，他のサイン−オン・アプレットのインスタンスが存在しているかを，決定する。他のサイン−オン・アプレットのインスタンスが，クライアント上で，既に動作していなければ，制御は，サイン−オン・アプレットが，ユーザからの，マスタ・パスワードを要求する，ステップ２０８に渡る。他方，サイン−オン・アプレットの他のインスタンスが，クライアント上で，既に動作している場合は，ユーザは，以前に存在しているサイン−オン・アプレットに，マスタ・パスワードを，既に入力しているので，制御は，ステップ２０６に渡る。ステップ２０６において，新たに到着したサイン−オン・アプレットは，前もって存在しているサイン−オン・アプレットから，マスタ・パスワードを得る。 
 　ステップ２１０において，サイン−オン・アプレットは，サイトに特有なデータを得る。サイトに特有なデータは，ユーザが，アクセスしようとするサイトを，明確に識別する，任意のデータであり得る。例えば，サイトに特有なデータは，ユーザが，アクセスしようと試みるサイトのＵＲＬであり得る。あるいは，サイトに特有なデータは，ユーザが，アクセスしようと試みるサイトのＩＰアドレス，或いは，サイトの，ＵＲＬとＩＰアドレスの組であり得る。サイトに特有なデータの，他の様々な形式が用いられ得る。その結果として，本発明は，サイトに特有なデータの，どんな特有なタイプについても，制限はない。 
　一実施例に従うと，サイトに特有なデータは，アプレットのコード・ベースにおいて符号化される。この実施例において，サイトに特有なデータは，アプレットのコード・ベースを展開することによって，ステップ２１０において，得られ得る。 
　ステップ２１２において，アプレットは，マスタ・パスワードと，サイトに特有なデータとに基づく，サイト特有のパスワードを，導出する。） 
　
　Ｃ．「At step 214 , the site-specific password generated at step 212 is transmitted to the web server that controls the restricted access web site. 」（７欄３０行〜３２行） 
（ステップ２１４において，ステップ２１２において生成されたサイト特有のパスワードは，アクセスが制限されたウェブ・サイトを制御するウェブ・サーバに送信される。） 
　
（ア）上記Ａの「A single sign-on mechanism is provided which allows a user to provide different passwords to different sites while still only having to remember a single “master” password.（まだ一つの「マスター」パスワードを覚えなければならないだけの間，ユーザーが異なるパスワードを異なるサイトに提供することができる，シングル−サインオン・メカニズムが提供される。）」という記載から，引用刊行物１が，“シングル−サインオンに関連するものである”ことが読み取れる。 
　
（イ）上記Ｃの「the site-specific password generated at step 212 is transmitted to the web server that controls the restricted access web site.（ステップ２１２において生成されたサイト特有のパスワードは，アクセスが制限されたウェブ・サイトを制御するウェブ・サーバに送信される。）」という記載から，引用刊行物１には， 
“ユーザの要求を受け付け，それをサーバに送信するクライアントと，クライアントから送信されるユーザの要求を受信する，ウェブ・サイトを制御するサーバが存在する”ことが記載されていると読み取れる。 
　
（ウ）上記Ａの「the user enters the master password into a client-side module that is responsible for providing passwords to restricted sites. When a restricted site requests a password, the client-side module generates a site-specific password that is derived from (1) the master password and (2) site-specific information.（ユーザは，制限されたサイトに，パスワードを提供することに責任を負っている，クライアント−サイド・モジュールに，マスタ・パスワードを入力する。制限されたサイトが，パスワードを要求すると，クライアント−サイド・モジュールは，（１）マスタ・パスワードと，（２）サイトに特有の情報から，導出される，サイトに特有のパスワードを生成する。）」という記載，上記Ａの「After deriving the site-specific password, the client-side module provides the site-specific password to the restricted site to authenticate the user at the restricted site.（サイト特有のパスワードが導出されると，クライアント−サイド・モジュールは，制限されたサイトで，ユーザを認証するために，制限されたサイトに，サイトに特有のパスワードを提供する。）」という記載，及び，上記Ｂの「At step 204 , the sign-on applet determines whether there is another instance of the sign-on applet already running on the client.（ステップ２０４において，サイン−オン・アプレットは，クライアント上で，既に動作している，他のサイン−オン・アプレットのインスタンスが存在しているかを，決定する。）」という記載，上記Ｂの「If, on the other hand, another instance of the sign-on applet is already running on the client, then the user would have already entered the master password into the previously-existing sign-on applet, and control passes to step 206 . At step 206 , the newly-arrived sign-on applet obtains the master password from the previously-existing sign-on applet. At step 210 , the sign-on applet obtains site-specific data. （サイン−オン・アプレットの他のインスタンスが，クライアント上で，既に動作している場合は，ユーザは，以前に存在しているサイン−オン・アプレットに，マスタ・パスワードを，既に入力しているので，制御は，ステップ２０６に渡る。ステップ２０６において，新たに到着したサイン−オン・アプレットは，前もって存在しているサイン−オン・アプレットから，マスタ・パスワードを得る。ステップ２１０において，サイン−オン・アプレットは，サイトに特有なデータを得る。）」という記載，並びに，上記（イ）において引用した上記Ｃの記載から，引用刊行物１には，
“ユーザは，制限されたサイトにアクセスするために，クライアントに，マスタ・パスワードを入力し，前記マスタ・パスワードと，前記制限されたサイトに特有の情報から，前記制限されたサイト特有のパスワードが導出され，前記特有のパスワードを用いて，ユーザを認証し，前記制限されたサイトにサインオンし，前記ユーザが，前記制限されたサイトにサインオンした状態で，他の制限されたサイトへのアクセスを要求し場合，前記特有のパスワードから，前記マスタ・パスワードを取得し，該マスタ・パスワードと，前記他の制限されたサイトに特有の情報から，前記他の制限されたサイト特有のパスワードが導出され，前記他の制限されたサイト特有のパスワードが，前記他の制限されたサイトを制御するサーバに送信される”ことが記載されていると読み取れる。 
　そして，“他の制限されたサイトを制御するサーバ”に送信された，“他の制限されたサイト特有のパスワード”は，該サイトにサインオンするために，認証処理に用いられることは明らかである。 
　
　以上，（ア）〜（ウ）において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されていると認める。 
　
　シングル−サインオンに関連する方法であって， 
　ユーザが，制限されたサイトにアクセスするために，クライアントに，マスタ・パスワードを入力し，前記マスタ・パスワードと，前記制限されたサイトに特有の情報から，前記制限されたサイト特有のパスワードが導出され，前記特有のパスワードを用いて，ユーザを認証し，前記制限されたサイトにサインオンし，前記ユーザが，前記制限されたサイトにサインオンした状態で，他の制限されたサイトへのアクセスを要求し場合，前記特有のパスワードから，前記マスタ・パスワードを取得し，該マスタ・パスワードと，前記他の制限されたサイトに特有の情報から，前記他の制限されたサイト特有のパスワードが導出され，前記他の制限されたサイト特有のパスワードが，前記他の制限されたサイトを制御するサーバに送信され，前記他の制限されたサイト特有のパスワードを用いて，前記他の制限されたサイトにおいて，ユーザ認証される，方法。 
　
イ．本願の請求項１に係る発明と引用発明との対比 
（ア）引用発明における「シングル−サインオン」が， 
　本願の請求項１に係る発明（以下，これを「本願発明」という）における「単一使用承認のユーザ認証」に相当し， 
　引用発明における「制限されたサイト」は，「ユーザ」に対して，それぞれ，異なる，「特有のパスワード」を有するものであるから，“サイト固有の認証制御”を有すると言い得るものである。 
　引用発明における「制限されたサイト」も，本願発明における「装置」も，ともに，「ユーザ」の“アクセス要求先”である点で共通し，引用発明における「クライアント」と，「制限されたサイトを制御するサーバ」とが，ネットワークを介して接続されているのは明らかであって， 
　引用発明において，「ユーザが，制限されたサイトにアクセスするために，クライアントに，マスタ・パスワードを入力し，前記マスタ・パスワードと，前記制限されたサイトに特有の情報から，前記制限されたサイト特有のパスワードが導出され，前記特有のパスワードを用いて，ユーザを認証」することは，「ユーザ」が“マスタ・パスワードを入力する”「クライアント」上で処理されることは明らかであるから， 
　本願発明における「ユーザが提供した装置固有ユーザＩＤに基づいて装置固有認証制御を行う装置上でユーザを認証するステップ」とは， 
 “ユーザが提供した認証情報に基づいて認証制御を行う装置上でユーザを認証するステップ”である点で共通するので， 
　引用発明における「シングル−サインオンに関連する方法」，及び，「ユーザが，制限されたサイトにアクセスするために，クライアントに，マスタ・パスワードを入力し，前記マスタ・パスワードと，前記制限されたサイトに特有の情報から，前記制限されたサイト特有のパスワードが導出され，前記特有のパスワードを用いて，ユーザを認証」することと， 
　本願発明における「一つ以上の装置が装置固有の認証制御を備えている装置からなるネットワーク内の多様な装置間の単一使用承認のユーザ認証方法において，ユーザが提供した装置固有ユーザＩＤに基づいて装置固有認証制御を行う装置上でユーザを認証するステップ」とは， 
“一つ以上のアクセス要求先が，固有の認証制御を備えているアクセス要求先からなるネットワーク内の多様なアクセス要求先の単一使用印象のユーザ認証方法であって， 
　ユーザが提供した認証情報に基づいて認証制御を行う装置上でユーザを認証するステップ” 
　である点で共通する。 
　
（イ）引用発明において，「ユーザが，前記制限されたサイトにサインオンした状態で，他の制限されたサイトへのアクセスを要求し場合，前記特有のパスワードから，前記マスタ・パスワードを取得し，該マスタ・パスワードと，前記他の制限されたサイトに特有の情報から，前記他の制限されたサイト特有のパスワードが導出」されることは， 
“最初にサインオンした，制限されたサイトに特有なパスワードを，マスタ・パスワードに変換し，該変換されたマスタ・パスワードを，他の制限されたサイトに特有の情報を用いて，他の制限されたサイトに特有のパスワードに変換する”と言い得るものであるから，
　本願発明における「前記装置固有認証制御を行う装置上でユーザが認証されたならば，ユーザ認証に用いられた前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップと，前記ネットワーク全域ユーザＩＤを他の装置固有ユーザＩＤに転換するステップ」とは， 
“一つのアクセス要求先においてユーザが認証されたならば，ユーザ認証に用いられた一つのアクセス先に固有の認証情報を，共通の認証情報に転換するステップと，前記共通の認証情報を，他のアクセス要求先に固有の認証情報に転換するステップ” 
　である点で共通する。 
　
（ウ）引用発明において，「前記他の制限されたサイト特有のパスワードを用いて，前記他の制限されたサイトにおいて，ユーザ認証される」ことと，
　本願発明における「他の装置は，前記他の装置の装置固有ユーザＩＤに基づいて前記ユーザを認証できる」こととは， 
“他のアクセス要求先は，前記他のアクセス要求先に固有の認証情報に基づいて，ユーザを認証できる”点で共通する。 
 　
　以上，（ア）〜（ウ）において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。 
　
［一致点］ 
　一つ以上のアクセス要求先が，固有の認証制御を備えているアクセス要求先からなるネットワーク内の多様なアクセス要求先の単一使用承認のユーザ認証方法であって， 
　ユーザが提供した認証情報に基づいて認証制御を行う装置上でユーザを認証するステップと， 
　一つのアクセス要求先においてユーザが認証されたならば，ユーザ認証に用いられた一つのアクセス先に固有の認証情報を，共通の認証情報に転換するステップと，前記共通の認証情報を，他のアクセス要求先に固有の認証情報に転換するステップとを含み， 
　前記他のアクセス要求先は，前記他のアクセス要求先に固有の認証情報に基づいて，前記ユーザを認証できる，単一使用承認のユーザ認証方法。 
　
［相違点１］ 
“アクセス要求先”に関して， 
　本願発明においては，「装置」であるのに対して， 
　引用発明においては，「制限されたサイト」である点。 
　
［相違点２］ 
“ユーザが提供した認証情報”に関して， 
　本願発明においては，「装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「マスタ・パスワード」である点。 
　
［相違点３］ 
“一つのアクセス先に固有の認証情報”に関して， 
　本願発明においては，「装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「制限されたサイトに特有のパスワード」である点。 
 　 
［相違点４］ 
“共通の認証情報”に関して， 
　本願発明においては，「ネットワーク全域ユーザＩＤ」であるのに対して， 
　引用発明においては，「マスタ・パスワード」である点。 
　
［相違点５］ 
“アクセス要求先に固有の認証情報”に関して 
　本願発明においては，「他の装置の装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「他の制限されたサイト特有のパスワード」である点。 
 　 
ウ．相違点についての当審の判断 
（ア）［相違点１］について 
　本願の第１国出願前に既に公知である，特表２００４−５０６２８１号公報（２００４年２月２６日公表，以下，これを「引用刊行物２」という）に， 
　
Ｄ．「【００２４】 
　本発明を公知，公用の文献及び装置に関して明瞭にするために，米国特許第５，９５６，４８７号を考察されたい。この文献は，装置にウェブアクセス機能を組み込んで，当該装置の制御のための低価格で，広くアクセス可能であり且つ強化されたユーザインターフェース機能を可能にすることに関するものである。該装置のウェブサーバは，装置のウェブページを介して当該装置用のユーザインターフェース機能へのアクセスを提供する。当該装置におけるネットワークインターフェースは，ウェブブラウザによる上記ウェブページへのアクセスを，該ウェブブラウザのユーザが該ウェブページを介して当該装置用のユーザインターフェース機能にアクセスするように，可能にする。この文献は，装置用の制御機能を備えるウェブページを超えて，使用のコンテキストについての情報を提供するようなことは教示も示唆もしていないことに注意されたい。一方，本発明は装置を，当該装置自体又はネットワーク上の代用品を介してトピックサーバにさせる。」（下線は，説明の都合上，当審にて附加したものである。） 
　
　と記載されてもいるように，“各装置にウェブページを割当て，アクセスする”ようなことは，本願の第１国出願前に，当業者には広く知られた技術事項であり，引用発明においても，「サイト」を，各「装置」の「サイト」とすることは，当業者が適宜なし得る事項である。 
　よって，相違点１は，格別のものではない。 
　
（イ）［相違点２］〜［相違点５］について 
　本願発明においては，“一の装置に対する認証を行う場合，ユーザが，該装置固有ユーザＩＤを提供（入力と解釈）し，該装置固有ユーザＩＤを用いて，ユーザ認証を行う”ものであるのに対して， 
　引用発明においては，“最初にサインオンするサイトに対して，ユーザが，マスタ・パスワードを入力し，該マスタ・パスワードを，サイトに特有のパスワードに変換している”，即ち，“ユーザが，直接，サイトに特有のパスワードを入力する”訳ではない。 
　しかしながら，原審が平成２３年７月８日付けの拒絶理由で引用した，本願の第１国出願前に既に公知である，国際公開第２００４／０５９４１５号（２００４年７月１５日公開，以下，これを「引用刊行物３」という）に， 
　
Ｅ．「The user completes an authentication operation with respect to domain 410; this authentication operation is handled by point-of-contact server 412. The authentication operation is triggered when the user requests access to some resource that requires an authenticated identity, e.g., for access control purposes or for personalization purposes. Point-of- contact server 412 may invoke a legacy authentication service, or it may invoke trust proxy 414 to validate the user's presented authentication credentials . Domain 410 becomes the user's home domain for the duration of the user's federated session. 」（４７頁２９行〜４８頁４行）
（【０１２２】 
　ユーザはドメイン４１０に関する認証操作を完了し，この認証操作はポイントオブコンタクト・サーバ４１２によって処理される。たとえば，アクセス制御またはパーソナライゼーションのために，認証済みＩＤを必要とする何らかのリソースへのアクセスをユーザが要求すると，認証操作がトリガされる。ポイントオブコンタクト・サーバ４１２は，レガシー認証サービスを呼び出す場合もあれば，トラスト・プロキシ４１４を呼び出してユーザが提示した認証信用証明情報を妥当性検査する場合もある。ドメイン４１０は，ユーザのフェデレーテッド・セッションの期間中，ユーザのホーム・ドメインになる。ファミリーである日本語公報，特表２００６−５１５４４７号公報より引用，以下，同じ。）
　
Ｆ．「Domain 420 receives the token that is issued by domain 410 at point-of-contract server 422, which invokes trust proxy 424 to validate the token and perform identity mapping. In this case, since trust proxy 424 is not able to map the user from a local identifier for domain 410 to a local identifier for domain 420, trust proxy 424 invokes trust broker 450, which validates the token and performs the identifier mapping. After obtaining the local identifier for the user, trust proxy 424, possibly through its security token service, can generate any local tokens that are required by the back-end applications at domain 420, e.g., a Kerberos token may be required to facilitate single-sign-on from the point-of-contact server to the application server. After obtaining a locally valid token, if required, the point-of-contact server is able to build a local session for the user. The point-of-contract server will also handle coarse-grained authorization of user requests and forward the authorized requests to the appropriate application servers within domain 420.」（５０頁２３行〜５１頁４行） 
（【０１２８】 
　ドメイン４２０は，ポイントオブコンタクト・サーバ４２２においてドメイン４１０によって発行されたトークンを受信し，そのポイントオブコンタクト・サーバはトラスト・プロキシ４２４を呼び出して，トークンを妥当性検査し，ＩＤマッピングを実行する。この場合，トラスト・プロキシ４２４はドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングすることができないので，トラスト・プロキシ４２４はトラスト・ブローカ４５０を呼び出し，そのトラスト・ブローカがトークンを妥当性検査し，ＩＤマッピングを実行する。そのユーザ用のローカルＩＤを入手した後，トラスト・プロキシ４２４は，おそらくそのセキュリティ・トークン・サービスにより，ドメイン４２０においてバックエンド・アプリケーションによって要求される任意のローカル・トークンを生成することができ，たとえば，ポイントオブコンタクト・サーバからアプリケーション・サーバへのシングル・サインオンを容易にするためにＫｅｒｂｅｒｏｓトークンが要求される可能性がある。必要であれば，ローカルで有効なトークンを入手した後，ポイントオブコンタクト・サーバはそのユーザ用のローカル・セッションを構築することができる。また，ポイントオブコンタクト・サーバは，ユーザ要求の粗雑な許可を処理し，ドメイン４２０内の適切なアプリケーション・サーバに許可された要求を転送することになる。） 
　
　と記載されているように，“ユーザが，最初のドメインに認証を要求するためのローカルＩＤの認証を行い，該最初のドメインのローカルＩＤを，次に認証を要求するドメインのローカルＩＤに変換する”ことが開示されており，引用発明も，引用刊行物３に記載の発明も，共に，シングル−サインオンに関するものであるから，引用発明において，変換の対象を，「パスワード」から「ユーザＩＤ」とし，“最初のサイトにサインオンする際に，最初のサイトに特有なユーザＩＤを用いて，サインオンを行い，認証後，該ユーザＩＤを，マスタのユーザＩＤに変換し，該マスタのユーザＩＤを，次のサイトにサインオンする際に，該次のサイトに特有のユーザＩＤに変換する”よう構成することは，引用発明，及び，引用刊行物３に記載の発明を知り得る当業者であれば，適宜なし得る事項である。
　よって，相違点２〜相違点５は，格別のものではない。 
　
　以上のとおりであるから，本願発明は，引用発明，及び，引用刊行物２，並びに，引用刊行物３に記載の発明から，当業者が容易になし得たものである。 
　
　本願の請求項１２，及び，本願の請求項２１に係る発明は，発明のカテゴリが相違するものの，その構成は，実質的，本願発明と同一であるから，本願発明と同じく，引用発明，引用刊行物２，並びに，引用刊行物３に記載の発明から，当業者が容易になし得たものである。 
　
（２）省略
（３）省略」
　
第４．当審の判断
１．当審拒絶理由の「２．３６条６項２号について」に関して
（１）補正後の請求項１に，
「前記ネットワーク内の多様な装置のうち装置固有認証制御を行う装置にユーザが入力した装置固有ユーザＩＤに基づいて，前記装置固有認証制御を行う装置上で該装置に対応する所定の装置固有ユーザＩＤ認証情報を用いてユーザを認証するステップ」（以下，「引用記載１」という），
　と記載され，また，同じく補正後の請求項１に，
「ユーザ認証に用いられた前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用されるネットワーク全域ユーザＩＤに転換するステップ」（以下，「引用記載２」という），
「前記装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップは，前記多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換し，前記システムＩＤマップは，前記多様な装置のうちの１つ以上にて具現化される制御器にて設定される」（以下，「引用記載３」という），
　と記載されている。
　
ア．上記「第３．当審拒絶理由」において引用した，当審拒絶理由の「２．３６条６項２号について」の（１）において，
「上記引用の請求項１，請求項１２，及び，請求項２１に記載の「提供」が，“認証のためにユーザＩＤを，装置に入力すること”と解釈した場合，“ユーザＩＤを提供される装置”は，“提供されたユーザＩＤを認証するための情報を，何時，どのように，誰，或いは，何によって設定されたのか”，本願の全ての請求項，発明の詳細な説明，及び，図面に記載された内容を加味しても，不明である。 
（「ユーザＩＤ，パスワードの初期設定は周知である」といった主張では，上記指摘の拒絶理由は解消しない。各装置に対しての設定方法が周知であっても，ユーザＩＤの変換と言った構成まで踏まえると，本願の場合は，ユーザＩＤの設定は重要な意味を持つことに留意されたい。） 」，
　と指摘した点に関して，引用記載１においては，平成２３年１１月１１日付けの手続補正により補正された請求項（以下，これを「補正前の請求項」という）１に記載された「ユーザ提供した装置固有ユーザＩＤ」が，「ユーザが
入力
　補正後の請求項８，及び，請求項１３に記載された内容についても同様に不明点は解消していない。
　そこで，上記指摘の点について，本願明細書の発明の詳細な説明に記載された内容についても検討すると，発明の詳細な説明においては，「所定の装置固有ユーザＩＤ認証情報」という用語自体が存在せず，提供されたユーザＩＤを認証するための「認証情報」に関しても，その段落【００１９】に，
ａ．「ステップ２０２：装置１００内の認証エージェント１０２が装置固有の方法を使用してユーザの認証情報を要請する。
ステップ２０４：ユーザがその要請に応答し，その応答は，認証エージェント１０２によって受信される。
ステップ２０６：認証エージェント１０２は，ユーザ入力を検証し，ユーザが権限のあるユーザであるか否かを確認する。
ステップ２０８：認証エージェント１０２が装置固有のユーザＩＤを認証プラグイン１１２に送る。」
　という記載が存在し，上記引用の記載からは，「ユーザ入力を検証」すること，及び，「ユーザが権限のあるユーザであるか確認」した後に，「認証エージェント」が，「装置固有のユーザＩＤ」を，「認証プラグイン」に送っていることは読み取れるが，「ユーザ入力」と「装置固有のユーザＩＤ」との関係は不明であり，更に，「ユーザ入力を検証」するための情報，及び，「装置固有のユーザＩＤ」が何処からもたらされたものであるかも不明である。
　更に，「認証情報」に関して，発明の詳細な説明には，当審拒絶理由にも引用した，段落【００２２】に，
ｂ．「ステップ４００：ユーザが装置３００（例えば，図１の自動温度調節器１５）上のアプリケーション３１８を始動する。
ステップ４０２：認証エージェント３０２は，自体認証方式を有しておらず，認証プラグイン３１２に認証要請を送る。この要請には，装置３００が装置３０４に自身にかえて認証を委任する委任メッセージが含まれる。
ステップ４０４：認証プラグイン３１２がその要請を認証ディレクトリ３１０に送る。
ステップ４０６：認証ディレクトリ３１０がその要請で委任情報を抽出し，その要請を認証プラグイン３１４に送る。
ステップ４０８：認証プラグイン３１４が装置３０４上の認証エージェント３０６に認証要請を送る。
ステップ４１０：認証エージェント３０６が装置３０４の装置固有方式を使用して，ユーザにユーザ認証情報を要請する。
ステップ４１２：ユーザが認証情報を入力（提供）する。
ステップ４１４：認証エージェント３０６がユーザログイン情報を検証及び承認する。
ステップ４１６：認証エージェント３０６が認証プラグイン３１４に装置固有のユーザＩＤを伝送する。
ステップ４１８：認証プラグイン３１４が認証ディレクトリに装置固有ＩＤをシステム全域ユーザＩＤにマッピングすることを要請する。
ステップ４２０：認証ディレクトリが認証プラグイン３１２に“ＯＫ”メッセージを送る。ステップ４２２：認証プラグイン３１２が再び“ＯＫ”メッセージを認証エージェント３０２に送って認証エージェント３０２がユーザを認証し，それにより，ユーザは，認証されてＳＳＯを通じて装置上のアプリケーションを使用できる。」
　という記載が存在し，上記ｂの記載から，「装置３０４」の「認証エージェント３０６」が，「ユーザにユーザ認証情報を要請」し，「ユーザが認証情報を入力（提供）」し，「認証エージェント３０６がユーザログイン情報を検証及び承認」し，「認証エージェント３０６が認証プラグイン３１４に装置固有のユーザＩＤを伝送する」ことは読み取れる。
　しかしながら，上記ｂの記載内容からは，「ユーザ」が，「装置３０４」に入力する「認証情報」，「認証エージェント３０６」が，「検証及び承認」する「ユーザログイン情報」，及び，「認証エージェント３０６」が，「認証プラグイン３１４」に伝送する「装置固有のユーザＩＤ」との関係が不明であり，上記ｂの記載内容からは，該「ユーザログイン情報」を「検証及び承認」するための情報，及び，「装置固有のユーザＩＤ」が，何処から，誰，或いは，何によってもたらされたものであるか，不明である。
　発明の詳細な説明には，上記ａ，ｂに引用した記載の他，
ｃ．「【００２５】
　図４のＳＳＯシステム３９０の段階的な動作の例が，以下で図７のステップ６００〜６２６と共に説明される。
ステップ６００：ユーザが装置５００及び５０４上のアプリケーション５１８を始動する。
ステップ６０２：認証エージェント５０２は，認証プラグイン５１２に認証要請を送る。
ステップ６０４：認証プラグイン５１２が認証エージェント５０２にユーザ認証を要請する。
ステップ６０６：認証エージェント５０２がユーザに認証情報を要求する。
ステップ６０８：ユーザが装置５００にログインして，認証情報（すなわち，装置固有ユーザＩＤ）を提供する。
ステップ６１０：認証エージェント５０２が装置固有ユーザ認証情報を認証プラグイン５１２に送る。
ステップ６１２：認証プラグイン５１２がユーザ認証を検証及び承認する。
ステップ６１４：認証プラグイン５１２が認証ディレクトリ５１０にシステムＩＤマップ５１６から装置固有ユーザＩＤをシステムＩＤにマッピングすることを要請する。
ステップ６１６：認証ディレクトリがそのシステムＩＤを装置５０４の装置固有ユーザＩＤにマッピングして，その装置固有ユーザＩＤを認証プラグイン５１４に送る。
ステップ６１８：認証プラグイン５１４が装置固有ユーザＩＤを認証エージェント５０６に送る。
ステップ６２０：認証エージェント５０６がユーザを検証及び承認する。
ステップ６２２：認証エージェント５０６がアプリケーション５１８にユーザが検証されたことを知らせる。
ステップ６２４：認証エージェント６０２がアプリケーション５１８にユーザが検証されたことを知らせる。
ステップ６２６：認証エージェント５０６が認証プラグイン５１４に“ＯＫ”メッセージを送り，認証プラグイン５１４が“ＯＫ”を認証ディレクトリ５１０に送り，それにより，ユーザが二つの装置で何れも認証されてＳＳＯとしてそのアプリケーションを使用できる。」
　という記載が存在し，上記ｃに引用の記載と，関連する本願の図面【図４】に開示された内容とから，「ＳＳＯシステム３９０の段階的な動作の例」においては，「装置５００」の「認証エージェント５０２がユーザに認証情報を要求する」と，「ユーザが装置５００にログインして，認証情報（すなわち，装置固有ユーザＩＤ）を提供」し，「認証エージェント５０２が装置固有ユーザ認証情報を認証プラグイン５１２に送」り，「認証プラグイン５１２がユーザ認証を検証及び承認」することが読み取れる。
　しかしながら，上記ｃの記載内容では，「ユーザ」が，「装置５００にログイン」する際に用いる“ログイン情報”が“何”で，「装置５００」は，該“ログイン情報”を“何”によって“認証”，或いは，“承認”しているのか，即ち，“ユーザが，装置５００にログインする際に，装置５００が，ユーザのログイン情報を認証，或いは，承認するための情報が，何時，どのように，誰，或いは，何によって，装置５００に設定されたのか”不明であり，「ユーザ」の「装置５００にログイン」することと，「ユーザ」が，「装置５００」に，「提供する」，「認証情報（すなわち，装置固有ユーザＩＤ）」との関係も不明である。
　仮に，「ＳＳＯシステム３９０の段階的な動作の例」において，「装置５００」への「ログイン」は，「ステップ６１２：認証プラグイン５１２がユーザ認証を検証及び承認する」ことをもって完了するものであり，上記ｃの「ユーザ認証」が，「ユーザ」が，「装置５００」に「提供」した，「認証情報（すなわち，装置固有ユーザＩＤ）」であるとしても，この場合は，「検証及び承認」は，「制御器５０８」の「認証プラグイン５１２」が行っていることになるが，この場合でも，“「ユーザ」が「提供」した，「認証情報（すなわち，装置固有ユーザＩＤ）」を「認証プラグイン５１２」において「検証及び承認」するために用いる“情報”を，何時，どのように，誰，或いは，何によって，認証プラグイン５１２に設定されたのか”不明である。
　よって，引用記載１に関して，補正後の請求項各項の記載内容，及び，本願明細書の発明の詳細な説明，並びに，図面に記載された内容を検討しても，当審拒絶理由において指摘した，「“提供されたユーザＩＤを認証するための情報を，何時，どのように，誰，或いは，何によって設定されたのか”，本願の全ての請求項，発明の詳細な説明，及び，図面に記載された内容を加味しても，不明である」点は解消しない。
　補正後の請求項８，及び，請求項１３に記載された内容についても同様である。
　
イ．同じく，当審拒絶理由の「２．３６条６項２号について」の（２）において，
「「ネットワーク全域ユーザＩＤ」とは，“個々のユーザに対して設定される，ネットワーク全域で共通のユーザＩＤ”といったものを表現するものであると解される。 
 　では，この「ネットワーク全域ユーザＩＤ」とは，“誰”，或いは，“何”によって，どのように設定されたものであるか，そして，各「装置固有ユーザＩＤ」との間で，相互変換するための関係，即ち，「システムＩＤマップ」を，どのように構築しているのか，本願の請求項各項の記載を参酌しても不明である」，
　と指摘した点に関して，「ネットワーク全域ユーザＩＤ」，及び，「システムＩＤマップ」については，引用記載２，及び，引用記載３の他，補正後の請求項１に，
「
ネットワーク全域ユーザＩＤ
　前記他の装置は，前記
ネットワーク全域ユーザＩＤ
　と記載されている他，補正後の他の請求項に，
「前記
ネットワーク全域ユーザＩＤ
　前記
システムＩＤマップ
「ユーザが認証されたならば，前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用される
ネットワーク全域ユーザＩＤ
ネットワーク全域ユーザＩＤ
「制御器は，前記多様な装置の装置固有ユーザＩＤ及び前記
ネットワーク全域ユーザＩＤ
システムＩＤマップ
システムＩＤマップ
ネットワーク全域ユーザＩＤ
「制御器は，前記
システムＩＤマップ
ネットワーク全域ユーザＩＤ
「ユーザが認証されたならば，前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用される
ネットワーク全域ユーザＩＤ
ネットワーク全域ユーザＩＤ
「制御器は，前記多様な装置の装置固有ユーザＩＤ及び前記
ネットワーク全域ユーザＩＤ
システムＩＤマップ
システムＩＤマップ
ネットワーク全域ユーザＩＤ
「制御器は，前記
システムＩＤマップ
ネットワーク全域ユーザＩＤ
　という記載が存在している。これら引用の補正後の請求項各項の記載内容から，「ネットワーク全域ユーザＩＤ」，及び，「システムＩＤマップ」に関して，
“１の装置における，あるユーザの装置固有ユーザＩＤを，システムＩＤマップを用いて，そのユーザのネットワーク全域ユーザＩＤに変換し，更に，システムＩＤマップを用いて，前記ネットワーク全域ユーザＩＤを，そのユーザの他の装置における装置固有のユーザＩＤに変換する”ことが行われていること，及び，該“変換”は，「制御器」によって実現されていることは読み取れる。
　しかしながら，上記で引用した請求項各項の記載内容からは，
　複数存在するであろう個々の「ユーザ」毎に個別の「ネットワーク全域ユーザＩＤ」を，どのタイミングで，“誰”，或いは，“何”によって，どのようにして設定されるのか，仮に，個々の「ユーザ」が，「制御器」に対して，それぞれの「ネットワーク全域ユーザＩＤ」を行うとしても，どのタイミングで，どのようにして行っているか不明である。
　そして，「ネットワーク」に，「装置」が複数存在する場合，各「装置」毎の「ユーザ」の「ＩＤ」であると想定される，「装置固有ユーザＩＤ」と，同じ「ユーザ」の「ネットワーク全域ユーザＩＤ」とを，どのタイミングで，“誰”，或いは，“何”が，どのようにして対応付けを行って，「システムＩＤマップ」を構築しているのかも不明である。
　そこで，これら「ネットワーク全域ユーザＩＤ」と，「システムＩＤマップ」に関して，本願明細書の発明の詳細な説明に記載された内容についても検討すると，該「ネットワーク全域ユーザＩＤ」と，「システムＩＤマップ」について，発明の詳細な説明には，上記ア．における検討の際に引用した，段落【００１９】，【００２２】，及び，【００２５】に記載されている程度の内容しか存在しておらず，「ネットワーク全域ユーザＩＤ」を，どのタイミングで，どのようにして設定し，「システムＩＤマップ」を，“誰”，或いは，“何”が，どのタイミングで，どのようにして設定しているか不明である。
　以上のとおりであるから，補正後の請求項各項に記載された内容，及び，発明の詳細な説明に記載された内容を検討しても，当審拒絶理由の「２．３６条６項２号について」の（２）において“不明である”と指摘した事項は，依然として不明のままである。
　
（２）当審拒絶理由の「２．３６条６項２号について」の（４）において指摘した事項について，補正後の請求項２〜請求項７（補正前の請求項３，請求項５〜請求項７，及び，請求項１０，並びに，請求項１１）は，補正後の請求項１（補正前の請求項１）を直接・間接に引用し，補正後の請求項９〜請求項１２（補正前の請求項１４，請求項１６，請求項１７，及び，請求項２０）は，補正後の請求項８（補正前の請求項１２）を引用し，補正後の請求項１４〜請求項１８（補正前の請求項２３，請求項２５，請求項２６，請求項２８，及び，請求項２９）は，補正後の請求項１３（補正前の請求項２１）を直接・間接に引用しているので，当審拒絶理由の「２．３６条６項２号について」の（１），及び，（２）において指摘した明確でない構成を内包し，かつ，上記ア．，及び，イ．において検討したとおり，補正後の請求項各項に記載された内容，及び，本願明細書の発明の詳細な説明の内容から，当審拒絶理由の「２．３６条６項２号について」の（１），及び，（２）において指摘した明確でない構成が明確になるものではない。
　
　以上，（１），及び，（２）において検討したとおり，補正後の請求項１〜請求項１８に係る発明は，依然として，明確ではない。
　
２．当審拒絶理由の「３．３６条４項１号について」に関して
　当審拒絶理由の「３．３６条４項１号について」において，
「（１）本願の請求項１等に記載された， 
 　・・・・・・・・・・・・ 
 　及び，本願の請求項２等に記載された， 
 「装置固有のＩＤをネットワーク全域ユーザＩＤに，そしてその逆に転換するマップを活用する」， 
 　並びに，本願の請求項４等に記載された， 
 「システムＩＤマップ」， 
 　に関して，本願明細書の発明の詳細な説明においては，特に重要な「システムＩＤマップ」に関して，
　　　・・・・・（中略）・・・・・・
 という記載が存在するものの，上記引用の記載からでは，「全域ユーザＩＤ」がどのようなもので，“誰”，或いは，“何”によって，どのように，各ユーザ毎に設定され，どのようにして，各装置に個別に設定されている装置固有ユーザＩＤとの対応関係を生成し，「システムＩＤマップ」を生成し得るのか，全く不明である。 
 　本願明細書，及び，図面の記載を全て勘案しても，上記指摘の不明点は解消しない。」
　と指摘した点について，本件手続補正を踏まえて以下に検討する。
　補正後の請求項１に記載された，「ネットワーク全域ユーザＩＤ」と，「システムＩＤマップ」に関して，本願明細書の発明の詳細な説明，及び，図面には，当審拒絶理由において引用し，上記「１．当審拒絶理由の「２．３６条６項２号について」に関して」においても引用した程度の内容しか記載されておらず，当審拒絶理由において引用し，上記「１．当審拒絶理由の「２．３６条６項２号について」に関して」においても引用した記載内容からは，当審拒絶理由において指摘したとおり，
“「ネットワーク全域ユーザＩＤ」がどのようなもので，“誰”，或いは，“何”によって，どのように，各ユーザ毎に設定され，どのようにして，各装置に個別に設定されている装置固有ユーザＩＤとの対応関係を生成し「システムＩＤマップ」を生成し得るのか，全く不明である。”
　本願明細書の発明の詳細な説明，及び，図面の，当審拒絶理由において引用した記載内容，及び，「１．当審拒絶理由の「２．３６条６項２号について」に関して」において引用した記載内容以外の記載内容を検討したも，当審拒絶理由の「３．３６条４項１号について」の（１）において指摘の不明点は，依然として解消しない。
　
３．当審拒絶理由の「４．２９条２項について」に関して 
　上記１．，及び，２．に指摘したとおり，補正後の請求項１に係る発明（以下，これを「本願発明」という）は，明確でなく，発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものではないが， 
　本願発明を，その補正後の請求項１に記載された，その字句どおりのものとして，以下の検討を行う。
　
（１）本願発明
　本願発明は，上記「第２．本願発明について」において，補正後の請求項１として引用した記載の事項により特定されるものである。
　
（２）引用刊行物に記載の発明
　上記「第３．当審拒絶理由」に引用した当審拒絶理由において，引用刊行物１として引用した，本願の第１国出願前に既に公知である，米国特許第６６２９２４６号明細書（２００３年９月３０日公開）には，当審拒絶理由において引用した引用刊行物１の記載内容からみて,次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　シングル−サインオンに関連する方法であって， 
　ユーザが，制限されたサイトにアクセスするために，クライアントに，マスタ・パスワードを入力し，前記マスタ・パスワードと，前記制限されたサイトに特有の情報から，前記制限されたサイト特有のパスワードが導出され，前記特有のパスワードを用いて，ユーザを認証し，前記制限されたサイトにサインオンし，前記ユーザが，前記制限されたサイトにサインオンした状態で，他の制限されたサイトへのアクセスを要求し場合，以前の入力情報から，前記マスタ・パスワードを取得し，該マスタ・パスワードと，前記他の制限されたサイトに特有の情報から，前記他の制限されたサイト特有のパスワードが導出され，前記他の制限されたサイト特有のパスワードが，前記他の制限されたサイトを制御するサーバに送信され，前記他の制限されたサイト特有のパスワードを用いて，前記他の制限されたサイトにおいて，ユーザ認証される，方法。
　
（３）本願発明と引用発明との対比
　本願発明は，概略，補正前の請求項１に係る発明における発明特定事項である，
「装置固有ユーザＩＤをネットワーク全域ユーザＩＤに転換するステップ」に対して，
「多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換し，前記システムＩＤマップは，前記多様な装置のうちの１つ以上にて具現化される制御器にて設定される」，
　という限定事項を附加したものであるから，当審拒絶理由において検討した，補正前の請求項１に係る発明と引用発明との一致点，及び，相違点を考慮すると，本願発明と引用発明との一致点，及び，相違点は，次のとおりである。
　
［一致点］ 
　一つ以上のアクセス要求先が，固有の認証制御を備えているアクセス要求先からなるネットワーク内の多様なアクセス要求先の単一使用承認のユーザ認証方法であって， 
　ユーザが入力した認証情報に基づいて認証制御を行う装置上でユーザを認証するステップと， 
　共通の認証情報を，他のアクセス要求先に固有の認証情報に転換するステップとを含み，
　前記他のアクセス要求先は，前記他のアクセス要求先に固有の認証情報に基づいて，前記ユーザを認証できる，単一使用承認のユーザ認証方法。 
　
［相違点１］ 
“アクセス要求先”に関して， 
　本願発明においては，「装置」であるのに対して， 
　引用発明においては，「制限されたサイト」である点。 
　
［相違点２］ 
“ユーザが入力した認証情報”に関して， 
　本願発明においては，「装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「マスタ・パスワード」である点。 
　
［相違点３］
　本願発明においては，「装置固有認証制御を行う装置上でユーザが認証されたならば，ユーザ認証に用いられた前記装置固有ユーザＩＤを，前記ネットワーク内の多様な装置の使用承認のために共通に利用されるネットワーク全域ユーザＩＤに転換するステップ」を有するものであるのに対して，
　引用発明においては，“マスタ・パスワードを，サイト特有のパスワードに変換して認証を行った後，該サイト特有のパスワードを，再び，マスタ・パスワードに変換する”構成を有するか不明である点。
　
［相違点４］ 
“一つのアクセス先に固有の認証情報”に関して， 
　本願発明においては，「装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「制限されたサイトに特有のパスワード」である点。 
 　 
［相違点５］ 
“共通の認証情報”に関して， 
　本願発明においては，「ネットワーク全域ユーザＩＤ」であるのに対して， 
　引用発明においては，「マスタ・パスワード」である点。 
　
［相違点６］ 
“アクセス要求先に固有の認証情報”に関して 
　本願発明においては，「他の装置の装置固有ユーザＩＤ」であるのに対して， 
　引用発明においては，「他の制限されたサイト特有のパスワード」である点。 
　
［相違点７］
　本願発明においては，「多様な装置の装置固有ユーザＩＤ及び前記ネットワーク全域ユーザＩＤを互いにマッピングするシステムＩＤマップに基づき前記装置固有ユーザＩＤを前記ネットワーク全域ユーザＩＤに転換し，前記システムＩＤマップは，前記多様な装置のうちの１つ以上にて具現化される制御器にて設定される」ものであるのに対して，
　引用発明においては，「マスタ・パスワード」と，「他の制限されたサイト特有のパスワード」との変換に，「マップ」に相当するものを用いること，及び，該「マップ」が設定される「制御器」に相当する構成を有する点については，特に言及されていない点。
　
（４）相違点についての当審の判断
ア．［相違点１］について
　上記引用の当審拒絶理由の「４．２９条２項について」の「（１）請求項１，請求項１２，及び，請求項２１に関して」における「ウ．相違点についての当審の判断」の「（ア）［相違点１］について」において検討したとおり，当審拒絶理由において，引用刊行物２として引用した，本願の第１国出願前に既に公知である，特表２００４−５０６２８１号公報（２００４年２月２６日公表）に記載された事項から，相違点１に係る事項は，引用発明，及び，引用刊行物２に記載の発明とから，当業者が容易になし得たものであるから，相違点１は，格別のものではいない。
　
イ．［相違点２］，［相違点４］〜［相違点６］について
　上記引用の当審拒絶理由の「４．２９条２項について」の「（１）請求項１，請求項１２，及び，請求項２１に関して」における「ウ．相違点についての当審の判断」の「（イ）［相違点２］〜［相違点５］について」において検討したとおり，当審拒絶理由において，引用刊行物３として引用した，国際公開第２００４／０５９４１５号（２００４年７月１５日公開）に記載された事項から，相違点２，相違点４〜相違点６に係る事項は，引用発明と，引用刊行物３に記載の発明とから，当業者が容易になし得たものであるから，相違点２，相違点４〜相違点６は，格別のものではない。
　
ウ．［相違点３］について
　一つの装置固有のユーザＩＤから，他の装置固有のユーザＩＤに変換する点は，引用刊行物２に記載されているので，引用発明においても，入力されている「マスタ・パスワード」を用いるのに替えて，一旦「サイト特有のパスワード」に変換したものを，再度「マスタ・パスワード」に変換するよう構成することは，当業者が必要に応じて，適宜なし得る事項である。
　よって，相違点３は，格別のものではない。
　
　ここで，審判請求人は，平成２６年１月２２日付けの意見書において，
「引用刊行物１は，以下を課題とした発明を開示するものであります。
「以上に基づき，セキュリティを危険にさらすことなく，ユーザが複数のパスワードを記憶しなければならないことを回避することを可能にする手法を提供することが望まれる。
　発明の概要
　なおも単一のマスタ・パスワードを覚えさえすればよいようにしながら，サーバ毎に異なるパスワードを用いてユーザが多数のサーバにサインオンすることを可能にするようにして，クライアント−サーバシステムにおいてユーザを認証する方法及びシステムが提供される。」（引用刊行物１の第２欄第４０−５０行）
　そして，引用刊行物１は，ユーザが単一の“マスタ”パスワードのみを記憶しながら異なるサイトに異なるパスワードを提供する構成を開示しています（引用刊行物１の第５欄第３０−５９行など）。
 
　仮に，引用刊行物３に記載の発明を引用発明に適用して「最初のサイトに特有なユーザＩＤを用いて，サインオン」を行うようにするとすれば，引用刊行物１に記載の発明が解決しようとする課題を解決することができません。故に，引用刊行物１の教示を受けた当業者が，「最初のサイトに特有なユーザＩＤを用いて，サインオン」を行うように引用発明を変更することはないと思料いたします。」
　と主張し，更に，同意見書において，当審拒絶理由において，引用刊行物３として引用し，原審のおける平成２３年７月８日付けの拒絶理由（以下，これを「原審拒絶理由」という）において，引用文献１として引用した，国際公開第２００４／０５９４１５号（２００４年７月１５日公開）について，
「さらに，上記回答書にて詳述いたしましたように，引用刊行物３（上記回答書において“引用文献１”）は，本願発明が含む「ユーザ認証に利用された前記装置固有ユーザＩＤを，・・・ネットワーク全域ユーザＩＤに転換するステップ」に相当する構成を開示するものではありません。」
　と主張しているが，本願発明のように，複数の機器それぞれに設定された異なるＩＤ・パスワードを用いて，それぞれの機器にログインするような手法自体は，当業者と言わず，一般に広く知られた周知の技術事項である。
　そして,引用発明において，個々のサイトにログインするためのサイト特有のパスワードと，マスタ・パスワードを用いて，該マスタ・パスワードを，個別のサイトにログインする際に，サイト特有のパスワードに変換してログインする技術が開示されている以上，上記で検討したように，変換の対象をＩＤとすることに格別の困難は見出せず，また，引用発明において，マスタ・パスワードと，サイト特有のパスワード相互の対応関係が存在することは明らかであるから，周知技術を勘案すれば，最初に何れかのサイトにログインした後，該ログイン情報を，共通の情報に変換するようなことは，当業者が適宜なし得る事項に過ぎない。
　当審拒絶理由においては，引用刊行物３は，“ローカルの認証情報で認証した後，該ローカルの認証情報を，別の認証情報に変換する”という点を引用したに過ぎない。
　引用発明と，引用刊行物３に係る発明から，引用発明において，
“共通の認証情報を入力して認証することに替えて，ローカルの認証情報で認証した後に，共通の認証情報に変換する”よう構成することは，当業者が，必要に応じて適宜なし得る事項である。
　よって，請求人の上記引用の意見書における主張は，採用できない。
　
エ．［相違点７］について
　当審拒絶理由において，引用刊行物４として引用した，特開２００３−１３２０２２号公報の【図２】，及び，該【図２】に関連するとして，
「【解決手段】共通認証サーバ１は，ユーザ毎に共通認証情報を予め記憶するユーザ情報データベース１４と，利用サービス毎に利用される各ユーザのユーザ認証情報を予め記憶する利用サービス認証変換データベース１５とを準備し，
端末２１から共通認証情報と利用サービスを識別するサービスＩＤとを受信した場合にその受信した共通認証情報がユーザ情報データベース１４に登録されているかを確認し，登録していた場合に受信した共通認証情報を基に利用サービス認証変換データベース１５から受信したサービスＩＤに対応するユーザ認証情報を抽出し，その抽出したユーザ認証情報を利用サービス認証サーバ３に認証させる
　が存在していて，本願発明においては，「制御器」が，どのように配置されているものであるか明確でなく，補正後の請求項１に記載された内容では，本願発明においては，「装置固有認証制御を行う装置」が，「制御器」を有する構成も含み得るものであるが，仮に，「装置固有認証制御を行う装置」と，「制御器」とが別体であるとすると，当審拒絶理由においても指摘したように，引用刊行物４に記載された「利用サービス認証変換データベース」，及び，「共通認証サーバ」が，本願発明の「システムＩＤマップ」，及び，「制御器」に相当するものであって，認証の変換に「データベース」を用いることは，本願の第１国出願前に，当業者には周知の技術事項であるから，引用発明においても，「マスタ・パスワード」と，「サイト特有のパスワード」との変換に，「データベース」，即ち，「マップ」を用いるよう構成することは，当業者が適宜なし得る事項である。
　また，「装置固有認証制御を行う装置」と，「制御器」とが一体であるとしても，引用発明において，「クライアント」に，“認証のためのデータベース”を持たせるよう構成することに，格別の困難は見出せない。
　よって，相違点７は，格別のものではない。
　
　上記で検討したごとく，相違点１〜相違点７はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　よって，本願発明は，本件手続補正後の記載内容を加味しても，引用発明，及び，引用刊行物２〜引用刊行物４記載の周知技術に基づいて当業者が容易に発明をすることができたものであるから，依然として，特許法第２９条第２項の規定により特許を受けることができない。
　
第５．むすび
　以上に検討したとおり，本願は，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　また，本願発明を，補正後の請求項１に記載のとおりのものとしても，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。