【事件の表示】
　特願２０１６−５４１９６０「対象のコンピューティング装置で実施される動作を認証する方法」拒絶査定不服審判事件〔平成２７年　３月１９日国際公開，ＷＯ２０１５／０３８２２０，平成２８年１１月１０日国内公表，特表２０１６−５３５５４７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２０１４年７月１日（パリ条約による優先権主張外国庁受理２０１３年９月１２日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２８年５月１０日付けで特許法１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，平成２９年６月１６日付けで審査請求がなされ，平成３０年８月２９日付けで審査官により拒絶理由が通知され，これに対して平成３０年１２月３日付けで意見書が提出されると共に手続補正がなされたが，令和１年５月３０日付けで審査官により拒絶査定がなされ，これに対して令和１年９月２０日付けで審判請求がなされると共に手続補正がなされ，令和１年１１月１８日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ，令和２年３月２日付けで上申書が提出され，当審により令和２年７月２２日付けで拒絶理由が通知され，これに対して令和２年１０月７日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という）は，令和２年１０月７日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。
　
「対象のコンピューティング装置（１０）で実施される動作を許可する方法であって，
　管理者のコンピュータが，前記対象のコンピューティング装置（１０）での動作を実施するため，前記動作を許可する要求を生成するステップと，
　前記管理者のコンピュータが，前記要求を管理者に割り当てられた第１の秘密鍵と公開鍵の対の秘密鍵で署名するステップと，
　前記管理者のコンピュータが，前記要求を認証サーバ（３０４）に送信するステップと，
　前記管理者のコンピュータが，前記要求および許可トークンを含む認証応答を前記認証サーバ（３０４）から受信するステップと，
　前記管理者のコンピュータが，前記認証応答を管理者に割り当てられた前記第１の秘密鍵と公開鍵の対の前記秘密鍵で署名して，前記認証応答を前記対象のコンピューティング装置（１０）に送信するステップと，
　を含み，
　前記対象のコンピューティング装置（１０）がモバイル通信装置である，方法。」
　
第３．当審における拒絶理由
　当審における令和２年７月２２日付けの拒絶理由（以下，これを「当審拒絶理由」という）は，概略，次のとおりである。
　
「本件出願の請求項１〜請求項９に係る発明は，下記の引用文献に記載の発明に基づいて当業者が容易に発明をすることができたものであるので，特許法２９条２項の規定により特許を受けることができない。
　
　引用文献一覧
　１．特開２００６−０７２９７０号公報（２００６年３月１６日公開）
　２．特開２０１２−２３０４５４号公報（２０１２年１１月２２日公開）」
　
第４．引用刊行物に記載の事項
１．当審拒絶理由に引用した,本願の第１国出願前に既に公知である，特開２００６−０７２９７０号公報（２００６年３月１６日公開，以下，これを「引用文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【０００３】
  以上のような，ネットワークを介する多くの伝送は，デジタル署名などの，何らかのタイプのセキュリティを利用してメッセージが本物であることを検証することができる。（当該段落の以下の記載は省略）」
　
Ｂ．「【００２７】
  次に，本発明を実施する際に利用されるソフトウェアアーキテクチャを説明する。簡単に述べると，そのアーキテクチャは，
コンピュータ１０のような機能ユーザ（以降，「ＦＵ」と呼ぶ），多機能デバイス３０のような機能プロバイダ（以降，「ＦＰ」と呼ぶ），セキュリティアプリケーション４１３のようなセキュリティアプリケーション（以降，「ＳＡ」と呼ぶ）
各コンポーネントは，本発明によるジョブ送信プロセスを実行するための機能を提供する様々なモジュールを含む。例えば，印刷動作を実行する際，多機能デバイス３０に印刷ジョブを送信することを望む機能ユーザは，セキュリティアプリケーションにジョブ許可要求コマンドを伝送する
その要求は，セキュリティアプリケーションが，ＴＡＴ（トランザクション許可トークン）を含む許可応答を機能ユーザに提供するためのものであってもよい
許可応答の中に含まれるＴＡＴは
セキュリティアプリケーションは，許可要求を処理して，許可応答で機能ユーザに応答する。機能ユーザは，許可応答を受信した後，印刷ジョブを許可応答と一緒にデバイス３０に送信し
　
Ｃ．「
ジョブをＦＰに送信することを望むＦＵは，許可要求をＳＡに伝送する
ＳＡは，その要求を処理し，許可応答を生成する。ＴＡＴのブロックとともにＦＰに配信されたＴＡＴの１つが，ＳＡによって許可応答の中に含められ，次に，その応答が，許可要求を伝送したＦＵに戻される
　
Ｄ．「【００４５】
  次に，
ＦＵが，ＳＡに対する接続を確立して，許可要求をＳＡに伝送する（ステップＳ９０２）。接続は，好ましくは，ＳＳＬなどのセキュリティで保護された接続である。これは，図６で示された矢印１および矢印２に対応する。ただし，許可要求は，ＳＳＬを介して伝送される代りに，暗号化された形態でＳＡに伝送されることも可能である。セキュリティで保護された接続が確立されると，ＦＵは，許可要求コマンドをＳＡに送信する（ステップＳ９０３）
暗号化された（デジタル署名された）ＴＡＴが，許可応答の中に含められ，ＳＡが，許可応答をＦＵに提供する
【００４６】
  
ＦＵは，ＳＡから許可応答を受信した後，ジョブデータおよび許可応答を含むジョブ要求の形態でＦＰコマンドパッケージを構築する。つまり，ＦＵによってＳＡから受信される許可応答は，受信されたのと同一の形態でジョブ要求の中に単に挿入される。ジョブ要求（ジョブデータおよび許可応答を含む）は，好ましくは，セッションキーを利用して暗号化され，次に，暗号化されたジョブが，ＦＵによってＦＰに送信される
　
２．同じく，当審拒絶理由に引用した，本願の第１国出願前に既に公知である，特開２０１２−２３０４５４号公報（２０１２年１１月２２日公開，以下，これを「引用文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｅ．「【００３９】
  主演算制御手段１４１は，ＤＲＭエージェントプログラムが動作することにより，ファイルＤＲＭ化部１４１ａ，ライセンス要求部１４１ｂ，署名部１４１ｃ，信頼リスト要求部１４１ｄの各々の機能部として動作する。ファイルＤＲＭ化部１４１ａは，対象ファイル１４２ａをＤＲＭ化する。ライセンス要求部１４１ｂは，ライセンス要求に署名を付加して送信する。署名部１４１ｃは，公開鍵に署名を付加する。信頼リスト要求部１４１ｄは，組織外ユーザのアカウントの登録・更新・削除を要求し，このアカウント要求に署名を付加して送信する。」
　
Ｆ．「【００５２】
  要求受信装置１３の受信部１３１ｄでは，受信した依頼データ３００の中の要求内容３１１に対する組織内ユーザの署名３１２を検証して改竄の有無をチェックする（ステップＡ０３）。要求の内容が改竄されていないことを確認できたら，要求内容３１１を識別する（ステップＡ０４）。要求内容３１１が「ユーザ情報の登録」である場合には，ステップＡ０３〜０４で要求受信装置１３の受信部１３１ｄで公開鍵３０１に対する組織内ユーザの署名３０２を検証すると共に，この公開鍵に対する署名３０２の署名者と要求内容３１１に対する署名３１２の署名者とが一致するか否かを検証する（ステップＡ０５）。」
　
３．本願の第１国出願前に既に公知である，特開２００７−２６４７７９号公報（２００７年１０月１１日公開，以下，これを「周知技術文献」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｇ．「【００７５】
  また，認証印刷ジョブ管理サーバ２０に代えて／加えて，ホスト装置１０やプリンタ装置３０内，更には外部記憶手段（ＵＳＢメモリや携帯端末なども含む）に認証印刷ジョブを蓄積する構成としてもよい。プリンタ装置３０内に認証印刷ジョブを蓄積する場合，プリンタ装置３０は，自装置内の認証印刷ジョブ蓄積手段を参照して認証印刷ジョブを取得することもできる。」
　
第５．引用文献１に記載の発明
１．上記Ｂの「コンピュータ１０のような機能ユーザ（以降，「ＦＵ」と呼ぶ），多機能デバイス３０のような機能プロバイダ（以降，「ＦＰ」と呼ぶ），セキュリティアプリケーション４１３のようなセキュリティアプリケーション（以降，「ＳＡ」と呼ぶ）」という記載，同じく，上記Ｂの「各コンポーネントは，本発明によるジョブ送信プロセスを実行するための機能を提供する様々なモジュールを含む。例えば，印刷動作を実行する際，多機能デバイス３０に印刷ジョブを送信することを望む機能ユーザは，セキュリティアプリケーションにジョブ許可要求コマンドを伝送する」という記載，及び，同じく，上記Ｂの「セキュリティアプリケーションは，許可要求を処理して，許可応答で機能ユーザに応答する」という記載から，引用文献１には，
“機能プロバイダにおいて実行される動作を許可する方法”に関して記載されていることが読み取れる。
　
２．上記１．において引用した上記Ｂの記載，及び，上記Ｃの「ジョブをＦＰに送信することを望むＦＵは，許可要求をＳＡに伝送する，ＳＡは，その要求を処理し，許可応答を生成する」という記載から，引用文献１においては，
“ジョブを機能プロバイダに送信することを望む機能ユーザが，許可要求を生成する”ものであることが読み取れる。
　
３．上記１．において引用した上記Ｂの記載内容，上記２．において引用した上記Ｃの記載内容，及び，上記Ｄの「ＦＵが，ＳＡに対する接続を確立して，許可要求をＳＡに伝送する（ステップＳ９０２）。接続は，好ましくは，ＳＳＬなどのセキュリティで保護された接続である。これは，図６で示された矢印１および矢印２に対応する。ただし，許可要求は，ＳＳＬを介して伝送される代りに，暗号化された形態でＳＡに伝送されることも可能である。セキュリティで保護された接続が確立されると，ＦＵは，許可要求コマンドをＳＡに送信する（ステップＳ９０３）」という記載から，引用文献１においては，
“機能ユーザが，セキュリティアプリケーションに許可要求を送信する”ものであることが読み取れる。
　
４．上記Ｂの「その要求は，セキュリティアプリケーションが，ＴＡＴ（トランザクション許可トークン）を含む許可応答を機能ユーザに提供するためのものであってもよい」という記載，同じく，上記Ｂの「許可応答の中に含まれるＴＡＴ」という記載，上記Ｃの「ＳＡは，その要求を処理し，許可応答を生成する。ＴＡＴのブロックとともにＦＰに配信されたＴＡＴの１つが，ＳＡによって許可応答の中に含められ，次に，その応答が，許可要求を伝送したＦＵに戻される」という記載，及び，上記Ｄの「暗号化された（デジタル署名された）ＴＡＴが，許可応答の中に含められ，ＳＡが，許可応答をＦＵに提供する」という記載から，引用文献１においては，
“機能ユーザが，セキュリティアプリケーションから，デジタル署名されたトランザクション許可トークンを含む許可応答を受信する”ものであることが読み取れる。
　
５．上記Ｂの「機能ユーザは，許可応答を受信した後，印刷ジョブを許可応答と一緒にデバイス３０に送信し」という記載，及び，上記Ｄの「ＦＵは，ＳＡから許可応答を受信した後，ジョブデータおよび許可応答を含むジョブ要求の形態でＦＰコマンドパッケージを構築する。つまり，ＦＵによってＳＡから受信される許可応答は，受信されたのと同一の形態でジョブ要求の中に単に挿入される。ジョブ要求（ジョブデータおよび許可応答を含む）は，好ましくは，セッションキーを利用して暗号化され，次に，暗号化されたジョブが，ＦＵによってＦＰに送信される」という記載から，引用文献１においては，
“機能ユーザが，デジタル署名されたトランザクション許可トークンを含む許可応答，及び，ジョブデータを含むジョブ要求を，機能プロバイダに送信する”ものであることが読み取れる。
　
６．上記１．〜上記５．において検討した事項から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「機能プロバイダおいて実行される動作を許可を行う方法であって，
　ジョブを前記機能プロバイダに送信することを望む機能ユーザが，許可要求を生成し，
　前記機能ユーザが，セキュリティアプリケーションに，前記許可要求を送信し，
　前記機能ユーザが，前記セキュリティアプリケーションから，デジタル署名されたトランザクション許可トークンを含む許可応答を受信し，
　前記機能ユーザが，前記デジタル署名されたトランザクション許可トークンを含む前記許可応答，及び，ジョブデータを含むジョブ要求を，前記機能プロバイダに送信する，ことを含む方法。」
　
第６．本願発明と引用発明との対比
１．引用発明における「機能プロバイダ」，「機能ユーザ」，「セキュリティアプリケーション」，及び，「ジョブ」が，それぞれ，
　本願発明における「対象のコンピューティング装置（１０）」，「管理者のコンピュータ」，「認証サーバ（３０４）」，及び，「対象のコンピューティング装置（１０）で実施される動作」に相当し，
　引用発明における「許可要求」，及び，「トランザクション許可トークン」が，それぞれ，
　本願発明における「動作を許可する要求」，及び，「許可トークン」に相当するので，
　引用発明における「機能プロバイダで実行されるジョブの送信の許可を行う方法であって」が，
　本願発明における「対象のコンピューティング装置（１０）で実施される動作を許可する方法であって」に相当する。
　
２．引用発明における「機能ユーザが，前記機能プロバイダにジョブを送信するために，許可する要求を生成し」が，
　本願発明における「管理者のコンピュータが，前記対象のコンピューティング装置（１０）での動作を実施するため，前記動作を許可する要求を生成するステップ」に相当する。
　
３．本願発明において，「認証サーバ（３０４）」に送信される「要求」は，「管理者のコンピュータ」の「秘密鍵」で「署名」されたものであるから，
　引用発明における「機能ユーザが，セキュリティアプリケーションに，許可要求を送信し」と，
　本願発明における「管理者のコンピュータが，前記要求を認証サーバ（３０４）に送信するステップ」とは，
“管理者のコンピュータが，要求情報を認証サーバ（３０４）に送信するステップ”である点で共有する。
　
４．引用発明における「機能ユーザが，前記セキュリティアプリケーションから，デジタル署名されたトランザクション許可トークンを含む許可応答を受信し」と，
　本願発明における「管理者のコンピュータが，前記要求および許可トークンを含む認証応答を前記認証サーバ（３０４）から受信するステップ」とは，
“管理者のコンピュータが，許可トークンを含む認証応答を認証サーバ（３０４）から受信するステップ”である点で共通する。
　
５．引用発明における「機能ユーザが，前記デジタル署名されたトランザクション許可トークンを含む前記許可応答，及び，ジョブデータを含むジョブ要求を，前記機能プロバイダに送信する」ことと，
　本願発明における「管理者のコンピュータが，前記認証応答を管理者に割り当てられた前記第１の秘密鍵と公開鍵の対の前記秘密鍵で署名して，前記認証応答を前記対象のコンピューティング装置（１０）に送信するステップ」とは，
“管理者のコンピュータが，認証応答情報を対象のコンピューティング装置（１０）に送信するステップ”である点で共通する。
６．以上，上記１．〜５．において検討した事項から，本願発明と，引用発明との，一致点．及び，相違点は，以下のとおりである。
　
［一致点］
　対象のコンピューティング装置（１０）で実施される動作を許可する方法であって，
　管理者のコンピュータが，前記対象のコンピューティング装置（１０）での動作を実施するため，前記動作を許可する要求を生成するステップと，
　前記管理者のコンピュータが，要求情報を認証サーバ（３０４）に送信するステップと，
　前記管理者のコンピュータが，許可トークンを含む認証応答を前記認証サーバ（３０４）から受信するステップと，
　前記管理者のコンピュータが，認証応答情報を前記対象のコンピューティング装置（１０）に送信するステップと，
　を含む方法。
　
［相違点１］
　本願発明においては，「管理者のコンピュータが，前記要求を管理者に割り当てられた第１の秘密鍵と公開鍵の対の秘密鍵で署名するステップ」が存在するのに対して，
　引用発明においては，「機能ユーザ」が，「要求」に「署名」する点について，特に言及されていない点。
　
［相違点２］
“要求情報”に関して，
　本願発明においては，「要求」は，「管理者に割り当てられた第１の秘密鍵と公開鍵の対の秘密鍵で署名」されたものであるのに対して，
　引用発明においては，「要求」に「署名」することについては，特に，言及されていない点。
　
［相違点３］
“管理者のコンピュータが，認証応答情報を前記対象のコンピューティング装置（１０）に送信するステップ”に関して，
　本願発明においては，「管理者のコンピュータが，前記認証応答を管理者に割り当てられた前記第１の秘密鍵と公開鍵の対の前記秘密鍵で署名して，前記認証応答を前記対象のコンピューティング装置（１０）に送信する」ものであるのに対して，
　引用発明においては，「許可応答」に対して「署名」する点について，特に言及されていない点。
　
［相違点４］
　本願発明においては，「対象のコンピューティング装置（１０）がモバイル通信装置である」のに対して，
　引用発明においては，「機能プロバイダ」が，「モバイル通信装置」である点について，特に言及されていない点。
　
第７．相違点についての当審の判断
１．［相違点１］〜［相違点３］について
　上記Ａに引用した記載にもあるとおり，「署名」自体は，当該技術分野において周知の技術事項である。
　そして，上記Ｅに引用した，引用文献２の記載にもあるとおり，「要求」に署名をして送信することも，周知の技術事項である。
　したがって，引用発明において，「機能ユーザ」から，「セキュリティアプリケーション」へ送信する「要求」に「署名」すること，及び，「機能ユーザ」から，「機能プロバイダ」へ送信する「許可応答」に「署名」することは，何れも，当業者が適宜なし得る事項である。
　よって，［相違点１］〜［相違点３］は，格別のものではない。
　
２．［相違点４］について
　出力先として，「プリンタ装置」に代えて，「携帯端末」を採用することは，上記Ｇに引用した，周知技術文献の記載内容にもあるとおり，当業者が必要に応じて適宜選択し得る事項であるから，引用発明においても，「多機能デバイス３０のような機能プロバイダ」に代えて，「携帯端末」を採用することは，当業者が適宜なし得る事項である。
　よって，［相違点４］は，格別のものではない。
　
３．以上，上記１．，及び，２．において検討したとおりであるから，［相違点１］〜［相違点４］は，いずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　なお，審判請求人は，令和２年１０月７日付けの意見書において，本願発明と，引用発明との構成の違い等について主張しているが，本願発明と，引用発明との相違点については，上記において検討したとおりであるから，当該意見書における主張は採用できない。
　
第８．むすび
　したがって，本願発明は，引用発明，引用文献２に記載の技術事項，及び，周知技術文献に記載の周知技術に基づいて当業者が容易に発明をすることができたものであるので，特許法２９条２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。