• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 4項4号特許請求の範囲における明りょうでない記載の釈明 特許、登録しない。 G06F
審判 査定不服 4項3号特許請求の範囲における誤記の訂正 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 4項1号請求項の削除 特許、登録しない。 G06F
管理番号 1307625
審判番号 不服2013-10813  
総通号数 193 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-01-29 
種別 拒絶査定不服の審決 
審判請求日 2013-06-10 
確定日 2015-11-11 
事件の表示 特願2010-514960「自動的なソフトウェア・プロビジョニング技法」拒絶査定不服審判事件〔平成20年12月31日国際公開,WO2009/002739,平成22年 9月30日国内公表,特表2010-532049〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2008年6月13日(パリ条約による優先権主張外国庁受理2007年6月27日 アメリカ合衆国)を国際出願日とする出願であって,
平成21年12月22日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,平成23年3月16日付けで審査請求がなされ,平成24年8月3日付けで審査官により拒絶理由が通知され,これに対して平成24年11月12日付けで意見書が提出されると共に手続補正がなされたが,平成25年2月4日付けで審査官により拒絶査定がなされ(発送;平成25年2月8日),これに対して平成25年6月10日付けで審判請求がなされると共に手続補正がなされ,平成25年8月9日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成25年11月5日付けで当審により特許法第134条第4項の規定に基づく審尋がなされたが,回答書の提出がなかったものである。

第2.平成25年6月10日付けの手続補正の却下の決定

[補正却下の決定の結論]

平成25年6月10日付け手続補正を却下する。

[理由]

1.補正の内容
平成25年6月10日付けの手続補正(以下,「本件手続補正」という)により,平成24年11月12日付けの手続補正により補正された特許請求の範囲,
「 【請求項1】
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって,
プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと,
前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと,
ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み,
前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと,
ここで,前記決定するステップは,
前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み,
ここで,前記判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと
を具えたことを特徴とする方法。
【請求項2】
タイプ識別子,ベンダ識別子,モデル識別子,ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項3】
ファイル・メジャー・バージョン識別子,ファイル・マイナー・バージョン識別子,ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング(ｑｕick fiｘ engineeｒing)識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項4】
前記装置構成情報と共に含まれる,前記パケット・テレフォニー装置のタイプ識別子に対応する前記ソフトウェア更新パッケージをプロビジョニング・データベースから取り出すステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項5】
前記プロビジョニング・サーバが前記ソフトウェア更新パッケージを公開サーバから受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項6】
前記パケット・テレフォニー装置において,
前記プロビジョニング要求を前記プロビジョニング・サーバの前記クライアント・プロビジョニング・モジュールに送信するステップと,
前記パケット・テレフォニー装置の装置構成情報を前記クライアント・プロビジョニング・モジュールに送信するステップと,
前記パケット・テレフォニー装置が前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから受け取るステップと,
前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置にインストールするステップと
をさらに具えたことを特徴とする請求項1記載の方法。
【請求項7】
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケットテレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に,前記ソフトウェア更新パッケージをテストおよび検証するステップをさらに具えたことを特徴とする請求項1ないし6のいずれかに記載の方法。
【請求項8】
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための装置であって,
様々な種類のパケット・テレフォニー装置向けのソフトウェア更新パッケージを記憶するためのプロビジョニング・データベースと,
前記プロビジョニング・データベースに通信可能に結合され,コンピュータ実行可能命令を有するクライアント・プロビジョニング・モジュールと,
前記クライアント・プロビジョニング・モジュールに通信可能に結合され,前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置に送信する,ネットワーク・インタフェースと,
を具え,前記コンピュータ実行可能命令は,
プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取ることと,
前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取ることと,
ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み,
前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定することと,
ここで,前記決定することは,
前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較することと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定することとを含み,
ここで,前記判定することは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定することを含み,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信することと
を具えたことを特徴とする装置。
【請求項9】
更新パッケージを公開サーバから受け取る更新エージェントと,前記更新パッケージをプロビジョニング・データベースにインストールしインストール結果を自動更新サービス・モジュールに通知するインストーラとを有する自動更新モジュールをさらに具えたことを特徴とする請求項8記載の装置。
【請求項10】
前記クライアント・プロビジョニング・モジュールは,
更新パッケージのインストール結果の通知を受け取る更新リスナを有する自動更新サービス・モジュールと,更新ファイルを前記更新パッケージから抽出しプロビジョニング・データベースに格納する更新パッケージ・ハンドラとをさらに具えたことを特徴とする請求項8記載の装置。
【請求項11】
前記装置構成情報は,タイプ識別子,ベンダ識別子,モデル識別子,ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報をさらに有することを特徴とする請求項8記載の装置。
【請求項12】
前記装置構成情報は,ファイル・メジャー・バージョン識別子,ファイル・マイナー・バージョン識別子,ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報をさらに有することを特徴とする請求項8記載の装置。
【請求項13】
前記コンピュータ実行可能命令は,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケットテレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に,前記ソフトウェア更新パッケージをテストおよび検証することをさらに具えたことを特徴とする請求項8記載の装置。
【請求項14】
コンピュータにより,請求項1ないし7のいずれかに記載の方法を実行することが可能な命令を有するコンピュータプログラム。
【請求項15】
請求項14記載のコンピュータプログラムを有するコンピュータ読取り可能な記録媒体。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「 【請求項1】
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって,
プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと,
ここで,該クライアント・プロビジョニング・モジュールは,更新リスナを有する自動更新サービスモジュールと,更新パッケージハンドラとを含み,
前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと,
ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み,
前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと,
ここで,前記決定するステップは,
前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み,
ここで,前記判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと,
前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと,
前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと
を具え,
前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,
前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成することを特徴とする方法。
【請求項2】
タイプ識別子,ベンダ識別子,モデル識別子,ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項3】
ファイル・メジャー・バージョン識別子,ファイル・マイナー・バージョン識別子,ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング(ｑｕick fiｘ engineeｒing)識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報を有する装置構成情報を受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項4】
前記装置構成情報と共に含まれる,前記パケット・テレフォニー装置のタイプ識別子に対応する前記ソフトウェア更新パッケージをプロビジョニング・データベースから取り出すステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項5】
前記プロビジョニング・サーバが前記ソフトウェア更新パッケージを公開サーバから受け取るステップをさらに具えたことを特徴とする請求項1記載の方法。
【請求項6】
前記パケット・テレフォニー装置において,
前記プロビジョニング要求を前記プロビジョニング・サーバの前記クライアント・プロビジョニング・モジュールに送信するステップと,
前記パケット・テレフォニー装置の装置構成情報を前記クライアント・プロビジョニング・モジュールに送信するステップと,
前記パケット・テレフォニー装置が前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから受け取るステップと,
前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置にインストールするステップと
をさらに具えたことを特徴とする請求項1記載の方法。
【請求項7】
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケット・テレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に,前記ソフトウェア更新パッケージをテストおよび検証するステップをさらに具えたことを特徴とする請求項1ないし6のいずれかに記載の方法。
【請求項8】
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための装置であって,
ブロセッサと,
様々な種類のパケット・テレフォニー装置向けのソフトウェア更新パッケージを記憶するためのプロビジョニング・データベースと,
前記プロビジョニング・データベースに通信可能に結合され,コンピュータ実行可能命令を有するクライアント・プロビジョニング・モジュールを格納したメモリと,
ここで,該クライアント・プロビジョニング・モジュールは,更新リスナを有する自動更新サービスモジュールと,更新パッケージハンドラとを含み,
前記クライアント・プロビジョニング・モジュールに通信可能に結合され,前記ソフトウェア更新パッケージを前記パケット・テレフォニー装置に送信する,ネットワーク・インタフェースと,
を具え,前記ブロセッサによって実行される前記クライアント・プロビジョニング・モジュールは,
プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取ることと,
前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取ることと,
ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み,
前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定することと,
ここで,前記決定することは,
前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較することと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定することとを含み,
ここで,前記判定することは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定することを含み,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信することと,
前記クライアント・プロビジョニング・モジュールの更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取ることと,
前記クライアント・プロビジョニング・モジュールの更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納することと
を具え,
前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,
前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成することを特徴とする装置。
【請求項9】
前記ソフトウェア更新パッケージを公開サーバから受け取る更新エージェントと,前記ソフトウェア更新パッケージをプロビジョニング・データベースにインストールしインストール結果を自動更新サービス・モジュールに通知するインストーラとを有する自動更新モジュールをさらに具えたことを特徴とする請求項8記載の装置。
【請求項10】
前記装置構成情報は,タイプ識別子,ベンダ識別子,モデル識別子,ハードウェア・リビジョン識別子またはロケール識別子を含む前記パケット・テレフォニー装置のタイプ識別情報をさらに有することを特徴とする請求項8記載の装置。
【請求項11】
前記装置構成情報は,ファイル・メジャー・バージョン識別子,ファイル・マイナー・バージョン識別子,ファイル・ビルド識別子またはファイル・クイック・フィックス・エンジニアリング識別子を含む前記パケット・テレフォニー装置のコンポーネント・バージョン情報をさらに有することを特徴とする請求項8記載の装置。
【請求項12】
前記コンピュータ実行可能命令は,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールから前記パケット・テレフォニー装置上でのインストール用に前記パケット・テレフォニー装置に送信する前に,前記ソフトウェア更新パッケージをテストおよび検証することをさらに具えたことを特徴とする請求項8記載の装置。
【請求項13】
コンピュータにより,請求項1ないし7のいずれかに記載の方法を実行することが可能な命令を有するコンピュータプログラム。
【請求項14】
請求項13記載のコンピュータプログラムを有するコンピュータ読取り可能な記憶媒体。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
(1)新規事項
本件手続補正によって,補正前の請求項1に加えられた,
「ここで,該クライアント・プロビジョニング・モジュールは,更新リスナを有する自動更新サービスモジュールと,更新パッケージハンドラとを含み」,
という記載事項は,平成21年12月22日付けで提出された,特許法第184条の4第1項の規定による明細書,請求の範囲の日本語による翻訳文,及び,国際出願の願書に添付された図面(以下,これを「当初明細書等」という)の段落【0020】に,
「プロビジョニング・モジュール122はさらに,クライアント・プロビジョニング・モジュール222,自動更新サービス・モジュール224,および更新パッケージ・ハンドラ228を備えることができる。自動更新サービス・モジュール224はさらに,更新リスナ226を備えることができる」,
という記載が存在することから,当初明細書等の記載の範囲内であることは明らかである。
同じく,補正前の請求項1に加えられた,
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと,
前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと」,
及び,
「前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,
前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成する」,
という記載事項は,当初明細書等に,
「【0029】
様々な実施形態では、自動更新サービス・モジュール224と更新パッケージ・ハンドら228を、自動更新モジュール210とプロビジョニング・データベース130に通信可能に結合することができる。自動更新サービス・モジュール224を、配布局(例えば、公開サーバ110、206)とプロビジョニング・サーバ120の間の更新動作を管理するように構成することができる。自動更新サービス・モジュール224は更新リスナ226を備えることができる。更新リスナ226は、更新パッケージ230のような更新パッケージのインストール結果の通知を自動更新モジュール210のインストーラ214から受け取ることができる。更新リスナ226は次に新しく到着した更新パッケージ230とそのプロビジョニング・データベース130内の位置を更新パッケージ・ハンドラ228に通知することができる。更新パッケージ・ハンドラ228を、更新パッケージ230から更新ファイル132-1-nを抽出するように構成することができ、更新パッケージ・ハンドラ228は更新ファイル132-1-nをプロビジョニング・データベース130に記憶する。更新パッケージ・ハンドラ228は、通信装置140-1?mの様々なサポートされる装置タイプに従って、プロビジョニング・データベース130内で更新ファイル132-1-nを編成することができる。」,
と記載されていることから,当初明細書等の記載の範囲内のものであることは明らかである。このことは,補正前の請求項8に加えられた記載内容についても同様である。
そして,補正前の上記指摘の請求項以外の請求項に加えられた記載事項は,何れも,当初明細書等の記載の範囲内のものである。
よって,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第3項の規定を満たすものである。

(2)目的要件
ア.目的要件についての当審の判断
次に,本件手続補正が,特許法第184条の12第2項により読み替える同法第17条の2第5項の規定を満たすものであるか否か,即ち,本件手続補正が,特許法第17条の2第5項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。

上記「(1)新規事項」において検討した,本件手続補正によって,補正前の請求項1に加えられた記載事項に関して,補正前の請求項1に係る発明は,方法の発明であって,補正前の請求項1を引用する請求項は,補正前の請求項2?請求項7である。
そして,補正前の請求項2?請求項7に記載された内容には,本件手続補正によって,補正前の請求項1に加えられた事項は存在していないので,補正後の請求項1が,補正前の請求項1を削除し,補正前の請求項1を引用する上記指摘の何れかの補正前の請求項の記載内容を加えて新たな補正後の請求項1とした,請求項の削除を目的としたものではないことは明らかである。
また,原審の平成24年8月3日付けの拒絶理由(以下,これを「原審拒絶理由」という)において不明であると指摘された事項,及び,原審の平成25年2月4日付けの拒絶査定(以下,これを「原審の拒絶査定」)の備考において,依然として不明であると指摘された事項を明りょうにすることを目的とした補正事項とも認められず,誤記の訂正でないことも明らかである。
そこで,本件手続補正が,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る)(以下,これを「限定的減縮」という)に該当するかを,以下に検討する。

上記「(1)新規事項」において検討した,本件手続補正によって,補正前の請求項1に加えられた記載事項のうち,
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと,
前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップと」,
及び,
「前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,
前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成する」,
は,補正前の請求項1に係る発明の構成に,
“更新リスナによって,インストール結果の通知を受け取るステップ”,
“更新パッケージ・ハンドラによって,更新ファイルをデータベースに格納するステップ”,
という,新たな2つの“ステップ”と,「更新リスナ」と,「更新パッケージ・ハンドラ」との間で行われる処理を付加するものである。
ここで,上述において指摘した,「更新リスナ」と,「更新パッケージ・ハンドラ」との間で行われる処理の内,特に,
“更新パッケージ・ハンドラによって,更新ファイルをデータベースに格納するステップ”
という処理は,
“プロビジョニング・サーバのデータベースに,パケット・テレフォニー装置のソフトウェア更新のための新たなソフトウェアを格納する”
というものであるから,補正前の請求項1に係る発明における,
“プロビジョニング・サーバによって,パケット・テレフォニー装置のソフトウェア更新を行う”
という処理に対して,新たな処理内容を付加するものであることは,明らかである。
したがって,補正前の請求項1に係る発明において,「更新リスナ」,及び,「更新パッケージ・ハンドラ」に関する処理内容は,補正前の請求項1に係る発明に新たに加えられた機能を表現するものであって,補正前の請求項1係る発明における発明特定事項の何れかを,限定的に減縮するものとは認められない。
以上検討したとおり,本件手続補正による,補正前の請求項1に対する補正内容は,特許法第17条の2第5項に既定された目的要件の何れにも該当しない。

イ.目的要件むすび
したがって,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第5項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

(3)独立特許要件
上記において検討したとおり,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第5項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものであるが,
仮に本件手続補正が,目的要件を満たすものであるとして,本件手続補正が,特許法第17条の2第6項において準用する同法第126条第7項の規定を満たすものであるか否か,即ち,補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か,検討する。

ア.補正後の請求項1に係る発明
補正後の請求項1に係る発明(以下,これを「本件補正発明」という)は,上記「第2.平成25年6月10日付けの手続補正の却下の決定」の「1.補正の内容」において,補正後の請求項1として引用した記載によって特定されるものである。

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

A.「【0080】
(実施の形態2)
図10は,本発明の実施の形態2に係るIP電話システム1000の全体構成を示す図である。図10に示すIP電話システム1000は,IP電話装置1001-1?1001-Nと,サーバユニット1002と,インターネット網1003と,から構成される。
【0081】
IP電話装置1001-1?1001-Nと,サーバユニット1002とは,インターネット網1003を介して接続されている。なお,IP電話装置1001-1?1001-N及びサーバユニット1002は,図10に示すようにそれぞれ異なるLANに設置されていてもよく,また,どのような組み合わせで同一のLAN内に設置されていてもよい。」

B.「【0083】
図10に示すIP電話システム1000は,サーバユニット1002がIP電話装置1001のソフトウェアデータの書き換えの要否を判断し,必要と判定した時には最適ソフトウェアデータをIP電話装置1001へ送信するため,自動的なソフトウェアデータの書き換えを可能とする。また,IP電話装置1001は,音声通信のほか映像通信も可能である。」

C.「【0087】
受信部1102は,サーバユニット1002が送信する登録応答メッセージ,又は,IP電話装置1001とサーバユニット1002との間のセッションを張るための登録応答メッセージ及び最適ソフトウェアデータを受信して,書き換え制御部1103に与える。ここで,最適ソフトウェアデータとは,IP電話装置において,例えば,その使用時期において最適な機能を付与するソフトウェアデータを意味する。また,最適ソフトウェア番号とは,最適のソフトウェアデータを識別するための番号である。
【0088】
書き換え制御部1103は,受信部1102からセッションを張るための登録応答メッセージ中に含まれる書き換え要否情報(ここでは,書き換えを必要とする旨を示す。)及び最適ソフトウェアデータを受け取ると,記憶部1104に記憶されているソフトウェアデータを最適ソフトウェアデータに書き換えると共に加入者管理情報テーブル(図8(1))で管理している現在のソフトウェア番号も最適ソフトウェア番号に書き換える。
【0089】
図12は,サーバユニット1002の構成を示すブロック図である。図12のサーバユニット1002は,受信部1201と,判定部1202と,記憶部1203と,制御部1204と,送信部1205と,から構成される。
【0090】
受信部1201は,IP電話装置1001から登録要求メッセージを受信する。記憶部1203は,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している。なお,この実施の形態2における端末管理情報テーブルは,図8(2)に示す本発明の実施の形態1の端末管理情報テーブルにおけるソフト管理サーバアドレスをなくしたものである。この実施の形態2における加入者管理情報テーブルは,図8(1)に示す実施の形態1の加入者管理情報テーブルと同様のものである。
【0091】
判定部1202は,受信部1201から識別情報及びソフトウェア番号を受け取る。判定部1202は,その識別情報をキーとして,加入者管理情報テーブルのソフトウェア更新要求の欄の設定がソフトウェアの書き換えを行う設定になっているかを判定する。判定の結果,書き換えを行う設定の時には,判定部1202は,その識別情報をキーとして,記憶部1203の端末管理情報テーブルから最適ソフトウェア番号を読み取って,ソフトウェア番号と最適ソフトウェア番号との比較を行う。比較の結果,ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部1202は,識別情報と書き換え要否情報(ここでは,書き換えが必要であることを示す内容を持っている。)と最適ソフトウェア番号とを制御部1204に与える。
【0092】
制御部1204は,判定部1202からその書き換えが必要である旨の書き換え要否情報を受け取った時には,記憶部1203から識別情報をキーとして,加入者管理情報テーブルにおけるIP電話装置101のIPアドレス及び端末管理情報テーブルにおける最適ソフトウェアデータを読み取る。また,制御部1204は,サーバユニット1002とIP電話装置1001との間のセッションを張るための登録応答メッセージを生成し,送信部1205に与える。
【0093】
送信部1205は,識別情報及びIPアドレスから特定されるIP電話装置1001へそのセッションを張るための登録応答メッセージを送信する。これにより,サーバユニット1002とIP電話装置1001との間のセッションが張られることになる。そして,制御部1204は,最適ソフトウェアデータ及び書き換え要否情報(ここでは,書き換えが必要であることを示す内容を持っている。)を送信部1205に与え,送信部1205は識別情報及びIPアドレスから特定されるIP電話装置1001へ送信する。」

D.「【0099】
次に,サーバユニット1002が行う判定処理について,図13を参照して説明する。
【0100】
サーバユニット1002の受信部1201は,IP電話装置1001から送信されるIP電話装置1001各々に固有の識別情報及び現在搭載しているソフトウェアデータのソフトウェア番号を含む登録要求メッセージを受信する(ST1301)。判定部1202は,受信部1201から識別情報及びソフトウェア番号を受け取る(ST1302)。
【0101】
判定部1202は,その識別情報をキーとして,記憶部1203の加入者管理情報テーブルに記憶されているソフトウェア更新要求の設定が「する」となっているか判定する(ST1303)。ソフトウェア更新要求の設定が「する」と設定されている時には,判定部1202は,その識別情報をキーとして,記憶部1203の端末管理情報テーブルから最適ソフトウェア番号を読み取る(ST1304)。ST1303において,ソフトウェア更新要求の設定が「しない」と設定されている時には,ST1307に移行する。
【0102】
判定部1202は,ソフトウェア番号と最適ソフトウェア番号との比較を行う(ST1305)。比較の結果,ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部1202は,ソフトウェアの書き換えが必要だと判断し,識別情報と書き換え要否情報(ここでは,書き換えが必要であることを示す内容を持っている。)と最適ソフトウェア番号とを制御部1204に与える。
【0103】
制御部1204は,判定部1202から書き換えが必要である旨の書き換え要否情報を受け取った時には,一緒に受け取る識別情報及び最適ソフトウェア番号をキーとして,IP電話装置101のIPアドレス及び最適ソフトウェアデータを読み取る。制御部1204は,サーバユニット1002とIP電話装置1001との間のセッションを張るための登録応答メッセージを生成する(ST1306)。
【0104】
サーバユニット1002の制御部1204は,判定部1202から書き換えが不要である旨の書き換え要否情報を受け取った時には,一緒に受け取る識別情報をキーとして,記憶部1203の加入者管理情報テーブルからIP電話装置1001のIPアドレスを読み取る。また,制御部1204は,書き換え要否情報(書き換えが不要である旨を示す。)を中に含む登録応答メッセージを生成する(ST1307)。
【0105】
以上のように,本発明の実施の形態2によれば,サーバユニットがIP電話装置のソフトウェアデータの書き換えの要否を判定し,必要と判定した時には最適ソフトウェアデータをIP電話装置へ送信するため,自動的なソフトウェアデータが書き換えが可能となるので,IP電話装置に最適のソフトウェアがインストールされるまでの期間を短くし,IP電話システムを利用できない期間を非常に短縮することができるIP電話システムを提供することができる。また,実施の形態2によれば,実施の形態1に係るIP電話システムにおける2つのサーバ装置を1つにまとめたため,IP電話システム構築の低コスト化を図ることができる。」

(イ)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,特開2007-128521号公報(2007年5月24日公開,以下,これを「引用刊行物2」という)には,関連する図面と共に,次の事項が記載されている。

E.「【0045】
次に,ステップ418で,依存性チェッカ410が,有資格ノードのリストをノード・マネージャ402に返す。このリストに,プロビジョニング待ち時間,ライセンス・コスト,ディスク使用量などのことに関する計画されたコストが含まれる。表2に,上で与えた例のコスト・リストを示す。」

F.「【0049】
ステップ430で,各ターゲットにされたノードが,インストールの結果を別々に報告する。最後に,ステップ432で,ノード・マネージャ402が,結果についてノード・キャッシュ414に通知する。さらに,このプロセス全体を通じて,提供フレームワーク400の状態が,ノード・マネージャ402にパス・スルーされ,ノード・マネージャ402は,状況情報を用いてフロント・エンド406を更新する。」

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

G.「【0017】すなわち,配信処理部1aは,格納処理部1bにより,配信対象のソフトウェアを,各受信側コンピュータ2?4のそれぞれに共通な共通モジュール部分13(図中,「AP」と記載)と,それぞれ異なる差分モジュール部分14,15(図中,「A」,「C」と記載)とに分けてハードディスク装置9に格納する。また,情報登録処理部1cにより,次の図3に示すように,各受信側コンピュータ2?4に配信済みのソフトウェアの識別情報と更新情報および差分モジュール部分14,15の識別情報をハードディスク装置9等に登録する。」

H.「【0031】さらに,送信元管理者が,バージョンアップしたソフトウェアをカスタマイズして受信用コンピュータ2への差分モジュール部分14(「A」)と受信用コンピュータ4への差分モジュール部分15(「C」)の格納を指示すると(ステップ104),送信側コンピュータ1は,配信先情報テーブル31の差分情報の項目に,マシン別のファイル名(差分モジュール部分の識別情報)を書込み,バージョンアップしたソフトウェアを共通モジュール部分13と差分モジュール部分14,15に分けてハードディスク装置9に格納する(ステップ105)。
・・・・・(中略)・・・・・
【0033】このようにして特定した相手マシンに対応して,共通モジュール部分13(「AP」)とマシン別の差分モジュール部分14(「A」),15(「C」)とを組み合わせて,相手マシン用のソフトウェアを作成し(ステップ109),バージョンアップすべき相手マシンに配信する(ステップ110)。」

(エ)本願の第1国出願前に既に公知である,国際公開第2004/114045号(2004年12月29日公開,以下,これを「周知文献2」という)には,関連する図面と共に,次の事項が記載されている。

I.「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.」(17頁22行?18頁13行)
(【0053】
“好適なエクスプロイト・ディテクター”
図5は,エクスプロイトプロテクションを提供するために操作可能なファイアーウォールの構成要素を,本発明の一つの実施形態に従って図示する。ファイアーウォール500の構成要素は,メッセージ・リスナー505,エクスプロイト・ディテクター510,および出力構成要素545を含む。エクスプロイト・ディテクター510は,メッセージ待ち行列515,解凍構成要素525,メッセージ・トラッカー527,スキャナ構成要素530,およびエクスプロイト・ハンドラー540を含む。メッセージ・トランスポート・エージェント555もまた示される。
【0054】
ファイアーウォール500は,図4のネットワーク450,および外部ネットワーク405に接続されたデバイス間で,送信された多くのメッセージタイプを受信するかもしれない。いくらかのメッセージは,通信に参加している二つのコンピュータ間で転送されるWWWトラヒック,またはデータに関連することが考えられる。一方では,その他のメッセージは,電子メールに関連し得る。メッセージ・リスナー505は,メッセージをリッスンし,電子メール,またはファイルのような適切なメッセージの受信に基づいて,エクスプロイトをスキャンするためのエクスプロイト・ディテクター510へ,メッセージを送信する。
【0055】
電子メールメッセージを処理する場合,エクスプロイト・ディテクター510は,いくぶん,電子メールメッセージのフィールドをスキャンし,検査することで,エクスプロイトプロテクションを提供する。電子メールメッセージは,一般的には,ヘッダ(一定のフィールドを含むかもしれない),ボディ(一般的には電子メールのテキストを含む),および一つ以上の任意の添付ファイルを含む。エクスプロイト・ディテクター510は,電子メールのフィールド長を調査することで,それらがあるべき長さよりも,長いか否かを決定する。「あるべき長さより長い」ことは,規格や,メールサーバー仕様書によって決定されるか,または,ファイアーウォール管理者によって選択される。もし,電子メールが,あるべき長さより長いフィールドを含む場合,そのメッセージは,以下に詳細に記述されるように,エクスプロイト・ハンドラー540へ送信されることが考えられる。<対応する,日本語公報である,特表2007-528040号より引用>)

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

J.「【0090】
第7のタイプのデータ構造は,プラグイン・マネージャ338の管理ハンドラを指定するQｕeｒｙCｏnfigおよびSeｔCｏnfigを含む。
【0091】
その通知リスナーの役割において,プラグイン・マネージャ338は,プラグインによって生成される更新信号を監視する。通知の取り扱いは,その通知と関連するプラグインのタイプに応じて異なる。」

(カ)本願の第1国出願前に既に公知である,特開2003-228486号公報(2003年8月15日公開,以下,これを「周知文献4」という)には,関連する図面と共に,次の事項が記載されている。

K.「【0035】具体的には,図3に示すように,ソフトウェアA1のバージョンアップ版のソフトウェアA2がリリースされた場合に,システム管理者が,DB部120のSW情報格納領域121に格納されているソフトウェアA1をソフトウェアA2に更新する。このとき,ソフトウェアA2の更新情報(ソフトウェアA1から更新(変更)された一部のプログラムのモジュールなどの情報)がSW情報格納領域121に登録されるとともに,そのソフトウェアA2の製品名,バージョン情報,更新プログラムなどもSW情報格納領域121にソフトウェアA2に対応付けて登録(格納)される。
【0036】また,図4に示すように,システム管理者は,DB部120のSW情報格納領域121にソフトウェアNを新規に追加(登録)する。このとき,ソフトウェアNの本体の情報がSW情報格納領域121に登録されるとともに,そのソフトウェアNの製品名,バージョン情報,インストールプログラムなどもSW情報格納領域121にソフトウェアNと対応付けて登録される。
【0037】さらに,図5に示すように,システム管理者は,DB部120のSW情報格納領域121からソフトウェアDを削除する。このとき,ソフトウェアDの製品名,バージョン情報,削除プログラムなどがSW情報格納領域121にソフトウェアNに対応付けて登録される。」

ウ.引用刊行物1に記載の発明
(ア)上記Aの「IP電話システム1000は,IP電話装置1001-1?1001-Nと,サーバユニット1002と,インターネット網1003と,から構成される」という記載,同じく,上記Aの「IP電話装置1001-1?1001-Nと,サーバユニット1002とは,インターネット網1003を介して接続されている」という記載,及び,上記Bの「最適ソフトウェアデータをIP電話装置1001へ送信する」という記載から,引用刊行物1には,
“インターネット網を介して接続されたIP電話装置とサーバユニットによって構成されるIP電話システムにおいて,IP電話装置に,最適ソフトウェアデータを送信するための方法”が記載されていることが読み取れる。

(イ)上記Cの「サーバユニット1002は,受信部1201と,判定部1202と,記憶部1203と,制御部1204と,送信部1205と,から構成される」という記載,同じく,上記Cの「受信部1201は,IP電話装置1001から登録要求メッセージを受信する」という記載,及び,同じく,上記Cの「記憶部1203は,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している」という記載から,引用刊行物1においては,
“サーバユニットは,受信部と,判定部と,記憶部と,制御部と,送信部と,から構成され,前記受信部が,IP電話装置からの登録要求メッセージを受信し,前記記憶部が,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶している”ことが読み取れる。

(ウ)上記Dの「サーバユニット1002の受信部1201は,IP電話装置1001から送信されるIP電話装置1001各々に固有の識別情報及び現在搭載しているソフトウェアデータのソフトウェア番号を含む登録要求メッセージを受信する」という記載と,上記(ア)において検討した事項から,引用刊行物1においては,
“サーバユニットを構成する受信部が,IP電話装置から,IP電話装置の各々に固有の識別情報,および,現在搭載しているソフトウェアデータのソフトウェア番号を受信する”ことが読み取れる。

(エ)上記Cの「判定部1202は,受信部1201から識別情報及びソフトウェア番号を受け取る。判定部1202は,その識別情報をキーとして,加入者管理情報テーブルのソフトウェア更新要求の欄の設定がソフトウェアの書き換えを行う設定になっているかを判定する」,及び,上記Dの「判定部1202は,の識別情報をキーとして,記憶部1203の端末管理情報テーブルから最適ソフトウェア番号を読み取って,ソフトウェア番号と最適ソフトウェア番号との比較を行う(ST1305)。比較の結果,ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部1202は,ソフトウェアの書き換えが必要だと判断し」という記載から,引用刊行物1においては,
“判定部が,受信部から識別情報及びソフトウェア番号を受け取り,ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い,比較の結果,ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部は,ソフトウェアの書き換えが必要だと判断する”ものであることが読み取れる。

(オ)上記Cの「制御部1204は,判定部1202からその書き換えが必要である旨の書き換え要否情報を受け取った時には,記憶部1203から識別情報をキーとして,加入者管理情報テーブルにおけるIP電話装置101のIPアドレス及び端末管理情報テーブルにおける最適ソフトウェアデータを読み取る」という記載,及び,上記Dの「制御部1204は,判定部1202から書き換えが必要である旨の書き換え要否情報を受け取った時には,一緒に受け取る識別情報及び最適ソフトウェア番号をキーとして,IP電話装置101のIPアドレス及び最適ソフトウェアデータを読み取る」という記載から,引用刊行物1においては,
“更新が必要である場合には,制御部が,識別情報及び最適ソフトウェア番号を用いて,IP電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取る”ものであることが読み取れる。

(カ)上記Cの「制御部1204は,最適ソフトウェアデータ及び書き換え要否情報(ここでは,書き換えが必要であることを示す内容を持っている。)を送信部1205に与え,送信部1205は識別情報及びIPアドレスから特定されるIP電話装置1001へ送信する」という記載,及び,上記Dの「IP電話装置に最適のソフトウェアがインストールされるまでの期間」という記載と,上記(イ)において引用した,上記Cの記載内容から,引用刊行物1においては,
“IP電話装置にインストールする最適ソフトウェアデータが,サーバユニットを構成する送信部から,前記IP電話装置に送信される”ことが読み取れる。

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

インターネット網を介して接続されたIP電話装置とサーバユニットによって構成されるIP電話システムにおいて,IP電話装置に,最適ソフトウェアデータを送信するための方法であって,
サーバユニットは,受信部と,判定部と,記憶部と,制御部と,送信部と,から構成され,前記受信部が,IP電話装置からの登録要求メッセージを受信し,前記受信部が,IP電話装置からの登録要求メッセージを受信し,前記記憶部が,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶し,
前記受信部が,IP電話装置から,IP電話装置の各々に固有の識別情報,および,現在搭載しているソフトウェアデータのソフトウェア番号を受信し,
前記判定部が,前記受信部から前記識別情報及びソフトウェア番号を受け取り,前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い,比較の結果,前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部は,ソフトウェアの書き換えが必要だと判断し,
更新が必要である場合には,前記制御部が,前記識別情報及び前記最適ソフトウェア番号を用いて,前記IP電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取り,
IP電話装置にインストールする最適ソフトウェアデータが,サーバユニットを構成する送信部から,前記IP電話装置に送信される,方法。

エ.本件補正発明と引用発明との対比
(ア)引用発明において,「最適ソフトウェアデータ」への更新が,自動で行われていることは,明らかであり,引用発明において,「IP電話装置」の「搭載しているソフトウェアデータ」を最適化する処理が,プロビジョニングと言い得るものであって,
引用発明における「IP電話装置」,及び,「サーバユニット」が,本願発明における「パケットテレフォニー装置」,及び,「プロビジョニング・サーバ」に相当し,
引用発明における「IP電話装置」は,上記Dの「IP電話装置1001各々に固有の識別情報」という記載から,“複数台の種類の異なる「IP電話装置」を含む”態様を有すると言い得るものであるから,
引用発明における「インターネット網を介して接続されたIP電話とサーバユニットによって構成されるIP電話システムにおいて,IP電話装置に,最適ソフトウェアデータを送信するための方法」が,
本件補正発明における「様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法」に相当する。

(イ)引用発明における「登録要求メッセージ」は,当該「メッセージ」によって,「IP電話装置」に搭載されている「ソフトウェアデータ」の更新の有無の判断を行うことになるので,本件補正発明における「プロビジョニング要求」に相当し,
引用発明における「受信部」は,前記「登録要求メッセージ」を受信するものであるから,引用発明における「受信部」と,本件補正発明における「クライアント・プロビジョニング・モジュール」とは,“プロビジョニング要求を受信する受信手段”である点で共通しているので,
引用発明における「サーバユニットは,受信部と,判定部と,記憶部と,制御部と,送信部と,から構成され,前記受信部が,IP電話装置からの登録要求メッセージを受信し」と,
本件補正発明における「プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップ」とは,
“プロビジョニング・サーバの受信手段が,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップ”である点で共通する。

(ウ)引用発明において,「IP電話装置の各々に固有の識別情報」は,“装置の種別”示す情報とし得ることは,明らかであるから,引用発明における「IP電話装置の各々に固有の識別情報」,及び,「現在搭載しているソフトウェアデータのソフトウェア番号」が,本願発明における「様々な種類のパケット・テレフォニー装置のタイプ識別情報」,及び,「コンポーネント・バージョン情報」に相当するので,
引用発明における「前記受信部が,IP電話装置から,IP電話装置の各々に固有の識別情報,および,現在搭載しているソフトウェアデータのソフトウェア番号を受信し」と,
本件補正発明における「前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと,ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み」とは,
“受信手段が,様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップ”である点で共通する。

(エ)引用発明において,「端末管理情報テーブル」は,「最適ソフトウェア番号」を記憶するものであって,前記「最適ソフトウェア番号」は,「ソフトウェアデータ」の更新の有無を判定するために用いるものであって,引用発明においては,「記憶部が,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶」するものであるから,
引用発明における「端末管理情報テーブル」,及び,「最適ソフトウェアデータ」を記憶する「記憶部」が,本件補正発明における「プロビジョニング・データベース」に相当し,
引用発明における「最適ソフトウェア番号」と,本件補正発明における「プロビジョニング・データベースに記憶した対応するフィールド値」とは,“判定情報データベースに記憶した対応するフィールド値”である点で共通し,
引用発明における「現在搭載しているソフトウェアデータのソフトウェア番号」は,引用発明においても「IP電話装置」が,複数の「ソフトウェア」を有する態様を含むことは明らかであるから,本件補正発明における「コンポーネント・バージョン情報の様々な識別フィールド値」に相当し,
引用発明において,「ソフトウェアの書き換えが必要と判断」することは,“受信部が受信した,登録要求メッセージに応じて,IP電話装置の各々に固有の識別情報,および,現在搭載しているソフトウェアデータのソフトウェア番号に基づいて行われる”ものであるから,このことと,本件補正発明における「前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップ」とは,
“プロビジョニング・サーバが,プロビジョニング要求に応答して,様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を,様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップ”である点で共通する。

(オ)引用発明における「判定部が,前記受信部から前記識別情報及びソフトウェア番号を受け取り,前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行」うことと,
本件補正発明における「前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップ」とは,
“プロビジョニング・サーバの判定手段が,コンポーネント・バージョン情報の様々な識別フィールド値を,判定情報データベースに記憶した対応するフィールド値と比較するステップ”で共通し,
引用発明において,「記憶部」の記憶する「最適ソフトウェアデータ」は,「IP電話装置」の「現在搭載しているソフトウェアデータ」を更新するために用いられるものであるから,本件補正発明における「様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージ」に相当するので,
引用発明における「記憶部が,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶」することは,
本件補正発明における「プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含」むこと相当する。

(カ)引用発明における「比較の結果,前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部1202は,ソフトウェアの書き換えが必要だと判断」すること,
本件補正発明における「前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップ」とは,
“比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,プロビジョニング・サーバの判定手段が,様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップ”である点で共通する。

(キ)引用発明においても,「ソフトウェア番号」を比較することで,“どの最適ソフトウェアデータが必要かの判断”を行っていることは明らかであるから,このことが,
本件補正発明における「判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップ」に相当する。

(ク)引用発明においても,「最適ソフトウェアデータ」は,「サーバユニット」から,「IP電話装置」に送信されるものであり,前記「IP電話装置」に「インストール」されるものであるから,
引用発明における「IP電話装置にインストールする最適ソフトウェアデータが,サーバユニットを構成する送信部から,前記IP電話装置に送信される」ことと,
本件補正発明における「前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップ」こととは,
“ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用にパケット・テレフォニー装置に送信するステップ”である点で共通する。

以上(ア)?(ク)において検討した事項から,本件補正発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって,
プロビジョニング・サーバの受信手段が,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと,
前記受信手段が,様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップと,
前記プロビジョニング・サーバが,前記プロビジョニング要求に応答して,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を,前記様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップと,
ここで前記決定するステップは,
前記プロビジョニング・サーバの判定手段が,コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,プロビジョニング・サーバの判定手段が,前記様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップとを含み,
ここで前記判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み,
前記ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用に前記パケット・テレフォニー装置に送信するステップと
を含む方法。

[相違点1]
“プロビジョニング・サーバの受信手段”に関して,
本件補正発明においては,「プロビジョニング・サーバのクライアント・プロビジョニング・モジュール」であるのに対して,
引用発明においては,「サーバユニット」の「受信部」である点。

[相違点2]
本件補正発明においては,「クライアント・プロビジョニング・モジュールは,更新リスナを有する自動更新サービスモジュールと,更新パッケージハンドラとを含」むものであるのに対して,
引用発明には,「更新リスナ」,「更新パッケージ・ハンドラ」についての言及がない点。

[相違点3]
“プロビジョニング・サーバが・・・提供するかを決定するステップ”に関して,
本件補正発明においては,「クライアント・プロビジョニング・モジュール」が行っているのに対して,
引用発明においては,「サーバユニット」の「判定部」が行っている点。

[相違点4]
“プロビジョニング・サーバの判定手段”に関して,
本件補正発明においては,「クライアント・プロビジョニング・モジュール」であるのに対して,
引用発明においては,「サーバユニット」の「判定部」である点。

[相違点5]
“プロビジョニング・サーバの送信手段”に関して,
本件補正発明においては,「クライアント・プロビジョニング・モジュールから」送信するものであるの対して,
引用発明においては,「サーバユニット」の「送信部」から送信するものである点。

[相違点6]
本件補正発明においては,「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップ」を有するのに対して,
引用発明においては,そのような「ステップ」に関する言及がない点。

[相違点7]
本件補正発明においては,「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと,前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップとを具え,前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成する」ものであるのに対して,
引用発明においては,「リスナ」と「パッケージ・ハンドラ」の処理に相当する点が言及されていない点。

オ.相違点についての当審の判断
(ア)[相違点1],[相違点3]?[相違点5]について
引用発明においては,「サーバユニット」において,「受信部」,「判定部」,「送信部」の別個の構成によって実現しているが,これらの構成を1つに統合した「モジュール」を構成することは,当業者が,適宜なし得る事項である。
よって,[相違点1],[相違点3]?[相違点5]は,格別のものではない。

(イ)[相違点2],[相違点6],及び,[相違点7]について
プロビジョニングにおいて,インストールの結果を受信する点については,上記E,及び,Fにおいて引用した,引用刊行物2の記載にあるとおり,本願の第1国出願前に,当業者には,広く知られた技術事項である。
また,新たなソフトウェア情報を,サーバのデータベースに登録すること,及び,事前に送信用のデータを生成する点についても,上記G,H,及び,Kにおいて引用した,周知文献1,及び,周知文献4の記載にあるとおり,本願の第1国出願前に,当業者には周知の技術である。
ここで,周知文献1においては,送信データのセットアップを,送信時に行っているが,事前に行い得ることは,当業者にとって自明の事項である。
そして,「リスナ」,及び,「ハンドラ」についても,上記I,Jにおいて引用した,周知文献2,及び,周知文献3の記載にもあるとおり,当業者には周知の技術事項であり,「リスナ」と「ハンドラ」間で通信を行う点についても,上記Iに引用する記載中にあるとおり,本願の第1国出願前に,当業者には広く知られた技術事項である。
したがって,引用発明においても,更新に用いる,新たな「最適ソフトウェアデータ」を,「サーバユニット」が受信した場合に,それを「リスナ」が当該受信した「最適ソフトウェアデータ」の種別と,「記憶部」上の格納場所を「ハンドラ」に通知し,該「ハンドラ」が,必要な処理を施してから,「記憶部」に格納するよう構成すること,及び,前記「リスナ」に,「IP電話装置」からの,「インストール結果の通知」を受信する機能を持たせるよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点2],[相違点6],及び,[相違点7]は,格別のものではない。

上記で検討したごとく,[相違点1]?[相違点7]はいずれも格別のものではなく,そして,本件補正発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

よって,本件補正発明は,引用発明,引用刊行物2に記載の発明,及び,周知文献1?周知文献4に記載の技術に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許出願の際独立して特許を受けることができない。

カ.独立特許要件むすび
したがって,本件手続補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

3.補正却下むすび
以上のおいて検討したとおり,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第5項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
仮に,本件手続補正が,目的要件を満たすものであったとしても,
本件手続補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。

第3.本願発明について
平成25年6月10日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成24年11月12付けの手続補正により補正された,上記「第2.平成25年6月10日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1として引用した,次のとおりのものである。

「様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって,
プロビジョニング・サーバのクライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと,
前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置の装置構成情報を受け取るステップと,
ここで,前記装置構成情報は,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報とを含み,
前記クライアント・プロビジョニング・モジュールが,前記プロビジョニング要求に応答して,前記装置構成情報に基づいてソフトウェア更新を前記様々な種類のパケット・テレフォニー装置に提供するかどうかを決定するステップと,
ここで,前記決定するステップは,
前記クライアント・プロビジョニング・モジュールが,前記コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,前記比較結果に基づいて前記ソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,前記クライアント・プロビジョニング・モジュールが,前記様々な種類のパケット・テレフォニー装置が前記ソフトウェア更新を必要とするか否かを判定するステップとを含み,
ここで,前記判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み,
前記ソフトウェア更新パッケージを前記クライアント・プロビジョニング・モジュールからインストール用に前記パケット・テレフォニー装置に送信するステップと
を具えたことを特徴とする方法。」

第4.引用刊行物に記載の発明
原審拒絶理由において引用した,特開2005-026993号公報(2005年1月27日公開)には,上記「第2.平成25年6月10日付けの手続補正の却下の決定」の「2.補正の適否」,「(3)独立特許要件」における「ウ.引用刊行物1に記載の発明」において認定したとおりの,次の引用発明が記載されている。

インターネット網を介して接続されたIP電話装置とサーバユニットによって構成されるIP電話システムにおいて,IP電話装置に,最適ソフトウェアデータを送信するための方法であって,
サーバユニットは,受信部と,判定部と,記憶部と,制御部と,送信部と,から構成され,前記受信部が,IP電話装置からの登録要求メッセージを受信し,前記受信部が,IP電話装置からの登録要求メッセージを受信し,前記記憶部が,加入者管理情報テーブル並びに端末管理情報テーブル及び最適ソフトウェアデータを記憶し,
前記受信部が,IP電話装置から,IP電話装置の各々に固有の識別情報,および,現在搭載しているソフトウェアデータのソフトウェア番号を受信し,
前記判定部が,前記受信部から前記識別情報及びソフトウェア番号を受け取り,前記ソフトウェア番号と端末管理情報テーブルからの最適ソフトウェア番号との比較を行い,比較の結果,前記ソフトウェア番号と最適ソフトウェア番号とが異なる時には,判定部は,ソフトウェアの書き換えが必要だと判断し,
更新が必要である場合には,前記制御部が,前記識別情報及び前記最適ソフトウェア番号を用いて,前記IP電話装置への端末管理情報テーブルにおける最適ソフトウェアデータを読み取り,
IP電話装置にインストールする最適ソフトウェアデータが,サーバユニットを構成する送信部から,前記IP電話装置に送信される,方法。

第5.本願発明と引用発明との対比
本願発明は,上記「第2.平成25年6月10日付けの手続補正の却下の決定」において検討した,本件補正発明から,
「該クライアント・プロビジョニング・モジュールは,更新リスナを有する自動更新サービスモジュールと,更新パッケージハンドラとを含み」という構成と,
「前記クライアント・プロビジョニング・モジュールの前記更新リスナによって,前記ソフトウェア更新パッケージのインストール結果の通知を受け取るステップと,
前記クライアント・プロビジョニング・モジュールの前記更新パッケージ・ハンドラによって,更新ファイルを前記ソフトウェア更新パッケージから抽出しプロビジョニング・データベースに格納するステップとを具え,
前記更新リスナは,新しく到着したソフトウェア更新パッケージとそのプロビジョニング・データベース内の位置とを前記更新パッケージ・ハンドラに通知し,
前記更新パッケージ・ハンドラは,前記パケット・テレフォニー装置の様々なサポートされる前記装置構成情報に従って,前記プロビジョニング・データベース内で更新ファイルを編成する」という構成を削除したものであるから,
本願発明と,引用発明との,一致点,及び,相違点は,

[一致点]
様々な種類のパケット・テレフォニー装置を自動的にプロビジョニングするための方法であって,
プロビジョニング・サーバの受信手段が,前記様々な種類のパケット・テレフォニー装置からプロビジョニング要求を受け取るステップと,
前記受信手段が,様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報を受け取るステップと,
前記プロビジョニング・サーバが,前記プロビジョニング要求に応答して,前記様々な種類のパケット・テレフォニー装置のタイプ識別情報とコンポーネント・バージョン情報に基づいてソフトウェア更新を,前記様々な種類のパケット・テレフォニー装置に提供するかどうか決定するステップと,
ここで前記決定するステップは,
前記プロビジョニング・サーバの判定手段が,コンポーネント・バージョン情報の様々な識別フィールド値を,プロビジョニング・データベースに記憶した対応するフィールド値と比較するステップと,
前記プロビジョニング・データベースが,前記様々な種類のパケット・テレフォニー装置に既にインストールされた1つまたは複数のバージョンのソフトウェア・コンポーネントを伴うソフトウェア更新パッケージを含み,比較結果に基づいてソフトウェア更新パッケージがより新しいバージョンのソフトウェア・コンポーネントを有する場合において,プロビジョニング・サーバの判定手段が,前記様々な種類のパケット・テレフォニー装置がソフトウェア更新を必要とするか否かを判定するステップとを含み,
ここで前記判定するステップは,前記必要としている場合には,当該ソフトウェア更新に対してどのソフトウェア更新パッケージを使用すべきかを判定するステップを含み,
前記ソフトウェア更新パッケージをプロビジョニング・サーバの送信手段からインストール用に前記パケット・テレフォニー装置に送信するステップと
を含む方法。

[相違点a]
“プロビジョニング・サーバの受信手段”に関して,
本願発明においては,「プロビジョニング・サーバのクライアント・プロビジョニング・モジュール」であるのに対して,
引用発明においては,「サーバユニット」の「受信部」である点。

[相違点b]
“プロビジョニング・サーバが・・・提供するかを決定するステップ”に関して,
本願発明においては,「クライアント・プロビジョニング・モジュール」が行っているのに対して,
引用発明においては,「サーバユニット」の「判定部」が行っている点。

[相違点c]
“プロビジョニング・サーバの判定手段”に関して,
本願発明においては,「クライアント・プロビジョニング・モジュール」であるのに対して,
引用発明においては,「サーバユニット」の「判定部」である点。

[相違点d]
“プロビジョニング・サーバの送信手段”に関して,
本願発明においては,「クライアント・プロビジョニング・モジュールから」送信するものであるの対して,
引用発明においては,「サーバユニット」の「送信部」から送信するものである点。

第6.相違点についての当審の判断
本願発明と,引用発明との[相違点a]?[相違点d]は,本件補正発明と,引用発明との[相違点1],[相違点3]?[相違点5]と同じものであるから,上記「第2.平成25年6月10日付けの手続補正の却下の決定」の「2.補正の適否」,「(3)独立特許要件」における「オ.相違点についての当審の判断」において検討したとおりであって,
[相違点a]?[相違点d]は,何れも格別のものではない。
そして,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

第7.むすび
したがって,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2015-06-09 
結審通知日 2015-06-16 
審決日 2015-06-29 
出願番号 特願2010-514960(P2010-514960)
審決分類 P 1 8・ 571- Z (G06F)
P 1 8・ 573- Z (G06F)
P 1 8・ 574- Z (G06F)
P 1 8・ 572- Z (G06F)
P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 坂庭 剛史  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
戸島 弘詩
発明の名称 自動的なソフトウェア・プロビジョニング技法  
代理人 大貫 進介  
代理人 伊東 忠重  
代理人 伊東 忠彦  

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