||||||||||||||Ill||||||||||Illlllllllllllllllll|||||lllllllllllllllllllllll
`US005566278A
`
`United States Patent
`[191
`5,566,278
`[11] Patent Number:
`
`Oct. 15, 1996
`[45] Date of Patent:
`
`Patel et al.
`
`[54] OBJECT ORIENTED PRINTING SYSTEM
`
`[75]
`
`Inventors: Jayendra N. Patel, Sunnyvale; Ryoji
`Watanabe, Cupertino; .Mark Peek, Ben
`Lomond; L. Bayles Holt, San Jose;
`Mahinda K. de Silva, Mountain View,
`all of Calif.
`
`[73] Assignee: Taligent, Inc., Cupertino, Calif.
`
`[21] Appl. No.: 111,238
`
`[22] Filed:
`
`Aug. 24, 1993
`
`Int. Cl.6 ..................................................... G06K 15/00
`[51]
`[52] U.S. Cl.
`............................................. 395/114; 395/112
`[58] Field of Search ..................................... 395/112, 114,
`395/117, 101, 115, 133, 138, 821, 831,
`834, 839, 844, 853, 854, 859, 870, 874,
`892, 280, 284, 285, 286, 292, 309, 116,
`500; 370/858
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUNLENTS
`
`4/1989 Duisberg .......................... 364/578
`4,821,220
`
`4,885,717 12/1989 Beck et al.
`..... 364/900
`
`1/1990 Friedman et al.
`4,891,630
`..... 340/706
`
`..... 364/200
`4,953,080
`8/1990 Dysart et a1.
`
`5,025,398
`6/1991 Nelson ...........
`395/112
`
`6/1991 Wendt et al. ........... 395/ 117
`5,025,399
`
`8/1991 Cunningham et al.
`..... 364/518
`5,041,992
`
`9/1991 Golub et al. ............ 364/478
`5,050,090
`
`. 400/121
`5,052,834 10/1991 Feistel et a1.
`
`..... 382/8
`5,060,276 10/1991 Morris et al.
`
`................................ 395/425
`5,075,848
`12/1992 Lai et a1.
`5,093,914
`3/1992 Coplien et al.
`......................... 395/700
`5,119,475
`6/1992 Smith et a1.
`..... 395/156
`
`..... 395/114
`5,123,757
`6/1992 Nagaoka et a1.
`
`..... 395/650
`5,125,091
`6/1992 Staas, Jr. et a1.
`
`7/1992 Risch .................. 395/800
`5,133,075
`........................... 395/575
`5,136,705
`8/1992 Stubbs et al.
`
`5,151,987
`5,181,162
`5,226,112
`5,287,194
`5,303,336
`5,323,393
`5,337,258
`5,353,388
`5,495,561
`
`9/1992 Abraham et al.
`....................... 395/575
`1/1993 Smith etal.
`......
`364/419
`
`7/1993 Mensing etal.
`395/114
`2/1994 Lobiondo ..........
`395/114
`
`4/1994 Kageyarna etal.
`395/114
`
`6/1994 Barrett etal. .....
`.. 370/858
`8/1994 Dennis ......
`395/575
`
`
`10/1994 Motoyama
`395/117
`........................................ 395/112
`2/1996 Holt
`
`OTHER PUBLICATIONS
`
`IBM Technical Disclosure Bulletin, V.34(10A), New York,
`US, pp. 912—193 “Use of Agraphical User Interface for
`Printers”.
`
`Primary Examiner—Arthur G. Evans
`Assistant Examiner—Dov Popovici
`_
`Anomey, Agent, or Finn—Keith Stephens; Bookstein &
`Kudirka
`
`[57]
`
`ABSTRACT
`
`An object-oriented printing system includes objects that
`provide query, data transfer, and control methods. The
`inventive object-oriented printing system communicates
`with the remainder of the operating system by means of a
`standard interface such as a grafport and printer drivers are
`provided for each printer type within the operating system.
`Thus, an application not only need not worry about the
`particular printer/computer combination with which it is to
`operate, but also need not have a built in document format~
`ting capability. The printing system includes objects that
`provide queries for device identification, optimized imaging,
`and printer status. Other objects are also provided for data
`transfer to bracket connections prior to sending and receiv-
`ing information. Still other objects are provided for cancel-
`ing a print job, pausing a job, and clearing out a job. Finally,
`an object is also provided for supporting multiple streams of
`communication to an imaging task.
`
`20 Claims, 12 Drawing Sheets
`
`
`
`
`
`
`
`APPLICATION
`PROGRAM
`
`
`
`'414
`
`
`
`
`
`
`
`
`
`
`
`
`OPERATING
`SYSTEM
`
`PRINTING
`INTERFACE
`
`i I
`
`aPRINTER
`
`420
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 1
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 1
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 1 of 12
`
`5,566,278
`
`_________
`
`____________
`
`m:
`
`52coin.FGE
`
`3%
`
`“Suhw>m
`___________o:_N:“m2___________
`
`mwthn—KuhZF—n—
`
`02F<mma020_._.<0_4n_n_<
`
`.FKOQmm>ED
`
`521001.“.
`
`Nov
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 2
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 2
`
`
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 2 of 12
`
`5,566,278
`
`CNN
`
`E"?moan:m.b~n~
`
`mthEn.
`
`5.10.“.
`
`KMHZEQ
`
`amazerEofi<m0
`
`mwN
`
`02_._.<mmn_0
`
`Ewhm>m
`
`ON
`
`saw—001n—
`
` N
`
`zO_._.<U_._n_n_<
`
`ON
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 3
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 3
`
`
`
`
`
`
`

`

`U
`
`w
`
`8
`
`
`mmE<o<_S_"><.Em_o 2Wiileiilliilili--i--l-ll---ii-ixilliiliiiiiliiiiliJ1__muu3__w.in“Em"h_mto,mmE<o<
`
`
`
`
` mofimmhz.“______%mE_w"mmE<o<“5,N5_O:_1_t__mmama"woo“xma"o;__“2m“um“:mo"e__t_Dom|\_.\a_8m__STilliiimmm.............v.omiiiiiNmm..............._
`
`
`
`
`
`
`
`
`
`mmm
`
`7.2,m65%
`
`
`
`5omm5><.Em_oom<om>mx
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 4
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 4
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 4 of 12
`
`5,566,278
`
` Futh—m
`
`8v6............................................
`02F<mmm0\$56.28
`
`Suhw>w
`
`02F2En.
`
`mo<mmm.rz_
`
`hmOnE<m0
`
`
`
`mmvZO_._.<O_.._n_n_<
`
`E<mwomm
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 5
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 5
`
`
`
`
`
`
`

`

`US. Patent
`
`9
`
`h
`
`n
`
`s.
`
`6i
`
`$5.05
`
`,mmwNNmwomm
`
`5
`
`553
`
`
`
`thammm
`
`momcomo5vomNam
`
`com
`
`
`
`mm4oz<zmmthn.
`
`0%mEmE0Sm
`
`w.3?“,nw,m.ww.,H,.
`
`mm>mmwAmzz<IO
`
`thn.._.Z_m_n_
`
`NEI89.
`hszDUOQ
`
`5,566,278
`
`N8
`
`0mm
`
`m.65%
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 6
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 6
`
`
`
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 6 of 12
`
`5,566,278
`
`mWEDGE
`
`E200
`
`5.52%355mnmoozmEzEnE
`
`._<U_mm¢:n_
`
`ENPZEQ
`
`20:55.9
`.05.5:56
`
`
`
`m...<._.wU_E<z>o
`
`.mthEQHt.".0
`
`
`
`Mambom0....
`
`.Okm
`
`
`
`20:5“.365200
`
`/mam—=0mg.
`
`S'EJO'WICI
`
`
`
`/Emacs.mszEnE
`
`mthEn—no.5.mmo
`
`
`
`$5.5mmEzE;
`
`whimhzmhmammm
`
`EMHZEah
`
`ZO_._.<m=GEZOU
`
`
`
`moq.PZEQ...
`
`20Fn=m0wmo
`
`
`
`E12285“.$5.5.
`
`:sz38..
`
`@222225
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 7
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 7
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 7 of 12
`
`5,566,278
`
`Illll'IIAIzogmaomzoo5.5?v
`“||‘
`
`
`
`IIMommammpzfimw\\
`
`<mu»
`
`/I18..EEEi\\um2:<EINIIIIIH\moimzo
`
`\\I.II2::imo
`
`szsaooomzb
`
`
`
`\\0.5223232.5\/mosmoSEE
`
`2:52.”:
`
`
`
`“Ea—hmmDmDOm0..
`
`zoEBtFozMom.@255
`955m9.<thao»
`
`thDCmm
`
`
`
`5.325.EEEE
`
`Emzotfima.
`
`Em>mmm
`
`mmoa
`
`£2:<Emzov
`
`
`H¥w<262552.
`
`NEEautomamnfiamvoh<5335.
`
`Emmaofiazg35355::E:
`
`
`
`EizommmaESE“.,z.omhomzmmwmmn\|IlI
`
`.L.ZmE:QOQ=>m02m2
`
`
`
`EMFquoz<1mthEm
`
`kWEDGE
`
`how—domE<wm:._.IIlIll\
`
`J\
`
`etitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 8
`
`p P
`
`4m22<20
`
`amzmtfiua\,._mzz<:oIIIlelele
`IIII.IllImosmo$5.5:homsmo
`
`
`
`‘nlIII
`
`ll,
`
`\
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 8
`
`

`

`9
`
`1f0
`
`5,566,278
`
`mx,,m02<zoxmoafiU\--
`Hx-W.://i.\\/li\\\i\\ii..iil/
`
`i/AmmSz/‘ImmpzimwVIi[/\..\
`6:\\Il]/\\’//\\.l\
`2l\\
`8(Ix/Wiii//
`
`t/|./.w/hflBEE/EB.Si\\
`
`/I//\iiii
`
`\ZO_Fn__mOmMDmOZ.Z_N_n_F\\..\\
`\L\//i\\I/_/
`\\Il/\\il/.i\\(l/i
`‘H/m0_>mo._.z_mn:.li‘
`
`
`Qw<526<2EszEm-t---\---
`
`@O_F<EDO_H_ZOOEMPZ_ZQH_
`
`\
`
`u.6an
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 9
`
`US. Patent
`
`{\‘01
`LlJ
`
`I E<[
`
`L
`<2
`
`0L
`
`L!
`'—
`
`OEL
`
`U
`L:
`b2]
`
`
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 9
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 9 of 12
`
`5,566,278
`
`
`mm._n_2<_._mmthm.ENDS”.I
`
`
`
`xwdc.02532:‘mam—DOm9.
`
`
`§<m00ma¥w<kmm2mommh
`
`._.Z_mn_
`
`¥Z_n_
`
`FZm—EDOOD
`
`4m22<IOm0_>mD._.
`
`wkwkzEm
`
`
`
`withO=2<Z>Q
`
`aGER
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 10
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 10
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 10 of 12
`
`5,566,278
`
`PINK '
`
`PRINT
`REQUEST
`
`DOCUMENT
`
`PRINTER HANDLER
`JOB QUEUE ‘
`
`
`
`
`TRECEIVERTASKPROGRAM
`
`TIMAGING TASK
`
`TDEVICECHANNEL
`
`
`
`PRINTER'S
`DYNAMIC STATE
`
`MESSAGE
`STREAM
`
`PRINTER HANDLER
`
`PRINT
`REQUEST
`
`TDEVICECHANNEL
`
`TRECEIVERTASKPROGRAM
`
`JOB QUEUE “ TIMAGINGTASK
`
`PRINTER'S
`DYNAMIC STATE
`
`'
`
`FIG. 10
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 11
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 11
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 11 of 12
`
`5,566,278
`
`
`
`
`PRINT
`
`
`PRINTER HANDLER
`
`
`
`REQUEST
`
`
`
`
`
`DYNAMIC STATE
`
`
`
`
`
`DOCUMENT
`
`TRECEIVERTASKPROGRAM
`
`JOB QUEUE
`
`TIMAGING TASK
`
`PRINTER'S
`
`TDEVICECHANNEL
`
`MESSAGE
`STREAM
`
`
`PRINT
`REQUEST
`PRINTER HANDLER
`
`
`TRECEIVERTASKPROGRAM
`
`JOB QUEUE.1
`
`TIMAGING TASK
`
`
`
`
`
`
`
`
`
`
`PRINTER'S
`DYNAMIC STATE
`
`TDEVICECHANNEL
`
`FIG. 11
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 12
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 12
`
`

`

`US. Patent
`
`Oct. 15, 1996
`
`Sheet 12 of 12
`
`5,566,278
`
`PRINT
`
`REQUEST
`
`DOCUMENT
`
`
`TDEVICECHANNEL
`DYNAMIC STATE
`
`
`
`
`
`
`
`
` PRINTER HANDLER
`
`
`
`TRECEIVERTASKPROGRAM
`
`JOB QUEUE
`
`TIMAGING TASK
`
`PRINTER'S
`
`FIG. 12
`
`NETWORK PRINTER,
`SUCH AS:
`- NOVELL IPX
`-PAP
`-TCPHP
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 13
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 13
`
`

`

`1
`OBJECT ORIENTED PRINTING SYSTEM
`
`COPYRIGHT NOTIFICATION
`
`Portions of this patent application contain materials that
`are subject to copyright protection. The copyright owner has
`no objection to the facsimile reproduction by anyone of the
`patent document or the patent disclosure, as it appears in the
`Patent and Trademark Office.
`
`FIELD OF THE INVENTION
`
`This invention generally relates to improvements in com-
`puter systems and, more particularly, to operating system
`software for printing documents.
`
`BACKGROUND OF THE INVENTION
`
`One of the most important aspects of a modern computer
`system is the ability to generate a “hard” copy of textual
`information or graphics which can be manipulated by the
`computer, visually displayed and stored. In order to accom-
`plish this task, a computer system generally includes a
`printing device which is electrically connected to the com-
`puter system and controlled by it in order to generate a
`permanent image on a selected medium. Examples of print—
`ing devices in common use are dot matrix, ink jet and laser
`printers which fix permanent images on paper under control
`of the computer. Although paper is the most common
`medium, other media are often used, such as photographic
`film.
`
`In order to print a document which is displayed on the
`monitor or stored within the memory, several actions must
`take place. First, since the print medium generally has a
`fixed size, the printable information must be divided into
`pieces which are small enough to fit on the selected medium,
`a process which is called pagination. In addition, the infor-
`mation may need to be reformatted from the format in which
`it is either displayed or stored into a format which is suitable
`for controlling the printing device to actually perform the
`printing on the medium. The reformatting in this latter step
`may include the insertion of control commands into the
`printable information in order to control the printing device.
`These added commands may, for example, include such
`commands as carriage returns, line feeds, form feeds, spaces
`and font information, all of which format the printable
`information. The reformatting may also include a conver-
`sion step in which a graphical display is converted into the
`form used by the printing device.
`The pagination and reformatting necessary to convert the
`printable information into a form which can be printed on a
`given printing device is generally performed by software
`programs running within the computer system. Software
`programs operating on a computing system generally can be
`categorized into two broad classes: operating systems which
`are usually specific to a type of computer system and consist
`of a collection of utility programs that enable the computer
`system to perform basic operations, such as storing and
`retrieving information on a peripheral disk memory, display-
`ing information on an associated video display, perfomring
`rudimentary file operations including the creation, naming
`and renaming of files and, in some cases, performing diag-
`nostic operations in order to discover or recover from
`malfunctions.
`
`By itself, the operating system generally provides only
`very basic functions and must be accompanied by an “appli-
`cation” program. The application program interacts with the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`5,566,278
`
`2
`
`operating system to provide much higher level functionality
`and a direct interface with the user. During the interaction
`between the application program and the operating system,
`the application program typically makes use of operating
`system functions by sending a series of task commands to
`the operating system which then performs the requested
`tasks. For example, the application program may request
`that the operating system store particular information on the
`computer disk memory or display information on the video
`display.
`FIG. 1 is a schematic illustration of a typical computer
`system utilizing both an application program and an oper—
`ating system. The computer system is schematically repre-
`sented by dotted box 100, the application program is rep-
`resented by box 102 and the operating system by box 106.
`The interaction between the application program 102 and the
`operating system 106 is illustrated schematically by arrow
`104. This dual program system is used on many types of
`computers systems ranging from mainframes to personal
`computers.
`The method for handling printing, however, varies from
`computer to computer, and, in this regard, FIG. 1 represents
`a prior art personal computer system. In order to provide
`printing functions, the application program 102 interacts (as
`shown schematically by arrow 108) with printer driver
`software 110. Printer driver software 110 is generally asso—
`ciated with an application program and reformats and con-
`verts the printable information as necessary. Since each
`printer has its own particular format and control command
`set, which must be embedded in the text properly to control
`the printer, the printer driver software 110 must be specifi-
`cally designed to operate with one printer or one type of
`printer.
`The printer driver software 110 produces a reformatted
`information stream containing the embedded commands as
`shown schematically as arrow 114. The converted informa-
`tion stream is, in turn, applied to a printer port 112 which
`contains circuitry that converts the incoming information
`stream into electrical signals. The signals are, in turn, sent
`over a cable 116 to the printer 118. Printer 118 usually
`contains an “imaging engine” which is a hardware device or
`a ROM-programmed computer which takes the incoming
`information stream and converts it into the electrical signals
`necessary to drive the actual printing elements. The result is
`a “hard copy” output on the selected medium.
`While the configuration shown in FIG. 1 generally works
`in a satisfactory manner, it has several drawbacks. Since the
`printer driver software 110 is specific to each type of printer,
`a separate driver had to be provided for each printer type
`with which the application program is to operate. In the
`personal computer market,
`there are a large number of
`different printer types that are compatible with each type of
`computer and, therefore, as the number of printer types
`proliferated, so did the number of printer drivers which were
`required for each application program so that the program
`was compatible with most available printers. Therefore,
`application program developers had to provide larger and
`larger numbers of printer drivers with each application
`program, resulting in wasted time and effort and wasted disk
`space to hold the drivers, only one or two of which were of
`interest
`to any particular user. Unfortunately,
`if a user
`purchased an application program and it did not include a
`printer driver which could control the printer which the user
`owned, unpredictable operation occurred, resulting in pro-
`gram returns and user dissatisfaction.
`In addition, it was also necessary for each application
`program to provide high level printing functions such as
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 14
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 14
`
`

`

`3
`
`5,566,278
`
`pagination and page composition (including addition of
`margins, footnotes, figure numbers, etc.) if such functions
`were desired. Consequently, each application program
`developer had to spend time developing programs to imple-
`ment common printing functions which programs were
`specific to each application program, thereby resulting in
`duplicated effort and wasted time.
`In order to overcome the aforementioned difiiculties, the
`prior art arrangement was modified as shown in FIG. 2. In
`this new arrangement, computer system 200 is still con-
`trolled by application program 202 which cooperates, as
`shown schematically by arrow 204, with operating system
`206. However, in the system shown in FIG. 2 operating
`system 206 includes printer drivers 214. A separate printer
`driver must still be provided for each diiferent type of
`printer, but the printer drivers are sold with, and part of, the
`operating system. Consequently, it is not necessary for each
`application program to have its own set of printer drivers. An
`application program, such as application program 202, com-
`municates with the printer driver 214 by means of a stan—
`dardized interface 210. Two common interfaces are called
`“grafports” or “device contexts”. Illustratively, application
`program 202 provides information (shown schematically
`shown by arrow 208) in a standardized form to the grafport
`210. The grafport 210, in turn, forwards information, as
`shown by arrow 212, to printer driver 214 which reforrnats
`and converts the information as previously described into
`the format required by the printer. The output of printer
`driver 214 is provided (illustratively shown as arrow 216) to
`printer port 218 where it is converted to electrical signals
`that are transmitted, via cable 220, to the printer 222.
`The configuration shown in FIG. 2 has the advantage that
`the application program developer need not worry about the
`specific computer and printer combination on which the
`program will ultimately run in order to provide printing
`capabilities to the application program. However, it still
`sufi°ers from the drawback that, if desired, high level printing
`capabilities such as pagination and page composition must
`still be designed into each application program,
`thereby
`duplicating program code and wasting programming
`resources.
`
`SUMMARY OF THE INVENTION
`
`The foregoing problems are overcome and the foregoing
`object is achieved in an illustrative embodiment of the
`invention in which an object—oriented printing interface
`includes document grouping or folio objects which, once
`instantiated provide complete and flexible printing capabil-
`ity that
`is transparent
`to the application program. The
`printing interface objects include objects that provide query,
`data transfer, and control methods.
`
`The inventive object-oriented printing interface commu-
`nicates with the remainder of the operating system by means
`of a standard interface such as a grafport and printer drivers
`are provided for each printer type within the operating
`system. Thus, an application not only need not worry about
`the particular printer/computer combination with which it is
`to operate, but also need not have a built in document
`formatting capability. The printing system includes objects
`that provide queries for device identification, optimized
`imaging, and printer status. Other objects are also provided
`for data transfer to bracket connections prior to sending and
`receiving information. Still other objects are provided for
`canceling a print job, pausing a job, and clearing out a job.
`Finally, an object is also provided for supporting multiple
`streams of communication to an imaging task.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`4o
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The above and further advantages of the invention may be
`better understood by referring to the following description in
`conjunction with the accompanying drawings, in which:
`FIG. 1 is a schematic block diagram of a prior art
`computer system showing the relationship of the application
`program to the operating system and the printer driver in the
`prior art;
`FIG. 2 is a schematic block diagram of a modification of
`the prior art system shown in FIG. 1 to allow the application
`program to interface to a standard printing interface in the
`prior art;
`FIG. 3 is a block schematic diagram of a computer
`system, for example, a personal computer system on which
`the inventive object-oriented printing interface operates in
`accordance with a preferred embodiment;
`FIG. 4 is a schematic block diagram of modified computer
`system in which the operating system includes an inventive
`object-oriented printing interface in accordance with a pre-
`ferred embodiment;
`
`FIG. 5 is a block schematic diagram of the information
`paths and hardware by which printable information is chan-
`neled through intermediate storage to a print device in
`accordance with a preferred embodiment;
`FIG. 6 shows how the personality document is used by
`difierent parts of the printing system in accordance with a
`preferred embodiment;
`FIG. 7 details the printer handler components and their
`interactions in accordance with a preferred embodiment;
`FIG. 8 illustrates the relationship between various printer
`handler classes in accordance with a preferred embodiment;
`FIG. 9 is a block diagram of local printing in accordance
`with a preferred embodiment;
`FIG. 10 is a block diagram of remote imaging in accor-
`dance with a preferred embodiment;
`FIG. 11 is a block diagram of local imaging in accordance
`with a preferred embodiment; and
`FIG. 12 is a block diagram of local imaging to a net-
`worked printer.
`
`DETAILED DESCRIPTION OF THE
`ILLUSTRATIVE EMBODIMENTS
`
`The invention is preferably practiced in the context of an
`operating system resident on a personal computer such as
`the IBM, PS/2, or Apple, Macintosh, computer. A represen-
`tative hardware environment is depicted in FIG. 3, which
`illustrates a typical hardware configuration of a computer
`300 in accordance with the subject invention. The computer
`300 is controlled by a central processing unit 302, which
`may be a conventional microprocessor; a number of other
`units, all interconnected via a system bus 308, are provided
`to accomplish specific tasks. Although a particular computer
`may only have some of the units illustrated in FIG. 3 or may
`have additional components not shown, most computers will
`include at least the units shown.
`
`Specifically, computer 300 shown in FIG. 3 includes a
`random access memory (RAM) 306 for temporary storage of
`information, a read only memory (ROM) 304 for permanent
`storage of the computer’s configuration and basic operating
`commands and an input/output (I/O) adapter 310 for con-
`necting peripheral devices such as a disk unit 313 and printer
`314 to the bus 308, via cables 315 and 312, respectively. A
`user interface adapter 316 is also provided for connecting
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 15
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 15
`
`

`

`5
`
`6
`
`5,566,278
`
`input devices, such as a keyboard 320, and other known
`interface devices including mice, speakers and microphones
`to the bus 308. Visual output is provided by a display adapter
`318 which connects the bus 308 to a display device 322 such
`as a video monitor. The workstation has resident thereon and
`
`is controlled and coordinated by operating system software
`such as the Apple System/7, operating system.
`In a preferred embodiment, the invention is implemented
`in the 01+ programming language using object—oriented
`programming techniques. C-i—i- is a compiled language, that
`is, programs are written in a human-readable script and this
`script is then provided to another program called a compiler
`which generates a machine-readable numeric code that can
`be loaded into, and directly executed by, a computer. As
`described below, the CH- language has certain characteris-
`tics which allow a software developer to easily use programs
`written by others while still providing a great deal of control
`over the reuse of programs to prevent their destruction or
`improper use. The C—H— language is well-known and many
`articles and texts are available which describe the language
`in detail. In addition, C++ compilers are commercially
`available from several vendors including Borland Intema—
`tional, Inc. and Microsoft Corporation. Accordingly, for
`reasons of clarity, the details of the C-i—l- language and the
`operation of the CH compiler will not be discussed further
`in detail herein.
`
`As will be understood by those skilled in the art, Object-
`Oriented Programming (OOP) techniques involve the defi—
`nition, creation, use and destruction of “objects”. These
`objects are software entities comprising data elements and
`routines, or functions, which manipulate the data elements.
`The data and related functions are treated by the software as
`an entity and can be created, used and deleted as if they were
`a single item. Together, the data and functions enable objects
`to model virtually any real-world entity in terms of its
`characteristics, which can be represented by the data ele-
`ments, and its behavior, which can be represented by its data
`manipulation functions. In this way, objects can model
`concrete things like people and computers, and they can also
`model abstract concepts
`like numbers or geometrical
`designs.
`Objects are defined by creating “classes” which are not
`objects themselves, but which act as templates that instruct
`the compiler how to construct the actual object. A class may,
`for example, specify the number and type of data variables
`and the steps involved in the functions which manipulate the
`data. An object is actually created in the program by means
`of a special function called a constructor which uses the
`corresponding class definition and additional information,
`such as arguments provided during object creation, to con-
`struct the object. Likewise objects are destroyed by a special
`function called a destructor. Objects may be used by using
`their data and invoking their frmctions.
`The principle benefits of object-oriented programming
`techniques arise out of three basic principles; encapsulation,
`polymorphism and inheritance. More specifically, objects
`can be designed to hide, or encapsulate, all, or a portion of,
`the internal data structure and the internal functions. More
`
`particularly, during program design, a program developer
`can define objects in which all or some of the data variables
`and all or some of the related functions are considered
`“private” or for use only by the object itself. Other data or
`functions can be declared “public” or available for use by
`other programs. Access to the private variables by other
`programs can be controlled by defining public functions for
`an object which access the object’s private data. The public
`functions form a controlled and consistent interface between
`
`10
`
`15
`
`20
`
`25
`
`3O
`
`35
`
`45
`
`50
`
`55
`
`65
`
`the private data and the “outside” world. Any attempt to
`write program code which directly accesses the private
`variables causes the compiler to generate an error during
`program compilation which error stops the compilation
`process and prevents the program from being run.
`Polymorphism is a concept which allows objects and
`functions which have the same overall format, but which
`work with different data, to function differently in order to
`produce consistent results. For example, an addition func—
`tion may be defined as variable A plus variable B (A+B) and
`this same format can be used whether the A and B are
`numbers, characters or dollars and cents. However,
`the
`actual program code which performs the addition may differ
`widely depending on the type of variables that comprise A
`and B. Polymorphism allows three separate function defi—
`nitions to be written, one for each type of variable (numbers,
`characters and dollars). After the functions have been
`defined, a program can later refer to the addition function by
`its common format (A+B) and, during compilation, the CH-
`compiler will determine which of the three functions is
`actually being used by examining the variable types. The
`compiler will
`then substitute the proper function code.
`Polymorphism allows similar
`functions which produce
`analogous results to be “grouped” in the program source
`code to produce a more logical and clear program flow.
`The third principle which underlies object-oriented pro-
`gramming is inheritance, which allows program developers
`to easily reuse pre-existing programs and to avoid creating
`software from scratch. The principle of inheritance allows a
`software developer to declare classes (and the objects which
`are later created from them) as related. Specifically, classes
`may be designated as subclasses of other base classes. A
`subclass “inherits” and has access to all of the public
`functions of its base classes just as if these function appeared
`in the subclass. Alternatively, a subclass can override some
`or all of its inherited functions or may modify some or all of
`its inherited functions merely by defining a new function
`with the same form (overriding or modification does not
`alter the function in the base class, but merely modifies the
`use of the function in the subclass). The creation of a new
`subclass which has some of the functionality (with selective
`modification) of another class allows software developers to
`easily customize existing code to meet their particular needs.
`Although object-oriented programming offers significant
`improvements over other programming concepts, program
`development still requires significant outlays of time and
`effort, especiallyif no pre-existing software programs are
`available for modification. Consequently,
`a prior art
`approach has been to provide a program developer with a set
`of pre-defined, interconnected classes which create a set of
`objects and additional miscellaneous routines that are all
`directed to performing commonly-encountered tasks in a
`particular environment. Such pre—defined classes and librar-
`ies are typically called “application framewor
`” and essen-
`tially provide a pre-fabricated structure for a working appli-
`cation.
`
`For example, an application framework for a user inter-
`face might provide a set of predefined graphic interface
`objects which create windows, scroll bars, menus, etc. and
`provide the support and “default” behavior for these graphic
`interface objects. Since application frameworks are based on
`object-oriented techniques, the pre—defined classes can be
`used as base classes and the built—in default behavior can be
`inherited by developer—defined subclasses and either modi-
`fied or overridden to allow developers to extend the frame-
`work and create customized solutions in a particular area of
`expertise. This object-oriented approach provides a major
`
`,
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 16
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1015 - Page 16
`
`

`

`7
`
`8
`
`5,566,278
`
`advantage over traditional programming since the program-
`mer is not changing the original program, but rather extend-
`ing the capabilities of the original program. In addition,
`developers are not blindly working through layers of code
`because the framework provides architectural guidance and
`modeling and, at the same time, frees the developers to
`supply specific actions unique to the problem domain.
`There are many kinds of application frameworks avail-
`able, depending on the level of the system involved and the
`kind of problem to be solved. The types of frameworks range
`from high-level application frameworks that assist in devel-
`oping a user interface, to lower-level frameworks that pro-
`vide basic system software services such as communica-
`tions,
`printing,
`file
`systems
`support,
`graphics,
`etc.
`Commercial examples of application frameworks include
`MacApp (Apple), Bedrock (Symantec), OWL (Borland),
`NeXT Step App Kit (NEXT), and Smalltalk-80 MVC (Parc-
`Place).
`While the application framework approach utilizes all the
`principles of encapsulation, polymorphism, and inheritance
`in the object layer, and is a substantial improvement over
`other programming techniques, there are difficulties which
`arise. These difliculties are caused by the fact that it is easy
`for developers to reuse their own objects, but it is difficult for
`the developers to use objects generated by other programs.
`Further, application frameworks generally consist of one or
`more object “layers” on top of a monolithic operating
`system and even with the flexibility of the object layer, it is
`still often necessary to directly interact with the underlying
`operating system by means of awkward procedural calls.
`In the same way that an application framework provides
`the developer with prefab functionality for an application
`program, a system framework, such as that included in a
`preferred embodiment, can p