【事件の表示】
　特願２０１０−５１４９６０「自動的なソフトウェア・プロビジョニング技法」拒絶査定不服審判事件〔平成２０年１２月３１日国際公開，ＷＯ２００９／００２７３９，平成２２年　９月３０日国内公表，特表２０１０−５３２０４９〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００８年６月１３日（パリ条約による優先権主張外国庁受理２００７年６月２７日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２１年１２月２２日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，平成２３年３月１６日付けで審査請求がなされ，平成２４年８月３日付けで審査官により拒絶理由が通知され，これに対して平成２４年１１月１２日付けで意見書が提出されると共に手続補正がなされたが，平成２５年２月４日付けで審査官により拒絶査定がなされ（発送；平成２５年２月８日），これに対して平成２５年６月１０日付けで審判請求がなされると共に手続補正がなされ，平成２５年８月９日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２５年１１月５日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされたが，回答書の提出がなかったものである。
　
第２．平成２５年６月１０日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成２５年６月１０日付け手続補正を却下する。
　
　［理由］
　
１．補正の内容
　平成２５年６月１０日付けの手続補正（以下，「本件手続補正」という）により，平成２４年１１月１２日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって，
　プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと，
　　　　　　ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み，
　前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと，
　　ここで，前記決定するステップは，
　　　　　　前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと，
　　　　　　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み，
　　　　　　　　　　　ここで，前記判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと
を具えたことを特徴とする方法。
　　【請求項２】
　タイプ識別子，ベンダ識別子，モデル識別子，ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項３】
　ファイル・メジャー・バージョン識別子，ファイル・マイナー・バージョン識別子，ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング（ｑｕｉｃｋ　ｆｉｘ　ｅｎｇｉｎｅｅｒｉｎｇ）識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項４】
　前記装置構成情報と共に含まれる，前記パケット・テレフォニー装置のタイプ識別子に対応する前記ソフトウェア更新パッケージをプロビジョニング・データベースから取り出すステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項５】
　前記プロビジョニング・サーバが前記ソフトウェア更新パッケージを公開サーバから受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項６】
　前記パケット・テレフォニー装置において，
　前記プロビジョニング要求を前記プロビジョニング・サーバの前記クライアント・プロビジョニング・モジュールに送信するステップと，
　前記パケット・テレフォニー装置の装置構成情報を前記クライアント・プロビジョニング・モジュールに送信するステップと，
　前記パケット・テレフォニー装置が前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから受け取るステップと，
　前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置にインストールするステップと
をさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項７】
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケットテレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に，前記ソフトウェア更新パッケージをテストおよび検証するステップをさらに具えたことを特徴とする請求項１ないし６のいずれかに記載の方法。
　　【請求項８】
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための装置であって，
　様々な種類のパケット・テレフォニー装置向けのソフトウェア更新パッケージを記憶するためのプロビジョニング・データベースと，
　前記プロビジョニング・データベースに通信可能に結合され，コンピュータ実行可能命令を有するクライアント・プロビジョニング・モジュールと，
　前記クライアント・プロビジョニング・モジュールに通信可能に結合され，前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置に送信する，ネットワーク・インタフェースと，
を具え，前記コンピュータ実行可能命令は，
　プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取ることと，
　前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取ることと，
　　　　　　ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み，
　前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定することと，
　　ここで，前記決定することは，
　　　　　　前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較することと，
　　　　　　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定することとを含み，
　　　　　　　　　　　ここで，前記判定することは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定することを含み，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信することと
を具えたことを特徴とする装置。
　　【請求項９】
　更新パッケージを公開サーバから受け取る更新エージェントと，前記更新パッケージをプロビジョニング・データベースにインストールしインストール結果を自動更新サービス・モジュールに通知するインストーラとを有する自動更新モジュールをさらに具えたことを特徴とする請求項８記載の装置。
　　【請求項１０】
　前記クライアント・プロビジョニング・モジュールは，
　更新パッケージのインストール結果の通知を受け取る更新リスナを有する自動更新サービス・モジュールと，更新ファイルを前記更新パッケージから抽出しプロビジョニング・データベースに格納する更新パッケージ・ハンドラとをさらに具えたことを特徴とする請求項８記載の装置。
　　【請求項１１】
　前記装置構成情報は，タイプ識別子，ベンダ識別子，モデル識別子，ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報をさらに有することを特徴とする請求項８記載の装置。
　　【請求項１２】
　前記装置構成情報は，ファイル・メジャー・バージョン識別子，ファイル・マイナー・バージョン識別子，ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報をさらに有することを特徴とする請求項８記載の装置。
　　【請求項１３】
　前記コンピュータ実行可能命令は，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケットテレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に，前記ソフトウェア更新パッケージをテストおよび検証することをさらに具えたことを特徴とする請求項８記載の装置。
　　【請求項１４】
　コンピュータにより，請求項１ないし７のいずれかに記載の方法を実行することが可能な命令を有するコンピュータプログラム。
　　【請求項１５】
　請求項１４記載のコンピュータプログラムを有するコンピュータ読取り可能な記録媒体。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって，
　プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと，
　　　ここで，該クライアント・プロビジョニング・モジュールは，更新リスナを有する自動更新サービスモジュールと，更新パッケージハンドラとを含み，
　前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと，
　　　　　　ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み，
　前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと，
　　ここで，前記決定するステップは，
　　　　　　前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと，
　　　　　　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み，
　　　　　　　　　　　ここで，前記判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと，
　前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと
を具え，
　　　前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，
　　　前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成することを特徴とする方法。
　　【請求項２】
　タイプ識別子，ベンダ識別子，モデル識別子，ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項３】
　ファイル・メジャー・バージョン識別子，ファイル・マイナー・バージョン識別子，ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング（ｑｕｉｃｋ　ｆｉｘ　ｅｎｇｉｎｅｅｒｉｎｇ）識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項４】
　前記装置構成情報と共に含まれる，前記パケット・テレフォニー装置のタイプ識別子に対応する前記ソフトウェア更新パッケージをプロビジョニング・データベースから取り出すステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項５】
　前記プロビジョニング・サーバが前記ソフトウェア更新パッケージを公開サーバから受け取るステップをさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項６】
　前記パケット・テレフォニー装置において，
　前記プロビジョニング要求を前記プロビジョニング・サーバの前記クライアント・プロビジョニング・モジュールに送信するステップと，
　前記パケット・テレフォニー装置の装置構成情報を前記クライアント・プロビジョニング・モジュールに送信するステップと，
　前記パケット・テレフォニー装置が前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから受け取るステップと，
　前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置にインストールするステップと
をさらに具えたことを特徴とする請求項１記載の方法。
　　【請求項７】
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケット・テレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に，前記ソフトウェア更新パッケージをテストおよび検証するステップをさらに具えたことを特徴とする請求項１ないし６のいずれかに記載の方法。
　　【請求項８】
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための装置であって，
　ブロセッサと，
　様々な種類のパケット・テレフォニー装置向けのソフトウェア更新パッケージを記憶するためのプロビジョニング・データベースと，
　前記プロビジョニング・データベースに通信可能に結合され，コンピュータ実行可能命令を有するクライアント・プロビジョニング・モジュールを格納したメモリと，
　　　　　　　　　ここで，該クライアント・プロビジョニング・モジュールは，更新リスナを有する自動更新サービスモジュールと，更新パッケージハンドラとを含み，
　前記クライアント・プロビジョニング・モジュールに通信可能に結合され，前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置に送信する，ネットワーク・インタフェースと，
を具え，前記ブロセッサによって実行される前記クライアント・プロビジョニング・モジュールは，
　プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取ることと，
　前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取ることと，
　　　　　　ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み，
　前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定することと，
　　ここで，前記決定することは，
　　　　　　前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較することと，
　　　　　　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定することとを含み，
　　　　　　　　　　　ここで，前記判定することは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定することを含み，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信することと，
前記クライアント・プロビジョニング・モジュールの更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取ることと，
　前記クライアント・プロビジョニング・モジュールの更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納することと
を具え，
　　　前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，
　　　前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成することを特徴とする装置。
　　【請求項９】
　前記ソフトウェア更新パッケージを公開サーバから受け取る更新エージェントと，前記ソフトウェア更新パッケージをプロビジョニング・データベースにインストールしインストール結果を自動更新サービス・モジュールに通知するインストーラとを有する自動更新モジュールをさらに具えたことを特徴とする請求項８記載の装置。
　　【請求項１０】
　前記装置構成情報は，タイプ識別子，ベンダ識別子，モデル識別子，ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報をさらに有することを特徴とする請求項８記載の装置。
　　【請求項１１】
　前記装置構成情報は，ファイル・メジャー・バージョン識別子，ファイル・マイナー・バージョン識別子，ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報をさらに有することを特徴とする請求項８記載の装置。
　　【請求項１２】
　前記コンピュータ実行可能命令は，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケット・テレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に，前記ソフトウェア更新パッケージをテストおよび検証することをさらに具えたことを特徴とする請求項８記載の装置。
　　【請求項１３】
　コンピュータにより，請求項１ないし７のいずれかに記載の方法を実行することが可能な命令を有するコンピュータプログラム。
　　【請求項１４】
　請求項１３記載のコンピュータプログラムを有するコンピュータ読取り可能な記憶媒体。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
（１）新規事項
　本件手続補正によって，補正前の請求項１に加えられた，
「ここで，該クライアント・プロビジョニング・モジュールは，更新リスナを有する自動更新サービスモジュールと，更新パッケージハンドラとを含み」，
　という記載事項は，平成２１年１２月２２日付けで提出された，特許法第１８４条の４第１項の規定による明細書，請求の範囲の日本語による翻訳文，及び，国際出願の願書に添付された図面（以下，これを「当初明細書等」という）の段落【００２０】に，
「プロビジョニング・モジュール１２２はさらに，クライアント・プロビジョニング・モジュール２２２，自動更新サービス・モジュール２２４，および更新パッケージ・ハンドラ２２８を備えることができる。自動更新サービス・モジュール２２４はさらに，更新リスナ２２６を備えることができる」，
　という記載が存在することから，当初明細書等の記載の範囲内であることは明らかである。
　同じく，補正前の請求項１に加えられた，
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと」，
　及び，
「前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，
　　　前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成する」，
　という記載事項は，当初明細書等に，
「【００２９】
　様々な実施形態では、自動更新サービス・モジュール２２４と更新パッケージ・ハンドら２２８を、自動更新モジュール２１０とプロビジョニング・データベース１３０に通信可能に結合することができる。自動更新サービス・モジュール２２４を、配布局（例えば、公開サーバ１１０、２０６）とプロビジョニング・サーバ１２０の間の更新動作を管理するように構成することができる。自動更新サービス・モジュール２２４は更新リスナ２２６を備えることができる。更新リスナ２２６は、更新パッケージ２３０のような更新パッケージのインストール結果の通知を自動更新モジュール２１０のインストーラ２１４から受け取ることができる。更新リスナ２２６は次に新しく到着した更新パッケージ２３０とそのプロビジョニング・データベース１３０内の位置を更新パッケージ・ハンドラ２２８に通知することができる。更新パッケージ・ハンドラ２２８を、更新パッケージ２３０から更新ファイル１３２−１−ｎを抽出するように構成することができ、更新パッケージ・ハンドラ２２８は更新ファイル１３２−１−ｎをプロビジョニング・データベース１３０に記憶する。更新パッケージ・ハンドラ２２８は、通信装置１４０−１〜ｍの様々なサポートされる装置タイプに従って、プロビジョニング・データベース１３０内で更新ファイル１３２−１−ｎを編成することができる。」，
　と記載されていることから，当初明細書等の記載の範囲内のものであることは明らかである。このことは，補正前の請求項８に加えられた記載内容についても同様である。
　そして，補正前の上記指摘の請求項以外の請求項に加えられた記載事項は，何れも，当初明細書等の記載の範囲内のものである。
　よって，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものである。
　
（２）目的要件
ア．目的要件についての当審の判断
　次に，本件手続補正が，特許法第１８４条の１２第２項により読み替える同法第１７条の２第５項の規定を満たすものであるか否か，即ち，本件手続補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。
　
　上記「（１）新規事項」において検討した，本件手続補正によって，補正前の請求項１に加えられた記載事項に関して，補正前の請求項１に係る発明は，方法の発明であって，補正前の請求項１を引用する請求項は，補正前の請求項２〜請求項７である。
　そして，補正前の請求項２〜請求項７に記載された内容には，本件手続補正によって，補正前の請求項１に加えられた事項は存在していないので，補正後の請求項１が，補正前の請求項１を削除し，補正前の請求項１を引用する上記指摘の何れかの補正前の請求項の記載内容を加えて新たな補正後の請求項１とした，請求項の削除を目的としたものではないことは明らかである。
　また，原審の平成２４年８月３日付けの拒絶理由（以下，これを「原審拒絶理由」という）において不明であると指摘された事項，及び，原審の平成２５年２月４日付けの拒絶査定（以下，これを「原審の拒絶査定」）の備考において，依然として不明であると指摘された事項を明りょうにすることを目的とした補正事項とも認められず，誤記の訂正でないことも明らかである。
　そこで，本件手続補正が，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る）（以下，これを「限定的減縮」という）に該当するかを，以下に検討する。
　
　上記「（１）新規事項」において検討した，本件手続補正によって，補正前の請求項１に加えられた記載事項のうち，
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと」，
　及び，
「前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，
　前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成する」，
　は，補正前の請求項１に係る発明の構成に，
“更新リスナによって，インストール結果の通知を受け取るステップ”，
“更新パッケージ・ハンドラによって，更新ファイルをデータベースに格納するステップ”，
　という，新たな２つの“ステップ”と，「更新リスナ」と，「更新パッケージ・ハンドラ」との間で行われる処理を付加するものである。
　ここで，上述において指摘した，「更新リスナ」と，「更新パッケージ・ハンドラ」との間で行われる処理の内，特に，
“更新パッケージ・ハンドラによって，更新ファイルをデータベースに格納するステップ”
　という処理は，
“プロビジョニング・サーバのデータベースに，パケット・テレフォニー装置のソフトウェア更新のための新たなソフトウェアを格納する”
　というものであるから，補正前の請求項１に係る発明における，
“プロビジョニング・サーバによって，パケット・テレフォニー装置のソフトウェア更新を行う”
　という処理に対して，新たな処理内容を付加するものであることは，明らかである。
　したがって，補正前の請求項１に係る発明において，「更新リスナ」，及び，「更新パッケージ・ハンドラ」に関する処理内容は，補正前の請求項１に係る発明に新たに加えられた機能を表現するものであって，補正前の請求項１係る発明における発明特定事項の何れかを，限定的に減縮するものとは認められない。
　以上検討したとおり，本件手続補正による，補正前の請求項１に対する補正内容は，特許法第１７条の２第５項に既定された目的要件の何れにも該当しない。
　
イ．目的要件むすび
　したがって，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第５項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
（３）独立特許要件
　上記において検討したとおり，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第５項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，
　仮に本件手続補正が，目的要件を満たすものであるとして，本件手続補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定を満たすものであるか否か，即ち，補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か，検討する。
　
ア．補正後の請求項１に係る発明
　補正後の請求項１に係る発明（以下，これを「本件補正発明」という）は，上記「第２．平成２５年６月１０日付けの手続補正の却下の決定」の「１．補正の内容」において，補正後の請求項１として引用した記載によって特定されるものである。
　
イ．引用刊行物に記載の事項
（ア）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，特開２００５−０２６９９３号公報（２００５年１月２７日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【００８０】
（実施の形態２）
図１０は，本発明の実施の形態２に係るＩＰ電話システム１０００の全体構成を示す図である。図１０に示すＩＰ電話システム１０００は，ＩＰ電話装置１００１−１〜１００１−Ｎと，サーバユニット１００２と，インターネット網１００３と，から構成される。
【００８１】
ＩＰ電話装置１００１−１〜１００１−Ｎと，サーバユニット１００２とは，インターネット網１００３を介して接続されている。なお，ＩＰ電話装置１００１−１〜１００１−Ｎ及びサーバユニット１００２は，図１０に示すようにそれぞれ異なるＬＡＮに設置されていてもよく，また，どのような組み合わせで同一のＬＡＮ内に設置されていてもよい。」
　
Ｂ．「【００８３】
図１０に示すＩＰ電話システム１０００は，サーバユニット１００２がＩＰ電話装置１００１のソフトウェアデータの書き換えの要否を判断し，必要と判定した時には最適ソフトウェアデータをＩＰ電話装置１００１へ送信するため，自動的なソフトウェアデータの書き換えを可能とする。また，ＩＰ電話装置１００１は，音声通信のほか映像通信も可能である。」
　
Ｃ．「【００８７】
受信部１１０２は，サーバユニット１００２が送信する登録応答メッセージ，又は，ＩＰ電話装置１００１とサーバユニット１００２との間のセッションを張るための登録応答メッセージ及び最適ソフトウェアデータを受信して，書き換え制御部１１０３に与える。ここで，最適ソフトウェアデータとは，ＩＰ電話装置において，例えば，その使用時期において最適な機能を付与するソフトウェアデータを意味する。また，最適ソフトウェア番号とは，最適のソフトウェアデータを識別するための番号である。
【００８８】
書き換え制御部１１０３は，受信部１１０２からセッションを張るための登録応答メッセージ中に含まれる書き換え要否情報（ここでは，書き換えを必要とする旨を示す。）及び最適ソフトウェアデータを受け取ると，記憶部１１０４に記憶されているソフトウェアデータを最適ソフトウェアデータに書き換えると共に加入者管理情報テーブル（図８（１））で管理している現在のソフトウェア番号も最適ソフトウェア番号に書き換える。
【００８９】
図１２は，サーバユニット１００２の構成を示すブロック図である。図１２のサーバユニット１００２は，受信部１２０１と，判定部１２０２と，記憶部１２０３と，制御部１２０４と，送信部１２０５と，から構成される。
【００９０】
受信部１２０１は，ＩＰ電話装置１００１から登録要求メッセージを受信する。記憶部１２０３は，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している。なお，この実施の形態２における端末管理情報テーブルは，図８（２）に示す本発明の実施の形態１の端末管理情報テーブルにおけるソフト管理サーバアドレスをなくしたものである。この実施の形態２における加入者管理情報テーブルは，図８（１）に示す実施の形態１の加入者管理情報テーブルと同様のものである。
【００９１】
判定部１２０２は，受信部１２０１から識別情報及びソフトウェア番号を受け取る。判定部１２０２は，その識別情報をキーとして，加入者管理情報テーブルのソフトウェア更新要求の欄の設定がソフトウェアの書き換えを行う設定になっているかを判定する。判定の結果，書き換えを行う設定の時には，判定部１２０２は，その識別情報をキーとして，記憶部１２０３の端末管理情報テーブルから最適ソフトウェア番号を読み取って，ソフトウェア番号と最適ソフトウェア番号との比較を行う。比較の結果，ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部１２０２は，識別情報と書き換え要否情報（ここでは，書き換えが必要であることを示す内容を持っている。）と最適ソフトウェア番号とを制御部１２０４に与える。
【００９２】
制御部１２０４は，判定部１２０２からその書き換えが必要である旨の書き換え要否情報を受け取った時には，記憶部１２０３から識別情報をキーとして，加入者管理情報テーブルにおけるＩＰ電話装置１０１のＩＰアドレス及び端末管理情報テーブルにおける最適ソフトウェアデータを読み取る。また，制御部１２０４は，サーバユニット１００２とＩＰ電話装置１００１との間のセッションを張るための登録応答メッセージを生成し，送信部１２０５に与える。
【００９３】
送信部１２０５は，識別情報及びＩＰアドレスから特定されるＩＰ電話装置１００１へそのセッションを張るための登録応答メッセージを送信する。これにより，サーバユニット１００２とＩＰ電話装置１００１との間のセッションが張られることになる。そして，制御部１２０４は，最適ソフトウェアデータ及び書き換え要否情報（ここでは，書き換えが必要であることを示す内容を持っている。）を送信部１２０５に与え，送信部１２０５は識別情報及びＩＰアドレスから特定されるＩＰ電話装置１００１へ送信する。」
　
Ｄ．「【００９９】
次に，サーバユニット１００２が行う判定処理について，図１３を参照して説明する。
【０１００】
サーバユニット１００２の受信部１２０１は，ＩＰ電話装置１００１から送信されるＩＰ電話装置１００１各々に固有の識別情報及び現在搭載しているソフトウェアデータのソフトウェア番号を含む登録要求メッセージを受信する（ＳＴ１３０１）。判定部１２０２は，受信部１２０１から識別情報及びソフトウェア番号を受け取る（ＳＴ１３０２）。
【０１０１】
判定部１２０２は，その識別情報をキーとして，記憶部１２０３の加入者管理情報テーブルに記憶されているソフトウェア更新要求の設定が「する」となっているか判定する（ＳＴ１３０３）。ソフトウェア更新要求の設定が「する」と設定されている時には，判定部１２０２は，その識別情報をキーとして，記憶部１２０３の端末管理情報テーブルから最適ソフトウェア番号を読み取る（ＳＴ１３０４）。ＳＴ１３０３において，ソフトウェア更新要求の設定が「しない」と設定されている時には，ＳＴ１３０７に移行する。
【０１０２】
判定部１２０２は，ソフトウェア番号と最適ソフトウェア番号との比較を行う（ＳＴ１３０５）。比較の結果，ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部１２０２は，ソフトウェアの書き換えが必要だと判断し，識別情報と書き換え要否情報（ここでは，書き換えが必要であることを示す内容を持っている。）と最適ソフトウェア番号とを制御部１２０４に与える。
【０１０３】
制御部１２０４は，判定部１２０２から書き換えが必要である旨の書き換え要否情報を受け取った時には，一緒に受け取る識別情報及び最適ソフトウェア番号をキーとして，ＩＰ電話装置１０１のＩＰアドレス及び最適ソフトウェアデータを読み取る。制御部１２０４は，サーバユニット１００２とＩＰ電話装置１００１との間のセッションを張るための登録応答メッセージを生成する（ＳＴ１３０６）。
【０１０４】
サーバユニット１００２の制御部１２０４は，判定部１２０２から書き換えが不要である旨の書き換え要否情報を受け取った時には，一緒に受け取る識別情報をキーとして，記憶部１２０３の加入者管理情報テーブルからＩＰ電話装置１００１のＩＰアドレスを読み取る。また，制御部１２０４は，書き換え要否情報（書き換えが不要である旨を示す。）を中に含む登録応答メッセージを生成する（ＳＴ１３０７）。
【０１０５】
以上のように，本発明の実施の形態２によれば，サーバユニットがＩＰ電話装置のソフトウェアデータの書き換えの要否を判定し，必要と判定した時には最適ソフトウェアデータをＩＰ電話装置へ送信するため，自動的なソフトウェアデータが書き換えが可能となるので，ＩＰ電話装置に最適のソフトウェアがインストールされるまでの期間を短くし，ＩＰ電話システムを利用できない期間を非常に短縮することができるＩＰ電話システムを提供することができる。また，実施の形態２によれば，実施の形態１に係るＩＰ電話システムにおける２つのサーバ装置を１つにまとめたため，ＩＰ電話システム構築の低コスト化を図ることができる。」
　
（イ）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，特開２００７−１２８５２１号公報（２００７年５月２４日公開，以下，これを「引用刊行物２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｅ．「【００４５】
  次に，ステップ４１８で，依存性チェッカ４１０が，有資格ノードのリストをノード・マネージャ４０２に返す。このリストに，プロビジョニング待ち時間，ライセンス・コスト，ディスク使用量などのことに関する計画されたコストが含まれる。表２に，上で与えた例のコスト・リストを示す。」
　
Ｆ．「【００４９】
  ステップ４３０で，各ターゲットにされたノードが，インストールの結果を別々に報告する。最後に，ステップ４３２で，ノード・マネージャ４０２が，結果についてノード・キャッシュ４１４に通知する。さらに，このプロセス全体を通じて，提供フレームワーク４００の状態が，ノード・マネージャ４０２にパス・スルーされ，ノード・マネージャ４０２は，状況情報を用いてフロント・エンド４０６を更新する。」
　
（ウ）本願の第１国出願前に既に公知である，特開平１１−２７２４７１号公報（１９９９年１０月８日公開，以下，これを「周知文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｇ．「【００１７】すなわち，配信処理部１ａは，格納処理部１ｂにより，配信対象のソフトウェアを，各受信側コンピュータ２〜４のそれぞれに共通な共通モジュール部分１３（図中，「ＡＰ」と記載）と，それぞれ異なる差分モジュール部分１４，１５（図中，「Ａ」，「Ｃ」と記載）とに分けてハードディスク装置９に格納する。また，情報登録処理部１ｃにより，次の図３に示すように，各受信側コンピュータ２〜４に配信済みのソフトウェアの識別情報と更新情報および差分モジュール部分１４，１５の識別情報をハードディスク装置９等に登録する。」
　
Ｈ．「【００３１】さらに，送信元管理者が，バージョンアップしたソフトウェアをカスタマイズして受信用コンピュータ２への差分モジュール部分１４（「Ａ」）と受信用コンピュータ４への差分モジュール部分１５（「Ｃ」）の格納を指示すると（ステップ１０４），送信側コンピュータ１は，配信先情報テーブル３１の差分情報の項目に，マシン別のファイル名（差分モジュール部分の識別情報）を書込み，バージョンアップしたソフトウェアを共通モジュール部分１３と差分モジュール部分１４，１５に分けてハードディスク装置９に格納する（ステップ１０５）。
・・・・・（中略）・・・・・
【００３３】このようにして特定した相手マシンに対応して，共通モジュール部分１３（「ＡＰ」）とマシン別の差分モジュール部分１４（「Ａ」），１５（「Ｃ」）とを組み合わせて，相手マシン用のソフトウェアを作成し（ステップ１０９），バージョンアップすべき相手マシンに配信する（ステップ１１０）。」
　
（エ）本願の第１国出願前に既に公知である，国際公開第２００４／１１４０４５号（２００４年１２月２９日公開，以下，これを「周知文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｉ．「
Exemplary Exploit Detector
　FIGURE 5 illustrates components of a firewall operable to provide exploit protection, according to one embodiment of the invention. The components of the firewall 500 include message listener 505, exploit detector 510, and output component 545. Exploit detector 510 includes message queue 515, decompression component 525, message tracker 527, scanner component 530, and exploit handler 540. Also shown is message transport agent 555.
　Firewall 500 may receive many types of messages sent between devices coupled to network 450 and outside network 405 of FIGURE 4. Some messages may relate to WWW traffic or data transferred between two computers engaged in a communication while other messages may relate to email. Message listener 505 listens for a message and, upon receipt of an appropriate message, such as an email or file, sends the message to exploit detector 510 to scan for exploits.
　 When processing email messages, exploit detector 510 provides exploit protection, in part, by scanning and verifying the fields of an email message. An email message typically includes a header (which may include certain fields), a body (which typically contains the text of an email), and one or more optional attachments. Exploit detector 510 may examine the lengths of the fields of an email message to determine whether they are longer than they should be. Being longer than they should be may be defined by standards, mail server specifications, or　 selected by a firewall .
 administrator. If an email message includes any fields that are longer than they should be, the message may be sent to exploit handler 540 as described in more detail below.」（１７頁２２行〜１８頁１３行）
（【００５３】
  “好適なエクスプロイト・ディテクター”
  図５は，エクスプロイトプロテクションを提供するために操作可能なファイアーウォールの構成要素を，本発明の一つの実施形態に従って図示する。ファイアーウォール５００の構成要素は，メッセージ・リスナー５０５，エクスプロイト・ディテクター５１０，および出力構成要素５４５を含む。エクスプロイト・ディテクター５１０は，メッセージ待ち行列５１５，解凍構成要素５２５，メッセージ・トラッカー５２７，スキャナ構成要素５３０，およびエクスプロイト・ハンドラー５４０を含む。メッセージ・トランスポート・エージェント５５５もまた示される。
【００５４】
  ファイアーウォール５００は，図４のネットワーク４５０，および外部ネットワーク４０５に接続されたデバイス間で，送信された多くのメッセージタイプを受信するかもしれない。いくらかのメッセージは，通信に参加している二つのコンピュータ間で転送されるＷＷＷトラヒック，またはデータに関連することが考えられる。一方では，その他のメッセージは，電子メールに関連し得る。メッセージ・リスナー５０５は，メッセージをリッスンし，電子メール，またはファイルのような適切なメッセージの受信に基づいて，エクスプロイトをスキャンするためのエクスプロイト・ディテクター５１０へ，メッセージを送信する。
【００５５】
  電子メールメッセージを処理する場合，エクスプロイト・ディテクター５１０は，いくぶん，電子メールメッセージのフィールドをスキャンし，検査することで，エクスプロイトプロテクションを提供する。電子メールメッセージは，一般的には，ヘッダ（一定のフィールドを含むかもしれない），ボディ（一般的には電子メールのテキストを含む），および一つ以上の任意の添付ファイルを含む。エクスプロイト・ディテクター５１０は，電子メールのフィールド長を調査することで，それらがあるべき長さよりも，長いか否かを決定する。「あるべき長さより長い」ことは，規格や，メールサーバー仕様書によって決定されるか，または，ファイアーウォール管理者によって選択される。もし，電子メールが，あるべき長さより長いフィールドを含む場合，そのメッセージは，以下に詳細に記述されるように，エクスプロイト・ハンドラー５４０へ送信されることが考えられる。対応する，日本語公報である，特表２００７-５２８０４０号より引用）
　
（オ）本願の第１国出願前に既に公知である，特開２００４−３０３２４８号公報（２００４年１０月２８日公開，以下，これを「周知文献３」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｊ．「【００９０】
  第７のタイプのデータ構造は，プラグイン・マネージャ３３８の管理ハンドラを指定するＱｕｅｒｙＣｏｎｆｉｇおよびＳｅｔＣｏｎｆｉｇを含む。
【００９１】
  その通知リスナーの役割において，プラグイン・マネージャ３３８は，プラグインによって生成される更新信号を監視する。通知の取り扱いは，その通知と関連するプラグインのタイプに応じて異なる。」
　
（カ）本願の第１国出願前に既に公知である，特開２００３−２２８４８６号公報（２００３年８月１５日公開，以下，これを「周知文献４」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｋ．「【００３５】具体的には，図３に示すように，ソフトウェアＡ１のバージョンアップ版のソフトウェアＡ２がリリースされた場合に，システム管理者が，ＤＢ部１２０のＳＷ情報格納領域１２１に格納されているソフトウェアＡ１をソフトウェアＡ２に更新する。このとき，ソフトウェアＡ２の更新情報（ソフトウェアＡ１から更新（変更）された一部のプログラムのモジュールなどの情報）がＳＷ情報格納領域１２１に登録されるとともに，そのソフトウェアＡ２の製品名，バージョン情報，更新プログラムなどもＳＷ情報格納領域１２１にソフトウェアＡ２に対応付けて登録（格納）される。
【００３６】また，図４に示すように，システム管理者は，ＤＢ部１２０のＳＷ情報格納領域１２１にソフトウェアＮを新規に追加（登録）する。このとき，ソフトウェアＮの本体の情報がＳＷ情報格納領域１２１に登録されるとともに，そのソフトウェアＮの製品名，バージョン情報，インストールプログラムなどもＳＷ情報格納領域１２１にソフトウェアＮと対応付けて登録される。
【００３７】さらに，図５に示すように，システム管理者は，ＤＢ部１２０のＳＷ情報格納領域１２１からソフトウェアＤを削除する。このとき，ソフトウェアＤの製品名，バージョン情報，削除プログラムなどがＳＷ情報格納領域１２１にソフトウェアＮに対応付けて登録される。」
　
ウ．引用刊行物１に記載の発明
（ア）上記Ａの「ＩＰ電話システム１０００は，ＩＰ電話装置１００１−１〜１００１−Ｎと，サーバユニット１００２と，インターネット網１００３と，から構成される」という記載，同じく，上記Ａの「ＩＰ電話装置１００１−１〜１００１−Ｎと，サーバユニット１００２とは，インターネット網１００３を介して接続されている」という記載，及び，上記Ｂの「最適ソフトウェアデータをＩＰ電話装置１００１へ送信する」という記載から，引用刊行物１には，
“インターネット網を介して接続されたＩＰ電話装置とサーバユニットによって構成されるＩＰ電話システムにおいて，ＩＰ電話装置に，最適ソフトウェアデータを送信するための方法”が記載されていることが読み取れる。
　
（イ）上記Ｃの「サーバユニット１００２は，受信部１２０１と，判定部１２０２と，記憶部１２０３と，制御部１２０４と，送信部１２０５と，から構成される」という記載，同じく，上記Ｃの「受信部１２０１は，ＩＰ電話装置１００１から登録要求メッセージを受信する」という記載，及び，同じく，上記Ｃの「記憶部１２０３は，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している」という記載から，引用刊行物１においては，
“サーバユニットは，受信部と，判定部と，記憶部と，制御部と，送信部と，から構成され，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し，前記記憶部が，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している”ことが読み取れる。
　
（ウ）上記Ｄの「サーバユニット１００２の受信部１２０１は，ＩＰ電話装置１００１から送信されるＩＰ電話装置１００１各々に固有の識別情報及び現在搭載しているソフトウェアデータのソフトウェア番号を含む登録要求メッセージを受信する」という記載と，上記（ア）において検討した事項から，引用刊行物１においては，
“サーバユニットを構成する受信部が，ＩＰ電話装置から，ＩＰ電話装置の各々に固有の識別情報，および，現在搭載しているソフトウェアデータのソフトウェア番号を受信する”ことが読み取れる。
　
（エ）上記Ｃの「判定部１２０２は，受信部１２０１から識別情報及びソフトウェア番号を受け取る。判定部１２０２は，その識別情報をキーとして，加入者管理情報テーブルのソフトウェア更新要求の欄の設定がソフトウェアの書き換えを行う設定になっているかを判定する」，及び，上記Ｄの「判定部１２０２は，の識別情報をキーとして，記憶部１２０３の端末管理情報テーブルから最適ソフトウェア番号を読み取って，ソフトウェア番号と最適ソフトウェア番号との比較を行う（ＳＴ１３０５）。比較の結果，ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部１２０２は，ソフトウェアの書き換えが必要だと判断し」という記載から，引用刊行物１においては，
“判定部が，受信部から識別情報及びソフトウェア番号を受け取り，ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い，比較の結果，ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部は，ソフトウェアの書き換えが必要だと判断する”ものであることが読み取れる。
　
（オ）上記Ｃの「制御部１２０４は，判定部１２０２からその書き換えが必要である旨の書き換え要否情報を受け取った時には，記憶部１２０３から識別情報をキーとして，加入者管理情報テーブルにおけるＩＰ電話装置１０１のＩＰアドレス及び端末管理情報テーブルにおける最適ソフトウェアデータを読み取る」という記載，及び，上記Ｄの「制御部１２０４は，判定部１２０２から書き換えが必要である旨の書き換え要否情報を受け取った時には，一緒に受け取る識別情報及び最適ソフトウェア番号をキーとして，ＩＰ電話装置１０１のＩＰアドレス及び最適ソフトウェアデータを読み取る」という記載から，引用刊行物１においては，
“更新が必要である場合には，制御部が，識別情報及び最適ソフトウェア番号を用いて，ＩＰ電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取る”ものであることが読み取れる。
　
（カ）上記Ｃの「制御部１２０４は，最適ソフトウェアデータ及び書き換え要否情報（ここでは，書き換えが必要であることを示す内容を持っている。）を送信部１２０５に与え，送信部１２０５は識別情報及びＩＰアドレスから特定されるＩＰ電話装置１００１へ送信する」という記載，及び，上記Ｄの「ＩＰ電話装置に最適のソフトウェアがインストールされるまでの期間」という記載と，上記（イ）において引用した，上記Ｃの記載内容から，引用刊行物１においては，
“ＩＰ電話装置にインストールする最適ソフトウェアデータが，サーバユニットを構成する送信部から，前記ＩＰ電話装置に送信される”ことが読み取れる。
　
　以上，（ア）〜（カ）において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　インターネット網を介して接続されたＩＰ電話装置とサーバユニットによって構成されるＩＰ電話システムにおいて，ＩＰ電話装置に，最適ソフトウェアデータを送信するための方法であって，
　サーバユニットは，受信部と，判定部と，記憶部と，制御部と，送信部と，から構成され，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し，前記記憶部が，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶し，
　前記受信部が，ＩＰ電話装置から，ＩＰ電話装置の各々に固有の識別情報，および，現在搭載しているソフトウェアデータのソフトウェア番号を受信し，
　前記判定部が，前記受信部から前記識別情報及びソフトウェア番号を受け取り，前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い，比較の結果，前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部は，ソフトウェアの書き換えが必要だと判断し，
　更新が必要である場合には，前記制御部が，前記識別情報及び前記最適ソフトウェア番号を用いて，前記ＩＰ電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取り，
　ＩＰ電話装置にインストールする最適ソフトウェアデータが，サーバユニットを構成する送信部から，前記ＩＰ電話装置に送信される，方法。
　
エ．本件補正発明と引用発明との対比
（ア）引用発明において，「最適ソフトウェアデータ」への更新が，自動で行われていることは，明らかであり，引用発明において，「ＩＰ電話装置」の「搭載しているソフトウェアデータ」を最適化する処理が，プロビジョニングと言い得るものであって，
　引用発明における「ＩＰ電話装置」，及び，「サーバユニット」が，本願発明における「パケットテレフォニー装置」，及び，「プロビジョニング・サーバ」に相当し，
　引用発明における「ＩＰ電話装置」は，上記Ｄの「ＩＰ電話装置１００１各々に固有の識別情報」という記載から，“複数台の種類の異なる「ＩＰ電話装置」を含む”態様を有すると言い得るものであるから，
　引用発明における「インターネット網を介して接続されたＩＰ電話とサーバユニットによって構成されるＩＰ電話システムにおいて，ＩＰ電話装置に，最適ソフトウェアデータを送信するための方法」が，
　本件補正発明における「様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法」に相当する。
　
（イ）引用発明における「登録要求メッセージ」は，当該「メッセージ」によって，「ＩＰ電話装置」に搭載されている「ソフトウェアデータ」の更新の有無の判断を行うことになるので，本件補正発明における「プロビジョニング要求」に相当し，
　引用発明における「受信部」は，前記「登録要求メッセージ」を受信するものであるから，引用発明における「受信部」と，本件補正発明における「クライアント・プロビジョニング・モジュール」とは，“プロビジョニング要求を受信する受信手段”である点で共通しているので，
　引用発明における「サーバユニットは，受信部と，判定部と，記憶部と，制御部と，送信部と，から構成され，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し」と，
　本件補正発明における「プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップ」とは，
“プロビジョニング・サーバの受信手段が，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップ”である点で共通する。
　
（ウ）引用発明において，「ＩＰ電話装置の各々に固有の識別情報」は，“装置の種別”示す情報とし得ることは，明らかであるから，引用発明における「ＩＰ電話装置の各々に固有の識別情報」，及び，「現在搭載しているソフトウェアデータのソフトウェア番号」が，本願発明における「様々な種類のパケット・テレフォニー装置のタイプ識別情報」，及び，「コンポーネント・バージョン情報」に相当するので，
　引用発明における「前記受信部が，ＩＰ電話装置から，ＩＰ電話装置の各々に固有の識別情報，および，現在搭載しているソフトウェアデータのソフトウェア番号を受信し」と，
　本件補正発明における「前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと，ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み」とは，
“受信手段が，様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップ”である点で共通する。
　
（エ）引用発明において，「端末管理情報テーブル」は，「最適ソフトウェア番号」を記憶するものであって，前記「最適ソフトウェア番号」は，「ソフトウェアデータ」の更新の有無を判定するために用いるものであって，引用発明においては，「記憶部が，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶」するものであるから，
　引用発明における「端末管理情報テーブル」，及び，「最適ソフトウェアデータ」を記憶する「記憶部」が，本件補正発明における「プロビジョニング・データベース」に相当し，
　引用発明における「最適ソフトウェア番号」と，本件補正発明における「プロビジョニング・データベースに記憶した対応するフィールド値」とは，“判定情報データベースに記憶した対応するフィールド値”である点で共通し，
　引用発明における「現在搭載しているソフトウェアデータのソフトウェア番号」は，引用発明においても「ＩＰ電話装置」が，複数の「ソフトウェア」を有する態様を含むことは明らかであるから，本件補正発明における「コンポーネント・バージョン情報の様々な識別フィールド値」に相当し，
　引用発明において，「ソフトウェアの書き換えが必要と判断」することは，“受信部が受信した，登録要求メッセージに応じて，ＩＰ電話装置の各々に固有の識別情報，および，現在搭載しているソフトウェアデータのソフトウェア番号に基づいて行われる”ものであるから，このことと，本件補正発明における「前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップ」とは，
“プロビジョニング・サーバが，プロビジョニング要求に応答して，様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を，様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップ”である点で共通する。
　
（オ）引用発明における「判定部が，前記受信部から前記識別情報及びソフトウェア番号を受け取り，前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行」うことと，
　本件補正発明における「前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップ」とは，
“プロビジョニング・サーバの判定手段が，コンポーネント・バージョン情報の様々な識別フィールド値を，判定情報データベースに記憶した対応するフィールド値と比較するステップ”で共通し，
引用発明において，「記憶部」の記憶する「最適ソフトウェアデータ」は，「ＩＰ電話装置」の「現在搭載しているソフトウェアデータ」を更新するために用いられるものであるから，本件補正発明における「様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージ」に相当するので，
　引用発明における「記憶部が，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶」することは，
　本件補正発明における「プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含」むこと相当する。
　
（カ）引用発明における「比較の結果，前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部１２０２は，ソフトウェアの書き換えが必要だと判断」すること，
　本件補正発明における「前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップ」とは，
“比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，プロビジョニング・サーバの判定手段が，様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップ”である点で共通する。
　
（キ）引用発明においても，「ソフトウェア番号」を比較することで，“どの最適ソフトウェアデータが必要かの判断”を行っていることは明らかであるから，このことが，
　本件補正発明における「判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップ」に相当する。
　
（ク）引用発明においても，「最適ソフトウェアデータ」は，「サーバユニット」から，「ＩＰ電話装置」に送信されるものであり，前記「ＩＰ電話装置」に「インストール」されるものであるから，
　引用発明における「ＩＰ電話装置にインストールする最適ソフトウェアデータが，サーバユニットを構成する送信部から，前記ＩＰ電話装置に送信される」ことと，
　本件補正発明における「前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップ」こととは，
“ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用にパケット・テレフォニー装置に送信するステップ”である点で共通する。
　
　以上（ア）〜（ク）において検討した事項から，本件補正発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって，
　プロビジョニング・サーバの受信手段が，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと，
　前記受信手段が，様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップと，
　前記プロビジョニング・サーバが，前記プロビジョニング要求に応答して，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を，前記様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップと，
　ここで前記決定するステップは，
　前記プロビジョニング・サーバの判定手段が，コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと，
　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，プロビジョニング・サーバの判定手段が，前記様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップとを含み，
　ここで前記判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み，
　前記ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用に前記パケット・テレフォニー装置に送信するステップと
　を含む方法。
　
［相違点１］
“プロビジョニング・サーバの受信手段”に関して，
　本件補正発明においては，「プロビジョニング・サーバのクライアント・プロビジョニング・モジュール」であるのに対して，
　引用発明においては，「サーバユニット」の「受信部」である点。
　
［相違点２］
　本件補正発明においては，「クライアント・プロビジョニング・モジュールは，更新リスナを有する自動更新サービスモジュールと，更新パッケージハンドラとを含」むものであるのに対して，
　引用発明には，「更新リスナ」，「更新パッケージ・ハンドラ」についての言及がない点。
　
［相違点３］
“プロビジョニング・サーバが・・・提供するかを決定するステップ”に関して，
　本件補正発明においては，「クライアント・プロビジョニング・モジュール」が行っているのに対して，
　引用発明においては，「サーバユニット」の「判定部」が行っている点。
　
［相違点４］
“プロビジョニング・サーバの判定手段”に関して，
　本件補正発明においては，「クライアント・プロビジョニング・モジュール」であるのに対して，
　引用発明においては，「サーバユニット」の「判定部」である点。
　
［相違点５］
“プロビジョニング・サーバの送信手段”に関して，
　本件補正発明においては，「クライアント・プロビジョニング・モジュールから」送信するものであるの対して，
　引用発明においては，「サーバユニット」の「送信部」から送信するものである点。
　
［相違点６］
　本件補正発明においては，「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップ」を有するのに対して，
　引用発明においては，そのような「ステップ」に関する言及がない点。
　
［相違点７］
　本件補正発明においては，「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと，前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップとを具え，前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成する」ものであるのに対して，
　引用発明においては，「リスナ」と「パッケージ・ハンドラ」の処理に相当する点が言及されていない点。
　
オ．相違点についての当審の判断
（ア）［相違点１］，［相違点３］〜［相違点５］について
　引用発明においては，「サーバユニット」において，「受信部」，「判定部」，「送信部」の別個の構成によって実現しているが，これらの構成を１つに統合した「モジュール」を構成することは，当業者が，適宜なし得る事項である。
　よって，［相違点１］，［相違点３］〜［相違点５］は，格別のものではない。
　
（イ）［相違点２］，［相違点６］，及び，［相違点７］について
　プロビジョニングにおいて，インストールの結果を受信する点については，上記Ｅ，及び，Ｆにおいて引用した，引用刊行物２の記載にあるとおり，本願の第１国出願前に，当業者には，広く知られた技術事項である。
　また，新たなソフトウェア情報を，サーバのデータベースに登録すること，及び，事前に送信用のデータを生成する点についても，上記Ｇ，Ｈ，及び，Ｋにおいて引用した，周知文献１，及び，周知文献４の記載にあるとおり，本願の第１国出願前に，当業者には周知の技術である。
　ここで，周知文献１においては，送信データのセットアップを，送信時に行っているが，事前に行い得ることは，当業者にとって自明の事項である。
　そして，「リスナ」，及び，「ハンドラ」についても，上記Ｉ，Ｊにおいて引用した，周知文献２，及び，周知文献３の記載にもあるとおり，当業者には周知の技術事項であり，「リスナ」と「ハンドラ」間で通信を行う点についても，上記Ｉに引用する記載中にあるとおり，本願の第１国出願前に，当業者には広く知られた技術事項である。
　したがって，引用発明においても，更新に用いる，新たな「最適ソフトウェアデータ」を，「サーバユニット」が受信した場合に，それを「リスナ」が当該受信した「最適ソフトウェアデータ」の種別と，「記憶部」上の格納場所を「ハンドラ」に通知し，該「ハンドラ」が，必要な処理を施してから，「記憶部」に格納するよう構成すること，及び，前記「リスナ」に，「ＩＰ電話装置」からの，「インストール結果の通知」を受信する機能を持たせるよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点２］，［相違点６］，及び，［相違点７］は，格別のものではない。
　
　上記で検討したごとく，［相違点１］〜［相違点７］はいずれも格別のものではなく，そして，本件補正発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　よって，本件補正発明は，引用発明，引用刊行物２に記載の発明，及び，周知文献１〜周知文献４に記載の技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。
　
カ．独立特許要件むすび
　したがって，本件手続補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．補正却下むすび
　以上のおいて検討したとおり，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第５項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　仮に，本件手続補正が，目的要件を満たすものであったとしても，
　本件手続補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成２５年６月１０日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２４年１１月１２付けの手続補正により補正された，上記「第２．平成２５年６月１０日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１として引用した，次のとおりのものである。
　
「様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって，
　プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと，
　　　　　　ここで，前記装置構成情報は，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み，
　前記クライアント・プロビジョニング・モジュールが，前記プロビジョニング要求に応答して，前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと，
　　ここで，前記決定するステップは，
　　　　　　前記クライアント・プロビジョニング・モジュールが，前記コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと，
　　　　　　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，前記クライアント・プロビジョニング・モジュールが，前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み，
　　　　　　　　　　　ここで，前記判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み，
　前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと
を具えたことを特徴とする方法。」
　
第４．引用刊行物に記載の発明
　原審拒絶理由において引用した，特開２００５−０２６９９３号公報（２００５年１月２７日公開）には，上記「第２．平成２５年６月１０日付けの手続補正の却下の決定」の「２．補正の適否」，「（３）独立特許要件」における「ウ．引用刊行物１に記載の発明」において認定したとおりの，次の引用発明が記載されている。
　
　インターネット網を介して接続されたＩＰ電話装置とサーバユニットによって構成されるＩＰ電話システムにおいて，ＩＰ電話装置に，最適ソフトウェアデータを送信するための方法であって，
　サーバユニットは，受信部と，判定部と，記憶部と，制御部と，送信部と，から構成され，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し，前記受信部が，ＩＰ電話装置からの登録要求メッセージを受信し，前記記憶部が，加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶し，
　前記受信部が，ＩＰ電話装置から，ＩＰ電話装置の各々に固有の識別情報，および，現在搭載しているソフトウェアデータのソフトウェア番号を受信し，
　前記判定部が，前記受信部から前記識別情報及びソフトウェア番号を受け取り，前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い，比較の結果，前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には，判定部は，ソフトウェアの書き換えが必要だと判断し，
　更新が必要である場合には，前記制御部が，前記識別情報及び前記最適ソフトウェア番号を用いて，前記ＩＰ電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取り，
　ＩＰ電話装置にインストールする最適ソフトウェアデータが，サーバユニットを構成する送信部から，前記ＩＰ電話装置に送信される，方法。
　
第５．本願発明と引用発明との対比
　本願発明は，上記「第２．平成２５年６月１０日付けの手続補正の却下の決定」において検討した，本件補正発明から，
「該クライアント・プロビジョニング・モジュールは，更新リスナを有する自動更新サービスモジュールと，更新パッケージハンドラとを含み」という構成と，
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって，前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと，
　前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって，更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップとを具え，
　前記更新リスナは，新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し，
　前記更新パッケージ・ハンドラは，前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って，前記プロビジョニング・データベース内で更新ファイルを編成する」という構成を削除したものであるから，
　本願発明と，引用発明との，一致点，及び，相違点は，
　
［一致点］
　様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって，
　プロビジョニング・サーバの受信手段が，前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと，
　前記受信手段が，様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップと，
　前記プロビジョニング・サーバが，前記プロビジョニング要求に応答して，前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を，前記様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップと，
　ここで前記決定するステップは，
　前記プロビジョニング・サーバの判定手段が，コンポーネント・バージョン情報の様々な識別フィールド値を，プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと，
　前記プロビジョニング・データベースが，前記様々な種類のパケット・テレフォニー装置に既にインストールされた１つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み，比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において，プロビジョニング・サーバの判定手段が，前記様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップとを含み，
　ここで前記判定するステップは，前記必要としている場合には，当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み，
　前記ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用に前記パケット・テレフォニー装置に送信するステップと
　を含む方法。
　
［相違点ａ］
“プロビジョニング・サーバの受信手段”に関して，
　本願発明においては，「プロビジョニング・サーバのクライアント・プロビジョニング・モジュール」であるのに対して，
　引用発明においては，「サーバユニット」の「受信部」である点。
　
［相違点ｂ］
“プロビジョニング・サーバが・・・提供するかを決定するステップ”に関して，
　本願発明においては，「クライアント・プロビジョニング・モジュール」が行っているのに対して，
　引用発明においては，「サーバユニット」の「判定部」が行っている点。
　
［相違点ｃ］
“プロビジョニング・サーバの判定手段”に関して，
　本願発明においては，「クライアント・プロビジョニング・モジュール」であるのに対して，
　引用発明においては，「サーバユニット」の「判定部」である点。
　
［相違点ｄ］
“プロビジョニング・サーバの送信手段”に関して，
　本願発明においては，「クライアント・プロビジョニング・モジュールから」送信するものであるの対して，
　引用発明においては，「サーバユニット」の「送信部」から送信するものである点。
　
第６．相違点についての当審の判断
　本願発明と，引用発明との［相違点ａ］〜［相違点ｄ］は，本件補正発明と，引用発明との［相違点１］，［相違点３］〜［相違点５］と同じものであるから，上記「第２．平成２５年６月１０日付けの手続補正の却下の決定」の「２．補正の適否」，「（３）独立特許要件」における「オ．相違点についての当審の判断」において検討したとおりであって，
　［相違点ａ］〜［相違点ｄ］は，何れも格別のものではない。
　そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
第７．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。