WO2000063771A1 - Systeme de gestion d'affichage electronique multi-utilisateurs - Google Patents

Systeme de gestion d'affichage electronique multi-utilisateurs Download PDF

Info

Publication number
WO2000063771A1
WO2000063771A1 PCT/US2000/010260 US0010260W WO0063771A1 WO 2000063771 A1 WO2000063771 A1 WO 2000063771A1 US 0010260 W US0010260 W US 0010260W WO 0063771 A1 WO0063771 A1 WO 0063771A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic
sign
message
user
display
Prior art date
Application number
PCT/US2000/010260
Other languages
English (en)
Inventor
Marion Meier
Original Assignee
Signature Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Signature Technologies, Inc. filed Critical Signature Technologies, Inc.
Priority to AU44641/00A priority Critical patent/AU4464100A/en
Publication of WO2000063771A1 publication Critical patent/WO2000063771A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G06F3/147—Digital output to display device ; Cooperation and interconnection of the display device with other functional units using display panels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q99/00—Subject matter not provided for in other groups of this subclass
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09F—DISPLAYING; ADVERTISING; SIGNS; LABELS OR NAME-PLATES; SEALS
    • G09F9/00—Indicating arrangements for variable information in which the information is built-up on a support by selection or combination of individual elements
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00—Aspects of data communication
    • G09G2370/02—Networking aspects
    • G09G2370/027—Arrangements and methods specific for the display of internet documents
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2380/00—Specific applications
    • G09G2380/06—Remotely controlled electronic signs other than labels

Definitions

  • the invention is generally related to electronic signs, and in particular to the generation, scheduling and display of messages on electronic signs.
  • Electronic signs are used in a multitude of applications to display informational and/or entertainment messages such as announcements or advertisements to persons viewing the signs.
  • electronic signs are often used in public facilities such as airports and train stations to display arrival and departure information to travelers, and are used on roads to provide traffic information to drivers.
  • Other concerns such as hotels, malls, retail stores, supermarkets, theaters, convention centers, sports facilities, restaurants, bars, casinos, and the like, may also utilize electronic signs, e.g., to advertise upcoming events or specials, or to provide informational messages to customers and/or potential customers.
  • Electronic signs are often located either indoors or outdoors, and typically in public places where large numbers of relevant viewers can view the signs.
  • a number of different display technologies have been developed, including incandescent lights, light emitting diodes (LED's), liquid crystal displays (LCD's), cathode ray tubes (CRT's) and plasma displays (among others).
  • Electronic signs can significantly vary in display capability.
  • electronic signs can be as simple as small monochrome 7-segment LED or LCD displays capable of displaying only a few digital characters at a time.
  • Electronic signs can also be as complex as large full-color billboard-type displays capable of displaying animation and full-motion video, such as Sony JumboTron displays found in locations such as stadiums and arenas, as well as in Times Square in New York City.
  • An electronic sign is typically controlled by a sign controller implemented as a dedicated electronic controller or a general purpose computer running sign control software, and interfaced with the sign through a wired or wireless interface.
  • a sign controller implemented as a dedicated electronic controller or a general purpose computer running sign control software, and interfaced with the sign through a wired or wireless interface.
  • an operator is capable of creating/editing messages, schedule messages, and perform maintenance functions for a sign via a sign controller.
  • multiple signs may be controlled by a single device such as a server, and connected via a wired or wireless network.
  • the signs may be owned by the same party, or may be owned by different parties and managed by a single entity contracted by the parties to manage their signs.
  • Some electronic signs are used exclusively by their owners to display messages such as announcements and/or advertisements related solely to the owners' interests.
  • Generating revenue from electronic signs can be problematic due to the difficulties involved in matching potential advertisers with message display service providers — often quantified in terms of the "transactional costs" or overhead associated with contracting for the display of an advertisement on a particular electronic sign.
  • a potential advertiser in New York might wish to run an advertisement on an electronic sign in Las Vegas.
  • the potential advertiser may not know where the best location to run the advertisement in Las Vegas would be, or if a particular location is identified, who is the owner of a sign at that location.
  • the advertiser would contact an advertising agency in New York, who would then attempt to locate and contact another agency in Las Vegas that works with one or more providers to assist in locating a desirable sign and handling the transaction.
  • the Las Vegas agency often with assistance from the New York agency, would typically produce the advertisement in the format required for the particular sign, and would handle the contractual, scheduling and monetary issues as required to ensure that the advertisement is displayed as agreed and the message display service provider is compensated accordingly.
  • the invention addresses these and other problems associated with the prior art by providing an apparatus, program product, and method of controlling an electronic sign in which an electronic communications link in a sign management system is used to accept message requests from a plurality of users.
  • the message requests received over the electronic communications link which are associated with selected messages and selected times to display those messages, may then be processed by the sign management system to generate control signals suitable for controlling the display of such messages at the appropriate times.
  • a sign management system may be coupled to a public network such as the Internet to permit users that are completely independent of a message display service provider (as well as independent of one another) to request that specific messages be displayed on an electronic sign controlled by that provider.
  • a public network such as the Internet
  • an image capture device positioned to view an electronic sign
  • incorporation of an image capture device could permit, for example, a user to view a real-time image of an electronic sign during the process of selecting among multiple available signs.
  • a user could be provided with proof that a message was in fact displayed on an electronic sign by providing a captured image of the electronic sign during display of the message.
  • FIGURE 1 is a block diagram of a sign management system consistent with the invention.
  • FIGURE 2 is a block diagram of a hardware platform for a server computer from the sign management system of Fig. 1.
  • FIGURE 3 is a block diagram illustrating the primary software components in a server computer and a user computer in the sign management system of Fig. 1.
  • FIGURE 4 is a block diagram of a computer display from a user computer in the sign management system of Fig. 1, illustrating the display of a message request home page in a browser window.
  • FIGURE 5 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during selection of a sign.
  • FIGURE 6 is a block diagram illustrating a HTML document utilized during the sequence of operations of Fig. 5.
  • FIGURE 7 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during creation or editing of a message.
  • FIGURE 8 is a flowchart illustrating the program flow of a message editor application executed by a user computer in the sign management system of Fig. 1.
  • FIGURE 9 is a block diagram illustrating a message editor window utilized by the message editor application of Fig. 8.
  • FIGURE 10 is a block diagram of a message record data structure suitable for use in the sign management system of Fig. 1.
  • FIGURE 11 is a block diagram of a sign record data structure suitable for use in the sign management system of Fig. 1.
  • FIGURE 12 is a block diagram of an order record data structure suitable for use in the sign management system of Fig. 1.
  • FIGURE 13A is a flowchart illustrating the program flow of the convert message routine referenced in Fig. 8.
  • FIGURE 13B is a flowchart illustrating the program flow of the create simulation routine referenced in Fig. 8.
  • FIGURE 14 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during scheduling of a message.
  • FIGURES 15A and 15B are block diagram illustrating HTML documents utilized during the sequence of operations of Fig. 14.
  • FIGURE 16 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during selection of a proof mode.
  • FIGURE 17 is a block diagram illustrating a HTML document utilized during the sequence of operations of Fig. 16.
  • FIGURE 18 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during selection of payment.
  • FIGURES 19A, 19B and 19C are block diagrams illustrating HTML documents utilized during the sequence of operations of Fig. 18.
  • FIGURE 20 is a flowchart illustrating the sequence of operations performed in the sign management system of Fig. 1 during handling of a submitted order.
  • FIGURE 21 is a flowchart illustrating the sequence of operations performed by the order verification module in the sign manager of Fig. 3.
  • FIGURE 22 is a flowchart illustrating the sequence of operations performed by the monitoring & approval module in the sign manager of Fig. 3.
  • FIGURE 23 is a flowchart illustrating the sequence of operations performed by the scheduler module in the sign manager of Fig. 3.
  • FIGURE 24 is a flowchart illustrating the sequence of operations performed by the proof of display module in the sign manager of Fig. 3.
  • FIGURE 25 is a block diagram of an alternate, distributed sign management system consistent with the invention.
  • FIGURE 26 is a flowchart illustrating the sequence of operations performed to handle a message request in the sign management system of Fig. 25. Detailed Description
  • Fig. 1 illustrates a sign management system 10 consistent with the invention.
  • Sign management system 10 is principally used to electronically interface one or more electronic signs (e.g., electronic signs 12, 14 and 16, owned and/or operated by one or more message display service providers) with a plurality of users, e.g., coupled to sign management system 10 through one or more user computers 18, 20, 22.
  • electronic signs e.g., electronic signs 12, 14 and 16, owned and/or operated by one or more message display service providers
  • Each electronic sign 12, 14, 16 typically includes a dedicated sign controller 24, 26, 28 that is configured to operate the electronic sign in any of several manners known in the art.
  • Each controller 24-28 may be, for example, an embedded controller designed specifically for its associated electronic sign, or a general purpose computer executing software that is specifically tailored for the associated electronic sign.
  • Various electronic communications links may be used to interface an electronic sign to its dedicated controller, including wired or wireless links, dial-up links, network links, etc.
  • each electronic sign may be considered to include practically any information display device, other than a requesting user's computer, that is capable of being viewed by the intended audience of a particular message.
  • Each electronic sign may be implemented using any number of known display technologies, including
  • sign management system 10 is principally implemented using one or more server computers (e.g., server computers 30, 32) interfaced via electronic communications links between user computers 18-22 and electronic signs 12-16.
  • server computers e.g., server computers 30, 32
  • each server computer and each user computer can be a public link, e.g., over a public communications network such as the Internet 34 (as with user computers 18 and 20), or over a private or proprietary link, e.g., direct or dial-up link 38 between server computer 32 and user computer 22.
  • a public link e.g., over a public communications network such as the Internet 34 (as with user computers 18 and 20), or over a private or proprietary link, e.g., direct or dial-up link 38 between server computer 32 and user computer 22.
  • each server computer and each electronic sign can be a public link (as illustrated by sign controller 28), or a private or proprietary link, e.g., links 36 between server computer 30 and sign controllers 24 and 26.
  • the electronic communications links between server computers in distributed applications where more than one server computer is utilized may also be public (as with server computers 30, 32) or private (not shown in Fig. 1).
  • each electronic communications link between server computers 30,32 sign controllers 24-28 and user computers 18-22 may be physically implemented using any known wired or wireless communications mediums, including but not limited to direct cables, radio frequency (RF) transmissions, analog or digital dial-up lines (e.g., POTS, ISDN, xDSL, or broadband cable), infrared (IR) transmissions, satellite transmissions, computer network cables, etc., and combinations thereof.
  • RF radio frequency
  • analog or digital dial-up lines e.g., POTS, ISDN, xDSL, or broadband cable
  • IR infrared
  • one or more image capture devices 40, 42 may also optionally be interfaced with sign management system 10, with each coupled to a server computer through either a private link (e.g., via direct cable 44 for image capture device 40) or a public link (e.g., as with image capture device 42).
  • Each image capture device which may be implemented, for example, using any commercially-available digital or analog still or video camera, is typically positioned relative to an associated electronic sign such that the display of messages on the electronic sign can be viewed through the image capture device.
  • An image capture device may be located at a fixed location, with a fixed focus and field of display, or can have a varying field of display controllable by the server computer.
  • an image capture device may be integrated with additional communication electronics, e.g., to provide the electronic interface with a server computer, to compress captured images prior to transmission to a server computer, to handle commands from the server computer, etc.
  • additional communication electronics e.g., to provide the electronic interface with a server computer, to compress captured images prior to transmission to a server computer, to handle commands from the server computer, etc.
  • one or more of such functions could be integrated into a server computer or a sign controller, among other variations. The use and operation of the image capture devices will be discussed in greater detail below.
  • the various components in a sign management system 10 may be owned and/or operated by the same or different entities.
  • an owner of one or more electronic signs may utilize a sign management system to rent advertising space on the signs from users having access to the system over the Internet or another public manner of access.
  • a sign management system could be owned and operated by an intermediary party that contracts with one or more owners of electronic signs to rent advertising space on those signs to independent users.
  • the owner of a sign management system could also incorporate kiosks placed in public places such as retail malls and stores as user computers to permit users that would not otherwise have computer access to the sign management system to rent advertising space on an electronic sign. It will be appreciated that a wide variety of alternate business models are also possible consistent with the invention.
  • a principal advantage of the sign management system implementations disclosed herein is that the processes of creating, editing and/or retrieving message requests from users; processing those message requests to verify compatibility with sign capabilities; securing payment from users; monitoring message requests for appropriate content; scheduling message requests; controlling electronic signs to display those message requests; and providing feedback to users to confirm display of messages, may all or in part be implemented in a highly automated manner, requiring little if any human interaction beyond that of the users generating the message requests.
  • the transactional costs typically associated with contracting for the display of messages on electronic signs are typically reduced, resulting in less effort, expense and frustration than conventional systems.
  • With reduced transactional costs often individual users or small advertisers, who would not otherwise be willing to expend the time, effort and expense necessary to get a message displayed on an electronic sign, are more likely to rent advertising space, presenting additional advertising revenue opportunities for message display service providers.
  • Fig. 2 illustrates an exemplary hardware and software environment for server computer 30.
  • Computer 30 typically includes at least one processor 32 coupled to a memory 34.
  • Processor 32 may represent only one or multiple processors (e.g., microprocessors), and memory 34 may be implemented using any of a number of known memory architectures, including one or more levels of volatile memory such as dynamic random access memory (DRAM) and/or one or more levels of cache memory (whether integrated into or external to a processor), as well as various nonvolatile or backup memories (e.g., programmable or flash memories), read-only memories, etc.
  • DRAM dynamic random access memory
  • cache memory whether integrated into or external to a processor
  • nonvolatile or backup memories e.g., programmable or flash memories
  • read-only memories etc.
  • memory 34 may be considered to include memory storage physically located elsewhere in or accessible by server computer 30, e.g., as stored in a mass storage device 38 or on another computer coupled to server computer 30 through network interface 40.
  • Server computer 30 also typically receives a number of inputs and outputs for communicating information externally.
  • server computer 30 typically includes a terminal interface 36.
  • additional storage may be provided through the use of one or more mass storage devices 38, e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a DVD drive, etc.), and/or a tape drive, among others.
  • server computer 30 may include an one or more network interfaces 40 to interface the computer with one or more networked devices, e.g., other server computers, user computers, sign controllers, and the like, using any of the aforementioned communications links.
  • server computer 30 typically includes suitable analog and/or digital interfaces between processor 32 and each of components 34, 36, 38 and 40 as is well known in the art.
  • Each user computer likewise includes any of a number of conventional hardware environments, typically including one or more processors, a memory architecture, and various input/output devices as is well known in the art.
  • a user computer can include any electronic device suitable for receiving user input and interacting with a user, as well as communicating with the sign management system. Exemplary devices can include, desktop or portable computers, hand-held computers, and kiosk terminals, among others.
  • Server computer 30 operates under the control of an operating system 42, and executes or otherwise relies upon various computer software applications, components, programs, objects, modules, data structures, etc. to implement the sign management functions described herein (e.g., sign manager 44 and user interface 46, among others). Moreover, various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer coupled to computer 30 via a network, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers over a network.
  • a network e.g., in a distributed or client-server computing environment
  • routines executed to implement the embodiments of the invention whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions will be referred to herein as "computer programs", or simply “programs".
  • the computer programs typically comprise one or more instructions that are resident at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause that computer to perform the steps necessary to execute steps or elements embodying the various aspects of the invention.
  • signal bearing media include but are not limited to recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., CD-ROM's, DVD's, etc.), among others, and transmission type media such as digital and analog communication links.
  • FIG. 1 illustrates the primary software components in a representative server computer 30 and user computer 18 in performing the various sign management functions described herein.
  • TCP server 50 transmission control protocol
  • CGI-BIN gateway application 52 common gateway interface-binaries gateway application 52.
  • TCP server and gateway 52 may be implemented, for example, in any commercially- available Internet or "web" server application, as is well known in the art.
  • the user interface functions are handled by a JAVA or Active X client application 54 and a web browser 56, each resident in the memory of user computer 18.
  • CGI-BIN gateway 52 typically interacts with web browser 56 to provide a series of platform-independent forms, e.g., in the format of hypertext markup language (HTML) documents, for viewing on web browser 56.
  • a locally-resident client sign editor application 54 is typically utilized to supplement the user interface operations of the sign management system.
  • CGI-BIN gateway 52 and web browser 56 are utilized to handle sign management functions such as selecting electronic signs and selecting time slots for display of messages, as well as additional functions such as handling payment and other transactional issues, and providing an on-line tutorial for the user. Further functions, such as the display of disclaimers, retrieving images as proof of display or as a mementos, user authentication, confirmation of orders, and other features described below are generally allocated to the HTML-based components of the user interface.
  • the client application 54 that executes locally on a user's computer interfaces with TCP server 50 to handle additional user interface operations that are not well suited for an HTML-based interface.
  • the client application may either be platform-independent, as with a JAVA applet, or may be a platform-dependent application, such as one or more Active X controls that are specific to the Microsoft Windows environment.
  • multiple client application formats may be supported to permit users having different platform capabilities and configurations to interface with the sign management system.
  • information about a particular user's capabilities and/or platform configuration e.g., the user's operating system and platform
  • can be readily obtained e.g., through the use of simple JavaScript functions and the like
  • a user may be required to manually specify which of multiple application formats is optimal for the user.
  • TCP server 50 download client application 54 to the user's computer during the initial interaction between the user and the sign management system. This eliminates the need for the user to specifically obtain and install the client application prior to interacting with the sign management system.
  • alternate user interface applications may be utilized consistent with the invention, e.g., alternate interface protocols, including active server pages (ASP), scripting languages, and other platform-independent or specific applications that are either fully resident on the user computer or are downloaded on an as-needed basis from the server computer to the user computer.
  • ASP active server pages
  • much of the functionality can be allocated to the server computer, with the user computer acting more as a terminal that displays the results of the operations performed by the server computer.
  • client application 54 and web browser 56 may be combined into a dedicated application, or that a web-type interface can be replaced with a proprietary interface, if desired.
  • Sign manager 44 principally implements the handling and processing of message requests generated via user interface 46.
  • Sign manager 44 is under the principal control of a main control module 48, which is coupled to both TCP server 50 and gateway 52, as well as to a database 58, an order verification module 60, a monitoring and approval module 62, a scheduler module 64 and a proof of display module 68.
  • the primary functions performed by main control module 48 include receiving user requests from the user interface, retrieving information from database 58, and calling and passing information between the various additional modules 60, 62, 64 and 68 as necessary.
  • Database 58 principally stores electronic records of the various message requests generated by users. Additional information may also be stored in database 58, e.g., the display capabilities and other operating parameters of the various electronic signs controlled by the computer, user profile information, pre-existing message content and gallery information, and other required data.
  • Order verification module 60 is principally responsible for verifying the eligibility of a user message request in terms of user profile, user payment and the overall compatibility of the request with various order parameters.
  • Monitoring and approval module 62 is principally responsible for verifying that the message content is acceptable, e.g., not including any dirty words or other content unsuitable for a particular sign purpose.
  • monitoring and approval module 62 may include a content filter that is purely automated, and/or may include an additional manual component that requires human approval of the message request prior to display of that request on an electronic sign.
  • Scheduler module 64 is principally responsible for allocating time slots for message requests and transmitting control signals to the signs for display of the messages at the proper time. This module is also responsible for responding to requests from other components in the sign management system, e.g., so that a user can reserve a time slot and/or find out at what times a particular sign is available.
  • scheduler module 64 may handle the actual scheduling of messages, or in the alternative, may transmit those messages prior to display to appropriate sign controllers having their own scheduling capabilities embedded therein.
  • Scheduler module 64 is specifically interfaced with various sign controllers via sign control drivers 66.
  • each sign control driver 66 is configured to interact with scheduler module 64 via a generic protocol, and to likewise interact with a particular sign controller based upon whatever specific requirements exist for that controller.
  • the scheduler module can be constructed to work with any type of sign, with only the program code in a particular sign controller driver specifically coded to conform to the particular requirements of the sign controller.
  • Proof of display module 68 is principally responsible for interfacing the sign manager with any image capture devices controlled by the server computer.
  • the proof of display module 68 may also include compression capabilities as well as synchronization capabilities to permit an image capture device to capture an image at a specific instant in time while a particular portion of a message is being display on its associated sign. Additional networking capabilities may be incorporated into server computer 30 to provide the electrical interface with the image capture devices as well as the various sign controllers to which the server computer is coupled.
  • Figs. 4-24 next describe the operation of the illustrated sign management system in generally the same order in which a user would interact with the system to generate and schedule a message request to be displayed on an electronic sign. These different steps along the process are illustrated as being performed using any number of user interface mechanisms, including HTML pages, CGI scripts, and the operation of program code executing on either of the server or user computers. The implementation of these operations to effect the herein described user interface is well within the abilities of one of ordinary skill in the art having the benefit of the instant disclosure.
  • Figure 4 illustrates, for example, a computer display 80 upon which is displayed a window 82 for a browser resident on a user's computer. Shown displayed within the browser window is a message request home page 84 that represents the initial user interface mechanism through which a user might generate a message request for sign management system 10. It is anticipated that a user could navigate directly to home page 84, or in the alternative, could be required to login, or authenticate, from a sign management home page prior to being granted access to the message request home page.
  • User authentication typically requires that a user provide a user name and password to permit profile information about the user to be retrieved and utilized during the generation of the user request.
  • an additional service provided by the sign management system is that of authenticating new users. Such an operation would likely also entail the input of profile information about the user, such as name and address, e-mail address, credit card number, etc.
  • Message request home page 84 includes a plurality of user interface controls 86-99 through which a user can interactively construct a message request (also referred to herein as a "electronic order").
  • Each user interface control 86-99 is shown as a button control through which a user can select the control to navigate to another HTML document to operate on a specific portion of a message request.
  • User interface control 86 is used to access a sign selection interface through which a user selects one or more of a plurality of available electronic signs to which a message request should be directed.
  • User interface control 88 permits a user to interactively create and edit a message to display on a selected electronic sign.
  • User interface control 90 enables a user to schedule display of the selected message on the selected sign.
  • User interface control 92 permits a user to select the mode in which the user will receive confirmation or proof of display of the selected message on the electronic sign.
  • User interface control 94 permits a user to select a method of payment for the message request, and user interface control 96 initiates processing of the message request or order once all of the necessary information has been entered by the user. Additional controls may also be provided on home page 84. For example, it may be desirable to permit a user to access a disclaimer through user interface control 98.
  • the disclaimer may include, for example, information warning the user that the message display service provider is not liable for the content of any messages, and that liability rests solely on the user, similar to a newspaper advertising disclaimer.
  • the disclaimer may also include warnings such as notifying the user of the inherent risks associated with electronic commerce.
  • the user may also be able to access an on-line help tutorial through user interface control 99.
  • supplemental help systems to provide interactive assistance to a user is well known in the art, and thus will not be described in further detail herein.
  • HTML-based mechanism described herein is merely exemplary, and should not be used to limit the invention.
  • Figure 5 illustrates a flow chart 100 of the operations performed when selecting a sign upon selection of user interface control 86 of Fig. 4.
  • sign parameters representing a search criteria are retrieved from a user.
  • block 104 a list of signs matching the sign parameters input by the user are retrieved and displayed to the user.
  • block 106 the sign management system waits for user input, and the sequence of blocks 108-114 detect and handle various types of user input received from a user.
  • Block 108 determines whether the user has requested a preview of a selected sign. If so, a digital image of the sign is retrieved in block 114.
  • the digital image may be a real-time image captured using an image capture device associated with that sign, the process of which is described in greater detail below.
  • a snapshot of an electronic sign stored persistently in the sign management system, may be displayed in the alternative.
  • Block 110 next determines whether the user input is to select a sign for display of a desired message. If so, the sequence of operations is complete, typically resulting in the user being returned to message request home page 84 of Fig. 4.
  • Block 112 represents other user input that may be received from a user, but which is not relevant to the selection of a sign as described herein.
  • Figure 6 illustrates, for example, one suitable HTML document 116 to be used during the sign selection process in connection with Fig. 5.
  • Document 116 is implemented as a framed document, including a search frame 118 and a results frame 120.
  • Search frame 118 includes a plurality of user interface controls 122-130 through which various sign parameters can be input by a user.
  • a button user interface control 132 may be selected by a user to initiate a search to retrieve and display a list of signs 134 in results frame 120.
  • a selected sign is illustrated at 136, and a plurality of button controls 138-142 are shown for providing user input to the browser with respect to the currently selected sign.
  • button control 138 enables a user to accept the currently selected sign and return to the message request home page.
  • Button control 140 performs a CANCEL operation, returning to the message request home page without selecting (or modifying a past selection) of a sign.
  • Button control 142 accesses the preview function discussed above by opening an additional window 144 within which is displayed an image 146 of the selected electronic sign.
  • a number of sign parameters may be input by a user to search and locate desirable electronic signs among those available through the sign management system.
  • controls 122 and 124 respectively permit a user to input width and height limitations on a sign so that only signs meeting a desired set of dimensions are retrieved.
  • Controls 126, 128 and 130 respectively permit a user to input state, city and street location to locate a sign in a predetermined geographical location.
  • Other sign parameters may also be utilized to restrict a search. For example, the scheduler could be accessed to only return signs that are available for a desired time slot.
  • Additional sign parameters may specify certain display capabilities of a sign, e.g., whether a sign is capable of displaying video, whether the sign is capable of colors, the display resolution or color depth of the sign, etc. It should also be appreciated that not all available sign parameters need be specified to limit the search results, and further, that other search criteria may be utilized to retrieve a subset of available electronic signs.
  • Figure 7 next illustrates a flow chart 150 showing the sequence of operations performed during creation or editing of a message in response to selection of user interface control 88 of Fig. 4. Specifically, in response to a user request to create or edit a message through the HTML message request home page, a message editor client application is executed locally on a user's computer to handle the interactive editing function in creating a message.
  • both JAVA and Active X versions of a message editor are supported such that, for Microsoft Windows-compatible user computers, Active X controls are utilized, while for other computing platforms where Active X controls are not supported, a platform-independent JAVA applet is downloaded to the user computer to perform similar functions.
  • the first step in executing the message editor application is to determine in block 152 whether Active X is supported by the user's computer. This can be performed through requesting input from the user, or in the alternative, through the use of known JavaScript function calls.
  • JAVA applet version of the message editor application is downloaded to the user computer in block 154.
  • the JAVA applet is started on the user's computer, whereby the initialization of the sign editing process is commenced.
  • Active X controls are already resident in the user's computer — that is, if the Active X controls have already been downloaded to the user's computer in the past. If not, the Active X control version of the message editor is downloaded to the user computer in block 160. Next, the Active X controls are started on the user computer in block 162 to initiate the sign editing function. Returning to block 158, if the Active X controls are already resident in the user computer, a download of the controls is not necessary, so the already-resident Active X controls can simply be started to initiate the sign editing process.
  • Figure 8 illustrates the program flow of a message editor application 170 consistent with the invention.
  • Message editor application 170 generally operates using an event-driven programming model, whereby, after initializing the editing window in block 172, events are waited upon at block 174 and handled via one of blocks 176-196 as they are received.
  • the initialization step performed in block 172 may also include retrieval of a message record if such a record already exists for the pending message request being constructed by a user. If, however, no message record has been constructed, the initialization step may also include initialization of a new message record in certain instances.
  • One event that can be handled by message editor application 170 is that of creating a new page or message record, which is detected at block 176 and handled in block 198 by adding a new message record and initializing the editing window to display a fresh, unedited window. Addition of a message record may also include the association of the new message record with the old message record, e.g., by incorporating a pointer to the new message record in the old record.
  • Another event capable of being detected by message editor application 170 is an event to input text into the message, which is detected in block 178 and handled in block 200 by adding the input text to the message record. Control then passes to block 202 to update the message record to reflect the additional text. Moreover, block 202 may also update the editing window to provide a what-you-see-is-what-you-get (WYSIWYG) or interactive editing operation. Control then returns to block 174 to process additional events.
  • WYSIWYG what-you-see-is-what-you-get
  • a request to import graphics is detected in block 180 and handled in block 204 by retrieving a graphics file from the user. Control then returns to block 202 to update the message record.
  • a similar event for importing animation is detected in block 182 and handled in block 206 by retrieving an animation file from the user and updating the message record in block 202.
  • Retrieval of a graphics or animation file is typically performed in an interactive manner, whereby a user is permitted to browse through a directory structure including appropriate graphics and animation files.
  • a preview function may also be provided in a manner known in the art.
  • Additional editing functions may be supported. For example, it may be desirable to modify the font and/or colors of textual information. Such a class of events may be detected in block 184 and handled in block 208 by retrieving new font and/or color selections from a user, and then updating the message record in block 202. Moreover, it may be desirable to provide the ability to incorporate special effects into a message. Selection of such effects is detected in block 186 and handled in block 210 by presenting the user with a list of special effects. In addition, it may be desirable to provide the user with a preview of a selected effect. Within such a structure, a user selects an effect, which is detected in block 212, and control passes to block 202 to update the message record to reflect the new effect.
  • Any number of known special effects may be incorporated into a message consistent with the invention, e.g., scroll effects, wipe effects, swipe effects, reveal effects, blink effects, inversion or flash effects, dissolve effects, rainbow effects, and others.
  • Another event that may be handled by message editor 170 is a request to select another sign type. Such an event is detected in block 188 and handled in block 214 by getting new sign parameters from the user, e.g., in the same manner as described above with regard to searching for a desired sign. When new sign parameters are obtained, a convert message routine 216 is executed to modify the message as necessary to be compatible with the new sign parameters associated with the newly- selected sign type. Control then returns to block 202 to update the message record and wait for new events.
  • Pre-existing message content may be stored, for example, in a content portion of database 58, and may include text information, as well as video, animation, graphics, or other predefined messages that a user is able to use as is or to modify to generate a custom message therefrom.
  • Yet another editing function supported by message editor 170 is a simulate function, which is detected in block 192 and handled in block 220 by creating a computer simulation of how a message defined by the current message record information would appear on the selected electronic sign. Creation of the simulation incorporates not only the contents of the message record, but also the display capabilities of the sign. Through the feedback provided by a simulation, a user is better able to anticipate how a message being edited will ultimately appear on the electronic sign when displayed.
  • the modeling of a physical electronic sign based upon sign parameters such as display resolution, color depth, and other display capabilities would be well within the abilities of one of ordinary skill in the art having the benefit of the instant disclosure.
  • the simulation modeling is an approximation of the physical sign display and it shows the message text and graphics, with limitations due to the capabilities of a standard computer display.
  • control Upon completion of the simulation, control returns to block 202, whereby the message record is updated if necessary, and the message editor waits for additional events.
  • An additional event detected by message editor 170 is a DONE event, which is detected in block 194 and is used to signify the termination of the message editing process.
  • additional edit events may also be supported by the message editor.
  • Figure 9 illustrates, for example, an exemplary window 230 through which user interaction with message editor 170 may be handled.
  • an editing region 232 is provided that simulates the look and feel of a particular sign (with, for example, the individual LED or LCD pixel locations delimited at 234 for the benefit of the user).
  • An editing cursor 236 is also illustrated in the editing region.
  • a menu bar 238 is shown providing access to advanced functions in the editor. Frequently used functions, such as the aforementioned new page, graphics and animation import, font/color selection, effects selection, sign-type selection, gallery viewing and simulation functions, may be accessed through a series of toolbar button user interface controls 240.
  • a message record may include, for example, a sequence of fields 252-264 providing various information about a message.
  • Field 252 provides a record of the text to be displayed in the message.
  • Field 254 identifies one or more graphic, video and/or animation files to be displayed in the message.
  • Field 254 may also be used to provide a background for a text message, and multiple graphics images may be utilized and stored in this field to create animation.
  • Field 256 provides sizing information representing the overall size of the message.
  • Field 258 identifies the sign type for which the message is designed.
  • Field 260 identifies one or more special effects to be utilized in the message, and fields 262 and 264 respectively provide speed indicators to indicate the speed at which an effect or an animation should be displayed (e.g., in frames per second).
  • the text in a particular message record is represented by a list of line records 266 pointed to by field 252.
  • Each line record includes a string field 268 identifying a list of characters.
  • a justification field 270 indicates whether left, center, right or full justification should be used for the list of characters.
  • Fields 272 and 274 identify the length of the string and the coordinate of the line's left upper corner in the message.
  • Field 276 includes a pointer to next line record 266 in the list of lines for the text message.
  • Each line record identifies a linked list of character records 278 pointed to by string field 268.
  • Each character record in turn includes a character code field 280 storing an ASCII code or special character to display.
  • Fields 282, 284 and 286 respectively identify a color, font size and font set for the character identified in field 280.
  • Field 288 provides a pointer to the next character record 278 in the list of characters for the line.
  • Figure 11 illustrates a representative data structure for a sign record 288 that identifies various display capabilities and other sign parameters for a given sign.
  • Field 290 provides a name or other identifier that uniquely identifies a given sign.
  • Field 292 provides location information for the sign, including various geographical information such as state, city, street, country, or address, among others.
  • Field 294 indicates the size or resolution of the sign, and field 296 provides a list of fonts supported by the sign.
  • Field 298 includes the network address of the sign through which the sign controller therefor can be accessed by the sign management system.
  • field 299 provides an identification of the color capabilities of the sign, e.g., the color depth or range of color supported by the sign. Additional information, e.g., whether the sign is capable of supporting video or animation, among other display capabilities may also be stored in sign record 288 consistent with the invention.
  • Figure 12 illustrates a representative electronic order, or message request, record 300 consistent with the invention.
  • Record 300 includes a user ID field 302 that identifies the user with which the record is associated.
  • Field 304 provides a linked list of message records 250' that are configured in a similar manner to message record 250 of Fig. 10, with the addition of a next record field in each message record 250' that points to the next record in the linked list.
  • multiple message records may be associated with a given message request, corresponding to the addition of a new page as described above in connection with message editor 170. With this configuration, multiple messages may be displayed in sequence to constitute a single message for the purposes of the message request.
  • Field 306 provides a sign name identifying the selected sign associated with the message request.
  • field 308 identifies a time slot, or selected time, at which to display the selected message on the selected sign. Starting, ending, and/or duration information may be used to define a time slot, and multiple time slots (even a definition of a repeating time slot) may be stored in field 308.
  • Field 310 provides method of payment information through which a user may be billed and a monetary amount can be collected from the user.
  • Field 312 indicates the type of proof that the user has requested in connection with the message request.
  • field 314 provides a proof frame indicator that indicates which frame of a multi-frame message should be captured by an image capture device to confirm display of a particular message on an electronic sign.
  • Figure 13 A next illustrates convert message routine 216 described above in connection with Fig. 8.
  • the message conversion process begins in block 320 by retrieving the new sign parameters, e.g., by accessing the database 58 for the sign parameters for the currently-selected sign type.
  • the resolution is converted, including scaling as necessary the size of the message component and/or requesting the user to select a sub-region of the existing message (if going to a lower resolution) or where to locate a previous message (if going from a lower to a higher resolution).
  • the color space of the message is converted, and in block 326 the frame rate of any animation or video is converted.
  • any non-supported effects are converted to other effects mapped to those non-existent effects. If desirable, a user may also be queried to select alternate effects if a particular effect is not supported by a new sign type. It should be appreciated that the conversion of resolution, color space, frame rate and effects are all well known image processing techniques. As such, a further discussion of such operations is not necessary for a full understanding of the invention.
  • 13B illustrates create simulation routine 220 in greater detail.
  • the capabilities of the selected electronic sign are retrieved from the server computer.
  • a simulated sign background image is created, based upon the sign capabilities of the selected sign.
  • the simulated background includes the relative horizontal and vertical dimensions of the sign.
  • the first frame of the message is generated using the information in the message record.
  • a window is opened on the user's computer display displaying the first frame superimposed over the background image of the selected sign.
  • block 744 generates the next frame for the message, or if the last frame was displayed, regenerates the first message frame.
  • block 746 updates the window to display the next frame.
  • Other alternatives will become apparent to one of ordinary skill in the art having benefit of the instant disclosure.
  • Figure 14 illustrates at 340 the sequence of operations performed in scheduling a message in response to user selection of user interface control 90 of Fig. 4.
  • the desired date and time interval during which to display a message is input by the user.
  • Other or additional chronological information may also be input, e.g., the availability of a repeating time interval, a duration of a time interval, etc.
  • the scheduler module is accessed to determine if the requested time interval is available for the selected sign. It should also be appreciated that if no sign is currently selected, the user may be queried to select a sign prior to proceeding to block 344.
  • the scheduler returns the result of the query, and it is determined whether the requested time interval is available. If not, control passes to block 347 to indicate that the time interval is unavailable, and control returns to block 342 to have the user input alternate information.
  • the desired date and time corresponding to at least one of the available time slots is obtained from the user.
  • the cost (if any) of the message is displayed to the user.
  • different signs may have different cost structures, which may also vary depending upon date, time, or other chronological information. For example, displaying an advertisement outside of a stadium just prior to a football game would demand a higher price than displaying the same message on the same sign at 4:00 AM. Any number of pricing structures may be supported, as would be well known to those in the advertising art.
  • block 352 waits for confirmation from the user.
  • the scheduler is notified to reserve the requested time slot for a short period of time (e.g., one hour). This limited-duration reservation of a time slot in essence permits a user to lock-out other users from a particular time slot while that user completes the message request. Otherwise, a user might select a time slot, then proceed with creating a message and submitting an order, only to find that another user has since purchased that time slot in the interim.
  • Document 370, 380 that may be displayed in browser window 82 during interactive scheduling of a message during the sequence of operations in Fig. 14.
  • Document 370 of Fig. 15A is typically displayed to receive the user input of a time interval, corresponding to block 342 of Fig. 14.
  • document 370 includes a series of date input fields 372 through which a user enters a starting and ending day, month and/or year. Hour and minute ranges are respectively input through input fields 374 and 376.
  • a "get free slots" button control 378 is used to submit the information to the sign management system, and a reset button control 379 is used to clear the information currently displayed in the input fields.
  • document 380 includes a list box control 382 displaying the available time slots.
  • document 380 includes input fields 384, 386 and 388 to input the date, hour and minute of a desired time slot (which may represent only a portion of an available time slot).
  • Button control 390 is used to submit the input to the sign management system, and button control 392 is used to clear the information currently displayed in the input fields.
  • Figure 16 illustrates at 400 the sequence of operations performed in selecting a proof mode in response to user selection of user interface control 92 of Fig. 4.
  • the user supplies an auto/demand selection to the system, indicating whether the user wishes to receive automatic confirmation of the display of the requested message, or whether the user wishes to receive confirmation "on demand" or manually.
  • Automatic confirmation is typically provided through the use of an e- mail sent to an e-mail address specified by the user when the message has been displayed and the request has been fulfilled.
  • the "on demand" confirmation is implemented using a file transfer protocol (FTP) server that is accessible to a user to permit the user to download the confirmation anytime after the confirmation has been placed on the server after fulfillment of the message request.
  • FTP file transfer protocol
  • a proof frame is next retrieved from the user in block 404 for message requests that specify animation or multiple frames.
  • An enhancement of this feature is to permit a user to specify a specific frame in a multi-frame message to capture for confirmation of delivery. As such, in block 404 the proof frame is retrieved from the user.
  • FIG. 17 illustrates a representative proof mode selection page 410 displayed in browser window 82.
  • Page 410 includes a pair of linked radio buttons, 412, 414 through which a user selects either the automatic or manual, or on-demand proof mode.
  • an input box 416 is provided for a user to submit his or her e-mail address to which the confirmation will be sent.
  • the user may input the e-mail address with his or her profile information at another stage of the message request generation process, whereby separate inputting of an e-mail address may not be required at this point.
  • Figure 18 illustrates at 430 the sequence of operations performed during the selection of the payment method in response to user selection of control 94 of Fig. 4. First, as shown in block 432, a ZIP code (if within the United States) or a country is obtained from the user. Next, the address of the user is obtained in block 434.
  • a user is asked to select a payment method, in this implementation, either payment by credit card or by purchase order. If the user selects payment by credit card, control passes to block 438 to obtain credit card information from the user. If on the other hand, the user selects payment by purchase order, control passes instead to block 439 to get bank account information from the user. Once such information is input, the user is returned to home page 84 of Fig. 4.
  • FIG. 19A A series of suitable HTML documents 440, 450 and 462 for use in inputting method of payment information are respectively shown in greater detail in Figs. 19A- 19C.
  • Document 440 of Fig. 19A is displayed during selection of a payment method, corresponding to block 436 of Fig. 18.
  • the method of payment may be selected, for example, through a drop-down list box control 442, with confirmation of the selection made via a continue button control 444.
  • informational text 446 may also be provided to provide instructions to the user.
  • Document 450 of Fig. 19B is displayed once a user has indicated that a credit card will be used as the selected payment method, corresponding to block 438 of Fig. 18.
  • the type of credit card may be selected, for example, through a drop-down list box control 452, with card number and expiration date entered through input fields 454, 456.
  • Completion of the order may be indicated via place order button control 458, with informational text 460 used to provide additional instructions to the user.
  • the control button 458 may be used to return to home page 84 to permit the user to separately submit the order via control button 96.
  • Document 460 of Fig. 19C is displayed once a user has indicated that a purchase order will be used as the selected payment method, corresponding to block 439 of Fig. 18.
  • the user's bank account number and purchase order number may be entered through input fields 464, 466, and completion of the order may be indicated via place order button control 468. Additional informational text 469 may also be included to provide instructions to the user.
  • Figure 20 illustrates at 480 the sequence of operations performed in response to user selection of submit order button 96 of Fig. 4 (in the alternative, the sequence of operations can be performed responsive to selection of a "place order" button control, e.g., as shown in Figs. 19B and 19C.
  • the sequence of operations shown at 480 are performed by main control module 48.
  • order verification module 60 (Fig. 3) is called to determine whether the submitted order is suitable for processing. Then, if module 60 confirms that the order is suitable for processing, monitoring and approval module 62 (Fig. 3) is called in block 484 to determine whether the content of the message specified in the order is appropriate. If so, control then passes to block 486 to submit the message to the scheduler module 64 (Fig. 3). If the scheduling operation succeeds, control passes to block 488 to debit the bank/credit card account (as appropriate), in a manner well known in the art. Next, block 490 determines whether the debit was successful. If so, control passes to block 491 to notify proof of display module 68 to provide a proof of display image at the time, and optionally frame, specified in the submitted order.
  • a confirmation email is sent to the email account specified in the order to confirm that the message has been scheduled for display.
  • additional information such as a summary of the order parameters and a receipt for the charge to the user's account, may also be provided.
  • the main control module waits until the message is displayed, whereby, as shown at block 496, a proof of display email is sent to the user, if that option was selected by the user during creation of the order. If not, no such email is sent. It should be appreciated that waiting for the message to be displayed need not positively executed by main control module 48, rather, the main control module may terminate handling of the order at block 492, and then execute block 496 asynchronously after notification from another module in the sign management system (e.g., either of modules 64, 68).
  • another module in the sign management system e.g., either of modules 64, 68.
  • order verification module 60 is illustrated by order verification routine 500 in Fig. 21.
  • order verification routine 500 the availability of the selected time slot for the order is verified by accessing scheduler module 64 (Fig. 3). If the selected time slot is still available, the message parameters are compared with the capabilities of the selected sign in block 504 to determine whether the message parameters are compatible (including accessing the sign capabilities stored in database 58 (Fig. 3).
  • the message context is appropriate — that is, whether the content of the message is compatible with the message display service provider.
  • a message advertising a particular product should not be displayed on an electronic sign owned by a competitor.
  • a message espousing a particular political view may not be acceptable to a particular message display service provider.
  • block 506 may be implemented by performing a search to locate any inappropriate terms.
  • monitoring and approval module 62 is illustrated by monitoring & approval routine 520 in Fig. 22.
  • the configuration of the sign is retrieved from database 58.
  • block 529 it is determined whether an additional, manual review of the text in the message is required. If so, control passes to block 532 to notify an administrator to obtain manual review and approval of the message content. Control then passes to block 534 to determine whether the message content is approved. Otherwise, if no manual review of the text is required, block 529 passes control to block 530 to determine whether the message includes graphics.
  • control also passes to block 530 to continue processing of the message. If the message does include graphics, control also passes to block 532 to notify an administrator to obtain manual review and approval of the message content. Then, after receiving manual review, or if no graphics are included in the message, control passes to block 534 to determine whether the message content is approved. If so, a "pass" result is returned, as represented by block 536. If not, a "fail” result is returned, as represented by block 538. Also, returning to block 524, if the message is not configured for monitoring and approval, control passes directly to block 536. In the alternative, content monitoring may be omitted, or may always be performed regardless of the electronic sign. It should also be appreciated that any other combination of automated and/or manual review may be utilized in other embodiments consistent with the invention.
  • scheduler routine 570 is illustrated as an event-driven routine, waiting for events in block 572, and detecting received events at blocks 574-580. Moreover, as shown in block 582, the scheduler routine periodically checks a message queue and submits any pending message to the appropriate sign controller for the electronic sign selected for that message. Moreover, as is known in the art, each sign controller typically includes scheduling capabilities such that submission of a message to the sign controller, as well as a specific time slot to display that message (using the controller-specific control signals provided by the sign control driver 66 for that sign), is sufficient to ensure that the message will be displayed at the appropriate time. In the alternative, scheduling capabilities may be incorporated directly into scheduler module 64, rather than relying on the capabilities provided by conventional sign controllers.
  • One type of event handled by scheduler routine 570 is a request to determine the availability of a particular sign over a particular time interval. Such an event is detected in block 574 and handled in block 590 by determining whether the specified sign is available at the time specified in the event. Such information is returned to the main control module, also including the specific time slots that are available within the specified time interval. The information is determined by accessing a message queue maintained within the scheduler module 64. In the alternative, the information can be determined by accessing a local message queue maintained in the appropriate sign controller.
  • Another type of event handled by scheduler routine 570 is a reserve time slot event, which is detected in block 576 and handled in block 592 by blocking out the specified time slot for the specified user, typically to give the user time to complete the creation of an order.
  • a reservation timer e.g., one hour
  • Expiration of a timer is detected in block 578 and handled in block 594 by clearing the previously-set block, thereby freeing the reserved time slot for selection by other users.
  • Another type of event handled by scheduler routine 570 is a message submitted event, which is detected in block 580 and handled in block 596 by adding the message to the message queue maintained in the scheduler module.
  • proof of display module 68 is shown at 620 in Fig. 24.
  • Module 68 may be located within a server computer (as shown in Fig. 3), or in the alternative, located within a sign controller and/or remote electronic device coupled to an image capture device.
  • a snapshot of the electronic sign is captured on a periodic basis (e.g., n times a second), in a manner known in the art.
  • the last captured snapshot is forwarded to the main control module in response to a request made by such module.
  • block 626 it is determined in block 626 whether a previously-stored proof of display time was reached —that is, whether a proof of delivery time specified in a particular message request has been reached. If so, control passes to block 628 to store the snapshot in a file transfer protocol (FTP) account accessible by the user that created the message to provide proof of delivery therefor. In addition, block 628 may also notify the main control module that the snapshot has been stored, so that the main control module may forward a proof of delivery email to the user if the user had requested such.
  • FTP file transfer protocol
  • a sign management system 700 is shown including a global sign management system gateway 702 coupled to a plurality of sign managers 704 over the Internet 34. It is anticipated that a user may log on and authenticate to any sign manager 704 in the manner discussed above. In the alternative, the user may register with the global sign management system gateway 702 to select among a plurality of available signs distributed among the various sign managers. Through this architecture, a user is able to select among a larger of available signs, and have the distribution of a message request transmitted to the appropriate sign manager for handling.
  • the complete ordering process may be handled by gateway 702, with the completed order sent to the various sign managers 704 as appropriate.
  • only a portion of the message request ordering process may be handled by gateway 702, with the user transferred to the appropriate sign manager to complete the order.
  • the sequence of operations in directing a message request to a particular sign manager are illustrated at 710.
  • the gateway 702 the user is permitted to select globally among a plurality of available signs available through the sign management system, as shown at block 712.
  • a preview function may also require the interaction between the gateway and the respective sign managers.
  • the gateway may be as simple as a sequence of HTML documents through which a user can search for different signs at different locations, with the selection of any of those signs and/or locations used to simply direct the user to the particular sign manager for an operation principally in the manner discussed above for sign management system 10.
  • a greater deal of interactivity may be provided between gateway 702 and each sign manager 704 to facilitate the streamlined processing of message requests throughout system 700.
  • a user may be able to obtain general background information about the sign management system and its operation.
  • a sign management system may permit message display service providers to obtain information about how to purchase the system and/or how to contract for the services of an existing sign management system.
  • An interactive manner of ordering service and/or sign management system may also be provided.
  • a user may be able to retrieve descriptive information about a particular sign during the selection process thereof.
  • a user may be permitted to have an account in the sign management system and to retrieve previously-prepared messages on a recurring basis.
  • a message display service provider may also be able to obtain statistical information regarding the orders placed to his or her owned electronic sign.
  • a user may have access (after authorization) to an FTP account to retrieve proof of display images.
  • a user may be permitted to purchase proof of display images, e.g., as a memento of the purchase of the message.
  • a value added service may include mailing a framed copy of a proof of display image to a message recipient (e.g., a person whose birthday was announced in a message).
  • Other uses for proof of display images will be envisioned by one of ordinary skill in the art having benefit of the instant disclosure.
  • Audio may be a component of a video clip, or may be a separate multimedia object associated with the message. Handling of audio may be handled in any number of manners, e.g., similar to the manner described herein for editing, selecting, and processing image, animation, and video multimedia components of a message.

Abstract

L'invention concerne un système de gestion (10) d'affichage électronique multi-utilisateurs comprenant une liaison de communication électronique (34, 36, 38) assurant la réception de demandes de message en provenance d'une pluralité d'utilisateurs indépendants. Les demandes reçues via la liaison (34, 36, 38), associées aux messages sélectionnés et aux durées sélectionnées d'affichage de ces messages, sont traitées par le système de gestion d'affichage (10) afin de générer des signaux de commande destinés à commander l'affichage de ces messages sur un panneau d'affichage (12, 14, 16) à des moments adéquats.
PCT/US2000/010260 1999-04-16 2000-04-14 Systeme de gestion d'affichage electronique multi-utilisateurs WO2000063771A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU44641/00A AU4464100A (en) 1999-04-16 2000-04-14 Multi-user electronic sign management system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29314399A 1999-04-16 1999-04-16
US09/293,143 1999-04-16

Publications (1)

Publication Number Publication Date
WO2000063771A1 true WO2000063771A1 (fr) 2000-10-26

Family

ID=23127823

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/010260 WO2000063771A1 (fr) 1999-04-16 2000-04-14 Systeme de gestion d'affichage electronique multi-utilisateurs

Country Status (2)

Country Link
AU (1) AU4464100A (fr)
WO (1) WO2000063771A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001055945A2 (fr) * 2000-01-31 2001-08-02 E-Steel Corporation Systeme et procede utilises pour telecharger des donnees de produit dans un serveur de bourse de marchandises
WO2001065531A1 (fr) * 2000-03-01 2001-09-07 Chad Moore Connexion de l'internet a un panneau d'affichage electronique
KR20020074710A (ko) * 2001-03-21 2002-10-04 (주)한일디스플레이 전광판의 다중운영 시스템
WO2003048985A1 (fr) * 2001-12-07 2003-06-12 Novocine Systeme de gestion de contenus numeriques et salle de cinema associee
WO2003100752A1 (fr) * 2002-05-24 2003-12-04 Teresa Cacciatore Systeme permettant de gerer et de distribuer des messages publicitaires et dispositif permettant d'afficher ces messages publicitaires
EP1456832A2 (fr) * 2001-11-21 2004-09-15 Goliath LLC Systeme de controle de la conformite d'une publicite
EP1805901A2 (fr) * 2004-07-23 2007-07-11 Charles E. Willmore Systeme et procede d'affichage multiutilisateur interactif sans fil
WO2012101499A2 (fr) * 2011-01-24 2012-08-02 Van Zyl Jacobus Gidion Système d'écran d'affichage et ses composants
US9391793B2 (en) 2012-11-02 2016-07-12 Trahan Tech Inc. Electronic placard
EP2559270A4 (fr) * 2010-04-15 2017-10-25 Samsung Electronics Co., Ltd Procédé et appareil de génération et de lecture de message d'animation

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2286073A (en) * 1994-01-27 1995-08-02 Peter Johnson Display system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2286073A (en) * 1994-01-27 1995-08-02 Peter Johnson Display system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DE TUNNELKRANT IN LEIDSCHENVEEN, 5 October 1998 (1998-10-05), XP002144153, Retrieved from the Internet <URL:http://www.factory.org/tunnel> [retrieved on 20000801] *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001055945A3 (fr) * 2000-01-31 2003-01-03 Steel Corp E Systeme et procede utilises pour telecharger des donnees de produit dans un serveur de bourse de marchandises
WO2001055945A2 (fr) * 2000-01-31 2001-08-02 E-Steel Corporation Systeme et procede utilises pour telecharger des donnees de produit dans un serveur de bourse de marchandises
WO2001065531A1 (fr) * 2000-03-01 2001-09-07 Chad Moore Connexion de l'internet a un panneau d'affichage electronique
KR20020074710A (ko) * 2001-03-21 2002-10-04 (주)한일디스플레이 전광판의 다중운영 시스템
EP1456832A4 (fr) * 2001-11-21 2010-07-14 Goliath Llc Systeme de controle de la conformite d'une publicite
EP1456832A2 (fr) * 2001-11-21 2004-09-15 Goliath LLC Systeme de controle de la conformite d'une publicite
WO2003048985A1 (fr) * 2001-12-07 2003-06-12 Novocine Systeme de gestion de contenus numeriques et salle de cinema associee
FR2833379A1 (fr) * 2001-12-07 2003-06-13 Novocine Systeme de gestion de contenus numeriques et salle de cinema associee
WO2003100752A1 (fr) * 2002-05-24 2003-12-04 Teresa Cacciatore Systeme permettant de gerer et de distribuer des messages publicitaires et dispositif permettant d'afficher ces messages publicitaires
EP1805901A2 (fr) * 2004-07-23 2007-07-11 Charles E. Willmore Systeme et procede d'affichage multiutilisateur interactif sans fil
EP1805901A4 (fr) * 2004-07-23 2010-03-24 Charles E Willmore Systeme et procede d'affichage multiutilisateur interactif sans fil
EP2559270A4 (fr) * 2010-04-15 2017-10-25 Samsung Electronics Co., Ltd Procédé et appareil de génération et de lecture de message d'animation
US10129385B2 (en) 2010-04-15 2018-11-13 Samsung Electronics Co., Ltd Method and apparatus for generating and playing animated message
WO2012101499A2 (fr) * 2011-01-24 2012-08-02 Van Zyl Jacobus Gidion Système d'écran d'affichage et ses composants
WO2012101499A3 (fr) * 2011-01-24 2013-06-27 Van Zyl Jacobus Gidion Système d'écran d'affichage et ses composants
US9391793B2 (en) 2012-11-02 2016-07-12 Trahan Tech Inc. Electronic placard

Also Published As

Publication number Publication date
AU4464100A (en) 2000-11-02

Similar Documents

Publication Publication Date Title
US7881954B2 (en) System and method for managing seat reservations
US20020055880A1 (en) System for facilitating digital advertising
US20040073484A1 (en) Electronic display advertising method and apparatus
US20070050372A1 (en) Systems and methods for creating, managing and publishing advertisements
JP2002501635A (ja) テンプレート印刷用のインターフェイスに動的ｐｄｆ技術を利用する校正システム
CA2779193A1 (fr) Systeme et produit logiciel
JP2007537496A (ja) コンテンツ作成、配信、対話、及びモニタリングシステム
US20020013738A1 (en) Online exhibition center
JP2004191496A (ja) 広告情報提供システム、サーバ、広告表示用端末装置、およびプログラム
US20050209996A1 (en) System and method for developing and implementing on-line marketing techniques
WO2000063771A1 (fr) Systeme de gestion d&#39;affichage electronique multi-utilisateurs
US20020052787A1 (en) Method for providing advertisement contents
JP2007102432A (ja) ランキングシステム、ランキング表示方法、サーバ及びランキング表示プログラム
JP4266929B2 (ja) コンテンツ情報処理システム、方法
JP2007164487A (ja) 美容サロン顧客情報システム、顧客情報収集送信装置、顧客情報収集送信プログラム、顧客情報収集送信方法、及び顧客情報システム
KR102466668B1 (ko) 이미지 출력기반의 수익형 apc 스마트 시스템
JP2002082870A (ja) 情報掲示板システム、情報掲示板サーバ、および情報掲示板プログラムを記録した記録媒体
JP2002056204A (ja) サービス提供システム、サービス提供方法および情報記憶媒体
JP2002329110A (ja) 予約管理システム
US20120059712A1 (en) Web enhancing systems and methods
JP2003022381A (ja) Ｃｍ枠斡旋システム
KR20020040222A (ko) 배너를 이용한 광고 시스템 및 광고 방법
JP2003187006A (ja) 教材コンテンツ作成配信システム
JP2002109089A (ja) ウェブサイト構築支援システム
JP2002112236A (ja) コンテンツ表示システム及びコンテンツ表示権利販売システム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

REF Corresponds to

Ref document number: 10190655

Country of ref document: DE

Date of ref document: 20030130

Format of ref document f/p: P

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP