Output management system and method for enabling access to private network resources
Abstract
Systems and methods for managing output such as printing, faxing, and e-mail on different types of computer networks. In one aspect, this system and method allows access to print and / or document resources located on the private network behind the firewall (61, 62, 63, 64). Establish a pass-through communication link between system components located across the firewall. The system's user interface allows you to select the source data and the output device to print this source data, either or both of which may be behind the firewall. It then retrieves the source data and transfers it to a print service (PS1) that draws the output image data according to the source data and the selected output device (D1). The output image data is then submitted to the output device and physically rendered. Access to private resources is achieved through pass-through communication links. In addition, the system also allows documents to be printed by reference.

Term
Term ended
Projected expiry passed 22 August 2022, 4.1 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
67 claims: 10 independent, 57 dependent
- 1ファイヤウォールの外側にある発信元デバイスからファイヤウォールの背後にあるプライベート・ネットワーク上で印刷する方法であって、 ファイヤウォールの背後に配置されている出力管理システム・コンポーネントとファイヤウォールの外側にある出力管理システム・コンポーネントとの間の、ファイヤウォールを通過するパススルー通信リンクを確立することと、 描画可能なデータを発信元デバイスに供給し、それによりユーザ・インターフェイスを発信元デバイス上に描画することと、 ユーザ・インターフェイスを介して印刷するソース・データをユーザが選択できるようにすることと、 ソース・データの印刷先のプライベート・ネットワーク上の出力デバイスをユーザが選択できるようにすることと、 ストアからソース・データを検索することと、 ソース・データと選択された出力デバイスに対応する出力イメージ・データを描画することと、 ファイヤウォールの外側にある出力管理システム・コンポーネントから出力イメージ・データをファイヤウォールの背後に配置されている出力管理システム・コンポーネントに送信することと、 ファイヤウォールの背後に配置されている出力管理システム・コンポーネントから出力イメージ・データを出力デバイスにサブミットし、出力デバイスにより物理的に描画することを含む方法。
- 2ファイヤウォールの外側および背後に配置されている各出力管理システム・コンポーネントは、出力管理システム内の他のコンポーネント管理機能を備えるメッセージ・センター・コンポーネントを含む請求項1に記載の方法。
- 3さらに、ファイヤウォールの背後に配置されている出力管理システム・コンポーネントを介してアクセスできるファイヤウォールの背後に配置されている1つまたは複数の出力デバイスを識別するパススルー通信リンクを使用し、ファイヤウォールの背後に配置されている出力管理システム・コンポーネントからデータをファイヤウォールの外側にある出力管理システム・コンポーネントに送信することを含む請求項1に記載の方法。
- 4ファイヤウォールの外側に配置されている出力管理システム・コンポーネントがサーバ・コンポーネントを含み、ファイヤウォールの背後に配置されている出力管理システム・コンポーネントはクライアント・コンポーネントを含む請求項1に記載の方法。
- 5パススルー通信のリンクは、仮想プライベート・ネットワーク(VPN)リンクを含む請求項1に記載の方法。
- 6発信元デバイスはWeb対応無線デバイスを含む請求項1に記載の方法。
- 7発信元デバイスはBluetooth対応デバイスを含む請求項1に記載の方法。
- 8ストアは発信元デバイス上のローカル・ストアを含む請求項1に記載の方法。
- 9ストアは、無線デバイスから遠い場所に配置されているリモート・ストアを含む請求項1に記載の方法。
- 10リモート・ストアはプライベート・ネットワーク上に配置されている請求項9に記載の方法。
- 11印刷サービスを使用し、 ソース・データのファイル・タイプを判別するオペレーションと、 プリント・サーバを介してロードし、出力イメージ・データを生成するのに適したアプリケーションを判別するオペレーションと、 アプリケーションと印刷サブシステムを組み合わせて出力イメージ・データを生成させる印刷アクションを開始するオペレーションとを実行することにより出力イメージ・データを生成する請求項1に記載の方法。
- 12さらに、ユーザ・インターフェイス上に描画するときに、出力デバイスにより生成される描画された出力のシミュレート表現を含む印刷プレビュー・データを無線デバイスに供給することを含む請求項1に記載の方法。
- 13ファイヤウォールの外側にある発信元デバイスからファイヤウォールの背後にあるプライベート・ネットワーク上で印刷する方法であって、 ファイヤウォールの背後に配置されている出力管理システム・コンポーネントとファイヤウォールの外側にある出力管理システム・コンポーネントとの間の、ファイヤウォールを通過するパススルー通信リンクを確立することと、 描画可能なデータを発信元デバイスに供給し、それによりユーザ・インターフェイスを発信元デバイス上に描画することと、 ユーザがユーザ・インターフェイスを介して印刷するソース・データを選択できるようにすることと、 ユーザがソース・データの印刷先のプライベート・ネットワーク上の出力デバイスを選択できるようにすることと、 ファイヤウォールの外側に配置されている出力管理システム・コンポーネントからソース・データまたはそのデータへの参照をファイヤウォールの背後に配置されている出力管理システム・コンポーネントに転送することと、 ソース・データと選択された出力デバイスに対応する出力イメージ・データを描画することと、 出力イメージ・データを出力デバイスにサブミットし、出力デバイスにより物理的に描画することを含む方法。
- 14ファイヤウォールの外側および背後に配置されている各出力管理システム・コンポーネントは、出力管理システム内の他のコンポーネント管理機能を備えるメッセージ・センター・コンポーネントを含む請求項13に記載の方法。
- 15さらに、ファイヤウォールの背後に配置されている出力管理システム・コンポーネントを介してアクセスできるファイヤウォールの背後に配置されている1つまたは複数の出力デバイスを識別するパススルー通信リンクを使用し、ファイヤウォールの背後に配置されている出力管理システム・コンポーネントからデータをファイヤウォールの外側にある出力管理システム・コンポーネントに送信することを含む請求項13に記載の方法。
- 16ファイヤウォールの内側に配置されている出力管理システム・コンポーネントがサーバ・コンポーネントを含み、出力イメージ・データを出力デバイスにサブミットすることが出力イメージ・データをクライアントに供給することを含み、出力イメージ・データを受信したことに対する応答として、クライアントは出力イメージ・データを描画のため出力イメージ・デバイスにサブミットする請求項13に記載の方法。
- 17発信元デバイスはWeb対応無線デバイスを含む請求項13に記載の方法。
- 18発信元デバイスはBluetooth対応デバイスを含む請求項13に記載の方法。
- 19ソース・データには発信元デバイス上に格納されているドキュメントが含まれ、さらに、ファイヤウォールの外側にある出力管理システム・コンポーネントで発信元デバイスからのソース・データを受信することを含む請求項13に記載の方法。
- 20ソース・データは、リモート・ストアに格納され、さらにリモート・ストアからソース・データを検索することを含む請求項13に記載の方法。
- 21リモート・ストアは、プライベート・ネットワーク上に配置されており、ソース・データは、ソース・データへの参照により識別された場所から検索される請求項20に記載の方法。
- 22さらに、ユーザ・インターフェイスを介してジョブ・ステータス情報をユーザに提供することを含む請求項13に記載の方法。
- 23印刷サービスを使用し、 ソース・データのファイル・タイプを判別するオペレーションと、 プリント・サーバを介してロードし、出力イメージ・データを生成するのに適したアプリケーションを判別するオペレーションと、 アプリケーションと印刷サブシステムを組み合わせて出力イメージ・データを生成させる印刷アクションを開始するオペレーションを実行することにより出力イメージ・データを生成する請求項13に記載の方法。
- 24さらに、ユーザ・インターフェイス上に描画するときに、出力デバイスにより生成される描画された出力のシミュレート表現を含む印刷プレビュー・データを無線デバイスに供給することを含む請求項13に記載の方法。
- 25ファイヤウォールの外側にある発信元デバイスからファイヤウォールの背後にあるプライベート・ネットワーク上で印刷する方法であって、 発信元デバイスとファイヤウォールの背後に配置されている出力管理システム・コンポーネントとの間の、ファイヤウォールを通過する仮想プライベート・ネットワーク(VPN)トンネルを備える通信リンクを確立することと、 描画可能なデータを発信元デバイスに供給し、それによりユーザ・インターフェイスを発信元デバイス上に描画することと、 ユーザがユーザ・インターフェイスを介して印刷するソース・データを選択できるようにすることと、 ユーザがソース・データの印刷先のプライベート・ネットワーク上の出力デバイスを選択できるようにすることと、 VPNトンネルを介して発信元デバイスからソース・データまたはそのデータの参照をファイヤウォールの背後に配置されている出力管理システム・コンポーネントに転送することと、 ソース・データと選択された出力デバイスに対応する出力イメージ・データを描画することと、 出力イメージ・データを出力デバイスにサブミットし、出力デバイスにより物理的に描画することを含む方法。
- 26ユーザ・インターフェイスは、複数の対話型Webページを備え、VPNトンネルは、ファイヤウォールに配置されているVPNスイッチと組み合わせてファイヤウォールの外側に配置されている共通ゲートウェイ・インターフェイス(CGI)VPNプロキシにより円滑に使用できる請求項25に記載の方法。
- 27発信元デバイスは、VPN対応デバイスを備え、VPNトンネルは、そのVPN対応デバイスとファイヤウォールに配置されているVPNスイッチ上で実行されるクライアント・サイド・コンポーネントにより円滑に使用できる請求項25に記載の方法。
- 28ファイヤウォールの背後に配置されている出力管理システム・コンポーネントは、サーバ・コンポーネントを含み、出力イメージ・データを出力デバイスにサブミットすることは、出力イメージ・データをクライアントに供給することを含み、出力イメージ・データを受信したことに対する応答として、クライアントは出力イメージ・データを描画のため出力イメージ・デバイスにサブミットする請求項25に記載の方法。
- 29発信元デバイスはWeb対応無線デバイスを含む請求項25に記載の方法。
- 30発信元デバイスはBluetooth対応デバイスを含む請求項25に記載の方法。
- 31ソース・データには発信元デバイス上に格納されているドキュメントが含まれ、さらに、ファイヤウォールの背後にある出力管理システム・コンポーネントでVPNトンネルを介して発信元デバイスからソース・データを受信することを含む請求項25に記載の方法。
- 32ソース・データは、リモート・ストアに格納され、さらにリモート・ストアからソース・データを検索することを含む請求項31に記載の方法。
- 33リモート・ストアがプライベート・ネットワーク上に配置されており、ソース・データがソース・データの参照により識別された場所から検索される請求項32に記載の方法。
- 34さらに、ユーザ・インターフェイスを介してジョブ・ステータス情報をユーザに提供することを含む請求項25に記載の方法。
- 35印刷サービスを使用し、 ソース・データのファイル・タイプを判別するオペレーションと、 プリント・サーバを介してロードし、出力イメージ・データを生成するのに適したアプリケーションを判別するオペレーションと、 アプリケーションと印刷サブシステムを組み合わせて出力イメージ・データを生成させる印刷アクションを開始するオペレーションを実行することにより出力イメージ・データを生成する請求項25に記載の方法。
- 36さらに、ユーザ・インターフェイス上に描画するときに、出力デバイスにより生成される描画された出力のシミュレート表現を含む印刷プレビュー・データを無線デバイスに供給することを含む請求項25に記載の方法。
- 37ファイヤウォールの外側に配置されている発信元デバイスからファイヤウォールの背後に配備されているプライベート・ネットワークに接続されている送り先出力デバイスで印刷を可能にする出力管理システムであって、 入力ソース・データおよび送り先出力デバイスに対応する出力イメージ・データを生成する印刷サービスと、 ファイヤウォールの外側に配置された、印刷サービスと通信するようにリンクされているメッセージ・センターであって、 描画可能データを供給し、これによりユーザ・インターフェイス(UI)をWebサーバ・コンポーネントと通信して動作するようにリンクされている発信元デバイス上に描画し、ユーザが描画するソース・データを選択して、送り先出力デバイス上にソース・データを描画するジョブ要求をサブミットできるようにするWebサーバ・コンポーネントと、 プライベート・ネットワーク上に配備され、ファイヤウォールを通るリンクを介してメッセージ・センターと通信するようにリンクされているクライアント・サイド・コンポーネントとを含むメッセージ・センターを備え、 メッセージ・センターはさらに、Webサーバ・コンポーネントから受信したジョブ要求を管理し、その受信に対する応答として、 選択したソース・データまたはそのデータへの参照を印刷サービスに送る経路を選択し、 印刷サービスにより生成された出力イメージ・データを送信先のプリンタに配信するのを制御するシステム管理コンポーネントを備える出力管理システム。
- 38クライアント・サイド・コンポーネントはさらに、そのサービスを介してアクセスできる出力デバイスをメッセージ・センターに登録するオペレーションを実行する請求項37に記載の出力管理システム。
- 39クライアント・サイド・コンポーネントとメッセージ・センターとの間のファイヤウォールを通るリンクは永続的接続を含む請求項37に記載の出力管理システム。
- 40さらに、出力デバイスにサブミットする前に出力イメージ・データを格納できる出力リポジトリを備える請求項37に記載の出力管理システム。
- 41ユーザ・インターフェイスは、無線Web対応デバイスを介してアクセスできる無線Webユーザ・インターフェイスを含む請求項37に記載の出力管理システム。
- 42さらに、メッセージ・センターと通信するようにリンクされている無線データ・アクセス・ポイント(WDAP)を備える請求項37に記載の出力管理システム。
- 43さらに、WDAPに動作するように結合されているBluetoothデバイス・エミュレータを備え、Bluetooth対応無線デバイスでシステムにアクセスすることができる請求項42に記載の出力管理システム。
- 44ユーザ・インターフェイスは、Bluetoothプロトコル上のWAP(無線アプリケーション・プロトコル)を使用して提供される請求項43に記載の出力管理システム。
- 45印刷サービスは、 ソース・データのファイル・タイプを判別するオペレーションと、 プリント・サーバを介してロードし、出力イメージ・データを生成するのに適したアプリケーションを判別するオペレーションと、 アプリケーションと印刷サブシステムを組み合わせて出力イメージ・データを生成させる印刷アクションを開始するオペレーションとを実行することにより出力イメージ・データを生成する請求項37に記載の出力管理システム。
- 46さらにユーザ・インターフェイスにより、ソース・データが描画される出力デバイスをユーザが選択できる請求項37に記載の出力管理システム。
- 47さらに、ユーザ・プロファイルおよびシステム・リソース情報が格納されるデータベース・サーバを備える請求項37に記載の出力管理システム。
- 48ユーザ・インターフェイスを使用することによりユーザは出力管理システムを介してアクセス可能な出力デバイスから1つまたは複数のお気に入りの出力デバイスを選択し、かつ/または指定することができ、ユーザにより選択され、かつ/または指定された出力デバイスに関係するデータは、データベース・サーバにより格納される請求項47に記載の出力管理システム。
- 49メッセージ・センターは、ルート・メッセージ・センターを含み、クライアント・サイド・コンポーネントは、第2のメッセージ・センターを含み、メッセージ・センター階層内のルート・メッセージ・センターの下に入れ子になっている請求項37に記載の出力管理システム。
- 50印刷サービスは、ファイヤウォールの背後に配備される請求項37に記載の出力管理システム。
- 51印刷サービスおよびクライアント・サイド・コンポーネントは、単一マシンをホストとする請求項37に記載の出力管理システム。
- 52印刷サービスはファイヤウォールの外側に配備され、クライアント・サイド・コンポーネントはメッセージ・センターを介してイメージ出力ダメージを受け取るリモート・デスクトップ・クライアントを含み、イメージ出力ダメージを描画のため送り先出力デバイスにサブミットする請求項37に記載の出力管理システム。
- 53さらに、印刷サービスは、ユーザ・インターフェイス上に描画するときに、出力デバイスにより生成される描画された出力のシミュレート表現を含む印刷プレビュー・データを無線デバイスに供給する請求項37に記載の出力管理システム。
- 54ファイヤウォールの外側に配置されている発信元デバイスからファイヤウォールの背後に配備されているプライベート・ネットワークに接続されている送り先出力デバイスで印刷を可能にする出力管理システムであって、 入力ソース・データおよび送り先出力デバイスに対応する出力イメージ・データを生成する印刷サービスと、 ファイヤウォールの内側に配置された、印刷サービスと通信するようにリンクされているメッセージ・センターであって、 描画可能データを供給し、これによりユーザ・インターフェイス(UI)をセキュリティ保護されたリンクを介してWebサーバ・コンポーネントと通信して動作するようにリンクされている発信元デバイス上に描画し、ユーザが描画するソース・データを選択して、送り先出力デバイス上にソース・データを描画するジョブ要求をサブミットできるようにするWebサーバ・コンポーネントと、 Webサーバ・コンポーネントから受信したジョブ要求を管理するシステム管理コンポーネントとを含み、その受信に対する応答として、 選択したソース・データまたはそのデータへの参照を印刷サービスに送る経路を選択し、 印刷サービスにより生成された出力イメージ・データを送信先のプリンタに配信するのを制御するメッセージ・センターを備える出力管理システム。
- 55さらに、ファイヤウォールとともに配備されている仮想プライベート・ネットワーク(VPN)スイッチを備え、VPN符号化データがファイヤウォールを通ることができ、またこのデータをメッセージ・センターが受信できる請求項53に記載の出力管理システム。
- 56さらに、ファイヤウォールの外側に配備されている共通ゲートウェイ・インターフェイス(CGI)VPNプロキシを備え、ユーザ・インターフェイスを介しVPN非対応発信元デバイスから受信したデータを符号化してVPN符号化データにし、それにより、VPN非対応無線デバイスとメッセージ・センターとの間のセキュリティ保護された接続を実現する請求項19に記載の出力管理システム。
- 57出力デバイスは、無線デバイスにより直接はアクセスできないプライベート・ネットワーク上に配備される請求項1に記載の出力管理システム。
- 58出力管理システムであって、 描画可能データを供給し、それによりユーザ・インターフェイス(UI)を少なくとも1つのWebサーバと通信し動作するようにリンクされている発信元デバイス上に描画し、前記ユーザ・インターフェイスにより、ユーザが、描画するソース・データを選択し、送り先出力デバイスにソース・データを描画するジョブ要求をサブミットすることができるように構成されているソフトウェアを実行する少なくとも1つのWebサーバを含むWebサーバ層と、 入力ソース・データおよび入力ソース・データを描画する出力デバイスに対応する出力イメージ・データを生成する印刷サービスを実行するソフトウェアを実行する少なくとも1つの印刷サービス・サーバを備える印刷サービス層と、 ジョブ要求を管理し、それに対する応答として、 選択したソース・データまたはそのデータへの参照を印刷サービス層に送る経路を選択し、 印刷サービスにより生成された出力イメージ・データを描画のため送り先出力デバイスにサブミットするのを管理するように構成されているソフトウェアを実行する少なくとも1つのメッセージ・センター・サーバを備えるメッセージ・センター層を備え、 印刷サービス層とメッセージ・サービス層内のサーバからの少なくとも1つのサーバがプライベート・ネットワーク上のファイヤウォールの背後に配置されている出力管理システム。
- 59さらに、少なくとも1つのデータベースのホストとなる少なくとも1つのデータベース・サーバを含むデータベース層を備え、前記データベース層は、システム管理およびジョブ要求データを含むシステム・データを格納する請求項57に記載の出力管理システム。
- 60データベース層は、システム管理およびジョブ要求データが格納されるメッセージ・センター・データベースおよび印刷サービスに関係するデータが格納される印刷サービス・データベースを含む請求項58に記載の出力管理システム。
- 61さらに、データベース層は、送り先出力デバイスにサブミットする前に出力イメージ・データを格納できる出力イメージ・ストアを備える請求項57に記載の出力管理システム。
- 62Webサーバ層は、複数のWebサーバを備え、さらに、複数のWebサーバの間で着信接続の負荷を分散するロード・バランサーを備える請求項57に記載の出力管理システム。
- 63印刷サービス層は、複数の印刷サービス・サーバをホストとし、さらに、複数のWebサーバの間で着信印刷サービス要求の負荷を分散するロード・バランサーを備える請求項57に記載の出力管理システム。
- 64さらに、メッセージ・センター層と通信するようにリンクされている、リモート・デスクトップ・クライアントを備え、出力イメージ・データをメッセージ・センター層から受信した出力デバイス・サブミット・コマンドによって指定された送り先出力デバイスに供給する請求項57に記載の出力管理システム。
- 65ユーザ・インターフェイスは、無線Web対応デバイスを介してアクセスできる無線Webユーザ・インターフェイスを含む請求項57に記載の出力管理システム。
- 66印刷サービスは、 ソース・データのファイル・タイプを判別するオペレーションと、 プリント・サーバを介してロードし、出力イメージ・データを生成するのに適したアプリケーションを判別するオペレーションと、 アプリケーションと印刷サブシステムを組み合わせて出力イメージ・データを生成させる印刷アクションを開始するオペレーションとを実行することにより出力イメージ・データを生成する請求項57に記載の出力管理システム。
- 67さらに、印刷サービスは、ユーザ・インターフェイス上に描画するときに、送り先出力デバイスにより生成される描画された出力のシミュレート表現を含む印刷プレビュー・データを無線デバイスに供給する請求項57に記載の出力管理システム。
Independent claims67
289 paragraphs, as filed
Related application
This application is a simultaneous pending provisional title "METHOD AND APPARATUS FOR WIRELESS DOCUMENT PRINTING, VIEWING AND SHARING" filed on August 22, 2001, in which the benefit of the filing date is claimed in accordance with 35 USC § 119 (e). Application No. 60 / 314,412 and co-pending provisional application No. 60 / 351,754 entitled "METHOD AND SYSTEM FOR PRINTING AND FORMATTING DOCUMENTS AND OUTPUT RESOURCE MANAGEMENT FROM MOBILE DEVICES" filed on January 23, 2002. , And the "UNIVERSAL PRINTING AND DOCUMENT IMAGING SYSTEM AND" filed on March 13, 2002, in which the benefit of the filing date is claimed in accordance with 35 USC §120. Simultaneous pending non-provisional application No. 10 / 098,832 entitled "METHOD" and co-pending non-provisional application No. 10 / entitled "METHOD AND SYSTEM TO PRINT VIA E-MAIL" filed on March 21, 2002. Based on No. 104,528. In addition, all specifications and drawings of each co-pending non-provisional application are incorporated herein by reference.
The field of the present invention generally relates to network printing environments, and more specifically, but not limited to, mobile network printing environments and management of output requirements.
In a traditional printing environment, a user operating a computer that is interconnected via a closed computer network, such as a local area network (LAN), can view the document generated by the application running on that computer. , Printers, plotters, and other output devices connected to the network. In today's rapidly evolving mobile business environment, such restricted printing solutions are no longer satisfactory. Traditional printing techniques have certainly evolved with the goal of delivering high resolution, superior print quality, and color documents at high speeds, but have neglected to develop printing techniques suitable for today's mobile workers. Was there.
<p> In today's mobile business environment, there are many scenarios that the developers of traditional printing environments didn't even think about or deal with about printing. For example, consider the following situation. Can a business developer submit the required contracts stored on his company's home network to a printer in the other's network while preparing to talk about commerce in the other's office? Can a salesperson on a business trip easily print a presentation slide to a nearby printer without having the document for his presentation slide at hand? Can a user of a Bluetooth handset enter the room, find out that there is a Bluetooth-enabled printer, and print a document with a nearby printer, even if the printer is not Bluetooth-enabled? Can instant messaging users drag and drop a document onto a companion printer list to print the document? Can investors print the required documents at headquarters using only their mobile phones while at the airport? It would be convenient to provide a printing solution for these situations and other similar scenarios.</p>
<p> According to aspects of the present invention, there are disclosed systems and methods for managing output such as printing, faxing, and e-mail on various types of computer networks. In one aspect, the system and methods allow access to print and / or document resources located on the private network behind the firewall. Establish a communication link through the firewall between system components located on either side of the firewall. Drawable data provided by the system to the source device, such as a wired computer or wireless device, is provided to draw the user interface on the source device. This user interface allows you to select the source data and the output device to print this source data, either or both of which may be behind the firewall. After making your selection, retrieve the source data (possibly from your private network) and transfer it to a printing service that draws the output image data depending on the source data and the selected output device. The output image data is submitted to the output device and physically rendered. Use pass-through communication links to access private resources. In addition, the system can also print documents by reference.</p><p> Many of the above aspects of the invention and the resulting advantages are by reference to the following detailed description with respect to the accompanying drawings in which similar reference numbers refer to similar parts throughout the drawings unless otherwise noted. It will be obvious because it is easy to understand.</p>
Here, an embodiment of an output management system and a method for realizing a printing solution for mobile users and terrestrial line users will be described. In the following description, many specific details such as an architecture implementation example will be described so that the embodiment of the present invention can be fully understood. However, one of ordinary skill in the art understands that the present invention can be carried out even if one or more specific details are not taken up, or even if other methods, components, materials, etc. are used. Will do. In other examples, well-known structures, materials, or operations are not detailed or described in order not to obscure aspects of the invention.
When referred to as "one embodiment" or "embodiment" throughout this specification, the particular function, structure, or property described in connection with that embodiment is included in at least one embodiment of the invention. Is done. Therefore, the appearance of the phrase "in one embodiment" or "in an embodiment" throughout the specification does not necessarily refer to the same embodiment. In addition, specific functions, structures, or properties can be combined in one or more embodiments in a suitable manner.
The following terms and their definitions are frequently used throughout the discussion that follows.
Source data: Source data refers to a document or medium that can be retrieved and output to the device. The supported input data formats are not limited to the following, but most of the types supported by the document processor (eg PDF, PostScript, Microsoft Word, ASCII text, etc.), Web URL links, email, and I have an email attachment.
Remote store: A remote store contains a local area network (LAN) or a remote location on the Internet where source data is stored. Remote stores include, but are not limited to, FTP content servers, NFS file servers, PC NFS file servers, and web servers.
Local Source: A local source contains source data stored on the same user device as the issuer of the print request. Therefore, when printing from a local source, the source data must be uploaded from the user's device to the output management system for processing.
<u style="single">Remote source</u>: Remote source contains source data stored on the remote store.
<u style="single">Outgoing device</u>: A wireless or wired device from which the user requests a job.
<u style="single">Output device</u>: The output device is equipped with a device that obtains output image data from the system and converts it into a specific format for display or recording. Supported output devices include, but are not limited to, printers, fax machines, remote document repositories, and e-mail destinations. These output devices can be placed on a LAN, but they can also be placed on an external network, including networks accessible to the general public, such as the Internet and private networks.
<u style="single">Job request</u>: A job request is a request that the user submits to be processed by the system and sent to the output device.
<u style="single">Job status</u>: This is the status of the job request, which indicates the current progress of request processing. This is a mechanism to help users understand the status of job requests and to help system administrators manage them.
<u style="single">Print by Reference (PBR)</u>: This job processing method requires the system to retrieve source data from a remote source rather than from a local source.
<u style="single">Delayed printing</u>: Defined as delaying the output of processed job requests, the final stage of job processing, when the destination output device is currently unavailable.
<u style="single">User database</u>: A system database used to track each user's system configuration settings.
<u style="single">server</u>: A computer running software that is accessible on the network.
<u style="single">Web server</u>: Hypertext Markup Language (HTML) files and common gateway interface (CGI) data using Hypertext Transfer Protocol (HTTP) or Secure HTTP (HTTPS) between the client and server computers A software program running on a computer or server that communicates with a client computer that transmits data files.
<u style="single">Windows® Printer</u>: In the Microsoft Windows operating system, a "printer" is defined as a named combination of printer driver, print processor, language monitor, and port monitor.
<u style="single">Spool file</u>: A printer language file created by the MS Windows printer driver. The contents of this file can be sent directly to the printer for printing.
<u style="single">Internet Printing Protocol (IPP)</u>: An HTTP-like protocol for sending spooled files to networked printers and getting print job status from networked printers.
<u style="single">Line Printer Remote (LPR)</u>: A protocol for submitting spooled files to networked printers.
<u style="single">zone</u>: The network that surrounds the autonomous output management system. Zones usually contain a logical representation of a network domain.
By using various embodiments of the invention described herein, a wireless or wired user can retrieve source data from a local or remote source and send the source data to a destination. You can request output to a selected output device, also known as an output device or destination output device. In general, the output device can be located on the same network as the source device (that is, the device that issued the output request), and, as is often the case, another network, such as a network where the source device is normally inaccessible. It can also be placed on the network.
At the top, the operations and functions of the embodiments of the output management system of the invention described herein are Message Center (MC), Print Service (PS), Remote Desktop Client (RDC), Wireless. It is available to users of the four key components of the Data Access Point (WDAP). Practical implementations typically use different combinations of these components, depending on the specific requirements of the implementation.
The message center is the heart of the system. It interfaces with the rest of the components in the system to ensure proper functioning of the entire system. As shown in FIG. 1, in one embodiment, the message center MCn has 12 main tasks: component registration and deregistration 10, job request reception 12, job request processing 14, job output scheduling and queue. Interface 16, Job Output Status Monitoring 18, Peer Message Center Interaction 20, Root Level Message Center Interaction 22, Remote Desktop Client Management 24, Print Service Management 26, Wireless Data Access Point Management 28 , Perform user profile management 30, user interface management 32.
The print service component handles the drawing and printing of job requests. As shown in FIG. 2, in one embodiment, the print service PSn "draws the output image" 34, "stores the output image in the repository" 36, "sends the output image to the local device" 38, Perform print service tasks such as Send Job Output Status to Message Center 40, Local Output Device Management 42.
You can use the Remote Desktop Client component to connect remote devices to the entire system. As shown in FIG. 3, in one embodiment, the remote desktop client RDCn has three main tasks: "register and unregister output device" 44, "receive output request from message center". 46, "Return job output status to message center" 48 is executed.
The wireless data access point component allows wireless users to connect to the system using standard wireless protocols such as Bluetooth and IEEE 802.11. The message center can also manage resource mappings for wireless access. As shown in FIG. 4, in one embodiment, the WDAPn performs five main tasks: "register and unregister components" 50, "receive device connection request" 52, "from the user's wireless device". Execute "Relay Request" 54, "Relay System Response to User's Wireless Device" 56, and "Record Output Device Geographical Relationship" 58.
In summary, in each aspect of the invention of the embodiments of the output management system described herein, 1) device resource management, 2) device resource discovery, 3) job request management, 4) job request scheduling. , 5) Job request monitoring, 6) User profile management, 7) User mobile sign-in operations. In the following, an outline of each embodiment will be briefly described together with details described by using the system examples described below.
The device resource management system manages device resources so that output devices can be easily and quickly identified. In one embodiment, these devices are divided into physical output devices and logical output devices. Physical output devices include, but are not limited to, printers, fax machines, copiers, and the like. Logical output devices include, but are not limited to, file servers, print servers, FTP repositories, and e-mail destinations. A list of related operations is shown below.
<u style="single">Facilitate resource management and sharing with hierarchical root message centers, public and private device classifications</u>: The system uses a database to record the relationships between each message center. The message center ID (MCID) of the root message center is equal to 0, and all other message center MCID values are non-zero positive integers. The root message center table holds information that identifies the zones and network addresses of other message centers. The local message center must register with the root message center to announce public resource information for resource sharing. All private device resources are considered private and cannot be shared outside the zone in which they are located.
<u style="single">Device management using local and remote client registration mechanisms</u>: The associated print service registers the connected output device with the message center, and similarly, the associated remote desktop client registers its directly connected output device with the message center. Use the corresponding print service or remote desktop client to reference these output devices. Depending on the specific security requirements of your implementation, it is wise to use encryption to ensure data security and data integrity for print services and remote desktop clients in your system, if necessary. It appears to be.
<u style="single">Device management using the World Wide Web and mobile device interface</u>: This system has a set of management interfaces as well as a simple mobile management interface for device management.
<u style="single">Remote device installation using centralized driver store</u>: After registering the output device, the corresponding driver must be installed in the print service associated with the output device. The Message Center has an array of commonly used drivers in the driver store, eliminating the need to transfer drivers to print service components on the device side. However, if the driver is not currently available from the MC driver store, it can be transferred to the driver store and then installed in the print service.
Device Resource Discovery The book allows users to identify output devices in a mobile computing environment. As described in detail below, one embodiment uses Bluetooth and IEEE 802.11 technologies for device discovery. It can also be used to allow non-Bluetooth devices to operate as if they were Bluetooth devices through a Bluetooth device emulator. A list of related operations is shown below.
<u style="single">Discover output devices via Bluetooth connection and register with Message Center</u>: This is done by running an agent on the wireless data access point (WDAP) to interface with the message center to get output device information. In addition, the agent works with the Message Center to maintain a database of output device information running on WDAP.
<u style="single">Local generic output device availability announcement to Bluetooth clients via Bluetooth gateway</u>: Allows the Message Center to manage the information it receives through WDAP by deploying an optional Bluetooth gateway. Announce this information, including the availability of output devices, to wireless users when connecting to the network through a registered WDAP. For mobile users, this information is updated by the system as the user travels through the network and connects to different WDAPs.
<u style="single">Output device discovery and registration through 802.11 gateway</u>: It is done by running an agent on the wireless data access point (WDAP) to interface with the message center to get the output device information in the same way as used for the Bluetooth connection.
<u style="single">Output device availability announcement via IP broadcast</u>: Allows the message center to manage the information received through WDAP by deploying an optional 802.11 gateway in the system. Announce this information, including output device availability, to 802.11 authenticated users when entering the network through a registered WDAP. This information is updated by the system as users move through the network and connect to different WDAPs.
<u style="single">Local output device availability announcement via instant messaging interface</u>: Remote Desktop Client can be extended to support device management through instant messaging (IM) protocols (eg AOL Instant Messaging, Yahoo messaging, MSN messaging, ICQ, etc.). The idea of this messaging is to allow other messenger users (eg, peers) to see and share their output resources. For example, with this feature, IM users can simply drag and drop files onto a shared device on their peer's output device list, and the output corresponding to those files will be on a device that their peers can easily access. Can be output.
<u style="single">Default output device allocation based on output resource discovery</u>: There are two types of default output devices, one is the static default output device and the other is the dynamic default output device. Users can change the static default output device by modifying their profile settings via a graphical user interface (GUI). However, only the system updates the dynamic default output device when the user uses the mobile device to access the system. In any case, the user can either turn off dynamic overwrite or always specify the output device destination in a way that modifies the user's profile settings.
Job request management This system implements a request queue to manage job requests. A list of related operations is shown below.
<u style="single">Managing job requests for output devices using Remote Desktop Client</u>: Job requests to destination output devices are channeled through the remote desktop client. This RDC allows the output device to retrieve the output data and send the status back to the message center. The same RDC can implement cryptography to protect the output data exchanged between the message center and the RDC.
<u style="single">Job submit via instant messaging interface</u>: You can modify the Remote Desktop client to support job submitting through instant messaging protocols (eg AOL Instant Messaging, Yahoo messaging, MSN messaging, ICQ, etc.). Using this mechanism, users can drag and drop files onto devices on their companion shared output device list. The companion then receives the output data from that device. The modified RDC must be registered with the Message Center (eg, AOL-owned, Yahoo-owned, corporate-owned, or root MC). If successful, you will see the output management interface on the instant messaging UI. If the user's companion is also running an RDC that has been tweaked for that instant messaging tool, the user's resource information is transferred to the connected companion through the instant messaging protocol. You can drag and drop documents onto your fellow shared output devices.
<u style="single">Receiving job print requests through the instant messaging interface</u>: The Remote Desktop client can be modified to support job reception through the instant messaging protocol. When the sender drags and drops the output data onto a device on the recipient's shared output device list, the job request is sent to the recipient's RDC for printing. The modified RDC must be registered with the Message Center as before. If successful, you will see the output management interface on the instant messaging UI. If the user's companion is also running an RDC that has been tweaked for that instant messaging tool, the user's resource information is transferred to the connected companion through the instant messaging protocol. The user can receive job requests from other registered users.
<u style="single">Interface with multimedia messaging system</u>: The Message Center can deploy inbound and outbound gateways that interface with most multimedia messaging systems. This deployment allows general purpose multimedia clients to communicate with output management system driven clients, exchange information, and request output to shared devices and destinations.
<u style="single">Job submit by Bluetooth connection to general-purpose output device</u>: WDAP with Bluetooth device emulator allows users to access the system's submit interface through a Bluetooth connection. Upon request, information about output device availability, including Bluetooth and general purpose output devices, is returned to the user. The user can then send the output to the selected destination output device via a Bluetooth connection.
<u style="single">Job request drawing by dedicated server</u>: In this system, the print service is used as a dedicated job drawing server. This saves you from having to install too many device drivers that you don't need on your client machine. With Remote Desktop Client, you can output jobs drawn thousands of miles away to your local device and vice versa.
<u style="single">Personal and business job requirements classification</u>: The current corporate printing environment makes no distinction between personal print job requests and business requests. On the other hand, this system implements a method of classifying job requests, tags the requests in the database, and retains information for accounting purposes. Therefore, the accounting department can bill the department or employee based on the job characteristics defined in the job request.
<u style="single">Guest printing support</u>: The system can be configured to support guest printing. This is done through the guest job submit interface hosted in the message center. This interface does not force user profile validation, but rather only allows restricted access to public output resources. The administrator can configure the Message Center to still support dynamic default printers for guest printing.
<u style="single">Email job request support</u>: This system accepts e-mail as a general job request with or without attachments. Requests can be processed with or without attachments to multiple output channels.
<u style="single">Document preview</u>: The system supports document preview, so users can visually check (for example, whether the document version is correct) before issuing the final output request. This document preview feature allows users to quickly view images in dithered thumbnails and other files in plain text format with page references saved. Spreadsheet software also has both vertical and horizontal navigation functions. In addition, the preview document preserves the relationships between the pages of the original document, allowing the user to preview the document with random access.
The job request scheduling system implements a request queue to manage job requests. A list of related operations is shown below.
<u style="single">Deferred job scheduling</u>: When a job request enters the message center, a job queue entry is inserted into the message center database to hold enough information to process the job. If the destination output device is not available, the system keeps its entry in the queue and later reschedules it to submit when the output device becomes available (using an administrator-configurable delay value). hand).
<u style="single">Output using file references in the job spooling factory</u>: In this system, the output image is drawn using the print service. Since the print service and message center are generally not located in the same location on the same host machine, the drawing data must be transferred from the print service to the message center for final processing. For efficiency, the print service stores the drawing image in a shared spooling factory (that is, a repository) and returns an image reference to the message center. The Message Center then uses this reference to output the data to the destination.
<u style="single">Secure output over firewall</u>: Since this system has a modular design, it is possible to customize the configuration of each component. The administrator can install a firewall to protect the system. The Remote Desktop client has the ability to interface with the Message Center when the firewall is properly configured. Therefore, the document can be printed through the firewall.
Job request monitoring This system implements the job status monitoring function via the job queue log tracking function. A list of related operations is shown below.
<u style="single">Job status monitoring through job persistence tracking using database updates</u>: The message center maintains a persistent state for each job request. When a job output request is sent, a table update handler monitors the job status to determine if the output request is complete. If complete, update the database and return the status to the user.
<u style="single">Job output status report via WAP push</u>: When the job request is completed, the job status in the database is updated. The Message Center then notifies the user that the job has been completed via WAP Push if the job source is a WAP client.
<u style="single">Job output status report via HTTP browser update</u>: When the job request is completed, the job status in the database is updated. The Message Center then notifies the user that it is complete. For HTTP job submit clients, the job state is updated by automatic browser updates until the state is marked as complete.
Output creation This system implements a print service for output creation. Below is a list of related operations performed by the print service.
<u style="single">Dynamic selection of output drawing application based on input file format and configurable system settings</u>: The application used to draw the output file image can be prioritized based on the format of the input file. The priority can be adjusted by changing the system configuration settings.
<u style="single">Using third-party applications for drawing output files and images</u>: The system can also use third party applications to draw the output image.
<u style="single">Support for multiple output drawing algorithms</u>: The system uses different methods to generate an output image, depending on the specific characteristics of the input document. You can use background services with print tools and printer drivers, use foreground keystroke simulation with application control handlers, and use translators to do the drawing.
<u style="single">Support for multiple output channels</u>: The system supports multiple output channels, including but not limited to printing to printer channels, sending faxes to fax recipients, previewing output images on the originating device, and sending outputs to email destinations. To do. If the email destination output channel is selected, the document can be included in the body of the email or sent as an attachment.
<u style="single">Window handler that increases the reliability of the entire system</u>: The system uses window handlers to handle various pop-up dialog boxes that appear when using the foreground output drawing option. As a result, the system can be operated in a completely unmanned state for a long period of time.
User Profile Management This system allows users to manage their personal profiles using the web or mobile device interface. A list of related operations is shown below.
<u style="single">User profile management and dynamic updates via web and mobile device interfaces</u>: The message center used to store subscription information creates and maintains user profiles. Users can change their configuration settings using the WEB (HTML) or WAP (WML) interface, if desired. In addition, if the user is currently using a mobile device to access a system in the user's home network, the system will automatically update the user's dynamic default printer.
<u style="single">Support for multiple user profile billing records</u>: The user profile contains multiple billing IDs for the system to tag different types of billing. For example, a user can have both a personal print account and a business print account. This allows organizations to incorporate output management systems into billing systems relatively easily.
User Mobile Sign-In This system allows users to sign on to a local network via a wireless data access point (WDAP). The locally shared resource will then be available to the user. A list of related operations is shown below.
<u style="single">User authentication by validating query results from mobile devices</u>: The system looks up the unique identifier of the query result and checks if it is valid against the user's profile. You can then send a customized greeting based on the user's identity.
<u style="single">Allow mobile users access to system resources</u>: The wireless data access point component allows wireless users to access the network over a wireless connection (eg Bluetooth, 802.11). WDAP also supports dynamic default printer management.
System Configuration Example A simple system configuration example 59 is shown in Figure 5. In this example, the systems are deployed in two zones, Zone 0 and Zone 1, and are linked by communication over the Internet 60. Zone 0 contains the root message center MC0, which manages all shared public output resources. Zone 0 can also contain an optional firewall 61. Zone 1 contains two message centers, MC1 and MC2. The message center MC1 is located behind the internal firewall 62 and is private. Message Center MC2 is located in the network DMZ (demilitarized zone) between firewalls 63 and 64 and is public. The printer service PS1 is also public, but so is the remote desktop client RDC1. Output devices D1 and D2 are also both public.
In Figure 5 and the system configuration diagram below, the solid line indicates that there is a direct link between the connected entities, and the dashed line indicates that the connection of the entities is not a direct link but a logical association (eg, registration). It is shown that it is due to). For example, output device D1 is directly linked to print service PS1 via direct link 66, and output device D2 is logically associated with remote desktop client RDC1 as shown in logical association 68. ing.
In some configurations, the firewall ports allow users to access the Message Center MC2 and the Message Center MC2 to access the print service PS1, Remote Desktop Client RDC1, and Output Devices D1 and D2. You need to open 80 (for example, for processing CGI calls by Apache Web Services) and port 5190 (for instant messaging and system communication ports). If SSL (Secure Socket Layer) is required, the firewall will also need to open port 443. Note that the wireless data access point WDAP1 is located behind the internal firewall 60 for security reasons, blocking external wireless users from the internal network.
A more complex system configuration example 70 is shown in Figure 6. In this example, the system has three zones, Zone 0, Zone 1, and Zone 2. Zone 0 contains the root message center MC0, which manages all shared public output resources. Zones 1 and 2 are private zones and can contain both public and private resources. Zone 1 consists of one public message center MC1, two private print services PS1 and PS2, two private WDAPs (WDAP1, WDAP2), one public remote desktop client RDC2, and two privates. Includes output devices D2, D3 and one public output device D4. Zone 2 consists of two public message centers MC2, MC3, two private printing services PS3, PS4, two private WDAPs (WDAP1, WDAP2), one private remote desktop client RDC5, and three. Includes three public remote desktop clients RDC3, RDC4, RDC6, three private output devices D6, D8, D9 and three public output devices D5, D7, D10. Zone 0 contains the public message center MC0, which has three message centers (MC1, MC2, MC3) registered. It also has a registered Remote Desktop Client (RDC1). Private resources within each zone (for example, output devices D2, D3, D8 and remote desktop client RDC5) are not shared outside the zone. The message center that manages public resources is registered with the root message center MC0 so that it can be accessed via public requests.
Message Center MC0 is a root-level message center that contains references to registered public message centers. After installing the system, the enterprise-owned message centers (MC1, MC2) must be registered with the root message center. If you need to manage a large number of public resources, you can have multiple root message centers in your configuration. In such a case, in one embodiment, the root MC is represented by a hierarchical tree. In general, organizing a root message center in such an implementation is very flexible. Using geographic placement to illustrate one classification method, the lowest level of the tree hierarchy corresponds to a particular region (eg California, Minnesota, Taiwan, Guangdong) and is the second from the bottom. At the level, some of the regional MCs are larger regional MCs (eg US) Grouping into MCs (MCs in China), and further at the levels above the hierarchy, some of the MCs in the second level from the bottom can be grouped into larger regional MCs (eg USA, Asia, Europe). And finally, this hierarchy causes the master MC to represent the entire domain. A similar approach can be applied to businesses, individuals, and governments to set up a message center hierarchy.
The registered message center can query the root message center for public output resources. In one embodiment, the search can be based on RDC parameters, that is, the client's name, client's zip code, or the state in which the client is located. This search can also be based on zone descriptors or zone types. In addition, device resource searches can also be based on device resource names or device resource descriptions. When the zone 0 root-level message center receives a search request, it returns the identifier of the record found in its database. Subsequent search runs use those identifiers as qualifiers and return a wider range of information.
Returning to Figure 1, we will discuss the details of the Message Center component. Remote Desktop Clients and Print Services register their output resources with the Message Center, which allows access to those services through the component registration and unregistration component 10. At run time of the registration process, the output resource type (eg, printer, plotter, etc.) is determined by the corresponding type definition data. The message center collects these output resources and registers the public output resources with the root-level message center. The root message center can create a record for each registered public output device with sufficient information, and other message centers can remotely access the resource using the data contained in the record as the corresponding reference. To do so.
If the output device needs to be separated from the Message Center, send a deregistration request to the Message Center. In response, the Message Center unregisters the output device from the Root Message Center. If the output device is a public resource, the corresponding shared record in the root message center database is also deleted.
Job Request Receiving In task 12, the message center can receive job requests. In one embodiment, the message center employs an Apache web server that runs a set of CGI scripts that can be called to submit a job request. The CGI script adds the print job to the Message Center system job queue. When a job queue entry is created, the job submit is considered complete.
After the job request is submitted, the processing of the request is executed by the job request processing task 14. When a job request enters the system, the message center collects source data through a reference to the remote source on the remote store, or the submitter sends the local source to the message center. The Message Center then identifies the print service and draws the output image file that corresponds to the source data and destination output device.
After the output image file is created, the print service returns a file reference to the message center, which then calls the corresponding RDC to send the rendered image to the output device. If the RDC or destination device is not available, the print request will be delayed. The system then attempts to resend the print request to the RDC, as defined by the configurable retry duration. These operations are handled by job output scheduling and queuing task 16.
After the job output request is sent to the output device, the job status is returned to the message center via job output status monitoring task 18. The Message Center updates its status and informs the user of the current job output status. In one current implementation, the system supports DOCUMENT_DONE, INPUT_PENDING, RESOURCE_WAIT, IN_PROGRESS, COMPLETE, CANCEL_BY_USER, and ERROR as job states.
According to Peer Message Center Interaction Task 20, the system architecture allows message center peer-to-peer communication for a variety of operations. The exchange of information between peer message centers includes zone 0 lookup queries, document route selection requests, document print requests, and status replies.
Two examples of message center interactions are shown in Figures 7 and 8. The example in Figure 7 illustrates how a user requests a public device to connect to his home message center in preparation for a subsequent request to the public device. The query procedure proceeds as follows. 1. The user (U1) submits a public device connection request to the user's home message center (MC1). This public device (D2) happens to be a root message center connection device. 2. The user's home message center (MC1) sends a query to the root message center (MC0) for access to the output device. 3. The Root Message Center (MC0) locates the route to the specified output device and sends a connection request to the Remote Desktop Client (RDC1). 4. The Remote Desktop Client (RDC1) connects to the user's home MC (MC1), where the connection is established.
The example shown in Figure 8 corresponds to a peer-to-peer message center request and the procedure is as follows: 1. The user (U1) submits a public device connection request to the user's home message center (MC1). This public device (D2) happens to be registered with another peer message center (MC2). 2. The user's home message center (MC1) queries the root MC (MC0). 3. The Root Message Center (MC0) identifies the route to the specified device and sends the connection request to the destination Message Center (MC2). 4. The destination message center (MC2) accepts the inquiry from the root message center (MC0) and sends the response back to the root message center (MC0). 5. The Route Message Center (MC0) receives the "OK" response and sends the route information to the user's Home Message Center (MC1). 6. The destination message center (MC2) connects to the user's home MC (MC1), where the connection is established.
According to Root Level Message Center Interaction Task 22, the concept of a root level message center facilitates the sharing of public output resources. The root-level message center has the advantage of centralizing the location for fast lookups of public resources. To support such a mechanism, non-root level message centers interact with root level message centers not only to announce public resources, but also to other users' public resources if necessary. You also need to query for.
The Remote Desktop Client allows the Message Center to send job requests to output devices. It can also be used to configure the entire system to reduce security risks. For example, you can set up an internal RDC for a secure output device and an external RDC for a public output device. These operations are handled by Remote Desktop Client Management Task 24.
The Message Center can connect to multiple print services. The idea is to use multiple print services as a set instead of one to improve the management efficiency of the output device. Since these print services are important components for producing output images, the Message Center has a very close relationship with these print services. These exchanges are processed by the print service management task 26.
To support wireless devices such as Bluetooth and 802.11-enabled devices, the system deploys one or more wireless data access points. Each WDAP contains a set of descriptions and information that needs to be managed by the corresponding message center. For example, the dynamic default output device for each radio data access point is maintained by the WDAP's corresponding MC. These operations are handled by wireless data access point management task 28.
The Message Center maintains a login authentication user profile and some default service settings, as indicated by User Profile Management Task 30. For example, a static default printer or a dynamic default printer for each user is defined in the user's profile. Users can modify their profile via a standard web interface or device interface.
User interface management task 32 handles the various user interfaces installed in the system. The "consumer" user interface is used not only for managing accounts by users, but also for exercising service requests. In one embodiment, the consumer interface provides one segment for home users and another segment for guest users. The guest user interface allows restricted access to system resources under certain conditions for security reasons. The system also has a management user interface for debugging and maintenance, as well as for setting up various system components and parameters.
The print service performs the five main tasks shown in Figure 2. In output image drawing task 34, when the print service receives a job drawing request, an internal component called the driverless print (DP) server collects the source data and puts that data in the DP server queue. The DP server then calls the DPS print module to identify the appropriate driver and generate an output image. The DPS print module queues the output image to the internal output queue and returns control to the DP server. Details of these operations will be described in detail below.
When the DPS print module returns control to the DP server, the DP server calls the status monitor module. If the destination device is not locally connected to the print service, the status monitor writes the output image to the shared repository according to task 36. After that, the control right is returned to the DP server. If the destination device is a locally connected device, the status monitor sends an output image to the device according to task 38. After that, the control right is returned to the DP server. Task 40 sends the job status back to the message center after the status monitor returns the job status to the DP server. By using the Local Output Device Management Task 42, the print service can support locally connected output devices. It handles device registration and deregistration with the Message Center.
With reference to Figure 3, the Remote Desktop client can manage the device's connection to the Message Center through device enrollment and deregistration task 44. To register, send a device registration request to establish an association with the Message Center. To unregister, send a device deregistration request to remove the association from the Message Center.
The remote desktop client refers to the output image file and receives the job output request from the message center according to task 46. It looks up the output image file and sends it to the destination output device. If the reference is not used, the Message Center sends the output data directly to the remote desktop client. After the job output is complete, the remote desktop client notifies the message center of updating the job output status and contacting the user based on task 48.
With reference to Figure 4, it can be seen that each radio data access point performs the following key tasks: The radio data access point needs to register with the message center and link to the system, which is handled through component registration and deregistration task 50. WDAP registration is intended to notify the Message Center of the WDAP's default output device (that is, the closest output device). This allows the Message Center to determine the dynamic default printer for mobile users. To remove the association, in task 50, send an unregistration request to the same message center.
To access a wired network from a wireless device, you need an access point that receives the request and translates the request from a wireless packet to a terrestrial line packet. The WDAP server is the system's data access point. By task 52, a radio request for a non-cellular device enters the system through a radio data access point.
When the wireless data access point receives the connection request, it translates the request into an IP packet and sends the IP packet to the destination defined by the request according to task 54. In return, task 56 processes the system response. When the user moves from the first position near the first WDAP to the second position near the second WDAP, the system returns another set of device information to the user via the second WDAP. Therefore, one of the key roles of WDAP is to make a detailed plan of the default output device and to be able to communicate with the message center to dynamically generate device information according to the output device geographic relationship recording task 58. is there.
As mentioned above, the system can use the optional Bluetooth gateway and Bluetooth device emulation to operate the system as if they were Bluetooth enabled devices, even if they are not Bluetooth devices. it can. If desired, Bluetooth gateway functionality can be incorporated into wireless data access points to reduce hardware costs, as described below.
Operation theory This section describes the flow of required data as well as the common operation of the system. Some of the outstanding features and requirements of the system are listed below. 1. All users are associated with the Home Message Center. 2. The system can enforce security between the two message centers, between the message center and the printing service, and between the message center and the RDC. 3. The Message Center allows home and guest (visitor) users to control resource access. 4. Each WDAP is associated with a configurable default printer. 5. When accessing the system through WDAP, if the user specifies permission to overwrite the dynamic system in his profile, the user's default printer will change based on the WDAP to which the user is currently connected. 6. The guest user interface can be implemented in a message center that supports visitor printing within the zone. Such an interface does not require user registration or profile creation. Therefore, it does not support static default printer printing. However, the system allows visitors to print to a dynamic default printer, and optionally allows the user to specify a destination printer.
The system employs a modular architecture design and an extensible database schema, allowing it to implement advanced security methods. First, in user authentication, the subscriber database contains a user profile that is used to match and verify user login data that is being entered into the system through supported access devices. .. If this verification fails, the system keeps a record for later reference or investigation and the login request is rejected. In addition, the Message Center can implement support from the public key infrastructure for higher level client and server authentication. Second, data encryption support allows each module to implement encryption to protect its content data. Encryption can be enforced from the file store to the message center, from the message center to the print service, from the print service to the output repository, and from the output repository to the RDC. Third, under the non-repudiation implementation, the system assigns each subscriber a unique ID. When a user submits a request to the system, the request is immediately tagged with the user's ID and timestamp. If this is a job submit request, a duplicate is generated in the system, logged, and archived for later reference and billing.
In addition to the security implementations mentioned above, another benefit of the modular distributed architecture is that administrators can customize security settings based on the specific needs of each organization. For example, a virtual private network (VPN) can be used to link a shared file server to a message center. Similarly, a VPN can be implemented between a message center and a remote desktop client. The system architecture supports VPN configurations with both software and hardware. The overall system configuration can include support for public key infrastructure, as well as provision of authentication and certification, protection of data integrity and data privacy, and fulfillment of non-rejection requirements.
Figure 9 shows a flow diagram illustrating the exchange of information between the RDC and the Message Center in accordance with the RDC client registration request. The RDC sends the session packet to the message center to initiate the client registration process. In one embodiment, the session packet contains a client descriptor string, client type, first name, middle name, last name, address 1, address 2, city, state, postal code, USERID, protected PASSWORD. Contains various parameters for defining the client on the message center, such as the EMAIL value. If successful, the client identifier (CID) is returned to the RDC.
A flow chart corresponding to the RDC printer registration request is shown in FIG. As in the previous process, the RDC sends a session packet to the message center to initiate the printer registration process. The packet contains data that identifies the client at the message center and provides the status of the resource requested to register (for example, the output device). If successful, the printer resource identifier (PID) is returned to the RDC.
Remote Desktop Clients must register with the MC to access and make available resources to other public resources. Figure 11 shows the flow diagram that corresponds to the RDC submitting the device resource definition to the message center. The RDC sends a device resource definition packet to the message center so that the device resource is defined within the message center. This information typically includes device name, device type, device descriptor, and device status.
If a client wants to access a remote public device, it must first identify the device via a public device query. This operation requires the Home Message Center to query the Root Message Center for a list of available public devices, as shown in the flow diagram in Figure 12. The Message Center then determines if such public devices are supported within the zone. This means that the Home Message Center needs to identify registered print services that support such public devices. In response to the query, a list of available public devices is returned to the requester. If no registered print service support for public devices is found, the list will not list unsupported public devices.
Figures 13 and 14 show the flow diagram and component interaction diagram for a print by reference (PBR) job request issued by a user in the home domain to an output device that is directly connected to a print service in the home domain. (For example, U1 D2 or U1 D3 in FIG. 6). Under the PBR job request, the user can print the document 72 (that is, the remote source) stored on the remote store 74 on the target destination printer, and the document or destination printer stored remotely. Can be selected by user interface 76.
Figure 15 shows a process flow diagram for non-PBR job requests. In this case, all operations are similar to PBR job requests, except that the source data is uploaded from the user's device to the Message Center and never retrieves the remote source.
Figures 16 and 17 show the process flow diagram and component interaction diagram corresponding to the PBR job request submitted by the user in the home domain to the local printer connected to the remote desktop client in the home domain, respectively. It is shown (for example, U1 D4 in Fig. 6). In this case, after the output image is drawn by the print service, it is stored in the output repository 78 as the output image file 80. The print request is then sent to the appropriate RDC (eg RDC2), where it looks up the output image file from the repository, submits it to the output device (eg D4), and physically draws it. Upon completion, a print completion notification is sent back to the user via the Message Center and displayed on user interface 76.
Figures 18 and 19 show the process flow diagram and component interactions for PBR job requests submitted by users in the home domain (eg, Zone 1) and printed on the root message center's public output device (D1). The figure is shown. The process begins with using the UI to activate user interface 76 and execute public device queries. In essence, this query returns a list of available public devices. The option allows the user to select a known public device, and a query performs the task of verifying that the device is available for public access. When a user submits a query to his home message center (MC1), that MC forwards the query to the root MC. The root MC then checks the database for all available printers for that user (based on the user credentials sent with the query and the configured list of the user's favorite printers). The local print service is identified along with the output device route to the home message center. The public device information is then sent back to the user, who can select the public output device and submit the print job request to the home MC.
After receiving the print job request, the home MC searches for the document to print (in this case, the document is a local source and is sent from the source device to the MC) and prints the document along with the draw request to the destination print service. Send to (PS1). The print service then draws the output image of the document and saves it in the output repository 78. After that, the notification that the drawing is completed is sent back from the PS to the home MC, where the home MC searches the drawing data (for example, the output image file 80) from the output repository and sends the print request together with the output image data to the destination. Send to Remote Desktop Client (RDC1). In addition, the RDC sends the output image data to the destination output device (DC1), after which the hardcopy output is drawn and a print completion notification is returned to the RDC. Then, the print completion notification is forwarded and returned to the user via the root MC and the home MC.
Message Center Access Mechanisms In general, there are three types of mechanisms for accessing the Home Message Center. That is, wired network connections, wireless network connections, and wireless web cellular connections (as used herein, cellular connections are implemented via cell-based infrastructure, including cellular and PSC networks. Including wireless connections made). For example, users of wireless web-enabled devices, including cellular phones (mobile phones) 100, PDAs 102, and two-way pagers 104 (eg Blackberry devices), have network operations with multiple cellular towers 106 and cellular service providers. -The message center MCn can be accessed via the cellular network including center 108.
In the United States, wireless Internet (ie, wireless Web) access is typically achieved using a wireless application protocol (WAP) that works with WAP-enabled devices. In Asia, wireless internet access is generally achieved using the i-mode® protocol. To access data using the i-mode protocol, the wireless device must be an i-mode device or have both i-mode and WAP connections. Other less-used protocols are also used around the world. In the embodiment shown in FIG. 20, this wireless web connection can also be used via a WAP gateway 110 hosted by the WAP gateway server 112. You can optionally use other types of wireless web gateways, such as i-mode gateways, depending on the functionality provided by your wireless service provider.
WAP-enabled devices can access data from a variety of Internet sites that provide content designed for use by such devices. This data is generally distributed to the device as wireless markup language (WML) data, as described below. WML was designed to take advantage of limited viewing capabilities given the low resolution displays and limited navigation capabilities available in today's handheld devices such as radiotelephones, PDAs and Pocket PCs. Includes special markup language. WML includes HDML (Handheld Device Markup Language) and its roots can be traced back to XML (Extended Markup Language). It also includes a metalanguage that supports user-defined extensions.
WAP-enabled devices can access a variety of websites that provide wireless Internet content through a WAP gateway (such as the WAP gateway 110), which is implemented using one or more WAP gateway servers 112. it can. Generally, each WAP gateway is operated by various service providers in the region that support wireless Internet access, but service providers can share WAP gateway functionality. That is, the WAP gateway server is HTML (Hypertext Markup Language) data retrieved from a wireless website (which does not directly encode wireless web content with WML) via HTTP (Hypertext Transport Protocol). Runs various software modules and / or applications with features that facilitate interaction with WAP-enabled devices, including converting to WML. These features include WAP encoders, script compilers, and protocol adapters that convert HTML data to WML.
Creating wireless Internet content generally requires the website to create a text-only version or an image- or video-free version of all or part of the site's pages. So far, only a few Internet websites offer wireless Internet content, but such sites are expected to grow exponentially as more people buy WAP-enabled devices. .. The main reason for preparing such text-only content or content that does not use images or videos is that the display screen resolution of WAP-enabled devices is generally very low, and typical wireless data transfer rates are networks over terrestrial communication lines. It is considerably slower than the data transfer rates available via. Some of the current wireless internet content contains HTML that must be converted to WML by the WAP gateway, but there are many websites that supply data already encoded in WML directly to the WAP gateway. Please note that
With reference to Figure 20, a normal WAP session proceeds as follows. A user operating a WAP-enabled device, such as a PDA 102, opens a "mini-browser" (the WAP client for that session) and then sends a radio signal 114 over the PDA 102's wireless modem to search for WAP services. .. In response, the user establishes a connection with a service provider with a wireless Internet access subscription service contract via the nearby Cellular Tower 106. The user then selects the website they want to view by entering the website URL through the UI provided by the mini-browser (as shown in mini-browser UI 107). Then make a request to access the site PDA Send from 102 to WAP gateway 110. The WAP gateway server 112 searches the website for information corresponding to the URL via HTTP in this case as HTML data, and encodes the HTML data into WML (wireless markup language). As mentioned above, some Internet sites do not require HTML-WML coding because the data may already be in WML format.
According to one embodiment of the invention, each message center MCn hosts one or more of the respective URLs via the web server 113, as described below. As indicated by HTML data 114 and WML data 116, URL data hosted by web server 113 is passed from the message center to the WAP gateway over a communication network such as the Internet 60 or a private network. .. WML data is then sent from the WAP gateway server 112 to the PDA 102 via the cellular tower 106. Similar to traditional browsing methods, users can browse various pages on the site by activating the appropriate UI components that are displayed to the user through a mini-browser, thereby with the user. In response to the exchange of information, a process similar to the one described above is executed, and the content corresponding to the one selected by the user is displayed.
In addition to wireless web access, a direct terrestrial line connection, or a communication link that includes a combination of a terrestrial line network and a wireless network (eg 802.11b), or a terrestrial link to a user device via a Bluetooth wireless link. You can access the message center via the communication line network. For example, a user of a personal computer (PC) 118 or laptop 120 can access the Message Center MCn via a direct network connection to the Message Center (eg, a LAN connection) or a WAN connection such as the Internet. Both of these network connections are indicated by computer network 122. In one embodiment, the user can access the services provided by the system through a browser-based user interface 124 through a set of web pages 126, as described below.
In general, the user interface is similar to a link that further includes an 802.11 (also known as WiFi) connection. For example, in a typical 802.11 implementation, a WiFi-enabled user device, such as the PDA 128 in Figure 20, is connected to a wired network (eg, network 122) via WDAP 130. WDAP controls all communications from WiFi-enabled devices, while making the device appear to the network as if it had a normal client connection. Therefore, from an operational point of view, wired and WiFi clients look the same to the message center.
The system also allows Bluetooth-connected clients to print to selected output devices, but uses a different mechanism. Based on this mechanism, it is necessary to implement a Bluetooth emulator to convince a Bluetooth-enabled source device such as cellular 132 that it is communicating directly with the Bluetooth device, and to make changes to the source device's built-in Bluetooth user interface 133. There is no. For example, suppose a user wants to print to a non-Bluetooth print / fax device. In this case, implement a Bluetooth printer / fax emulator that allows the front-end agent to communicate with nearby wireless data access points. In one embodiment, a Bluetooth device emulator can be incorporated into the WDAP. This is shown on the WDAP + Bluetooth device emulator 134. Optionally, the Bluetooth device emulator can be an independent device linked to and communicating with network 122. In general, the Bluetooth device emulator uses the corresponding output device information retrieved from the message center to generate the required Bluetooth device information (eg, print or fax profile), and the profile was retrieved from the message center. Created on the fly with resource information. Therefore, in one embodiment, the emulator also comprises a back-end communication channel that is employed to interface with the message center (via embedded or nearby WDAP). When a Bluetooth-enabled device connects to the system on a different access point, the corresponding emulator responds with profile information specific to that access point.
The system allows non-Bluetooth devices to behave as if they were Bluetooth-enabled devices through similar Bluetooth device emulation as defined by the Bluetooth Basic Printing or Fax Profile Interoperability Specification, and therefore wireless. It's a simple and cost-effective way for businesses to manage non-wireless devices in a computing environment. These operations are transparent to both the user and the destination device. In addition, resources such as legacy devices are currently managed by the Message Center, eliminating the need for enterprises to modify or replace these legacy devices, or even upgrade.
In addition, the "print by reference" feature of the output management system can be extended to Bluetooth-enabled source devices. For example, in one embodiment, WML content that renders the WAP interface described below can be supplied to a Bluetooth enabled device with a WAP mini-browser 107A designed for WAP on a Bluetooth service. Such devices will soon become commonplace. In such a configuration, the user of the Bluetooth-enabled device interacts with the system in much the same way as the wireless web user by supplying the same WML content to the Bluetooth-enabled device via the WDAP + Bluetooth device emulator. Can be done.
The Default Device Discovery (WiFi) system introduces the concept of static and dynamic default settings to better accommodate mobile computing protocols. For example, the Message Center implements default device configuration options in the user's profile. Taking a printer as an example, each user has two types of default printers: static default printers and dynamic default printers. The former is selected when the user accesses the system via a wired connection (eg, PC 118) and the latter is selected when the user accesses the system via a wireless connection (eg, Bluetooth, 802.11, etc.). Perhaps users rarely have the opportunity to send output to their office printer when using a mobile station at their client site. It is quite practical and affordable to use the access method to automatically switch the default settings. However, for flexibility, users have the option of disabling the dynamic default printer override feature through profile configuration.
FIG. 21 is a schematic diagram detailing the operations used to determine the dynamic default printer when a user submits a job through WDAP. First of all, a user of wireless device 128 enters the system with a wireless connection to the wireless data access point WDAP2. The example shown in the figure assumes that the user submits a PBR job request. In response, WDAP2 relays the PBR job request to the message center. The Message Center retrieves the source data from the file store 136 that corresponds to the PBR job request. The Message Center discovers that the request is from WDAP2, checks its device database, and finds that the dynamic default printer associated with WDAP2 is the output device D1 associated with print service PS1. know. Therefore, the drawing request is sent to PS1. PS1 draws the job request and then sends the output image data to output device D1. The output device D1 completes the job output and notifies PS1 of the completion of the task. PS1 then informs the message center. The message center sends a response to WDAP2 to inform the user that the job request has completed successfully. WDAP2 then relays the response to the user's device.
Default Device Discovery (Bluetooth) In the following cases shown in Figures 22A and 22B, WDAP1 and WDAP2 are Bluetooth devices, as shown by WDAP + Bluetooth device emulator devices 138 and 140, respectively. The network configuration is substantially the same except that it includes an emulator. In both cases, the process begins with the user of the Bluetooth-enabled source device 132 requesting initialization communication with another Bluetooth-enabled device. In these examples, the source device's Bluetooth signal is received by the WDAP2 + Bluetooth device emulator device 140, which establishes a communication link with the Bluetooth-enabled source device.
At this point, the basic Bluetooth UI (eg Bluetooth UI 133) and the advanced Bluetooth UI (eg Bluetooth Mini Browser UI) are common types of interfaces that can be used by the system to interact with Bluetooth enabled device users. There is WAP) on 107A. In a basic Bluetooth UI, the emulator acts as a simulated Bluetooth-enabled output device, or multiple such output devices. In the advanced Bluetooth UI, the emulator acts as a bridge to deliver WAP content to Bluetooth-enabled devices via WAP over Bluetooth.
Basic bluetooth Suppose you have a UI. This case is shown in Figure 22A. In this case, after establishing the Bluetooth link, the user searches for a Bluetooth-enabled output device (or the user initializes the Bluetooth link using the output device search feature). In response, the emulator connects to the root message center (directly or indirectly) and retrieves information related to the output device near the WDAP that facilitates the exchange of information. This type of information is stored in the Message Center database so that the MC can return Bluetooth emulation parameter 141 to the emulator for the various output devices available via WDAP. In an optional embodiment, the emulator requires the user to authenticate (or identifies the user by some other means, eg, using a unique device identifier), and displays a list of output devices that are unique to that user. Can be sent. The emulator then emulates the available output devices, assuming that the Bluetooth-enabled source device is actually communicating directly with one or more corresponding Bluetooth-enabled output devices. For example, if the available output devices include two laser printers and a text printer, the emulator will perform Bluetooth device emulation for all three printers. If only one device is available, that device becomes the default output device. The user then Bluetooth Select the output device via the UI and upload the source data to the emulator as if you were uploading it directly to a Bluetooth enabled output device. The emulator then transfers the source data to the message center, where it calls the appropriate print service to generate the output image data and submit it to the selected output device for drawing.
According to the example shown in Figure 22B, the user can access the system via a WAP on a Bluetooth service hosted by the Message Center. First, a Bluetooth connection between the Bluetooth-enabled source device and the emulator is established as described above. The emulator then contacts the message center to serve the WML content and begins drawing the user interface through the WAP in the Bluetooth mini-browser 107A, which allows the user to source from file store 136. You can select the data and select the output device (D1). All remaining operations proceed in much the same way as described above for the PBR example in Figure 21.
In one embodiment, the system includes an optional configuration that employs a Bluetooth gateway 142. This gateway allows the Message Center to communicate with the Bluetooth device emulator. The Bluetooth gateway also tracks the mapping between the device and the wireless data access point and synchronizes the map with the message center. Such mappings are calculated using input from the device emulator or by sniffing the network.
System Connection Topology Figure 23 shows an overview of the system connection topology Figure 150, which represents the different connection paths and types of connections that can occur in a typical implementation of an output management system. Solid lines indicate persistent connections and wavy lines indicate temporary connections. For component communication, the first rule is that PS and RDC always initiate a connection to the message center. According to the second rule for peer-to-peer message center communication, this connection always starts from a secure network to a less secure network (eg, from a private network to a DMZ). , From Zone 1 DMZ to Zone 0 DMZ, etc.). If both rules are applicable, the first rule takes precedence.
In Figure 23, 150, Zone 0, located in the middle of the figure, is the root message center MC0, which contains a central repository for all MCs to announce and share their public resources (eg output devices). including. Therefore, the components in Zone 0 are preferably placed in the DMZ to accept incoming connection requests that use appropriate security protection. Zone 1 and Zone 2 are located on either side of Zone 0 and contain two independent networks, each with a fully secured subnet (that is, a private network portion) and a DMZ portion. The MCs (MC12, MC22) in the DMZs in Zones 1 and 2 manage public and sharable sources and are therefore referred to as "public" MCs. The MCs in the private subnet behind the internal enterprise firewalls 152 and 154 (MC21 and M11, respectively) manage private resources and are therefore referred to as "private" MCs.
The following is a table of component deployment position maps showing the positions where the components are resident according to the embodiment of the present invention. "Public network" refers to a network that is directly connected to the Internet and does not have firewall protection. Normally accepts all incoming connection requests. "DMZ" refers to a private network that is protected with restrictions. Incoming connection requests are typically accepted when patched through some well-known ports. "Private network" refers to a network with strong firewall protection. Blocks most, if not all, incoming connection requests. Locations within the private network suggest that incoming connection requests are blocked and therefore a proxy that bridges to job requests (eg DMZ). Using MC or root MC makes it easier to share resources. MCs and PSs should not be deployed in public networks for obvious security reasons. The root message center (eg MC0) cannot be deployed on a private network because it must be granted at least limited public access to allow public MCs to register. RDCs can be placed within public networks to allow sharing of a wide range of resources, but this is not recommended.<tables num="1"><img file="JP2005523489A_D0001.tif" /></tables>
Below is a table of component deployment location classification maps that illustrate the 150 component deployment locations in Figure 23.<tables num="2"><img file="JP2005523489A_D0002.tif" /></tables>
Tables 3-6 below show a set of MC network connection maps that describe how components communicate with each other, including connection types, connection initiators, and data transfer types. For performance reasons, persistent connections are preferred only when used for control message exchanges (eg, resource queries, resource registrations), while temporary connections are both control message exchanges and uncontrolled message exchanges. That is, it can be used for source file data transfer and drawing output image data transfer. Support for temporary connections is implicitly included, even if persistent connections are available. The type of data transfer is either "by buffer" or "by reference". Even if "by reference" transfers are available, "buffered" transfer support is implicitly included. Transfer by reference may not be an option available when the sender's file store is not visible to the recipient. In such cases, the appropriate MC directs the data to the destination resource.
The table below corresponds to the network connection map within the MC0 zone. This table describes how to communicate with other components in the same zone as the root MC. Since it is in Zone 0, "private" MCs and PSs are not available.<tables num="3"><img file="JP2005523489A_D0003.tif" /></tables>
The following shows the MC0 inter-zone / network connection map similar to Table 3 above, except for inter-zone communication. This table describes how to communicate with other components in the zone that are different from the root MC.<tables num="4"><img file="JP2005523489A_D0004.tif" /></tables>
The following is a network connection map within the MC zone that is not zone 0. This table describes how to communicate with other components in the same zone as the non-zone 0 message center.<tables num="5"><img file="JP2005523489A_D0005.tif" /></tables>
The following is a non-zone 0 MC zone / network connection map similar to the table above, except for interzone communication. This table describes how to communicate with non-zone 0 MCs and other components in different zones.<tables num="6"><img file="JP2005523489A_D0006.tif" /></tables>
In general, the components in the system communicate using the network message protocol. For example, there is an RDC network message protocol for communication between a remote desktop client and a message center server. In one embodiment, the connection between the RDC and the MC server is initiated by a socket connection from the RDC to port 5190 on the MC server. These socket connections are persistent for the duration of the session. A session is defined as a connection interaction between a client and a server. Most sessions are essentially quiesced between the client and server unless there is a print job destined for a remote printer associated with the client. When a session starts, the client sends a number of session parameters to the client to establish a connected session.
Supported data transfer types This section briefly describes how to process job request data and how to transfer it to each component. The basic job request process flow can be summarized in the following operations. 1) Upload the input file data to the message center, 2) MC will identify the appropriate printing service for drawing the output image based on the identified destination output device, 3) MC will PS the input data 4) PS draws the output image, 5) PS transfers the output image to the MC, or stores the output image in a common repository, 6) The MC either sends the output data to the RDC or lets the RDC access the file by referencing a common repository. Depending on the actual job request source and destination, the staging MC may need to bridge the data transmission. Transfer types are classified into two types: "by reference" and "by buffer". In general, referral transfers appear to be more efficient than buffer transfers (because of less file schooling), but from different components located in different parts of the network due to security constraints (eg firewalls). It may not be possible if you cannot confirm each other's references. In such cases, buffer transfer is the only option for data transmission. The table below defines the types of data transfers.<tables num="7"><img file="JP2005523489A_D0007.tif" /></tables>
<u style="single">In-zone MC (DMZ)-RDC (public)</u>.. The purpose of this type of communication is to send print requests from the DMZ MC to devices connected to the RDC in the public network registered with the same MC in the same DMZ in the same zone. For example, the transfer from MC12 to RDC14.
With reference to the flow diagram in Figure 24, the process begins at block 160, where the user connects to the user's home message center and performs a login operation. At block 162, the user submits a print request through the user interface that corresponds to the originating device of the other party when the user connects to the system. If the print request corresponds to print by reference (PBR), the MC is in block 164, which contains the source data (eg, the source data) from the remote store specified via the UI and notified by the PBR request. Upload the "input" file). If the print request corresponds to a non-PBR request (that is, the source data to print is located on the source device), the MC uploads the source data from the device in a buffer at block 166.
The MC then identifies the appropriate print service and sends a job drawing request in block 168. In general, a suitable print service corresponds to a PS that is in the same zone as the destination output device and provides support for the print service with respect to specific characteristics of the destination output device and source data (eg, driver support for the output device). Have an application that you can run to do and generate the image output data that corresponds to the source data). If the request is PBR, the MC sends a reference to the print service that identifies the network storage location of the input file in block 170. If the request is not PBR, the MC buffers the input file to PS at block 172. After searching or receiving the input file, at block 174, the print service produces the output image data (output image file).
When using the repository, PS stores the output image file in the repository in block 176 and transfers the output image to the MC by reference in block 178. In this case, the output image data is stored in a file in the repository, and the transfer by reference means that the PS sends the route, filename, and network location of the output image file to the MC. If the repository is not used, PS will buffer the output image to MC in block 180.
At this time, in block 182, the MC identifies the appropriate remote desktop client to receive the output image. This is typically done through a database lookup based on the destination output device to identify the RDCs that can be used to submit the output image to the destination output device. The MC then sends the output image to the RDC identified by reference in block 184. After receiving this reference, the RDC looks up the output image, submits it to the output device at block 186, and draws it by the output device. When the information that the job has been printed is obtained, the MC sends a notification back to the user to inform the user that the print job has printed successfully. In block 188, in simple terms, the process can be represented by (UBR, UBB) (DBR, DBB) (TBR, TBB) PBB.
<u style="single">In-zone MC (DMZ)-RDC (DMZ)</u>.. The purpose of this type of communication is to send a print request from a message center located in the DMZ to a device connected to an RDC in the same DMZ registered in the same MC in the same zone as that MC. That is (for example, MC12 RDC13). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) (PBR, PBB).
<u style="single">In-zone MC (DMZ)-RDC (private)</u>.. The purpose of this type of communication is to send a print request from the DMZ MC to a device connected to an RDC in a private network registered with the same MC in the same zone (eg MC12 RDC12). .. The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) (PBR, PBB).
<u style="single">In-zone MC (private)-RDC (public)</u>.. The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in a public network registered with another MC in the DMZ in the same zone (eg,). MC11 RDC14). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) SBB PBB.
<u style="single">In-zone MC (private)-RDC (DMZ)</u>.. The purpose of this type of communication is to send print requests from the private MC to devices connected to the RDC in the DMZ registered with other MCs in the same DMZ in the same zone (eg MC11). RDC13). The corresponding notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) SBB (PBR, PBB).
<u style="single">In-zone MC (private)-RDC (private)</u>.. The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in a private network registered with the same MC in the same zone (eg MC11 RDC11). .. The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) (PBR, PBB).
<u style="single">Inter-zone MC (DMZ) -RDC (public)</u>.. The purpose of this type of communication is to send print requests from the DMZ MC to devices connected to the RDC in the public network registered with other MCs in the external DMZ from different zones (eg). , MC12 RDC24). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) PBB.
<u style="single">Inter-zone MC (DMZ) -RDC (DMZ)</u>.. The purpose of this type of communication is to send print requests from different zones to devices connected to RDCs in different DMZs registered with other MCs in the same external DMZ (eg MC12 RDC23). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) PBB.
<u style="single">Inter-zone MC (DMZ) -RDC (private)</u>.. The purpose of this type of communication is to send print requests from the DMZ MC to devices connected to the RDC in a private network registered with other MCs in different DMZs from different zones (eg). , MC12 RDC22). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) PBB.
<u style="single">Inter-zone MC (private)-RDC (public)</u>.. The purpose of this type of communication is to send print requests from a private MC to a device connected to an RDC in a public network registered with another MC in a different DMZ from a different zone (eg). , MC11 RDC24). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) SBB PBB.
<u style="single">Inter-zone MC (private)-RDC (DMZ)</u>.. The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in the DMZ registered with another MC in the same external DMZ from a different zone (eg,). MC11 RDC23). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) SBB PBB.
<u style="single">Inter-zone MC (private) -RDC (private)</u>.. The purpose of this type of communication is to send print requests from a private MC to devices connected to RDCs in different private networks registered with other MCs in different external DMZs from different zones. (For example, MC11 RDC22). The corresponding simple notation is (UBR, UBB) (DBR, DBB) (TBR, TBB) SBB PBB.
Multitier Architecture of System Hardware In one embodiment, a four-tier architecture design is used to implement the system, as shown in Multitier Architecture 200 in Figure 25. The first layer of this architecture contains Web Server Farm (WSF) 202, the second layer contains Message Center Farm (MCF) 204, and the third layer contains Print Service Server Farm (PSSF) 206. , Layer 4 contains a database server farm (DBSF). Each layer will be described below.
<u style="single">Layer 1 Web Server Farm (WSF)</u>.. This layer consists of a load balancer (LB) 208 and a web server farm 202. The load balancer receives incoming requests and distributes them to one of the web servers in the web server farm. Web servers share the same URL, so users only need to remember one URL to access the system. The distribution of requests depends on the configuration of the load balancer 208. The load balancer handles the location of the web server and request dispatch. The assigned web server runs the script locally and calls the common database access interface to the corresponding database server farm, thereby either NFS (Network File System) or SAN (Storage Area Network). ) Update database 210 stored on device 212. In addition, the load balancer can send a warning message to the administrator to indicate that an error has occurred in the web server farm.
<u style="single">Layer 2 Message Center Farm (MCF)</u>.. The Message Center farm contains two running copies of the Message Center software components. One contains the primary MC 214 running in processing mode and the other contains the secondary MC 216 running in standby mode. The primary MC always responds to the incoming request first. If the primary MC does not respond, the secondary MC switches to processing mode and processes the request. It then sends a warning message to the system administrator to indicate that there is an error. This failover switch runs automatically without human intervention. When the problem is resolved and the primary MC comes back online, the secondary MC automatically returns to standby mode, informing the primary MC of the takeover.
The system supports an automatic failover switch by implementing a "heartbeat check" between the primary and secondary MCs. For this implementation, each MC has two Ethernet® interfaces and one serial port. All four Ethernet interfaces are connected within the same subnet and the serial ports are connected to each other. After installation, the MC is assigned the same floating IP address on one of the Ethernet interfaces (floating interface) and a different static IP address on the other interface (static interface). The primary MC boots both Ethernet interfaces at system startup. However, the secondary MC only launches the static interface to avoid conflicts. The secondary MC checks if the primary MC is available by sending test packets through the static interface. If the floating interface of the primary MC is unreachable, as a guarantee, double-check the secondary MC using the locally connected serial port to find out more about the problem. The secondary MC then launches a floating interface to process incoming requests and send a warning message to the system administrator. In the meantime, continue heartbeat testing to detect if the primary MC has recovered. When the primary MC comes back online, the secondary MC shuts down the floating interface and sends a request to the primary MC to bring it up. To ensure that the secondary MC is always on standby, the primary MC performs the same check on the secondary MC, but admins a warning message if there is a problem with the secondary MC. Just send to. The heartbeat test will continue as long as the system is up and running. Set heartbeat intervals to improve system reliability and performance
<u style="single">Layer 3 Print Service Server Farm (PSSF)</u>.. This layer consists of a load balancer 218 and a print service server farm 206. The load balancer receives an incoming request from Message Center Farm 204 and distributes it to one of the print service servers in PSSF 206. The MCF always uses the same destination IP to access the print service. The distribution of requests depends on the configuration of the load balancer 218. The load balancer handles the location of the print service server and request dispatch. The assigned print service server processes the drawing request, stores the output image data on a shared NFS or SAN device if necessary, and then sends the result back to the MCF. In addition, the load balancer can send a warning message to the administrator to indicate that an error has occurred in the print service server farm.
<u style="single">Tier 4 Database Server Farm (DBSF)</u>.. This layer consists of two database server farms, including the Message Center Database Server Farm (MCDSF) 220 and the Print Services Database Server Farm (PSDSF) 222. These server farms are connected to NFS servers or Storage Area Network (SAN) servers 224 and 226, respectively, and host the databases 228 and 230, respectively.
Database server farms implement each other's heartbeat checks in a similar manner as described above for Layer 2 message center farms. However, some advanced commercial database systems have built-in server failover switches. In such a case, reliability can be maintained without the implementation of "server farm heartbeat survey".
<u style="single">Scalability</u>.. The entire system can be extended by creating more running instances in Layers 1 and 3. Placing an optional load balancer inside Layer 2 can also extend the system entirely. In such cases, the heartbeat inspection mechanism is not needed because the load balancer can be assigned a role to guarantee accessibility to each component.
<u style="single">Security</u>.. With a modular architecture design and an extensible database schema, you can implement a high degree of security. First, with user authentication, the subscriber database contains a user profile that is used to verify that user login to the system is valid when performed through a supported device. If this verification fails, the system keeps a record for later reference or investigation and the login request is rejected. In addition, the Message Center can implement support from the public key infrastructure for higher levels of client and server authentication. Second, data encryption support allows each module to implement encryption to protect its content data. Encryption can be done from the file store to the message center, from the message center to the print service, from the print service to the output image repository, and from the file image repository to the RDC. Indeed, too much encryption can degrade overall performance, and insufficient encryption can jeopardize user data. Third, in a non-rejective implementation, the system assigns each subscriber a unique ID. When a user submits a request to the system, the request is immediately tagged with the user's ID and timestamp. If this is a job submit request, a duplicate is generated in the system, logged, and archived for later reference and billing.
In addition to the security implementations mentioned above, another benefit of the system's modular distributed architecture is that administrators can customize security settings based on the needs of their organization. For example, a virtual private network (VPN) can be implemented as a standard setup between a shared file server and a message center. Similarly, a VPN can be implemented between a message center and a remote desktop client. The system architecture supports VPN configurations with both software and hardware. The entire system can provide a public key infrastructure, provide authentication and certification, protect data integrity and data privacy, and meet non-rejection requirements.
Message Center The Message Center provides (generally) public access (eg, over the Internet) and has one or more network connectivity servers that implement an RDBMS (relational database management system) database. .. Referring to FIG. 26, in one embodiment, the message center MCn hosts a UNIX® server 232. In general, various server classes can be used to host a message center, including servers running operating systems such as UNIX, Microsoft Windows Server, and Linux. The server is preferably implemented as redundant components such as RAID 5 disk subsystems and high availability hardware.
The message center MCn includes an RDBMS database 228 that stores data about the operation of the message center and other system components. Generally, the host of an RDBMS database is SQL RDBMS database software, which can be Oracle (eg 8i or 9i), Microsoft (eg SQL Server 7 or 2000), IBM (DB2), Informix, Sybase, etc. It is sold by the vendor of. The current implementation uses a MySQL RDBMS that utilizes network socket connections and PERL and C programming APIs. Optionally, the host for database 228 can be a non-SQL RDBMS.
Each message center also has various software modules that handle the tasks described above with reference to Figure 1. These include a message handler 234, a table update handler 236, a table maintenance operation 238, and a print service communication channel 240. In addition, the message center has a web server component for interfacing with web traffic. In one embodiment, an Apache web server is used along with PHP4 server and SSL server extensions and associated CGI applications to support remote server maintenance and management as well as print service communication operations.
Message handler 234 runs as a service bound to a specific network port (eg, system port 5190). Remote Desktop clients use this port to connect to the Message Center and maintain a persistent connection for the duration of the session. Communication between the message center and the RDC is connection-oriented, and each session consists of specific phases that use the network message protocol. Communication between the Message Center and the Remote Desktop client begins when the RDC begins the session launch process and either disconnects unexpectedly (network connectivity is lost or the RDC host machine (eg, PC) shuts down. Or when the RDC application terminates abnormally and an error occurs in the RDC) or when the RDC starts the session stop process.
The table update handler (TUH) 236 consists of a set of database methods written in the native API of the RDBMS system (for example, in the case of a MySQL RDBMS implementation, it uses the C or PERL API and Oracle For RDBMS implementations, use PLSQL stored procedures). The methods in this module consist of the ability to modify the resource status of remote printers, the ability to add, delete, and modify wireless subscriber profiles, update the job queue management table for print services, and much more.
Table Maintenance Operations (TMO) Module 238 is a set of individual database operations that generate logs and reports, purge tables on a regular basis, and perform the maintenance functions needed to resolve database table problems. To be equipped. Some of these features are ad hoc, while others are scheduled to run on a regular basis, eg, hourly, daily, or weekly. Some features of this module are available via the CGI interface (or SSL) on port 80.
The print service communication channel 240 implements a message channel for the print service component to access the message center. This channel allows print services in the system to connect to the Message Center and update the job queue management status. In one embodiment, this channel is implemented by message center port 80 or SSL port, and APIs with messaging capabilities include CGI scripts.
Database Schema In general, the Message Center RDBMS schema has three separate databases: Remote Printer Resource Management (RPRM) Database 242, Job Print Queue Management (JPQM) Database 244, and Wireless Subscriber (SUB) Database 246. including. The RPRM database contains a printer resource registry, RDC processes, and tables related to printer asset management. The JPQM database contains tables related to submitting print jobs processed by the print service. The wireless subscriber database contains tables related to wireless subscribers.
SUB database table<u style="single">Subscriber table</u>.. This table contains specific information about wireless subscribers in the system. Subscribers fill in the fields in this table with a one-time registration procedure. The field corresponding to the description starting with "HTTP_X_UP_DEVCAP" contains the value of the device function returned by the wireless device in the HTTP GET header that defines some functions of the wireless device. The SUB_NO field contains a unique subscriber number associated with the cellular number entered by the subscriber at registration and is used to identify subscribers for all sessions. The index field SUB_ID is unique for each record and is used to reference (ie, link to) the NETWORK_SITES and PRINTERS tables described below.<tables num="8"><img file="JP2005523489A_D0008.tif" /></tables>
<u style="single">Network site table</u>.. This table contains multiple fields that define the network sites added by the subscriber, as well as login information for each site.<tables num="9"><img file="JP2005523489A_D0009.tif" /></tables>
<u style="single">Printer resource table</u>.. This table contains several fields of information needed to define printer resources for a particular subscriber.<tables num="10"><img file="JP2005523489A_D0010.tif" /></tables><tables num="11"><img file="JP2005523489A_D0011.tif" /></tables>
<u style="single">RPRM database table</u> Master printer resource table. In this table, the remote printer resource configuration and status information of the entire system are described for each print resource registered on a specific message center.<tables num="12"><img file="JP2005523489A_D0012.tif" /></tables>
<u style="single">Zone descriptor table</u>.. This table defines the parameters of the zones defined within the system-wide network. The records in this table are referenced by the Zone Identifier (ZID) value. The ZONE_DESC descriptor, ZONE_TYPE, and STATUS fields describe the characteristics of the zone.<tables num="13"><img file="JP2005523489A_D0013.tif" /></tables>
<u style="single">Message Center Table (MCT)</u>.. This table contains information used to refer to the message center in the system. These processes are identified by a message center identifier (MCID), and the value is a unique value that affects the entire system. Note that for all PUBLIC resources, there is a master message center that is always referenced with an MCID equal to 0, and the MCID value of all other message centers is a non-zero positive number. The MCT contains information that identifies the message center zone and network address. Note that the ZONE identifier (ZID) of the master message center is equal to 0 and the MCID value of all other message centers is a non-zero positive number.<tables num="14"><img file="JP2005523489A_D0014.tif" /></tables>
<u style="single">Client descriptor table</u>.. This table defines the individual clients involved in the remote printer resource. The records in this table are referenced by the client identifier (CID). The CLIENT_DESC, CLIENT_TYPE, name and address fields define the client's attributes. The information stored in this table is generated when the desktop client software is installed by an individual or on a PC behind a corporate firewall during the registration process. The print job queue information contains the CID identifier associated with the job that prints the client process.<tables num="15"><img file="JP2005523489A_D0015.tif" /></tables>
Job print queue management database table<u style="single">Print service table</u>.. This table describes the registered printing services installed in the network. The records in this table are referenced by the MPID identifier. (In the current implementation, the print service server is referred to as the "MAGICPRINT" server and therefore uses the identifier name MPID. These print servers are driverless in this specification. Also known as the Print Server (DPS).) Use the name descriptor, IP address, status, and server descriptor string fields to define the attributes of each print service. Note that you enter each type of driver on the print service server. For servers located locally, use the ZID identifier to refer to the relevant zone.<tables num="16"><img file="JP2005523489A_D0016.tif" /></tables>
<u style="single">Print queue table</u>.. This table manages network printer queues. Each record in this table represents a single print job referenced by the QID identifier. The system-wide design facilitates delayed print job functionality, with QDATE and DQDATE fields tracking the date and time of job queue entry and exit. Most of the identifiers in this table are copied from this table to the JOB queue log table after the print job is processed. The DRIVERDESC string contains information that defines the type of printer driver used to process the document and the remote printer resource referenced by the PID identifier and associated with the desktop client referenced by the CID identifier. Is included.<tables num="17"><img file="JP2005523489A_D0017.tif" /></tables>
<u style="single">JOB queue LOG table</u>.. The JOB queue LOG table contains information for logging processed print jobs. Jobs in this log are referenced by the JOB log ID (JID) value. Fields are transferred from the print queue table to this table. The print service server is referenced by the MPID identifier. The client used to print the job is referenced by the CID identifier. Remote printer resources associated with the CID are referenced by the PID identifier. In addition, write the JOB owner descriptor string to identify the originator of the print job.<tables num="18"><img file="JP2005523489A_D0018.tif" /></tables>
A detailed description of an embodiment of the software component used in the print service PSn is shown in FIG. The software components are logically divided into four groups, including the setup component 300, the message center communication interface 301, the domain processing component 302, and the management component 304. Each of these components further includes one or more software applications, scripts, components, / or modules. Setup component 300 includes print setup module 306 and account wizard module 308. Message center communication interface 301 includes a print server to message center communication channel 310. Document processing component 302 includes CGI script 311, driverless print server component 312, port monitor 314, status monitor 316, and preview module 318. Administrator component 304 includes system monitor 320, management (control panel) web page 322, auto-extension module 324, and auto-update module 326.
In one embodiment, the printer setup module 306 includes a Microsoft (MS) Windows application run by a system administrator to change the configuration of a Windows printer used in the system. You can use this application to convert an existing printer, install a new printer, or delete a printer. Converting an existing printer installs the existing printer and replaces the operations provided by the MS Windows port monitor with port monitor 314. By using port monitor 314, the DPS system manipulates spooled files, which allows status monitor 316 to send spooled files to selected destination output devices.
Print setup module 306 can also be used to install a new printer with the appropriate printer device drivers. For example, an administrator can set up a PostScript printer by using the printer's PostScript Printer Description (PPD) file, installing the Adobe PostScript driver, and using it on a DPS system. Once the administrator has the PDD ready, the setup module installs the PostScript driver and configures it for use with the DPS system. In other cases, the administrator will have the appropriate printer device driver software for the new printer. Printer setup module 306 can also be used to delete printers. In such cases, you can restore the Windows port monitor as a system port monitor, or remove support for the DPS server for the selected printer altogether.
Account Wizard Module 308 applies security to a set of administrative web pages 322, allowing administrators to log in and determine which set of web pages they can access. In one embodiment, the system implements three types of management levels: monitor, manager, and management level. In one embodiment, the Account Wizard creates these three groups as MS Windows user groups. In addition, the Account Wizard creates MS Windows user accounts and puts them in one of the administrative user groups. In one embodiment, Account Wizard Module 308 is an MS Windows application.
Communication between the print service and the message center can be performed by using the communication channel 310 from the print service to the message center. Communication includes print service registration and deregistration, job drawing request, job print request, device registration and deregistration, device status query, and the like.
A detailed description of CGI script 311 is shown in Figure 28. "Cancel Print Job" Use CGI script 328 to delete the print job request from the system. From administrative web page 322, you can call the script for any print job that has been submitted to the system and the spooled file has not yet been sent to the printer. You can also call this script from the Message Center.
The autoextended configuration CGI script 329 searches the print service host for installed applications, finds document types that the found application can support, and allows it to execute print job requests for the found file types. Configure the print service. You can update the resource configuration information by transferring this information to the message center. Use the system update CGI script 330 to compare the installed system components with the latest available components, download the new components (if applicable), and install them on the PS host.
The print request CGI script 331 takes the source data (eg, a document file, graphic image file, or URL) as input from the message center and creates a print job request to be processed by the print service. The job queue CGI script 332 reads a queue of print job requests from the system and returns the list to the caller of the script (eg, MC). "Preview CGI" CGI script 333 receives a document file, graphic image file, or URL from the message center and creates a print job request on the system in a manner similar to a print request CGI script. However, when the preview CGI script is called, the system transforms the document, image, or web page into a format that can be displayed in the source device's user interface, rather than being sent to a printer for printing. You can call the preview CGI script again for a document, image, or web page to instruct the system to send the previewed item to the selected output device.
Reset CGI script 334 closes and restarts the system application. This script is used by system administrators as a last resort to clear a program error if it occurs. Status CGI script 335 displays administrative web page 322 showing the progress of print job requests.
The components implemented by the driverless print server 312 are shown in Figure 29. A driverless print server is a major software component used by printing services. It is an application that runs on a print service host (that is, a server computer) that accepts job requests, queues them, and directs the process of printing documents, images, or URLs from request to final print. including. Driverless print server components include File Type Configuration List 336, Browser Print Component 337, Auxiliary Application Print Component 338, Shell Extended Print Component 339, Print Preview Component 340, Job Request Server Component 341, Job Processing. There are component 342, window processing component 343, and job status component 344.
The file type configuration list 336 is maintained by the driverless print server. For each file type, the configuration list describes the extension and the method used to print that file type. If the Auxiliary Application Printing Component 338 provides a printing method, the list includes the path to the application used for printing, the menu commands that the application uses to print, and the menu that the application uses to close the application. -Contains commands.
The browser print component 337 comprises one of three methods used by the driverless print server to generate the output image data. In one embodiment, this component uses an application programming interface (API) provided by a Microsoft Internet Explorer (IE) web browser. The component uses the IE API to run the browser within the window of a driverless print server application. In order to print the URL, driver-less print server, a Web page window by using the navigation programming interface that is provided to load into the Indou. After the page loads, the component instantiates the print operation using IE, which provides a print programming interface.
If the IE browser instance on the DPS server computer is configured to use the browser plug-in that corresponds to the requested document or image file type, use this method for documents and images. -Files can be printed. For example, consider an IE plug-in for Adobe Acrobat . The extension of Adobe Acrobat document files is PDF. If the Acrobat plug-in is installed on the server computer, IE's navigation programming interface allows you to load PDF files into IE, and IE's print programming interface allows you to print files.
Auxiliary application printing component 338 provides another method used by driverless print servers to generate output image data. This component uses file type configuration list 336 to find the application associated with that file extension, loads the file into the application, executes the application's print menu command, and after the print operation is complete, the application. Close. The combination of the file type configuration list and the auxiliary application printing method allows the system administrator to install the application on the server machine and edit the file type configuration list to add support for additional documents or image types. be able to.
The shell extended print component 339 comprises a third method used by the driverless print server for printing. This component prints using the MS Windows Shell Extensions programming interface. The MS Windows Shell Extensions interface is a feature of the operating system that allows users to print document types using commands sent to applications that support that document type. The application loads, prints, and automatically closes the document if it supports the Shell Extension interface. The combination of the file type configuration list and the shell-extended printing method allows system administrators to add support for additional documents or image types by installing the application on the server machine and editing the file type configuration list 336. can do.
The print preview component 340 converts the requested document, image, or URL of a print job into a document-formatted file so that the consumer user can view an example of the requested document, image, or URL. This component works in conjunction with the preview CGI script 333. One of the transformations performed by the driverless print server is for the Adobe Acrobat document format. By using the print preview component, the driverless print server creates the spool file in the same way that it creates the spool file for printing. However, instead of sending the spooled file to Status Monitor 316 for sending to an output device or repository, it runs the spooled file through an Adobe Acrobat Distiller application that converts the document to Acrobat PDF format. For this conversion, the printer driver is Adobe Must be a PostScript driver. The driverless print server holds the spooled file created during the preview process, so the DPS simply sends the spooled file to status monitor 316 when the consumer user wants to print the document. The spool file is simply sent to the printer and printed.
The job request server component 341 receives a print job request from the print request CGI script 331, queues it, and waits for processing. The job processing component 342 manages print job requests from the time it is inserted into the job queue until the spool file of output image data is generated. This component reads the queued job request, determines one of the three printing methods to use for printing, submits the document, image, or URL to the determined printing method, and of the print command. Process the execution and submit and save the spool file to the status monitor. At each stage of the output image generation process, track the status and make the status available from the call if the status CGI script 335 can be called.
Use windowing component 343 for reliable printing. Many applications display message boxes and / or dialog boxes during the printing process to provide or collect information from users requesting printing services. To support the automatic processing of print requests, you need a mechanism to respond to message boxes or dialog boxes that appear in the application used to print the request. This mechanism is provided by the window processing component 343. The driverless print server monitors the server for message boxes and dialog boxes during the printing process. When a new message box or dialog box appears, the window processing component reads that information, compares it to a known message or statement, and follows the programmed logic of the message box or dialog box. Close. The details of the window processing component will be described below with reference to FIG.
It includes a job status component 344 to keep memory-mapped files for all jobs in each driverless print server queue. By periodically writing job status information to a memory-mapped file, the status CGI script can read the status of the job request.
The port monitor contains standard components within the MS Windows printing subsystem. The port monitor receives spooled data from the printer driver through the print subsystem. Traditional boat monitors are tasked with receiving spooled data from the printer driver and handing it over to the printer. On a driverless print server, port monitor module 314 (Figure 27) writes spooled data to a file. When the entire spooled file is written to the file, port monitor module 314 sends a message to the driverless print server with the name and location of the spooled file.
Status monitor 316 contains applications that run on the server computer. It performs multiple functions, but is primarily responsible for sending spooled files to the printer. The driverless print server receives a message from port monitor 314 indicating the location of the spool file, and then sends the location of the spool file, the URL of the printer to which the spool file is sent, and the spool file to the printer. Sends a message to the status monitor 316 showing the protocol information for. Status monitor 316 queues each requested printer URL. Since the printer can only receive one spooled file at a time, it serializes the sending of the spooled file. Status monitor 316 can create and maintain multiple queues at the same time.
After the output image is successfully generated, Status Monitor 316 notifies the driverless print server with a message that the job is complete. The job history is updated and the job is removed from the driverless print server queue. Status monitor 316 can be configured to send a message to external components when and / or after generating the output image. For example, it can be used to notify the message center that started the print job that the output image corresponding to the print job is complete.
System Monitor Component 320 includes an application that monitors all other print service components, checks for errors, and monitors incoming specific requests. If a print job request arrives from print request CGI script 331 and the driverless print server application is not running, the print request CGI script launches the driverless print server for system monitor 320. And you can request that the print job request be processed. System Monitor 320 periodically sends a message to the driverless print server to get the status of the program and print jobs in the queue. If System Monitor detects an error, it will try to resolve this issue.
System Monitor 320 can also be used to download and install newer print service system components. Collect version numbers for all components in the system and send them to the system update website. If the update website replies with information about the availability of newer components, search for these components and install them on your system. System Monitor accepts update requests from the menu or from the "Update System" CGI script 330.
Administrative Web page 322 allows administrative users to perform remote configuration and monitoring of the system. Use security features to prevent consumer users from accessing these web pages.
When you submit a file to generate an output image, the driverless print server opens the application that corresponds to the file type of the file. For example, if the file has a .doc extension, it is generally MS. The Word application opens. The application then opens the file and uses the built-in print command to send the submitted file to the selected printer. In the extension web page (not shown), in the row (entry) that displays a list of file type information (in the Extension column) and in the file type (in the Application Name column). The corresponding software application is displayed. Each entry also contains the extension priority level (which defines the order in which file types with the same extension are evaluated to determine the appropriate application for the submitted file), and OS registry information about the application. It displays the registry location that identifies the destination, the application's default path, the application's executable file name, and the internal code to print and close the application. Administrators can activate the Add New Entry button to add a new file type and use this button to use the corresponding edit control in each column of the previous web page to create a web page (shown in the figure). Draw). Users can also update file types and edit existing file types.
A driverless print server uses an extension table that corresponds to a file type value and is installed on the server computer that is used to print the files for each file type listed in the extension table. Determine which application you have. In addition, the information contained in this table is used to determine the location of executable files on the print service server computer. In one embodiment, extension tables and various other configurations and print job data are kept in the database. Databases are usually hosted on the same machine that hosts the DPS software, but one of ordinary skill in the art will understand that another machine can be used to host the database.
Processing print requests A data flow diagram illustrating the data flow and the operations performed by the print service DPS system software component in response to the print request is shown in Figure 30. First, the user of source device 350 connects to the system, selects the source data to print from either the local store or the remote store, and then selects the output device to print the source data as described above. .. This information, including user input 352, is received and processed by the corresponding message center to generate print job 353. In general, a print job contains source data or a reference to the source data and identifies whether to store the output image produced by the print service in a repository or submit it directly to the output device. The print job is first processed by the print request CGI script 331, which produces a tmpdoc.dpsn document 354 containing the print parameters and other data corresponding to the print job. The tmpdoc.dpsn document is then sent to job queue 356 by the print request CGI script. In one embodiment, the job queue includes a first-in first-out (FIFO) type job queue. Other types of job queues can optionally be used, but those skilled in the art will understand this. As mentioned above, job queue operations are performed by job processing component 342.
Job requests submitted by the job queue are processed by the print service. It parses the tmpdoc.dpsn file and finds the print job parameters that correspond to the print requests stored in the document file 360, but each request is processed by block 358. For example, the analyzed information includes printer selection, number of copies, consumer user ID, document name, message center for submitting print jobs, and so on. Some of the print job parameters are stored in the DPS database 361.
Decision block 362 determines what kind of document was requested to be printed, for example, an application file, an image, or a web page URL. If the document pertains to a viewable document such as a web page, image, or PDF file, the logic flow goes into block 364, where the web page, image, or PDF document launches a driverless print server browser. Loaded through. Otherwise, the logic flow goes into block 366, where the document and the appropriate auxiliary application that can be used to print the document are loaded. For example, if the document contains an MS Excel spreadsheet, MS An instance of the Excel application is loaded with the Excel document. Block 368 generates an internal command that simulates a user requesting a print operation that requires either a browser or ancillary application to print a URL, image, or document. For example, most applications have a File> Print menu option that initiates the application's printing process.
Various print and document information is internally passed to the operating system component that handles the printer operation in response to the print request of the internal application or browser. As mentioned above, in one embodiment, the driverless print server operates in an MS Windows OS environment. Therefore, this environment is a graphical device that communicates with the printer device driver 372 that corresponds to the selected printer that is sent to the target printer 374 to produce the output document (that is, the output device) data. · Equipped with OS printing subsystem 369 including interface (GDI) component 370. The printer data is processed internally by the MS Windows print spooler component 376, which outputs the print spool file received by port monitor 314. In the example shown in the figure, the destination output device D<sub>DEST</sub>Is assumed to include a PostScript printer. Therefore, the port monitor 314 outputs the PostScript file 378.
While the above operations are in progress, the user of the originating device 350 may choose to preview the simulated printed output of the document, image, or web page before printing the source document. The decision block 380 determines whether the user has made a request to preview the printer output. If the answer is "yes" (TRUE), in one embodiment, an instance of Adobe Acrobat Distiller 382 is launched and used to generate Adobe Portable Document Format (PDF) Document 384. The PDF document is processed by the preview CGI script 333 and sent back to the outgoing device 350 via the Message Center MCn, where Adobe The PDF plugin renders it in a browser running on the source device. The rendered display (not shown) is a preview of what the printed document will look like, and a laser interface that allows the consumer user to choose whether to print or undo the document. It has a (UI) control.
If the consumer user wants to print the document, a print notification is sent back to the Message Center MCn, where it is processed by the preview CGI script 333. In response to receiving the print notification, the preview CGI script 333 activates the status monitor 316 and directs the print document 378 to the destination output device D, depending on the destination of the output image data.<sub>DEST</sub>Or submit to one of the output repositories 78. Along with this event, the job history information in the DPS database 361 is updated. In addition, after the output image is printed, a print completion notification 380 is sent back to the status monitor 316, where the notification is forwarded to the message center MCn as job status message 381.
If the print preview option is not selected by the consumer user, the answer to decision block 382 is "no" (FALSE), status monitor 316 is activated, and print document 378 is the destination output device D.<sub>DEST</sub>Or submitted to output repository 78. During the print process, Status Monitor 116 monitors the progress of the process and updates DPS database 361. Use the status CGI script 335 to retrieve progress information from the database, generate the appropriate HTML, and send the corresponding print job back to the submitted message center, as indicated by job status message 381. Provides print status information to the message center.
In one embodiment, the driverless print server supports direct printing of printer files. For example, if the print job file contains a printer file, it can be printed directly if it corresponds to the printer file type of the destination output device. For example, a PostScript file can be output to a PostScript printer. Similarly, printer files for other types of printers can be pre-created by selecting the Save to File option during the printing process. If decision block 362 determines that the file is a printer file, this logic proceeds to block 367, where the printer file (indicated by printer file 367) is sent directly to the Windows print spooler 376. Will be done.
If the output image is stored in the output repository 78 instead of being sent to the output device, status monitor 316 will issue job status message 381, as indicated by output image file reference 386. Use to send a message to the Message Center MCn indicating that the output image file corresponding to the print job is stored in the repository, along with the name and location of the output image file.
The details of the internal operation of the driverless print server software 46 are shown in FIG. As before, the consumer user operating the source device 350 will have source data (eg, documents, images) via the appropriate user interface for the source device (eg, mini-browser UI 107 or browser UI 124). · Request to print a file or web page). In response to activating the "Print Now" button on the appropriate UI page, the print request CGI script 331 processes the user input data and creates the tmpdoc.dpsn document 354. The print request CGI script also pipes a message containing the print request to the new job pipe server 390 and stores the message in message queue 392. For each print request message, Message Queuing Handler 394 spawns a corresponding thread that parses the corresponding tmpdox.dpsn document 354, generates a document file 360, and submits the print request to job queue 356.
The following operations and logic displayed between the ends of these loops are performed on the print job, as shown in job queue loop start block 396 and job queue loop end block 397. To. First, in block 398, the next job is retrieved from job queue 356. The decision block 400 determines what kind of document the print job corresponds to. If the document is an application file, the logic goes to decision block 402, where it is determined what kind of file type should be used as the printing method. If the file requires an auxiliary application (eg MS Word, MS Excel, AutoCAD, etc.), the logic goes to block 366, where the document and the appropriate auxiliary application are loaded, as described above. When the file is loaded into the auxiliary application, it internally generates a file print command inside block 368, submits the file as before, and leaves it to the OS to print.
The decision block 404 then determines if a "completion" message has been received from port monitor 314. This determination is performed periodically or by the software's interrupt mechanism until a "completion" message is received. Then, in block 406, status monitor 316 is activated, sends print document 378 to target printer 374, and the job history data in DPS database 386 is updated as before.
Returning to decision blocks 400 and 402, the document type is a web page or printed directly by a driverless print server computer without an auxiliary application (eg, a PDF document or various types of image files). For file types that allow, the logic goes to block 364, where the browser on the DPS computer navigates to the URL of that web page, or uses the browser in some other way to get the PDF or image file. indicate. Once drawn, the rest of the print operation is performed as described above, starting at block 368. As mentioned above, if the document type is a printer file, the document will be sent directly to the Windows Print Spooler 376.
Figure 32 shows a flow diagram illustrating the logic and operations performed by the window processing component 343. As shown in the start block 450 of FIG. 30, the window processing thread is started at the beginning of decision block 362, immediately after the print action is called in block 368. As mentioned above, using the windowing component, various dialog boxes and messages that can be launched when loading an application, loading a document into an application, initiating a print action, during the printing process, and so on. -Process the box.
Returning to the flow diagram of Figure 32, the window processing thread determines if there are still desktop windows that must be examined in block 452 after startup. Such windows generally include a dialog box and a message box. If there are no more windows to look at, the thread terminates as shown in thread termination block 454. If there are still windows to look at, the logic goes to block 456 to get the window information for a window. On the MS Windows operating system, make the appropriate Windows API call to get the window information.
The decision block 458 then determines if the window is a child window of the drawing application (that is, whether it was generated by an auxiliary application or browser). If the decision is "no", the window does not respond to the drawing application and the logic proceeds to decision block 452 to evaluate the next window. If the answer to decision block 458 is "yes" (TRUE), the logic goes to block 460, where the window's text and control buttons are examined.
If the text matches the standard message string when determined by decision block 462, the logic goes to block 464, where the "close window" command is given internally and the user "closes" on the window. Emulates the behavior of activating the "Close Window" icon within the frame of a button or window. The logic then returns to decision block 452 and processes the next window.
If the text does not match the standard message string, the answer to decision block 462 is "no" (FALSE) and the logic goes to decision block 466, where the text is stored in windowing table 470 in DPS database 386. Determines if it matches the MessageText value in the corresponding entry list. If there is a matching value, the logic goes to block 468, where it looks up the data in the row of matching MessageText values and issues a table command to the Windows API based on the parameters given by the data. Run. For example, line 472 of the regular entry list is displayed above Figure 32. The line contains the MessageID, Wparam, and Lparam values, Windows Information related to API is stored. Use these parameters to call the corresponding API to perform the desired operation of processing the window. When the table command is executed, or if the answer to decision block 466 is "no" (FALSE), the logic returns to decision block 452 and begins processing the next window.
User account setup With reference to Figures 33-37, the system has various user interface screens that allow users to set up their own accounts and configure various parameters such as network, printer, fax and contacts. As mentioned above, these UI screens typically include HTML-based web pages with wired and wireless network access, and WAP-based cards for devices that access the system via a cellular infrastructure. A setup process with multiple operations is displayed on Web page 500 in Figure 33. These operations include setup start operation 502, file server access setup operation 504, favorite printer setup 506, fax setup operation 508, contact list setup operation 510, and setup end operation 512. is there. Prior to setting up the various parameters available through these operations, the user has registered with the system using standard user authentication methods with a username and personal identification number PIN.
The user initiates the setup process by logging in to the system and navigating to either the account setup screen or the settings screen. Multiple navigation methods can be used to access a variety of screens, including content as described below. During the setup operation, the user determines the parameters for one or more file servers for which he wants to access the source data from subsequent user sessions. Web page 500 allows users to define server names (ie, aliases) and corresponding server addresses in edit boxes 514, 516. The user also enters the account name and password in edit boxes 518 and 520, respectively, and the confirmation password in edit box 522. Finally, the user selects a file server type from pull-down list 524. After entering all the parameters, the user will see "ADD SERVER" Activate the NOW (Add Server Now) button 526 and the web page returns the parameters to the message center that hosts the web page. These parameters are then stored in the network site table in the message center database 228.
FIG. 34 illustrates Web Page 500A, which shows how Web Page 500 is displayed after a user has added multiple servers. As shown in server name column 528, the user can name the server, but the name can be any name you like (within reasonable length limits, such as up to 32 characters). The network site table references the subscriber table via the SUB_ID foreign key and uses the surrogate primary key (SITE_ID), which can be confusing even if multiple users use the same server name, such as myServer or home_network. Does not cause. However, the only server that the user can see is the server that the user has already registered.
The user uses either the IP address (for example, 200.221.219.218) or the domain name (for example, ftp.prlsip.com) to provide the server (host) address, as shown in host address column 530. Can be identified. The file server type column 532 displays a list of server types for the server added by the user. Activate the EDIT button 534 to make changes to these parameters, and use the REMOVE button 536 to delete the server.
After setting up their server, users activate the NEXT> button 538 and make the setup process their favorite printer setup operation, as shown on web page 540 of Figure 35. Proceed to 506. At this time, the user is presented with two options for selecting the printer (that is, the output device). Activating the SELECT button 542 allows the user to search for a printer in a preconfigured print list, and activating the SEARCH button 544 allows one user. Alternatively, the printer can be searched via multiple input parameters. Generally, preconfigured print lists are composed by administrators with respect to the company or company they work for via another set of administrative web pages available only to the administrator. The user is presented with a list of printers, from which the user can select one or more printers as "favorite" printers.
Activating the "SEARCH" button 544 provides the user with web page 546. This web page provides multiple edit boxes that users can select to enter search information: City Edit Box 458, State Edit Box 550, and Postal Code Edit Box 552. , "By business" editing box 554, "By printer / nickname" editing box 556, "By printer manufacturing" editing box 558, "By printer model" editing box 560, etc. "SEARCH In response to activating the NOW button 562, the system attempts to identify registered printers that are available to the user and meet the user's search criteria. For example, an exemplary set of three printers returns the value Washington entered in the "State" edit box 550 as a response to the search criteria. You can then add to the user's printer list by selecting the printers in the returned list and checking the checkbox 564 corresponding to each row in the list. The user then activates the FINISHED button 566 to save the selected printer and return the user to web page 540 (A). At this time, the Web page displays the printers already selected in the Favorites Printer List 568. The user can remove the printer from the list using the activation button 570 if desired.
After adding the printer to his favorites list, the user activates the "NEXT>" button 572 and proceeds with the setup process to fax setup operation 508. This will take the user to a series of fax setup web pages (not shown). These pages allow the user to select the default outgoing fax and configure the facsimile cover page. The user can then use a set of contact list setup pages (not shown) to select and add contact information when performing contact list setup operation 510. it can. Contact information allows users to send documents and faxes to people on their contact list with relative ease.
Example of WAP UI As described above, in one embodiment, a wireless web-enabled device can be used to access the system through the WAP gateway 110 (FIG. 20). The WAP interface has a "pair of cards" that are roughly similar to HTML-based web pages, except that they are WML-encoded and contain significantly less data. In addition, the WAP card is designed for navigation with a minimal user interface. With reference to the legend in Figure 38, details of the various WAP cards and operations corresponding to the WAP-based user interface example are shown in Figures 39-52. In one embodiment, a set of CGI scripts is used to automatically generate a WAP card.
With reference to Figures 39 and 40, the user accesses the system with a WAP-enabled device as follows. First, the user accesses his wireless Internet gateway as described above. The user then enters the URL of the system, either directly or through a memorized link (ie, a favorite link, etc.). The splash screen 600 corresponding to WAP card 1 is displayed to the user. At the first part of login, the system identifies the wireless device (for example, using a cellular number or other unique identifier) and the subscriber table in the message center database 228 via database query 601. Attempts to find the corresponding information for the device using If the device is recognized, the user has already registered the device with the system. Therefore, the login screen 602 corresponding to the WAP card 2 is displayed to the user. The screen displays the user's first name (or other identifier) based on the information already entered in the subscriber table, prompting the user to enter their PIN. If the PIN you enter matches the stored PIN, the user logs in to the system. If they do not match, a screen 604 is displayed asking the user to re-enter the PIN. If the PIN entry fails again, a screen 606 is displayed asking the user if he or she wants to send the PIN to the user by email.
If the user's wireless device is new to the system, the result of database query 601 is Null and the logic goes to the initial input screen 606, where the user enters the username and PIN. If the PIN you entered is invalid, the device will display a screen 610 asking you to enter a new PIN. If the PIN can be entered successfully, a confirmation screen 612 is displayed to the user. Referring to FIG. 40, when the username and PIN are entered, the database query 613 consists of a subscriber table to retrieve the user's email address. If the user is a new user or the email address cannot be found, the user is prompted to enter the email address via screen 614. If an existing user email address is found, the entry in the subscriber table for the new device is updated via database query 616. Separately, when a new username, PIN, and email address are entered, a new subscriber record is inserted into the subscriber table via database query 618.
After verifying the user, use database query 622 to determine if the user already has a configured network site. If the user has already configured the network site, the logic proceeds to run CGI script 3, as detailed in Figure 41, otherwise the logic is the navigation shown in Figure 43. Jump to position 5.
Referring to FIG. 41, in response to the execution of CGI script 3, a site selection screen 624 is displayed to the user, which places the source data corresponding to the document that the user wants to print. You can select the network site you are using. If desired, the user can also select a new network site setting, in which case the logic will jump to navigation position 5.
When a network site is selected, CGI Script 4 starts executing and produces the network navigation screens 626, 628, and 630 shown in Figure 42. These screens allow the user to navigate the network site and browse the document files that the user wants to print. After the user selects a document, use CGI script 3 to generate screen 632 with the network site name and document file name. In addition, this screen allows the user to select the type of output he or she desires via print, fax, or email option 634.
Referring to FIG. 43, after jumping to navigation position 5, the setup screen 636 is displayed to the user. Using this screen, users can set up a variety of favorites, including network sites and printers, and determine fax and email information. When the network site option is selected, the user goes to the file server add screen 638, where the user URLs in the same way as described above for adding a new network site via web page 500. Alternatively, you can add a new network site by providing an IP address, username and password. As before, the username and password relate to the particular network being added. After choosing to add to the network site, the user is presented with a confirmation screen 640. After the user chooses to add a network site using the "OK" option, CGI script 9 is executed and entered data via database query 642, as shown in Figure 44. Is stored in the network site table, where a screen 644 confirming that the server has been added is drawn on the user's device.
In response to the selection of fax options on screen 636, the user is presented with the Add Fax screen 646, which allows the user to enter a new fax by specifying a name and fax number. After the user chooses to add fax data, a confirmation screen 647 is displayed, after selecting the OK option, CGI script 11 is executed and faxed via database query 648, as shown in Figure 46. / Insert a new record into the email table (FET). The user is then presented with a screen 650 confirming that the fax data has been added.
Similarly, in response to selecting the email option from screen 636, the add email screen 652 is displayed to the user, where the user enters the email name (ie, alias) and email address. In addition, if you choose to add new email information, a confirmation screen 653 will be displayed. After accepting with the OK option, CGI script 12 is executed to insert a new record into the FET table via database query 654, as shown in Figure 47. The user is then presented with a screen 656 confirming that the email data has been added.
As shown in Figure 45, in response to selecting the printer option on screen 636, the add printer screen 658 is displayed to the user, where the user sees web pages 540, 546 above. The printer to be added can be selected by the same search conditions as described in. After the user chooses to add a printer from the picklist returned, a confirmation screen 660 is displayed, the OK option is selected, and then a new record is inserted into the printer table via database query 662. The user is then presented with a screen 664 confirming that a new printer has been added.
Returning to screen 632 in Figure 41, after selecting a document file, you can either print the document to the selected printer, fax the document to the selected fax machine (by the machine's fax number), or print. Documents can be sent by fax to selected e-mail recipients using fax, e-mail option 634. When the print option is activated, CGI script 13 is launched and the printer selection screen 666 shown in Figure 48 is generated. This screen allows the user to select one of several printers that have already been added to the user's favorite printer list. After selecting a printer in the list, the user is presented with a configuration screen 668 that identifies the document to print and the selected printer. When the OK option is activated, CGI script 16 is executed, as shown in Figure 52. According to the print request, the corresponding print job is put into the print queue table via database query 670 and the job queue confirmation screen 672 is displayed to the user. After being queued, the print job is processed by the appropriate combination of message center, RDC, and print service, and the document is printed to the selected printer as described above.
Activating the fax option on screen 632 launches CGI script 14 and generates the fax selection screen 674 shown in Figure 49. On this screen, the user can select one of the faxes already added to the user's favorite fax list, or enter the number of a fax machine that has not yet been set up in the fax list. Can be done. If the user chooses to enter the latter number, screen 676 will be displayed and the number can be entered there. If you select the OK option on screen 676 or select the preconfigured fax on screen 674, a confirmation screen 676 is drawn. If you select the OK option, CGI script 16 is executed, where fax job information is inserted into the fax / email queue table via database query 678. After being queued, the fax job is processed by the appropriate message center, which produces fax data corresponding to the document in a manner somewhat similar to the printing service processing the document for printing. And sent to the destination fax machine based on the fax number.
Processing of email requests proceeds in a manner similar to fax requests. This process is started by activating the email option on screen 632, as shown in Figure 50, and the CGI script 15 is launched. This CGI script first generates an email selection screen 682, where the user selects an email address and sends the document to the configured list of the user's favorite email recipients, or yet You can enter someone's new email address that is not configured. If the user chooses to manually enter an email address that is not in the list, a screen 684 will be displayed where the user can enter the address. If you select the OK option on screen 684 or select the preconfigured email recipient on screen 682, the confirmation screen 686 is drawn. If you select the OK option, CGI script 16 is executed, where the email job information is inserted into the fax / email queue table via database query 678. The email job is queued and then processed by the appropriate message center to generate an email message with the selected document file attached from the recipient's email address or screen 684. It will be sent to the email address you entered. You can optionally include the content of the document in the body of the email. Details of e-mail generation are described in US Simultaneous Patent Application No. xxxxx, entitled "METHOD AND SYSTEM TO PRINT VIA E-MAIL," filed March 21, 2002. All documents and drawings are incorporated herein by reference.
Returning to screen 606 of Figure 39, in response to a request for a user to send their PIN by email, the system searches the Message Center database 228 for that user's PIN and identifies the user by name. Automatically generate an email with an identified and PIN and send the email back to the user to the user's already registered email address. The CGI script 17 is then executed, as shown in Figure 52. If the e-mail message is sent successfully, a screen 688 is drawn to identify such ones. If there is an error sending the email address, the error message corresponding to screen 690 is drawn.
Document Preview Navigation One of the optional output methods for job requests is document preview. Due to the generally limited display capabilities (eg small screen, non-standard aspect ratio, low pixel resolution), generate a preview to see what the document will look like when drawn to the output device. Doing is an important task, rather than a daunting task. Moreover, the response time required for the preview request is considerably stricter than that for the print request. Output management systems address these challenges in two directions. For image files, create dithered thumbnails and adjust the final output size to fit the vertical and horizontal dimensions without losing the aspect ratio. For non-image files, convert the file to plain text format without losing the relationship between the pages, divide each page into a series of cards, link those cards by reference, and organize the page navigation vertically. Allows you to do it directionally and laterally.
Display 700 in FIG. 53 illustrates how this conversion is done. This process begins with the original image 702. In the first row, thumbnail 704 is output based on the display capability of palm device 706, and in the second row, thumbnail 708, which is smaller than that, corresponds to the considerably low resolution of the screen of the cellular 710. .. Note that cellular thumbnails do not cover the entire screen to preserve the aspect ratio.
Display 712 in FIG. 54 describes the display conversion process for a text document. As mentioned above, the text pages of the output document are divided into WAP cards based on the text flow. For example, the first 256 bytes of the page are converted to the first card (label "1"), the next 256 bytes are converted to the second card, and so on. The images in the original text page are replaced by image links in the card, as shown by image link 714 and preview image 716, respectively, to indicate their placement in the original context. Users can use these links to preview the images generated based on the image display transformation mechanism described above. Using this layout, you can not only navigate the page up and down, but also navigate to another page. Since the page relationships are preserved, the user can also preview those pages with random access.
In addition to sequential text documents, the system can also preview spreadsheet-type documents, as shown in Display 718 in Figure 55. The difference between a regular (ie, sequential text) document and a spreadsheet preview is that the spreadsheet preview needs to preserve the physical layout. Therefore, the spreadsheet preview should be created within both the vertical and horizontal dimensions. The example in Figure 55 is a two-page spreadsheet document that is converted to two nine-card preview pages, each containing two or more links (if applicable) to navigate to other pages. It corresponds to. For example, the first card 720 includes a "right" link 722 to card 724 and a "bottom" link 726 to card 728. It also has links for navigating between pages. Since the page relationships are preserved, the user can also preview those pages with random access.
Instant Messaging Integration With the rapid spread and popularization of instant messaging technology, instant messaging has become a huge system of connecting users. Instant messaging allows users to exchange text messages, chat, image or voice greetings with friends and family in a simple, realistic way. However, because it was originally designed for text exchange, sharing of information or resources was generally not allowed. Therefore, an output management system may intervene to make up for the shortfall.
The system allows instant messaging users to share their resources with their peers. Resources are not limited to their type, connectivity (internal or external, network or local), or execution platform as long as the device is shared on the network. Resources include files, floppy (registered trademark) and compact disk drives, and Network File Systems (ie, co-star files and directories, etc.). When the user announces that the shared resource is available, their sources will be visible to their peers. Friends can press a button to download a file from another person's local directory, drag and drop the file onto another person's floppy or compact disc, and click the drive link to make another person's local. · Remote desktop client enabled without any significant repetitive system management tasks other than displaying the drive directory and deploying the output management system all once within the instant messaging operations domain. All you have to do is get the user to run your instant messaging tool.
To perform resource sharing within an instant messaging domain, the instant messaging client must have Remote Desktop Client functionality. Remote Desktop Client allows client machines to announce shared resources by registering with the Message Center. Once registered, the client machine can send and receive resource sharing requests. For better performance, instant messaging operators prefer to install a dedicated message center to manage their clients instead of relying on the root message center.
A display 729 illustrating an example embedded implementation of instant messenger is shown in Figure 56. In this example, the two public message centers MC1 and MC2 each have a built-in print service and are located within the instant messaging (IM) operating network 730. These message centers are registered with the root message center MC0 in zone 0. The user of each instant messaging client 732 runs a remote desktop client on the same host and is registered with one of the message centers in the IM operator network 730. In this configuration, all users of the instant messaging client can access each other's shared resources without contacting the root message center. If desired, IM network operators can also install more message centers to extend the system for better performance.
The system described utilizes the new architecture of Microsoft Windows for device sharing. For example, when using a printer driver, the device driver for a Windows shared printer can be delivered to other hosts through a remote desktop client when requested. After downloading and installing the printer driver, the user can access another person's printer as a shared network device. This extends the concept of device sharing in Windows to a wider range. The network in this configuration extends to the entire instant messaging network instead of LAN. Instant messaging users can then output the document to their respective shared devices as if they were connected to the same LAN, while the remote desktop client was doing all the work.
Integration of Multimedia Messaging Services Until very recently, wireless computing was still limited to text-based applications due to the generally low network bandwidth and lack of processing power of wireless devices. Recently, some carriers have introduced support for a wide range of services, such as WAP applications. The initial response was trivial, but it was thought that most wireless carriers would offer services that users would want to experience. This requires higher network bandwidth, more powerful hardware, and more powerful devices. The era of "3G" (third generation) wireless communications has arrived, thanks to the efforts of carriers, infrastructure providers and device makers.
Many mobile device makers have embarked on the development of 3G services such as video clips, MP3s, slide shows and video conferencing. These fall into the general category of multimedia wireless solutions. The architecture of this system complements such multimedia and mobile computing environments by providing a common platform for multimedia output management. Figure 57 shows the display 734 for a multimedia integrated system called Multimedia Messaging Service (MMS) under development by one of the industry leaders, Nokia.
In this example, both the inbound gateway 736 and the outbound gateway 738 are deployed to connect to the MMSC and the message center MC1 in the egress management network 740. The inbound gateway receives mobile outbound MMS requests from the MMS-enabled device 742, translates those requests, sends them to the message center MC1, and further processes them. Typical requirements are storing movie clips on a shared file server, outputting picture images to a color laser printer, or outputting MP3 audio messages to the output management system-driven instant messaging described above. It may be relayed to the client. The outbound MMS gateway receives general requests from output management clients to MMS devices. It translates the request into MMS format and sends it to the Multimedia Messaging Service Center (MMSC) 744 for delivery. The system can use the optional root message center in MMS Operations Network 746 to support efficient resource sharing between MMS-enabled message centers and clients. In one embodiment, the inbound and outbound gateways can be co-located (ie, hosted on the same device) to minimize hardware costs. This architecture uses an output management system as a bridge to take advantage of MMS services to non-MMS clients. The general concept of multimedia messaging service integration can be applied to any type of multimedia service by simply modifying the inbound gateway's incoming interface and the outbound gateway's outgoing interface. The rest of the output management system remains unchanged.
Document Access / Printing Behind the Firewall Using a Secure CGI / VPI Proxy As mentioned above, this system allows users to view documents that are located on the private network behind the firewall. You can access resources, including output devices. In previous architectures, this functionality was achieved using persistent communication channels between message channels over the firewall. See Figure 58, another way to do this is via a CGI / VPN proxy user. As illustrated in the figure, different users of the system choose the route of communication for public users from the public network (eg, Internet 60) through the CGI VPN proxy 752 located in the DMZ 754. -Interface 750 can be configured. Then CGI VPN, DMZ Select a communication path through a VPN switch 756 with secure passthrough through a firewall 758 that provides security between the 754 and the private intranet 760. Next, the VPN switch sets the inbound communication route to the message center MC1 located in the intranet 760. There are also three private resources on the intranet, including the print service PS1, the file store FS1, and the output device D1.
According to the architecture described, public users use a VPN link between a publicly accessible user interface (that is, the Web and WAP UI) and a message center located within a private network. Is allowed access to private resources. If the security of the web and WAP UI is secured, for example, using user authentication or optional encryption techniques, only authorized users can access the VPN link, and therefore the security of Firewall 756. Function is maintained. In addition, it uses a secure CGI / VPN proxy, which virtually eliminates hacking into private networks through the proxy.
This implementation extends the functionality of the system and eliminates the need for a publicly accessible message center. For example, companies want to be able to find and print documents stored on one or more private enterprise networks when sales reps are away from headquarters. .. By combining a CGI / VPN proxy with a private MC, these sales reps can access the file store in the private enterprise network and any documents stored in the file store are registered with the private MC. Can be printed on the output device of.
Another way to access the private MC through the VPN switch is to use J2ME (Java® 2 Micro Edition) + VPN compatible device 762. Such devices are currently under development, but are expected to be available soon in the near future. In essence, J2ME + VPN-enabled devices incorporate a VPN client that allows the device to communicate directly with the VPN switch without the need for a VPN proxy user, as shown in Figure 58.
Printing to a resource on a private network without MC
As shown in Figures 59A and 59B, it is possible to configure the system to print to output devices located on a private network that does not include a message center. For example, in configuration 764 shown in Figure 59A, the message center MC1 is located in the DMZ 754 and the destination printer D1 is located in the appropriate private intranet 760, which is separated from the DMZ by the firewall 758. Has been done. In this configuration, a persistent connection 764 is set up between the remote desktop client RDC1 located with the private intranet and the message center MC1.
During the setup operation, the remote desktop client RDC1 initializes communication with the message center MC1 and opens a communication link corresponding to persistent communication 766 with the message center. The RDC then sends the data to the message center MC1 and identifies the output device connected to it (in this case, the output device (D1)). This information is stored in the RPRM database 242 of message center MC1.
An example of a print operation corresponding to configuration 764 proceeds as follows. First, a user on the originating device, such as the Cellular 768, connects to the Message Center MC1 through the UI 750. Through the UI, the user selects the remote source document to be printed, for example, stored on the file store FS1 located in the DMZ 754. Optionally, documents can be retrieved from other DMZs or private networks (not shown), depending on the configuration of other MCs and the location of other file stores. Of course, the user can also select and print a local source document stored on the source device.
After selecting the document, the user will select the output device, in which case the output device D1 is selected. After confirming the print request, the print service PS searches the file store for the source document or sends it to the print service if the document was a local resource. The MC also sends information to the PS that identifies the device capabilities of the selected output device. The print service then generates the output image data for the source document and the selected output device and places the output image data as an output image file in a repository (eg, in file store FS1). Store in). The PS then notifies the message center MC1 that the job is complete with a reference to the output image file. The Message Center then retrieves the output image file and forwards it to the remote desktop client RDC1 over a persistent connection 766. After receiving the image data file, RDC submits it to output device D1 to draw it. Upon completion, the RDC sends a notification to Message Center MC1 via a persistent connection 766, which then updates the UI 750 to notify the user that the print job is complete.
Another configuration 770 with the same final result is shown in Figure 59B. In this example, all components are the same as in Figure 59A, except that VPN switch 756 and VCN clients 722, 774 are added. In this example, the message center MC1 and the remote desktop client RDC1 communicate over VPN channel 776. By using the VPN channel, you can increase the security level of Private Intranet 760.
The above description and accompanying drawings have disclosed embodiments of the invention that implement the operation of the software provided by the MS Windows operating system components. This does not imply limiting because the principles and teachings of the present invention are applicable to implementations in which other operating systems are used, such as UNIX-based operating systems and LINUX-based operating systems. For example, various UNIX and LINUX operating systems are supported by OS kernel components that perform operations similar to the MS Windows print support components described above (eg, Windows GDI, print spoolers, printer drivers, etc.). It has a built-in graphical user interface, application API, and printing function.
Example of a server computer system With reference to FIG. 60, the conventional computer server 800 is generally described, but it is suitable for use in connection with the practice of the present invention and is not the same. Computers can be used for DPS server computers and web server computers that are used to perform web server operations. Examples of computer systems that may be suitable for these purposes include computer servers running Microsoft Windows, UNIX-based, and LINUX-based operating systems.
Computer server 800 is generally equipped with suitable integrated circuits, including one or more processors 804 and memory (eg, DIMMs or SIMMs), as is familiar to those skilled in the art. It has a chassis 802 with a motherboard (not shown). The monitor 808 is provided to display the graphics and text generated by the software programs and program modules executed by the computer server. The mouse 810 (or other pointing device) can be connected to a serial port (or bus port or USB port) on the back of the chassis 802, which allows the signal from the mouse 810 to be transmitted to the motherboard. A software program or module running on your computer controls the cursor on the display to select text, menu options, and graphic components that appear on the monitor 808. In addition, the keyboard 812 is coupled to the motherboard to allow the user to enter text and commands that affect the execution of software programs running on the computer. The computer server 800 also incorporates a network interface card (NIC) 814 or equivalent circuit within the motherboard that allows the server to send and receive data over network 816.
The storage of the file system corresponding to the present invention is a plurality of hard disks 818 housed inside the chassis 802 and / or an external disk accessible via a SCSI card 822 embedded in the motherboard or an equivalent SCSI circuit. -Can be mounted via multiple hard disks housed within the array 820. Optionally, the disk array 820 can be accessed using Fiber Channel links using the appropriate Fiber Channel interface card (not shown) or embedded circuitry.
The computer server 800 can typically include a compact disk read-only memory (CD-ROM) drive 824, which inserts the CD-ROM and reads the executable files and data on the disk into memory 806 and / Or can be transferred to storage on the hard disk 818. Similarly, floppy drive 826 can be provided for such a purpose. Other high capacity memory storage devices such as optical recording media or DVD drives can also be provided. Machine language instructions, including software programs, components, and modules that cause the processor 804 to perform the operations of the invention described above, are typically floppy disks 828 or CD-ROMs. Distribute on 830 (or other memory medium) or store on one or more hard disks 818 and load into memory 806 when run by processor 804. Optionally, machine instruction can be loaded as a carrier file over network 816. As mentioned above, embodiments of the present invention may be implemented in some form of processing core (such as a computer CPU) or implemented or implemented on or in a machine-readable medium by some other method. It can be used as an realized software program or can be used to support that software program. A machine-readable medium comprises a mechanism for storing or transmitting information in a machine-readable format (eg, a computer). For example, machine-readable media can include read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage devices, flash memory devices, and the like. Further, the machine-readable medium can include propagating signals such as electrical, optical, acoustic, or other forms of propagating signals (eg, carrier waves, infrared signals, digital signals, etc.).
Accordingly, embodiments of the present invention are software that is executed in some form on a processing core (such as a computer CPU) or implemented or implemented on or in a machine-readable medium by some other method. It can be used as a program or to support its software program. A machine-readable medium comprises a mechanism for storing or transmitting information in a machine-readable format (eg, a computer). For example, machine-readable media can include read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage devices, flash memory devices, and the like. Further, the machine-readable medium can include propagating signals such as electrical, optical, acoustic, or other forms of propagating signals (eg, carrier waves, infrared signals, digital signals, etc.).
The above description of embodiments of the drawings of the present invention, including the contents of the abstract, is not intended to be exhaustive, nor is it intended to limit itself to the exact form in which the invention is disclosed. Certain embodiments of the invention and examples thereof are for purposes of illustration herein, but within the scope of the invention, various equivalent modifications are possible, as will be appreciated by those skilled in the art. Is.
These modifications can be made to the present invention in the light of the above description. The terms used in the claims should not be construed as limiting the invention to the particular embodiments disclosed in the specification and claims. Rather, the scope of the invention is entirely determined by the claims to be construed in accordance with the established principles of the interpretation of the claims.
<figref num="1">It is a block schematic diagram illustrating various tasks performed by the Message Center (MC).</figref><figref num="2">It is a block schematic diagram exemplifying various tasks performed by a print service (PS).</figref><figref num="3">It is a block schematic which illustrates various tasks performed by a remote desktop client (RDC).</figref><figref num="4">FIG. 6 is a block schematic illustrating various tasks performed by a wireless data access point (WDAP).</figref><figref num="5">It is the schematic which illustrates the simple output management system implementation example.</figref><figref num="6">It is a schematic diagram exemplifying a more complicated output management system implementation example.</figref><figref num="7">It is a schematic diagram which shows the exchange of information between a root message center and a message center connected to a private network.</figref><figref num="8">It is a schematic diagram illustrating the setup operation used to establish a peer-to-peer message center connection.</figref><figref num="9">It is a flow chart which illustrates the exchange of information between an RDC and a message center according to an RDC client registration request.</figref><figref num="10">It is a flow chart corresponding to the RDC printer registration request.</figref><figref num="11">It is a flow diagram corresponding to the RDC submitting the device resource definition to the message center.</figref><figref num="12">It is a flow chart of public device queries sent to the root message center via the home message center.</figref><figref num="13">It is a flow diagram corresponding to a print (PBR) job request by reference issued by a user in the home domain to an output device directly connected to a print service in the home domain.</figref><figref num="14">It is a figure which shows the exchange of the information of the component corresponding to the PBR job request of FIG.</figref><figref num="15">It is a flow chart corresponding to a non-PBR job request issued by a user in the home domain to an output device directly connected to a printing service in the home domain.</figref><figref num="16">It is a flow chart corresponding to a PBR job request submitted by a user in the home domain to a local printer connected to a remote desktop client in the home domain.</figref><figref num="17">It is a figure which shows the exchange of the information of the component corresponding to the PBR job request of FIG.</figref><figref num="18">A flow diagram corresponding to a PBR job request submitted by a user in the home domain (eg, zone 1) and printed on the root message center's public output device (D1).</figref><figref num="19">It is a figure which shows the exchange of the information of the component corresponding to the PBR job request of FIG.</figref><figref num="20">It is a schematic diagram illustrating three main access mechanisms for exchanging information with the message center in the system.</figref><figref num="21">FIG. 6 illustrates an operation used to determine a dynamic default printer when a user submits a job request via WDAP.</figref><figref num="22">FIG. 6 illustrates an operation used to determine a dynamic default printer when a user of a Bluetooth-enabled source device submits a job request through a WDAP that includes a Bluetooth device emulator.</figref><figref num="23">It is a schematic diagram of a system connection topology showing various connection paths and connection types that can occur in a normal implementation of an output management system.</figref><figref num="24">It is a flow chart which exemplifies the operation performed at the time of processing a job request processed through a zone / message center and a public RDC.</figref><figref num="25">It is a schematic block diagram corresponding to the four-layer architecture by one Embodiment of this invention.</figref><figref num="26">It is a block schematic illustrating the corresponding database schema used to implement the operations provided by the various software modules and message centers.</figref><figref num="27">It is a block schematic which illustrates various software components implemented by a print service.</figref><figref num="28">It is a block schematic which illustrates various CGI scripts used by a printing service.</figref><figref num="29">It is a block schematic which illustrates various software components implemented by a driver print server.</figref><figref num="30">It is a schematic diagram illustrating a typical data flow process corresponding to a print request submitted to a print service.</figref><figref num="31">FIG. 6 is a combination of a schematic and a flow diagram illustrating other operations and logics realized by the driverless print server software of the print service.</figref><figref num="32">A flow diagram and a schematic diagram illustrating the operations and logic used by the window processing component to handle the various dialog and message boxes that are launched when processing a print job.</figref><figref num="33">Diagram of a web-based user interface (UI) that users can use to set up file server access through an output management system.</figref><figref num="34">FIG. 33 is a diagram of the web-based UI in Figure 33 after setting up multiple file servers to be accessible.</figref><figref num="35">Diagram of a web-based UI that users can use to set up a list of their favorite printers.</figref><figref num="36">Diagram of a web-based UI that users can use to search for printers that have already been configured by a system administrator.</figref><figref num="37">FIG. 35 is a diagram of the web-based UI in Figure 35 after adding multiple printers to the list of favorite printers.</figref><figref num="38">A legend corresponding to the details of the WAP-based user interface in Figures 39-52.</figref><figref num="39">This is the first part of the WAP UI flow diagram that corresponds to the subscriber login process.</figref><figref num="40">This is the second part of the WAP UI flow diagram in Figure 39.</figref><figref num="41">It is a flow chart of WAP UI corresponding to the CGI script subOutputIndex.pl.</figref><figref num="42">It is a flow chart of WAP UI corresponding to a set of cards that enables searching of documents output by network navigation.</figref><figref num="43">A flow diagram of the WAP UI for adding network sites, fax machines, and email addresses.</figref><figref num="44">A WAP UI used to notify a user that a network site has been added to the user's network site list.</figref><figref num="45">It is a flow chart of WAP UI corresponding to adding a new printer to the list of favorite printers.</figref><figref num="46">A WAP UI used to notify a user that a fax machine has been added to the user's fax list.</figref><figref num="47">The WAP UI used to notify the user that the email name has been added to the user's contact list.</figref><figref num="48">It is a flow chart of WAP UI corresponding to the confirmation of the selected document and output device.</figref><figref num="49">It is a flow diagram of WAP UI corresponding to adding a new fax to the user's favorite fax list.</figref><figref num="50">It is a flow diagram of the WAP UI corresponding to adding a new e-mail contact to the user's contact list.</figref><figref num="51">It is a flow chart of WAP UI corresponding to inserting a print job, a fax job, and an e-mail job into the corresponding job queue.</figref><figref num="52">It is a flow chart of the WAP UI showing whether or not the PIN was correctly sent to the user via e-mail in response to the user's send request.</figref><figref num="53">FIG. 5 illustrates how to convert an original document image into thumbnails of various sizes for previewing a document on a device that uses a low resolution screen.</figref><figref num="54">It is a schematic diagram showing a method of browsing a part of a text-based document and previewing how the document is displayed when output to a selected output device.</figref><figref num="55">It is a schematic diagram which shows the method of browsing the part part of the document of spreadsheet software and previewing how the document is displayed when it is output to the selected output device.</figref><figref num="56">It is a schematic diagram illustrating how to extend the architectural principles of an output management system to support resource sharing via instant messaging services.</figref><figref num="57">FIG. 6 is a schematic diagram illustrating how to use the system via a multimedia messaging capable device.</figref><figref num="58">It is a schematic diagram illustrating how to implement a CGI VPN proxy to enhance the security of a private network that contains the resources used by the system.</figref><figref num="59A">FIG. 5 is a schematic diagram illustrating a first configuration that enables access to output devices located on a private network that does not include a message center.</figref><figref num="59B">FIG. 5 is a schematic diagram illustrating a second configuration that allows access to output devices located on a private network that does not include a message center.</figref><figref num="60">FIG. 5 is a schematic representation of an example computer server used as a host for various components of the system, including a message center and print services.</figref>
80 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46 Sheet 47 Sheet 48 Sheet 49 Sheet 50 Sheet 51 Sheet 52 Sheet 53 Sheet 54 Sheet 55 Sheet 56 Sheet 57 Sheet 58 Sheet 59 Sheet 60 Sheet 61 Sheet 62 Sheet 63 Sheet 64 Sheet 65 Sheet 66 Sheet 67 Sheet 68 Sheet 69 Sheet 70 Sheet 71 Sheet 72 Sheet 73 Sheet 74 Sheet 75 Sheet 76 Sheet 77 Sheet 78 Sheet 79 Sheet 80
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2016099843A | Cited by | Japan | Search report |
| US9686431B2 | Cited by | United States of America | Applicant |
| JP2006227854A | Cited by | Japan | Search report |
| US10575341B2 | Cited by | United States of America | Applicant |
| JP2007122739A | Cited by | Japan | Search report |
| JP2016099843A | Cited by | Japan | Search report |
| US8411291B2 | Cited by | United States of America | Applicant |
| JP2007110378A | Cited by | Japan | Examiner |
38 members in 8 offices
Priority claims29
| Document | Office | Kind | Date |
|---|---|---|---|
| 31441201 | United States of America | P | |
| 31441201 | United States of America | P | |
| 60314412 | United States of America | – | |
| 35175402 | United States of America | P | |
| 35175402 | United States of America | P | |
| 60351754 | United States of America | – | |
| 10098832 | United States of America | – | |
| 9883202 | United States of America | A | |
| 9883202 | United States of America | A | |
| 10104528 | United States of America | – | |
| 10452802 | United States of America | A | |
| 10452802 | United States of America | A | |
| 10225582 | United States of America | – | |
| 22558202 | United States of America | A | |
| 22558202 | United States of America | A | |
| 0226791 | United States of America | W | |
| 0226791 | United States of America | W | |
| 2001314412 | – | – | – |
| 2002098832 | – | – | – |
| 2002104528 | – | – | – |
| 2002225582 | – | – | – |
| 2002351754 | – | – | – |
| 200226791 | – | – | – |
| US20010314412P | – | – | – |
| US20020098832 | – | – | – |
| US20020104528 | – | – | – |
| US20020225582 | – | – | – |
| US20020351754P | – | – | – |
| WO2002US26791 | – | – | – |
Members38
| Document | Office | Kind | |
|---|---|---|---|
| US2002138564A1 | United States of America | A1 | |
| WO02076175A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2002247382A1 | Australia | A1 | |
| WO02076175A9 | World Intellectual Property Organization (WIPO) | A9 | |
| WO03019389A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO03019403A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO02076175A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2003078965A1 | United States of America | A1 | |
| US2003079030A1 | United States of America | A1 | |
| US2003182378A1 | United States of America | A1 | |
| WO03081524A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2002308678A1 | Australia | A1 | |
| WO03019403A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1380194A2 | European Patent Office (EPO) | A2 | |
| KR20040029438A | Republic of Korea | A | |
| KR20040039304A | Republic of Korea | A | |
| TW588245B | Taiwan Province of China | B | |
| EP1428129A1 | European Patent Office (EPO) | A1 | |
| EP1428134A2 | European Patent Office (EPO) | A2 | |
| KR20040058105A | Republic of Korea | A | |
| CN1537298A | China | A | |
| JP2004535618A | Japan | A | |
| EP1490829A1 | European Patent Office (EPO) | A1 | |
| JP2005501341A | Japan | A | |
| CN1575458A | China | A | |
| CN1575460A | China | A | |
| JP2005521166A | Japan | A | |
| JP2005523489AThis record | Japan | A | |
| US6993562B2 | United States of America | B2 | |
| US2006294251A1 | United States of America | A1 | |
| US2007022180A1 | United States of America | A1 | |
| CN1307565C | China | C | |
| US2007168514A1 | United States of America | A1 | |
| JP4202272B2 | Japan | B2 | |
| EP1490829A4 | European Patent Office (EPO) | A4 | |
| US8019829B2 | United States of America | B2 | |
| US8024398B2 | United States of America | B2 | |
| US8065357B2 | United States of America | B2 |
5 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 2005523489
- Publication, DOCDB
- 2005523489
- Publication, EPODOC
- JP2005523489
- Application
- 2003523379
- Application, DOCDB
- 2003523379
- Application, EPODOC
- JP20030523379
Titles2
- Japanese
- プライベート・ネットワーク・リソースへのアクセスを可能にする出力管理システムと方法
- English
- Output management systems and methods that allow access to private network resources
Classification
- CPC, 20
- H04N1/00416
- H04L12/22
- H04L63/0272
- H04L63/029
- H04N1/32767
- H04L67/306
- H04L67/04
- H04L67/02
- H04L69/329
- H04L51/00
- H04W76/10
- H04W12/033
- H04L67/10015
- H04L67/59
- H04L67/1001
- H04L67/51
- H04L67/53
- H04L67/55
- H04L67/563
- H04L67/565
- IPC, 6
- G06F3 12
- H04L12 28
- H04L12 56
- H04L12 58
- H04L29 06
- H04L29 08
Designated states4
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo