U.S. patent application number 11/833148 was filed with the patent office on 2008-02-07 for configurable document server.
Invention is credited to William R. Harman, Byron D. Hunt, Jonathan Isabelle, Treber Rebert, Michael Riedel, Jason K. Webster.
Application Number | 20080030774 11/833148 |
Document ID | / |
Family ID | 38997880 |
Filed Date | 2008-02-07 |
United States Patent
Application |
20080030774 |
Kind Code |
A1 |
Webster; Jason K. ; et
al. |
February 7, 2008 |
CONFIGURABLE DOCUMENT SERVER
Abstract
A configurable document server is described. In some
embodiments, the configurable document server can enable
administrators to set an option that prevents documents from being
routed to users when the configurable document server experiences
some types of errors. When the configurable document server
determines that such an error condition exists, it may prevent the
routing of the corresponding document. By preventing documents
causing errors from being routed, the configurable document server
enables administrators to improve the accuracy of document workflow
and thereby improve productivity of users.
Inventors: |
Webster; Jason K.; (Tucson,
AZ) ; Riedel; Michael; (Tucson, AZ) ; Hunt;
Byron D.; (Tucson, AZ) ; Rebert; Treber;
(Tucson, AZ) ; Isabelle; Jonathan; (Tucson,
AZ) ; Harman; William R.; (Tucson, AZ) |
Correspondence
Address: |
PERKINS COIE LLP;PATENT-SEA
P.O. BOX 1247
SEATTLE
WA
98111-1247
US
|
Family ID: |
38997880 |
Appl. No.: |
11/833148 |
Filed: |
August 2, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60835228 |
Aug 2, 2006 |
|
|
|
Current U.S.
Class: |
358/1.15 |
Current CPC
Class: |
G06F 3/126 20130101;
G06F 3/1217 20130101; H04L 51/14 20130101; H04N 2201/0039 20130101;
G06F 3/121 20130101; G06F 3/1275 20130101; G06F 3/1288 20130101;
H04N 2201/0094 20130101; H04N 1/0022 20130101; H04N 1/00912
20130101; H04N 1/32641 20130101; H04N 1/324 20130101; H04N 1/32411
20130101; G06F 3/1208 20130101; H04N 1/32427 20130101 |
Class at
Publication: |
358/1.15 |
International
Class: |
G06F 3/12 20060101
G06F003/12 |
Claims
1. A method performed by a computer system for routing documents,
comprising: receiving a configuration specification indicating how
to handle documents with errors; receiving a document at a document
server; determining whether the received document is associated
with an error; when the received document is associated with an
error, preventing routing of the received document; and when the
received document is not associated with an error, identifying an
intended recipient and routing the received document to the
identified recipient.
2. The method of claim 1 wherein the configuration specification is
a configuration option that is set by an administrator of the
document server to indicate whether documents with errors should be
routed to intended recipients.
3. The method of claim 2 wherein the received document is a
facsimile document.
4. The method of claim 2 wherein the received document is a
facsimile document and the determining includes determining whether
a transmission error occurred when receiving the document.
5. The method of claim 1 further comprising causing a workflow
engine to suspend a workflow task when the received document is
associated with an error.
6. The method of claim 1 wherein the received document is
associated with an error when it cannot be converted from one
format to another.
7. The method of claim 1 wherein the received document is
associated with an error when it cannot be converted from an SMS
message to a facsimile document.
8. The method of claim 1 further comprising causing a workflow
engine to change a workflow task when the received document is
associated with an error wherein the change includes notifying a
user other than the identified recipient.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This patent application claims the benefit of U.S.
Provisional Patent Application Ser. No. 60/835,228, filed Aug. 2,
2006, entitled "Righffax Improvements" which is incorporated herein
in its entirety by reference. This patent application also
incorporates by reference commonly assigned U.S. patent application
Ser. No. 11/591,449, filed on Oct. 31, 2006, entitled "Queue
Processor for Document Servers," and U.S. Pat. No. 6,747,761, filed
on Oct. 29, 1996, entitled "Delivery Expert System and Method."
BACKGROUND
[0002] Computer networks generally enable data communications
between computing devices ("network nodes") that are connected to
such computer networks. Many such computer networks are
interconnected, such as via the Internet, and can have "transports"
that transport documents and other computer files between network
nodes. A document is a container for any type of digital content,
including facsimiles, voice messages, videos, word processing
documents, spreadsheets, and any other type of media, including
multimedia.
[0003] Conventional transports have various deficiencies. As an
example, conventional transports cannot intelligently select a
network from multiple available networks based on the type of
document that needs to be communicated between computing devices.
Instead, they generally use the same network to transport documents
without regard as to whether some networks may be better adapted to
transport a particular document type. Moreover, document servers
may not route documents even though documents may not be correctly
converted, received, or transmitted.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 is a block diagram illustrating a suitable computing
system in which aspects of the invention may be implemented.
[0005] FIG. 2 is a flow diagram illustrating a send_document
routine invoked by a Document Transport module in some
embodiments.
[0006] FIG. 3 is a block diagram illustrating use of the Document
Transport in some embodiments.
[0007] FIG. 4 is a block diagram illustrating a Document Transport
with MIME support.
[0008] FIG. 5 is a block diagram illustrating rules for
least-cost-routing and for store-and-forward document transport in
some embodiments.
[0009] FIG. 6 is a block diagram illustrating some of the queue
management done by separate protocols administered by Document
Transport.
[0010] FIG. 7 is a block diagram illustrating an environment in
which a configurable queue processor may operate in some
embodiments.
[0011] FIG. 8 is a block diagram illustrating operation of a
configurable queue processor in some embodiments.
[0012] FIG. 9 is a flow diagram illustrating a process_document
routine invoked by a document flow in some embodiments.
[0013] FIG. 10 is a flow diagram illustrating an
allocate_document_flow routine invoked by a configurable queue
processor in some embodiments.
[0014] FIG. 11 is a flow diagram illustrating a prevent_routing
routine invoked by the configurable document server in some
embodiments.
[0015] The headings provided herein do not necessarily limit the
scope of the invention.
DETAILED DESCRIPTION
[0016] Various embodiments of the invention will now be described.
The following description provides specific details for a thorough
understanding and enabling description of these embodiments. One
skilled in the art will understand, however, that the invention may
be practiced without many of these details. Additionally, some
well-known structures or functions may not be shown or described in
detail, so as to avoid unnecessarily obscuring the relevant
description of the various embodiments
[0017] The terminology used in the description presented below is
intended to be interpreted in its broadest reasonable manner, even
though it is being used in conjunction with a detailed description
of specific embodiments of the invention. Some terms may even be
emphasized below. However, any terminology intended to be
interpreted in any restricted manner will be overtly and
specifically defined as such in this Detailed Description
section.
[0018] A configurable document server is described. In some
embodiments, the configurable document server can enable
administrators to set an option that prevents documents from being
routed to users when the configurable document server experiences
some types of errors. As an example, an administrator can configure
the document server to prevent routing of inbound facsimile
messages when those facsimile messages are incomplete because of
transmission or reception errors. The configurable document server
may determine that an error has occurred when the inbound facsimile
was not completely transmitted, when the power fails, when the
connection terminates, or other error conditions occur.
Alternatively, the configurable document server may determine that
documents that could not be converted from one document format to
another because of an error should not be routed. When the
configurable document server determines that such an error
condition exists, it may prevent the routing of the corresponding
document. As an example, the configurable document server may
instead route the document to an administrator or identify the
document to the administrator. By preventing documents causing
errors, such as facsimile documents with transmission errors, from
being routed, the configurable document server enables
administrators to improve the accuracy of document workflow and
thereby improve productivity of users.
[0019] A configurable queue processor for document servers is
described. In some embodiments, the configurable queue processor
allocates server resources in an optimal manner such that document
servers can process documents efficiently. Server resources
include, e.g., processors, disk space, network bandwidth, etc. A
document server is a server that handles documents or otherwise
processes documents, such as servers that process facsimiles,
copies, print jobs, scanning jobs, optical character recognition
jobs, voice messages, document transmissions, document conversions,
archiving, and indeed any type of document processing request.
Document servers may receive multiple documents of various types.
The configurable queue processor allocates one or more "document
flows" to handle the incoming documents. A document flow is a
component of a document server that manages the processing of one
or more documents or document types. As an example, the
configurable queue processor may allocate multiple document flows
and configure each document flow to handle different types of
documents. The document flows receive documents they are configured
to handle from a queue and handle the documents according to each
document's type. The document flows can provide the received
documents to appropriate document handlers, such as for sending a
facsimile, making a copy, printing, optical character recognition,
etc.
[0020] In various embodiments, the document flows can retrieve
documents from a queue or may be provided documents by another
component, such as the configurable queue processor.
[0021] The configurable queue processor can be configured by a
user, such as an administrator, to allocate document flows in an
identified manner. As an example, an administrator may determine
that facsimile transmissions are to receive higher priority during
the day than another type of document processing service the
document server provides, but can receive a lower priority at
night. Alternatively, the configurable queue processor can allocate
document flows dynamically to balance system load. As an example,
the configurable queue processor may allocate an identified number
of document flows and, as server resources become available or are
consumed, can increase or decrease the number of document flows.
Alternatively, the configurable queue processor may increase or
decrease the number of document flows as the queue of documents
waiting to be processed increases or decreases. As an example, the
configurable queue processor may increase the number of document
flows that handle facsimiles as the number of waiting facsimiles in
the queue increases.
[0022] In some embodiments, the configurable queue processor may
increase the number of queues that hold pending documents.
[0023] In various embodiments, the configurable queue processor may
allocate document flows across one or more document servers.
Alternatively, each document server may have its own configurable
queue processor that allocates document flows on that document
server.
[0024] Thus, by using multiple document flows, the configurable
queue processor can tune system performance to manage a document's
time in the queue, such as by managing system performance or
resources. This permits flexible management of queues in document
servers, such as to prevent bottlenecks associated with the
processing of multiple document types, events, and network
protocols.
[0025] Various techniques can be employed to enable communication
between the configurable queue processor and allocated document
flows. These include shared memory, named pipes, remote procedure
calls, application programming interface invocations, etc.
[0026] The document flows that the configurable queue processors
create communicate with universal Document Transport ("DocTrans")
modules to process documents or forward documents for processing.
The DocTrans modules may be adapted for use with document servers
for recognizing document requests, interacting with routing rules
and workflow requirements, and generally managing document flows
between network nodes, including other document servers. The
DocTrans module can function with a document server (e.g., a
RightFax server) to recognize document requests, interact with
document routing rules and workflow requirements, and manage
document flows between network nodes or devices. The DocTrans
module provides to its operator multiple benefits over conventional
transports. Examples include providing a common processing
architecture for all message transports rather than requiring
individual processing engines for multiple transport types; having
common scheduling and queuing support for each transport type; and
selecting document- or hardware-specific processing tasks by
reference to the type of protocol. This feature is prevalent now
given the wide use of multifunction devices such as all-in-one
print/scan/copy/fax/telephone/answering machine devices, which may
be enhanced with audio & video capture, messaging, email,
network router & gateway capabilities. It is also a benefit to
use DocTrans modules to integrate messaging and workflow operations
when using standalone machines that perform these functions on a
network.
[0027] Various techniques can be employed to enable communication
between the configurable document flows and their corresponding
DocTrans modules. These include shared memory, named pipes, remote
procedure calls, application programming interface invocations,
etc.
[0028] The DocTrans module provides methods for transporting
documents between network devices, such as printers, fax boards,
and document servers (e.g., RightFax 9.0 facsimile server by
Captaris, Inc. of Bellevue, Wash.) across local and wide-area
networks, and permits document transport and routing optimization
with other types of communications networks (e.g., messaging
services, telephony, and Internet Protocol ("IP") networks).
Document servers can handle faxes and other documents, such as for
routing purposes. The module can route documents instead of, or in
addition to, a board server, such as a fax board server. The
DocTrans module routes documents in a manner that is similar to how
a board server routes documents, except that the DocTrans module
can route documents based on a document type or a transport's type
in addition to just phone number, user, group, and so forth. In
addition, the DocTrans module exposes an interface that permits
other types of document transport mechanisms (e.g., multi-function
devices, email, and SMS servers) to operate with various networks
systems, and to be extended so that routing operations (such
operations as StartTransmission, SendDocument, ReceiveDocument,
EndTransmission, or StatusCheck) can be readily used with other
network services.
[0029] The DocTrans module can be implemented as an independently
configurable software module that transports content and related
metadata across computer networks. It can function as a
communication layer between various computer networks and network
servers that perform discrete document creation, storage and
transmission tasks. The DocTrans module can operate independently
of the originating message service or source of a document to
perform operations on documents, such as send, receive, or cache
documents and messages, once a task is loaded, and can operate
independently to receive items (such as facsimile tasks) for
forwarding later. It permits flexible, programmable, and optimized
rules-based routing of documents in various message formats and on
multiple network types.
[0030] Conventional fax products did not provide board servers with
loading balancing capabilities or analysis of cost, time, or
security rules for routing across multiple types of document and
messaging protocols (e.g., MIME, SMS, T.37 fax, T.38 fax). By
contrast, the DocTrans module is extensible to perform document
transport and load equalization on virtually all document types and
network types using those messaging protocols. This feature is
prevalent now given the wide use of multifunction devices such as
all-in-one print/scan/copy/fax/telephone/answering machine devices,
which may be enhanced with audio & video capture, messaging,
email, network router & gateway capabilities. It is also a
benefit to use DocTrans modules to integrate messaging and workflow
operations when using standalone machines that perform these
functions on a network.
[0031] Turning now to the figures, FIG. 1 and the following
discussion provide a brief, general description of a suitable
computing environment in which aspects of the invention can be
implemented. Although not required, aspects and embodiments of the
invention will be described in the general context of
computer-executable instructions, such as routines executed by a
general-purpose computer, e.g., a server or personal computer.
Those skilled in the relevant art will appreciate that the
invention can be practiced with other computer system
configurations, including Internet appliances, hand-held devices,
wearable computers, cellular or mobile phones, multi-processor
systems, microprocessor-based or programmable consumer electronics,
set-top boxes, network PCs, mini-computers, wireless network
devices, mainframe computers and the like. The invention can be
embodied in a special purpose computer or data processor that is
specifically programmed, configured or constructed to perform one
or more of the computer-executable instructions explained in detail
below. Indeed, the term "computer", as used generally herein,
refers to any of the above devices, as well as any data
processor.
[0032] The invention can also be practiced in distributed computing
environments, where tasks or modules are performed by remote
processing devices, which are linked through a communications
network, such as a Local Area Network ("LAN"), Wide Area Network
("WAN") or the Internet. In a distributed computing environment,
program modules or sub-routines may be located in both local and
remote memory storage devices. Aspects of the invention described
below may be stored or distributed on computer-readable media,
including magnetic and optically readable and removable computer
discs, stored as firmware in chips (e.g., EEPROM chips), as well as
distributed electronically over the Internet or over other networks
(including wireless networks). Those skilled in the relevant art
will recognize that portions of the invention may reside on a
server computer, while corresponding portions reside on a client
computer. Data structures and transmission of data particular to
aspects of the invention are also encompassed within the scope of
the invention.
[0033] Referring to FIG. 1, one embodiment of the invention employs
a computer 100, such as a personal computer or workstation, having
one or more processors 101 coupled to one or more user input
devices 102 and data storage devices 104. The computer is also
coupled to at least one output device such as a display device 106
and one or more optional additional output devices 108 (e.g.,
printer, plotter, speakers, tactile or olfactory output devices,
etc.). The computer may be coupled to external computers, such as
via an optional network connection 110, a wireless transceiver 112,
or both.
[0034] The input devices 102 may include a keyboard and/or a
pointing device such as a mouse. Other input devices are possible
such as a microphone, joystick, pen, game pad, scanner, digital
camera, video camera, and the like. The data storage devices 104
may include any type of computer-readable media that can store data
accessible by the computer 100, such as magnetic hard and floppy
disk drives, optical disk drives, magnetic cassettes, tape drives,
flash memory cards, digital video disks (DVDs), Bernoulli
cartridges, RAMs, ROMs, smart cards, etc. Indeed, any medium for
storing or transmitting computer-readable instructions and data may
be employed, including a connection port to or node on a network
such as a local area network (LAN), wide area network (WAN) or the
Internet (not shown in FIG. 1).
[0035] FIG. 2 is a flow diagram illustrating a send-document
routine performed by the DocTrans module in some embodiments. The
routine may be employed by the facility to send a document, such as
a fax document. The routine begins at block 202 where it receives
an indication of a document as a parameter.
[0036] At block 204, the routine applies dialing or routing rules
to the indicated document. The dialing or routing rules determine
how the facility is to transport or route a document. As an
example, dialing or routing rules may indicate that a document that
is to be sent at a specific time or is from a particular user is to
be sent using a specific document transport.
[0037] At block 206, the routine selects a target based on the
applied dialing or routing rules. As examples, the routine may
select a public service telephone network ("PSTN"), another
RightFax server, a board server containing one or more
communications devices, and so forth. As examples, the DocTrans may
select a target based on metadata, type of document, or other
attributes relating to the document.
[0038] At block 208, the routine routes the document to the
selected target. The selected target may perform additional
analyses on the document and route the document to another DocTrans
so that the document can be routed appropriately.
[0039] At block 210, the routine returns.
[0040] FIG. 3 is a block diagram illustrating use of the DocTrans
in some embodiments. According to the illustrated embodiment, a
document 302 enters a RightFax server 304, such as after the
document is scanned. A workflow application 310 may take various
workflow steps, such as when the document is scanned, received,
sent, etc. This document is routed to a DocTrans module 306. This
DocTrans could reside in the same computing device as the RightFax
server or in a different computing device, in which case it is
referred to as a "Remote DocTrans." The DocTrans may invoke the
"send-document" routine described above in relation to FIG. 2 to
route the document to another DocTrans module. Once the document
has been transferred to one of the DocTrans modules, dialing or
routing rules 308 may be applied to this document. Dialing or
routing rules can be applied based on information pertaining to the
document, such as phone number, DocTrans, group, users, etc. A
dialing rule may cause the document to be routed to another
DocTrans, or to a specific type of transport. Transports include,
e.g., fax boards (e.g., from Brooktrout, Eicon, Intel, etc.), SMS
devices, routers (e.g., from Cisco) for T.38 fax, email, T.37
(Store and Forward) fax, a DocPlus (e.g., Xpedite) provider,
virtual implementation of the above, including document
transmission simulations (e.g., evaluating cost, schedule,
destination, and security for transmission), and so forth.
Extensibility and Routing Priorities
[0041] Since the DocTrans operates independently of network
connections, content servers, or network resources providing the
document, it can readily be configured to handle multiple document
types and route documents to multiple types of network connections.
As an example, the addition of email MIME types provides a secure
and reliable transport for email from any point on the network.
Moreover, the facility can confirm deliverability of the email,
verify or certify receipt of contents and attachments; confirm
results of operations performed by the DocTrans in routing the
document to various network nodes for storage, transmission, and
notifications; and so forth. By using rules that employ a TCP/IP
transport between RightFax servers with encryption and secure
session protocols (e.g., contrasted with open transmission on
telephone lines), the DocTrans can provide secure routing of
documents, such as facsimile ("fax") documents. To secure email
messages and attachments, the fax server could provide certified
delivery for documents or messages encrypted by the source server.
As an example, the fax server could employ independent sender and
recipient verifications and notifications for certified
delivery.
[0042] FIG. 4 illustrates a DocTrans with MIME support, such as for
using email with a DocTrans module in some embodiments. While the
figure illustrates a MIME-type document, other document types are
also possible. Flexible routing based on DocTrans permits simple
mail transport protocol ("SMTP") services for email operating with
the RightFax server to transmit an email document 402 between
DocTrans modules associated with RightFax servers directly, then
into a client inbox (e.g., Microsoft.RTM. Outlook.RTM.) 408 on a
RightFax client machine via an Intranet 406 and an email server
404. The illustrated embodiment identifies several advantages over
the prior art. Because there are redundant links between DocTrans
modules, "failsafe" transmission becomes possible. As an example,
when one DocTrans node is unavailable, the facility can employ
another DocTrans module to ensure that the document is delivered.
Content services on a RightFax server can archive, search &
retrieve, and store native documents, such as emails and their
attachments. The system can apply workflow by using, for example,
Captaris' RightFax EDC API or Captaris' WorkFlow product, such as
to accomplish multiple tasks with the same transmission (e.g.,
storing, logging, notifying, printing, and archiving). Metadata
regarding the document, its routing to known DocTrans modules, and
the network and communication resources available can be stored and
applied as well. For example, this information could be requested
and bound to the fax server document or task log for each task for
later retrieval.
[0043] Because the system has access to the intranet and Internet,
it can verify and certify that emails and any related documents
were delivered or that web links contained therein can be accessed.
The system can deliver documents via alternate transport
mechanisms. For example, if an email with MIME attachments could
not be delivered, the system could alternately route the email text
as an SMS message and provide the attachments as file pathnames or
URL links. Alternatively, the DocTrans system can convert an SMS
message into a facsimile, or a facsimile into a Fax-Over-IP (FOIP)
document, and send it using one of several facsimile transports
(e.g., telephone line, or T.37/T.38 fax over IP, etc.). The
DocTrans system can also confirm the origin, validity, delivery and
source of the document as required by using an independent, secure
notification and document validation method.
[0044] In this manner, the system enables receiving and employing
extensions for connecting to various transports, configuring
dialing and routing rules for these transports, and handling the
routing of message protocols, such as for MIME, SMS, T37 Fax, T38
Fax, and RightFax server. The system also enables extensions for
specific facsimile hardware, such as Eicon and Brooktrout. Third
party vendors that use RightFax ("RF") server for their document
transport can enhance their capabilities by using DocTrans.
Least-Cost Routing
[0045] Least-cost routing rules enable transmission of facsimile
documents over TCP/IP connections to other RightFax servers or to
local multifunction printer devices, where the document may be
printed, sent at local telephone rates rather than long distance
rates, or transmitted over an available TCP/IP connection. In
particular, using server-to-server IP network transmission of faxes
enables managing the long-distance calling costs of sending faxes
on telephone networks. Moreover, the facility can then employ local
storage to replicate documents. The ability to store-and-forward
documents in local networks (e.g., in RightFax servers or client
inboxes) with logging for verification of receipt and retention of
copies, enables re-transmission to be accomplished locally should
the printed document or original email attachment be lost or
inadvertently deleted. FIG. 5 is a block diagram illustrating rules
for least-cost-routing and for store-and-forward document transport
in some embodiments. According to the illustrated embodiment, rules
for least-cost-routing and for store-and-forward document transport
on the network can be applied by the queuing and routing system.
The correct routing for a document can be determined with reference
to the document type, transport protocol, availability of
communications channels, availability of and load on network
resources, and so forth.
[0046] A document 502 with metadata (e.g., metadata that contains
information pertaining to a sender) enters a server queue 503 of a
DocTrans. After routing rules 504 are applied to the document
(e.g., based on the metadata) the document is scheduled on one of
DocTrans's queues 506. These queues allow the DocTrans to treat all
document types in a similar fashion. As an example, all Transport
Mechanisms ("transports") 508 can implement the same or a similar
application program interface (API) to interact with these queues
and receive documents for transmission. DocTrans is also able to
identify documents based on document type (e.g., SMS, email, or
RightFax) or transmission type (e.g., fax board transmission, T.37
transmission, or T.38 transmission). The transports act as plug-ins
to the DocTrans (e.g., all have identical or similar interfaces,
such as for various operations including StartTransmission,
SendDocument, ReceiveDocument, EndTransmission, etc.) and new
libraries supporting these operations can extend transmission
capabilities in the DocTrans to add a new protocol. Also, in some
embodiments, a queue will be serviced if a transport that services
that type of queue has been configured on the DocTrans. In some
embodiments, the document may be enqueued when (510) a transport
associated with a queue is available.
[0047] FIG. 6 illustrates aspects of queue management performed by
protocols administered by DocTrans in some embodiments. The
illustrated embodiment indicates how queue management can be
separated from each transport type. In some embodiments, each queue
is managed by a DocTrans module. Multiple transport types can be
plugged-in and can service a corresponding queue. The DocTrans
module performs queue management, maintenance, and scheduling of
sending/receiving documents. According to the illustrated
embodiment, a RightFax server 602 sends a request 604 to a DocTrans
module 606. Based upon dialing or routing rules, the DocTrans
module determines whether to use a RightFax queue 608, SMS queue
610, or global queue 612. The RightFax queue 608 may be configured
to transport documents between other RightFax servers. The SMS
queue 610 may be configured to communicate with an SMS service
provider. The global queue 612 handles board-level communications,
such as by checking transports that are configured for use with the
system, to determine whether one of these transports can handle the
request 604. If one of the configured transports can handle the
request, the global queue routes the request to that transport.
[0048] Upon receiving a document, the DocTrans module delivers the
document 614 to the RightFax Server. The DocTrans module may also
send notifications to the RightFax Server upon receipt of a
document 616.
Load Balancing
[0049] Load balancing is a factor that DocTrans modules use to
determine whether a document is to be processed or forwarded to
another DocTrans module. All DocTrans modules can perform load
equalization based on a comparison of its load with other DocTrans
modules in the network. Rules based on such formulae may be applied
using cost parameters, transmission times, schedule times, security
or priority parameters, and routing and destination information.
Similarly, a DocTrans module can be used in conjunction with a
workflow application or simulation engine to estimate and to
optimize such rules before or during their application to a
document transmission task. As an example, DocTrans modules may
perform load balancing based on the following formula: (total of X
pages from Y Documents)/(number of send channels).
[0050] Another method varies the load calculation by channel and
content type, such as by using the following formula:
(Waiting Pages Of This Type*Expected Transport Time Per Page Of
This Document Type)/Number # of Channels Sending This Document
Type.
[0051] These formulae may be evaluated for each document type. For
example, if email can be sent in 3 seconds and a fax can be sent 1
minute, there are 60 one "page" emails queued, 50 one page faxes
queued, and there are 2 e-mail channels, and 24 fax channels, the
e-mail load would be:
60*3/2=90
and the fax load would be:
50*60/24=125
Managing Network Connections
[0052] If a resource is unavailable, such as because of a server
outage, it may not be considered for load balancing for a period of
time (e.g., 40 minutes) to permit the resource to be restored or
reconfigured. This applies to DocTrans, PSTN, Board Servers, and
RightFax servers. In some cases, the system may use the local
DocTrans to PSTN connection to transmit documents, even if that is
not the preferred configuration or least-cost routing for the
document, such as when other network resources are unavailable.
Grouping Using DocTrans
[0053] Conventional facsimile transmission has costs associated
relating to connections, such as call initiation and duration. The
process of grouping avoids contention for connection resources or
accrual of connection initiation charges when multiple documents
are directed to the same destination. Grouping can prevent tasks
from waiting on a "busy" line while other tasks to the same
destination are sending documents.
[0054] The grouping process can be implemented as follows: set the
number of pages or length of the transmission (to prevent unlimited
send time on the channel), identify and cache queued documents with
the same destination identifier, open connections on the transport,
and send the documents with the same destination identifier over
the open connection.
[0055] The group send feature may update its cache of queued
documents with documents that enter the queue during transmission
of a group, so long as the new documents share the same destination
identifier.
Implementation of DocTrans in Various Embodiments:
[0056] In various embodiments, a framework for accepting a plug-in
style implementation DLL for each transport type (or group of
types) is provided. Each DLL implements a predefined set of entry
points that enable support of various transport types.
[0057] Each entry point takes a resizable context structure that
supports all information transferred between the DocTrans and the
DLL. The document transports tolerate changes in the context
structures' sizes, and each document transport independently
supports operations such as store & forward, task scheduling,
sender or recipient intervention, least-cost routing rules,
document or task lifespan, and deliver-or-delete options without
breaking the document task.
Configurable Queue Processor:
[0058] FIG. 7 is a block diagram illustrating an environment in
which a configurable queue processor may operate in some
embodiments. A document server 700 contains multiple components,
including a configurable queue processor 702, server module 704,
and a DocTrans module 706. The document server can contain zero or
more of any of these components. The configurable queue processor
702 can allocate or deallocate document flows, such as by invoking
an application program interface (API) provided by the server
module 704. The server module 704 may associate each allocated
document flow with a DocTrans module 706. The server module 704 may
access a queue associated with the configurable queue processor.
The queue can be stored in a database, such as a SQL server 708 or
in any other memory associated with the server and shared by the
configurable queue processor and the document flows it
allocates.
[0059] FIG. 8 is a block diagram illustrating operation of a
configurable queue processor in some embodiments. A document 802
enters a document server 804, such as a facsimile server, and is
placed in a document queue 806. A configurable queue processor 807
can allocate or deallocate document flows 808, such as based on the
document server's resource utilization. Each document flow can be
associated with one or more DocTrans modules 810, such as modules
810a and 810b. The DocTrans modules receive the documents from the
queue via the document flows. As an example, a document flow can
retrieve a document from the queue and provide the retrieved
document to the associated DocTrans module for processing. DocTrans
modules 810a and 810b may operate on different document servers. A
document in the queue may be assigned for processing to a
particular document flow based on the document's properties, such
as its metadata or type. Example of properties that can be used in
assigning a document to a document flow include the document's
size, author, type, protocol used to send the document, and so
forth. A component may assign documents to a document flow.
Alternatively, a document flow may retrieve documents from the
queue based on the document flow's configuration, which can include
an indication of these properties. In some embodiments, the
configurable queue processor can dynamically reconfigure document
flow to handle documents with a different set of metadata or
properties.
[0060] FIG. 9 is a flow diagram illustrating a process_document
routine invoked by a document flow in some embodiments. The
process_document routine starts at block 902 where it receives an
indication of a document.
[0061] At block 904, the routine retrieves the document. In various
embodiments, the routine may actively check a queue for pending
documents and retrieve documents the document flow associated with
the routine is configured to handle. Logic to check the queue is
not illustrated. In various embodiments, the routine receives an
indication of the document, such as from a queue handling
component.
[0062] At block 906, the routine provides the retrieved document to
a DocTrans module associated with the document flow component that
invokes the routine. As an example, the routine may invoke an
application program interface ("API") provided by the associated
DocTrans module to provide the document.
[0063] At block 908, the routine invokes a send_document routine
provided by the DocTrans module's API to forward or otherwise
handle the document. The send_document routine was described above
in detail in relation to FIG. 2.
[0064] At block 910, the routine returns.
[0065] FIG. 10 is a flow diagram illustrating an
allocate_document_flow routine invoked by a configurable queue
processor in some embodiments. The configurable queue processor
invokes the routine to allocate or deallocate document flows. The
routine begins at block 1002.
[0066] At block 1004, the routine evaluates resources, such as
system resources, associated with the document server at which the
routine is invoked or the server with which the configurable queue
processor is associated. Examples of resources include processor,
memory, storage, network bandwidth, and so forth. The routine may
also evaluate the length of the queue of pending documents.
[0067] At block 1006, the routine determines whether there is an
efficient allocation of document flows. The routine can make this
determination by evaluating the queue, system resources, document
flows, and so forth. As an example, the routine can evaluate the
number and type of pending documents in the queue and processor
load to determine whether there is an efficient allocation of
document flows. If documents are flowing through the system within
some defined threshold period of time, the routine may determine
that the document flows are efficiently allocated. In such a case,
the routine continues at block 1010, where it returns. Otherwise,
the routine continues at block 1008.
[0068] At block 1008, the routine increases or decreases the number
of document flows, such as by allocating additional document flows
or deallocating document flows.
[0069] At block 1010, the routine returns.
[0070] FIG. 11 is a flow diagram illustrating a prevent_routing
routine invoked by the configurable document server in some
embodiments. The routine begins at block 1102.
[0071] At decision block 1104, the routine determines whether an
error condition exists. An error condition can exist when a
document could not be converted from one format to another, when a
facsimile transmission error occurs, or another error condition
occurs relating to the configurable document server. The error
detection can be made by a facsimile board connected to the
document server when a facsimile document is received, facsimile
software, such as server facsimile software, or other hardware or
software component. If an error condition exists, the routine
continues at decision block 1106. Otherwise, the routine returns at
block 1114.
[0072] At decision block 1106, the routine determines whether a
configuration option is set to prevent routing when an error
condition exists. If that is the case, the routine continues at
block 1108. Otherwise, the routine continues at block 1112.
[0073] At block 1108, the routine reports an error. As examples,
the routine can report errors to an administrator, a sender of the
document, a user attempting to convert the document, and so forth.
When the routine reports an error, the configurable document server
may, in addition to preventing the document from being routed or
forwarded to the intended recipient, take various workflow-related
actions, such as notifying users or workflow processes, suspend
workflow, and so forth. The routine may also take queue-related
actions, such as archiving workflow tasks until a notified user
takes an action, the workflow task expires, and so forth.
[0074] At block 1110, the routine may route the document to an
administrator for further analysis and troubleshooting. The routine
then returns at block 1114.
[0075] At block 1112, the routine routes the document to the
intended recipient because no error was detected. The routine then
returns at block 1114.
CONCLUSION
[0076] Unless the context clearly requires otherwise, throughout
the description and the claims, the words "comprise," "comprising,"
and the like are to be construed in an inclusive sense, as opposed
to an exclusive or exhaustive sense; that is to say, in the sense
of "including, but not limited to." As used herein, the terms
"connected," "coupled," or any variant thereof, means any
connection or coupling, either direct or indirect, between two or
more elements; the coupling of connection between the elements can
be physical, logical, or a combination thereof. Additionally, the
words "herein," "above," "below," and words of similar import, when
used in this application, shall refer to this application as a
whole and not to any particular portions of this application. Where
the context permits, words in the above Detailed Description using
the singular or plural number may also include the plural or
singular number respectively. The word "or," in reference to a list
of two or more items, covers all of the following interpretations
of the word: any of the items in the list, all of the items in the
list, and any combination of the items in the list. Although the
terms "dialing rules" or "routing rules" may be used together or
individually, the terms can refer to either or both types of
rules.
[0077] The above detailed description of embodiments of the
invention is not intended to be exhaustive or to limit the
invention to the precise form disclosed above. While specific
embodiments of, and examples for, the invention are described above
for illustrative purposes, various equivalent modifications are
possible within the scope of the invention, as those skilled in the
relevant art will recognize. For example, while processes or blocks
are presented in a given order, alternative embodiments may perform
routines having steps, or employ systems having blocks, in a
different order, and some processes or blocks may be deleted,
moved, added, subdivided, combined, and/or modified to provide
alternative or subcombinations. Each of these processes or blocks
may be implemented in a variety of different ways. Also, while
processes or blocks are at times shown as being performed in
series, these processes or blocks may instead be performed in
parallel, or may be performed at different times.
[0078] The teachings of the invention provided herein can be
applied to other systems, not necessarily the system described
above. The elements and acts of the various embodiments described
above can be combined to provide further embodiments.
[0079] Any patents and applications and other references noted
above, including any that may be listed in accompanying filing
papers, are incorporated herein by reference. Aspects of the
invention can be modified, if necessary, to employ the systems,
functions, and concepts of the various references described above
to provide yet further embodiments of the invention.
[0080] These and other changes can be made to the invention in
light of the above Detailed Description. While the above
description describes certain embodiments of the invention, and
describes the best mode contemplated, no matter how detailed the
above appears in text, the invention can be practiced in many ways.
Details of the document transport layer may vary considerably in
its implementation details, while still being encompassed by the
invention disclosed herein. As noted above, particular terminology
used when describing certain features or aspects of the invention
should not be taken to imply that the terminology is being
redefined herein to be restricted to any specific characteristics,
features, or aspects of the invention with which that terminology
is associated. In general, the terms used in the following claims
should not be construed to limit the invention to the specific
embodiments disclosed in the specification, unless the above
Detailed Description section explicitly defines such terms.
Accordingly, the actual scope of the invention encompasses not only
the disclosed embodiments, but also all equivalent ways of
practicing or implementing the invention under the claims.
[0081] While certain aspects of the invention are presented below
in certain claim forms, the inventors contemplate the various
aspects of the invention in any number of claim forms. For example,
while only one aspect of the invention is recited as embodied in a
computer-readable medium, other aspects may likewise be embodied in
a computer-readable medium. Accordingly, the inventors reserve the
right to add additional claims after filing the application to
pursue such additional claim forms for other aspects of the
invention.
* * * * *