• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1264709
審判番号 不服2010-14560  
総通号数 156 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-12-28 
種別 拒絶査定不服の審決 
審判請求日 2010-07-01 
確定日 2012-10-10 
事件の表示 特願2008-296890「データベースデータの同期」拒絶査定不服審判事件〔平成21年 5月21日出願公開、特開2009-110530〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 手続の経緯・本願発明
本願は、2002年4月24日(パリ条約による優先権主張2001年4月25日、米国)を国際出願日とする特願2002-584207号の一部を、平成20年11月20日に新たな特許出願(分割出願)としたものであって、平成22年3月5日付けで拒絶査定がされ(発送日:同年3月16日)、これに対して同年7月1日に審判の請求がなされたものである。そして、本願の請求項1に係る発明は、平成22年2月8日付けの手続補正書の特許請求の範囲の請求項1に記載された事項により特定される以下のとおりのものである(以下、「本願発明」という。)。

「データベース間の同期のためにトランスポート層コネクションを確立するステップと、
前記トランスポート層コネクションを使って、前記データベース間で実行された先の同期を記述する更新識別子を送信するステップと、
同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップと、
を有する方法であって、
前記データベース間で実行された前記先の同期を記述する第1更新識別子と、第1デバイスにより規定されかつ前記現在の同期を記述する第2更新識別子が、前記第1デバイスから第2デバイスへ送信され、
同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する、
方法。」

2 引用例及び周知例
(1) 引用発明
原査定の拒絶の理由に引用された、本願の優先日前である2000年(平成12年)12月7日に公開された「”SyncML Sync Protocol, version 1.0”,[online],2000年12月7日,p.7-13」 (以下、「引用例」という。)には、図面とともに、以下の事項が記載されている。(下線は当審付与。訳は当審訳。)

(ア) 7ページ3?5行
「This specification defines the protocol for different sync procedures, which can occur between a SyncML client and a SyncML server, in the form of message sequence charts (MSC's).」
(この仕様書は、SyncMLクライアントとSyncMLサーバとの間で発生し得る種々の同期手順のためのプロトコルをメッセージシーケンス図(MSC)の形で定義している。」

(イ) 7ページ12?13行
「The service and device are connected over some common network transport, such as HTTP.」
(そのサービスとデバイスはHTTPのような何らかの一般的なネットワークトランスポート上で接続されている。)

(ウ) 7ページ19行?8頁2行
「1.2 Device Roles
Figure 2 depicts a synchronization example in which a mobile phone acts as a SyncML client and a server acts as a SyncML server. The SyncML client sends SyncML message including the data modifications made in the client to the SyncML server. The server synchronizes the data (including possible additions, replaces, and deletions) within the SyncML messages with data stored in the server. After that, the SyncML server returns its modifications back to the SyncML client.」
(1.2 デバイスの役割
第2図は、携帯電話がSyncMLクライアントとして動作し、サーバがSyncMLサーバとして動作する同期の例を描写している。SyncMLクライアントは、そのクライアント内で発生したデータ変更を含むSyncMLメッセージをSyncMLサーバへ送信する。サーバは、そのSyncMLメッセージ内のデータ(可能性のある追加、置換、及び削除を含む)をサーバに記憶されたデータと同期させる。その後、SyncMLサーバは、自身の変更をSyncMLクライアントへ送り返す。)

(エ) 8ページ5?15行
「SyncML Client - This is the device that contains a sync client agent and that sends first its modifications to the server. The client must also be able to receive responses from the SyncML server. Although the SyncML client has always the role to send its modifications first, in some cases the server may have a role to initiate synchronization. The SyncML client is typically a mobile phone, PC, or PDA device.
SyncML Server - This is the device, which contains a sync server agent and sync engine, and which usually waits that the SyncML client starts synchronization and sends the clients modification to the server. The server is responsible for processing the sync analysis when it has received the client modifications. In addition, it may be able to initiate synchronization if unsolicited commands from the server to the client are supported on the transport protocol level. Typically, the SyncML server is a server device or PC.」
(SyncMLクライアント - これは、同期クライアント・エージェントを含むデバイスであり、その変更を最初にサーバに送信する。クライアントは、SyncMLサーバからの応答を受信することもできなければならない。SyncMLクライアントは、常にその変更を最初に送る役割を有するが、あるケースでは、サーバが同期を開始する役割を有しても良い。典型的には、SyncMLクライアントは、携帯電話か、PC、PDAデバイスである。
SyncMLサーバ - これは、同期サーバ・エージェントと同期エンジンを含むデバイスであり、通常、SyncMLクライアントが同期を開始してクライアント変更をサーバに送信するのを待つ。サーバは、クライアント変更を受信したとき、同期の解析を処理する責任を持つ。さらに、トランスポート・プロトコル・レベルで、サーバからクライアントへの、一方的に与えられる(unsolicited)コマンドがサポートされていれば、同期を開始することができるであろう。典型的には、SyncMLサーバは、サーバ・デバイスか、PCである。)

(オ) 10ページ16?22行
「2.2.1 Sync Anchors for Databases
To enable sanity checks of synchronization, this protocol uses sync anchors (See Definitions) associated with databases (e.g., a calendar database). There are two sync anchors, Last and Next (See Meta Information DTD [3]), which are always sent at the initialization of sync. The Last sync anchor describes the last event (e.g., time) when the database was synchronized from the point of sending device and the Next sync anchor describes the current event of sync from the point of sending device. Thus, both the client and the server send their own anchors to each other.」
(2.2.1 データベースのための同期アンカー
同期の健全性(sanity)チェックを可能にするために、このプロトコルはデータベース(例,カレンダーデータベース)と関連付けられた同期アンカー(定義参照)を使用する。ラストとネクストの2つの同期アンカーがあり(メタ情報DTD参照[3])、それらは同期の初期化時に常に送信される。ラスト同期アンカーは、送信デバイスの点からデータベースが同期化されたときの最後のイベント(例,時刻)を記述し、ネクスト同期アンカーは、送信デバイスの点からの同期の現在のイベントを記述する。このようにして、クライアントとサーバの両方がそれら自身のアンカーを互いに送信する。)

(カ) 10ページ27?29行
「The utilization of sync anchors is implementation specific but in order to enable the utilization, the Next sync anchor of another device needs to be stored until the next synchronization. The SyncML server MUST store the Next sync anchor sent by the client to enable this utilization.」
(同期アンカーの利用は実装依存であるが、利用を可能にするために、他のデバイスのネクスト同期アンカーは次回の同期まで記憶されている必要がある。SyncMLサーバは、この利用を可能にするために、クライアントによって送信されたネクスト同期アンカーを記憶しなければならない。)

(キ) 10ページ30?33行
「If the device stores the Next sync anchor, it is able to compare during the next synchronization whether the sync anchor is the same as the Last sync anchor sent by another device. If they are matching, the device is able to conclude that no failures have happened since last sync. If they are not matching, the device can request a special action from another device (e.g., slow sync).」
(もしデバイスがネクスト同期アンカーを記憶していれば、次回の同期の際に、その同期アンカーが他のデバイスによって送信されたラスト同期アンカーと同じであるか否かを比較することができる。もしそれらが一致していれば、デバイスは前回の同期以降に障害が発生しなかったと断定することができる。もしそれらが一致していなかったら、デバイスは他のデバイスから特別な動作(例,低速同期)を要求することができる。)

(ク) 10ページ34行
「The stored sync anchors must not be updated before the synchronization session is finished.」
(記憶された同期アンカーは同期セッションが終了する前に更新されてはならない。)

これらの引用例の記載から、引用例には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「SyncMLクライアントとSyncMLサーバとの間で発生し得る種々の同期手順のためのプロトコルにおいて、
そのサービスとデバイスはHTTPのような何らかの一般的なネットワークトランスポート上で接続されており、
SyncMLクライアントは、同期クライアント・エージェントを含むデバイスであり、その変更を最初にサーバに送信するものであり、
SyncMLサーバは、同期サーバ・エージェントと同期エンジンを含むデバイスであり、通常、SyncMLクライアントが同期を開始してクライアント変更をサーバに送信するのを待つものであり、
同期の健全性チェックを可能にするために、このプロトコルはデータベース(例、カレンダーデータベース)と関連付けられた同期アンカーを使用し、ラストとネクストの2つの同期アンカーがあり、それらは同期の初期化時に常に送信され、ラスト同期アンカーは、送信デバイスの点からデータベースが同期化されたときの最後のイベント(例、時刻)を記述し、ネクスト同期アンカーは、送信デバイスの点からの同期の現在のイベントを記述し、クライアントとサーバの両方がそれら自身のアンカーを互いに送信し、
同期アンカーの利用は実装依存であるが、利用を可能にするために、他のデバイスのネクスト同期アンカーは次回の同期まで記憶されている必要があり、SyncMLサーバは、この利用を可能にするために、クライアントによって送信されたネクスト同期アンカーを記憶しなければならず、
もしデバイスがネクスト同期アンカーを記憶していれば、次回の同期の際に、その同期アンカーが他のデバイスによって送信されたラスト同期アンカーと同じであるか否かを比較することができ、もしそれらが一致していれば、デバイスは前回の同期以降に障害が発生しなかったと断定することができ、もしそれらが一致していなかったら、デバイスは他のデバイスから特別な動作(例、低速同期)を要求することができ、
記憶された同期アンカーは同期セッションが終了する前に更新されてはならない、方法。」

(2) 周知例1(特開平4-291556号公報)
原査定の備考欄において周知例として引用された特開平4-291556号公報(以下、「周知例1」という。)には、図面とともに次の事項が記載されている。

(ケ) 段落【0001】-【0004】
「【0001】
【産業上の利用分野】本発明は計算機又は計算機と装置間を接続する場合の複数の通信制御処理を階層的に持つ通信制御方式に関する。図4は本発明の産業上の利用分野の説明図である。同図において、計算機A及び計算機Bはそれぞれ、第1層から第n層までの通信制御処理を階層的に持っている。第1層に近い層を下位層と称し、第n層に近い程上位層と称する。第1層に近い程、物理的なインタフェースに近く、第n層に近い程、ユーザのプログラムに近いインタフェースである。計算機Aと計算機Bの間の通信を終了させるためには、第n層から第1層までの全層における処理を終了させなければならない。これは、各層では、例えば、全通信状況を把握するためのメモリや、下位層での処理が終了するまでを監視するタイマ等が存在するので、各計算機は、全層における切断(解放)処理が終了するまでは、次の処理を実行できないからである。この全層における切断処理をできるだけ短時間に行うことが要望されている。
【0002】
【従来の技術】図5は従来の通信制御方式を説明するシーケンス図である。同図において、図面の簡単化のために、階層的な複数の通信制御処理層を第1層、第m層、及び第n層で代表して示してある。実際には、第1層の上位は第2層であり、第m層の上位は第(m+1)層であり、第n層の直下位の層は第(n-1)層である。
【0003】従来は、複数の通信制御処理を階層的に持つ計算機間又は計算機と端末間では、データ送受信開始時は、下位層の通信制御処理から通信路を確立していき、データ送受信終了時は上位層の通信制御処理から順に通信路を解放する処理を行っていた。即ち、データ送受信開始時は、計算機Aの第1層から計算機Bの第1層に対して、第1層の通信路確立要求信号ER(1)を送出し、これに応答して計算機Bの第1層から計算機Aの第1層に対して通信路確立確認信号EC(1)が返される。計算機AではEC(1)に応答して第1層の通信路確立通知信号EI(1)が第2層に送られ、それにより計算機Aの第2層から計算機Bの第2層に対して、第2層の通信路確立要求信号ER(2)を送出し、これに応答して計算機Bの第2層から計算機Aの第2層に対して通信路確立確認信号EC(2)が返される。これを順次繰り返して、最上位層の通信路確立確認信号EC(n)が計算機Aの第n層に通知されると、データ送受信が可能になる。
【0004】又、データ送受信終了時は、計算機Aの第n層から第n層の解放要求信号TR(n)が計算機Bの第n層に通知され、これに応答して、計算機Bの第n層から計算機Aの第n層に、解放確認信号TC(n)が通知される。この解放確認信号TC(n)に応答して、計算機Aの第n層から第(n-1)層に対し、第n層の解放通知信号が伝達される。これを受けた計算機Aの第(n-1)層では、第(n-1)層の解放要求信号TR(n-1)が計算機Bの第(n-1)層に通知され、これに応答して、計算機Bの第(n-1)層から計算機Aの第(n─1)層に、解放確認信号TC(n-1)が通知される。この解放確認信号TC(n-1)に応答して、計算機Aの第(n-1)層から第(n-2)層に対し、第(n-1)層の解放通知信号が伝達される。これを繰り返して、計算機Aの第1層が解放確認信号TC(1)を受信したときに、計算機Aと計算機Bの間の切断処理が完了する。」

(コ) 段落【0010】-【0016】
「【0010】
【作用】所定の下位層より下位の層でのみ、自局1と相手局2との間での通信路解放処理を行うので、所定の下位層以上の中位層及び上位層での通信制御処理における自局1と相手局2との間の通信路解放処理が不要になり、同一局内での層間の解放通知信号の通知や解放確認信号の通知はなんら複雑な手順ではなく短時間で済むので、所定の下位層より下位の層でのみの自局1と相手局2との間での通信路解放処理により、実質的に全層の通信処理の通信路解放とみなすことができる。
【0011】通常通信処理中の下位層通信処理の通信障害と分区別するために、所定の下位層以上の層の通信処理で通信終了時に、その層の一つ下の層に解放通知(通信終了指示)を渡す事とし、解放通知(通信終了指示)を当該一つ下の層に渡してから一定時間内の当該一つ下の層からの終了処理による使用不可通知を障害と見なさない様にするか、もしくは、当該一つ下の層から解放確認信号をその層に通知する事により障害との切り分けを行う。
【0012】上記において、最上位層における通信終了の検出時期は、相手との終了手順完了時でもよいし、必要データの送受信完了時でもよい。
【0013】
【実施例】図2は本発明の実施例による通信制御方式の通信路の確立・解放手順を示すシーケンス図である。同図において、ER(X)はX層の確立要求信号、EC(X)はX層の確立確認信号、EI(X)はX層の確立通知信号、TR(X)はX層の解放要求信号、TE(X)はX層の解放確認信号、TI(X)はX層の解放通知信号、TC(X)はX層の解放確認信号である。通信路確立手順は従来と同様であるので、説明を省略する。
【0014】データ通信終了後の通信路の解放手順は以下の通りである。まず、計算機1及び2のそれぞれにおいて、第n層は相手局の第n層に解放を要求する(又は表示する)解放要求信号を送出せず、自局の第(n-1)層に対してのみ第n層の解放通知TI(n)を出す。図においては、簡単のために、第(n-1)層を第m層としている。第m層は第n層からの解放通知TI(n)を受け、自層での解放手順を行う。第m層は自局の第(m-1)層に対してのみ第m層の解放通知TI(m)を出す。以下、同様の解放通知を第(m-1)層から順次第3層まで送る。
【0015】第3層から解放通知TI(3)をうけ取った第2層は、相手局2の第2層との間で解放手順を実行するこの解放手順は従来の各層における解放手順と同様であり、自局の第2層から相手局の第2層に解放要求信号を送出し、相手局2の第2層から解放確認信号TC(2)を受け取ったあと、第2層の下位層である第1層に対し解放通知信号TI(2)を出す。
【0016】下位層に対し解放通知信号TI(2)を出す前に、下位層から切断信号を受けた場合は、下位層の障害とみなす。本実施例では、相手局の層との間で実際に解放手順を行う層を第2、第1層にしているが、第1層だけでも同様の効果が得られる。自局と相手局との間で実際に解放手順を実行する下位層の数は、その通信系が必要とする最低限の層の数により定まる。」

(サ) 図2
【図2】には、計算機1の第2層が、計算機2の第2層から解放確認信号TC(2)を受け取ると、第m層に解放確認信号TE(2)を送出する旨が図示されている。

上記(ケ)、(コ)の記載、上記(サ)の事項及び関連する図面を参照すると、周知例1には、次の技術が記載されているものと認められる。(以下、「周知例1記載の技術」という。)
「複数の通信制御処理を階層的に持つ通信制御方式において、自局と相手局との間の通信を終了させるためには、第n層から第1層までの全層における処理を終了させなければならないので、各層では、下位層の処理が終了するまでを監視するタイマ等を備えており、従来、データ送受信終了時は上位層の通信制御処理から順に通信路を解放する処理を行っていたこと、及びこれに替えて、上位層において、通信完了時に、自局の下位層に対して「解放通知信号TI」を送出し、該下位層が、従来の各層における解放手順と同様に、相手局に「解放要求信号TR」を送出し、相手局から「解放確認信号TC」を受け取ると、自局の前記上位層に対して「解放確認信号TE」を送出し、前記上位層が、前記下位層からの前記「解放確認信号TE」を受信したことによって当該上位層の通信路解放とみなすこと。」

(3) 周知例2(特開平10-107737号公報)
(シ) 段落【0002】-【0004】
「【0002】
【従来の技術】従来、この種のシリアル赤外線通信装置においては、シリアル赤外線通信機構(以下、Irポートとする)と、IrLAP(IrDA Link Access Protocol)層と、IrLMP(IrDA Link Management Protocol)層と、上位層ソフトウエア(以下、上位層とする)とを有し、シリアル赤外線通信によって相手装置との通信を行っている。
【0003】IrLAP層はIrDAが提唱する標準化の規定であり、赤外線通信の高速性と信頼性とを確保するためにHDLC(High Level Data Link Control Procedure:ハイレベルデータリンク制御手順)に似た通信手順の管理を行うプロトコルレイヤである。
【0004】IrLMP層はIrLAP層の上位層であり、複数の装置との接続を行うためにセッションや接続する相手の固有情報サービスを管理するプロトコルレイヤである。上位層はIrLAP層及びIrLMP層が提供するサービスを利用して相手装置との通信を行うためのものである。」

(ス) 段落【0022】-【0029】
「【0022】
【発明が解決しようとする課題】

・・・(中略)・・・

【0023】また、上位層、IrLMP層、IrLAP層の各層は送信処理及び切断処理の完了を待ち合わせるようなインタフェースを有していないので、装置Aの上位層及びIrLMP層は夫々切断要求を下位層に発行した時点で、送信処理が完了したものと認識している。
【0024】例えば、装置Aから装置Bにデータ転送を行った後に切断する際、装置Bが受信バッファフル状態のためにデータを受取ることができない場合の動作を図13に示す。
【0025】図13において、装置Aの上位層からの送信要求(1)からデータフレーム送信(3)までの動作は図12のシーケンスと同一である.ここで、装置Bがバッファフル状態であるためにデータフレーム(3)を受信することができなかったとする。その時、装置BのIrLAP層はビジー状態を装置Aに知らせるため、RNRフレーム(4)を応答する。RNRフレームを受信した装置AのIrLAP層はデータフレームの再送(5)を行う。
【0026】装置Aの上位層はIrLAP層がそのような再送処理を行っていることを知る手段がなく、送信処理の完了を待ち合わせることもないため、送信処理が完了しているものとして、切断要求(6)を発行する。
【0027】IrLMP層もまたIrLAP層の再送処理を知ることがないので、IrLMPレベルの切断要求のためにData.request(7)を発行する。IrLAP層はデータフレーム(5)の再送処理中であるから、Data.request(7)によって受取ったIrLMPレベルの切断要求であるデータフレーム(41)は再送処理が完了するまで送信が待たされる。
【0028】同様に、IrLMPレベル(審決注:「IrLMPレベル」とあるのは「IrLAPレベル」の誤記と認める。)の切断要求であるDisconnect.indication(42)によるDISCフレーム(43)もまたデータフレーム(5),(41)の送信処理が完了するまで、送信を待たされることになる。
【0029】上述したように、切断要求は処理の完了を待ち合わせることがないため、装置Aの上位層では切断処理が完了したものと認識する。ところが、実際は装置BがIrLMPレベルの切断要求(41)さえも受取っていない。すなわち、装置Bにとってはリンクが接続状態にあり、装置A、装置B間でリンクの状態の認識が食い違うという問題が発生する。」

上記(シ)、(ス)の記載及び関連する図面を参照すると、周知例2には、次の技術が記載されているものと認められる。(以下、「周知例2記載の技術」という。)

「上位層が、下位層が提供するサービスを利用して、装置A、B間で通信を行う際、装置Aの上位層が、より下位層の切断処理の完了を待ち合わせしない場合には、実際は下位層の切断処理が完了していない状態でも、装置A上位層では切断処理が完了したと認識するという問題が発生すること。」

(4) 周知例3(特開平1-136263号公報)
(セ) 2ページ左上欄1-10行
「〔従来の技術〕
従来、国際標準化機構(ISO)の解放型システム間相互接続(OSI)のような、階層化された通信規約を実行する計算機システムでは、各層の通信手順を実行する通信制御プログラムが個々にバッファ領域を持ち、ある層を実行する通信制御プログラムから他の層を実行する通信制御プログラムへデータを受け渡す場合には、それらのバッファ領域間で、データを転送する方式が一般的である。」

(ソ) 2ページ右上欄13-20行
「特にOSIのトランスポート層のように下位層で複数の経路の選択ができ、同一データの再送処理を下位層と上位層で行う場合には、相手からの受理応答だけでは下位層の再送処理が終わっているかどうかを判定できない。
このため、バッファ領域の解放は、下位層の送信完了通知と相手システムからの受理応答の両方がそろった時点で行なわなければならなくなり制御が複雑になる。」

(タ) 2ページ右下欄4-8行
「さらに、バッファ管理情報域にそのバッファ領域の管理を行う階層に対応する番号を付加し、バッファの使用状態を各層の通信制御プログラムが独立に知ることができこれを制御できるので、複雑なバッファ解放待ち合わせ制御が不要となる。」

上記(セ)-(タ)の記載及び関連する図面を参照すると、周知例3には、次の技術が記載されているものと認められる。(以下、「周知例3記載の技術」という。)

「従来、OSIのような階層化された通信規約を実行する計算機システムでは、特にOSIのトランスポート層のように、同一データの再送処理を下位層と上位層で行う場合には、相手からの受理応答だけでは下位層の再送処理が終わっているかどうかを判定できないため、バッファ領域の解放処理は、下位層の送信完了通知と相手システムからの受理応答の両方がそろった時点で行なわなければならないこと。」

3 対比
(1) 引用発明は、例えば「カレンダーデータベース」などについての、クライアントとサーバ間での「同期手順のためのプロトコル」であって、「そのサービスとデバイスはHTTPのような何らかの一般的なネットワークトランスポート上で接続され」ているから、デバイス間でのネットワークトランスポート上の接続を用いる前提として、クライアントとサーバ間で、トランスポート層コネクションを確立していると解される。
よって、引用発明は、本願発明の「データベース間の同期のためにトランスポート層コネクションを確立するステップ」に相当するステップを備えるといえる。

(2) 引用発明の「ラスト同期アンカー」は、最後に、すなわち直前に実行された同期を識別するために、時刻などを記述するものであるから、本願発明の「前記データベース間で実行された先の同期を記述する更新識別子(第1更新識別子)」に相当する。
よって、クライアントとサーバ間が「HTTPのような何らかの一般的なネットワークトランスポート上で接続され」、「ラストとネクストの2つの同期アンカーがあり、それらは同期の初期化時に常に送信され」る引用発明における、「ラスト同期アンカー」を送信する動作は、本願発明の「前記トランスポート層コネクションを使って、前記データベース間で実行された先の同期を記述する更新識別子を送信するステップ」に相当する。

(3) 引用発明における「クライアント」及び「サーバ」は、いずれも「デバイス」であるから、それぞれ、本願発明における「第1デバイス」及び「第2デバイス」に相当する。
引用発明の「ネクスト同期アンカー」は、「送信デバイスの点からの同期の現在のイベントを記述」するものであるから、本願発明の「第1デバイスにより規定されかつ現在の同期を記述する更新識別子(第2更新識別子)」に相当する。
よって、引用発明において、「ラストとネクストの2つの同期アンカーがあり、それらは同期の初期化時に常に送信され」、「クライアントとサーバの両方がそれら自身のアンカーを互いに送信」することは、本願発明の「前記データベース間で実行された前記先の同期を記述する第1更新識別子と、第1デバイスにより規定されかつ前記現在の同期を記述する第2更新識別子が、前記第1デバイスから第2デバイスへ送信され」に相当する。

(4) 引用発明において、「記憶された同期アンカーは同期セッションが終了する前に更新されてはならない」から、当該同期セッションが終了した後のいつかの時点で、記憶された同期アンカーを更新することは自明である。
そして、上記同期アンカーの更新とは、クライアント及びサーバに記憶された、最後に実行された同期を記述する「ラスト同期アンカー」の内容を、それぞれ、現在の同期を記述する「ネクスト同期アンカー」の内容で更新することであると解される。
よって、引用発明において、記憶された同期アンカーは同期セッションが終了する前に更新せず、当該同期セッションが終了した後のいつかの時点で記憶された同期アンカーを更新することは、本願発明の「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する」ことと、「同期処理が実行され、この後、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する」点で一致する。

(5) 上記(4)記載のように、引用発明の同期アンカーの更新動作は、本願発明の「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップ」と、「同期処理が実行され、この後、現在の同期を記述する更新識別子を記憶するステップ」である点で一致する。

したがって、本願発明と引用発明の一致点、相違点は、以下のとおりである。

[一致点]
「データベース間の同期のためにトランスポート層コネクションを確立するステップと、
前記トランスポート層コネクションを使って、前記データベース間で実行された先の同期を記述する更新識別子を送信するステップと、
同期処理が実行され、この後、現在の同期を記述する更新識別子を記憶するステップと、
を有する方法であって、
前記データベース間で実行された前記先の同期を記述する第1更新識別子と、第1デバイスにより規定されかつ前記現在の同期を記述する第2更新識別子が、前記第1デバイスから第2デバイスへ送信され、
同期処理が実行され、この後、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する、
方法。」

[相違点]
本願発明は、「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップ」を備え、また、「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する」のに対して、引用発明は、記憶された同期アンカーは同期セッションが終了した後のいつかの時点で更新されるものの、同期処理が実行され、この後、「前記トランスポート層コネクションが正しく終了した場合」に、現在の同期を記述する更新識別子を記憶するステップを備えて、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新することは記載が無い点。

4 当審の判断
[相違点について]
上記周知例1-周知例3に見られるように、一般に、複数の階層からなる通信制御方式において、上位層が通信を終える際、下位層の通信の完了を監視したり待ち合わせすることは、適宜に行われていることにすぎない(上記「周知例1記載の技術」-「周知例3記載の技術」参照。)。
引用発明は、上位層であるクライアントとサーバ間の同期のための通信手順を、HTTPなどの、ネットワークトランスポートという下位層が運搬するものであるから、上記周知例1-3記載の技術を上記引用発明に適用できない理由はない。
さらに、引用発明のSyncML同期プロトコルの仕様書では、「同期アンカーの利用は実装依存」であって、「記憶された同期アンカーは同期セッションが終了する前に更新されてはならない」と規定するのみであるから、当該同期セッションが終了した後のどのような時点で同期アンカーを更新するかは、当業者が適宜選択すべき設計的事項と認められる。
してみれば、引用発明の同期セッションが終了した後の時点について、セッションとは二つのシステム間で実行される通信の論理的な接続の開始から終了までのことであって、セッションの確立と解放のやり取りをするものであり、上位層が通信を終える際、下位層の通信の完了を監視したり待ち合わせする上記周知例1-3記載の周知技術を適用して、さらに、一般に、下位層の通信が正常終了する場合と異常終了する場合とがあることを考慮することで、同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップ」を備えるとともに、「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第1更新識別子の内容を、第2更新識別子の内容で更新する」ようにすることは、当業者が容易に想到し得ることである。

そして、本願発明のように構成したことによる効果も引用発明、及び、周知技術から予測できる程度のものである。

5 むすび
したがって、本願発明は、引用発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2012-05-09 
結審通知日 2012-05-15 
審決日 2012-05-28 
出願番号 特願2008-296890(P2008-296890)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 上嶋 裕樹野田 佳邦  
特許庁審判長 和田 志郎
特許庁審判官 甲斐 哲雄
稲葉 和生
発明の名称 データベースデータの同期  
代理人 下道 晶久  
代理人 森 啓  
代理人 青木 篤  
代理人 鶴田 準一  

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