【事件の表示】
　特願２００３−３５４５２２「ネットワークＡＶシステム」拒絶査定不服審判事件〔平成１７年　５月１２日出願公開、特開２００５−１２２３３５、請求項の数（６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯 
 　本願は、平成１５年１０月１５日の出願であって、平成１７年９月１５日付けで拒絶の査定がなされ、これに対し、平成１７年１０月２７日に拒絶査定を不服として審判請求がなされるとともに、同年１１月２１日付けで手続補正がなされ、さらに、平成１８年８月２８日付けで手続補正がなされたものである。 
 　
 ２．本願発明 
　本願の請求項１−６に係る発明は、平成１８年８月２８日付手続補正書の特許請求の範囲の請求項１−６に記載された事項により特定される、以下のとおりのものである。
「【請求項１】
　複数のコンテンツを蓄積可能なデータベースを有するサーバと、
　前記サーバに接続可能であり、前記データベースを前記サーバに更新させるアップローダと、
　前記サーバに接続可能であり、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備え、
　前記アップローダは、
　要求開始通知を前記サーバに送信する開始通知手段と、
　前記開始通知手段が要求開始通知を送信した後、前記サーバに前記データベースを更新させるための複数の更新要求を前記サーバに送信する更新要求手段と、
　前記更新要求手段が前記複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備え、
　前記サーバは、
　前記複数の更新要求を受け、各更新要求ごとに前記データベースを更新する更新手段と、
　前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするネットワークＡＶシステム。
【請求項２】
　請求項１に記載のネットワークＡＶシステムであって、
　前記クライアントは、
　前記更新通知を受けたとき、前記選択されたコンテンツに関する情報を前記サーバから取得する取得手段と、
　前記情報に基づいて、前記選択されたコンテンツを前記サーバに要求する要求手段とを備えることを特徴とするネットワークＡＶシステム。
【請求項３】
　請求項１又は請求項２に記載のネットワークＡＶシステムであって、
　前記サーバはさらに、
　前記データベースが更新されたか否かを判断する判断手段を備え、
　前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするネットワークＡＶシステム。
【請求項４】
　複数のコンテンツを蓄積可能なデータベースを有するサーバと、前記サーバに接続可能であり、前記データベースを前記サーバに更新させるアップローダと、前記サーバに接続可能であり、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備えるネットワークＡＶシステムにおける前記サーバであって、
　前記アップローダから要求開始通知を受ける手段と、
　前記要求開始通知を受けた後、前記アップローダから送信される複数の更新要求を受け、各更新要求ごとに前記データベースを更新する更新手段と、
　前記アップローダから前記更新要求を完了する旨の要求完了通知を受ける手段と、
　前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするサーバ。
【請求項５】
　請求項４に記載のサーバであってさらに、
　前記データベースが更新されたか否かを判断する判断手段を備え、
　前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするサーバ。
【請求項６】
　請求項４又は請求項５に記載の手段をコンピュータに実行させるためのサーバプログラム。」 
 
 ３．原査定の理由 
　原査定の理由は、請求項１−１０に係る発明は、以下の引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができず、本願は拒絶をすべきものであるというものである。
　　引用例１：特開２００２−２１５５０６号公報
　　引用例２：特開２００３−１５０４９４号公報
　　引用例３：特開２００２−３１２６４６号公報
　　引用例４：特開２００３−８５０７３号公報
　
　また、特許法１６２条による審査（前置審査）の報告書でも、審査官は、請求項１−８に係る発明についても、同様の理由により特許を受けることができない旨、報告している。 
 　 
４．引用例記載事項
（１）引用例１
　原審の拒絶の理由で引用された引用例１には、図面とともに、以下の事項が記載されている。
（ａ）「【００２７】まず、少なくとも１ページのＨＴＭＬファイルをアップロードした際に、少なくとも１ページのＨＴＭＬファイルから構成されるホームページのアップロード前後のＨＴＭＬファイルを読込み、各ＨＴＭＬファイルの情報分野ごとに比較する手順Ｓ４について、図７のフローチャートを用いて説明する。最初にＷＥＢサーバにＨＴＭＬファイルをアップロードした際、このアップロード後のＨＴＭＬファイルとアップロード前のＨＴＭＬファイルとを読取り（Ｓ３１）、それぞれのＨＴＭＬファイルから分野毎に抽出する（Ｓ３２）。この場合において、ＨＴＭＬファイルには、あらかじめ各情報分野を区別して検出できるように識別子３０ａ、３０ｂによって分野Ａ、分野Ｂなどを分けておくことが好ましい。なお、識別子は図９に示す例に限られない。次に、各ＨＴＭＬファイルについて各分野毎に比較して（Ｓ３３）、分野毎に変更があるかどうか判断し（Ｓ３４）、分野に変更点があると判断した場合には、そのＨＴＭＬファイルのページタイトルとその分野を一時記憶装置に記憶する（Ｓ３５）。次いで、１ページのＨＴＭＬファイル中の全ての分野を読み取ったかどうか判断し（Ｓ３６）、完了していなければＳ３２の手順から繰り返す。さらに、アップロードした全てのＨＴＭＬファイルを読み取ったかどうか判断し（Ｓ３８）、全てのＨＴＭＬファイルについて読取り及び比較が完了していなければＳ３１の手順から繰り返す。全てのＨＴＭＬファイルについて読取り及び比較が完了していればこの手順Ｓ４を終了する。なお、ホームページを構成する複数のＨＴＭＬファイルのうち、追加や削除されるＨＴＭＬファイルがある場合には、追加、削除等の状態を記録するようにしてもよい。
【００２８】次に、メールリストに登録された各メンバごとに必要とする分野の変更があったホームページのＨＴＭＬファイルのページタイトルを記載したメールを作成し、各メンバに送信する手順Ｓ６について、図８のフローチャートを用いて説明する。まず、上記Ｓ４の手順中Ｓ１４の手順で一時記憶装置に保存している変更のあったページタイトルと分野を読み出す（Ｓ４１）。次に、記憶装置に記憶している図１３に示す送信先メールリストからメンバＹｍのメールアドレスと必要とされる分野とを読み出す（Ｓ４２）。次いで、メンバＹｍが必要とする分野に変更があったかを判断する（Ｓ４３）。必要とされる分野で変更があった場合には、さらに、メールのあて先にメールリストから読み込んだメールアドレスを記入し（Ｓ４４）、メール本文にメンバＹｍが必要とする情報分野で変更のあったページタイトルを記入して（Ｓ４５）、メールを送信する（Ｓ４６）。そして、全てのメンバを読み取ったかどうか判断し（Ｓ４７）、完了していなければメンバ全員についてＳ４２の手順から繰り返す。これによってホームページのＨＴＭＬファイルをメンテナンスでアップロード時に、各メンバが必要とする分野で変更があった場合、その分野の変更情報を必要とするメンバに効率的に送信することができる。」（段落【００２７】及び【００２８】）
　してみると、引用例１には、
『「通知装置（１）」がＷＥＢサーバにＨＴＭＬファイルをアップロードし、そのアップロードが完了した時点で「ユーザ端末（２０）」に変更情報を通知する』
との発明が記載されている。
　
（２）引用例２
　原審の拒絶の理由で引用された引用例２には、図面とともに、以下の事項が記載されている。
（ｂ）「【請求項１０】通信ネットワークを介した通信を行う通信手段と、
予めアクセスアカウントを付与したコンテンツ送信装置に関する提供者情報を記憶する提供者情報データベースと、
上記通信手段に対して接続要求があった際に、上記提供者情報データベースを参照して、当該接続要求が、予めアクセスアカウントを付与したコンテンツ送信装置からの接続要求であるか否かを判別する判別手段と、
格納手段と、
上記判別手段の判別処理を行った上で、上記通信手段との間で通信接続されたコンテンツ送信装置から送信されてくるコンテンツを上記格納手段に格納するコンテンツ格納制御手段と、
上記通信手段との間で通信接続されたコンテンツ送信装置から送信されてきたコンテンツを、提供可能なコンテンツとして提示する提示手段と、
上記提示手段によって提示したコンテンツに対しての提供要求に応じて、上記通信手段により当該提供要求元に対してコンテンツを送信する送信制御手段と、
を備えたことを特徴とするサーバ装置。」（特許請求の範囲【請求項１】）
　
（ｃ）「【００６７】まず顧客Ａは、ビデオカメラ１を用いて撮像する（Ｓ１）。例えばビデオジャーナリストを想定した場合、事件現場の映像を撮像することなどがこの撮像手順に相当する。この撮像によって１つの映像コンテンツがビデオカメラ１において生成されることになる。撮像によって生成した映像コンテンツ、つまりＨＤＤ１８に記録されたコンテンツに対しては、ビデオカメラ１をそのまま用いて編集することができる（Ｓ２）。例えば簡単なカット編集を行って適当な長さの映像コンテンツを作る。そして顧客Ａは、撮像したコンテンツ、或いは編集を行ったコンテンツを、ＩＳＰ２にアップロードできる（Ｓ３）。このアップロードは、図３の構成のビデオカメラ１により、他の機器（パーソナルコンピュータ等）を用いることなく実行できる。即ちビデオカメラ１に付与されたインターネットアクセスアカウントを使ってインターネットに接続し、映像コンテンツをＩＳＰ２ににアップロードする。」（段落【００６７】）
　
（ｄ）「【０１００】ステップＦ１０５で送信した接続要求に対して、ＩＳＰ２側でアクセス許可となった場合は、システムコントローラ１１の処理はステップＦ１０９からＦ１１０に進み、ＩＳＰ２との間の通信接続を確立し、アップロード実行可能状態とする。そしてステップＦ１１１で、ユーザーが或るコンテンツを指定してアップロードする操作を行ったことを検出したら、ステップＦ１１２としてコンテンツのアップロードを実行する。即ちＨＤＤ１７からコンテンツを読み出して図８のストリームエンコード処理Ｊ６，送信処理Ｊ７を実行する。この際、もしＨＤＤ１８にコンテンツに対応するコメントファイルが存在すれば、そのコメントファイルも同時に送信する。また、ＨＤＤ１８に記録されているコンテンツが、マークイン／マークアウト情報による編集済のものであれば、コンテンツの再生時にはマークイン／マークアウト情報に応じた編集後の状態の映像ストリームとしての再生を行い、それに対してストリームエンコード処理Ｊ６，送信処理Ｊ７を実行することになる。」（段落【０１００】）
　
　してみれば、引用例２には、
『「ビデオカメラ（１）」から「ＩＳＰ（２）」に映像コンテンツをアップロードする』との発明が記載されている。
　
（３）引用例３
　原審の拒絶の理由として引用された引用例３には、図面とともに、以下の事項が記載されている。
（ｅ）「【請求項１】ＥＤＩによりネットワークを介した受発注を行う際に必要なデータを管理するＥＤＩデータ管理手段と、
前記ネットワークを介した端末装置からダウンロード要求を行う受注者に対応するデータを前記ＥＤＩデータ管理手段により抽出して、当該端末装置に送信するダウンロード手段と、
前記ネットワークを介した端末装置から受注者のアップロード要求がなされたデータを受信して、前記ＥＤＩデータ管理手段により当該受注者のデータを更新するアップロード手段と、
前記端末装置からの前記ダウンロード要求及びアップロード要求の認証を行う認証手段と、を備えることを特徴とするＥＤＩ受発注システム。」（特許請求の範囲【請求項１】）
　
（ｆ）「【００４１】〔アップロード〕アップロードの際の動作を、図９などを参照して説明する。なお、図９において、符号のＳは処理を意味する。
【００４２】まず受注者は、Ｗｅｂクライアント３０のＷＷＷブラウザプログラムによりＷｅｂＥＤＩサーバ１０にアクセスして認証を受けた後、図示しないアップロード用Ｗｅｂページを表示する（Ｓ３１）。そして、アップロードファイルを生成してアップロード要求に添付し、アップロード要求を行う（Ｓ３２）。アップロードファイルは、前記した注文諾否情報、納期回答情報、見積回答情報などのいずれか１つ以上である（図４（ｃ）参照）。これら情報は、ダウンロードされた注文情報などに応答して、受注者がアップロードするものである。
【００４３】ＷｅｂＥＤＩサーバ１０は、アップロード要求を受信するとＥＤＩサーバ２０に対してデータ更新要求を行う（Ｓ３４）。データ更新要求には、アップロードファイルが添付されている。ＥＤＩサーバ２０（データベース管理手段）は、データ更新要求に添付されたアップロードファイルを用いてＥＤＩデータベース（図４参照）の更新を行う（Ｓ３５）。更新は、取引先コードと手配番号が一致するＥＤＩデータベースのレコードが対象になる。ＥＤＩサーバ２０は、ＥＤＩデータベースの更新が完了すると更新完了通知をＷｅｂＥＤＩサーバ１０に送信する（Ｓ３６）。なお、アップロードファイルによる注文情報テーブルの更新は、図４（ｃ）のように行われる。ＷｅｂＥＤＩサーバは、更新完了通知を受信するとＷｅｂクライアント３０にアップロード完了通知を行う（Ｓ３７）。Ｗｅｂクライアント３０は、アップロード完了通知を行うと社内受発注データベースの更新を行い（Ｓ３８）、ＥＤＩサーバ２０のＥＤＩデータベースとのデータの整合などを図る。」（段落【００４１】−【００４３】）
　
　してみると、引用例３には、
『「Ｗｅｂクライアント（３０）」がアップロードする際に、アップロードファイルを作成して、「ＥＤＩ受発注システム（１）」にアップロード要求を行う』
との発明が記載されている。
　
（４）引用例４
　原査定の拒絶の理由として引用された引用例４には、図面とともに、以下の事項が記載されている。
（ｇ）「【請求項１８】前記支援プログラムは、
前記個人ファイル格納部へのアップロード要求があると、
アップロードする端末又はサーバからの前記ファイルを受信し、前記個人ファイル格納部に当該受信したファイルをその属性情報と共に格納した後に、ファイルアップロード完了通知を前記端末又は前記サーバに対して行う、手順を順次踏む、
ことを特徴とする請求項１５、１６又は１７に記載のファイルダウンロード支援プログラム。」（特許請求の範囲【請求項１８】）
　
　（ｈ）「【０１１３】図８は、本発明プログラムで実行される、ファイルサーバの動作についてのフロー図でであり、ファイルサーバの動作は、ＳＴ１〜ＳＴ２０の各ステップを実行することになる。ＳＴ１として、ファイルサーバＦＳａは、アップロード端末ＵＴ、サーバＳ群の何れかの接続、受取方法指示端末Ｔからの接続、又はダウンロード端末ＤＴからの接続を待機している。
【０１１４】ＳＴ２として、ＳＴ１の何れかの接続があると、「アップロード要求？」において、アップロード端末ＵＴ、サーバＳ群からのアップロード要求であるか否かをコマンド名から判断し、アップロード要求であれば順にＳＴ３〜ＳＴ６を行い、そうでなければＳＴ７へ進む。
【０１１５】［アップロード要求時の動作（ＳＴ３〜ＳＴ６）］ＳＴ３として、アップロード端末ＵＴ、サーバＳ群の何れかからのアップロード要求と共に送信されたユーザＩＤ及びパスワードを受信し、ユーザ認証を個人ファイル格納部ＦＳａ１へのアクセス権限があるか否かを判断する。
【０１１６】この判断は、ユーザ管理データベースＦＳａ２のユーザＩＤフィールド及びパスワードフィールドを参照し、受信したユーザＩＤ及びパスワードが存在するか否かにより行われ、ユーザ認証結果により、正当なユーザと判断された場合にはＳＴ４及びＳＴ５の各処理を行う一方で、不正なユーザと判断された場合にはＳＴ６の処理を行う。
【０１１７】ＳＴ４として、アップロード端末ＵＴ、サーバＳ群から、ファイルサーバＦＳａにアップロードされたファイルを受信し、ＳＴ３で認証したユーザＩＤと対応付けてファイルサーバＦＳａの個人ファイル格納部ＦＳａ１に保持する。その際に、ファイルの属性情報（ファイルサイズ、ファイル種別など）を同時に個人ファイル格納部ＦＳａ１にて保持する。
【０１１８】ＳＴ５として、アップロードを完了してことをＳＴ１でファイルサーバＦＳａにアクセスしてきたアップロード端末ＵＴ、サーバＳ群に通知する。ＳＴ６として、ユーザ認証エラーをＳＴ１でファイルサーバＦＳａにアクセスしてきたアップロード端末ＵＴ、サーバＳ群に返信する。」（段落【００１３】−【００１８】）
　
　してみると、引用例４には、
『「ファイルサーバ（ＦＳ）」からアップロードを要求した「アップロード端末（ＵＴ）」にアップロードの完了通知が送信される』
との発明が記載されている。
　
（５）周知例５
　拒絶査定において周知技術の一例として引用された特開２００３−６６９７８号（以下「周知例１」という。）には、図面とともに、以下の事項が記載されている。
（ｉ）「【請求項１】  通信カラオケシステムを利用した新譜案内メールの発送方法であって、つぎの事項（１）〜（４）によって特定される。
（１）前記通信カラオケシステムは、多数のカラオケ楽曲についてのカラオケデータと目次情報とをカラオケデータベースに集約・管理するカラオケホスト装置と、多数のカラオケ演奏端末とが通信回線網で結合されてなり、前記ホスト装置から各カラオケ演奏端末に配信されるカラオケデータを各端末にて蓄積して再生利用する。
（２）前記カラオケ演奏端末に対して選曲入力を行うために多数の顧客がそれぞれ個別に所持する顧客別リモコン送信器が存在し、各顧客別リモコン送信器にはそれぞれ固有のリモコンＩＤが割り当てられている。当該顧客別リモコン送信器は、選曲したカラオケ楽曲の楽曲ＩＤと前記リモコンＩＤとを含んだ送信信号を発生し、カラオケ演奏端末は前記楽曲ＩＤと前記リモコンＩＤとを対応付けして前記ホスト装置に適時に送信する。
（３）前記カラオケホスト装置は、多数の顧客の個人情報と各顧客がカラオケ装置にリクエストした楽曲の履歴を前記リモコンＩＤ別に整理した顧客データベースを管理し、多数の前記カラオケ演奏端末から集信した前記リモコンＩＤと楽曲ＩＤとに基づいて、当該顧客データベースにおける各顧客の欄の演奏履歴を更新する。
（４）前記カラオケホスト装置は、前記カラオケデータベースに新譜楽曲が追加登録されたのを受けて、その新譜楽曲の目次情報と前記顧客データベースにおける顧客別のリクエスト楽曲履歴とを対比することで前記新譜楽曲を好みそうな顧客を選出する顧客選出プロセスと、このプロセスにより選出した顧客のメールアドレスを前記顧客データベースから取得するとともに、前記新譜楽曲が登録された旨を知らせる電子メールを作成して前記メールアドレス宛に発送する新譜案内発送プロセスとを実行する。」（特許請求の範囲【請求項１】）
　
（ｊ）「【００２４】＝＝＝新譜案内メールの発送＝＝＝
カラオケホスト装置は、新譜楽曲のカラオケデータと目次情報とがカラオケデータベースに登録されたことを認知すると、それらのデータを各地のカラオケ演奏端末に配信する。そして、例えば「アーティスト○○の新譜××××がカラオケで歌えます」というような内容を本文に記載した新譜案内メールを作成し、新譜楽曲のアーティストをメール発送条件に設定している顧客の電子メールアドレスに宛てて新譜案内メールをインターネットに送出する。なお、新譜案内メールの発送タイミングは、本実施例では全てのカラオケ演奏端末への配信作業が完了した時点としている。図３に上述した新譜案内メールを特定の顧客に発送するための処理の流れ図を示した。」（段落【００２４】）
　
　してみると、周知例１には、
『カラオケホスト装置は、カラオケデータベースに新譜楽曲が追加登録をされると、前記新譜楽曲が登録された旨を知らせる電子メールを作成して顧客に通知する』
との事項が記載され、コンテンツの更新時に更新完了をクライアントに通知する旨の周知事項が開示されていると認められる。
　
　なお、同様に、拒絶査定において周知技術の一例として特開２００３−３７８３４号公報（以下「周知例２」という。）及び特開平２００３−１６２８７号公報（以下「周知例３」という。）が引用されているが、周知例１と同じ趣旨で引用されているので、記載事項については省略する。
　
 ５．当審の判断 
 　そこで、原査定の当否について各請求項に係る発明毎に検討する。 
 （１）請求項１−３に係る発明について
　本願の課題として「サーバが複数のコンテンツについてデータベースを更新したときのサーバとクライアントとの通信量を減らすこと」があげられており、この課題を解決するために本願の請求項１に係る発明では、アップローダが、更新要求手段が複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段を備え、サーバが、前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが、更新された旨の更新通知を前記クライアントに送信する更新通知手段を備えている。
　引用例１に記載された発明の「通知装置（１）」、「ＷＥＢ」は請求項１に係る発明の「アップローダ」、「サーバ」に相当し、同じく、引用例２に記載された事項「ビデオカメラ（１）」、「ＩＳＰ（２）」は」請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例３に記載された事項の「Ｗｅｂクライアント（３０）」、「ＥＤＩ受発注システム（１）」は請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例４に記載された事項の「アップロード端末（ＵＴ）」、「ファイルサーバ（ＦＳ）」は、請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例５に記載された事項の「カラオケ装置」は請求項１に係る発明の「サーバ」に相当する。
　この点を考慮して検討しても、アップローダが、更新要求手段が複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段を備え、サーバが、前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが、更新された旨の更新通知を前記クライアントに送信する更新通知手段を備える点は、引用例１−４及び周知例１−３のいずれにも記載されておらず、それらの記載からみて自明な事項とも認められない。
 また、引用例１−４及び周知例１−３に記載された事項を組み合わせたとしても上記の点を導出することはできない。
　そうすると、本願の請求項１に係る発明は引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたとする原査定の理由は維持できない。 
　請求項２、３は、請求項１の発明にさらに限定を加えたものであるから、請求項２、３に係る発明についても、引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたとする原査定の理由は維持できない。 
　
（２）請求項４−６に係る発明について
　請求項１に係る発明と同様に、本願の課題として「サーバが複数のコンテンツについてデータベースを更新したときのサーバとクライアントとの通信量を減らすこと」があげられており、この課題を解決するために本願の請求項４に係る発明では、サーバが、前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段を備えている。
　引用例１に記載された事項の「通知装置（１）」、「ＷＥＢ」は請求項１に係る発明の「アップローダ」、「サーバ」に相当し、同じく、引用例２に記載された事項「ビデオカメラ（１）」、「ＩＳＰ（２）」は請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例３に記載された事項の「Ｗｅｂクライアント（３０）」、「ＥＤＩ受発注システム（１）」は請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例４に記載された事項の「アップロード端末（ＵＴ）」、「ファイルサーバ（ＦＳ）」は、請求項１に係る発明の「アップローダ」、「サーバ」に相当し、引用例５に記載された事項の「カラオケ装置」は請求項１に係る発明の「サーバ」に相当する。
　これらの点を考慮して検討しても、サーバが、前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段を備える点は、引用例１−４及び周知例１−３のいずれにも記載されておらず、それらの記載からみて自明な事項とも認められない。
　また、引用例１−４及び周知例１−３に記載された事項を組み合わせたとしても上記の点を導出することはできない。
　そうすると、本願の請求項４に係る発明は引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたとする原査定の理由は維持できない。 
 　本願の請求項５に係る発明は、請求項１に係る発明にさらに限定を加えたものであり、本願の請求項６に係る発明は、請求項４又は５を引用したプログラムの発明であるから、請求項５、６に係る発明についても、引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたとする原査定の理由は維持できない。 
 　 
 ５．むすび 
　以上の理由により、本願の請求項１−６に係る発明は引用例１−４に記載された発明に基づいて当業者が容易に発明をすることができたものとすることはできない。 
 　また、他に本願を拒絶すべき理由を発見しない。 
　
 　よって、結論のとおり審決する。