Surya R. Sagi et al.

Patent Trials and Appeals Board

Aug 22, 2019

13341942 - (D) (P.T.A.B. Aug. 22, 2019)

UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 13/341,942 12/31/2011 Surya R. Sagi G-576-O1 1054 919 7590 08/22/2019 PITNEY BOWES INC. INTELLECTUAL PROPERTY & PROCUREMENT LAW DEPT. 27 Waterview Drive Shelton, CT 06484 EXAMINER KLOBERG, PAUL R ART UNIT PAPER NUMBER 3691 NOTIFICATION DATE DELIVERY MODE 08/22/2019 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): iptl@pb.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte SURYA R. SAGI and BERNARD E. GRACY ____________ Appeal 2018-005996 Application 13/341,942 Technology Center 3600 ____________ Before HUNG H. BUI, NABEEL U. KHAN, and MICHAEL M. BARRY, Administrative Patent Judges. BARRY, Administrative Patent Judge. DECISION ON APPEAL Appellants1 appeal under 35 U.S.C. § 134(a) from a final rejection of claims 1, 4-6, 10-13, and 15-20, which are all the pending claims. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM-IN-PART. 1 Appellants identifies Pitney Bowes Inc. as the real party in interest. Br. 2. Appeal 2018-005996 Application 13/341,942 2 Introduction Appellants describe the disclosed embodiments of the invention as “relat[ing] generally to document delivery systems and, more particularly, to new and useful systems and methods for managing mail documents including creating recipient reminders and calendar entries.” Spec. ¶ 2. Appellants state that a problem arises from “a need, among other needs, for systems and methods to provide mail recipients with a convenient, efficient mechanism for managing and scheduling actions related to digital mail.” Spec. ¶ 6 (further stating there are needs to “provide such features in an integrated environment for both physical and digital mail”). Claims 1, 6, and 13 are independent; claims 1 and 13 are illustrative: 1. A computer system for organizing mail communications and scheduling related actions for a mail recipient user comprising: a mail notification processor and associated memory that provides a calendar display to the user, wherein the calendar display displays at least two items, the first one of the at least two items is automatically received electronically from a print stream processor and includes time sensitive data related to a first mail piece, the first mail piece comprising a bill and the corresponding time sensitive data includes a due date and a due amount; and the second one of the at least two items is input by the user and includes time sensitive data related to a second mail piece, the second mail piece comprising an offer and the corresponding time sensitive data includes an expiration date associated with the offer. 13. A computer implemented method for sending mail scheduling data to an integrated mail information system, the integrated mail information system used by a first user and a second user, comprising: Appeal 2018-005996 Application 13/341,942 3 utilizing the computer to process at least one print stream, and in processing the at least one print stream, processing a first mail piece directed to the first user and a second mail piece directed to the second user, determining that the first mail piece is to be delivered electronically; determining that the second mail piece is to be delivered physically; obtaining first time sensitive data from the print stream associated with the first mail piece; obtaining second time sensitive data from the print stream associated with the second mail piece; creating a first mail scheduling message including the first time sensitive data and calendar data for display in calendar view form; creating a second mail scheduling message including the second time sensitive data and calendar data for display in calendar view form; sending the first mail piece to the first user electronically; sending the first mail scheduling message electronically to the integrated mail information system for display to the first user in calendar view form; sending the second mail piece to a physical delivery subsystem for physical delivery to the second user; and sending the second mail scheduling message electronically to the integrated mail information system for display to the second user in calendar view form. Br. (App’x A (Claims) pp. i-iii). Appeal 2018-005996 Application 13/341,942 4 The Pending Rejection 2 The Examiner rejected claims 1, 4-6, 10-13, and 15-20 under 35 U.S.C. § 101 as ineligibly directed to a judicial exception. Final Act. 2-8; see also Ans. 4-10. ANALYSIS Appellants argue the Examiner erred in the § 101 rejection of the independent claims and present no separate arguments for the dependent claims (which, accordingly, stand or fall with their respective parent independent claims). Br. 4-7; 37 C.F.R. § 41.37(c)(1)(iv). § 101 General Legal Framework and the USPTO Guidance An invention is patent-eligible if it claims a “new and useful process, machine, manufacture, or composition of matter.” 35 U.S.C. § 101. The Supreme Court, however, has long interpreted 35 U.S.C. § 101 to include implicit exceptions: “[l]aws of nature, natural phenomena, and abstract ideas” are not patentable. E.g., Alice Corp. v. CLS Bank Int’l, 573 U.S. 208, 216 (2014) (internal quotation marks and citation omitted). In determining whether a claim falls within an excluded category, we are guided by the Supreme Court’s two-step framework, described in Mayo and Alice. Id. at 217-18 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66, 75-77 (2012)). In accordance with that framework, we first determine what concept the claim is “directed to.” See Alice, 573 U.S. at 219 (“On their face, the claims before us are drawn to the concept of 2 In response to Appellants’ arguments in the Appeal Brief, the Examiner’s Answer withdrew the Final Action’s rejections of claims 1, 4-6, 10-13, and 15-20 under 35 U.S.C. § 103(a). See Ans. 3. Appeal 2018-005996 Application 13/341,942 5 intermediated settlement, i.e., the use of a third party to mitigate settlement risk.”); see also Bilski v. Kappos, 561 U.S. 593, 611 (2010) (“Claims 1 and 4 in petitioners’ application explain the basic concept of hedging, or protecting against risk.”). Concepts determined to be abstract ideas, and, thus, patent ineligible, include certain methods of organizing human activity, such as fundamental economic practices (Alice, 573 U.S. at 219-20; Bilski, 561 U.S. at 611); mathematical formulas (Parker v. Flook, 437 U.S. 584, 594-95 (1978)); and mental processes (Gottschalk v. Benson, 409 U.S. 63, 69 (1972)). Concepts determined to be patent eligible include physical and chemical processes, such as “molding rubber products” in Diamond v. Diehr, 450 U.S. 175, 191 (1981). If the claim is “directed to” an abstract idea, we turn to the second step of the Alice and Mayo framework, where “we must examine the elements of the claim to determine whether it contains an ‘inventive concept’ sufficient to ‘transform’ the claimed abstract idea into a patent-eligible application.” Alice, 573 U.S. at 221 (internal citation omitted). “A claim that recites an abstract idea must include ‘additional features’ to ensure ‘that the [claim] is more than a drafting effort designed to monopolize the [abstract idea].’” Id. (alterations in original) (quoting Mayo, 566 U.S. at 77). “[M]erely requir[ing] generic computer implementation[] fail[s] to transform that abstract idea into a patent-eligible invention.” Id. In early 2019 the PTO published revised guidance on the application of § 101. 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50-57 (Jan. 7, 2019) (“Guidance”). Under the Guidance, we first look, in step one of the Alice/Mayo analysis, to whether the claim recites: Appeal 2018-005996 Application 13/341,942 6 (1) any judicial exceptions, including certain groupings of abstract ideas (i.e., mathematical concepts, certain methods of organizing human activity such as a fundamental economic practice, or mental processes) (“prong one”); and (2) additional elements that integrate the judicial exception into a practical application (“prong two”) (see MPEP § 2106.05(a)-(c), (e)-(h)).3 See Guidance, 84 Fed. Reg. at 53-55. Only if a claim (1) recites a judicial exception and (2) does not integrate that exception into a practical application, do we then look to whether the claim adds “significantly more” under step two of the Alice/Mayo analysis, i.e., whether the claim: (3) adds a specific limitation beyond the judicial exception that are not “well-understood, routine, conventional” in the field (see MPEP § 2106.05(d)); or simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception. See Guidance, 84 Fed. Reg. at 56. Alice/Mayo Step One, Guidance Step 2A, Prong One (Do the Claims Recite a Patent-Ineligible Concept?) Under the first prong of step 2A of the Guidance, we determine whether the independent claims recites a patent-ineligible concept. Claims 1 and 6 Based on their significant relevant similarities, we consider claims 1 and 6 together. Claims 1 and 6 recite the same preamble for a “system for organizing mail communications and scheduling related actions for a mail 3 All references to the MPEP are to the 9th ed., Rev. 08.2017 (Jan. 2018). Appeal 2018-005996 Application 13/341,942 7 recipient.”4 Claim 1 recites “provid[ing] a calendar display” that displays two mail-related items. The first item “includes time sensitive data related to a first mail piece” that comprises “a bill” and “includes a due date and a due amount.” The second item “includes time sensitive data related to a second mail piece” that comprises “an offer” and “includes an expiration date associated with the offer.” The first item is “received” and the second item “is input by the user.” Relatedly, claim 6 recites “provid[ing] a calendar display” that displays four items-“two items associated with a first mail type” and “two items associated with a second mail type.” Each of the four items includes “time sensitive data” that is related to a “mail piece.” The first mail type “includ[es] bills and . . . a due date and a due amount.” The second mail type “includ[es] offers and the time sensitive data including an expiration date for the offer.” Claim 6 also recites that “the calendar display is a 4 To determine whether the claims recite a judicial exception, our analysis under prong one of the Guidance puts aside the high-level technological limitations in the claims such as “[a] computer system,” “a mail notification processor and associated memory,” and “electronically from a print stream processor.” We consider such limitations in our analysis under prong two of the Guidance (for determining whether a claim that recites a judicial exception is directed to that exception, or whether instead it integrates the exception into a practical application) and under step two of the Alice/Mayo framework (for determining whether a claim that is directed to a judicial exception recites significantly more than that exception). Although at this stage of our analysis we put aside these high-level technological limitations, we remain mindful that we must not express the basic concept of the claim in a way that is “untethered from the language of the claims.” Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1337 (Fed. Cir. 2016). Our analysis that follows assesses what the claims otherwise recite at the same level of generality or abstraction expressed in the claims. Id. Appeal 2018-005996 Application 13/341,942 8 monthly view, and has distinct coding for each of the first mail type and the second mail type.” Under their broadest reasonable interpretation, the foregoing recitations of claims 1 and 6 describe systems that encompass a manual calendaring system that people can implement with only pen and paper. For example, claim 1 recites limitations that encompass a manual system for using a paper calendar for (a) recording, based on data from a bill received in the mail, a calendar entry that identifies how much to pay on a future date, and (b) recording, based on an offer letter received in the mail, a calendar entry that identifies the deadline for the offer. Claim 6 similarly recites limitations that encompass a manual system for using a paper calendar for recording two calendar entries based on data from two received bills and two calendar entries based on two received offers (using a monthly view for the calendar and distinct coding for the two mail types). Thus, claims 1 and 6 describe (recite) systems for organizing mail communications for calendaring related actions for a mail recipient. A human can implement such a system with only the assistance of pen and paper. Thus, claims 1 and 6 describe systems for implementing mental processes or a process of managing human behavior as one of certain methods of organizing human activity that courts have found constitutes an abstract idea. Guidance, 84 Fed. Reg. at 52; see also id. n.14 (citing, inter alia, Versata Dev. Grp. v. SAP Am., Inc., 793 F.3d 1306, 1335 (Fed. Cir. 2015) (“Courts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.”)); Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1318 (Fed. Cir. 2016) (“[W]ith the Appeal 2018-005996 Application 13/341,942 9 exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.”); Mortg. Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324 (Fed. Cir. 2016) (holding that computer- implemented method for “anonymous loan shopping” was an abstract idea because it could be “performed by humans without a computer”). Accordingly, in view of the Guidance and relevant precedent, we determine that claims 1 and 6 recite organizing mail communications for calendaring of related actions for a mail recipient and, thus, an abstract idea under the Guidance. Claim 13 Claim 13 recites a “method for sending mail scheduling data to an integrated mail information system.” A first “mail piece” is determined “to be delivered electronically” to a first user, and a second mail piece is determined “to be delivered physically” to a second user.5 “[T]ime sensitive data” is obtained from processing of the mail pieces, and a “scheduling message” that includes the time sensitive data “and calendar data for display in calendar view form” is created for each mail piece. The two scheduling messages are sent “to the integrated mail information system for display to” each of the respective users. The first mail piece is sent electronically to the first user and the second piece is sent “to a physical delivery subsystem for physical delivery to the second user.” 5 See supra note 4. Here, although “electronically” is a technology-related term, the specific limitation of “determining that the first mail piece is to be delivered electronically” is, as discussed infra, recites an activity that people can and routinely do perform. Appeal 2018-005996 Application 13/341,942 10 Under their broadest reasonable interpretation, the foregoing recited limitations of claim 13 describe a process that encompasses human activities and mental processes for mail processing and calendaring. For example, making a determination to deliver mail electronically or physically is a routine mental process. Similarly, people routinely perform the mental process of inspecting mail items to identify (i.e., obtain from them) the recited “time sensitive data.” Recording calendar entries that identify scheduling information in a paper calendar, a routine human activity, constitutes creating a “scheduling message” that is displayed “in calendar view form” (as discussed above for claims 1 and 6, people routinely perform these types of calendar-related activities manually, with the aid only of pen and paper). Keeping in mind the caveat that we must not express a claim’s idea in a way “untethered from the language of the claims” (Enfish, 822 F.3d at 1337), based on requirements from each of the steps recited in claim 13, we also determine claim 13 describes (recites) the abstract idea of determining to send some mail items electronically and some physically, along with calendaring actions for the recipients of those mail items. In accordance with the Guidance, this “compound” idea is an abstract idea, because it constitutes a combination of mental processes and organizing routine human activities for calendaring and sending mail. See Guidance, 84 Fed. Reg. at 52; see also RecogniCorp, LLC v. Nintendo Co. LTD., 855 F.3d 1322, 1327 (Fed. Cir. 2017) (“Adding one abstract idea . . . to another abstract idea . . . does not render the claim non-abstract.”). Appeal 2018-005996 Application 13/341,942 11 Guidance Step 2A, Prong One Conclusion Because each of claims 1, 6, and 13 recites an abstract idea, we next proceed to the Guidance step 2A prong two to consider whether each of the claims integrates its recited judicial exception into a practical application. See Guidance, 84 Fed. Reg. at 54. Before proceeding we note the differences between what the Examiner identified-“an abstract idea of processing data related to illustrative systems and methods for allowing a mail recipient to manage and schedule events relating to mail” (Final Act. 4)-and the abstract ideas we identify above for claims 1, 6, and 13 do not give rise to a reversible error, i.e., the differences do not constitute a change in the thrust of the rejection. Alice/Mayo Step One, Guidance Step 2A, Prong Two (Do the Claims Integrate the Abstract Idea into a Practical Application?) To determine whether the judicial exception is integrated into a practical application, we identify whether there are “any additional elements recited in the claim beyond the judicial exception(s)” and evaluate those elements to determine whether they integrate the judicial exception into a practical application. Guidance, 84 Fed. Reg. at 54-55 (emphasis added); see also MPEP § 2106.05(a)-(c), (e)-(h). Claims 1 and 6 Independent claim 1 recites the computer-related terms of a “computer,” a “mail notification processor and associated memory,” and “automatically received electronically from a print stream processor.” Claim 6 recites the same terms except that it omits “automatically.” Claim 1 combines these technology-related limitations (shown in italics) with the limitations reciting the judicial exception as follows (claim 6 similarly combines its technological limitations with its abstract idea limitations): Appeal 2018-005996 Application 13/341,942 12 1. A computer system for organizing mail communications and scheduling related actions for a mail recipient user comprising: a mail notification processor and associated memory that provides a calendar display to the user, wherein the calendar display displays at least two items, the first one of the at least two items is automatically received electronically from a print stream processor and includes time sensitive data related to a first mail piece, the first mail piece comprising a bill and the corresponding time sensitive data includes a due date and a due amount; and the second one of the at least two items is input by the user and includes time sensitive data related to a second mail piece, the second mail piece comprising an offer and the corresponding time sensitive data includes an expiration date associated with the offer. Appellants contend claims 1 and 6 are not directed to an abstract idea because they are “related to a mail notification processor and associated memory configured to provide a calendar display to the user based on information received from mail items” and “the claims are directed to a problem of recent nature finding its roots in the world of computing.” Br. 5. This argument is unpersuasive, however. The “mail notification processor and memory configured to provide a calendar display” are merely generic technological limitations to automate the recited abstract idea of organizing mail communications for calendaring related actions for a mail recipient. These computer-related limitations in claims 1 and 6 are all high- level recitations that do not serve to improve a technology or technical field. “Computer” and “memory” are generic terms. Regarding “mail notification processor,” the Specification does not provide a special meaning, and those Appeal 2018-005996 Application 13/341,942 13 of ordinary skill in the art would have understood the term to encompass any processor used to perform the relevant functionality recited in the claims. In other words, in view of the recited limitations for providing “a calendar display to the user,” “mail notification” is patently insignificant nonce label for the “mail notification processor,” as recited. Regarding “print stream processor,” ordinarily skilled artisans would have understood this constitutes a high-level recitation of well-known computer processor technology for computerized processing of printer-related data. See, e.g., U.S. Patent Nos. 6,337,743 B1, 6,433,881 B1, and 6,483,599 B1. The technological limitations in claims 1 and 6 are all recited at a high level and used for their ordinary purposes, and they do not constitute an improvement to “the functioning of the computer itself” or “‘any other technology or technical field.’” See MPEP § 2106.05(a) (quoting Alice, 573 U.S. at 225). Neither do these limitations qualify as applying the judicial exception with “a particular machine,” because these components provide their conventional functions and require no more than general purpose equipment. See MPEP § 2106.05(b); see also Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17 (Fed. Cir. 2014); SiRF Tech., Inc. v. Int’l Trade Comm’n, 601 F.3d 1319, 1333 (Fed. Cir. 2010) (“In order for the addition of a machine to impose a meaningful limit on the scope of a claim, it must play a significant part in permitting the claimed method to be performed, rather than function solely as an obvious mechanism for permitting a solution to be achieved more quickly.”). The use of device limitations for implementing the abstract idea do not serve to integrate the abstract idea into a practical application. The Supreme Court has “rejected the argument that ‘implement[ing] a principle Appeal 2018-005996 Application 13/341,942 14 in some specific fashion’ will ‘automatically fal[l] within the patentable subject matter of § 101.’” Alice, 573 U.S. at 222 (quoting Flook, 437 U.S. at 593). Claims 1 and 6 do not effect a particular transformation of the recited articles, which are simply used for their ordinary purposes, nor do they add any other meaningful (technological) limitations, i.e., limitations beyond simply “linking the use” of the abstract idea to generic technology. See MPEP § 2106.05 (c), (e)-(f); see also id. at (g)-(h) (use of well-known limitations beyond the judicially excepted matter constitutes “insignificant extra-solution activity” (g) and claim limitations “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more” (h)). Moreover, claims 1 and 6 are unlike the claims at issue in Enfish, which were patent eligible as “directed to a specific improvement to the way computers operate, embodied in [a] self-referential table.” 822 F.3d at 1336. The computer-related limitations in claims 1 and 6 do not alter their focus on issues with organizing communications and calendaring related actions- issues that, as discussed above, encompass purely human activities; in other words, they do not address a problem arising from computer technology or the Internet. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014) (eligible claims “necessarily rooted in computer technology” because they overcame a problem unique to the Internet). Claim 13 In contrast to claims 1 and 6, Appellants’ claim 13 further recites limitations for “an integrated mail information system” and “a physical delivery subsystem for physical delivery” of mail pieces. This is unlike claims 1 and 6, which employ generic technology to implement their recited Appeal 2018-005996 Application 13/341,942 15 abstract ideas, without any limitations for physical mail pieces or delivery of the mail pieces. Specifically, claim 13 requires a “delivery subsystem for physical delivery” of a mail piece as part of a method that requires mail delivery both electronically and physically. Claim 13 further requires “an integrated mail information system” that interfaces with users receiving both electronic and physical mail pieces. These physical and electronic mail piece limitations along with the physical delivery subsystem are integral to the functionality recited for the abstract idea, and this combination of abstract and non- abstract limitations “imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception.” Guidance, 84 Fed. Reg. at 54; see also Diehr, 450 U.S. at 180 n.5 (setting forth three exemplary claims), 192 (holding claims with physical process limitations patent eligible regardless that they recited abstract ideas (in that case, mathematical algorithms) that were fundamental to the process). In other words, we determine claim 13’s combined limitations recite and are directed to a practical application, consistent with MPEP § 2106.05 (a)-(c), (e)-(h). Thus, we determine claim 13 integrates its recited abstract idea into a practical application. Guidance, 84 Fed. Reg. at 54-55. Guidance Step 2A, Prong Two Conclusion Because each of claims 1 and 6 recites a judicial exception and does not integrate it into a practical application, for those claims we next proceed under the Guidance to Alice/Mayo step two, to consider whether each of the claims recites significantly more than its recited exception. Guidance, 84 Appeal 2018-005996 Application 13/341,942 16 Fed. Reg. at 54. Because claim 13 integrates its recited judicial exception into a practical application, we need no further analysis for that claim. Id. Alice/Mayo Step Two; Guidance Step 2B In step two of the Alice/Mayo analysis, we consider whether there are additional limitations that, individually or as an ordered combination, ensure the claims amount to “significantly more” than the abstract idea. Alice, 573 U.S. at 217-18 (citing Mayo, 566 U.S. at 72-73, 77-79). As stated in the Guidance, many of the considerations to determine whether the claims amount to “significantly more” under step two of the Alice framework are already considered as part of determining whether the judicial exception has been integrated into a practical application. Guidance, 84 Fed. Reg. at 56. Thus, at this point of our analysis, we determine if the independent claims add a specific limitation, or combination of limitations, that is not well- understood, routine, conventional activity in the field; or whether, in addition to the recited judicial exception, they recite only well-understood, routine, conventional activities at a high level of generality. Id. Here, Appellants’ claims 1 and 6 do not recite specific limitations (or a combination of limitations) that are beyond what was well-understood, routine, and conventional. The Examiner finds, and we agree, that beyond the limitations for the judicial exception, the technological limitations recited in claims 1 and 6, constitute the use of technology that was well known to those of ordinary skill prior to the invention. Final Act. 5-7. As the Examiner finds, we agree, and Appellants do not effectively rebut, for the technological limitations recited in claims 1 and 6, Appellants’ Specification discloses the claimed technological features only at a generic level, using such technology for routine, well understood, and conventional Appeal 2018-005996 Application 13/341,942 17 purposes. See Final Act. 5-8 (citing Spec. ¶¶ 27, 32, 49, 53); see also Spec. ¶¶ 70-78. There is no discussion of any special technological consideration for the technological component recited in claims 1 and 6. Appellants contend “[t]here are several specific, necessary limitations included in the claims such that the broad category of organizing human activity is not pre-empted.” Br. 6. This argument is unpersuasive. [T]he proper focus is not preemption per se, for some measure of preemption is intrinsic in the statutory right granted with every patent to exclude competitors, for a limited time, from practicing the claimed invention. See 35 U.S.C. § 154. Rather, the animating concern is that claims should not be coextensive with a natural law, natural phenomenon, or abstract idea; a patent-eligible claim must include one or more substantive limitations that, in the words of the Supreme Court, add “significantly more” to the basic principle, with the result that the claim covers significantly less. See Mayo 132 S. Ct. at 1294. Thus, broad claims do not necessarily raise § 101 preemption concerns, and seemingly narrower claims are not necessarily exempt. CLS Bank Int’l v. Alice Corp., 717 F.3d 1269, 1281 (Fed. Cir. 2013); see also Ariosa Diagnostics, Inc. v. Sequenom, Inc., 788 F.3d 1371, 1379 (Fed. Cir. 2015) (“While preemption may signal patent ineligible subject matter, the absence of complete preemption does not demonstrate patent eligibility.”). Because we find the claimed subject matter covers patent- ineligible subject matter, the pre-emption concern is necessarily addressed. “Where a patent’s claims are deemed only to disclose patent ineligible subject matter under the Mayo framework, [] preemption concerns are fully addressed and made moot.” Ariosa Diagnostics, 788 F.3d at 1379. Appeal 2018-005996 Application 13/341,942 18 Conclusion Appellants do not persuade us of reversible error in the § 101 rejection of claims 1, 4-6, and 10-12. We agree with Appellants that the Examiner erred in the § 101 rejection of claims 13 and 15-20. DECISION We affirm the 35 U.S.C. § 101 rejection of claims 1, 4-6, and 10-12. We reverse the § 101 rejection of claims 13 and 15-20. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv). AFFIRMED-IN-PART Notice of References Cited Application/Control No. Applicant(s)/Patent Under Patent Appeal No. Examiner Art Unit Page 1 of 1 U.S. PATENT DOCUMENTS * Document Number Country Code-Number-Kind Code Date MM-YYYY Name Classification A US- B US- C US- D US- E US- F US- G US- H US- I US- J US- K US- L US- M US- FOREIGN PATENT DOCUMENTS * Document Number Country Code-Number-Kind Code Date MM-YYYY Country Name Classification N O P Q R S T NON-PATENT DOCUMENTS * Include as applicable: Author, Title Date, Publisher, Edition or Volume, Pertinent Pages) U V W X *A copy of this reference is not being furnished with this Office action. (See MPEP § 707.05(a).) Dates in MM-YYYY format are publication dates. Classifications may be US or foreign. U.S. Patent and Trademark Office PTO-892 (Rev. 01-2001) Notice of References Cited Part of Paper No. (12) United States Patent Woodman et al. USOO6483599B1 US 6,483,599 B1 Nov. 19, 2002 (10) Patent No.: (45) Date of Patent: (54) SYSTEM AND METHOD FOR SEPARATING 5,608,786 A 3/1997 Gordon et al. .............. 379/100 A PRINT STREAM INTO AN ELECTRONIC 5,627,764 A 5/1997 Schutzman et al. ..... 364/514 R DOCUMENT PRINT STREAM AND A 3: E. Erm 'E, Y/ - aIKIS C. a. ............. PHYSICAL DOCUMENT PRINT STREAM 5,675,507 A 10/1997 Bobo, II .......... ... 364/514 R (75) Inventors: Clare E. Woodman, Norwalk, CT A E. sing - - - - - - - - - - - - - - - - - - - - 395/234 2Y- - -2 Oyle et al. .................. 705/26 (US); David P. Gardner, Southbury, 5,696,906. A 12/1997 Peters et al. . ... 705/34 CT (US) 5,699,528 A 12/1997 Hogan ......... ... 705/40 (73) Assignee: Pitney Bowes Inc., Stamford, CT (US) 5,761,650 A 6/1998 Munsil et al. ................ 705/34 - 0 (List continued on next page.) (*) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 OTHER PUBLICATIONS U.S.C. 154(b) by 0 days. “Methodology for Mail Delivery in a Multi-Media Envi (21) Appl. No.: 09/222,528 ronment”, IBM Technical Disclosure Bulletin, Apr. 1993. “The Future of Mail and Messaging, Brian Baxendale, President Pitney Bowes, Production Mail & Software Sys (22) Filed: Dec. 29, 1998 tems Division, Dec. 1996/Jan. 1997, Mail: The Journal of Communication Distribution. 7 (51) Int. Cl." ................................................ G06F 15/00 Primary Examiner-Gabriel Garcia (52) U.S. Cl. ................. ... 358/1.15; 358/1.1 (74) Attorney, Agent, or Firm Michael J. Cummings; (58) Field of Search ............................... 358/1.15, 1.13, Angelo N. Chaclas 358/1.18, 1.6, 1.1, 407, 468; 705/14, 10, 26, 27; 382/101, 102 (57) ABSTRACT (56) References Cited An apparatus for Separating print Stream data containing a U.S. PATENT DOCUMENTS plurality of primary documents and information concerning a asSociated customers to receive the documents, wherein the 4,908.850 A 3/1990 Masson ....................... 379/88 apparatus receives customer preference data that allow sepa 4.941,091 A 7/1990 Breault et al. .............. 364/406 ration of the print Stream data into an electronic primary 5,142,662 A 8/1992 Gump et al. ... ... 395/100 document print Stream and a hard copy primary document 5,187,787 A 2/1993 Skeen .......... ... 395/600 print Stream. The print Stream Separator further generates a E. R. E. E. "...O.E. second output for the customers that are to receive their 5,283,829. A 2/1994 Anderson ...................... 3800 primary documents by electronic delivery, where this second 5,381.527 A 1/1995 Inniss et al. ... ... 395/200 output contains information regarding which of a plurality of 5,383,113 A 1/1995 Kight et al. .................. 705/40 Secondary documents the customer should receive with the 5,465,206. A 11/1995 Hilt et al. ..................... 705/40 primary document. The priorities of these Secondary docu 5,479,411 A 12/1995 Klein ........ ... 370/110.1 ments may be based upon Specific customer preference data 5,483,445 A 1/1996 Pickering ..................... 705/40 for the Specific customer receiving his or her primary 5,493,692 A 2/1996. Thelmer et al. .. ... 455/26.1 document. Priorities for these Secondary documents can also 5... A 3. R" - - - - - - - - 5.3. be included in this Second output. A method corresponding 5509,071 A 4/1996 E. Jr. et al. ............... S. to this apparatus is also described. 5,513,126 A 4/1996 Harkins et al. ......... 364/514 A 5,579,087 A * 11/1996 Salgado ...................... 358/296 10 Claims, 4 Drawing Sheets "N 4 S 13 18 20 Z PRINT STREA DIGITA ACCOUNTS E. EE H SEPARATOR ( D ACCOUNT DAA FILE ENR) JOS SETUP I-32 CONTROL IBS1370 APPLICATION & (J8) REPORTING EMRF 30 J08 -39 27 CONTROL SETUP DATA 33 INSERTATA (HOTLINKS 28 25 DATA ECORS 3i S STATUS 37 BILL REQUEST (St. 26N ELECTRONIC REQUEST INSERER AFP EI) FILE 24 AFP 34 AFR FELE HIGH YOL PRINTER-22 He AFP DROPOFFOTRICTORY ROUTER /36 INSTRUCTION PROCESSGR RIP) RAAFP FILE US 6,483,599 B1 Page 2 U.S. PATENT DOCUMENTS 5,884.284 A 3/1999 Peters et al. .................. 705/30 5,956,693 A 9/1999 Geerlings .................... 705/14 5,790,790 A 8/1998 Smith et al. ................ 395/200 5,963,925 A 10/1999 Kolling et al. ................ 705/40 5,794.221 A 8/1998 Egendorf ...... ... 705/40 6,031,625 A 2/2000 Sherman et al. ... 358/1.18 5,802.498 A 9/1998 Comesanas ...... ... 705/34 6,044,362 A 3/2000 Neely ............... ... 705/34 5,825.865 A 10/1998 Oberlander et al. ... 379/211 2001/0014164 A1 8/2001 Daniels et al. . 358/1.15 5,832,460 A 11/1998 Bednar et al. ... ... 705/27 2001/0049659 A1 12/2001 Eckl............................ 705/40 5,872,926 A 2/1999 Levac et al. .. 395/200.36 5,873,073. A 2/1999 Bresnan ...................... 705/410 * cited by examiner US 6,483,599 B1 Sheet 1 of 4 Nov. 19, 2002 U.S. Patent US 6,483,599 B1 1 SYSTEMAND METHOD FOR SEPARATING A PRINT STREAM INTO AN ELECTRONIC DOCUMENT PRINT STREAM AND A PHYSICAL DOCUMENT PRINT STREAM BACKGROUND OF THE INVENTION In the development of a digital data delivery System, it is found that an analog to the physical generation of a printed document is advantageous for acceptance of an electronic version of the document for presentation to an end-user Such as a customer receiving for instance, a bill from a company with which that customer does business. In many legacy computer Systems, mainframe computers are used to gen erate print Stream information in one of a plurality of formats, including the AFP file format. It is thus desirable to be able to use Such a file format as the basis for generating electronic document in a digital document delivery System. SUMMARY OF THE INVENTION A print Stream Separator according to the present inven tion receives print Stream data from an associated generator of Such information, Such as a legacy mainframe computer print Stream output. Such information in a typical applica tion may contain a plurality of customer bills for presenta tion to the customers of a particular company. Bill informa tion and accompanying customer account information form at least part of this print Stream. Such information in the past would generally be directed to a high Speed, high Volume printer in a particular file format such as the AFP file format for generation of the customer bills with insertion of one or more hard copy inserts, typically of an advertisement or informational nature. Such inserts are put into the custom er's bill based upon information concerning the identified customer as derived from a customer preference database and with the Specific inserts being determined based upon a prioritization in view of information received from the customer preference database So as to maintain a certain weight limit for the hard copy mailing. The present invention provides a print Stream Separator which receives the initial print Stream data, as well as information from a customer preference database. The print Stream Separator then determines which documents are to be generated in electronic form and which are to be directed to a high Speed, high Volume printer, Such that the data presented to the high Speed, high Volume is separate and distinct from the data Sent for ultimate presentation and Viewing in electronic form. Information within the customer preference file for each customer is the basis upon which a determination is made as to directing the print Stream either to the high Speed, high Volume printer or to an electronic inserter for presentation in electronic form. If the data is to be presented in electronic form, the print Stream Separator generates two outputs, a first output rep resenting the customer primary document to be ultimately viewed by the customer, as well as an Electronic Mail Run Data File (EMRDF), which includes a header and fields containing information directed to that customer and the preference of inserts to be generated with the primary document for that customer. Both the electronic document print stream and the EMRDF document record for the customer are then presented to the electronic inserter, which in turn receives job Setup data from an associated job Setup application module, including information for links associ ated with particular inserts to be associated with the cus tomer's primary document. The electronic inserter generates 15 25 35 40 45 50 55 60 65 2 an output print Stream in an AFP file format containing the primary document information. The EMRDF file is com municated to the router instruction processor (RIP) and contains information regarding specific links for “inserts' (secondary documents) which are to be associated with the primary document. AS more fully described in co-pending application Ser. No. 09/222,196 entitled System and Method for Presenting and Processing Documents on the Internet, filed on the same date herein, and assigned to the same assignee, the print data Stream from the electronic inserter is presented to an inter active bill presentation server (IBPS), under the control of a bill processing server (BPS). The IBPS output is ultimately presented to a customer having access to a computer with an associated web browser so as to allow view of the primary document and the associated inserts. The customer can, after viewing the primary document (which typically would be in the nature of a bill), respond to the primary document (bill) Such as to make payment thereof. This response information is processed by the overall digital document delivery System by means of the bill processor server which updates the customer's account database Such as to indicate payment of a bill or the like. BRIEF DESCRIPTION OF THE DRAWINGS FIGS. 1A and 1B form an overall block diagram of a digital document delivery System according to the present invention illustrating the print Stream Separator and the asSociated electronic inserter forming part of the overall System and method. FIG. 2 is a block/flow diagram of the electronic inserter and router instruction processor shown in FIGS. 1A and 1B. FIG. 3 is a block/flow diagram of the router instruction processor, bill processing Server and interactive bill present ment server shown in FIGS. 1A and 1B. DETAILED DESCRIPTION AS used throughout this description, the words “user” and “customer' are synonymous as are the words “bill” and “primary document” and the words “insert” and “secondary document”. Definitions of acronyms are presented in Table 1. FIGS. 1A and 1B form an overall block diagrams of a digital document delivery System of which the print Stream separator 16 and electronic insert 26 form a part thereof. Full disclosure concerning the Overall operation of the digital document delivery System is presented in the aforemen tioned co-pending application Ser. No. 09/222,196 filed Dec. 29, 1998 entitled: System and Method for Presenting and Processing Documents on the Internet, assigned to the present assignee, and incorporated herein by reference. The present invention is Specifically directed to the mechanism by which a print Stream generated by a computer System or the like Such as a legacy mainframe computer 12 can be used as the input to a print Stream Separator So as to Separate this print Stream into a first print Stream 24 intended for hard copy printing via a high Speed, high Volume printer 22 and a second print stream 25 intended for ultimate electronic delivery. The data emanating from the computer on output 14 typically represents a print Stream of primary documents Such as bills for customers of a public utility or the like. It is desired to be able to identify those documents which are intended for electronic distribution and to Separate these documents from the print Stream 14 So as to be deliverable in electronic form, while the remaining docu US 6,483,599 B1 3 ments which are intended for hard copy printing are directed to the Second print Stream 24. The print Stream Separator based upon customer informa tion in the print stream 14 (which may be the customer's account number with the proprietor of the digital document delivery) identifies those documents intended for electronic delivery by comparing Such information with information received from the customer's preference file 18 via a com munication path 19, and thereby creates a separate electronic print Stream 25 for Such documents. Likewise, the print Stream Separator generates the first print Stream 24 intended for hard copy printing, which excludes those documents intended for electronic delivery. Furthermore, the print Stream Separator generates an Elec tronic Mail Run Data File Specification (EMRDF) which contains control and preference information with respect to those electronic documents presented on output 25. The electronic inserter 26 receives both the electronic print stream data 25 and the EMRDF data output 28. The elec tronic inserter generates an electronic output print Stream on output 34 which contains information regarding the elec tronic primary document to be presented to the customer. The EMRDF file containing information concerning any additional Secondary documents known as “inserts' which are intended to be delivered with the primary document to that customer, are presented to the router instruction pro cessor (RIP)36. This technique is thus an electronic analog of the output generated by the high Speed, high volume printer 22, which is also able to insert additional documents with the primary document based upon information received in the print Stream 24. For hard copy, this result is performed by what is known in the art as an inserting System which inserts documents with the primary document, Such as advertising inserts, accompanying a customer bill with the Specific inserts based upon a customer preference file. The customer preference file 18 may contain information concerning the customer Such as the customer's Sex, age, interests and the like. This information can be used by the electronic inserter to determine which of the inserts are of potentially the greatest interest to that customer and thus gives higher priorities to those inserts. The electronic analog does not necessarily need to gen erate the electronic equivalent of Such Secondary documents (inserts) but rather need only contain links which can be used by the customer with an associated computer executing an Internet browser for using those links to access the Specific insert information and viewing Same on the cus tomer's browser. The electronic inserter also receives general customer information from the customer preference file 18 stored in the customer preference database 20 via communication path 30. This information, for instance, can include the customer's e-mail address, facsimile number, beeper number, resident address and the like. It can also include the customer's preference for bill notification; Such as e-mail as the first preference, and fax message as the Second prefer ence. Some of this information can be used to determine how the customer is to be notified (e.g., E-mail, fax, beeper, regular mail) that a primary document is ready for viewing. If the customer does not view the primary document within a predetermined length of time, an alternative method of notification can be used. Furthermore, the electronic inserter receives information from a job Set up application module 32 via communication path 33 which contains information concerning potential inserts and their associated links which may form part of the 15 25 35 40 45 50 55 60 65 4 print Stream 34 for a specific customer, based upon that customer's preferences. In this regard, reference is made to the details of the Electronic Mail Run Data File and how it is used by the electronic inserter to Select inserts to accompany the primary document for a particular customer. The EMRDF is a file that is analogous to the MRDF file structure used with physical print inserters. The EMRDF is intended to contain information that is known only to the mechanism that generates the print Stream. Other files in the System have information about the customer, Such as the customer data base file 20, as well as SpecificS concerning the particular print job as contained in the job Set up application module 32. The EMRDF contains piece-level information for each document in the electronic print System. Its primary purpose is therefore to indicate which electronic insert(s) (Secondary documents(s) is to accompany the primary document, as well as the priority of that insert vis-a-vis other inserts. This information is translated into the equivalent of an electronic insert Such as a hypertext markup language (HTML) page or bit maps, or files in the PDF format, etc., as well as the relative importance for positioning the link to the insert with respect to the primary document. Priorities with regard to physical print inserts are nor mally based upon overall weight of the envelope and its contents and, from that, the inserts typically have priority, Such as “must have’, which means that it is to be inserted if the weight of the overall envelope is under a predetermined amount, Such as one ounce. For electronic presentation, priorities can be of a different nature, for instance, where on the primary document the link to the insert should be displayed to the customer and the like. Thus, customers might want high priority inserts in a more Visible location on the primary document than lower-priority inserts. Higher priority inserts may also contain JAVA lan guage applets for making the insert more Visible or pleasing to the customer. In general, priority data when used for electronic presentation is used by the electronic insert decision-making algorithms for purposes of determining the location and number of inserts to be presented to the customer. The determination of an insert's priority can be fixed (i.e., the same for all customers) or it can be based upon information of the specific customer (i.e., the custom er's age, Sex, occupation, income level and the like). The customer preference can form part of the customer prefer ence data 18 transferred to the print Stream Separator 16. The customer preference data can also be used to deter mine the inclusion or exclusion of a particular Secondary document. As seen in Table 3, parameter “InsertXX” (where “XX” is a number from 1 to 16) is a Boolean parameter which indicates the inclusion or exclusion of a particular insert. The customer preference file can, therefore, be used to Set the true or false State of any of these parameters, which, in the example shown, has information for Sixteen inserts (Insert.01 through Insert16). The EMRDF file contains fields which are all of the type “character'. The character Set can vary depending upon where the EMRDF file is used and, thus, can be in the EBCDIC format when used for mainframe computer output and can be in the ASCII output when used on computer servers using the Microsoft NT operating system or the UNIX operating system. Of course, if the EMRDF file is in the ASCII format and it is to be transferred to a mainframe, it would generally have to first be converted to the EBCDIC format. US 6,483,599 B1 S The fields of the EBRDF file are typically left justified and padded with blanks for the remainder of each field. The file consists of a header record with N piece records, where N is an integer up to Some maximum number of primary docu ments for a given print job, Such as ten million. Each of these record types is defined in Table 2. The records are terminated by two bytes containing carriage return (CR) and line feed (LF) characters (ASCII hex 0D 0A). As set forth in Table 2, the specifics of the record are shown with regard to the header while Table 3 shows the Specifics of the piece records. From these tables, it is clear that the inserts can have a priority based upon the number of inserts. In the preferred embodiment, the priority can be from 1 to 16 for each primary document. AS Seen in Tables 2 and 3, the header record thus contains exactly 40 bytes and the piece record contains exactly 124 bytes. In the preferred embodiment of the invention, there can be up to ten million piece records in a given file. As also seen in FIGS. 1A and 1B, the customer preference database is typically associated with an enrollment applica tion module 27 which interacts with the user, typically over the Internet So as to update the customer preference data asSociated with a given customer. Such information can include address information, interests of the customer, as well as any other pertinent information deemed necessary or desirable for the proprietor of the digital document delivery System. In operation, the print Stream Separator, based upon cus tomer preference data received from the customer prefer ence database, determines which print documents should be Separated from the Overall print Stream for presentation to the electronic inserter. Furthermore, based upon the cus tomer preference data, the details of the Electronic Mail Run Data File can be determined for presentation to the elec tronic inserter. Other data concerning the customer via the customer preference database can be communicated from this data base via communication path 19 to the electronic inserter, Such as the customer's e-mail address, preferences concern ing document notification, and the like. Furthermore, as Seen in FIGS. 1A and 1B, not only does the electronic inserter generate an output print Stream file, typically in an AFP format, but it also can generate control and Status data via communication path 37 to a control and reporting module 39 with control and Status data typically being generated by the electronic inserter for presentation to the controller reporting module. Such information can then be used to determine the Status of a given print run, as well as the nature of the customers and inserts associated with the primary docu ments Sent to the customers in that particular print run. The overall System thus comprises an efficient and con Venient method for extracting documents for electronic delivery to customers from a print Stream which contains print data, with the determination for extraction based upon a customer preference database. Furthermore, the invention provides for the ability of generating links to other docu ments for presentation to the customer in electronic form based upon the preferences of the particular customer who is receiving the electronic primary document. MODULE DETAILS Details of the modules described above So as to achieve the stated operation are presented in Table 4. FIG. 2 shows details of the modules as well as the objects and language protocols used in the preferred embodiment of the present invention. The print Stream Separator, electronic inserter, BPS and IBPS can be implemented on computer Servers, e.g., Intel processor based servers using Microsoft Windows NTTM on 15 25 35 40 45 50 55 60 65 6 UNIXTM operating systems. A high level object oriented language, e.g., Sun MicroSystems JAVA language, can be preferably used to implement the Specific instructions for performing above described tasks. In the foregoing Specification, the invention has been described as referenced to specific embodiments thereof. It will, however, be evident that various modification and changes may be made thereto without departing from the broader Spirit and Scope of the invention. The Specification and drawings are, accordingly, to be regarded as illustrative rather than in a restrictive Sense. TABLE 1. ACRONYMS DEFINITIONS ACH Automated Clearing House AFP Advanced Format for Printing ASCII American Standard Code for Information Exchange CORBA Common Object Request Broker Architecture EBCDIC Extended Binary Coded Decimal Interchange Code HTML Hypertext Markup Language HTTP Hypertext Transport Protocol IIOP Internet Inter-ORB Protocol JDBC JAVA Database Connectivity MRDF Mail Run Data Fle ORB Object Request Broker PDF Portable Document Format SMTP Simple Mail Transfer Protocol XML Extended Markup Language TABLE 2 Parameter Length Offset Description EMRDFID 1O O Identifier for this job PrtStrim) 2O 10 Identifies which print stream, most likely a file, that goes with this EMRDF. For a file, 8-dot-3 naming convention is acceptable. The directory in which the file resides is a job setup parameter. TotalPieces 8 30 Total number of piece records. 10M aX. RecBnd 2 38 CRLF pair; hex ODOA The header record contains exactly 40 bytes. TABLE 3 Parameter Length Offset Description PieceNumber 8 40 Piece number, Unique to file. AccountNumber 2O 48 Customers account number for billing. PaperFlag 68 Y or N indicating whether paper was sent also. TemplateID 5 69 Template for documen composition. InsertO1 74 Y or N indicating whether to include this insert. Insert02 75 Y or N indicating whether to include this insert. Insert03 76 Y or N indicating whether to include this insert. Insert04 77 Y or N indicating whether to include this insert. Insert05 78 Y or N indicating whether to include this insert. Insert06 79 Y or N indicating whether to include this insert. InsertO7 80 Y or N indicating whether to include this insert. US 6,483,599 B1 7 TABLE 3-continued Parameter Length Offset Description Insert08 81 Y or N indicating whether to include this insert. Insert09 82 Y or N indicating whether to CCC. S. Set. Insert10 83 Y or N indicating whether to include this insert. Insert11 84 Y or N indicating whether to include this insert. Insert12 85 Y or N indicating whether to include this insert. Insert13 86 Y or N indicating whether to include this insert. Insert14 87 Y or N indicating whether to include this insert. Insert15 88 Y or N indicating whether to include this insert. Insert16 89 Y or N indicating whether to include this insert. InsertPriority01 2 90 Priority of this insert. 1 to 16 InsertPriority02 2 92 Priority of this insert. 1 to 16 InsertPriority03 2 94 Priority of this insert. 1 to 16 InsertPriority04 2 96 Priority of this insert. 1 to 16 InsertPriority05 2 98 Priority of this insert. 1 to 16 InsertPriority06 2 100 Priority of this insert. 1 to 16 InsertPriority07 2 102 Priority of this insert. 1 to 16 InsertPriority08 2 104 Priority of this insert. 1 to 16 InsertPriority09 2 106 Priority of this insert. 1 to 16 InsertPriority10 2 108 Priority of this insert. 1 to 16 InsertPriority11 2 110 Priority of this insert. 1 to 16 InsertPriority12 2 112 Priority of this insert. 1 to 16 InsertPriority13 2 114 Priority of this insert. 1 to 16 InsertPriority14 2 116 Priority of this insert. 1 to 16 InsertPriority15 2 118 Priority of this insert. 1 to 16 InsertPriority16 2 1120 Priority of this insert. 1 to 16 RecBnd 2 122 CRLF pair; hex ODOA The piece record contains exactly 124 bytes. There can be up to 10 mil lion piece records in a file. TABLE 4 MODULE Enrollment Application Module 27 Print Stream Separator 16 Electronic Inserter 26 Job Setup Application 32 Router Instruction Processor (RIP) 36 Database Account 56 FUNCTION Capture customer account number, full name of customer, email address of customer, checking account number, customer's account bank name, bank routing number, WEB password Based on customer account number, split out documents destined by digital delivery, send these documents as AFP file. Get data from Job Setup Module 32, customer preference file from customer preference database 20, print stream separator 16 and EMRDF output, compose bill request objects (bR), receive status messages from RIP, control AFP feed to IBPS. Produce file of inserts in the form of hotlinks that are logically assigned to physical inserter bins. Service incoming requests from multiple clients (EIs), route requests to FAX, EMAIL, WEB, LOCAL PRINT, and PAGER, issue notifications based on status received, process status back to clients. Store remittance data, bill data, and status data for digital bills. 15 25 35 40 45 50 55 60 65 8 TABLE 4-continued MODULE FUNCTION Save and retrieve bill data to the database, service CORBA requests for hotlinks from IBPS, process bill status messages from IBPS back to the RIP, issue reports and initiate payments feeds. Process interactive events performed on the bill by customers, render HTML to customers based on downloaded servlets and stored XML rules, design document templates. Bill Processing Server (BPS) 42 Interactive Bill Present Server (IBPS) 44 What is claimed is: 1. An apparatus for Separating print Stream data contain ing a plurality of primary documents and information con cerning associated customers for receipt of each primary document, Said print Stream data to be separated into at least two data paths by Said apparatus, one path of which is for electronic delivery of an electronic primary document with N Secondary documents inserts, where N is a non-negative integer including 0, Said apparatus comprising: a print Stream Separator having: A) means for receipt of the print Stream data and means for receipt of customer preference data regarding at least Some of the customers to which said print Stream is directed; B) means based upon the customer preference data for determining if a particular primary document in the print Stream is intended for electronic delivery to the associated customer and if so, generate an output of the print Stream for electronic delivery thereof; and C) means for generating an output for the remaining print Stream data for non-electronic delivery thereof; an electronic inserter for receipt of the print Stream for electronic delivery and for receiving the Second output related to the preferences of the associated customer, for generating an electronic print Stream output con taining the primary document associated with the customer, as well as information with respect to each Secondary document to be associated with the primary document based upon the customer preference data, the electronic inserter having: A) means for receipt of job Setup data which contains information concerning links directed to Secondary documents that can be associated with a primary document for delivery to a particular customer elec tronically; and B) means for generating control and status data con cerning the electronic print Stream output generated by the electronic inserter; wherein the electronic inserter receives customer prefer ence data from a customer preference database, wherein Said information is used to assist in notifying customers that at least a primary document is available for viewing, wherein the received customer preference data by the electronic inserter can be used to determine the Specific way the customer is notified that at least a primary document is available for viewing, wherein the customer may be notified in more than one way that at least a primary document is available for viewing, and wherein an alternative way of notifying the customer is used if the customer does not view at least the primary document within a predetermined time after initial notification. US 6,483,599 B1 2. An apparatus for Separating print Stream data contain ing a plurality of primary documents and information con cerning associated customers for receipt of each primary document, Said print Stream data to be separated into at least two data paths by Said apparatus, one path of which is for electronic delivery of an electronic primary document with N Secondary documents inserts, where N is a non-negative integer including 0, Said apparatus comprising: a print Stream Separator having: A) means for receipt of the print Stream data and means for receipt of customer preference data regarding at least Some of the customers to which Said print Stream is directed; B) means based upon the customer preference data for determining if a particular primary document in the print Stream is intended for electronic delivery to the asSociated customer and if So, generate an output of the print Stream for electronic delivery thereof; and C) means for generating an output for the remaining print Stream data for non-electronic delivery thereof; an electronic inserter for receipt of the print Stream for electronic delivery and for receiving the Second output related to the preferences of the associated customer, for generating an electronic print Stream output con taining the primary document associated with the customer, as well as information with respect to each Secondary document to be associated with the primary document based upon the customer preference data, wherein the electronic print Stream output of the elec tronic inserter is in the AFP file format. 3. An apparatus for Separating print Stream data as defined in claim 2, wherein the means for determining if a particular primary document is intended for electronic delivery further has means for generating a Second output related to the control and preferences of any Secondary documents to be asSociated with the primary document. 4. An apparatus for Separating print Stream data as defined in claim 3, wherein the Second output of the print Stream Separator contains information regarding which Secondary documents can accompany the primary document. 5. An apparatus for Separating print Stream data contain ing a plurality of primary documents and information con cerning associated customers for receipt of each primary document, Said print Stream data to be separated into at least two data paths by Said apparatus, one path of which is for electronic delivery of an electronic primary document with N Secondary documents inserts, where N is a non-negative integer including 0, Said apparatus comprising: a print Stream Separator having: A) means for receipt of the print Stream data and means for receipt of customer preference data regarding at least Some of the customers to which Said print Stream is directed; B) means based upon the customer preference data for determining if a particular primary document in the print Stream is intended for electronic delivery to the 15 25 35 40 45 50 55 10 asSociated customer and if So, generate an output of the print Stream for electronic delivery thereof; and C) means for generating an output for the remaining print Stream data for non-electronic delivery thereof; wherein the means for determining if a particular primary document is intended for electronic delivery further has means for generating a Second output related to the control and preferences of any Secondary documents to be associated with the primary document; wherein the Second output of the print Stream Separator contains information regarding which Secondary docu ments can accompany the primary document; and wherein the Second output of the print Stream Separator contains information regarding the priorities of the respective Secondary documents that can accompany the primary document. 6. An apparatus for Separating print Stream data as defined in claim 5, wherein the priorities of at least one Secondary document is based at least in part on customer preference data for the customer to receive Said primary document. 7. An apparatus for Separating print Stream data as defined in claim 5, wherein the inclusion or exclusion of at least one Secondary document is based upon customer preference data. 8. A method for Separating print Stream data containing a plurality of primary documents and information concerning asSociated customers for receipt of each primary document, Said print Stream data to be separated into at least two data paths, one path of which is for electronic delivery of an electronic primary document with N Secondary documents inserts, where N is a non-negative integer including 0, Said method comprising the Steps of A) receiving the print stream data and receiving the customer preference data regarding at least Some of the customers to which said print Stream is directed; B) based upon the customer preference data, determining if a particular primary document in the print Stream is intended for electronic delivery to the associated cus tomer and if So, generating an output of the print Stream for electronic delivery thereof; and C) generating an output for the remaining print stream data for non-electronic delivery thereof, and, D) for the print stream intended for electronic delivery, prioritizing any Secondary documents that are to be sent to the customer, Such that Some Secondary documents are given higher priority for inclusion or positioning than other Secondary documents. 9. A method as defined in claim 8, wherein the step of prioritizing at least one of the Secondary documents is based at least in part on customer preference data for the customer to receive the primary document. 10. A method as defined in claim 8, further comprising the Step of notifying the customer that at least a primary document is available for viewing. k k k k k USOO6337743B1 (12) United States Patent (10) Patent No.: US 6,337,743 B1 Brown et al. (45) Date of Patent: Jan. 8, 2002 (54) METHOD AND SYSTEM OF PRINT STREAM 5,680,615. A 10/1997 Marlin et al. ............... 395/614 ADDRESS EXTRACTION 5,684.934 A 11/1997 Chen et al. ................. 395/113 5,869,824. A 2/1999 Okada et al. ............... 235/380 (75) Inventors: Nanette Brown, Norwalk, Victor * cited by examiner Girardi, Oxford, both of CT (US); Michael S. Kelley, Woodinville, WA Primary Examiner Joseph Mancuso (US); Paul A. Kovlakas, Milford, CT Assistant Examiner Douglas Tran (US) (74) Attorney, Agent, or Firm-Ronald Reichman; Paul A. Levitsky; Michael E. Melton (73) Assignee: Pitney Bowes Inc., Stamford, CT (US) (57) ABSTRACT (*) Notice: Subject to any disclaimer, the term of this The invention is a method and System for determining an patent is extended or adjusted under 35 address from a print Stream. Address determination begins U.S.C. 154(b) by 0 days. by initiating the print Stream at a remote application. The print Stream is transmitted through a graphical driver inter (21) Appl. No.: 09/119,183 face to a virtual driver where a System operator can Select a 1-1. data interface mode Such as an eavesdrop mode and an (22) Filed: Jul. 20, 1998 intercept mode. The eavesdrop mode allows the Virtual (51) Int. Cl. ................................................ G06F 15/00 driver to pass the print Stream through to the output device (52) ... 358/1.13: 358/1.15 while producing a duplicate copy of the print Stream for (58) Field of Search ............................... 358/113, 114, transmission to a server which is linked to an address parsing 358/1.15, 1.16 module for parsing the print Stream. The intercept mode allows the Virtual driver to pass the print Stream directly to (56) References Cited the Server for parsing the print Stream. The Server will in turn pass the print Stream to an output device Such as a printer or U.S. PATENT DOCUMENTS monitor over transmission means. Parsing of the print 4,858.907 A 8/1989 Eisner et al. ............... 271/124 Stream to obtain address data is performed in accordance 5,146,439 A 9/1992 Jachmann et al. ............ 369/25 with instructions resident in the module. The address data is 5,175,691. A 12/1992 Baker ......................... 364/478 then placed into an address list or database. The Selection of 5,278.947 A 1/1994 Balga et al. ................ 395/117 the address parsing module is further based upon the address 5,319,562 A 6/1994 Whitehouse ...... ... 364/464.01 characteristics required by the System user. The character 5,326,181 A 7/1994 Eisner et al. ............... 400/104 istics are defined by creating an address data profile com 5,400.243 A 3/1995 Oheda et al. .......... 364/419.17 prised of tokens and wherein the tokens further define a 5,495,581 A 2/1996 Tisai ... . . . . . . . . . . . . . . . . . 395/154 h teristic of an address. The address parsing module can 5546.577 A 8/1996 Marlin et al. 30so enaracteristico sparsing 5583,970 A 12/1996 Strobel ............. ... 395/114 then be selected as based upon its particular address format 5,657.431. A s/1997 Piakoshet al... 395/11s which can be representative of a particular carrier. 5,668,934. A 9/1997 Maw .......................... 395/110 5,668,990 A 9/1997 Bajorinas et al. ........... 395/615 15 Claims, 9 Drawing Sheets 230 232 G) site. We MODE 238 238 PRINT STREAM WRJALRWER DATAPASS pouces REYES THROUGHTO ---DUPLICAE of PRINT ... SELECTED OUTPUT SRAMAA STAM DEWICE 2NECETE DATA ! 234 CONCL p SEE LCATRIN UTILIZATIONFO STREAMATAPASSED THIS PRINT HROUGH TO OE SAM AUOMATION SERVER 240- 244-1 OUPLICATEDATA S PARSE FC ADDRESSAA - Y - ADSSAA NON-ADSS PLACEN 250 E. Eleted ARESS 246 Yes DAABASE FOR - Y - CONCLUD - uTE --- 2ATION 254 FUTURUS Q. 252 - - U.S. Patent Jan. 8, 2002 Sheet 3 of 9 US 6,337,743 B1 FIG. 2B 74 82 84 US 6,337,743 B1 Sheet 5 of 9 Jan. 8, 2002 U.S. Patent FFT HOSSE OOHCHOHOIWN HETTO ZGT H_LNOO HELNIHd HELNIHc] ÕST EN 15DNE3FT ÅBO WEWN U.S. Patent Jan. 8, 2002 Sheet 6 of 9 US 6,337,743 B1 2OO NITIATE PRINT STREAM FROM FG. 4 REMOTE APPLICATION 2O6 204 TRANSMIT PRINT STREAM THRU SELECT SELECT PRINTERFOR YES PRINTER INTERCEPT WINDOWS GD TO VIRTUAL DRIVER STREAM INTERCEPT 208 2O NO SELECT EAVESDROP INTERFACE VIRTUAL MODE OR INTERCEPT DRIVER TO ADDRESS MODE ATVIRTUAL PARSING AND DRIVER CAPTURE APPLICATION INPUT PERFORMADDRESS ADDRESSESTO PARSING AND ADDRESS HYGENE ON DATABASE ADDRESS DATA TRANSMIT PRINT STREAM TO PRINTER DRIVER RETAN ADDRESS IN DATABASE FOR FUTURE USE UTILIZE PRINTER DRIVER TO PRINT AT PRINTERSITE 216 28 CONCLUDE PRINT STREAM UTILIZATION FOR 222 THIS PRINTER U.S. Patent Jan. 8, 2002 Sheet 7 of 9 US 6,337,743 B1 23O 232 F. G ... 5 INITIATE SELECT VIRTUAL EAVESDROP DRIVER MODE 238 236 VIRTUAL DRIVER PRINT STREAM RECEIVES DATAPASSED PRODUCES PRINT THROUGHTO DUPLICATE OF PRNT STREAM SELECTED OUTPUT STREAM DATA DATA DEVICE INTERCEPTED 234 CONCLUDE DUPLICATED PRINT PRINT STREAM STREAM DATAPASSED UTILIZATION FOR THROUGH TO OLE THIS PRINT STREAM AUTOMATION SERVER DUPLICATE DATA ANOTHER PARSED FOR PRINT D STREAM? ADDRESS DATA 248 SADDRESS DATA PRESENT ADDRESS DATA NON-ADDRESS PLACED IN 250 DATADEETED ADDRESS DATABASE FOR FUTURE USE 252 CONCLUDE DATA UTILIZATION 254 U.S. Patent Jan. 8, 2002 Sheet 8 of 9 US 6,337,743 B1 NITIATE F.G. 6 VIRTUAL 260 DRIVER RECEIVES SELECT 264 PRINT STREAM INTERCEPT N. DATA MODE 262 PRINT STREAM DATA PASSEPTHROUGHTO as OLE AUTOMATION SERVER PRINT STREAM DATA PARSED FOR 268 ADDRESS DATA NO SADDRESS YES DATA PRESENT2 276 272 270 PRINT STREAM DATA ADESSRTA PASSED THROUGH 55ESS TO SELECTED TABASE FOR OUTPUT DEVICE DATABA FUTURE USE CONCLUDE PRINT STREAM NO ANOTHER UTILIZATION FOR PRINT THIS PRINT STREAM? STREAM 278 Ge) YES U.S. Patent Jan. 8, 2002 Sheet 9 of 9 US 6,337,743 B1 FIG. 7 3OO NITIATE PRINT STREAM FROM REMOTE APPLICATION 306 304 3O2 TRANSMIT PRINT SELECT STREAM THRU OUTPUT DEVICE YES WINDOWS GD TO FOR STREAM VIRTUAL DRIVER INTERCEPT NO SELECT EAVESDROP MODE OR INTERCEPT MODE ATVIRTUAL DRIVER INTERFACE VIRTUAL DRIVERTO EXTRACTION OR NPUT APPLICATION PERFORM EXTRACTION OR INPUT TO SELECTED DATA INPUT DATA FILE TO DATABASE TRANSMIT PRINT STREAM UTILIZE PRINTER OR OUTPUT DRIVER TO DOWNLOAD STREAM TO OUTPUT DEVICE RETANDATA FLE NDATABASE FOR FUTURE USE TO PRINTER OR OUTPUT DRIVER 36 318 CONCLUDE PRINT STREAM UTILIZATION FOR 322 THIS OUTPUT DEVICE US 6,337,743 B1 1 METHOD AND SYSTEM OF PRINT STREAM ADDRESS EXTRACTION RELATED APPLICATIONS Reference is made to application Ser. No. 09/119,463 entitled A METHOD AND SYSTEM OF DISPLAYING DATABASE CONTENTS IN ENVELOPE DATA FIELDS, assigned to the assignee of this application and filed on even date herewith. Reference is made to U.S. Pat. No. 6,282,524 issued on Aug. 28, 2001, entitled A METHOD AND SYSTEM OF PRINTING POSTAGE INDICIA FROMAN ENVELOPE DESIGN APPLICATION, assigned to the assignee of this application and filed on even date herewith. Reference is made to application Ser. No. 09/119,462 entitled A METHOD AND SYSTEM FOR CAPTURING DESTINATION ADDRESSES FROM LABEL DATA, assigned to the assignee of this application and filed on even date herewith. BACKGROUND OF THE INVENTION Addressing Systems are an example of Systems whose purpose is to utilize address lists, perform addressing hygiene through the use of address correction techniques, assign barcoding and, download data to addressing printers, collators, Sealers, and the like, for the purpose of producing a mailpiece. The print Stream introduced to addressing Systems is generally in the form an address list, though it may take on other forms. The list must be parsed and checked before format correction and barcoding techniques can be directed to the addresses on the list before creation of a mailpiece. An address database provides a link to prospective cus tomers by creating the ability for a list user to reach out to those customers represented by the databases individual addresses. The value of the database is measured in terms of the discounts available for the Sending of mailpieces, the Scope of the target audience, the detail, and accuracy of an individual address. The value is thus derived from the detail found in its contents. There is thus great value in assembling files for a database where the files are “complete” in detail. The ability to ensure detail of files withinan address database has been taught in such prior art as U.S. Pat. No. 5,668,990 for an APPARA TUS AND METHOD FOR GENERATING 100% UNITED STATES POSTAL SERVICE BAR CODED LISTS issued Sep. 16, 1997 to Bajorinas et al. (hereinafter referred to as Bajorinas) and assigned to the assignee of the present claimed invention. Bajorinas disclosed a method and apparatus for generat ing a coded address list. The method is initiated by inputting an address list to a data processing device which then reads each address record on the address list. AS an address record is read, a Set of rules is applied to the record to determine whether or not a corresponding bar code can be assigned. If a bar code can be assigned, then the data processing device writes the address record and its corresponding bar code to a first list. If, however, a corresponding bar code is not determined for an address record, then the unmatched address record is posted to a Second list. The first list is output for printing, while the Second list is Saved to memory. With respect to the Second list, the System operator can: manually correct an address record on the list, delete the address record; or, output the address record to a printer for non-discounted mailing. 1O 15 25 35 40 45 50 55 60 65 2 Refinement to file contents within an address database can be further made by employing methods disclosed in Such prior art as U.S. Pat. application Ser. No. 08/413,579 for a METHOD AND SYSTEM FOR MINIMIZING ATTRIBUTE NAMING ERRORS IN SET ORIENTED DUPLICATE DETECTION with a Notice of Allowance issued therefore on Feb. 6, 1998 for Robert J. Johnson et al. (hereinafter referred to as Johnson) and assigned to the assignee of the present claimed invention. Johnson disclosed a method and System for detecting duplicate records on a list or in a file. The method steps include entering a list, comprised of one or more records, to a data processing System; then, applying a nickname lookup table to the records to determine a common first name. Once a common name has been determined, the method matches a first record from the list with a second record from the list by comparing the fields of the first record with the fields of at least one other record; the comparison is based on a set of pre-determined criteria. The matching Sequence determines a duplicate Set, wherein the duplicate Set is comprised of at least two records with fields that match. The method then lists matching records Sequentially So that the System can create a new record by filling each empty field with a next available corresponding field from a Subsequent record within the duplicate set. The newly created record is then retained on the original list, and the duplicate records are placed on a Second list. Pre-Sorting of the list can occur just prior to the matching Sequence as well as just prior to outputting the final list. Additionally, the System operator can be given a number of options to provide flexibility. These options can include: manually correcting a record on the duplicate records list, deleting an address record from the list of duplicates; or, outputting the record. The value of the perfected files in the address database become readily apparent when the lists are printed to media when forming individual mailpieces to which postage is to be applied. The postal discounts available to the postal Service customer are calculated by mailpiece production Systems and are therefore only as good as the value of the data input to the System. Mailpiece production Systems are known in the art and have developed with changes in postal Service regulations (such as those of the United States Postal Service, or USPS) and with the proliferation of appropriate Software applica tions. In turn, this production has served the need to auto mate and accelerate to accommodate growth. As the USPS, together with the postal services of other countries around the World, moves toward more fully auto mated mail handling in an effort to contain costs while processing ever increasing Volumes of mail, automated equipment which Sorts and processes mail on the basis of machine readable postal codes, Such as the "Zip code' or other forms of postal coding, play an ever more significant role. In the United States, postal Service regulations provide for a “Postnet' bar code which represents the five, nine, or eleven digit Zip code of the destination address in a machine readable form. 4-State can be utilized within Canada. Systems have been used or proposed to meet the need to produce mail pieces imprinted with the Postnet bar code, and to enable mailers to obtain the benefit of the discounts offered for such mail. One such system is described in U.S. Pat. No. 4,858,907, for a SYSTEM FOR FEEDING ENVE LOPES FOR SIMULTANEO US PRINTING OF ADDRESSES AND BAR CODES, issued to Eisner et al. (hereinafter referred to as Eisner-1) on Aug. 22, 1989. This patent discloses a System for printing envelopes with US 6,337,743 B1 3 addresses, Zip codes, and corresponding bar codes. The System is controlled by a computer which includes Software for converting a Zip code included in the address into bar code form and then adding the bar code representation to the material to be printed on the envelope. Another example of the art is found in U.S. Pat. No. 5,326,181 for an ENVELOPE ADDRESSING SYSTEM ADAPTED TO SIMULTAN E OUSLY PRINT ADDRESSES AND BARCODES; issued on Jul. 5, 1994 to Eisner et al. (hereinafter referred to as Eisner-2). This patent teaches a method of addressing Substrates with a human readable address containing a Zip code and a bar code corresponding to the Zip code. The method utilizes a com puter and comprises Several Steps. These Steps include: receiving in the computer a plurality of addresses, with pre-existing Zip code information contained in each as complete address data, and requiring no manual inputting or identification; automatically Scanning the address data in the computer to find the pre-existing Zip code; automatically converting, in the computer, the pre-existing Zip code into a line of corresponding bar code; and, essentially Simulta neously printing the complete address, including Zip code information and corresponding bar code, on a Substrate, under control of the computer So that the Substrate produced has human readable Zip code and machine readable bar code information thereon. Additionally, a System for printing envelopes with addresses including bar code is disclosed in commonly assigned U.S. Pat. No. 5,175,691 for a SYSTEM AND METHOD FOR CONTROLLING AN APPARATUS TO PRODUCE ITEMS IN SELECTED CONFIGURATIONS: issued on Dec. 29, 1992 to Baker et al. (hereinafter referred to as Baker), which describes a System for printing mail pieces which includes a printer for printing sheets and envelope forms and a folder-Sealer mechanism for folding the envelope form around the Sheets to form a mail piece, and a computer based control System for controlling the printer and folder. In the System of this application, when an operator is creating a file of letters to be printed, the operator may designate a Selected field within each letter as contain ing the destination address. The System will then extract the information in this designated field and with it create a new page of material to be printed on the envelope form; and, if the address within the designated field includes a Zip code, the System will add a corresponding barcode to the new page. The System then adds this new page to the file before the file is output. U.S. Pat. No. 5,278,947 for a SYSTEM FOR AUTO MATIC PRINTING OF MAIL PIECES; issued Jan. 11, 1994 to Balga, Jr. et al. (hereinafter referred to as Balga), and assigned to the assignee of the present claimed invention, is for a System which includes a printer for printing text in response to the input of Signals. The printer has a capability to Selectively print either sheets or envelopes. The System further includes a controller for output of a Sequence of Signals representative of materials to be printed on a sheet which forms part of the mail piece, where the Sequence includes a Subset of Signals representative of an address. In accordance with another aspect of the Balga invention, the System includes a Scanning mechanism for identifying a character String which conforms to a valid postal coding Standard. The System further includes a mechanism for identifying the character String as a valid postal code. Additionally, the System forms the destination address to include a line including the postal code and a Selected number of proceeding lines of text. The ability to structure Software coding is extremely important when linking data to be downloaded to a printer 15 25 35 40 45 50 55 60 65 4 being utilized in the addressing environment. U.S. Pat. No. 5,583,970 for a PRINTER COMMAND SET FOR CON TROLLING ADDRESS AND POSTAL CODE PRINTING FUNCTIONS, issued Dec. 10, 1996 to Strobel (hereinafter referred to as Strobel), and assigned to the assignee of the present claimed invention, is instructive in this respect. Strobel is a method and System for printing images to a Substrate wherein the commands normally input by an operator, or resident within the printer, can be determined at a host data processor. The System can control address and postal code printing functions beginning at the host com puter together. The System will derive printing data, includ ing address data, from a Selected application resident in the host computer. The host computer creates and then transmits printer command Sets and printing data, via transmitting means to a microprocessor within the printer. The micro processor drives a language interpreter which directs the printer commands to a parsing Step for determining the address location from within the data to be printed. The language interpreter then assigns delivery point digits to a Zip code that was isolated from the transmitted address data. The newly created zip code is then matched with the bar code data Stored within the microprocessor's corresponding memory. A bar code corresponding to the new Zip code is Selected. The language interpreter then directs the printer's controller to prepare to print the address with its correspond ing Zip code, any graphics images that may have been included within the print data, and text, if any. The printer controller positions the bar code for printing, and then prints the bar code and address data, Zip code, and any graphics images and text to an envelope or other Substrate. Thus, Strobel overcame the limitations of the prior art by providing flexibility in determining what data, and how much, may be downloaded for printing to a Substrate. Flexibility is accomplished by controlling address and postal coding functions in the printer from a host computer. The invention thus Simplifies the firmware required in a Selected printer, or can allow the performance of additional tasks or provide for greater database functionality under the direction of the printer microprocessor. Thus, printer ROM memory can be reduced or freed up for other tasks, and RAM memory can be increased to handle more detailed data. A particular limitation to current methods and Systems, however, is found in the assembly of the address database which fuels the prior art detailed above. Mailpiece produc tion Systems and methods of perfecting database files must have raw material in the form of an address file. The current methods of identifying Such raw material are limited to direct input by a System operator or by parsing of data in list formats. Therefore, it is an object of the present invention to provide for a method and System for determining and extracting an address from a print Stream. SUMMARY OF THE INVENTION The limitations of the prior art are overcome by a method and System for determining an address from a print Stream in a data processing System. The method of determination begins by initiating the print Stream at a remote application. The remote location initiat ing the print Stream typically comprises a microprocessor for manipulating data and a print Stream application operatively connected to the microprocessor for creating the print Stream. The print Stream application can be a word proceSS ing application or similar type application that requires downloading to a printer. The remote location will also have transmission means for transmitting the print Stream to the virtual driver. US 6,337,743 B1 S The print Stream is transmitted, from the remote location, through a Graphical Device Interface to a virtual driver where a System operator can Select from at least two data interface modes. The Selected data interface mode interfaces with an address parsing application which parses the print Stream to identify address data resident in the print Stream. The identified address data is then saved in a database for future use. The print stream is allowed to be printed or be displayed at a Selected output device. The data interface modes further comprise an eavesdrop mode and an intercept mode. The eavesdrop mode allows the virtual driver to pass the print Stream through to the output device and wherein further the eavesdrop mode produces a duplicate copy of the print Stream for transmis Sion to a Server. The Server is linked to an address parsing module for parsing the print Stream. The intercept mode, on the other hand, allows the virtual driver to pass the print stream directly to the server, wherein the server is linked to the address parsing module for parsing the print Stream. The Server can be an OLE automation Server which in turn can pass the print Stream to an output device Such as a printer or monitor over transmission means. The address parsing application further performs the Steps of Selecting the address parsing module which comprises parsing instructions. Parsing of the print Stream to obtain address data is performed in accordance with those instruc tions. The address data is then placed into an address list or database. The Selection of the address parsing module further is based upon the address characteristics required by the SyS tem user. The user requirements are defined by creating an address data profile wherein the profile defines one or more tokens and wherein the tokens further define a characteristic of an address. The address data profile can be assigned to an addressing parsing module wherein the tokens comprising that address data profile are representative of a particular address format The address parsing module can then be Selected as based upon its particular address format. The particular address format can be representative of a particu lar carrier, Such as the United States Postal Service. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram of a typical prior art networked System within which a print Stream generated at a remote site is downloaded to a printer for output. FIG. 2A is a diagram of a typical networked System within which the method of the present invention could reside. FIG. 2B is a diagram of a typical Standalone System within which the method of the present invention could reside. FIG. 3A is a block diagram of a typical host addressing system within which the virtual driver of the present inven tion could reside. FIG. 3B is a block diagram of a typical addressing printer system within which the virtual driver of the present inven tion could reside. FIG. 4 is an upper level flowchart of the method of the present invention wherein an address is determined from a print Stream and retained in a memory for future use. FIG. 5 is a detailed flowchart of the method of the present invention as it pertains to an eavesdrop option Selected by a System operator. FIG. 6 is a detailed flowchart of the method of the present invention as it pertains to an intercept option Selected by a System operator. 15 25 35 40 45 50 55 60 65 6 FIG. 7 is a detailed flowchart of an alternative embodi ment of the present invention wherein an extraction or an input module is Selected for interface with the print System. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 depicts, in diagram form, a typical prior art networked printing environment. The networked printer 10 receives a print stream from each of remote systems 11, 12, 13, 14, 15, and/or 16. The printer 10 can be any one of a number of commercially available printers that are capable of being networked with two or more remote locations. A typical remote location, Such as remote System 11, that can generate a print Stream, has a central processing unit (CPU) 22a interoperatively connected to a monitor 24a CPU 22a processes data input from one or more data Sources or input devices which can be interoperatively connected or interfaced as appropriate. Monitor 24a allows a System operator to view transactions occurring within the CPU 22a. CPU 22a is further connected to: a keyboard 26.a for data input via interface cable 30a, a modem 28a for data trans mission via interface cable 32a, and, to the network printer 10 for data output via interface cable 34a. In FIG. 1, remote systems 12 through 16 are shown with elements common to remote System 11 but designated with the legends “b” though “f respectively, the remote systems 12 through 16, each has a central processing unit (CPU) 22(b frespectively) interoperatively connected to a monitor 24(bf respectively). CPU 22(bf respectively) is further connected to: a keyboard 26(b frespectively) via interface cable 30(b frespectively); a modem 28(b frespectively) via interface cable 32(b frespectively); the network printer 10 for data output via interface cable 34(b frespectively). Turning to FIG. 2A, there is shown the network environ ment in which the Subject claimed invention can be utilized. The host system 40 receives a print stream from each of remote systems 11, 12, 13, 14, 15, and/or 16. The host System 40, after intercepting the print Stream then passes the print stream to the printer 60. The printer 60 can be any one of a number of commercially available printers that are capable of being networked with two or more remote locations. A typical host System, Such as host System 40, which intercepts a print stream, has a central processing unit (CPU) 42 interoperatively connected to a monitor 44. CPU 42 processes the incoming print Stream being received from interface cables 34(af) by passing the print stream through a Graphical Device Interface (GDI) to a Virtual driver where a System operator can Select from at least two data interface modes. The Selected data interface mode interfaces with an address parsing application resident in CPU 42 which parses the print stream to identify address data resident in the print Stream. The identified address data is then saved in a database located within CPU 42 for future use. Input devices can be interoperatively connected or interfaced to CPU 42 as appropriate. Monitor 44 allows a System operator to view transactions occurring within the CPU 42. CPU 42 is further connected to: a keyboard 46 for data input via interface cable 50; a modem 48 for data transmission or reception via interface cable 52, the network printer 60 for print stream data output via interface cable 54. In FIG. 2A, remote systems 11 through 16 are shown with elements common to host system 40. The remote systems 11 through 16, each has a central processing unit (CPU) 22(a-f US 6,337,743 B1 7 respectively) interoperatively connected to a monitor 24(a-f respectively). CPU 22(a-frespectively) is further connected to: a keyboard 26(a-f respectively) via interface cable 30(af respectively); a modem 28(af respectively) via interface cable 32(a frespectively); and, to the host System 40 via interface cable 34(a frespectively). Turning to FIG. 2B, there is shown a stand-alone system environment in which the Subject claimed invention can be utilized. A typical Stand-alone System, Such as host System 70, which intercepts a print Stream, has a central processing unit (CPU) 72 interoperatively connected to a monitor 74. CPU 72 initiates the print stream in an appropriate application, then passes the print Stream through a Graphical Device Interface to a virtual driver where a System operator can Select from at least two data interface modes. The Selected data interface mode interfaces with an address parsing application or data extraction module resident in CPU 72 which parses the print stream to identify address data resident in the print Stream, or extracts data from the print Stream based upon pre-determined extraction criteria. The identified address data or extracted data file is then saved in a database located within CPU 72 for future use. Input devices can be interoperatively connected or inter faced to CPU 72 as appropriate. Monitor 74 allows a system operator to view transactions occurring within the CPU 72. CPU 72 is further connected to: a keyboard 76 for data input via interface cable 80; a modem 78 for data transmission or reception via interface cable 82; and, a printer 90 for print stream data output via interface cable 84. Turning to FIG. 3A, there are depicted in block form two Subsets that, combined, form an addressing System. The addressing System can act as a host System Such as that depicted in FIG. 2A, or can act as the initiating System for the print Stream while Supporting the virtual driver. Thus, the initiating application and the Virtual driver applications are remote to each other though co-located within the same Stand-alone data processing System. Addressing subsystem 110 includes: microprocessor 112 connected to monitor 114 by interface cable 122a, keyboard 116 connected to microprocessor 112 by interface cable 122b, memory 118 operatively connected to microprocessor 112 at 122c, memory 120 operatively connected to micro processor 112 at 122d modem 122 connected to micropro cessor 112 by interface cable 122e, and, interface cable 122f for connection to addressing Subsystem 125. Addressing subsystem 125 includes: printer 126 con nected to addressing subsystem 110 by interface cable 122f; operator panel 128 operatively connected to printer 126 at 122g, printer controller 132 operatively connected to printer 126 at 122h, and, marking engine 130 operatively connected to printer 126 at 122I. A microcomputer, or any computer that can download data that can be printed on a printer whether that printer is a peripheral device of the computer or not, uses application programs for creating data. These are resident in the micro computer ROM memory and in memory 118; memory 120 is utilized for the storing of address lists. The printers commonly utilized in the addressing art may also contain a microprocessor that is able to assign bar code data to addresses that are delivered from the host. These so-called “smart” printers vary in their ability to process data. FIG. 3B is a block diagram of a Smart printer which can Serve as an alternative host for the invention claimed herein. Turning to FIG.3B, system 140 is depicted as comprising: printer 142 which is operatively connected to microproces 15 25 35 40 45 50 55 60 65 8 Sor 144 at 154a, operator panel 146 operatively connected to printer 142 at 154b, memory 148 operatively connected to printer 142 at 154c, marking engine 150 operatively con nected to printer 142 at 154d. and, printer controller 152 operatively connected to printer 142 at 154e. The system environment of the claimed invention hosts the method as is shown in FIGS. 4-6. Turning to FIG. 4, there is shown a flowchart of the method of the present invention wherein an address is determined from a print Stream and retained in a memory for future use. FIG. 4 begins at step 200 with the initiation of the print stream from a remote location such as that depicted in FIGS. 2A and 2B. The remote location can be located as remotely from the virtual driver as is possible with conventional transmission means, or may be co-located So that the remote location is only remote as to the Separation of the Virtual driver and the print Stream generating application. From Step 200 the method advances to a query at step 202. The query at step 202 asks whether or not the host system 40 is to intercept a print Stream generated at the remote location 11 (or 12, 13, ... orn, as the case may be). If the response to the query is “NO,” then the method advances to step 218 where the print stream is transmitted to the printer driver. From step 218, the method utilizes, at step 220, the printer driver to print the print Stream at the Selected printer Site. It should be noted that the print Stream environment can have more than one printer 60 available for outputting the print Stream. In the case of multiple available printers, a particular printer is Selected for downloading of the print Stream. Upon printing the individual print Stream at Step 220, the print Stream utilization for the printer is concluded, at Step 222, until Such time as a Subsequent print Stream is directed to the printer. Returning to the query at Step 202, if the response to the query is “YES,” then the method advances to step 204 where a particular printer destination is Selected for print Stream interception. The method then advances to step 206 where the print stream is transmitted through a Windows' Graphi cal Device Interface (GDI) to a “virtual driver.” The virtual driver can operate in one of two interface modes; these are the eavesdrop mode and the intercept mode. The eavesdrop mode allows the virtual driver to pass the print Stream through to the printer while producing a dupli cate copy of the print Stream for transmission to a server. The Server is further linked to an address parsing module for parsing the print Stream. The intercept mode, on the other hand, allows the Virtual driver to pass the print Stream directly to the Server without making a duplicate copy; the Server is further linked to the address parsing module for parsing the print Stream. In a preferred embodiment, the server is an OLE automation server which in turn will pass the print Stream to an output device Such as a printer or monitor via an interface cable or Similar link. The method advances from step 206 to step 208 where either the eavesdrop or the intercept mode is Selected by the system user. The modes could be predetermined as well by the system user. The system then proceeds to step 210 where the Virtual driver is interfaced with an address parsing and capture application. The print Stream, which was transmitted to the virtual driver at step 206, is then parsed at step 212, So that address data, if any is present in the print Stream, in the form of an address file is extracted from the print Stream. The extracted address file can then be subjected to an optional address hygiene routine. The routine can be utilized to perform address correction, assignment of Zip codes, or checked against other address files for duplicate detection. US 6,337,743 B1 9 From step 212, the method advances to step 214 where the addresses are placed into an address database which can be further formatted in the form of an address list. The address is retained, at Step 216, in the address database for future use which might include a print run to mailpieces for Subsequent postal Service delivery. The method path for the eavesdrop and intercept modes is further detailed in FIGS. 5 and 6. Turning to FIG. 5, there is shown a detailed flowchart of the method as it pertains to an eavesdrop option Selected by a System operator. The flow begins at step 230 where the virtual driver is initiated before Selection of the eavesdrop option is made at step 232. From step 232, the method advances to step 234 where the virtual driver receives the print Stream data upon which it will act. The print stream data is duplicated by the virtual driver at step 236 before the original print stream is passed through to the Selected output device or printer at Step 238. The newly created duplicate print Stream passes directly to step 244; its path will be further discussed hereinbelow. From step 238, the method then advances to step 240 where the utilization of the original print stream is concluded before advancing to a query at Step 242. At Step 242, the System queries as to whether or not there is another print Stream to be enacted upon. If the response to the query is “YES, then the method returns along path A to re-enter the flow at step 230. However, if the response to the query at step 242 is “NO,” then the method advances to step 254 and concludes data utilization for the original print Stream. Returning to Step 244, the duplicate print Stream is passed by the virtual driver to an OLE automation server or similar Server capable of linking with an appropriate parsing appli cation. The automation Server application is responsible for the parsing of print Stream data, extraction of address information, and compilation of an address list. By inter facing with an interchangeable parsing module, the automa tion Server is able to extract addresses of varied format. Additionally, the automation Server can be configured to Save additional information about the print job (i.e., number of pages, username, etc.) with each address in the database. The address parsing application performs the Steps of Select ing the address parsing module which comprises particular parsing instructions. Parsing of the print Stream to obtain address data is performed in accordance with those instruc tions. The address data is then placed into an address list or database. The Selection of the address parsing module further is based upon the address characteristics required by the SyS tem user. The user requirements are defined by creating an address data profile wherein the profile defines one or more tokens and wherein the tokens further define a characteristic of an address. The address data profile can be assigned to an addressing parsing module wherein the tokens comprising that address data profile are representative of a particular address format The address parsing module can then be Selected as based upon its particular address format. The particular address format can be representative of a particu lar carrier, Such as that of the United States Postal Service, Federal Express, or similar carrier that has particular address file requirements. The method then advances from step 244 to step 246 where the duplicate print Stream is parsed for address data. The method will query at step 248 as to whether or not any address data is located during the parsing process. If the response to the query is “YES, then the method advances to Step 252 where the extracted address data is placed in an 15 25 35 40 45 50 55 60 65 10 address database for future use or possible address hygiene. The general uses would include the creation of address lists for mailing or Shipping. Once the address data has been saved in the form of a file within a database, the method advances to step 254 where the data utilization of the duplicate print Stream is concluded. Returning to Step 248, if the response to the query is “NO, however, then the method advances to step 250 where the non-address data is deleted before advancing to step 254. Turning to FIG. 6, there is shown a detailed flowchart of the method as it pertains to an intercept option Selected by a System operator. The flow begins at step 260 where the virtual driver is initiated before Selection of the intercept option is made at step 262. From step 262, the method advances to step 264 where the virtual driver receives the print Stream data upon which it will act. The method then advances to step 266 where the duplicate print Stream is passed by the virtual driver to an OLE automation Server or Similar Server capable of linking with an appropriate parsing application. The automation Server application is responsible for the parsing of print Stream data, extraction of address information, and compilation of an address list. By interfacing with an interchangeable parsing module, the automation Server is able to extract addresses of varied format. Additionally, the automation Server can be configured to Save additional information about the print job (i.e., number of pages, username, etc.) with each address in the database. The address parsing application performs the Steps of Selecting the address parsing module which comprises particular parsing instructions. Parsing of the print Stream to obtain address data is performed in accordance with those instruc tions. The address data is then placed into an address list or database. The Selection of the address parsing module further is based upon the address characteristics required by the SyS tem user. The user requirements are defined by creating an address data profile wherein the profile defines one or more tokens and wherein the tokens further define a characteristic of an address. The address data profile can be assigned to an addressing parsing module wherein the tokens comprising that address data profile are representative of a particular address format. The address parsing module can then be Selected as based upon its particular address format. The particular address format can be representative of a particu lar carrier, Such as that of the United States Postal Service, Federal Express, or similar carrier that has particular address file requirements. The method then advances from step 266 to step 268 where the duplicate print Stream is parsed for address data. The method will query at step 270 as to whether or not any address data is located during the parsing process. If the response to the query is “YES, then the method advances to Step 272 where the extracted address data is placed in an address database for future use or possible address hygiene. The general uses would include the creation of address lists for mailing or Shipping. Once the address data has been saved in the form of a file within a database, the method advances to step 274 where the System queries as to whether or not there is another print Stream to be enacted upon. If the response to the query is “YES,” then the method returns along path B to re-enter the flow at step 260. However, if the response to the query at step 274 is “NO,” then the method advances to step 278 and concludes data utilization for the print Stream. Returning to step 270, if the response to the query is “NO, however, then the method advances to step 276 where US 6,337,743 B1 11 the print Stream data is passed through to the Selected output device before advancing to step 278. Turning to FIG. 7, there is shown a detailed flowchart of an alternative embodiment of the present invention wherein an extraction or an input module is Selected for interface with the print stream. This differs from the embodiment of FIG. 4 where the virtual driver interfaced with an address parsing module; in this embodiment, the System can extract or input data from/to the print Stream for further use. The flow begins at step 300 with the initiation of the print Stream from a remote application. The remote application can be located as remotely from the virtual driver as is possible with conventional transmission means, or may be colocated So that the remote application is only remote as to the Separation of the virtual driver and the print Stream generating application. From Step 300, the method advances to a query at step 302. The query at step 302 asks whether or not the host system is to intercept a print Stream generated at the remote appli cation. If the response to the query is “NO,” then the method advances to step 318 where the print stream is transmitted to the output device driver. From step 318, the method utilizes, at step 320, the output driver to download the print stream at the selected output site. It should be noted that the print Stream environment can have more than one output device available for outputting the print Stream. In the case of multiple available printers, for instance, a particular printer is Selected for downloading of the print Stream. Upon outputting the individual print Stream at Step 320, the print Stream utilization for the output device is concluded, at Step 322, until Such time as a Subsequent print Stream is directed to the output device. Returning to the query at Step 302, if the response to the query is “YES,” then the method advances to step 304 where a particular output destination is Selected for print Stream interception. The method then advances to step 306 where the print Stream is transmitted through a Graphical Device Interface (GDI) to a “virtual driver.” The virtual driver can operate in one of two interface modes; these are the eaves drop mode and the intercept mode. The eavesdrop mode allows the virtual driver to pass the print Stream through to the printer while producing a dupli cate copy of the print Stream for transmission to a Server. The Server is further linked to either an extraction module or an input module. The intercept mode, on the other hand, allows the virtual driver to pass the print Stream directly to the Server without making a duplicate copy; the Server is further linked to either the extraction or input modules for interfac ing with the print Stream. In a preferred embodiment, the server is an OLE automation server which in turn will pass the print Stream to an output device Such as a printer or monitor via an interface cable or Similar link. The extraction module is similar to the parsing module in that it will interface with the print stream to extract data from the Stream. However, the extraction module can be used to Select specifically defined data fields, Such as: name; date; or subject fields. The module is defined by the instructions it contains with respect to the data it extracts from the print Stream. Instructions are further defined by tokens which, when taken together, instruct the Virtual river on the data Sought to be extracted. The input module differs the parsing module in that it will interface with the print Stream to input data to the Stream. Like the extraction module, the input module can be used to input Specifically defined data fields, Such as character codes or instructions for Subsequent use. The module is defined by 15 25 35 40 45 50 55 60 65 12 the instructions it contains with respect to the data it inputs to the print Stream. Instructions are further defined by tokens which, when taken together, instruct the virtual driver on the data Sought to be input at a particular location within the Stream. The method advances from step 306 to step 308 where either the eavesdrop or the intercept mode is Selected by the System user. The modes can be pre-determined as well by the system user. The system then proceeds to step 310 where the virtual driver is interfaced with the extraction or input modules. The print Stream, which was transmitted to the virtual driver at step 306, is then acted upon by the module at Step 312, So that specific data, in the form of an data file is either extracted or input. From step 312, the method advances to step 314 where the extracted data or an input record is placed into a database. The data file is retained, at step 316, in the database for future use. While certain embodiments have been described above in terms of the system within which the address object methods may reside, the invention is not limited to Such a context. The system shown in FIGS. 2A, 2B, 3A, and 3B are examples of a host System for the invention, and the System elements are intended merely to exemplify the type of peripherals and Software components that can be used with the invention. In the foregoing Specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader Spirit and Scope of the invention. The Specification and drawings are, accordingly, to be regarded in an illus trative rather than a restrictive Sense. What is claimed is: 1. A method of extracting an address data from a print Stream in a data processing System, comprising the Steps of: (a) initiating Said print Stream at a remote application; (b) transmitting said print Stream through a graphical device interface to a virtual driver; (c) selecting either an eavesdrop mode or an intercept mode from a plurality of data interface modes at Said Virtual driver wherein Said Selected data interface mode interfaces with an address parsing application; wherein Said eavesdrop mode allowing Said virtual driver to pass Said print Stream through to Said output device and producing a duplicate copy of Said print Stream transmitted to a server wherein Steps of parsing Said print Stream by Said address parsing application is carried out on the duplicate copy of Said print Stream; and Said intercept mode allowing Said Virtual driver to pass said print Stream directly to Said Server wherein Said the Steps of parsing Said print Stream is carried out at Said the Server, (d) parsing Said print Stream at Said address parsing application, wherein Said address parsing application further performs the steps of: i. Selecting an address parsing module wherein Said address parsing module comprises parsing instruc tions, ii. parsing Said print Stream to identify address data resident in Said print Stream in accordance with Said parsing instructions, and iii. compiling an address list comprising Said address data; (e) retaining said identified address data in a database for future use; and US 6,337,743 B1 13 (f) printing said print Stream at a selected output device. 2. The method of claim 1, wherein Said Step of initiating Said print Stream further comprises: creating a print Stream with print Stream application. 3. The method of claim 1, wherein said step of selecting Said address parsing module further comprises the Steps of: (a) creating an address data profile wherein the address data profile defines one or more tokens and wherein the tokens define a characteristic of an address, (b) assigning said address data profile to said addressing parsing module wherein Said tokens comprising Said address data profile are representative of a particular address format; and (c) Selecting said address parsing module based upon its particular address format. 4. The method of claim 3, wherein said particular address format is representative of a particular carrier. 5. The method of claim 1, wherein the step of parsing said print Stream further comprises the Step of using an OLE Automation Server as the Server for the Step of parsing. 6. The method of claim 1, further comprising the step of using a printer as the Selected output device. 7. A System of extracting an address data from a print Stream, comprising: (a) a data processing Station being capable of initiating Said print Stream; (b) transmitting means for transmitting said print stream through a graphical device interface to a virtual driver: (c) Selecting means for Selecting either an eavesdrop mode or an intercept mode from a plurality of data interface modes at Said virtual driver wherein Said Selected data interface mode interfaces with an address parsing application; wherein Said eavesdrop mode allows said virtual driver to pass Said print Stream through to Said output device and produces a duplicate copy of Said print Stream trans mitted to a Server wherein Said address parsing appli cation parsing Said print Stream is carried out on the duplicate copy of Said print Stream; and Said intercept mode allows Said virtual driver to pass Said print Stream directly to Said Server wherein Said address parsing application parsing Said print Stream is carried out at Said Server, (d) said address parsing application further comprising: i. means for Selecting an address parsing module wherein Said address parsing module comprises parsing instructions, ii. address parsing means for parsing Said print Stream to identify address data resident in Said print Stream in accordance with Said parsing instructions, and iii. means for compiling an address list comprising Said address data; (e) means for retaining said identified address data in a database for future use; and (f) means for printing said print Stream at a selected output device. 8. The system of claim 7, wherein said output device is a printer for printing Said print Stream to a Substrate. 5 15 25 35 40 45 50 55 14 9. The system of claim 7, wherein said server is an OLE Automation Server. 10. A method of extracting data from a print Stream in a data processing System, comprising the Steps of: (a) initiating Said print Stream at a remote application; (b) transmitting said print stream through a Graphical Device Interface to a virtual driver; (c) Selecting one of a plurality of data interface modes at Said virtual driver wherein Said Selected data interface mode interfaces with a data marker application; Said data marker application further performing the Steps of: (i) selecting either an extraction module or an input module based upon a System operator determination; (ii) performing a routine in accordance with a set of instructions contained in Said extraction module or Said input module; and (iii) Selecting either an eavesdrop mode or an intercept mode, wherein Said eavesdrop mode allows said virtual driver to pass said print Stream through to Said output device and produces a duplicate copy of Said print Stream transmitted to a Server and extracting Selected data by Said data marker application from duplicate print Stream at Said Server; and Said intercept mode allows the virtual driver to pass Said print Stream directly to Said Server and extracting Selected data by Said data marker application from Said print Stream at Said Server; and (d) printing said print stream at a selected output device. 11. The method of claim 10, further comprising the steps of defining Said extraction module with data capture instructions, and defining a profile of a data file with Said data capture instructions and with one or more tokens wherein Said tokens, wherein Said tokens define a charac teristic of Said data file. 12. The method of claim 11, comprising the further steps of: (a) assigning Said data profile to said extraction module wherein Said tokens comprising Said data profile are representative of a particular data requirement; and (b) selecting said extraction module based upon its par ticular data requirement. 13. The method of claim 10, further comprising the steps of defining Said input module with data entry instructions, and defining a profile of a data file with Said data input instructions and with one or more tokens, wherein Said tokens define a characteristic of Said data file. 14. The method of claim 13, comprising the further steps of: (a) assigning said data profile to said input module wherein Said tokens comprising Said data profile are representative of a particular data requirement; and (b) Selecting said input module based upon its particular data requirement. 15. The method of claim 10, wherein said step of printing Said print Stream further comprises using a printer for printing Said print Stream to a Substrate. k k k k k USOO6433881B1 (12) United States Patent (10) Patent No.: US 6,433,881 B1 Lynch et al. (45) Date of Patent: Aug. 13, 2002 (54) METHOD OF ESTABLISHING ASET OF 6,173,295 B1 1/2001 Goertz et al. ............... 707/505 PRINT STREAM OBJECTS IN AN OBJECT RE37,258 E * 7/2001 Patel et al. ................ 358/1.15 (75) (73) (*) (21) (22) (51) (52) (58) (56) ORIENTED ENVIRONMENT Inventors: John P. Lynch, Yorkville; Robert P. Williamson, Naperville, both of IL (US) Assignee: Pitney Bowes Inc., Stamford, CT (US) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by 0 days. Appl. No.: 09/223,304 Filed: Dec. 30, 1998 Int. Cl................................................. G06K 15/00 U.S. Cl. ...................... 358/1.13; 707/500; 707/900; 707/901 Field of Search ................. 358/1.1-1.9, 1.11-1.18; 707/500, 500.1, 501.1, 502-542, 900-911 References Cited U.S. PATENT DOCUMENTS 4970,554 A 11/1990 Rourke ....................... 355/202 5,270,775 A 12/1993 Suzuki ...... ... 355/204 5,353,388 A 10/1994 Motoyama .................. 395/117 5,383,129 A 1/1995 Farrell ....... ... 364/464.01 5,384,620 A 1/1995 Ebner et al. ................ 355/202 5,423,043 A 6/1995 Fitzpatricket al. ......... 395/700 5,450,571 A 9/1995 Rosekrains et al. .......... 395/500 5,467,434 A 11/1995 Hower et al. ..... ... 395/114 5,475.801 A 12/1995 Brindle et al. .... ... 395/114 5,483,653 A 1/1996 Furman ........ ... 395/650 5,495,561. A * 2/1996 Holt .......... ... 358/1.15 5,499,369 A 3/1996 Atkinson ... ... 395/650 5,506,661 A 4/1996 Kagaku ..... ... 355/209 5,528,734. A 6/1996 Sanchez .... ... 395/115 5,566.278 A * 10/1996 Patel et al. ................ 358/1.15 5,619,649 A 4/1997 Kovnat et al. ......... 395/200.01 5,644,682 A 7/1997 Weinberger et al. ........ 395/101 5,715,379 A 2/1998 Pavlovic et al. ..... ... 395/112 5,760,775 A 6/1998 Skut et al. .... ... 345/349 6,031,623 A 2/2000 Smith et al. ............... 358/1.14 OTHER PUBLICATIONS “Object-Oriented Modeling and Design”, Prentice Hall, Englewood Cliffs, New Jersey. “Copyright: The Java Tutorial”, for the Internet, 1995 Sun MicroSystem, Inc. * cited by examiner Primary Examiner-Gabriel Garcia Assistant Examiner King Y. Poon (74) Attorney, Agent, or Firm-Ronald Reichman; Paul A. Levitsky, Angelo Chaclas (57) ABSTRACT The invention is a method for creating a print job object, in an object oriented development environment of a print Stream processing System. The object creation function within the System is named which registers a class within the function and instantiates the class. The instantiation estab lishes a programming interface to the print job object which allows the establishment of the print job object properties. The object's programming interface creates a portal through which a set of object methods can be placed within the print job object. The methods include action instructions which further include: display instructions, Storage instructions, and, printing instructions. Additionally device Selection functionality, text formatting functionality which further includes text templates for the matching of the print Stream to a set of desired document finishing Schemes, and a set of print job data tables can be placed within the print job object by utilizing the programming interface. The Set of print job data tables further includes a plurality of text field data; rules for use of text field data; error messages, and Suggestions for alternate paths of movement within the print Stream pro cessing System. Creation of a human interface for allowing data to be displayed to a System operator under direction from the object methods, and placing of the human interface within the print job object, can also be accomplished by utilizing the programming interface. 7 Claims, 6 Drawing Sheets USERINITIALIZESCLENT REGISTERING SERVERSYSTEM 2O COMPRESIN AN OBJECT CREATIONFUNCTION As 202 ESTABLISH PROGRAMMING 204 INTERFACE ESTABLISTHE FROPERIES OF TH 208 CLASS 208 PLACE CBJEC METHODS WITHIN THE BRic HFUNCTIONALITY OBJECT TABLES WITHIN THE FUNCTIONALITY 2 a. i. A HUMAN s PLACEDATA MTRFACE WITHIN THE PRINT JOB OBJECT 20 PLACEDEVICE SELECTION WITHIN THE PRIMT JCB OBJECT PLACE EXT FORMAT WITHIN THE PRINT JOBOBJECT 22 UTILIZE THE PRINT JOB OBJECT WHEN NWOKED} US 6,433,881 B1 Sheet 2 of 6 Aug. 13, 2002 U.S. Patent 7 0/ E!OW-H HELNIHEST) Å HO_LNHANH 7 09 SHEAHES |N|Hc] US 6,433,881 B1 U.S. Patent N U.S. Patent Aug. 13, 2002 Sheet 4 of 6 US 6,433,881 B1 FIG. 3 USER INITIALIZESCLENT SERVER SYSTEM COMPRISING AN OBJECT CREATION FUNCTION REGISTERING THE CLASS ESTABLISH PROGRAMMING INTERFACE 2OO 2O4. ESTABLISH THE PROPERTIES OF THE CLASS 2O6 PLACE OBJECT PLACE DEVICE SELECTION METHODS WITHN THE PRINT JOB FUNCTIONALITY OBJECT WITHIN THE PRINT JOB OBJECT PLACE TEXT PLACE DATA FORMAT TABLES WITHIN THE FUNCTIONALITY PRINT JOB OBJECT WITHIN THE PRINT JOB OBJECT 214 22 PLACE A HUMAN UTILIZE THE INTERFACE WITHIN PRINT JOB THE PRINT JOB OBJECT WHEN OBJECT NVOKED 218 216 U.S. Patent Aug. 13, 2002 Sheet S of 6 US 6,433,881 B1 FIG. 4 NITIATE JOB OBJECT CREATION 25O LOCATE AJOB TEMPLATE (JT) IN SERVER DATABASE 252 COPY JT TO CREATEA NEW JOB OBJECT 254 OVERRIDE JOB PROPERTIES AND AUGMENT WITH JOB PROPERTIES FOUND IN THE START MESSAGE 256 SAVE NEWLY DEFINED JOB 258 OBJECT TO SERVER DATABASE UTILIZE DATABASE ENGINE TO STORE JOB OBJECTS AND CLIENT MESSAGES 260 JOB OBJECT SAVED 262 US 6,433,881 B1 Sheet 6 of 6 Aug. 13, 2002 U.S. Patent Z 19 808 NOI LOETESEOIA O #709 US 6,433,881 B1 1 METHOD OF ESTABLISHING ASET OF PRINT STREAM OBJECTS IN AN OBJECT ORIENTED ENVIRONMENT RELATED APPLICATIONS Reference is made to application Ser. No. 09/222,745, entitled A METHOD AND SYSTEM FOR PRINT STREAM JOB DETERMINATION AND ANALYSIS, assigned to the assignee of this application and filed on even date herewith. Reference is made to application Ser. No. 09/222,640, entitled A METHOD AND SYSTEM OF DETERMINING AJOBTICKET FOR A PRINT STREAM DETERMINING PROCESS, assigned to the assignee of this application and filed on even date herewith. Reference is made to application Ser. No. 09/223,348, entitled MESSAGE STRUCTURE FOR A PRINT STREAM DETERMINING AND ANALYSIS SYSTEM, assigned to the assignee of this application and filed on even date herewith. FIELD OF THE INVENTION The general field of the invention is that of data processing, and, more Specifically, print Stream processing. In its most Specific Segmentation, the field is that of opti mization of those devices directed to processing a print Stream for the purpose of producing a plurality of mail pieces. BACKGROUND OF THE INVENTION AS the capabilities of data processing Systems has grown, So too have the requirements that are tasked to these SyS tems. Greater Speed has given rise to more detail oriented applications, greater memory capability has made memory intensive applications more attractive, and detailed applica tions have lead to more wide-spread use of previously inaccessible data processing abilities. With the Spiraling growth in data processing ability, there has grown a need for more efficient ways of programming that promote speed as well as flexibility. Flexibility, in particular, allows applica tions that have been designed in varied programming languages, or operating on different platforms to be able to communicate without extensive System or file modification. Once Such means of promoting flexibility within a data processing System is in the use of “object-oriented” design (OOD). Object oriented programming languages are useful in removing Some of the restrictions that have hampered application design due to the inflexibility of traditional programming languages. OOD utilizes a basic element or construct known as the “object...” which combines both a data structure and an intended behavior characteristic within the Single element. Thus, Software applications become an organized collection of discrete objects in which data is held or moved based on the intended behavior of an object which is inherently unique. Each object knows how to perform Some activity. Objects can be specific or conceptual. But, to be of value to a particular application, objects must be able to be refer enced. Referencing is accomplished through indexing, addressing, or through value assignment which can be placed in a table for use as required. Objects can also be arranged by classification. Classification is based on group ings of objects based upon properties or characteristics important to an application or requirement. Each class describes a potentially infinite Set of objects that comprise that class. 15 25 35 40 45 50 55 60 65 2 OOD is known in the software arts and specific discussion of application design based upon OOD is not required for a thorough understanding of the applicant's claimed inven tion. In the past Several years, Significant changes have occurred in the operation of high Volume document produc tion centers. These centerS have merged traditional printing capabilities with mailroom production facilities. Executives tasked with the management of both print and mail opera tions are expected to play an ever-growing role in the creation and design of document centers that will deliver effective, high quality, and high integrity output. The current development and emphasis on these centers in corporations or regional centerS has lead to the growing use of the term “Automated Document Factory” (hereinafter “ADF) to describe consolidated printing and mail finishing operations. In current practice, large mailing companies tend to Separate the process of creating documents from the process of manufacturing documents (mailpieces). The print center tasked with finishing the created document receives both Scheduled and Scheduled print jobs with a wide range of requirements. These print jobs are evaluated, Scheduled, and executed in the printfinish center. Because the print/finish center has traditionally been “information Systems poor, most of the work required to prepare or “condition' the print job for manufacturing was created in the busineSS unit or print Service client. Typical conditioning processes include: performing postal address hygiene; adding PostNet' barcodes, presorting mailings, adding inserter barcode instructions, adjusting printer paper Size and orientation; and, adding Spot color instructions. The manager of Such a print/finish operation, Seeking to maximize efficiency through optimal use of equipment and decision making tools, is faced with a dilemma. First, the decisions about the Structure and management of the print/ finish center are generally made outside of the center, the decisions are generally made by the Information Systems (IS) group creating the print job and its associated print Stream. Document manufacturing requests are also assigned lower priorities, further limiting management control. Second, the hardware Systems and their associated periph eral devices are often Sourced from different manufacturers So that the printers and inserters being fed by the print Stream are relying on differing motivators from the print Stream. To help classify and organize the concept of the emerging print/finish center, an architecture has been developed within the print stream industry that is referred to as the ADF. The Automated Document FactoryTM architecture proposed by the Gartner Group of Stamford, Connecticut, provides a model for a set of processes that prepares and positions enterprises to manage the creation and delivery of high Volume digitized documents by using factory production techniques that appropriately and optimally mechanize document production. The raw materials of production (i.e., the document data and preparation instructions), enter the ADF which transforms them into digital documents and prepares them for delivery. The architecture for the ADF is comprised of four (4) modules, these include: input; transformation; delivery and preparation; and, control and reporting. Each module, or building block, is made up of other modules and each is connected by a Series of interfaces, or linkS. Each of the building blocks must be linked through effective communication which includes the tracking and measurement of the input and output of the document manufacturing hardware and associated peripherals. To US 6,433,881 B1 3 enhance productivity and cost-effectiveness of the overall System, Systems managers need to be able to Scrutinize every element of the print job process to see where improvements can be made. Thus, each of the modules takes on an increased significance when Viewed with respect to their relationship with the overall system. There is thus a need to provide each of the modules for the ADF So that the Structure can be self Supporting and viable. The input module is where all of the data and instructions needed to transform the arriving print Stream data into documents enters the ADF. The present invention is cur rently being introduced to the print Stream market by the assignee of the present invention, Pitney Bowes Inc. of Stamford, Conn., as the InStream TM server which is designed as the input module for the ADF. It is an object of the present invention to provide the input module to the conceptual ADF frame by describing herein an open Systems, client-Server technology for facilitating automated document manufacturing techniques. The use of object oriented design to facilitate object oriented linking of diverse applications, is a distinct benefit when employed within data processing Systems. Such as print stream client/server systems with diverse device driver applications. Therefore, it is an object of the present inven tion to provide for an object oriented method and System of interfacing between print Stream creation applications that are based on differing program languages or exist on dif fering operating System platforms and a document manu facturing System. It is a further object of the present invention to provide a method of optimizing the use of hardware and associated peripheral devices in manufacturing documents that have been digitally delivered through the input module. Additionally, it is further object of the present invention to measure the activities of each of the hardware and peripheral components So that accurate reporting can be made So as to facilitate Subsequent job performance decisions and So as to maximize System utility and performance. SUMMARY OF THE INVENTION According to the invention, the above objects are achieved and the disadvantages of the prior art are overcome by a method for creating a print job object, in an object oriented development environment of a print Stream pro cessing System. There are two alternatives for object cre ation as defined herein; the Selection of one over the other is dependent upon the object legacy. In a preferred embodiment of the object creation method, an object creation function within the print Stream proceSS ing System is initiated. The initiated function registers a class within the object creation function and names (instantiates) the class. The instantiation establishes a programming inter face to the print job object which allows the establishment of the print job object properties. The object's programming interface creates a portal through which a set of object methods can be placed within the print job object. The set of object methods comprises action instructions which further comprise: display instruc tions for instructing the print Stream processing System to display data on the display means, Storage instructions for instructing the print Stream processing System to Store data; and, printing instructions for instructing the print Stream processing System to print data on the output means. Additionally, device Selection functionality, text format ting functionality, and a set of print job data tables can be placed within the print job object by utilizing the program 15 25 35 40 45 50 55 60 65 4 ming interface. The device Selection functionality further comprises: a table of required output devices, a table of available output devices, and, matching rules for matching the table of required output devices to the table of available output devices. The device Selection functionality comprises lookup means for looking up an interface between the print Stream and a driver for the output device; the lookup based upon a comparison of a requested device identifier and an available device identifier. Text formatting functionality further comprises text templates for the matching of the print Stream to a set of desired document finishing Schemes, and one or more Sets of instructions for creating text Sub-fields, wherein each of the Sub-fields corresponds to a Selected text format. The set of print job data tables further comprises: a plurality of text field data; rules for use of text field data; error messages, and Suggestions for alternate paths of move ment within the print Stream processing System. Creation of a human interface for allowing data to be displayed to a System operator under direction from the object methods, and placing of the human interface within the print job object, can also be accomplished by utilizing the program ming interface. An alternative method of creating the print job object begins with the location of a job template in the print Stream client Server. The job template is copied to create a new job object instance. The copied job template has a Set of job properties embedded in the new job object instance; these are augmented with a Second Set of job object properties to establish a new job object. The new job object is then saved to a database of the print Stream client Server by utilizing a database engine of the print Stream client Server to Store the new job object. Utilization of the print job object begins with the creation of a document within the print Stream processing application and then determining that the processing of the print Stream is required at a remote location for document finishing. The print Stream is transmitted, under control of the Server, to the remote location; and, then the print job object is invoked at the Server, whereby the print job object performs finishing device Selection and text formatting at the remote location. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1A is an upper level block diagram of a host System which is capable of Supporting the method of the present invention. FIG. 1B is a block diagram of the system of the present invention and is shown as three (3) Subsystems. FIG. 2 is a block diagram of a data processing System which is representative of a System which could act as host to the invention's method. FIG. 3 is a detailed flowchart of the method of creating a print job object, from initial establishment, for use within a client Server System of a print Stream management System. FIG. 4 is a detailed flowchart of the method of creating a print job object, from an existing job template, for use within a client Server System of a print Stream management System. FIG. 5 is a block diagram of a print job object. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1A is an upper level block diagram of a host System which is capable of providing input to, and Supporting, the method of the present invention while further providing output paths. US 6,433,881 B1 S The system is divided into two subsystems; these are designated as document creation 10 and document manu facturer 30 which will also be referred to as the Automated Document Factory or ADF. Document creation 10 includes a database warehouse market 12 which provides one or more data Streams to be incorporated within the document assembly at document assembly station 18. The data streams are sourced from one or more databases contained within the database warehouse market 12 at the request of a document assembly routine within document assembly 18. The data may pass directly to document assembly 18 or may first pass through data quality and enhancement routine 14. Data quality and enhancement routine 14 processes data So as to prepare it for the require ments of the document assembly routine. If the document assembly routine does not require quality or enhancement processing, then the data would pass directly from the database warehouse market 12 to document assembly 18. Document assembly 18 prepares a digital document and transmits the document to an ADF via a digital document transmission 20 known as a print stream. The ADF Sub system is shown in FIG. 1A as document manufacturer 30. Document manufacturer 30 receives the digital document transmission 20 at the ADF input 32 and assigns a job ticket to the Stream which is indicative of the print parameters associated with the print stream. ADF input 32 will re-direct the Stream in accordance with the job ticket to various peripheral devices for printing and/or various output paths for re-transmission or data Storage. The peripheral devices and output paths include: printers and their associated con trol Systems 38; inserters and their associated control Sys tems 40; and, E-mail and transmission control Systems 42. It should be noted that the current invention is not limited to the embodiment shown, but may include any print Stream finishing device Such as console print Stream finishers, Storage devices for re-transmission, or interim data quality and enhancement routines for processing the print Stream. ASADF input 32 processes and directs the print Stream, it will constantly monitor the forces acting on the print Stream through control and reporting routines 34, these routines will in turn interface with scheduling module 36 to promote efficiency in current or Subsequent print Stream processing. Turning to FIG. 1B there is shown a block diagram of the system of the present invention which is further broken down into three (3) Subsystems designated as print Service clients 50, InStream server system 60, and InStream clients 70. Print service clients 50 is comprised of: print servers 52 which are receiving one or more print Streams from InStream Server 62 and reporting back Statistical or proceSS data which can be used by InStream clients 70 to manage the document creation process, digital document delivery Sys tems 54 which enable high-volume mail producers to utilize existing legacy-generated print Streams, and the images they contain, to further acceSS internet billing and bill present ment applications, and, finishing equipment 56 for actually producing the document defined by the print Stream. Print Service clients 50 communicate with InStream server system 60 via TCP/IP sockets. TCP/IP sockets are known to those skilled in the art and do not require further detail or explanation to fully appreciate and understand the present invention. InStream server system 60 comprises InStream server 62 and InStream database 64. In one embodiment of the present invention, InStream Server 62 is a multi-threaded, concur 15 25 35 40 45 50 55 60 65 6 rent server running on the Win32TM platform (available from Microsoft Corporation of Redmond, Wash.). InStream Server 62 is implemented in the Java" programming lan guage (available from Sun MicroSystems, Inc. of Palo Alto, Calif.) and is therefore not necessarily restricted to the Win32 platform. Database access is provided via the Microsoft SOLTM server. InStream clients 70 further comprises: reports 72 for producing print Stream and finishing reports that can be used to monitor the System, determine optimal peripheral and system efficiencies or detail production; inventory 74 for monitoring System-wide capacity; accounting 76 for moni toring time and expense for Sub-routines or document pro duction activities, and, user interface 78 for monitoring of client activities. Now turning to FIG. 2 there is shown a block diagram of a data processing System which is representative of a System which could act as host to the invention's method. The ADF Server is represented by data processing System 110 which is based on data processor 122. Data processor 122 is a central processing unit (CPU) of a computer (Such as a personal computer (PC), a mid-frame (IBM AS/400), or main frame) and its associated RAM or other memory, operating System Software, and application Systems which are capable of performing basic print Stream processing functions (such as SmartMailer(R) which is available from Pitney Bowes Inc. of Stamford, Conn.) or more advanced print stream processing (such as StreamWeaver(R) which is available from Pitney Bowes Inc. of Stamford, Conn.). The base components of the data processor 122 are known in the art and do not require a detailed description herein for an understanding of their utility and application. Interoperatively connected to data processor 122 is the application program 124 which is the basis for the present application. Additionally, connected to data processor 122 are memory cells 132, 134, 136, and 138 which are utilized for Saving various data Streams being processed by the application program 124. The multiple memory means of the System may be located independently of each other, or may exist in co-located combinations. Varied memory means are contemplated wherein the memory may exist in the form of a PROM chip, PROM card, magnetic media, or other commercially available forms. The system layout, with respect to the memory, is at the convenience of the System designer. Further coupled to data processor 122, is printer 144 for document or print stream data output, monitor 142 which allows a System operator to View transactions occur ring within the application program 24, and various input/ output devices 146(a-n). Input and output devices 146(a-n), Such as a keyboard for data input, or a modem for data transmission or reception can be interoperatively connected or interfaced to data processor 122 as appropriate. Turning to FIG. 3, there is shown a flowchart of the method utilized to create the print job object 300. A detailed discussion of object oriented programming is not required for a full understanding of the method described hereunder. The creation of the print job object 300 begins at step 200 when a System user initializes a data processing System which has an object creation functionality resident therein. From step 200, the method advances to step 202 where the method instantiates a print job object by registering an object class with the object creation functionality. Registra tion of the class creates, at Step 204, a programming inter face that will be used as a port of entry into the object. The port of entry will allow the System to place class properties within the object. The system user will determine the US 6,433,881 B1 7 properties of the class at Step 206. The Specific properties of the print job object are discussed in the description of FIG. 5. From step 206, the method advances to step 208 where object methods are placed within the print job object by entering them through the programming interface. The method then advances to step 210 where finishing device Selection functionality is placed within the print job object by entering it through the programming interface. In Succession, text format functionality, data tables, and a human interface are placed within the print job object by entering them through the programming interface in Steps 212, 214, and 216 respectively. It should be noted that steps 208 through 216 can be performed in any order so long as each of the Step actions are performed prior to utilization of the object. When the properties of the address object 300 have been placed into the object, the method advances to step 218 where the print job object can be utilized for its intended purpose when invoked. The use of the print job object 300 reduces the Steps necessary to apply print Stream manipu lation functionality and is thus a significant improvement over the prior art. Turning to FIG. 4, there is shown a detailed flowchart of the method of creating a print job object, from an existing job template, for use within a client Server System of a print Stream management System. While FIG. 3 details the creation of print job object 300 when first establishing the database of the server, FIG. 4 details the creation of the print job object from a legacy established in the database. The method begins with initia tion of the legacy based job object creation routine at Step 250. From step 250, the method advances to step 252 where a job template (JT) is located in the server database. The job template is copied, at Step 254, to create a new job object instance of the template. From step 254, the method advances to step 256 where the server over-rides the job properties embedded in the new job object; these are augmented with a new set of job properties which are found in the START message of the initiation step 250. The augmentation of the print job object with a new set of properties creates a new print job object which is Saved, at step 258, to the server database. The method then advances to step 260, where the server utilizes the database engine to Store, at Step 262, the new print job object and any Saved messages in one of the System memories dedicated to the database object Storage routines. Turning to FIG. 5, there is shown a block diagram of the print job object 300 and its constituent Sub-elements. The print job object 300 contains a programming interface 302 which serves as the portal by which properties of the print job object 300 can be entered into it. The programming interface 302 is returned by the print Stream processing server when the print job object 300 is instantiated, thus allowing the print job object 300 to be invoked as needed. In applications Such as Visual Basic, an object oriented designer would use a command Such as “create object' to instantiate the object. The “createobject' command returns a programming interface Such as “interface. ” which will allow the designer to place the necessary properties into the object by entering their file name after the interface com mand. The print job object 300 has specific requirements; therefore, through the programming interface 302 will come: a human interface 316; device Selection functionality 304; text formatting functionality 314; a set of print job data 15 25 35 40 45 50 55 60 65 8 tables 306-306n; and, a set of methods comprising display method 308, storage method 310, and printing method 312. Each of these elements is described in more detail herein below. Human interface 316 allows print job object 300 to provide a visual interface to the System user; additionally, printing methods 312 as contained in print job object 300 cause human interface 316 to direct a printer, Such as document printer 38, to print data under the direction of the object. Thus, the purpose of human interface 316 is to provide the path for user interface functionality. Additional functionality for print job object 300 is pro vided by device selection functionality 304 and text format ting functionality 314. Each of these performs a unique role. Device selection functionality 304 includes interface capa bility for interfacing the print Stream Selection functionality with the device drivers called out in the print instruction sets. Device selection functionality 304 further includes lookup instructions for looking up a device driver interfaces within a Set of coding tables. Text formatting functionality 314, on the other hand, provides for document reconstruction and rules for the finishing of the document when under control of the individual device drivers. Additionally, text format ting functionality 314 allows print job object 300 to distin guish text format from color codes necessary to drive certain printers or monitorS receiving the print Stream. Print job data tables 306-306n provide much of the data utilized by the print job object 300. Print job tables 306-306n include a number of fields from which an optimal data field will be constructed by print job object 300; these further include: a choice of fonts; rules for use of print job data; error messages, and Suggestions for alternate paths of movement within data processing System 110. Paths of movement are further dictated by print job object 300 through the use of its distinct method elements. Display method 308 is used for instructing the data processing system to display data on monitor 142. Storage method 310 is used for maintaining instructions for the data processing system to store data in its associated memory 132,134, 136, and 138, or within a peripheral device. Printing method 312 is used for instructing the data processing System to print data on output means Such as document printer 144, or a Separate text printer 146. While certain embodiments have been described above in terms of the system within which the InStream server may reside, the invention is not limited to Such a context. The system shown in FIGS. 1A, 1B, and 2 are an example of a host System for the invention, and the System elements are intended merely to exemplify the type of peripherals and Software components that can be used with the invention. In the foregoing Specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader Spirit and Scope of the invention. The Specification and drawings are, accordingly, to be regarded in an illus trative rather than a restrictive Sense. What is claimed is: 1. A method of creating a print job object, in an object oriented development environment of a print Stream pro cessing System, comprising the Steps of: (a) establishing an object creation function within Said print Stream processing System; (b) registering a class within said data object creation function and instantiating Said class, and, wherein Said instantiation establishes a programming interface to Said print job object; US 6,433,881 B1 (c) establishing the properties of Said print job object by: (i) placing a set of object methods within Said print job object by utilizing Said programming interface; (ii) placing device Selection functionality within Said print job object by utilizing Said programming inter face; (iii) placing text formatting functionality within Said print job object by utilizing Said programming inter face; (iv) placing a set of print job data tables that comprise: (A) a plurality of text field data; (B) rules for use of text field data; (C) error messages; and (D) Suggestions for alternate paths of movement within Said print Stream processing System within Said print job object by utilizing Said programming interface; and (d) creating a human interface, for allowing data to be displayed to a System operator under direction from Said object methods, and placing Said human interface within Said print job object by utilizing Said program ming interface. 2. The method of claim 1, wherein said set of object methods comprises action instructions, Said action instruc tions further comprising display instructions for instructing Said print Stream processing System to display data on a display means. 3. The method of claim 1, wherein said set of object methods comprises action instructions, Said action instruc 15 25 10 tions further comprising Storage instructions for instructing Said print Stream processing System to Store data. 4. The method of claim 1 wherein said set of object methods comprises action instructions, Said action instruc tions further comprising printing instructions for instructing Said print Stream processing System to print data on an output means. 5. The method of claim 1, wherein said device selection functionality further comprises: (a) a table of required output devices; (b) a table of available output devices; and (c) matching rules for matching said table of required output devices to Said table of available output devices. 6. The method of claim 5, wherein said device selection functionality comprises lookup means for looking up an interface between said print Stream and a driver for Said output device, Said lookup based upon a comparison of a requested device identifier and an available device identifier. 7. The method of claim 1, wherein said text formatting functionality further comprises: (a) text templates for the matching of Said print stream to a set of desired document finishing Schemes, and (b) one or more sets of instructions for creating text Sub-fields, wherein each of Said Sub-fields corresponds to a Selected text format.