ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1334632 |
| 審判番号 | 不服2016-6297 |
| 総通号数 | 217 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2018-01-26 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2016-04-27 |
| 確定日 | 2017-11-17 |
| 事件の表示 | 特願2012- 75329「電子書類発行システム」拒絶査定不服審判事件〔平成25年10月 7日出願公開、特開2013-206205〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、平成24年3月29日に出願された特許出願であって、平成27年6月5日付けで拒絶の理由が通知され、これに対して、同年8月10日に意見書及び手続補正書が提出されたが、平成28年1月25日付けで拒絶の査定がなされ、同拒絶査定の謄本は同年1月28日に請求人に送達された。 これに対して、同年4月27日に拒絶査定不服審判の請求がなされ、それと同時に手続補正がなされたものである。 第2 平成28年4月27日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 平成28年4月27日にされた手続補正(以下、「本件補正」という。)を却下する。 [理由] 1 本件補正について 本件補正は、特許請求の範囲等を変更するものであり、平成27年8月10日に提出された手続補正書に記載された特許請求の範囲の請求項1の記載(下記(1))を平成28年4月27日に提出された手続補正書に記載された特許請求の範囲の請求項1に記載(下記(2))されたとおりに補正することをその一部に含むものである。 (1)平成27年8月10日提出の手続補正書に記載された特許請求の範囲の請求項1の記載 「システム管理業者の管理電子書類作成手段と、受領業者が保有する電子書類受領手段とで構成し、 配布依頼業者自身が配布書類の書式として使用する書式データ又はシステム管理業者の保有する配布書類用の書式データを予め前記管理電子書類作成手段に登録し、 前記管理電子書類作成手段が、配布依頼業者からの配布書類用データと配布先データとを受け取って、その配布書類用データと配布先データとを合体させて前記書式データに当てはめ、前記管理電子書類作成手段で配布書類用確定配布データを作成するとともに、前記配布書類用確定配布データを前記電子書類受領手段に渡す電子書類発行システム。」 (2)平成28年4月27日提出の手続補正書に記載された特許請求の範囲の請求項1の記載 「システム管理業者の管理電子書類作成手段と、受領業者が保有する電子書類受領手段と で構成し、 配布依頼業者自身が採用していた書式を配布書類の書式として使用する書式データ又はシステム管理業者の保有する配布書類用の書式データを予め前記管理電子書類作成手段に登録し、 前記管理電子書類作成手段が、配布依頼業者からの配布書類用データと配布先データとを受け取って、その配布書類用データと配布先データとを合体させて前記書式データに当てはめ、前記管理電子書類作成手段で配布書類用確定配布データを作成するとともに、前記配布書類用確定配布データを前記電子書類受領手段に渡す電子書類発行システム。」(下線(補正箇所)は当審で付与。) (3)請求項1の補正の内容について 請求項1の補正は、「配布依頼業者自身が配布書類の書式として使用する書式データ」を「配布依頼業者自身が採用していた」ものに限定するものであるから、本件補正前の請求項1に係る発明を減縮するものである。そして、その産業上の利用分野及び解決しようとする課題を変更するものではない。よって、請求項1についての補正は、特許法第17条の2第5項第2号に規定する特許請求の範囲の減縮を目的とするものである。 そこで、本件補正後の請求項1に記載された発明(以下、「本願補正発明」という。)が、特許法第17条の2第6項で準用する同法第126条第7項の規定する要件を満たすものであるか否か(いわゆる、「独立特許要件」を有するか否か)について検討する。 2 独立特許要件違反についての検討 (1)本願補正発明 本願補正発明は、上記1(2)に示した、平成28年4月27日に提出された手続補正書の特許請求の範囲の請求項1に記載された事項により特定されるとおりのものである。 (2)引用文献と周知例 ア 引用文献 原査定の拒絶の理由において引用された、特開2001-7843号公報(以下、引用文献という。)は、平成13年1月12日に出願公開がなされた特許公報であり、次の事項が記載されている。(下線は当審で付与。) (ア) 「【0002】【従来の技術】例えば自治体から住民へ自動車税等の納税請求通知を発行する場合、納付遅延に対する督促状を送付する場合に、従来は電子計算機上で稼動する該当する業務システムがその通知内容をはがき等の帳票に出力し、郵便局へ配達依頼するのが一般的である。このため対象とする住民の数が多くなると、帳票の出力時間が長くなり、また帳票の発送業務に係わる担当者の作業負荷及び発送経費が膨大となる。同様の問題は民間企業でも生じており、例えば計算機を利用して利用者への請求書を出力し、これを郵送する場合についても同じことが言える。 【0003】【発明が解決しようとする課題】上記従来技術によれば、外部へ通知する帳票を出力して発送するために計算機出力時間がかかり、発送業務の作業負荷及び発送経費が大きいという問題があった。特に同一の官公庁、自治体、企業内で複数の業務システムがこのような帳票を発行する場合に、発送作業の負荷及び発送に伴う経費は加算的に大きくなる。 【0004】本発明の目的は、発送データを電子的に送付先に発送することにより、このような紙の帳票出力をなくし紙の発送業務に伴う作業負荷及び発送経費を回避することにある。」 (イ) 「【0006】【発明の実施の形態】以下、本発明の一実施形態について図面を用いて説明する。 【0007】図1は、本実施形態の電子発送システムの構成図である。システムは複数の業務システムサーバ2、電子発送システム1、インターネット3、電子郵便システム6及びインターネット3に接続される電子メールサーバ4、パソコン5から構成される。業務システムサーバ2と電子発送システム1とは、LAN8によって接続される。LAN8はルータを介してインターネット3に接続される。・・・業務システムサーバ2は発送処理の要求元であり、外部に発送すべき帳票を出力する業務システムが稼動する計算機である。 【0008】電子発送システム1は、電子発送サーバ10と、電子発送サーバ10の記憶装置上に格納される発送データファイル11、発送管理テーブル12、宛先管理テーブル13、書式テーブル14及び発送履歴ファイル15と、運用監視端末20とを有する。また電子発送サーバ10のメモリには発送データ受付部16、発送データ発送部17、発送データ運用管理部18の各プログラムが格納され、電子発送サーバ10によって実行される。・・・ 【0009】電子発送サーバ10は、業務システムサーバ2から発送案件の発送要求を受け、その各発送データを受け取ってファイルに保存する。運用監視端末20の指示に従って発送データを1件ずつ電子メールの手段によってインターネット3を介して電子メールサーバ4へ送信し、電子メールサーバ4を介して各送付先のパソコン5へ送信するか、または電子郵便システム6を介して郵便物7として送付先に届ける。 【0010】少なくとも発送データ受付部16および発送データ発送部17を記憶媒体に格納し、電子発送サーバ10に接続される駆動装置を介して電子発送サーバ10のメモリに読み込むか、または他の計算機に接続される駆動装置、他の計算機、ネットワークを介して電子発送サーバ10へ伝送し、電子発送サーバ10によつて実行することが可能である。」 (ウ) 「【0012】図3は、電子発送システム1で使用される各ファイルのデータ構成を示す図である。発送データファイル11は、各発送案件ごとに設けられるファイルであり、各発送データファイルは複数の発送データを格納する。各発送データは1件の帳票に対応して「帳票ID」「送付先ID」及び「帳票内容」を有する。「帳票ID」は帳票の種別を示す識別子、「送付先ID」は送付先を区別する識別子である。一般に1つの発送データファイル中のすべての発送データの「帳票ID」は同一である。 ・・・ 【0015】書式テーブル14の各書式レコードは、帳票種別ごとに設けられ、基本情報として「帳票ID」「帳票名称」「帳票作成日付」、属性情報として「用紙サイズ」「文字数/行」「行数/頁」「フォントサイズ」、および文面情報として「文面基本情報」「文面可変情報」の各項目を有する。「帳票ID」は上記の帳票IDである。属性情報は帳票の書式を設定する情報である。「文面基本情報」はその帳票種別に共通に付加される固定情報を格納する。「文面可変情報」は「送付先区分」の区分による相違など状況に応じて付加される可変情報を格納する。」 (エ) 「【0017】図4は、発送データ受付部16の処理の流れを示すフローチャートである。いずれかの業務システムサーバ2から業務システムID及び帳票IDを伴って新しい発送案件の発送要求を受信すると(ステップ31)、発送データ受付部16は、発送受付番号を採番し(ステップ32)、発送データ運用管理部18に発送受付番号、要求元の業務システムID及び帳票IDを通知する(ステップ33)。発送データ運用管理部18は、発送管理テーブル12に「発送受付番号」「業務システムID」「帳票ID」「発送状況フラグ」「処理状況フラグ」及び「受付処理開始時刻」を格納する新規のレコードを登録する。「発送状況フラグ」は”受付中”のフラグとする。また「処理状況フラグ」は”処理中”のフラグとする。次に発送データ受付部16は、要求元の業務システムサーバ2に発送受付番号を伴って受付通知を送信する(ステップ34)。また採番した発送受付番号を含むような文字列をファイル名として、新しいファイルを生成する。発送データの受信が終了していなければ(ステップ35Nｏ)、業務システムサーバ2から受信した発送データを生成した発送データファイル11に出力して(ステップ36)、ステップ35に戻る。発送データの受信が終了したとき、または異常事態によって処理の続行ができないとき(ステップ35Yeｓ)、要求元の業務システムサーバ2に発送データ受信完了通知を送信する(ステップ37)。次に発送データ運用管理部18に受信完了した発送案件についてその発送受付番号を伴って受付済であることとその処理状況を通知する(ステップ38)。 【0018】発送データ運用管理部18は、発送管理テーブル12を検索して該当するレコードの「発送状況フラグ」を”受付済”のフラグに更新し、「処理状況フラグ」を”正常終了”又は”異常終了”に更新する。また「受付処理終了時刻」を格納する。また「発送状況フラグ」が”受付済”で「処理状況フラグ」が”正常終了”である発送案件の「発送状況フラグ」を”発送待ち”に更新する。発送データ運用管理部18は、運用監視端末20からの指示に応答し、発送管理テーブル12の内容を運用監視端末20の表示装置上に表示する。運用監視端末20から”発送待ち”状態のいずれかの発送案件が指示されたとき、発送データ運用管理部18は、発送データ発送部17に発送受付番号を伴って発送要求を送る。」 (オ) 「【0019】図5は、発送データ発送部17の処理の流れを示すフローチャートである。発送データ発送部17は、発送データ運用管理部18から発送要求を受け取り(ステップ41)、発送番号を採番し(ステップ42)、発送データ運用管理部18に発送受付番号および採番した発送番号を通知する(ステップ43)。発送データ運用管理部18は、発送管理テーブル12を参照して通知を受けた発送案件のレコード中の「発送番号」を格納し、「発送状況フラグ」を”発送中”に、「処理状況フラグ」を”処理中”に更新し、「発送処理開始時刻」を格納する。次に発送データ発送部17は、発送要求のあった発送案件の発送受付番号から発送データファイル11のファイル名を得て、発送データファイル11の該当する発送データファイルにアクセスする。ファイル中の発送データの終了でなければ(ステップ44Nｏ)、発送データを1件入力する(ステップ45)。そしてその「送付先ID」をキーとして宛先管理テーブル13を検索して該当する宛先レコードを取得する(ステップ46)。また発送データ中の「帳票ID」をキーとして書式テーブル14を検索して、該当する書式レコードを取得する(ステップ47)。次に取得した書式レコードに基づいて当該発送データを編集する(ステップ48)。このとき帳票の属性情報に従い、また書式レコード中の「文面基本情報」を発送データに追加し、宛先レコード中の「送付先区分」などに応じて「文面可変情報」を選択して発送データに追加する。さらに電子透かしの技法によって発送元の署名情報を発送データ中に埋め込む。 【0020】次に「送付先区分」が電子メールか電子郵便かを判定する(ステップ49)。電子メールであれば、宛先レコード中の「送付先電子メールアドレス」に従ってインターネット3を介して発送データを電子メールサーバ4へ送信する(ステップ50)。正常に発送できたか否かに応じて宛先レコード中の「発送状況フラグ」に”発送済”又は”発送異常”のフラグを格納する。」 (カ) 「【0022】なお上記実施形態では、電子発送システム1は業務システムサーバ2と同一の官公庁、自治体又は企業に属するものとしたが、電子発送システム1が業務システムサーバ2から独立して発送業務を行う電子発送センタであっても本発明を支障なく実施できる。この場合には、電子発送システム1はLAN8とは別のLAN及びインターネット3を介して他の官公庁、自治体又は企業の業務システムサーバ2に接続され、複数の官公庁、自治体又は企業に対してアウトソーシングの形態で発送サービスを行うことができる。」 イ 周知例 (ア)特開平7-129689号公報 「【0003】・・・従来から用いていた帳票、特に顧客に対する納品書等の帳票を変更することには抵抗があり、同じ帳票を使用したいという要求が非常に強かった。」 (イ)特開2001-92884号公報 「【0003】・・・注文された資源の納品を確認するために用いられている資源に付随する納品伝票は、その性格上電子化することは困難であり、従来通りの伝票形式がなお採用されている。このため、注文先では、注文情報に基づいて手書きで納品伝票を作成したり、電子的な注文情報に対してフォーマット変換やレイアウト変換といった加工を施して納品伝票を作り上げ、プリント出力する必要がある。この作業は、ほとんどの注文元が自己の指定フォームをもった納品伝票を要求することを考慮すれば、大きな負担を強いるものである。・・・」 (ウ)特開2008-262380号公報 「【0002】例えば、建設機械のリース・レンタル業務における請求書の発行は概略次のようにして行われていた。まず、顧客毎に指定請求書の書式が異なるために、夫々に対応できるように複数種類の書式を作成しておく。そしてその中から任意の書式を選択し、該選択した書式の中に項目や金額を記入していくものである。 尚、これらの作業は手書きで行う場合と予め作成されているプログラムに沿ってコンピュータを使用して作成する場合がある。コンピュータによって作成する場合には、顧客毎に異なる指定請求書の書式に対応するべく複数種類の請求書作成プログラムを予め用意しておき、その中から任意の請求書作成プログラムを選択して作成するものである。」 (3)引用発明 ア (2)ア(ア)によれば、引用文献は、「自治体」からの「自動車税等の納税請求通知」の「はがき」や「民間企業」からの「請求書」等の帳票の発行を念頭においたものであるから、引用文献の「電子発送システム」は、このような帳票の発行に用いられるものである。 また、(2)ア(イ)及びここで参照された図1によれば、官公庁、自治体又は企業(以下、官公庁等)は、「外部に発送すべき帳票を出力する業務システム」を有しており、上記「電子発送システム」は、ここで出力された帳票を電子メール等により発送する「官公庁等の電子発送サーバ」と、これとインターネットを介して接続された「送付先のパソコン」等から構成されるものである。 イ (2)ア(イ)及び同(ウ)によれば、「電子発送サーバ」は、その「記憶装置上」に、(2)ア(ウ)に示された「書式レコード」からなる「書式テーブル」を有するものである。 ウ (2)ア(エ)によれば、「電子発送サーバ」は、業務システムのいずれかから発送要求を受信する。そして、発送データ受付部のプログラムの処理として、その業務システムから発送データを受信して発送データファイルに格納するところ、この発送データは、(2)ア(ウ)によれば、「1件の帳票に対応し」て「帳票ID」と「帳票内容」を有するものである。 エ (2)ア(オ)によれば、「電子発送サーバ」は、発送データ発送部のプログラムの処理として、この発送データ中の帳票IDをキーとして書式テーブルを検索し、該当する書式レコードを取得し、取得した書式レコードに基づいて当該発送データを編集する。そして、編集された発送データは、「送付先区分」が電子メールの場合、インターネット及び電子メールサーバを介して送付先のパソコンへ送信され、これによって「送付先」へ「発送」される(発送済となる)ものである。 オ 以上によれば、(2)アの引用文献には、次の発明(以下、「引用発明」という。)が記載されているものと認められる。 「帳票の発行に用いられ、電子メール等により発送される帳票を出力する複数の業務システムを有する官公庁等の電子発送サーバと、これとインターネットを介して接続され、出力された帳票が発送される送付先のパソコン等から構成される電子発送システムであって、 電子発送サーバは、その記憶装置上に格納された書式テーブルの書式レコードを有し、 業務システムのいずれかから発送要求を受けた電子発送サーバは、 発送データ受付部のプログラムの処理として、その業務システムから帳票ID、帳票内容等を有する発送データを受信し、 発送データ発送部のプログラムの処理として、この発送データ中の帳票IDをキーとして取得した書式テーブルの書式レコードに基づいて当該発送データを編集し、編集された発送データをインターネット及び電子メールサーバを介して送付先のパソコンへ送信して送付先へ発送する、 電子発送システム。」 (4)本願補正発明と引用発明との対比 ア 本願補正発明と引用発明とを対比する。 (ア) 引用発明の「電子メール等により発送される帳票」は、本願補正発明の「配布書類である電子書類」に相当し、引用発明が「帳票の発行に用いられる電子発送システム」あることは、本願補正発明が「電子書類発行システム」であることに相当する。 (イ) 引用発明の「書式テーブルの書式レコード」は、「配布書類である電子書類」の書式データであるから、本願補正発明の「書式データ」に相当し、引用発明の「書式データ」の「格納」は、本願補正発明の「書式データ」を「予め」「登録」することに相当する。 (ウ) 引用発明の「官公庁等」は、配布書類である電子書類の発行元であるから、本願補正発明の「配布依頼業者」に相当する。また、引用発明は、予め登録された書式データに基づいて配布依頼業者から受信して受け取った「電子書類作成用データ」である帳票ID、帳票内容等を有する発送データを編集して、編集された「発送データ」を「配布書類である電子書類」とするものであり、他方、本願補正発明は、予め登録された書式データを当てはめることで配布依頼業者から受け取った「電子書類作成用データ」である「配布書類用データ」及び「配布先データ」から「配布書類である電子書類」としての「配布書類用確定データ」を「作成」するものである。 これによれば、本願補正発明と引用発明とは、電子書類作成用データが何か(後記相違点1)及び電子書類作成用データから配布書類である電子書類としての配布書類用確定データを作成する際何を行うか(後記相違点2)については相違しているものの、いずれも、予め登録された書式データに基づいて配布依頼業者から受け取った電子書類作成用データから配布書類である電子書類としての配布書類用確定データを作成するものであり、この点で共通している。 (エ) 引用発明の「送付先」は、配布書類である電子書類の発行先であり、本願補正発明の「受領業者」に相当し、引用発明の「送付先のパソコン」は、編集された「発送データ」が送信されることで配布書類である電子書類を受領するものであり、本願補正発明の「受領業者が保有する電子書類受領手段」に相当する。 これによれば、本願補正発明と引用発明とは、(ウ)で上記したところに加えて電子書類作成手段が何か(後記相違点3)及び書式データが何か(後記相違点4)についても相違しているものの、いずれも、予め登録された書式データに基づいて電子書類作成用データから配布書類である電子書類を作成する手段(以下、「電子書類作成手段」という。)と受領業者が保有する電子書類受領手段とで構成された電子書類発行システムであり、この点で共通している。 イ してみると、本願補正発明と引用発明とは、次の点で一致する。 ＜一致点＞ 電子書類作成手段と、受領業者が保有する電子書類受領手段とで構成し、 書式データを予め前記電子書類作成手段に登録し、 前記電子書類作成手段が、予め登録された書式データに基づいて配布依頼業者から受け取った電子書類作成用データから配布書類である電子書類としての配布書類用確定配布データを作成して前記電子書類受領手段に渡す 電子書類発行システム。 ウ そして、本願補正発明と引用発明とは、次の相違点1乃至4において、相違する。 ＜相違点＞ (相違点1)電子書類作成用データが、本願補正発明では配布書類用データと配布先データであるのに対し、引用発明では「帳票ID、帳票内容等を有する発送データ」である点。 (相違点2)電子書類作成用データから配布書類である電子書類を作成する際、本願補正発明では、「配布書類用データと配布先データとを合体させて書式データにあてはめ」るのに対し、引用発明では、帳票ID、帳票内容等を有する発送データを編集し、その際、発送データ中の帳票IDをキーとして取得した書式テーブルの書式レコードに基づいて当該発送データを編集するにあたって、発送データ中の帳票内容に配布書類用データと配布先データが含まれているか否か、編集にあたってこれらが合体されて書式データにあてはめられているかについて、明示されていない点。 (相違点3)電子書類作成手段が、本願補正発明では「システム管理業者の管理電子書類作成手段」であるのに対し、引用発明では配布依頼業者である「官公庁等」の電子発送サーバである点。 (相違点4)書式データが、本願補正発明では「配布依頼業者自身が採用していた書式を配布書類の書式として使用する書式データ又はシステム管理業者の保有する配布書類用の書式データ」であるのに対し、引用発明では書式データが何かについて明示されていない点。 (5)相違点の判断 ア 相違点1及び相違点2について 引用文献には、引用発明の「電子書類作成用データ」である「帳票内容」の具体的な内容の明記はないものの、(3)アで上記したとおり、ここでの帳票としては、「自治体」からの「自動車税等の納税請求通知」の「はがき」や「民間企業」からの「請求書」等が念頭におかれており、このような帳票の代替となる電子書類を作成するために、その作成用データには、これらの帳票の必要的記載事項である配布先(宛先)のデータが含まれていることになる。このことを踏まえれば、「帳票内容」を「配布先」データとこれ以外の「配布書類用」データとするか否かは、表現上の違いにすぎない。また、このような帳票の代替となる電子書類の作成のための書式データに基づくデータの編集にあたって、「配布先」データとこれ以外の「配布書類用」データを合わせた両方について書式データへのあてはめを行うことも当然のことである。 してみると、これらの点は、実質的な相違点でないか、当業者が適宜なし得たことである。 イ 相違点3及び相違点4について (2)ア(カ)にあるように、引用文献には、「電子発送システム」を「業務システム」から独立した「電子発送センタ」としたり「アウトソーシングの形態」とすることが可能である旨の記載があり、「電子書類作成手段」を「配布依頼業者(官公庁等)」でない者のものとすることが示唆されている。 この示唆に従って、引用発明の「電子書類作成手段(電子発送サーバ)」を、「配布依頼業者(官公庁等)」でない者のものとし、その際、この者を「システム管理業者」と称し、電子書類作成手段を「管理電子書類作成手段」と称することは、適宜なし得たことである。 さらに、「書式データ」は、必要なものを用意すればよいのであるから、取決め乃至設計事項にすぎない。 この点、上記のとおり、「電子書類作成手段」を「配布依頼業者(官公庁等)」でない者である「システム管理業者」のものとすれば、そこに格納された「書式データ」が「システム管理業者」の「保有する」ものとなることは当然である。また、帳票を用いるにあたって、請求書等の帳票の書式を発行先の要望に応じたものとする等、発行元で新たな書式を採用できず、従前使用していた書式を継続して使用したいという要望があることは、(2)イに示した周知例にもあるように、広く知られたことであり、このことに照らせば、「配布依頼業者」でない「システム管理業者」の「電子書類作成手段」でも、このような要望を踏まえて「配布依頼業者が採用していた書式」を用意することは、当業者が適宜なし得たことである。してみると、引用発明において、「書式データ」を「配布依頼業者自身が採用していた書式を配布書類の書式として使用する書式データ又はシステム管理業者の保有する配布書類用の書式データ」とすることは、当業者が適宜なし得たことであり、取決め乃至設計事項にすぎない。 ウ 本願補正発明の効果について 本願補正発明の効果は、引用文献に記載された事項及びイにおいて上記した広く知られた要望に照らして当業者が予測し得る程度のことであり、格別なものでない。 エ 小括 上記ア乃至ウで検討したように、本件補正発明は、引用発明に基づいて当業者が容易に発明をすることができたものであって、特許法第29条第2項の規定により特許を受けることができないものであるから、特許出願の際独立して特許を受けることができるものではない。 (6)補正の却下の決定のまとめ 以上のとおりであるから、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するものである。 したがって、本件補正は、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 よって、上記補正却下の決定の結論のとおり決定する。 第3 本願発明について 1 本願発明 上記第2の補正の却下の決定により、本件補正は却下された。よって、本願の請求項1乃至7に係る発明は、平成27年8月10日に提出された手続補正書の特許請求の範囲の請求項1乃至7に記載された事項により特定されるとおりのものであり、その請求項1に係る発明(以下、単に、「本願発明」という。)は、第2 1(1)において摘示したとおりのものである。 2 引用文献及び引用発明について 引用文献及び引用発明については、それぞれ、第2 2(2)ア及び第2 2(3)に上記したとおりである。 3 判断 本願発明は、本願補正発明における「配布依頼業者自身が配布書類の書式として使用する書式データ」が「配布依頼業者自身が採用していた」ものである旨の限定を除くものである。 そうすると、本願発明の発明特定事項を全て含み、さらに「配布依頼業者自身が配布書類の書式として使用する書式データ」が「配布依頼業者自身が採用していた」ものであるものに限定されるものに相当する本件補正発明が、上記第2 2(4)及び同(5)に説示したように、引用発明に基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明に基づいて当業者が容易に発明をすることができたものである。 4 むすび 以上のとおりであるから、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、その他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2017-01-23 |
| 結審通知日 | 2017-01-26 |
| 審決日 | 2017-09-12 |
| 出願番号 | 特願2012-75329(P2012-75329) |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 松野 広一、松田 直也 |
| 特許庁審判長 |
金子 幸一 |
| 特許庁審判官 |
相崎 裕恒 貝塚 涼 |
| 発明の名称 | 電子書類発行システム |
| 代理人 | 小副川 義昭 |