• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1309539
審判番号 不服2014-20047  
総通号数 194 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-02-26 
種別 拒絶査定不服の審決 
審判請求日 2014-10-03 
確定日 2016-01-04 
事件の表示 特願2013-502645「ネットワークリソースをリースすること」拒絶査定不服審判事件〔平成23年 9月29日国際公開、WO2011/119615、平成25年 7月 4日国内公表、特表2013-527951〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本願は、2011年3月22日(パリ優先権主張外国官庁受理2010年3月26日(以下、「優先日」という。)、米国)を国際出願日とする出願であって、それ以降の主な手続は以下のとおりである。

国内書面(提出日) 平成24年 9月26日
審査請求(提出日) 平成24年11月26日
拒絶理由(起案日) 平成25年11月 8日(同年同月19日発送)
意見書(提出日) 平成26年 2月18日
手続補正(提出日) 平成26年 2月18日
拒絶査定(起案日) 平成26年 5月28日(同年6月3日発送)
審判請求(提出日) 平成26年10月 3日
手続補正(提出日) 平成26年10月 3日
前置報告(作成日) 平成26年11月27日
上申書(提出日) 平成27年 2月26日

第2 平成26年10月3日付け手続補正についての補正却下の決定

[補正却下の決定の結論]
平成26年10月3日付け手続補正を却下する。

[理由]
1 本件補正
平成26年10月3日付けの手続補正(以下、「本件補正」という。)により、特許請求の範囲は次のとおり補正された。
[本件補正前]
「【請求項1】
プロセッサと、
前記プロセッサに接続された少なくとも1つのメモリとを備え、前記少なくとも1つのメモリは、プロセッサに、アプリケーションを実行するように構成されたアプリケーションモジュールと、ユーザブローカーモジュールを実施させるための命令を格納し、前記ユーザブローカーモジュールは、
前記アプリケーションモジュールの要求セットを決定し、
前記要求のセットをリースするために支払う通貨を決定する、または少なくとも1つの遠隔局から特定のリソースを提供する通貨に関する情報を受信し、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する前記少なくとも1つの遠隔端末を識別し、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにし、
前記リソースの前記使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払う
ように構成される、装置。
【請求項2】
前記ユーザブローカーモジュールは、前記少なくとも1つの遠隔端末の通知されたリソース容量を受け取り、前記通知されたリソース容量が前記少なくとも1つの遠隔端末の前記要求セットを少なくとも部分的に満足するかどうか決定することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項3】
前記アプリケーションモジュールの前記要求セットは、データ記憶容量の要求量を備える、
請求項1に記載の装置。
【請求項4】
前記アプリケーションモジュールの前記要求セットは、計算帯域幅の要求量を備える、請求項1に記載の装置。
【請求項5】
前記アプリケーションモジュールの前記要求セットは、ネットワークトラフィック帯域幅の要求量を備える、
請求項1に記載の装置。
【請求項6】
前記アプリケーションモジュールの前記要求セットは、前記リソースが使用されうるタイムスケジュールを備える、
請求項1に記載の装置。
【請求項7】
前記アプリケーションモジュールの前記要求セットは、サポートされるターゲットアプリケーション、特定のハードウェアの利用可能性、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを備える、
請求項1に記載の装置。
【請求項8】
前記通貨は、貨幣、前記装置のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、
請求項1に記載の装置。
【請求項9】
少なくとも1つのパラメータを指定する前記サービス合意は、保証されたデータ記憶容量の最小量、計算帯域幅の最小量、ネットワークトラフィック帯域幅の最小量、およびサポートされるオペレーティングシステムから成るグループから選択される、
請求項1に記載の装置。
【請求項10】
前記サービス合意は、前記少なくとも1つの遠隔端末の前記リソースが使用されうるタイムスケジュールを指定する、
請求項1に記載の装置。
【請求項11】
前記装置は、携帯電話を備え、前記アプリケーションは、ウェブブラウザを備え、前記要求セットは、インターネットにアクセスするための最小帯域幅を備える、
請求項1に記載の装置。
【請求項12】
前記アプリケーションは、プロセッサに、計算タスクを処理させるように構成され、前記要求セットは、前記計算タスクの少なくとも一部を処理するための最小計算帯域幅を備える、
請求項1に記載の装置。
【請求項13】
前記装置は、第1のオペレーティングシステム(OS)を実行するための第1のハードウェアを備え、前記要求セットは、第2のOSのためのターゲットアプリケーションを実行することを備え、前記少なくとも1つの遠隔端末は、前記第2のOSを実行するための第2のハードウェアを備え、前記ユーザブローカーモジュールは、前記アプリケーションモジュールが前記第2のハードウェアを使用する前記第2のOS上で前記ターゲットアプリケーションを実行することによって前記少なくとも1つの遠隔端末の前記リソースを使用できるように構成される、
請求項1に記載の装置。
【請求項14】
前記ユーザブローカーモジュールは、ワイヤレス通信リンクを使用して前記少なくとも1つの遠隔端末のリースブローカーモジュールと通信することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項15】
前記ユーザブローカーモジュールは、ワイヤード通信リンクを使用して前記少なくとも1つの遠隔端末のリースブローカーと通信することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項16】
プロセッサと、
前記プロセッサに接続された少なくとも1つのメモリとを備え、前記メモリは、前記プロセッサに、リースブローカーモジュールを実施させるための命令を格納し、前記リースブローカーモジュールは、
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定し、
提供される前記リソースのための通貨を確立し、
前記少なくとも1つの遠隔端末に前記条件を通知し、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決め、
前記少なくとも1つの遠隔端末がリソースを使用できるようにし、
前記リソースの前記使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求する
ように構成される、装置。
【請求項17】
前記リソースは、データ記憶容量を備える、
請求項16に記載の装置。
【請求項18】
前記リソースは、計算帯域幅を備える、
請求項16に記載の装置。
【請求項19】
前記リソースは、ネットワークトラフィック帯域幅を備える、
請求項16に記載の装置。
【請求項20】
前記リソースは、サポートされるターゲットアプリケーション、特定ハードウェアモジュール、サポートされるオペレーティングシステム、から成るグループから選択される、
請求項16に記載の装置。
【請求項21】
前記通貨は、貨幣、前記装置のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、
請求項16に記載の装置。
【請求項22】
前記サービス合意は、保証されたデータ記憶容量の最小量、計算帯域幅の最小量、およびネットワークトラフィック帯域幅の最小量から成るグループから選択される、
請求項16に記載の装置。
【請求項23】
前記サービス合意は、前記リソースが使用されうるタイムスケジュールを指定する、
請求項16に記載の装置。
【請求項24】
前記サービス合意は、サポートされるターゲットアプリケーション、特定のハードウェア、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを指定する、
請求項16に記載の装置。
【請求項25】
前記装置は、携帯電話を備え、前記少なくとも1つの遠隔端末は、携帯電話を備え、前記サービス合意は、インターネットにアクセスするための最小帯域幅を備える、
請求項16に記載の装置。
【請求項26】
前記装置は、第1のオペレーティングシステム(OS)を実行するための第1のハードウェアを備え、前記サービス合意は、前記第1のOSのためのターゲットアプリケーションを実行することを備え、前記リースブローカーモジュールは、前記少なくとも1つの遠隔端末が前記第1のハードウェアを使用する前記第1のOS上で前記ターゲットアプリケーションを実行することによって前記リソースを使用できるように構成される、
請求項16に記載の装置。
【請求項27】
前記リースブローカーモジュールは、ワイヤレス通信リンクを使用して前記少なくとも1つの遠隔端末のユーザブローカーモジュールと通信することによって通知するように構成される、
請求項16に記載の装置。
【請求項28】
前記リースブローカーモジュールは、ワイヤード通信リンクを使用して前記少なくとも1つの遠隔端末のユーザブローカーと通信することによって通知するように構成される、
請求項16に記載の装置。
【請求項29】
前記リソースは、前記装置上でローカルに利用できるリソースである、
請求項16に記載の装置。
【請求項30】
前記リソースは、前記装置から離れて配置される、
請求項16に記載の装置。
【請求項31】
アプリケーションモジュールの要求セットを決定することと、
前記要求のセットをリースするために支払う通貨を決定すること、または少なくとも1つの遠隔局から特定のリソースを提供する通貨に関する情報を受信することと、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別することと、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにすることと、
前記リソースの前記使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払うことと
を備える、方法。
【請求項32】
前記通貨は、貨幣、装置のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、請求項31に記載の方法。
【請求項33】
前記要求セットは、データ記憶容量の要求量、計算帯域幅の要求量、ネットワークトラフィック帯域幅の要求量、前記リソースが使用されうるタイムスケジュール、サポートされるターゲットアプリケーション、特定ハードウェアの利用可能性、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを備える、
請求項31に記載の方法。
【請求項34】
前記少なくとも1つの遠隔端末を識別することは、前記少なくとも1つの遠隔端末のリースブローカーモジュールと通信することを備える、
請求項31に記載の方法。
【請求項35】
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定することと、
提供される前記リソースのための通貨を確立することと、
前記少なくとも1つの遠隔端末に前記条件を通知することと、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決めることと、
前記少なくとも1つの遠隔端末がリソースを使用できるようにすることと、
前記リソースの前記使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求することと
を備える、方法。
【請求項36】
前記通知することは、能力メッセージの要求を受信することに応答して前記少なくとも1つの遠隔端末に前記条件を送ることを備える、
請求項35に記載の方法。
【請求項37】
前記リソースは、データ記憶容量、計算帯域幅、ネットワークトラフィック帯域幅、サポートされるアプリケーション、特定ハードウェアの利用可能性、サポートされるオペレーティングシステム、から成るグループから選択される少なくとも1つのメンバーを備える、
請求項35に記載の方法。
【請求項38】
前記取り決めることは、前記少なくとも1つの遠隔端末上のユーザブローカーモジュールと通信することを備える、
請求項35に記載の方法。
【請求項39】
アプリケーションモジュールの要求セットを決定するための手段と、
前記要求のセットをリースするために支払う通貨を決定するための手段、または少なくとも1つの遠隔局から特定のリソースを提供する通貨に関する情報を受信するための手段と
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別するための手段と、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにするための手段と、
前記リソースの前記使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払うための手段と
を備える、装置。
【請求項40】
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定するための手段と、
提供される前記リソースのための通貨を確立するための手段と、
前記少なくとも1つの遠隔端末に前記条件を通知するための手段と、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決めるための手段と、
前記少なくとも1つの遠隔端末がリソースを使用できるようにするための手段と、
前記リソースの前記使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求するための手段と
を備える、装置。」
(以下、上記引用の請求項各項を「補正前請求項」という)

[本件補正後]
「【請求項1】
プロセッサと、
前記プロセッサに接続された少なくとも1つのメモリとを備え、前記少なくとも1つのメモリは、プロセッサに、アプリケーションを実行するように構成されたアプリケーションモジュールと、ユーザブローカーモジュールを実施させるための命令を格納し、前記ユーザブローカーモジュールは、
前記アプリケーションモジュールの要求セットを決定し、
前記要求のセットをリースするために支払う通貨を決定し、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別し、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにし、
前記リソースの使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払う
ように構成される、装置。
【請求項2】
前記ユーザブローカーモジュールは、前記少なくとも1つの遠隔端末の通知されたリソース容量を受け取り、前記通知されたリソース容量が前記少なくとも1つの遠隔端末の前記要求セットを少なくとも部分的に満足するかどうか決定することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項3】
前記アプリケーションモジュールの前記要求セットは、データ記憶容量の要求量を備える、
請求項1に記載の装置。
【請求項4】
前記アプリケーションモジュールの前記要求セットは、計算帯域幅の要求量を備える、
請求項1に記載の装置。
【請求項5】
前記アプリケーションモジュールの前記要求セットは、ネットワークトラフィック帯域幅の要求量を備える、
請求項1に記載の装置。
【請求項6】
前記アプリケーションモジュールの前記要求セットは、前記リソースが使用されうるタイムスケジュールを備える、
請求項1に記載の装置。
【請求項7】
前記アプリケーションモジュールの前記要求セットは、サポートされるターゲットアプリケーション、特定のハードウェアの利用可能性、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを備える、
請求項1に記載の装置。
【請求項8】
前記通貨は、貨幣、前記装置のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、
請求項1に記載の装置。
【請求項9】
少なくとも1つのパラメータを指定する前記サービス合意は、保証されたデータ記憶容量の最小量、計算帯域幅の最小量、ネットワークトラフィック帯域幅の最小量、およびサポートされるオペレーティングシステムから成るグループから選択される、
請求項1に記載の装置。
【請求項10】
前記サービス合意は、前記少なくとも1つの遠隔端末の前記リソースが使用されうるタイムスケジュールを指定する、
請求項1に記載の装置。
【請求項11】
前記装置は、携帯電話を備え、前記アプリケーションは、ウェブブラウザを備え、前記要求セットは、インターネットにアクセスするための最小帯域幅を備える、
請求項1に記載の装置。
【請求項12】
前記アプリケーションは、プロセッサに、計算タスクを処理させるように構成され、前記要求セットは、前記計算タスクの少なくとも一部を処理するための最小計算帯域幅を備える、
請求項1に記載の装置。
【請求項13】
前記装置は、第1のオペレーティングシステム(OS)を実行するための第1のハードウェアを備え、前記要求セットは、第2のOSのためのターゲットアプリケーションを実行することを備え、前記少なくとも1つの遠隔端末は、前記第2のOSを実行するための第2のハードウェアを備え、前記ユーザブローカーモジュールは、前記アプリケーションモジュールが前記第2のハードウェアを使用する前記第2のOS上で前記ターゲットアプリケーションを実行することによって前記少なくとも1つの遠隔端末の前記リソースを使用できるように構成される、
請求項1に記載の装置。
【請求項14】
前記ユーザブローカーモジュールは、ワイヤレス通信リンクを使用して前記少なくとも1つの遠隔端末のリースブローカーモジュールと通信することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項15】
前記ユーザブローカーモジュールは、ワイヤード通信リンクを使用して前記少なくとも1つの遠隔端末のリースブローカーと通信することによって前記少なくとも1つの遠隔端末を識別するように構成される、
請求項1に記載の装置。
【請求項16】
プロセッサと、
前記プロセッサに接続された少なくとも1つのメモリとを備え、前記メモリは、前記プロセッサに、リースブローカーモジュールを実施させるための命令を格納し、前記リースブローカーモジュールは、
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定し、
提供される前記リソースのための通貨を確立し、
前記少なくとも1つの遠隔端末に前記条件を通知し、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決め、ここで、前記サービス合意を取り決めることは、前記少なくとも1つの遠隔端末と前記サービス合意のための価格を取り決めることを備える、
前記少なくとも1つの遠隔端末がリソースを使用できるようにし、ここで、リソースを使用できるようにすることは、リソースが前記サービス合意を超えるかどうかモニタすることを含む、
前記リソースの使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求する
ように構成され、前記通貨を要求することは、リソース使用量を測定し、サービス合意気に従って支払いを調節することを含む、装置。
【請求項17】
前記リソースは、データ記憶容量を備える、
請求項16に記載の装置。
【請求項18】
前記リソースは、計算帯域幅を備える、
請求項16に記載の装置。
【請求項19】
前記リソースは、ネットワークトラフィック帯域幅を備える、
請求項16に記載の装置。
【請求項20】
前記リソースは、サポートされるターゲットアプリケーション、特定ハードウェアモジュール、サポートされるオペレーティングシステム、から成るグループから選択される、
請求項16に記載の装置。
【請求項21】
前記通貨は、貨幣、前記遠隔端末のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、
請求項16に記載の装置。
【請求項22】
前記サービス合意は、保証されたデータ記憶容量の最小量、計算帯域幅の最小量、およびネットワークトラフィック帯域幅の最小量から成るグループから選択される、
請求項16に記載の装置。
【請求項23】
前記サービス合意は、前記リソースが使用されうるタイムスケジュールを指定する、
請求項16に記載の装置。
【請求項24】
前記サービス合意は、サポートされるターゲットアプリケーション、特定のハードウェア、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを指定する、
請求項16に記載の装置。
【請求項25】
前記装置は、携帯電話を備え、前記少なくとも1つの遠隔端末は、携帯電話を備え、前記サービス合意は、インターネットにアクセスするための最小帯域幅を備える、
請求項16に記載の装置。
【請求項26】
前記装置は、第1のオペレーティングシステム(OS)を実行するための第1のハードウェアを備え、前記サービス合意は、前記第1のOSのためのターゲットアプリケーションを実行することを備え、前記リースブローカーモジュールは、前記少なくとも1つの遠隔端末が前記第1のハードウェアを使用する前記第1のOS上で前記ターゲットアプリケーションを実行することによって前記リソースを使用できるように構成される、
請求項16に記載の装置。
【請求項27】
前記リースブローカーモジュールは、ワイヤレス通信リンクを使用して前記少なくとも1つの遠隔端末のユーザブローカーモジュールと通信することによって通知するように構成される、
請求項16に記載の装置。
【請求項28】
前記リースブローカーモジュールは、ワイヤード通信リンクを使用して前記少なくとも1つの遠隔端末のユーザブローカーと通信することによって通知するように構成される、
請求項16に記載の装置。
【請求項29】
前記リソースは、前記装置上でローカルに利用できるリソースである、
請求項16に記載の装置。
【請求項30】
前記リソースは、前記装置から離れて配置される、
請求項16に記載の装置。
【請求項31】
アプリケーションモジュールの要求セットを決定することと、
前記要求のセットをリースするために支払う通貨を決定することと、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別することと、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにすることと、
前記リソースの使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払うことと
を備える、方法。
【請求項32】
前記通貨は、貨幣、装置のリソースの使用の提供、前記装置のローカル記憶装置容量の一定の提供、または前記サービス合意である、請求項31に記載の方法。
【請求項33】
前記要求セットは、データ記憶容量の要求量、計算帯域幅の要求量、ネットワークトラフィック帯域幅の要求量、前記リソースが使用されうるタイムスケジュール、サポートされるターゲットアプリケーション、特定ハードウェアの利用可能性、およびサポートされるオペレーティングシステムから成るグループから選択される少なくとも1つのパラメータを備える、
請求項31に記載の方法。
【請求項34】
前記少なくとも1つの遠隔端末を識別することは、前記少なくとも1つの遠隔端末のリースブローカーモジュールと通信することを備える、
請求項31に記載の方法。
【請求項35】
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定することと、
提供される前記リソースのための通貨を確立することと、
前記少なくとも1つの遠隔端末に前記条件を通知することと、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決めることと、ここで、前記サービス合意を取り決めることは、前記少なくとも1つの遠隔端末と前記サービス合意のための価格を取り決めることを備える、
前記少なくとも1つの遠隔端末がリソースを使用できるようにすることと、ここで、リソースを使用できるようにすることは、リソースが前記サービス合意を超えるかどうかモニタすることを含む、
前記リソースの使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求することとを備え、前記通貨を要求することは、リソース使用量を測定し、サービス合意気に従って支払いを調節することを含む、方法。
【請求項36】
前記通知することは、能力メッセージの要求を受信することに応答して前記少なくとも1つの遠隔端末に前記条件を送ることを備える、
請求項35に記載の方法。
【請求項37】
前記リソースは、データ記憶容量、計算帯域幅、ネットワークトラフィック帯域幅、サポートされるアプリケーション、特定ハードウェアの利用可能性、サポートされるオペレーティングシステム、から成るグループから選択される少なくとも1つのメンバーを備える、
請求項35に記載の方法。
【請求項38】
前記取り決めることは、前記少なくとも1つの遠隔端末上のユーザブローカーモジュールと通信することを備える、
請求項35に記載の方法。
【請求項39】
アプリケーションモジュールの要求セットを決定するための手段と、
前記要求のセットをリースするために支払う通貨を決定するための手段と
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別するための手段と、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにするための手段と、
前記リソースの使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払うための手段と
を備える、装置。
【請求項40】
リソースが少なくとも1つの遠隔端末によって使用されることができる条件を決定するための手段と、
提供される前記リソースのための通貨を確立するための手段と、
前記少なくとも1つの遠隔端末に前記条件を通知するための手段と、
前記リソースを使用する前記少なくとも1つの遠隔端末とサービス合意を取り決めるための手段と、ここで、前記サービス合意を取り決める手段は、前記少なくとも1つの遠隔端末と前記サービス合意のための価格を取り決めるための手段を備える、
前記少なくとも1つの遠隔端末がリソースを使用できるようにするための手段と、
前記リソースの使用量に応じて前記少なくとも1つの遠隔端末に通貨を要求するための手段とを備え、前記通貨を要求するための手段は、リソース使用量を測定し、サービス合意気に従って支払いを調節するための手段を含む、装置。」
(以下、上記引用の請求項各項を「補正後請求項」という。下線は補正事項を示すものとして出願人が付与したものである。)

2 新規事項追加禁止要件について
(1)補正前請求項16の「前記少なくとも1つの遠隔端末がリソースを使用できるようにし」を補正後請求項16の「前記少なくとも1つの遠隔端末がリソースを使用できるようにし、ここで、リソースを使用できるようにすることは、リソースが前記サービス合意を超えるかどうかモニタすることを含む、」に補正することは、願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)に記載されたものではない。
発明の詳細な説明の段落【0069】には「アービタ820は、(中略)合意済みのサービスレベルが維持されているか否かモニタしうる。」と記載されているものの、「リソースを使用できるようにすること」は「リソースがサービス合意を超えるかどうかをモニタすることを含む」ことについて記載も示唆もされていない。

(2)上記(1)での指摘と同様、補正前請求項35の「前記少なくとも1つの遠隔端末がリソースを使用できるようにすることと、」を補正後請求項35の「前記少なくとも1つの遠隔端末がリソースを使用できるようにすることと、ここで、リソースを使用できるようにすることは、リソースが前記サービス合意を超えるかどうかモニタすることを含む、」に補正することは、願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)に記載されたものではない。

したがって、本件補正は、当初明細書等に記載した事項の範囲内においてしたものではないから、特許法第17条の2第3項の規定に適合しない。

3 むすび
本件補正は、当初明細書等に記載した事項の範囲内においてしたものではないから、特許法第17条の2第3項の規定に違反するので同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

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

第3 本願発明について

1 本願発明

平成26年10月3日付けの手続補正は、上記のとおり却下されたので、本願の請求項に係る発明は、平成26年2月18日付けの手続補正の特許請求の範囲の請求項1?請求項40に記載された事項により特定されるものである。そして、その請求項31に係る発明(以下、「本願発明」という。)は、明細書及び図面の記載からみて、請求項31に記載された事項により特定される、以下のとおりのものである。(再掲する。)

「 アプリケーションモジュールの要求セットを決定することと、
前記要求のセットをリースするために支払う通貨を決定すること、または少なくとも1つの遠隔局から特定のリソースを提供する通貨に関する情報を受信することと、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別することと、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにすることと、
前記リソースの前記使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払うことと
を備える、方法。」

2 引用文献1に記載されている引用発明の認定

(1)引用文献1
原審の拒絶の査定の理由である上記平成25年11月8日付けの拒絶理由通知において引用され、本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能となった文献である特開2005?158068号公報(以下、「引用文献1」という。)には、関連図面とともに、以下の技術的事項が記載されている。(下線は、参考のために当審で付与したものである。)

A 「【0001】 本発明は、アプリケーションを共有する方法に関し、より詳しくは、P2P(Peer-to-Peer)方式を用いてピア(Peer)同士それぞれが搭載しているアプリケーションをライセンス(license)に抵触することなく、他のピアでも使用できるようにし、互いの遊休リソースを効率良く利用できるようにする方法及び装置に関する。」

B 「【0036】 図7は、本発明に係るアプリケーション共有システムのクライアント側の構成を示す図である。クライアントは、ユーザの要求事項によって検索条件を作成し、検索条件に該当するピアのアプリケーションを検索する。また、検索されたピアの中からユーザが選択したピアとネゴシエーションして接続を結び、アプリケーションの円滑な実行のためにセッションを維持する。セッションが開始されると、ユーザは、リモートディスプレイシステムのビューアを介して相手方のピアのアプリケーションを実行できるようにする。
【0037】 クライアント側ピアの構成を具体的に説明すると、最下位にシステムの駆動のためのオペレーティングシステム(OS)750が存在し、その上に本発明に係るP2P方式でコンピュータリソースを共有するためのミドルウェア710が存在する。かつ、前記ミドルウェア710には、前記サーバ側のミドルウェア620と同様に、P2Pプロトコルスタック730と、リモートディスプレイシステム740と、かつ、これらの上位層に本発明においてさらに備えられたアプリケーション共有システムモジュール720が存在する。前記アプリケーション共有システムモジュール720は、複数の下位モジュールを含んでいるが、以下にこれについて説明する。」
【0038】 検索モジュール(searching module)712は、クライアントの動作後、ユーザからGUIモジュール631を介してサービスを受けたいアプリケーションに対する検索条件を受信し、その検索条件を満たすサービスを検索するために検索メッセージを作成し、これを下位P2Pスタックを介して他のピアに転送する役割を担う。
【0039】 接続モジュール(connection module)715は、サーバ側の接続モジュール637と同様に、サーバのサービスの提供を受けるために、サーバとクライアントとの間に所定のプロトコルで通信を行うことができるように接続する役割を担う。
【0040】 ネゴシエーションモジュール(negotiation module)714は、サーバ側のネゴシエーションモジュール636と同様に、データ伝送品質やサービス政策などのように、サービスに関連した事項をサーバと打ち合わせする役割を担う。
【0041】 セッションモジュール(session module)713は、サーバからリモートディスプレイサービスの提供を受けるセッションを維持する役割を担う。1つのセッションには、サーバ側情報、QoSのような品質情報、安全なプロセス終了、該当のサービス政策、ログ情報などが含まれる。セッションモジュール713は、提供するアプリケーションのサービス別にこのようなセッションを維持し、サービスの終了と共にセッションを閉じる。
【0042】 GUIモジュール711は、クライアントユーザが命令を入力できるように、グラフィックインタフェースを提供し、前記サーバユーザから命令を受信する。このように、クライアント側GUIモジュール711は、隣接するノードに対する検索結果及びユーザが要求したサービスに対する検索結果を表示する部分、かつ、ユーザが所望するアプリケーションを検索するためのオプションを入力する部分を含んでいる。これだけでなく、GUIモジュール711は、サーバの状況やネットワークに対する情報を表示する部分を含んでも良い。かつ、GUIモジュール711は、サーバから前記アプリケーションの実行の結果、即ち、リモートディスプレイサービスをリモートディスプレイシステム740を介して伝達され、その結果をクライアントユーザにディスプレイする役割を担う。」

C 「【0043】 図8は、本発明に係る全体の動作を示すフローチャートである。
【0044】 先ず、サーバ機能を有する各ピア10、20、30は、それぞれ共有しようとするアプリケーションを登録する(S810、S811、S812)。この登録過程では、アプリケーションの実行命令のみならず、アプリケーションをサービスするときにサービスの基準となる種々の政策も共に登録する。
【0045】 次に、前記各ピア10、20、30の1つの第2のピア20が隣りにいかなるピアがあるかを確認するために、Pingパケットをブロードキャストすると(S820)、隣接する各ピア10、30は、これに応答するPongパケットを第2のピア20に送信する(S830)。これにより、第2のピア20は、隣りに第1のピア10及び第3のピア30が存在することが分かる。
【0046】 次に、クライアント側(第2のピア)モジュールは、ユーザの要求によって実行される(S840)。ユーザは、他のピアのアプリケーションを使用しようとするとき、サービスを受けたいアプリケーションの検索条件をGUIモジュール711を介して入力する。すると、クライアントの検索モジュール712は、ユーザから入力された検索条件を用いて検索メッセージを構成した上、コミュニティを形成している隣接する各ピア10、30に接続モジュール715を介して検索命令を転送する(S850)。前記検索命令を受信した隣りの各ピア10、30は、自分のディスクリプションファイルを参照し、前記検索条件を満たすと応答し、満たしていないと応答しない。第1のピア10が前記検索条件を満たすアプリケーションを登録していると、第2のピア20にそのアプリケーションに対するディスクリプションファイルを送信し、第2のピア20は、これを受信する(S860)。
【0047】 このときから第2のピア20と第1のピア10との間でアプリケーションサービスを実行するために接続を行う(S870)。本実施の形態においては、応答としてディスクリプションファイルを送信したピアが1つである場合を例に挙げているが、もし、ディスクリプションファイルを送信したピアが複数である場合には、第2のピア20は、前記ディスクリプションファイルに基づいて前記アプリケーションを登録しているピアの中から第2のピア20のユーザが選択したピアと所定のプロトコルで接続する。」
【0048】 前記接続過程を経た後、第2のピア20と第1のピア10との間にサービスに対するネゴシエーションを開始し(S880)、このネゴシエーション過程が終了すると、第1のピア10が第2のピア20にリモートディスプレイサービスを提供するセッションを開始し、アプリケーションを実行する(S890)。」

(2)引用発明の認定
ここで、引用文献1に記載されている事項を検討する。

ア 前記Bの「図7は、本発明に係るアプリケーション共有システムのクライアント側の構成を示す図である。」との記載から、クライアント側には「プロセッサ」と「プロセッサに接続された少なくとも1つのメモリ」を備えられていることは自明であるので、引用文献1には「プロセッサと、前記プロセッサに接続された少なくとも1つのメモリを備え」たアプリケーション共有システムが記載されていると言える。

イ 前記Bの「セッションが開始されると、ユーザは、リモートディスプレイシステムのビューアを介して相手方のアプリケーションを実行できるようにする。」「これらの上位層に本発明においてさらに備えられたアプリケーション共有システムモジュール720が存在する。前記アプリケーション共有システムモジュール720は、複数の下位モジュールを含んでいる」との記載から、「アプリケーションが実行できるように構成されたリモートディスプレイシステム」と「アプリケーション共有システムモジュール」がクライアント側ピアを構成しており、前記ア.の「メモリ」に「プロセッサに実施させるための命令を格納していることが自明であることから、引用文献1には「少なくとも1つのメモリは、プロセッサにアプリケーションが実行できるように構成されたリモートディスプレイシステムとアプリケーション共有システムモジュールを実施させるための命令を格納」するアプリケーション共有システムが記載されていると言える。

ウ 前記Bの「検索モジュール(searching module)712は、クライアントの動作後、ユーザからGUIモジュール631を介してサービスを受けたいアプリケーションに対する検索条件を受信し、その検索条件を満たすサービスを検索するために検索メッセージを作成」との記載から、「検索モジュール」は「アプリケーション共有システムモジュール」に含まれているので、引用文献1には「ユーザがアプリケーションに対する検索条件を決定し、アプリケーション共有システムモジュール(検索モジュール)が検索条件を満たす検索メッセージを決定すること」の方法を含むアプリケーション共有システムが記載されていると言える。

エ 前記C「クライアントの検索モジュール712は、ユーザから入力された検索条件を用いて検索メッセージを構成した上、コミュニティを形成している隣接する各ピア10、30に接続モジュール715を介して検索命令を転送する(S850)。前記検索命令を受信した隣りの各ピア10、30は、自分のディスクリプションファイルを参照し、前記検索条件を満たすと応答し、満たしていないと応答しない。第1のピア10が前記検索条件を満たすアプリケーションを登録していると、第2のピア20にそのアプリケーションに対するディスクリプションファイルを送信し、第2のピア20は、これを受信する(S860)。」と記載されていることから、「ディスクリプションファイルを送信し、これを受信」することで、「検索条件を満たし、応答したサーバを識別」できると言えるので、引用文献1には「アプリケーションに対する検索条件を少なくとも部分的に満足するアプリケーションを有するサーバを識別すること」の方法を含むアプリケーション共有システムが記載されていると言える。

オ 前記B「ネゴシエーションモジュール(negotiation module)714は、(中略)、データ伝送品質やサービス政策などのように、サービスに関連した事項をサーバと打ち合わせする役割を担う。」「 セッションモジュール(session module)713は、サーバからリモートディスプレイサービスの提供を受けるセッションを維持する役割を担う。1つのセッションには、サーバ側情報、QoSのような品質情報、安全なプロセス終了、該当のサービス政策、ログ情報などが含まれる。セッションモジュール713は、提供するアプリケーションのサービス別にこのようなセッションを維持し、サービスの終了と共にセッションを閉じる。」、前記C「前記接続過程を経た後、第2のピア20と第1のピア10との間にサービスに対するネゴシエーションを開始し(S880)、このネゴシエーション過程が終了すると、第1のピア10が第2のピア20にリモートディスプレイサービスを提供するセッションを開始し、アプリケーションを実行する(S890)」との記載から、「伝送品質やサービス政策」などの「サービス合意」を行い、その「サービス合意」に従って「リモートディスプレイシステム」が「サーバ側からアプリケーション」を受け、少なくとも1つの「サーバ側のアプリケーションを使用できる」と言えるので、引用文献1には「リモートディスプレイシステムがサービス合意に従って前記少なくとも1つのサーバ側のアプリケーションを使用できる」ように構成されるアプリケーション共有システムが記載されていると言える。

カ 前記ア乃至オで検討した事項を踏まえると、引用文献1には次の発明(以下、「引用発明」という)が記載されているものと認められる。

「プロセッサと、
前記プロセッサに接続された少なくとも1つのメモリを備え、
少なくとも1つのメモリは、プロセッサにアプリケーションが実行できるように構成されたリモートディスプレイシステムとアプリケーション共有システムモジュールを実施させるための命令を格納し、
ユーザがアプリケーションに対する検索条件を決定することと、
アプリケーションに対する検索条件を少なくとも部分的に満足するアプリケーションを有するサーバを識別すること
リモートディスプレイシステムがサービス合意に従って前記少なくとも1つのサーバ側のアプリケーションを使用できるようにすること
を構える方法を含むアプリケーション共有システム

3 周知慣用技術

引用文献2及び参考文献には以下の技術的事項が記載されている。

(1)引用文献2
原審の拒絶の査定の理由である上記平成25年11月8日付けの拒絶理由通知において引用され、本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能となった文献である特開2002-252624号公報(以下、「引用文献2」という)には、次の事項が記載されている。

D 「【0032】接続サービスの交渉及び選択図4は、接続サービスを提供してもらう為に本発明の一実施例に基づいて実施される交渉ステップを説明するフローチャートである。ステップ404において、第一の無線装置がRF送受信機のレンジ内にある全てのサービスプロバイダへとサービス要求を送信(ブロードキャスト)する。ステップ408においては、単数又は複数のサービスプロバイダが要求を行った装置に対してサービスオファーを返す。サービスオファーは、空き状況、可能な支払い方式、サービスコスト、平均接続速度、保証接続速度、終了通知(例えば終了通知から切断までの時間長)等が含まれるが、これらに限られない情報を指定できる。これと異なる交渉モデルを採用しても良いことは言うまでもない。例えば、最小限の接続パラメータ(例えば接続速度等)しか必要としない場合等はオークションモデル、又はサービス品質モデルを利用することも出来る。
【0033】ステップ414において、第一の無線装置がサービスオファーを評価し、どのサービスオファーがサービス条件を満たしているか(例えばどのオファーが所望の接続速度を満たしているか等)を判定する。更にステップ414では、サービス条件を満たしたサービスオファーが更に評価され、どのオファーが最良の取引条件や価格を提供するものであるか(例えば毎分の接続料金が最も安いのはどのオファーか)を決定する。決定ブロック418においては、「最良の取引条件」が見つけられたかどうかが決定される。「最良の取引条件」とは、例えば空きのあるサービスオファーの中から選ばれた、最も高い接続速度を最も低い料金で提供するサービスオファーのことである。
【0034】「最良の取引条件」が見つかった場合、処理はステップ424へと進み、ここでサービスリクエスタが1つ以上のサービスオファーを選択する。「最良の取引条件」が見つからなかった場合、処理はステップ404へと進み、ここで更なるサービスオファーの要求、受信、評価が実施される(ステップ404、408、414)。
【0035】かわりに各サービスオファーと第一の無線装置のユーザーが事前定義したパラメータとを比較することにより「最良の取引条件」の決定処理を行うことも出来る。例えば、ユーザーが接続料金の最高額を毎分10セントに設定しており、最低額のサービスオファーが毎分15セントであった場合、処理はステップ404へと進んでユーザーの条件を満たすサービスオファーを探す処理が続けられる。」

E 「【0039】課金・支払い処理 本発明の一態様は、接続サービスに対する課金・支払いの為の機構を提供するものである。この課金・支払いシステムを設けることで、本発明により第二の無線装置(例えば移動アクセスポイントとして作動している携帯電話)の所有者は、提供したサービスの分毎の接続料金全額を払ってもらい、更に携帯電話接続サービスに関わるコスト(例えば毎月の携帯電話サービス使用料等)を部分的に負担してもらうことが出来る。課金・支払い処理はステップ504?518及びステップ544に説明されている。ステップ504、508及び514は支払い情報の受信及び検証が行われる課金段階318に含まれるものと見ることが出来る。
【0040】ステップ504において、サービスプロバイダが第一の無線装置に対して支払い情報(例えばクレジットカード番号又はSIM)を要求する。ステップ508においては、第一の無線装置が要求された支払い情報を送信する。ステップ514ではサービスプロバイダが支払い情報を検証する(支払い情報が有効か、口座の信用状態は良好か、その口座が予想接続費用をカバーするに充分な信用供与限度額を持っているか等)。
【0041】決定ブロック518においては、支払い情報が有効であるかどうかが判定される。支払い情報が無効であった場合、処理はステップ504へと進み、要求、送信及び検証ステップが繰り返される。支払い情報が有効であった場合、処理はステップ524へと進み、サービスが開始される。
【0042】ステップ524においてはサービスプロバイダが接続設備を使用して第一の無線装置をリソース(広域ネットワーク又は携帯電話基地局)へと接続する。ステップ528においては課金目的の為にメータが使用量(例えば接続時間)を計測する。
【0043】ステップ534では第一の無線装置及び移動アクセスポイントとして働く第二の無線装置が移動により互いのレンジから外れてしまったかどうかが判定される。先にも触れたように、近距離送受信機のレンジは約15?20フィートである。また、第一及び第二の無線装置はいずれもモバイル装置である為、静止している第二の無線装置のレンジから第一の無線装置が外れることも、静止している第一の無線装置のレンジから第二の無線装置が外れることも、また或いは第一及び第二の無線装置の両方が互いから離れる方向に移動することで双方の送受信機のレンジを外れることもある。第一及び第二の無線装置がレンジから外れた場合、処理はステップ544へと移行し、サービスプロバイダが先に取得した支払い情報及び使用量の計測値を使って第一の無線装置に対して課金が行われる。第一の無線装置及び第二の無線装置が依然互いのレンジ内にある場合、処理はステップ524へと移行して接続サービスの提供が続けられる。
【0044】ステップ538においてはサービスが終了したかどうか、或いは打ち切られたかどうかが判定される。第一の無線装置又は第二の無線装置のいずれかがサービスを終了させることが出来る。例えば、第一の無線装置が新たにそのレンジ内に入って来たより好ましい取引条件を提供する他の無線装置を発見し、現行のサービスを終了することもある。一方、第二の無線装置もそのユーザーが電話を受けたりかけたり、或いは接続時間あたりにより高額の料金を支払う意思のある他の無線装置にサービス提供を切り換えたりする際にサービスを終了することが出来る。第一又は第二の無線装置いずれかによりサービスが終了されると、処理はステップ544へと進む。また、第一及び第二の無線装置のいずれもサービスを終了しなかった場合、処理はステップ524へと進み、接続サービスの提供が続けられる。
【0045】図3に示されているように、発見段階304においてはサービスリクエスタ150が第一の無線装置114のレンジ内に無線サービスプロバイダ(例えば装置124)が存在しているかどうかを判定する。交渉段階308においては、第一の無線装置114及び第二の無線装置124がそれぞれサービスリクエスタ150及びサービスプロバイダ154を使ってサービス条件の交渉を行う。サービス段階304に入ると、サービスプロバイダ154が接続サービスを提供し、メータ等を使って使用量をモニタする。上述したように、接続サービスに対する支払いは課金段階318において処理される。」

(2)参考文献
本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能となった文献である特開2008-27442号公報(以下、「参考文献」という)には、次の事項が記載されている。

F 「【0054】 図5に示す別モデル400では、ユーザ・ノード402とプロバイダ・ノード404は、ネットワーク406を介して、流動資本市場(liquid capital market)408により相互作用してもよい。ユーザ・ノード402は、流動資本市場408にリストアップするためにタスク・リクエスト410を送信してもよい。流動資本市場408は、たとえば、他のユーザ・ノード402やプロバイダ・ノード404からアクセス可能なウェブサイトにて、各タスク・リクエスト410の一覧表示する。各タスク・リクエスト410は、ユーザ・ノード402が、利用可能プロバイダ群に分散させたいタスクについての情報が含まれてもよい。この情報には、上記したさまざまなパラメータが含まれる。タスク・リクエスト410は、ユーザ・ノードの操作者がプロバイダ・ノードのリソース使用に支払う対価を含んでもよい。この対価とは、たとえば、プロバイダ・ノードのリソース使用の代わりに、ノード操作者が譲渡するリソース、あるいは、通貨といった観点から示されてもよい。プロバイダ・ノード404は、流動資本市場408にて一覧表示されているタスク・リクエスト410に入札(bid)412をしてもよい。ユーザ・ノード操作者とプロバイダ・ノード操作者は、オープンかつ競争的な入札処理(せり)により、提供すべきリソースとそれらの対価について合意してもよい。」

4 対比

(1)引用発明における「アプリケーション共有システム」は、前記Aの「本発明は、アプリケーションを共有する方法に関し、互いの遊休リソースを効率良く利用できるようにする方法及び装置に関する。」との記載から、「ネットワーク上のリソース共有のための技術」と言えるので、本願発明の課題である「ネットワークリソース共有のための技術」と共通している。

(2)引用発明における「アプリケーションに対する検索条件」は、本願発明における「アプリケーションモジュールの要求セット」に対応するので、引用発明における「ユーザがアプリケーションに対する検索条件を決定すること」は、本願発明の「アプリケーションモジュールの要求セットを決定すること」に相当する。

(3)引用発明における「アプリケーションに対する検索条件を少なくとも部分的に満足するアプリケーションを有するサーバを識別すること」は、本願発明の「前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別することと」に相当する。

(4)引用発明における「リモートディスプレイシステム」は、本願発明における「アプリケーションモジュール」に対応し、引用発明におけるサーバ側のアプリケーション」は、本願発明における「遠隔端末のリソース」に対応するので、引用発明における「リモートディスプレイシステムがサービス合意に従って前記少なくとも1つのサーバ側のアプリケーションを使用できるようにすること」は、本願発明における「前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにすること」に相当する。

(5)一致点
本願発明は、引用発明と以下の点で一致する。

<一致点>
アプリケーションモジュールの要求セットを決定することと、
前記アプリケーションモジュールの前記要求セットを少なくとも部分的に満足するリソースを有する少なくとも1つの遠隔端末を識別することと、
前記アプリケーションモジュールがサービス合意に従って前記少なくとも1つの遠隔端末の前記リソースを使用できるようにすること
を備える、方法。

(6)相違点
本願発明は、引用発明と以下の点で相違する。

<相違点1>
本願発明ではユーザブローカーモジュールが「要求セットをリースするために支払う通貨を決定」しているのに対して、引用発明ではその点が特定されていない。

<相違点2>
本願発明ではユーザブローカーモジュールが「前記リソースの使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払う」のに対して、引用発明ではその点が特定されていない。

5 当審の判断

(1)相違点1について
前記Dのとおり、引用文献2には「サービス条件を満たしたサービスオファーが更に評価され、どのオファーが最良の取引条件や価格を提供するものであるか(例えば毎分の接続料金が最も安いのはどのオファーか)を決定する。(中略)ユーザーが事前定義したパラメータとを比較することにより「最良の取引条件」の決定処理を行うことも出来る。例えば、ユーザーが接続料金の最高額を毎分10セントに設定しており、最低額のサービスオファーが毎分15セントであった場合、処理はステップ404へと進んでユーザーの条件を満たすサービスオファーを探す処理が続けられる。」と記載されており、所望のリソースをリースするために支払う料金を決定することは周知慣用手段に過ぎない。また、前記Fのとおり、参考文献には「ユーザ・ノードの操作者がプロバイダ・ノードのリソース使用に支払う対価を含んでもよい。この対価とは、たとえば、プロバイダ・ノードのリソース使用の代わりに、ノード操作者が譲渡するリソース、あるいは、通貨といった観点から示されてもよい。」と記載されており、所望のリソース使用するために支払う対価(通貨)を決定することは周知慣用手段に過ぎない。
即ち、要求のセットをリースするために支払う通貨(料金、対価)を決定することは、周知慣用技術に過ぎず、これを引用発明に用いることは当業者が適宜なし得ることである。

(2)相違点2について
前記Eのとおり、引用文献2には「サービス段階304に入ると、サービスプロバイダ154が接続サービスを提供し、メータ等を使って使用量をモニタする。上述したように、接続サービスに対する支払いは課金段階318において処理される。」と記載されており、リソースを使用量に対して支払うべき料金を支払うことは周知慣用技術に過ぎず、引用発明において「前記リソースの使用量に対して支払うべき通貨を前記少なくとも1つの遠隔端末に支払う」ようにすることは、当業者が容易に想到しうることである。

したがって、本願発明の構成は当業者が引用発明、引用文献2及び参考文献にみられる周知慣用技術から容易に想到しうるものである。

そして、本願発明の構成により奏する効果も、引用文献1に記載された事項、引用文献2及び参考文献にみられる周知慣用技術から当然予測される範囲内のもので、格別顕著なものとは認められない。

(3)小括
本願発明(特許請求の範囲の請求項31に記載されている事項により特定される発明)は、特許法第29条第2項の規定により特許を受けることができないものである。

(4)付記
仮に、平成26年10月3日付けの手続補正が適法であったとしても、補正後請求項31に係る発明は、補正前請求項31に係る発明と実質的に同一であるため、前述と同じ理由により、特許法第29条第2項の規定により特許を受けることができないものである。

6 平成27年2月26日付けの上申書について
請求人は、平成27年2月26日付けの上申書において、「上記上申をもってしても審判で特許できない旨の心証であれば下記、補正案のように補正し,下記のように意見する用意があります。」と主張している。
当該上申書において提示された請求項1に係る補正案(以下、「上申補正案」という。)を検討する。

(1)新規事項追加禁止要件について
上申補正案において、「前記取って置いた資金を前記少なくとも1つの遠隔端末に告知することと、前記告知することは、前記少なくとも1つの遠隔端末が前記ユーザブローカーモジュールによって前記取って置かれた資金が正しいか確認することを含む」との記載を追加している。明細書の段落【0057】「リースブローカー212は、ユーザブローカー222によって支払うための取って置かれた資金が正しいか確認しうる。」との記載があるものの、「ユーザブローカー」が「取って置かれた資金が正しいか確認すること」と解することができない。そうすると、上申補正案は、外国語の翻訳文に記載した事項の範囲内においてなされたものでないので、特許法第17条の2第3項に適合していない。

(2)目的要件について
上申補正案において、「前記少なくとも1つの遠隔端末と支払合意を確立するように構成され、前記支払い合意を確立することは」と追記しているが、これは「支払合意を確立」という新たな構成要素を追加するものであり、「ユーザブローカーモジュール」を限定的に減縮しているものではない。
また、特許法第17条の2第5項に規定する請求項の削除、誤記の訂正、或いは、明瞭でない記載の釈明の何れも目的としたものでないので、上申補正案は、特許法第17条の2第5項各号に掲げる事項を目的とするものに限られるものではない。

(3)進歩性について
上申補正案の「支払い合意を確立すること」として、「支払いのための資金を取って置くこと」「取って置いた資金が正しいか確認すること」「取って置いて資金が正しいと確認された場合」に「サービスを提供(リソースを使用)できるようにすること」は、信用状態を確認して行う取引において、例示するまでもなく、当該技術分野の常套手段であり、当業者が適宜なし得ることである。即ち、上申補正案に記載されている事項により特定される発明は、特許法第29条2項の規定により特許を受けることができない。

上記(1)乃至(3)に示すとおり、上申補正案は、特許法第17条の2第3項及び第5項に適合しておらず、仮に当該補正案どおり補正がなされたとしても、これは、同法同条第6項にも適合していないので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものとなる。よって、さらなる補正の機会を設ける事に益はない。

7 むすび

以上のとおりであるから、本願発明は、特許法第29条第2項の規定により特許を受けることができないものであり、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-07-30 
結審通知日 2015-08-04 
審決日 2015-08-18 
出願番号 特願2013-502645(P2013-502645)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 大塚 俊範杉浦 孝光  
特許庁審判長 辻本 泰隆
特許庁審判官 戸島 弘詩
高木 進
発明の名称 ネットワークリソースをリースすること  
代理人 井上 正  
代理人 砂川 克  
代理人 岡田 貴志  
代理人 峰 隆司  
代理人 蔵田 昌俊  
代理人 福原 淑弘  
代理人 井関 守三  
代理人 野河 信久  
代理人 佐藤 立志  
代理人 河野 直樹  
代理人 堀内 美保子  

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