【事件の表示】
　特願２０１３−５３９９４５「証明書検証およびチャネル結合」拒絶査定不服審判事件〔平成２４年　５月２４日国際公開，ＷＯ２０１２／０６８０９４，平成２５年１２月１２日国内公表，特表２０１３−５４４４７１〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１．手続の経緯
　本件請求に係る出願（以下「本願」と記す。）は，２０１０年１１月１５日（以下「優先日」という。）のアメリカ合衆国における出願，及び，２０１１年１月７日のアメリカ合衆国における出願を基礎とするパリ条約による優先権主張を伴った，２０１１年１１月１５日を国際出願日とする出願であって，その手続の経緯の概略は以下のとおりである。
　　平成２５年　５月１５日　　　：国内書面の提出
　　平成２５年　７月１６日　　　：国際出願翻訳文提出書の提出
　　　　　　　　　　　　　　　　　出願審査請求書，手続補正書の提出
　　平成２６年　７月１４日付け　：拒絶理由の通知
　　平成２６年１０月２０日　　　：意見書，手続補正書の提出
　　平成２６年１１月１４日付け　：拒絶査定（同年１１月２５日送達）
　　平成２７年　３月２５日　　　：審判請求書，手続補正書の提出
　　平成２７年　５月２９日　　　：前置報告
　　平成２７年　８月　５日　　　：上申書の提出
２．本願発明
　本願の請求項１に記載された発明（以下，「本願発明」という。）は，上記平成２７年３月２５日付け手続補正書により補正された特許請求の範囲，明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「制約されたネットワークエンティティで，ネットワークエンティティに関連付けられた証明書および前記ネットワークエンティティに関連付けられた公開鍵を受信するステップであって，前記証明書および前記公開鍵は，前記制約されたネットワークエンティティと前記ネットワークエンティティとの間で安全なチャネルを確立するために受信される，受信するステップと，
　前記受信した前記公開鍵および前記証明書を使用して前記制約されたネットワークエンティティで，前記ネットワークエンティティとの暫定的な安全なチャネルを確立するステップと，
　前記制約されたネットワークエンティティによって，コアネットワークエンティティへ，前記ネットワークエンティティに関連付けられた前記証明書および前記公開鍵または前記公開鍵の導出のうちの１つを送信して，前記受信した証明書の有効性を決定するステップであって，前記制約されたネットワークエンティティは，前記コアネットワークエンティティをプロキシとして使用して前記証明書を検証する，決定するステップと，
　前記制約されたネットワークエンティティで，前記コアネットワークエンティティから，前記証明書および前記公開鍵または前記公開鍵の前記導出の前記コアネットワークエンティティによる分析に基づく前記証明書の前記有効性の表示を受信するステップであって，前記証明書の前記受信した有効性の表示より前に前記証明書の前記有効性は前記制約されたネットワークエンティティによって知られていなかった，受信するステップと，
　前記証明書の前記有効性の前記表示に基づいて，前記ネットワークエンティティで認証するかどうか，および前記暫定的な安全なチャネルを有効化するかどうかを決定するステップと
　を含むことを特徴とする方法。」
３．引用文献
　本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である上記平成２６年７月１４日付けの拒絶理由通知（以下，「原審拒絶理由」という。）において引用された，3GPP TSG-SA3, Living Document on Key Security Issues of Relay Node Architectures, [online], 2010年9月, 3GPP（以下，「引用文献」という。）には，以下の技術的事項が記載されている。
　（当審注：以下，下線は，参考のために当審で付与したものである。）
Ａ．「3.1 Terminology 
・・・（中略）・・・
RN subscription authentication
This form of authentication is performed between the RN in its role as a UE and the MME-RN. It is performed using the EPS AKA protocol as defined in TS 33.401 and involves 
a USIM on a UICC
・・・（中略）・・・
RN-UICC secure channel authentication 
This is any authentication performed as part of the set up of a secure channel between an RN and a UICC, for example according to ETSI TS 102 484 Smart cards; Secure channel between a UICC and an end-point terminal where the end-point terminal is the RN.
（当審訳：「３．１　用語
・・・（中略）・・・
ＲＮサブスクリプション認証
この形態の認証は，ＵＥとしての役割のＲＮとＭＭＥ−ＲＮとの間で実行される。それは，TS 33.401で定義されるようなＥＰＳ　ＡＫＡプロトコルを用いて，実行され，ＲＮに挿入された
ＵＩＣＣ上のＵＳＩＭ
・・・（中略）・・・
ＲＮ−ＵＩＣＣ安全チャネル認証
これは，ＲＮとＵＩＣＣの間の安全なチャネルのセットアップの一部として実行される認証である。例えば，ETSI TS 102 484“スマートカード；ＵＩＣＣとエンドポイント端末の間の安全なチャネル”による。ここで，“エンドポイント端末”とは，ＲＮである。
Ｂ．「3.2.4 Access restrictions for the RN
Requirement 3: 
During Phase I, the RN shall only be allowed IP access for specific purposes
 to access certificate validation servers
All other access (including general Internet access) shall be denied.
（当審訳：「３．２．４　ＲＮのアクセス制限
要求３：
フェーズ１の間，ＲＮは
証明書検証サーバ
にアクセスするような，特定目的のＩＰアドレスが許されるのみでなければならない。他の全てのアクセス（一般のインターネットアクセスを含む）は拒否されなければならない。
Ｃ．「7.12.2 Security Procedures
The start-up of an RN proceeds in the following steps. If one of the steps fails in any of the involved entities the procedure is aborted by that entity.
・・・（中略）・・・
E2. The RN attaches as a UE using USIM-INI to be prepared for performing steps E5. and, optionally, E3.
・・・（中略）・・・
E4. Then the RN platform secure environment and the UICC establish a Secure Channel between RN and USIM-RN according to ETSI TS 102 484 by means of a TLS connection. This TLS connection shall be initiated by the UICC and use certificates on both sides.
The UICC is pre-provisioned with a root certificate to verify the RN certificate.
The private key corresponding to the RN certificate and the root certificate used to verify the UICC certificate are stored in the secure environment of the RN platform validated in step E1, and the TLS connection terminates there. From the completion of this step onwards, all communication between the USIM-RN and the RN is protected by the Secure Channel. 
The USIM-RN shall not engage in any AKA-related communication prior to the establishment of the Secure Channel and a successful certificate validation check, 
・・・（中略）・・・
E5. An certificate validation client on the UICC checks the validity of RN certificate used in the secure channel set-up with an certificate validation server. 
E6. The RN detaches from the network if it has attached for performing steps E2, E3, or E5.
NOTE2: ETSI TS 102 484 states in clause 6.2.2: “
The terminal or terminal application should temporarily accept such a certificate 
”
NOTE3: ETSI TS 102 484 states in clause 6.2: “Both the terminal or the UICC shall be able to initiate a TLS secure channel.” It is proposed here that 
the UICC assumes the role of TLS client 
（当審訳：「７．１２．２　セキュリティ手続
ＲＮのスタートアップは，以下の複数ステップで進められる。もし，関係するエンティティのどれかで，複数ステップの１つが失敗したら，手続はそのエンティティにより中止される。
・・・（中略）・・・
Ｅ２．ＲＮは，ステップＥ５と任意にＥ３を実行するために準備されるように，ＵＳＩＭ−ＩＮＩを用いて，ＵＥとしてアタッチする。
・・・（中略）・・・
Ｅ４．それから，ＲＮプラットフォームセキュア環境とＵＩＣＣとは，ETSI TS 102 484に従ってＴＬＳ接続を用いて，ＲＮとＵＳＩＭ−ＲＮの間の安全なチャネルを確立する。ＴＬＳ接続は，ＵＩＣＣにより開始され，両サイドの証明書を用いる。
ＵＩＣＣは，ＲＮ証明書を検証するためのルート証明書を事前設定される。
ＲＮ証明書及びＵＩＣＣ証明書を検証するために使われるルート証明書に対応するプライベート鍵は，Ｅ１で検証されたＲＮプラットフォームの安全な環境に格納され，ＴＬＳ接続は，そこで終了する。以降，このステップが完了してから，ＵＳＩＭ−ＲＮとＲＮとの間の全ての通信は安全なチャネルにより保護される。
ＵＳＩＭ−ＲＮは，安全なチャネルの確立，及び，成功した証明書の有効性チェックより前にＡＫＡ関連の通信には携わらない。
・・・（中略）・・・
Ｅ５．ＵＩＣＣ上の証明書検証クライアントは，証明書検証サーバを用いて，安全なチャネルのセットアップに使用されるＲＮ証明書の有効性をチェックする。
Ｅ６．ＲＮは，ステップＥ２，Ｅ３又はＥ５を実行するためにアタッチしたのなら，ネットワークから分離する。
注２：６．２．２節でのETSI TS 102 484は“
端末又は端末アプリケーションは
このような証明書を一時的に受け入れるべきである。”と述べる。
注３：６．２節でのETSI TS 102 484は“端末又はＵＩＣＣの両方は，ＴＬＳ安全チャネルを開始できるものとする。”と述べる。ここで，以下の理由で，
ＵＩＣＣがＴＬＳクライアントの役割とみなす
・・・（後略）・・・」）
Ｄ．「7.12.6 Certificate validation
The solution in this clause requires the UICC and the RN to perform certificate validation of the RN certificate and the UICC certificate respectively used for the set up of the secure channel prior to the RN attach procedure with the DeNB. The certificate validation protocol is self-secured and can therefore be executed before security on the Un interface has been established. 
The certificate validation client on the UICC needs to send the IP packets carrying the certificate validation message via the RN. The RN requires IP connectivity for the certificate validation messages to be able to reach the certificate validation server.
（当審訳：「７．１２．６　証明書検証
この節のソリューションは，ＤｅＮＢを用いたＲＮアタッチ手続より前に，安全なチャネルのセットアップのために，それぞれ使用されるＲＮ証明書とＵＩＣＣ証明書の証明書検証を実行するＵＩＣＣ及びＲＮが必要である。証明書検証プロトコルは，自己セキュアであるため，インタフェースのセキュリティが確立される前に実行できる。
ＵＩＣＣ上の証明書検証クライアントは，ＲＮ経由で証明書検証メッセージを運ぶＩＰパケットを送信する必要がある。ＲＮは，証明書検証サーバに到達できるように，証明書検証メッセージのＩＰ接続を必要とする。
　ここで，上記引用文献に記載されている事項を検討する。
（１）上記Ａの「ＵＩＣＣ上のＵＳＩＭ」の記載からすると，「ＵＳＩＭ」は「ＵＩＣＣ」の一部であることが読み取れる。
　上記Ａの「ここで，“エンドポイント端末”とは，ＲＮである。」旨の記載からすると，「ＲＮ」は「端末」であることが読み取れる。
（２）上記Ｃの「Ｅ４．それから，ＲＮプラットフォームセキュア環境とＵＩＣＣとは，ETSI TS 102 484に従ってＴＬＳ接続を用いて，ＲＮとＵＳＩＭ−ＲＮの間の安全なチャネルを確立する。ＴＬＳ接続は，ＵＩＣＣにより開始され，両サイドの証明書を用いる。」，「ＵＩＣＣは，ＲＮ証明書を検証するためのルート証明書を事前設定される。」，「ＵＳＩＭ−ＲＮは，安全なチャネルの確立，及び，成功した証明書の有効性チェックより前にＡＫＡ関連の通信には携わらない。」，「注２：６．２．２節でのETSI TS 102 484は“・・・（中略）・・・端末又は端末アプリケーションは・・・（中略）・・・このような証明書を一時的に受け入れるべきである。”と述べる。」，「ＵＩＣＣがＴＬＳクライアントの役割とみなす」旨の記載，及び，前記（１）で検討した事項からすると，
　「ＵＩＣＣ」により開始されるＴＬＳ接続は，端末の証明書を用いるものであるから，「ＵＩＣＣ」が端末の証明書を取得できることは明らかである。
　また，ＴＬＳ接続を用いて，端末とＵＳＩＭ−ＲＮの間の安全なチャネルを確立するものであり，ＵＳＩＭはＵＩＣＣの一部であるから，端末の証明書は，端末とＵＩＣＣの間の安全なチャネルを確立するためのものであることが読み取れる。
　また，安全なチャネルの接続先の端末において，証明書は一時的にしか受け入れていないから，該安全なチャネルは一時的に確立されたものである。
　したがって，引用文献には，
“ＵＩＣＣは，端末の証明書を取得し，
　ＴＬＳクライアントとして，端末の証明書を用いて，端末との間で一時的な安全チャネルを確立する”ことが記載されていると認められる。
（３）上記Ｂの「フェーズ１の間，ＲＮは・・・（中略）・・・証明書検証サーバ・・・（中略）・・・にアクセスするような，特定目的のＩＰアドレスが許されるのみでなければならない。他の全てのアクセス（一般のインターネットアクセスを含む含む）は拒否されなければならない。」旨の記載，及び，上記Ｃの「Ｅ５．ＵＩＣＣ上の証明書検証クライアントは，証明書検証サーバを用いて，安全なチャネルのセットアップに使用されるＲＮ証明書の有効性をチェックする。」旨の記載，及び，上記Ｄの「ＵＩＣＣ上の証明書検証クライアントは，ＲＮ経由で証明書検証メッセージを運ぶＩＰパケットを送信する必要がある。ＲＮは，証明書検証サーバに到達できるように，証明書検証メッセージのＩＰ接続を必要とする。」旨の記載，及び，前記（１）で検討した事項からすると，
　ＵＩＣＣは，安全なチャネルのセットアップに使用されるＲＮ証明書の有効性をチェックするために，ＲＮ，すなわち，端末経由で，証明書検証メッセージを，証明書検証サーバにＩＰ接続で送信することが読み取れるから，
　引用文献には，前記「ＵＩＣＣ」が，
“証明書検証メッセージを，証明書検証サーバに送信することで，証明書検証サーバを用いて，安全なチャネルのセットアップに使用される端末の証明書の有効性をチェックする”ことが記載されていると認められる。
（４）上記Ａの「ＲＮ−ＵＩＣＣ安全チャネル認証
これは，ＲＮとＵＩＣＣの間の安全なチャネルのセットアップの一部として実行される認証である。例えば，ETSI TS 102 484“スマートカード；ＵＩＣＣとエンドポイント端末の間の安全なチャネル”による。」旨の記載，及び，上記Ｃの「ＲＮのスタートアップは，以下の複数ステップで進められる。もし，関係するエンティティのどれかで，複数ステップの１つが失敗したら，手続はそのエンティティにより中止される。
・・・（中略）・・・
Ｅ４．それから，ＲＮプラットフォームセキュア環境とＵＩＣＣとは，ETSI TS 102 484に従ってＴＬＳ接続を用いて，ＲＮとＵＳＩＭ−ＲＮの間の安全なチャネルを確立する。・・・（中略）・・・ＵＳＩＭ−ＲＮは，安全なチャネルの確立，及び，成功した証明書の有効性チェックより前にＡＫＡ関連の通信には携わらない。
・・・（中略）・・・
Ｅ５．ＵＩＣＣ上の証明書検証クライアントは，証明書検証サーバを用いて，安全なチャネルのセットアップに使用されるＲＮ証明書の有効性をチェックする。」旨の記載，及び，前記（１）で検討した事項からすると，
　引用文献には，前記「ＵＩＣＣ」が，
“証明書検証サーバを用いた端末の証明書の有効性チェックが失敗すると，安全なチャネルの確立や認証を含む，端末のスタートアップ手続が中止される”ことが記載されていると認められる。
（５）以上，（１）乃至（４）で検討した事項を踏まえると，引用文献には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
「ＵＩＣＣは，端末の証明書を取得し，
　ＵＩＣＣは，ＴＬＳクライアントとして，端末の証明書を用いて，端末との間で一時的な安全チャネルを確立し，
　ＵＩＣＣは，証明書検証メッセージを，証明書検証サーバに送信することで，証明書検証サーバを用いて，安全なチャネルのセットアップに使用される端末の証明書の有効性をチェックし，
　証明書検証サーバを用いた端末の証明書の有効性チェックが失敗すると，安全なチャネルの確立や認証を含む，端末のスタートアップ手続が中止される方法」
４．参考文献
（１）本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審拒絶理由において引用された，特開２００３−２０９５４２号公報（平成１５年７月２５日公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｅ．「【０００８】
デジタル放送受信機とWebサーバとのデータ交換には
ＴＬＳ（Transport Layer Security）
と呼ばれる技術がある。
Ｆ．「【００２１】デジタル放送受信機１２において，受信装置１２ｂで受信されたデジタル放送波は，デコーダ１２ｃで映像１２ｄ，音声１２ｅ，データ放送コンテンツ１２ｆに分離される。このうち，映像１２ｄ及び音声１２ｅは，図示しない再生装置に出力されてユーザに提示される。
【００２２】また，データ放送コンテンツ１２ｆは，ブラウザ１２ｇに供給される。このブラウザ１２ｇは，データ放送コンテンツ１２ｆに含まれるサーバアドレス１１ｆを取り出して，通信装置１２ｈに出力している。この通信装置１２ｈは，入力されたサーバアドレス１１ｆに基づいて，ＴＬＳに対応したＨＴＴＰリクエストデータを作成してインターネット１５に送信する。
【００２３】
このＴＬＳに対応したＨＴＴＰリクエストデータは，Webサーバ１３の通信装置１３ｃで受信される。この通信装置１３ｃは，サーバ証明書データ１３ｂを取り込み，ＨＴＴＰデータとしてインターネット１５を介してデジタル放送受信機１２の通信装置１２ｈに返送する。
【００２４】このＨＴＴＰレスポンスデータを受信した通信装置１２ｈは，ＣＡ局公開鍵データ１２ａを用いて，
入力されたサーバ証明書に付加されているデジタル署名を評価する。
【００２５】
サーバ証明書のデジタル署名が正しい場合
サーバ証明書に記述された公開鍵を使用してＴＬＳセッション開始に必要なＴＬＳ通信パラメータを，インターネット１５を介してWebサーバ１３の通信装置１３ｃに送信する。
【００２６】これにより，Webサーバ１３の通信装置１３ｃと，デジタル放送受信機１２の通信装置１２ｈとの間で，ＴＬＳセキュア通信のためのハンドシェークが行なわれる。
【００２７】このように，
通信データの暗号手順が決定してセキュアなＨＴＴＰ通信路が確立する
Ｇ．「【００３６】
デジタル放送受信機１２は
送信されてきたサーバ証明書が
サーバ証明書失効リストに登録されているかどうかを検証する。そして，登録されている場合は，Webサーバ１３の信頼性を否としてＴＬＳセッションを中断し，登録されていない場合にのみＴＬＳのセッションを継続する。
（２）本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審拒絶理由において引用された，特開２００５−２１７６７９号公報（平成１７年８月１１日公開，以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｈ．「【００６８】
　上記処理を行うことにより，
端末２１と，端末２２は，公開鍵証明書５０９１と５０９２を交換する。
【００６９】
　次に，端末２１と端末２２はそれぞれ，図３に示すフローに従い，所属するサイトの認証サーバ３１，３２に，通信先端末２２，２１との通信許可をもとめ，可否判定を受け取る。
【００７０】
　図３は，端末２１が認証サーバ３１に通信許可を求める場合を示すが，端末２２が認証サーバ３２に通信許可をもらう場合も，同様の手順を行う。
【００７１】
　
端末２１は，
通信先である端末２２の公開鍵証明書５０９２を認証サーバ３１に送信する
　認証サーバ３１は，公開鍵証明書５０９１と，公開鍵証明書５０９２を，受信する（ステップ１１０２，ステップ１１０６）
　このとき，公開鍵証明書５０９２を送った後で，公開鍵証明書５０９１を送っても良い。あるいは，二つの公開鍵証明書を同時に送っても良い。
・・・（中略）・・・
【００７６】
　許可されている場合には（ステップ１１１０でYES），端末２１から送られてきた，公開鍵証明書５０９１を検証する。公開鍵証明書５０９１の検証では，有効期限，署名，公開鍵証明書失効リストを検証する（ステップ１１１２）。
【００７７】
　公開鍵証明書５０９１の検証１１１２が成功しなかった場合は（ステップ１１１４でNO），ステップ１１２０へ進む。
【００７８】
　公開鍵証明書５０９１の検証１１１２が成功した場合は（ステップ１１１４でYES），
公開鍵証明書５０９２を検証する。
【００７９】
　
通信先すなわち端末２２の公開鍵証明書５０９２の検証１１１６が成功しなかった場合は
ステップ１１２０へ進む。
【００８０】
　
通信先すなわち端末２２の公開鍵証明書５０９２の検証１１１６が成功した場合は
接続許可通知を端末２１に対して送信する
【００８１】
　
ステップ１１２０では，
接続不可通知を端末２１に対して送信する。
【００８２】
　端末２１はステップ１１２０あるいは１１２２で送信された，接続不可通知あるいは接続許可通知を受信し，通知に付与された認証サーバ３１の署名を検証することにより，通知が確かに認証サーバ３１から送付されたことを確認する（ステップ１１２４）。
【００８３】
　
端末２１は，接続許可通知を受け取った場合は（ステップ１１２６でYES），図４の（Ｃ）へ処理を進める。
【００８４】
　
端末２１は，接続不可通知を受け取った場合は（ステップ１１２６でNO），セキュア通信を切断する
（３）本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審拒絶理由において引用された，米国特許出願公開第２００５／０２７８５３４号明細書（２００５年１２月１５日公開，以下，「参考文献３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｉ．「Abstract
A method, an apparatus, a system, and a computer program product are presented for validating certificates. A certificate validation service receives a certificate validation request for a target certificate from a client, thereby allowing the client to offload certificate validation tasks into an online certificate validation service that is accessible and sharable by multiple components within a data processing system. In response to a determination that the target certificate is valid or invalid, the certificate validation service sends a certificate validation response with an indicating status value that the target certificate is valid or invalid.」
（当審訳：「要約
方法，装置，システム，及びコンピュータプログラム製品が，証明書を検証するために提示される。
証明書検証サービスは，クライアントからターゲット証明書の証明書検証要求を受信し
ターゲット証明書が有効か無効かの決定に応じて，証明書検証サービスは，ターゲット証明書が有効か無効かを示す状態値と証明書検証応答を送信する。
Ｊ．「[0055] With reference now to  FIG. 5 , a flowchart depicts a process by which a client of a certificate validation service employs the service to perform certificate validation on its behalf in accordance with an embodiment of the present invention. The process commences with a software component obtaining a digital certificate (step  502 ).
・・・（中略）・・・
(step  504 ); with respect to the certificate validation service, the requesting software component may be described as a client of the certificate validation service, and the certificate validation service as a server that performs certificate validation tasks on behalf of a client. At a later point in time, the client receives a certificate validation response from the certificate validation service (step  506 ). The client then continues to process its transaction as appropriate in accordance with the certificate validation status that it receives from the certificate validation service (step  508 ), thereby concluding the process. In this manner, the client efficiently offloads its certification validation processing tasks to the certificate validation service.」
（当審訳：「［００５５］今，図５を参照すると，フローチャートは，証明書検証サービスのクライアントが，本発明の実施形態に従って，自身の代わりに，証明書の検証を実行するためのサービスを採用するプロセスを示す。プロセスは，ソフトウェアコンポーネントが，デジタル証明書を得ることから開始する（ステップ502）。
・・・（中略）・・・
（ステップ504）；
証明書検証サービスに関し，要求するソフトウェアコンポーネントは，証明書検証サービスのクライアントとして説明でき，証明書検証サービスは，クライアントの代わりに証明書検証タスクを実行するサーバとして説明できる。後の時点で，クライアントは，証明書検証サービスから証明書検証応答を受信する（ステップ506）
（４）本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定において引用された，藤城孝宏 他，証明書検証サービスの開発，電子情報通信学会論文誌，2004年8月1日，Vol. J87-D-I No.8，p.833-840（以下，「参考文献４」という。）には，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｋ．「あらまし
・・・（中略）・・・
本論文では，
従来，利用者側で行っていた検証処理をサーバ側で一括して行う
この検証処理を行うサーバである証明検証サーバの提案
Ｌ．「３．証明書検証サーバ
　２．で述べたように，証明書の検証処理は大変複雑かつ，複数のリポジトリにアクセスし認証情報を取得する必要があるなど，利用者側の負担が大きいという問題がある．
そこで，利用者の代理で証明書検証を行い，利用者に対して検証結果を応答する機能をもつ証明書検証サーバを提案する．
Ｍ．「３．１証明書検証サーバによる検証
　証明書検証サーバを用いて証明書の検証を行う方法を図５に示す．
証明書検証サーバでは，官職ＥＥから証明書検証要求を受け取り，検証結果を応答する．
証明書検証サーバを用いる場合，従来利用者側で行っていた検証処理を，証明書検証サーバが行う
以下に，証明書検証サーバに必要となる主な機能を示す．
・・・（中略）・・・
　（３）
証明書の有効性確認機能
・ＣＲＬ／ＡＲＬをリポジトリから取得し，証明書が失効されていないことを確認する．
・ＯＣＳＰレスポンダに対して問合せを行い，証明書が失効されていないことを確認する．
　（４）
証明書検証要求の受付・応答機能
　
利用者からの証明書検証要求を受け付ける．なお，検証要求として渡す情報には，検証対象の証明書を必須とする．
・証明書の検証結果のみを返却
・証明書の検証結果及び認証パスを返却」（第８３６頁左欄第２８行〜右欄第２３行）
（５）本願優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった，梅澤克之 他，モバイル向け証明書検証システムの開発，情報処理学会論文誌，2007年2月15日，Vol.48 No.2，p.625-633（以下，「参考文献５」という。）には，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｎ．「２．２．３ＣＶＳ方式
ＣＲＬ方式やＯＣＳＰ方式には，証明書検証者が認証パスの構築や証明書の検証を行わなければならず，証明書検証者側の負担が大きいといった問題がある．この負担を軽減するために考えられた方式がＣＶＳ方式である．
ＣＶＳ方式は，本来の証明書の検証者に代わって，認証パスの構築および有効性確認を含めた認証パスの検証を証明書検証サーバが代行する方式である。検証者が，証明書検証サーバに検証対象となる証明書と信頼する認証局の証明書を送付すると，検証対象証明書の正当性を確認した結果が返信される．
・・・（後略）・・・」（第６２７頁右欄第１８行〜第２８行）
Ｐ．「３．モバイル環境における証明書の有効性確認のモデル
前章で示したように，
ＣＶＳ方式は証明書の検証に関する大部分の処理を証明書検証サーバが代行する方式であり，非力な携帯電話端末が検証者となるモバイル環境での証明書検証方式に向いている
５．対比
　本願発明と引用発明とを対比する。
（１）引用発明の「ＵＩＣＣ」と本願発明の「制約されたネットワークエンティティ」を対比すると，
　本願発明の「制約されたネットワークエンティティ」について，本願の請求項６の「前記制約されたネットワークエンティティは，ＵＩＣＣまたはＵＳＩＭの少なくとも１つである」との記載からすると，「ＵＩＣＣ」が「制約されたネットワークエンティティ」の一態様である。
　したがって，引用発明の「ＵＩＣＣ」は，本願発明の「制約されたネットワークエンティティ」に相当する。
　引用発明の「端末の証明書」と本願発明の「ネットワークエンティティに関連付けられた証明書」を対比すると，
　本願発明の「ネットワークエンティティ」は，本願の請求項４の「前記ネットワークエンティティは，端末またはＭ２Ｍネットワークエンティティの少なくとも１つである」との記載からすると，「端末」が「ネットワークエンティティ」の一態様である。
　したがって，引用発明の「端末」は，本願発明の「ネットワークエンティティ」に相当する。
　そうすると，引用発明の「端末の証明書」は，本願発明の「ネットワークエンティティに関連付けられた証明書」に相当する。
　引用発明の「証明書検証サーバ」は，証明書検証メッセージを送信されるエンティティであり，さらに，上記Ｂの「フェーズ１の間，ＲＮは・・・（中略）・・・証明書検証サーバ・・・（中略）・・・にアクセスするような，特定目的のＩＰアドレスが許されるのみでなければならない。他の全てのアクセス（一般のインターネットアクセスを含む）は拒否されなければならない。」旨の記載からすると，インターネット上ではない，初期からアクセス可能なネットワーク上のエンティティといえるから，本願発明の「コアネットワークエンティティ」に相当する。
（２）引用発明の「ＵＩＣＣは，端末の証明書を取得し，
　ＵＩＣＣは，ＴＬＳクライアントとして，端末の証明書を用いて，端末との間で一時的な安全チャネルを確立」することと，
　本願発明の「制約されたネットワークエンティティで，ネットワークエンティティに関連付けられた証明書および前記ネットワークエンティティに関連付けられた公開鍵を受信するステップであって」，
　「前記証明書および前記公開鍵は，前記制約されたネットワークエンティティと前記ネットワークエンティティとの間で安全なチャネルを確立するために受信される，受信するステップと」，
　「前記受信した前記公開鍵および前記証明書を使用して前記制約されたネットワークエンティティで，前記ネットワークエンティティとの暫定的な安全なチャネルを確立するステップ」の両者を対比すると，
　上記（１）で検討したように，引用発明の「ＵＩＣＣ」，「端末」，「端末の証明書」は，それぞれ，本願発明の「制約されたネットワークエンティティ」，「ネットワークエンティティ」，「ネットワークエンティティに関連付けられた証明書」に相当し，
　引用発明の「一時的な安全チャネル」は，本願発明の「暫定的な安全なチャネル」に相当するから，
　前記両者は，後記する点で相違するものの，
“制約されたネットワークエンティティで，ネットワークエンティティに関連付けられた証明書を受信するステップであって，前記証明書は，前記制約されたネットワークエンティティと前記ネットワークエンティティとの間で安全なチャネルを確立するために受信される，受信するステップと，
　前記受信した前記証明書を使用して前記制約されたネットワークエンティティで，前記ネットワークエンティティとの暫定的な安全なチャネルを確立するステップ”である点で共通しているといえる。
（３）引用発明の「ＵＩＣＣは，証明書検証メッセージを，証明書検証サーバに送信することで，証明書検証サーバを用いて，安全なチャネルのセットアップに使用される端末の証明書の有効性をチェック」することと，
　本願発明の「前記制約されたネットワークエンティティによって，コアネットワークエンティティへ，前記ネットワークエンティティに関連付けられた前記証明書および前記公開鍵または前記公開鍵の導出のうちの１つを送信して，前記受信した証明書の有効性を決定するステップであって，前記制約されたネットワークエンティティは，前記コアネットワークエンティティをプロキシとして使用して前記証明書を検証する，決定するステップ」の両者を対比すると，
　上記（１）で検討したように，引用発明の「ＵＩＣＣ」，「証明書検証サーバ」，「端末の証明書」は，それぞれ，本願発明の「制約されたネットワークエンティティ」，「コアネットワークエンティティ」，「ネットワークエンティティに関連付けられた証明書」に相当し，
　引用発明の「端末の証明書の有効性をチェック」することは，「ネットワークエンティティに関連付けられた証明書」が有効か否かを決定する処理であるから，本願発明の「前記証明書を検証」することに相当し，
　引用発明の「証明書検証メッセージ」と，本願発明の「前記ネットワークエンティティに関連付けられた前記証明書および前記公開鍵または前記公開鍵の導出のうちの１つ」とは，「コアネットワークエンティティ」が「ネットワークエンティティに関連付けられた証明書」を検証するための情報である点で一致するから，
　前記両者は，後記する点で相違するものの，
“前記制約されたネットワークエンティティによって，コアネットワークエンティティへ，前記証明書を検証するための情報を送信して，前記受信した証明書の有効性を決定するステップであって，前記制約されたネットワークエンティティは，前記コアネットワークエンティティを使用して前記証明書を検証する，決定するステップ”である点で共通しているといえる。
（４）引用発明の「証明書検証サーバを用いた端末の証明書の有効性チェックが失敗すると，安全なチャネルの確立や認証を含む，端末のスタートアップ手続が中止」することと，
　本願発明の「前記証明書の前記有効性の前記表示に基づいて，前記ネットワークエンティティで認証するかどうか，および前記暫定的な安全なチャネルを有効化するかどうかを決定するステップ」の両者を対比すると，
　上記（１），（２）で検討したように，引用発明の「端末」，「証明書検証サーバ」，「端末の証明書」，「一時的な安全チャネル」は，それぞれ，本願発明の「ネットワークエンティティ」，「コアネットワークエンティティ」，「ネットワークエンティティに関連付けられた証明書」，「暫定的な安全なチャネル」に相当し，
　引用発明の「安全なチャネルの確立や認証を含む，端末のスタートアップ手続」は，「端末の証明書」が有効性チェックが失敗か否か，すなわち，証明書の有効性に基づいて，一時的な安全なチャネルの確立や認証の制御を決定するものであるから，
　前記両者は，後記する点で相違するものの，
“前記証明書の前記有効性の前記表示に基づいて，前記ネットワークエンティティで認証するかどうか，および前記暫定的な安全なチャネルの制御を決定するステップ”である点で共通しているといえる。
　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点） 
「制約されたネットワークエンティティで，ネットワークエンティティに関連付けられた証明書を受信するステップであって，前記証明書は，前記制約されたネットワークエンティティと前記ネットワークエンティティとの間で安全なチャネルを確立するために受信される，受信するステップと，
　前記受信した前記証明書を使用して前記制約されたネットワークエンティティで，前記ネットワークエンティティとの暫定的な安全なチャネルを確立するステップと，
　前記制約されたネットワークエンティティによって，コアネットワークエンティティへ，前記証明書を検証するための情報を送信して，前記受信した証明書の有効性を決定するステップであって，前記制約されたネットワークエンティティは，前記コアネットワークエンティティを使用して前記証明書を検証する，決定するステップと，
　前記証明書の前記有効性の前記表示に基づいて，前記ネットワークエンティティで認証するかどうか，および前記暫定的な安全なチャネルの制御を決定するステップを含むことを特徴とする方法。」
（相違点１）
本願発明では，「ネットワークエンティティに関連付けられた証明書」と「ネットワークエンティティに関連付けられた公開鍵」を用いるのに対して，
引用発明では，「ネットワークエンティティに関連付けられた公開鍵」については明示されていない点。
（相違点２）
本願発明では，「コアネットワークエンティティ」に，「前記ネットワークエンティティに関連付けられた前記証明書および前記公開鍵または前記公開鍵の導出のうちの１つ」を送信し，「コアネットワークエンティティ」を「プロキシ」として使用し，「コアネットワークエンティティ」から「前記証明書の前記有効性の表示」を受信するのに対して，
引用発明では，証明書検証サーバ（コアネットワークエンティティ）に，証明書検証メッセージを送信することで，証明書検証サーバを用いて端末の証明書の有効性をチェックするものの，
　証明書検証サーバ（コアネットワークエンティティ）との送受信データの具体的内容や，プロキシとして使用する点については明示されていない点。
（相違点３）
本願発明では，「暫定的な安全なチャネル」を「有効化」するかどうかを決定するのに対して，
引用発明では，「安全なチャネルの確立や認証を含む，端末のスタートアップ手続」を中止するかどうか制御するものの，
　「有効化」処理について明示していない点。
６．当審の判断
　上記相違点１乃至相違点３について検討する。
（１）相違点１について
　引用発明の「ＵＩＣＣ」は，「ＴＬＳクライアント」として，「端末の証明書」を用いて，「端末」との間で「一時的な安全チャネル」を確立するものであるところ，
　ＴＬＳ接続において，クライアントがサーバ証明書及びその公開鍵を受信して安全な通信路を確立する点は，例えば，参考文献１（上記Ｅ，Ｆ参照）に記載されているように，従来から当業者が必要に応じて採用している常とう手段であった。
　してみると，引用発明において，公開鍵を用いるように構成すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
（２）相違点２について
　引用発明は，証明書検証メッセージを，証明書検証サーバに送信することで，証明書検証サーバを用いて，端末の証明書の有効性をチェックするところ，
　端末がサーバに証明書を送信し，端末ではなくサーバが該証明書を検証して検証結果を端末に送信する技術は，例えば，参考文献２（上記Ｈ参照），参考文献３（上記Ｉ，Ｊ参照），参考文献４（上記Ｋ，Ｌ，Ｍ参照），参考文献５（上記Ｎ，Ｐ参照）に記載されているように，本願の優先日前には，情報処理の技術分野において普通に採用されていた周知技術であった。
　してみると，引用発明において，ＵＩＣＣが証明書検証サーバに端末の証明書を送信し，証明書検証サーバが前記証明書の有効性を決定し，ＵＩＣＣが前記証明書の有効性の表示を受信するように構成すること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
（３）相違点３について
　引用発明は「証明書検証サーバを用いた端末の証明書の有効性チェックが失敗すると，安全なチャネルの確立や認証を含む，端末のスタートアップ手続が中止される」ところ，
　デバイス間の安全チャネルの確立処理において，証明書の検証が成功した場合，該チャネルを継続し，そうでない場合は，切断する技術は，例えば，参考文献１（上記Ｇ参照），参考文献２（上記Ｈ参照）に記載されているように，本願の優先日前には，情報処理の技術分野において普通に採用されていた周知技術であった。
　してみると，引用発明において，「端末の証明書」の有効性に基づいて，「安全なチャネル」を継続させることで有効化するように構成すること，すなわち，上記相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
（４）小括
　上記で検討したごとく，相違点１乃至相違点３は格別のものではなく，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，上記引用発明及び，当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
７．むすび 
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　よって，結論のとおり審決する。