【事件の表示】
　特願２００８−２９６８９０「データベースデータの同期」拒絶査定不服審判事件〔平成２１年　５月２１日出願公開、特開２００９−１１０５３０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯・本願発明　
　本願は、２００２年４月２４日（パリ条約による優先権主張２００１年４月２５日、米国）を国際出願日とする特願２００２−５８４２０７号の一部を、平成２０年１１月２０日に新たな特許出願（分割出願）としたものであって、平成２２年３月５日付けで拒絶査定がされ（発送日：同年３月１６日）、これに対して同年７月１日に審判の請求がなされたものである。そして、本願の請求項１に係る発明は、平成２２年２月８日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される以下のとおりのものである（以下、「本願発明」という。）。
　
「データベース間の同期のためにトランスポート層コネクションを確立するステップと、
　前記トランスポート層コネクションを使って、前記データベース間で実行された先の同期を記述する更新識別子を送信するステップと、
　同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップと、
を有する方法であって、
　前記データベース間で実行された前記先の同期を記述する第１更新識別子と、第１デバイスにより規定されかつ前記現在の同期を記述する第２更新識別子が、前記第１デバイスから第２デバイスへ送信され、
　同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第１更新識別子の内容を、第２更新識別子の内容で更新する、
方法。」
　
２　引用例及び周知例 
（１）　引用発明　
　原査定の拒絶の理由に引用された、本願の優先日前である２０００年（平成１２年）１２月７日に公開された「”ＳｙｎｃＭＬ　Ｓｙｎｃ　Ｐｒｏｔｏｃｏｌ，　ｖｅｒｓｉｏｎ　１．０”，［ｏｎｌｉｎｅ］，２０００年１２月７日，ｐ．７−１３」 （以下、「引用例」という。）には、図面とともに、以下の事項が記載されている。（下線は当審付与。訳は当審訳。）
　
（ア）　７ページ３〜５行
「This specification defines 
the protocol for different sync procedures, which can occur between a SyncML client and a SyncML server
（この仕様書は、
SyncMLクライアントとSyncMLサーバとの間で発生し得る種々の同期手順のためのプロトコル
　
（イ）　７ページ１２〜１３行
「
The service and device are connected over some common network transport, such as HTTP
（
そのサービスとデバイスはHTTPのような何らかの一般的なネットワークトランスポート上で接続されて
　
（ウ）　７ページ１９行〜８頁２行
「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.」
（１．２　デバイスの役割
　第２図は、携帯電話がSyncMLクライアントとして動作し、サーバがSyncMLサーバとして動作する同期の例を描写している。SyncMLクライアントは、そのクライアント内で発生したデータ変更を含むSyncMLメッセージをSyncMLサーバへ送信する。サーバは、そのSyncMLメッセージ内のデータ（可能性のある追加、置換、及び削除を含む）をサーバに記憶されたデータと同期させる。その後、SyncMLサーバは、自身の変更をSyncMLクライアントへ送り返す。）
　
（エ）　８ページ５〜１５行
「
SyncML Client
is the device that contains a sync client agent and that sends first its modifications to the server
SyncML Server
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
（
SyncMLクライアント
は、同期クライアント・エージェントを含むデバイスであり、その変更を最初にサーバに送信
SyncMLサーバ
は、同期サーバ・エージェントと同期エンジンを含むデバイスであり、通常、SyncMLクライアントが同期を開始してクライアント変更をサーバに送信するのを待
　
（オ）　１０ページ１６〜２２行
「2.2.1 Sync Anchors for Databases
To enable sanity checks of synchronization, this protocol uses sync anchors 
associated with databases (e.g., a calendar database)
here are two sync anchors, Last and Next
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
the Next sync anchor describes the current event of sync from the point of sending device
both the client and the server send their own anchors to each other
（２．２．１　データベースのための同期アンカー
　
同期の健全性
チェックを可能にするために、このプロトコルはデータベース（例，カレンダーデータベース）と関連付けられた同期アンカー
を使用
ラストとネクストの２つの同期アンカーがあり
それらは同期の初期化時に常に送信され
ラスト同期アンカーは、送信デバイスの点からデータベースが同期化されたときの最後のイベント（例，時刻）を記述し
ネクスト同期アンカーは、送信デバイスの点からの同期の現在のイベントを記述
クライアントとサーバの両方がそれら自身のアンカーを互いに送信
　
（カ）　１０ページ２７〜２９行
「
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サーバは、この利用を可能にするために、クライアントによって送信されたネクスト同期アンカーを記憶しなければなら
　
（キ）　１０ページ３０〜３３行
「
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
（
もしデバイスがネクスト同期アンカーを記憶していれば、次回の同期の際に、その同期アンカーが他のデバイスによって送信されたラスト同期アンカーと同じであるか否かを比較することができ
もしそれらが一致していれば、デバイスは前回の同期以降に障害が発生しなかったと断定することができ
もしそれらが一致していなかったら、デバイスは他のデバイスから特別な動作（例，低速同期）を要求することができ
　
（ク）　１０ページ３４行
「
The stored sync anchors must not be updated before the synchronization session is finished
（
記憶された同期アンカーは同期セッションが終了する前に更新されてはならない
　
　これらの引用例の記載から、引用例には次の発明（以下、「引用発明」という。）が記載されていると認められる。 
　
「SyncMLクライアントとSyncMLサーバとの間で発生し得る種々の同期手順のためのプロトコルにおいて、　
　そのサービスとデバイスはHTTPのような何らかの一般的なネットワークトランスポート上で接続されており、
　SyncMLクライアントは、同期クライアント・エージェントを含むデバイスであり、その変更を最初にサーバに送信するものであり、
　SyncMLサーバは、同期サーバ・エージェントと同期エンジンを含むデバイスであり、通常、SyncMLクライアントが同期を開始してクライアント変更をサーバに送信するのを待つものであり、
　同期の健全性チェックを可能にするために、このプロトコルはデータベース（例、カレンダーデータベース）と関連付けられた同期アンカーを使用し、ラストとネクストの２つの同期アンカーがあり、それらは同期の初期化時に常に送信され、ラスト同期アンカーは、送信デバイスの点からデータベースが同期化されたときの最後のイベント（例、時刻）を記述し、ネクスト同期アンカーは、送信デバイスの点からの同期の現在のイベントを記述し、クライアントとサーバの両方がそれら自身のアンカーを互いに送信し、
　同期アンカーの利用は実装依存であるが、利用を可能にするために、他のデバイスのネクスト同期アンカーは次回の同期まで記憶されている必要があり、SyncMLサーバは、この利用を可能にするために、クライアントによって送信されたネクスト同期アンカーを記憶しなければならず、
　もしデバイスがネクスト同期アンカーを記憶していれば、次回の同期の際に、その同期アンカーが他のデバイスによって送信されたラスト同期アンカーと同じであるか否かを比較することができ、もしそれらが一致していれば、デバイスは前回の同期以降に障害が発生しなかったと断定することができ、もしそれらが一致していなかったら、デバイスは他のデバイスから特別な動作（例、低速同期）を要求することができ、
　記憶された同期アンカーは同期セッションが終了する前に更新されてはならない、方法。」
　
（２）　周知例１（特開平４−２９１５５６号公報）
　原査定の備考欄において周知例として引用された特開平４−２９１５５６号公報（以下、「周知例１」という。）には、図面とともに次の事項が記載されている。
　
（ケ）　段落【０００１】−【０００４】
「【０００１】
【産業上の利用分野】本発明は計算機又は計算機と装置間を接続する場合の
複数の通信制御処理を階層的に持つ通信制御方式に関する
計算機Ａと計算機Ｂの間の通信を終了させるためには、第ｎ層から第１層までの全層における処理を終了させなければならない
各層では、例えば、
下位層での処理が終了するまでを監視するタイマ等が存在する
【０００２】
【従来の技術】図５は従来の通信制御方式を説明するシーケンス図である。同図において、図面の簡単化のために、階層的な複数の通信制御処理層を第１層、第ｍ層、及び第ｎ層で代表して示してある。実際には、第１層の上位は第２層であり、第ｍ層の上位は第（ｍ＋１）層であり、第ｎ層の直下位の層は第（ｎ−１）層である。
【０００３】従来は、複数の通信制御処理を階層的に持つ計算機間又は計算機と端末間では、データ送受信開始時は、下位層の通信制御処理から通信路を確立していき、
データ送受信終了時は上位層の通信制御処理から順に通信路を解放する処理を行っていた
【０００４】又、データ送受信終了時は、計算機Ａの第ｎ層から第ｎ層の解放要求信号ＴＲ（ｎ）が計算機Ｂの第ｎ層に通知され、これに応答して、計算機Ｂの第ｎ層から計算機Ａの第ｎ層に、解放確認信号ＴＣ（ｎ）が通知される。この解放確認信号ＴＣ（ｎ）に応答して、計算機Ａの第ｎ層から第（ｎ−１）層に対し、第ｎ層の解放通知信号が伝達される。これを受けた計算機Ａの第（ｎ−１）層では、第（ｎ−１）層の解放要求信号ＴＲ（ｎ−１）が計算機Ｂの第（ｎ−１）層に通知され、これに応答して、計算機Ｂの第（ｎ−１）層から計算機Ａの第（ｎ─１）層に、解放確認信号ＴＣ（ｎ−１）が通知される。この解放確認信号ＴＣ（ｎ−１）に応答して、計算機Ａの第（ｎ−１）層から第（ｎ−２）層に対し、第（ｎ−１）層の解放通知信号が伝達される。
これを繰り返して、計算機Ａの第１層が解放確認信号ＴＣ（１）を受信したときに、計算機Ａと計算機Ｂの間の切断処理が完了する
　
（コ）　段落【００１０】−【００１６】
「【００１０】 
 【作用】
所定の下位層より下位の層でのみ、自局１と相手局２との間での通信路解放処理を行う
同一局内での層間の解放通知信号の通知や解放確認信号の通知はなんら複雑な手順ではなく短時間で済む
所定の下位層より下位の層でのみの自局１と相手局２との間での通信路解放処理により、実質的に全層の通信処理の通信路解放とみなすことができる
 【００１１】通常通信処理中の下位層通信処理の通信障害と分区別するために、所定の下位層以上の層の通信処理で通信終了時に、その層の一つ下の層に解放通知（通信終了指示）を渡す事とし、解放通知（通信終了指示）を当該一つ下の層に渡してから一定時間内の当該一つ下の層からの終了処理による使用不可通知を障害と見なさない様にするか、もしくは、
当該一つ下の層から解放確認信号をその層に通知する事により
 【００１２】上記において、最上位層における通信終了の検出時期は、相手との終了手順完了時でもよいし、必要データの送受信完了時でもよい。
 【００１３】 
 【実施例】図２は本発明の実施例による通信制御方式の通信路の確立・解放手順を示すシーケンス図である。同図において、ＥＲ（Ｘ）はＸ層の確立要求信号、ＥＣ（Ｘ）はＸ層の確立確認信号、ＥＩ（Ｘ）はＸ層の確立通知信号、ＴＲ（Ｘ）はＸ層の解放要求信号、ＴＥ（Ｘ）はＸ層の解放確認信号、ＴＩ（Ｘ）はＸ層の解放通知信号、ＴＣ（Ｘ）はＸ層の解放確認信号である。通信路確立手順は従来と同様であるので、説明を省略する。
 【００１４】
データ通信終了後の通信路の解放手順は以下の通りである
 【００１５】
第３層から解放通知ＴＩ（３）をうけ取った第２層は、相手局２の第２層との間で解放手順を実行する
解放手順は従来の各層における解放手順と同様であり、自局の第２層から相手局の第２層に解放要求信号を送出し
相手局２の第２層から解放確認信号ＴＣ（２）を受け取った
 【００１６】下位層に対し解放通知信号ＴＩ（２）を出す前に、下位層から切断信号を受けた場合は、下位層の障害とみなす。本実施例では、相手局の層との間で実際に解放手順を行う層を第２、第１層にしているが、第１層だけでも同様の効果が得られる。自局と相手局との間で実際に解放手順を実行する下位層の数は、その通信系が必要とする最低限の層の数により定まる。」 
 　 
（サ）　図２
　【図２】には、
計算機１の第２層が、計算機２の第２層から解放確認信号ＴＣ（２）を受け取ると、第ｍ層に解放確認信号ＴＥ（２）を送出する旨
 　 
 　上記（ケ）、（コ）の記載、上記（サ）の事項及び関連する図面を参照すると、周知例１には、次の技術が記載されているものと認められる。（以下、「周知例１記載の技術」という。） 
 「複数の通信制御処理を階層的に持つ通信制御方式において、自局と相手局との間の通信を終了させるためには、第ｎ層から第１層までの全層における処理を終了させなければならないので、各層では、下位層の処理が終了するまでを監視するタイマ等を備えており、従来、データ送受信終了時は上位層の通信制御処理から順に通信路を解放する処理を行っていたこと、及びこれに替えて、上位層において、通信完了時に、自局の下位層に対して「解放通知信号ＴＩ」を送出し、該下位層が、従来の各層における解放手順と同様に、相手局に「解放要求信号ＴＲ」を送出し、相手局から「解放確認信号ＴＣ」を受け取ると、自局の前記上位層に対して「解放確認信号ＴＥ」を送出し、前記上位層が、前記下位層からの前記「解放確認信号ＴＥ」を受信したことによって当該上位層の通信路解放とみなすこと。」 
　
（３）　周知例２（特開平１０−１０７７３７号公報）
（シ）　段落【０００２】−【０００４】
「【０００２】
【従来の技術】従来、この種のシリアル赤外線通信装置においては、シリアル赤外線通信機構（以下、Ｉｒポートとする）と、
ＩｒＬＡＰ（ＩｒＤＡ  Ｌｉｎｋ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）層
ＩｒＬＭＰ（ＩｒＤＡ  Ｌｉｎｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）層と
上位層ソフトウエア（以下、上位層とする）とを有し
【０００３】ＩｒＬＡＰ層はＩｒＤＡが提唱する標準化の規定であり、赤外線通信の高速性と信頼性とを確保するためにＨＤＬＣ（Ｈｉｇｈ  Ｌｅｖｅｌ  Ｄａｔａ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｐｒｏｃｅｄｕｒｅ：ハイレベルデータリンク制御手順）に似た通信手順の管理を行うプロトコルレイヤである。
【０００４】
ＩｒＬＭＰ層はＩｒＬＡＰ層の上位層であり
上位層はＩｒＬＡＰ層及びＩｒＬＭＰ層が提供するサービスを利用して相手装置との通信を行う
　
（ス）　段落【００２２】−【００２９】
「【００２２】
【発明が解決しようとする課題】
　　　
　　　・・・（中略）・・・
　　　
【００２３】また、
上位層、ＩｒＬＭＰ層、ＩｒＬＡＰ層の各層は
切断処理の完了を待ち合わせるようなインタフェースを有していないので、装置Ａの上位層及びＩｒＬＭＰ層は夫々切断要求を下位層に発行した時点で、送信処理が完了したものと認識している
【００２４】例えば、装置Ａから装置Ｂにデータ転送を行った後に切断する際、装置Ｂが受信バッファフル状態のためにデータを受取ることができない場合の動作を図１３に示す。
【００２５】図１３において、装置Ａの上位層からの送信要求（１）からデータフレーム送信（３）までの動作は図１２のシーケンスと同一である．ここで、装置Ｂがバッファフル状態であるためにデータフレーム（３）を受信することができなかったとする。その時、装置ＢのＩｒＬＡＰ層はビジー状態を装置Ａに知らせるため、ＲＮＲフレーム（４）を応答する。ＲＮＲフレームを受信した装置ＡのＩｒＬＡＰ層はデータフレームの再送（５）を行う。
【００２６】
装置Ａの上位層はＩｒＬＡＰ層がそのような再送処理を行っていることを知る手段がなく、送信処理の完了を待ち合わせることもないため、送信処理が完了しているものとして
【００２７】
ＩｒＬＭＰ層もまたＩｒＬＡＰ層の再送処理を知ることがないので、ＩｒＬＭＰレベルの切断要求のためにＤａｔａ．ｒｅｑｕｅｓｔ（７）を発行する
【００２８】同様に、ＩｒＬＭＰレベル（審決注：「ＩｒＬＭＰレベル」とあるのは「
ＩｒＬＡＰレベル
の切断要求であるＤｉｓｃｏｎｎｅｃｔ．ｉｎｄｉｃａｔｉｏｎ（４２）
【００２９】上述したように、
切断要求は処理の完了を待ち合わせることがないため、装置Ａの上位層では切断処理が完了したものと認識する。ところが、実際は装置ＢがＩｒＬＭＰレベルの切断要求（４１）さえも受取っていない。すなわち、装置Ｂにとってはリンクが接続状態にあり、装置Ａ、装置Ｂ間でリンクの状態の認識が食い違うという問題が発生する
　
 　上記（シ）、（ス）の記載及び関連する図面を参照すると、周知例２には、次の技術が記載されているものと認められる。（以下、「周知例２記載の技術」という。） 
　
「上位層が、下位層が提供するサービスを利用して、装置Ａ、Ｂ間で通信を行う際、装置Ａの上位層が、より下位層の切断処理の完了を待ち合わせしない場合には、実際は下位層の切断処理が完了していない状態でも、装置Ａ上位層では切断処理が完了したと認識するという問題が発生すること。」
　
（４）　周知例３（特開平１−１３６２６３号公報）
（セ）　２ページ左上欄１−１０行
「〔従来の技術〕
　
従来、国際標準化機構（ＩＳＯ）の解放型システム間相互接続（ＯＳＩ）のような、階層化された通信規約を実行する計算機システムでは
　
（ソ）　２ページ右上欄１３−２０行
「
特にＯＳＩのトランスポート層のように
同一データの再送処理を下位層と上位層で行う場合には、相手からの受理応答だけでは下位層の再送処理が終わっているかどうかを判定できない
　
このため、バッファ領域の解放は、下位層の送信完了通知と
がそろった時点で行なわなければならなくなり制御が複雑になる
　
（タ）　２ページ右下欄４−８行
「さらに、バッファ管理情報域にそのバッファ領域の管理を行う階層に対応する番号を付加し、バッファの使用状態を各層の通信制御プログラムが独立に知ることができこれを制御できるので、
複雑なバッファ解放待ち合わせ制御が不要となる
　
 　上記（セ）−（タ）の記載及び関連する図面を参照すると、周知例３には、次の技術が記載されているものと認められる。（以下、「周知例３記載の技術」という。） 
　
「従来、ＯＳＩのような階層化された通信規約を実行する計算機システムでは、特にＯＳＩのトランスポート層のように、同一データの再送処理を下位層と上位層で行う場合には、相手からの受理応答だけでは下位層の再送処理が終わっているかどうかを判定できないため、バッファ領域の解放処理は、下位層の送信完了通知と相手システムからの受理応答の両方がそろった時点で行なわなければならないこと。」
　
３　対比　
（１）　引用発明は、例えば「カレンダー
データベース
同期手順のための
トランスポート上で接続
　よって、引用発明は、本願発明の「データベース間の同期のためにトランスポート層コネクションを確立するステップ」に相当するステップを備えるといえる。
　
（２）　引用発明の「ラスト同期アンカー」は、最後に、すなわち直前に実行された同期を識別するために、時刻などを記述するものであるから、本願発明の「前記データベース間で実行された先の同期を記述する更新識別子（第１更新識別子）」に相当する。
　よって、クライアントとサーバ間が「HTTPのような何らかの一般的なネットワーク
トランスポート上で接続
ラスト
同期アンカーがあり、それらは
常に送信され
　
（３）　引用発明における「クライアント」及び「サーバ」は、いずれも「デバイス」であるから、それぞれ、本願発明における「第１デバイス」及び「第２デバイス」に相当する。
　引用発明の「ネクスト同期アンカー」は、「送信デバイスの点からの同期の現在のイベントを記述」するものであるから、本願発明の「第１デバイスにより規定されかつ現在の同期を記述する更新識別子（第２更新識別子）」に相当する。
　よって、引用発明において、「ラストとネクストの２つの同期アンカーがあり、それらは同期の初期化時に常に送信され」、「クライアントとサーバの両方がそれら自身のアンカーを互いに送信」することは、本願発明の「前記データベース間で実行された前記先の同期を記述する第１更新識別子と、第１デバイスにより規定されかつ前記現在の同期を記述する第２更新識別子が、前記第１デバイスから第２デバイスへ送信され」に相当する。
　
（４）　引用発明において、「記憶された同期アンカーは同期セッションが終了する前に更新されてはならない」から、当該同期セッションが終了した後のいつかの時点で、記憶された同期アンカーを更新することは自明である。 
　そして、上記同期アンカーの更新とは、クライアント及びサーバに記憶された、最後に実行された同期を記述する「ラスト同期アンカー」の内容を、それぞれ、現在の同期を記述する「ネクスト同期アンカー」の内容で更新することであると解される。 
　よって、引用発明において、記憶された同期アンカーは同期セッションが終了する前に更新せず、当該同期セッションが終了した後のいつかの時点で記憶された同期アンカーを更新することは、本願発明の「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、記憶された第１更新識別子の内容を、第２更新識別子の内容で更新する」ことと、「同期処理が実行され、この後、記憶された第１更新識別子の内容を、第２更新識別子の内容で更新する」点で一致する。
　
（５）　上記（４）記載のように、引用発明の同期アンカーの更新動作は、本願発明の「同期処理が実行され、この後、前記トランスポート層コネクションが正しく終了した場合、現在の同期を記述する更新識別子を記憶するステップ」と、「同期処理が実行され、この後、現在の同期を記述する更新識別子を記憶するステップ」である点で一致する。
　
　したがって、本願発明と引用発明の一致点、相違点は、以下のとおりである。
　
［一致点］　
「データベース間の同期のためにトランスポート層コネクションを確立するステップと、
　前記トランスポート層コネクションを使って、前記データベース間で実行された先の同期を記述する更新識別子を送信するステップと、
　同期処理が実行され、この後、現在の同期を記述する更新識別子を記憶するステップと、
を有する方法であって、
　前記データベース間で実行された前記先の同期を記述する第１更新識別子と、第１デバイスにより規定されかつ前記現在の同期を記述する第２更新識別子が、前記第１デバイスから第２デバイスへ送信され、
　同期処理が実行され、この後、記憶された第１更新識別子の内容を、第２更新識別子の内容で更新する、
方法。」
 
［相違点］
　本願発明は、「同期処理が実行され、この後、
前記トランスポート層コネクションが正しく終了した場合
前記トランスポート層コネクションが正しく終了した場合
　
４　当審の判断　
［相違点について］
　上記周知例１−周知例３に見られるように、一般に、複数の階層からなる通信制御方式において、上位層が通信を終える際、下位層の通信の完了を監視したり待ち合わせすることは、適宜に行われていることにすぎない（上記「周知例１記載の技術」−「周知例３記載の技術」参照。）。
　引用発明は、上位層であるクライアントとサーバ間の同期のための通信手順を、ＨＴＴＰなどの、ネットワークトランスポートという下位層が運搬するものであるから、上記周知例１−３記載の技術を上記引用発明に適用できない理由はない。
　さらに、引用発明のSyncML同期プロトコルの仕様書では、「同期アンカーの利用は実装依存」であって、「記憶された同期アンカーは同期セッションが終了する前に更新されてはならない」と規定するのみであるから、当該同期セッションが終了した後のどのような時点で同期アンカーを更新するかは、当業者が適宜選択すべき設計的事項と認められる。
　してみれば、引用発明の同期セッションが終了した後の時点について、セッションとは二つのシステム間で実行される通信の論理的な接続の開始から終了までのことであって、セッションの確立と解放のやり取りをするものであり、上位層が通信を終える際、下位層の通信の完了を監視したり待ち合わせする上記周知例１−３記載の周知技術を適用して、さらに、一般に、下位層の通信が正常終了する場合と異常終了する場合とがあることを考慮することで、同期処理が実行され、この後、
前記トランスポート層コネクションが正しく終了した場合
前記トランスポート層コネクションが正しく終了した場合
　
　そして、本願発明のように構成したことによる効果も引用発明、及び、周知技術から予測できる程度のものである。
　
５　むすび　
　したがって、本願発明は、引用発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。