• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1341609
審判番号 不服2017-227  
総通号数 224 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-08-31 
種別 拒絶査定不服の審決 
審判請求日 2017-01-06 
確定日 2018-07-10 
事件の表示 特願2014-529679「起動パターン管理」拒絶査定不服審判事件〔平成25年 3月14日国際公開、WO2013/036255、平成26年10月 6日国内公表、特表2014-526731、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本件審判請求に係る出願(以下,「本願」という。)は,2011年10月10日(パリ条約による優先権主張外国庁受理2011年9月9日(以下,「優先日」という。),米国)を国際出願日として出願したものであって,その手続の経緯は以下のとおりである。

平成26年 3月 7日 :国内書面の提出
平成26年 4月17日 :翻訳文の提出
平成27年11月30日付け :拒絶理由の通知
平成28年 3月 4日 :意見書,手続補正書の提出
平成28年 8月26日付け :拒絶査定
平成29年 1月 6日 :審判請求書,手続補正書の提出
平成30年 1月22日付け :拒絶理由の通知(当審)
平成30年 4月19日 :意見書,手続補正書の提出

第2 本願発明
本願請求項1-10に係る発明(以下,それぞれ「本願発明1」-「本願発明10」という。)は,平成30年4月19日付けの手続補正で補正された特許請求の範囲の請求項1-10に記載された事項により特定される発明であり,本願発明1は以下のとおりの発明である。

「 【請求項1】
コンピューティングデバイスによって実現される方法であって,
前記コンピューティングデバイスは,起動パターン・マネージャ・モジュール,ネットワーク・デバイス・マネージャ・モジュール,およびキープ・アライブ・マネージャ・モジュール,を含み,
前記起動パターン・マネージャ・モジュールは,
前記コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックをモニタリングするステップと,
前記モニタリングされたネットワークトラフィック内のトラフィックパターンを認識するステップと,
前記認識されたトラフィックパターンに対応する前記コンピューティングデバイスのアプリケーションを識別するステップと,
前記識別するステップに応じて,前記識別されたアプリケーションの少なくとも一部を起動するステップと,を備え,
前記キープ・アライブ・マネージャ・モジュールは,
エンドポイントとサーバタイムアウト間隔,及び/又は,中継デバイスのネットワークタイムアウト間隔に基づいて,キープアライブ間隔を算出し,前記キープアライブ間隔を使用して,前記ネットワーク・インターフェイス・デバイスを起動し,前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持し,
前記ネットワーク・デバイス・マネージャ・モジュールは,
前記ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,
前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる,
ことを特徴とする方法。」

なお,本願発明2-10の概要は以下のとおりである。

本願発明2-4,6-7,10は,本願発明1を直接に引用する。また,本願発明5は本願発明4を引用し,本願発明8は本願発明7を引用し,本願発明9は本願発明8を引用することから,本願発明5,8-9は本願発明1を間接に引用する。
よって,本願発明2-10は,本願発明1を減縮した発明である。

第3 引用文献,引用発明等
1 引用文献1について
原査定の拒絶の理由に引用された引用文献1(米国特許出願公開第2008/0162682号明細書)には,図面とともに次の事項が記載されている。

A 「[0018] An embodiment of the client 110 is illustrated in FIG. 2 . The client 110 may comprise sub-systems such as a processor 210 , a chipset 230 , a memory 240 , a network interface card (NIC) 250 , and I/O devices 290 -A to 290 -N.」
(当審訳: [0018] クライアント110の実施例は図2に示されているクライアント110は,プロセッサー210,チップセット230,メモリ240,ネットワークインターフェースカード(NIC)250と,入出力装置290-A?290-Nのようなサブシステムを含んでいてもよい。)

B 「[0032] In one embodiment, the subsystem such as the network interface card 250 may receive a message from the network device 170 . In one embodiment, the sub-system may determine whether a pattern is found in the message or an incoming packet and may perform an action associated with a pattern if the pattern occurs in the incoming packet. In one embodiment, the network interface card (NIC) 250 may comprise a network interface 251 , a rules unit 252 , and a pattern-action table 253 .」
(当審訳: [0032] 一実施形態では,ネットワーク・インタフェース・カード250のようなサブシステムは,ネットワーク装置170からのメッセージを受信することができる。1つの実施形態において,サブシステムはメッセージまたは受信パケットにパターンが存在するか否かを判断し,前記パターンが前記受信パケットに生じた場合,前記パターンに関連付けられたアクションを実行することができる。一実施形態では,ネットワークインタフェースカード(NIC)250は,ネットワーク・インターフェース251,ルール252,およびパターン・アクション・テーブル253を含むことができる。)

C 「[0035] In one embodiment, the rules unit 252 may receive an incoming packet from the network interface 251 and determine if any pattern, stored in the table 253 , is present in the incoming packet. In one embodiment, the rules unit 252 may perform an action associated with a pattern that is present in the incoming packet. In one embodiment, the action corresponding to a first pattern may indicate that a keep-alive message may be transmitted to the network device 170 . In one embodiment, the keep-alive message transmitted to the network device 170 may be sent by the rules unit 252 on behalf of the higher level layers implemented in the processor 210 .
[0036] In one embodiment, the action corresponding to a second pattern may indicate that a wake-up signal may be sent to the control unit 214 . For example, the second pattern may equal a port number 0808 and the action associated with the pattern 0808 may equal #wake-up the client 110 -A#. In one embodiment, the rules unit 252 may determine the presence of 0808, for example, in a header of the incoming packet. In response to determining the presence of the second pattern 0808, the rules unit 252 may assert an event ASSERT_PME on the bus, which indicates to the control unit 214 that the client 110 -A may be woken up from the low-power mode.
[0037] For example, the pattern 0808 may refer to a port on which an incoming VoIP call may be received and the control unit 214 may wake-up a corresponding application in the collaboration application 211 to receive the VoIP call. In one embodiment, the logic for maintaining the network connectivity during the low-power mode operation of the client 110 -A may be stored as a microcode in the rues unit 252 .」
(当審訳: [0035] 一実施形態において,ルール部252は,ネットワークインタフェース251から受信パケットを受信すると,テーブル253に記憶された任意のパターンが受信パケットに存在するかどうかを決定できる。一実施形態において,ルール部252は,受信パケット内に存在するパターンに関連付けられたアクションを実行することができる。一実施形態では,第1のパターンに対応するアクションは,キープ・アライブ・メッセージがネットワーク装置170に送信されてもよいことを示すことができる。一実施形態では,ネットワーク装置170に送信されたキープアライブメッセージは,プロセッサ210内に実装された上位層に代わって,ルール部252によって送信することができる。
[0036] 一実施形態では,第2のパターンに対応するアクションは,ウェイクアップ信号が制御部214に送信されてもよいことを示すことができる。例えば,第2のパターンは,ポート番号0808に等しいことが可能であり,パターン0808に関連付けられたアクションがクライアント110-Aの起動に等しくてもよい。一実施形態において,ルール部252は,受信パケットのヘッダ内の,例えば,0808の存在を決定することができる。第2のパターン0808の存在を決定することに応答して,ルール部252はバスに,クライアント110-Aが低電力モードからウェイクアップしたことを制御部214に指示する,イベントASSERT_PMEをアサートしてもよい。
[0037] 例えば,パターン0808は,VoIP着信呼が受信されるポートを指すことができ,制御部214は,共同アプリケーション211に対応するアプリケーションを起動し,VoIP呼を受信することができる。一実施形態では,クライアント110-Aの低電力モード動作の間,ネットワークの接続性を維持するためのロジックは,ルール部252のマイクロコードとして格納することができる。)

D 「[0047] In block 380 , the rules unit 252 may perform an action associated with the pattern and control may pass to block 340 . In one embodiment, the rules unit 252 may send a keep-alive message to the network device 170 on behalf of the higher level network layers of the client 110 -A.」
(当審訳: [0047] ブロック380において,ルール部252は,パターンに関連付けられたアクションを実行することができ,制御はブロック340に渡され得る。一実施形態において,ルール部252は,クライアント110-Aの高いレベルのネットワーク層の代わりにネットワークデバイス170にキープアライブメッセージを送信することができる。)

したがって,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「クライアントにおいて,
サブシステムとしてネットワーク・インターフェイス・カードを備え,
前記ネットワーク・インターフェイス・カードは,パケットを受信し,テーブルに事前に格納された所定のパターンが前記パケット中に含まれていると判断された場合,前記パターンに対応するアプリケーションを起動させ,
前記ネットワーク・インターフェイス・カードは,キープアライブメッセージをネットワーク装置に送信する,
ことを特徴とする方法。」

2 引用文献2について
原査定の拒絶の理由に引用された引用文献2(特開2000-235433号公報)の【要約】及び段落【0040】-【0041】の記載からみて,当該引用文献2には,「携帯電話からの着信に基づいてPCがウェイクアップした後にアプリケーションを起動するものであって,前記携帯電話からの入力データをバッファに保持し,前記バッファの保持データからウェイクアップ要因を判断して,複数のアプリケーションのうち,前記ウェイクアップ要因に対応するアプリケーションを起動させる」という技術的事項(以下,「引用文献2記載技術」という。)が記載されていると認められる。

3 引用文献3について
原査定の拒絶の理由に引用された引用文献3(特開2007-158870号公報)の【要約】の記載からみて,当該引用文献3には,「ネットワーク・インターフェイス・カードを仮想化する」という技術的事項(以下,「引用文献3記載技術」という。)が記載されていると認められる。

4 引用文献4について
原査定の拒絶の理由に引用された引用文献4(吉川和成,“iOS 4アプリ“真”手法 第2章 マルチタスクのしくみと実装ポイント”,SoftwareDesign,日本,株式会社技術評論社,2010年12月18日,通巻308号(発刊242号),pp.46-47,ISSN 0916-6297)の第46頁右欄-第47頁左欄の「マルチタスクにおけるライフサイクル」の項及び図1の記載からみて,当該引用文献4には,「フォアグラウンドで実行されていたアプリケーションがバックグラウンドへ遷移することによりサスペンド状態に移行する」という技術的事項(以下,「引用文献4記載技術」という。)が記載されていると認められる。

5 引用文献5-8について
原査定の拒絶の理由に引用された引用文献5(米国特許出願公開第2010/0312899号明細書)の要約,図4,引用文献6(特表2010-520668号公報)の段落【0029】,【0043】,引用文献7(特開2006-164252号公報)の段落【0031】-【0032】,及び引用文献8(特開2006-033026号公報)の段落【0055】には,「キープアライブメッセージの送信間隔をタイムアウト間隔に基づいて算出する」という周知技術が記載されていると認められる。

第4 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。
ア 引用発明の「クライアント」は,ネットワーク接続を実現するコンピュータ装置であるから,本願発明1の「コンピューティングデバイス」に相当する。
また,引用発明では,サブシステムとして「ネットワーク・インターフェイス・カード」を備え,「ネットワーク・インターフェイス・カード」は受信した「パケット」に基づき,「アプリケーションを起動させ」るとともに,「キープアライブメッセージをネットワーク装置に送信する」ことから,引用発明の「ネットワーク・インターフェイス・カード」は本願発明1の「ネットワーク・インターフェイス・デバイス」に相当するといえる。

イ 引用発明では,「ネットワーク・インターフェイス・カードは,パケットを受信し,テーブルに事前に格納された所定のパターンが前記パケット中に含まれていると判断された場合,前記パターンに対応するアプリケーションを起動させ」るところ,ここでの「パケット」,「パターン」は,それぞれ本願発明1の「ネットワークトラフィック」,「トラフィックパターン」に相当することは明らかであるから,引用発明においては,「ネットワーク・インターフェイス・カード」は,「ネットワークトラフィック」をモニタリングし,モニタリングされた「ネットワークトラフィック」内の「トラフィックパターン」を認識するといえる。
また,引用発明では,「前記パターンに対応するアプリケーションを起動させ」ることから,認識された「パターンに対応するアプリケーション」を識別していることは明らかであるから,認識された「トラフィックパターン」に対応するアプリケーションを識別し,識別に応じて,識別されたアプリケーションの少なくとも一部を起動するといえる。そして,引用発明における,識別されたアプリケーションの少なくとも一部を起動する処理は,「クライアント」が“起動パターン管理部”を実質的に備え,“起動パターン管理部”が実行するとみることができる。
一方,本願発明1では,「コンピューティングデバイス」が「起動パターン・マネージャ・モジュール」を含み,「起動パターン・マネージャ・モジュール」が,認識された「トラフィックパターン」に対応するアプリケーションを識別し,識別に応じて,識別されたアプリケーションの少なくとも一部を起動するところ,「起動パターン・マネージャ・モジュール」は「コンピューティングデバイス」の“起動パターン管理部”とみることができる。
そうすると,引用発明と,本願発明1の
「前記起動パターン・マネージャ・モジュールは,
前記コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックをモニタリングするステップと,
前記モニタリングされたネットワークトラフィック内のトラフィックパターンを認識するステップと,
前記認識されたトラフィックパターンに対応する前記コンピューティングデバイスのアプリケーションを識別するステップと,
前記識別するステップに応じて,前記識別されたアプリケーションの少なくとも一部を起動するステップと,を備え」ることとは,後記する点で相違するものの,
“前記コンピューティングデバイスは,起動パターン管理部,を含み,
前記起動パターン管理部は,
前記コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックをモニタリングするステップと,
前記モニタリングされたネットワークトラフィック内のトラフィックパターンを認識するステップと,
前記認識されたトラフィックパターンに対応する前記コンピューティングデバイスのアプリケーションを識別するステップと,
前記識別するステップに応じて,前記識別されたアプリケーションの少なくとも一部を起動するステップと,を備え”る点で共通しているといえる。

ウ 引用発明では,「前記ネットワーク・インターフェイス・カードは,キープアライブメッセージをネットワーク装置に送信する」ところ,「キープアライブメッセージ」を「ネットワーク装置」に送信するのは,「クライアント」とネットワークの間を接続を維持するためであることは明らかであるから,「ネットワーク・インターフェイス・デバイス」により,「コンピューティングデバイス」とネットワークとの間の接続を維持するとみることができる。そして,引用発明における,「ネットワーク・インターフェイス・デバイス」により,「コンピューティングデバイス」とネットワークとの間の接続を維持する処理は,「クライアント」が“キープアライブ管理部”を実質的に備え,“キープアライブ管理部”が実行するとみることができる。
一方,本願発明1では,「コンピューティングデバイス」が「キープ・アライブ・マネージャ・モジュール」を含み,「キープ・アライブ・マネージャ・モジュール」が,「前記ネットワーク・インターフェイス・デバイスを起動し,前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持」するところ,「キープ・アライブ・マネージャ・モジュール」は「コンピューティングデバイス」の“キープアライブ管理部”とみることができる。
そうすると,引用発明と,本願発明1の
「前記キープ・アライブ・マネージャ・モジュールは,
エンドポイントとサーバタイムアウト間隔,及び/又は,中継デバイスのネットワークタイムアウト間隔に基づいて,キープアライブ間隔を算出し,前記キープアライブ間隔を使用して,前記ネットワーク・インターフェイス・デバイスを起動し,前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持」することとは,後記する点で相違するものの,
“前記コンピューティングデバイスは,キープアライブ管理部,を含み,
前記キープアライブ管理部は,
前記ネットワーク・インターフェイス・デバイスにより,前記コンピューティングデバイスとネットワークとの間の接続を維持”する点で共通しているといえる。

エ 引用発明では,「前記ネットワーク・インターフェイス・カードは,キープアライブメッセージをネットワーク装置に送信する」ところ,引用文献1の段落[0015]の記載からすると,引用発明の「ネットワーク装置」は,「クライアント」と無線通信可能であることから,本願発明1の「無線アクセスポイント」に相当するといえる。
そして,引用発明において,「キープアライブメッセージ」を「ネットワーク装置」に送信するのは,「クライアント」と「ネットワーク装置」との間を接続を維持するためであることは明らかであるから,引用発明では,「ネットワーク・インターフェイス・デバイス」に,「無線アクセスポイント」との接続を維持させるとみることができる。そして,引用発明における,「ネットワーク・インターフェイス・デバイス」に,「無線アクセスポイント」との接続を維持させる処理は,「クライアント」が“ネットワークデバイス管理部”を実質的に備え,“ネットワークデバイス管理部”が実行するとみることができる。
一方,本願発明1では,「コンピューティングデバイス」が「ネットワーク・デバイス・マネージャ・モジュール」を含み,「ネットワーク・デバイス・マネージャ・モジュール」が,「前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる」ところ,「ネットワーク・デバイス・マネージャ・モジュール」は「コンピューティングデバイス」の“ネットワークデバイス管理部”とみることができる。
そうすると,引用発明と,本願発明1の
「前記ネットワーク・デバイス・マネージャ・モジュールは,
前記ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,
前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる」こととは,後記する点で相違するものの,
“前記コンピューティングデバイスは,ネットワークデバイス管理部,を含み,
前記ネットワークデバイス管理部は,
前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続を維持させる”点で共通しているといえる。

したがって,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「コンピューティングデバイスによって実現される方法であって,
前記コンピューティングデバイスは,起動パターン管理部,ネットワークデバイス管理部,およびキープアライブ管理部,を含み,
前記起動パターン管理部は,
前記コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックをモニタリングするステップと,
前記モニタリングされたネットワークトラフィック内のトラフィックパターンを認識するステップと,
前記認識されたトラフィックパターンに対応する前記コンピューティングデバイスのアプリケーションを識別するステップと,
前記識別するステップに応じて,前記識別されたアプリケーションの少なくとも一部を起動するステップと,を備え,
前記キープアライブ管理部は,
前記ネットワーク・インターフェイス・デバイスにより,前記コンピューティングデバイスとネットワークとの間の接続を維持し,
前記ネットワークデバイス管理部は,
前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続を維持させる,
ことを特徴とする方法。」

(相違点)
(相違点1)
起動パターン管理部に関し,本願発明1では,「コンピューティングデバイス」が「起動パターン・マネージャ・モジュール」を含み,「起動パターン・マネージャ・モジュール」が「識別されたアプリケーションの少なくとも一部を起動する」のに対して,引用発明では,「クライアント」の「ネットワーク・インターフェイス・カード」が「パターンに対応するアプリケーションを起動させ」るものの,「起動パターン・マネージャ・モジュール」が実行することについて明記されていない点。

(相違点2)
キープアライブ管理部に関し,本願発明1では,「コンピューティングデバイス」が「キープ・アライブ・マネージャ・モジュール」を含み,「キープ・アライブ・マネージャ・モジュール」が「エンドポイントとサーバタイムアウト間隔,及び/又は,中継デバイスのネットワークタイムアウト間隔に基づいて,キープアライブ間隔を算出し,前記キープアライブ間隔を使用して,前記ネットワーク・インターフェイス・デバイスを起動し,前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持」するのに対して,引用発明では,「クライアント」の「ネットワーク・インターフェイス・カード」が「キープアライブメッセージをネットワーク装置に送信する」ものの,「キープ・アライブ・マネージャ・モジュール」が「キープアライブ間隔」を算出し,使用することについて言及されていない点。

(相違点3)
ネットワークデバイス管理部に関し,本願発明1では,「コンピューティングデバイス」が「ネットワーク・デバイス・マネージャ・モジュール」を含み,「ネットワーク・デバイス・マネージャ・モジュール」が「前記ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる」のに対して,引用発明では,「クライアント」の「ネットワーク・インターフェイス・カード」が「キープアライブメッセージをネットワーク装置に送信する」ものの,「ネットワーク・デバイス・マネージャ・モジュール」が「ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理」することについて言及されていない点。

(2)相違点についての判断

ア 相違点3について
事案に鑑みて,上記相違点3を先に検討すると,引用発明では,コンピューティングデバイス(クライアント)のネットワーク・インターフェイス・デバイス(ネットワーク・インターフェイス・カード)は「キープアライブメッセージをネットワーク装置に送信する」ものの,ネットワーク・インターフェイス・デバイスの電力モードを高電力モードまたは低電力モードにより管理するものではないから,ネットワーク・インターフェイス・デバイスが低電力モード時でも,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させることの動機付けも直ちには認められない。
加えて,引用文献5-8に記載されるような「キープアライブメッセージの送信間隔をタイムアウト間隔に基づいて算出する」旨の技術が本願の優先日前に当該技術分野の周知技術であったとしても,ネットワーク・インターフェイス・デバイスが低電力モードである間,当該ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させることが周知技術であったとはいえない。また,そのような構成は引用文献2-4記載技術にも特定されていない。
そうすると,引用発明において,コンピューティングデバイスがネットワーク・デバイス・マネージャ・モジュールを含み,ネットワーク・デバイス・マネージャ・モジュールがネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させること,すなわち,上記相違点3に係る本願発明1の構成とすることは,当業者が適宜なし得たものであるとすることはできない。

イ まとめ
上記相違点1,2について判断するまでもなく,本願発明1は,当業者であっても,引用発明,引用文献2-4記載技術及び引用文献5-8に記載の周知技術に基づいて容易に発明できたものとはいえない。

2 本願発明2-10について
本願発明2-10は,本願発明1を減縮した発明であり,本願発明1の
「前記ネットワーク・デバイス・マネージャ・モジュールは,
前記ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,
前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる,」
と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2-4記載技術及び引用文献5-8に記載の周知技術に基づいて容易に発明できたものとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は,請求項1-10について上記引用文献1-8に記載された発明に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。
しかしながら,平成30年4月19日付け手続補正により補正された請求項1は,
「前記ネットワーク・デバイス・マネージャ・モジュールは,
前記ネットワーク・インターフェイス・デバイスについて,電力モードを高電力モードまたは低電力モードにするように管理し,
前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる,」
という事項を有するものとなっており,上記のとおり,本願発明1-10は,引用発明,引用文献2-4記載技術及び引用文献5-8に記載の周知技術に基づいて,当業者が容易に発明できたものではない。
したがって,原査定を維持することはできない。

第6 当審拒絶理由について
1 特許法第36条第6項第1号について
当審では,請求項1-10の「キープ・アライブ・マネージャ・モジュール」が「キープアライブ間隔」を算出することを特定するにとどまり,リソースの効率的な消費という発明の課題を解決するための手段が反映されていないため,発明の詳細な説明に記載したものではないとの拒絶の理由を通知しているが,平成30年4月19日付けの手続補正により,「キープ・アライブ・マネージャ・モジュール」について,「前記キープアライブ間隔を使用して,前記ネットワーク・インターフェイス・デバイスを起動し,前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持し」と限定事項が追加された結果,この拒絶の理由は解消した。

2 特許法第36条第6項第2号について
当審では,請求項1-10の「前記ネットワーク・インターフェイス・デバイスが前記低電力モードである最中に,無線アクチュエータポイントとの接続およびインターネットプロトコル(IP)アドレスを維持する」が特定する事項が不明確であるとの拒絶の理由を通知しているが,平成30年4月19日付けの手続補正により,「前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間,前記ネットワーク・インターフェイス・デバイスに,無線アクセスポイントとの接続およびインターネットプロトコル(IP)アドレスを維持させる」と補正された結果,この拒絶の理由は解消した。

第7 むすび
以上のとおり,本願発明1-10は,当業者が引用発明,引用文献2-4記載技術及び引用文献5-8に記載の周知技術に基づいて容易に発明をすることができたものではない。したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2018-06-25 
出願番号 特願2014-529679(P2014-529679)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 坂庭 剛史  
特許庁審判長 高木 進
特許庁審判官 山崎 慎一
辻本 泰隆
発明の名称 起動パターン管理  
代理人 伊東 忠重  
代理人 伊東 忠彦  
代理人 大貫 進介  

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