JP2012194695A - データ通信システム及びその制御方法 - Google Patents

Abstract

【課題】 受信側のユーザは、一度も受信したことがないが、受信可能な送信元を判別して管理することが難しかった。
【解決手段】 データを受信する受信側であるＰＣ１０２Ｂと、データを送信する送信元であるＰＣ１０２Ａ及びデータ転送装置１０１とを有するデータ通信システムにおいて、ＰＣ１０２Ｂは、データの通信においてＰＣ１０２Ｂを特定する識別子である受信ＩＤをＰＣ１０２Ａに通知し、ＰＣ１０２Ａから受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧をデータ転送装置１０１に要求し、その要求に応じてデータ転送装置１０１から送信されるデータの一覧から取得対象のデータをデータ転送装置１０１に要求する。
【選択図】 図３

Description

本発明は、データを受信する受信側と、データを送信する送信元とを有するデータ通信システムにおいて、受信側で送信元を判別する技術に関するものである。

ネットワークを介して送信元の機器から受信側の機器にデータを送信する際、受信側の機器では、送信元の機器のユーザが与えた送信者名を、受信データと共に表示するものがある（特許文献１参照）。これにより受信側のユーザは、そのデータはどこから送信されたものであるかを識別できるようにしている。

特開昭６３−２７６６５１号公報

上記従来技術では、受信側の機器で送信者名を表示するためには、送信元の機器がデータを送信する際に、その送信側のユーザが付与した送信者名を受信しなければならない。このため、受信側のユーザは、一度も受信したことがないが、受信可能な送信元を判別して管理することが難しかった。

また、送信側のユーザが付与した送信者名では、その送信者名は送信側の機器の入出力機能の範囲内で表現されたものとなる。このため、受信側の機器の入出力機能の範囲を超えていた場合には正しく送信者名を表示できない。例えば、送信者名に使用されている文字コードに対応したフォントを受信側の機器が有していない場合は、受信側の機器では、別の代替文字に置き換えられるため送信者名を受信ユーザが判別できないという問題がある。

本発明の目的は、上記従来技術の問題点を解決することにある。

本願発明の特徴は、受信側の装置が、どこから送信されたデータであるかを識別できる技術を提供することにある。

上記目的を達成するために本発明の一態様に係るデータ通信システムは以下のような構成を備える。即ち、
データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムであって、
前記第１通信装置は、
データの通信において前記第１通信装置を特定する識別子である受信ＩＤを前記第２通信装置に通知する通知手段と、
前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求手段と、
前記要求手段の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求手段とを有し、
前記第２通信装置は、
前記受信ＩＤを従って、送信対象のデータを前記サーバに登録する登録手段を有し、
前記サーバは、
前記要求手段からの要求に応じて前記データの一覧を前記第１通信装置に送信し、前記データ要求手段の要求に応答して、前記登録手段により登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とする。

本発明によれば、受信側の装置が、どこから送信されたデータであるかを識別できるという効果がある。

本発明の実施形態に係るデータ通信システムの構成を示すブロック図。 ユーザＰＣ及びデータ転送装置の構成例を説明するブロック図。 本実施形態１に係る送信元のユーザＰＣ１０２Ａから受信側のユーザＰＣ１０２Ｂへデータを送信する手順の一例を示す図。 本実施形態１に係るデータ通信システムにおける別の手順を説明する図。 本実施形態１に係るデータ転送装置の転送管理部が管理しているデータ例を示す図。 本実施形態１の受信側のＰＣで管理している管理データの構成例を示す図。 本実施形態１の送信元のＰＣで管理している管理データの構成の一例を示す図。 本実施形態１のデータ転送装置が作成する、要求された受信ＩＤに関連付けられている一時保管しているデータのリストの一例を示す図。 本実施形態１に係る受信側のＰＣにおいて送信元のＰＣを管理する処理を説明するフローチャート。 本実施形態１に係る受信側のＰＣがデータ転送装置からデータを取得する受信処理を示すフローチャート。 本実施形態に係る送信元のＰＣにおいて受信側を管理する処理を説明するフローチャート。 本実施形態２に係るデータ通信システムにおける手順を説明する図。 本実施形態２において、送信元に受信ＩＤを通知した後、受信フォルダを取得する際に利用するデータ転送装置におけるデータの構成の一例を示す図。 実施形態３に係る受信側のＰＣの受信フォルダとユーザが設定した送信元の名称の管理データの構成の一例を示す図（Ａ）、本実施形態３に係るデータ転送装置おける受信ＩＤと識別子に関連付けて管理している送信ＩＤの構成の一例を示す図（Ｂ）。 本実施形態３に係るデータ通信システムにおける手順を説明する図。 実施形態４に係る、発行するコードに関係する管理データの一例を示す図（Ａ）と、コードを発行する際に利用する管理データの一例を示す図（Ｂ）。 、 実施形態４に係るデータ転送装置において、コードを発行する際のコードの文字数を求める処理を説明するフローチャート。 本実施形態４に係るデータ転送装置において、図１７Ａ，図１７Ｂのフローチャートに従って決定したコードの文字数からコードを求める処理を説明するフローチャート。 本実施形態４に係るデータ転送装置において生成したコードの管理データからデータを削除する処理を説明するフローチャート。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、本発明の実施形態に係るデータ通信システムの構成を示すブロック図である。この送信システムでは、送信元のユーザＰＣ（第２通信装置）１０２Ａから受信側のユーザＰＣ（第１通信装置）１０２Ｂへデータ転送装置（サーバ）１０１を経由してデータを転送する例を示している。

データ転送装置１０１は、送信を行うユーザのＰＣ１０２Ａ、受信を行うユーザのユーザＰＣ１０２Ｂとネットワーク１０４を介して接続されている。これらユーザＰＣ１０２Ａ，１０２Ｂは、プログラムを動作させることにより、ＨＴＴＰ等の標準プロトコルを用いてデータ転送装置１０１にアクセスし、ＸＭＬ等で作成された情報を取得して解析する。また、これらユーザＰＣ１０２Ａ，１０２Ｂは、プログラムを利用して解析した情報を、そのＰＣが備える表示部（図２の２２１）に表示させることができる。データ転送装置１０１は、データの転送管理する転送管理部１０６、各ユーザＰＣのＩＤ等を登録しているデータベース（ＤＢ）１０７を有している。尚、転送管理部１０６の機能は、後述する図２のＣＰＵ２０６とＲＡＭ２０８にロードされたプログラムにより実現される。

送信側のユーザは、ユーザＰＣ１０２ＡでプログラムＡを実行し、そのプログラムＡの指示に従って、送信したいデータをデータ転送装置１０１へ送出する。これによりデータ転送装置１０１は、その送出されたデータを受信して一時保管する。受信側のユーザは、ユーザＰＣ１０２ＢでプログラムＢを実行し、そのプログラムＢの指示に従ってデータをデータ転送装置１０１から取得する。データ転送装置１０１は、受信側のユーザＰＣ１０２Ｂから要求されたデータを返す。

尚、実施形態では、説明の便宜上、ユーザＰＣ１０２（１０２Ａ，１０２Ｂ）として説明するが、それ以外の情報機器等の情報処理装置であってもよく、送信元及び受信側がそれぞれ複数であってもよい。また本実施形態では、プログラムによりデータ転送装置１０１とのデータのやり取りを説明したが、そのプログラムに代えて汎用のブラウザを利用してもよい。更に、ネットワーク１０４を通してデータ転送装置１０１と送受信するのでＳＳＬ等の暗号化を行ったり、認可されている情報処理装置のみで送受信を行えるようにしてもよい。また実施形態では、説明の便宜上データ転送装置１０１は、送信されたデータを一時保管しているが、受信側がアクティブであるかどうかを判断し、受信側がアクティブであれば直接送信元から受信側へデータを送信するようにしてもよい。

図２は、本実施形態に係るユーザＰＣ及びデータ転送装置１０１の構成例を説明するブロック図である。尚、図２では、ユーザＰＣ１０２Ａ、１０２Ｂの構成をＰＣ１０２で代用して示している。

データ転送装置１０１は、表示部２０１、ＶＲＡＭ２０２、ＢＭＵ２０３、キーボード２０４、ＰＤ２０５、ＣＰＵ２０６、ＲＯＭ２０７、ＲＡＭ２０８、ＨＤＤ２０９、ＦＤドライブ（ＦＤＤ）２１０、ネットワークＩ／Ｆ２１１、バス２１２を有する。ＶＲＡＭ２０２は、表示部２０１に表示するための表示データを記憶する。ＢＭＵ（ビットムーブユニット）２０３は、例えば、メモリ間（例えば、ＶＲＡＭ２０２と他のメモリとの間）のデータ転送や、メモリと各Ｉ／Ｏデバイス（例えば、ネットワークＩ／Ｆ２１１）との間のデータ転送を制御する。キーボード２０４は、文字等を入力するための各種キーを有する。ＰＤ（ポインティングデバイス）２０５は、例えば、表示部２０１に表示されたアイコン、メニューその他のコンテンツを指示又はオブジェクトのドラッグドロップのために使用される。ＣＰＵ２０６は、ＲＯＭ２０７、ＨＤＤ２０９又はフレキシブルディスク２１０に格納され、ＲＡＭ２０８に展開されたＯＳや後述する制御プログラムに基づいて、各デバイスを制御する。ＲＯＭ２０７は、各種制御プログラムやデータを保存する。ＲＡＭ２０８は、ＣＰＵ２０６のワーク領域、エラー処理時のデータの退避領域、制御プログラムのロード領域等を有する。ＨＤＤ（ハードディスクドライブ）２０９は、データ転送装置１０１で実行される各制御プログラムやデータを格納する。ネットワークＩ／Ｆ２１１は、他の情報処理装置やプリンタ等とネットワークを介して通信を行う。バス２１２は、アドレスバス、データバス及びコントロールバスを含む。

ユーザＰＣ１０２も同様に、表示部２２１、ＶＲＡＭ２２２、ＢＭＵ２２３、キーボード２２４、ＰＤ２２５，ＣＰＵ２２６，ＲＯＭ２２７，ＲＡＭ２２８，ＨＤＤ２２９，ＦＤＤ２３０、ネットワークＩ／Ｆ２３１、バス２３２を有する。表示部２２１には、例えばユーザＰＣ１０２においてプログラムのウィンドウやアイコン、メッセージ、メニューその他のユーザインタフェース情報が表示される。尚、これら各ハードウェア構成は、前述のデータ転送装置１０１の構成と同様であるため、それらの説明を省略する。尚、上記構成において、各ＣＰＵ２０６，２２６に対する制御プログラムの提供は、ＲＯＭ２０７，２２７，ＨＤＤ２０９，２２９，ＦＤＤ２１０，２３０から行うこともできる。またネットワークＩ／Ｆ２１１，２３１を介してネットワーク経由で他の情報処理装置等から行うこともできる。

図３は、本実施形態１に係る送信元のユーザＰＣ１０２Ａから受信側のユーザＰＣ１０２Ｂへデータを送信する手順の一例を示す図である。

まずＳ３０１で、受信側のユーザＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、データ転送装置１０１へ受信ＩＤの取得を要求する。これのよりＳ３０２でユーザＰＣ１０２ＢからのＳ３０１からの受信ＩＤの要求を受けると、データ転送装置１０１のＣＰＵ２０６は、ＤＢ１０７を利用してシステム全体でユニークである受信ＩＤを求めて受信側のＰＣ１０２Ｂへ返信する。これによりＳ３０１で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、その受信ＩＤを取得する。そしてその取得した受信ＩＤを、プログラムの指示に従って、ＨＤＤ２２９等にプログラムデータとして保存する。このようにＳ３０１，Ｓ３０２で、システム全体でユニークな受信ＩＤを各受信側のＰＣ毎に割り当てることで、データ転送装置１０１はデータの受信先を一意に管理することができる。尚、不図示であるが、受信ＩＤが、プログラムデータとして既に受信側のＰＣ１０２ＢのＨＤＤ２２９等に保存されていた場合は、これらＳ３０１，Ｓ３０２は省略可能である。

次にＳ３０３で、受信側のユーザＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、Ｓ３０１で取得した受信ＩＤを送信元のユーザＰＣ１０２Ａに通知する。これにより送信元のＰＣ１０２ＡのＣＰＵ２２６は、Ｓ３０４で、プログラムの指示に従って、その通知された受信ＩＤを受信してＨＤＤ２２９等へプログラムデータとして保存する。尚、受信側のＰＣ１０２Ｂから送信元のＰＣ１０２Ａへの受信ＩＤの通知は、受信側のＰＣ１０２Ｂと送信元のＰＣ１０２Ａとが近接している場合は、ネットワークＩ／Ｆ２３１を利用した何らかの近接通信を利用してもよい。一方、遠隔地にある場合は、受信側のＰＣ１０２Ｂのプログラムで通知用の情報を表示し、送信元のＰＣ１０２Ａのプログラムで通知用の情報の入力を行ってもよい。

次にＳ３０５で、送信元のＰＣ１０２Ａでは、ユーザにより送信データを選ばせた後、そのデータをデータ転送装置１０１へ登録する。ここでは、送信元のＰＣ１０２ＡのＣＰＵ２２６は、送信するデータと受信側のＰＣ１０２Ｂの受信ＩＤとをデータ転送装置１０１へ送信する。これによりＳ３０６で、データ転送装置１０１のＣＰＵ２０６は、転送管理部１０６の指示に従って、ＤＢ１０７を参照して、受信ＩＤと関連付けて、その送信されたデータを一時保管する。ここでは説明の便宜上、送信元のＰＣ１０２Ａから、送信するデータと、受信側のＰＣ１０２Ｂの受信ＩＤを各データの送信毎に組み合わせて送信している。しかし、データ転送装置１０１に、各データの送信ごとにフォルダ等の識別子を発行させ、その識別子に対して一つ或いは複数のデータを送信し、その識別子と受信ＩＤを別のタイミングで組み合わせるようにしてもよい。

次にＳ３０７で、送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従い、受信側のＰＣ１０２Ｂにデータの送信を通知する。これによりＳ３０８で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、Ｓ３０７で通知されたデータの送信通知を検知してＳ３０９を実行する。尚、送信元のＰＣ１０２Ａから受信側のＰＣ１０２Ｂへの送信通知は、ネットワーク１０４を利用したメールでの通知、或いは電話での通知などいずれの方法であってもよく、通知手段は本発明において特定されるものではない。また、後述するＳ３０９が、受信側のＰＣ１０２Ｂで一定時間毎に定期的に実行されるような場合には、送信元のＰＣ１０２Ａから受信側のＰＣ１０２Ｂへのデータ送信の通知は必須ではない。

Ｓ３０９では、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、受信ＩＤとともに、その受信ＩＤに関連付けてデータ転送装置１０１が一時保管しているデータのリストを要求する。これによりＳ３１０で、データ転送装置１０１のＣＰＵ２０６はそのリスト要求を受け取る。そして転送管理部１０６の指示に従って、前述のＳ３０６で一時保管したデータの中から、その要求とともに受信した受信ＩＤに関連付けられたデータのリスト（一覧）を受信側のＰＣ１０２Ｂへ返信する。こうしてＳ３０９でリストを取得した受信側のＰＣ１０２ＢのＣＰＵ２２６は、Ｓ３１１で、プログラムの指示に従って、Ｓ３０９で取得したデータのリストの中から、取得したいデータをデータ転送装置１０１に要求する。これによりＳ３１２で、データ転送装置１０１のＣＰＵ２０６は、そのデータ要求に応答して、転送管理部１０６の指示に従って、その指定された送信対象のデータを受信側のＰＣ１０２Ｂへ送信する。

このように、一度、受信側のＰＣ１０２Ｂから送信元のＰＣ１０２Ａへ受信ＩＤが通知されていれば、送信元のＰＣ１０２Ａは、受信側のＰＣ１０２Ｂを特定して、要求されたデータを送信することができる。そしてＳ３０５からＳ３１２の処理を繰り返すことにより、送信元のＰＣ１０２Ａから受信側のＰＣ１０２Ｂへ何度でもデータの転送を行うことができる。尚、不図示ではあるが、データ転送装置１０１で一時保管したデータは、一定期間の経過後、或いはＳ３１２で、データの取得が行われた後に任意のタイミングで削除されても良い。また、説明の便宜上、送信元のＰＣ、受信側のＰＣをそれぞれ別々に説明したが、共通のプログラムで送受信してもよい。但し、図３では、受信側のＰＣが複数の送信元のＰＣに対して受信ＩＤを通知した場合、受信ＩＤと関連付けて複数の送信元のＰＣからのデータが一時保管される。よって、受信側のＰＣは、どのデータがどの送信元のＰＣからのデータであるのかを判別したいという要望がある。

図４は、本実施形態１に係るデータ通信システムにおける別の手順を説明する図である。ここでは、受信側のＰＣで送信元のＰＣを判別する仕組みを備えた例を示している。

Ｓ４０１では、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、データ転送装置１０１へ受信ＩＤの取得を要求する。この要求によりＳ４０２でデータ転送装置１０１のＣＰＵ２０６は、転送管理部１０６の指示に従い、ＤＢ１０７を利用してシステム全体でユニークとなる受信ＩＤを求めて受信側のＰＣ１０２Ｂへ返信する。これにより受信側のＰＣ１０２ＢのＣＰＵ２２６は、その受信ＩＤを受信してＨＤＤ２２９等へプログラムデータとして保存する。このようにＳ４０１，Ｓ４０２で，システム全体でユニークとなる受信ＩＤを受信側毎に割り当てることにより、データ転送装置１０１はデータ受信側を一意に管理することができる。尚、受信ＩＤがプログラムデータとして前もってＰＣ１２０ＢのＨＤＤ２２９等へ保存されていた場合は、これらＳ４０１，Ｓ４０２を省略できることは言うまでもない。

次にＳ４０３で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従ってデータ転送装置１０１へ受信フォルダの取得を要求する。これによりデータ転送装置１０１のＣＰＵ２０６は、この取得要求を受けると転送管理部１０６の指示に従い、ＤＢ１０７を参照して、受信ＩＤ単位でユニークとなる受信フォルダを求め、受信ＩＤと関連付けて受信側のＰＣ１０２Ｂに返信する。これにより受信側のＰＣ１０２Ｂは、Ｓ４０３で、その要求した受信フォルダ（フォルダの名称）を取得する。

このときデータ転送装置１０１のＣＰＵ２０６は、Ｓ４０４で、転送管理部１０６の指示に従い、図５に示すような受信ＩＤと受信フォルダを組み合わせたレコードを作成する。このレコードは、ＩＮＤＥＸ５０１、受信ＩＤ５０２と受信フォルダ５０３を含んでいる。

図５は、本実施形態に係るデータ転送装置１０１の転送管理部１０６が管理しているデータ例を示す図である。

受信フォルダは、受信側のＰＣ１０２Ｂからの受信ＩＤを伴う要求に従ってデータ転送装置１０１が発行した受信フォルダの名称を示す。カラム５０１は、受信ＩＤと受信フォルダとを組み合わせたレコードを表すＩＮＤＥＸ（インデックス）を示す。カラム５０２は、受信ＩＤを示す。カラム５０３は受信フォルダを示す。カラム５０４，５０５は、受信ＩＤと受信フォルダとの組み合わせと、一時保管しているデータとの関係を示す。カラム５０６は、一時保管しているデータのレコードを表すＩＮＤＥＸを示す。カラム５０７は、一時保管しているデータの名前を示す。カラム５０８は、一時保管しているデータのデータ転送装置１０１におけるファイルの位置（ファイルのパス）を示す。尚、データファイルパスを、一時保管しているデータのファイルの位置としたが、データそのものをカラム５０８に持たせてもよい。

レコード５０９，５１０は、受信ＩＤが「１０００」である受信側のＰＣで、受信フォルダとしてそれぞれ「ａ」と「ｂ」が作成されたことを示している。レコード５１１は、受信ＩＤが「２０００」である受信側のＰＣで、受信フォルダ「ｃ」が作成されていることを示している。

一例として、受信ＩＤ「１０００」に対して受信フォルダ「ａ」を生成した場合、レコード５０９で示すようなレコードをＤＢ１０７に保存する。尚、受信フォルダは、受信ＩＤとの組み合わせで使用するため、受信ＩＤに対してユニークであれば良く、またシステム全体でユニークであってもよい。また説明の便宜上、受信フォルダとしたがデータ転送装置１０１が一時保管するデータを識別できるものであればよいため、データ転送装置１０１に物理的なフォルダを生成する必要はない。

再び図４に戻り、Ｓ４０５で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、Ｓ４０２，Ｓ４０４で取得した受信ＩＤと受信フォルダとを送信元のＰＣ１０２Ａに通知する。このとき受信側と送信元が遠隔地の場合には、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、送信元のＰＣ１０２Ａに通知する情報と送信元のＰＣ１０２Ａの名称を設定する画面を表示し、受信側のＰＣ１０２Ｂのユーザに入力させる。

これにより送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従って、Ｓ４０５で通知された受信ＩＤと受信フォルダとを取得する。Ｓ４０７では、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従って、送信元のＰＣ１０２Ａの名称を受信フォルダに関連付けてＨＤＤ２２９等へプログラムデータとして保存する。

図６は、本実施形態の受信側の管理データの構成の一例を示す図である。

ユーザが設定した送信元のＰＣ１０２Ａの名称は、後述する本実施形態のフローで受信側のプログラムＢによりユーザＰＣ１０２Ｂに保存される。カラム６０１は、受信フォルダの名称を示す。カラム６０２は、受信フォルダに対応するユーザが設定した送信元の名称を示す。カラム６０３は、受信フォルダに対応するユーザが設定した受信可否の状態を示す。カラム６０４は、送信ＩＤを示す。

レコード６０５は、受信フォルダ「ａ」に対して、送信元の名称として「Ｔｏｍ」が設定されており、その受信は「可」に設定されている。レコード６０６は、受信フォルダ「ｂ」に対して送信元の名称として「Ｊｅｒｒｙ」が設定されており、その受信は「否」に設定されている。レコード６０７は、受信フォルダが未設定で、送信ＩＤに対してユーザが設定した送信元の名称として「Ｇｅｏｒｇｅ」が設定されており、その受信は「可」に設定されている。このようにして、受信側のＰＣで受信フォルダと、ユーザが設定した送信元の名称とを関連付けて管理することができる。

次に再び図４のＳ４０８で、送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従い、設定画面に受信ＩＤと受信フォルダの名称、受信側の名称を表示する。そしてユーザより保存の指示が入力されると、これらを関連付けてＨＤＤ２２９等へプログラムデータとして保存する。次にＳ４０９に進み、送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従い、送信するデータと受信側の受信ＩＤと受信フォルダとをデータ転送装置１０１へ送信する。

このとき送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従い、一例として図７に示すような受信側の管理データを表示する。

図７は、本実施形態１の送信元の管理データの構成の一例を示す図である。ここでは受信ＩＤと受信フォルダとユーザが設定した受信側の名称の管理データの構成の一例を示している。

ユーザが設定した受信側の名称は、後述する本実施形態のフローで送信元のプログラムＡによりユーザＰＣ１０２Ａに保存される。カラム７０１は、受信側のＰＣ１０２Ｂの受信ＩＤを示す。カラム７０２は、受信側のＰＣ１０２Ｂの受信フォルダを示す。カラム７０３は、受信ＩＤと受信フォルダに対応するユーザが設定した受信側の名称を示す。レコード７０４は、受信ＩＤが「１０００」で、受信フォルダ「ａ」の受信側に対してユーザが設定した受信側の名称として「Ｂｕｔｃｈ」が設定されていることを示している。レコード７０５は、受信ＩＤが「２０００」で、受信フォルダ「ｃ」の受信側のＰＣ１０２Ｂに対して、ユーザが受信側の名称として「Ｓｐｉｋｅ」を設定したことを示している。レコード７０６は、受信ＩＤが「３０００」で、受信フォルダが未設定の受信側に対してユーザが設定した受信側の名称として「Ｔｙｋｅ」が設定されていることを示している。

尚、受信ＩＤと受信フォルダとが合成されて受信側から通知される場合には、分解しないで通知された値を受信ＩＤとして扱い、受信フォルダ７０２に受信フォルダ取得済みを設定するとこで、受信フォルダが未設定となる場合と区別することができる。このようにして、受信ＩＤと受信フォルダとに、ユーザが設定した受信側の名称を関連付けて管理することができる。

ここでデータ送信の指示がユーザにより実行されると、送信元のＰＣ１０２ＡのＣＰＵ２２６はプログラムの指示に従い、送信するデータと、選択された一つ以上複数の受信側の受信ＩＤと受信フォルダとをデータ転送装置１０１へ送信する（Ｓ４０９）。ここでは一例として、受信側の名称「Ｂｕｔｃｈ」を選択して送信を行うと、図７に示すような受信側の管理データに従って、受信ＩＤが「１０００」と受信フォルダ「ａ」を取得し、データと併せてデータ転送装置１０１へ送信する。

これによりＳ４１０では、データ転送装置１０１のＣＰＵ２０６は、Ｓ４０９での登録指示を受けて、転送管理部１０６の指示に従い、ＤＢ１０７を利用して受信ＩＤと受信フォルダとに関連付けて、送信されたデータを一時保管する。一例として、Ｓ４０９でデータ「ｘ.ｊｐｇ」が、受信ＩＤ「１０００」と受信フォルダ「ａ」と併せてデータ転送装置１０１へ送信されると、図５の５０６，５０７，５０８で構成される一時保管データのレコード５１５を管理データとして生成する。次に、受信ＩＤが「１０００」と受信フォルダ「ａ」を示すＩＮＤＥＸと、一時保管データのＩＮＤＥＸとを関連付けるレコード５１２を管理データとして生成する。

即ち、データ転送装置１０１では、図５の５１５，５１６に示すようなレコードを作成する。ここでは受信ＩＤが「１０００」の受信側のＰＣ１０２Ｂの受信フォルダ「ａ」のデータとして、一時保管しているデータ「ｘ．ｊｐｇ」と「ｙ．ｊｐｇ」が存在することが分かる。同様にして、レコード５１４，５１７には、受信ＩＤが「１０００」の受信側のＰＣ１０２Ｂで、受信フォルダ「ｂ」のデータとして一時保管しているデータ「ｚ．ｊｐｇ」が存在することが分かる。このように受信ＩＤ、受信フォルダ、及び一時保管しているデータを関連付けて管理している。このようにすることで、データ転送装置１０１が、一時保管データと受信ＩＤ、受信フォルダを関連付けて管理することができる。

尚、説明の便宜上、送信元のＰＣ１０２Ａから送信するデータと、受信側のＰＣ１０２Ｂの受信ＩＤと受信フォルダとを送信毎に組み合わせて送信している。しかし、データ転送装置１０１に送信単位でフォルダ等の識別子を発行させ、その識別子に対して一つ或いは複数のデータの送信を行い、その識別子と受信ＩＤと受信フォルダとを別のタイミングで組み合わせてもよいことは言うまでもない。

再び図４のＳ４１１で、送信元のＰＣ１０２ＡのＣＰＵ２２６は、プログラムの指示に従い、受信側のＰＣ１０２Ｂにデータの送信を通知する。これによりＳ４１２で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、Ｓ４１１で通知されたデータの送信を検知してＳ４１３を実行する。尚、ここで送信元のＰＣから受信側のＰＣへの送信通知は、ネットワーク１０４を利用したメールでの通知、或いは電話での通知などいずれの方法であってもよく、通知手段は本発明において特定されるものではない。また、後述するＳ４１３が受信側のＰＣで、一定時間毎に定期的に実行されるような場合には、送信元から受信側へのデータ送信の通知は必須ではない。

Ｓ４１３では、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、データ転送装置１０１に受信ＩＤに関連付けて一時保管しているデータのリストを要求する。これによりＳ４１４で、データ転送装置１０１のＣＰＵ２０６は、そのリスト要求を受けると転送管理部１０６の指示に従い、Ｓ４１０で一時保管したデータから、要求された受信ＩＤに関連付けられているデータのリストを受信側のＰＣ１０２Ｂへ返信する。一例として、受信ＩＤ「１０００」に関連付けられているデータのリストをデータ転送装置１０１へ要求すると、図５の受信ＩＤ５０２から受信フォルダ５０３、データ名５０７を求めることができる。そして、受信ＩＤ「１０００」に対応して、受信フォルダ「ａ」に一時保管しているデータ「ｘ．ｊｐｇ」と「ｙ．ｊｐｇ」があり、受信フォルダ「ｂ」に一時保管しているデータ「ｚ．ｊｐｇ」があることが分かる。

こうして求めた情報から図８に示すように、受信ＩＤに関連付けられている一時保管しているデータのリストを生成する。

図８は、本実施形態１のデータ転送装置１０１が作成した、要求された受信ＩＤに関連付けられている一時保管しているデータのリストの一例を示す図である。

８０１〜８０３は、受信ＩＤ「１０００」に関連付けられた、一時保管しているデータを示す。８０１，８０２は、受信フォルダ「ａ」に関連付けられているデータのリストを示し、８０３は、受信フォルダ「ｂ」に関連付けられているデータのリストを示している。

このようにデータ転送装置１０１から受信ＩＤに関連付けられているデータのリストが受信フォルダに関連付けて返される。尚、説明の便宜上、データのリストは、受信ＩＤ、受信フォルダ、データ名で構成されたＵＲＬとしているが、別の要素を含んでいたり、異なる形式であっても問題ない。また、一度に受信ＩＤ、受信フォルダ、データ名が返されるが、それぞれの要素毎でデータ転送装置１０１から返されるようになっていても問題ない。

こうしてＳ４１５で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、Ｓ４１３で取得したデータのリストと、Ｓ４０７で保存した送信元の管理データから送信元を取得する。一例として図８に示すデータのリストをＳ４１３で取得したとする。８０１，８０２は、受信フォルダ「ａ」に関連付けられていることが分かるので、図６のレコード６０５から、受信フォルダ「ａ」の送信元の名称は「Ｔｏｍ」であることが分かる。従って、送信元「Ｔｏｍ」からデータ「ｘ．ｊｐｇ」とデータ「ｙ．ｊｐｇ」の２つのデータがデータ転送装置１０１に送信されていることが分かる。同様に図８の８０３は、送信元「Ｊｅｒｒｙ」からデータ「ｚ．ｊｐｇ」が送信されていることが分かる。

これらの取得した情報から、不図示ではあるが受信ユーザに対して、「Ｔｏｍ」と「Ｊｅｒｒｙ」からそれぞれデータが送信されていること表示することができる。尚、送信元の名称の表示は、未受信データを持つ送信元の名称の表示のみとしてもよく、その未受信データを取得するかどうかユーザに判断させてもよい。

次に図４のＳ４１６で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、Ｓ４１３で取得したデータのリストと、Ｓ４０７で保存した送信元の管理データから、所望の（取得対象）データをデータ転送装置１０１に要求する。一例として図８に示すデータのリストをＳ４１３で取得したとする。この場合、図６における受信可否の状態６０３から受信フォルダ「ａ」は受信するが、受信フォルダ「ｂ」は受信しないように設定されている。従って、８０１，８０２で示すデータのみをデータ転送装置１０１に要求する。このようにすることで、受信側のユーザが設定したデータの受信可否に従った処理を行うことができる。

またＳ４０７で保存した、送信元の管理データにない受信フォルダが、Ｓ４１３で取得したデータのリストにある場合、その受信フォルダのデータを取得しないようにすることができる。

こうしてＳ４１７で、データ転送装置１０１のＣＰＵ２０６は、Ｓ４１６からのデータの取得要求を受けると、転送管理部１０６の指示に従い、指定されたデータを受信側へ返信する。このように、一度、受信側から送信元への受信ＩＤの通知がされていると、送信元から受信側へデータの転送を行うことができるため、図４のＳ４０９からＳ４１７を繰り返すことで、送信元から受信側へ何度でもデータの転送を行うことができる。尚、不図示ではあるが、データ転送装置１０１で一時保管したデータは、一定期間経過後、或いはＳ４１７でデータの取得が行われた後、任意のタイミングで削除される。

また説明の便宜上、データ転送装置１０１で、送信されたデータを一時保管しているが、受信側がアクティブであるかどうかを判断して受信側がアクティブであれば直接送信元から受信側へデータに受信フォルダの情報を付加して送信してもよい。

図９は、本実施形態１に係る受信側のＰＣにおいて送信元のＰＣを管理する処理を説明するフローチャートである。この処理は、例えば図６に示すような管理データの編集処理であり、受信側のＰＣ１０２ＢのＣＰＵ２２６が、ＲＡＭ２２８にロードされたプログラムを実行することにより達成される。

まずＳ９０１で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、図６に示すような送信元の管理データをＨＤＤ２２９のプログラムデータから取得する。次にＳ９０２に進み、受信側のＣＰＵ２２６は、プログラムの指示に従い、その取得した送信元の管理データを表示部２２１に表示する。次にＳ９０３に進み、受信側のＣＰＵ２２６は、プログラムの指示に従い、各送信元のＰＣごとにデータの受信操作があるかどうかを判断し、受信操作がある場合はＳ９０４に処理を進め、受信操作でない場合はＳ９０５に処理を進める。Ｓ９０４では、受信側のＣＰＵ２２６は、プログラムの指示に従い、該当する送信元の管理データを利用して、データ転送装置１０１にデータを要求してデータを取得してＳ９０２へ戻る。

Ｓ９０５では、受信側のＣＰＵ２２６は、プログラムの指示に従い、送信元毎に削除操作があるかどうかを判断し、削除操作の場合にはＳ９０６に処理を進める。Ｓ９０６で、受信側のＣＰＵ２２６は、プログラムの指示に従い、送信元の管理データから該当するレコードを削除してＳ９０２へ戻り、送信元を管理する画面を再表示する。またＳ９０５で削除操作でない場合はＳ９０７に処理を進め、受信側のＣＰＵ２２６は、プログラムの指示に従い、設定変更の操作があるかどうかを判断する。ここで設定変更操作の場合はＳ９０８に処理を進め、設定変更操作でない場合はＳ９１１に処理を進める。Ｓ９０８では、受信側のＣＰＵ２２６は、プログラムの指示に従い、送信元の名称、受信可否の設定が変更されているかどうかを確認する。ここで変更されている場合はＳ９０９に処理を進み、受信側のＣＰＵ２２６は、プログラムの指示に従い、変更されている送信元の管理データの送信元の名称と受信可否状態を更新してＳ９１０に処理を進める。Ｓ９０８で。変更がない場合、或いはＳ９０９を実行した後、Ｓ９０１で受信側のＣＰＵ２２６は、プログラムの指示に従い、Ｓ９０２で表示した送信元を管理する画面をクローズする。

またＳ９０７で設定変更の操作出ないときはステップＳ９１１に進み、受信側のＣＰＵ２２６は、プログラムの指示に従い、設定中止の操作かどうかを判断する。設定中止操作の場合にはＳ９１０に処理を進めて画面をクローズし、設定中止操作でない場合はＳ９０２へ戻り、名称の変更等の操作を反映させて表示を行う。

このように受信側で送信元を判別する仕組みを設けることで、受信側で送信元の名称の入力と表示を行うことができ、受信機器の入出力機能の範囲内で送信元の名称を管理できる。

また、図４のフローチャートで示したように、送信元から受信側にデータの送信を行うＳ４０９の前にＳ４０７で送信元の名称を保存するので、一度も受信したことがないが受信することができる送信元を図６、図９で示したように管理することができる。

図１０は、本実施形態に係る受信側のＰＣがデータ転送装置１０１からデータを取得する受信処理を示すフローチャートである。尚、このデータの取得は、一例として図９のＳ９０４のようなユーザの操作で行う。

まずＳ１００１で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、データ転送装置１０１に受信ＩＤと受信フォルダに関連付けて一時保管しているデータのリストを要求する。一例として、送信元の名称が「Ｔｏｍ」の受信が指示されたとすると図６の送信元の管理データから送信元の名称が「Ｔｏｍ」のレコード６０５より受信フォルダ「ａ」を取得する。そして、受信ＩＤ「１０００」とともにデータ転送装置１０１に要求する。

これによりＳ１００２で、データ転送装置１０１のＣＰＵ２０６は、Ｓ１００１の要求を受け、図４のＳ４１０で一時保管したデータから、要求された受信ＩＤと受信フォルダ「ａ」とに関連付けられているデータのリストを受信側へ送信する。一例として、受信ＩＤ「１０００」と受信フォルダ「ａ」に関連付けられているデータのリストをデータ転送装置１０１へ要求すると、図５のカラム５０２，５０３，５０７から、受信ＩＤ、受信フォルダ、及びデータ名を求めることができる。更に、受信ＩＤ「１０００」と受信フォルダ「ａ」に一時保管しているデータとして「ｘ．ｊｐｇ」と「ｙ．ｊｐｇ」があることが分かる。

こうして求めた情報からデータ転送装置１０１のＣＰＵ２０６は、図８に示すような、受信ＩＤと受信フォルダに関連付けられている一時保管しているデータのリストを生成する。

次にＳ１００３で、受信側のＣＰＵ２２６は、プログラムの指示に従い、Ｓ１００１で取得したデータのリストから、所望するデータをデータ転送装置１０１に要求する。これによりＳ１００４で、データ転送装置１０１のＣＰＵ２０６は、Ｓ１００３の要求を受けて、転送管理部１０６の指示に従い、指定されたデータを受信側のＰＣ１０２Ｂに送信する。このようにして、受信フォルダ毎に、データ転送装置１０１に問い合わせすることで、ユーザが指定した、送信元のＰＣ１０２Ａからのデータを受信することができる。

図１１は、本実施形態１に係る送信元のＰＣにおいて受信側を管理する処理を説明するフローチャートである。この処理は、例えば図７の管理データの編集処理であり、送信元のＰＣ１０２ＡのＣＰＵ２２６が、ＲＡＭ２２８にロードされたプログラムを実行することにより達成される。

まずＳ１１０１で、送信元のＣＰＵ２２６は、プログラムの指示に従い、図７に示すような受信側の管理データをＨＤＤ２２９に記憶されたプログラムデータから取得する。次にＳ１１０２で、送信元のＣＰＵ２２６は、プログラムの指示に従い、取得した受信側の管理データを表示部２２１に表示する。次にＳ１１０３で、送信元のＣＰＵ２２６は、プログラムの指示に従い、受信側毎に削除の操作があるかどうかを判断し、削除操作の場合にはＳ１１０４に処理を進め、削除操作でない場合はＳ１１０５に処理を進める。Ｓ１１０４で、送信元のＣＰＵ２２６は、プログラムの指示に従い、受信側の管理データから、指示されたレコードを削除してＳ１１０２へ戻り、受信側を管理する画面を再表示する。Ｓ１１０５では、送信元のＣＰＵ２２６は、プログラムの指示に従い、設定変更の操作があるかどうかを判断し、設定変更操作の場合はＳ１１０６に処理を進め、設定変更操作でない場合はＳ１１０９に処理を進める。Ｓ１１０６で、送信元のＣＰＵ２２６は、プログラムの指示に従い、受信側の名称が変更されているかどうかを確認し、変更されている場合にはＳ１１０７に処理を進め、変更されていない場合はＳ１１０８に処理を進める。Ｓ１１０７で、送信元のＣＰＵ２２６は、プログラムの指示に従い、変更されている受信側の管理データの受信側の名称を更新してＳ１１０８に処理を進める。Ｓ１１０８では、送信元のＣＰＵ２２６は、プログラムの指示に従い、Ｓ１１０２で表示した受信側を管理する画面をクローズする。

一方、Ｓ１１０５で設定変更の操作でないときはＳ１１０９に進み、送信元のＣＰＵ２２６は、プログラムの指示に従い、設定変更処理の中止かどうかを判断し、中止操作の場合にはＳ１１０８に処理を進めて画面をクローズする。また設定中止操作でない場合はＳ１１０２へ戻り、名称の変更等の操作を反映させて表示を行う。

このようにして、送信元のＰＣで受信側のＰＣの名称の入力と表示、及びその修正を行うことができるので、送信元の機器の入出力機能の範囲内で受信側の機器の名称を管理できる。

＜実施形態１の変形例１＞
上述の実施形態１では、受信フォルダを、図４のＳ４０３，Ｓ４０４で説明したようにデータ転送装置１０１で生成している。しかしながら、受信フォルダは受信ＩＤに対してユニークであればよいため、受信フォルダを受信側で独自に生成して送信元の名称を関連付けて管理することもできる。

図４において、本実施形態の受信側で独自に生成する場合の受信側で送信元を判別する仕組みを備えた送信元から受信側へ情報を送信するフローの一例を説明する。Ｓ４０１，Ｓ４０２は、前述した実施形態１と同じである。

Ｓ４０３で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、図６の送信元の管理データを利用してユニークになるように受信フォルダを独自に生成する。次のＳ４０４を省略する。Ｓ４０５，Ｓ４０６，Ｓ４０７，Ｓ４０８，Ｓ４０９は、先に説明した実施形態１と同じである。

Ｓ４１０で、データ転送装置１０１のＣＰＵ２０６は、Ｓ４０９を受けて転送管理部１０６の指示に従い、ＤＢ１０７を利用して受信ＩＤと受信フォルダとに関連付けて送信されたデータを一時保管する。

このときデータ転送装置１０１のＣＰＵ２０６は、転送管理部１０６の指示に従い、ＤＢ１０７に、図５に示した受信ＩＤと受信フォルダとを組み合わせたレコードを確認する。そしてレコードがなければ、受信ＩＤと受信フォルダを組み合わせたレコードを表すＩＮＤＥＸ５０１、受信ＩＤ５０２と受信フォルダ５０３の管理データを生成する。

一例として、データ「ｘ.ｊｐｇ」が受信ＩＤ「１０００」と受信フォルダ「ａ」と併せてデータ転送装置１０１へ送信されると、図５に示すようなレコードを生成する。

次に、図５に示した５０６〜５０８で構成される一時保管データのレコード５１５を管理データとして生成する。その後、受信ＩＤ「１０００」と受信フォルダ「ａ」を示すＩＮＤＥＸと、一時保管データのＩＮＤＥＸとを関連付けるレコード５１２のようなレコードを管理データとして生成する。このようにすることで、データ転送装置１０１で一時保管データと受信ＩＤ、受信フォルダとを関連付けて管理することができる。尚、Ｓ４１１からＳ４１７は先に説明した実施形態１と同じである。

このようにＳ４０３からＳ４０８において、受信側から送信元へ受信ＩＤ、受信フォルダを通知する際、データ転送装置１０１を必要としない。このため、受信側から送信元への通知は、データ転送装置１０１が利用できない環境においても事前に送信ＩＤと受信ＩＤをそれぞれが取得していれば受信フォルダの通知ができる。

＜実施形態１の変形例２＞
前述の実施形態１及び変形例１では、送信元毎に受信フォルダを生成して送信元の名称を関連付けて管理を行っている。しかし、送信元毎に受信ＩＤをデータ転送装置１０１から取得して受信ＩＤと送信元の名称を関連付けて管理することもできる。

図４を用いて、本実施形態の受信ＩＤと送信元の名称を関連付けて管理する場合の受信側で送信元を判別する仕組みを備えた送信元から受信側へ情報を送信するフローの一例を説明する。

Ｓ４０１，Ｓ４０２は省略される。Ｓ４０３，Ｓ４０４で、受信側のＣＰＵ２２６は、受信フォルダの代わりに、先に説明したＳ４０１，Ｓ４０２を行い、送信元毎に受信ＩＤをデータ転送装置１０１から取得する。Ｓ４０５からＳ４１２は先に説明した実施形態１の受信フォルダの代わりに送信元毎の受信ＩＤを使用する。Ｓ４１３，Ｓ４１４は先に説明した実施形態１の受信フォルダの代わりに、送信元毎の受信ＩＤを使用するが、送信元毎に受信ＩＤが変わるので送信元毎に実行する。このとき、Ｓ４１３，Ｓ４１４を送信元毎に繰り返すのではなく、複数の受信ＩＤを一度に処理できてもよい。次にＳ４１５で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、送信元の管理データから、処理している受信ＩＤと関連付けた送信元の情報を取得する。こうして取得できた送信元情報から、不図示であるが受信ユーザに対して送信元名称を表示してデータが送信されていること表示することができる。Ｓ４１６，Ｓ４１７は先に説明した実施形態１と同じである。

このように送信元毎に受信ＩＤを使用することにより、送信元の名称を関連付けて管理することができる。

＜実施形態２＞
次に本発明の実施形態２を説明する。尚、この実施形態２のシステム構成、及びデータ転送装置１０１及びＰＣ１０２のハードウェア構成は、前述の実施形態１と同様であるため、その説明を省略する。

図１２は、本発明の実施形態２において、送信元に受信ＩＤを通知した後、受信フォルダを取得するフローの一例を示している。この処理はＰＣ１０２Ａ，１０２ＢのＣＰＵ２２６、及びデータ転送装置１０１のＣＰＵ２０６が、各対応するＲＡＭにロードされたプログラムを実行することにより達成される。

まずＳ１２０１で、受信側のＰＣ１０２ＢのＣＰＵ２２６は、プログラムの指示に従い、データ転送装置１０１へ受信ＩＤの取得を要求する。これによりＳ１２０２で、データ転送装置１０１のＣＰＵ２０６は、その要求を受け、転送管理部１０６の指示に従い、ＤＢ１０７を利用してシステム全体でユニークとなる受信ＩＤを求めて受信側のＰＣ１０２Ｂに送信する。これにより受信側のＣＰＵ２２６は、その受信ＩＤを受信してプログラムの指示に従い、ＨＤＤ２２９等へプログラムデータとして保存する。尚、不図示であるが、受信ＩＤがプログラムデータとして既にＨＤＤ２２９等へ保存されていた場合は、Ｓ１２０１，Ｓ１２０２の処理は省略できることは言うまでもない。

一方、送信元のＣＰＵ２２６は、Ｓ１２０３で、プログラムの指示に従い、データ転送装置１０１へ送信ＩＤの取得を要求する。これによりＳ１２０４で、データ転送装置１０１のＣＰＵ２０６は、その要求を受けて、転送管理部１０６の指示に従い、ＤＢ１０７を利用してシステム全体でユニークとなる送信ＩＤを求めて送信元のＰＣ１０２Ａへ送信する。こうして送信元のＣＰＵ２２６は、その送信ＩＤを受信してプログラムの指示に従い、ＨＤＤ２２９等へプログラムデータとして保存する。このようにして、Ｓ１２０３，Ｓ１２０４において、システム全体でユニークとなる送信ＩＤを送信元毎に割り当てることができ、データ転送装置１０１は、データ転送元を一意に管理することができる。尚、不図示であるが、送信ＩＤがプログラムデータとして既にＨＤＤ２２９等へ保存されていた場合は、これらＳ１２０３，Ｓ１２０４は省略できることは言うまでもない。

次にＳ１２０５で、受信側のＣＰＵ２２６は、プログラムの指示に従い、Ｓ１２０２で取得した受信ＩＤを送信元に通知し、送信元から送信ＩＤを取得する。このとき受信側のＣＰＵ２２６は、送信元の名称を設定する項目を持つ画面を表示する。このとき送信元のＣＰＵ２２６は、Ｓ１２０６で、プログラムの指示に従い、Ｓ１２０４で要求された送信ＩＤを受信側のＰＣ１０２Ｂに通知し、受信側から受信ＩＤを取得する。このとき送信元のＣＰＵ２２６は、受信側の名称を設定する項目を持つ画面を表示する。

次に受信側のＣＰＵ２２６は、Ｓ１２０７で、ユーザの指示があれば、プログラムの指示に従い、送信元の名称を送信ＩＤに関連付けてＨＤＤ２２９等へプログラムデータとして保存する。一例として、送信元の名称に設定されている「Ｇｅｏｒｇｅ」とＳ１２０５で取得した送信ＩＤ「４０００」を、図６のレコード６０７にしてプログラムデータとして保存する。

また送信元のＣＰＵ２２６は、Ｓ１２０８で、プログラムの指示に従い、受信側の名称を受信ＩＤに関連付けてＨＤＤ２２９等へプログラムデータとして保存する。一例として、ユーザにより受信側の名称を登録する指示が実行されると、名称に設定されている「Ｔｙｋｅ」と、Ｓ１２０６で取得した受信ＩＤ「３０００」を、図７のレコード７０６にして、プログラムデータとして保存する。

次に受信側のＣＰＵ２２６は、Ｓ１２０９で、プログラムの指示に従い、送信元の管理データから受信フォルダが未設定で送信ＩＤが設定されているレコードを判定する。受信フォルダが未設定の場合はＳ１２１０に処理を進め、受信フォルダが未設定のものがなければ処理を終了する。Ｓ１２１０で、受信側のＣＰＵ２２６は、プログラムの指示に従い、受信ＩＤと送信ＩＤとをデータ転送装置１０１に通知して受信フォルダを取得する。ここでは受信側のＣＰＵ２２６は、プログラムの指示に従い、受信フォルダが未設定のレコードに該当する返信された受信フォルダを設定してＨＤＤ２２９等へプログラムデータとして保存し、処理を終了する。

また送信元のＣＰＵ２２６は、Ｓ１２１１で、プログラムの指示に従い、受信側の管理データから受信フォルダが未設定のレコードを判定する。受信フォルダが未設定の場合はＳ１２１２に処理を進め、受信フォルダが未設定のものがなければ処理を終了する。Ｓ１２１２では、送信元のＣＰＵ２２６は、プログラムの指示に従い、受信ＩＤと送信ＩＤとをデータ転送装置１０１のＰＣ１０２Ｂに通知して受信フォルダを取得する。そして送信元のＣＰＵ２２６は、プログラムの指示に従い、受信フォルダが未設定のレコードに該当する返信された受信フォルダを設定してＨＤＤ２２９等へプログラムデータとして保存し、処理を終了する。

またデータ転送装置１０１のＣＰＵ２０６は、Ｓ１２１３で、Ｓ１２１０，Ｓ１２１２の要求を受けると、転送管理部１０６の指示に従い、受信した受信ＩＤと送信ＩＤとに関連付けた受信フォルダがあるかどうかを判断する。ここで、受信ＩＤと送信ＩＤとに関連付けた受信フォルダがあれば処理をＳ１２１５に進め、関連付けた受信フォルダがなければ処理をＳ１２１４に進める。一例として、受信ＩＤ「３０００」と送信ＩＤ「４０００」に関連付けられている受信フォルダをデータ転送装置１０１へ要求すると、図１３の受信ＩＤ１３０１、送信ＩＤ１３０２から受信フォルダ１３０３を求めることができる。

図１３は、本実施形態２において、受信フォルダを取得する際に利用するデータ転送装置１０１におけるデータの構成の一例を示す図である。

カラム１３０１は受信ＩＤを示す。カラム１３０２は送信ＩＤを示す。カラム１３０３は、受信ＩＤと送信ＩＤとに対応する受信フォルダを示す。レコード１３０４は、一例として受信ＩＤ「３０００」の受信側と、送信ＩＤ「４０００」の送信元において、送信元から受信側に受信フォルダ「ｅ」が設定されていることを示している。即ち、受信ＩＤ「３０００」と送信ＩＤ「４０００」に関連付けられている受信フォルダとして受信フォルダ「ｅ」が生成されていることが分かる。尚、受信フォルダが生成されていない場合は該当するレコードがない状態となる。

またＳ１２１４で、データ転送装置１０１のＣＰＵ２０６は、受信ＩＤと送信ＩＤとに関連付けた受信フォルダを生成し、図１３のレコード１３０４に示すような情報をＤＢ１０７に保存する。尚、受信ＩＤと関連付けた受信フォルダの生成は、図４のＳ４０４で説明した方法と同じである。

このようにＳ１２０５からＳ１２０８において、受信側との送信元との間で受信ＩＤ及び送信ＩＤを通知することにより、これらＩＤをデータ転送装置１０１から取得する必要がなく、また受信側と送信元がそれぞれ後から受信フォルダを取得できる。このため、受信側と送信元との間での受信ＩＤ及び送信ＩＤの通知に際して、データ転送装置１０１が利用できない環境においても、事前に送信ＩＤと受信ＩＤをそれぞれを取得して受信フォルダの通知ができる。

＜実施形態２の変形例１＞
実施形態１では、送信ＩＤ、受信ＩＤ、受信フォルダをそれぞれで個別に生成したが送信ＩＤ、受信ＩＤと送信元の名称を関連付けて管理することもできる。

図１２を用いて、受信側で送信元を判別する仕組みを備え、送信元から受信側へ情報を送信する処理について説明する。

Ｓ１２０１からＳ１２０６は先に説明した実施形態２と同じである。Ｓ１２０７で、受信側のＣＰＵ２２６は、プログラムの指示に従い、送信元の名称を送信ＩＤに関連付けてＨＤＤ２２９等へプログラムデータとして保存する。一例として、ユーザにより登録指示が実行されると、名称に設定されている「Ｇｅｏｒｇｅ」と、Ｓ１２０５で取得した送信ＩＤ「４０００」を、図６のレコード６０７にしてプログラムデータとして保存する。

このとき実施形態１では、図６の送信ＩＤに送信ＩＤ「４０００」を設定したが、送信ＩＤがシステム全体で混在しないユニークなＩＤなのでカラム６０１の受信フォルダに送信ＩＤ「４０００」を設定する。

またＳ１２０８で、送信元のＣＰＵ２２６は、プログラムの指示に従い、受信側の名称を受信ＩＤに関連付けてＨＤＤ２２９等へプログラムデータとして保存する。一例として、受信側の名称を登録する指示がユーザにより実行されると、名称に設定されている「Ｔｙｋｅ」と、Ｓ１２０６で取得した受信ＩＤ「３０００」を図７に示すようなレコード７０６としてプログラムデータとして保存する。

このとき実施形態２では、図７のカラム７０２の受信フォルダを未設定としたが、送信ＩＤがシステム全体で混在しないユニークなＩＤなので、カラム７０２の受信フォルダに送信ＩＤの値「４０００」を設定する。Ｓ１２０９からＳ１２１５の処理は行わない。尚、データ転送装置１０１では、受信ＩＤと受信フォルダを組み合わせたレコードがデータ送信前に生成できないので、実施形態１のＳ４１０で説明した処理を行うこととなる。

尚、送信元のＰＣ１０２Ａでは、Ｓ１２１２の後でＳ４１１で送信通知を受信側のＰＣ１０２Ｂに送信し、Ｓ４１２で、受信側のＰＣ１０２Ｂは、この送信通知を受信する。この後の処理は、前述の図４と同じであるため、その説明を省略する。

このように、送信ＩＤを受信フォルダと同等に扱うことにより、送信ＩＤを取得できれば受信フォルダを生成する必要がない。

＜実施形態３＞
次に本発明の実施形態３を説明する。尚、この実施形態３のシステム構成、及びデータ転送装置１０１及びＰＣ１０２のハードウェア構成は、前述の実施形態１と同様であるため、その説明を省略する。

図１４（Ａ）は、本実施形態３に係る受信側のＰＣの受信フォルダとユーザが設定した送信元の名称の管理データの構成の一例を示す図である。

ユーザが設定した送信元の名称は、後述する本実施形態３のフローで受信側のプログラムＢによりユーザＰＣ１０２Ｂに保存される。

カラム１４０１は、仮登録時の送信元と、ユーザが設定した送信元の名称を関連付ける識別子を示す。カラム１４０２は、ユーザが設定した送信元の名称を示す。カラム１４０３は、受信フォルダに対応するユーザが設定した受信可否の状態を示す。カラム１４０４は送信ＩＤを示す。

レコード１４０５は、登録状態で識別子「ａ」に対してユーザが設定した送信元の名称が「Ｔｏｍ」であり、送信ＩＤが「４０００」であることを示している。レコード１４０６は、仮登録状態で識別子「ｂ」に対してユーザが設定した送信元の名称が「Ｊｅｒｒｙ」であることを示している。レコード１４０７は、仮登録状態で、識別子「ｃ」に対して、ユーザが設定した送信元が「Ｇｅｏｒｇｅ」であることを示している。このように送信ＩＤとユーザが設定した送信元の名称を関連付けて管理することができる。

図１４（Ｂ）は、本実施形態３に係るデータ転送装置１０１おける受信ＩＤと識別子に関連付けて管理している送信ＩＤの構成の一例を示す図である。

カラム１４１０は受信ＩＤを示す。カラム１４１１は識別子を示す。カラム１４１２は、受信ＩＤと識別子とに関連付けられた送信ＩＤを示す。レコード１４１３は、受信ＩＤが「１０００」、識別子「ａ」に対して送信ＩＤが「４０００」に設定されていることを示している。レコード１４１４は、受信ＩＤが「１１００」、識別子「ｃ」に対して送信ＩＤが「４１００」に設定されていることを示している。またレコード１４１５は、受信ＩＤが「１２００」、識別子「ｂ」に対して送信ＩＤが「４２００」に設定されていることを示している。このように受信ＩＤと識別子に関連付けて送信ＩＤを管理することができる。

図１５は、本実施形態３に係るデータ通信システムにおける手順を説明する図である。ここでは、受信側が送信ＩＤとユーザが設定した送信元の名称を関連付ける仕組みを備えており、送信元から受信側へ情報を送信する場合で説明する。

Ｓ１５０１で、受信側のＣＰＵ２２６は、プログラムの指示に従い、データ転送装置１０１へ受信ＩＤの取得を要求する。これによりデータ転送装置１０１のＣＰＵ２０６は、Ｓ１５０２で、Ｓ１５０１の要求を受け、転送管理部１０６の指示に従い、ＤＢ１０７を利用してシステム全体でユニークとなる受信ＩＤを求めて受信側へ送信する。これにより受信側のＣＰＵ２２６は、その返信された受信ＩＤを、プログラムの指示に従いＨＤＤ２２９等へプログラムデータとして保存する。尚、不図示であるが、受信ＩＤがプログラムデータとして既にＨＤＤ２２９等へ保存されていた場合は、これらＳ１５０１，Ｓ１５０２を実行しなくてもよい。

一方、送信元のＣＰＵ２２６は、Ｓ１５０３で、プログラムの指示に従い、データ転送装置１０１へ送信ＩＤの取得を要求する。これによりデータ転送装置１０１のＣＰＵ２０６は、Ｓ１５０４で、その要求を受けると、転送管理部１０６の指示に従い、ＤＢ１０７を利用して、システム全体でユニークとなる送信ＩＤを求めて送信元へ送信する。これにより送信元のＣＰＵ２２６は、その返信された送信ＩＤを、プログラムの指示に従い、ＨＤＤ２２９等へプログラムデータとして保存する。このようにＳ１５０３，Ｓ１５０４においてシステム全体でユニークとなる送信ＩＤを送信元毎に割り当てることで、データ転送装置１０１はデータ転送元を一意に管理することができる。尚、不図示であるが、送信ＩＤがプログラムデータとして既にＨＤＤ２２９等へ保存されていた場合は、Ｓ１５０３，Ｓ１５０４を実行しなくてもよい。

次に受信側のＣＰＵ２２６は、Ｓ１５０５で、プログラムの指示に従い、仮の登録で必要となる識別子を生成し、Ｓ１５０２で取得した受信ＩＤとともに送信元に通知する。尚、この識別子は、受信側でユニークであればよく、受信側で生成してもよいし、データ転送装置１０１で生成してもよい。このとき受信側と送信元が遠隔地の場合は、受信側のＣＰＵ２２６は、プログラムの指示に従い、送信元に通知する情報と送信元の名称を設定する画面を表示する。尚、送信元に通知する情報は、前述した受信フォルダではなく識別子となることは言うまでもない。

これにより送信元のＣＰＵ２２６は、Ｓ１５０６で、プログラムの指示に従い、Ｓ１５０５で通知された受信ＩＤと識別子とを取得する。

次に受信側のＣＰＵ２２６は、Ｓ１５０７で、プログラムの指示に従い、送信元の名称を識別子に関連付けてＨＤＤ２２９等へプログラムデータとして、仮の登録状態で保存する。一例として、ユーザにより送信元の名称の登録指示が実行されると、名称に設定されている「Ｔｏｍ」と、そのときの受信フォルダ「ａ」を図１４（Ａ）のレコード１４０５にしてプログラムデータとして保存する。

また送信元のＣＰＵ２２６は、Ｓ１５０８で、プログラムの指示に従い、設定画面に受信側の名称、受信ＩＤを表示し、これらをＨＤＤ２２９へプログラムデータとして保存する。次にＳ１５０９で、送信元のＣＰＵ２２６は、プログラムの指示に従い、通知された受信ＩＤと識別子とに関連付けて、送信ＩＤをデータ転送装置１０１へ送信する。これによりデータ転送装置１０１のＣＰＵ２０６は、Ｓ１５１０で、Ｓ１５０９の要求を受けると、転送管理部１０６の指示に従い、ＤＢ１０７を利用して受信ＩＤと識別子に関連付けて送信ＩＤを一時保管する。一例として、受信ＩＤが「１０００」、識別子が「ａ」に対して送信ＩＤが「４０００」の場合には、図１４（Ｂ）のレコード１４１３のようなレコードを管理データとして生成する。尚、不図示であるが、送信ＩＤの一時保管は、後述する受信側からの問い合わせで返信をした後、或いは一定期間経過後で削除してもよい。

また受信側のＣＰＵ２２６は、Ｓ１５１１で、プログラムの指示に従い、送信元からのデータ送信の通知、或いは一定時間毎に定期的に送信元の名称が仮登録状態のものがあるかどうかを判断する。ここで送信元の名称が仮登録状態のものがあればＳ１５１２に処理を進め、仮登録状態のものがなければ処理を終了する。

一例として、図１４（Ａ）のレコード１４０６，１４０７に示すような送信ＩＤが設定されていないレコードが存在すれば仮登録状態のものがあることになる。

次にＳ１５１２に進み、受信側のＣＰＵ２２６は、プログラムの指示に従い、受信ＩＤと送信元の名称が仮登録状態の識別子を組としてデータ転送装置１０１へ送信ＩＤの確認を要求する。これによりデータ転送装置１０１のＣＰＵ２０６は、Ｓ１５１３で、その要求された受信ＩＤと識別子に基づいて、Ｓ１５１０で一時保管した送信ＩＤを返信する。これにより受信側のＣＰＵ２２６は、Ｓ１５１４で、プログラムの指示に従い、Ｓ１５１３で取得した識別子に対応する送信ＩＤがあるかどうかを判定する。そして識別子に対応する送信ＩＤがあればＳ１５１５に処理を進め、識別子に対応する送信ＩＤがなければ処理を終了する。Ｓ１５１５では、受信側のＣＰＵ２２６は、プログラムの指示に従い、識別子に対応する送信ＩＤを送信元の名称の管理データに設定して仮登録状態を登録状態に変え処理を終了する。一例として、図１４（Ａ）のレコード１４０５に示すように、送信ＩＤが設定されている状態にすることで仮登録状態が登録状態に変わる。

データの送受信は、先に説明した実施形態１における受信フォルダを送信ＩＤに置き換えることで、Ｓ４０９からＳ４１７にて同様に処理することができる。このようすることで、受信フォルダを利用しなくても送信元の名称を受信側で管理することができる。

尚、送信元のＰＣ１０２Ａでは、Ｓ１５０９の後でＳ４１１で送信通知を受信側のＰＣ１０２Ｂに送信し、Ｓ４１２で、受信側のＰＣ１０２Ｂは、この送信通知を受信する。この後の処理は、前述の図４と同じであるため、その説明を省略する。

＜実施形態４＞
次に本発明の実施形態４について説明する。尚、この実施形態４のシステム構成、及びデータ転送装置１０１及びＰＣ１０２のハードウェア構成は、前述の実施形態１と同様であるため、その説明を省略する。この実施形態４は、前述の実施形態の受信ＩＤや送信ＩＤを示すコードを表す文字数（桁数）が多すぎるため、ユーザが電話などで音声で伝えることが難しかく、またその入力も容易でなかったことに鑑みてなされたものである。そこで本実施形態４では、そのコードの発行状況や動作状況や用途などに応じて、そのコードの字数を調整することを目的としている。

図１６（Ａ）（Ｂ）は、本実施形態３のデータ転送装置１０１において利用する管理データの一例を示す図である。

図１６（Ａ）は、発行するコードに関係する管理データの一例を示し、図１６（Ｂ）は、コードを発行する際に利用する管理データの一例を示している。

情報番号１６０１は、データ転送装置１０１で受信し保存した情報に対して、データ転送装置１０１でユニークになるように発行され情報を管理する番号である。１６０２は、データ転送装置１０１で受信し保存した情報のファイルパスを示す。この実施形態４では、ファイルパスで情報を管理しているが、ファイルパスの代わりに直接情報を扱ってもよい。情報番号１６０３は、コード１６０４と関連付ける情報番号である。コード１６０４は、情報番号と関連付けられたコードである。コード１６０５は、データ転送装置１０１で受信し保存した情報に対して、ユーザが情報を取得するためのコードである。パスワード１６０６は、ユーザがデータ転送装置１０１に情報を一時保管する際にパスワードを付加した場合に、その付加されたパスワードを設定する。このパスワードは、ユーザがデータ転送装置１０１から情報を取得する際に利用され、パスワードが一致しなければ一時保管した情報を取得できない。発行日時１６０７は、データ転送装置１０１が、コード１６０５を発行した日時である。停止予定日時１６０８は、コード１６０５を発行した日時から、そのコード１６０５が有効な期間を付加した日時である。例えば、２０１０年１月１日０時０分０秒に発行して、コードの有効期間が２４時間の場合には、２０１０年１月２日０時０分０秒が停止予定日時として設定される。尚、発行日時１６０７を持っているので、停止日時に代えて有効期間を持っていてもよい。

上限アクセス数１６０９は、データ転送装置１０１がコードを発行してから情報を取得を要求できる上限の回数を設定している。例えば、１回限りの利用を目的としたコードでは「１」が設定される。アクセス数１６１０は、データ転送装置１０１がコードを発行してから、情報取得を要求された回数を計数している。ここでは有効／無効、期限、上限アクセスに拘わらず情報取得を要求されると、その回数がカウントアップされて設定される。最終アクセス日１６１１は、情報取得を要求されたときの最終日時であり、有効／無効、期限、上限アクセスに拘わらず、情報取得を要求されるとその日時が設定される。発行ＭＡＣアドレス１６１２は、データ転送装置１０１で受信し保存したコードを発行した情報処理装置のＭＡＣアドレスが設定される。

このようなデータを持つことで、データ転送装置１０１で受信したコードと、一時保存しているコードとが同じであること。及び、データ転送装置１０１に、そのコードを送出した情報処理装置と、一時保存している情報を送出した情報処理装置が同じでことを確認すると、同じコードを返すことができる。尚、このとき上限アクセス数３０９をインクリメントして取得回数を調整してもよいことは言うまでもない。

コード１６１３は、コード１６０５と関連付けるコードである。また取得要求ＭＡＣアドレス１６１４には、情報の取得要求を行った情報処理装置ごとのＭＡＣアドレスが設定される。最終アクセス日１６１５は、情報の取得要求を行った報処理装置ごとに有効／無効、期限、上限アクセスに拘わらず情報取得が要求された最終日時が設定される。このように１６１３から１６１５に示すようなデータを持つことで、コード毎に情報の取得を行った報処理装置と最終アクセス日が特定できる。例えば、あるコードを利用して情報の取得を行った情報処理装置（ＰＣ）から、再度同じコードで情報取得がされても、一定期間は情報の取得を制限するなどの制御を行うことができる。

このようにすることで、データ転送装置１０１が再利用したコードに対して、ユーザが過去に利用したコードを保持していて、それを基に情報を取得した場合等の制限ができる。

次に図１６（Ｂ）の分１６１６は、データ転送装置１０１に対して行われた、分単位でのコードの発行要求回数と取得要求回数を管理する分の値を示している。発行カウンタ１６１７は、データ転送装置１０１に対して行われた、分単位でのコードの発行要求回数を示す。取得カウンタ１６１８は、データ転送装置１０１に対して行われた、分単位での取得要求回数を示す。年月日時１６１９は、データ転送装置１０１に対して行われた、年月日での時単位での、コードの発行要求回数と取得要求回数を管理する年月日での時単位の値を示している。発行カウンタ１６２０は、データ転送装置１０１に対して行われた、年月日での時単位でのコードの発行要求回数を示す。取得カウンタ１６２１は、データ転送装置１０１に対して行われた、年月日での時単位での取得要求回数を示す。例えば、分単位でのコードの発行要求回数と取得要求回数を毎時集計して、年月日での時単位での発行要求回数と取得要求回数にすることで、データが形成される。

年月日１６２２は、データ転送装置１０１を利用する情報処理装置の発売日など関連するイベントの年月日が設定される。イベント番号１６２３は、データ転送装置１０１を利用する情報処理装置の発売日などに関連するイベントを示すイベント番号が設定される。尚、不図示であるが、このイベント番号はイベントの詳細と関連付けられている。ＭＡＣアドレス１６２４は、データ転送装置１０１に対してコードの発行要求、又は取得要求を行った情報処理装置（ＰＣ）のＭＡＣアドレスが設定される。記録開始日時、再開日時１６２５は、ＭＡＣアドレスごとに記録を開始、或いは正常に処理の受付を再開した日時が設定される。停止開始日時１６２６は、ＭＡＣアドレスごとに、そのＭＡＣアドレスからの発行要求と取得要求処理を処理しないようにした日時が設定される。発行カウンタ１６２７は、ＭＡＣアドレスごとに正常に処理したかどうかの有無に関係なく、記録を開始、或いは正常に処理の受付を再開した日時、或いは発行と取得の要求を処理しないようにした日時のいずれかからの発行要求回数が設定される。取得カウンタ１６２８は、ＭＡＣアドレスごとに正常に処理したかどうかの有無に関係なく、記録を開始、或いは正常に処理の受付を再開した日時、或いは発行と取得の要求を処理しないようにした日時のいずれかからの取得要求回数が設定される。

これら１６２４から１６２８に示すようなデータを持つことで、各ＰＣの発行リクエストと取得リクエストに対する制御を行うことができる。例えば、あるＰＣからの発行リクエストが、単位時間当たりのリクエスト数の閾値を超えた場合に、その発行リクエストを受け付けても、情報の一時保存とコードの発行を一定期間停止させるようなことができる。同様に、あるＰＣからの取得リクエストが、単位時間当たりのリクエスト数の閾値を超えた場合に、その取得リクエストを受けても一定期間情報を返さないようにすることができる。このようにすることで、不正アクセスに対応することができる。

図１７Ａ，１７Ｂは、本実施形態４のデータ転送装置１０１において、コードを発行するためのコードの文字数を求める処理を説明するフローチャートである。尚、この処理を実行するプログラムは、実行時にＲＡＭ２０８にロードされており、ＣＰＵ２０６の制御の下に実行される。

まずＳ１７０１で、ＣＰＵ２０６は文字数として変数digit（ＲＡＭ２０８にある）に「３」を初期設定する。尚、説明の便宜上、初期値を「３」としたが自然数であれば何でもよい。次にＳ１７０２で、ＣＰＵ２０６は、パスワードが付与されているか否かを判断し、パスワードが付与されている場合はＳ１７４４（図１７Ｂ）へ処理を進め、パスワードがない場合はＳ１７０３へ処理を進める。このようにすることで、パスワードが付与されていて、パスワードで保護できる場合には、文字数の調整を行わないようにできる。尚、不図示であるが、パスワードがある場合には、未発行のコードがあり既定の任意の文字数以上となる文字数を取得するようにしてもよい。パスワードがない場合はＳ１７０３で、ＣＰＵ２０６は、一時保存した情報の取得可能回数を判断し、情報の取得回数が１回限りの場合はＳ１７０５へ処理を進め、情報の取得回数が複数回の場合はＳ１７０４へ処理を進める。Ｓ１７０４では、ＣＰＵ２０６は、一時保存した情報の取得可能回数を変数digitに加算する。このようにすることで、一時保存した情報の取得を複数回行うことができる場合の文字数の調整が可能となる。尚、説明の便宜上、一時保存した情報の取得可能回数をそのまま加算したが、関数化するなどして他の方法で加算する値を取得可能回数から算出するようにしてもよい。また、不図示であるが、取得可能回数が無期限の場合は最大の文字数に設定することは言うまでもない。

Ｓ１７０５では、ＣＰＵ２０６は、一時保存した情報の取得可能時間を判断し、その情報の取得可能時間が８時間未満の場合はＳ１７０７へ処理を進め、情報の取得可能時間が８時間以上の場合はＳ１７０６へ処理を進める。Ｓ１７０６では、ＣＰＵ２０６は一時保存した情報の取得可能時間を８で割った商を変数digitに加算する。このようにすることで、一時保存した情報の取得可能時間が長い場合の文字数調整が可能となる。尚、ここでは、一時保存した情報の取得可能時間を定数で割った商を加算したが、例えば関数化するなどして他の方法で加算する値を取得可能時間から算出するようにしてもよい。また、８時間を判断基準としたが任意の定数であってもよいことは言うまでもない。更に、不図示であるが、取得可能時間が無期限の場合は最大の文字数に設定することは言うまでもない。

Ｓ１７０７では、ＣＰＵ２０６は、変数digitの文字数未満の文字数の発行コード数を取得する。この発行コード数は、図１６（Ａ）に示す管理データを使って説明する。コード１６０５の文字数が変数digitより小さく、かつ、停止予定日時１６０８が現在の日時より未来であり、かつ、アクセス数１６１０が上限アクセス数１６０９より小さい場合のデータ数となる。次にＳ１７０８に進み、ＣＰＵ２０６は、Ｓ１７０７で取得した、所定の文字数（桁数）の発行コード数と未発行のコード数とを比較し、発行コード数が未発行のコード数に対して１／５以上であればＳ１７０９へ処理を進める。一方、発行コード数が未発行のコード数に対して１／５未満であればＳ１７１０へ処理を進める。ここで、未発行のコード数は、例えば変数digitが「３」とすると、３桁で発行できる数字だけで構成されるコード総数は１０００個となるので容易に算出することができる。Ｓ１７０９では、ＣＰＵ２０６は変数digitを＋１してＳ１７０７に処理を戻す。このようにすることで、発行コード数と未発行コード数の割合に応じて文字数の調整が可能となる。尚、説明の便宜上、発行コード数と未発行コード数の割合を１／５としたが、関数化するなどして文字数に応じて例えば文字数が小さいときは未発行コード数に対する発行コード数の割合が小さくなるようにするなど他の方法を行ってもよい。

Ｓ１７１０では、ＣＰＵ２０６は発行コードの分布確認を行い、規定値以上の分布の偏りがあればＳ１７１１に処理を進め、規定値未満の分布の偏りであればＳ１７１２に処理を進める。発行コードの分布確認は、例えば、変数digitが「５」とすると、２文字、３文字、４文字、５文字となる。図１６（Ａ）に示す管理データを使って示すと、コード１６０５からそれぞれの文字数における度数分布を求め、それぞれの文字数に応じた規定値を超えているかどうかを判断することで行うことができる。尚、分布確認として度数分布とそれぞれの文字数に応じた規定値での判断を例にあげたが他の分布確認の方法であってもよい。Ｓ１７１１では、ＣＰＵ２０６は、変数digitを＋１してＳ１７１２に処理を進める。このようにすることで、発行コードの分布に偏りがあった場合の文字数の調整が可能となる。

Ｓ１７１２では、ＣＰＵ２０６は、直近の発行リクエスト数の確認を行い、発行リクエストの数が規定値以上であればＳ１７１３に処理を進め、規定値未満であればＳ１７１４に処理を進める。この直近の発行リクエスト数は、図１６（Ｂ）に示す管理データを使って示すと、現在の時間から直近の分を求め、分１６１６から発行カウンタ１６１７を取得することで得ることができる。例えば、分１６１６が毎日０時から１分毎に生成されていると、現在時間が１時１分の場合には、直近の１時から１時１分の発行リクエストのカウントつまり、分１６１６が「６０」となっているレコードから発行カウンタ１６１７を取得すればよい。Ｓ１７１３では、ＣＰＵ２０６は、直近の発行リクエストのカウント数の１／１０を変数digitに加算してＳ１７１４に処理を進める。尚、説明の便宜上、直近の発行リクエストのカウントの１／１０を加算したが、関数化するなどして他の方法で加算する値を直近の発行リクエストのカウントから算出するようにしてもよい。このようにすることで、直近のコードの発行数から文字数調整が可能となる。

Ｓ１７１４では、ＣＰＵ２０６は発行リクエスト数の傾向の確認を行い、発行リクエストの数が増加傾向であればＳ１７１５に処理を進め、増加傾向でなければＳ１７１６に処理を進める。この発行リクエストは、図１６（Ｂ）に示す管理データを使って示すと、現在の時間から数時間の過去の傾向を分１６１６と発行カウンタ１６１７を利用して線形近似や近似曲線などを利用して求めることができる。例えば、線形近似を用いて過去１時間分の傾向を算出し、その傾きが増加であるかそうでないかを判断する。そしてＳ１７１５で、ＣＰＵ２０６は線形近似を用いて算出した傾きを、そのまま変数digitに加算してＳ１７１６に処理を進める。尚、過去１時間分の線形近似を用いて傾きを算出し、算出した傾きを加算したが、他に、近似曲線を用いて次のリクエスト数を予想して、予想に基づき変数digitに加算するなどしてもよい。このようにすることで、コードの発行傾向から文字数の調整が可能となる。

Ｓ１７１６では、ＣＰＵ２０６は、直近の取得リクエスト数の確認を行い、取得リクエストが規定値以上であればＳ１７１７に処理を進め、規定値未満であればＳ１７１８に処理を進める。直近の取得リクエスト数は、図１６（Ｂ）に示す管理データを使って示すと、現在の時間から直近の分を求め、分１６１６から取得カウンタ１６１８を取得することで得ることができる。例えば、分１６１６が毎日０時から１分毎に生成されているとすると、現在時間が１時１分の場合には、直近の１時から１時１分の取得リクエストのカウントつまり、分１６１６の値が「６０」となっているレコードから取得カウンタ１６１８を取得すればよい。そしてＳ１７１７で、ＣＰＵ２０６は直近の取得リクエストのカウントの１／１０を変数digitに加算してＳ１７１８に処理を進める。尚、直近の取得リクエストのカウントの１／１０を加算したが、関数化するなどして他の方法で加算する値を直近の取得リクエストのカウントから算出するようにしてもよい。このようにすることで、直近の取得リクエスト数から文字数の調整が可能となる。

Ｓ１７１８では、ＣＰＵ２０６は、取得リクエスト数の傾向の確認を行い、取得リクエストが増加傾向であればＳ１７１９に処理を進め、増加傾向でなければＳ１７２０に処理を進める。この取得リクエストは、図１６（Ｂ）に示す管理データを使って示すと、現在の時間から数時間の過去の傾向を分１６１６と取得カウンタ１６１８を利用して線形近似や近似曲線などを利用して求めることができる。例えば、線形近似を用いて過去１時間分の傾向を算出し、その傾きが増加であるかそうでないかを判断する。そしてＳ１７１９で、ＣＰＵ２０６は線形近似を用いて算出した傾きを、そのまま変数digitに加算してＳ１７２０に処理を進める。尚、過去１時間分の線形近似を用いて傾きを算出し、算出した傾きを加算したが、他に、近似曲線を用いて次のリクエスト数を予想して、予想に基づき変数digitに加算するなどしてもよい。このようにすることで、取得リクエストの傾向から文字数調整が可能となる。

Ｓ１７２０では、ＣＰＵ２０６は、現在の時間帯の発行リクエスト数を予想し、その発行リクエスト数の予想から文字数を算出してＳ１７２１に処理を進める。この発行リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から１日の時間帯での過去の傾向を発行カウンタ１６２０を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前時間帯での予想と前時間帯での実測値から過去の傾向を実測に合わせた補正を行ってもよい。

Ｓ１７２１では、ＣＰＵ２０６はＳ１７２０で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７２２に処理を進め、足りていればＳ１７２３に処理を進める。Ｓ１７２２では、ＣＰＵ２０６はＳ１７２０で算出した文字数を変数digitに設定し、Ｓ１７２３に処理を進める。このようにすることで、時間帯の発行リクエスト数の傾向から文字数の調整が可能となる。

Ｓ１７２３では、ＣＰＵ２０６は、現在の月日の発行リクエスト数を予想し、発行リクエスト数の予想から文字数を算出してＳ１７２４に処理を進める。この発行リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から１日単位での過去の傾向を発行カウンタ１６２０を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前日での予想と前日での実測値から過去の傾向を実測に合わせた補正を行ってもよい。そしてＳ１７２４で、ＣＰＵ２０６は、Ｓ１７２３で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７２５に処理を進め、足りていればＳ１７２６に処理を進める。Ｓ１７２５では、ＣＰＵ２０６は、Ｓ１７２３で算出した文字数を変数digitに設定し、Ｓ１７２６に処理を進める。このようにすることで、月毎の日単位での発行リクエスト数の傾向から文字数の調整が可能となる。

図１７ＢのＳ１７２６では、ＣＰＵ２０６は、現在の曜日の発行リクエスト数を予想し、この発行リクエスト数の予想から文字数を算出しＳ１７２７に処理を進める。発行リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から曜日単位での過去の傾向を発行カウンタ１６２０を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前週の同一曜日での予想と前週の同一曜日での実測値から過去の傾向を実測に合わせた補正を行ってもよい。

Ｓ１７２７では、ＣＰＵ２０６は、Ｓ１７２６で算出した文字数と変数digitを比較して、文字数が足りない場合はＳ１７２８に処理を進め、足りていればＳ１７２９に処理を進める。Ｓ１７２８では、ＣＰＵ２０６はＳ１７２６で算出した文字数を変数digitに設定し、Ｓ１７２９に処理を進める。このようにすることで、曜日単位での発行リクエスト数の傾向から文字数調整が可能となる。

Ｓ１７２９では、ＣＰＵ２０６は、現在の月日から前後３０日の登録されたイベントを求め、過去の同一イベントにおける発行リクエスト数を予想し、この発行リクエスト数の予想から文字数を算出してＳ１７３０に処理を進める。登録されたイベントは、図１６（Ｂ）に示す管理データを使って示すと、年月日１６２２から現在の月日と関係あるイベント番号１６２３で求めることができる。過去の同一イベントは、図１６（Ｂ）に示す管理データを使って示すと、先に求めたイベント番号１６２３と同じイベント番号を持つ年月日１６２２を求めることで、過去の同一イベントの年月日のリストを取得することができる。また発行リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、先に求めた過去の同一イベントの年月日のリストと発行カウンタ１６２０から、イベントの前後３０日の近似曲線等を利用して求めることができる。尚、ここではイベントの前後３０日としたが、イベントによって日数を変えたりしてもよい。また、近似曲線で管理データから直接予測を行ったが、イベントがなかった場合の予測を行い、実測値との差分をイベントによる増減分と判断する。そして現在のイベントがない場合の予測に対して、先に求めたイベントによる増減分を加味させて調整してもよい。

Ｓ１７３０では、ＣＰＵ２０６は、Ｓ１７２９で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７３１に処理を進め、足りていればＳ１７３２に処理を進める。Ｓ１７３１では、ＣＰＵ２０６は、Ｓ１７２９で算出した文字数を変数digitに設定してＳ１７３２に処理を進める。このようにすることで、イベントでの発行リクエスト数の傾向から文字数の調整が可能となる。

Ｓ１７３２では、ＣＰＵ２０６は、現在の時間帯の取得リクエスト数を予想し、この取得リクエスト数の予想から文字数を算出してＳ１７３３に処理を進める。この取得リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から１日の時間帯での過去の傾向を取得カウンタ１６２１を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前時間帯での予想と前時間帯での実測値から過去の傾向を実測に合わせた補正を行ってもよい。

Ｓ１７３３では、ＣＰＵ２０６は、Ｓ１７３２で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７３４に処理を進め、足りていればＳ１７３５に処理を進める。Ｓ１７３４では、ＣＰＵ２０６は、Ｓ１７３２で算出した文字数を変数digitに設定し、Ｓ１７３５に処理を進める。このようにすることで、時間帯の取得リクエスト数の傾向から文字数の調整が可能となる。

Ｓ１７３５では、ＣＰＵ２０６は、現在の月日の取得リクエスト数を予想し、取得リクエスト数の予想から文字数を算出しＳ１７３６に処理を進める。この取得リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から１日単位での過去の傾向を取得カウンタ１６２１を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前日での予想と前日での実測値から過去の傾向を実測に合わせた補正を行ってもよい。

Ｓ１７３６では、ＣＰＵ２０６は、Ｓ１７３５で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７３７に処理を進め、足りていればＳ１７３８に処理を進める。Ｓ１７３７では、ＣＰＵ２０６は、Ｓ１７３５で算出した文字数を変数digitに設定してＳ１７３８に処理を進める。このようにすることで、月毎の日単位での取得リクエスト数の傾向から文字数の調整が可能となる。

Ｓ１７３８では、ＣＰＵ２０６は、現在の曜日の取得リクエスト数を予想し、取得リクエスト数の予想から文字数を算出してＳ１７３９に処理を進める。この取得リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、年月日時１６１９から曜日単位での過去の傾向を取得カウンタ１６２１を利用して線形近似や近似曲線などを利用して求めることができる。このとき、例えば、前週の同一曜日での予想と前週の同一曜日での実測値から過去の傾向を実測に合わせた補正を行ってもよい。

Ｓ１７３９では、ＣＰＵ２０６は、Ｓ１７３８で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７４０に処理を進め、足りていればＳ１７４１に処理を進める。Ｓ１７４０では、ＣＰＵ２０６は、Ｓ１７３８で算出した文字数を変数digitに設定し、Ｓ１７４１に処理を進める。このようにすることで、曜日単位での取得リクエスト数の傾向から文字数の調整が可能となる。

Ｓ１７４１では、ＣＰＵ２０６は、現在の月日から前後３０日の登録されたイベントを求め、過去の同一イベントにおける取得リクエスト数を予想し、この取得リクエスト数の予想から文字数を算出しＳ１７４２に処理を進める。登録されたイベントは、図１６（Ｂ）に示す管理データを使って示すと、年月日１６２２から現在の月日と関係あるイベント番号１６２３を求めることができる。過去の同一イベントは、図１６（Ｂ）に示す管理データを使って示すと、先に求めたイベント番号１６２３と同じイベント番号を持つ年月日１６２２を求めることで過去の同一イベントの年月日のリストを取得することができる。取得リクエスト数の予想は、図１６（Ｂ）に示す管理データを使って示すと、先に求めた過去の同一イベントの年月日のリストと取得カウンタ１６２１とからイベントの前後３０日の近似曲線などを利用して求めることができる。尚、説明の便宜上、イベントの前後３０日としたがイベントによって日数を変えたりしてもよい。また、説明の便宜上、近似曲線で管理データから直接予測を行った。しかしイベントがなかった場合の予測を行い、実測値との差分をイベントによる増減分と判断し、現在のイベントがない場合の予測に対して、先に求めたイベントによる増減分を加味させて調整してもよい。

Ｓ１７４２では、ＣＰＵ２０６は、Ｓ１７４１で算出した文字数と変数digitとを比較して、文字数が足りない場合はＳ１７４３に処理を進め、足りていればＳ１７４４に処理を進める。Ｓ１７４３では、ＣＰＵ２０６は、Ｓ１７４１で算出した文字数を変数digitに設定し、Ｓ１７４４に処理を進める。このようにすることで、イベントでの取得リクエスト数の傾向から文字数調整が可能となる。

Ｓ１７４４では、ＣＰＵ２０６は、区切り文字数で割りきれるかどうかを確認し、割り切れない場合はＳ１７４５に処理を進め、割り切れる場合は処理を終了する。Ｓ１７４５では、ＣＰＵ２０６は、区切り文字数で割りきれるように変数digitに文字数を加算して処理を終了する。このようにすることで、例えば、区切り文字数を「４」とすると、「４」の倍数に文字数をすることができ、ユーザに対してコードを表示する際に４文字区切りで表示が行えるのでユーザが扱いやすくすることができる。尚、区切り文字数は任意の定数でよいことは言うまでもない。このようにして生成した文字数を基に、本実施形態４に係るデータ転送装置１０１はコードを生成する。

図１８は、本実施形態４に係るデータ転送装置において、図１７Ａ，図１７Ｂのフローチャートに従って決定したコードの文字数に基づいて、コードを求める処理を説明するフローチャートである。尚、この処理を実行するプログラムは、実行時にＲＡＭ２０８にロードされており、ＣＰＵ２０６の制御の下に実行される。

まずＳ１８０１で、ＣＰＵ２０６は、コードの発行が要求されているかどうかを判定し、要求されていればＳ１８０２に処理を進め、要求されていなければＳ１８０４に処理を進める。Ｓ１８０２では、ＣＰＵ２０６は、要求されているコードの文字数と、図１７Ａ，１７Ｂで生成したコードの文字数とを比較する。そして、要求されているコードの文字数が、生成したコードの文字数と等しいか、それよりも長ければＳ１８０６に処理を進める。一方、要求されているコードの文字数の方が、生成したコードの文字数よりも短ければＳ１８０３に処理を進め、ＣＰＵ２０６は要求されているコード文字数に足りない分の文字を発生して、要求されている文字数の文字列を生成する。そして、その生成した文字列のコードを生成してＳ１８０６に処理を進める。

一方、Ｓ１８０４では、ＣＰＵ２０６は、図１７Ａ，１７Ｂのフローチャートに従って生成した文字数分の文字列（コード）を生成してＳ１８０５に処理を進める。尚、文字列の生成は、必要な文字数で文字列が生成できればよく、文字の生成の方法に依存しない。尚、文字列の生成の一例を挙げると、乱数を利用して文字列を生成してもよいし、一時保存する情報からハッシュデータを取得して文字列を生成しても良い。また或いは図１６の管理データを順次参照して、空きコードを探すなどしてもよい。

次にＳ１８０５に進み、ＣＰＵ２０６は、Ｓ１８０４で生成した文字列（コード）に、同一文字の連続や、数字の連番、文字がアルファベット順で配置されているといった、推測され易い文字列などが含まれているかどうか判断する。そして、このような文字列があると判断されるとＳ１８０４に処理を戻して、再度、コード（文字列）を生成する。一方、そうでないときはＳ１８０６に処理を進め、ＣＰＵ２０６は、そのコードが発行済みでないかどうかを判断する。ここで、同じコードを発行済みであると判定した場合はＳ１８０４に処理を戻して、再び、コード（文字列）を生成する。一方、Ｓ１８０６で、未発行であると判定した場合はＳ１８０７に処理を進める。

尚、発行済みかどうかの判断は、図１６（Ａ）に示す管理データを使って説明すると、コード１６０５に同一コードがあるかどうかにより確認できる。また、不図示であるが、このとき発行済みだけでなく、生成したコードの一定の範囲内（コードが数字の場合には、一定の差分内）の発行済みコードがあるかどうかにより確認できる。そして、一定の範囲内の発行済みのコードがあれば、同一コードがある場合と同様にの処理を実行するようにしても良い。例えば、生成したコードが「３７５８」である場合に、「３７５９」や「３７５６」等が発行済みであればＳ１８０４に処理を戻して、別のコードを再発行する用にしても良い。

そしてＳ１８０７では、ＣＰＵ２０６は、生成したコードを管理データとして登録して処理を終了する。図１６（Ａ）に示す管理データを使って示すと、コード１６０５に生成したコードを設定したデータの登録を行うこととなる。このようにすることで、生成したコードの文字数に基づいて、ユーザにより要求されたコードを求めることができる。

図１９は、本実施形態４に係るデータ転送装置において生成したコードの管理データからデータを削除する処理を説明するフローチャートである。尚、この処理を実行するプログラムは、実行時にＲＡＭ２０８にロードされており、ＣＰＵ２０６の制御の下に実行される。

まずＳ１９０１で、ＣＰＵ２０６は、再利用が可能なコードのリストを取得してＳ１９０２へ処理を進める。この再利用が可能なコードのリストは、図１６（Ａ）に示す管理データを使って示すと、停止予定日時１６０８が現在の日時より過去、或いは、アクセス数１６１０が上限アクセス数１６０９に等しいか、大きい状態のデータである。即ち、Ｓ１９０１の処理は、既に有効でなくなっていて、既存のコードから削除すべきコードのリストを取得する処理である。このとき、発行日時１６０７から一定期間が経過しているという検索条件を追加することで、発行日時が最近のコードの再利用を抑えることができる。また最終アクセス日１６１１から一定期間が経過しているという検索条件を追加することで、そのコードが取得できなくなっているにも拘わらず、依然としてそのコードへのアクセスが発生している場合に、そのコードの再利用を抑えることができる。

次にＳ１９０２に進み、ＣＰＵ２０６は、変数ｃｏｕｎｔ（ＲＡＭ２０８にある）に、Ｓ１９０１で取得したリストの総数を設定し、変数ｉ（ＲＡＭ２０８にある）に「０」を設定してＳ１９０３へ処理を進める。次にＳ１９０３に進み、ＣＰＵ２０６は、変数ｉと変数ｃｏｕｎｔとを比較し、変数ｉが変数ｃｏｕｎｔより小さい場合はＳ１９０４に処理を進め、変数ｉが変数ｃｏｕｎｔより大きいか等しい場合は処理を終了する。Ｓ１９０４では、ＣＰＵ２０６は、変数ｉの示すコードの一定の範囲内に再利用が可能なコードがないかどうかを判断する。ここで再利用が可能なコードが一定の範囲内にあればＳ１９０６に処理を進め、再利用が可能なコードが一定の範囲内になければＳ１９０５に処理を進める。例えば、変数ｉの示すデータのコードが「３７５８」であった場合、「３７５９」や「３７５６」等が再利用が可能なコードになっていればＳ１９０６に処理を進める。このようにすることで、一定の範囲内にあるコードがあれば、そのコードを削除して再利用可能にしないようにできる。これにより、一定の範囲内にあるコードが同時に削除されて再利用される度合い抑制することができる。

Ｓ１９０５では、ＣＰＵ２０６は、変数ｉの示すコードと、そのコードに関連するデータを管理データから削除してＳ１９０６に処理を進める。Ｓ１９０６では、ＣＰＵ２０６は、変数ｉをインクリメントしてＳ１９０３に処理を戻す。このようにすることで、発行済みで、有効でなくなったコードを再利用することができる。

尚、Ｓ１９０５で、管理データから、コードとその関連するデータを削除することにより、そのコードが生成したことのないデータと同列になりコードの再利用が可能となるようにした。しかし削除せずに、再利用が可能なコードを返すようにしてもよい。この場合は、図１８のＳ１８０４のコード生成処理において、通知された再利用が可能なコードを、生成したコードとして利用することで再利用することができる。

尚、本実施形態４では、文字数で説明したが、例えば、コードで利用する文字種の数であっても同様に行える。また、文字数と文字種の数の両方同時に制御してもよい。

以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。上述の実施形態の一部を適宜組み合わせてもよい。

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

Claims (11)

1. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムであって、
   前記第１通信装置は、
   データの通信において前記第１通信装置を特定する識別子である受信ＩＤを前記第２通信装置に通知する通知手段と、
   前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求手段と、
   前記要求手段の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求手段とを有し、
   前記第２通信装置は、
   前記受信ＩＤを従って、送信対象のデータを前記サーバに登録する登録手段を有し、
   前記サーバは、
   前記要求手段からの要求に応じて前記データの一覧を前記第１通信装置に送信し、前記データ要求手段の要求に応答して、前記登録手段により登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とするデータ通信システム。
2. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムであって、
   前記第１通信装置は、
   前記サーバに要求して、送信対象のデータを保持する受信フォルダの名称を取得する取得手段と、
   データの通信において前記第１通信装置を特定する識別子である受信ＩＤに関連付けて前記取得手段で取得した前記受信フォルダの名称を前記第２通信装置に通知する通知手段と、
   前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求手段と、
   前記要求手段の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求手段とを有し、
   前記第２通信装置は、
   前記受信ＩＤに従って、前記受信フォルダに関連付けて受信先の名称を保存する保存手段と、
   送信対象のデータを前記受信フォルダに登録するように前記サーバに要求して登録する登録手段を有し、
   前記サーバは、
   前記要求手段からの要求に応じて、前記受信ＩＤに関連付けられた前記受信フォルダのデータの一覧を前記第１通信装置に送信し、前記データ要求手段の要求に応答して、前記受信フォルダに登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とするデータ通信システム。
3. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムであって、
   前記第１通信装置は、
   データの通信において前記第１通信装置を特定する識別子である受信ＩＤを前記第２通信装置に通知する通知手段と、
   前記第２通信装置から前記第２通信装置を特定する識別子である送信ＩＤを受信する受信手段と、
   前記受信ＩＤと前記送信ＩＤとに関連付けて、送信対象のデータを保持する受信フォルダの名称を取得する通知手段と、
   前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求手段と、
   前記要求手段の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求手段とを有し、
   前記第２通信装置は、
   前記受信ＩＤと前記送信ＩＤとに関連付けられた前記受信フォルダに関連付けて受信先の名称を保存する保存手段と、
   送信対象のデータを前記受信フォルダに登録するように前記サーバに要求して登録する登録手段を有し、
   前記サーバは、
   前記要求手段からの要求に応じて、前記受信ＩＤに関連付けられた前記受信フォルダのデータの一覧を前記第１通信装置に送信し、前記データ要求手段の要求に応答して、前記受信フォルダに登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とするデータ通信システム。
4. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムであって、
   前記第１通信装置は、
   データの通信において前記第１通信装置を特定する識別子である受信ＩＤを含む受信側の仮の識別子を前記第２通信装置に通知する通知手段と、
   前記受信ＩＤと前記受信側の仮の識別子とに基づいて、前記第２通信装置を特定する送信ＩＤを前記サーバから受信する受信手段と、
   前記第２通信装置から送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求手段と、
   前記要求手段の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求手段とを有し、
   前記第２通信装置は、
   前記受信ＩＤと前記受信側の仮の識別子とを関連付けて前記送信ＩＤを前記サーバに登録する登録手段を有し、
   前記サーバは、
   前記受信ＩＤと前記受信側の仮の識別子とに対応する前記第２通信装置の送信ＩＤを前記第１通信装置に通知する通知手段を有し、
   前記要求手段からの要求に応じて前記データの一覧を前記第１通信装置に送信し、前記データ要求手段の要求に応答して、前記登録手段により登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とするデータ通信システム。
5. 前記第１通信装置は、前記サーバから前記受信ＩＤを取得することを特徴とする請求項１乃至４のいずれか１項に記載のデータ通信システム。
6. 前記第２通信装置は、前記サーバから前記送信ＩＤを取得することを特徴とする請求項３又は４に記載のデータ通信システム。
7. 前記受信フォルダは、受信の可否を示す情報を含むことを特徴とする請求項２又は３に記載のデータ通信システム。
8. 前記サーバは、所定の桁数の受信ＩＤや送信ＩＤを示すコードの発行済みのコード数と、当該所定の桁数のコードのうちの未発行のコード数とに基づいて、前記コードの桁数を決定する決定手段を更に有することを特徴とする請求項５に記載のデータ通信システム。
9. 前記決定手段は、前記第２通信装置の前記登録手段により登録される前記データの取得可能回数に応じて、前記コードの桁数を決定することを特徴とする、請求項１乃至３のいずれか１項に従属する請求項５に記載のデータ通信システム。
10. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムを制御する制御方法であって、
    前記第１通信装置から、データの通信において前記第１通信装置を特定する識別子である受信ＩＤを前記第２通信装置に通知する通知工程と、
    前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、前記第１通信装置から当該送信通知に対応するデータの一覧を前記サーバに要求する要求工程と、
    前記要求工程の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを、前記第１通信装置から前記サーバに要求するデータ要求工程と、
    前記第２通信装置から、前記受信ＩＤを従って、送信対象のデータを前記サーバに登録する登録工程と、
    前記要求工程の要求に応じて前記データの一覧を前記サーバから前記第１通信装置に送信し、前記データ要求工程の要求に応答して、前記登録工程により登録されている前記取得対象のデータを前記第１通信装置に送信することを特徴とするデータ通信システムの制御方法。
11. データを受信する受信側である第１通信装置と、データを送信する送信元である第２通信装置及びサーバとを有するデータ通信システムを制御する制御方法であって、
    前記第１通信装置から、前記サーバに要求して、送信対象のデータを保持する受信フォルダの名称を取得する取得工程と、
    データの通信において前記第１通信装置を特定する識別子である受信ＩＤに関連付けて前記取得工程で取得した前記受信フォルダの名称を、前記第１通信装置から前記第２通信装置に通知する通知工程と、
    前記第２通信装置から前記受信ＩＤを含む送信通知を受信すると、当該送信通知に対応するデータの一覧を前記サーバに要求する要求工程と、
    前記要求工程の要求に応じて前記サーバから送信される前記データの一覧から取得対象のデータを前記サーバに要求するデータ要求工程と、
    前記受信ＩＤに従って、前記第２通信装置において、前記受信フォルダに関連付けて受信先の名称を保存する保存工程と、
    送信対象のデータを、前記第２通信装置から前記受信フォルダに登録するように前記サーバに要求して登録する登録工程とし、
    前記要求工程の要求に応じて、前記受信ＩＤに関連付けられた前記受信フォルダのデータの一覧を前記サーバから前記第１通信装置に送信し、前記データ要求工程の要求に応答して、前記受信フォルダに登録されている前記取得対象のデータを前記サーバから前記第１通信装置に送信することを特徴とするデータ通信システムの制御方法。

Images