US20070177195A1 - Queue processor for document servers - Google Patents

Queue processor for document servers Download PDF

Info

Publication number
US20070177195A1
US20070177195A1 US11/591,449 US59144906A US2007177195A1 US 20070177195 A1 US20070177195 A1 US 20070177195A1 US 59144906 A US59144906 A US 59144906A US 2007177195 A1 US2007177195 A1 US 2007177195A1
Authority
US
United States
Prior art keywords
document
network
documents
server
routing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/591,449
Inventor
Treber Rebert
Jonathan Isabelle
Jason Webster
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Open Text Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US11/591,449 priority Critical patent/US20070177195A1/en
Application filed by Individual filed Critical Individual
Assigned to CAPTARIS, INC. reassignment CAPTARIS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ISABELLE, JONATHAN, WEBSTER, JASON K., REBERT, TREBER
Publication of US20070177195A1 publication Critical patent/US20070177195A1/en
Assigned to WELLS FARGO FOOTHILL, LLC, AS AGENT reassignment WELLS FARGO FOOTHILL, LLC, AS AGENT SECURITY AGREEMENT Assignors: CAPTARIS, INC.
Assigned to CAPTARIS, INC. reassignment CAPTARIS, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: WELLS FARGO FOOTHILL, LLC, AS AGENT
Priority to US12/495,743 priority patent/US9277092B2/en
Priority to US12/606,915 priority patent/US8823976B2/en
Priority to US14/446,937 priority patent/US10594822B2/en
Priority to US14/992,880 priority patent/US10587772B2/en
Priority to US16/806,422 priority patent/US11716404B2/en
Priority to US18/332,484 priority patent/US20230319159A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/561Adding application-functional data or data for application control, e.g. adding metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00204Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a digital computer or a digital computer system, e.g. an internet server
    • H04N1/00209Transmitting or receiving image data, e.g. facsimile data, via a computer, e.g. using e-mail, a computer network, the internet, I-fax
    • H04N1/00214Transmitting or receiving image data, e.g. facsimile data, via a computer, e.g. using e-mail, a computer network, the internet, I-fax details of transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00204Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a digital computer or a digital computer system, e.g. an internet server
    • H04N1/00209Transmitting or receiving image data, e.g. facsimile data, via a computer, e.g. using e-mail, a computer network, the internet, I-fax
    • H04N1/00214Transmitting or receiving image data, e.g. facsimile data, via a computer, e.g. using e-mail, a computer network, the internet, I-fax details of transmission
    • H04N1/00217Transmitting or receiving image data, e.g. facsimile data, via a computer, e.g. using e-mail, a computer network, the internet, I-fax details of transmission only involving computer data transmission protocols, e.g. SMTP, WAP or HTTP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32358Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device using picture signal storage, e.g. at transmitter
    • H04N1/324Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device using picture signal storage, e.g. at transmitter intermediate the transmitter and receiver terminals, e.g. at an exchange
    • H04N1/32406Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device using picture signal storage, e.g. at transmitter intermediate the transmitter and receiver terminals, e.g. at an exchange in connection with routing or relaying, e.g. using a fax-server or a store-and-forward facility
    • H04N1/32411Handling instructions for routing or relaying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0077Types of the still picture apparatus
    • H04N2201/0082Image hardcopy reproducer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0077Types of the still picture apparatus
    • H04N2201/0093Facsimile machine
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0077Types of the still picture apparatus
    • H04N2201/0094Multifunctional device, i.e. a device capable of all of reading, reproducing, copying, facsimile transception, file transception
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3212Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to a job, e.g. communication, capture or filing of an image
    • H04N2201/3222Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to a job, e.g. communication, capture or filing of an image of processing required or performed, e.g. forwarding, urgent or confidential handling

Definitions

  • 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.
  • 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.
  • FIG. 1 is a block diagram illustrating a suitable computing system in which aspects of the invention may be implemented.
  • FIG. 2 is a flow diagram illustrating a send_document routine invoked by a Document Transport module in some embodiments.
  • FIG. 3 is a block diagram illustrating use of the Document Transport in some embodiments.
  • FIG. 4 is a block diagram illustrating a Document Transport with MIME support.
  • FIG. 5 is a block diagram illustrating rules for least-cost-routing and for store-and-forward document transport in some embodiments.
  • FIG. 6 is a block diagram illustrating some of the queue management done by separate protocols administered by Document Transport.
  • FIG. 7 is a block diagram illustrating an environment in which a configurable queue processor may operate in some embodiments.
  • FIG. 8 is a block diagram illustrating operation of a configurable queue processor in some embodiments.
  • FIG. 9 is a flow diagram illustrating a process_document routine invoked by a document flow in some embodiments.
  • FIG. 10 is a flow diagram illustrating an allocate_document_flow routine invoked by a configurable queue processor in some embodiments.
  • a configurable queue processor for document servers is described.
  • 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.
  • 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.
  • the document flows can retrieve documents from a queue or may be provided documents by another component, such as the configurable queue processor.
  • 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.
  • the configurable queue processor may increase the number of queues that hold pending documents.
  • the configurable queue processor may allocate document flows across one or more document servers.
  • each document server may have its own configurable queue processor that allocates document flows on that document server.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • routing operations such operations as StartTransmission, SendDocument, ReceiveDocument, EndTransmission, or StatusCheck
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • computer refers to any of the above devices, as well as any data processor.
  • 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.
  • LAN Local Area Network
  • WAN Wide Area Network
  • 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).
  • EEPROM chips electrically erasable programmable read-only memory
  • 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.
  • 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.
  • 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 ).
  • LAN local area network
  • WAN wide area network
  • the Internet not shown in FIG. 1 .
  • 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.
  • 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.
  • 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.
  • the routine selects a target based on the applied dialing or routing rules.
  • 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.
  • PSTN public service telephone network
  • the DocTrans may select a target based on metadata, type of document, or other attributes relating to the document.
  • 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.
  • the routine returns.
  • FIG. 3 is a block diagram illustrating use of the DocTrans in some embodiments.
  • 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.
  • 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.
  • fax boards e.g., from Brooktrout, Eicon, Intel, etc.
  • SMS devices e.g., from Cisco
  • routers e.g., from Cisco
  • routers e.g., from Cisco
  • DocPlus e.g., Xpedite
  • virtual implementation of the above including document transmission simulations (e.g., evaluating cost, schedule, destination, and security for transmission), and so forth.
  • the DocTrans 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.
  • fax facsimile
  • 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® Outlook®) 408 on a RightFax client machine via an Intranet 406 and an email server 404 .
  • SMTP simple mail transport protocol
  • client inbox e.g., Microsoft® Outlook®
  • the illustrated embodiment identifies several advantages over the prior art. Because there are redundant links between DocTrans modules, “failsafe” transmission becomes possible.
  • 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.
  • the system 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.
  • 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.
  • 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 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.
  • server-to-server IP network transmission of faxes enables managing the long-distance calling costs of sending faxes on telephone networks.
  • 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
  • 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.
  • 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.
  • a document 502 with metadata enters a server queue 503 of a DocTrans.
  • 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.
  • 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.
  • a queue will be serviced if a transport that services that type of queue has been configured on the DocTrans.
  • the document may be enqueued when ( 510 ) a transport associated with a queue is available.
  • 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.
  • 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.
  • 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.
  • the DocTrans module 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 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).
  • Another method varies the load calculation by channel and content type, such as by using the following formula:
  • 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.
  • 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.
  • connection initiation and duration 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 810 a and 810 b.
  • the DocTrans modules receive the documents from the queue via the document flows.
  • a document flow can retrieve a document from the queue and provide the retrieved document to the associated DocTrans module for processing.
  • DocTrans modules 810 a and 810 b 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.
  • 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.
  • a document flow may retrieve documents from the queue based on the document flow's configuration, which can include an indication of these properties.
  • the configurable queue processor can dynamically reconfigure document flow to handle documents with a different set of metadata or properties.
  • 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.
  • the routine retrieves the document.
  • 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.
  • the routine receives an indication of the document, such as from a queue handling component.
  • the routine provides the retrieved document to a DocTrans module associated with the document flow component that invokes the routine.
  • the routine may invoke an application program interface (“API”) provided by the associated DocTrans module to provide the document.
  • API application program interface
  • 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 .
  • 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 .
  • 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.
  • 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 .
  • the routine increases or decreases the number of document flows, such as by allocating additional document flows or deallocating document flows.
  • the routine returns.
  • 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.”
  • 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.
  • 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.

Abstract

A configurable queue processor for document servers is described. The configurable queue processor strives to allocate server resources in an optimal manner such that document servers can process documents efficiently. In various embodiments, the facility includes a configurable queue processor for allocating document flows for handling documents, document transport module for transporting documents between network devices, such as printers, fax boards, and content servers and across local and wide-area networks; functionality for routing optimization with other communications networks, such as messaging services, telephony, and IP networks; and flexible document transport capabilities to workflow applications and multifunction devices (such as all-in-one print/scan/copy/fax/telephone/answering machine devices) and multifunction devices enhanced with video & video capture, messaging, email, network router & gateway capabilities.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This patent application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/731,949, filed Oct. 31, 2005 and entitled “Universal Document Transport,” U.S. Provisional Patent Application Ser. No. 60/732,167, filed Nov. 1, 2005, and entitled “Universal Document Transport,” and U.S. Provisional Patent Application Ser. No. 60/812,709, filed Jun. 9, 2006, and entitled “Universal Document Transport,” all of which are incorporated herein in their entireties by reference. This patent application also incorporates by reference copending U.S. patent application No. 10/118,541, which was filed on Apr. 8, 2002, and entitled “Document Transmission and Routing With Recipient Control, Such As Facsimile Document Transmission and Routing.”
  • BACKGROUND
  • 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.
  • However, 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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating a suitable computing system in which aspects of the invention may be implemented.
  • FIG. 2 is a flow diagram illustrating a send_document routine invoked by a Document Transport module in some embodiments.
  • FIG. 3 is a block diagram illustrating use of the Document Transport in some embodiments.
  • FIG. 4 is a block diagram illustrating a Document Transport with MIME support.
  • FIG. 5 is a block diagram illustrating rules for least-cost-routing and for store-and-forward document transport in some embodiments.
  • FIG. 6 is a block diagram illustrating some of the queue management done by separate protocols administered by Document Transport.
  • FIG. 7 is a block diagram illustrating an environment in which a configurable queue processor may operate in some embodiments.
  • FIG. 8 is a block diagram illustrating operation of a configurable queue processor in some embodiments.
  • FIG. 9 is a flow diagram illustrating a process_document routine invoked by a document flow in some embodiments.
  • FIG. 10 is a flow diagram illustrating an allocate_document_flow routine invoked by a configurable queue processor in some embodiments.
  • The headings provided herein do not necessarily limit the scope of the invention.
  • DETAILED DESCRIPTION
  • 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
  • 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.
  • A configurable queue processor for document servers is described. 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.
  • 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.
  • 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.
  • In some embodiments, the configurable queue processor may increase the number of queues that hold pending documents.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • At block 210, the routine returns.
  • 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
  • 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.
  • 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® Outlook®) 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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).
  • 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.
  • These formulae may be evaluated for each document type. For example, if e-mail can be sent in 3 seconds and a fax can be sent 1 minute, there are 60 one “page” e-mails 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
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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 810 a and 810 b. 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 810 a and 810 b 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • At block 910, the routine returns.
  • 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.
  • 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.
  • 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.
  • At block 1008, the routine increases or decreases the number of document flows, such as by allocating additional document flows or deallocating document flows.
  • At block 1010, the routine returns.
  • Conclusion
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Claims (21)

1. A method for handling documents of various types, the method comprising:
receiving a document at a document server;
analyzing metadata associated with the received document;
evaluating a resource at the document server to determine whether an additional document flow is to be allocated;
when it is determined that an additional document flow is to be allocated, allocating an additional document flow; and
causing the received document to be processed by the allocated document flow wherein the processing includes:
forwarding the document and associated metadata to one of multiple document transport modules, wherein a document transport module provides rule-based routing of documents;
assessing dialing or routing rules based on the metadata for the document;
routing the document by the document transport module via one of multiple communication methods, including without limitation, a Public Service Telephone Network (“PSTN”), another document transport module, Internet, mobile device network, wireless device network, document server, fax server, or a board server containing one or more communications hardware devices, and wherein the routing is based on at least one dialing or routing rule; and
repeating the associating, forwarding, assessing and routing for any subsequent document transport module that receives the document, wherein the dialing or routing rules are applied independently at each document transport module encountered by the document during processing of the document.
2. The method of claim 1 wherein when it is not determined that a document flow is to be allocated, the received document is processed by a previously allocated document flow.
3. The method of claim 1 wherein the resource comprises a processor, a memory, or network bandwidth.
4. The method of claim 1 wherein the allocating includes associating the allocated document flow with the document transport module.
5. The method of claim 1 wherein the document flow handles an identified document type.
6. The method of claim 5 wherein the document type comprises a facsimile, a T.30 image, or a SMS message.
7. A computer-readable medium whose contents cause at least one data processing platform to process a document under a document processing method, the method comprising:
recognizing at least one document request based on a received document;
interacting with one or more document routing rules and one or more workflow requirements with respect to the received document;
evaluating a load at the document server to determine whether a document flow is to be allocated;
when it is determined that a document flow is to be allocated, allocating a document flow; and
causing the received document to be processed by the allocated document flow wherein the processing includes:
managing content flows between network nodes or devices, wherein a same processing architecture is employed for document handling or transporting, wherein a common scheduling and a common queue support multiple transport types, and wherein the managing of content flows includes selecting document-specific or hardware-specific processing tasks by reference to a type of protocol associated with the document or a desired handling of the document.
8. The computer-readable medium of claim 7 wherein when it is not determined that a document flow is to be allocated, the received document is processed by a previously allocated document flow.
9. The computer-readable medium of claim 7 wherein the computer-readable medium comprises a memory of a document server or a board server.
10. The computer-readable medium of claim 7 wherein the computer-readable medium comprises a logical node in a computer network receiving the contents, a network service receiving the document, a network storage system or database server, or a computer-readable disk.
11. The computer-readable medium of claim 7 wherein the load is processor utilization.
12. An apparatus for handling various documents within a network, the apparatus comprising:
document transport means for transporting documents between network devices, wherein the network devices include printers, fax boards, multifunction devices, and content servers;
queue processor means for allocating document flows that provide documents in a queue to the document transport means; and
means for routing optimization wherein the other communications networks include messaging services, telephony, Internet, mobile and wireless networks, IP networks, or other document transport modules.
13. The apparatus of claim 12 wherein the network comprises a local network or a wide-area network.
14. The apparatus of claim 12 wherein the queue processor means is configured to allocate an identified number of document flows, each document flow for processing one of multiple identified types of documents.
15. The apparatus of claim 14, wherein the queue processor means allocates document flows dynamically based on a server load.
16. The apparatus of claim 14 wherein the server load includes a measure of a number of documents awaiting processing.
17. The apparatus of claim 12, wherein the server load includes a measure of processor utilization.
18. The apparatus of claim 12, wherein the document transport means comprises:
communication means for performing discrete document creation, storage and transmission tasks between various communication networks and network servers;
means for providing flexible, programmable communication of documents in various message formats and on various network types; and
means for routing the document communications via optimization routing rules.
19. The apparatus of claim 18 wherein the document transport means communicates with another document transport means that is configured for use with a server.
20. The apparatus of claim 18 wherein the document transport means communicates with another document transport means via a secure connection.
21-29. (canceled)
US11/591,449 2005-10-31 2006-10-31 Queue processor for document servers Abandoned US20070177195A1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US11/591,449 US20070177195A1 (en) 2005-10-31 2006-10-31 Queue processor for document servers
US12/495,743 US9277092B2 (en) 2006-08-02 2009-06-30 Configurable document server
US12/606,915 US8823976B2 (en) 2005-10-31 2009-10-27 Queue processor for document servers
US14/446,937 US10594822B2 (en) 2005-10-31 2014-07-30 Queue processor for document servers
US14/992,880 US10587772B2 (en) 2006-08-02 2016-01-11 Configurable document server
US16/806,422 US11716404B2 (en) 2005-10-31 2020-03-02 Queue processor for document servers
US18/332,484 US20230319159A1 (en) 2005-10-31 2023-06-09 Queue processor for document servers

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US73194905P 2005-10-31 2005-10-31
US73216705P 2005-11-01 2005-11-01
US81270906P 2006-06-09 2006-06-09
US11/591,449 US20070177195A1 (en) 2005-10-31 2006-10-31 Queue processor for document servers

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/606,915 Continuation US8823976B2 (en) 2005-10-31 2009-10-27 Queue processor for document servers

Publications (1)

Publication Number Publication Date
US20070177195A1 true US20070177195A1 (en) 2007-08-02

Family

ID=38321789

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/591,449 Abandoned US20070177195A1 (en) 2005-10-31 2006-10-31 Queue processor for document servers
US12/606,915 Expired - Fee Related US8823976B2 (en) 2005-10-31 2009-10-27 Queue processor for document servers
US14/446,937 Active US10594822B2 (en) 2005-10-31 2014-07-30 Queue processor for document servers
US16/806,422 Active US11716404B2 (en) 2005-10-31 2020-03-02 Queue processor for document servers

Family Applications After (3)

Application Number Title Priority Date Filing Date
US12/606,915 Expired - Fee Related US8823976B2 (en) 2005-10-31 2009-10-27 Queue processor for document servers
US14/446,937 Active US10594822B2 (en) 2005-10-31 2014-07-30 Queue processor for document servers
US16/806,422 Active US11716404B2 (en) 2005-10-31 2020-03-02 Queue processor for document servers

Country Status (1)

Country Link
US (4) US20070177195A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070177183A1 (en) * 2006-02-02 2007-08-02 Microsoft Corporation Generation Of Documents From Images
US20090279123A1 (en) * 2008-05-09 2009-11-12 Hitoshi Sekine Job scheduling in a workflow architecture
US20090300652A1 (en) * 2008-05-29 2009-12-03 Microsoft Corporation Queue dispatch using deferred acknowledgement
US20140201062A1 (en) * 2013-01-11 2014-07-17 Capital One Financial Corporation Systems and Methods for Managing a Loan Application
US8984530B2 (en) 2008-01-31 2015-03-17 Microsoft Corporation Queued message dispatch
US20170230544A1 (en) * 2014-06-24 2017-08-10 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible internet fax architecture
US10089150B2 (en) 2015-02-03 2018-10-02 Alibaba Group Holding Limited Apparatus, device and method for allocating CPU resources
US11138539B2 (en) * 2017-08-25 2021-10-05 Target Brands, Inc. Robtic business process automation system utilizing reusable task-based microbots

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1949252A4 (en) * 2005-10-31 2012-10-10 Open Text SA Queue processor for document servers
US20070177195A1 (en) 2005-10-31 2007-08-02 Treber Rebert Queue processor for document servers
US20230319159A1 (en) * 2005-10-31 2023-10-05 Treber Rebert Queue processor for document servers
JP2007164422A (en) * 2005-12-13 2007-06-28 Canon Inc Information processor, information processing method and information processing program
EP2047360A4 (en) 2006-08-02 2013-03-13 Open Text SA Configurable document server
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network

Citations (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4922524A (en) * 1987-05-20 1990-05-01 Ricoh Company Ltd. Facsimile system with a voice transmission function
US5237430A (en) * 1990-04-20 1993-08-17 Ricoh Company, Ltd. Facsimile apparatus which stores image data in a bulk storage device
US5289532A (en) * 1990-10-02 1994-02-22 Fuji Xerox Co., Ltd. Facsimile apparatus providing facsimile transmission with forwardable voice communication
US5305376A (en) * 1989-09-25 1994-04-19 Ricoh Company, Ltd. Facsimile machine with voice answer unit
US5377257A (en) * 1991-11-08 1994-12-27 Hitachi, Ltd. Facsimile receiving method and facsimile apparatus carrying out the method
US5412710A (en) * 1991-09-11 1995-05-02 Fujitsu Limited Facsimile machine capable of transmitting voice messages
US5423043A (en) * 1994-01-21 1995-06-06 International Business Machines Corporation Method and apparatus for creating and monitoring logical associations among desktop objects
US5452099A (en) * 1993-04-12 1995-09-19 Faxguard Systems Corporation Method and system for storage and/or transmission of confidential facsimile documents
US5472905A (en) * 1990-11-17 1995-12-05 Samsung Electronics Co., Ltd. Method for forming a field oxide layer of a semiconductor integrated circuit device
US5483580A (en) * 1993-03-19 1996-01-09 Octel Communications Corporation Methods and apparatus for non-simultaneous transmittal and storage of voice message and digital text or image
US5517556A (en) * 1992-09-18 1996-05-14 Vmx, Inc. Call processing system with facsimile processing
US5559860A (en) * 1992-06-11 1996-09-24 Sony Corporation User selectable response to an incoming call at a mobile station
US5627764A (en) * 1991-10-04 1997-05-06 Banyan Systems, Inc. Automatic electronic messaging system with feedback and work flow administration
US5715302A (en) * 1995-06-17 1998-02-03 Samsung Electronics Co., Ltd. Apparatus and method for executing mode conversion of a facsimile system into automatic mode
US5717744A (en) * 1994-03-16 1998-02-10 Canon Kabushiki Kaisha Data communicating apparatus having user notification capability and method
US5717498A (en) * 1995-06-06 1998-02-10 Brother Kogyo Kabushiki Kaisha Facsimile machine for receiving, storing, and reproducing associated image data and voice data
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5761283A (en) * 1995-06-16 1998-06-02 Samsung Electronics Co., Ltd. Message processing method of facsimile systems
US5767985A (en) * 1994-06-29 1998-06-16 Fuji Xerox Co., Ltd. System employing facsimile units to transmit E-mail between information processors over public telephone lines
US5781886A (en) * 1995-04-20 1998-07-14 Fujitsu Limited Voice response apparatus
US5978454A (en) * 1991-12-06 1999-11-02 Mediaone Group, Inc. Method and instructions for fax mail user interface
US20020049817A1 (en) * 2001-07-12 2002-04-25 Eatamar Drory Storageless system and method for unified messaging on existing mail accounts via standard internet mail protocols
US6466909B1 (en) * 1999-06-28 2002-10-15 Avaya Technology Corp. Shared text-to-speech resource
US6477494B2 (en) * 1997-07-03 2002-11-05 Avaya Technology Corporation Unified messaging system with voice messaging and text messaging using text-to-speech conversion
US20020176117A1 (en) * 1996-10-29 2002-11-28 Douglas J. Randalli Delivery expert system and method
US6549612B2 (en) * 1998-05-06 2003-04-15 Telecommunications Premium Services, Inc. Unified communication services via e-mail
US20030164986A1 (en) * 2002-01-30 2003-09-04 Sebastien Boire-Lavigne Fax transmission over the packet network
US20030193967A1 (en) * 2001-12-31 2003-10-16 Gregg Fenton Method, apparatus and system for processing multimedia messages
US6636587B1 (en) * 1997-06-25 2003-10-21 Hitachi, Ltd. Information reception processing method and computer-telephony integration system
US6745221B1 (en) * 1999-03-01 2004-06-01 Mitel, Inc. Dynamic resource reallocation
US20040114194A1 (en) * 2002-12-11 2004-06-17 Murata Kikai Kabushiki Kaisha Facsimile machine
US6785021B1 (en) * 1988-09-22 2004-08-31 Audiofax, Ip, Llc Facsimile telecommunications system and method
US20050021631A1 (en) * 2003-05-08 2005-01-27 Venali, Inc. Premium messaging exchange
US6856676B1 (en) * 1998-10-15 2005-02-15 Alcatel System and method of controlling and managing voice and data services in a telecommunications network
US20050063005A1 (en) * 2003-09-08 2005-03-24 Kevin Phillips Integrated document delivery method and apparatus
US6906817B1 (en) * 2000-06-23 2005-06-14 Esker, Inc. Network system for directing the transmission of facsimiles
US20050146753A1 (en) * 2004-01-02 2005-07-07 Jonathan Firooz Multi-functional printer device
US20050219614A1 (en) * 2004-04-02 2005-10-06 Garg Man M Scalable hierarchical-states based job management engine with resource balancing and services monitoring
US20050254083A1 (en) * 2002-03-22 2005-11-17 Jean-Marc Bodart Document processing order management system, method for managing document processing orders, and software product for carring out the method
US6981023B1 (en) * 1999-03-09 2005-12-27 Michael Hamilton Message routing
US20060189333A1 (en) * 2003-09-12 2006-08-24 Core Mobility, Inc. Unified interface for voice, text or picture message authoring
US20060280165A1 (en) * 2005-06-14 2006-12-14 Gordon Blumenschein Intelligent negotiator node
US7230745B1 (en) * 2002-04-08 2007-06-12 Captaris, Inc. Document transmission and routing with recipient control, such as facsimile document transmission and routing

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4994926C1 (en) * 1988-09-22 2001-07-03 Audiofax Ip L L C Facsimile telecommunications system and method
KR100193809B1 (en) * 1995-11-16 1999-06-15 윤종용 How to notify error status in fax
US6707580B1 (en) * 1996-10-15 2004-03-16 E-Mate Enterprises, Llc Facsimile to E-mail communication system with local interface
JP3760526B2 (en) * 1996-10-18 2006-03-29 ブラザー工業株式会社 Data communication system and data communication control method
US6425033B1 (en) 1997-06-20 2002-07-23 National Instruments Corporation System and method for connecting peripheral buses through a serial bus
US6104500A (en) * 1998-04-29 2000-08-15 Bcl, Computer Inc. Networked fax routing via email
JP2000268012A (en) * 1999-03-12 2000-09-29 Nec Corp Method and device for distributing load in client server system
US6600750B1 (en) * 1999-03-19 2003-07-29 Cisco Technology, Inc. Email to fax processing when no secondary storage is available
CA2400296A1 (en) * 2000-02-16 2001-08-23 Real Consulting Llc A system and method for automating the assembly, processing and delivery of documents
US20040105122A1 (en) * 2000-03-20 2004-06-03 Schaeffer Richard J. Printer control and document management system
US6799318B1 (en) * 2000-04-24 2004-09-28 Microsoft Corporation Method having multiple interfaces with distinguished functions and commands for providing services to a device through a transport
JP2001358867A (en) * 2000-06-15 2001-12-26 Murata Mach Ltd Image processor
US6928482B1 (en) * 2000-06-29 2005-08-09 Cisco Technology, Inc. Method and apparatus for scalable process flow load balancing of a multiplicity of parallel packet processors in a digital communication network
US20050203673A1 (en) * 2000-08-18 2005-09-15 Hassanayn Machlab El-Hajj Wireless communication framework
JP4299447B2 (en) * 2000-09-12 2009-07-22 インターナショナル・ビジネス・マシーンズ・コーポレーション Workflow system, information processing apparatus, and storage medium
JP2002297522A (en) * 2001-03-30 2002-10-11 Minolta Co Ltd Data transmitter, data transmission method, program, and recording medium
US7073174B2 (en) * 2001-06-05 2006-07-04 Hewlett-Packard Development Company, L.P. Use of job tickets to secure resource access
US20020194245A1 (en) * 2001-06-05 2002-12-19 Simpson Shell S. Job ticket service
US7349869B2 (en) * 2001-06-05 2008-03-25 Hewlett-Packard Development Company, L.P. Use of a job ticket service to store bid information
US7207069B2 (en) * 2001-06-05 2007-04-17 Hewlett-Packard Development Company, L.P. Branch locking of job tickets to control concurrency
US7151763B2 (en) * 2001-06-29 2006-12-19 Bellsouth Intellectual Property Corporation Retrieving voice-based content in conjunction with wireless application protocol browsing
US7212301B2 (en) * 2001-10-31 2007-05-01 Call-Tell Llc System and method for centralized, automatic extraction of data from remotely transmitted forms
US7274476B2 (en) * 2001-12-20 2007-09-25 Murata Kikai Kabushiki Kaisha Facsimile apparatus having a function of archiving an image data into an external device through a network
US7395343B1 (en) * 2002-02-26 2008-07-01 Cisco Technology, Inc. Network tunneling method and apparatus
US20040080776A1 (en) 2002-10-28 2004-04-29 Garcia Elias S. Image forming devices, imaging forming systems and image forming device operational methods
US20040095612A1 (en) * 2002-11-18 2004-05-20 Murata Kikai Kabushiki Kaisha Facsimile machine and facsimile transmission method
CN100426733C (en) * 2003-01-16 2008-10-15 华为技术有限公司 System for realizing resource distribution in network communication and its method
KR100513866B1 (en) 2003-02-06 2005-09-09 삼성전자주식회사 Legacy fax service system in home network and method thereof
US8009307B2 (en) * 2003-02-06 2011-08-30 Advectis Inc Fax handling system and method
JP4039276B2 (en) * 2003-03-05 2008-01-30 富士ゼロックス株式会社 Service processing system and program
JP4123995B2 (en) * 2003-03-20 2008-07-23 富士ゼロックス株式会社 Image communication device
US7861002B2 (en) 2003-05-22 2010-12-28 Adtran, Inc. Network router that efficiently switches between a primary data path and a backup data path
GB2402578A (en) * 2003-06-04 2004-12-08 Research In Motion Ltd Selection of message transport in a communication device
US7355758B2 (en) * 2003-06-12 2008-04-08 At&T Delaware Intellectual Property, Inc. Automated facsimile monitoring and displaying methods and related systems
US20060036649A1 (en) * 2004-08-12 2006-02-16 Simske Steven J Index extraction from documents
US7672003B2 (en) 2004-09-01 2010-03-02 Eric Morgan Dowling Network scanner for global document creation, transmission and management
US20060048210A1 (en) * 2004-09-01 2006-03-02 Hildre Eric A System and method for policy enforcement in structured electronic messages
US7443883B2 (en) * 2004-12-07 2008-10-28 Comcast Cable Holdings, Llc Method and system of providing customer premise equipment code
JP4362782B2 (en) * 2005-06-30 2009-11-11 ブラザー工業株式会社 Image printing apparatus and error information output program for image printing apparatus
CA2741494C (en) 2005-10-31 2013-05-07 Open Text Inc. Universal document transport
EP1949252A4 (en) * 2005-10-31 2012-10-10 Open Text SA Queue processor for document servers
US20070177195A1 (en) * 2005-10-31 2007-08-02 Treber Rebert Queue processor for document servers
US7570382B2 (en) * 2005-11-14 2009-08-04 Kabushiki Kaisha Toshiba System and method for detecting errors in electronic document workflow
US8086737B2 (en) * 2005-12-07 2011-12-27 Cisco Technology, Inc. System to dynamically detect and correct errors in a session
US20080015918A1 (en) 2006-07-14 2008-01-17 Pangrazio Donald M Workflow selection process and system
EP2047360A4 (en) 2006-08-02 2013-03-13 Open Text SA Configurable document server

Patent Citations (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4922524A (en) * 1987-05-20 1990-05-01 Ricoh Company Ltd. Facsimile system with a voice transmission function
US6785021B1 (en) * 1988-09-22 2004-08-31 Audiofax, Ip, Llc Facsimile telecommunications system and method
US5305376A (en) * 1989-09-25 1994-04-19 Ricoh Company, Ltd. Facsimile machine with voice answer unit
US5237430A (en) * 1990-04-20 1993-08-17 Ricoh Company, Ltd. Facsimile apparatus which stores image data in a bulk storage device
US5289532A (en) * 1990-10-02 1994-02-22 Fuji Xerox Co., Ltd. Facsimile apparatus providing facsimile transmission with forwardable voice communication
US5472905A (en) * 1990-11-17 1995-12-05 Samsung Electronics Co., Ltd. Method for forming a field oxide layer of a semiconductor integrated circuit device
US5412710A (en) * 1991-09-11 1995-05-02 Fujitsu Limited Facsimile machine capable of transmitting voice messages
US5627764A (en) * 1991-10-04 1997-05-06 Banyan Systems, Inc. Automatic electronic messaging system with feedback and work flow administration
US5377257A (en) * 1991-11-08 1994-12-27 Hitachi, Ltd. Facsimile receiving method and facsimile apparatus carrying out the method
US5978454A (en) * 1991-12-06 1999-11-02 Mediaone Group, Inc. Method and instructions for fax mail user interface
US5559860A (en) * 1992-06-11 1996-09-24 Sony Corporation User selectable response to an incoming call at a mobile station
US5517556A (en) * 1992-09-18 1996-05-14 Vmx, Inc. Call processing system with facsimile processing
US5483580A (en) * 1993-03-19 1996-01-09 Octel Communications Corporation Methods and apparatus for non-simultaneous transmittal and storage of voice message and digital text or image
US5452099A (en) * 1993-04-12 1995-09-19 Faxguard Systems Corporation Method and system for storage and/or transmission of confidential facsimile documents
US5423043A (en) * 1994-01-21 1995-06-06 International Business Machines Corporation Method and apparatus for creating and monitoring logical associations among desktop objects
US5717744A (en) * 1994-03-16 1998-02-10 Canon Kabushiki Kaisha Data communicating apparatus having user notification capability and method
US5767985A (en) * 1994-06-29 1998-06-16 Fuji Xerox Co., Ltd. System employing facsimile units to transmit E-mail between information processors over public telephone lines
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5781886A (en) * 1995-04-20 1998-07-14 Fujitsu Limited Voice response apparatus
US5717498A (en) * 1995-06-06 1998-02-10 Brother Kogyo Kabushiki Kaisha Facsimile machine for receiving, storing, and reproducing associated image data and voice data
US5761283A (en) * 1995-06-16 1998-06-02 Samsung Electronics Co., Ltd. Message processing method of facsimile systems
US5715302A (en) * 1995-06-17 1998-02-03 Samsung Electronics Co., Ltd. Apparatus and method for executing mode conversion of a facsimile system into automatic mode
US20020176117A1 (en) * 1996-10-29 2002-11-28 Douglas J. Randalli Delivery expert system and method
US6636587B1 (en) * 1997-06-25 2003-10-21 Hitachi, Ltd. Information reception processing method and computer-telephony integration system
US6477494B2 (en) * 1997-07-03 2002-11-05 Avaya Technology Corporation Unified messaging system with voice messaging and text messaging using text-to-speech conversion
US6487533B2 (en) * 1997-07-03 2002-11-26 Avaya Technology Corporation Unified messaging system with automatic language identification for text-to-speech conversion
US6549612B2 (en) * 1998-05-06 2003-04-15 Telecommunications Premium Services, Inc. Unified communication services via e-mail
US6856676B1 (en) * 1998-10-15 2005-02-15 Alcatel System and method of controlling and managing voice and data services in a telecommunications network
US6745221B1 (en) * 1999-03-01 2004-06-01 Mitel, Inc. Dynamic resource reallocation
US6981023B1 (en) * 1999-03-09 2005-12-27 Michael Hamilton Message routing
US6466909B1 (en) * 1999-06-28 2002-10-15 Avaya Technology Corp. Shared text-to-speech resource
US6906817B1 (en) * 2000-06-23 2005-06-14 Esker, Inc. Network system for directing the transmission of facsimiles
US20020049817A1 (en) * 2001-07-12 2002-04-25 Eatamar Drory Storageless system and method for unified messaging on existing mail accounts via standard internet mail protocols
US20030193967A1 (en) * 2001-12-31 2003-10-16 Gregg Fenton Method, apparatus and system for processing multimedia messages
US20030164986A1 (en) * 2002-01-30 2003-09-04 Sebastien Boire-Lavigne Fax transmission over the packet network
US20050254083A1 (en) * 2002-03-22 2005-11-17 Jean-Marc Bodart Document processing order management system, method for managing document processing orders, and software product for carring out the method
US7230745B1 (en) * 2002-04-08 2007-06-12 Captaris, Inc. Document transmission and routing with recipient control, such as facsimile document transmission and routing
US20040114194A1 (en) * 2002-12-11 2004-06-17 Murata Kikai Kabushiki Kaisha Facsimile machine
US20050021631A1 (en) * 2003-05-08 2005-01-27 Venali, Inc. Premium messaging exchange
US20050063005A1 (en) * 2003-09-08 2005-03-24 Kevin Phillips Integrated document delivery method and apparatus
US20060189333A1 (en) * 2003-09-12 2006-08-24 Core Mobility, Inc. Unified interface for voice, text or picture message authoring
US20050146753A1 (en) * 2004-01-02 2005-07-07 Jonathan Firooz Multi-functional printer device
US20050219614A1 (en) * 2004-04-02 2005-10-06 Garg Man M Scalable hierarchical-states based job management engine with resource balancing and services monitoring
US20060280165A1 (en) * 2005-06-14 2006-12-14 Gordon Blumenschein Intelligent negotiator node

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8509563B2 (en) * 2006-02-02 2013-08-13 Microsoft Corporation Generation of documents from images
US20070177183A1 (en) * 2006-02-02 2007-08-02 Microsoft Corporation Generation Of Documents From Images
US8984530B2 (en) 2008-01-31 2015-03-17 Microsoft Corporation Queued message dispatch
US20090279123A1 (en) * 2008-05-09 2009-11-12 Hitoshi Sekine Job scheduling in a workflow architecture
US8508768B2 (en) * 2008-05-09 2013-08-13 Ricoh Company, Ltd Job scheduling in a workflow architecture related to printing
US20090300652A1 (en) * 2008-05-29 2009-12-03 Microsoft Corporation Queue dispatch using deferred acknowledgement
US8171495B2 (en) 2008-05-29 2012-05-01 Microsoft Corporation Queue dispatch using deferred acknowledgement
US10839455B2 (en) 2013-01-11 2020-11-17 Capital One Services, Llc Systems and methods for managing a loan application
US20140201062A1 (en) * 2013-01-11 2014-07-17 Capital One Financial Corporation Systems and Methods for Managing a Loan Application
US10991039B2 (en) 2013-01-11 2021-04-27 Capital One Services, Llc Systems and methods for managing a loan application
US10262363B2 (en) * 2013-01-11 2019-04-16 Capital One Financial Corporation Systems and methods for managing a loan application
US10269063B2 (en) * 2013-01-11 2019-04-23 Capital One Financial Corporation Systems and methods for managing a loan application
US20170230544A1 (en) * 2014-06-24 2017-08-10 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible internet fax architecture
US10477069B2 (en) 2014-06-24 2019-11-12 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible internet fax architecture
US10477070B2 (en) 2014-06-24 2019-11-12 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible Internet fax architecture
US10674040B2 (en) * 2014-06-24 2020-06-02 EC Data Systems, Inc. Audit logging for a secure, scalable and flexible internet fax architecture
US10277778B2 (en) * 2014-06-24 2019-04-30 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible internet fax architecture
US10089150B2 (en) 2015-02-03 2018-10-02 Alibaba Group Holding Limited Apparatus, device and method for allocating CPU resources
US11138539B2 (en) * 2017-08-25 2021-10-05 Target Brands, Inc. Robtic business process automation system utilizing reusable task-based microbots

Also Published As

Publication number Publication date
US11716404B2 (en) 2023-08-01
US20140344393A1 (en) 2014-11-20
US10594822B2 (en) 2020-03-17
US20100182635A1 (en) 2010-07-22
US8823976B2 (en) 2014-09-02
US20200204641A1 (en) 2020-06-25

Similar Documents

Publication Publication Date Title
US11716404B2 (en) Queue processor for document servers
CA2628099C (en) Queue processor for document servers
US10652423B2 (en) Configurable document server
US9374479B2 (en) Integrated document delivery method and apparatus
CA2741494C (en) Universal document transport
US20230319159A1 (en) Queue processor for document servers

Legal Events

Date Code Title Description
AS Assignment

Owner name: CAPTARIS, INC., WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:REBERT, TREBER;ISABELLE, JONATHAN;WEBSTER, JASON K.;REEL/FRAME:019126/0987;SIGNING DATES FROM 20070117 TO 20070126

AS Assignment

Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT, CALIFORNIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:CAPTARIS, INC.;REEL/FRAME:020362/0679

Effective date: 20080102

Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT,CALIFORNIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:CAPTARIS, INC.;REEL/FRAME:020362/0679

Effective date: 20080102

AS Assignment

Owner name: CAPTARIS, INC., WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;REEL/FRAME:021849/0895

Effective date: 20081117

Owner name: CAPTARIS, INC.,WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;REEL/FRAME:021849/0895

Effective date: 20081117

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION