WO2004107797A1

WO2004107797A1 - 移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法

Info

Publication number: WO2004107797A1
Application number: PCT/JP2004/007178
Authority: WO
Inventors: Naoto Itaba; Toshiyuki Tamura; Masayuki Sakata
Original assignee: Nec Corporation
Priority date: 2003-05-28
Filing date: 2004-05-26
Publication date: 2004-12-09
Also published as: CN1795694B; KR20060005000A; EP1631110A1; JP4192947B2; US20060264206A1; JPWO2004107797A1; US7653680B2; KR100787013B1; HK1092987A1; CN1795694A; EP1631110A4

Abstract

　対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新可能な移動通信システムを提供する。　サーバはソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、端末種別とソフトウェアのバージョン情報とを含むＯＴＡＳＰ要求をＧＧＳＮに送信する。ＯＴＡＳＰ要求はＧＧＳＮ、ＳＧＳＮ、ＲＮＣを介して携帯端末（ＵＥ＃１，ＵＥ＃２）に転送される。携帯端末（ＵＥ＃１，ＵＥ＃２）は自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致すると、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　ＲｅｑｕｅｓｔをＲＮＣに送信する。

Description

明細書

移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法技術分野

[0001] 本発明は移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法に関し、特に携帯電話機内のソフトウェアの更新を行うためのデータ転送方法に関する。

背景技術

[0002] 近年、携帯電話システムにおいては、携帯電話端末の加入者が飛躍的に増大しているが、携帯端末の不具合を修正するために、販売済みの携帯端末を回収するという出来事も生じている。

[0003] このような携帯端末の回収処理を避けるという目的も含めて、無線を利用して携帯端末のソフトウェアを書換えるという OTASP (Over The Air Service Provisio ning)力 ¾GPP2 (3rd Generation Partnership Project 2)で検討されている (例えば、非特許文献 1参照)。

[0004] この場合、ソフトウェアを書換える携帯端末を特定する技術としては、ページング技術がある。ページング技術では、携帯端末に対して着信があった時に、その旨を携帯端末に通知する必要があり、携帯端末が位置登録している位置登録エリア内の全ての携帯端末に対して着信があったことを同報的に通知する。すると、携帯端末では待ち受け状態にあっても、呼び出し用のチャネルを常に監視しているため、自端末に対するページングを認識することが可能となる（例えば、非特許文献 2参照）。

[0005] し力、しながら、携帯端末一つ一つにデータを転送しているのでは効率が悪くなるため、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する技術も提案されている (例えば、特許文献 1， 2参照)。

特許文献 1 :特開 2001— 28787号公報（第 7, 8、図 1)

特許文献 2 :特開 2003— 51796号公報（第 6— 8、図 1)

非特午文献 1： dGPP2 Access Network Interfaces Interoperability Spec ification Release A, June, 2000 非特許文献 2 :「W— CDMA移動通信方式 4 ネットワーク方式 4一 3 ネットワーク制御 ·信号方式」（立川敬二監修、丸善株式会社刊、平成 13年 6月 25日発行、第 2 54— 256頁）

発明の開示

発明が解決しょうとする課題

[0006] し力しながら、上記の 3GPP2で検討されている OTASPでは、携帯端末毎にデータを送信しており、複数の携帯端末が同時に同じデータを受信することができるという無線の性質が最大限に利用されていない。この場合、携帯端末毎にデータを送信することは、移動通信システム自体の輻輳を招いてしまう。

[0007] また、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する方法では、ソフトウェアを書換える必要がなレ、携帯端末でもそのデータを受信し、必要でないと判定した時に当該データを破棄する動作が必要になる。つまり、この方法では、ソフトウェアを書換える必要がない場合でもそのデータの受信動作と判定動作とを行わなければならず、携帯端末の消費電力の増大を招くという問題力 Sある。

[0008] そこで、本発明の目的は上記の問題点を解消し、対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法を提供することにある。

課題を解決するための手段

[0009] 本発明による移動通信システムは、無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに備えてレ、る。

[0010] 本発明による他の移動通信システムは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Pro visioning)を行う移動通信システムであって、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに備えている。

[0011] 本発明によるサーバは、無線を利用して携帯端末との間でデータ送受信を行うサーバであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を備えている。

[0012] 本発明による他のサーバは、無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Provisioning) を行うサーバであって、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を備えている。

[0013] 本発明による携帯端末は、無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換える OTASP (Over The Air Service Provisioning)が行われる移動通信システムの携帯端末であって、前記 OTASPが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを備えている。

[0014] 本発明によるデータ転送方法は、無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムのデータ転送方法であって、前記サーバ側に、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出すステップを備えてレ、る。

[0015] 本発明による他のデータ転送方法は、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Provi sioning)を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップを備えている。

[0016] すなわち、本発明の移動通信システムは、移動通信のブロードキャストまたはマルチキャストにおいて、サーバが携帯端末からの要求を受けることなぐ対象となる携帯端末群にデータの配信を行い、携帯端末のソフトウェアを修正することを特徴とする。この場合、一度修正したソフトウェアは、何度も修正しないようにすることも特徴とする

[0017] 通常、ブロードキャストにおいては、全ての携帯端末がデータを受信することが可能であるが、本発明では対象となる携帯端末のみがデータの受信を可能とする方式を実現するものである。

[0018] また、通常、マルチキャストでは、携帯端末が自らの意思でサービスに Join (参加）を行い、データの受信を行うが、本発明では、サーバが携帯端末特有の情報 [例えは、 IMEI_SV (The International MoDile station Equipment Identity a nd Software Version Number) ]を用いてネットワーク側力、ら携帯端末を呼出すことを提案している。

[0019] さらに、本発明では、ソフトウェアの正常性の確認を行うことで、成功した時に今後同じデータを受信しないように、失敗した時に改めてデータを受信可能とする機能を有している。

[0020] ブロードキャストを用いた OTASP (Over The Air Service Provisioning)では、対象となる携帯端末の存在を確認する必要がなぐネットワーク側は携帯端末からの応答の受信もなレ、。そのため、ネットワーク側での負荷が軽減される。しかしながら、対象となる携帯端末がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、 OTASPは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるためのものである。

[0021] 一方、マルチキャストを用いた OTASPでは、ネットワーク側は対象となる携帯端末が存在することを確認する必要があるので、携帯端末からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。し力、しながら、対象となる携帯端末が存在しないエリアにデータを送信することを避けることが可能となる。

[0022] そこで、最初の数回は対象となる携帯端末が多いことが予想されるため、ブロードキヤストを利用し、ブロードキャストを数回適用した後で、マルチキャストを適用することが考えられる。これによつて、効率の良い OTASPが実現可能となる。

[0023] 現在、 3GPPでは MBMS (Multimedia Broadcast/Multicast Service)力 S 検討されている。 MBMSの目的は、無線リソースの有効利用であり、あるデータをあるエリア全体に送信するブロードキャストと、あるデータをそのデータの受信を望んでレ、る携帯端末のグループのみに送信するマルチキャストが考えられている。これらの技術を利用することで、特定の携帯端末のグループのみに必要なデータを送信することが可能となる。

[0024] 現状の 3GPPの仕様では、呼出し通知チャネル（PICH : Page Indication Chan nel)における自端末が登録されたビットを確認し、そのビットが「1」であれば、呼出しチャネル (PCH : Paging Channel)の情報を読出し、自端末の着信かどうかを判断している。本発明では、現状の 3GPPの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって、呼出し通知チャネルの間欠受信を行っている。

[0025] 特定の携帯端末のソフトウェア修正を行う場合には、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに「1」を設定する。また、呼出しチャネルには対象となる携帯端末の機種 (端末種別）とソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョンの情報とを含ませる。

[0026] 呼出し通知チャネルによって呼出しチャネルを受信することを指示された全ての携帯端末は、自端末の機種及びソフトウェアバージョンと、呼出しチャネルに含まれてレ、る機種 (端末種別)及びソフトウェアバージョンとを比較する。その比較結果、それらが異なっている携帯端末はその時点で待ち受け状態に戻る。また、それらが一致した携帯端末は、呼出しチャネルの情報を基に、必要なデータをマルチキャスト、またはブロードキャストで受信する。マルチキャストか、ブロードキャストかの判断は、呼出し時にネットワーク側から違いがわかるように設定されている。

[0027] マルチキャストを行う場合には、一つでも携帯端末からの応答があれば、データ転送を開始するが、一つも応答がなければ、データ転送を行わず、 OTASPを終了する機能を有している。

[0028] ソフトウェアバージョンの更新が成功した携帯端末は、自端末のソフトウェアパージヨンを更新する。ソフトウェアバージョンの更新が失敗した携帯端末は、受信したデータを破棄し、ソフトウェアバージョンを更新しない。この動作によって、更新が成功した携帯端末では再度同じデータを受信することはないが、更新が失敗した携帯端末では成功するまで再度同じデータを受信することが可能である。発明の効果

[0029] 以上説明したように本発明は、上記のような構成及び処理手順とすることで、携帯端末において無駄な電力消費を行わせることなぐ対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができるという効果が得られる。

発明を実施するための最良の形態

[0030] 次に、本発明の実施例について図面を参照して説明する。図 1及び図 2は本発明の一実施例による移動通信システムの動作例を示す図である。図 1において、本発明の一実施例による移動通信システムでは、移動通信のブロードキャストまたはマルチキャストにおいて、図示せぬサーバ（Server)が携帯端末 1一 1一 1一 5からの要求を受けることなぐ対象となる携帯端末群にデータの配信を行い、携帯端末 1一 1一 1一 5 のソフトウェアを修正することを特徴とする。また、一度修正したソフトゥヱァは、何度も修正しなレ、ようにすることも特徴である。

[0031] 通常のブロードキャストでは、全ての携帯端末 1一 1一 1一 5においてデータの受信が可能であるが、本実施例では対象となる携帯端末 1一 1 , 1_3のみがデータの受信を可能としている。

[0032] また、通常のマルチキャストでは、携帯端末 1一 1一 1一 5が自らの意思でサービスに J oin (参カロ）を行ってデータの受信を行うが、本実施例では、サーバが携帯端末 1_1 一 1—5特有の情報 [例えば、 IMEI_SV (The International Mobile station Equipment Identity and Software Version Number) ]を用レヽてネットヮ¹ ~~ ク側カ携帯端末 1-1一 1-5を呼出すようにしている。「IMEト SV」については、 3 GPP TS23. 003 V5. 5. 1 (2003— 1)の 6. 2. 2章に記載されてレヽる。

[0033] 携帯端末 1_1一 1_5ではソフトウェアの正常性の確認を行うことで、ソフトウェアの更新に成功した時に今後同じデータを受信しないように、またソフトウェアの更新に失敗した時に改めてデータを受信可能とする機能を備えている。

[0034] 図 1において、サーバからのデータ（端末タイプ A用のソフトウェアのバージョン" n" のデータ）は NodeB (基地局） 2から携帯端末（UE： User Equipment) 1—1一 1—5 に送信されるが、そのデータは端末タイプ Aでソフトウェアのバージョンが" n"の携帯端末 1—1 , 1 - 3のみで受信され、端末タイプ Bの携帯端末 1 - 4や端末タイプ Aでソフトウエアのバージョンが "n "より古い携帯端末 1-2、端末タイプ Aでソフトウェアのバージョンが" n"より新しい携帯端末 1一 5では受信されない。

[0035] ブロードキャストを用いた OTASP (Over The Air Service Provisioning)では、対象となる携帯端末 1一 1 , 1一 3の存在を確認する必要がなぐネットワーク側は携帯端末 1一 1， 1—3からの応答の受信もなレ、。そのため、ネットワーク側での負荷が軽減される。し力ながら、対象となる携帯端末 1一 1， 1—3がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、 OTASPは、無線を利用してサーバから送られてくるデータで携帯端末 1一 1一 1一 5のソフトウェアを書換えるためのものである。「〇TASP」につレヽては、 3GPP TR23. 846 6. 1. 0 (2002—12)に記載されている。

[0036] 一方、マルチキャストを用いた OTASPでは、ネットワーク側が対象となる携帯端末

1-1 , 1-3が存在することを確認する必要があるので、携帯端末 1一 1 , 1-3からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。しかしながら、対象となる端末 1一 1， 1一 3が存在しないエリアにデータを送信することを避けることができる。

[0037] そこで、本実施例では、最初の数回、対象となる携帯端末が多いことが予想されるため、ブロードキャストを利用して、ブロードキャストを数回適用した後、続いてマルチキャストを適用するようにしている。これによつて、本実施例では効率の良い OTASP を実現すること力 Sできる。

[0038] 図 2においては、本実施例によるブロードキャスト及びマルチキャストの適用例を示している。この例では、携帯端末 UE # 1 UE # 10へのソフトウェアの書換え動作を示しており、ソフトウェアのバージョン「3」からバージョン「4」への書換え例を示している。

[0039] まず、サーバは 1日目にブロードキャストにてソフトウェアのバージョン「4」のデータを配信する。端末を呼び出す時には、現在のバージョン「3」を利用し、端末タイプとバージョンとがー致した端末が反応する。この場合、携帯端末 UE # 1， UE # 5， UE # 7— UE # 9は電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「4」のデータを書込む。他の携帯端末 UE# 2— UE# 4, UE#6, UE#10では電源を入れていなかつたので、サーバ力のソフトウェアのバージョン「4」のデータが書込まれない。

[0040] 続いて、サーバは 2日目にもブロードキャストにてソフトウェアのバージョン「4」のデータを配信する。この場合、携帯端末 UE#1， UE#5， 1；£#7 1；£#9はすでにデータが書込まれており、バージョンが一致しないので、そのブロードキャストに対して反応することはなレ、。一方、携帯端末 UE# 2 UE# 4では電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「4」のデータを書込む。他の携帯端末 UE#6， UE# 10ではまだ電源を入れていな力たので、サーバからのソフトゥエアのバージョン「4」のデータが書込まれなレ、。

[0041] サーバは上記のブロードキャストを予め設定された N— 1日だけ適用すると、 N日目にはマルチキャストにて携帯端末 UE# 6, UE# 10へのソフトウェアのバージョン「4」のデータ配信を行う。この場合、他の携帯端末 UE#1— UE#5， UE#7—UE#9 はすでにデータが書込まれてレ、るので、そのマルチキャストに対して反応することはない。

[0042] 図 3は本発明の一実施例による移動通信システムの構成を示すブロック図である。

図 3において、本発明の一実施例による移動通信システムは携帯端末 (UE) 1と、 N odeB (基地局）2—1, 2—2と、 RNC(Radio Network Controller) 3と、 SGSN[S ervmg GPRS (General Packet Radio Service) Support Node]4^、GU"S N (Gataway GPRS Support Node) 5と、サーバ 6と、 IP (Internet Protocol) ネットワーク 100と力ら構成されている。

ここで、以下の説明では、簡略化のために、呼出し通知チャネルを PICH (Page I ndication Channel)、呼出しチャネルを PCH (Paging Channel)とし、 3GPP (3 rd Generation Partnership Project)に特化した用語を用いるものとする。

[0043] 図 4は図 3のサーバ 6の構成を示すブロック図である。図 4において、サーバ 6はデータ入出力部 61と、データ蓄積部 62と、データ送信制御部（スケジューラ） 63と、マノレチキャスト部 64と、ブロードキャスト部 65と力、ら構成されている。

[0044] データ入出力部 61は他装置 (例えば、携帯端末 1に搭載する制御プログラム、アブリケーシヨンプログラム等のプログラム製作会社の装置）からそれらのプログラムのアツプデート用のデータ等が入力されると、そのデータをデータ蓄積部 62に蓄積する。また、データ入出力部 61はデータ蓄積部 62に蓄積されたデータを読出してデータ送信制御部 63に送出することで、当該データによるアップデートの指示を行う。

[0045] データ送信制御部 63はデータ入出力部 61からデータを受取ると、上述したようなブロードキャスト及びマルチキャストによるそのデータの配信スケジュールを作成し、そのスケジュールにしたがってデータをマルチキャスト部 64及びブロードキャスト部 6 5に渡す。

[0046] マルチキャスト部 64はデータ送信制御部 63で作成されたスケジュールにしたがつてマルチキャストにて携帯端末 1にデータ配信を行うために、データを GGSN5に送信する。マルチキャスト部 64では GGSN5からの応答を待つ必要があり、応答を受信しない時には対象となる端末が配下に一つも存在しないと判断し、データ送信自体をやめる機能を持つ。ブロードキャスト部 65はデータ送信制御部 63で作成されたスケジュールにしたがってブロードキャストにて携帯端末 1にデータ配信を行うために、データを GGSN5に送信する。ブロードキャスト部 65では、マルチキャスト部 64とは異なり、 GGSN5からの応答を待つ必要がない。マルチキャスト部 64及びブロードキヤスト部 65はそれぞれ端末の受信準備が整ったと思われる一定時間後、データ送信を開始する。

[0047] 図 5は図 3の携帯端末 (UE) 1の構成を示すブロック図である。図 5において、携帯端末 1はアンテナ 11と、無線通信部 12と、制御部 13と、ベースバンド部 18と、音声入出力部 19と、表示部 20と、キー操作部 21とから構成されている。尚、アンテナ 11 、無線通信部 12、ベースバンド部 18、音声入出力部 19、表示部 20、キー操作部 21 各々の動作は公知であるので、それらの説明は省略する。

[0048] 制御部 13は CPU (中央処理装置） 14と、 CPU14で動作する制御プログラムゃァプリケーシヨンプログラム等を格納するメモリ 15と、転送方式判定部 16と、データ転送制御部 17とから構成されている。

[0049] 転送方式判定部 16はサーバ 6からソフトウェアのバージョンアップのデータ等が上述したブロードキャストで転送されてくるの力 \あるいはマルチキャストで転送されてくるの力を判定し、その判定結果にしたがって CPU14及びデータ転送制御部 17が動作する。

[0050] サーバ 6からソフトウェアのバージョンアップのデータ等がブロードキャストやマルチキャストで転送されてくる場合、 CPU14及びデータ転送制御部 17は自端末のソフトウェアのバージョンと送られてくるデータのバージョンとを比較し、そのバージョンがー致しない場合には動作を終了する。 CPU14及びデータ転送制御部 17はそのバージョンが一致した場合、マルチキャストであれば応答をネットワーク側に送信し、プロードキャストであればネットワーク側になにも返送しないで、そのデータの取込み動作を準備して開始する。

[0051] その際、携帯端末 1は呼び出し用のチャネルの監視と上記の比較判定動作のみを行っていればよぐデータの取込みを行う際に必要な部位に電源を供給すればょレ、ため、従来のブロードキャストによるデータ受信時のように、装置全体に電源を供給する必要はない。

[0052] 図 6は本発明における PICHの構成及び PICHと PCHとの関係を示す図である。

図 6において、 RNC3と個別の通信を行うことができない状態の携帯端末 1 {idle, Ce 11/URA[UTRAN (UMTS Terrestrial Radio Access Network) Registr ation Area]— PCH}は RNC3から指示されたタイミングで PICHの間欠受信を行つている。これは携帯端末 1が着信を受けるために必要な動作である。

[0053] 携帯端末 1が PICHを受信するタイミングは携帯端末 1の識別子 [IMSI (Internati onal Mobile Subscriber Identity) ]等の値から計算される。 PICHの 1つのフレームは 300ビットで構成され、そのうちの後半 12ビットはリザーブとなっている。

[0054] さらに、各携帯端末 1が PICH内のどのビットを監視する力、も、携帯端末 1の識別子

(IMSI)等の値から計算される。携帯端末 1が監視すべき PICH内のビットが" 1"になつていた場合には、携帯端末 1が PICHと対になっている PCHを受信する。

[0055] 現状の 3GPPの仕様は、呼出し通知チャネル（PICH)の自端末を登録したビットを確認し、「1」であれば呼出しチャネル (PCH)の情報を読出し、自端末の着信かどうか判断している。本実施例では、現状の 3GPPの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって呼出し通知チャネルの間欠受信を行っている（図 6及び図 7参照）。

[0056] 図 7—図 9は本発明における PCH内の UE識別子の変更イメージを示す図である。

図 7—図 9において、 PICHのフレーム番号数（0— 4095)、 PICH内のビット数（288 )の制限から、必ずしも、 PICH内の各ビットに 1つの UEが割当てられるとは限らない

[0057] 仮に、 PICH内のあるビットに 3つの UEが割当てられているとすると、そのビットを" 1 "にすることで 3つの UEが PCHの受信を行う。しかしながら、 3つの UEが同時に着信を受けることは非常に稀であり、そのビットの" はどの UEを対象にしているかを示す方法が必要である。それを実現しているものが PCHに含まれる UE Identityである。 PCHを受信した UEは必ず UE Identityをチヱックし、自端末宛の着信であるかどうかを確認する。

[0058] ここでは、 1つのデータを転送し、それを複数の UEに同時に受信させることを想定しているので、データ転送の対象となる複数の UE (特定の機種、ソフトウェアバージョン）に同時に着信を行う必要がある。各 UEは異なる識別子を有するので、全ての UE に着信を行うために、まず、 PICHの全てのビットを "1 "に設定する。し力しながら、現状の PCHの UE Identityでは、個々の UEの UE Identityが設定されてしまうため、複数の UEに同時に着信を行うには不向きである。

[0059] そこで、 UE Identityに IMEI— SVを追加し、データの転送の対象となる UEの端末種別及びソフトウェアのバージョン情報を UE識別子に用いる。これによつて、対象となる UEをグループとして扱うことができる。 IMEI— SVには個々の UEを識別するためのシリアルナンパが含まれている力 S、ここでは特定の UEのグループに着信を行うことが目的であるので、シリアルナンパの情報は用いない。

[0060] また、上記のように PICHの全てのビットを" 1 "に設定することで、対象となる UEが一斉にページングに対する応答を行い、上りの無線容量の圧迫、ネットワーク側での処理負荷の増大が懸念されるため、必ずしも PICHの全てのビットを" と設定することが最良ではない場合も考えられる。例えば、ソフトウェアのダウンロードが完了する時間を見計らって、数分おきに":！ "と設定する PICHのビットを lObitずつシフトするとレ、うこともできる。 [0061] さらに、 UE Identityとして IMEI— SV以外のパラメータを設定することで、例えば、ミドルウェアやアプリケーションのアップデートに対しても上記の技術を適用することができる。

[0062] 本実施例では、上述したように、特定の携帯端末のソフトウェア修正を行う場合、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに "1 "を設定する。また、呼出しチャネルには対象となる携帯端末の機種及びソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョン情報を含ませる（図 7 図 9参照）。

[0063] 図 10は図 3のサーバ 6による処理手順を示すフローチャートである。これら図 1一図

10を参照して本発明の一実施例によるサーバ 6による処理手順について説明する。サーバ 6はバージョンアップ等によるソフトウェアの変更が発生すると（図 10ステップ S1)、予め設定されたブロードキャストの配信時刻（例えば、携帯端末 1の使用が減る深夜等）になると（図 10ステップ S2)、ソフトウェアの変更内容をブロードキャスト部 65 力ブロードキャストにて配信する（図 10ステップ S3)。

[0064] サーバ 6はブロードキャストの配信回数が予め設定した回数（=L)になるまで（図 1 0ステップ S4)、上記の処理を繰返し行う。また、サーバ 6はブロードキャストの配信日数が予め設定した日数（ = M) (例えば、 1週間や 1か月等）になるまで（図 10ステップ S5)、毎日、上記の処理を配信時刻となる毎に行う。

[0065] サーバ 6はブロードキャストの配信日数が予め設定した日数（ = M)になり（図 10ステツプ S5)、予め設定したマルチキャストの配信時刻になると（図 10ステップ S6)、マルチキャストによる OTASP要求を送信する（図 10ステップ S7)。

[0066] サーバ 6はその要求に対して応答する端末が一つでもあれば（図 10ステップ S8)、ソフトウェアの変更内容をマルチキャスト部 64からマルチキャストにて配信する（図 10 ステップ S9)。サーバ 6はマルチキャストの配信日数が予め設定した日数（ = K) (例えば、 1週間や 1か月等）になるまで（図 10ステップ S10)、毎日、上記の処理を配信時刻となる毎に行う。

[0067] マルチキャストによるソフトウェアの配信が終了した後は、位置登録情報等の情報を利用して、個々の端末にソフトウェアのバージョンアップを促すことが可能である。 [0068] 図 11は図 3の携帯端末 1による処理手順を示すフローチャートである。これら図 1一図 9と図 11とを参照して本発明の一実施例による携帯端末 1の処理手順について説明する。

[0069] 携帯端末 1は上述した従来と同様の処理で PCHを受信する（図 11ステップ S21— S23)。携帯端末 1は受信した PCHを解析し、従来の着信、従来の MBMS (Multim edia Broadcast/Multicast Service)、ブロードキャストでの〇TASP、マノレチキャストでの OTASPのいずれであるのかを認識する（図 11ステップ S24, S25)。ここで、 MBMSの仕様は未決定であるので、 PCH以外の CHが用いられる可能性もある。「MBMS」につレヽては、 3GPP TS23. 246 V0. 32. 01 (2002—06)に記載されている。

[0070] 携帯端末 1はブロードキャストでの OTASPの場合（図 11ステップ S24)、ネットヮーク側が OTASPの対象となる携帯端末の存在を認識することを要求されなレ、ので、ネットワーク側からの信号に対する応答を行わずに、 OTASPのデータを受信する準備を行う（図 11ステップ S30)。データを受信するための情報は PCHに含まれてレ、る。

[0071] 携帯端末 1はマルチキャストでの OTASPの場合（図 11ステップ S25)、ネットワーク側が OTASPの対象となる携帯端末の存在を認識することが要求されるので、ぺージングの応答として、 RRC (Radio Resource Control) Connection Request を送信し（図 11ステップ S27)、 OTASPのデータを受信する準備を行う（図 11ステツプ S28)。

[0072] 但し、携帯端末 1はブロードキャストでの OTASPの場合、またはマルチキャストでの OTASPの場合、自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれてレ、る機種 (端末種別）及びソフトウェアのバージョンとを比較する（図 11ステップ S26， S29)。

[0073] 携帯端末 1は上記の比較結果が異なっていれば、その時点で待ち受け状態に戻り、上記の比較結果が一致していれば、呼出しチャネルの情報を基に必要なデータをマルチキャスト、またはブロードキャストで受信する（図 11ステップ S28, S30)。マルチキャストか、ブロードキャストかの判断は、上述したように、呼出し時にネットワーク側から違レ、がわかるように設定されてレ、る。 [0074] 図 12は本発明の一実施例による OTASPでのデータ送信手順（マルチキャストで OTASPを行う場合の手順）を示すシーケンスチャートである。これら図 3及び図 12を参照して本発明の一実施例によるマルチキャストで OTASPを行う場合の手順について説明する。

[0075] サーバ 6はソフトウェアのバージョンアップが必要な携帯端末（UE#1, UE#2)がある時に、 OTASP要求を GGSN5に送信する（図 12の al)。このメッセージには、端末種別とソフトウェアのバージョン情報とが含まれ、さらに携帯端末 (UE#1， UE#2 )からの応答をサーバ 6に転送するためにサーバ 6の識別子も含まれている。この場合にはデータの転送モードも指定され、この転送モードによって RNC3の動作が異なる。この例では転送モードにマルチキャストが設定されてレ、る。

[0076] GGSN5はサーバ 6からの OTASP要求を受信すると、 GTP (GPRS Tunneling

Protocol)_Cメッセージで OTASP要求を SGSN4に転送する（図 12の a2)。

[0077] SGSN4は GGSN5からの OTASP要求を受信すると、 RANAP(Radio Access

Network Application Part)の Pagingメッセージで OTASP要求を RNC3に転送する（図 12の a3)。

[0078] マルチキャスト転送は RNC3が対象となる携帯端末 (UE#1, UE#2)を意識したい時に用いられるので、 RNC3は RRCの Pagingメッセージを携帯端末（UE#1, U E # 2)に送信し (図 12の a4)、対象となる携帯端末 (UE # 1 , UE # 2)からの応答を期待する。この時の Pagingには、上記の図 6—図 9によって説明した方法が用いられる。

[0079] マルチキャストの場合には、 RRC Connection Requestが携帯端末（UE# 1, UE#2)から RNC3に送信される（図 12の a6)。本実施例では、 RRC Connection

Requestが RNC3に送信されるのは、上記のように、携帯端末（UE#1， UE#2) が自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合である（図 12の a5)

[0080] この後、携帯端末 (UE#1, UE# 2)はサーバ 6に対して Join (参カロ）を行うためのデフォルトのトンネルを確立し（図 12の a7)、サーバ 6に対して OTASPのデータを受信する意思があることを知らせるために Joinを行う（図 12の a8)。これらの処理は 3GP

P標準の MBMSの手順に合わせる。

[0081] サーバ 6は携帯端末 (UE # 1, UE # 2)のうちの一つでも Joinの応答があった場合

、 OTASPのデータの送信を開始する（図 12の a9)。ネットワークの各装置は MBMS の手順にしたがってデータを送信する。

[0082] サーバ 6は OTASPのデータの送信が終わると、 GGSN5に OTASP終了通知でデータ送信の終了を通知する（図 12の alO)。この時、 OTASP終了通知には〇TA

SP要求に含まれていた機種及びソフトウェアのバージョン情報が含まれる。

[0083] GGSN5はサーバ 6からの OTASP終了通知を受信すると、 GTP—Cメッセージで O

TASP終了通知を SGSN4に転送する（図 12の al l)。 SGSN4は GGSN5からの O

TASP終了通知を受信すると、 RANAPメッセージで OTASP終了通知を RNC3に転送する（図 12の al2)。

[0084] RNC3は SGSN4からの OTASP終了通知を受信すると、 RRCメッセージで、 OT

ASP終了通知を対象となる携帯端末 (UE # 1， UE # 2)に送信し（図 12の al 3)、データ送信が終了したことを通知する。この時のメッセージにも、上記の図 6—図 9によつて説明した方法が用いられる。

[0085] 携帯端末 (UE # 1 , UE # 2)は上記の OTASPのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図 12の al4)。

[0086] 図 13は本発明の一実施例による OTASPでのデータ送信手順（ブロードキャストで

OTASPを行う場合の手順）を示すシーケンスチャートである。これら図 3及び図 13を参照して本発明の一実施例によるブロードキャストで OTASPを行う場合の手順について説明する。

[0087] サーバ 6はソフトウェアのバージョンアップが必要な携帯端末（UE # 1 , UE # 2)がある時に、 OTASP要求を GGSN5に送信する（図 13の a21)。このメッセージには端末種別及びソフトウェアのバージョン情報が含まれ、さらに、データの転送モードも指定され、この転送モードによって NC3の動作が異なる。この場合には、サーバ 6が携帯端末 (UE # 1， UE # 2)からの信号を受信する必要がないので、サーバ 6への信号転送のための情報は含まなレ、。

[0088] GGSN5はサーバ 6からの OTASP要求を受信すると、 GTP—Cメッセージで OTA SP要求を SGSN4に転送する（図 13の a22)。 SGSN4は GGSN5からの OTASP要求を受信すると、 RANAPの Pagingメッセージで OTASP要求を RNC3に転送する (図 13の a23)。

[0089] ブロードキャスト転送はネットワークが対象となる携帯端末 (UE # 1 , UE # 2)を意識しなくても良い時に用いられるので、 RNC3は対象となる携帯端末 (UE # 1， UE # 2)力、らの応答を期待する通常のページングではなぐブロードキャストを示すぺージングを行う（図 13の a24)。この時のメッセージにも、上記の図 6 図 9によって説明した方法が用いられる。また、これらの処理は 3GPP標準の MBMSの手順に合わせる。

[0090] 携帯端末 (UE # 1 , UE # 2)は、上記のように、自端末の機種及びソフトウェアのバ一ジョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合（図 13の a25)、 OTASPのデータを受信する準備を行う (図 13の a26)。この処理は 3GPP標準の MBMSの手順に合わせる。

[0091] この後、サーバ 6は OTASPのデータの送信を行う（図 13の a27)。ネットワークの各装置は、 3GPP標準の MBMSの手順にしたがってデータを送信する。

[0092] サーバ 6は OTASPのデータの送信が終わると、 OTASP終了通知で GGSN5にデータ送信の終了を通知する（図 13の a28)。この時、 OTASP終了通知には上記の OTASP要求に含まれていた端末種別及びソフトウェアのバージョン情報が含まれている。

[0093] GGSN5はサーバ 6から OTASP終了通知を受信すると、 GTP—Cメッセージで〇T ASP終了通知を SGSN4に転送する（図 13の a29)。 SGSN4は GGSN5から〇TA SP終了通知を受信すると、 RANAPメッセージで OTASP終了通知を RNC3に転送する（図 13の a30)。

[0094] RNC3は SGSN4から OTASP終了通知を受信すると、 RRCメッセージで、 OTAS P終了通知を対象となる携帯端末 (UE # 1 , UE # 2)に送信し、データ送信が終了したことを通知する（図 13の a31)。この時のメッセージにも、上記の図 6—図 9によって説明した方法が用いられる。

[0095] 携帯端末 (UE # 1 , UE # 2)は上記の OTASPのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図 13の a32)。

[0096] 図 14は図 3のサーバ 6側での処理手順（マルチキャストで OTASPを行う場合の手順）を示すフローチャートである。これら図 3及び図 14を参照してサーバ 6側でマルチキャストにて OTASPを行う場合の手順について説明する。

[0097] マルチキャストでは対象の携帯端末 1が存在しない時にデータの送信を行わないので、サーバ 6は OTASP要求を行うと同時に（図 14ステップ S41)、携帯端末 1からの応答を待ち受けるタイマ（図示せず）を起動する。

[0098] サーバ 6はタイマが満了するまでに携帯端末 1からの応答がなければ（図 14ステツプ S42， S43)、 OTASPを終了する（図 14ステップ S45)。このタイマは対象の携帯端末 1が存在するかを確認するだけではなぐ対象となる携帯端末群からの応答を収集するとレ、う目的も含まれてレ、る。

[0099] 一方、サーバ 6はタイマが満了するまでに携帯端末 1からの応答があれば（図 14ステツプ S42, S43)、 OTASPデータの送信を開始する（図 14ステップ S44)。

[0100] サーバ 6はマルチキャストを行う場合、上記のように、一つでも携帯端末 1からの応答があれば OTASPデータの転送を開始する力一つも応答がなければデータ転送を行わず、 OTASPを終了する機能を有する。

[0101] 尚、上記のマルチキャストによる端末ページングは、上述したようなソフトウェアのバ一ジョンアップだけでなぐ使用するソフトウェアのバージョンを使用している端末数の統計データの取得やその端末への特定ソフトウェアの提供等にも使用することが可能であり、これらに限定されるものではない。

[0102] 図 15は図 3の携帯端末 1でのデータの処理手順を示すフローチャートである。これら図 3及び図 15を参照して携帯端末 1におけるデータの処理手順について説明する

[0103] 携帯端末 1は OTASP終了のメッセージが到達しない場合を考慮して、 OTASP終了メッセージ待ちタイマを OTASPのデータの受信を開始したら起動する（図 15ステップ S51 , S52)。

[0104] 携帯端末 1は RRCメッセージにて OTASP終了が通知され（図 15ステップ S53)、ソフトウェアのアップデートに成功すると（図 15ステップ S54)、自端末のソフトウェアのバージョンを更新する（図 15ステップ S55)。

[0105] これは OTASP終了通知に含まれる機種及びソフトウェアバージョン力 OTASP 要求に含まれていた機種及びソフトウェアバージョンを用いるため、 OTASP終了通知を受信する前にソフトウェアバージョンを書換えてしまうと、終了通知を受信することができなくなってしまうからである。

[0106] 携帯端末 1はソフトウェアのアップデートが成功する前に、 OTASP終了タイマが満了したり（図 15ステップ S52)、 OTASP終了が通知されると（図 15ステップ S53， S5 4)、そこまで受信した OTASPデータを破棄し（図 15ステップ S56)、アップデートの手順を終了して機種及びソフトウェアのバージョン情報として以前のものを用いる。ソフトウェアのアップデートが失敗する場合としては、携帯端末 1でのデータの受信が完了する前に、 OTASP終了が通知されることも考えられる。

[0107] 上記のように、携帯端末 1はソフトウェアのアップデートが成功すると、自端末のソフトウエアのバージョン情報を更新する。また、携帯端末 1はソフトウェアのアップデートが失敗すると、受信したデータを破棄し、ソフトウェアのバージョンを更新しない。

[0108] これらの動作によって、ソフトウェアの更新が成功した携帯端末 1は再度同じデータを受信することはないが、更新が失敗した携帯端末 1は成功するまでソフトウェアのバ一ジョンを更新しないので、再度同じデータを受信することが可能となる。

[0109] このように、本実施例では、ソフトウェアのバージョンアップ等におけるプログラムの書換えを行うための OTASPに MBMSを利用することで、携帯端末 1において無駄な電力消費を行わせることなぐ対象となる携帯端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる。

[0110] また、本実施例では、携帯端末に特有の情報 (例えば、 IMEI— SVに含まれている機種及びソフトウェアのバージョン情報）を利用することで、携帯端末 1のグループ化を効果的に行うことができる。

[0111] さらに、本実施例では、ソフトウェアの更新が完了した携帯端末 1が自端末のソフトウェアのバージョンを更新することで、同じデータの重複受信を避けることができる。図面の簡単な説明

[0112] [図 1]本発明の一実施例による移動通信システムの動作例を示す図である。

[図 2] (a)一 (c)は本発明の一実施例による移動通信システムの動作例を示す図である。

[図 3]本発明の一実施例による移動通信システムの構成を示すブロック図である。

[図 4]図 3のサーバの構成を示すブロック図である。

[図 5]図 3の携帯端末の構成を示すブロック図である。

[図 6]本発明における PICHの構成及び PICHと PCHとの関係を示す図である。

[図 7]本発明における PCH内の UE識別子の変更イメージを示す図である。

[図 8]本発明における PCH内の UE識別子の変更イメージを示す図である。

[図 9]本発明における PCH内の UE識別子の変更イメージを示す図である。

[図 10]図 3のサーバによる処理手順を示すフローチャートである。

[図 11]図 3の携帯端末による処理手順を示すフローチャートである。

[図 12]本発明の一実施例による OTASPでのデータ送信手順を示すシーケンスチヤートである。

[図 13]本発明の一実施例による OTASPでのデータ送信手順を示すシーケンスチヤートである。

[図 14]図 3のサーバ側での処理手順を示すフローチャートである。

[図 15]図 3の携帯端末でのデータの処理手順を示すフローチャートである。

符号の説明

[0113] 1 , 1-1-1-5 携帯端末

2, 2-1 , 2-2 NodeB

3 RNC

4 SGSN

5 GGSN

6 サーバ

11 アンテナ無線通信部制御部

CPU

メモリ

転送方式判定部データ転送制御部ベースバンド部音声入出力部表示部

キー操作部データ入出力部データ蓄積部データ送信制御部マ

ブロードキャスト部 IPネットワーク

Claims

請求の範囲

[1] 無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有することを特徴とする移動通信システム。

[2] 前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項 1記載の移動通信システム。

[3] 無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Provisioning)を行う移動通信システムであつて、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有することを特徴とする移動通信システム。

[4] 前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別する機能と、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを前記携帯端末に含むことを特徴とする請求項 3記載の移動通信システム。

[5] 前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを前記携帯端末に含むことを特徴とする請求項 3または請求項 4記載の移動通信システム。

[6] 前記サーバは、前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項 5記載の移動通信システム。

[7] 前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を前記携帯端末に含むことを特徴とする請求項 3から請求項 6のレ、ずれか記載の移動通信、：

[8] 無線を利用して携帯端末との間でデータ送受信を行うサーバであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を有することを特徴とするサーバ。

[9] 前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項 8記載のサーバ。

[10] 無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Provisioning)を行うサーバであって、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を有することを特徴とするサーバ。

[11] 前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項 10記載のサーバ。

[12] 少なくとも自端末の端末種別及び自端末のソフトウェアのバージョン情報を含むぺ一ジングを受信した時に動作することを特徴とする携帯端末。

[13] 無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換える O TASP (Over The Air Service Provisioning)が行われる移動通信システムの携帯端末であって、前記 OTASPが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを有することを特徴とする携帯端末。

[14] 前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを含むことを特徴とする請求項 13記載の携帯端末。

[15] 前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を含むことを特徴とする請求項 13または請求項 14記載の携帯端末。

[16] 無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信 > のデータ転送方法であって、前記サーバ側に、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出すステツプを有することを特徴とするデータ転送方法。

[17] 前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項 16記載のデータ転送方法。

[18] 無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換える OTASP (Over The Air Service Provisioning)を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記 OTASPを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップを有することを特徴とするデータ転送方法。

[19] 前記携帯端末側に、前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別するステップと、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新するステップとを含むことを特徴とする請求項 18記載のデータ転送方法。

[20] 前記携帯端末側に、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別するステップと、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信するステップと、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信するステップとを含むことを特徴とする請求項 18または請求項 19記載のデータ転送方法。

[21] 前記サーバが前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項 20記載のデータ転送方法。

[22] 前記携帯端末側に、前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウエアのバージョン情報の更新を抑止するステップを含むことを特徴とする請求項 18から請求項 21のいずれか記載のデータ転送方法。