• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1345591
審判番号 不服2017-12761  
総通号数 228 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-12-28 
種別 拒絶査定不服の審決 
審判請求日 2017-08-29 
確定日 2018-11-21 
事件の表示 特願2016-541816「データをバックアップするための方法および装置並びに電子装置」拒絶査定不服審判事件〔平成28年 2月18日国際公開,WO2016/023362,平成28年12月 1日国内公表,特表2016-537743,請求項の数(10)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1.手続の経緯
本願は,2015年3月19日(パリ条約による優先権主張外国庁受理2014年8月15日 中華人民共和国)を国際出願日とする出願であって,
平成27年12月2日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,同日付けで審査請求がなされると共に手続補正がなされ,平成29年1月26日付けで審査官により拒絶理由が通知され,これに対して平成29年4月25日付けで意見書が提出されたが,平成29年5月9日付けで審査官により拒絶査定がなされ(謄本送達;平成29年5月11日),これに対して平成29年8月29日付けで審判請求がなされると共に手続補正がなされ,平成29年9月14日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成29年10月27日付けで上申書が提出され,平成30年6月12日付けで当審により拒絶理由が通知され,これに対して平成30年9月11日付けで意見書が提出されると共に手続補正がなされたものである。

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

「データをバックアップするための方法であって,
端末が,ルータによって形成されるローカルネットワークに加わることをトリガーとして,所定のタイプの新たなファイルが前記端末に存在するかどうかを決定するステップと,
前記端末が前記所定のタイプの前記新たなファイルが存在する場合に所定のアルゴリズムにしたがって前記新たなファイルに対応するチェック値を計算するステップと,
前記端末が接続されるルータへ前記チェック値を含む問い合わせ要求を送って,前記チェック値を有するファイルが前記ルータに記憶されているかどうかを問い合わせるステップと,
前記端末が前記ルータから戻される問い合わせ結果にしたがって前記チェック値を有するファイルが前記ルータに記憶されていないと決定する場合には,前記新たなファイルを前記ルータにバックアップするステップと,
を備え,
接続されるルータへ前記チェック値を含む問い合わせ要求を送る前記ステップは,
既に登録されたアカウント情報にしたがって前記ルータにログインする場合にログインアカウントを介して前記問い合わせ要求を前記ルータへ送るステップを備え,それにより,前記ルータは,前記チェック値を有するファイルが,前記ログインアカウントがアクセス可能なバックアップデータとして記憶されているかどうかを問い合わせる方法。」

2.本願発明2?本願発明10について
本願発明2?本願発明10の概略は以下のとおりである。
本願発明2?本願発明4は,本願発明1に限定事項を付加したものである。
本願発明5は,本願発明1に対応する装置発明であって,本願発明1とカテゴリが異なるものである。
本願発明6?本願発明8は,本願発明5に限定事項を付加したものである。
本願発明9は,本願発明1?本願発明4の方法発明の何れかをコンピュータに実行させるためのプログラム発明であり,本願発明10は,本願発明9におけるプログラムを記録する記録媒体の発明である。

第3.引用文献に記載の事項及び引用文献に記載の発明
1.引用文献1について
原査定の拒絶の理由に引用された引用文献1(特開2012-079044号公報<2012年4月19日公開>)には,図面とともに次の事項が記載されている。

A.「【0202】
(領域毎のファイル更新/ファイル・FI処理部/ストレージサーバ)
次に,図14を参照してストレージサーバ3におけるファイル・FI処理部322の処理について説明する。図34は,ストレージサーバ3のファイル・FI処理部322による領域毎にファイル更新を行う場合の処理を示すフローチャートである。
【0203】
図33は,ストレージサーバ3の記憶部33に格納された領域データファイルの構成を示す図である。図33に示すように,領域データファイルは,ファイルを特定するためのユニークID毎に構成され,領域番号毎のハッシュ値及び領域データからなる。記憶部33には,ユニークIDaのファイルについて,領域番号毎のハッシュ値c(1),・・・,c(5)及び領域データが格納されているものとする。
【0204】
ストレージサーバ3における同期制御部32の操作種別特定部321により,端末装置1-2から受信したファイル操作通知に基づいて操作種別が「ファイル更新」に特定されると(ステップS3401:Y),ファイル・FI処理部322は,ファイル操作通知に含まれる属性群のハッシュ値と,ストレージサーバ3の記憶部33に格納されたユニークIDが同じFIのハッシュ値とを比較し,異なるハッシュ値c1(3)を選出して領域番号3を特定する(ステップS3402)。
【0205】
ファイル・FI処理部322は,領域番号3を含む領域データ送信指令を生成し,通信部31に出力する。この領域データ送信指令は,APIサーバ2を介して,ファイル操作通知を送信してきた端末装置1-2へ送信される(ステップS3403)。これにより,端末装置1-2は,前述のとおり,記憶部13の領域データファイルから,領域データ送信指令に含まれる領域番号3のハッシュ値c1(3)及び領域データを読み出し,領域番号3,ハッシュ値c1(3)及び領域データを含む領域データ応答をストレージサーバ3へ送信する。
【0206】
ファイル・FI処理部322は,端末装置1-2から受信した領域データ応答を通信部31から入力し(ステップS3404),記憶部33の領域データファイルに,領域データ応答に含まれる領域番号3に対応して,領域データファイルに含まれるハッシュ値c1(3)及び領域データを格納する(ステップS3405)。
【0207】
ファイル・FI処理部322は,ファイル操作通知に含まれる属性群のハッシュ値のうち,ストレージサーバ3の記憶部33に格納されたユニークIDが同じFIに含まれる同じハッシュ値c(1),c(2),c(4),c(5)について,領域番号1,2,4,5を特定し,記憶部33の領域データファイルから,領域番号1,2,4,5の領域データを読み出す(ステップS3406)。
【0208】
ファイル・FI処理部322は,受信した領域データ応答に含まれる領域番号3の領域データと,ステップS3406において読み出した領域番号1,2,4,5の領域データとを統合し(ステップS3407),元のファイルを記憶部33から削除し,統合したファイルを記憶部33に格納する(ステップS3408)。このステップS3408の処理は,図30に示したステップS3006の処理に相当する。そして,ファイル・FI処理部322は,Eタグd2等を付与してFIを生成する等の処理を行う(ステップS3409)。このステップS3409の処理は,図30に示したステップS3007及びステップS3008の処理に相当する。
【0209】
以上のように,端末装置1におけるファイル処理部12のファイル操作部121及び属性処理部122,並びにストレージサーバ3における同期制御部32のファイル・FI処理部322によれば,ファイルを所定サイズに分割した領域毎のハッシュ値及び領域データを含む領域データファイルを格納し,属性群及びFIに含まれるハッシュ値を領域毎のハッシュ値として扱うようにした。そして,端末装置1におけるファイル処理部12のファイル操作部121は,ストレージサーバ3から受信した領域データ送信指令に含まれる領域番号に従って,更新された領域データのみをストレージサーバ3へ送信するようにした。これにより,ファイルを構成する全データを送信する必要がないから,送信データ量を低減することができ,送信処理速度の向上を図ることができる。また,通信が中断した後再開した場合,ファイルを構成する全データを送信する必要がなく,更新された領域の領域データのみを送信すれば済むから,処理の効率化を図ることができる。」

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

「ストレージサーバ3のファイル・FI処理部322による領域毎にファイル更新を行う方法であって,
前記ストレージサーバ3の記憶部33に格納された領域データファイルは,ファイルを特定するためのユニークID毎に構成され,領域番号毎のハッシュ値及び領域データからなり,
前記記憶部33には,ユニークIDaのファイルについて,前記領域番号毎のハッシュ値c(1),・・・,c(5)及び前記領域データが格納され,
端末装置1-2は,前記ストレージサーバ3に,ファイル操作通知を送信し,
前記ストレージサーバ3は,前記端末装置1-2から受信した前記ファイル操作通知に基づいて操作種別が「ファイル更新」に特定されると,前記ファイル操作通知に含まれる属性群のハッシュ値と,前記ストレージサーバ3の前記記憶部33に格納されたユニークIDが同じFIのハッシュ値とを比較し,異なるハッシュ値を選出して領域番号を特定し,特定された前記領域番号を含む領域データ送信指令を生成し,前記領域データ送信指令を,前記端末装置1-2に送信し,
前記端末装置1-2は,自身の記憶部13の領域データファイルから,前記領域データ送信指令に含まれる前記領域番号のハッシュ値及び領域データを読み出し,前記領域番号,前記ハッシュ値及前記び領域データを含む領域データ応答を前記ストレージサーバ3へ送信し,
前記ストレージサーバ3は,前記記憶部33の領域データファイルに,受信した前記領域データ応答に含まれる前記領域番号に対応して,前記領域データファイルに含まれる前記ハッシュ値及び前記領域データを格納し,
前記ファイル操作通知に含まれる属性群のハッシュ値のうち,ストレージサーバ3の記憶部33に格納されたユニークIDが同じFIに含まれる同じハッシュ値について,領域番号を特定し,前記記憶部33の領域データファイルから、前記領域番号の領域データを読み出し,
受信した前記領域データ応答に含まれる前記領域番号の前記領域データと,前記記憶部33読み出した領域データとを統合し,元のファイルを前記記憶部33から削除し,統合したファイルを前記記憶部33に格納する,方法。」

2.引用文献2について
原査定の拒絶の理由に引用された引用文献2(特開2013-061883号公報<2013年4月4日公開>)には,図面とともに次の事項が記載されている。

B.「【0051】
バックアップの開始指示に応じ,バックアップリストアサーバ10のバックアップ制御部11は,バックアップ対象として指定された対象サーバ30に対して,一つの単位データのハッシュ値の送信を要求する(S111)。当該要求に応じ,対象サーバ30は,未転送の単位データのうちの一つ(以下,「対象データ」という。)のハッシュ値と,対象データの位置情報とをバックアップリストアサーバ10に返信する(S112)。
【0052】
続いて,バックアップ制御部11は,当該ハッシュ値に対応する単位データの存在確認要求をイメージ管理サーバ20に送信する(S113)。当該要求に応じ,イメージ管理サーバ20のバックアップ部21は,バックアップイメージ記憶部23において,haｓh属性の値として当該ハッシュ値が記録されている単位データ管理ファイルの有無を確認する。すなわち,対象データと同一の単位データが,既存のバックアップイメージ内に存在するか否かが判定される。バックアップ部21は,該判定結果をバックアップリストアサーバ10に返信する(S114)。
【0053】
イメージ管理サーバ20からの判定結果が,当該ハッシュ値に対応する単位データが存在しないことを示す場合,バックアップリストアサーバ10のバックアップ制御部11は,対象サーバ30に対して,対象データに関して,イメージ管理サーバ20への送信を要求する(S115)。当該要求には,当該ハッシュ値と,バックアップの開始指示において指定された,バックアップイメージのイメージ名とが指定される。
【0054】
対象サーバ30は,当該要求に応じ,対象データ及びその位置情報と,イメージ名とをイメージ管理サーバ20に送信する(S116)。イメージ管理サーバ20のバックアップ部21は,イメージ名,対象データ(の実体),ハッシュ値,及び位置情報等を含む単位データ管理ファイルを生成し,当該単位データ管理ファイルをバックアップイメージ記憶部23に記憶(保存)する。続いて,バックアップ部21は,単位データの保存が完了した旨をバックアップリストアサーバ10に送信する(S117)。
【0055】
一方,イメージ管理サーバ20からの判定結果が,当該ハッシュ値に対応する単位データが存在することを示す場合,バックアップリストアサーバ10のバックアップ制御部11は,イメージ名,対象データのハッシュ値,及び位置情報を指定して,単位データ管理ファイルの更新要求をイメージ管理サーバ20に送信する(S118)。当該要求に応じ,イメージ管理サーバ20のバックアップ部21は,当該ハッシュ値と一致するハッシュ値がhaｓh属性の値として記録されている単位データ管理ファイルを更新する。具体的には,当該単位データ管理ファイルに,指定されたイメージ名を含むimage_infｏ属性が無い場合,当該イメージ名を含むimage_infｏ属性が追加される。当該image_infｏ属性のイメージ内重複度には1が記録され,データ位置には受信された位置情報が記録される。一方,当該単位データ管理ファイルに,指定されたイメージ名を含むimage_infｏ属性が有る場合,当該image_infｏ属性が更新対象とされる。すなわち,当該image_infｏ属性のイメージ内重複度には1が加算され,データ位置には受信された位置情報が追加される。
【0056】
続いて,バックアップ部21は,単位データ管理ファイルの更新が完了した旨をバックアップリストアサーバ10に返信する(S119)。」

3.引用文献3について
原査定の拒絶の理由に引用された引用文献3(米国特許第8370532号明細書<2013年2月5日公開>)には,図面とともに次の事項が記載されている。

C.「An archive process of computer 120 may generate one or more hash values or checksums to indicate data that has been archived. According to some embodiments, an archive process of computer 120 may use a hash value or a checksum to determine whether the data has changed since a prior archive. If a hash value or checksum has not changed, data may not be archived.」(第6欄第22行-同欄第27行)
(コンピュータ120のアーカイブ・プロセスは,データが,既にアーカイブされていることを示すための1以上のハッシュ値,或いは,チェックサムを生成し得る。もし,ハッシュ値,或いは,チェックサムが変化しなければ,データは,アーカイブされていないであろう。<当審にて訳出。以下,同じ。>)

D.「According to some embodiments, a hash value or checksum may be used to determine whether a portion of data has previously been archived. If the data has previously been archived, archival of the data may be skipped.」(第7欄第63行-同欄第67行)
(ある実施例よれば,ハッシュ値,或いは,チェックサムは,データの一部が,既にアーカイブされているかどうかを決定するために用いられ得る。もし,そのデータが,既にアーカイブされていれば,データのアーカイブ化は,スキップされる。)

E.「At block 312, data may be archived. Archival of data may be performed in accordance with specified archive parameters. According to some embodiments, an archive process, agent, or module may use a checksum, a hash value, or another indicator to determine whether or not data should be archived. A hash value may be generated to compare against a prior hash value to determine whether data has changed since a last archival. If data has not previously been archived or if data has changed, the data may be archived.」(第8欄第56行-同欄第64行)
(ブロック312において,データがアーカイブされるであろう。データのアーカイブ化は,特定のアーカイブ・パラメータに従って,実行され得る。ある実施例によれば,アーカイブ・プロセス,エージェント,或いは,モジュールは,データが,アーカイブされたどうかを決定するために,チェックサム,ハッシュ値,或いは,他の標識を使用し得る。ハッシュ値は,最後のハッシュ化から変化したかどうかを決定するために,以前のハッシュ値に対して比較するため,生成され得る。もし,データが,以前にアーカイブされていないか,或いは,データが変化していれば,そのデータは,アーカイブされるであろう。)

第4.本願発明と引用発明との対比及び相違点についての判断
1.本願発明1について
(1)対比
ア.引用発明における「端末装置1-2」は,「ストレージサーバ3」に対して「ファイル操作通知」を送信するものであって,当該「ファイル操作通知」は,「ストレージサーバ3」に対して,「ファイル更新」を依頼する要求であって,当該「ファイル操作通知」は,「領域データ」の「ハッシュ値」を含み,
引用発明における前記「領域データ」,「ハッシュ値」が,本願発明1における「新たなファイル」,「チェック値」に相当し,
引用発明における「端末装置1-2」,「ストレージサーバ3」と,
本願発明1における「端末」,「ルータ」とは,
“依頼端末”,“データ格納部”である点で共通し,
引用発明は,「ファイル更新を行う方法」であって,「ストレージサーバ3」に「領域データ」を送信する方法であるから,
引用発明における「ストレージサーバ3のファイル・FI処理部322による領域毎にファイル更新を行う方法」と,
本願発明1における「データをバックアップするための方法」とは,
“データを格納するための方法”である点で共通する。

イ.引用発明において,当該「ハッシュ値」は,「端末装置1-2」において計算されるものであるから,
引用発明において,「端末装置1-2」において「ハッシュ値」を計算することと,
本願発明1における「端末が前記所定のタイプの前記新たなファイルが存在する場合に所定のアルゴリズムにしたがって前記新たなファイルに対応するチェック値を計算するステップ」とは,
“依頼端末が所定のアルゴリズムにしたがって新たなファイルに対応するチェック値を計算するステップ”である点で共通し,
引用発明における「端末装置1-2は,前記ストレージサーバ3に,ファイル操作通知を送信し」と,
本願発明1における「端末が接続されるルータへ前記チェック値を含む問い合わせ要求を送って,前記チェック値を有するファイルが前記ルータに記憶されているかどうかを問い合わせるステップ」とは,
“依頼端末が接続されるデータ格納部へチェック値を含む問い合わせ要求を送るステップ”である点で共通する。

ウ.引用発明において,「ストレージサーバ3は,前記端末装置1-2から受信した前記ファイル操作通知に基づいて操作種別が「ファイル更新」に特定されると,前記ファイル操作通知に含まれる属性群のハッシュ値と,前記ストレージサーバ3の前記記憶部33に格納されたユニークIDが同じFIのハッシュ値とを比較し,異なるハッシュ値を選出して領域番号を特定し,特定された前記領域番号を含む領域データ送信指令を生成し,前記領域データ送信指令を,前記端末装置1-2に送信」することは,「端末装置1-2」から送信された「ファイル操作通知」に対する応答であるから,
本願発明1における「端末が前記ルータから戻される問い合わせ結果」とは,
“依頼端末が,データ格納部から戻される問い合わせ結果”である点で共通する。

エ.引用発明において,「端末装置1-2は,自身の記憶部13の領域データファイルから,前記領域データ送信指令に含まれる前記領域番号のハッシュ値及び領域データを読み出し,前記領域番号,前記ハッシュ値及前記び領域データを含む領域データ応答を前記ストレージサーバ3へ送信」することと,
本願発明1における「チェック値を有するファイルが前記ルータに記憶されていないと決定する場合には,前記新たなファイルを前記ルータにバックアップするステップ」とは,
“新たなファイルをデータ格納部に送信するステップ”である点で共通する。

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

[一致点]
データを格納するための方法であって,
依頼端末が所定のアルゴリズムにしたがって新たなファイルに対応するチェック値を計算するステップと,
前記依頼端末が接続されるデータ格納部へ前記チェック値を含む問い合わせ要求を送るステップと,
前記依頼端末が,前記データ格納部から戻される問い合わせ結果に応じて,前記新たなファイルを前記データ格納部に送信するステップと,
を備える方法。

[相違点1]
“データを格納するための方法”に関して,
本願発明1は,「データをバックアップするための方法」であるのに対して,
引用発明は「ファイルの更新を行う方法」であって,「バックアップ」をしているか不明である点。

[相違点2]
本願発明1においては,「端末が,ルータによって形成されるローカルネットワークに加わることをトリガーとして,所定のタイプの新たなファイルが前記端末に存在するかどうかを決定するステップ」が存在しているのに対して,
引用発明には,そのようなステップが存在していない点。

[相違点3]
“依頼端末が所定のアルゴリズムにしたがって新たなファイルに対応するチェック値を計算する”ことに関して,
本願発明1においては,「端末が前記所定のタイプの前記新たなファイルが存在する場合に」,「チャック値を計算」しているのに対して,
引用発明においては,「端末装置1-2」が,どのようなタイミングで「ハッシュ値」を計算しているのか不明である点。

[相違点4]
“問い合わせ要求を送るステップ”に関して,
本願発明1においては,「端末が接続されるルータへ前記チェック値を含む問い合わせ要求を送って,前記チェック値を有するファイルが前記ルータに記憶されているかどうかを問い合わせる」要求であるのに対して,
引用発明においては,「ファイル更新」を要求するものである点。

[相違点5]
“データ格納部”に関して,
本願発明1においては,「ルータ」であるのに対して,
引用発明においては,「ストレージサーバ」である点。

[相違点6]
“新たなファイルをデータ格納部に送信する”ことに関して,
本願発明1においては,「新たなファイル」を「バックアップする」ものとして送信しているのに対して,
引用発明においては,「領域データ」ば,「更新」のために送信されている点。

[相違点7]
本願発明1には,「接続されるルータへ前記チェック値を含む問い合わせ要求を送る前記ステップは,
既に登録されたアカウント情報にしたがって前記ルータにログインする場合にログインアカウントを介して前記問い合わせ要求を前記ルータへ送るステップを備え,それにより,前記ルータは,前記チェック値を有するファイルが,前記ログインアカウントがアクセス可能なバックアップデータとして記憶されているかどうかを問い合わせる」ものであるのに対して,
引用発明は,そのような構成について,特に言及されていない点。

(2)相違点についての当審の判断
上記[相違点2]について検討すると,当該[相違点2]に係る構成は,上記[第3.引用文献に記載の事項及び引用文献に記載の発明]において言及した,引用文献2,及び,引用文献3の何れにも記載されておらず,また,当該[相違点2]に係る構成を,引用発明に加えることが,当業者にとって周知の技術事項とはいえない。
したがって,上記他の相違点について判断するまでもなく,本願発明1は,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2?本願発明5について
本願の請求項2?本願の請求項5は,本願の請求項1を直接・間接に引用するものであるから,本願発明2?本願発明5も,上記において検討の[相違点2]に係る構成を有するものである。
したがって,本願発明1と同じ理由により,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.本願発明6?本願発明10について
本願発明6は,本願発明1とカテゴリが相違するものの,ほぼ同等の構成を有する発明であるから,上記において検討した[相違点2]に係る構成を有し,本願の請求項7?本願の請求項10は,本願の請求項6を直接・間接に引用するものであるから,本願発明7?本願発明10も,当該[相違点2]に係る構成を有している。
したがって,本願発明1と同じ理由により,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は,請求項1?請求項12について上記引用文献1?引用文献2に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができないというものである。しかしながら,平成29年8月29日付け手続補正により補正された請求項1?請求項10は,上記「第4.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」おける「(2)相違点についての当審の判断」において検討した,「相違点2」に係る構成を有するものとなっており,上記のとおり,本願発明1?本願発明10は,上記引用文献1に記載された発明及び上記引用文献2,引用文献3に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。したがって,原査定を維持することはできない。

第6 当審拒絶理由について
1.36条6項2号について
当審は,請求項1?請求項12に記載された内容が明確でない旨指摘したが,平成30年9月11日付けの手続補正により,この拒絶理由は解消した。

2.36条4項1号について
当審は,「ローカル」,「ローカル装置」,「標識化」,「ログインアカウントにアクセス可能なバックアップデータ」,「ログインアカウントにアクセス可能なバックアップデータに記憶されている」が,本願明細書の発明の詳細な説明の記載内容を検討しても不明である旨指摘したが,平成30年9月11月付けの手続補正により,この拒絶理由は解消した。

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

よって,結論のとおり審決する。
 
審決日 2018-11-09 
出願番号 特願2016-541816(P2016-541816)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 536- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 月野 洋一郎  
特許庁審判長 仲間 晃
特許庁審判官 山崎 慎一
石井 茂和
発明の名称 データをバックアップするための方法および装置並びに電子装置  
代理人 特許業務法人 ユニアス国際特許事務所  

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