• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L
管理番号 1375562
審判番号 不服2019-12531  
総通号数 260 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-08-27 
種別 拒絶査定不服の審決 
審判請求日 2019-09-20 
確定日 2021-06-29 
事件の表示 特願2016-541960「対象のコンピューティング装置で実施される動作を認証する方法」拒絶査定不服審判事件〔平成27年 3月19日国際公開,WO2015/038220,平成28年11月10日国内公表,特表2016-535547〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2014年7月1日(パリ条約による優先権主張外国庁受理2013年9月12日 アメリカ合衆国)を国際出願日とする出願であって,
平成28年5月10日付けで特許法184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,平成29年6月16日付けで審査請求がなされ,平成30年8月29日付けで審査官により拒絶理由が通知され,これに対して平成30年12月3日付けで意見書が提出されると共に手続補正がなされたが,令和1年5月30日付けで審査官により拒絶査定がなされ,これに対して令和1年9月20日付けで審判請求がなされると共に手続補正がなされ,令和1年11月18日付けで審査官により特許法164条3項の規定に基づく報告がなされ,令和2年3月2日付けで上申書が提出され,当審により令和2年7月22日付けで拒絶理由が通知され,これに対して令和2年10月7日付けで意見書が提出されると共に手続補正がなされたものである。

第2.本願発明について
本願の請求項1に係る発明(以下,これを「本願発明」という)は,令和2年10月7日付けの手続補正により補正された特許請求の範囲の請求項1に記載された,次のとおりのものである。

「対象のコンピューティング装置(10)で実施される動作を許可する方法であって,
管理者のコンピュータが,前記対象のコンピューティング装置(10)での動作を実施するため,前記動作を許可する要求を生成するステップと,
前記管理者のコンピュータが,前記要求を管理者に割り当てられた第1の秘密鍵と公開鍵の対の秘密鍵で署名するステップと,
前記管理者のコンピュータが,前記要求を認証サーバ(304)に送信するステップと,
前記管理者のコンピュータが,前記要求および許可トークンを含む認証応答を前記認証サーバ(304)から受信するステップと,
前記管理者のコンピュータが,前記認証応答を管理者に割り当てられた前記第1の秘密鍵と公開鍵の対の前記秘密鍵で署名して,前記認証応答を前記対象のコンピューティング装置(10)に送信するステップと,
を含み,
前記対象のコンピューティング装置(10)がモバイル通信装置である,方法。」

第3.当審における拒絶理由
当審における令和2年7月22日付けの拒絶理由(以下,これを「当審拒絶理由」という)は,概略,次のとおりである。

「本件出願の請求項1?請求項9に係る発明は,下記の引用文献に記載の発明に基づいて当業者が容易に発明をすることができたものであるので,特許法29条2項の規定により特許を受けることができない。

引用文献一覧
1.特開2006-072970号公報(2006年3月16日公開)
2.特開2012-230454号公報(2012年11月22日公開)」

第4.引用刊行物に記載の事項
1.当審拒絶理由に引用した,本願の第1国出願前に既に公知である,特開2006-072970号公報(2006年3月16日公開,以下,これを「引用文献1」という)には,関連する図面と共に,次の事項が記載されている。

A.「【0003】
以上のような,ネットワークを介する多くの伝送は,デジタル署名などの,何らかのタイプのセキュリティを利用してメッセージが本物であることを検証することができる。(当該段落の以下の記載は省略)」

B.「【0027】
次に,本発明を実施する際に利用されるソフトウェアアーキテクチャを説明する。簡単に述べると,そのアーキテクチャは,コンピュータ10のような機能ユーザ(以降,「FU」と呼ぶ),多機能デバイス30のような機能プロバイダ(以降,「FP」と呼ぶ),セキュリティアプリケーション413のようなセキュリティアプリケーション(以降,「SA」と呼ぶ),およびディレクトリサービス414のようなディレクトリサービス(以降,「DS」と呼ぶ)を含む。各コンポーネントは,本発明によるジョブ送信プロセスを実行するための機能を提供する様々なモジュールを含む。例えば,印刷動作を実行する際,多機能デバイス30に印刷ジョブを送信することを望む機能ユーザは,セキュリティアプリケーションにジョブ許可要求コマンドを伝送する。その要求は,セキュリティアプリケーションが,TAT(トランザクション許可トークン)を含む許可応答を機能ユーザに提供するためのものであってもよい。その応答は,印刷ジョブをデバイス30に伝送するために利用される。以下により詳細に説明するとおり,許可応答の中に含まれるTATは,印刷ジョブのリプレイアタックを防止するのに利用される。セキュリティアプリケーションは,許可要求を処理して,許可応答で機能ユーザに応答する。機能ユーザは,許可応答を受信した後,印刷ジョブを許可応答と一緒にデバイス30に送信し,機能プロバイダ(デバイス30)が,印刷ジョブを相応した形で処理する。以下により詳細に説明するとおり,機能プロバイダによる印刷ジョブの処理は,印刷ジョブとともに受信される許可応答の中に含まれるTATが有効であることを検証して,リプレイアタックを防止するようにすることが含まれることが可能である。次に,以上のプロセスをより詳細に説明する。」

C.「ジョブをFPに送信することを望むFUは,許可要求をSAに伝送する。SAは,その要求を処理し,許可応答を生成する。TATのブロックとともにFPに配信されたTATの1つが,SAによって許可応答の中に含められ,次に,その応答が,許可要求を伝送したFUに戻される。FUは,ジョブを,TATを含む許可応答と一緒に,FPに配信する」(段落【0032】より引用)

D.「【0045】
次に,FUが,SAに対する接続を確立して,許可要求をSAに伝送する(ステップS902)。接続は,好ましくは,SSLなどのセキュリティで保護された接続である。これは,図6で示された矢印1および矢印2に対応する。ただし,許可要求は,SSLを介して伝送される代りに,暗号化された形態でSAに伝送されることも可能である。セキュリティで保護された接続が確立されると,FUは,許可要求コマンドをSAに送信する(ステップS903)。これは,図6で示された矢印3に対応する。SAは,許可要求を受信すると,その要求を処理して許可応答を構築する(ステップS904)。許可応答を構築する際,SAは,許可要求の中で特定されたFPのためのTATを獲得し,そのTATにデジタル署名する。次に,暗号化された(デジタル署名された)TATが,許可応答の中に含められ,SAが,許可応答をFUに提供する(ステップS905)。SAは,好ましくは,セキュリティで保護された形で(すなわち,SSL,または暗号化を介して)許可応答をFUに提供する。
【0046】
FUは,SAから許可応答を受信した後,ジョブデータおよび許可応答を含むジョブ要求の形態でFPコマンドパッケージを構築する。つまり,FUによってSAから受信される許可応答は,受信されたのと同一の形態でジョブ要求の中に単に挿入される。ジョブ要求(ジョブデータおよび許可応答を含む)は,好ましくは,セッションキーを利用して暗号化され,次に,暗号化されたジョブが,FUによってFPに送信される(ステップS906)。暗号化されたジョブ要求を受信すると,FPは,セッションキーを利用して,受信されたデータを解読し,許可応答からTATを抽出する。FPは,抽出されたTATが有効であるかどうかを判定し(ステップS907),有効であった場合,相応した形でそのジョブを処理する(ステップS908)(すなわち,ジョブは,印刷ジョブである場合,印刷される)。TATが無効であると判定された場合,ジョブは,拒否される(ステップS909)。ステップS907のTAT検証プロセスを,図10および図11に関連して以下により詳細に説明する。」

2.同じく,当審拒絶理由に引用した,本願の第1国出願前に既に公知である,特開2012-230454号公報(2012年11月22日公開,以下,これを「引用文献2」という)には,関連する図面と共に,次の事項が記載されている。

E.「【0039】
主演算制御手段141は,DRMエージェントプログラムが動作することにより,ファイルDRM化部141a,ライセンス要求部141b,署名部141c,信頼リスト要求部141dの各々の機能部として動作する。ファイルDRM化部141aは,対象ファイル142aをDRM化する。ライセンス要求部141bは,ライセンス要求に署名を付加して送信する。署名部141cは,公開鍵に署名を付加する。信頼リスト要求部141dは,組織外ユーザのアカウントの登録・更新・削除を要求し,このアカウント要求に署名を付加して送信する。」

F.「【0052】
要求受信装置13の受信部131dでは,受信した依頼データ300の中の要求内容311に対する組織内ユーザの署名312を検証して改竄の有無をチェックする(ステップA03)。要求の内容が改竄されていないことを確認できたら,要求内容311を識別する(ステップA04)。要求内容311が「ユーザ情報の登録」である場合には,ステップA03?04で要求受信装置13の受信部131dで公開鍵301に対する組織内ユーザの署名302を検証すると共に,この公開鍵に対する署名302の署名者と要求内容311に対する署名312の署名者とが一致するか否かを検証する(ステップA05)。」

3.本願の第1国出願前に既に公知である,特開2007-264779号公報(2007年10月11日公開,以下,これを「周知技術文献」という)には,関連する図面と共に,次の事項が記載されている。

G.「【0075】
また,認証印刷ジョブ管理サーバ20に代えて/加えて,ホスト装置10やプリンタ装置30内,更には外部記憶手段(USBメモリや携帯端末なども含む)に認証印刷ジョブを蓄積する構成としてもよい。プリンタ装置30内に認証印刷ジョブを蓄積する場合,プリンタ装置30は,自装置内の認証印刷ジョブ蓄積手段を参照して認証印刷ジョブを取得することもできる。」

第5.引用文献1に記載の発明
1.上記Bの「コンピュータ10のような機能ユーザ(以降,「FU」と呼ぶ),多機能デバイス30のような機能プロバイダ(以降,「FP」と呼ぶ),セキュリティアプリケーション413のようなセキュリティアプリケーション(以降,「SA」と呼ぶ)」という記載,同じく,上記Bの「各コンポーネントは,本発明によるジョブ送信プロセスを実行するための機能を提供する様々なモジュールを含む。例えば,印刷動作を実行する際,多機能デバイス30に印刷ジョブを送信することを望む機能ユーザは,セキュリティアプリケーションにジョブ許可要求コマンドを伝送する」という記載,及び,同じく,上記Bの「セキュリティアプリケーションは,許可要求を処理して,許可応答で機能ユーザに応答する」という記載から,引用文献1には,
“機能プロバイダにおいて実行される動作を許可する方法”に関して記載されていることが読み取れる。

2.上記1.において引用した上記Bの記載,及び,上記Cの「ジョブをFPに送信することを望むFUは,許可要求をSAに伝送する,SAは,その要求を処理し,許可応答を生成する」という記載から,引用文献1においては,
“ジョブを機能プロバイダに送信することを望む機能ユーザが,許可要求を生成する”ものであることが読み取れる。

3.上記1.において引用した上記Bの記載内容,上記2.において引用した上記Cの記載内容,及び,上記Dの「FUが,SAに対する接続を確立して,許可要求をSAに伝送する(ステップS902)。接続は,好ましくは,SSLなどのセキュリティで保護された接続である。これは,図6で示された矢印1および矢印2に対応する。ただし,許可要求は,SSLを介して伝送される代りに,暗号化された形態でSAに伝送されることも可能である。セキュリティで保護された接続が確立されると,FUは,許可要求コマンドをSAに送信する(ステップS903)」という記載から,引用文献1においては,
“機能ユーザが,セキュリティアプリケーションに許可要求を送信する”ものであることが読み取れる。

4.上記Bの「その要求は,セキュリティアプリケーションが,TAT(トランザクション許可トークン)を含む許可応答を機能ユーザに提供するためのものであってもよい」という記載,同じく,上記Bの「許可応答の中に含まれるTAT」という記載,上記Cの「SAは,その要求を処理し,許可応答を生成する。TATのブロックとともにFPに配信されたTATの1つが,SAによって許可応答の中に含められ,次に,その応答が,許可要求を伝送したFUに戻される」という記載,及び,上記Dの「暗号化された(デジタル署名された)TATが,許可応答の中に含められ,SAが,許可応答をFUに提供する」という記載から,引用文献1においては,
“機能ユーザが,セキュリティアプリケーションから,デジタル署名されたトランザクション許可トークンを含む許可応答を受信する”ものであることが読み取れる。

5.上記Bの「機能ユーザは,許可応答を受信した後,印刷ジョブを許可応答と一緒にデバイス30に送信し」という記載,及び,上記Dの「FUは,SAから許可応答を受信した後,ジョブデータおよび許可応答を含むジョブ要求の形態でFPコマンドパッケージを構築する。つまり,FUによってSAから受信される許可応答は,受信されたのと同一の形態でジョブ要求の中に単に挿入される。ジョブ要求(ジョブデータおよび許可応答を含む)は,好ましくは,セッションキーを利用して暗号化され,次に,暗号化されたジョブが,FUによってFPに送信される」という記載から,引用文献1においては,
“機能ユーザが,デジタル署名されたトランザクション許可トークンを含む許可応答,及び,ジョブデータを含むジョブ要求を,機能プロバイダに送信する”ものであることが読み取れる。

6.上記1.?上記5.において検討した事項から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「機能プロバイダおいて実行される動作を許可を行う方法であって,
ジョブを前記機能プロバイダに送信することを望む機能ユーザが,許可要求を生成し,
前記機能ユーザが,セキュリティアプリケーションに,前記許可要求を送信し,
前記機能ユーザが,前記セキュリティアプリケーションから,デジタル署名されたトランザクション許可トークンを含む許可応答を受信し,
前記機能ユーザが,前記デジタル署名されたトランザクション許可トークンを含む前記許可応答,及び,ジョブデータを含むジョブ要求を,前記機能プロバイダに送信する,ことを含む方法。」

第6.本願発明と引用発明との対比
1.引用発明における「機能プロバイダ」,「機能ユーザ」,「セキュリティアプリケーション」,及び,「ジョブ」が,それぞれ,
本願発明における「対象のコンピューティング装置(10)」,「管理者のコンピュータ」,「認証サーバ(304)」,及び,「対象のコンピューティング装置(10)で実施される動作」に相当し,
引用発明における「許可要求」,及び,「トランザクション許可トークン」が,それぞれ,
本願発明における「動作を許可する要求」,及び,「許可トークン」に相当するので,
引用発明における「機能プロバイダで実行されるジョブの送信の許可を行う方法であって」が,
本願発明における「対象のコンピューティング装置(10)で実施される動作を許可する方法であって」に相当する。

2.引用発明における「機能ユーザが,前記機能プロバイダにジョブを送信するために,許可する要求を生成し」が,
本願発明における「管理者のコンピュータが,前記対象のコンピューティング装置(10)での動作を実施するため,前記動作を許可する要求を生成するステップ」に相当する。

3.本願発明において,「認証サーバ(304)」に送信される「要求」は,「管理者のコンピュータ」の「秘密鍵」で「署名」されたものであるから,
引用発明における「機能ユーザが,セキュリティアプリケーションに,許可要求を送信し」と,
本願発明における「管理者のコンピュータが,前記要求を認証サーバ(304)に送信するステップ」とは,
“管理者のコンピュータが,要求情報を認証サーバ(304)に送信するステップ”である点で共有する。

4.引用発明における「機能ユーザが,前記セキュリティアプリケーションから,デジタル署名されたトランザクション許可トークンを含む許可応答を受信し」と,
本願発明における「管理者のコンピュータが,前記要求および許可トークンを含む認証応答を前記認証サーバ(304)から受信するステップ」とは,
“管理者のコンピュータが,許可トークンを含む認証応答を認証サーバ(304)から受信するステップ”である点で共通する。

5.引用発明における「機能ユーザが,前記デジタル署名されたトランザクション許可トークンを含む前記許可応答,及び,ジョブデータを含むジョブ要求を,前記機能プロバイダに送信する」ことと,
本願発明における「管理者のコンピュータが,前記認証応答を管理者に割り当てられた前記第1の秘密鍵と公開鍵の対の前記秘密鍵で署名して,前記認証応答を前記対象のコンピューティング装置(10)に送信するステップ」とは,
“管理者のコンピュータが,認証応答情報を対象のコンピューティング装置(10)に送信するステップ”である点で共通する。

6.以上,上記1.?5.において検討した事項から,本願発明と,引用発明との,一致点.及び,相違点は,以下のとおりである。

[一致点]
対象のコンピューティング装置(10)で実施される動作を許可する方法であって,
管理者のコンピュータが,前記対象のコンピューティング装置(10)での動作を実施するため,前記動作を許可する要求を生成するステップと,
前記管理者のコンピュータが,要求情報を認証サーバ(304)に送信するステップと,
前記管理者のコンピュータが,許可トークンを含む認証応答を前記認証サーバ(304)から受信するステップと,
前記管理者のコンピュータが,認証応答情報を前記対象のコンピューティング装置(10)に送信するステップと,
を含む方法。

[相違点1]
本願発明においては,「管理者のコンピュータが,前記要求を管理者に割り当てられた第1の秘密鍵と公開鍵の対の秘密鍵で署名するステップ」が存在するのに対して,
引用発明においては,「機能ユーザ」が,「要求」に「署名」する点について,特に言及されていない点。

[相違点2]
“要求情報”に関して,
本願発明においては,「要求」は,「管理者に割り当てられた第1の秘密鍵と公開鍵の対の秘密鍵で署名」されたものであるのに対して,
引用発明においては,「要求」に「署名」することについては,特に,言及されていない点。

[相違点3]
“管理者のコンピュータが,認証応答情報を前記対象のコンピューティング装置(10)に送信するステップ”に関して,
本願発明においては,「管理者のコンピュータが,前記認証応答を管理者に割り当てられた前記第1の秘密鍵と公開鍵の対の前記秘密鍵で署名して,前記認証応答を前記対象のコンピューティング装置(10)に送信する」ものであるのに対して,
引用発明においては,「許可応答」に対して「署名」する点について,特に言及されていない点。

[相違点4]
本願発明においては,「対象のコンピューティング装置(10)がモバイル通信装置である」のに対して,
引用発明においては,「機能プロバイダ」が,「モバイル通信装置」である点について,特に言及されていない点。

第7.相違点についての当審の判断
1.[相違点1]?[相違点3]について
上記Aに引用した記載にもあるとおり,「署名」自体は,当該技術分野において周知の技術事項である。
そして,上記Eに引用した,引用文献2の記載にもあるとおり,「要求」に署名をして送信することも,周知の技術事項である。
したがって,引用発明において,「機能ユーザ」から,「セキュリティアプリケーション」へ送信する「要求」に「署名」すること,及び,「機能ユーザ」から,「機能プロバイダ」へ送信する「許可応答」に「署名」することは,何れも,当業者が適宜なし得る事項である。
よって,[相違点1]?[相違点3]は,格別のものではない。

2.[相違点4]について
出力先として,「プリンタ装置」に代えて,「携帯端末」を採用することは,上記Gに引用した,周知技術文献の記載内容にもあるとおり,当業者が必要に応じて適宜選択し得る事項であるから,引用発明においても,「多機能デバイス30のような機能プロバイダ」に代えて,「携帯端末」を採用することは,当業者が適宜なし得る事項である。
よって,[相違点4]は,格別のものではない。

3.以上,上記1.,及び,2.において検討したとおりであるから,[相違点1]?[相違点4]は,いずれも格別のものではなく,そして,本願発明の構成によってもたらされる効果も,当業者であれば容易に予測できる程度のものであって,格別なものとは認められない。
なお,審判請求人は,令和2年10月7日付けの意見書において,本願発明と,引用発明との構成の違い等について主張しているが,本願発明と,引用発明との相違点については,上記において検討したとおりであるから,当該意見書における主張は採用できない。

第8.むすび
したがって,本願発明は,引用発明,引用文献2に記載の技術事項,及び,周知技術文献に記載の周知技術に基づいて当業者が容易に発明をすることができたものであるので,特許法29条2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2021-01-22 
結審通知日 2021-01-25 
審決日 2021-02-12 
出願番号 特願2016-541960(P2016-541960)
審決分類 P 1 8・ 121- WZ (H04L)
最終処分 不成立  
前審関与審査官 金沢 史明  
特許庁審判長 田中 秀人
特許庁審判官 月野 洋一郎
石井 茂和
発明の名称 対象のコンピューティング装置で実施される動作を認証する方法  
代理人 黒田 晋平  
代理人 村山 靖彦  
代理人 阿部 達彦  
代理人 崔 允辰  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ