2017-700932

特許第６１０４４３９号発明「認証のためのシステム、方法、プログラム、及びプログラムを記録した記録媒体」の特許異議申立事件について、次のとおり決定する。

【結　論】 特許第６１０４４３９号の請求項１，３，６，１１，１６，１８，２１及び２６に係る特許を維持する。

【理　由】 １．手続の経緯 特許第６１０４４３９号の請求項１乃至３１に係る特許についての出願は，平成２８年８月８日に特許出願され，平成２９年３月１０日にその特許権の設定登録がされ，その後，請求項１，３，６，１１，１６，１８，２１及び２６に対して、特許異議申立人　當山章（以下単に「申立人」という。）により特許異議の申立てがされたものである。 ２．本件発明 特許第６１０４４３９号の請求項１，３，６，１１，１６，１８，２１及び２６の特許に係る発明（以下，それぞれ「本件特許１」，「本件特許３」…，「本件特許２６」という。）は，それぞれ，その特許請求の範囲の請求項１，３，６，１１，１６，１８，２１及び２６に記載された事項により特定されるとおりのものと認める。 このうち本件特許１については次のとおりの発明と認める。 「【請求項１】 第１の端末と、 第２の端末と、 認証サブシステムと、 を備え、 前記認証サブシステムは、 記憶部と、 前記第１の端末から受信した識別情報と、前記第２の端末の固有ＩＤと対応付けて前記記憶部に記憶されている識別情報を照合する識別情報照合部と、 前記第１の端末から受信した前記識別情報と一致する識別情報が、前記記憶部に記憶されていた場合、プッシュＩＤを生成すると共に、該プッシュＩＤを前記第１の端末に送信するプッシュＩＤ生成部と、 前記第１の端末から受信した前記識別情報と一致する前記識別情報に基づいて、該識別情報と対応付けて前記記憶部に記憶された前記第２の端末の固有ＩＤを取得する第２端末固有ＩＤ取得部と、 前記第１の端末から受信したプッシュＩＤを前記記憶部に記憶させるプッシュＩＤ受付部と、 前記第２端末固有ＩＤ取得部により取得された前記第２の端末の固有ＩＤに基づいて、前記第２の端末に、前記プッシュＩＤ生成部により生成された前記プッシュＩＤと、プッシュ認証操作開始要求を送信するプッシュ認証操作開始要求部と、 前記第２の端末から送信されたプッシュ認証操作完了通知を受信するプッシュ認証操作完了通知受付部と、 前記第２の端末から受信したプッシュＩＤと、前記記憶部に記憶された、前記第１の端末からの前記プッシュＩＤを照合するプッシュＩＤ照合部と、 を備え、 第１の端末は、 前記識別情報及び第１のプッシュ認証要求を前記識別情報照合部に送信し、 前記プッシュＩＤ生成部から受信した前記プッシュＩＤを記憶すると共に、該プッシュＩＤを前記プッシュＩＤ受付部に送信し、 第２の端末は、 前記プッシュ認証操作開始要求を受信すると、前記プッシュ認証のために、知識認証情報、所有物認証情報、及び生体認証情報の入力を伴わない所定の操作のみをユーザに促し、 前記ユーザにより、前記所定の操作が行われると、前記プッシュ認証操作開始要求部から受信した前記プッシュＩＤとプッシュ認証操作完了通知を前記プッシュ認証操作完了通知受付部に送信する、 認証システム。」 ３．申立理由の概要 申立人は，証拠として甲第１号証ないし甲第７号証を提出し，取消理由１および取消理由２により，請求項１，３，６，１１，１６，１８，２１及び２６に係る特許を取り消すべき旨主張している。 （取消理由１） （取消理由１－１） 本件特許１，１１，１６及び２６は，甲第１号証に記載された発明，甲第２号証乃至甲第５号証に記載された技術常識，並びに，甲第４号証に記載された発明に基いて，当業者が容易に発明をすることができたものであるから，その特許は特許法２９条２項の規定に違反してなされたものであるので，同法１１３条２号の規定に該当し，取り消されるべきものである。 （取消理由１－２） 本件特許３及び１８は，甲第１号証に記載された発明，甲第２号証乃至甲第５号証に記載された技術常識，並びに，甲第４号証に記載された発明及び甲第６号証に記載された発明に基いて，当業者が容易に発明をすることができたものであるから，その特許は特許法２９条２項の規定に違反してなされたものであるので，同法１１３条２号の規定に該当し，取り消されるべきものである。 （取消理由１－３） 本件特許６及び２１は，甲第１号証に記載された発明，甲第２号証乃至甲第５号証に記載された技術常識，並びに，甲第４号証に記載された発明及び甲第７号証に記載された発明に基いて，当業者が容易に発明をすることができたものであるから，その特許は特許法２９条２項の規定に違反してなされたものであるので，同法１１３条２号の規定に該当し，取り消されるべきものである。 （取消理由２） 本件特許１，３，６，１１，１６，１８，２１及び２６は，その記載が明確でなく，その特許は特許法３６条６項２号の規定に違反してなされたものであるので，同法第１１３条４号の規定に該当し，取り消されるべきものである。 （証拠方法） 甲第１号証： ANDREW MATRONIK, "Google enables new two-step 'prompt' log-in verification from your phone", [online], ２０１６年６月２０日，[平成２９年９月２７日検索］, インターネット, ＜URL:https://www.androidcentral.com/google-enables-brand-new-two-step-log-option-your-phone?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+androidcentral+%28Android+Central%29&utm_content=Google+Internatinal#comments＞ （以下「引用例１」という。） 甲第２号証： “ローカル通知／リモート通知プログラミングガイド”, [online], ２０１５年１２月１７日, ［平成２９年９月２７日検索］, インターネット, ＜URL:https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/Introduction.html＞ （以下「引用例２」という。） （なお，公知日については，下記記載事項Ｋより認定した。） 甲第３号証： jonchambers, "Apple Developer Forums/Use cases for 'apns-id' header in HTTP/2-based APNs protocol?", [online], ２０１６年２月８日, [平成２９年９月２７日検索], インターネット, ＜URL:http://forums.developer.apple.com/thread/35582＞ （以下「引用例３」という。） 甲第４号証：特開２０１１－２３８０３６号公報（以下「引用例４」という。）， 甲第５号証：特開２０１３－２１０８７１号公報（以下「引用例５」という。）， 甲第６号証： ITTOUSAI, “Googleからのメッセージを取得してログインする”, ［online］, ２０１６年６月２２日, [平成２９年９月２７日検索], インターネット, ＜http://japanese.engadget.com/2016/06/21/google-2-android-iphone/＞ （以下「引用例６」という。）， 甲第７号証： SUMIT, "How to Enable Google Prompt To Make-2-Step Verification", ２０１６年６月２９日, ［平成２９年９月２７日検索］, インターネット, ＜URL:http://www.stechguide.com/enable-google-prompt-to-make-2-step-verification/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+stechguide+%28stechguide%29&utm_content=Google+International＞ （以下「引用例７」という。） ４．各引用例の記載について （１）引用例１ ア　引用例１に記載された事項 引用例１には，次の事項が記載されている。 Ａ　「Having two-step verification enabled on your Google account is an absolute must for keeping it safe, and today Google has enabled yet another way to verify your log-in attempts called a "Google prompt." Now sitting alongside the Google Authenticator app, text messages and security keys is the option to simply verify log-in attempts by unlocking a registered phone - the feature was announced today for paid Google Apps accounts, but has also been enabled for personal Google accounts as well.」（第１段落） （仮訳： Googleアカウントにおける２段階の認証システムは、安全確保のために必須であり、今日のGoogleは、ユーザのログインの試みをさらに別の手法で認証する「Google prompt」と呼ばれる新たな手段を導入しています。この手法はGoogle Authenticator、テキストメッセージと並列して提供されており、セキュリティキーは、登録されたスマートフォンのロックを外すことによりログインの試みの認証を簡素化するオプションとして提供されています。この機能は、有償のGoogle Appsアカウント向けに本日付で発表された機能ですが、個人のGoogleアカウントにも導入されています。） Ｂ　「Once enabled through the Google security settings online, you can choose to have your phone prompt you with a full-screen notice any time a Google account log-in attempt was made - you simply tap "yes" on your phone and the log-in will be completed on the computer you tried to log in on. (You can also tap "no" if this was an unauthorized attempt.) The only requirements are a data connection on the phone and the latest version of Google Play Services. It can even be used on an iPhone using the Google Search app.」（第２段落） （仮訳： PromptをオンラインのGoogleセキュリティ設定上で一度有効にすると、Googleアカウントヘのログインの試みを行う度にスマートフォン上の全画面での通知によりpromptの起動が選択できます。ユーザは「はい」を端末上にタップするだけで、ログインを試みたコンピュータ上でのログインが完了します（許可されていないログインの場合はユーザは「いいえ」をタップします）。この機能に必要なものは手持ちのスマートフォンと最新バージョンのGoogle Play Services間のデータ接続です。 Google Search appを使用することにより、この機能をiPhoneでも使用できます。） Ｃ　「The new two-step option is not unlike Google's Smart Lock feature on Chrome OS, which lets you unlock your Chromebook when your registered phone is within Bluetooth range and unlocked.」（第３段落） （仮訳： この新しい二段階の認証オプションは、ユーザによって登録されたスマートフォンがBluetoothのネットワーク内に存在していて、ロックが解除されている場合にChromebookのロックを解除できるChrome OSにおけるGoogle Smart Lock機能と類似のものです。） Ｄ　「This new Google prompt two-step verification option removes the extra step of waiting for a text message to arrive or opening an app like Google Authenticator to enter a code - all you have to do is have your phone nearby and have it secured with a lock screen. It also can stand alongside the Google Authenticator (or a third-party authenticator) app, meaning you could have multiple devices that are able to handle log-ins. In other words, this just took away any excuse you could've previously had for not having two-step verification enabled on your account.」（第４段落） （仮訳： この新しいGoogle promptによる二段階の認証オプションは、テキストメッセージの到着を待つ、あるいはコードを入力するためにGoogle Authenticatorを開くという追加のステップを除去します。ユーザは自分のスマートフォンが身近にあり、そのスマートフォンが両面ロックされていてセキュアな状態であればよいだけです。また、この機能はGoogle Authenticator（あるいは第三者の認証アプリケーション）と並んで提供されているため、ユーザはログインに複数のデバイスを使えます。つまり、ユーザが自らのアカウントに二段階の認証オプションを採用しない理由は、これで一切なくなったということです。） Ｅ　引用例１の第１段落及び第２段落の間には，引用例１に示す情報を，ウェブブラウザのようなアプリケーションで読み込み，当該情報を表示した画面上，左下の「△」（右方向へその先が向けられているもの）をマウスなどでクリックすることによって順次表示される画面１乃至５が表示される。 当該操作によって表示される画面１乃至５は次の通りである。 画面１ 画面２ 画面３ 画面４ 画面５ イ　引用例１に記載された発明 １）上記記載事項Ａによると，グーグル社が提供する２段階認証について，「グーグル　プロンプト」と呼ばれる方法が新たに提供されて利用可能となったことを読み取ることができ，これは“２段階認証を実行するシステム”を示しているといえる。そして当該方法は，グーグルアカウント，すなわち“特定の個人のアカウント”に対応したものであること，記載事項Ｅの画面１乃至４の様子から，さらに当該“特定の個人のアカウントに対応付けて特定のスマートフォンを認証用のデバイスとして登録”することを読み取ることができる。 なお，申立人によると，当該スマートフォンの登録にあたっては，「電話番号」を登録すること（上記記載事項Ｅの画面１及び３）を示していることを主張しているが，上記記載事項Ａ乃至Ｅのいずれにも，「電話番号」を登録することは明記されておらず，また，上記記載事項Ｅの画面１乃至５のいずれにも，「電話番号」を登録することを示す事実は見当たらない。 ２）上記記載事項Ｂによると，あるコンピュータにおいて，特定の個人のアカウントへのログインを試みた際の動作を読み取ることができ，さらに上記記載事項Ｅの画面５の様子から，“コンピュータを用いて特定の個人のアカウントへのログインを実行すると，登録されたスマートフォン上に，ログインを試みていることを通知し，かつ，当該ログインの可否（「はい」又は「いいえ」）の操作をユーザに選択させるための通知を”行っていることを読み取ることができる。 ３）上記記載事項Ｂによると，「Ｙｅｓ」をタップすること，すなわち「はい」を選択することによってログインがなされることを読み取ることができるから，引用例１には“ログインの可否において「はい」がユーザによってスマートフォン上で選択された場合に，ログインを実行したコンピュータのログインが完了する”ことを読み取ることができる。 ４）上記１）乃至３）によれば，引用例１には，次の発明（以下「引用発明」という。）が記載されていると認める。 「特定の個人のアカウントに対応付けて特定のスマートフォンを認証用のデバイスとして登録し， コンピュータを用いて特定の個人のアカウントへのログインを実行すると，登録されたスマートフォン上に，ログインを試みていることを通知し，かつ，当該ログインの可否（「はい」又は「いいえ」）の操作をユーザに選択させるための通知をし， ログインの可否において「はい」がユーザによってスマートフォン上で選択された場合に，ログインを実行したコンピュータのログインが完了する， ２段階認証を実行するシステム。」 （２）引用例２に記載された事項 引用例２には，次の事項が記載されている。 Ｆ　「一方、リモート通知（あるいは「プッシュ通知」）は、デバイスの外部から届きます。リモートサーバ（アプリケーションの通知プロバイダー）で発生し、デバイス上のアプリケーションに、Apple Push Notificationサービス（APNs）経由で配信（プッシュ）されます。」（「ローカル通知，リモート通知について」の項の「概要」のうち，「ローカル通知とリモート通知の違い」の項） Ｇ　「APNs Provider APIを活用すれば、iOS、tvOS、macOSデバイス上で動作しているアプリケーションに、あるいはiOSを経由してApple Watchに、リモート通知を送信できます。このAPIはHTTP/2ネットワークプロトコルを基盤としています。通知の送信はプロバイダーサーバからAPNsへのPOST要求で始まり、これにはJSONペイロードが収容されています。APNsはこれを受けて、指定されたユーザデバイス上で動作しているアプリケーションに通知を送ります。」（「APNs Provider API」の項） Ｈ　「APNsに安全に接続するため、プロバイダー認証トークンやプロバイダー証明書が有用です。この節ではトークンを使った接続について説明します。 Provider APIはJWT（JSON Web Token）の仕様に対応しており、プッシュ通知とともに、クレームと呼ばれる文やメタデータをAPNsに渡すことができます。詳しくは仕様文書（https://tools.ietf.org/html/rfc7519）を参照してください。また、JWTや、署名付きJWTを生成するためのライブラリについては、https://jwt.ioを参照してください。」（「APNs Provider API」の項のうち，「プロバイダー認証トークン」の項） Ｉ　「通知を識別する標準的なUUID。通知の送信時にエラーが発生した場合、APNsはこの値を使って、サーバに送信しようとした通知を識別します。 標準的な形式は32桁の16進小文字で、8-4-4-4-12桁ごとにハイフンで区切った文字列です。たとえば次のような形式です。 123e4567-e89b-12d3-a456-42665544000 このヘッダを省略した場合、APNsが新規にUUIDを生成し、応答に入れて返します。」（「APNs Provider API」の項のうち，「APNsへのHTTP/2要求」の項の「表６－２　APNsの要求ヘッダ」の「ヘッダ」“apns-id”に対応する「説明」の項） Ｊ　「要求のapns-id値を転記。要求にこの値がなかった場合、サーバが新規にUUIDを生成し、このヘッダに入れて返します。」（同「表６－３　APNs応答ヘッダ」の「ヘッダ名」“apns-id”の「値」の項） Ｋ　「2015年12月から利用できる、HTTP/2ベースのAPNs Provider APIの説明を追加しました。」（「改訂履歴」の中の，"2015/12/17"に対応する項） Ｌ　「プロバイダがApple Push Notificationサービスを使用してクライアントアプリケーションにPush Notificationを送信する仕組みについて説明したドキュメントの初版。」（同"2009/03/15"に対応する項） （３）引用例３に記載された事項 引用例３には，次の事項が記載されている。 Ｍ　「First, a small quibble with the definition: in practice, it appears that the `apns-id` header is always sent by the server regardless of whethere or not there was an error. In other words, responses to notifications accepted by the server will also include the `apns-id` header.」（第３段落） （仮訳： まず、定義に少々の疑問があります。事実上、'apns-id'ヘッダはエラーのあるなしに関わらず、常にサーバから送信されているようです。つまり、サーバが受理した通知への応答にも常に'apns-id'ヘッダは含まれているということです。） Ｎ　「Beyond that, though, we're a little unclear on the use cases for the `apns-id` header. It seems to be intended to correlate responses from the server with requests from the provider. That made a lot of sense back in pre-HTTP/2 days, but it seems to me that HTTP/2 already has a mechanism to correlate requests and responses (i.e. the stream ID). If that's already the case, what is the stream ID for? Also, what should the provider do with the `apns-id` if it's automatically generated by the server?」（第４段落） （仮訳： さらに我々は、'apns-id'ヘッダの使用例についてまだよく理解していません。 apns-idヘッダの使用は、サーバからの応答とプロバイダからのリクエストを相関付ける意図であるようです。それは以前のHTTP/2が使用されていた時代には確かに大きな意昧がありましたが、私の目にはHTTP/2には既にリクエストと応答を相関付けるメカニズムを有しているように見えます（例:stream ID）。それが正しいなら、stream IDは何のために存在しているのか？また、apns-idがサーバによって自動的に生成されるなら、プロバイダはこれをどう取り扱うべきなのでしょうか？） （４）引用例４について ア　引用例４に記載された事項 引用例４には次の事項が記載されている。 Ｏ　「【００１３】 図１は、本発明の認証システムのネットワーク構成図を示す。本発明の認証システムは、インターネット１０を介してパーソナルコンピュータ２０（以下、クライアントＰＣ２０として参照する）に接続されるサーバ装置３０と、移動体通信網１２およびインターネット１０を介してサーバ装置３０と通信可能な移動携帯端末４０を含んで構成されている。本システムにおいて、クライアントＰＣ２０は、必ずしもユーザが所有・管理するものである必要はない。すなわち、本発明の認証システムは、たとえば、宿泊先のホテルの貸出用パソコンや外出先の他人のパソコンを使用して構築することができる。 …（中略）… 【００１７】 また、本実施形態におけるサーバ装置３０は、ユーザからの要求に応じてネットワークを通して各種サービスを提供するサービスサーバであり、ユーザ認証機能を備える。サーバ装置３０は、移動体通信網１２あるいはインターネット１０を介して携帯電話４０およびクライアントＰＣ２０のいずれとも通信可能に構成されおり、クライアントＰＣ通信部３３、移動携帯端末通信部３４、ログイン認証部３５を含んで構成されている。なお、本発明におけるサーバ装置は、サービスサーバに限定されず、他のサービスサーバに代行してユーザ認証を実行する認証専用サーバであってもよい。以下の説明においては、サーバ装置３０をサービスサーバ３０として参照する。 【００１８】 サービスサーバ３０は、クライアントＰＣ２０のウェブブラウザ２２から送信されたログイン要求に応答してクライアントセッションを生成し、これにクライアントセッションＩＤ（以下、ＣセッションＩＤとして参照する）を割り当てる。本実施形態におけるクライアントＰＣ通信部３３は、ＣセッションＩＤを表示するための情報を生成するクライアントセッションＩＤ表示情報生成部を含み、生成したクライアントセッションＩＤ表示情報をウェブブラウザ２２に送信する。 【００１９】 本実施形態におけるクライアントセッションＩＤ表示情報生成部は、クライアントセッションＩＤ表示情報をテキストデータとして生成することができる。その場合、ＣセッションＩＤを示す文字列がクライアントＰＣ２０のウェブブラウザ２２によって表示装置２６に表示される。ユーザは、表示装置２６に表示された文字列を見ながら、モバイルブラウザ４３に表示された入力フォームにこれを入力する。この場合、モバイルブラウザ４３がクライアントセッションＩＤ入力部４４をして機能する。一方、本実施形態においては、クライアントセッションＩＤ表示情報をＱＲコードとして生成することもできる。その場合、ＱＲコードがクライアントＰＣ２０のウェブブラウザ２２によって表示装置２６に表示される。ユーザは、表示装置２６に表示されたＱＲコードを携帯電話４０に標準搭載されたＱＲコードリーダで読み取り、クライアントセッションＩＤを取得する。この場合、ＱＲコードリーダがクライアントセッションＩＤ入力部４４をして機能する。 …（中略）… 【００４２】 ユーザは、携帯電話４０の表示画面を見ながら、図９（ａ）に示すクライアントＰＣ２０に表示された認証ページの入力フォームにパスワード１「1234」およびパスワード２「5678」を入力し、「送信」アイコンを選択する。「送信」アイコンの選択に応答して、クライアントＰＣ２０は、入力された携帯認証用１ＴＰＷ（パスワード１）とサーバ認証用１ＴＰＷ（パスワード２）を関連付けてサービスサーバ３０に送信する（ステップ３１４)。 …（中略）… 【００４９】 本実施形態において、サービスサーバ３０は、ステップ３１５で取得したＭセッションＩＤとクライアントＰＣ２０のＣセッションＩＤとを関連付けて一時記憶手段５０に格納する（ステップ３１５－２）。すなわち、本実施形態においては、サービスサーバにアクセス権限を有するユーザの携帯電話のセッションとクライアントＰＣ２０のセッションが一時記憶手段５０において関連付けられて管理される。なお、一時記憶手段５０は、セッション管理データベースとして構成することができる。さらに、サービスサーバ３０は、ＭセッションＩＤに関連付けられたＣセッションＩＤの表示情報を含む確認ダイアログを生成する（ステップ３１５－３)。サービスサーバ３０は、ステップ３１５で取得したＭセッションＩＤが示すモバイルセッション内で生成した確認ダイアログを携帯電話４０に送信する（ステップ３１５－４)。サービスサーバ３０から確認ダイアログを受信した携帯電話４０は、これを表示する（ステップ３１５－５)。 【００５０】 図１２（ｃ）は、携帯電話４０において、１ＴＰＷ表示ページの上に確認ダイアログが重ねて表示された態様を示す。確認ダイアログには、ＣセッションＩＤ「abcdefgh」が表示され、「パソコン画面に表示されたセッションＩＤと同じですか？」という問いかけとともに、選択アイコン（「はい」、「いいえ」）が表示されている。ユーザは、図１２（ａ）に示したクライアントＰＣ２０に表示された認証ページに表示されたＣセッションＩＤ「abcdefgh」と、図１２（ｃ）に示した携帯電話４０の確認ダイアログに表示されたＣセッションＩＤ「abcdefgh」を比較する。図１２に示す例においては、両画面に表示されたＣセッションＩＤが同じなので、ユーザは、携帯電話４０の確認ダイアログの「はい」アイコンを選択する。これに応答して、携帯電話４０は、サービスサーバ３０に承認応答を通知する（ステップ３１５－６)。サービスサーバ３０は、この間、携帯電話４０からの承認応答を待機しており、上記承認応答を受領すると、一時記憶手段５０を検索して承認応答のＭセッションＩＤに対応するＣセッションＩＤを取得し、当該ＣセッションＩＤに基づいてクライアントセッションを検出して（ステップ３１５－７）、当該クライアントセッション内で認証結果（ログイン成功）をクライアントＰＣ２０に通知する（ステップ３１８)。以上、第１～第３の実施形態をもって、本発明の認証システムについて説明してきたが、上述した本発明の認証の手法は、シングルサインオンシステムに拡張することができる。この点について、本発明の第４の実施形態として、以下説明する。」 イ　引用例４に記載された発明 上記記載事項Ｏより，引用例４には，次の発明（以下「引用発明４」という。）が記載されていると認める。 「インターネット１０を介してクライアントＰＣ２０に接続されるサーバ装置３０と，移動体通信網１２およびインターネット１０を介してサーバ装置３０と通信可能な移動携帯端末４０を含んで構成される認証システムであって， 前記サーバ装置３０は，ユーザ認証機能を備え，移動体通信網１２あるいはインターネット１０を介して携帯電話４０およびクライアントＰＣ２０のいずれとも通信可能に構成されており，クライアントＰＣ通信部３３，移動携帯端末通信部３４，ログイン認証部３５を含んで構成され，サーバ装置３０はサービスサーバ３０であり， 前記サービスサーバ３０は，クライアントＰＣ２０のウェブブラウザ２２から送信されたログイン要求に応答してクライアントセッションを生成し，これにＣセッションＩＤを割り当て，クライアントＰＣ通信部３３は，ＣセッションＩＤを表示するための情報を生成するＣセッションＩＤ表示情報生成部を含み，生成したＣセッションＩＤ表示情報を前記クライアントＰＣ２０のウェブブラウザ２２に送信し， 前記クライアントセッションＩＤ表示情報生成部は，ＣセッションＩＤ表示情報をテキストデータとして生成することができ，この場合，ＣセッションＩＤを示す文字列がクライアントＰＣ２０のウェブブラウザ２２によって表示装置２６に表示され，ユーザは，表示装置２６に表示された文字列を見ながら，モバイルブラウザ４３に表示された入力フォームにこれを入力し，この場合，モバイルブラウザ４３がクライアントセッションＩＤ入力部４４として機能し， ユーザは，前記携帯電話４０の表示画面を見ながら，前記クライアントＰＣ２０に表示された認証ページの入力フォームにパスワード１「1234」およびパスワード２「5678」を入力し，「送信」アイコンを選択して，クライアントＰＣ２０は，入力された携帯認証用１ＴＰＷ（パスワード１）とサーバ認証用１ＴＰＷ（パスワード２）を関連付けてサービスサーバ３０に送信し， 前記サービスサーバ３０は，ＭセッションＩＤとクライアントＰＣ２０のＣセッションＩＤとを関連付けて一時記憶手段５０に格納し，これにより，サービスサーバにアクセス権限を有するユーザの携帯電話のセッションとクライアントＰＣ２０のセッションが一時記憶手段５０において関連付けられて管理され，一時記憶手段５０は，セッション管理データベースとして構成することができ，さらに，サービスサーバ３０は，ＭセッションＩＤに関連付けられたＣセッションＩＤの表示情報を含む確認ダイアログを生成して前記ＭセッションＩＤが示すモバイルセッション内で生成した確認ダイアログを携帯電話４０に送信し，前記サービスサーバ３０から前記確認ダイアログを受信した携帯電話４０は，これを表示し， 前記確認ダイアログには，ＣセッションＩＤ「abcdefgh」が表示され，「パソコン画面に表示されたセッションＩＤと同じですか？」という問いかけとともに，選択アイコン（「はい」，「いいえ」）が表示され，ユーザは，クライアントＰＣ２０に表示された認証ページに表示されたＣセッションＩＤ「abcdefgh」と，携帯電話４０の確認ダイアログに表示されたＣセッションＩＤ「abcdefgh」を比較し，両画面に表示されたＣセッションＩＤが同じの場合，ユーザは，携帯電話４０の確認ダイアログの「はい」アイコンを選択し，これに応答して，携帯電話４０は，サービスサーバ３０に承認応答を通知し，サービスサーバ３０は，上記承認応答を受領すると，一時記憶手段５０を検索して承認応答のＭセッションＩＤに対応するＣセッションＩＤを取得し，当該ＣセッションＩＤに基づいてクライアントセッションを検出して，当該クライアントセッション内で認証結果（ログイン成功）をクライアントＰＣ２０に通知する 認証システム。」（下線は，説明のために当審で付加。） （５）引用例５に記載された事項 引用例５には，次の事項が記載されている。 Ｐ　「【００２２】 ［第１実施形態］ 図１及び図２に示すように、ドキュメント閲覧システム２は、データサーバ１０と、第１携帯電話１１と、第２携帯電話１２とを備える。各携帯電話１１，１２は、インターネット１５を介してデータサーバ１０と通信可能となっている。 【００２３】 データサーバ１０は、インターネット１５を介して各携帯電話１１，１２と通信を行うための通信部２１と、ワードデータ、エクセルデータ、図面データ等の複数のドキュメントデータを記憶したデータベース（以下、ＤＢと称する）２２と、ＤＢ制御部２３と、ＣＰＵ２４と、各携帯電話１１，１２でのドキュメントデータの閲覧を認証する認証部２５とが設けられている。また、データサーバ１０は、ドキュメントデータの形式（種別、解像度）を変換するデータ変換部２６と、ドキュメントデータの一時的な閲覧を認証するための情報を生成する情報生成部２７と、各携帯電話１１，１２との通信状態を検出する通信検出部２８と、メモリ２９が設けられている。各部は、データバス２０を介してＣＰＵ２４に接続されており、ＣＰＵ２４により統括的に制御される。また、複数のドキュメントデータは、それぞれ異なるセッションＩＤが割り振られている。 …（中略）… 【００３４】 第２携帯電話１２は、一時的閲覧用情報を受信すると、受信した一時的閲覧用情報に含まれるアクセス先ＵＲＬに基づいて、インターネット１５を介してデータサーバ１０に接続するとともに、一時的閲覧要求情報（セッションＩＤ、第１携帯電話１１のＩＤ、第２携帯電話１２のＩＤ、ＬＣＤ４４の設定解像度データを含む）を情報生成部４９で生成し、データサーバ１０に送信する。 …（中略）… 【００４５】 ドキュメントデータの閲覧が認証されていない第２携帯電話１２を通信モードに切り換えて、インターネット１５を介してデータサーバ１０に接続し、メニューキー３３を操作して、データサーバ１０のＤＢ２２内のドキュメントデータから閲覧を要求するドキュメントデータを１つ選択すると、ＤＢ制御部２３は、選択されたドキュメントデータのセッションＩＤを読み出し、通信部２１から第２携帯電話に送信する。第２携帯電話１２は、受信したセッションＩＤと、アクセス先ＵＲＬと、第２携帯電話１２のＩＤデータとを含む閲覧要求情報を生成し、短距離通信部４８から第１携帯電話１１に送信する（Ｓ７）。」 （６）引用例６に記載された事項 引用例６には，次の事項が記載されている。 Ｑ　「従来の2段階認証のように認証アプリ(Authenticator)を開いたり、SMSが届くのを待ってトークンを手入力する必要なく、スマホに届く「ログインしようとしていますか？」通知に「はい」とタップするだけで認証できるようになります。」（第２段落） Ｒ　「対する 2SVはパスワードに加えてUSB接続のセキュリティキーや、ワンタイムトークン生成器(生成アプリ)、あるいはテキストメッセージや音声で届くトークンを組み合わせることで、もうひとつの鍵を持った本人であると認証して安全性を高める方式です。」（第５段落） Ｓ　「Googleの2段階認証プロセスに新たに加わったのは、スマートフォンに届く通知を利用する「Google prompt」方式。ログインを試行するとあらかじめ設定した端末に「ログインしようとしていますか？」と分かりやすいメッセージの通知が届き、「はい」を選択するだけで完了します。数字を読み取ったり、コピーして入力する手間はありません。」（第８段落） Ｔ　「Googleの2段階認証ではふたつ目の認証方式をログイン試行ごとに選べるため、「Googleからのメッセージ」をデフォルトにしても、その他の方式が使えなくなるわけではありません。」（第１３段落） Ｕ　「データ通信がオフラインで通知が届かない場合は認証システムアプリを使ったり、音声またはSMSを使ったり、別の携帯電話やスマートフォン、メールアドレスにコードを送信するなど。持っていればUSBセキュリティキーと併用もできます。」（第１４段落） （７）引用例７に記載された事項 引用例７には，次の事項が記載されている。 Ｖ　「Today we discuss How to Enable Google Prompt To Make 2-Step Verification On Android. Google added an extra layer of security to keep your account safe from hackers. With 2-Step Verification, you'll protect your account with both your password and your phone. Every time you Sign-in to your Google account it will ask for your password as well as six-digit code generated through a text message. But sometimes it's annoying to wait for the OTP and manually entering the code. Considering this Google announced a new feature called “Google prompt” for all users. Check below How to Enable Google Prompt To Make 2-Step Verification On Android.」（第１段落） （仮訳： ユーザが既に２段階認証を有効にしている場合、Google Promptを採用することにより、Googleの認証が簡単かつ迅速になります。Android端末およびiPone上でGoogle Promptを有効にすると、ユーザはアカウントにログインしようとする度に毎回OTPを入力する必要がなくなり、代わりに登録されたスマートフォン上にログインの確認画面が表示されます。Promptでは「ログインしようとしていますか？」というメッセージが「いいえ」および 「はい」ボタンと共に表示され、アカウント認証が行われます。２段階認証を行うためのGoogle Prompt の設定は、以下の手順にて行います。） Ｗ　「1) First, Go to myaccount.google.com and login with your Google account and click on ‘Signing in to Google‘ 2) Now enable 2-step verification by clicking on it. 3) Now click on ‘Get Started‘ and enter your Gmail Password. 4) Now enter your Phone Number. Google will use this number to send you verification codes. 5) Now enter the code Google sends you and click ‘Next‘. 6) In next window Click on the ‘Turn On‘ to enable 2-step verification. 7) Done! You enable 2-Factor Verification On Google account successfully. To enable Google Prompt follow below steps.」（第４段落） （仮訳： ・２段階認証のAndroid端末上での設定方法 １）まず、myaccount.Google.comにアクセスし、自分のGoogleアカウントにログインするために、「Googleにログイン」をクリックします。」 ２）「Googleへのログイン」をクリックして２段階認証を有効にします。 ３）「開始」をクリックしてGmailパスワードを入力します。 ４）ユーザのスマートフォンの番号を入力します。Googleはそのスマートフォンの番号宛に認証コードを送付します。 ５）Googleから送付された認証コードを入力し、「次へ」をクリック。 ６）次の画面で２段階認証を有効にするために「有効にする」をク リックしてください。 ７）完了しました！ Googleアカウント向けに２段階認証が有効となりました。 Google Promptを設定するためには以下の手順に従ってください。） ５．対比・判断 １　取消事由１（特許法２９条２項（進歩性））について （１）本件特許１について ＜対比＞ 引用発明と本件特許１とを対比する。 ア　引用発明の「コンピュータ」，「スマートフォン」は，本件特許１の「第１の端末」，「第２の端末」にそれぞれ相当する。 イ　引用発明の「２段階認証を実行するシステム」は，「コンピュータを用いて特定の個人のアカウントへのログインを実行」し，「ログインの可否において「はい」がユーザによってスマートフォン上で選択された場合に，ログインを実行したコンピュータのログインが完了する」ものであることから，本件特許１と“認証システム”であることで一致するといえる。 また，引用発明では，「特定の個人のアカウントに対応付けて特定のスマートフォンを認証用のデバイスとして登録」したり，「登録されたスマートフォン上に，ログインを試みていることを通知」したり，「当該ログインの可否（「はい」又は「いいえ」）の操作をユーザに選択させるための通知」をしたりするための，何らかのシステムが存在していることを読み取ることができるから，引用発明と本件特許１とは，上記アに示す事項と併せて，“第１の端末と、第２の端末と、認証サブシステムと、を備える認証システム”の点で一致するといえる。 ウ　引用発明では，「特定の個人のアカウントに対応付けて特定のスマートフォンを認証用のデバイスとして登録」していて，当該「登録」には，何らかの記憶手段が必要なことは自明であることから，本件特許１とは，“認証サブシステム”が，“記憶部”を備える点で一致するといえる。 エ　引用発明において，「特定の個人のアカウント」に関して，当該「アカウント」に対応するいわゆるユーザＩＤのような本件特許１の「識別情報」に相当する情報が存在することは明らかである。また引用発明において「コンピュータを用いて特定の個人のアカウントへのログインを実行すると，登録されたスマートフォン上に，ログインを試みていることを通知」していて，当該「登録されたスマートフォン」は，「特定の個人のアカウントに対応付け」られていることからして，当該「通知」を行うためには，「コンピュータ」（第１の端末）から「特定の個人のアカウント」，すなわち「識別情報」が入力されると，当該「特定の個人のアカウント」に対応付けられた「スマートフォン」，すなわち「第２の端末」が特定されているものと理解することができる。 そして，当該「第２の端末」の特定にあたっては，「識別情報」と「第２の端末」とが対応付けて登録されていることが前提となっていることは技術常識であり，また，当該特定にあたって，なんらかの情報，すなわち本件特許１の「第２の端末の固有ＩＤ」に相当するような情報を用いていることを推定することができる。 以上総合すると，引用発明と本件特許１とは，“前記第１の端末から受信した前記識別情報と一致する前記識別情報に基づいて、該識別情報と対応付けて前記記憶部に記憶された前記第２の端末の固有ＩＤを取得する第２端末固有ＩＤ取得部”を有する点で一致するといえる。また，当該“第２端末固有ＩＤ取得部”において，“前記第１の端末から受信した前記識別情報と一致する前記識別情報に基づい”て，“第２の端末の固有ＩＤを取得する”ための，「第１の端末」から得られた「識別情報」と，予め「記憶部」に記憶された「第２の端末の固有ＩＤと対応」付けられた「識別情報」との間で所定の照合が行われることも自明であるから，引用発明と本件特許１とはさらに，“前記第１の端末から受信した識別情報と、前記第２の端末の固有ＩＤと対応付けて前記記憶部に記憶されている識別情報を照合する識別情報照合部”を有する点でも一致するといえる。 オ　引用発明において，「コンピュータを用いて特定の個人のアカウントへのログインを実行すると，登録されたスマートフォン上に，ログインを試みていることを通知」していて，上記エで認定したとおり，本件特許１の「第２の端末の固有ＩＤ」に相当するような情報を用いて当該通知を行っていることを理解することができ，また，当該通知の際に表示される画面である上記記載事項Ｅの画面５は，本件特許１の「プッシュ認証操作開始要求」に相当する情報が，スマートフォン，すなわち「第２の端末」に送信されていることを読み取ることができるから，引用発明と本件特許１とは，“前記第２端末固有ＩＤ取得部により取得された前記第２の端末の固有ＩＤに基づいて、前記第２の端末に、プッシュ認証操作開始要求を送信するプッシュ認証操作開始要求部”を有する点で一致するといえる。 カ　引用発明は，「ログインの可否において「はい」がユーザによってスマートフォン上で選択された場合に，ログインを実行したコンピュータのログインが完了する」ものであり，当該「「はい」がユーザによってスマートフォン上で選択され」，そのことが認証サブシステムに受け付けられていることを示しているといえることから，引用発明と本件特許１とは，“前記第２の端末から送信されたプッシュ認証操作完了通知を受信するプッシュ認証操作完了通知受付部”を有する点で一致するといえる。 キ　引用発明において，「登録されたスマートフォン上に，ログインを試みていることを通知し，かつ，当該ログインの可否（「はい」又は「いいえ」）の操作をユーザに選択させるための通知」をすることは，本件特許１の「前記プッシュ認証操作開始要求を受信すると、前記プッシュ認証のために、知識認証情報、所有物認証情報、及び生体認証情報の入力を伴わない所定の操作のみをユーザに促し」に相当することから，引用発明と本件特許１とは，“第２の端末は、前記プッシュ認証操作開始要求を受信すると、前記プッシュ認証のために、知識認証情報、所有物認証情報、及び生体認証情報の入力を伴わない所定の操作のみをユーザに促”す点で一致するといえる。 ク　引用発明において「ログインの可否において「はい」がユーザによってスマートフォン上で選択」することは，本件特許１において，「前記ユーザにより、前記所定の操作が行われる」に相当するといえ，その結果「ログインを実行したコンピュータのログインが完了する」ことから，引用発明においても本件特許１の「プッシュ認証操作完了通知を前記プッシュ認証操作完了通知受付部に送信」に相当する処理が行われているといえ，したがって引用発明と本件特許１とは，“前記ユーザにより、前記所定の操作が行われると、プッシュ認証操作完了通知を前記プッシュ認証操作完了通知受付部に送信する”点で一致するといえる。 ケ　上記ア乃至クにおける対比から，引用発明と本件特許１との間には，次の一致点，相違点が認められる。 ［一致点］ 第１の端末と、 第２の端末と、 認証サブシステムと、 を備え， 前記認証サブシステムは， 記憶部と， 前記第１の端末から受信した識別情報と、前記第２の端末の固有ＩＤと対応付けて前記記憶部に記憶されている識別情報を照合する識別情報照合部と， 前記第１の端末から受信した前記識別情報と一致する前記識別情報に基づいて、該識別情報と対応付けて前記記憶部に記憶された前記第２の端末の固有ＩＤを取得する第２端末固有ＩＤ取得部と， 前記第２端末固有ＩＤ取得部により取得された前記第２の端末の固有ＩＤに基づいて、前記第２の端末に、プッシュ認証操作開始要求を送信するプッシュ認証操作開始要求部と， 前記第２の端末から送信されたプッシュ認証操作完了通知を受信するプッシュ認証操作完了通知受付部と， を備え， 第２の端末は， 前記プッシュ認証操作開始要求を受信すると、前記プッシュ認証のために、知識認証情報、所有物認証情報、及び生体認証情報の入力を伴わない所定の操作のみをユーザに促し， 前記ユーザにより、前記所定の操作が行われると、プッシュ認証操作完了通知を前記プッシュ認証操作完了通知受付部に送信する 認証システム。 ［相違点］ （相違点１） 本件特許１が，「前記第１の端末から受信した前記識別情報と一致する識別情報が、前記記憶部に記憶されていた場合、プッシュＩＤを生成すると共に、該プッシュＩＤを前記第１の端末に送信するプッシュＩＤ生成部」を有するのに対し，引用発明は，そのような構成を有することが不明な点。 （相違点２） 本件特許１が，「前記第１の端末から受信したプッシュＩＤを前記記憶部に記憶させるプッシュＩＤ受付部」を有するのに対し，引用発明は，そのような構成を有することが不明な点。 （相違点３） 本件特許１が，「プッシュ認証操作開始要求部」が，「プッシュ認証操作開始要求」を送信する際に，「プッシュＩＤ生成部により生成された前記プッシュＩＤ」も送信しているのに対し，引用発明は，そのような情報を送信しているか不明な点。 （相違点４） 本件特許１が，「前記第２の端末から受信したプッシュＩＤと、前記記憶部に記憶された、前記第１の端末からの前記プッシュＩＤを照合するプッシュＩＤ照合部」を有するのに対し，引用発明は，そのような構成を有することが不明な点。 （相違点５） 本件特許１が，「第１の端末」が「前記識別情報及び第１のプッシュ認証要求を前記識別情報照合部に送信し，前記プッシュＩＤ生成部から受信した前記プッシュＩＤを記憶すると共に、該プッシュＩＤを前記プッシュＩＤ受付部に送信」するものであるのに対し，引用発明は，そのような構成を有しているか不明な点。 （相違点６） 本件特許１の「第２の端末」が，「プッシュ認証操作完了通知受付部に送信する」情報が，「前記プッシュ認証操作開始要求部から受信した前記プッシュＩＤ」も含むものであるのに対し，引用発明は，そのような情報を送信するものか不明な点。 ＜判断＞ 事案に鑑み，先に，申立人も引用発明との間の相違点と認める，相違点４について判断する。 引用例４には，上記「４．各引用例の記載について」「（４）引用例４について」「イ　引用例４に記載された発明」の項で説示した，引用発明４が記載されている。 引用発明４は，本件特許１の「第１の端末」に相当する「クライアントＰＣ２０」と，同「第２の端末」に相当する「携帯電話４０」との間で，「サービスサーバ３０」を介して「ＣセッションＩＤ」を用いた通信を行うものである。そして，「携帯電話４０」の画面には，「確認ダイヤログ」が表示され，当該ダイヤログに表示された「ＣセッションＩＤ」を，「ユーザ」が読み取り，「クライアントＰＣ２０」に表示された「ＣセッションＩＤ」との比較を，「ユーザ」が行って，「携帯電話４０の確認ダイアログの「はい」アイコンを選択」した上で，「サービスサーバ３０に承認応答を通知」するものである。（特に下線部を参照。） したがって，本件特許１の「プッシュＩＤ」が，「携帯電話４０」（第２の端末）から受信されることや，記憶部に記憶された，「クライアントＰＣ２０」（第１の端末）からの「プッシュＩＤ」についての記載は認められないばかりか，認証サブシステム，すなわち引用発明４における，「サービスサーバ３０」において，当該「プッシュＩＤ」を「照合」することも読み取ることはできない。 したがって，引用例４からは，相違点４に係る構成を見いだすことはできない。 相違点４に関する技術的事項は，その他引用例２乃至３及び５に記載された上記記載事項Ｆ乃至Ｎ及びＰを参照したとしても，読み取ることはできない。 よって，引用例１乃至５のいずれにも，「前記第２の端末から受信したプッシュＩＤと、前記記憶部に記憶された、前記第１の端末からの前記プッシュＩＤを照合するプッシュＩＤ照合部」が記載されていない。したがって，本件特許１は，上記引用例１に記載された発明及び引用例４に記載された発明，並びに引用例２乃至３及び５から読み取ることのできる技術常識を勘案したとしても，当業者が容易になし得るものではない。 なお申立人は，特許異議申立書において，相違点４に関し，次のように主張している。 「構成要件１Ｋは，「前記第２の端末から受信したプッシュＩＤと，前記記憶部に記憶された，前記第１の端末からの前記プッシュＩＤを照合するプッシュＩＤ照合部と，を備え，」である。 これに対して，甲１発明は，サーバなどがスマートフォンから送信されたプッシュＩＤを受信することについては明らかでないものの，上述に記載されたように，ログイン認証などの端末を用いてサーバに記憶されたデータと照合して認証を実行する技術分野においては，甲第２号証から甲第５号証に記載されているように，サーバと端末間における各認証処理を識別するための認証に関するＩＤを，サーバ及び端末間において送受信することは技術常識である。 したがって，甲１発明には，端末としてのスマートフォンから送信された認証に関するＩＤを受信することを明示することができないとしても，これらの事項は甲第１号証に記載されているに等しい事項である。 一方，甲１発明は，このような認証処理を実行する際に，スマートフォンによって受信された認証に関するＩＤと，コンピュータから送信された認証に関するＩＤを照合しているかについては不明である。 しかしながら，甲第４号証に記載の甲４発明は，ワンタイムパスワードを用いた認証システムであるものの，サーバ装置において，認証を行う際に割り当てられたＣセッションＩＤを，クライアントＰＣに送信し，当該送信したＣセッションＩＤをクライアントＰＣから受信するとともに，受信したＣセッションＩＤを記憶する構成を有している。 また，甲４発明は，サーバ装置において，移動携帯端末にＣセッションＩＤを送信するとともに，当該移動携帯端末における承認応答を受領する際にＣセッションＩＤも受信し，受信したＣセッションＩＤに基づいて認証結果を判定する構成を有している。 確かに，甲４発明は，移動携帯端末から送信されたＣセッションＩＤと，記憶されたＣセッションＩＤとを照合していることを明示することができないが，記憶されたＣセッションＩＤは，クライアントＰＣからＣセッションＩＤを受信した際に取得したＭセッションＩＤとともに記憶されており，かつ，移動携帯端末から受信したＣセッションＩＤに基づいて認証結果を判定する際に，ＭセッションＩＤも用いている。してみれば，甲４発明は，クライアントＰＣから受信して記憶されたＣセッションＩＤと，移動携帯端末から受信したＣセッションＩＤを照合していることは明らかである。 すなわち，甲４発明は，当該相違点１において，第１の端末としてのクライアントＰＣから受信したログインに関するＩＤと，第２の端末としての移動携帯端末からのログインに関するＩＤを照合する構成を有していると言える。」（特許異議申立書５９ページ８行乃至６１ページ１行） 上記主張中で申立人も認めるとおり，引用例４（甲第４号証）は，移動携帯端末から送信されたＣセッションＩＤと，記憶されたＣセッションＩＤとを照合していることは記載されておらず，仮に，甲第２号証乃至甲第５号証（引用例２乃至５）において，「ログイン認証などの端末を用いてサーバに記憶されたデータと照合して認証を実行する技術分野」において，「サーバと端末間における各認証処理を識別するための認証に関するＩＤを，サーバ及び端末間において送受信すること」が技術常識であることが理解できるとしても，上記したとおり，「プッシュＩＤ」に関する記載や，当該「プッシュＩＤ」の「照合」についての記載を認めることができない以上，かかる主張は理由がない。 したがって，その余の相違点について判断するまでもなく，本件特許１は，引用例１乃至５に記載された事項から当業者が容易になし得たものとはいえない。 （２）本件特許３及び６について 本件特許３及び６は，本件特許１を更に減縮したものであるから，上記本件特許１についての判断と同様の理由により，上記引用例１に記載された発明，引用例４に記載された技術的事項，引用例２乃至５に記載された技術常識，さらに引用例６及び７に記載された技術的事項を勘案したとしても，当業者が容易になし得るものではない。 （３）本件特許１１について 本件特許１１も，「前記第２の端末から受信したプッシュＩＤと、前記記憶部に記憶された、前記第１の端末からの前記プッシュＩＤを照合するプッシュＩＤ照合部」との特定事項を含むから，上記本件特許１についての判断と同様の理由により，上記引用例１に記載された発明及び引用例４に記載された技術的事項並びに引用例２乃至５に記載された技術常識を勘案したとしても，当業者が容易になし得るものではない。 （４）本件特許１６，１８，２１及び２６について 本件特許１６，１８，２１及び２６は，概ね，本件特許１，３，６及び１１と単にカテゴリーのみ異なるに過ぎず，上記本件特許１，３，６及び１１についての判断と同様の理由により，上記引用例１に記載された発明，引用例４に記載された技術的事項，引用例２乃至５に記載された技術常識，さらに引用例６及び７に記載された技術的事項を勘案したとしても，当業者が容易になし得るものではない。 （５）小括 以上のとおり，本件特許１，３，６，１１，１６，１８，２１及び２６は，引用例１に記載された発明及び引用例４に記載された技術的事項並びに引用例２乃至５に記載された技術常識を勘案し，かつ引用例６及び７に記載された技術的事項を加味したとしても，当業者が容易に発明をすることができたものではない。 ２　取消事由２（特許法３６条６項２号（明確性））について 異議申立人は，請求項１，３，６，１１，１６，１８，２１及び２６に記載された，「プッシュＩＤ」につき，その定義が特許請求の範囲，明細書及び図面に記載がなく，また，「プッシュＩＤ」が周知であったという事実もないことから，当該事項を含む特許請求の範囲の請求項１，３，６，１１，１６，１８，２１及び２６に記載された発明は不明確である旨を主張しているので，この点を検討する。 （１）特許請求の範囲における，「プッシュＩＤ」について 特許請求の範囲の請求項１，３，６，１１，１６，１８，２１及び２６のうち，請求項１，１１，１６及び２６には「プッシュＩＤ」なる記載が存在し，同請求項３，６，１８及び２１には存在しない。 このうち，請求項１に記載された「プッシュＩＤ」につき，次の事項を読み取ることができる。 ア　「認証サブシステム」が備える，「プッシュＩＤ生成部」において生成されるものであり，当該生成された「プッシュＩＤ」は，「第１の端末」に送られるものであること。 イ　同じく「認証サブシステム」が備える「プッシュＩＤ受付部」によって，「第１の端末」から送信されて，同じく「認証サブシステム」が備える「記憶部」に記憶されるものであること。 ウ　同じく「認証サブシステム」が備える「プッシュ認証操作開始要求部」によって，「プッシュ認証操作開始要求」と共に「第２の端末」に送信されるものであること。 エ　同じく「認証サブシステム」が備える「プッシュＩＤ照合部」によって，「第２の端末」から送られた「プッシュＩＤ」と，「第１の端末」から送られ，同じく「認証サブシステム」が備える「記憶部」に記憶された「プッシュＩＤ」が照合されるものであること。 オ　「第１の端末」において，「識別情報」及び「第１のプッシュ認証要求」を「認証サブシステム」の「識別情報照合部」に送信して，「認証サブシステム」の「プッシュＩＤ生成部」が生成した「プッシュＩＤ」を記憶すると共に，当該記憶された「プッシュＩＤ」を「認証サブシステム」の「プッシュＩＤ受付部」に送信するものであること。 カ　「第２の端末」において，ユーザにより所定の操作が行われ，「認証サブシステム」の「プッシュ認証操作開始要求部」から送信された「プッシュＩＤ」と「プッシュ認証操作完了通知」を，「認証サブシステム」の「プッシュ認証操作完了通知受付部」に送信するものであること。 以上ア乃至カの記載から，「プッシュＩＤ」そのものの明示的な定義が特許請求の範囲に記載が無かったとしても，当該「プッシュＩＤ」と呼ばれるものが，請求項１に記載された「認証システム」を構成する「第１の端末」，「第２の端末」及び「認証サブシステム」の間でやりとりされる情報であって，「認証サブシステム」で生成され，記憶され，第１及び第２の端末に送信され，また受信されるなどするものであること，さらに「認証サブシステム」の「プッシュＩＤ照合部」において照合される対象であることなどは読み取ることができるといえる。したがって，特許請求の範囲に記載された「プッシュＩＤ」につき，その記載が明確でないとまではいえない。 また，請求項１１，１６及び２６からも，上記ア乃至カに示された事項と概ね一致する内容を読み取ることができる。 （２）明細書における「プッシュＩＤ」について 本願明細書の発明の詳細な説明において，「プッシュＩＤ」につき，段落７－８，１１，１３－１５，１８－２０，２３，２５－２６，２９，３１－３３，３６－３８，４０，５１，５４，５６－５７，６０，６２－７０，９１－９５，９７－９８，１００－１０３，１０８－１１０にその記載が認められる。 上記箇所においても，特許請求の範囲に記載された程度の，どのような情報であるかを説示するのみであって，「プッシュＩＤ」がどのようなものであるかを明示的に定義する記載は存在しないものの，特許請求の範囲から読み取ることのできる上記ア乃至カに示した記載事項を説明するものであって，当該記載事項と矛盾するものでもなく，したがって特許請求の範囲に記載された「プッシュＩＤ」につき，その記載が明確でないとまではいえない。 （３）図面における「プッシュＩＤ」について 本願図面において「プッシュＩＤ」につき，図２，５ａ－５ｄに記載が認められるところ，特許請求の範囲に記載された上記ア乃至カに示した記載事項を説明するものであって，当該記載事項と矛盾するものでもなく，したがって特許請求の範囲に記載された「プッシュＩＤ」につき，その記載が明確でないとまではいえない。 （４）したがって，特許請求の範囲のうち，請求項１，３，６，１１，１６，１８，２１及び２６の記載は，不明確なものとまではいえない。 ６．むすび したがって，特許異議の申立ての理由及び証拠によっては，請求項１，３，６，１１，１６，１８，２１及び２６に係る特許を取り消すことはできない。 また，他に請求項１，３，６，１１，１６，１８，２１及び２６に係る特許を取り消すべき理由を発見しない。 よって，結論のとおり決定する。