JP2004112598A - データ生成システム及びデータ生成方法 - Google Patents

Abstract

【課題】セキュリティ性を高める。
【解決手段】性質の異なる複数の要素データから構成される単位データを、各要素データを合成することによって生成するデータ生成システムにおいて、前記複数の要素データのうち、ユーザが秘匿性が高いと認める要素データである高秘匿性要素データを保存するため、ユーザ自身が携帯する携帯通信端末と、前記複数の要素データのうち当該高秘匿性要素データ以外の要素データである低秘匿性要素データを少なくとも一時的に保存するための保存サーバと、前記携帯通信端末および保存サーバと通信するためのインタフェースを持ち、前記携帯通信端末から供給された高秘匿性要素データと保存サーバから供給された低秘匿性要素データを合成した上で、前記単位データを構成し、所定の出力形態で出力する合成出力端末とを備える。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明はデータ生成システムおよびデータ生成方法に関し、例えば、インターネットなどを経由して、広域に分散配置されたＭＭＫ（マルチメディアキオスク）端末等で、個人情報（プロファイル）などを含んだ秘匿性のあるデータを印刷出力する場合などに適用して好適なものである。
【０００２】
【従来の技術】
従来、個人情報を含んだドキュメントが欲しい場合、ドキュメント制作会社へ当該ドキュメントの制作を依頼する方法と、ユーザが自身で当該ドキュメントを制作する方法があった。
【０００３】
ドキュメントの例としては、例えば、年賀状や宅配便の送り状などがあり、年賀状などの場合には差出人の住所、氏名や、宛先の住所、氏名などが前記個人情報に該当する。
【０００４】
ドキュメント制作会社に当該ドキュメントの制作を依頼する場合、年賀状のデザイン（絵柄など）のドキュメント形態を具体的に指定した上で当該個人情報を提供すると、ユーザ自身がドキュメントを制作する場合に比べ、わずかな労力で、高い品質のドキュメントを手に入れることが可能である。
【０００５】
【発明が解決しようとする課題】
しかしながら、マスメディアなどで個人情報流出事件が報じられることが少なくない現状を反映して、個人情報の管理状況が必ずしも明確ではないドキュメント制作会社などへ、重要な個人情報を提供することは敬遠する傾向が高まっている。
【０００６】
これは、個人情報の提供などがネットワーク経由で行われる場合も同じである。例えば、ドキュメント制作会社などが運営するＷｅｂサイトなどを介し、インターネット経由で、前記個人情報の提供やドキュメント形態の指定を行うことができれば、ユーザの労力がさらに軽減できて便利であるが、ドキュメント制作会社側の管理の誤りでユーザの個人情報がＷｅｂサイト上で公開されてしまったり、適正な管理を行ってはいても、Ｗｅｂサイトのセキュリティホールを突いた攻撃などによって個人情報が流出する可能性も小さくない。
【０００７】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、性質の異なる複数の要素データ（一例として、個人情報）から構成される単位データ（一例として、年賀状）を、各要素データを合成することによって生成するデータ生成システムにおいて、前記複数の要素データのうち、ユーザが秘匿性が高いと認める要素データである高秘匿性要素データ（一例として、年賀状の差出人情報）を保存するため、ユーザ自身が携帯する携帯通信端末（一例として、携帯電話機）と、前記複数の要素データのうち当該高秘匿性要素データ以外の要素データである低秘匿性要素データ（一例として、年賀状の宛先情報）を少なくとも一時的に保存するための保存サーバ（一例として、仮想プリントサーバ）と、前記携帯通信端末および保存サーバと通信するためのインタフェースを持ち、前記携帯通信端末から供給された高秘匿性要素データと保存サーバから供給された低秘匿性要素データを合成した上で、前記単位データを構成し、所定の出力形態（一例として印刷出力）で出力する合成出力端末（一例としてプリンタ等の印刷機器を有したＭＭＫ端末）とを備えたことを特徴とする。
【０００８】
また、第２の発明では、性質の異なる複数の要素データから構成される単位データを、各要素データを合成することによって生成するデータ生成方法において、前記複数の要素データのうち、ユーザが秘匿性が高いと認める要素データである高秘匿性要素データを保存するための携帯通信端末をユーザ自身が携帯し、前記複数の要素データのうち当該高秘匿性要素データ以外の要素データである低秘匿性要素データは少なくとも一時的に保存サーバに保存し、合成出力端末は、前記携帯通信端末および保存サーバと通信するためのインタフェースを持ち、前記携帯通信端末から供給された高秘匿性要素データと保存サーバから供給された低秘匿性要素データを合成した上で、前記単位データを構成して、所定の出力形態で出力することを特徴とする。
【０００９】
このような構成により、高秘匿性要素データと低秘匿性要素データを、携帯通信端末と保存サーバに分散して保存することができる。
【００１０】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかるデータ生成システム及びデータ生成方法の実施形態について説明する。
【００１１】
（Ａ−１）実施形態の構成
本実施形態の通信システム１０の全体構成例を図１に示す。
【００１２】
図１において、通信システム１０は、ネットワーク１１と、携帯電話ネットワーク１２と、仮想プリントサーバ１３と、ＭＭＫ端末１４と、通信端末１５と、携帯電話機１６とを備えている。
【００１３】
このうちネットワーク１１は、ＬＡＮ（ローカルエリアネットワーク）などであってもかまわないが、ここでは、インターネットであるものとする。また、携帯電話ネットワーク１２は、携帯電話機１６を使用できるようにするため、携帯電話事業者によって運営されているネットワークである。携帯電話ネットワーク１２とインターネット１１は図示しないゲートウエイなどを介して接続されていて、携帯電話機１６からも、インターネット１１上のＷｅｂサイトを閲覧したり、インターネット１１上と電子メールのやり取りを行ったりすることが可能である。
【００１４】
通信端末１５は、例えば、パーソナルコンピュータなどの情報処理装置である。
【００１５】
当該通信端末１５も前記携帯電話機１６と同様、ユーザ（例えば、Ｕ１）によって操作されるが、携帯電話機１６のユーザインタフェースは、周知のように、携帯電話機のボディサイズが極めて小さいこと等に起因し、大量の文字の読み書きを快適に行うことができるものではないため、本実施形態では、ドキュメントの作成上、必要な大量の文字の読み書きには、通信端末１５のほうを使用する。
【００１６】
したがって当該通信端末１５は、ノートパソコンや、据え置き型のパーソナルコンピュータなど、携帯電話機に比べると、はるかに大きくて使い勝手のよい表示画面やキーボードなどを装備した情報処理装置であることを要する。
【００１７】
仮想プリントサーバ１３やＭＭＫ端末１４は、ユーザＵ１以外の多数のユーザに対しても、ユーザＵ１と同様なサービスを提供するものであるが、以下では、主として、ユーザＵ１がこれらのサービスを利用する場合を例に説明を進める。
【００１８】
前記仮想プリントサーバ１３は、ユーザＵ１が最終的にＭＭＫ端末１４から所望のドキュメントを印刷出力するために必要な各種のサービスを提供するサーバである。当該仮想プリントサーバ１３はインターネット１１上に配置されており、通信端末１５，携帯電話機１６，ＭＭＫ端末１４からアクセスを受けることができる。
【００１９】
仮想プリントサーバ１３の内部構成例を図４に示す。
【００２０】
（Ａ−１−１）仮想プリントサーバの内部構成例
図４において、当該仮想プリントサーバ１３は、通信部４０と、制御部４１と、記憶部４２とを備えている。
【００２１】
通信部４０は、アクセスしてきた通信端末１５，携帯電話機１６，およびＭＭＫ端末１４に対し、基本的にＷｅｂサーバ（あるいは、ＦＴＰサーバ）としてのインタフェースを提供するものであってよい。
【００２２】
制御部４１は、ハードウエア的には当該仮想プリントサーバ１３のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）やＤＢＭＳ（データベース管理システム）、Ｗｅｂサーバ、ＣＧＩプログラムなどの各種プログラムに相当する部分である。
【００２３】
後述するように、本実施形態では、前記通信端末１５，携帯電話機１６，ＭＭＫ端末１４と、この仮想プリントサーバ１３のあいだ等で、公開鍵系に属する暗号方式の一種を多用する。この公開鍵暗号方式は、大きな数（大きな素数ｐ、ｑの積ｎ＝ｐｑ（ｐ、ｑのそれぞれは一例として１００桁以上））の素因数分解が困難であることに、安全性の根拠を置くものである。この困難性は、当該公開鍵や秘密鍵によって暗号化されたデータに第３者がアタックした場合、例えば、最も効率的で最も計算量の少ない素因数分解アルゴリズムを、最も処理速度の速いコンピュータ上で実行したとしても、その解を得るまでに（すなわち、暗号を解読できるまでに）、現実的でないほど長い時間（一例として、数万年）を要するという程度の困難性である。数万年後に解読できたとしても、この第３者にとっても、ユーザＵ１にとってもほとんど何の意味もないため、事実上、解読不能であるといえる。
【００２４】
なお、解読とは、正規の受信者でない第３者が、素因数分解アルゴリズムなどを利用して暗号化されたデータにアタックし、平文のデータまたは平文の暗号化鍵を得ることを指し、復号化とは、正規の受信者が、復号化鍵（公開鍵または秘密鍵）を利用して暗号化されたデータを処理し平文のデータを得ることを指す。
【００２５】
前記公開鍵暗号方式の利用により、仮想プリントサーバ１３も、必要に応じて当該公開鍵暗号方式に対応した処理（暗号化や復号化）を行うことになるが、この暗号化や復号化を実行するのは、通信部３０または制御部３１である。
【００２６】
暗号化や復号化をＯＳＩ参照モデルのアプリケーション層以下のプロトコルとして実行する場合（例えば、トランスポート層で実行する場合など）は、通信部４０が、その実行主体となるが、アプリケーションとして実行する場合には、制御部４１がその実行主体となる。
【００２７】
記憶部４２はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、データベースや各種のファイルがこの部分に含まれる。
【００２８】
記憶部４２には、ユーザ管理ファイルＵＭ、宛先情報ファイルＤＮ、アプリファイル群ＡＦ１〜ＡＦＮ、個人ファイル群ＰＦ１〜ＰＦＭ、テンプレートファイル群ＴＦ１〜ＴＦＳ、ドキュメントリストファイルＬＴ１などの各ファイルが格納されている。
【００２９】
このうちユーザ管理ファイルＵＭは、仮想プリントサーバ１３に会員登録を行ったユーザを管理するためのファイルである。
【００３０】
したがって、会員として認定するために最小限度の個人情報は、このユーザ管理ファイルＵＭに登録されている。例えば、ユーザ（会員）の氏名、電子メールアドレス、ユーザＩＤ、パスワードなどの情報がこれに該当する。
【００３１】
前記ユーザＵ１も、当該仮想プリントサーバ１３が提供するサービスを利用する以上、会員登録した者であることを要するから、その個人情報は、このユーザ管理ファイルＵＭに登録されている。
【００３２】
宛先情報ファイルＤＮ１〜ＤＮＬは、前記ドキュメントの宛先情報を登録するためのファイルである。
【００３３】
会員である各ユーザ（その一人がＵ１）ごとに、異なるドキュメントの制作依頼（印刷依頼）が行われるが、そのドキュメントが宛先情報を必要とするものである場合に、当該ユーザに対応付けた形式で、当該宛先情報ファイルＤＮ１〜ＤＮＬが生成される。
【００３４】
本実施形態で、印刷依頼の対象となり得るドキュメントの例としては、例えば、年賀状、宅配便の送り状、名刺、履歴書、経歴書など、様々なものがあり得るが、このなかでは、年賀状、宅配便の送り状の場合に宛先情報と差出人情報が必要となり、名刺、履歴書、経歴書の場合には、宛先情報や差出人情報は不要である。
【００３５】
宛先情報とはドキュメントの宛先となる情報のことで、具体的には、当該年賀状や送り状などの宛先として記述される住所、氏名、電話番号などを指す。同様に、差出人情報とは、ドキュメントの差出人となる人の情報で、具体的には、当該年賀状や送り状などの差出人として記述される住所、氏名、電話番号などを指す。以下の説明では、主として、この年賀状の印刷を行う場合を想定する。
【００３６】
この宛先情報ファイルＤＮ１〜ＤＮＬは、印刷依頼にかかるドキュメントの印刷が完了したときには削除することが望ましい。一般的な情報処理装置では、削除の操作を行っても、削除の対象となったデータが記憶されていた領域を論理的に有効なデータが存在しない領域として扱うだけで、物理的にデータは記憶されたままであることが多いが、そのような状態の場合、特殊なツールを使うことによって当該データが読み出され再利用される可能性も残るため、本実施形態における削除は、当該データを物理的に消去または上書きして、完全に再利用不能な状態にしてしまうことが望ましい。
【００３７】
アプリファイル群ＡＦ１〜ＡＦＮは、インターネット１１経由で携帯電話機１６や、通信端末１５に送信される可搬性（この可搬性には、クロスプラットフォーム性なども含まれることが好ましい）のプログラムであるアプリを収容したファイルの集合体である。アプリファイルＡＦ１にはアプリＡＰ１が収容され、アプリファイルＡＦ２にはアプリＡＰ２が収容され、アプリファイルＡＦ３にはアプリＡＰ３が収容され、…、アプリファイルＡＦＮにはアプリＡＰＮが収容されている。
【００３８】
各ファイル中のアプリＡＰ１〜ＡＰＮはそれぞれに異なる機能を備えているが、本実施形態では特にアプリＡＰ１〜ＡＰ３が重要である。
【００３９】
アプリＡＰ１は前記通信端末１５上で実行されて通信端末１５に固有な一対の公開キー（公開鍵）と秘密キー（秘密鍵）を生成する機能を備えている。このとき当該アプリＡＰ１は、通信端末１５に固有な資源（固有資源）である端末ＩＤ（端末ＩＤ以外に、携帯電話機１６の例えば電話番号、電子メールアドレスなども利用可能）を利用して通信端末１５に固有な公開キー（ＰＣ公開キーＰＢ５）と秘密キー（ＰＣ秘密キーＰＶ５）を生成する。端末ＩＤは、パーソナルコンピュータ製品などを一義的に識別するために各製品に付与される識別情報であるから、この端末ＩＤをもとに生成された一対の公開キーＰＢ５と秘密キーＰＶ５は、その生成を行うアプリＡＰ１が同じであっても、端末ごとに異なる一意な鍵とすることができる。
【００４０】
なお、この一意性は必ずしも厳格なものとする必要はない。実用上は、同一の鍵が偶然、生成される確率が十分に小さければ足りるし、厳格な一意性を求めると、それによって、鍵生成のアルゴリズムが大きな制約を受けることも少なくないからである。
【００４１】
当該アプリＡＰ１はまた、生成した一対のＰＣ公開キーＰＢ５とＰＣ秘密キーＰＶ５のうち、ＰＣ公開キーＰＢ５を、仮想プリントサーバ１３の公開鍵であるサーバ公開キーＰＢ３で暗号化して仮想プリントサーバ１３へ送信する機能なども備えている。
【００４２】
サーバ公開キーＰＢ３は、予め通信端末１５へ配送しておくものである。
【００４３】
アプリＡＰ２はこのＡＰ１と同様な機能を携帯電話機１６上で実現するためのプログラムである。パーソナルコンピュータと携帯電話機ではプログラムの実行環境が大きく異なることが多いため、通信端末１５用とは別に携帯電話機１６用のアプリＡＰ２を用意する必要がある。なお、一般的に携帯電話機では、携帯電話機相互間においても、製品ごとにその実行環境がかなり相違するため、当該アプリＡＰ２と同等な機能を持つアプリを携帯電話機製品ごとに用意することが必要になる可能性がある。
【００４４】
当該アプリＡＰ２によって携帯電話機１６上で生成された公開キー（携帯公開キー）をＰＢ６とし、秘密キー（携帯秘密キー）をＰＶ６とする。
【００４５】
アプリＡＰ３は各ドキュメント（ここでは、年賀状）に対応したユーザインタフェースを通信端末１５上でユーザＵ１に提供するプログラムで、後述するように、通信端末１５上で作成した前記個人情報である前記宛先情報および差出人情報のうち、いずれか一方を、前記携帯公開キーＰＢ６等で暗号化して携帯電話機１６へ送信し、他方を仮想プリントサーバ１３のサーバ公開キーＰＢ３等で暗号化して仮想プリントサーバ１３へ送信する機能を備えている。
【００４６】
宛先情報および差出人情報のうち、いずれの情報を携帯電話機１６に送信するかは、どのように決定してもかまわないが、ここで、携帯電話機１６に送信しないほうの情報は、仮想プリントサーバ１３に送信され一時的に保存されることになる。携帯電話機１６はユーザＵ１が２４時間３６５日そばに置いて自身で管理することが可能であるのに対し、仮想プリントサーバ１３の管理は、通常、ユーザＵ１と面識のないドキュメント制作会社などのシステム管理者やネットワーク管理者などが行うことになるため、ユーザＵ１がより重要で、より秘匿性が高いと考えるほうの情報を携帯電話機１６へ送信するようにすれば、ユーザＵ１の安心感が高まる。
【００４７】
また、年賀状などのように膨大な数の宛先に同じ差出人からほぼ同じ内容を送るドキュメントの場合、差出人情報はユーザＵ１の住所、氏名など一人分の個人情報であるのに対し、宛先情報のほうは、例えば数百人分に及ぶ多量の個人情報になる場合なども少なくない。このようなケースでは、携帯電話機１６の記憶容量の小ささに配慮することも必要になる。一般的に携帯電話機の記憶容量はパーソナルコンピュータなどに比べてはるかに小さいのが普通であり、数百人分の個人情報を記憶させるほどの余裕のない携帯電話機の場合には、一人分で済む差出人情報を携帯電話機のほうへ送信するしかない。
【００４８】
前記アプリＡＰ３は、ユーザＵ１の選択に応じて、差出人情報、宛先情報の送信先を動的に決定する機能などを備えたものものであってよいが、本実施形態では、当該差出人情報を携帯電話機１６へ送信し、宛先情報を仮想プリントサーバ１３へ送信するものとする。
【００４９】
また、差出人情報を携帯電話機１６へ安全に送信することができればどのような方法を用いてもかまわないが、本実施形態では、前記アプリＡＰ３は、差出人情報を収容した状態で、差出人情報とともに携帯電話機１６へ送信され、あるいは、宛先情報を収容した状態で、宛先情報とともに仮想プリントサーバ１３へ送信されるものとする。
【００５０】
アプリＡＰ３はまた、テンプレートや宛先情報を包含した状態で仮想プリントサーバ１３からＭＭＫ端末１４へ送信され、ＭＭＫ端末１４上で実行されて、テンプレートや宛先情報を、携帯電話機１６側から供給される差出人情報と合成して前記年賀状を生成したり、印刷出力させたりする機能の少なくとも一部を担うものであってよい。具体的に、テンプレートと、宛先情報と、差出人情報をどのように合成するかについては、ＸＭＬなどを利用して記述しておくとよい。
【００５１】
前記個人ファイル群ＰＦ１〜ＰＦＭは、仮想プリントサーバ１３のサービスを利用するユーザＵ１などの各ユーザごとに設けられるファイルの集合体である。例えば、ユーザＵ１が選択した年賀状のテンプレートなどの情報は、この個人ファイル群ＰＦ１〜ＰＦＭのうち、ユーザＵ１に該当する個人ファイル（例えば、ＰＦ１）に登録される。必要に応じて、前記宛先情報ファイルＤＮ１〜ＤＮＬの内容などは、当該個人ファイルのなかに収容するようにしてもよい。
【００５２】
テンプレートファイル群ＴＦ１〜ＴＦＳは、各種のドキュメントに対応するテンプレートを収容したファイルの集合体である。
【００５３】
テンプレートとは、予め用意された複数の標準的なドキュメント形態のことで、例えば、年賀状のテンプレートの場合、裏面に印刷するデザイン（絵柄など）、裏面に差出人情報を印刷するか否か、「明けましておめでとうございます」と記述するか、「あけましておめでとうございます」と記述するか等、ユーザＵ１が選択可能な多くのバリエーションを含んでいる。
【００５４】
ドキュメントリストファイルＬＴ１は、Ｗｅｂページを構成するＨＴＭＬファイルであるが、その詳細については後述する。
【００５５】
次に、当該仮想プリントサーバ１３とインターネット１１経由で通信する通信端末１５の内部構成例を図２に示す。
【００５６】
（Ａ−１−２）通信端末の内部構成例
図２において、当該通信端末１５は、通信部２０と、制御部２１と、記憶部２２と、操作部２３と、表示部２４とを備えている。
【００５７】
このうち通信部２０は前記通信部４０に対応し、制御部２１は前記制御部４１に対応し、記憶部２２は前記記憶部４２に対応するため、その詳しい説明は省略する。
【００５８】
なお、この制御部２１の場合、前記仮想プリントサーバ１３側の制御部４１と異なり、ＷｅｂサーバやＣＧＩプログラムを含むことはなく、その替わりにＷｅｂブラウザなメーラなどの各種プログラムを含む。
【００５９】
また、通信部２０は、携帯電話機１６と後述するローカル通信を行うための機能を備えている。
【００６０】
さらに、記憶部２２は前記記憶部４２とは、格納しているファイルが異なる。
【００６１】
すなわち当該記憶部２２は、ＰＩＭ（個人情報管理）ファイルＰＭ１、差出人情報ファイルＳＮ、宛先情報ファイルＤＮ１、アプリファイルＡＦＳ１、ＡＦＲ１などの各ファイルを格納する。
【００６２】
このうちＰＩＭファイルＰＭ１は、例えば、住所録や電話帳などのＰＩＭソフトが生成するファイルで、ユーザＵ１によって登録された多数の個人情報が収容されている。通信端末１５上でこのようなＰＩＭソフトを利用するか否かはユーザＵ１の自由であり、ＰＩＭソフトを利用しない場合にはＰＩＭファイルＰＭ１も存在しないが、すでにユーザＵ１がＰＩＭソフトを利用し、多数の個人情報を収容したＰＩＭファイルＰＭ１を記憶部２２に格納している場合には、前記宛先情報は（あるいは、差出人情報も）新たに作成しなくても、このＰＩＭファイルＰＭ１の内容をそのまま利用することができる。
【００６３】
差出人情報ファイルＳＮは、ユーザＵ１自身の個人情報である前記差出人情報を収容したファイルである。このファイルＳＮは、必要に応じて、後述する処理の過程で生成される。同様に、宛先情報ファイルＤＴ１は、前記宛先情報を収容したファイルである。
【００６４】
通信端末１５から送信することで当該宛先情報ファイルＤＴ１の内容は仮想プリントサーバ１３の記憶部４２に格納されて、例えば、前記宛先情報ファイルＤＮ１となる。ただし、通信端末１５上にあるとき当該宛先情報ファイルＤＴ１の内容は平文であってよいのに対し、仮想プリントサーバ１３上にあるときには、必ず暗号化された状態にある。しかもこの暗号化には、事実上、携帯電話機１６を持つユーザＵ１にしか復号化（解読）できない携帯公開キーＰＢ６による暗号化が含まれている。
【００６５】
このため、例えば、仮想プリントサーバ１３側のシステム管理者などの管理の誤りで、インターネット１１上で宛先情報ファイルＤＮ１などが公開されてしまったり、Ｗｅｂサイトのセキュリティホールを突いた攻撃などによって当該宛先情報ファイルＤＮ１が第３者に取得されてしまったりした場合でも、事実上、解読不能な暗号（携帯公開キーＰＢ６等）によって秘匿された状態にあるため、宛先情報ファイルＤＮ１の内容（平文の宛先情報）が第３者に知られることはない。
【００６６】
アプリファイルＡＦＳ１とＡＦＲ１は、前記アプリＡＰ３を収容したファイルである。したがって、前記アプリＡＰ３を前記仮想プリントサーバ１３が受信する前には、当該アプリファイルＡＦＳ１とＡＦＲ１は存在しない。
【００６７】
アプリファイルＡＦＳ１は、前記差出人情報を包含した状態のアプリＡＰ３を収容し、アプリファイルＡＦＲ１は、前記宛先情報を包含した状態のアプリＡＰ３を収容する。
【００６８】
操作部２３は、ユーザＵ１が操作して通信端末１５に指示を伝える部分で、例えば、マウス等のポインティングデバイスや、キーボードなどを有する。
【００６９】
表示部２４は、前記Ｗｅｂブラウザなどの機能に応じて画面表示を行うディスプレイ装置に対応する部分で、ユーザＵ１に仮想プリントサーバ１３のＷｅｂサーバが提供するＷｅｂページなどを閲覧させる。
【００７０】
一方、前記仮想プリントサーバ１３とインターネット１１経由で通信し、ＭＭＫ端末１４や通信端末１５とローカル通信を用いて通信する携帯電話機１６の内部構成例を図３に示す。
【００７１】
（Ａ−１−３）携帯電話機の内部構成例
図３において、当該携帯電話機１６は、通信部３０と、制御部３１と、記憶部３２と、操作部３３と、表示部３４とを備えている。
【００７２】
このうち通信部３０は前記通信部２０に対応し、制御部３１は前記制御部２１に対応し、記憶部３２は前記記憶部２２に対応し、操作部３３は前記操作部２３に対応し、表示部３４は前記表示部２４に対応するため、その詳しい説明は省略する。
【００７３】
なお、上述したように、携帯電話機１６で大量の文字の読み書きを快適に行うことができないのは、結局のところ、この操作部３３や表示部３４のサイズが小さいことが、主な原因である。
【００７４】
携帯電話機のなかにも、前記ＰＩＭソフトを搭載したものがあり、携帯電話機１６がこのような携帯電話機である場合、その記憶部３２には、前記ＰＩＭファイルＰＭ１と同等なＰＩＭファイルＰＭ２を搭載することになる。
【００７５】
また、携帯電話機１６は、前記通信端末１５から前記差出人情報を包含した状態のアプリＡＰ３を受信すると、当該アプリＡＰ３をアプリファイルＡＦＳ２に収容して、記憶部３２に格納する。
【００７６】
上述したように携帯電話機が搭載している記憶部３２の記憶容量は通信端末１５に比べるとはるかに小さいが、（ＰＩＭファイルＰＭ２と）アプリファイルＡＦＳ２程度ならば、十分に格納可能である。
【００７７】
なお、本実施形態の構成上、携帯電話機１６は通信端末１５と通信する必要がある。その際の通信手段は、例えば電子メールなどのように、インターネット１１を経由するものであってもかまわないが、ここでは、インターネット１１を経由せず、直接、１対１で通信端末１５と携帯電話機１６が通信するローカル通信を行うものとする。
【００７８】
ローカル通信は大きく有線方式と無線方式に分かれる。有線方式は、通信端末１５と携帯電話機１６を１対１でケーブルなどで直接、接続して通信する（このケーブルには、携帯電話機１６と通信端末１５以外の端末は接続されない）もので、無線方式は当該ケーブルなどを用いずに通信するものである。無線方式のなかには、赤外線を用いるものと電波を用いるものがある。
【００７９】
通信の秘匿性を確保する観点では有線方式のほうが望ましいが、使い勝手などの観点では無線方式のほうが優れている。無線方式のなかでは、回折してどこまで届いているかが不明確な電波を用いるものよりも、見通しが得られる範囲でしか通信できない赤外線を用いるもののほうが傍受される危険性が少なく秘匿性に優れているといえる。
【００８０】
このようにケーブルや赤外線を活用すれば、平文で送信しても通信の過程では物理的に秘匿性を確保できるため、暗号を利用して論理的に秘匿性を保証する必要性は低いといえるが、本実施形態では、当該ローカル通信にも暗号を利用するものとする。これは、前記電波を用いる無線方式の利用を前提としたものとみてもよい。
【００８１】
なお、各ローカル通信を行うためには、互いに通信する２つの端末（例えば、携帯電話機１６と通信端末１５）が、そのローカル通信に対応した通信インタフェースを装備していることが必要であることは当然である。
【００８２】
最後に、前記ＭＭＫ端末１４の内部構成例を図５に示す。ＭＭＫ端末１４は、コンビニエンスストアや駅など、多数の人が集まる場所に高い密度で配置される情報処理装置で、プリンタ機能を内蔵しているものと外部のプリンタ機能を利用するものがあるが、いずれにしても不特定多数のユーザ（例えば、Ｕ１など）に対してプリンタ機能を提供することができる。
【００８３】
（Ａ−１−５）ＭＭＫ端末の内部構成例
図５において、当該ＭＭＫ端末１４は、通信部５０と、制御部５１と、記憶部５２と、操作部５３と、表示部５４と、印刷部５５と、秘密キー対応部５６とを備えている。
【００８４】
このうち通信部５０は前記通信部２０に対応し、制御部５１は前記制御部２１に対応し、記憶部５２は前記記憶部２２に対応し、操作部５３は前記操作部２３に対応し、表示部５４は前記表示部２４に対応するため、その詳しい説明は省略する。
【００８５】
なお、当該通信部５０は、前記年賀状の印刷出力時に、インターネット１１経由で仮想プリントサーバ１３と通信するほか、前記ローカル通信を利用して携帯電話機１６とも通信する。
【００８６】
また、記憶部５２は、処理の進行に伴って前記ドキュメントリストファイルＬＴ１、アプリファイルＡＤ１などの各ファイルを格納する。
【００８７】
ドキュメントリストファイルＬＴ１は、名刺、年賀状、宅配便の送り状、履歴書、経歴書などユーザＵ１が印刷依頼することが可能な各ドキュメントの一覧（リスト）を含んだＷｅｂページに対応するＨＴＭＬファイルである。操作部５３を操作することにより、ユーザＵ１が当該Ｗｅｂページ上で所望のドキュメントを選択すると、例えば、ハイパーリンクとそのハイパーリンクによって指定される前記ＣＧＩプログラムの機能によって当該選択に対応した前記アプリＡＰ３が、仮想プリントサーバ１３からＭＭＫ端末１４へ送信される。
【００８８】
このときアプリＡＰ３は、該当するテンプレートや宛先情報を包含した状態であるため、ＭＭＫ端末１４は、当該アプリＡＰ３を受信すると、記憶部５２には、当該アプリＡＰ３を収容したアプリファイルＡＤ１が格納される。
【００８９】
前記秘密キー対応部５６は、前記記憶部５２に保存される携帯秘密キーＰＶ６に対し物理的な消去または上書きを行ったり、あるいは暗号化を施すことで、完全に再利用不能な状態にするための部分である。
【００９０】
一般的に秘密キーは、管理している本来の構成要素（携帯秘密キーＰＶ６の場合には携帯電話機１６）の外部へ送信しないほうが望ましいが、後述するように本実施形態では平文の携帯秘密キーＰＶ１が少なくとも一時的にＭＭＫ端末１４上で保存される必要があるため、当該秘密キー対応部５６を用いて、安全性を確保するものである。
【００９１】
以下、上記のような構成を有する本実施形態の動作について、図６〜図９のフローチャートを参照しながら説明する。
【００９２】
図６のフローチャートは、Ｓ１０〜Ｓ２２の各ステップから構成され、図７のフローチャートは、Ｓ３０〜Ｓ３８の各ステップから構成され、図８のフローチャートは、Ｓ４０〜Ｓ４９の各ステップから構成され、図９のフローチャートは、Ｓ５０〜Ｓ６８の各ステップから構成されている。
【００９３】
図６のフローチャートはドキュメント印刷出力の申込み等に関する処理を示し、図７のフローチャートはこの申込み等の処理が終了後、前記差出人情報を携帯電話機１６に保存するまでの準備処理を示し、同様に、図８のフローチャートはこの申込み後、前記宛先情報やテンプレートを仮想プリントサーバ１３に保存するまでの準備処理を示し、図９のフローチャートはこれらの準備処理の終了から、最終的に前記年賀状をＭＭＫ端末１４で印刷出力するまでの処理を示す。
【００９４】
（Ａ−２）実施形態の動作
前記ユーザＵ１が通信端末（パーソナルコンピュータ）１５を用いて、前記仮想プリントサーバ１３にインターネット１１経由でアクセスし、図６に示すように、当該仮想プリントサーバ１３が提供するログイン用のＷｅｂページなどに所定のユーザＩＤやパスワード等を入力してログインする（Ｓ１０）。
【００９５】
ユーザ認証の結果がＯＫでログインできれば、仮想プリントサーバ１３は、鍵生成機能を持つ前記アプリＡＰ１をインターネット１１経由で通信端末１５へ送信する（Ｓ１１）。このとき、サーバ公開キーＰＢ３もアプリＡＰ１とともに送信する。
【００９６】
これを受信した通信端末１５では、サーバ公開キーＰＢ３は記憶部２２に保存し、当該アプリＡＰ１は起動する（Ｓ１２）。これによって、上述したように当該アプリＡＰ１は、通信端末１５上の固有資源を利用して、通信端末１５に固有のＰＣ公開キーＰＢ５と、ＰＣ秘密キーＰＶ５とを生成する（Ｓ１３）。
【００９７】
なお、アプリＡＰ１はインターネット１１経由で通信端末１５に伝送されるものなので、この伝送の過程で第３者に傍受されないように暗号化を施しておくことが望ましい。
【００９８】
この伝送時にはまだ、アプリＡＰ１がユーザＵ１の個人情報などの秘匿すべき情報を包含してはいないが、個人情報を安全に秘匿するためには、鍵（ここでは、（ＰＣ公開キーＰＢ５と）ＰＣ秘密キーＰＶ５）を確実に秘匿する必要があり、鍵を秘匿するには、アプリＡＰ１の平文のコードを、第３者から隠す必要があるからである。
【００９９】
したがって、アプリＡＰ１は暗号化した上でインターネット１１上を伝送する必要があるが、この暗号化には、例えば、サーバ秘密キーＰＶ３を利用することができる。この場合、アプリＡＰ１を受信した通信端末１５上では、会員登録の際などに予め取得してあるサーバ公開キーＰＢ３によってこれを復号化して平文のアプリＡＰ１を取得することになる。平文のアプリＡＰ１を取得してからの処理は、前記ステップＳ１２，Ｓ１３と同じである。
【０１００】
これによって、仮想プリントサーバ１３の会員以外の第３者から鍵を秘匿することができるが、仮想プリントサーバ１３にはユーザＵ１以外にも正規の会員が存在するため、これらの会員からも鍵を秘匿する必要があると考えられる。正規の会員は正規の方法で平文のアプリＡＰ１を取得することができるため、これらの会員から鍵を秘匿するには、アプリＡＰ１が実行する鍵生成アルゴリズムに例えば乱数などを利用して、再現や推測が困難な鍵生成を行う必要がある。再現や推測が困難な鍵生成を行うことができれば、他の正規の会員からだけではなく、仮想プリントサーバ１３上に保存されている平文のアプリＡＰ１自体にアクセスする権限を有する仮想プリントサーバ１３側の正規のネットワーク管理者やシステム管理者からも、ユーザＵ１の鍵を秘匿することができる。実際の個人情報漏洩事件では、このような正規のシステム管理者やネットワーク管理者が漏洩に関与している場合も少なくないことを考慮すると、これらの者から鍵を秘匿する必要性も小さくない。したがって、この鍵生成アルゴリズムは再現や推測の困難性が十分に高いことが求められる。
【０１０１】
再現や推測の困難性を得られる具体的な鍵生成アルゴリズムとしては、様々なものが考えられるが、一例として次のようなアルゴリズムを利用できる。
【０１０２】
すなわち、前記公開鍵暗号方式で使用する一対の公開キーと秘密キーの鍵生成には、周知のように、上述した素数ｐ、ｑの選定、Ｌと互いに素で、Ｌよりも小さな整数ｅの選定の処理が含まれるが（ここで、Ｌは、ｐ−１とｑ−１の最小公倍数）、これらの選定の双方または一方に、前記固有資源（例えば、端末ＩＤ）だけでなく、動的に生成した乱数の値などを反映させるものである（ｐ、ｑ、ｅはいずれも、鍵の構成要素である）。
【０１０３】
なお、端末ＩＤなどの固有資源は必ずしも秘密の情報ではないし、推測も可能であるから、単純にこの固有資源だけを鍵生成に反映させると、端末に固有な一意な鍵を生成することはできても、この鍵は再現したり推測したりすることができるものになる可能性が高い。
【０１０４】
このように再現や推測が困難な鍵を生成する必要があるのは、通信端末１５のＰＣ公開キーＰＢ５とＰＣ秘密キーＰＶ５に限らない。例えば、携帯電話機１６の携帯公開キーＰＢ６と携帯秘密キーＰＶ６についても同様である。
【０１０５】
ステップＳ１３で生成した一対のＰＣ公開キーＰＢ５とＰＣ秘密キーＰＶ５は、後で利用するため、通信端末１５の記憶部２２に保存しておく（Ｓ１４）。
【０１０６】
また、ＰＣ公開キーＰＢ５のほうは、予め取得してある仮想プリントサーバ１３の公開鍵である前記サーバ公開キーＰＢ３で暗号化して当該通信端末１５から仮想プリントサーバ１３に送信する（Ｓ１５）。必要に応じて、この暗号化の実行や、送信の機能も、アプリＡＰ１の機能であってよい。
【０１０７】
なお、一般に、前記公開鍵暗号方式における一対の公開キーと秘密キーは、一方から他方を容易に求めることができない性質を有するため、当該ステップＳ１５では暗号化を省略して平文のＰＣ公開キーＰＢ５を送信するようにしても一応のセキュリティは確保できる。その場合、サーバ公開キーＰＢ３を予め通信端末１５が取得しておく必要もなくなる。
【０１０８】
一方、当該ステップＳ１０、Ｓ１２〜Ｓ１５とほぼ同時に、同じユーザＵ１が操作する携帯電話機１６のほうでも、ステップＳ１７，Ｓ１８〜Ｓ２１の処理が進んでいる。これらのステップＳ１７，Ｓ１８〜Ｓ２１の処理内容は、前記ステップＳ１０、Ｓ１２〜Ｓ１５とほぼ同様である。
【０１０９】
すなわち、ステップＳ１７は前記Ｓ１０に対応し、ステップＳ１８は前記Ｓ１２に対応し、ステップＳ１９は前記Ｓ１３に対応し、ステップＳ２０は前記Ｓ１４に対応し、ステップＳ２１は前記Ｓ１５に対応している。
【０１１０】
ただし携帯電話機１６の場合、ログイン（Ｓ１７）後に仮想プリントサーバ１３から送信されるのはアプリＡＰ１ではなく、前記アプリＡＰ２である。ステップＳ１９で生成された一対の携帯公開キーＰＢ６と携帯秘密キーＰＶ６は、携帯電話機１６の記憶部３２に保存し（Ｓ２０）、携帯公開キーＰＢ６を予め取得してあるサーバ公開キーＰＢ３で暗号化して送信する（Ｓ２１）点などは、前記ステップＳ１０、Ｓ１２〜Ｓ１５と同様である。
【０１１１】
また、必要に応じて、この暗号化の実行や、送信の機能も、アプリＡＰ２の機能であってよい点、携帯公開キーＰＢ６を暗号化せずに平文のまま送信してもよく、その場合には、サーバ公開キーＰＢ３を予め取得しておく必要がない点なども、前記ステップＳ１０、Ｓ１２〜Ｓ１５と同様である。
【０１１２】
さらに、前記ステップＳ１７のログインでユーザＵ１が携帯電話機１６から入力するユーザＩＤおよびパスワードは、前記ステップＳ１０で通信端末１５から入力したユーザＩＤおよびパスワードと同じであるため、仮想プリントサーバ１３側では、この携帯電話機１６からのアクセスが前記通信端末１５からと同じユーザＵ１によるものであることを認識することができる。
【０１１３】
なお、図６の例では、通信端末１５側で実行する前記ステップＳ１０、Ｓ１２〜Ｓ１５を、携帯電話機１６側で実行する前記ステップＳ１７，Ｓ１８〜Ｓ２１よりも先に処理しているが、この順番は逆でもかまわない。また、同時並列的に処理してもかまわない。
【０１１４】
前記ステップＳ１５で送信されたＰＣ公開キーＰＢ５と、前記ステップＳ２１で送信された携帯公開キーＰＢ６が届くと、仮想プリントサーバ１３では、記憶部４２上に設けたユーザＵ１の個人ファイルである前記ＰＦ１にこれらを収容し、保存する。ユーザＵ１に関する２つの公開キーＰＢ５およびＰＢ６が個人ファイルＰＦ１に収容された時点で、前記年賀状の印刷依頼に関する申込みが終了する（Ｓ１６）。ただしこの時点ではまだ、ドキュメントの種類は特定されていない。
【０１１５】
申込み終了後は、ＰＣ公開キーＰＢ５が、仮想プリントサーバ１３から携帯電話機１６へ送信され（Ｓ２２）、携帯電話機１６の記憶部３２に格納され、保存される（Ｓ２３）。この通信はインターネット１１経由の通信になる。
【０１１６】
なお、ＰＣ公開キーＰＢ５の携帯電話機１６への送信は、このように仮想プリントサーバ１３経由で行わず、通信端末１５と携帯電話機１６のあいだのローカル通信によって行うようにしてもよい。インターネット１１はユーザＵ１の管理下にはないがローカル通信はほぼ完全にユーザＵ１の管理下にあり、特に上述した有線方式や赤外線を利用するケースでは、十分な秘匿性を物理的に確保できるため、ローカル通信の利用が安全性の点で有利となる可能性が高い。
【０１１７】
つづいて図７では、通信端末１５からの要求（ＨＴＴＰリクエスト）に応じて、前記アプリＡＰ３が、前記個人ファイルＰＦ１に格納されている携帯公開キーＰＢ６を包含した状態で仮想プリントサーバ１３から送信され（Ｓ３０）、インターネット１１経由でこれを受信した通信端末１５では、当該アプリＡＰ３を起動し（Ｓ３１）、データ入力を受け付ける（Ｓ３２）。
【０１１８】
なお、アプリＡＰ３は例えばＰＣ公開キーＰＢ５で暗号化した状態で通信端末１５へ送信するようにしてもよい。この場合、通信端末１５では、ＰＣ秘密キーＰＶ５で復号化した上で、前記ステップＳ３１以降の処理を行うことになる。
【０１１９】
また、当該アプリＡＰ３を、各ドキュメント（ここでは、年賀状）に対応した専用のアプリとするためには、当該ＨＴＴＰリクエストを送信する際などに、通信端末１５側からドキュメントの種類（ここでは、年賀状）を指定しておく必要がある。
【０１２０】
ただしアプリＡＰ３をドキュメント別の専用のアプリとせず、すべてのドキュメントに対応可能な分岐を持つプログラムとする場合には、ドキュメントの種類の指定は省略できる。
【０１２１】
この前後の処理に関し通信端末１５の表示部２４に画面表示される画面は、例えば、図１０のＧ１１〜Ｇ１８に示すものであってよい。画面遷移は、画面Ｇ１１、Ｇ１２，Ｇ１３，Ｇ１４，Ｇ１５，Ｇ１６，Ｇ１７，Ｇ１８の順番である。
【０１２２】
図１０の画面Ｇ１１は、前記ＨＴＴＰリクエスト送信のための画面であり、画面Ｇ１２は、ドキュメントの種類の指定（ドキュメント選択）を行うための画面である。画面Ｇ１３〜Ｇ１８は、一人の個人（例えば、前記宛先情報に含まれる一人分の個人情報（プロファイルデータ）を入力するための画面の例である。これらの画面Ｇ１３〜Ｇ１８は、アプリＡＰ３の機能に基づいて画面表示されるものであってよい。
【０１２３】
なお、図１０には年賀状の印刷のために必要でない画面も含まれている。例えば、画面Ｇ１４で入力する生年月日や、年齢などの情報は一般的な年賀状には不要である。
【０１２４】
前記差出人情報や宛先情報など、年賀状の印刷に必要な個人情報（プロファイル）の入力が終了し、通信端末１５の記憶部２２に保存されると（Ｓ３３）、前記アプリＡＰ３が表示させる画面Ｇ２をもとに、各個人情報の送信先を選択する。図７の例では、送信先として携帯電話機１６を選択している（Ｓ３４）。
【０１２５】
画面Ｇ２では、ユーザＩＤやパスワードを入力させてアプリＡＰ３がユーザ認証を行っているため、ユーザ認証の結果がＯＫの場合にのみ、次のステップＳ３５へ進むことができる。必要に応じて、このようなユーザ認証は省略可能である。
【０１２６】
当該ステップＳ３５ではＰＣ秘密キーＰＶ５と携帯公開キーＰＢ６で、暗号化するため、これにつづくステップＳ３６では、例えば前記差出人情報を包含し暗号化されたアプリＡＰ３を携帯電話機１６へ送信する（Ｓ３６）。
【０１２７】
秘匿性を確保するためには、携帯公開キーＰＢ６で暗号化するだけで十分であるが、重ねてＰＣ秘密キーＰＶ５で暗号化することで、信頼できる通信相手である通信端末１５から供給されたデータであることを携帯電話機１６側で確認でき、なりすましの防止などに有効である。ＰＣ秘密キーＰＶ５で暗号化することができるのは通信端末１５だけであるため、なりすましがあると、後で、ＰＣ公開キーＰＢ５を利用して行う復号化（ステップＳ３７）の結果が、正常なものでなくなるからである。
【０１２８】
ステップＳ３６の送信は、インターネット１１経由で行ってもかまわないが、通信端末１５と携帯電話機１６が上述した通信インタフェースを装備している場合には、ローカル通信を用いたほうが安全である。また、有線方式や赤外線によるローカル通信では、暗号化の処理（ステップＳ３５）を省略できることも上述した通りである。有線方式はもちろん、赤外線を用いるローカル通信の場合も、伝送路全体がほぼ完全にユーザＵ１の管理下にあるため、なりすましの危険性もほとんど無い。
【０１２９】
前記差出人情報を包含した状態でステップＳ３５においてＰＣ秘密キーＰＶ５と携帯公開キーＰＢ６で暗号化され、前記ステップＳ３５で送信されたアプリＡＰ３を受信すると、携帯電話機１６は、当該アプリＡＰ３を、携帯秘密キーＰＶ６とＰＣ公開キーＰＢ５を用いて復号化し（Ｓ３７）、記憶部３２に保存する（Ｓ３８）。
【０１３０】
必要に応じて、ステップＳ３７とＳ３８の順番を入れ替えてもかまわない。その場合、アプリＡＰ３は携帯電話機１６上で保存されているときには暗号化された状態にあり、利用される直前に復号化されることになる。
【０１３１】
次に図８について説明する。
【０１３２】
図８のフローチャートは情報の送信先が異なるだけで、基本的に図７のフローチャートと同じである。
【０１３３】
すなわち、ステップＳ４０は前記Ｓ３０に対応し、ステップＳ４１は前記Ｓ３１に対応し、ステップＳ４２は前記Ｓ３２に対応し、ステップＳ４３は前記Ｓ３３に対応し、ステップＳ４４は前記Ｓ３４に対応し、ステップＳ４５は前記Ｓ３５に対応し、ステップＳ４７は前記Ｓ３６に対応し、ステップＳ４８は前記Ｓ３７に対応し、ステップＳ４９は前記Ｓ３８に対応する。
【０１３４】
ステップＳ４４では前記ステップＳ３４と異なり、ユーザＵ１が送信先として仮想プリントサーバ１３を選択している。
【０１３５】
なお、ステップＳ４６は対応する処理が図７には存在しないが、このステップＳ４６では、宛先情報を包含した状態のアプリＡＰ３を、前記サーバ公開キーＰＢ３で暗号化している。
【０１３６】
また、前記ステップＳ３８に対応するステップＳ４９では、仮想プリントサーバ１３上に設けられているユーザＵ１のための前記個人ファイルＰＦ１に復号結果が保存される。
【０１３７】
図７のように、通信端末１５から携帯電話機１６へ送信（Ｓ３６）する場合と異なり、図８のステップＳ４６では通信端末１５から仮想プリントサーバ１３へ送信しなければならない。この送信では、前記ローカル通信は使用できず、危険性の高いインターネット１１経由の通信を行う必要がある。
【０１３８】
したがってステップＳ４６でサーバ公開キーＰＢ３で暗号化を施すことにより、サーバ秘密キーＰＶ３を持つ仮想プリントサーバ１３でしか当該アプリＡＰ３を復号（解読）できないようにしておく必要性は高い。この場合、さらに、ステップＳ４９にて保存された個人ファイルＰＦ１はサーバ秘密キーＰＶ３により復号化されてはいるが、この時点では平文ではなく依然としてＰＣ秘密キーＰＶ５および携帯公開キーＰＢ６にて暗号化された状態にあるため、ファイルＰＦ１にアクセス可能なサーバ管理者等であっても携帯秘密キーを入手することは不可能であり、セキュリティ性は高い。
【０１３９】
なお、図８中に示した画面Ｇ３は、前記画面Ｇ２と同じである。
【０１４０】
また、図７のフローチャートと図８のフローチャートは、いずれを先に実行してもかまわない。
【０１４１】
図７と図８のフローチャートの処理が終了し、前記差出人情報が携帯電話機１６に保存され、前記宛先情報が仮想プリントサーバ１３に保存された状態になると、ユーザＵ１はいつでも、携帯電話機１６を携帯してＭＭＫ端末１４まで移動し、図９のフローチャートの処理を開始することができる。図９のフローチャートは、携帯電話機１６，ＭＭＫ端末１４，仮想プリントサーバ１３のあいだで実行される。
【０１４２】
図９に示すように、ユーザＵ１の操作によってＭＭＫ端末１４から仮想プリントサーバ１３に要求が送信されると、ログインのため、例えば、画面Ｇ４に示すようなＷｅｂページが仮想プリントサーバ１３から送信されて、ＭＭＫ端末１４の表示部５４に画面表示される。
【０１４３】
この画面Ｇ４に対し、ユーザＵ１が仮想プリントサーバ１３の会員としてのユーザＩＤとパスワードを入力すると（Ｓ５０）、その入力内容が仮想プリントサーバ１３へ送信され、前記ユーザ管理ファイルＵＭの格納内容などを用いて会員照合を行う（Ｓ５１）。
【０１４４】
ユーザＵ１は正規の会員であるから、そのユーザＩＤやパスワードがユーザ管理ファイルＵＭに登録されており、入力内容と一致するユーザＩＤやパスワードが検索されるため、ステップＳ５２はＹＥＳ側に分岐する。
【０１４５】
もし正規の会員でない者がログインしようとした場合には、当該ステップＳ５２はＮＯ側に分岐して所定のエラー処理が行われる（Ｓ５３）。エラー処理の内容には様々なものが考えられるが、例えば、「あなたは会員登録されておりません」というメッセージを表示部５４に画面表示させたり、会員登録を促すメッセージを画面表示させたりするようにしてもよい。
【０１４６】
ステップＳ５２がＹＥＳ側に分岐すると、ステップＳ５４とＳ５７が実行される。
【０１４７】
当該ステップＳ５４では、仮想プリントサーバ１３からＭＭＫ端末１４に対して携帯電話機１６が保存中の前記アプリＡＰ３や携帯秘密キーＰＶ６を取得するように指示を出し、この指示に応じてＭＭＫ端末１４は携帯電話機１６に対して、前記アプリＡＰ３と携帯秘密キーＰＶ６の送信を依頼する。この依頼は、前記ローカル通信によって行う。
【０１４８】
この依頼を受信（Ｓ５５）した携帯電話機１６では、前記差出人情報を包含した状態のアプリＡＰ３と携帯秘密キーＰＶ６が前記ローカル通信によってＭＭＫ端末１４に送信されて（Ｓ５６）、前記アプリファイルＡＤ１等に保存される（Ｓ５８）。このステップＳ５６の送信の前に当該アプリＡＰ３が例えば携帯公開キーＰＢ６で暗号化された場合には、ステップＳ５８の保存の前に、携帯秘密キーＰＶ６を用いて復号化しておくとよい。
【０１４９】
また、ステップＳ５７では、前記ドキュメントリストファイルＴＬ１を仮想プリントサーバ１３からＭＭＫ端末１４へ送信する。
【０１５０】
これをインターネット１１経由で受信したＭＭＫ端末１４は、例えば、画面Ｇ５のようなＷｅｂページを表示部５４に表示することで、作成可能なドキュメントをユーザＵ１に提示する（Ｓ５９）。ここで、当該画面Ｇ５は、ドキュメントリストファイルＴＬ１に対応した画面となっている。
【０１５１】
このとき当該画面Ｇ５に対しユーザＵ１がＭＭＫ端末１４の操作部５３を用いて行った操作に応じて、あるいは、画面Ｇ５の表示当初から、仮想プリントサーバ１３またはＭＭＫ端末１４からユーザＵ１に伝えるメッセージを表示することができる。
【０１５２】
例えば、画面Ｇ５上ではドキュメントの一つである名刺に対応して、「会社情報が不足」していることを示すメッセージが記述されている。これは、上述したステップＳ４２などにおけるデータ入力で、会社の名称や住所などに関する一般的な名刺では必要とされる記載事項がユーザＵ１から仮想プリントサーバ１３に提供されていないこを伝えるものである。
【０１５３】
したがって、ユーザＵ１はこの時点では、名刺を選択することはできない。
【０１５４】
また、前記ドキュメントリストファイルＴＬ１に所定のプログラムを埋め込んでおくこと等により、埋め込んだ当該プログラムの機能によって、ＭＭＫ端末１４の記憶部５２上における前記アプリファイルＡＤ１の存否を検査し、その検査結果により、まだ差出人情報などがＭＭＫ端末１４に送信されていないことをユーザＵ１に伝えるようにすること等も可能である。
【０１５５】
画面Ｇ５上でボタンが埋められていることから、当該名刺以外の４つのドキュメント、すなわち年賀状、宅配便の送り状、履歴書、経歴書は選択可能であることが分かる。ただしこの時点で選択可能であるか否かは、前記ステップＳ４２などで入力したデータやアプリファイルＡＤ１の存否などに応じて変化するため、例えば、学歴や職歴などに関するデータをステップＳ４２等で入力していない場合などには、履歴書や経歴書も選択できない状態となる。
【０１５６】
画面Ｇ５上で選択可能な４つのドキュメントのうち、いずれか一つの「作成」ボタンを、ユーザＵ１が操作部５３を操作することによって選択すると（Ｓ６０）、以降では、そのドキュメントを印刷するための処理が進められる。ここでは、ユーザＵ１は、前記年賀状の「作成」ボタンを選択したものとする。
【０１５７】
当該ステップＳ６０で前記年賀状の「作成」ボタンを選択したことにより、年賀状の作成に必要な前記アプリＡＰ３が仮想プリントサーバ１３へ要求される（Ｓ６１）。これは、画像Ｇ５の年賀状の「作成」ボタンに、対応するアプリＡＰ３に応じたＵＲＬを用いた要求が送信できるようにドキュメントリストファイルＴＬ１を記述しておくことで実現できる。なお、このＵＲＬは、前記個人ファイルＰＦ中から前記ステップＳ４９で保存したアプリＡＰ３を検出して返送する機能を持つＣＧＩプログラムを指定するＵＲＬである。
【０１５８】
これを受けて、仮想プリントサーバ１３では、当該ＵＲＬに対応するＣＧＩプログラムが、前記アプリＡＰ３を前記個人ファイルＰＦ１のなかから抽出して（Ｓ６２）、予め取得してあるＭＭＫ公開キーＰＢ４で暗号化した上で、ＭＭＫ端末１４へ送信する（Ｓ６３）。
【０１５９】
このとき、テンプレートもアプリＡＰ３とともにＭＭＫ端末１４へ送信されることになる。テンプレートの内容は必ずしも秘匿性のあるものではないとも考えられるが、もしも秘匿したければ、当該ステップＳ６３でＭＭＫ公開キーＰＢ４を用いてテンプレートを暗号化するとよい。
【０１６０】
個人ファイルＰＦ１から抽出したとき、アプリＡＰ３は前記宛先情報を包含し、ＰＣ秘密キーＰＶ５と携帯公開キーＰＢ６で暗号化された状態にあり、それだけでも十分な秘匿性を有するが、このステップＳ６３でさらにＭＭＫ公開キーＰＢ４で暗号化するのは、ＭＭＫ秘密キーＰＶ４を持つＭＭＫ端末１４でしかアプリＡＰ３の復号化（解読）を行うことができないようにするためである。
【０１６１】
インターネット１１経由でこれを受信すると、ＭＭＫ端末１４は、前記ＭＭＫ公開キーＰＢ４に対応するＭＭＫ秘密キーＰＶ４で復号化し（Ｓ６４）、さらに携帯秘密キーＰＶ６と、ＰＣ公開キーＰＢ５で復号化する（Ｓ６５）。
【０１６２】
テンプレートは当該ステップＳ６４が実行された時点で平文にもどるためステップＳ６５の対象外である。アプリＡＰ３と当該アプリＡＰ３に包含されている前記宛先情報のほうは、このステップＳ６５が実行されることによってはじめて平文にもどる。
【０１６３】
次に、当該テンプレート、宛先情報、および前記ステップＳ５８でアプリファイルＡＤ１に保存されていたほうのアプリＡＰ３が包含する差出人情報が、前記ＸＭＬの指定に応じてＭＭＫ端末１４の記憶部５２上で合成され（Ｓ６６）、印刷出力される（Ｓ６７）。
【０１６４】
このステップＳ６６には、テンプレートが提供する多様なバリエーションのなかからユーザＵ１が望むものを選択する処理が含まれる。
【０１６５】
その選択には、例えば、図１１に示す画面例Ｇ２０〜Ｇ２６を用いて行う宛名印刷のバリエーションの選択や、図１２に示す画面例Ｇ２０，Ｇ３１〜Ｇ３６を用いて行う裏面印刷のバリエーションの選択が含まれる。
【０１６６】
画面Ｇ２０〜Ｇ２６，Ｇ３１〜Ｇ３６は、前記アプリＡＰ３などの機能によってＭＭＫ端末１４の表示部５４に表示される画面を示している。
【０１６７】
ステップＳ６７の印刷出力が正常に終了すると、自動的に、またはユーザＵ１からの指示に応じて、前記秘密キー対応部５６が動作し、前記物理的な消去または上書きを行ったり、あるいは暗号化を施すことで、ＭＭＫ端末１４上の携帯秘密キーＰＶ６を完全に再利用不能な状態にする（Ｓ６８）。
【０１６８】
ステップＳ６７で印刷が終了すると、当該携帯秘密キーＰＶ６をＭＭＫ端末１４に保存しておく必要はなくなるし、平文の携帯秘密キーＰＶ６はセキュリティ上の観点から、本来、携帯電話機１６以外の場所に置くべきものではないからである。
【０１６９】
（Ａ−３）実施形態の効果
以上のように、本実施形態によれば、個人情報（差出人情報や宛先情報など）のセキュリティ性が高く、安全である。
【０１７０】
また、個人情報の一部（例えば、差出人情報）を携帯電話機（１６）に保存できるようにすることで、ユーザ（Ｕ１）に大きな安心感を与えることもできる。
【０１７１】
（Ｂ）他の実施形態
上記実施形態にかかわらず、アプリＡＰ１〜ＡＰ３の機能は、２つまたは１つのアプリに集約してもかまわない。ただし一般的に多数の機能を有する分岐の多いプログラムはサイズも大きくなるため、ネットワーク１１やローカル通信を介して搬送するアプリの性質上、あまりサイズを大きくすることは好ましくないといえる。また、記憶容量の制約が大きい携帯電話機などは、あまりにサイズの大きなアプリを搭載することができない可能性もある。
【０１７２】
また、前記宛先情報や差出人情報が不要なドキュメントの印刷を依頼する場合も、これらを必要とする前記年賀状や送り状の場合と同様、一対の情報を、仮想プリントサーバ１３と、携帯電話機１６に分散して蓄積することができる。例えば、履歴書などの場合には、本人の住所、氏名などの情報と、本人の学歴や職歴などの情報がこの一対の情報に該当するので、これらを分散して蓄積することになる。
【０１７３】
さらに、上記実施形態にかかわらず、単に通信端末（パーソナルコンピュータ）１５上にあるデータを携帯電話機１６に送信するだけならば、前記アプリＡＰ３の機能を利用しなくても、そのための一般的なツールを利用することも可能である。また、通信端末１５と携帯電話機１６を直接、１対１でケーブルで接続してデータ（ここでは、差出人情報）を送信する場合などには暗号化を施さなくても十分な秘匿性が確保できるため、前記アプリＡＰ３の機能のうち、暗号化したデータを携帯電話機１６へ送信する機能は省略できる可能性がある。
【０１７４】
なお、宛先情報を仮想プリントサーバ１３へ送信するには、上記実施形態にかかわらず、ＦＴＰプロトコルを利用してもよい。サイズの大きなデータ（例えば、宛先情報）をインターネット経由でサーバ側へ送信するにはＦＴＰが適していることが多い。
【０１７５】
また、前記携帯電話機１６がＰＩＭソフトを搭載している場合などには、前記通信端末１５を省略することが可能である。
【０１７６】
すでに前記ＰＩＭファイルＰＭ２などに収容している多数の個人情報を前記差出人情報や宛先情報として再利用でき、小さすぎて使い勝手のよくない携帯電話機１６を利用したとしても、ユーザＵ１の操作負担が大きくないからである。
【０１７７】
なお、上記実施形態では通信端末１５から携帯電話機１６へ差出人情報を送信するステップＳ３６でも、通信端末１５から仮想プリントサーバ１３へ宛先情報を送信するステップＳ４７でも、同じアプリＡＰ３を利用するものとしたが、各場合で異なるアプリを利用するようにしてもよい。
【０１７８】
上記実施形態ではユーザＵ１が一人で、年賀状の印刷出力を行ったが、複数のユーザで同一のドキュメント形態を共用できるようにしてもよい。その場合、年賀状の宛先情報や差出人情報は各ユーザごとに異なる。
【０１７９】
また、ドキュメント形態を共用する場合、前記公開鍵暗号方式に対応した鍵を利用することもできるが、共通鍵暗号方式を利用するのが簡便である。共通鍵の配送方法には様々な方法を用いることができるが、例えば、同じ内容の共通鍵を共用にかかる各ユーザの（例えば携帯電話機の）公開キーで暗号化した上で配送することが考えられる。各ユーザが携帯電話機などを用いてＭＭＫ端末や仮想プリントサーバと通信するときには、当該共通鍵による暗号化や復号化を行うことになる。
【０１８０】
共通鍵は１つの印刷依頼に関する処理が完了した時点で廃棄し、新しい印刷依頼があるたびに、異なる共通鍵を用いるようにすると安全性が高まる。
【０１８１】
なお、上記実施形態では、アプリに宛先情報や差出人情報などのデータを包含させた状態でアプリとともにこれらのデータを、通信相手（例えば、仮想プリントサーバ１３）へ送信するようにしたが、必要に応じて、データだけを送信するようにしてもよいことは当然である。
【０１８２】
また、上記実施形態には、既存の暗号システムを利用してもかまわない。例えば、ステップＳ５０〜Ｓ６３のあいだにおけるＭＭＫ端末１４と仮想プリントサーバ１３の通信には、ＳＳＬなどを利用することも可能である。
【０１８３】
さらに、前記ＣＧＩプログラムはベンダ固有のプログラムに置換可能である。ベンダ固有のプログラムのほうが、高いスループットが得られる可能性がある。
【０１８４】
なお、上記実施形態で使用した携帯電話機（１６）はその他の携帯通信端末に置換可能である。例えば、ＰＤＡや、ＰＨＳ端末などに置換することができる。
【０１８５】
また、上記実施形態で使用したＭＭＫ端末（１４）はその他の種類の通信端末に置換可能である。さらに、上記実施形態では、最終的に印刷出力を行ったが、出力の形態は必ずしも印刷出力である必要はない。例えば、画像出力を最終的な出力の形態とするようにしてもかまわない。
【０１８６】
なお、上記実施形態では、鍵生成機能を持つアプリ（例えば、ＡＰ１，ＡＰ２）の配送元がテンプレートなどの配送元と同じ仮想プリントサーバ１３であったが、これらの配送元は異なるサーバであってもかまわない。
【０１８７】
また、上記実施形態にかかわらず、各アプリ等を配送する際には、平文のアプリ等を所定のハッシュ関数で演算した結果であるハッシュ値（ダイジェスト）を付加して、アプリ等の受信側で、改ざんが行われていないことを確認できるようにすることも望ましい。
【０１８８】
さらに、上記実施形態では、印刷出力前に前記ステップＳ６６で合成するデータは、宛先情報と差出人情報とテンプレートの３種類であったが、合成するデータの種類は、２種類であってもよく、４種類以上であってもよい。
【０１８９】
以上の説明では主としてソフトウエア的に本発明を実現したが、本発明はハードウエア的に実現することも可能である。
【０１９０】
【発明の効果】
以上に説明したように、本発明のリモート印刷システム及びリモート印刷サービス方法によれば、ユーザの負担が少なく、可用性や利便性が高い。
【図面の簡単な説明】
【図１】実施形態にかかる通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用する通信端末の内部構成例を示す概略図である。
【図３】実施形態で使用する携帯電話機の内部構成例を示す概略図である。
【図４】実施形態で使用する仮想プリントサーバの内部構成例を示す概略図である。
【図５】実施形態で使用するＭＭＫ端末の内部構成例を示す概略図である。
【図６】実施形態の動作例を示すフローチャートである。
【図７】実施形態の動作例を示すフローチャートである。
【図８】実施形態の動作例を示すフローチャートである。
【図９】実施形態の動作例を示すフローチャートである。
【図１０】実施形態の動作を示す画面例である。
【図１１】実施形態の動作を示す画面例である。
【図１２】実施形態の動作を示す画面例である。
【符号の説明】
１０…通信システム、１１…ネットワーク、１２…携帯電話ネットワーク、１３…仮想プリントサーバ、１４…ＭＭＫ端末、１５…通信端末、１６…携帯電話機、２０，３０，４０，５０…通信部、２１，３１，４１，５１…制御部、２２，３２，４２，５２…記憶部、５５…印刷部、５６…秘密キー対応部、ＰＢ３…サーバ公開キー、ＰＶ３…サーバ秘密キー、ＰＢ４…ＭＭＫ公開キー、ＰＶ４…ＭＭＫ秘密キー、ＰＢ５…ＰＣ公開キー、ＰＶ５…ＰＣ秘密キー、ＰＢ６…携帯公開キー、ＰＶ６…携帯秘密キー、ＡＰ１〜ＡＰＮ…アプリ。

Claims (14)

1. 性質の異なる複数の要素データから構成される単位データを、各要素データを合成することによって生成するデータ生成システムにおいて、前記複数の要素データのうち、ユーザが秘匿性が高いと認める要素データである高秘匿性要素データを保存するため、ユーザ自身が携帯する携帯通信端末と、前記複数の要素データのうち当該高秘匿性要素データ以外の要素データである低秘匿性要素データを少なくとも一時的に保存するための保存サーバと、
   前記携帯通信端末および保存サーバと通信するためのインタフェースを持ち、前記携帯通信端末から供給された高秘匿性要素データと保存サーバから供給された低秘匿性要素データを合成した上で、前記単位データを構成し、所定の出力形態で出力する合成出力端末とを備えたことを特徴とするデータ生成システム。
2. 請求項１のデータ生成システムにおいて、
   前記低秘匿性要素データのうち第１の低秘匿性要素データは、前記ユーザから供給を受けたデータであり、第２の低秘匿性要素データは、対応する前記単位データの標準的な形態を示すテンプレートデータで、前記保存サーバがその供給元となることを特徴とするデータ生成システム。
3. 請求項２のデータ生成システムにおいて、
   前記携帯通信端末のほかに、前記ユーザが、前記高秘匿性要素データまたは第１の低秘匿性要素データを作成するために使用するデータ作成用通信端末を備えることを特徴とするデータ生成システム。
4. 請求項３のデータ生成システムにおいて、
   各ユーザ固有の所定の暗号鍵の生成機能を持つ可搬性プログラムを、前記携帯通信端末またはデータ作成用通信端末に供給する鍵供給手段を、前記保存サーバの内部または外部に備えたことを特徴とするデータ生成システム。
5. 暗号鍵として公開鍵系の暗号鍵を利用する場合の請求項４のデータ生成システムにおいて、
   前記第１の低秘匿性要素データは、前記ユーザ以外の者に解読不能な形で、前記保存サーバに一時的に保存させることを特徴とするデータ生成システム。
6. 請求項５のデータ生成システムにおいて、
   前記第１の低秘匿性要素データは、前記保存サーバに一時的に保存されているとき、少なくとも前記携帯通信端末の公開鍵である携帯用公開鍵で、暗号化された状態にあることを特徴とするデータ生成システム。
7. 請求項６のデータ生成システムにおいて、
   前記携帯通信端末は、
   当該携帯通信端末からの要求に応じて、前記鍵供給手段が可搬性プログラムを届けると、当該可搬性プログラムが携帯通信端末上の固有のリソースを利用して生成した一対の秘密鍵と公開鍵である携帯用秘密鍵と前記携帯用公開鍵とを保存する携帯用鍵保存部を備え、
   前記データ作成用通信端末は、
   当該携帯通信端末から配送を受けた携帯用公開鍵を用いて、前記第１の低秘匿性要素データを暗号化した上で、前記保存サーバに送信し、保存させることを特徴とするデータ生成システム。
8. 性質の異なる複数の要素データから構成される単位データを、各要素データを合成することによって生成するデータ生成方法において、
   前記複数の要素データのうち、ユーザが秘匿性が高いと認める要素データである高秘匿性要素データを保存するための携帯通信端末をユーザ自身が携帯し、
   前記複数の要素データのうち当該高秘匿性要素データ以外の要素データである低秘匿性要素データは少なくとも一時的に保存サーバに保存し、
   合成出力端末は、前記携帯通信端末および保存サーバと通信するためのインタフェースを持ち、前記携帯通信端末から供給された高秘匿性要素データと保存サーバから供給された低秘匿性要素データを合成した上で、前記単位データを構成して、所定の出力形態で出力することを特徴とするデータ生成方法。
9. 請求項８のデータ生成方法において、
   前記低秘匿性要素データのうち第１の低秘匿性要素データは、前記ユーザから供給を受けたデータであり、第２の低秘匿性要素データは、対応する前記単位データの標準的な形態を示すテンプレートデータで、前記保存サーバがその供給元となることを特徴とするデータ生成方法。
10. 請求項９のデータ生成方法において、
    前記携帯通信端末のほかに、前記ユーザは、前記高秘匿性要素データまたは第１の低秘匿性要素データを作成するためにデータ作成用通信端末を使用することを特徴とするデータ生成方法。
11. 請求項１０のデータ生成方法において、
    各ユーザ固有の所定の暗号鍵の生成機能を持つ可搬性プログラムを、前記携帯通信端末またはデータ作成用通信端末に供給する鍵供給手段を、前記保存サーバの内部または外部に備えたことを特徴とするデータ生成方法。
12. 暗号鍵として公開鍵系の暗号鍵を利用する場合の請求項１１のデータ生成方法において、
    前記第１の低秘匿性要素データは、前記ユーザ以外の者に解読不能な形で、前記保存サーバに一時的に保存させることを特徴とするデータ生成方法。
13. 請求項１２のデータ生成方法において、
    前記第１の低秘匿性要素データは、前記保存サーバに一時的に保存されているとき、少なくとも前記携帯通信端末の公開鍵である携帯用公開鍵で、暗号化された状態にあることを特徴とするデータ生成方法。
14. 請求項１３のデータ生成方法において、
    前記携帯通信端末は、
    当該携帯通信端末からの要求に応じて、前記鍵供給手段が可搬性プログラムを届けると、当該可搬性プログラムが携帯通信端末上の固有のリソースを利用して生成した一対の秘密鍵と公開鍵とである携帯用秘密鍵と前記携帯用公開鍵とを、携帯用鍵保存部に保存し、
    前記データ作成用通信端末は、
    当該携帯通信端末から配送を受けた当該携帯用公開鍵を用いて、前記第１の低秘匿性要素データを暗号化した上で、前記保存サーバに送信し、保存させることを特徴とするデータ生成方法。

Images