U.S. patent application number 09/805667 was filed with the patent office on 2001-08-30 for document delivery system facilitating aggregation of periodic content.
Invention is credited to Lee, Edward O..
Application Number | 20010017707 09/805667 |
Document ID | / |
Family ID | 23266180 |
Filed Date | 2001-08-30 |
United States Patent
Application |
20010017707 |
Kind Code |
A1 |
Lee, Edward O. |
August 30, 2001 |
Document delivery system facilitating aggregation of periodic
content
Abstract
A document server is presented comprising a user profile,
established by a user requesting delivery of content from one or
more content providers on a periodic basis, and an edit module. The
edit module periodically receives content from solicited content
providers in accordance with a content provider publication
schedule, and aggregates the received content for periodic delivery
to a requesting user when the content provider's publication
schedule deviates from a delivery schedule defined in the user
profile.
Inventors: |
Lee, Edward O.; (Corvallis,
OR) |
Correspondence
Address: |
HEWLETT-PACKARD COMPANY
Intellectual Property Administration
P.O. Box 272400
Fort Collins
CO
80527-2400
US
|
Family ID: |
23266180 |
Appl. No.: |
09/805667 |
Filed: |
March 13, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09805667 |
Mar 13, 2001 |
|
|
|
09325040 |
Jun 7, 1999 |
|
|
|
Current U.S.
Class: |
358/1.12 ;
707/E17.109 |
Current CPC
Class: |
G06F 16/9535 20190101;
G06Q 30/0273 20130101; G06Q 30/0264 20130101; G06Q 30/0271
20130101; G06Q 30/0272 20130101; G06F 3/1279 20130101; G06F 3/1229
20130101; G06Q 10/0631 20130101; Y10S 707/99932 20130101; G06F
3/1204 20130101; G06Q 30/0269 20130101; Y10T 83/543 20150401 |
Class at
Publication: |
358/1.12 |
International
Class: |
B41B 001/00 |
Claims
What is claimed is:
1. A method for generating a publication, the method comprising:
soliciting content from one or more content providers in response
to a user request to receive such content in accordance with a
user-defined delivery schedule; and receiving the content at a
content repository in accordance with a publication schedule of the
content and aggregating the content for subsequent delivery to the
requesting user if the publication schedule differs from the
user-defined delivery schedule.
2. A method according to claim 1, further comprising: compiling the
received content into a document format; and delivering the
formatted content in a user-defined form to the requesting
user.
3. A method according to claim 2, wherein compiling the received
content into a document format comprises: formatting the received
content within a publication to denote a chronological order in
which the content was received.
4. A method according to claim 2, wherein delivering the aggregated
content comprises: sending the formatted publication, along with a
print instruction, to printing device designated by the requesting
user.
5. A method according to claim 4, wherein the print instructions
designates a time for printing the publication.
6. A method according to claim 2, wherein delivering the aggregated
content comprises: sending the formatted publication to one or more
electronic mailboxes designated by the requesting user.
7. A method according to claim 1, wherein soliciting content from
one or more content providers comprises: sending a subscription
request to one or more content providers requesting the content in
accordance with the publication schedule of the content
provider.
8. A method according to claim 1, wherein soliciting content from
one or more content providers comprises: periodically issuing
requests to the content providers for content on behalf of the
requesting user.
9. A method according to claim 8, wherein the period is determined
by the publication schedule of the content provider(s).
10. A method according to claim 8, wherein the requests are issued
daily.
11. A storage medium comprising a plurality of executable
instructions which, when executed, implement an edit module to
solicit content from one or more content providers in response to a
user request to receive such content in accordance with a
user-defined delivery schedule, to receive the content at a content
repository in accordance with a publication schedule of the
content, and to aggregate the content for subsequent delivery to
the requesting user if the publication schedule differs from the
user-defined delivery schedule.
12. A storage medium according to claim 11, wherein the edit module
compiles the received content into a document format, and delivers
the formatted content in a user-defined form to the requesting
user.
13. A storage medium according to claim 12, wherein the edit module
compiles the received content by formatting the received content
within a publication to denote a chronological order in which the
content was received.
14. A storage medium according to claim 12, wherein the edit module
delivers the aggregate content by sending the formatted
publication, along with a print instruction, to printing device
designated by the requesting user.
15. A storage medium according to claim 12, wherein the edit module
delivers the aggregate content by sending the formatted publication
to one or more electronic mailboxes designated by the requesting
user.
16. A document delivery system comprising: an content repository,
to receive content from one or more content providers in accordance
with a content provider publication schedule; and an edit module,
coupled to the content repository, to periodically collect and
aggregate content received in the content repository for delivery
to a requesting user in accordance with a user-defined delivery
schedule.
17. A document delivery system according to claim 16, wherein the
edit module compiles the received content into a document format,
and delivers the formatted content in a user-defined form to the
requesting user.
18. A document delivery system according to claim 17, wherein the
edit module compiles the received content by formatting the
received content within a publication to denote a chronological
order in which the content was received.
19. A document delivery system according to claim 17, wherein the
edit module delivers the aggregate content by sending the formatted
publication, along with a print instruction, to printing device
designated by the requesting user.
20. A document delivery system according to claim 17, wherein the
edit module delivers the aggregate content by sending the formatted
publication to one or more electronic mailboxes designated by the
requesting user.
Description
RELATED INVENTIONS
[0001] The present invention is a continuation-in-part of U.S.
application Ser. No. 09/325,040 filed on Jun. 7, 1999 titled
Document Delivery System for Automatically Printing a Document on a
Printing Device, by Brewster, et al.
TECHNICAL FIELD
[0002] This invention generally relates to the printing field and,
more particularly, to a document delivery system facilitating
aggregation of periodic content.
BACKGROUND
[0003] In the mid-1400's, Johann Gutenberg revolutionized how
information is disseminated through his invention of the movable
type press. With the publication of the Mazarin Bible, documents
which were once held in the exclusive domain of a chosen few were
now widely available to the masses. Nearly 550 years later, the
mass media revolution that Gutenberg started is alive and well,
complete with newspapers such as the New York Times and the
Washington Post, magazines such as Newsweek and Sports Illustrated,
and literally thousands upon thousands of other publications.
[0004] While these thousands of publications cover a wide range of
interests, from news to sports to fashion to model rocketry, they
have one thing in common: they are intended to be read by a mass
market. Unlike the pre-Gutenberg days, where a document would
literally be read by only one person of a very small number of
people, it is not economically viable for today's publications to
have such a small readership, due at least in part to high
marketing, production and distribution costs. In fact, many of
today's publications are funded to a very large extent by the
advertising contained within them. These advertisers are attracted
to publications that can consistently deliver a large, reliable
audience of consumers that will be exposed to their
advertising.
[0005] While this mass-market publication model has worked well for
hundreds of years, it is not without its problems. One such problem
is that a typical reader of a publication has a wide variety of
interests, and no single mass market publication will be able to
satisfy all of these interests. For example, a reader who is
interested in international news, golf, fly-fishing, Genealogy, and
computers may have to subscribe to several different publications
to satisfy these interests. Of course, since these publications are
intended for the mass market, they will also contain a significant
amount of material that our reader is not interested in and will
not read. It goes without saying that if there is a significant
amount of material a read isn't reading, there is a significant
amount of advertising that the reader isn't reading either--as well
as a significant amount of paper that is wasted. Advertisers know
this, and agree to pay considerably less to a mass market magazine
or newspaper per 1000 exposures to their ad than they would pay to
a direct-mail generator that can provide a more specific guarantee
that the people exposed to their ad are of a demographic group that
will be much more likely to read and be receptive to their ad.
[0006] In addition, it is neither cost-effective nor time effective
for most readers to subscribe to and/or read a large number of
publications. Generally, the typical reader will only subscribe to
a few publications that are of the most interest to them. The
reduced readership level of the publications our typical reader
chooses not to subscribe to, even though she might be interested in
at least some of the editorial and advertising content contained
inside, means that the publication receives less subscription and
advertising revenue than they otherwise would. If many other
readers make the same decision, the continued health of the
publication may be in jeopardy, and the publication may be forced
out of business. In fact, many publications do go out of business
yearly for failing to attract a sustaining number of advertisers
and readers--even if there are a large number of readers that would
be interested in reading their publication, and a corresponding
number of advertisers anxious to have these readers exposed to
their ads. In general, publications that fail to attract a
substantial mass market of people willing to pay for and/or read
them cease publication. This is a shame, since many of these
publications would enrich the diversity of information available to
all readers, and would provide an avenue for lesser known writers
and artists to practice their wares.
[0007] In more recent years, a new type of publication has emerged:
the electronic publication. Readers of these publications typically
sign into the Internet through their computer, and read the
publications online. Some of these publications, such as CNN.com
and pointcast.com, allow users to state personal preference(s) on
what type of material they would like to read. Often, these
personalized publications include advertising, usually in the form
of a banner ad that is placed on or along a periphery of the visual
display (top, bottom, side, etc.).
[0008] While these electronic publications have been an interesting
development in the distribution of information, they still
represent only a tiny fraction of the information that is published
under the more traditional post-Gutenberg model. Many readers of
these electronic publications complain that they are very difficult
to read (on the video display), especially for long periods of
time. While it might be convenient for a reader to sign onto the
Internet to look at the CNN.com web site for a brief summary of
late breaking news, this reader would most likely only spend a few
minutes at the site, and would likely still subscribe to the more
traditional print media such as Newsweek or the Washington Post.
They would also likely spend significantly more time reading the
more traditional printed publication than they would spend reading
the electronic publication, and correspondingly, spend more time
being exposed to the ads in the traditional printed publication.
Accordingly, printed publications continue to flourish today--more
than five centuries after Gutenberg made them possible--and after
more than a decade after the innovation of the electronic
publication.
[0009] While these printed publications have certainly benefited
modern society, no significant attempt has been made thus far to
solve the underlying problems with these publications discussed
above. Just such a solution is provided herein.
SUMMARY
[0010] In accordance with the teachings of the present invention, a
document delivery system for automatically printing a document on a
printing device is presented. More specifically, in accordance with
one aspect of the invention, a document server is presented
comprising a user profile, established by a user requesting
delivery of content from one or more content providers on a
periodic basis, and an edit module. The edit module, responsive to
the user profile, periodically receives content from solicited
content providers in accordance with a content provider publication
schedule, and aggregates the received content for periodic delivery
to a requesting user when the content provider's publication
schedule deviates from a delivery schedule defined in the user
profile.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 shows a block diagram of a document delivery system
of one embodiment of the invention;
[0012] FIGS. 2-4 illustrate flow charts detailing the operation of
the transmission module and the printing module of the document
delivery system of one embodiment of the invention;
[0013] FIG. 5 illustrates how user profile information is acquired
from a user in one embodiment of the invention;
[0014] FIG. 6 shows how user profile information is acquired from a
user in one embodiment of the invention;
[0015] FIG. 7 shows a print schedule for the delivery of documents
in one embodiment of the invention;
[0016] FIG. 8 shows how the print schedule of FIG. 7 can be
modified by the user;
[0017] FIGS. 9A-9B shows a document printed by the printing device
according to one embodiment of the invention;
[0018] FIG. 10 shows a document printed by the printing device
according to one embodiment of the invention;
[0019] FIGS. 11A-11D show a document printed by the printing device
according to one embodiment of the invention;
[0020] FIG. 12 shows a document printed by the printing device
according to one embodiment of the invention;
[0021] FIG. 13 illustrates a block diagram of an example print
manager, according to one embodiment of the present invention;
[0022] FIG. 14 is a flow chart of an example method of generating
and delivering a personalized publication, in accordance with
another aspect of the present invention;
[0023] FIG. 15 graphically illustrates an example form requesting
aggregated delivery of periodic content, according to one example
embodiment;
[0024] FIGS. 16A and B graphically illustrate an example delivery
list segment of a user profile, according to one example
embodiment; and
[0025] FIG. 17 illustrates an example publication of aggregated
content, according to one embodiment of the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
[0026] FIG. 1 illustrates a block diagram of a document delivery
system of one embodiment of the invention. Document delivery system
10 contains document server 100. In the preferred embodiment,
document server 100 is operatively coupled via network 200 to a
variety of personal computers, printing devices, and other
electronic devices, collectively referred to devices 300. Document
server 100 contains edit module 120, transmission module 150 and
knowledge module 170. Edit module 120 receives inputs from one or
more content providers 50, and/or one or more advertising providers
80. Distribution module 400 is operatively coupled to document
server 100. In a preferred embodiment, document server 100 is a
minicomputer/server, such as an HP 9000 server sold by the
Hewlett-Packard Company, although those skilled in the art will
appreciate that document server 100 could be any type of other
computing or electronic device(s) that performs the functions
described herein and still fall within the spirit and scope of the
invention. Network 200 is preferably the Internet, although an
Intranet, local area network, or other type of public or private
network, either wired (e.g., telephone, cable TV, etc.) or wireless
(e.g., satellite, radio, cell phone, etc.), could also or
additionally be used.
[0027] Devices 300 are shown in FIG. 1 as being capable of being
configured in a wide variety of ways. For example, personal
computer 310 is shown connected to printing device 320, which
prints document 10320 for user 20320. Personal computer 310 is
operatively coupled to network 200. In contrast, printing device
330, which prints document 10330 for user 20330, is operatively
coupled to network 200 without an intervening personal computer or
other electronic device. Printing device 350, which prints document
10350 for user 20350, is shown connected to electronic device 340,
which could be a set top box, television set, palmtop personal
digital assistant (PDA) or other type of electronic device that is
operatively coupled to network 200. Finally, printing device 370,
which prints document 10370 for user 20370, is connected to
electronic device 360, which is operatively connected to network
200. The printing devices shown in FIG. 1 could be printers, such
as the HP DeskJet 890 printer, HP LaserJet V printer, or other
models of printers manufactured by HP or others; so-called
"mopiers" or other multi-function printing devices that can print,
fax, scan, and/or copy, or any other device capable of transferring
information to a printable media such as plain paper, specialty
paper, transparencies, or other media capable of tangibly receiving
such information and which can be easily carried about by the
user.
[0028] According to one aspect of the present invention, document
delivery system 100 includes an innovative printing module 380 and
a transmission module 150. Transmission module is preferably
located with document server 100. As FIG. 1 shows, printing module
380 could be located in any of the devices 300, such as in personal
computer 310, printing device 330, or electronic device 340,
operatively coupled via network 200 to document server 100, or it
could be located within document server 100 itself, such as in
knowledge module 170. According to one embodiment of the invention,
transmission module 150 and printing module 380 represent software
functions that execute on suitably programmed microprocessor(s)
within a device 300 and/or document server 100. It will be
appreciated, however, that special purpose hardware or other
mechanisms could be employed to implement the innovative features
and functions described below.
[0029] Turning briefly to FIG. 13, a block diagram of an example
printing module 380 is presented, according to one embodiment of
the invention. According to one embodiment, to be described more
fully below, printing module 380 resides within one or more of
devices 300 and, in response to user interaction with a user
interface (not shown), schedules and manages the delivery of one or
more documents to a printing device. Any of a number of user
interfaces may be used to utilize the features and functions of
printing module 380. According to a preferred embodiment, to be
described more fully below, a web page is projected to a device 300
by document server 100, content provider 50 and/or advertisers 80,
wherein the web page includes one or more iconic function calls to
one or more of the features/functions provided by printing module
380.
[0030] As shown in FIG. 13, printing module 380 includes one or
more controller(s) 402, a print function 404, a scheduler function
406, a document translation/interpretation function 408, a
memory/storage system 410, an input/output (I/O) interface 412, and
optionally one or more applications 413, each coupled as shown. It
will be appreciated that, although denoted as separate functional
blocks, one or more elements 402-413 may well be combined without
deviating from the spirit and scope of the present invention.
Moreover, although depicted in accordance with a hardware paradigm,
those skilled in the art will appreciate that printing module 380
and its associated elements 402-413 may well be embodied as a
series of executable instructions which, when executed by a host
processor of devices 300, implement the features and functions of
printing module 380 to be discussed below. In this regard, FIG. 13
is merely illustrative of the scope and spirit of the claimed
invention.
[0031] As shown, controller(s) 402 selectively invoke one or more
functions 404-408 and/or applications 413 in response to user
interaction with a user interface, e.g., a web page. According to
one embodiment, the user interface includes iconic selectors, e.g.,
buttons, which when selected by the user causes controller 402 to
selectively invoke an instance of a function associated with the
selector. In this regard, controller 402 communicates with external
elements via input/output (I/O) interface(s) 412. In an alternate
embodiment, controller 402 provides a user with a user interface
from applications 413.
[0032] As used herein, I/O interface(s) 412 are intended to include
one or more of any of a number of communication interfaces known in
the art including, but not limited to, a direct connect
communication interface (e.g., a serial interface, a parallel
interface, a Universal Serial Bus (USB), an Advanced Graphic Port
(AGP), etc.), a local area network interface (e.g., an Ethernet
interface, a Token Ring interface, etc.), or a wide area network
interface. In this regard, printing module 380 may communicate with
any of a number of external and remote devices using an appropriate
one of a plurality of wired and/or wireless I/O interfaces 413.
[0033] Automated print function 404 is selectively invoked by
controller 402 in response to a user indication to immediately
print a document (e.g., within the next several seconds) without
first viewing or displaying the document. According to one
embodiment, a user interface projected by printing module 380 or
from an external source (e.g., document server 100) includes an
iconic selector associated with one or more documents to invoke the
automated print function 404 to print the one or more documents.
Insofar as selection of the iconic selector associated with the one
or more documents automatically causes the documents to be queued
for printing (e.g., within the subsequent several seconds), the
iconic selector is referred to herein as an "automated print" icon,
or an "instant print" icon.
[0034] When the automated print icon associated with one or more
documents is selected by a user, the user interface provides
controller 402 with information regarding the associated one or
more documents. According to one implementation, user interface
provides controller 402 with a name/identifier and storage location
of the one or more documents. Controller 402 provides the
name/identifier and location information to automated print
function 404 to queue the document for printing. As will be
described in more detail below, automated print function generates
and issues a request to retrieve the identified document(s) from
the identified storage location via I/O interface 412. The
retrieved documents are stored in memory locations 414A, 414B, etc.
of memory 410. Once retrieved, document translation/interpretation
function 408 is selectively invoked to interpret/translate and
print the retrieved document. According to one implementation, the
retrieved documents are queued and printed substantially
instantaneously (e.g., within the subsequent several seconds). In
alternate embodiments, the retrieved document(s) are printed
according to a print schedule defined by the user.
[0035] According to one aspect of the invention, to be described
more fully below, the document associated with an iconic selector
is retrieved from a provider into memory 410 of print module 380
and immediately printed without invoking an application associated
with the document. That is, translation/interpretation function 408
reads the stored document(s), interprets the textual, image,
formatting, etc. content of the document(s) to print the document
on an operatively coupled printer without having to invoke the
application associated with the retrieved document(s), and without
having to display the document(s) to the user prior to
printing.
[0036] In an alternate embodiment, an application 413 (e.g.,
Microsoft Word, Adobe Acrobat, etc.) associated with the document
is invoked by controller 402 to print the document, but neither the
document nor the application 413 are displayed to the user so, from
the user's perspective, the application is not launched. In either
case, automated print function 404 enables a user to immediately
print a remote document without having to manually download, launch
and print the document, thereby providing the user with the
convenience and selection of electronic publications, with the
physical reading experience introduced by the Gutenberg press.
[0037] The scheduling function 406 enables a user to establish a
print schedule 390 for documents of interest. According to one
embodiment of the present invention, scheduling function 406 is
selectively invoked by controller 402 in response to a user's
indication to add the document to a print schedule 390. As shown in
FIG. 1, the printing schedule 390 may be located in devices 300,
document server 100 or any other accessible location.
[0038] Turning to FIGS. 2-4, flowcharts detailing the operation of
transmission module 150 and a first mode of operation of printing
module 380 are presented, according to one embodiment of the
invention. In FIGS. 2-4, the flow diagram shown in the left column
is executed by transmission module 150 of document server 100, and
the flow diagram in the right column is executed by printing module
380.
[0039] Referring now to FIG. 2, the flow diagram for transmission
module 150 starts in block 1000, and the flow diagram for printing
module 380 starts in block 2000. Since there is a great deal of
interaction between these two flow diagrams, as represented by
dashed lines connecting the two columns, the operation of the two
flow diagrams will be described simultaneously.
[0040] In block 2100, user profile data is sent to document server
100 to be stored in the user profile. This user profile data can
take on many different forms, from simple to very detailed. FIG. 5
shows a very simply acquisition of user profile data, such as that
used in HP's Instant Delivery Program, the first version of which
was generally available to the public less than one year from the
filing date of this patent application. In this program, only three
pieces of information are stored in the user profile: type of
printer, email address, and whether HP can contact the user. FIG. 6
shows a more complicated user profile than that currently used in
HP's Instant Delivery Program, which includes the user's name,
email address, company name, city, state, country, zip or postal
code, phone number, printer information, and areas of interest.
Those skilled in the art will appreciate that more or less user
profile data from those shown in FIGS. 5 and 6 could be sent to
transmission module 150 in block 2100 and still fall within the
spirit and scope of the invention, and that at least some of this
information could come from a source other than a user. For
example, the user profile data could also include household income,
age, and sex of the user, among other things. In any event, block
1100 receives the user profile data sent by block 2100. Block 1200
stores the user profile data, preferably in knowledge module 170.
Alternately, the user profile data could be stored in device 300 or
in some other local or remote location.
[0041] Block 2200 checks to see whether a document should be
received form document server 100. This is done by checking print
schedule 390 which is preferably stored on a device 300 or document
server 100, but may be stored in some other local or remote
location. Printing schedule 930 preferably contains information
that can be used to determine when documents should be printed by
the printing device, such as upon document creation, user requested
time, lapse of specified time period, and/or occurrence of one or
more external events (e.g., a stock price or index reaching a
specified value, a final score of a sporting event, etc.). Printing
schedule 390 may be associated with an individual user, a device or
a group or users and/or devices. In addition, each entry of
printing schedule 390 could result in the printing of one or more
documents.
[0042] FIG. 7 shows one example of printing schedule 390, of the
type that might be used in an enhanced version of HP's Instant
Delivery program. In this example, the title of delivery, delivery
schedule, next delivery data and time, and the last deliver status
are shown. Preferably, the user can select what time a document
should be printed, whether it should be printed on a specific day
of the week or month, weekdays, or weekends, and whether the
printing schedule should expire after a specific period of time or
continue indefinitely.
[0043] Referring again to FIG. 2, printing module 380 monitors
printing schedule 390 to see if a document should be requested from
document server 100 or from another source. When block 2200
determines that a document should be requested from document server
100 or from another source, block 2200 is answered affirmatively,
and block 2300 automatically requests the document without user
intervention from server 100 or from another source, as will be
described in greater detail below. Note that if printing module 380
is located on device 300, block 2200 operates in a "pull"
mode--where the document is "pulled" from document server 100 or
another source to device 300. However, if printing module 380 is
located remotely from device 300, such as in document server 100,
block 2200 operates in a "push" mode--where the document is
"pushed" from document server 100 or another source to device 300.
If block 2300 determines that the document is located on document
server 100 or at another source accessible via network 200, and if
device 300 is currently in a disconnected state where it is not
operatively coupled to the network 200, block 2300 will sign on to
or otherwise enter a connected state with network 200, so that
device 300 is operatively coupled to network 200.
[0044] Meanwhile, block 1300 checks to see if a document has been
requested from printing module 380 in block 2300. Once it
determines that such a document has been requested, block 1400
generates the document for printing module 380. Block 1500 then
sends the document to printing module 380. Block 2400 checks to see
whether a document has been received from document server 100 via
block 1500. Once such a document has been received, block 2500
automatically prints the document, without user intervention, on a
printing device. The term "without user intervention" means that a
user is not directly involved in the printing operation; the
document is sent automatically to a device 300 to be printed out by
a printing device. According to this mode of operation, the user
does not press "any" print buttons or otherwise be directly
involved in the printing process; in fact, the user may not even be
present in the same room, city, state, or country as device 300
during the printing operation. The printing operation automatically
occurs in an unattended state-- regardless of whether the user is
present or not. In addition, if print schedule 390 is stored in a
device-independent manner, such as on document server 100, a
travelling user could "log in" to document server 100 and have his
or her customized document sent to a device 300 that is convenient
to the user's current location.
[0045] Referring now to FIG. 3, block 2600 checks to see whether
the document printed successfully. If not, block 2800 performs
error handling, such as attempting to print the document again,
notifying the user that the printing device is out of paper or has
some other error condition, or simply deciding not to print the
document. When the document prints successfully, block 2900 informs
document server 100 that the document printed successfully. Block
1600 waits for an indication from printing module 380 that the
document did print successfully. When such an indication is
received, block 1700 updates the user profile with this
information.
[0046] It will be appreciated that not all of the blocks in FIGS.
2-4 need be implemented, or implemented according to the order
denoted, to fall within the spirit and scope of the present
invention. More specifically, according to one implementation, flow
of control moves from block 2600 to block 4100 of FIG. 4, as will
be discussed later, and from block 1500 back to block 1300 of FIG.
2.
[0047] An alternate embodiment has been contemplated where other
information is transmitted back to document server 100 in block
2900 to update the user profile preferably stored in knowledge
module 170. This other information could be ink usage (total usage
or usage broken out by ink color), printable media usage (number of
pages printed, type of media used, etc.), or other types of
information. In addition, another alternate embodiment has been
contemplated where some or all of the information contained in the
user profile stored in knowledge module 170 came from a source
other than the user via printing module 380. For example, publicly
or privately available information about the user, and/or the
devices 300 he/she/they use, could be acquired from a wide variety
of different sources and inserted into the user profile preferably
stored in knowledge module 170.
[0048] Block 1800 examines the user profile preferably stored in
knowledge module 170 to determine whether a product subsidy should
be provide to the user. For example, if the information in the user
profile indicates that this user has printed off his 1000.sup.th
document, such as a "preferred" document that contains advertising
from advertising providers 80 or is otherwise under the control of
edit module 120, providing a product subsidy to the user may be
warranted. For purposes of this invention, a "product subsidy"
could be a print consumable or other product. A "print consumable"
is an inkjet cartridge for an inkjet printer, ink for such an
inkjet cartridge, a toner cartridge for a laser printer, toner for
such a toner cartridge, or any other product or substance that is
depleted when a document gets printed, including printer ribbons,
etc. Note that the "ink" referred to above would typically be of a
permanent variety, but erasable ink, such as that sold by the Eink
Company, could also be used.
[0049] Note that the product subsidy referred to herein is
preferably funded at least in part by advertising revenue received
from advertising providers 80 (FIG. 1), but an embodiment has been
contemplated where the product subsidy is funded at least in part
from the distribution revenue received from content providers 50
(FIG. 1). In either case, information (such as statistical
information) about what was printed by whom is preferably provided
to content providers 50 and/or advertising providers 80--
preferably as a document that is automatically sent to one or more
printing devices according to the teachings of this invention.
[0050] Other forms of products that are contemplated to be
subsidized by this invention include printable media, such as plain
paper, specialty paper, transparencies, and the like, and may also
include devices 300 such as printing devices, electronic devices,
and personal computers. In fact, alternate embodiments have been
contemplated where other products, such as a subscription price to
a document, or even a product not directly related to the document
delivery system shown herein, such as soap or dog food, are
subsidized. If block 1800 determines that such a subsidy is
warranted, block 1900 requests that distribution module 400
provides such a subsidy to the user. In one embodiment,
distribution module 400 simply mails a product such as a print
consumable or other product such as the type described above to a
user at the address specified in the user profile. In another
embodiment, distribution module 400 mails or electronically
generates a coupon that the user can use to receive a free or
discounted product of the type described above. Regardless of
whether block 1800 is answered affirmatively or negatively, flow of
control then returns back to block 1300 (FIG. 2) to see if another
document has been requested from the printing module 380.
[0051] Referring again to FIG. 3, after block 2900 informs document
server 100 that the document printed successfully, flow of control
moves to block 4100 (FIG. 4), which checks with document server 100
to see what the current version of printing module 380 is. Block
3100 checks to see whether such a request has been received, and
when it is, block 3200 sends information concerning the current
version of the printing module to printing module 380. Block 4200
compares this information from document server 100 with its own
version and determines whether an updated version of printing
module is available. For example, if printing module 380 is running
version 4.0, and document server 100 indicates that version 4.1 is
the current version of printing module 380, block 4200 would
determine that an updated version of printing module 380 is
available, and flow control would move to block 4300. Block 4300
checks to see whether this updated version of printing module 380
should be requested to be downloaded. While a user would typically
be asked whether such a download should be requested or not, and
would typically perform this download at a convenient time, such a
step could also be performed automatically without user
intervention. If such a download is requested, block 4400 is
answered affirmatively, and block 3500 downloads the updated
printing module, which is then installed in block 4500. Regardless
of how blocks 4200 and 4300 are answered, flow of control moves to
block 4600, which checks to see if a disconnected state should be
entered. If block 2300 (FIG. 2) determined that device 300 was in a
disconnected state when the document was requested, as discussed
above (i.e., not operatively coupled to network 200), block 4600 is
answered affirmatively, and block 4700 reenters the disconnected
state. In any event, flow of control returns to block 2200 of FIG.
2.
[0052] Referring again to print schedule 390 shown in FIG. 7, it
can be seen that many different types of documents can be requested
to be printed. For example, the title of document 11000 specifies a
network address, such as an Internet uniform resource locator (URL)
that contains the network location of a document to be printed.
Note that this URL may be partially or completely hidden from the
user, as is the case with the URL for document 15000
(http://www.beloitdailynews.com). In this scenario, edit module 120
of document server 100 merely goes out to the Internet at the URL
indicated (which would be shown in FIG. 1 as one of the content
providers 50), and captures the indicated content, which may well
be aggregated over a period of time, formatted and subsequently
transmitted to a requesting user, e.g., at a coupled printing
device, via transmission module 150 and printing module 380, as has
been discussed. Alternatively, device 300 could go directly out to
the URL itself without assistance from document server 100; in this
case, block 2300 (FIG. 2) requests document 11000 from another
source--directly from the content provider 50 (at the indicated
URL) via network 200.
[0053] In certain instances, described more fully below, edit
module 120 periodically receives content on behalf of a requesting
user for aggregation and delivery according to a user-defined
delivery schedule that differs from a content provider publication
schedule. Accordingly, edit module 120 stores the received content
for later retrieval, aggregation and formatting into a personalized
publication for delivery in accordance with the user defined
delivery schedule (e.g., as denoted in the user profile).
[0054] In contrast, document 12000 is not a document that
originates with a content provider 50 via the Internet, but instead
is stored directly on device 300, such as a printing device,
personal computer, or other electronic device. An example of such a
document could be a daily calendar from a program such as Microsoft
Outlook, which the user has requested be printed automatically to
his printer, without any user intervention, at 7:00 a.m. every
weekday morning. In such an embodiment, printing module 380 does
not need to request the document from document server 100, since it
can access the documents without going through network 200. In this
embodiment, block 2300 of FIG. 2 requests the document from another
source--device 300. While block 2900 would still preferably
indicate that the document was printed, and while block 1700 would
still preferably update the user profile in knowledge module 170,
printing such a document would preferably not generate any type of
credit towards a product subsidy, since such a document would not
be considered a "preferred" document, e.g., not a document under
the control of edit module 120.
[0055] Referring again to FIG. 7, a print schedule of document
13000 is shown. Document 13000 is referred to as a "personalized
document". A "personalized document" is a document that is
assembled by edit module 120 of document server 100 from a variety
of content providers 50 and advertising providers 80, based on
information contained in the user profile stored in knowledge
module 170. For example, document 13000 is a "personalized
document". Our user has requested that document 13000--his
personalized newspaper--be printed at 6:00 a.m. every day. Edit
module 120 examines the user's interests as specified in the user
profile stored in knowledge module 170 to assemble the document
from selected content providers 50 in which the user has indicated
an interest. Edit module 120 also inserts advertising from selected
advertising providers 80--again based on the user profile stored in
knowledge module 170.
[0056] FIG. 8 shows how the print schedule 390 of FIG. 7 can be
edited by the user. The user can use the publisher's recommended
schedule, use a default schedule the user has set, or use a custom
schedule for delivery. If a custom schedule is selected, the user
can select a daily, weekly, or monthly delivery, or select a
delivery once every specified number of days, or specify every
weekday. In addition, the time of day can also be specified: once
at a designated time, multiple times during the day, or multiple
times separated by a specified period of time. While not shown
here, the user could also edit print schedule 390 to request that a
document be sent upon creation, or upon the occurrence of an
external event.
[0057] FIGS. 9A-9B show document 11000 printed by the printing
device according to one embodiment of the invention. Note that this
document came from one content provider 50 via network 200 (either
through document server 100 or directly), and contains no
advertising. While document 11000 is preferably formatted by
content provider 50 such that the information contained in the
document is optimized to be printed, such formatting is not
necessary.
[0058] FIG. 10 shows document 12000 printed by the printing device
according to one embodiment of the invention. Note that this
document is a user's daily calendar which came directly from device
300 and not from document server 100 via network 200.
[0059] FIGS. 11A-D show document 1300 printed by the printing
device according to one embodiment of the invention. Note that this
document is a user's personalized newspaper which contains
information in which the user has indicated a specific interest in,
as stored in the user profile in knowledge module 170. Note also
that this document contains advertising that edit module 120
determined the user would also be interested in, again based on the
information contained in the user profile stored in knowledge
module 170. As has already been discussed, when the user prints a
sufficient number of such "preferred" documents, the user may
receive a product subsidy of a print consumable or other
product(s).
[0060] FIG. 12 shows document 14000 printed by the printing device
according to one embodiment of the present invention. Note that
document 14000 is the HP Instant Delivery Times--a document located
on document server 100. While this document does not contain
advertising per se, it is still considered to be a "preferred
document", since it is under the control of edit module 120.
Document 14000 informs users of Instant Delivery of new releases or
new information about the Instant Delivery Program.
[0061] Aggregated Delivery of Periodic Content
[0062] Having introduced an example document delivery system
architecture and associated operational methods, above, attention
is now drawn to FIGS. 14-17, wherein another aspect of the
invention is presented. As introduced above, document server 100
solicits and/or receives content from one or more content providers
(50, 80) in the generation of personalized publications for
requesting users. Typically, to provide the most current
information, once the content is received from the content
provider(s) (50, 80), it is formatted and delivered to the user.
There is content, however, wherein it is not as important that the
user receive it while it is "fresh". Indeed, there are
circumstances when it may well be more convenient for the user to
receive an aggregate of such content on a periodic basis which
differs (e.g., more infrequently) from the publication schedule of
the content itself. For example, while comic strips are published
on a daily basis, it may be more convenient for certain users to
receive an aggregate of such content on a weekly or monthly basis.
Thus, in accordance with one aspect of the present invention,
document delivery system 10 may well incorporate a content
repository (e.g., a storage medium coupled to document server 100)
to aggregate periodic content for delivery in accordance with a
user-defined delivery schedule. For purposes of illustration, and
not limitation, this aspect of the invention will be developed in
accordance with the example implementation introduced above,
wherein a user wishes to receive a weeks worth of daily content
(e.g., the Cathy.RTM. comic strip) once a week.
[0063] Turning to FIG. 14, a flow chart of an example method for
delivering aggregate content to a requesting user is presented,
according to one aspect of the present invention. In accordance
with the illustrated example embodiment of FIG. 14, the method
begins with block 16002, wherein document server 100 receives an
indication from a user requesting content delivery in accordance
with a user-defined schedule. Unlike the implementations introduced
above, however, the user wants the content delivered according to a
schedule (user-defined schedule) that differs from the publication
schedule of the content provider(s) (50, 80). According to one
example implementation, edit module 120 of document server 100
receives a request from a user interface (UI) rendered on a
computing interface for the user. A graphical illustration of an
example UI to generate just such an indication is presented with
reference to FIG. 15.
[0064] Turning briefly to FIG. 15, a graphical illustration of an
example user interface enabling a user to schedule aggregate
delivery of content is presented, according to one example
embodiment. In accordance with the illustrated example embodiment
of FIG. 15, a user interface 17000 associated with the select
content (e.g., Cathy.RTM. comic strip) is presented. According to
one implementation, the UI 17000 is presented upon user selection
of the content from a catalog of available content. The indication
introduced above is sent to, for example, edit module 120, when the
user selects the "add delivery" button 17002.
[0065] In block 1604, edit module 120 updates a print schedule 390
associated with the user to denote periodic delivery of aggregate
of content. More particularly, edit module 120 presents the user
with an interface that enables the user to add the content to the
delivery schedule, and updates the delivery schedule to reflect the
user's preferences. Just such an interface is presented with
reference to FIGS. 16A and B.
[0066] As shown, FIG. 16A and FIG. 16B graphically illustrate an
example interface to manage a user print schedule, according to one
example embodiment. In accordance with the illustrated example
implementation of FIGS. 16A and B, the user's delivery schedule
18000 is presented, along with a dialog box 18002 requesting that
the user confirm that they wish to add the select content to the
delivery schedule. If the user selects the "accept" button of the
dialog box 18002, a management interface is presented, which
enables the user to define the delivery criteria for the selected
content. An example management interface was presented above, with
reference to FIG. 8. As introduced above with reference to FIG. 8,
a user can select delivery of content on a schedule that differs
from that of the content provider(s) publication schedule. More
particularly, by selecting "my default schedule" or the "custom
defined schedule" for the delivery of the content, the user can
elect to receive an aggregate of the content provider's serially
published content on a schedule that suits their particular
situation. In accordance with the illustrated example
implementation, perhaps it is more convenient for the user to
receive the entire week's worth of Cathy.RTM. comic strips,
published daily, on Sunday when they have the time to read the
content they so enjoy. If the content were delivered according to
the publication schedule, it may go unread if the user does not
have the time to review the material, thereby wasting print-related
supplies (e.g., paper, ink, etc.). Once the user has defined the
delivery criteria for the selected content in the UI of FIG. 8, an
updated delivery schedule 18004 is generated, in accordance with
the teachings above, to reflect the addition of the aggregate
content, block 18006.
[0067] Continuing with the flow chart of FIG. 14, once the delivery
schedule has been updated to reflect the addition of aggregate
content 18006, edit module 120 determines whether new content has
been received, block 16006. According to one example
implementation, edit module 120 periodically receives content from
one or more content providers in accordance with the content
providers publication schedule for delivery to requesting users.
For those users that wish delivery of the content in accordance
with the publication schedule of the content provider (50, 80), the
content is prepared for delivery in accordance with FIGS. 2-4. For
those users that desire delivery of the content on their own
schedule, the process continues with block 16008 wherein the new
content is stored in a content repository accessible by edit module
120 for subsequent retrieval and delivery by document server
100.
[0068] According to one implementation, document server 100
includes a storage device (not shown) which caches pointers to
memory locations at the content provider(s), wherein a copy of
content that was previously published for serial delivery may be
found. It is to be appreciated that by leveraging the storage
capability of the content provider(s) (50, 80), which likely retain
a copy of published content for a period of time anyway, the
storage requirements of the document server 100 are reduced. In an
alternate embodiment, document server 100 is coupled to one or more
storage devices which receive and maintain a copy of select content
from content provider(s) (50, 80) for subsequent retrieval and
delivery to requesting users.
[0069] In block 16010, the process continues with edit module 120
determining whether it is delivery time for one or more of the
content identified in the delivery schedule 18004. If not, document
server 100 continues with block 16006. If, in block 16010 edit
module determines that it is time to deliver aggregate content, the
content is collected from the content repository for delivery,
block 16012. In accordance with the illustrated example
implementation, the content repository is accessed by edit module
120 to retrieve the select content published since the last
scheduled delivery. As introduced above, the collection by edit
module 120 may involve issuing requests to memory of the content
provider(s) for content stored at memory locations denoted by the
one or more pointers retrieved from the repository. Alternatively,
the edit module 120 retrieves the actual content from local storage
for delivery to the user. According to one implementation, edit
module 120 formats the aggregate content, in accordance with user
preferences, to denote when the content was originally published.
In accordance with the example implementation, edit module 120
formats a publication with a weeks-worth of Cathy.RTM. comic
strips, wherein each daily strip is specifically denoted.
[0070] In block 16014, the personalized publication comprising the
aggregated content is delivered to the requesting user. An example
of just such a personalized publication is presented with reference
to FIG. 17, according to the example implementation introduced
above.
[0071] FIG. 17 illustrates an example publication of aggregated
content, according to one embodiment of the present invention. In
accordance with the illustrated example implementation of FIG. 17,
a personalized publication comprising a weeks worth of Cathy.RTM.
comic strips is generated for periodic delivery to the user, in
accordance with the user delivery schedule 18004. As introduced
above, edit module 120 may format the personalized publication
19000 to denote when the content was originally published (e.g.,
the day of the week, the date, etc.). Thus, in accordance with the
illustrated example implementation, edit module 120 formats the
personalized publication 19000 to denote which strip appeared on
Monday 19002, Tuesday 19004, etc.
* * * * *
References