JP6112955B2 - 通信装置、その制御方法、プログラム - Google Patents

Description

本発明は、通信装置、通信装置の制御方法、プログラムに関する。

無線通信の普及に伴い、デジタルカメラなどの携帯端末にも無線通信機能を搭載し、画像ファイルなどを送信することが考えられている（特許文献１）。例えば従来のファイル転送サービスを用いたファイル転送を考えると、まず最初にセッションを生成し、そのセッション内でファイル転送をする、という方法が用いられている。この方法をデジタルカメラからの画像ファイルの送信に用いることも考えられる。

このようにセッションを生成する方法を採用する場合、ファイル送信処理中に送信するファイルを追加したい場合は、送信処理中のセッションとは別に、新たなセッションを生成する方法が考えられる。

特開２００９−１５２６８９号公報

しかしながら、新たな送信対象ファイルが追加されるたびに新たなセッションを生成するとセッションの数が多くなってしまう。また、同時に生成できるセッション数が限定されている場合、送信処理中のセッションにおける送信処理をすべて完了させてから、新たなセッションを生成しなければならなかった。

本発明に係る通信装置は、外部装置と通信が可能な通信装置であって、前記外部装置に送信するデータの候補を表示部に表示する表示手段と、前記表示手段により表示された候補から、前記外部装置に送信する送信対象データを指定する指定手段と、前記外部装置と通信するためのセッションを制御する制御手段と、前記制御手段により生成されたセッションを用いて、前記指定手段により指定された送信対象データを前記外部装置に送信する送信手段とを有し、前記指定手段は、前記送信手段によるデータの送信が開始された後にも、前記表示手段に表示された候補から前記送信対象データをさらに指定することが可能であり、前記指定手段により前記送信対象データがさらに指定された場合、前記制御手段は既に生成されているセッションの情報を変更するよう制御し、前記送信手段は、前記制御手段により変更されたセッションを用いて、前記さらに指定された送信対象データを前記外部装置に送信することを特徴とする。

本発明によれば、送信対象の変更に応じて、生成されたセッションを柔軟に活用することが可能となる。

通信装置のハードウェア機能ブロックを示す図 通信装置のソフトウェア機能ブロックを示す図 本発明が適用されるネットワーク構成の一例を示す図 （ａ）（ｂ）は実施形態１における通信装置間のシーケンス図 実施形態１における通信装置のファイル送信機能に関わるソフトウェアタスク構成を示す図 実施形態１における通信装置のタスク間のジョブの仕様の一例を示す図 実施形態１における通信装置のＵＩタスクの処理のフローチャート図 実施形態１における通信装置のＧＵＩ画面の一例を示す図 実施形態１における通信装置の通信タスクの処理のフローチャート図 実施形態２における通信装置間のシーケンス図 実施形態２における通信装置のタスク間のジョブの仕様の一例を示す図 実施形態２における通信装置のＵＩタスクの処理のフローチャート図 実施形態２における通信装置のＧＵＩ画面の一例を示す図

［実施形態１］
以下、本実施形態に係る通信装置について、図面を参照しながら詳細に説明する。以下では、ＩＥＥＥ８０２．１１シリーズに準拠した無線ＬＡＮシステムを用いた例について説明するが、通信形態は必ずしもＩＥＥＥ８０２．１１準拠の無線ＬＡＮには限らない。

本実施形態に好適な事例におけるハードウェア構成について説明する。

図１は本発明を適用できる実施形態に係る、後述の各装置の構成の一例を表すブロック図である。

１０１は、装置全体を示す。

１０２は、記憶部１０３に記憶される制御プログラムを実行することにより装置全体を制御する制御部である。制御部１０２は、１つ又は複数のＣＰＵやＭＰＵ等のプロセッサを含む。制御部１０２は、他の装置との間で通信パラメータの設定制御も行う。

１０３は、制御部１０２が実行する制御プログラムと、通信パラメータ等の各種情報を記憶する記憶部である。また、記憶部１０３には、通信装置で生成された、又は、外部装置から受信した、画像データやファイル等を記憶してもよい。記憶部１０３は、ＲＯＭ，ＲＡＭ，ＨＤＤ，フラッシュメモリ等の各種メモリによって構成される。尚、後述する各種動作は、記憶部１０３に記憶された制御プログラムを制御部１０２が実行することにより行われる。

１０４は、ＩＥＥＥ８０２．１１シリーズに準拠した無線ＬＡＮ通信を行うための無線部である。

１０５は、各種表示を行う表示部でありＬＣＤやＬＥＤのように視覚で認知可能な情報の出力、あるいはスピーカなどの音出力が可能な機能を有する。表示部１０５は視覚情報および音情報の少なくともどちらか一方を出力する機能を備えるものである。

１０７は、アンテナ制御部、そして１０８はアンテナである。アンテナ制御部１０７はアンテナ１０８を制御して無線通信による信号を送受信する。

１０９は、ユーザが各種入力等を行い、通信装置を操作するための操作部である。操作部１０９は、各種ボタンやタッチパネル等によって構成される。

１１０は、撮像部である。撮像部１１０は、光学レンズ、ＣＭＯＳセンサ、デジタル画像処理部等を備え、光学レンズを介して入力されるアナログ信号をデジタルデータに変換して画像データを生成する。撮像部１１０によって生成された画像データは、記憶部１０３に記憶される。

尚、図１は一例であり、通信装置１０１は図１に示すハードウェア構成以外のハードウェア構成を備えていてもよい。

図２は、後述の通信制御機能を実行するソフトウェア機能ブロックの構成の一例を表すブロック図である。

２０１は、ソフトウェア機能ブロック全体を示す。

２０２は、Ｄｉｓｃｏｖｅｒｙ制御部であり、通信相手となる通信装置を検索する検索処理を動作させる。

２０３は、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ制御部である。Ｗｉ−Ｆｉ Ｄｉｒｅｃｔプロトコル仕様に基づいた制御を行い、通信装置間でどちらが無線ＬＡＮアクセスポイントになり、どちらが無線ＬＡＮステーションになるかといった無線レイヤにおける役割を決定する。Ｗｉ−Ｆｉ Ｄｉｒｅｃｔにおいては、無線ＬＡＮアクセスポイント機能を実施する通信装置をＰ２Ｐグループオーナー（以下、ＧＯ）、無線ＬＡＮステーション機能を実施する通信装置をＰ２Ｐクライアント（以下、ＣＬ）と称する。ＧＯまたは無線ＬＡＮアクセスポイントとなる場合は、後述の無線ＬＡＮアクセスポイント機能制御部２１１が起動され、ＣＬまたは無線ＬＡＮステーションとなる場合は、後述の無線ＬＡＮステーション機能制御部２１０が起動される。このＧＯ ＮｅｇｏｔｉａｔｉｏｎのプロトコルはＷｉ−Ｆｉ Ｄｉｒｅｃｔ仕様で決定されている。本発明のポイントではないため、説明は割愛する。Ｗｉ−Ｆｉ ＤｉｒｅｃｔではＧＯが構築したネットワークをＰ２Ｐグループと称する。本明細書でもネットワークのことをＰ２Ｐグループと記載する場合がある。本においては、これらは同一の意味で記載されている。なお、本明細書では、Ｐ２Ｐグループオーナー（ＧＯ）、Ｐ２Ｐクライアント（ＣＬ）および役割が未決定の通信装置群をまとめて、Ｐ２Ｐデバイスと称す。

２０４は、ＤＨＣＰクライアント制御部であり、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ制御部２０３において自通信装置の役割が無線ＬＡＮステーションとなったときに起動される。

２０５は、ＤＨＣＰサーバ制御部であり、ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ制御部２０３において自通信装置の役割が無線ＬＡＮアクセスポイントとなった時に起動される。

２０６は、ＷＰＳエンローリ制御部であり、無線ＬＡＮの通信のために必要な通信パラメ―タを、他のＷＰＳレジストラ装置より受信する。ＤＨＣＰクライアント制御部２０４と同様に、自通信装置の役割が無線ＬＡＮステーションの時に動作する。

２０７は、ＷＰＳレジストラ制御部であり、無線ＬＡＮの通信のために必要な通信パラメータを、他のＷＰＳエンローリ装置に提供する。ＤＨＣＰサーバ制御部２０５と同様に、自通信装置の役割が無線ＬＡＮアクセスポイントの時に動作する。尚、ＷＰＳレジストラによって提供される通信パラメータは、ネットワーク識別子としてのＳＳＩＤ、暗号鍵、暗号方式、認証鍵、認証方式等のパラメータである。

２０８は、無線ＬＡＮパケット受信部、２０９は、無線ＬＡＮパケット送信部であり、上位レイヤの通信プロトコルを含むあらゆるパケットの送受信をつかさどる。

２１０は、無線ＬＡＮステーション機能制御部である。自通信装置が無線ＬＡＮステーションとして動作するときの認証・暗号処理等を実施し、無線ＬＡＮアクセスポイントとして動作する装置が構築した無線ネットワークに参加する。

２１１は、無線ＬＡＮアクセスポイント機能制御部であり、自通信装置が無線ＬＡＮアクセスポイント機能として動作するときに無線ネットワークを構築し、認証・暗号処理および通信相手装置の管理等を実施する。無線ＬＡＮステーション機能制御部２１０および無線ＬＡＮアクセスポイント機能制御部２１１は、どちらか一方の機能もしくは同時に動作することが可能である。

２１２は、パケットルーティング制御部であり、無線ＬＡＮアクセスポイント機能制御部２１１が動作しているときに、通信パケットをブリッジおよびルーティングする。

２１３は、データ記憶部であり、ソフトウェアそのものおよび、無線ＬＡＮパラメータや、前述のＤＨＣＰアドレステーブルおよびＡＲＰテーブル等の各種テーブルを記憶保持している。

２１４は、サービスディスカバリ制御部であり、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ特有のサービスディスカバリ機能をつかさどる。サービスディスカバリ機能は、ＩＥＥＥ８０２．１１ｕで定められたアクションフレームを送受信することにより、相手通信装置の保有しているサービス情報をやりとりする。具体的にはＳＤ Ｑｕｅｒｙを送信し、ＳＤ Ｒｅｓｐｏｎｓｅを返答として受信する。もしくは、相手装置からのＳＤ Ｑｕｅｒｙを受信し、応答としてＳＤ Ｒｅｓｐｏｎｓｅを送信する。ＳＤ Ｒｅｓｐｏｎｓｅにはサービスの種類を示す情報が含まれており、具体的には、ファイル送信サービスや、印刷サービス、動画像ストリーミングサービス、などの種類が示される。

２１５は、Ｐ２Ｐ Ｉｎｖｉｔａｔｉｏｎ機能制御部であり、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ規格で定められたＩｎｖｉｔａｔｉｏｎ機能を制御する。本Ｉｎｖｉｔａｔｉｏｎ機能についてはＷｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に定められているため割愛するが、ＧＯ機器もしくはＣＬ機器が役割の決まっていないＰ２ＰデバイスをＰ２Ｐクライアントとして接続を促す機能である。

２１６は、アプリケーションレイヤのファイル送信サービスを提供するファイル送信サービス提供部である。ここでのアプリケーションレイヤとは、ＯＳＩ参照モデルにおける第５層以上の上位レイヤにおけるサービス提供層のことをさす。ファイル送信サービスは、ＨＴＴＰプロトコルを利用して各種要求応答の送受信や、送信ファイルの送受信処理を実施する。

２１７は、アプリケーションレイヤにおけるファイル送信サービス利用部である。対向となる装置のアプリケーションレイヤのファイル送信サービス提供部によって提供されるサービスを利用する。

２１８は、セッション管理部であり、ファイル送信サービスにおける論理的な接続を管理する。ファイル送信サービスを利用する場合は、最初に送信ファイルの情報を相手通信装置に送信してセッション生成を要求する。ファイル送信サービスを提供する場合は、受信した送信ファイル情報の内容に基づいて受信可否判断を行い、受信可能であればセッション生成要求に成功応答を返す。ここで、送信ファイル情報は、ファイルの数や、合計サイズ、ファイル名で構成される情報である。セッション管理部２１５は、セッション生成が可能と判定された場合は、無線レイヤでの接続処理を実施する。なお、セッション管理に関わる情報のやりとりは、ＩＥＥＥ８０２．１１で定められたパブリックアクションフレームを利用して行われる。

なお、図２に示す全ての機能ブロックはソフトウェアによって提供されるものに限らず、少なくとも一部がハードウェアによって提供されるようにしてもよい。そして、図２に示す各機能ブロックは、相互関係を有するものである。また、図２に示す各機能ブロックは一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、何れかの機能ブロックが更に複数の機能を行うブロックに分かれてもよい。

また、本実施形態において、アプケリーションレイヤにおけるファイル送信サービスは、そのサービスを提供する装置と、そのサービスを利用する装置とによって実現される。サービス提供装置、およびサービス利用装置は、いわゆるスマートフォン等の携帯電話、いわゆるタブレットデバイス、デジタルカメラ等に適用できる。

図３は、通信装置Ａ３２（以下、ＳＴＡ−Ａ）、通信装置Ｂ３３（以下、ＳＴＡ−Ｂ）、および、ＳＴＡ−Ａ、ＳＴＡ−Ｂとから構成されるネットワークＡ３１（以下、ネットワークＡ）を示した図である。これら全ての装置は、先に説明した図１、図２の構成を有している。

＜基本シーケンス＞
図４（ａ）は、ＳＴＡ−Ａが、記憶部１０３に格納されている画像ファイルを、ＳＴＡ−Ｂに送信する場合の、各装置間の基本的な動作シーケンスを示す模式図である。

図４（ａ）の例では、ＳＴＡ−Ａがファイル送信サービスを利用する送信側の通信装置であり、ＳＴＡ−Ｂは、ファイル送信サービスを提供する受信側の通信装置として動作している。

ＳＴＡ−Ａは、ユーザ操作によって画像送信モードの開始指示を受け付けると（Ｓ４０１）、ファイル送信サービスを利用するために当該サービスを提供している通信装置を検索するための問い合わせ信号を送信する（Ｓ４０２）。

前記問い合わせ信号を受信したＳＴＡ−Ｂは、ＳＴＡ−Ａに検出応答信号を送信する（Ｓ４０３）。

検出応答を受信したＳＴＡ−Ａは、ＳＴＡ−Ｂとファイル送信サービスの論理的な接続を確立させるため、送信ファイル情報を付加したセッション生成要求信号を送信する（Ｓ４０４）。

前記セッション生成要求信号を受信したＳＴＡ−Ｂは、ＳＴＡ−Ａに成功応答信号を送信する（Ｓ４０５）。

成功応答信号を受信すると、ＳＴＡ−Ａは、ＳＴＡ−Ｂとの間で、無線レイヤの接続処理を実施する（Ｓ４０６）。無線レイヤでの接続処理は、前述したＷｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に基づいた接続処理である。すなわちＳＴＡ−ＡまたはＳＴＡ−Ｂのどちらか一方がＧＯ（Ｐ２Ｐグループオーナー）となり、他方がＣＬ（Ｐ２Ｐクライアント）となり、ＣＬはＧＯが構築した無線ネットワークに参加することによって接続を行う。無線レイヤの接続確立後、ＧＯとＣＬの間で、ＤＨＣＰによるＩＰアドレス設定処理が実施される。

無線レイヤでの接続確立後、送信対象データの一種である送信対象ファイルの選択となる。具体的には、ＳＴＡ−Ａは表示部１０５に送信対象ファイルを選択するための画面（例えばファイルＩＤ一覧）を表示し、ＳＴＡ−Ａのユーザ操作によって送信対象ファイルが選択される。ここでは、２つの画像ファイル（１．ＪＰＧ、２．ＪＰＧ）が送信対象として選択されたとする（Ｓ４０７）。

ＳＴＡ−Ａは、選択された送信ファイルの情報をＳＴＡ−Ｂに送信し、セッション生成要求を行う（Ｓ４０８）。ここで、セッション生成要求は、ＩＥＥＥ８０２．１１で定められたパブリックアクションフレームを利用して実施されてもよいし、ＨＴＴＰプロトコルによって実施されてもよい。セッション生成要求信号を受信したＳＴＡ−Ｂは、指定された送信ファイルの受信が可能であると判定し、ＳＴＡ−Ａに成功応答信号を送信する（Ｓ４０９）。これでＳＴＡ−ＡとＳＴＡ−Ｂとの間でファイル送信を行うことが可能になる。

成功応答を受信したＳＴＡ−Ａは、送信した送信ファイル情報に基づいて、ＳＴＡ−Ｂに対する画像ファイル（１．ＪＰＧ、２．ＪＰＧ）の送信処理を実施する（Ｓ４１０、Ｓ４１４）。

その後、ＳＴＡ−Ａ側のユーザ操作によって画像送信モードの終了指示を受け付けたとする（Ｓ４１６）。するとＳＴＡ−Ａは、ＳＴＡ−Ｂとのファイル送信サービスの論理的な接続を終了させるため、セッション終了要求信号を送信する（Ｓ４１７）。セッション終了要求信号を受信したＳＴＡ−Ｂは、ＳＴＡ−Ａに成功応答信号を送信し（Ｓ４１８）、無線レイヤでの接続を切断する（Ｓ４１９）。以上が、基本的なファイル送信のシーケンスである。

＜送信対象ファイルが追加された場合＞
次に、一旦送信対象ファイルの選択後に、新たに送信対象ファイルが追加された場合のシーケンスについて、図４（ｂ）を用いて説明する。

図４（ｂ）は、図４（ａ）とＳ４１１以下の処理が異なる。Ｓ４１０で１つの画像ファイル（１．ＪＰＧ）の送信の送信中または送信完了時点で、ユーザ操作によってさらに画像ファイル（３．ＪＰＧ）が送信対象として選択されたとする（Ｓ４１１）。

この場合、ＳＴＡ−Ａは未送信の送信ファイルの情報と、新たに選択された送信ファイルの情報をＳＴＡ−Ｂに送信して、セッション変更要求を行う（Ｓ４１２）。図４（ｂ）の例では、セッション変更要求には、未送信のファイル（未送信データ）である２．ＪＰＧと、新たに選択されたファイルである３．ＪＰＧの情報が含まれることになる。

セッション変更要求信号を受信したＳＴＡ−Ｂは、指定された送信ファイルの受信が可能であるか判定し、可能であればＳＴＡ−Ａに成功応答信号を送信する（Ｓ４１３）。

その後ＳＴＡ−Ｂは、２．ＪＰＧ、３．ＪＰＧの受信に備える。成功応答を受信したＳＴＡ−Ａは、変更した送信ファイル情報に基づいて、ＳＴＡ−Ｂに対する画像ファイル（２．ＪＰＧ、３．ＪＰＧ）の送信処理を実施する（Ｓ４１４、Ｓ４１５）。

上記のようにして、本実施形態のＳＴＡ−Ａは、新たな送信対象が追加された場合には新たにセッションを生成せず、既に生成されたセッションの情報を変更して追加されたファイルを送信する。

＜各タスクの処理＞
図５は、図４で説明したファイル送信機能に関わるソフトウェアタスクの構成を模式的に示した図である。以下の説明には、説明をわかりやすくするためにソフトウェア自身が処理を実行するような記載が含まれるが、実際に処理を実行するのはソフトウェアを読み込んだハードウェアであることは言うまでもない。

５０１は、ユーザ操作に基づいて処理を実行するＵＩ（ユーザーインターフェース）タスクである。ＵＩタスク５０１はユーザ操作の内容に応じて、通信タスク５０２にジョブを送信する。５０２は、ＵＩタスク５０１から渡されるジョブに基づいて無線通信の制御を実行する通信タスクである。５０３は、ＵＩタスク５０１から通信タスク５０２にジョブを送信するためのジョブキューである。

図５に示すように、ジョブキュー５０３を設けることにより、通信タスク５０２において未処理の送信ジョブが残っている状態であっても、ＵＩタスク５０１上では新たなファイルを送信するジョブを追加することが可能となる。

ここで、図６（ａ）はジョブのデータフォーマットである。ジョブは、ジョブＩＤとパラメータから構成される。

図６（ｂ）は、ジョブに含まれるジョブＩＤ及びパラメータの内容を示す図である。ジョブＩＤには０ｘ１（接続）、０ｘ２（送信）、０ｘ３（切断）の三種類があり、それぞれのジョブにおいて、図６（ｂ）に示すようなパラメータが定義される。

図７は、図４で説明したファイル送信処理に関わるＵＩタスク５０１の制御内容を示すフローチャートである。ＵＩタスク５０１は、画像送信モードが開始されるタイミングで有効化され、画像送信モードが終了するタイミングで無効化される。本フローチャートの各ステップは、記憶部１０３に記憶されたプログラムを制御部１０２が実行することによって処理される。なお図７では、Ｓ４０１からＳ４０５で説明した受信機器の検索処理の説明は省略する。本フローチャートの開始時点において、ＵＩタスクは、検出した受信機器の情報（ＭＡＣアドレス）を備えていることを前提とする。

Ｓ７０１においてＵＩタスク５０１は、検出した受信機器との無線レイヤの接続を行うために、通信タスク５０２に接続ジョブを送信する。接続ジョブのパラメータには受信機器のＭＡＣアドレスが含まれる。

Ｓ７０２においてＵＩタスク５０１は、受信機器に送信する画像ファイルをユーザに選択させるための送信ファイル選択画面を表示する。

送信ファイル選択画面において、ユーザによって送信ファイルが選択され、送信指示を受け付けた場合（Ｓ７０３）、ＵＩタスク５０１は、その内容に基づいて通信タスク５０２に送信ジョブを送信する（Ｓ７０４）。送信ジョブのパラメータには、選択された画像ファイルの数、およびそれぞれのファイル名とサイズ情報が含まれる。

一方、送信ファイル選択画面において、ユーザからの送信モードの終了指示を受け付けた場合は（Ｓ７０５）、ＵＩタスク５０１は、受信機器との無線レイヤ接続を終了するために、通信タスク５０２に切断ジョブを送信する（Ｓ７０６）。

図８は、上述した送信ファイル選択画面の一例を示す図である。

図８（ａ）は、Ｓ７０２において表示される送信ファイル選択画面である。８０１は画像ファイルのサムネイルであり、８０２は選択を示すチェックボックスである。この図では初期の状態であるため、いずれの画像も選択されていない。８０３は送信ボタンである。少なくとも一つの画像ファイルが選択された状態において送信ボタン８０３が押された場合、Ｓ７０４が実施される。８０４は終了ボタンである。このボタンが押された場合、Ｓ７０６が実施される。

図８（ｂ）は、二つの画像ファイル（１．ＪＰＧ、２．ＪＰＧ）が選択されている状態を示す送信ファイル選択画面である。８０５は選択されていることを示すチェックボックスである。

図８（ｃ）は、送信ボタン８０３が押されてＳ７０４が実施された場合に表示される画面である。８０６は、Ｓ７０４が実施された旨と、対象の送信ファイル名をユーザに通知するポップアップ画面である。

なお、本実施形態では画像ファイルを一覧表示することで送信対象ファイルの候補を指定させることとしたが、必ずしもこの構成には限定されない。例えば、ユーザ操作に応じて１枚ずつ画像ファイルを切り替えながら表示する（いわゆる「画像送り」）場合であっても、送信対象として指定することは可能である。この場合は、例えば１つの画像ファイルの送信を指示した後、画像送りを行いながら所望の画像ファイルに対し送信指示を行えるようにすればよい。この場合、送信指示のたびに送信対象変更後の情報を反映したセッション変更要求を行うことで、複数のセッションを生成せずに、順次指定された画像ファイルを送信することが可能となる。

図９は、図４で説明したファイル送信処理に関わる通信タスク５０２の制御内容を示すフローチャートである。通信タスク５０２は、ＵＩタスク５０１と同様に、画像送信モードが開始されるタイミングで有効化され、画像送信モードが終了するタイミングで無効化される。以下、タスクが処理を実行しているかのような記載があるが、前述のように実際には、記憶部１０３に記憶されたプログラムを読み込んだ制御部１０２が各部を制御することによって各ステップは実行される。

Ｓ９０１において通信タスク５０２は、ＵＩタスク５０１からジョブを受信していないかを確認する。

接続ジョブの受信を検出した場合（Ｓ９０２）、通信タスク５０２は、無線レイヤの接続処理を実施する（Ｓ９０３）。具体的には、接続ジョブのパラメータに含まれるＭＡＣアドレスに該当する受信機器との間で、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ仕様に基づいた無線レイヤの接続処理を実施し、ＤＨＣＰによるＩＰアドレス設定処理を実施する。

送信ジョブの受信を検出した場合（Ｓ９０４）、通信タスク５０２は、無線レイヤ接続後の初めての送信ジョブであるかどうかの確認を行う（Ｓ９０５）。

初めての送信ジョブであった場合、通信タスク５０２は、送信ジョブのパラメータに含まれる送信ファイル情報を受信機器に送信し、ファイル送信サービスのセッション生成処理を実施する（Ｓ９０６）。

ここでＳ９０１に戻り、ＵＩタスク５０１からのジョブを受信していない場合は、通信タスク５０２は、未送信の画像ファイルがあれば（Ｓ９０７）、受信機器に対する画像ファイルの送信処理を実施する処理を実施する（Ｓ９０８）。ここでＳ９０８での画像ファイルの送信処理は、一つの画像ファイルの送信処理を示す。

続いて二回目以降の送信ジョブの受信を検出した場合（Ｓ９０１、Ｓ９０２、Ｓ９０４、Ｓ９０５）、通信タスク５０２は、未送信ファイルの情報を確認し（Ｓ９０９）、未送信の送信ファイル情報と、送信ジョブのパラメータに含まれる送信ファイル情報を受信機器に送信し、ファイル送信サービスのセッション変更処理を実施する（Ｓ９１０）。ここで例えば、未送信の画像ファイルが２．ＪＰＧで、送信ジョブで指定された画像ファイルが３．ＪＰＧの場合は、２．ＪＰＧと３．ＪＰＧの情報が受信機器に送信され、セッション変更処理が実施される。

ここで再びＳ９０１に戻り、ＵＩタスク５０１から切断ジョブの受信を検出した場合（Ｓ９０１、Ｓ９０２、Ｓ９０４）、通信タスク５０２は、未送信の画像ファイルがあれば（Ｓ９１１）、受信機器に対する画像ファイルの送信処理を実施する処理（Ｓ９１２）を未送信の画像ファイルが無くなるまで繰返す。すべての送信ファイルの送信処理が完了した場合、通信タスク５０２は、受信機器に対してファイル送信サービスのセッション終了処理を実施し（Ｓ９１３）、無線レイヤの接続を切断する処理を実施する（Ｓ９１４）。

以上のように本実施形態で説明した実施形態によれば、送信ファイルの送信指示が実行されたタイミングで、送信ファイル情報を改めて受信機器に送信して生成済のセッションを変更する処理を実施する。もし生成済みのセッションが存在しない場合は、つまり最初の送信指示のタイミングでは、新たにセッションを生成する処理を実施する。

これにより、画像ファイルの送信処理を開始した後でも、ユーザはいつでも送信対象の画像ファイルを追加できるようになる。また、セッション変更処理に対して受信機器からエラー応答が返された場合は、通信タスク５０２からＵＩタスク５０１にその情報を通知し、ＵＩタスク５０１がＧＵＩ画面にエラー応答を表示することで、ユーザにすぐにエラーを通知することも可能となる。このように、使い勝手の良いユーザーインターフェースを提供できる。

なお、本実施形態では、無線レイヤの接続処理が実施された後、送信ファイルが選択された後にセッション生成要求を実施する、というシーケンスを前提に説明したが、送信ファイルが選択される前にセッション生成要求を実施する、という構成にしてもよい。以下、この場合について、図９に対する変更部分を説明する。

この場合、Ｓ９０３の後にセッション生成処理を実施するステップが追加され、Ｓ９０５とＳ９０６のステップが削除され、Ｓ９０４の後はＳ９０９が実行されるようになる。具体的には、Ｓ９０３の無線レイヤ接続処理の後に、通信タスク５０２はセッション生成処理を実施する。このとき、まだ送信ファイルは選択されていないため、受信機器には仮のダミー情報を送信する。

その後通信タスク５０２は、ＵＩタスク５０１からの送信処理の受信するまで、ファイル送信処理は実行しない。ＵＩタスク５０１から送信ジョブを受信すると（Ｓ９０４）、未送信ファイル情報を取得するが（Ｓ９０９）、ここでは未送信ファイルは無いため、送信ジョブのパラメータに含まれる送信ファイル情報のみを受信機器に送信してセッション変更処理を実施する（Ｓ９１０）。

このような実施形態により、送信ファイルが選択される前にセッション生成要求を実施することも可能である。

また図９では、ＵＩタスク５０１から切断ジョブの受信を検出した場合に、未送信の画像ファイルの送信がすべて終わるまでＳ９１３を実施しないとしたが、この限りでは無い。切断ジョブの優先度を高くして、すぐにセッション終了処理を実行するように制御してもよい。また、どちらの優先度を高くするかをユーザに選択させるようにすることも可能である。

［実施形態２］
実施形態１では、ＵＩタスク５０１からは、すべて同じ優先順位の送信ジョブが送信されることを前提とした場合について説明した。本実施形態では、画像ファイルの選択時に、ファイル送信の優先度をユーザが設定できる場合の実施の形態について説明する。

なお本実施形態の特徴となる点を中心に説明し、実施形態１と同様の内容については、説明を割愛する。具体的には、各通信装置の構成、およびネットワーク構成は実施形態１の図１、図２、図３と同様であるため、説明は省略する。

図１０は、ＳＴＡ−Ａが、記憶部１０３に格納されている画像ファイルを、ＳＴＡ−Ｂに送信する場合の、各装置間の動作シーケンスを示す模式図である。ここでは図４と異なる部分について説明する。

Ｓ４１０において、一つの画像ファイル（１．ＪＰＧ）の送信が完了した時点で、ユーザ操作によって一つの画像ファイル（３．ＪＰＧ）が優先順位の高い送信対象として選択されたとする（Ｓ１００１）。選択の方法は種々考えられるが、例えば選択画面に「優先送信」といった特別なメニューを設け、そのメニューを介して選択されたファイルの優先順位を高くする方法が考えられる。この方法については後に詳述する。また、ファイルの形式に応じた優先順位を予め設定してもよい。例えば、ファイルサイズの小さな静止画ファイルや楽曲ファイルの優先順位を、よりサイズの大きな動画ファイルの優先順位よりも高く設定することが考えられる。

するとＳＴＡ−Ａは、未送信の送信ファイルの情報と、選択された送信ファイルの情報を取得し、優先対象の画像ファイルが先になるように順番に並べられた送信ファイル情報をＳＴＡ−Ｂに送信して、セッション変更要求を行う（Ｓ１００２）。ここで、具体的には、セッション変更要求には、３．ＪＰＧ、２．ＪＰＧの情報が含まれることになる。なお、３．ＪＰＧを示す情報には、後述する優先フラグが有効な値に設定されている。

Ｓ４１３によって成功応答を受信したＳＴＡ−Ａは、変更した送信ファイル情報に基づいて、ＳＴＡ−Ｂに対する画像ファイル（３．ＪＰＧ、２．ＪＰＧ）の送信処理を実施する（Ｓ１００３、Ｓ１００４）。

図１１は、本実施形態におけるジョブのデータフォーマット仕様を示す図である。

図６（ｂ）と異なる点として、送信ジョブのパラメータにおいて、ファイル情報のなかに優先フラグが追加される。

図１２は、図１０で説明したファイル送信処理に関わるＵＩタスク５０１の制御内容を示すフローチャートである。ここでは図７と異なる部分についてのみ説明する。

送信ファイル選択画面において、ユーザによって送信ファイルが選択され、送信指示を受け付けた場合（Ｓ７０３）、ＵＩタスク５０１は、その画像ファイルが優先対象かどうかを判定し（Ｓ１２０１）、優先対象である場合は送信ジョブパラメータの優先フラグを有効化し（Ｓ１２０２）、通信タスク５０２に送信ジョブを送信する（Ｓ７０４）。

このように優先フラグが有効となっている送信ジョブを受け付けた通信タスク５０２は、実施形態１で説明した受信機器へのセッション変更処理（Ｓ９１０）、あるいはセッション生成処理（Ｓ９０６）を実施する際に、優先フラグが有効となっている画像ファイルが先に送信される旨の情報を含めた送信ファイル情報を受信機器に送信する。また、実際のファイル送信処理（Ｓ９０８、Ｓ９１２）の送信順においても、それに従うように制御する。

図１３は、本実施形態における送信ファイル選択画面の一例を示す図である。ここでは図８と異なる点についてのみ説明する。

図１３（ａ）は、Ｓ７０２において表示される送信ファイル選択画面である。１３０１は、優先ボタンである。この図では初期の状態であるため、優先ボタン１３０１は選択されていない。

図１３（ｂ）は、優先ボタン１３０１が選択され、かつ画像ファイル（３．ＪＰＧ）が選択されている状態を示す送信ファイル選択画面である。１３０２は優先対象の画像ファイルが選択されていることを示すチェックボックスである。

図１３（ｃ）は、図１３（ｂ）の画面においてＳ７０４が実施された場合に表示される画面である。１３０３は、Ｓ７０４が実施された旨と、対象の送信ファイル名をユーザに通知するポップアップ画面である。

以上のように本実施形態で説明した実施形態によれば、優先対象として選択された送信ファイルの送信指示が実行されたタイミングで、対象の画像ファイルが先に送信されるように変更された送信ファイル情報を改めて受信機器に送信して生成済のセッションを変更する。

このようにすることで、あるセッションにおいて画像ファイルの送信処理を開始した後でも、いつでも優先的に送信したい画像ファイルを追加選択することができるようになる。ユーザ観点においては、ファイル送信の通信状態を気にすることなく優先的に送信したいファイルを好きなタイミングで選択できるため、使い勝手の良いユーザーインターフェースを提供できる。

［その他の実施形態］
上記の各実施形態は、本発明を実施するための一例を示すものであり、本発明の趣旨を逸脱しない限り種々の変更が可能である。また、上記実施形態１〜２は、組み合わせることができる。また、各通信装置が、実施形態１〜２のどれに従って動作するかをユーザが任意に選択できるようにしてもよい。

また、上記実施形態はＩＥＥＥ８０２．１１準拠の無線ＬＡＮを例に説明した。しかしながら、本発明は、ワイヤレスＵＳＢ、ＭＢＯＡ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＵＷＢ、ＺｉｇＢｅｅ（登録商標）等の他の無線通信において実施してもよい。また、有線ＬＡＮ等の有線通信媒体において実施してもよい。ここで、ＭＢＯＡは、Ｍｕｌｔｉ Ｂａｎｄ ＯＦＤＭ Ａｌｌｉａｎｃｅの略である。また、ＵＷＢは、ワイヤレスＵＳＢ、ワイヤレス１３９４、ＷＩＮＥＴなどが含まれる。

更に、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (5)

1. 外部装置と通信が可能な通信装置であって、
   前記外部装置に送信するデータの候補を表示部に表示する表示手段と、
   前記表示手段により表示された候補から、前記外部装置に送信する送信対象データを指定する指定手段と、
   前記外部装置と通信するためのセッションを制御する制御手段と、
   前記制御手段により生成されたセッションを用いて、前記指定手段により指定された送信対象データを前記外部装置に送信する送信手段とを有し、
   前記指定手段は、前記送信手段によるデータの送信が開始された後にも、前記表示手段に表示された候補から前記送信対象データをさらに指定することが可能であり、
   前記指定手段により前記送信対象データがさらに指定された場合、前記制御手段は既に生成されているセッションの情報を変更するよう制御し、
   前記送信手段は、前記制御手段により変更されたセッションを用いて、前記さらに指定された送信対象データを前記外部装置に送信することを特徴とする通信装置。
2. 前記制御手段は、変更後のセッションの情報を前記外部装置に送信することを特徴とする請求項１に記載の通信装置。
3. 前記指定手段により指定され、かつ前記送信手段によりまだ送信されていない未送信データがある状態で、前記指定手段により前記送信対象データがさらに指定された場合、前記制御手段は前記未送信データと前記さらに指定された送信対象データとを送信対象とするよう前記セッションの情報を変更するよう制御することを特徴とする請求項１または２に記載の通信装置。
4. 外部装置と通信が可能な通信装置の制御方法であって、
   前記外部装置に送信するデータの候補を表示部に表示する表示工程と、
   前記表示工程で表示された候補から、前記外部装置に送信する送信対象データを指定する指定工程と、
   前記外部装置と通信するためのセッションを生成する生成工程と、
   前記生成工程で生成されたセッションを用いて、前記指定工程で指定された送信対象データを前記外部装置に送信する送信工程と、
   前記送信工程でデータの送信が開始された後に、前記表示工程で表示された候補から前記送信対象データをさらに指定する工程と、
   前記送信対象データがさらに指定された場合、前記生成工程で既に生成されているセッションの情報を変更する変更工程とを有し、
   前記変更工程でセッションの情報が変更された場合、前記変更されたセッションを用いて前記さらに指定された送信対象データを前記送信工程にて送信することを特徴とする通信装置の制御方法。
5. コンピュータを、請求項１乃至３のいずれか１項に記載の通信装置の各手段として機能させるコンピュータが読み取り可能なプログラム。

Images