JP6109771B2 - ファイル送受信装置およびファイル送受信方法 - Google Patents

ファイル送受信装置およびファイル送受信方法 Download PDF

Info

Publication number
JP6109771B2
JP6109771B2 JP2014050845A JP2014050845A JP6109771B2 JP 6109771 B2 JP6109771 B2 JP 6109771B2 JP 2014050845 A JP2014050845 A JP 2014050845A JP 2014050845 A JP2014050845 A JP 2014050845A JP 6109771 B2 JP6109771 B2 JP 6109771B2
Authority
JP
Japan
Prior art keywords
communication
file
transmission
transfer history
transfer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014050845A
Other languages
English (en)
Other versions
JP2015177267A (ja
Inventor
良成 熊木
良成 熊木
英知 松尾
英知 松尾
和哉 奈良
和哉 奈良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2014050845A priority Critical patent/JP6109771B2/ja
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to PCT/JP2015/058393 priority patent/WO2015137523A1/en
Priority to US15/123,999 priority patent/US9859954B2/en
Priority to TW104108257A priority patent/TWI574521B/zh
Priority to TW108125316A priority patent/TWI693804B/zh
Priority to CN202010169183.5A priority patent/CN111327709B/zh
Priority to CN202210935867.0A priority patent/CN115277683B/zh
Priority to KR1020167023864A priority patent/KR101921396B1/ko
Priority to TW109117149A priority patent/TWI743802B/zh
Priority to TW106100072A priority patent/TWI677204B/zh
Priority to CN201580011266.9A priority patent/CN106068655B/zh
Priority to EP15717264.4A priority patent/EP3117594A1/en
Publication of JP2015177267A publication Critical patent/JP2015177267A/ja
Publication of JP6109771B2 publication Critical patent/JP6109771B2/ja
Application granted granted Critical
Priority to US15/830,082 priority patent/US10187118B2/en
Priority to US16/202,446 priority patent/US10454531B2/en
Priority to US16/448,560 priority patent/US10623059B2/en
Priority to US16/808,928 priority patent/US11309938B2/en
Priority to US17/690,420 priority patent/US11881910B2/en
Priority to US18/510,795 priority patent/US20240088941A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H04B5/72
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access, e.g. scheduled or random access
    • H04W74/08Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0833Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure
    • H04W74/0841Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure with collision treatment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/23Manipulation of direct-mode connections
    • H04B5/70
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2250/00Details of telephonic subscriber devices
    • H04M2250/64Details of telephonic subscriber devices file transfer between terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H04W84/20Master-slave selection or change arrangements

Description

本発明の実施形態は、ファイル送受信装置およびファイル送受信方法に関する。
従来、近距離無線通信でデータ通信を行う場合、一般的にマスタ(Master)機器からスレーブ(Slave)機器に対して処理要求を発行している。近接無線通信技術の1つであるTransferJet(商標)では、相互機器のPriorityは接続待機時のモードによって決定する。マスタで接続待ちの機器がスレーブで接続待ちの機器と接続すると、マスタ機器はHigh Priorityとなり、スレーブ機器はLow Priorityとなって接続確立できる。なお、接続待機時のモードがダイナミック(Dynamic)の機器は、相手機器がマスタの場合は自機器がLow Priorityとなり、相手機器がスレーブの場合は自機器がHigh Priorityとなり、相手機器に合わせて自機器のPriorityを決定する。
しかしながら、従来技術では、ファイル送信要求を持ったマスタ機器同士またはダイナミック機器同士が近接すると、どちらがHigh Priority機器になるかの判断がつかず、接続確立できずにコンフリクトが発生する。そのため、同じモード同士の機器間でOBEXプロトコル等を利用した通信機能を動作させることができない、という問題がある。
特開2011−91762号公報
一つの実施形態は、対向機器との間でコンフリクトが発生した場合に、コンフリクトを解消してファイルの送受信が可能なファイル送受信装置およびファイル送受信方法を提供することを目的とする。
一つの実施形態によれば、ファイル送受信装置は、近接無線通信において、対向機器との間でコンフリクトが発生した場合に前記対向機器との接続を切断し、前記対向機器と再接続後、自装置のモードとしてマスタおよびスレーブを切り替える制御を行う通信方向管理部を持つ。また、前記通信方向管理部からのモードの指示に従い、マスタまたはスレーブとして、前記対向機器との間でファイルの送信または受信または送受信を行うアプリケーション部と、を持つ。
図1は、第1の実施形態の通信デバイスの構成例を示す図である。 図2は、TransferJetの階層モデルを示す図である。 図3は、第1の実施形態のファイル送受信処理を示すフローチャートである。 図4は、TransferJetにおけるデータフレームの構成例を示す図である。 図5は、第1の実施形態における双方向通信の処理を示すフローチャートである。 図6は、デバイスA,B間のファイル送受信処理を示すシーケンス図である。 図7は、各デバイスのモード遷移を示す図である。 図8は、通信デバイスにおける通信状態の表示例を示す図である。 図9は、通信デバイスにおける双方向通信完了後の表示例を示す図である。 図10は、第2の実施形態における双方向通信の処理を示すフローチャートである。 図11は、第3の実施形態における片方向通信の処理を示すフローチャートである。 図12は、各デバイスのモード遷移を示す図である。 図13は、通信デバイスにおける片方向通信完了後の表示例を示す図である。 図14は、第4の実施形態の通信デバイスおよびホストデバイスの構成例を示す図である。 図15は、第4の実施形態のデバイスおよび接続相手管理テーブルの構成例を示す図である。 図16は、第4の実施形態のデバイスおよび送信リストテーブルの構成例を示す図である。 図17は、通信デバイスにおける双方向通信完了後の表示例を示す図である。 図18は、第5の実施形態のデバイスおよび接続相手管理テーブルの構成例を示す図である。 図19は、第5の実施形態のデバイスおよび送信リストテーブルの構成例を示す図である。 図20は、基本的な差分転送方法を示す図である。 図21は、第6の実施形態の通信デバイスの構成例を示す図である。 図22は、第6の実施形態の差分転送制御部の構成例を示す図である。 図23は、デバイスAを中心としたファイル転送可能な関係を示す図である。 図24は、デバイスAにおける転送履歴保存部の転送履歴リストの構成例を示す図である。 図25は、デバイスBにおける転送履歴保存部の転送履歴リストの構成例を示す図である。 図26は、第6の実施形態のファイル転送処理を示すフローチャートである。 図27は、送信機器および受信機器との間で送受信される情報を示す図である。 図28は、低レベルの転送履歴リストの構成例を示す図である。 図29は、第7の実施形態のファイル転送処理を示すフローチャートである。 図30は、未送信ファイルを探す処理を示す図である。 図31は、各デバイスのファイルリストおよび転送履歴リストの遷移を示す図である。 図32は、転送途中で中断されたファイル(j)の構成例を示す図である。 図33は、第9の実施形態の通信デバイスおよびホストデバイスの構成例を示す図である。 図34は、第9の実施形態の差分転送制御部の構成例を示す図である。 図35は、通信デバイスの構成を簡易化した図である。 図36は、通信デバイスおよびホストデバイスの構成を簡略化した図である。 図37は、通信デバイスおよびホストデバイスの構成を簡略化した図である。 図38は、通信デバイスおよびホストデバイスのレジスタの利用状態を示す図である。 図39は、レジスタマップの構成例を示す図である。
以下に添付図面を参照して、実施形態にかかるファイル送受信装置およびファイル送受信方法を詳細に説明する。なお、これらの実施形態により本発明が限定されるものではない。
(第1の実施形態)
図1は、本実施形態の通信デバイス1の構成例を示す図である。ファイル送受信装置である通信デバイス1は、ユーザI/F部10と、アプリケーション部11と、通信方向管理部12と、転送条件情報管理部13と、通信制御部14と、接続相手管理テーブル15と、送信リストテーブル16と、を備える。
ユーザI/F部10は、通信開始、ユーザー名登録、接続相手管理テーブル15の入力、送信データのカテゴリ分類など、ユーザーからの処理とのインターフェースとなる。
アプリケーション部11は、マスタ処理およびスレーブ処理を実行し、ファイルの送信、受信などの動作全体の管理などを行う。
通信方向管理部12は、自機器と対向機器が同一モードのためコンフリクトが発生した場合に、UID(ユニークID)の比較、乱数の生成等を行い、自機器のモード(マスタまたはスレーブ)を決定する。また、通信方向管理部12は、単一方向の(一方のモードでの)通信完了後に、自機器のモードをマスタからスレーブに、またはスレーブからマスタに切り替える。
転送条件情報管理部13は、接続確立後に対向機器の転送条件情報を取得、管理して、送受信する対象のファイルを決定する。
通信制御部14は、接続要求・接続応答・切断要求等のデータフレームの送信・受信を行う。
接続相手管理テーブル15は、ユーザーが入力した接続相手となる対向機器の情報を登録するテーブルである。
送信リストテーブル16は、対向機器と接続時に送信するファイルとそのファイルが所属するカテゴリを登録するテーブルである。
本実施形態では、近距離無線通信でデータ通信を行う場合の一例として、通信デバイス1が、TransferJet(商標)によりファイルを対向機器との間で送受信する場合について説明する。TransferJetでは、マスタ、ダイナミック、スレーブのモードがあるが、以降の説明では、マスタおよびスレーブを用いて説明し、マスタがHigh Priority、スレーブがLow Priorityとする。ここで、TransferJetの階層モデルについて簡単に説明する。図2は、TransferJetの階層モデルを示す図である。通信デバイス1であるデバイスA,Bが接続する際にコ
ンフリクトが発生する様子を示すものである。TransferJetの階層モデルは大きく分けて、アプリケーション層、セッション層、データリンク層の3階層に分けることができる。
アプリケーション層からマスタとしての接続が要求されると、データリンク層では、接続要求データフレームを送信する。データリンク層では、自機器のモードがマスタ/スレーブどちらであっても、相手デバイスが送信してくるデータフレームを受信することが可能である。ただし、プライオリティが等しいマスタのデバイス同士が、お互い接続要求データフレームを受け取っても、セッション層では、コンフリクトと認識して正しく接続することはできない。このように、アプリケーション層では、マスタとして接続要求して他マスタと近接させると、コンフリクト通知を受け取り、プロトコル通信を行えない。また、セッション層では、マスタ同士が接続要求を受信するとコンフリクト状態となり、正しく接続確立ができない。なお、データリンク層では、上位層がコンフリクト状態であっても、各デバイスがお互いのデータフレームを送受信することができる。
つづいて、通信デバイス1において、対向機器である通信デバイス1との接続の際にコンフリクトが発生した場合に、コンフリクトを解消してファイル送受信を行う双方向通信の動作について説明する。通信デバイス1であるデバイスA(UID:0x22222222)およびデバイスB(UID:0x11111111)が、初期状態としてともにマスタモード(またはともにダイナミックモード)で接続待受け状態であり、各機器ともに接続要求のデータフレームを送信している状態とする。
図3は、本実施形態のファイル送受信処理を示すフローチャートである。以下のフローチャートに示す手順で各機器のモードを切り替えることにより、お互いが順番にマスタおよびスレーブとなり、お互いが所望のファイルを送信することが可能となる。なお、デバイスAの対向機器はデバイスBであり、デバイスBの対向機器はデバイスAとなる。
まず、デバイスA,Bでは、ユーザーが通信開始すると、アプリケーション部11が、自機器のモードをマスタと設定して接続を開始し、通信制御部14が、接続要求データフレームの送信を開始する(ステップS101)。通信制御部14は、対向機器が送信する接続要求データフレームを受信しない間、すなわち、対向機器を検出しない間は(ステップS102:No)、接続要求データフレームを定期的に送信し続ける(ステップS101)。
つぎに、デバイスA,Bを近接させる。デバイスA,Bでは、通信制御部14が、対向機器が送信する接続要求データフレームを受信、すなわち、対向機器を検出すると(ステップS102:Yes)、受信した接続要求データフレームの中身を解析する。接続要求データフレームには要求発行元機器のプライオリティが記載されているため、通信制御部14は、自機器のプライオリティと比較する(ステップS103)。
自機器のプライオリティと対向機器のプライオリティとが異なる場合、すなわち、一方がマスタで他方がスレーブ、一方がマスタで他方がダイナミック等の場合(ステップS103:No)、プライオリティの低い機器が接続応答データフレームを返して接続を確立させる。例えば、デバイスAがマスタ、デバイスBがスレーブであった場合には、デバイスBからデバイスAへ接続応答データフレームを返す。デバイスAは、デバイスBから接続応答データフレームを受信していない場合は(ステップS104:No)、接続応答データフレームを待ち(ステップS105)、ステップS104へ戻る。デバイスAは、デバイスBから接続応答データフレームを受信すると(ステップS104:Yes)、マスタとして接続して接続確立を通知し(ステップS106)、Push送信、Pull受信等のマスタ処理を実行し(ステップS107)、対向機器との通信を終了する(ステップ
S114)。なお、ステップS103:NoからステップS107までは従来同様の一般的な処理のため、詳細な説明については省略する。
自機器のプライオリティと対向機器のプライオリティとが同一(ともにマスタ、またはともにダイナミック)の場合(ステップS103:Yes)、デバイスA,Bでは、通信制御部14が、コンフリクト発生を通知する(ステップS108)。
デバイスA,Bでは、通信方向管理部12が、コンフリクト発生通知を受け取ると、対向機器の接続要求データフレームからUID情報を読み出して記憶する(ステップS109)。図4は、TransferJetにおけるデータフレームの構成例を示す図である。TransferJetのデータリンク層で送受信されるデータフレームは、本実施の形態の双方向通信の動作に対応しているかどうかを確認可能なバージョン情報(仕様情報)を示すLiCC versionと、データフレーム種別を示すLiCCと、リザーブ情報を示すReservedと、送信元デバイスのUIDを示すOwn UIDと、データフレームの情報であるLiCC Informationと、から構成される。デバイスA,Bでは、対向機器とデータリンク層で接続されていれば、対向機器からUID情報、バージョン情報を取得することができる。デバイスAでは、対向機器であるデバイスBからUID「0x11111111」を取得し、デバイスBでは、対向機器であるデバイスAからUID「0x22222222」を取得する。
デバイスA,Bでは、通信方向管理部12が、切断要求データフレームを送信し、対向機器との接続を一旦切断する(ステップS110)。
デバイスA,Bでは、通信方向管理部12が、切断後、対向機器から受信した接続要求データフレームのバージョン情報を確認し、対向機器も本実施形態の双方向通信の動作に対応しているかどうかを確認する(ステップS111)。
デバイスA,Bでは、対向機器が本実施形態の双方向通信の動作に対応している場合(ステップS111:Yes)、双方向通信処理を行って(ステップS112)、対向機器との通信を終了する(ステップS114)。一方、デバイスA,Bでは、対向機器が本実施形態の双方向通信の動作に対応していない場合(ステップS111:No)、片方向通信処理を行って(ステップS113)、対向機器との通信を終了する(ステップS114)。
本実施形態では、双方向通信(ステップS112)の動作について説明する。図5は、本実施形態における双方向通信の処理を示すフローチャートである。ここでは、デバイスAを中心に説明する。
デバイスA,Bでは、通信方向管理部12が、自機器のUIDと前回接続時の対向機器のUIDとを比較し、UIDが大きい機器が先にマスタとなり、小さい機器が先にスレーブとなる(ステップS201)。デバイスAでは、デバイスAのUID>デバイスBのUIDのため(ステップS201:Yes)、通信方向管理部12が、自機器がマスタになることを決定する。一方、デバイスBでは、デバイスAのUID>デバイスBのUIDのため(ステップS201:No)、通信方向管理部12が、自機器がスレーブになることを決定する。
デバイスAでは、通信制御部14が、接続要求データフレームを送信し(ステップS202)、デバイスBから接続応答データフレームを受信していない場合は(ステップS203:No)、接続応答データフレームを受信するまで定期的に接続要求データフレームを送信し続ける(ステップS202)。
デバイスAでは、通信制御部14が、デバイスBから接続応答データフレームを受信すると(ステップS203:Yes)、接続応答データフレームに含まれるUIDと前回接続時の対向機器のUIDとを比較する(ステップS204)。通信制御部14は、UIDが一致しない場合は(ステップS204:No)、双方向通信を終了し、UIDが一致した場合は(ステップS204:Yes)、接続確立したことをアプリケーション部11に通知する(ステップS205)。アプリケーション部11は、マスタとして接続を行う(ステップS205)。
デバイスAでは、転送条件情報管理部13が、スレーブ側のデバイスBから転送条件情報を取得し(ステップS206)、取得した情報に基づいてスレーブ側のデバイスBに対するマスタ処理を確定する。具体的には送信するファイルの選別等を行うが、詳細については後述する実施形態において説明する。
デバイスAでは、アプリケーション部11が、転送条件情報管理部13で確定されたマスタ処理に従って、Push送信、Pull受信等のマスタ処理を実行する(ステップS207)。
マスタ処理が完了すると、デバイスAでは、通信方向管理部12が、スレーブ側のデバイスB(対向機器)に対して、マスタ処理終了通知とともに、切断要求データフレームを送信し、対向機器との接続を一旦切断する(ステップS208)。
通信方向管理部12は、マスタ側、スレーブ側の双方向通信の処理を完了したかどうかを確認する(ステップS209)。マスタ側、スレーブ側の双方向通信の処理を完了していない場合(ステップS209:No)、通信方向管理部12が、まだ完了していないモード、ここではアプリケーション部11のモードとしてスレーブを設定し、通信制御部14では、スレーブモードで接続待ち状態になる(ステップS210)。なお、通信方向管理部12は、双方向通信の処理が完了した場合には(ステップS209:Yes)、双方向通信を終了する。
デバイスAでは、通信制御部14が、デバイスBから接続要求データフレームを受信するまで待機し(ステップS211:No)、接続要求データフレームを受信すると(ステップS211:Yes)、接続応答データフレームを送信する(ステップS212)。
デバイスAでは、通信制御部14が、デバイスBからの接続要求データフレームに含まれるUIDと前回接続時の対向機器のUIDとを比較する(ステップS213)。通信制御部14は、UIDが一致しない場合は(ステップS213:No)、双方向通信を終了し、UIDが一致した場合は(ステップS213:Yes)、接続確立したことをアプリケーション部11に通知する(ステップS214)。アプリケーション部11は、スレーブとして接続を行う(ステップS214)。
デバイスAでは、アプリケーション部11が、スレーブ側の処理(マスタであるデバイスBからのPushによるデータ受信処理、Pullによるデータ送信処理等)を実行する(ステップS215)。
デバイスAでは、スレーブ処理が完了すると、通信制御部14が、デバイスBからの切断要求データフレームを待つ(ステップS216)。デバイスBから切断要求データフレームを受信するまで待機し(ステップS217:No)、切断要求データフレームを受信すると(ステップS217:Yes)、デバイスBとの接続を切断する。
通信方向管理部12は、マスタ側、スレーブ側の双方向通信の処理を完了したかどうかを確認する(ステップS218)。マスタ側、スレーブ側の双方向通信の処理を完了したため(ステップS218:Yes)、通信方向管理部12は、双方向通信を終了する。なお、マスタ側、スレーブ側の双方向通信の処理が完了していない場合(ステップS218:No)、通信方向管理部12が、まだ完了していないモード、ここではアプリケーション部11のモードとしてマスタを設定し、通信制御部14では、マスタモードとして接続要求データフレームを送信する(ステップS202)。
このように、デバイスAでは、ステップS201〜ステップS218の順に処理を実行し、双方向通信の処理を終了する。一方、デバイスBでは、ステップS201:Noとなるため、ステップS201,S210〜S218,S202〜S209の順に処理を実行し、双方向通信の処理を終了する。いずれのデバイスにおいても、マスタ/スレーブを切り替えて対向機器と接続することで、各モードでの通信を実行することができる。
なお、図3に示すファイル送受信処理および図5に示す双方向通信の処理において、デバイスA,Bが接続を一旦切断して再接続する処理がいくつかあるが、切断中に対向機器が離れてしまった、または、対向機器が故障した等によって再接続できないことも想定される。そのため、デバイスA,Bでは、再接続処理で一定期間以上対向機器と再接続できなかった場合は、双方向処理を途中終了する。
デバイスA,Bで実行されるファイル送受信処理を、シーケンス図を用いて説明する。図6は、デバイスA,B間のファイル送受信処理を示すシーケンス図である。ステップS301は、図3のステップS101〜S111までの処理に相当し、ステップS302は、デバイスAについては図5のステップS201〜S209、デバイスBについては図5のステップS201,S210〜S218に相当し、ステップS303は、デバイスAについては図5のステップS201,S210〜S218、デバイスBについては図5のステップS201〜S209に相当する。このように、デバイスA,Bでは、コンフリクト発生後において、マスタとスレーブを入れ替えて同様の処理を実行することにより、双方向での通信が可能となる。
図7は、各デバイスのモード遷移を示す図である。図6に示すシーケンス図において、各デバイスの状態を抜き出したものである。最初に、状態1として、デバイスA,Bは、ともにマスタで接続要求を行うので、コンフリクトが発生して通信不可となる。つぎに、UIDの比較の結果、まず、状態2として、デバイスAがマスタ、デバイスBがスレーブとして起動する。この状態でデバイスA,Bを近接させると接続を確立し、デバイスAからデータ通信を行う。デバイスAからのデータ通信が完了すると、モードを入れ替えて、状態3として、デバイスAがスレーブ、デバイスBがマスタとして起動する。この状態でデバイスA,Bを近接させると接続を確立し、デバイスBからデータ通信を行うことができる。
なお、通信デバイス1では、図1では図示していないが、自機器が備える表示部において、ユーザーに対して現在の通信状態および通信結果を示すことができる。図8は、通信デバイス1における通信状態の表示例を示す図である。例えば、双方向通信処理実行中の通信デバイス1では、最初にスレーブ処理を実行中で、まだマスタ処理を実行していない場合は、マスタとして「未通信」、スレーブとして「通信中」であり、現在スレーブ通信中であることを表示することで、ユーザーに対して、自機器の状態を示すことができる。表示する内容としては、一方のモードが完了していれば「通信完了」とする。また、図9は、通信デバイス1における双方向通信完了後の表示例を示す図である。各デバイスでは、双方向通信処理としてマスタ処理およびスレーブ処理が完了した場合には、マスタとして「通信完了」、スレーブとして「通信完了」であり、双方向通信が完了したことを表示
することで、ユーザーに対して、自機器の状態を示すことができる。表示する内容としては、通信が失敗した場合には「通信失敗」、通信データがない場合には「通信データ無し」と表示する。
また、本実施形態では、2つのデバイスが双方向通信によりマスタ/スレーブを切り替えて通信を行う場合に、上述のように、一旦対向機器との通信を切断し、モードを切り替えてから再度接続する処理を行う。2つのデバイスがマスタ/スレーブを切り替える方法としては、2つのデバイス間で、マスタからスレーブに切り替えた、スレーブからマスタに切り替えた、等のコンファメーション情報の送信により確認する方法がある。しかしながら、一旦通信を切断することで、各デバイスでは、対向機器のモードが切り替わったタイミングを確実に認識することができ、双方のモードが決まった状態でリスタートできる。
また、本実施形態では、対向機器との間でコンフリクトが発生した場合、各デバイスが自動でマスタ/スレーブのモードを切り替えることとしたが、デバイスを操作しているユーザーからの操作を受け付けて、手動によるタイミングで双方向通信を開始してもよい。この場合、ユーザー操作により、一方のデバイスをマスタ、他方のデバイスをスレーブとしてもよい。また、ユーザーは、対向機器との間でコンフリクトが発生していなくても、送信または受信したいファイルがある場合に、手動により双方向通信を開始してもよい。
また、本実施形態では、各デバイスは、対向機器との間でUIDの情報を交換し、UIDの大きさによってマスタまたはスレーブのモードを決定していたが、モードの決定方法はこれに限定するものではない。各デバイスは、データフレームにより対向機器との間でUIDの情報を交換するが、このデータフレームのReservedを用いて、ファイルに関する情報、例えば、ファイルの優先度、ファイルサイズ、送受信対象のファイルの有無、ファイルの送受信を希望するのかを示す情報等について、ビットを立てる/クリアする等による情報を含める。各デバイスは、ファイルに関するこれらの情報を用いて、モードを決定してもよい。
また、本実施形態では、近距離無線通信としてTransferJetによりファイルを送受信する場合について説明したが、一例であり、TransferJetに限定するものではない。
第1の実施形態によれば、ファイル送受信装置である通信デバイス1では、同じモードのため対向機器との間でコンフリクトが発生した場合、データリンク層でデータフレームの通信が可能な状態の際に対向機器との間でUIDを送受信し、対向機器のUIDと自機器のUIDとを比較した結果に基づいて、対向機器とは異なるマスタまたはスレーブのモードで起動し、一方のモードでの処理実行後、対向機器とともにモードを切り替え、他方のモードでの処理を実行して、ファイルの送信または受信または送受信を行うこととした。その結果、対向機器との間でコンフリクトが発生した場合においても、コンフリクトを解消して対向機器との間でファイルを送受信できる、という効果を得ることができる。
(第2の実施形態)
本実施形態では、第1の実施形態とは異なる双方向通信(図3のステップS112)の処理について説明する。なお、通信デバイス1の構成は第1の実施形態と同様であり、また、双方向通信処理以外のファイル送受信処理(図3のフローチャート)は、第1の実施形態と同様である。
図10は、本実施形態における双方向通信の処理を示すフローチャートである。以下のフローチャートに示す手順で各機器のモードを切り替えることにより、お互いが順番にマ
スタおよびスレーブとなり、お互いが所望のファイルを送信することが可能となる。
デバイスA,Bでは、通信方向管理部12が、乱数を生成し(ステップS401)、接続要求待ち状態となる(ステップS402)。
デバイスA,Bでは、通信方向管理部12が、対向機器から接続要求データフレームを受信しない場合(ステップS403:No)、生成した乱数に基づく乱数時間が経過するまではこの状態(接続要求待ち状態)を継続し(ステップS404:No)、乱数時間が経過した場合、すなわち、接続要求待ちの間に対向機器から接続要求データフレームを受信しなかった場合(ステップS404:Yes)、接続要求待ちを停止した後に(ステップS405)、自機器のモードをマスタとして設定し直す。ここでは、一例として、デバイスAが、デバイスBよりも生成した乱数が小さかった(乱数時間が短い)として、接続要求待ちの間に対向機器から接続要求データフレームを受信しなかった(ステップS404:Yes)場合について説明する。なお、通信方向管理部12では、対向機器から接続要求データフレームを受信した場合(ステップS403:Yes)、ステップS416の処理へ移行する。
デバイスAでは、通信制御部14が、接続要求データフレームを送信し(ステップS406)、デバイスBから接続応答データフレームを受信していない場合は(ステップS407:No)、接続応答データフレームを受信するまで定期的に接続要求データフレームを送信し続ける(ステップS406)。
デバイスAでは、通信制御部14が、デバイスBから接続応答データフレームを受信すると(ステップS407:Yes)、接続応答データフレームに含まれるUIDと前回接続時の対向機器のUIDとを比較する(ステップS408)。通信制御部14は、UIDが一致しない場合は(ステップS408:No)、双方向通信を終了し、UIDが一致した場合は(ステップS408:Yes)、接続確立したことをアプリケーション部11に通知する(ステップS409)。アプリケーション部11は、マスタとして接続を行う(ステップS409)。
デバイスAでは、転送条件情報管理部13が、スレーブ側のデバイスBから転送条件情報を取得し(ステップS410)、取得した情報に基づいてスレーブ側のデバイスBに対するマスタ処理を確定する。具体的には送信するファイルの選別等を行うが、詳細については後述する実施形態において説明する。
デバイスAでは、アプリケーション部11が、転送条件情報管理部13で確定されたマスタ処理に従って、Push送信、Pull受信等のマスタ処理を実行する(ステップS411)。
マスタ処理が完了すると、デバイスAでは、通信方向管理部12が、スレーブ側のデバイスB(対向機器)に対して、マスタ処理終了通知とともに、切断要求データフレームを送信し、対向機器との接続を一旦切断する(ステップS412)。
通信方向管理部12は、マスタ側、スレーブ側の双方向通信の処理を完了したかどうかを確認する(ステップS413)。マスタ側、スレーブ側の双方向通信の処理を完了していないため(ステップS413:No)、通信方向管理部12が、まだ完了していないモード、ここではアプリケーション部11のモードとしてスレーブを設定し、通信制御部14では、スレーブモードで接続待ち状態になる(ステップS414)。なお、通信方向管理部12は、双方向通信の処理が完了した場合には(ステップS414:Yes)、双方向通信を終了する。
デバイスAでは、通信制御部14が、デバイスBから接続要求データフレームを受信するまで待機し(ステップS415:No)、接続要求データフレームを受信すると(ステップS415:Yes)、接続応答データフレームを送信する(ステップS416)。
デバイスAでは、通信制御部14が、デバイスBからの接続要求データフレームに含まれるUIDと前回接続時の対向機器のUIDとを比較する(ステップS417)。通信制御部14は、UIDが一致しない場合は(ステップS417:No)、双方向通信を終了し、UIDが一致した場合は(ステップS417:Yes)、接続確立したことをアプリケーション部11に通知する(ステップS418)。アプリケーション部11は、スレーブとして接続を行う(ステップS418)。
デバイスAでは、アプリケーション部11が、スレーブ側の処理(マスタであるデバイスBからのPushによるデータ受信処理、Pullによるデータ送信処理等)を実行する(ステップS419)。
デバイスAでは、スレーブ処理が完了すると、通信制御部14が、デバイスBからの切断要求データフレームを待つ(ステップS420)。デバイスBから切断要求データフレームを受信するまで待機し(ステップS421:No)、切断要求データフレームを受信すると(ステップS421:Yes)、デバイスBとの接続を切断する。
通信方向管理部12は、マスタ側、スレーブ側の双方向通信の処理を完了したかどうかを確認する(ステップS422)。マスタ側、スレーブ側の双方向通信の処理を完了したため(ステップS422:Yes)、通信方向管理部12が、双方向通信を終了する。なお、マスタ側、スレーブ側の双方向通信の処理が完了していない場合(ステップS422:No)、通信方向管理部12が、まだ完了していないモード、ここではアプリケーション部11のモードとしてマスタを設定し、通信制御部14では、マスタモードとして接続要求を送信する(ステップS406)。
このように、デバイスAでは、ステップS401〜ステップS422の順に処理を実行し、双方向通信の処理を終了する。一方、デバイスBでは、ステップS403:Noとなるため、ステップS401〜S403,S416〜S422,S406〜S413の順に処理を実行し、双方向通信の処理を終了する。いずれのデバイスにおいても、マスタ/スレーブを切り替えて対向機器と接続することで、各モードでの通信を実行することができる。
なお、図3に示すファイル送受信処理および図10に示す双方向通信の処理において、デバイスA,Bが接続を一旦切断して再接続する処理がいくつかあるが、切断中に対向機器が離れてしまった、対向機器が故障した等によって再接続できないことも想定される。そのため、デバイスA,Bでは、再接続処理で一定期間以上対向機器と再接続できなかった場合は、双方向処理を途中終了する。
本実施の形態におけるデバイスA,Bで実行されるファイル送受信処理のシーケンス図(図6参照)、各デバイスのモード遷移を示す図(図7参照)、通信デバイスにおける表示例(図8,9参照)は、第1の実施形態と同様である。
なお、本実施形態では、各デバイスにおいて、マスタへの切り替えタイミングを、生成した乱数に基づくこととしたが、これに限定するものではない。各デバイスでマスタへの切り替えタイミングを変えることができればよいので、時間のパラメータとなるものであれば乱数以外のものを用いてもよい。
また、本実施形態の乱数の情報を、各デバイスが、第1の実施形態のように対向機器と交換し、UIDに替えて乱数の大小により、マスタまたはスレーブを決定してもよい。
第2の実施形態によれば、ファイル送受信装置である通信デバイス1では、同じモードのため対向機器との間でコンフリクトが発生した場合、自機器で乱数を生成し、スレーブで起動後、対向機器から接続要求データフレームを受信せずに乱数時間経過した場合は、マスタモードに切り替えて、対向機器に対して接続要求データフレームを送信してマスタモードでの処理を行い、乱数時間経過前に対向機器から接続要求データフレームを受信した場合は、スレーブモードでの処理を行い、一方のモードでの処理実行後、対向機器とともにモードを切り替え、他方のモードでの処理を実行して通信を行うこととした。その結果、対向機器との間でコンフリクトが発生した場合においても、コンフリクトを解消して対向機器との間でファイルを送受信できる、という効果を得ることができる。
また、第1の実施形態と異なり、対向機器との間で、対向機器を識別するUID以外の情報を相互に交換しなくても、双方向通信が可能となる。
(第3の実施形態)
本実施形態では、第1の実施形態における片方向通信(図3のステップS113)の処理、すなわち、デバイスA,Bの一方が第1(または第2)の実施形態の双方向通信の動作に対応していない場合(図3のステップS111:No)について説明する。ここでは、デバイスA,Bは、TransferJet通信が可能であるが、デバイスAのみが第1(または第2)の実施形態で説明した双方向通信に対応し、デバイスBは第1(または第2)の実施形態で説明した双方向通信に非対応とする。
デバイスBは、双方向通信機能を持たないため、自動でスレーブモードに切り替わることはできない。そのため、双方向通信に対応したデバイスAがスレーブモードに切り替わることで、コンフリクトが発生した場合でも片方向の通信は実現できる。
図11は、本実施形態における片方向通信の処理を示すフローチャートである。以下のフローチャートに示す手順により、デバイスBからデバイスAへ所望のファイルを送信することが可能となる。片方向通信(ステップS113)の処理までのファイル送受信処理(図3のステップS101〜S111)は前述の通りである。
デバイスA,Bでは、対向機器が本実施形態の双方向通信の動作に対応していない場合(ステップS111:No)、片方向通信処理を行って(ステップS113)、対向機器との通信を終了する(ステップS114)。
このとき、双方向通信の動作に対応しているデバイスAでは、対向機器のデバイスBが双方向通信の動作に非対応のため、通信方向管理部12が、自機器のアプリケーション部11のモードとしてスレーブを設定し、接続要求待ち状態となる(ステップS501)。
デバイスAでは、通信制御部14が、デバイスBから接続要求データフレームを受信するまで待機し(ステップS502:No)、接続要求データフレームを受信すると(ステップS502:Yes)、接続応答データフレームを送信する(ステップS503)。
デバイスAでは、通信制御部14が、デバイスBからの接続要求データフレームに含まれるUIDと前回接続時の対向機器のUIDとを比較する(ステップS504)。通信制御部14は、UIDが一致しない場合は(ステップS504:No)、片方向通信を終了し、UIDが一致した場合は(ステップS504:Yes)、接続確立したことをアプリ
ケーション部11に通知する(ステップS505)。アプリケーション部11は、スレーブとして接続を行う(ステップS505)。
デバイスAでは、アプリケーション部11が、スレーブ側の処理(マスタであるデバイスBからのPushによるデータ受信処理、Pullによるデータ送信処理等)を実行する(ステップS506)。
デバイスAでは、スレーブ処理が完了すると、通信制御部14が、デバイスBへ切断処理を送信してデバイスBとの接続を切断し(ステップS507)、片方向の処理が完了したので通信を終了する。
図12は、各デバイスのモード遷移を示す図である。最初に、状態1として、デバイスA,Bは、ともにマスタで接続要求を行うので、コンフリクトが発生して通信不可となる。このとき、デバイスA,B間でデータフレームが送受信されており、データフレームに含まれるバージョン情報からデバイスAでは、対向機器のデバイスBが双方向通信に非対応であることが分かる。そのため、デバイスAは、状態2として、自機器がスレーブとなることで、マスタであるデバイスBと接続を確立することができ、デバイスBからデータ通信を行うことができる。
図13は、通信デバイス1における片方向通信完了後の表示例を示す図である。デバイスAでは、片双方向通信処理としてマスタ処理が失敗し、スレーブ処理が完了したので、スレーブ通信のみ完了したことを表示することで、ユーザーに対して、自機器の状態を示すことができる。このとき、対向機器が双方向通信非対応のデバイスであることを通知するエラー表示をしてもよい。
第3の実施形態によれば、ファイル送受信装置である通信デバイス1では、同じモードのため対向機器との間でコンフリクトが発生した場合、対向機器が第1(または第2)の実施形態の双方向通信に対応していない場合、自機器がスレーブのモードで起動し、対向機器をマスタとする片方向の通信のみを行うこととした。その結果、コンフリクトが発生した場合でも、双方向通信非対応のデバイスから双方向通信対応のデバイスの方向への片方向の通信は実現できる、という効果を得ることができる。
(第4の実施形態)
本実施形態では、マスタ機器がスレーブ機器に対してデータを送信する際に、スレーブ機器から取得した転送条件情報によって、送信するファイルを自動で制限する機能について説明する。
具体的には、無線通信機能を有するデバイスとして、リムーバブルデバイス(SDカード、SDIOカード、ドングル等)の利用を想定する。無線通信機能を有するデバイスがリムーバブルデバイスの場合、このデバイスは、様々なホストデバイスに差し替えての利用が考えられるため、デバイスが有するUIDでは通信相手(ホストデバイス)での情報が特定できない場合がある。そのため、通信相手の識別にホストデバイス種別とシリアル番号の情報を利用する。
図14は、本実施形態の通信デバイス1aおよびホストデバイス2の構成例を示す図である。ファイル送受信装置である通信デバイス1aは、例えば、前述のようにSDカード、SDIOカード、ドングル等のリムーバブルデバイスであるが、これらに限定するものではない。また、ホストデバイス2は、例えば、デジタルカメラ、パーソナルコンピュータ(PC)等であるが、これらに限定するものではない。
通信デバイス1aは、アプリケーション部11と、通信方向管理部12と、転送条件情報管理部13と、通信制御部14と、接続相手管理テーブル15と、送信リストテーブル16と、ホストデバイスI/F部17と、を備える。ホストデバイスI/F部17は、ホストデバイス2との間でデータの送受信を行うインターフェースである。
また、通信デバイス1aでは、転送条件情報管理部13は、ホストデバイスI/F部17を経由して、ホストデバイス2の機器情報管理部20からホストデバイス2の情報(シリアル番号、ユーザー名等)を取得する。
ホストデバイス2は、ユーザI/F部10と、機器情報管理部20と、通信デバイスI/F部21と、を備える。機器情報管理部20は、ホストデバイス2のシリアル番号、ユーザーから入力された「ユーザー名」など、ホストデバイス2の情報を管理する。通信デバイスI/F部21は、通信デバイス1aとの間でデータの送受信を行うインターフェースである。
つづいて、本実施形態におけるファイルの送信処理について説明する。図15は、本実施形態のデバイスおよび接続相手管理テーブル15の構成例を示す図である。一例として、デバイスAは、図1に示す構成の通信デバイス1であり、デバイスBは、図14に示す構成の通信デバイス1aである。なお、デバイスAを、図14に示す構成の通信デバイス1aにすることも可能である。図15では、デバイスBは、4つのホストデバイス2(ホストデバイスA,B,C,D)と接続可能であることを示すものである。デバイスBは、実際にデバイスAと通信する際には1つのホストデバイス2と接続する。
図15では、無線通信機能を有するデバイスA,Bにおいて、デバイスAが送信側機器(マスタ)、デバイスBが受信側機器(スレーブ)として動作するものとする。デバイスBは、リムーバブルデバイスのため様々なホストデバイス2に挿入可能であり、ホストデバイス2に無線通信機能を付加することができる。
まず、マスタ側であるデバイスAでは、送信を実行する前に、ユーザーI/F部10を介して、ユーザーからの入力で接続相手管理テーブル15に、各ホストデバイス2の「ホストデバイス種別」、「ホストデバイスのシリアルNo.」を登録し、そのホストデバイス2がどのカテゴリ(「Family」、「Business」、「Friend」、「Personal」等)に属するかを登録する。
デバイスAの転送条件情報管理部13は、送信する各ファイルに対して、送信していいカテゴリを設定し、送信リストテーブル16に登録する。デバイスAの転送条件情報管理部13は、各ファイルに対して、送信していいカテゴリを複数選択することができる。
デバイスBでは、通信デバイス1aの転送条件情報管理部13が、ホストデバイスI/F部17、通信デバイスI/F部21経由でホストデバイス2の機器情報管理部20から「ホストデバイス種別」および「ホストデバイスのシリアルNo.」の情報を取得し、転送条件情報として保存しておく。
デバイスAとデバイスBの接続が確立すると、マスタ側であるデバイスAの転送条件情報管理部13が、スレーブ側のデバイスBから転送条件情報として、デバイスBが接続しているホストデバイス2の情報(「ホストデバイス種別」および「ホストデバイスのシリアルNo.」)を取得する。
デバイスAでは、転送条件情報管理部13が、取得したホストデバイス2の情報が接続相手管理テーブル15に含まれていれば、相手機器のカテゴリが特定できるため、送信リ
ストテーブル16の中からカテゴリが一致するファイルのみを送信する。なお、転送条件情報管理部13では、カテゴリが「Personal」のホストデバイス2に対しては、全てのファイルを送信するなどの条件を指定して送信することもできる。転送条件情報管理部13は、取得したホストデバイス2の情報が接続相手管理テーブル15に含まれていなければ、カテゴリが「Guest」のファイルのみを送信する。
図16は、本実施形態のデバイスおよび送信リストテーブル16の構成例を示す図である。図16に示す送信リストテーブル16を持ったデバイスAでは、リムーバルデバイスであるデバイスBを各ホストデバイス2に挿した場合に、下記に示すようにファイルを送信する。
デバイスBをカテゴリが「Friend」として登録されているホストデバイス2(ホストデバイスA)に挿して通信した場合、デバイスAは、No.2,3,6,7のファイルを送信する。
デバイスBをカテゴリが「Business」として登録されているホストデバイス2(ホストデバイスB)に挿して通信した場合、デバイスAは、No.1のファイルを送信する。
デバイスBをカテゴリが「Family」として登録されているホストデバイス2(ホストデバイスC)に挿して通信した場合、デバイスAは、No.4,5,6,7のファイルを送信する。
デバイスBをカテゴリが「Personal」として登録されているホストデバイス2(ホストデバイスD)に挿して通信した場合、デバイスAは、全てのファイルを送信する。
デバイスBを登録されていないホストデバイス2に挿して通信した場合、デバイスAは、そのホストデバイス2を「Guest」として扱い、No.5,6,7のファイルを送信する。
なお、ここでは、デバイスAからデバイスBへファイルを送信する場合について説明したが、デバイスBからデバイスAへファイルを送信することも可能である。この場合、一方のデバイスにおいて転送条件に一致するデータ(ファイル)が無い場合には、図17のように表示してもよい。図17は、通信デバイス1aにおける双方向通信完了後の表示例を示す図である。転送条件に一致するデータが無い場合には、その旨のエラー表示を行うことで、ユーザーに対して、自装置の状態を示すことができる。
第4の実施形態によれば、ファイル送受信装置である通信デバイス1または通信デバイス1aでは、対向機器が無線通信機能を有するリムーバブルデバイス(通信デバイス1a)の場合、様々なホストデバイス2に差し替えての利用が考えられるため、通信相手の識別にホストデバイス2の「ホストデバイス種別」および「ホストデバイスのシリアルNo.」の情報を利用することとした。その結果、接続相手管理テーブル15および送信リストテーブル16の設定により、各ホストデバイス2別に送信対象のファイルを設定できる、という効果を得ることができる。
(第5の実施形態)
本実施形態では、マスタ機器がスレーブ機器に対してデータを送信する際に、スレーブ機器から取得した転送条件情報によって、送信するファイルを自動で制限する機能について、第4の実施形態と異なる方法について説明する。
本実施形態では、通信相手の識別にユーザー名を利用する。なお、デバイスB側の構成は、第4の実施形態で説明した図14の構成と同様である。
つづいて、本実施形態におけるファイルの送信処理について説明する。図18は、本実施形態のデバイスおよび接続相手管理テーブル15の構成例を示す図である。一例として、デバイスAは、図1に示す構成の通信デバイス1であり、デバイスBは、図14に示す構成の通信デバイス1aである。なお、デバイスAを、図14に示す構成の通信デバイス1aにすることも可能である。
まず、マスタ側であるデバイスAでは、送信を実行する前に、ユーザーI/F部10を介して、ユーザーからの入力で接続相手管理テーブル15に、各ホストデバイス2の「ユーザー名」を登録し、そのホストデバイス2がどのカテゴリ(「Family」、「Business」、「Friend」、「Personal」等)に属するかを登録する。
デバイスAの転送条件情報管理部13は、送信する各ファイルに対して、送信していいカテゴリを設定し、送信リストテーブル16に登録する。デバイスAの転送条件情報管理部13は、各ファイルに対して、送信していいカテゴリを複数選択することができる。
デバイスBでは、ユーザーが各ホストデバイス2のユーザーI/F部10を介して各ホストデバイス2に「ユーザー名」を登録し、各ホストデバイス2の機器情報管理部20は、登録されたユーザー名を保存しておく。
デバイスBでは、通信デバイス1aの転送条件情報管理部13が、ホストデバイスI/F部17、通信デバイスI/F部21経由でホストデバイス2の機器情報管理部20から「ユーザー名」の情報を取得し、転送条件情報として保存しておく。
デバイスAとデバイスBの接続が確立すると、マスタ側であるデバイスAの転送条件情報管理部13が、スレーブ側のデバイスBから転送条件情報として、デバイスBが接続しているホストデバイス2の情報(「ユーザー名」)を取得する。
デバイスAでは、転送条件情報管理部13が、取得したホストデバイス2の情報が接続相手管理テーブル15に含まれていれば、相手機器のカテゴリが特定できるため、送信リストテーブル16の中からカテゴリが一致するファイルのみを送信する。なお、転送条件情報管理部13では、カテゴリが「Personal」のホストデバイス2に対しては、全てのファイルを送信するなどの条件を指定して送信することもできる。転送条件情報管理部13は、取得したホストデバイス2の情報が接続相手管理テーブル15に含まれていなければ、カテゴリが「Guest」のファイルのみを送信する。
図19は、本実施形態のデバイスおよび送信リストテーブル16の構成例を示す図である。図19に示す送信リストテーブル16を持ったデバイスAでは、リムーバルデバイスであるデバイスBを各ホストデバイス2に挿した場合に、下記に示すようにファイルを送信する。
デバイスBをカテゴリが「Friend」として登録されているホストデバイス2(ホストデバイスA)に挿して通信した場合、デバイスAは、No.2,3,6,7のファイルを送信する。
デバイスBをカテゴリが「Business」として登録されているホストデバイス2(ホストデバイスB)に挿して通信した場合、デバイスAは、No.1のファイルを送信
する。
デバイスBをカテゴリが「Family」として登録されているホストデバイス2(ホストデバイスC)に挿して通信した場合、デバイスAは、No.4,5,6,7のファイルを送信する。
デバイスBをカテゴリが「Personal」として登録されているホストデバイス2(ホストデバイスD)に挿して通信した場合、デバイスAは、全てのファイルを送信する。
デバイスBを登録されていないホストデバイス2に挿して通信した場合、デバイスAは、そのホストデバイス2を「Guest」として扱い、No.5,6,7のファイルを送信する。
第5の実施形態によれば、ファイル送受信装置である通信デバイス1または通信デバイス1aでは、対向機器が無線通信機能を有するリムーバブルデバイス(通信デバイス1a)の場合、様々なホストデバイス2に差し替えての利用が考えられるため、通信相手の識別にホストデバイス2の「ユーザー名」の情報を利用することとした。その結果、接続相手管理テーブル15および送信リストテーブル16の設定により、各ホストデバイス2別に送信対象のファイルを設定できる、という効果を得ることができる。
(第6の実施形態)
第4および第5の実施形態では、転送条件情報によって送信するファイルを自動で制限する方法について説明した。ここで、近距離無線通信におけるファイル転送の方法は、メディア媒体にある全てのファイルを転送する方法の他に、ある期間のみのファイルを転送する方法などいくつかある。本実施形態および以降の実施形態では、差分転送方法について説明する。なお、第1から第5の実施形態では、ファイル送受信装置である通信デバイスを、デバイスと表現していたが、以降についてはファイルの転送方法についての説明のため、ファイルの送信側と受信側が判別し易いように、送信機器または受信機器と表現することがある。
図20は、基本的な差分転送方法を示す図である。送信機器には、1回目の送信時にファイル1〜6、2回目の送信時にファイル1〜10があるものとする。
差分転送方法として、送信機器と受信機器があり、送信機器は、同じ受信機器と何度も転送処理をする場合、同じファイルを重複転送しないように、ファイルを送信する前に送信履歴の過去の送信内容と比較して、新しく追加されたファイルだけを送信するという、送信側で選別する方法がある。送信機器は、追加分(ファイル7〜10)だけを選別して受信機器に送信する。
また、他の差分転送方法として、送信機器と受信機器があり、互いの転送履歴ファイルを交換したあと、受信機器は、過去の受信内容と比較して送信機器側に追加分のファイルがある場合、送信機器に対して受信したいファイルをリクエストして送信機器から送信させるという、受信側で選別する方法がある。受信機器は、受信したいファイルとして追加分(ファイル7〜10)を選別してリクエストし、送信機器は、リクエストされたファイル7〜10を受信機器に送信する。
図21は、本実施形態の通信デバイス1bの構成例を示す図である。ファイル送受信装置である通信デバイス1bは、ユーザーI/F部10と、アプリケーション部11と、通信方向管理部12と、転送条件情報管理部13と、通信制御部14と、接続相手管理テー
ブル15と、送信リストテーブル16と、差分転送制御部18と、を備える。差分転送制御部18は、接続する機器毎の転送履歴(送信情報と受信情報)を作成し、転送完了の都度メモリ領域に保存し、次回転送時にそれぞれの転送履歴を比較することで同じデータを重複転送することが無いように制御する。差分転送制御部18におけるソフトウェア構成としては、図2に示すアプリケーション層でのアプリケーションとなる。
図22は、本実施形態の差分転送制御部18の構成例を示す図である。差分転送制御部18は、転送履歴保存処理部30と、転送履歴保存部31と、転送履歴比較部32と、パケット保存部33と、復元処理部34と、を備える。
転送履歴保存処理部30は、通信デバイス1bにおいて図示しない記憶部に記憶されているファイル、他のデバイスとの間で送受信したファイルの情報を転送履歴保存部31に保存する。
転送履歴保存部31は、通信デバイス1bにおいて図示しない記憶部に記憶されているファイル、他のデバイスとの間で送受信したファイルの情報を転送履歴リストとして保存する記憶部である。
転送履歴比較部32は、転送履歴保存部31に保存された自機器の転送履歴と対向機器から取得した転送履歴との比較を行う。なお、転送履歴保存部31については、差分転送制御部18内に配置せずに、通信デバイス1b内にある図示しない記憶部であって、ファイル等を記憶する記憶部内に配置してもよい。
パケット保存部33は、他のデバイスからファイルを受信している際に、そのファイルを構成するパケットのうち受信できないパケットがあった場合に、受信成功したパケットを一時的に保存する。
復元処理部34は、パケット保存部33に保存されているパケットと、新たに受信した当該ファイルを構成する残りのパケットを用いて、ファイルを復元する。
図23は、デバイスAを中心としたファイル転送可能な関係を示す図である。ここでは、通信デバイス1bとしてデバイスA,B,C,Dの4つのデバイスがあり、デバイスAは、他のデバイスB,C,Dと相互にファイルを送受信可能とする。
図24は、デバイスAにおける転送履歴保存部31の転送履歴リストの構成例を示す図である。また、図25は、デバイスBにおける転送履歴保存部31の転送履歴リストの構成例を示す図である。転送履歴リストは、送信または受信の区分と、ファイル送受信対象の相手デバイスIDと、送信又は受信したファイル名と、そのファイルについての更新日時、ファイルのサイズ、送信が中断した場合の送信成功したパケット情報を示すパケット、送信済み・未送信・送信禁止・受信禁止等の状態を示すステータスの情報を保存する。
相手デバイスIDは、実際にはMACアドレスのように16進数で表し、固有のもののため他に同じものは無い。なお、相手デバイスIDは、TransferJetではUIDと呼ばれる機器を特定できる固有のID、上位レベルのユーザー識別ID、ホストデバイスID(シリアル番号)等としてもよい。
また、更新日時は、実際にはUTC(Coordinated Universal Time)などの秒数とし、ここでは分かり易く日付で表現している。なお、更新日時として日付情報は、ファイルが作成された日付となっているが、各デバイスが独自な日付で管理する方法もある。例えば、そのデバイスがファイルを作成した日付、コピーした場合はコピーした日付を用いて
もよい。
また、ステータスにおいて、送信禁止、受信禁止等については、相手デバイスID等を用いて、ユーザーが意図的に設定できるものとする。ステータスが送信禁止のファイルについては、送信対象とはしないこととする。
転送履歴リストは、上記では、送信と受信のカテゴリに分け、それぞれで相手デバイスID毎に今までの転送履歴をリスト化して1つのファイルとしているが、一例であり、これに限定するものではない。例えば、相手デバイスID毎にファイルを分け、それぞれに送信と受信の今までの転送履歴がリスト化されている場合など、いくつかのパターンがあるものとする。
各デバイスでは、相手デバイスIDにより各デバイスを識別できることから、複数のデバイスを対象として、ファイルの送受信の履歴を保存することができる。
つづいて、通信デバイス1bにおけるファイル転送の動作について説明する。ここでは、最初に説明した図20の送信機器および受信機器を用いて、送信側で選別する方法について説明する。図26は、本実施形態のファイル転送処理を示すフローチャートである。具体的に、送信機器と受信機器との間で既にファイルを送受信しており、その後、デジカメで撮影するなどして送信機器にファイルが追加された場合について説明する。
まず、送信機器では、転送履歴比較部32が、接続した受信機器のIDを取得し(ステップS601)、あわせて、受信機器の転送履歴を取得する(ステップS602)。これらの情報は、送信機器と受信機器が接続する際に、受信機器から送信機器に送信されるデータフレームに含まれているものである。なお、送信機器では、受信機器から取得する転送履歴について、全ての転送履歴ではなく、受信機器での自機器からの受信に関する履歴のみを取得してもよい。
送信機器では、転送履歴比較部32が、転送履歴保存部31から自機器の転送履歴を取得する(ステップS603)。なお、転送履歴比較部32では、転送履歴として、全ての転送履歴ではなく、受信機器に対応する自機器の送信に関する転送履歴のみを取得してもよい。
送信機器では、転送履歴比較部32が、取得した受信機器の転送履歴と、自機器の転送履歴にある受信機器(受信機器ID)に対応する転送履歴とを比較する(ステップS604)。
転送履歴比較部32は、未送信ファイルがあるので(ステップS605:Yes)、未送信ステータスのファイルを送信対象ファイルとして送信リストテーブル16にセットする。転送履歴比較部32は、未送信対象ファイルとしてファイル7〜10があるので、ファイル7から順に送信リストテーブル16にセットする(ステップS606)。
そして、通信制御部14が、送信リストテーブル16にセットされた未送信ステータスのファイルを受信機器へ送信する(ステップS607)。
送信機器では、転送履歴保存処理部30が、受信機器へ送信成功したファイルについて、該当する転送履歴保存部31の転送履歴リストのステータス欄を送信済として更新する(ステップS608)。
送信機器では、ステップS604に戻って、未送信ファイルがある場合は、ステップS
604〜S608までの処理を繰り返し実行する。送信機器は、ファイル7から順に送信し、ファイル10を送信するまで繰り返し実行する。ファイル10の送信が完了すると、転送履歴比較部32は、未送信ファイルがないので(ステップS605:No)、ファイルの転送処理を終了する。
送信機器では、転送履歴保存処理部30は、複数のファイルを連続して転送して最後に転送履歴リストを更新すると、転送途中で機器が電源OFFするなどして転送が中断した場合、転送履歴リストに正しい情報が残らない。そのため、転送履歴保存処理部30は、上記のように、1つのファイルが転送成功するたびに転送履歴リストを更新する。
なお、受信機器でも、ファイル受信後に、該当する転送履歴保存部31の転送履歴リストのステータス欄を受信済として更新する(ステップS608)。
図27は、送信機器および受信機器との間で送受信される情報を示す図である。送信機器および受信機器は、互いにIDおよび自機器の転送履歴リストの情報を送信する。送信機器は、お互いの転送履歴リストを比較して差分のファイル7〜10だけを転送する。そして、送信機器および受信機器は、それぞれファイル1〜10を有することになり、それぞれの転送履歴リストを更新することで、差分なしとなる。
なお、送信側で選別する方法について具体的に説明したが、受信側で選別する動作について簡単に説明する。図26に示すフローチャートを参考にすると、受信機器が、ステップS601〜S605に相当する処理を行う。受信機器が、ステップS606に相当する処理で、未送信のファイルを選別して、送信機器に対して受信したいファイルをリクエストする。送信機器は、ステップS607で送信ファイルを送信する。そして、ステップS608において、受信機器および送信機器は、自機器の転送履歴保存部31の転送履歴リストのステータス欄を更新する。この場合においても、受信機器および送信機器では、送信側で選別する方法と同様の状態とすることができる。
第1の実施形態等で説明したように、近接無線通信では、転送するトリガーとして、ユーザーによるボタン操作等は必要なく、送信対象のファイルがあれば、相手機器との接続開始時がトリガーとなる。
また、各デバイス(例えば、デジカメ)では、上記で説明した他のデバイスからの転送処理以外にも、PC等からファイルコピーで新規にファイルが追加されることもある。そのため、各デバイスは、他のデバイスとの転送処理の開始前に転送履歴リストを更新し、新規追加ファイルを追加することとする。このとき、新規追加ファイルのステータスは未送信となる。
また、PC等からファイルコピーで新規にファイルが追加される場合では、過去の古いファイルが追加されることも想定される。この場合でも、過去の古いファイルは、相手デバイスへ送信していないことから、ステータスは未送信となる。そのため、転送履歴比較部32は、過去の古いファイルについても、未送信ステータスのファイルとして、送信対象ファイルとして送信リストテーブル16にセットすることができる。
第6の実施形態によれば、ファイル送受信装置である通信デバイス1bでは、送信機器側と受信機器側でお互いの転送履歴の情報を送受信し、送信機器が受信機器に対して未送信のファイルのみを送信する、または、受信機器が未受信のファイルの送信を送信機器へリクエストし、送信機器がリクエストされたファイルを送信することとした。その結果、同じファイルを何度も重複して送信する事態を回避でき、ファイル転送の時間を短縮し、通信効率を向上できる、という効果を得ることができる。
(第7の実施形態)
第6の実施形態では、転送履歴保存部31に保存する転送履歴リストとして、図24,25に示すように、相手デバイス毎に各ファイル別にステータスを管理している。しかしながら、対象のファイルまたは対象の相手デバイスが増加すると、転送履歴保存部31の容量が増大する。また、転送履歴比較部32でもファイルの検索等に対して高い処理能力が必要とされる。転送履歴リストを使用するデバイスでは、搭載しているCPU(Central Processing Unit)などのハード構成の処理能力次第で、転送履歴リストを検索するスピードが左右される。
そのため、転送履歴リストの管理レベルを複数設ける。第6の実施形態で説明した転送履歴リストを高レベルとし、本実施形態では、第6の実施形態で説明した転送履歴リストよりも管理レベルが低い低レベルの転送履歴リストを使用する場合について説明する。
高レベルの転送履歴リストは、管理する情報量が多い場合で、転送した全てのファイルのファイル情報(ファイル名、更新日時、ファイルサイズ、パケット、ステータス)として、過去の転送履歴が全てリスト化されて保存され、ファイル転送のたびに膨大なデータになる(図24,25参照)。図28は、低レベルの転送履歴リストの構成例を示す図である。低レベルの転送履歴リストは、管理する情報量が少ない場合で、例えば、最後に転送したファイル情報だけを転送履歴としてリスト化して転送履歴保存部31に保存することで、膨大なデータにはならない。これにより、機器の処理能力次第で、管理レベルを使い分けることができる。なお、低レベルの転送履歴リストにおける各項目(相手デバイスID、更新日時等)の記載方法は、第6の実施形態の(高レベルの)転送履歴リストの記載方法と同様である。
つづいて、低レベルの転送履歴リストを使用する場合の通信デバイス1bにおけるファイル転送の動作について説明する。ここでは、最初に説明した図20の送信機器を用いて説明する。図29は、本実施形態のファイル転送処理を示すフローチャートである。
まず、送信機器では、転送履歴比較部32が、接続した受信機器のIDを取得する(ステップS701)。IDの情報は、送信機器と受信機器が接続する際に、受信機器から送信機器に送信されるデータフレームに含まれているものである。
送信機器では、転送履歴比較部32が、転送履歴保存部31から自機器の転送履歴を取得する(ステップS702)。なお、転送履歴比較部32では、転送履歴として、全ての転送履歴ではなく、受信機器に対応する自機器の送信に関する転送履歴のみを取得してもよい。
送信機器では、転送履歴比較部32が、送信対象となるファイル群を日付が古い順に並べてファイルリストを作成する(ステップS703)。
送信機器では、転送履歴比較部32が、ファイルリストから未送信ファイルを検索する(ステップS704)。転送履歴比較部32は、具体的に、日付が古い順にリスト化されたファイルリストの中から、転送履歴において対応する送信機器に対して最後に転送成功したファイルと同じものを検索する。同じものがある場合、同じファイルの次のファイルからが新しいファイル、すなわち、未送信のファイルとなる。
図30は、未送信ファイルを探す処理を示す図である。ファイルリストとして日時の古い順に並べられたファイル1〜10がある。転送履歴比較部32は、転送履歴に記載の最後に転送成功したファイルと、ファイル1から順にファイルリストの情報とを比較する。
具体的に、転送履歴比較部32は、ファイルリストの中に、転送履歴に記載の最後に転送成功したファイルと同じファイルがあるかどうかを検索する。送信装置では、1回目の送信時にファイル6まで転送しているので、ここではファイル6で一致することになる。そのため、転送履歴比較部32は、ファイル7以降(ファイル7〜10)が未送信ファイルとなる(ステップS705:Yes)。なお、一致するファイルがない場合は、送信装置からこの受信装置に対する送信は新規の送信となるので、全てのファイルが未送信のため、全てのファイルを送信対象ファイルとする。
転送履歴比較部32は、未送信ファイルがあるので(ステップS705:Yes)、未送信ファイルを送信対象ファイルとして送信リストテーブル16にセットする。転送履歴比較部32は、未送信対象ファイルとしてファイル7〜10があるので、ファイル7から順に送信リストテーブル16にセットする(ステップS706)。
そして、通信制御部14が、送信リストテーブル16にセットされた未送信ステータスのファイルを受信機器へ送信する(ステップS707)。
送信機器では、転送履歴保存処理部30が、ファイルの送信が成功した受信機器について、該当する転送履歴保存部31の転送履歴リストのファイル名および当該ファイルについての更新日時等の項目を更新する(ステップS708)。
第6の実施形態同様、転送履歴保存処理部30は、複数のファイルを連続して転送する場合は、ステップS704〜S708までの処理を繰り返し実行する。送信機器は、ファイル7から順に送信し、ファイル10を送信するまで繰り返し実行する。ファイル10の送信が完了すると、転送履歴比較部32は、未送信ファイルがないので(ステップS705:No)、ファイルの転送処理を終了する。送信機器では、1つのファイルが転送成功するたびに転送履歴リストを更新する。
第7の実施形態によれば、ファイル送受信装置である通信デバイス1bでは、転送履歴として、最後に送信または受信したファイルの情報のみを保存することとした。その結果、第6の実施形態に対して、転送履歴保存部31の容量を小さくでき、また、転送履歴比較部32の処理能力を低くできるため、低コストで実現できる、という効果を得ることができる。
(第8の実施形態)
本実施形態では、低レベルの転送履歴リストの更新方法について、更新が必要な様々な状況での動作について説明する。
まず、低レベルの転送履歴リストを使用する場合に、初回転送時に全ファイルを転送し、その後ファイル追加されて、2回目の転送を行う場合について説明する。
図31は、各デバイスのファイルリストおよび転送履歴リストの遷移を示す図である。各デバイスの構成は、第6の実施形態(図21,22参照)と同様である。図31に示すデバイスA,B,Cは、それぞれファイルの送受信が可能であるが、ここでは、デバイスAを送信機器、デバイスBを受信機器とする。なお、各デバイスの転送履歴については、本実施形態の説明で必要な項目を抽出したものとする。
デバイスAは、転送履歴比較部32が、最初の送信時に、デバイスBと接続して相手デバイスIDを取得する。デバイスAでは、転送履歴比較部32が、転送履歴リストの送信のカテゴリに「相手デバイスID」がデバイスBに相当するデバイスはないので、その時点でファイルリストにある全てのファイル(a)〜(f)を送信する制御を行う。
デバイスAでは、全てのファイル(a)〜(f)をデバイスBに転送成功したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの送信カテゴリに、デバイスBのID(B)と最後に転送成功したファイル(f)の情報を保存する。このとき、転送途中で中断したファイルはないので、受信成功したパケットを示すパケットの欄には0の送信結果を保存する。
デバイスBでは、デバイスAからファイル(a)〜(f)を受信したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの受信カテゴリに、デバイスAのID(A)と最後に転送成功したファイル(f)の情報を保存する。このとき、転送途中で中断したファイルはないので、パケットの欄には0の受信結果を保存する。
その後、デバイスAに新たにファイル(g)〜(j)の4ファイルが追加されたとする。デバイスAでは、デバイスBとの2回目の接続では転送履歴リストにID=Bがあり、転送成功したファイルの情報としてファイル(f)の情報があるので、次のファイル(g)から送信する。デバイスAは、ファイル(j)まで送信完了すると、デバイスAおよびデバイスBの転送履歴リストには、転送成功したファイルの情報としてファイル(j)の情報が保存される。
つづいて、低レベルの転送履歴リストを使用する場合に、初回転送時に全ファイルを転送中にデバイス間の接続切断により転送中断し、その後再転送を行う場合について説明する。図31において、デバイスBを送信機器、デバイスAを受信機器とする。
デバイスBは、転送履歴比較部32が、最初の送信時に、デバイスAと接続して相手デバイスIDを取得する。デバイスBでは、転送履歴比較部32が、転送履歴リストの送信のカテゴリに「相手デバイスID」がデバイスAに相当するデバイスはないので、その時点でファイルリストにある全てのファイル(あ)〜(こ)を送信する制御を行う。
デバイスBでは、全てのファイル(あ)〜(こ)をデバイスAに送信を試みるが、ファイル(い)の転送成功直後に中断したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの送信カテゴリに、デバイスAのID(A)と最後に転送成功したファイル(い)の情報を保存する。このとき、転送途中で中断したファイルはないので、パケットの欄には0の送信結果を保存する。
デバイスAでは、デバイスBからファイル(あ)〜(い)を受信したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの受信カテゴリに、デバイスBのID(B)と最後に転送成功したファイル(い)の情報を保存する。このとき、転送途中で中断したファイルはないので、パケットの欄には0の受信結果を保存する。
その後、デバイスBは、デバイスAと再接続すると、ファイルの転送を再開する。デバイスBでは、転送履歴リストにID=Aがあり、転送成功したファイルの情報としてファイル(い)の情報があるので、次のファイル(う)から送信する。デバイスBは、ファイル(こ)まで送信完了すると、デバイスBおよびデバイスAの転送履歴リストには、転送成功したファイルの情報としてファイル(こ)の情報が保存される。
つづいて、低レベルの転送履歴リストを使用する場合に、初回転送時に全ファイルを転送中にデバイス間の接続切断により転送中断し、その後パケット単位で再転送を行う場合について説明する。図31において、デバイスAを送信機器、デバイスCを受信機器とする。
デバイスAは、転送履歴比較部32が、最初の送信時に、デバイスCと接続して相手デバイスIDを取得する。デバイスAでは、転送履歴比較部32が、転送履歴リストの送信のカテゴリに「相手デバイスID」がデバイスCに相当するデバイスはないので、その時点でファイルリストにある全てのファイル(a)〜(j)を送信する制御を行う。
デバイスAでは、全てのファイル(a)〜(j)をデバイスCに送信を試みるが、ファイル(f)の送信途中で中断したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの送信カテゴリに、デバイスCのID(C)と最後に転送成功したファイル(e)の情報を保存する。このとき、転送途中で中断したファイルがあるので、パケットの欄には途中履歴として30/100(成功したパケット数/全パケット数)の送信結果を保存する。例えば、1パケット64kB単位で転送したものとする。
デバイスCでは、デバイスAからファイル(a)〜(e)を受信したので、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの受信カテゴリに、デバイスAのID(A)と最後に転送成功したファイル(e)の情報を保存する。このとき、転送途中で中断したファイルがあるので、パケットの欄には途中履歴として30/100の送信結果を保存する。
その後、デバイスAは、デバイスCと再接続すると、ファイルの転送を再開する。デバイスAでは、転送履歴リストにID=Cがあり、転送成功したファイルの情報としてファイル(e)の情報、およびパケットの欄には途中履歴として30/100の情報があるので、次のファイル(f)の31番目のパケットから送信する。デバイスAは、ファイル(j)まで送信完了すると、デバイスAおよびデバイスCの転送履歴リストには、転送成功したファイルの情報としてファイル(j)の情報が保存される。
図32は、転送途中で中断されたファイル(j)の構成例を示す図である。デバイスAでは、ファイル(f)のサイズが100パケットとすると、中断時点までにパケット1〜30を送信成功しているので、送信再開後はパケット31から送信を開始し、パケット31〜100を送信する。
デバイスCでは、具体的に、差分転送制御部18において、中断途中までに受信成功しているパケット1〜30をパケット保存部33に保存しておき、復元処理部34が、パケット保存部33に保存されているパケット1〜30と送信再開後のパケット31〜100を合成することでパケット(f)を復元する。
つづいて、送信機器または受信機器のデバイスでは、ファイル転送の転送履歴を更新完了する前に電源OFFされると、送信機器側と受信機器側において転送履歴が一致しないことになる。ここでは、送信機器と受信機器で転送履歴が一致しない場合に、一方の転送履歴を更新して転送履歴を一致させるリカバリの方法について説明する。図31において、デバイスBを送信機器、デバイスCを受信機器とする。
デバイスBは、転送履歴比較部32が、最初の送信時に、デバイスCと接続して相手デバイスIDを取得する。デバイスBでは、転送履歴比較部32が、転送履歴リストの送信のカテゴリに「相手デバイスID」がデバイスCに相当するデバイスはないので、その時点でファイルリストにある全てのファイル(あ)〜(こ)を送信する制御を行う。このとき、デバイスBでは、転送履歴保存処理部30が、ファイルを1つ1つ送信するたびに、送信成功したファイル情報を、転送履歴保存部31の転送履歴ファイルに更新していく。
デバイスCでは、デバイスBからファイル(あ)〜(こ)を受信すると、転送履歴保存処理部30が、転送履歴保存部31の転送履歴リストの受信カテゴリに、デバイスBのI
D(B)と最後に転送成功したファイルの情報を保存する。このとき、デバイスCでは、転送履歴保存処理部30が、ファイルを1つ1つ受信するたびに、受信成功したファイル情報を、転送履歴保存部31の転送履歴ファイルに更新していく。
デバイスBは、最後のファイル(こ)を送信成功すると、転送履歴リストには、デバイスCの履歴としてファイル(こ)が送信されたことが記録される。ここで、デバイスC側では、最後のファイル(こ)を受信後、転送履歴ファイルを更新中(完了前)にデバイスの電源をOFFされたとする。この場合、デバイスCでは、転送履歴リストにおいて、デバイスBからの受信記録には、最後のファイル(こ)ではなく、その前のファイル(け)が記録されることになる。そのため、デバイスB,Cでは、お互いの転送履歴が一致しないことになる。
このような場合、デバイスBおよびデバイスCは、再度接続し、お互いに転送履歴を交換したときに、転送履歴が一致していないことを認識する。デバイスCは、デバイスBから取得した転送履歴の情報に基づいて、ファイル(こ)があるか検索する。該当するファイルが発見できた場合、デバイスCは、既にファイル(こ)を受信していたものとみなして、転送履歴において最後に受信したファイルをファイル(け)からファイル(こ)に更新する。これにより、どちらの転送履歴も一致することになる。
第8の実施形態によれば、ファイル送受信装置である通信デバイス1bでは、低レベルの転送履歴を使用する場合に、初回のファイル送受信時に転送履歴リストに対向機器についての項目が追加されるが、以降、既にファイルを送受信している対向機器との2回目以降のファイル送受信時では、ファイルの送受信に対して転送履歴リストに保存する情報量は増大せず、該当する対向機器との履歴のみを更新することで対応可能とした。その結果、低レベルの転送履歴を使用する場合では、新たに送受信されたファイルの詳細な情報を保存する必要がないため、転送途中に中断が生じた場合、また、相手側と転送履歴が一致しない場合のようなイレギュラーな事態が発生しても、簡易な処理で更新できる、という効果を得ることができる。
(第9の実施形態)
第6から第8の実施形態までは、第1から第3の実施形態に対応した図21に示す通信デバイス1bについて説明したが、転送履歴を利用する方法については、第4および第5の実施形態で説明したリムーバブルデバイスの通信デバイスについても対応可能である。
図33は、本実施形態の通信デバイス1cおよびホストデバイス2の構成例を示す図である。通信デバイス1cは、アプリケーション部11と、通信方向管理部12と、転送条件情報管理部13と、通信制御部14と、接続相手管理テーブル15と、送信リストテーブル16と、ホストデバイスI/F部17と、差分転送制御部18aと、を備える。
図34は、本実施形態の差分転送制御部18aの構成例を示す図である。差分転送制御部18aは、転送履歴保存処理部30と、転送履歴保存部31と、転送履歴比較部32と、パケット保存部33と、復元処理部34と、レジスタ部35と、レジスタ管理部36と、を備える。レジスタ部35は、通信デバイス1cおよびホストデバイス2の双方で利用可能なレジスタである。レジスタ管理部36は、レジスタ部35に対して、リード、ライトの処理を行う。
図35は、通信デバイス1bの構成を簡易化した図である。図35は、以降で説明する図36,37との比較を容易にするため、図21に示す構成を、通信部分と、転送履歴リストが保存されているメモリと、その他の構成をシステムとして表している。図35において、通信部分とは、図21における通信方向管理部12〜送信リストテーブル16であ
り、メモリとは、転送履歴保存部31であり、システムとは、ユーザI/F部10〜アプリケーション部11、転送履歴保存処理部30、転送履歴比較部32〜復元処理部34である。図35では、1つのデバイスでファイル送受信装置を構成しており、ホストデバイスとして機能する。
図36および図37は、通信デバイス1cおよびホストデバイス2の構成を簡略化した図である。図36および図37は、図33に示す通信デバイス1cおよびホストデバイス2の構成を簡易化した図である。図36において、通信部分とは、図33における通信方向管理部12〜送信リストテーブル16であり、ホストデバイス2のメモリとは、転送履歴保存部31であり、通信デバイス1c側のメモリとは、転送履歴保存部31であり、ホストデバイス2のシステムとは、図33におけるユーザーI/F部10、機器情報管理部20、通信デバイスI/F部21であり、通信デバイス1c側のシステムとは、アプリケーション部11、ホストデバイスI/F部17、転送履歴保存処理部30、転送履歴比較部32〜レジスタ管理部36である。
なお、図37では、ホストデバイス2のメモリに転送履歴保存部31を含んでいない点が異なる。すなわち、図36は、ホストデバイス2側にあるメモリ内と、通信デバイス1cのメモリ内の両方に、転送履歴リストが保存されている場合を示す。また、図37は、通信デバイス1cのメモリのみに、転送履歴リストが保存されている場合を示す。
図35および図37に示すように、転送履歴リストが、通信デバイス1bのみ、またはリムーバブルデバイスである通信デバイス1cのみにある場合は、転送履歴リストに差分が生じることはない。これに対して、図36に示すように、転送履歴リストが、ホストデバイス2および通信デバイス1cの双方にあり、通信デバイス1cがホストデバイス2に挿入されている場合は、2つの転送履歴リストの間で差分が生じるおそれがある。そのため、通信デバイス1cおよびホストデバイス2では、双方のシステムを通じて、転送履歴リストを同期させることとする。このとき、各転送履歴リストに差分がある場合は、プライオリティが高い方に同期させることとする。
通信デバイス1cおよびホストデバイス2で転送履歴リストを同期させる方法としては、例えば、差分転送制御部18aの転送履歴保存処理部30または転送履歴比較部32が、ホストデバイスI/F部17、通信デバイスI/F部21経由でホストデバイス2側の転送履歴リストの情報を取得し、転送履歴保存部31の転送履歴リストの内容と比較して、転送履歴保存部31の転送履歴リストの内容を変更する、またはホストデバイス2に対して、転送履歴リストの内容の変更を通知する、という方法があるが、これに限定するものではない。
第9の実施形態によれば、リムーバブルデバイスである通信デバイス1cとホストデバイス2が接続し、双方に転送履歴リストの情報が保存されている場合には、通信デバイス1cとホストデバイス2との間で転送履歴リストの同期をとることとした。その結果、通信デバイス1cとホストデバイス2との間で転送履歴リストの差分をなくすことができ、他の通信デバイスとの間でファイルを送受信する場合でも、通信デバイス1bと同様に、転送履歴リストに基づいてファイルを管理できる、という効果を得ることができる。
(第10の実施形態)
本実施形態では、第9の実施形態と同様、通信デバイス1cがホストデバイス2と接続する場合において、通信デバイス1c内のレジスタ情報を、通信デバイス1cおよびホストデバイス2の各ソフトウェアが別々に利用する場合について説明する。
図38は、通信デバイス1cおよびホストデバイス2のレジスタの利用状態を示す図で
ある。ホストデバイス2(例えば、デジカメなど)、メディア媒体である通信デバイス1cでは、通信デバイス1cのメディア媒体にはレジスタ(レジスタ部35)と、そのレジスタ情報を利用するソフトウェアYがあり、また、ホストデバイス2にも、そのレジスタ(レジスタ部35)の情報を利用する別のソフトウェアXがあるものとする。
上記レジスタ(レジスタ部35)の一部には、転送中のファイルのファイルサイズ情報と、転送中のファイルの転送済み分のファイルサイズ情報を記憶できる領域が用意されているものとする。図39は、レジスタマップの構成例を示す図である。図39において、「File Size」、「Transferred File Size」の部分が、図38に示すレジスタマップの「ファイルサイズ」および「転送済み分のファイルサイズ」に相当する。
通信デバイス1cのソフトウェアYでは、ファイルを送受信すると、レジスタに転送中のファイルのファイルサイズ情報と、転送済み分のファイルサイズを記憶させる。送受信完了するまでこの処理が定期的に何度も発生し、ファイルサイズが大きい場合にはこの回数は多くなる。具体的には、差分転送制御部18aにおいて、レジスタ管理部36が、レジスタ部35(レジスタ)の「ファイルサイズ」および「転送済み分のファイルサイズ」を更新する。
ホストデバイス2では、送受信発生中にレジスタ情報を取得することにより、転送中ファイルのファイルサイズに対してどれくらい送受信できたのかを判定できることになる。ホストデバイス2では、GUI表示することなどにより、転送の進捗度をユーザーに知らせることができる。
すなわち、ホストデバイス2側のソフトウェアXでは、別のソフトウェア(この場合、通信デバイス1c内にあるソフトウェアY)の転送中のファイルの進捗状況を直接取得することはできないが、通信デバイス1c内にあるレジスタ情報から、転送中のファイルの進捗状況を取得することが可能となる。
第10の実施形態によれば、通信デバイス1cがレジスタを備えており、通信デバイス1cおよびホストデバイス2において各ソフトウェアがともにレジスタを利用する場合に、通信デバイス1c側でレジスタの「ファイルサイズ」および「転送済み分のファイルサイズ」を更新することとした。その結果、ホストデバイス2側では、通信デバイス1c内にあるレジスタ情報を参照することで、通信デバイス1cがファイル転送中の進捗状況を取得することが可能となる、という効果を得ることができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
1,1a,1b,1c 通信デバイス、2 ホストデバイス、10 ユーザI/F部、11 アプリケーション部、12 通信方向管理部、13 転送条件情報管理部、14 通信制御部、15 接続相手管理テーブル、16 送信リストテーブル、17 ホストデバイスI/F部、18,18a 差分転送制御部、20 機器情報管理部、21 通信デバイスI/F部、30 転送履歴保存処理部、31 転送履歴保存部、32 転送履歴比較部、33 パケット保存部、34 復元処理部、35 レジスタ部、36 レジスタ管
理部。

Claims (23)

  1. 近接無線通信において、対向機器との間で第1の通信層より上位の第2の通信層における接続にコンフリクトが発生した場合に前記対向機器との前記第2の通信層における接続を切断し、前記第1の通信層を介して前記対向機器と前記第2の通信層における再接続を行う時の自装置のモードとしてマスタおよびスレーブを切り替える制御を行う通信方向管理部と、
    前記通信方向管理部からのモードの指示に従い、マスタまたはスレーブとして、前記対向機器との間でファイルの送信または受信または送受信を行うアプリケーション部と、
    を備え
    前記通信方向管理部は、前記対向機器が双方向通信の動作に対応しているかどうかを判断し、前記対向機器が双方向通信の動作に対応している場合に、双方向通信処理を行うように自装置のモードを決定し、前記対向機器が双方向通信の動作に対応していない場合に、片方向通信処理を行うように自装置のモードを決定する
    ファイル送受信装置。
  2. 前記通信方向管理部は、コンフリクト発生後に前記対向機器から前記第1の通信層を介して取得する前記対向機器の仕様情報に基づいて、前記対向機器が双方向通信の動作に対応しているかどうかを判断する
    請求項1に記載のファイル送受信装置。
  3. 前記通信方向管理部は、前記対向機器が双方向通信の動作に対応している場合に、コンフリクト発生後に前記対向機器から前記第1の通信層を介して前記対向機器を識別可能な識別情報を取得して前記第2の通信層における接続を切断し、前記対向機器の識別情報と自装置の識別情報とを比較した結果に基づいて、前記第2の通信層における再接続を行う時の自装置のモードを決定する、
    請求項1又は2に記載のファイル送受信装置。
  4. 前記通信方向管理部は、前記対向機器が双方向通信の動作に対応している場合に、前記対向機器との前記第2の通信層における接続切断した後、前記第2の通信層における再接続を行う時の自装置のモードをスレーブとし、前記対向機器から接続要求を受信しない場合は、自装置で設定した時間経過後にマスタモードに切り替える、
    請求項1又は2に記載のファイル送受信装置。
  5. 前記通信方向管理部は、コンフリクト発生後に前記対向機器から前記第1の通信層を介して前記対向機器を識別可能な識別情報を取得して前記第2の通信層における接続を切断し、前記第2の通信層における再接続を行う処理において前記対向機器から前記第1の通信層を介して再度識別情報を取得し、取得した識別情報が一致した場合に、前記アプリケーション部に対して前記第2の通信層における接続確立を通知する、
    請求項1から4のいずれか1項に記載のファイル送受信装置。
  6. 前記通信方向管理部は、前記対向機器が双方向通信の動作に対応している場合に、前記アプリケーション部において、マスタまたはスレーブの一方のモードの処理を完了後、他方のモードに切り替える制御を行う、
    請求項1から5のいずれか1項に記載のファイル送受信装置。
  7. 前記通信方向管理部は、前記対向機器が双方向通信の動作に対応しており自装置のモードがマスタの場合に、前記アプリケーション部でマスタ処理完了後に前記対向機器との前記第2の通信層における接続を切断する制御を行う、
    請求項に記載のファイル送受信装置。
  8. 前記通信方向管理部は、記対向機器が双方向通信の動作に対応していない場合、前記第2の通信層における再接続を行う時の自装置のモードをスレーブとする、
    請求項1から7のいずれか1項に記載のファイル送受信装置。
  9. さらに、
    前記対向機器から前記第1の通信層を介して取得した転送条件情報に基づいて、自装置で設定した条件に一致するファイルのみを送信または受信する制御を行う転送条件情報管理部、
    を備える請求項1から8のいずれか1項に記載のファイル送受信装置。
  10. 前記転送条件情報を、前記対向機器が複数のホストデバイスと接続する場合に、各ホストデバイスを識別可能な識別情報とする、
    請求項に記載のファイル送受信装置。
  11. 前記近接無線通信を、TransferJetとする、
    請求項1から10のいずれか1項に記載のファイル送受信装置。
  12. さらに、
    前記対向機器の識別情報と、送信および受信したファイルの情報と、を含む転送履歴リストを作成する転送履歴保存処理部と、
    前記対向機器から前記第1の通信層を介して取得した前記対向機器で作成された転送履歴リストと、自装置の転送履歴リストと、を比較した結果に基づいて、前記対向機器へ未送信のファイルを送信対象のファイルとして設定する転送履歴比較部と、
    を備える請求項1から11のいずれか1項に記載のファイル送受信装置。
  13. さらに、
    前記対向機器の識別情報と、送信および受信したファイルの情報と、を含む転送履歴リストを作成する転送履歴保存処理部と、
    前記対向機器から前記第1の通信層を介して取得した前記対向機器で作成された転送履歴リストと、自装置の転送履歴リストと、を比較した結果に基づいて、前記対向機器に対して、前記第1の通信層を介して自装置で未受信のファイルの送信を要求する転送履歴比較部と、
    を備える請求項1から11のいずれか1項に記載のファイル送受信装置。
  14. さらに、
    前記対向機器から複数回のファイル受信で取得した前記ファイルを構成するパケットを保存するパケット保存部と、
    前記パケット保存部に保存されたパケットから前記ファイルを復元する復元処理部と、
    を備え、
    前記転送履歴保存処理部は、前記転送履歴リストに、前記ファイルを構成するパケットのうち、送信または受信が成功したパケットの情報を記録する、
    請求項12または13に記載のファイル送受信装置。
  15. 前記転送履歴比較部は、前記対向機器との接続確立後、前記対向機器から前記対向機器で作成された転送履歴リストを取得する、
    請求項12から14のいずれか1項に記載のファイル送受信装置。
  16. ホストデバイスと接続可能な場合に、
    さらに、
    前記ホストデバイスが利用可能なレジスタ部と、
    送信中または受信中のファイルのファイルサイズおよび送信済みまたは受信済みのファイルサイズの情報を、前記レジスタ部に記憶するレジスタ管理部と、
    を備える請求項12から15のいずれか1項に記載のファイル送受信装置。
  17. 近接無線通信において、対向機器との間で第1の通信層より上位の第2の通信層における接続にコンフリクトが発生した場合に前記対向機器との前記第2の通信層における接続を切断し、前記第1の通信層を介して前記対向機器と前記第2の通信層における再接続を行った後、自装置のモードとしてマスタおよびスレーブを切り替える制御を行う通信方向管理部と、
    前記通信方向管理部からのモードの指示に従い、マスタまたはスレーブとして、前記対向機器との間でファイルの送信または受信または送受信を行うアプリケーション部と、
    を備え、
    前記通信方向管理部は、コンフリクト発生後に前記対向機器から前記第1の通信層を介して取得する前記対向機器の仕様情報に基づいて、前記対向機器がマスタおよびスレーブのモードを切り替える機能を有していない場合、前記第2の通信層における再接続を行う時の自装置のモードをスレーブとする、
    ファイル送受信装置。
  18. 近接無線通信において、ファイルの送信または受信または送受信が可能な対向機器との間で第1の通信層より上位の第2の通信層における接続にコンフリクトが発生した場合に、前記対向機器との前記第2の通信層における接続を切断することと、
    前記対向機器が双方向通信の動作に対応しているかどうかを判断することと、
    前記判断の結果に応じて、自装置のモードをマスタまたはスレーブに決定することと、
    前記決定されたモード前記第1の通信層を介して前記対向機器と前記第2の通信層における再接続を行うことと、
    を含み、
    前記決定は、
    前記対向機器が双方向通信の動作に対応している場合に、双方向通信処理を行うように自装置のモードを決定することと、
    前記対向機器が双方向通信の動作に対応していない場合に、片方向通信処理を行うように自装置のモードを決定することと、
    を含む
    ファイル送受信方法。
  19. ンフリクト発生後に前記対向機器から前記第1の通信層を介して前記対向機器の仕様情報取得することをさらに備え、
    前記判断は、
    前記取得された仕様情報基づいて、前記対向機器が双方向通信の動作に対応しているかどうかを判断することを含む
    請求項18に記載のファイル送受信方法。
  20. 前記対向機器が双方向通信の動作に対応している場合における決定は、
    前記対向機器のモードがマスタになる場合前記対向機器と前記第2の通信層における再接続を行う時の自装置のモードをスレーブに決定することと
    前記対向機器のモードがスレーブになる場合、前記対向機器と前記第2の通信層における再接続を行う時の自装置のモードをマスタに決定することと
    を含む
    請求項18に記載のファイル送受信方法。
  21. 前記対向機器が双方向通信の動作に対応していない場合における決定は、前記対向機器と前記第2の通信層における再接続を行う時の自装置のモードをスレーブに決定することを含む
    請求項18に記載のファイル送受信方法。
  22. さらに、
    前記対向機器の識別情報と、送信および受信したファイルの情報と、を含む転送履歴リストを作成することと、
    前記対向機器から前記第1の通信層を介して取得した前記対向機器で作成された転送履歴リストと、自装置の転送履歴リストと、を比較した結果に基づいて、前記対向機器へ未送信のファイルを送信対象のファイルとして設定することと、
    を含む請求項18から21のいずれか1項に記載のファイル送受信方法。
  23. さらに、
    前記対向機器の識別情報と、送信および受信したファイルの情報と、を含む転送履歴リストを作成することと、
    前記対向機器から前記第1の通信層を介して取得した前記対向機器で作成された転送履歴リストと、自装置の転送履歴リストと、を比較した結果に基づいて、前記対向機器に対して、前記第1の通信層を介して自装置で受信していないファイルの送信を要求することと、
    を含む請求項18から21のいずれか1項に記載のファイル送受信方法。
JP2014050845A 2014-03-13 2014-03-13 ファイル送受信装置およびファイル送受信方法 Active JP6109771B2 (ja)

Priority Applications (18)

Application Number Priority Date Filing Date Title
JP2014050845A JP6109771B2 (ja) 2014-03-13 2014-03-13 ファイル送受信装置およびファイル送受信方法
EP15717264.4A EP3117594A1 (en) 2014-03-13 2015-03-13 File transmission/reception device and control method of file transmission/reception device
US15/123,999 US9859954B2 (en) 2014-03-13 2015-03-13 File transmission/reception device and control method of file transmission/reception device
TW108125316A TWI693804B (zh) 2014-03-13 2015-03-13 Sd卡
CN202010169183.5A CN111327709B (zh) 2014-03-13 2015-03-13 文件传送/接收装置及其控制方法
CN202210935867.0A CN115277683B (zh) 2014-03-13 2015-03-13 文件传送/接收装置及其控制方法
KR1020167023864A KR101921396B1 (ko) 2014-03-13 2015-03-13 파일 송수신 디바이스 및 파일 송수신 디바이스의 제어 방법
TW109117149A TWI743802B (zh) 2014-03-13 2015-03-13 檔案傳送/接收裝置
TW106100072A TWI677204B (zh) 2014-03-13 2015-03-13 檔案傳送/接收裝置
CN201580011266.9A CN106068655B (zh) 2014-03-13 2015-03-13 文件传送/接收装置及其控制方法
PCT/JP2015/058393 WO2015137523A1 (en) 2014-03-13 2015-03-13 File transmission/reception device and control method of file transmission/reception device
TW104108257A TWI574521B (zh) 2014-03-13 2015-03-13 檔案傳送/接收裝置及其控制方法
US15/830,082 US10187118B2 (en) 2014-03-13 2017-12-04 File transmission/reception device and control method of file transmission/reception device
US16/202,446 US10454531B2 (en) 2014-03-13 2018-11-28 File transmission/reception device and control method of file transmission/reception device
US16/448,560 US10623059B2 (en) 2014-03-13 2019-06-21 File transmission/reception device and control method of file transmission/reception device
US16/808,928 US11309938B2 (en) 2014-03-13 2020-03-04 File transmission/reception device and control method of file transmission/reception device
US17/690,420 US11881910B2 (en) 2014-03-13 2022-03-09 File transmission/reception device and control method of file transmission/reception device
US18/510,795 US20240088941A1 (en) 2014-03-13 2023-11-16 File transmission/reception device and control method of file transmission/reception device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014050845A JP6109771B2 (ja) 2014-03-13 2014-03-13 ファイル送受信装置およびファイル送受信方法

Publications (2)

Publication Number Publication Date
JP2015177267A JP2015177267A (ja) 2015-10-05
JP6109771B2 true JP6109771B2 (ja) 2017-04-05

Family

ID=52988372

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014050845A Active JP6109771B2 (ja) 2014-03-13 2014-03-13 ファイル送受信装置およびファイル送受信方法

Country Status (7)

Country Link
US (7) US9859954B2 (ja)
EP (1) EP3117594A1 (ja)
JP (1) JP6109771B2 (ja)
KR (1) KR101921396B1 (ja)
CN (3) CN106068655B (ja)
TW (4) TWI693804B (ja)
WO (1) WO2015137523A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6468976B2 (ja) 2015-09-09 2019-02-13 株式会社ニフコ 給油口装置
US10623919B2 (en) 2016-09-23 2020-04-14 Nec Corporation IoT device, communication system, and control method and control program for IoT device
MX2020009170A (es) * 2018-03-06 2020-10-15 Smc Corp Sistema de comunicacion inalambrica, dispositivo inalambrico esclavo y dispositivo inalambrico maestro.
JP7037512B2 (ja) * 2019-01-08 2022-03-16 株式会社東芝 無線通信装置、無線通信方法、およびプログラム

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60138519D1 (de) * 2000-06-21 2009-06-10 Seiko Epson Corp Mobiltelefon und funkkommunikationsgerät zur gemeinsamen verarbeitung eines ankommenden anrufes
JP4005348B2 (ja) 2001-12-12 2007-11-07 富士通テン株式会社 無線端末
WO2004109996A1 (en) * 2003-06-02 2004-12-16 Matsushita Electric Industrial Co., Ltd. Device, method, and program for performing master/slave switching process
US7127164B1 (en) * 2003-08-06 2006-10-24 Eastman Kodak Company Method for rating images to facilitate image retrieval
US20060072525A1 (en) * 2004-09-23 2006-04-06 Jason Hillyard Method and system for role management for complex bluetooth® devices
EP3154206A1 (en) * 2004-10-29 2017-04-12 Sony Deutschland Gmbh Method for operating a near field communication system
JP4463237B2 (ja) 2006-04-28 2010-05-19 株式会社ソニー・コンピュータエンタテインメント 通信装置、ゲーム装置、無線ゲームコントローラおよびゲームシステム
JP2008301329A (ja) * 2007-06-01 2008-12-11 Renesas Technology Corp 無線通信システム、simカード、移動通信端末およびデータの保証方法
US9391670B2 (en) * 2007-06-15 2016-07-12 Animas Corporation Methods for secure communication and pairing of a medical infusion device and a remote controller for such medical device
JP4458184B2 (ja) * 2008-06-09 2010-04-28 ソニー株式会社 情報管理装置、通信処理装置、および方法、並びにプログラム
JP4405569B1 (ja) 2008-07-23 2010-01-27 株式会社東芝 電子機器および通信制御方法
US8451122B2 (en) * 2008-08-08 2013-05-28 Tyfone, Inc. Smartcard performance enhancement circuits and systems
US8126433B2 (en) * 2008-09-15 2012-02-28 Sony Ericsson Mobile Communications Ab Electronic devices and methods that communicate via transferjet and NFC transmitter and receiver pairing
JP2010109608A (ja) * 2008-10-29 2010-05-13 Olympus Corp 無線通信端末及び無線通信システム
US20100257239A1 (en) * 2009-04-02 2010-10-07 Qualcomm Incorporated Method and apparatus for establishing a social network through file transfers
JP2010258595A (ja) * 2009-04-22 2010-11-11 Toshiba Corp 電子機器および通信制御方法
US8045961B2 (en) * 2009-06-22 2011-10-25 Mourad Ben Ayed Systems for wireless authentication based on bluetooth proximity
JP5264629B2 (ja) * 2009-06-23 2013-08-14 キヤノン株式会社 通信端末、及び通信端末の制御方法
JP5522983B2 (ja) * 2009-06-23 2014-06-18 キヤノン株式会社 通信装置、通信装置の制御方法
JP5304513B2 (ja) * 2009-07-24 2013-10-02 ソニー株式会社 通信装置、通信方式の判別方法、及びプログラム
US20110074552A1 (en) * 2009-09-29 2011-03-31 Savi Technology, Inc. Apparatus and method for advanced communication in low-power wireless applications
JP5531553B2 (ja) 2009-10-26 2014-06-25 富士通モバイルコミュニケーションズ株式会社 電子機器
ES2643740T3 (es) * 2010-01-14 2017-11-24 France Brevets Dispositivo electrónico y método de funcionamiento del mismo
JP5781272B2 (ja) * 2010-01-29 2015-09-16 富士通株式会社 通信機器、マスタスレーブ確定方法、およびコンピュータプログラム
US8738783B2 (en) * 2010-06-22 2014-05-27 Microsoft Corporation System for interaction of paired devices
JP2012010052A (ja) * 2010-06-24 2012-01-12 Sony Corp 情報処理装置および方法、プログラム、並びに、情報処理システム
EP2442254B1 (en) * 2010-10-14 2021-04-21 Sony Corporation Near field communication device and method for near field communication
US9501399B2 (en) * 2011-02-04 2016-11-22 Kabushiki Kaisha Toshiba Memory system capable of controlling wireless communication function
JP2012231429A (ja) * 2011-04-27 2012-11-22 Canon Inc 通信装置、通信装置の制御方法、およびプログラム
KR20130022182A (ko) * 2011-08-25 2013-03-06 삼성전자주식회사 근거리 무선 통신 시스템에서 단말간 연결 우선순위를 고려하여 데이터를 송수신하는 장치 및 방법
JP5915964B2 (ja) * 2011-09-14 2016-05-11 ソニー株式会社 通信装置、通信システムおよび通信装置の制御方法
EP2690839B1 (en) * 2012-07-23 2018-09-26 STMicroelectronics (Rousset) SAS NFC apparatus capable to perform a contactless tag reading function
JP2014140125A (ja) * 2013-01-21 2014-07-31 Toshiba Corp 無線通信装置、無線通信方法および無線通信プログラム
CN103503323B (zh) * 2013-03-05 2015-02-04 华为终端有限公司 近场通信射频通信方法、装置和终端设备
CN103326749B (zh) * 2013-06-17 2016-01-13 华为终端有限公司 一种nfc射频通信的控制方法、装置及系统

Also Published As

Publication number Publication date
CN111327709A (zh) 2020-06-23
CN115277683A (zh) 2022-11-01
US9859954B2 (en) 2018-01-02
US20240088941A1 (en) 2024-03-14
US20220200660A1 (en) 2022-06-23
TW201547223A (zh) 2015-12-16
JP2015177267A (ja) 2015-10-05
US10187118B2 (en) 2019-01-22
US20180175912A1 (en) 2018-06-21
KR101921396B1 (ko) 2018-11-22
CN115277683B (zh) 2023-11-14
US11309938B2 (en) 2022-04-19
TWI693804B (zh) 2020-05-11
US20190097685A1 (en) 2019-03-28
US20200204211A1 (en) 2020-06-25
EP3117594A1 (en) 2017-01-18
US10454531B2 (en) 2019-10-22
US20170093462A1 (en) 2017-03-30
TWI743802B (zh) 2021-10-21
TW202005300A (zh) 2020-01-16
CN111327709B (zh) 2022-11-01
TWI574521B (zh) 2017-03-11
US10623059B2 (en) 2020-04-14
TWI677204B (zh) 2019-11-11
TW202114361A (zh) 2021-04-01
US11881910B2 (en) 2024-01-23
WO2015137523A1 (en) 2015-09-17
CN106068655A (zh) 2016-11-02
US20190312611A1 (en) 2019-10-10
CN106068655B (zh) 2020-04-10
TW201720068A (zh) 2017-06-01
KR20160114700A (ko) 2016-10-05

Similar Documents

Publication Publication Date Title
US11881910B2 (en) File transmission/reception device and control method of file transmission/reception device
CN102833873B (zh) 无线通信装置
JP2013157943A (ja) 無線通信装置
JP5947254B2 (ja) 無線lan装置、無線lan装置のプログラムおよび無線lan装置の制御方法
US9307068B2 (en) Information processing apparatus and communication processing method thereof
JP4932272B2 (ja) チャットシステム
JP6365594B2 (ja) 無線通信装置
JP3501968B2 (ja) データベース管理装置、および、そのプログラムが記録された記録媒体
JP4447761B2 (ja) 周辺装置の集中管理システム、方法及び記憶媒体
JP6805659B2 (ja) 無線通信装置、無線通信システム、及び無線通信設定プログラム
JP6648576B2 (ja) 画像形成装置、端末装置接続方法、およびコンピュータプログラム
JPH11327987A (ja) データベース管理装置、および、そのプログラムが記録された記録媒体
JP2005100343A (ja) 接続管理機能を有するサーバ
JP2016151795A (ja) データベースシステム及びそのマスター/スレーブ決定方法

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20151102

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170123

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170207

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170308

R151 Written notification of patent or utility model registration

Ref document number: 6109771

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350