ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F 審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
---|---|
管理番号 | 1347332 |
審判番号 | 不服2017-11699 |
総通号数 | 230 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2019-02-22 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2017-08-04 |
確定日 | 2019-01-08 |
事件の表示 | 特願2015-126205「ファイルバリアントを作成する方法、計算装置、及びプログラム」拒絶査定不服審判事件〔平成27年11月26日出願公開、特開2015-212961、請求項の数(17)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は、2012年(平成24年)3月7日(パリ条約による優先権主張外国庁受理2011年3月14日、米国)を国際出願日とする特願2013-554693号の一部を平成27年6月24日に新たな特許出願(特願2015-126205号)としたものであって、平成28年8月5日付けで拒絶理由通知がされ、平成28年11月16日付けで手続補正がされたが、平成29年3月31日付けで拒絶査定がなされ、これに対し、平成29年8月4日に拒絶査定不服審判の請求がされると同時に手続補正がされ、その後、平成30年3月12日付けで当審より拒絶理由が通知され(以下、「当審拒絶理由(1)」という。)、平成30年6月13日に手続補正がされ、平成30年8月2日付けで当審より拒絶理由(以下、「当審拒絶理由(2)」という。)が通知され、平成30年11月7日に手続補正がされたものである。 第2 原査定の概要 原査定(平成29年3月31日付け拒絶査定)の概要は次のとおりである。 理由2 本件出願は、特許請求の範囲の請求項14-20の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。 理由3 本願請求項1-20に係る発明は、引用文献A-Dに基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献等一覧 A.特開2006-323448号公報 B.特開2006-12105号公報 C.特開2004-30644号公報 D.特開2003-319365号公報 第3 当審拒絶理由の概要 1 当審拒絶理由(1)の概要 理由1 本願請求項1-19に係る発明は、引用文献1-6に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献等一覧 1.特開2006-323448号公報 (拒絶査定時の引用文献A) 2.特開平7-56781号公報(当審において新たに引用した文献) 3.特開2007-115140号公報(当審において新たに引用した文献) 4.特開2006-12105号公報(拒絶査定時の引用文献B) 5.特開2004-30644号公報(拒絶査定時の引用文献C) 6.特開2003-319365号公報(拒絶査定時の引用文献D) 理由2 本件出願は、特許請求の範囲の請求項13-19の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。 2 当審拒絶理由(2)の概要 この出願は、特許請求の範囲の請求項16の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。 第4 本願発明 本願請求項1-17に係る発明(以下、それぞれ「本願発明1」-「本願発明17」という。)は、平成30年11月7日付けの手続補正で補正された特許請求の範囲の請求項1-17に記載された事項により特定される発明であり、本願発明12は以下のとおりの発明である。 「【請求項12】 データストアと、 プロセッサと、 を有する計算装置であって、 前記プロセッサは、 複数のユーザに関する複数のファイルシステムを前記データストアに保持し、それぞれの前記ファイルシステムは複数のファイルおよび少なくとも1つのフォルダを有し、それぞれの前記ファイルは識別子および少なくとも1つの前記データストア内に格納されたデータオブジェクトへのリファレンスを有し、 複数のファイルバリアントを前記データストアに保持し、 それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し、 それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し、 前記ファイルバリアントのそれぞれは前記ファイルのデータ減少バージョンを含む、 計算装置。」 なお、概略、本願発明1は、本願発明12に対応する、カテゴリ表現が異なる「プログラム」の発明である。 本願発明2-3は、本願発明1を減縮した発明である。 本願発明4は、本願発明12に対応する、カテゴリ表現が異なる「方法」の発明である。 本願発明5-11は、本願発明4を減縮した発明である。 本願発明13-17は、本願発明12を減縮した発明である。 第5 引用文献、引用発明等 1 引用文献1及び引用発明 当審拒絶理由(1)に引用した引用文献1には、図面とともに、以下の記載がある(下線は、特に着目した箇所を示す。以下同様。)。 (1) 段落【0014】 「【0014】 ファイルサーバ50は、LAN100に接続された機器において共有されるデータファイルを管理するサーバであり、後述するように、共有可能な状態にあるデータファイルの実体が蓄積される。」 (2) 段落【0037】-【0043】 「【0037】 次に、このような通信システムにおいて、PC30内のデータファイルを共有するための動作について説明する。 図5は、データファイルを共有する際の動作全体の概要を示す図である。 【0038】 この図5では例として、電子会議端末10aおよび10bの間で電子会議の実行中に、PC30内の画像や文書、図面などのデータファイルを電子会議端末10bに送信して再生表示させる場合の動作の概要を示している。なお、この図5では、説明をわかりやすくするために、電子会議端末10a、無線LANアクセスポイント20aおよび20bを省略している。 【0039】 この通信システムでは、各会議室の出席者が持つ携帯端末60aおよび60bを利用して、システム内の機器に記憶されたデータファイルを簡単な操作で共有できるようにしている。まず、PC30内のデータファイルを共有可能な状態にするために、電子会議端末10a側のユーザは、PC30に接続された拡張ボックス40に対して携帯端末60aを近づけ、拡張ボックス40にこの携帯端末60aを検知させる(ステップS11)。拡張ボックス40の接続制御部41は、近距離無線インタフェース42を通じて携帯端末60aを検知すると、この携帯端末60aとの認証処理を実行する。認証に成功すると、拡張ボックス40と携帯端末60aとの間はLAN100経由で通信できる状態となる。 【0040】 ここで、携帯端末60aは、無線LANアクセスポイント20aを通じてLAN100経由で拡張ボックス40にアクセスし、PC30内の所定のデータファイルを共有可能にするための制御コマンドを送信する。この制御コマンドに応じて、拡張ボックス40は、PC30を制御して対応するデータファイルをファイルサーバ50にアップロードさせ、共有対象として登録させた後(ステップS12)、このデータファイルが共有可能となったことを示すファイル共有情報を、LAN100経由で携帯端末60aに送信する(ステップS13)。このファイル共有情報には、ファイルサーバ50に記憶された対応するデータファイルのURL(Uniform Resource Locator)などの位置情報や、データファイルの属性情報などが格納され、携帯端末60aはファイル共有情報を取得することで、対応するデータファイルを他の機器に利用させる、あるいは自分自身で利用することが可能となる。 【0041】 なお、携帯端末60aを拡張ボックス40に検知させた後、PC30内のデータファイルをファイルサーバ50にアップロードさせる際には、例えば、携帯端末60aにおいてユーザの操作入力に応じて制御コマンドが送信され、この制御コマンドに応じて拡張ボックス40がPC30にアップロードを実行させる。例えば、PC30に接続されたモニタ34aにおいて、該当データファイルのアイコンを選択した状態としておき、携帯端末60aから制御コマンドが送信されると、そのデータファイルを共有可能にするための動作(ステップS12およびS13)が実行される。あるいは、同様に該当データファイルを選択した状態から、携帯端末60aを拡張ボックス40に検知させると(ステップS11)、上記動作(ステップS12およびS13)が自動的に開始されるようにしてもよい。この場合には、制御コマンドやファイル共有情報が各機器の近距離無線インタフェース42および63を通じて伝送されてもよい。 【0042】 次に、ファイルサーバ50にアップロードしたデータファイルを電子会議端末10bに利用させるために、携帯端末60aおよび60bの間でIP電話の通話を開始し、VoIPにおけるメッセージ送信の手順により、ファイル共有情報を携帯端末60aから携帯端末60bに送信する(ステップS14)。電子会議端末10b側のユーザは、携帯端末60bを電子会議端末10bに近づけて検知させる(ステップS15)。電子会議端末10bの接続制御部14は、近距離無線インタフェース16を介して携帯端末60bを検知すると、この携帯端末60bの認証処理を実行する。認証に成功すると、電子会議端末10bと携帯端末60bとがLAN100経由で通信できる状態となる。 【0043】 次に、携帯端末60bは、例えばユーザの操作入力に応じて、ファイル共有情報を制御コマンドとともに電子会議端末10bに対してLAN100経由で送信し、対応するデータファイルをファイルサーバ50からダウンロードするように要求する(ステップS16)。電子会議端末10bは、この要求を受けると、ファイル共有情報に基づいてファイルサーバ50から対応するデータファイルをダウンロードする(ステップS17)。これにより、電子会議端末10bにおいてデータファイルを利用することが可能となる。」 (3)段落【0048】-【0054】 「【0048】 ところで、ファイル共有情報には、共有可能となったデータファイルの位置情報の他、そのデータファイルに関する種々の属性情報を格納しておき、携帯端末60aおよび60bなどでその属性情報に応じた処理を行うようにすることができる。以下の処理例では、共有するデータファイルが画像データである場合に、その画像データのサムネイル画像のデータを用意しておき、サムネイル画像の属性情報および位置情報もファイル共有情報に格納しておく。これにより、携帯端末60aにおいてこの端末に最適なサムネイル画像のデータを受信し、表示できるようにする。 【0049】 図6は、データファイルを共有可能にする際の処理シーケンスを示す図である。 図6の初期状態では、携帯端末60aが拡張ボックス40に近づけられて近距離通信方式により検知されると、携帯端末60aと拡張ボックス40との間で認証処理が行われる。この認証処理では、互いの識別IDやIPアドレスなどが交換され、認証に成功すると、それらの情報を用いてLAN100を通じた通信ができるようになる。 【0050】 この状態で、携帯端末60aは、PC30内の所望のデータファイルを共有可能な状態にするための制御コマンドを、LAN100経由で拡張ボックス40に送信する(ステップS21)。ここでは例えば、PC30において拡張ボックス40と連携するためのアプリケーションプログラムを実行しておき、そのプログラムの処理によりPC30内の所望のデータファイルのアイコンを表示しておく。この状態で、携帯端末60aの操作により制御コマンドを送信させることで、表示されたデータファイルを共有可能にするための要求を実行できる。 【0051】 要求を受けた拡張ボックス40は、通信インタフェース43を通じてPC30を制御し、対応するデータファイルをファイルサーバ50にアップロードさせる(ステップS22)。データファイルを受信したファイルサーバ50は、その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録する(ステップS23)。次に、登録したデータファイルの属性を識別し、それが画像データである場合には、解像度の異なる複数のサムネイル画像のデータファイルを作成する(ステップS24)。そして、元のデータファイルの位置情報(URL)、各サムネイル画像の位置情報(URL)、各サムネイル画像の属性情報(例えば解像度、データサイズなど)を含むファイル共有情報を作成し、拡張ボックス40に送信する(ステップS25)。なお、動画像データが登録された場合には、例えばその先頭画面など、所定位置のサムネイル画像のデータを作成するようにしてもよい。 【0052】 拡張ボックス40は、ファイル共有情報を受信すると、携帯端末60aに対してLAN100経由でコマンド応答を返し、ファイル共有情報を転送する(ステップS26)。携帯端末60aは、受信したファイル共有情報に格納されていたサムネイル画像の属性情報を参照し、自機の能力に合致したサムネイル画像を選択して、その位置情報を基にファイルサーバ50にアクセスし、対応するサムネイルの送信を要求する(ステップS27)。このステップでは、例えば、携帯端末60aのモニタ651の表示能力、表示のための処理能力、内部のメモリ容量などを基準として、最適なサムネイル画像を選択する。 【0053】 ファイルサーバ50は、携帯端末60aからの要求に応じたサムネイル画像のデータファイルを共有管理領域から抽出し、携帯端末60aに返信する(ステップS28)。携帯端末60aは、サムネイル画像のデータファイルを受信すると、そのサムネイル画像をモニタ651に表示する(ステップS29)。 【0054】 このような処理により、携帯端末60aのユーザは、共有可能となったデータファイルの内容を、その端末のモニタ651を通じて確認することができる。このときユーザは、あたかも元のデータファイル自体が携帯端末60aに記憶されているような感覚でその内容を確認できる。そして、その後に他の機器に対してデータファイルのダウンロードを要求する操作においても、あたかもその携帯端末60aから他の機器へ元のデータファイル自体を転送するような感覚で操作できる。」 よって、引用文献1には、次の発明(以下、「引用発明」という。)が記載されているといえる。 [引用発明] 「ファイルサーバ50は、LAN100に接続された機器において共有されるデータファイルを管理するサーバであり、 この通信システムでは、各会議室の出席者が持つ携帯端末60aおよび60bを利用して、システム内の機器に記憶されたデータファイルを簡単な操作で共有できるようにし、 携帯端末60aは、無線LANアクセスポイント20aを通じてLAN100経由で拡張ボックス40にアクセスし、PC30内の所定のデータファイルを共有可能にするための制御コマンドを送信し、 この制御コマンドに応じて、拡張ボックス40は、PC30を制御して対応するデータファイルをファイルサーバ50にアップロードさせ、共有対象として登録させた後、このデータファイルが共有可能となったことを示すファイル共有情報を、LAN100経由で携帯端末60aに送信し、 このファイル共有情報には、ファイルサーバ50に記憶された対応するデータファイルのURL(Uniform Resource Locator)などの位置情報や、データファイルの属性情報などが格納され、携帯端末60aはファイル共有情報を取得することで、対応するデータファイルを他の機器に利用させる、あるいは自分自身で利用することが可能となり、 ファイルサーバ50にアップロードしたデータファイルを電子会議端末10bに利用させるために、携帯端末60aおよび60bの間でIP電話の通話を開始し、VoIPにおけるメッセージ送信の手順により、ファイル共有情報を携帯端末60aから携帯端末60bに送信し、 携帯端末60bは、例えばユーザの操作入力に応じて、ファイル共有情報を制御コマンドとともに電子会議端末10bに対してLAN100経由で送信し、対応するデータファイルをファイルサーバ50からダウンロードするように要求し、 電子会議端末10bは、この要求を受けると、ファイル共有情報に基づいてファイルサーバ50から対応するデータファイルをダウンロードし、これにより、電子会議端末10bにおいてデータファイルを利用することが可能となり、 ファイル共有情報には、共有可能となったデータファイルの位置情報の他、そのデータファイルに関する種々の属性情報を格納しておき、携帯端末60aおよび60bなどでその属性情報に応じた処理を行うようにすることができ、 携帯端末60aは、PC30内の所望のデータファイルを共有可能な状態にするための制御コマンドを、LAN100経由で拡張ボックス40に送信し、 PC30において拡張ボックス40と連携するためのアプリケーションプログラムを実行しておき、そのプログラムの処理によりPC30内の所望のデータファイルのアイコンを表示しておき、この状態で、携帯端末60aの操作により制御コマンドを送信させることで、表示されたデータファイルを共有可能にするための要求を実行でき、 要求を受けた拡張ボックス40は、通信インタフェース43を通じてPC30を制御し、対応するデータファイルをファイルサーバ50にアップロードさせ、 データファイルを受信したファイルサーバ50は、その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録し、 次に、登録したデータファイルの属性を識別し、それが画像データである場合には、解像度の異なる複数のサムネイル画像のデータファイルを作成し、 元のデータファイルの位置情報(URL)、各サムネイル画像の位置情報(URL)、各サムネイル画像の属性情報(例えば解像度、データサイズなど)を含むファイル共有情報を作成し、拡張ボックス40に送信し、 拡張ボックス40は、ファイル共有情報を受信すると、携帯端末60aに対してLAN100経由でコマンド応答を返し、ファイル共有情報を転送し、携帯端末60aは、受信したファイル共有情報に格納されていたサムネイル画像の属性情報を参照し、自機の能力に合致したサムネイル画像を選択して、その位置情報を基にファイルサーバ50にアクセスし、対応するサムネイルの送信を要求し、 携帯端末60aのモニタ651の表示能力、表示のための処理能力、内部のメモリ容量などを基準として、最適なサムネイル画像を選択し、 ファイルサーバ50は、携帯端末60aからの要求に応じたサムネイル画像のデータファイルを共有管理領域から抽出し、携帯端末60aに返信し、携帯端末60aは、サムネイル画像のデータファイルを受信すると、そのサムネイル画像をモニタ651に表示する、 PC30内のデータファイルを共有するための動作をする通信システムのファイルサーバ50。」 2 引用文献2及び引用文献3について 引用文献2の段落【0002】には、以下の記載がある。 「【0002】情報処理システムにおいては、ユーザごとに作成された複数のファイルシステムからファイルの実体をなす一つのデータブロックにアクセスする場合、各ファイルシステムに設けられたディレクトリファイルによって指定するファイル(ディレクトリファイルではファイル名を指定するが、以下においては混乱のおそれがない限りファイル名を単にファイルと記し、ファイルの上位に位置するディレクトリファイルを名前管理用ファイルと記す)からアクセスさせるデータブロックに対してファイルリンクを設定して各ファイルシステムと所望のデータブロックを結合させている。」 引用文献3の段落【0012】には、以下の記載がある。 「【0012】 すなわち、本発明の第1は、複数のファイルサーバと、このファイルサーバにマウントされる複数のファイルシステムと、前記ファイルサーバに対して記憶資源を提供するストレージと、前記クライアントの前記ファイルシステムへのアクセスを管理する管理モジュールと、を備え、前記ファイルシステムに対してアクセスするクライアントに対して、同じ名前空間を持つ共有ファイルシステムを提供するストレージシステムであって、前記管理モジュールは、前記ファイルシステムと、このファイルシステムがマウントされているファイルサーバとの対応関係が格納された第1の情報テーブルと、前記ファイルシステムと、このファイルシステムに前記クライアントがアクセスした頻度と、の対応関係が格納された第2の情報テーブルと、を備える、ことを特徴とするものである。」 これらの記載から、システムにおいて、複数のファイルシステムを保持し、そのファイルシステムごとにユーザの処理を管理する構成は周知技術であるといえる。 3 引用文献4及び引用文献5について 引用文献4の段落【0013】には、以下の記載がある。 「【0013】 前記課題に対して、まず、図2のような、電子メールアドレス毎に、表示画面1行当たりに表示可能な文字数と、表示画面1枚当たりに表示可能な行数と、受信1回当たりに受信可能な電子メールの文字数及びサイズ及び添付ファイルの個数及び添付ファイルのサイズと、再生可能な文字コードと、再生可能な静止画の種類及びサイズ及び色数及び色と、再生可能な動画の種類及びサイズ及び色数及び色及び再生時間と、再生可能な音声の種類及び再生時間と、その他再生可能な添付ファイルの種類及び属性、(以下、機器能力と呼ぶ)の全てまたはいずれかを対応付けた情報(以下、端末情報と呼ぶ)を記憶装置に保存し、さらに、図3のような、送信予定の電子メール内容について、同じ意味の内容でありながらも、機器能力に応じて変化させた複数のパターンの内容(以下、送信内容情報と呼ぶ)を記憶装置に保存する。電子メール送信時に、送信先電子メールアドレスに相当する機器能力を端末情報により取得する。送信する電子メール内容について、送信内容情報から、取得した機器能力に最も一致し且つ十分満たす適切な内容を選択し、送信先電子メールアドレスに送信する。」 引用文献5の段落【0053】-【0057】には、以下の記載がある。 「【0053】 次に、処理できるデータ形式の異なる複数のタイプの端末装置から同一のURLによる要求データを本実施例のコンテンツデータ提供システムが受信した場合にも、各端末装置および利用者の各種属性に対応したコンテンツデータを送信する仕組みについて説明する。 ・・・(中略)・・・ 【0057】 上述した手順の処理により、本コンテンツデータ提供サーバは、端末装置の画面表示能力に最も適した画像を提供することが可能となる。ここでは端末装置のカラー表示可否に対応した送信すべき画像データの選択の手順を例として説明したが、この他にも例えば、端末装置の画面の大きさや解像度(縦および横の画素数)に対応して異なる画像データを送信するようにしても良い。例えば、パーソナルコンピュータの表示画面と携帯型電話端末の表示画面とでは、画面の物理的なサイズにおいても表示画素数においても大きく異なっており、それぞれに適した画像データを自動的に選択して提供できることのメリットは大きい。またこの他にも、画面で表示可能な色数および階調数や、動画像の表示の可否や、表示の際の画面走査周波数や、インターレース走査などの画面表示方式など、様々な画面表示の特性に対応して要求元の端末装置に適した画像データを送信できるようにすることも可能である。」 これらの記載から、データの送信先端末の種類や能力に応じて、送信するデータを選択する処理を行う構成は、周知技術であるといえる。 4 引用文献6について 引用文献6の段落【0072】-【0073】には、以下の記載がある。 「【0072】また、画像サーバ90から表示用ファイルを受信すると情報処理手段480は、受信した表示用ファイルに記載されている情報に基づいた表示を、携帯電話40の表示手段468に表示する処理を行う。 【0073】上記の実施の形態ではS210にて、携帯電話40の再生能力に見合う画像データが存在しなければ「NG」を返答する処理を実施しているが、ここで情報処理手段980が、新たに携帯電話40の表示手段468の再生能力に応じた画像データをオリジナルの画像データから生成するようにしてもよい。以下にその処理の流れを示す。」 上記記載から、送信先の端末に応じた画像データを選択して提供する際、適切な画像データが存在しなければ、新たに画像データを生成する点は、公知技術であるといえる。 第6 対比・判断 1 本願発明12について (1) 本願発明12と引用発明とを対比すると、次のことがいえる。 ア 引用発明の「ファイルサーバ50」は、「LAN100に接続された機器において共有されるデータファイルを管理するサーバであり」、「ファイルサーバ50は、その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録し」ているから、本願発明12の「データストアと、プロセッサと、を有する計算装置」に相当する。 イ 引用発明の「ファイルサーバ50」は、「PC30を制御して対応するデータファイルをファイルサーバ50にアップロードさせ、共有対象として登録させ」るとともに、「電子会議端末10bは、ファイル共有情報に基づいてファイルサーバ50から対応するデータファイルをダウンロードし」、「ファイルサーバ50は、その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録し」ているから、「データファイル」を管理するために、何らかの「ファイルシステム」を備えていることは明らかであるといえる。さらに、引用発明の「ファイルサーバ50」が、このような「複数のユーザに関する」、「ファイルシステムを前記データストアに保持し」ていることは明らかであるといえる。 また、引用発明の「ファイルサーバ50」の備える「ファイルシステム」が、「複数のファイル」を有していることは明らかであるといえる。 よって、引用発明の「ファイルサーバ50」が「PC30を制御して対応するデータファイルをファイルサーバ50にアップロードさせ、共有対象として登録させ」、「電子会議端末10bは、ファイル共有情報に基づいてファイルサーバ50から対応するデータファイルをダウンロードし」、「その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録し、次に、登録したデータファイルの属性を識別し、それが画像データである場合には、解像度の異なる複数のサムネイル画像のデータファイルを作成」していることは、本願発明12の「前記プロセッサは、複数のユーザに関する複数のファイルシステムを前記データストアに保持し、それぞれの前記ファイルシステムは複数のファイルおよび少なくとも1つのフォルダを有」することと、「前記プロセッサは、複数のユーザに関するファイルシステムを前記データストアに保持し、前記ファイルシステムは複数のファイルを有」する点で共通するといえる。 ウ 引用発明のファイルサーバ50に格納された「データファイル」が、「ファイル名」などの「識別子」を有することは明らかである。 また、引用発明のファイルサーバ50に「データファイル」を格納する際に作成される「ファイル共有情報」のうち「元のデータファイルの位置情報(URL)」は、本願発明12の「少なくとも1つの前記データストア内に格納されたデータオブジェクトへのリファレンス」に相当する。 よって、引用発明において「データファイルを受信したファイルサーバ50は、その要求に対応する共有管理領域を記録媒体内に生成し、その領域にデータファイルを格納して登録し、次に、登録したデータファイルの属性を識別し、それが画像データである場合には、解像度の異なる複数のサムネイル画像のデータファイルを作成し、元のデータファイルの位置情報(URL)、各サムネイル画像の位置情報(URL)、各サムネイル画像の属性情報(例えば解像度、データサイズなど)を含むファイル共有情報を作成し」ていることは、本願発明12の「それぞれの前記ファイルは識別子および少なくとも1つの前記データストア内に格納されたデータオブジェクトへのリファレンスを有」することに相当する。 エ 引用発明のファイルサーバ50に格納された「データファイル」について、「それが画像データである場合には、解像度の異なる複数のサムネイル画像のデータファイルを作成し、元のデータファイルの位置情報(URL)、各サムネイル画像の位置情報(URL)、各サムネイル画像の属性情報(例えば解像度、データサイズなど)を含むファイル共有情報を作成し」ていることは、本願発明12の「複数のファイルバリアントを前記データストアに保持し」、「前記ファイルバリアントのそれぞれは前記ファイルのデータ減少バージョンを含む」ことに相当する。 よって、本願発明12と引用発明との一致点・相違点は次のとおりであるといえる。 [一致点] データストアと、 プロセッサと、 を有する計算装置であって、 前記プロセッサは、 複数のユーザに関する、ファイルシステムを前記データストアに保持し、前記ファイルシステムは複数のファイルを有し、それぞれの前記ファイルは識別子および少なくとも1つの前記データストア内に格納されたデータオブジェクトへのリファレンスを有し、 複数のファイルバリアントを前記データストアに保持し、 前記ファイルバリアントのそれぞれは前記ファイルのデータ減少バージョンを含む、 計算装置。 [相違点1] 本願発明12では、「複数のユーザに関する複数のファイルシステムを保持し、それぞれの前記ファイルシステムは複数のファイルおよび少なくとも1つのフォルダを有し」ているのに対し、引用発明では、ファイルシステムが「複数の」ファイルシステムを保持し、「それぞれの」ファイルシステムは複数のファイル「および少なくとも1つのフォルダ」を有していることが特定されていない点。 [相違点2] 本願発明12では、「それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ているのに対し、引用発明の「サムネイル画像のデータファイル」が、「前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ていることが特定されていない点。 (2) 当審の判断 事案に鑑みて、上記[相違点2]について先に検討すると、本願発明12の上記[相違点2]に係る、「それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ている構成は、上記引用文献1-6には記載されておらず、本願出願前において周知技術であるともいえない。 したがって、他の相違点について判断するまでもなく、本願発明12は、当業者であっても引用発明、引用文献2-6に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 2 請求項1-11、13-17について 本願発明1-11、13-17も、本願発明12の上記[相違点2]に係る、「それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ていることと、実質的に同一の構成を備えるものであるから、本願発明12と同様の理由により、当業者であっても、引用発明、引用文献2-6に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 第6 当審拒絶理由(1)、(2)について 1 当審拒絶理由(1)について (1) 理由1について 平成30年11月7日付けの補正により補正された請求項1-17は、「それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ているという技術的事項を有しており、当該技術的事項は、当審拒絶理由(1)における引用文献1-6には記載されておらず、本願出願前における周知技術でもないので、本願発明1-17は、当業者であっても、当審拒絶理由(1)における引用文献1-6に基づいて容易に発明をすることができたものではない。したがって、この拒絶の理由は解消した。 (2) 理由2について 当審では、補正前の請求項13-19における「ファイルサービス」及び「バリアントサービス」が「サービス」として不明確であるとの拒絶の理由を通知しているが、平成30年11月7日付けの手続補正で補正された特許請求の範囲の請求項12-17から「ファイルサービス」及び「バリアントサービス」との記載は削除されている。したがって、この拒絶の理由は解消した。 2 当審拒絶理由(2)について 当審では、補正前の請求項16はどのような「識別子」を有するのかが不明確であるとの拒絶の理由を通知しているが、平成30年11月7日付けの補正により、補正前の請求項16は削除された。したがって、この拒絶の理由は解消した。 第7 原査定についての判断 1 理由2について 原査定における、補正前の請求項14-20における「ファイルサービス」及び「バリアントサービス」が「サービス」として不明確であるとの拒絶の理由について、平成30年11月7日付けの手続補正で補正された特許請求の範囲の請求項12-17から「ファイルサービス」及び「バリアントサービス」との記載は削除されている。したがって、この拒絶の理由は解消した。 2 理由3について 平成30年11月7日付けの補正により補正された請求項1-17は、「それぞれの前記ファイルバリアントは前記ファイルのうちのそれぞれ1つの前記識別子を有し」、「それぞれの前記ファイルバリアントは、前記ファイルのうちの前記それぞれ1つに参照される前記それぞれの1次データオブジェクトに関する少なくとも1つの前記データストア内に格納された2次データオブジェクトへのリファレンスをさらに有し」ているという技術的事項を有しており、当該技術的事項は、原査定における引用文献A-引用文献D(引用文献1、引用文献4-引用文献6)には記載されておらず、本願出願前における周知技術でもないので、本願発明1-17は、当業者であっても、原査定における引用文献A-引用文献Dに基づいて容易に発明をすることができたものではない。したがって、原査定を維持することはできない。 第8 むすび 以上のとおり、原査定の理由によって、本願を拒絶することはできない。 他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
審決日 | 2018-12-17 |
出願番号 | 特願2015-126205(P2015-126205) |
審決分類 |
P
1
8・
537-
WY
(G06F)
P 1 8・ 121- WY (G06F) |
最終処分 | 成立 |
前審関与審査官 | 圓道 浩史 |
特許庁審判長 |
▲吉▼田 耕一 |
特許庁審判官 |
稲葉 和生 菊地 陽一 |
発明の名称 | ファイルバリアントを作成する方法、計算装置、及びプログラム |
代理人 | 中島 淳 |
代理人 | 加藤 和詳 |