【事件の表示】
　特願２００９−５０１０１４「システム間シングルサインオン」拒絶査定不服審判事件〔平成１９年　９月２７日国際公開，ＷＯ２００７／１０７９６９，平成２１年１１月２６日国内公表，特表２００９−５４１８１７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００７年３月２２日（パリ条約による優先権主張外国庁受理２００６年３月２２日　中華人民共和国）を国際出願日とする出願であって，
　平成２０年１１月１９日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，平成２２年３月２３日付けで審査請求がなされ，平成２４年３月２２日付けで審査官により拒絶理由が通知され，これに対して平成２４年６月２１日付けで意見書が提出されると共に手続補正がなされたが，平成２４年１２月２５日付けで審査官により拒絶査定がなされ（発送；平成２４年１２月２８日），これに対して平成２５年４月２６日付けで審判請求がなされると共に手続補正がなされ，平成２５年７月２５日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２５年１０月４日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２６年１月８日付けで回答書の提出があったものである。
　
第２．平成２５年４月２６日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成２５年４月２６日付け手続補正を却下する。
　
　［理由］
　
１．補正の内容
　平成２５年４月２６日付けの手続補正（以下，「本件手続補正」という）により，平成２４年６月２１日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　システム間シングルサインオン（ＳＳＯ）のための方法であって，
　第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，ステップと，
　前記第２のシステムに関する前記ユーザのＩＤ情報を前記第２のシステムに送信するステップと
　を含むことを特徴とする方法。
　　【請求項２】
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成し，前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記署名を前記第２のシステムに送信するステップと，
　前記第２のシステムにおいて，受信した前記署名を審査することによって，前記ユーザのＩＤ情報を認証するステップと
　をさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記ユーザは，最初に前記第１のシステムにサインオンする方法であって，
　前記第２のシステムにおいて，前記ユーザのＩＤ情報が認証された場合，前記ユーザが前記第２のシステムにサインオンすることを許可するステップをさらに含むことを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記署名を作成するステップは，前記ユーザが前記第２のシステムにサインオンしようとする知らせを受けた上で行われることを特徴とする請求項２に記載の方法。
　　【請求項５】
　前記署名を作成するステップは，前記第２のシステムによって前記第１のシステムにリダイレクトされるログオン要求を受けた上で行われることを特徴とする請求項２に記載の方法。
　　【請求項６】
　前記署名が作成された上で，前記第２のシステムへ前記ログオン要求をリダイレクトするステップをさらに含むことを特徴とする請求項５に記載の方法。
　　【請求項７】
　前記ユーザは，最初に前記第１のシステムにサインオンする方法であって，
　前記第２のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報を受信後，前記ユーザが前記第２のシステムにサインオンすることを許可するステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項８】
　前記ユーザが前記第１のシステムにまだサインオンしていない場合，前記ユーザのＩＤを認証するために，前記ユーザにサインオンすることを要求するステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項９】
　前記第２のシステムに，前記第１のシステムから前記ユーザがリダイレクトされたことを示すステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項１０】
　システム間シングルサインオン（ＳＳＯ）のための方法であって，
　第１のシステムにおいて，第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，ステップと，
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成するステップと，
　前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記署名を前記第２のシステムに送信するステップと
　を含むことを特徴とする方法。
　　【請求項１１】
　前記第１のシステムにおいて，前記署名または前記ユーザのＩＤ情報を前記第２のシステムに送信する前に，前記署名または前記第２のシステムに関する前記ユーザのＩＤ情報にタイムスタンプを押すステップと，
　前記第２のシステムにおいて，タイムスタンプ情報を確認することによって，前記署名または前記ユーザのＩＤ情報を認証するステップと
　をさらに含むことを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　前記第２のシステムにおいて，受信した前記署名を審査することによって，前記第２のシステムに関する前記ユーザのＩＤ情報を認証するステップと，
　前記ユーザのＩＤ情報が認証された場合，前記ユーザが前記第２のシステムにサインオンすることを許可するステップと，前記第２のシステムにサインオンした前記ユーザの権限を制限するステップと
　をさらに備えることを特徴とする請求項１０に記載の方法。
　　【請求項１３】
　システム間シングルサインオン（ＳＳＯ）手順を有効にするためのコンピュータ実行可能指示を含む，１つ以上のコンピュータ可読媒体であって，前記手順は，
　第１のシステムにおいて，第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関する前記ユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，ステップと，
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成するステップと，
　前記署名を前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記第２のシステムに送信するステップと
　を含むことを特徴とするコンピュータ可読媒体。
　　【請求項１４】
　システム間ユーザサインオンを認証するためのシステムであって，
　ユーザＩＤライブラリおよびユーザＩＤマッピングデータを含む，データストレージであって，ユーザＩＤマッピングデータは，前記システムに関するユーザＩＤ情報とパートナーシステムに関するユーザＩＤ情報との間のマッピング関係を定義するデータストレージであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，データストレージと，
　前記データストレージと通信しているＩＤ認証デバイスであって，前記データストレージに保存される前記ユーザＩＤライブラリを使用して，ログオンを要求しているユーザのＩＤを認証し，前記システムに関する前記ユーザのＩＤ情報を判断するＩＤ認証デバイスとを備え，
　前記システムは，前記システムに関する前記ユーザのＩＤ情報から，前記ユーザＩＤマッピングデータを使用して，前記パートナーシステムに関する前記ユーザのＩＤ情報を判断することを特徴とするシステム。
　　【請求項１５】
　システム間ユーザサインオンを認証するためのシステムであって，
　前記システムに関するユーザＩＤ情報を保存する，データストレージと，
　パートナーシステムから受信するユーザのＩＤ情報に添付される署名を復号化する署名認証デバイスと，
　前記データストレージに保存された前記ユーザＩＤ情報を使用して，前記パートナーシステムから受信した前記ユーザのＩＤ情報を認証するＩＤ認証デバイスであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，ＩＤ認証デバイスと
　を備えることを特徴とするシステム。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　システム間シングルサインオン（ＳＳＯ）のための方法であって，
　第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれ，前記追加情報には，追加の署名情報が含まれる，ステップと，
　前記第２のシステムに関する前記ユーザのＩＤ情報を前記第２のシステムに送信するステップと
　を含むことを特徴とする方法。
　　【請求項２】
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成し，前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記署名を前記第２のシステムに送信するステップと，
　前記第２のシステムにおいて，受信した前記署名を審査することによって，前記ユーザのＩＤ情報を認証するステップと
　をさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記ユーザは，最初に前記第１のシステムにサインオンする方法であって，
　前記第２のシステムにおいて，前記ユーザのＩＤ情報が認証された場合，前記ユーザが前記第２のシステムにサインオンすることを許可するステップをさらに含むことを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記署名を作成するステップは，前記ユーザが前記第２のシステムにサインオンしようとする知らせを受けた上で行われることを特徴とする請求項２に記載の方法。
　　【請求項５】
　前記署名を作成するステップは，前記第２のシステムによって前記第１のシステムにリダイレクトされるログオン要求を受けた上で行われることを特徴とする請求項２に記載の方法。
　　【請求項６】
　前記署名が作成された上で，前記第２のシステムへ前記ログオン要求をリダイレクトするステップをさらに含むことを特徴とする請求項５に記載の方法。
　　【請求項７】
　前記ユーザは，最初に前記第１のシステムにサインオンする方法であって，
　前記第２のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報を受信後，前記ユーザが前記第２のシステムにサインオンすることを許可するステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項８】
　前記ユーザが前記第１のシステムにまだサインオンしていない場合，前記ユーザのＩＤを認証するために，前記ユーザにサインオンすることを要求するステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項９】
　前記第２のシステムに，前記第１のシステムから前記ユーザがリダイレクトされたことを示すステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項１０】
　システム間シングルサインオン（ＳＳＯ）のための方法であって，
　第１のシステムにおいて，第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，前記追加情報には，追加の署名情報が含まれる，ステップと，
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成するステップと，
　前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記署名を前記第２のシステムに送信するステップと
　を含むことを特徴とする方法。
　　【請求項１１】
　前記第１のシステムにおいて，前記署名または前記ユーザのＩＤ情報を前記第２のシステムに送信する前に，前記署名または前記第２のシステムに関する前記ユーザのＩＤ情報にタイムスタンプを押すステップと，
　前記第２のシステムにおいて，タイムスタンプ情報を確認することによって，前記署名または前記ユーザのＩＤ情報を認証するステップと
　をさらに含むことを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　前記第２のシステムにおいて，受信した前記署名を審査することによって，前記第２のシステムに関する前記ユーザのＩＤ情報を認証するステップと，
　前記ユーザのＩＤ情報が認証された場合，前記ユーザが前記第２のシステムにサインオンすることを許可するステップと，前記第２のシステムにサインオンした前記ユーザの権限を制限するステップと
　をさらに備えることを特徴とする請求項１０に記載の方法。
　　【請求項１３】
　システム間シングルサインオン（ＳＳＯ）手順を有効にするためのコンピュータ実行可能指示を含む，１つ以上のコンピュータ可読媒体であって，前記手順は，
　第１のシステムにおいて，第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関する前記ユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，前記追加情報には，追加の署名情報が含まれる，ステップと，
　前記第１のシステムにおいて，前記第２のシステムに関する前記ユーザのＩＤ情報に添付される署名を作成するステップと，
　前記署名を前記第２のシステムに関する前記ユーザのＩＤ情報と共に，前記第２のシステムに送信するステップと
　を含むことを特徴とするコンピュータ可読媒体。
　　【請求項１４】
　システム間ユーザサインオンを認証するためのシステムであって，
　ユーザＩＤライブラリおよびユーザＩＤマッピングデータを含む，データストレージであって，ユーザＩＤマッピングデータは，前記システムに関するユーザＩＤ情報とパートナーシステムに関するユーザＩＤ情報との間のマッピング関係を定義するデータストレージであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，前記追加情報には，追加の署名情報が含まれる，データストレージと，
　前記データストレージと通信しているＩＤ認証デバイスであって，前記データストレージに保存される前記ユーザＩＤライブラリを使用して，ログオンを要求しているユーザのＩＤを認証し，前記システムに関する前記ユーザのＩＤ情報を判断するＩＤ認証デバイスとを備え，
　前記システムは，前記システムに関する前記ユーザのＩＤ情報から，前記ユーザＩＤマッピングデータを使用して，前記パートナーシステムに関する前記ユーザのＩＤ情報を判断することを特徴とするシステム。
　　【請求項１５】
　システム間ユーザサインオンを認証するためのシステムであって，
　前記システムに関するユーザＩＤ情報を保存する，データストレージと，
　パートナーシステムから受信するユーザのＩＤ情報に添付される署名を復号化する署名認証デバイスと，
　前記データストレージに保存された前記ユーザＩＤ情報を使用して，前記パートナーシステムから受信した前記ユーザのＩＤ情報を認証するＩＤ認証デバイスであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，前記追加情報には，追加の署名情報が含まれる，ＩＤ認証デバイスと
　を備えることを特徴とするシステム。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
　本件手続補正が，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件手続補正が，平成２０年１１月１９日付けで提出された明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文（以下，これを「当初明細書等」という）に記載した事項の範囲内でなされたものであるかについて，以下に検討する。
　
　本件手続補正によって，補正前の請求項１，請求項１０，請求項１３，請求項１４，及び，請求項１５に，
「追加情報は，追加の署名情報が含まれる」
　という記載が加えられたが，当初明細書等には，「追加情報は，追加の署名情報が含まれる」と同一の記載は存在しない。
　そこで，当初明細書等に記載された内容から，「追加情報は，追加の署名情報が含まれる」という記載内容は読み取れるかについて，以下に検討する。
　
　当初明細書等には，「追加の署名情報」に類似する記載として，段落【００４４】に，
「（１）情報（ウェブサイトＢに関するユーザＩＤ情報に署名される署名，およびその他の
追加署名情報
　という記載が存在するが，上記引用の段落【００４４】に記載された内容からでは，「追加署名情報」が，「追加情報」に含まれるものであるとは言えない。
　次に，「追加情報」に関して，当初明細書等の記載内容を見ていくと，当初明細書等に，
「【００３６】
　一致したＩＤ情報は，ログオンユーザ名およびパスワードなどの属性を含む場合があるが，システム間で異なる
追加属性
追加情報
「【００４９】
　ユーザＣが初めてウェブサイトＢを訪問している場合，タイムスタンプは，以前のタイムスタンプと比較することなく承認される必要がある場合があるが，署名およびユーザＩＤ情報が初めて適用されるため，この特別な状況において，リプレイのリスクは無い。ユーザＣが正真正銘の正当な繰り返し訪問を行っている場合，異なる，唯一の継続的なタイムスタンプを有する，現行の署名および以前の署名が別々に作成される。この技術を使用し，ユーザＣが特定の署名で正真正銘の訪問を行った場合，同一署名は，事実上失効する。この技術では，ウェブサイトＢが，
タイムスタンプなどの追加添付情報を含む
「【００６０】
　ウェブサイトＢに関するユーザＣのＩＤ情報は，データストレージ２２０に保存されるＩＤマッピングデータ２２６を使用して，ウェブサイトＡで判断される。例えば，ユーザＩＤマッピングデータ２２６がウェブサイトＡ／ウェブサイトＢ（Ａ／Ｂ）マッピングテーブルを含む場合，ＩＤ署名ジェネレータ２２２は，ウェブサイトＢに関するユーザＣのＩＤ情報を，マッピングテーブルを読み込むことによって取得してもよい。そしてＩＤ署名ジェネレータ２２２は，取り決められた署名アルゴリズムを使用して，
ウェブサイトＢに関するユーザＣのＩＤ情報，およびその他の追加情報（タイムスタンプ情報など）に署名する
　【００６１】
　ブロック３０４では，ウェブサイトＡは，ユーザＩＤ署名を含むログオン要求をウェブサイトＢに誘導する。ログオン要求では，ウェブサイトＡはさらに，ユーザＣにウェブサイトＡから来ているというラベルを付けてもよい。そのようなラベリングは，異なるサブドメイン名または
追加添付パラメータ
「【００６９】
　ブロック４００では，ユーザＣがウェブサイトＢにログオンし，特定のリソースにアクセスすることを要求する。これは，ユーザＣにより，ウェブサイトＢで直接開始されてもよいが，ウェブサイトＡがＣ２Ｃサイトである一方，ウェブサイトＢは，支払いサイトである，示される実施例においては，サインオンするための要求は，ウェブサイトＡからウェブサイトＢに向けられる可能性が高い。この場合，ログオン要求は，ウェブサイトＡから来ているものとして，ユーザＣを識別してもよい。そのような識別表示は，ログオン要求情報内に，異なるサブドメイン名，または
追加添付パラメータ
「【００７２】
  ブロック４０３では，ウェブサイトＡのＩＤ署名ジェネレータ２２２がユーザＩＤマッピングデータ２２６からユーザＣのウェブサイトＢに関するユーザＩＤ情報を読み出し，ウェブサイトＡおよびウェブサイトＢに取り決められた署名アルゴリズムを使用してユーザＩＤ情報からユーザＩＤ署名を生成する。
またユーザＩＤ署名は，タイムスタンプ情報などの追加情報もカバーする
　と，「追加情報」に類似する記載内容も含めて，上記引用の記載が存在している。
　しかしながら，何れの記載内容からも，「追加情報」が，「追加の署名情報」を含むことは読み取れず，特に，上記引用の段落【００６０】の，
「ウェブサイトＢに関するユーザＣのＩＤ情報，およびその他の追加情報（タイムスタンプ情報など）に署名する」，
　という記載，及び，同じく，上記引用の段落【００７２】の，
「またユーザＩＤ署名は，タイムスタンプ情報などの追加情報もカバーする」，
　という記載から，「タイムスタンプ」などの「他の追加情報」に「署名」されているので，「署名情報」が，「追加情報」に含まれるものでないことは明らかである。
　以上検討したとおりであるから，当初明細書等には，本件手続補正によって，上記指摘の請求項に付加された「追加情報は，追加の署名情報が含まれる」という記載は存在しておらず，更に，上記において指摘したとおり，当初明細書等に記載された内容から，「追加情報は，追加の署名情報が含まれる」という構成を読み取ることもできない。
　よって，本件手続補正は，当初明細書等に記載された範囲内でなされたものではない。
　
３．補正却下むすび
　したがって，本件手続補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成２５年４月２６日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２４年６月２１日付けの手続補正により補正された，上記「第２．平成２５年４月２６日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１として引用した，次の記載のとおりのものである。
　
「システム間シングルサインオン（ＳＳＯ）のための方法であって，
　第１のシステムに関するユーザのＩＤ情報を取得するステップと，
　前記第１のシステムにおいて，前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップであって，前記ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる，ステップと，
　前記第２のシステムに関する前記ユーザのＩＤ情報を前記第２のシステムに送信するステップと
　を含むことを特徴とする方法。」
　
第４．引用刊行物に記載の発明
　原審における平成２４年３月２２日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用された，本願の第１国出願前に既に公知である，特開２００２−３２４０５１号公報（２００２年１１月８日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【０００４】さて，複数のシステムが稼働している環境では，全てのシステムに対して同一のユーザアカウントで接続（ログイン）できること，すなわち，
あるユーザは，１回だけログイン名とパスワードを入力するだけで全てのシステムが利用可能となる（以下，シングルサインオンと称する）
・・・・・（中略）・・・・・
【０００６】ディレクトリサービスを利用するためには，対象となるシステム側にディレクトリサービスに接続するための機能が備わっていなければならない。しかしながら，
「レガシーシステム」と呼ばれるような旧いシステムでは，ディレクトリサービスに接続するための機能が備わっていないことが多い
【０００７】このため，
シングルサインオンの実現には，ディレクトリサービス上のユーザに対応するエントリに，予めレガシーシステムに対するアカウント情報を関連付け，これを参照することでユーザに意識させることなくログイン処理を行うといった方法がとられる
　
Ｂ．「【００３４】図３は，管理情報３１の木構造の例を示した図である。同図に示すように，管理情報３１は，節を表現する「ｔｏｐ」ディレクトリ３２，「ｊｐ」ディレクトリ３３，「ＦＸ」ディレクトリ３４，「Ｄｅｖｅｌｏｐｍｅｎｔ」ディレクトリ３５，「ｍａｐｐｉｎｇ＃００１」ディレクトリ３６−１，「ｍａｐｐｉｎｇ＃００２」ディレクトリ３６−２，「ｓｔｏｒａｇｅＺ」ディレクトリ３６−３，「ｓｔｏｒａｇｅＹ」ディレクトリ３６−４，「ｓｔｏｒａｇｅＸ」ディレクトリ３６−５の階層構造により構成される。また，ディレクトリ３６−１〜３６−５の直下には，それぞれ属性ファイル３７−１〜３７−５がおかれている。
【００３５】「ｓｔｏｒａｇｅＸ」ディレクトリ３６−５，「ｓｔｏｒａｇｅＹ」ディレクトリ３６−４，「ｓｔｏｒａｇｅＺ」ディレクトリ３６−３は，それぞれ文書管理システム（Ｘ）４０，文書管理システム（Ｙ）５０，文書管理システム（Ｚ）６０に関する情報を表している。つまり，属性ファイル３７−５，３７−４，３７−３に，文書管理システム（Ｘ）４０，文書管理システム（Ｙ）５０，文書管理システム（Ｚ）６０に関する情報が記述されている。
【００３６】図３に示した例では，
属性ファイル３７−５と属性ファイル３７−４には，それぞれ「ｕｓｅｒＭａｐｐｉｎｇＮａｍｅ＝ｍａｐｐｉｎｇ＃００１」といった記述が含まれている。この記述は，「ｍａｐｐｉｎｇ＃００１」という節であるディレクトリ３６−１の属性ファイル３７−１に記述されている情報を利用して文書管理システム（Ｘ）４０，文書管理システム（Ｙ）５０に接続する際のログイン処理を行うことを意味している
【００３７】同様に，
属性ファイル３７−３には，「ｕｓｅｒＭａｐｐｉｎｇＮａｍｅ＝ｍａｐｐｉｎｇ＃００２」といった記述が含まれており，「ｍａｐｐｉｎｇ＃００２」という節であるディレクトリ３６−２の属性ファイル３７−２に記述されている情報を利用して文書管理システム（Ｚ）６０に接続する際のログイン処理を行うことになる
　
Ｃ．「【００３８】ここで，
属性ファイル３７−１および属性ファイル３７−２の記述について説明する。属性ファイル３７−１，３７−２には，自システム（文書統合システム３０）でのアカウント情報と他システム（文書管理システム（Ｘ）４０等）でのアカウント情報の対応が記述されている
【００３９】図４は，属性ファイルの記述例を示した図であり，同図（ａ）は属性ファイル３７−１の記述例を，同図（ｂ）は属性ファイル３７−２の記述例を示している。
【００４０】
属性ファイル３７−１，３７−２は，自システムでのアカウント情報を「ユーザ名」として記述し，他システムでのアカウント情報を「他システムユーザ名」と「パスワード」として記述している
文書統合システム３０にユーザ名「ｓｕｚｕｋｉ」でログインするユーザが文書管理システム（Ｘ）４０若しくは文書管理システム（Ｙ）５０に接続する際には，ユーザ名「ｔａｒｏ．ｓｕｚｕｋｉ」で自動的にログイン処理されることになる
【００４１】なお，属性ファイル３７−１，３７−２において，自システムでのアカウント情報と他システムでのアカウント情報の対応は，必ずしもテーブル形式で記述されているとは限らず，両者の対応が記述できるならばどのような記述方法をとってもよい。」
　
Ｄ．「【００４３】まず，
ユーザが
文書統合システム３０へアクセスすると，文書統合システム３０は，ユーザを認証する認証処理を実行する（ステップ１０１）。この認証処理は，ユーザにユーザ名とパスワードを入力させることで行う
【００４４】認証処理の結果，ユーザの認証に失敗した場合には（ステップ１０２でＮＯ），エラーを通知する等のエラー処理を行って（ステップ１０３），処理を終了する。」
　
Ｅ．「【００６５】このため，
属性情報に変更箇所のみの差分情報を記述し
【００６６】図８は，属性ファイルへの差分情報の記述例を示した図である。同図においては，ユーザ名「ｓｕｚｕｋｉ」のユーザが文書管理システム（Ｙ）５０へ接続する際のアカウント情報に変更があった場合を示しており，
文書管理システム（Ｘ）４０へは，従来通り「ｔａｒｏ．ｓｕｚｕｋｉ」のユーザ名で接続できるが，文書管理システム（Ｙ）５０へは，「ｔａｒｏ２．ｓｕｚｕｋｉ」のユーザ名で接続する場合である。ただし，パスワードは，両者で同一であるとする
【００６７】この場合には，
属性情報として「ユーザ名」，「他システムユーザ名」，「パスワード」の他に，「差分情報」として「ｔａｒｏ２．ｓｕｚｕｋｉ（ｕｓｅｒＩＤ＠ｓｔｏｒａｇｅＹ）」を記述している
　
１．上記Ａの「
あるユーザは，１回だけログイン名とパスワードを入力するだけで全てのシステムが利用可能となる（以下，シングルサインオンと称する
　
２．上記Ｄの「
ユーザが
文書統合システム３０へアクセスすると，文書統合システム３０は，ユーザを認証する認証処理を実行する（ステップ１０１）。この認証処理は，ユーザにユーザ名とパスワードを入力させることで行う
　
３．上記Ｂの「
属性ファイル３７−５と属性ファイル３７−４には，それぞれ「ｕｓｅｒＭａｐｐｉｎｇＮａｍｅ＝ｍａｐｐｉｎｇ＃００１」といった記述が含まれている。この記述は，「ｍａｐｐｉｎｇ＃００１」という節であるディレクトリ３６−１の属性ファイル３７−１に記述されている情報を利用して文書管理システム（Ｘ）４０，文書管理システム（Ｙ）５０に接続する際のログイン処理を行うことを意味している
属性ファイル３７−３には，「ｕｓｅｒＭａｐｐｉｎｇＮａｍｅ＝ｍａｐｐｉｎｇ＃００２」といった記述が含まれており，「ｍａｐｐｉｎｇ＃００２」という節であるディレクトリ３６−２の属性ファイル３７−２に記述されている情報を利用して文書管理システム（Ｚ）６０に接続する際のログイン処理を行うことになる
　
４．上記３．において検討した事項と，上記Ｃの「
属性ファイル３７−１および属性ファイル３７−２の記述について説明する。属性ファイル３７−１，３７−２には，自システム（文書統合システム３０）でのアカウント情報と他システム（文書管理システム（Ｘ）４０等）でのアカウント情報の対応が記述されている
属性ファイル３７−１，３７−２は，自システムでのアカウント情報を「ユーザ名」として記述し，他システムでのアカウント情報を「他システムユーザ名」と「パスワード」として記述している
文書統合システム３０にユーザ名「ｓｕｚｕｋｉ」でログインするユーザが文書管理システム（Ｘ）４０若しくは文書管理システム（Ｙ）５０に接続する際には，ユーザ名「ｔａｒｏ．ｓｕｚｕｋｉ」で自動的にログイン処理されることになる
　そして，４．の上記において検討した事項と，上記Ａの「
シングルサインオンの実現には，ディレクトリサービス上のユーザに対応するエントリに，予めレガシーシステムに対するアカウント情報を関連付け，これを参照することでユーザに意識させることなくログイン処理を行うといった方法がとられる
　即ち，引用刊行物１の上記引用の記載内容から，引用刊行物１においては，
“文書統合システムログインしたユーザが，更に文書管理システムにログインする際に，属性ファイルに記述された，文書統合システムのアカウント情報に対応する，文書管理システムのアカウント情報が取得され，前記取得された文書管理システムのアカウント情報を，前記文書管理システムに入力することで，前記文書管理システムに自動的にログイン処理がなされる”ものであることが読み取れる。
　
５．上記４．においても引用した，上記Ｃの「
属性ファイル３７−１，３７−２は，自システムでのアカウント情報を「ユーザ名」として記述し，他システムでのアカウント情報を「他システムユーザ名」と「パスワード」として記述している
　
６．上記Ｅの「
属性情報に変更箇所のみの差分情報を記述
属性情報として「ユーザ名」，「他システムユーザ名」，「パスワード」の他に，「差分情報」として「ｔａｒｏ２．ｓｕｚｕｋｉ（ｕｓｅｒＩＤ＠ｓｔｏｒａｇｅＹ）」を記述している
文書管理システム（Ｘ）４０へは，従来通り「ｔａｒｏ．ｓｕｚｕｋｉ」のユーザ名で接続できるが，文書管理システム（Ｙ）５０へは，「ｔａｒｏ２．ｓｕｚｕｋｉ」のユーザ名で接続する場合である。ただし，パスワードは，両者で同一であるとする
“属性ファイルに記述される情報として，アカウント情報，他のシステムのアカウント情報に加えて，ユーザの認証に用いられる差分情報が含まれ，前記差分情報は，システムによって異なるものである”ことが読み取れる。
　
　以上１．〜６．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　シングルサインオンを実現するための方法であって，
　ユーザが，文書統合システムへアクセスすると，前記文書統合システムは，ユーザにユーザ名とパスワードを入力させ，
　前記文書統合システムログインしたユーザが，更に文書管理システムにログインする際に，属性ファイルに記述された，前記文書統合システムのアカウント情報に対応する，前記文書管理システムのアカウント情報が取得され，前記取得された文書管理システムのアカウント情報を，前記文書管理システムに入力することで，前記文書管理システムに自動的にログイン処理がなされ，
　前記属性ファイルに記述される情報として，アカウント情報，他のシステムのアカウント情報に加えて，ユーザの認証に用いられる差分情報が含まれ，前記差分情報は，システムによって異なるものである，方法。
　
第５．本願発明と引用発明との対比，及び，判断
１．引用発明は，「文書統合システム」と，「文書管理システム」との間の「シングルサインオン」を実現するものであるから，
　引用発明における「シングルサインオンを実現するための方法」は，
　本願発明における「システム間シングルサインオン（ＳＳＯ）のための方法」に相当する。
　
２．引用発明における「文書統合システム」が，本願発明における「第１のシステム」に相当し，引用発明において，「文書統合システムは，ユーザにユーザ名とパスワードを入力させ」ることは，「文書統合システム」についての「アカウント情報」を取得することに他ならず，引用発明における「アカウント情報」が，本願発明における「ＩＤ情報」に相当するものであるから，
　引用発明における「ユーザが，文書統合システムへアクセスすると，前記文書統合システムは，ユーザにユーザ名とパスワードを入力させ」が，
　本願発明における「第１のシステムに関するユーザのＩＤ情報を取得するステップ」に相当する。
　
３．引用発明における「文書管理システム」が，本願発明における「第２のシステム」に相当し，引用発明において，「属性ファイルに記述された」，「文書統合システムのアカウント情報」と，「文書管理システムのアカウント情報」との対応関係が，本願発明における「第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係」に相当するので，
　引用発明における「属性ファイルに記述された，前記文書統合システムのアカウント情報に対応する，前記文書管理システムのアカウント情報が取得され」が，
　本願発明における「前記第１のシステムと第２のシステムとの間のユーザＩＤマッピング関係に従って，前記第１のシステムに関するユーザのＩＤ情報から前記第２のシステムに関する前記ユーザのＩＤ情報を取得するステップ」に相当する。
　
４．上記３．において検討したとおり，引用発明における「属性ファイル」は，「文書統合システム」の「ユーザ名」と，「文書統合システム」における「他のシステムのユーザ名」である「文書管理システム」の「ユーザ名」との対応関係が記載されると共に，前記「文書管理システム」の「ユーザ名」で，「文書管理システム」に「ログイン」する場合の，「パスワード」並びに，「差分情報」が記述されており，当該「差分情報」は，前記「文書管理システム」の「ユーザ名」を認証するために用いられる“追加的な情報”であることは明らかである。
　そして，本願発明においては，「ユーザＩＤマッピング関係」は，「システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる」ものであるが，「システム間で異なる追加属性」か，「ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報」の何れかを含むものであって，後者，即ち，「ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報」を採用すれば，引用発明における「差分情報」は，上記において検討したとおり，「ユーザ名」を認証するための情報であり，当該「差分情報」によって認証されなければ，“ユーザの権限”が制限されることは明らかであるから，本願発明における「ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報」に相当するものと言い得るものである。
　また，「システム間で異なる追加属性」という構成を採用したとしても，引用発明における「差分情報」は，「文書管理システム」毎に異なるものとなり得るので，本願発明における「システム間で異なる追加属性」と言い得るものである。
　よって，引用発明における「属性ファイルに記述される情報として，アカウント情報，他のシステムのアカウント情報に加えて，ユーザの認証に用いられる差分情報が含まれ，前記差分情報は，システムによって異なるものである」ことが，
　本願発明における「ユーザＩＤマッピング関係には，システム間で異なる追加属性，または，ユーザＩＤの認証，及びユーザ権限の制御ならびに制限に使用される追加情報も含まれる」に相当する。
　
５．引用発明において，「取得された文書管理システムのアカウント情報を，前記文書管理システムに入力することで，前記文書管理システムに自動的にログイン処理がなされ」ということは，「文書統合システム」から，「文書管理システム」へ，「取得された文書管理システムのアカウント情報」が送信されることは明らかであるから，
　引用発明における「取得された文書管理システムのアカウント情報を，前記文書管理システムに入力することで，前記文書管理システムに自動的にログイン処理がなされ」ることが，
　本願発明における「第２のシステムに関する前記ユーザのＩＤ情報を前記第２のシステムに送信するステップ」に相当するので，
　本願発明と引用発明とは，表現上の相違は存在するものの，本願発明と引用発明は，実質的には相違しない。
　そして，引用発明が，本願発明と同一の構成を有する以上，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものである。
　そして，本願発明の構成によってもたらされる効果も，引用発明から当業者ならば容易に予測することができる程度のものであって，格別のものとはいえない。
　
　第６．むすび
　したがって，本願発明は引用刊行物１に記載された発明であるから，特許法第２９条第１項第３号の規定により特許を受けることができない。
　加えて，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。