US20040078304A1

US20040078304A1 - Background advertising system

Info

Publication number: US20040078304A1
Application number: US10/620,947
Authority: US
Inventors: Chuck Gabbard; Bruce Chaffins; Everett Howerton
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-06-05
Filing date: 2003-07-16
Publication date: 2004-04-22
Also published as: US6205432B1; US6633850B1

Abstract

An advertisement system and method are provided for inserting into an end user communication message a background reference to an advertisement. In some embodiments, the background reference causes an advertisement image to be tiled, or watermarked, across an end user screen behind the text of an e-mail message or public posting. A message server inserts the background reference after receiving a message originally sent from an end user originator and before sending the message to be delivered to an end user recipient. When necessary, the message server will convert at least a portion of the message into a proper format, such as HTML, before inserting the background reference to an advertisement, which is preferably selected in accordance with end user recipient demographic information and/or ad exposure statistics. The advertisement itself, often a graphical file, is preferably not transmitted with the message, but is typically stored at the message server or other location remote from the end user recipient. Preferably, the message server maintains and refer to records on each end user recipient to allow for selective enablement of background reference insertion and overwriting based upon end user preferences. According to various “non-web” example embodiments, the message server transmits an SMTP, POP3 or NNTP message with an HTML portion for a respective HTML-compatible client. In other “web-based” example embodiments, the message server transmits the entire message in HTML to be used as a stand-alone web page or as a portion of a larger page employing frames or tables.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 09/567,250, filed May 9, 2000, which is hereby incorporated herein by reference in its entirety, and which is a continuation of Ser. No. 09/193,459, filed Nov. 16, 1998, which claimed the benefit of U.S. application Ser. No. 60/088,149, filed Jun. 5, 1998.[0001]

STATEMENT AS TO ANY INVENTION RIGHTS UNDER FEDERALLY SPONSORED RESEARCH

Not applicable.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of advertising systems, and more particularly to the field of Internet advertising.

The worldwide network of computers connected through the Transmission Control Protocol/Internet Protocol (TCP/IP) communications standard, commonly known as the Internet, has seen explosive growth during the last several years. This growth has been fueled in part by the introduction and widespread use of so-called “web” browsers, which allow for simple graphical user interface (GUI) access to network servers, which support documents formatted as so-called web pages. The World Wide Web (WWW), or “web”, is a collection of servers on the Internet that utilize a Hypertext Transfer Protocol (HTTP), which is an application protocol that provides users access to files (which can be in different formats such as text, graphics, images, sound, video, etc.) using a Standard Generalized Markup Language (SGML), which is an information management standard for providing platform-independent and application-independent documents that retain formatting, indexing, and linking information. SGML provides a grammar-like mechanism for users to define the structure of their documents and the tags they will use to denote the structure in individual documents. The page description language known as Hypertext Markup Language (HTML) is an application of SGML. HTML provides basic document formatting of text and images and allows the developer to specify hyperlinks, or “links,” to other servers and files. Use of an HTML-compliant client, such as a web browser, involves specification of an address via a Uniform Resource Locator (URL). Upon such specification, the client makes a TCP/IP request to the server identified in the URL and receives a “web page” (namely, a document formatted according to HTML) in return.

Electronic mail (E-mail) is another important part of online activity. Conventional e-mail is the exchange of text messages and computer files over a communications network, such as a local area network or the Internet, usually between computers or terminals. Routing of e-mail on the Internet is typically accomplished through the use of a protocol for sending messages called the simple mail transfer protocol (SMTP). Multipurpose Internet mail extensions (MIME) extend SMTP to permit data, such as video, sound, and binary files, to be transmitted by Internet e-mail without having to be translated by the e-mail client into ASCII format. This is accomplished by the use of MIME types, which describe the contents of a document. A MIME-compliant client application sending a file, such as one of various conventional e-mail programs, assigns a MIME type to the file. The receiving application, which must also be MIME-compliant, refers to a standardized list of documents that are organized into MIME types and subtypes to interpret the content of the file. MIME is part of HTTP, and both web browsers and HTTP servers use MIME to interpret e-mail files they send and receive. Post Office Protocol 3 (POP3) is a recent version of a standard protocol for receiving e-mail. POP3 is a client-server protocol in which e-mail is received and held in a mailbox for a user by a network server. Periodically, the end user checks the mailbox on the network server and downloads any e-mail. An alternative protocol is Interactive Mail Access Protocol (IMAP), according to which a user views e-mail at the server as though it was on the user's computer, and an e-mail message deleted locally is still on the server. Thus, POP3 can be thought of as a “store-and-forward” service, while IMAP can be thought of as a remote file server. Therefore, an e-mail message is typically sent with SMTP, and after a network server receives the e-mail message on the end user recipient's behalf, the e-mail message is typically read by the end user using POP3 or IMAP.

In addition to older basic e-mail systems, including basic ASCII e-mail clients using SMTP and POP3, some enhanced e-mail clients, such as Eudora Pro Email v. 4.0, display HTML portions of messages according to HTML formatting contained in the e-mail message bodies. Also, web-based e-mail systems, such as are currently offered by Hotmail™ and Yahoo™, are accessible through web browsers. In those systems, e-mail messages are formatted into web pages, or portions thereof, for formatted viewing control through web browsers. Thus, plain text e-mail messages received by those web based e-mail systems are converted into web pages for viewing by web browsers.

Shared public message networks include Usenet Newsgroups, Internet Relay Chat, Fidonet, RIME, ELINK, and a host of others. Public message networks also include public message areas in proprietary online systems. Most are normally set up according to separate general interest categories (e.g., “conferences,” “forums,” or “newsgroups”), subjects within those categories (e.g., “subjects,” “topics,” or “threads”), and finally individual messages or postings within each subject, typically arranged chronologically, as well as according to earlier messages to which they respond. Also included in this category of public messaging are instant messaging programs, which allow users to communicate publically with other users in real time. These conferences typically are carried by many online systems regionally, around the country, or even around the world. Newsgroups also have an Internet protocol which governs their transmission called network news transfer protocol (NNTP). As with e-mail clients, public messages are also accessible through web browsers, enhanced public messaging clients capable of displaying HTML formatting, and basic ASCII clients.

The recent growth of information applications on international public packet-switched computer networks, such as the Internet, suggests that public computer networks have the potential to establish a new kind of open marketplace for goods and services. As web pages, discussion forums and e-mail communications are used more nationally and internationally, it is highly desired that manufacturers and merchants be able to non-offensively advertise their goods and services to users during their regular course of Internet activity. With only limited success, such advertising has been done through the use of images as well as text transferred over the Internet. Advertisements transferred over the Internet often, but not always, make use of trademarks. A “trademark” is a word, design, color, sound, smell, etc., or any combination thereof, used by a manufacturer or merchant to identify their goods and/or services and distinguish them from others. In general, advertisements include most types of communications promoting goods and/or services of organizations or individuals, as well as promoting the organizations or individuals themselves. Entities with access to potential viewers of advertisements often charge a fee to other entities interested in advertising themselves and/or their goods and/or services.

On the Internet, as in more traditional venues of advertising, such as billboards, TV commercials, products, etc., most advertisements (ads) include promotional material intended to be used to interest consumers with particular goods or services. Currently, one primary way to advertise on the Internet is through ad banners, which often contain static or animated images, with or without trademarks, and normally advantageously function as hyperlinks to advertisement owner web pages. Unfortunately, banner ads often disappear with scrolling by the user and take up precious screen space. Furthermore, because of typically large graphical content, banner advertisements are often slow in downloading. As a result, users often move down a web page or to another web page and do not wait for advertisements to complete the downloading process if text or other content is displayed before, or simultaneously with, the advertisements, thereby clearly diminishing the impact of the advertisements. If text or other content is displayed only after an advertisement is completely downloaded, users may become very frustrated with the owner of the advertisement if the wait time is prolonged. Interstitial displays, such as splash screens which appear in between web page requests and before a web page is actually delivered, also provide advertisement opportunities, but they are often extremely brief, thereby greatly lessening their effect.

Others have addressed the problem of getting advertisements to an end user through the use of screensavers, such as a product commercialized by PointCast, Inc., Sunnyvale, Calif., as described in U.S. Pat. No. 5,740,549 to Reilly, et al. Although the screensaver program approach does appear to be capable of communicating advertisements to some users, there are clearly disadvantages to displaying these advertisements in an area outside of the normal user work area during times of inactivity when a user may typically not be looking at the display. In addition, the extra steps required to install and update such software can be too complicated or cumbersome for some users. Advertisers also have used broadcast e-mails and public postings to send advertisement messages from themselves containing plain text, as well as HTML formatting for more effective display. In general, e-mail messages and public postings containing hyperlinks pointing to additional information are also known, such as described in U.S. Pat. No. 5,790,793. Unfortunately, users often immediately delete unsolicited e-mail messages, as well as those sent from unknown senders.

Outside the Internet, top of mind awareness (TOMA) advertising acquaints the public with advertisers' brand-names, logos, trademarks, etc., through selective infiltration and saturation in the market. The purpose of such advertising is not to compel immediate purchase, but to enhance public awareness of the availability of the product from a particular manufacturer or merchant, so that when shoppers are at the retail markets to make purchases, they will recognize brands and immediately have higher perceived values of those products in relation to like products by other manufacturers or merchants. The key to a TOMA campaign is repetition since the more times that an individual is exposed to a particular brand-name, logo, trademark, etc., the more likely that individual will buy a particular product when making a buying decision in the future. Unfortunately, on the Internet, TOMA advertising is rarely accomplished successfully since, as discussed above, most conventional Internet advertising methods often result in very limited exposure to users. This conclusion is evidenced by the attention brokerage system described in U.S. Pat. No. 5,794,210, which actually teaches a method of compensating users for paying attention to advertisements on the Internet.

There is, therefore, a need for an advertising system for addressing these and other needs and problems.

BRIEF SUMMARY OF THE INVENTION

An advertisement system and method are provided for inserting into an end user communication message a background reference to an advertisement. In some preferred embodiments of the present invention, the background reference causes an advertisement image to be tiled, or watermarked, across an end user screen behind the text of an e-mail message or public posting. A message server inserts the background reference after receiving a message originally sent from an end user originator and before sending the message to be delivered to an end user recipient. When necessary, the message server will convert at least a portion of the message into a proper format, such as HTML, before inserting the background reference to an advertisement, which is preferably selected in accordance with end user recipient demographic information and/or ad exposure statistics. The advertisement itself, often a graphical file, is preferably not transmitted with the message in some preferred embodiments of the invention, but is typically stored at the message server or other location remote from the end user recipient. In some embodiments, the message server will also maintain and refer to records on each end user recipient to allow for selective enablement of background reference insertion and overwriting based upon end user preferences. According to various “non-web” example embodiments, the message server receives an SMTP or NNTP message and transmits an SMTP, POP3 or NNTP message with an HTML portion for a respective HTML-compatible client. In other “web-based” embodiments, the message server transmits the entire message in HTML to be used as a stand-alone web page or as a portion of a larger page employing frames or tables.

Since the advertisement is placed in the background when viewed by a user, it is normally non-clickable, i.e., not a hyperlink to another HTML page. While this novel system of advertising is unusual since a typical user may initially desire, as with conventional banner advertisement, to click on the background image to go to another web page owned by the advertiser for more information or for ordering a product, the user will often be exposed to the tiled advertisement longer, and many times subliminally, while reading the content of the message, and the user may also be initially surprised to see an advertisement in the background of an e-mail message which may be from a known originator, thus increasing the awareness and exposure. Background images may also be very small in comparison to banner advertisements, thus downloading relatively quickly. While the scope of the present invention is also intended to include inserting a reference to any type of background image or graphic, including non-advertisements, the method of inserting a reference to an advertisement is considered particularly useful and beneficial in view of the above unexpected advantages, among others. In addition, Internet service providers, web site owners, e-mail service providers, newsgroup services and other end user communication providers are able to extract revenue for non-obtrusive advertising on 100% of the active screen area while still providing a work area for users to perform desired functions. In addition, this display does not necessarily affect current advertisement banners being displayed. Other features and advantages of various preferred embodiments of the present invention will become apparent to one with skill in the art upon examination of the following drawings and detailed description.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The accompanying drawings incorporated in and forming a part of the specification illustrate several aspects of the present invention, and together with the description, serve to explain the principles of the invention. [0015]
FIG. 1 is a block diagram illustrating physical components of one implementation of the present invention. [0016]
FIG. 2 is a block diagram illustrating one type of end user workstation in accordance with one preferred embodiment of the present invention. [0017]
FIG. 3 is a block diagram illustrating one type of network server in accordance with one preferred embodiment of the present invention. [0018]
FIG. 4 is a flowchart showing general operation steps of the background reference system of the present invention in accordance with one preferred embodiment. [0019]
FIG. 5 is a flowchart showing the operation of one implementation of a background reference insertion process of FIG. 4. [0020]
FIG. 6 is an illustration of selected basic components of an example end user e-mail communication message as sent by an end user originator, in accordance with one preferred embodiment of the present invention. [0021]
FIG. 7 is an illustration of the end user e-mail communication message of FIG. 6 converted completely into HTML for use in a web-based e-mail implementation of one preferred embodiment of the present invention. [0022]
FIG. 8 is an illustration of the message of FIG. 7 with an inserted advertising background reference. [0023]
FIG. 9 is an illustration of a screen display of the message of FIG. 8. [0024]
FIG. 10 is a flowchart showing the general operation of another preferred embodiment of the present invention in a non-web-based, SMTP/POP3 implementation of a background reference system accommodating an e-mail message with an attachment. [0025]
FIG. 11 is an illustration of selected basic components of an example end user e-mail communication message that is not in MIME format and that has an attachment, in accordance with the preferred embodiment of FIG. 10. [0026]
FIG. 12 is an illustration of an example message similar to that of FIG. 11 converted into MIME format. [0027]
FIG. 13 is an illustration of an example message similar to that of FIG. 12 converted into a multipart/alterative part MIME format with an HTML part including a background reference. [0028]
FIG. 14 is an object model diagram showing portions of one implementation of an advertising system in accordance with one preferred embodiment of the present invention. [0029]
FIG. 15 is a flowchart showing a configuration process of the advertising system implementation portion represented by FIG. 14. [0030]
FIG. 16 is a flowchart showing selected e-mail processing steps of the advertising system implementation portion represented by FIG. 14.[0031]
Reference will now be made in detail to the description of the invention as illustrated in the drawings. While the invention will be described in connection with these drawings, there is no intent to limit it to the embodiments disclosed therein. On the contrary, the intent is to cover all alternatives, modifications and equivalents included within the spirit and scope of the invention as defined herein and by the appended claims. [0032]

DETAILED DESCRIPTION OF THE INVENTION

Turning now to the drawings, wherein like reference numerals designate corresponding parts throughout the drawings, FIG. 1 is a block diagram illustrating [0033] physical components 10 of one implementation of the present invention, which has flexibility, expandability, and platform independence. While system configuration can take many forms in accordance with scope of the present invention, the diagram of FIG. 1 illustrates a plurality of end user workstations 11, 12, 13 and 14 directly connected to networks 18 and 19, acceptable examples of which include, among others, local area networks (LANs) and Intranets. Additional workstations 20, 22 are remotely located and in communication with the network 18 through a remote access network 24. Network servers 26, 28, and 30, one or more of which are capable of functioning as a message server to perform the background reference insertion methods in accordance with the present invention, as discussed below, are shown connected to each other through an Internet 32, with conventional routers and switches omitted for clarity, but understood by those reasonably skilled in the art of the present invention. Such network servers are configured to support one or more conventional communication protocols, including, but not limited to, SMTP, POP3, IMAP, NNTP, HTTP, etc. Of course, the elements of FIG. 1 are understood to be representative of multitudes of similarly connected components, and various types of conventional workstations are understood to be connected to the Internet 32 through conventional schemes.
In one application of the [0034] physical components 10, one end user organization owns and maintains the components directly connected to network 18, and another end user organization owns and maintains the components directly connected to network 19. In that application, the network server 28 can be configured to insert background references into end user communications originated and received by any of the workstations 11, 12, 13, 14, 20, 22. For example, if an end user at workstation 20 sends an e-mail message to an end user at workstation 12, such a message could be routed through network server 26, network server 28 for background reference insertion, and then network server 30. Though not necessary, such routing could be prompted by the end user at workstation 12 maintaining an e-mail mailbox on network server 28. In another of the many applications of the physical components 10 included in the scope of the present invention, network server 26 is maintained by an Online Service Provider (OSP) to provide OSP customers using workstations 20, 22 access to the Internet 32, including e-mail mailboxes and access to the web and public messaging. In one example use of such an application, e-mail messages or public postings originated and/or received by an OSP customer would include background references inserted by network server 26, including those from and/or to other customers of the OSP and others outside the OSP, as configured by the OSP. As with the former application, OSP customers may also maintain mailboxes on network server 28. Clearly, these applications are merely examples, and other applications of the physical components 10 are also contemplated such that any network server is capable of functioning as a message server to perform the background reference insertion method of the present invention, as discussed below, without regard to whether mailboxes or user accounts are maintained by the message server.
Refer now to FIG. 2, which is a block diagram illustrating one type of [0035] end user workstation 11, in accordance with one preferred embodiment of the present invention. A local interface 38, such as a conventional computer bus, is shown connected to a variety of components, including a storage unit 40, a processor 42, an input device interface 44 providing an interface to the local interface 38 for a conventional keyboard 46 and mouse 48, a display 50 for displaying information for being viewed by a user, a modem/network interface 55 for providing connectivity to other computers and networks, and memory 95. One example, among others, of an acceptable storage device 40 is a conventional hard drive, which is used for non-volatile storage of programs and other data which are loaded into memory 95 for operation of the workstation 11 and used by processor 42 to control operation of the workstation 11. Such programs (also referred to as applications, systems, software, etc.) typically include, among others, an operating system 96, a browser client 52, an e-mail client 53, and a public posting client 54. Examples of acceptable operating systems 96 include, among others, Microsoft® Windows® and Unix. Examples of acceptable browser clients 52 include, among others, Microsoft® Internet Explorer and Netscape Navigator. One example, among others, of an acceptable e-mail client is Eudora Pro Email v4.0. One example, among others, of an acceptable public posting client 54 is Microsoft® Outlook Express, which also functions as an acceptable e-mail client. Some web browser clients also function as non-web-based newsgroup and e-mail clients, thus also serving as enhanced readers of NNTP and POP3 information. Of course, the scope of the present invention is intended to include, but not be limited to, any client capable of displaying end user information with a definable background from any type of electronic feed, including but not limited to, web pages, e-mail messages, public postings, etc.
Referring back to FIG. 1, one example implementation and application of the present invention includes the [0036] network server 28 functioning as a message server for inserting advertisement background references into end user messages. Refer now to FIG. 3, which shows a block diagram representation of selected elements of one type of network server 28, which is shown including hardware elements similar to those of the example workstation 11 shown in FIG. 2. For example, a local interface 138, such as a conventional computer bus, is shown connected to a variety of components, including a storage unit 140, a processor 142, an input device interface 144 providing an interface to the local interface 138 for a conventional keyboard 146 and mouse 148, a display 150, a modem/network interface 160 for providing connectivity to other computers and networks, and memory 195. One example, among others, of an acceptable storage device 140 is a conventional hard drive, which is used for non-volatile storage of software programs and other data which are loaded into memory 195 for operation of the network server 28 and used by processor 142 to control operation of the network server 28. However, the network server 28 executes software programs (also referred to as applications, systems, software, etc.) which are different from those of the workstations. For example, in accordance with one implementation, software executed by the network server 28 executes a web server 152, e-mail server 153, public posting server 154, such as a newsgroup server, and background reference system 155. In other implementations, network server 28 executes background reference system 155 in combination with one or more of the web server 152, public posting server 154, e-mail server 153, or other end user message server software. In addition, while one implementation of the present invention includes separate background reference system 155 which communicates with one or more end user message server software programs, other implementations include integrated end user message software solutions which directly incorporate the functionality of the background reference system 155.
In addition, the [0037] background reference system 155 of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In one preferred embodiment, the background reference system 155 is implemented in software or firmware that is stored in a memory and that is executed by a suitable instruction execution system. The background reference system 155, which comprises an ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. Examples, among many others, of acceptable software implementation environments include Java, Javascript, C++, etc. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
Refer also to FIG. 4, which is a flowchart showing general operation steps [0038] 300 of the background reference system 155 of the present invention, in accordance with one preferred embodiment. The background reference system 155 receives an end user communication message in step 304, such as, for example, through an SMTP or NNTP gateway from the Internet 32 (FIG. 1), through a POP3 or IMAP mailbox, or through any other communication connection method for intercepting or otherwise accessing an end user communication message sent toward at least one end user recipient from an end user originator. The background reference system 155 determines if the received message is in a format, such as HTML as one example, that can accept a reference to a background, such as an advertising image as one example. If the message is not in such a format, such as plain text as one example, the message is converted into an appropriate format to accept a background reference, as indicated in step 308. If the message is already in such a format, or after the message is converted into such a format in step 308, an appropriate background reference is added to the message, such as through a background reference insertion process 312, an example of one implementation of which is shown in FIG. 5 and discussed below. Subsequently, as indicated in step 314, the end user message is made available for delivery to one or more end user recipients. In some embodiments and implementations of the present invention, this step includes sending and actually delivering the message to one more end users in user dependent formats.
Refer now to FIG. 5, which shows the operation of one implementation of the background [0039] reference insertion process 312 of FIG. 4. The implementation of FIG. 5 is related to an advertisement system, but it should be understood that the present invention includes inserting references to any type of background into end user messages. In addition, included in the scope of the present invention are practically all technologies through which a background, tiled or not tiled on an end user recipient's screen, is designated for an end user communication message, including client-based solutions and future technologies for accomplishing the described functions. Nonetheless, it should be clear that while the scope of the present invention is also intended to include inserting a reference to any type of background image, graphic, etc., including non-advertisements, the method of inserting a reference to an advertisement is considered particularly useful and beneficial, as discussed above.
According to the implementation of FIG. 5, it is first determined at [0040] step 404 whether the message already includes a background reference. While some embodiments of the present invention include determining if any type of background reference is specified, including a mere designation of a color, other embodiments include checking only for a designation of a separate image file as a background. In addition, some embodiments will include making this determination only for messages previously determined in step 306 to already be in a format that can accept a background reference since such messages are more likely to already include a background reference. If the message already includes a background reference, step 406 determines if an approval configuration specifies whether the background reference can be overwritten with a new background reference. If the approval configuration indicates that background references are not to be overwritten for a particular message, step 412 indicates that the background reference insertion process 312 terminates without overwriting the existing background reference. An approval configuration file is maintained in one embodiment of the present invention in order to enable end user recipients to configure the background reference system 155 (FIG. 3) on whether or not to overwrite existing background references in messages received by them. In other embodiments, steps 404 and/or 406 are omitted, whereby there is automatic overwriting of all or no existing background references. Furthermore, the ordering of steps in the various flowcharts of the present invention are not intended to limit the scope of the present invention with respect to order of operation since other embodiments include varying the orders of the steps. As one example, in some embodiments, steps 404, 406 and 412 are instead executed after a message is received and before format determination is made in step 306. In still other embodiments, a general approval determination is included before format determination in order to determine if a particular end user recipient has approved any background reference insertions, regardless of whether any background references already exist.
In accordance with the implementation shown in FIG. 5, when the [0041] background reference system 155 determines that an existing background reference may be overwritten in step 406, or if it is determined that there is no background reference specified in step 404, then further determinations are made as to which advertisement should be referenced by a new background reference to be inserted (or overwritten if already present) into the message. Based on a determination in step 408, advertisements may be selected by the background reference system 155 based on available demographic information for a particular end user recipient (step 414) and/or on advertiser and advertisement exposures (step 416). In a web-based “free” e-mail implementation, acquisition of demographic information is required before the e-mail account is provided to a user. If demographic information is not available or is otherwise inconclusive for targeted advertisements, commitments to advertisers may drive the selection from a pool of available advertisers. Of course, as advertisements are selected based on demographic categories or exposure requirements, records are maintained for future selection and reporting purposes. There are many conventional demographic and advertisement pool processing systems currently available and understood by those reasonably skilled in the art of the present invention. Although only two types of advertisement selection criteria have been discussed, it should be understood that other criteria can be used without departing from the spirit of the present invention. Of course, advertisements should be constructed in color and design to not interfere with end user recipients being able to read the foreground message text.
Once an appropriate advertisement has been selected in [0042] steps 414 or 416, a background reference to that advertisement is inserted into the message at step 418. In one implementation of the present invention in HTML, a background tag, such as <body background=“AdvertisementFile”>, is inserted into an HTML portion of a message, where “AdvertisementFile” is the name of a stored advertisement file. The advertisement file itself, often a graphical file, is preferably not transmitted with the message in some preferred embodiments of the invention, but is typically stored at the message server or other location remote from the end user recipient. In web-based embodiments, the background file may be co-located, and in a similar storage directory or folder, with the web page message or located remotely from the web page message. If the background file is co-located with the web page message in the same storage directory or folder, the background reference need only include the name of the background file. Otherwise, preamble directory names or full URL addresses beginning with “http://www”, etc., are necessary since the background file can be located anywhere on the Web in some embodiments.
In some web-based embodiments where messages are stored on a network server after viewing by an end user recipient, the background reference insertion steps of the present invention are repeated each time the end user views the message to show the end user a different background each time the message is viewed. In addition, in other embodiments, regardless of whether those embodiments are web-based, the actual background file referenced by the background reference is changed so that the end user recipient views a different background when the message is viewed subsequently. In still other embodiments, the URL is not an actual address of a known file, but a call to a separate server program, or script, to supply an unknown particular file chosen by the server program. Since the particular file supplied will automatically vary in some embodiments, end user recipients see different backgrounds each time the message is viewed. While apparently never having been associated with the insertion of background references into end user communication messages, some methods of calling a server program, or script, for receiving an unknown particular file are conventional and would be understood by those reasonably skilled in the art of the present invention, and are included within the scope of the present invention. [0043]
Some other embodiments include transmitting the advertisement file as an attachment along with the message for storage on an end user recipient workstation. Of course, configuration or knowledge of the end user recipient downloading location would be necessary (e.g., c:\downloadfolder\) in constructing the proper address in the background reference of the downloaded advertisement, which would only need to be downloaded once in embodiments tracking which advertisements are downloaded to which end user recipients and selectively sending only those advertisements that have not previously been sent to particular end user recipients. [0044]
FIG. 6 shows an illustration of selected basic components of an example end user e-mail communication message as sent by an end user originator, in accordance with one preferred embodiment of the present invention. Additional conventional header information is not shown for purposes of clarity, as is also often selectively the case with conventional e-mail clients. Referring also back to FIG. 4, if a message represented by the example message of FIG. 6 is received in [0045] step 304 of FIG. 4, it would be subsequently determined in step 306 that the message is not in format that can accept a background reference since the message is in plain text. Consequently, in step 308, the message would be converted into an appropriate format, such as HTML, an example of which is shown in FIG. 7. If, instead, a message represented by FIG. 7 was initially received at step 304, i.e., one which includes an HTML portion, as an example, it would already be in an appropriate format, and step 308 would not be executed. Subsequently, as discussed above with respect to background reference insertion process 312, a background reference is inserted into the message, an example of which is shown in FIG. 8. The example background reference shown in FIG. 8 is <body background=“http://www.exampledomain.com/tkhr_ad.jpg”>. As discussed above, in some web-based embodiments storing advertisements in the same directory or folder as web page messages, the preamble can be omitted; thus, in the example shown in FIG. 8, the preamble “http://www.exampledomain.com/” could then be omitted.
FIG. 9 shows an illustration of a screen display of the example message of FIG. 8, where a tiled background image of a diagonal “www.tkhr.com” is shown as an example. Again, this image is not “clickable” since it is in the background of the screen, but e-mail messages and other end user communications can be branded, or watermarked, with virtually any background image as shown. In one implementation of a web-based e-mail system, the entire browser viewing area is used for displaying the message and background image, thus control buttons such as reply, reply all, forward, delete, close, download attachment, etc. are on another screen and are accessible by a back button on a browser, as is conventionally available in other web-based e-mail systems. In another implementation, the information shown in FIG. 9 is placed in a frame or table to share the browser viewing area with one or more other frames and/or tables containing controls. In yet another implementation, control buttons and additional information is inserted into the message itself. Of course, traditional banner advertisements may still be displayed in addition to the background. [0046]
Refer now to the FIG. 10, which is a flowchart showing general operation steps [0047] 500 of another preferred embodiment of the present invention in a non-webbased, SMTP/POP3 implementation of a background reference system accommodating an e-mail message with an attachment. This example is useful for end user recipients with MIME-compatible and HTML-compliant e-mail clients. In the example shown, after receiving a message in step 504, it is determined if the message is in a conventional MIME format in step 506. In this preferred embodiment, this determination can be performed by searching the message for the text “MIME-Version”, for example, in a header field. Although this is the search criteria in this preferred embodiment, it should be understood that the scope of the present invention includes any search criteria that may be used in identifying whether a message is MIME formatted. If the message is not in a MIME format, it is checked for attachments included within the text of the message and converted into a MIME format in step 908. One such type of attachment is the conventional UUENCODED attachment, which is delineated by keywords “begin” and “end”; hence, in this preferred embodiment, the message is checked for characteristic placement of these keywords. Once converted, the message will include a “MIME-Version” header field, and any attachment will be converted into a MIME attachment portion. One example attachment conversion process includes converting from UUENCODE to base64, which is well defined and documented in Request for Comments (RFC) 2045, which is considered understood by those skilled in the art of the present invention and which is herein incorporated by reference. The converted attachments will be added as parts to the message, including the addition of separators as discussed in more detail in RFC 2045.
Next, a MIME multipart/alternative part with HTML is added in [0048] step 510. The multipart/alterative designation offers an alternative version of the text of the message such that clients that support HTML can display it, and clients that do not can show the other alternative, which is usually plain text. The HTML part is essentially an HTML version of the e-mail message, the conversion to which would be understood by those reasonably skilled in the art of the present invention as similar to that discussed above with respect to step 308 (FIG. 4). If the message received in step 506 is already in a MIME format, it is determined in step 511 whether the message already contains an HTML part, such as through searching for an appropriately located string “text/html”. If not, step 510 is executed as discussed previously. If so, as well as after step 510 is executed in the other two circumstances discussed previously, a background reference insertion process is executed in step 512, which is similar to the background reference insertion process 312 shown in FIG. 5. As with the embodiment discussed in FIGS. 4 and 5, the ordering of steps is changed in other embodiments, and previous determinations may affect subsequent determinations. For example, if it is known through steps 508 or 511 that the message does not contain an HTML part, steps 404, 406, and 412 need not be executed since it would already be known that no background reference is specified.
FIG. 11 is an illustration of selected basic components of an example end user e-mail communication message that is not in MIME format and that has an attachment, in accordance with the preferred embodiment of FIG. 10. The attachment, “clouds.bmp”, is shown in a UUENCODED format between, and including, the words “begin” and “end.” FIG. 12 is an illustration of an example message similar to that of FIG. 11 converted into MIME format with the attachment in base[0049] 64 encoding. FIG. 13 is an illustration of an example message similar to that of FIG. 12 converted into a multipart/alterative part MIME format with an HTML part including a background reference. The HTML part begins with <HTML> and ends with </HTML>, and the example background reference is shown as <body background=“http://www.exampledomain.com/tkhr_ad.jpg>. In an HTML-compatible, MIME-compliant e-mail client, the “clouds.bmp” attachment would be downloaded to the end user recipient's workstation, and the e-mail message would be displayed with a tiled background of the image file located at the referenced address. The “clouds.bmp” file is not intended to be the background file in this preferred embodiment, but as discussed above, other embodiments include sending the background file along as an attachment to the message. Thus, if the “clouds.bmp” file were the intended background file, and if it were known that the download directory on the end user recipient workstation was “c:\download”, then the background reference would be similar to <body background=“c:\download\clouds.jpg”>.
Refer now to FIG. 14, which is an object model diagram [0050] 600 showing portions of one implementation of an advertising system in accordance with one preferred embodiment of the present invention. The method employed by the diagram 600, also known as a Rose model, is a unified modeling language, (UML), a standardized way of representing objects and their relationships to each other. In the diagram 600, a hollow arrow “inherits” (a first object inherits from a second object if the first object takes on the properties and behavior of the second object, i.e., the first object contains the properties and methods of the second object), a dotted line with an arrow is a dependency (using an object internally or during a function call as a parameter) and a straight solid line is an “association” (using an object internally without exposing it). Boxes shown in the diagram are object classes, which include member variables and methods. The letter “Z” merely signifies that the element is an object, i.e., standing for “the.”
Thus, a [0051] ZVendorSpecificEmailInterface 610 inherits from a ZEMailInterfaceBase 612; a ZVendorSpecificDemographicInterface 614 inherits from a ZDemographicInterfaceBase 616; ZVendorSpecificApprovalInterface 618 inherits from a ZApprovalInterfaceBase 620; and a ZHTMLEMail 622 inherits from both a ZEMailBase 624 and a string 626. A ZWatermarker 628 has a dependency on the ZEMailInterfaceBase 612, the ZDemographicInterfaceBase 616, and the ZApprovalInterfaceBase 620, as well as an association with the ZHTMLEMail 622 and the ZEMailBase 624. The ZEMailInterfaceBase 612 also has dependencies on the ZHTMLEMail 622 and the ZEMailBase 624. The ZEMailBase 624 has dependencies on the string 626 and a ZAttachment 632, as well as associations with a list<String> 630 and a list<ZAttachment> 634, both of which are aggregates of a list<Type> 636 and themselves have dependencies on the string 626 and ZAttachment 632, respectively. The ZApprovalInterfaceBase 620 has a dependency on the ZEMailBase 624. The list<Type> 636 is a template class corresponding to a standard template library for dynamic compilation. A template class is a class which, at compile time, takes parameters passed to it and replaces those parameters internally. The ZEMailBase 624 contains Zattachment 632 and string 626 to store its contents.
Member variables and methods for the objects of FIG. 14 include the following, with colons “:” meaning “type” for members and “return type” for methods: [0052]

ZAttachment

632

MEMBERS [0053]
m_ulLength: Long=0 [0054]
m_pBinaryData: void*=NULL [0055]
m_Name: String=“”[0056]
METHODS [0057]
ZAttachment ( ) [0058]
GetData ( ): void* [0059]
PutData (pData: void*=default, lDataLength long=default): [0060]
enumSuccessError [0061]

ZEMailBase

624

MEMBERS [0062]
m_RecipientList: list<String>[0063]
m_CarbonCopyList: list<String>[0064]
m_Date: Date [0065]
m_sSender: String [0066]
m_sSubject: String [0067]
m_sBody: String [0068]
m_AttachmentList: list<ZAttachment>[0069]
m_IReferenceID: Long=0 [0070]
m_sMailBoxName: String [0071]
METHODS [0072]
GetRecipientCount ( ): Long [0073]
GetRecipient (lIndex: Long): String [0074]
GetCarbonCopyCount ( ): Long [0075]
GetCarbonCopy (lIndex: Long): String [0076]
GetDate ( ): Date [0077]
GetSender ( ): String [0078]
GetSubject ( ): String [0079]
GetBody ( ): String [0080]
GetAttachmentCount ( ): Long [0081]
GetAttachment ( ): ZAttachment [0082]
GetReferenceID ( ): Long [0083]
GetMailBoxName ( ): String [0084]

ZHTMLEMail

622

METHODS [0085]
ZHTMLEMail (EMailBaseToCopy: ZEMailBase&) [0086]
Construct (EMailBaseToCopy: ZEMailBase&): enumSuccessError [0087]
AddBackground (sBackgroundReference: String): enumSuccessError [0088]

ZWatermarker

628

MEMBERS [0089]
m_pEMailInterfaceBase: ZEMailInterfaceBase*=NULL [0090]
m_pDemographicIInterface: ZDemographicInterface*=NULL [0091]
m_pApprovalInterface: ZApprovalInterfaceBase*=NULL [0092]
METHODS [0093]
PutEmailInterface (pEMailIInterface: ZEMailIInterfaceBase*): enumSuccessError [0094]
PutDemographicInterface (pDemographicInterface: ZDemographicInterfaceBase*) : enumSuccessError [0095]
PutApprovalInterface (pDemographicInterface: ZApprovalInterfaceBase*=default): enumSuccessError [0096]
ProcessEMail (IReferenceID: Long): enumSuccessError [0097]
ConvertEMail ( ): enumSuccessError [0098]

ZEMailInterfaceBase

612

METHODS [0099]
Register (pWatermarker: ZWatermarker*): enumSuccessError [0100]
GetEMail (IReferenceID: DataType): ZEMailBase [0101]
PutEMail (HTMLEMail: ZHTMLEMail&): enumSuccessError [0102]

ZDemogarhicInterfaceBase

616

METHOD [0103]
GetBackgroundReference (MailBoxName: String): String [0104]

ZApprovalInterfaceBase

620

METHOD [0105]
IsApproved (rEMailBase: const ZEMailBase&=default): BOOL [0106]
Each of the vendor specific objects, including [0107] ZVendorSpecificEmailInterface 610, ZVendorSpecificDemographicInterface 614, and ZVendorSpecificApprovalInterface 618, are constructed to interface with specific vendor systems. Thus, such objects may be interchanged and used as necessary when working with different systems. Furthermore, the ZVendorSpecificEmailInterface 610 is replaced with a ZVendorSpecificNewsgroupInterface for NNTP interfacing, as well as any other type of end user messaging system needed.
Refer also to FIG. 15, which is a flowchart showing a [0108] configuration process 700 of the advertising system implementation portion represented by FIG. 14. When configuration process 700 software is compiled, a determination is made regarding the operating system environment, such as Windows or Unix. After that determination is made, the compiled software runs according to the operating system distinctions shown, but the determination is made only once. Thus, after it is determined that Unix or Windows is the operating environment for a particular implementation, all of the illustrated operating system determinations 704, 718, 726, and 734 are already determined. After the process 700 starts in step 702, a manual process, if Unix is the operating system, three daemons are manually started in steps 706, 708, and 710, including a vendor specific email interface daemon, a vendor specific demographic interface daemon, and a vendor specific approval interface daemon, respectively.
Subsequently, a watermarker container program is manually started in [0109] step 712. The watermarker container program then instantiates, creates an instance of, ZWatermarker 628 in step 714. Subsequently, in step 716, the watermarker container program creates an instance of the ZEMailInterfaceBase 612, after which either a vendor specific EMailInterface DLL is loaded (step 720) or communication is established to a vendor specific EMailInterface daemon (step 722), depending on the operating system in which the process 700 software is compiled, as discussed above. Then, in step 724, the watermarker container program creates an instance of the ZApprovalInterfaceBase 620, after which either a vendor specific ApprovalInterface DLL is loaded (step 728) or communication is established to a vendor specific ApprovalInterface daemon (step 730), depending on the operating system in which the process 700 software is compiled, as discussed above. In step 732, the watermarker container program creates an instance of the ZDemographicInterfaceBase 616, after which either a vendor specific DemographicInterface DLL is loaded (step 736) or communication is established to a vendor specific DemographicInterface daemon (step 738), depending on the operating system in which the process 700 software is compiled, as discussed above.
The watermarker container program then passes the [0110] ZApprovalInterfaceBase 620 to the ZWatermarker 628 in step 740, which calls the PutApprovalInterface method in the ZWatermarker 628. The watermarker container program passes the ZEMailInterfaceBase 612 to the ZWatermarker 628 in step 742, which calls the PutEMailInterface method in the ZWatermarker 628, which then prompts the ZWatermarker 628, in step 744, to call ZEMailInterfaceBase::Register to enable the ZEMailInterfaceBase 612 to trigger work. In step 746, the watermarker container program passes the ZDemographicInterfaceBase 616 to the ZWatermarker 628, which calls the PutDemographicInterface method in the ZWatermarker 628. Although the watermarker container program is then finished initializing, the process 700 waits in step 748 for the ZEMailInterfaceBase 612 to trigger work in response to receiving an e-mail message as discussed below.
Refer also to FIG. 16, which is a flowchart showing selected e-mail processing steps [0111] 800 of the advertising system implementation portion represented by FIG. 14. After an e-mail message is received in step 802, through the ZVendorSpecificEmailInterface 610, the ZEMailInterfaceBase 612 calls, in step 804, the ZWatermarker::ProcessEmail method in the ZWatermarker 628 with an EMail reference ID (identification number). Step 802 may include being notified by an external brand-specific e-mail server program through the ZVendorSpecificEmailInterface 610 that a new e-mail message is in a particular mailbox. In other embodiments, the ZVendorSpecificEmailInterface 610 polls the external e-mail server program to determine when a new e-mail message is available. When the ZWatermarker 628 is available in step 806, it retrieves the e-mail message from the ZEMailInterfaceBase 612 as a ZEMailBase 624 object using the previously supplied reference ID. The ZEMailBase 624 is a data container that parses the received e-mail message so that the ZWatermarker 628 can operate on e-mail messages regardless of format. Subsequently, in step 808, the ZWatermarker 628 passes the ZEMailBase 624 object to the ZApprovalInterfaceBase:IsApproved method of the ZApprovalInterfaceBase 620, which examines the ZEMailBase 624 object to determine if further processing is necessary, as determined by a separate approval system with which the ZVendorSpecificApprovalInterface 618 interfaces. As discussed above, this separate approval system functions in accordance with an approval configuration for each end user recipient which, in some embodiments, determines if an existing background reference exists and if it is to be overwritten. In other embodiments, certain users may be configu red to have all background references overwritten, and in other embodiments, the insertion of background references is approved based on other demographic or message content factors. As determined in decision step 810, if the ZApprovalInterfaceBase:IsApproved method returns false, the process 800 essentially terminates and waits for another incoming e-mail message in step 812. Otherwise, processing continues in step 814.
In [0112] step 814, the ZWatermarker 628 retrieves the MailBoxName from the ZEMailBase 624 object. Subsequently, in step 816, the ZWatermarker 628 begins the process of obtaining an appropriate background reference by calling the ZDemographicInterfaceBase::GetBackgroundReference method of the ZDemographicInterfaceBase 616 and supplying the MailBoxName. Then, in step 818, separate demographic software, to which an interface is provided through ZVendorSpecificDemographicInterface 614, determines the appropriate background reference for the supplied MailBoxName. In step 820, the ZWatermarker 628 converts the ZEMailBase 624 object to a ZHTMLEMail 622 object with a provided copy constructor. Since the ZHTMLEMail 622 inherits from the ZEMailBase 624, the ZHTMLEMail 622 has access to all of the data and structure of the ZHTMLEMail 622 object for making an HTML copy. As discussed above, conversion to HTML includes a complete conversion for webbased applications, and conversion of a portion of the e-mail message for non-web-based applications. In addition, attachments are also handled at this point as discussed above, as well as the creation of control buttons for general control and for downloading any attachments through server scripting in web-based applications. Then, in step 822, the ZWatermarker 628 calls the ZHTMLEMail::AddBackground method of the ZHTMLEMail 622 with the appropriate background reference, which is inserted into the HTML of the ZHTMLEMail 622 object. In step 824, the ZWatermarker 628 returns the newly formatted ZHTMLEMail to the ZEMailInterfaceBase by calling the PutEmail method, which includes placing the ZHTMLEMail 622 object in an appropriate place for making the message available for delivery to an end user recipient. Subsequently, the process 800 waits for the next e-mail message in step 812.
In other embodiments of the present invention, the RecipientList and CarbonCopyList variables of the [0113] ZEMailBase 624 object for each e-mail message are used to generate associational demographic information. In other words, marketing conclusions can be drawn about other primary recipients and carbon copy recipients based on demographic information of one intended end user recipient. Thus, this information is useful and easily tracked and reported in accordance with the present invention.
In concluding the detailed description, it should be noted that it will be obvious to those skilled in the art that many variations and modifications can be made to the preferred embodiment without substantially departing from the principles of the present invention. All such variations and modifications are intended to be included herein within the scope of the present invention, as set forth in the following claims. [0114]

Claims

We claim:

1. An advertising method for inserting a background reference to a stored advertisement into an end user communication message in a communications network, said method comprising the steps of:

receiving an end user communication message at a first site on a communications network;

inserting into said end user communication message a background reference to a stored advertisement; and

transmitting said end user communication message with said background reference to a second site on the communications network.

2. The method as claimed in claim 1, wherein said background reference is operative for enabling background tiling of said advertisement at said second site.

3. The method as claimed in claim 1, wherein said end user communication message includes an Internet e-mail message.

4. The method as claimed in claim 1, wherein said end user communication message includes a public posting.

5. The method as claimed in claim l, further comprising a step of transforming said end user communication message into hypertext markup language (HTML), and wherein said transmitting step includes transmitting said end user communication message in a web-based e-mail system to a web browser at said second site.

6. The method as claimed in claim 1, wherein said transmitting step includes transmitting said end user communication message in a post office protocol (POP) format.

7. The method as claimed in claim 1, wherein said inserting step includes selecting the stored advertisement based on user demographic information.

8. The method as claimed in claim 1, wherein said inserting step includes selecting the stored advertisement based on advertisement exposure for a pool of advertisers.

9. The method as claimed in claim 1, wherein said inserting step includes inserting a hypertext markup language (HTML) background reference tag into the end user communication message.

10. The method as claimed in claim l, wherein said stored advertisement is stored at the first site.

11. The method as claimed in claim 1, wherein said stored advertisement is stored at a site remote from said second site, wherein said background reference includes a file address remote from said second site.

12. The method as claimed in claim 1, wherein said stored advertisement is a graphical image file.

13. The method as claimed in claim 1, wherein said inserting step includes:

determining whether said end user communication message is in a format capable of operatively accepting said background reference; and

converting said end user communication message into a format capable of operatively accepting said background reference responsive to determining that said message is not in a format capable of operatively accepting said background reference.

14. The method as claimed in claim 13, wherein said determining step includes a step of determining whether said end user communication message is in multipurpose Internet mail extensions (MIME) format.

15. The method as claimed in claim 13, wherein said converting step includes a step of converting said end user communication message into multipurpose Internet mail extensions (MIME) format.

16. The method as claimed in claim 1, further comprising the steps of:

first determining whether said end user communication message in said receiving step is in a format capable of operatively accepting a background reference;

second determining whether said end user communication message contains a standard generalized markup language (SGML) part responsive to determining that said end user communication message is in a format capable of operatively accepting a background reference in said first determining step; and

adding an SGML part to said end user communication message responsive to determining that said end user communication message does not contain an SGML part;

17. The method as claimed in claim 16, wherein said SGML part includes hypertext markup language (HTML).

18. The method as claimed in claim 16, further comprising the steps of:

third determining whether said end user communication message already contains a background reference responsive to determining that said end user communication message is in a format capable of operatively accepting a background reference in said second determining step; and

inserting a background reference responsive to determining that said end user communication message does not contain a background reference in said third determining step.

19. The method as claimed in claim 18, further comprising the steps of:

fourth determining whether a configuration enables an existing background reference to be overwritten responsive to determining in said third determining step that said end user communication message already contains a background reference; and

overwriting a background reference responsive to determining in said fourth determining step that the configuration enables the existing background reference to be overwritten.

20. The method as claimed in claim 15, further comprising a step of adding an SGML part to said end user communication message converted into MIME format.