RICH CONTENT MANAGEMENT AND DISPLAY FOR USE IN REMOTE FIELD ASSETS

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete and thorough understanding of the present embodiments and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:

FIG. 1 is a block diagram of selected elements of a machine to machine environment including a plurality of remotely located field assets;

FIG. 2 is a block diagram of a vending machine according to the prior art;

FIG. 3 is a block diagram of selected elements of a field asset of FIG. 1 in communication with a wireless adapter;

FIG. 4 is a state diagram showing selected states and state transitions characteristic of the field asset depicted in FIG. 3;

FIG. 5 is a conceptual representation of selected elements of a machine state representing, for example, the product inventory and environmental state;

FIG. 6 is a flow diagram of a method of providing targeted and rich content display messages according to one embodiment; and

FIG. 7 is a block diagram of selected elements of an embodiment of a rich content agent.

DETAILED DESCRIPTION OF THE DISCLOSURE

Preferred embodiments and their advantages are best understood by reference to FIG. 1 through FIG. 5, wherein like numerals indicate like and corresponding components. Where different instances of a particular element are shown, they may be numbered with hyphenated reference numerals to indicate a common design or functionality. For example, reference numerals 102-1 and 102-2 represent individual instances of a generic 102 element.

In one aspect, a machine-to-machine (M2M) network for remote field assets is described. M2M network 100 includes a collection of remotely located field assets 102, 103 in communication with a transaction processing server 110. Transaction processing server 110 communicates with a field assets 102 via a wide area wireless network or via local wireless networks using a hand held data processing device as an intermediary. Some field assets, including field assets 103, may lack wireless WAN connectivity and may, therefore, communicate with transaction processing server 110 through an intermediate field asset such as field asset 102-1. In some embodiments, field assets 102-1 may lack built-in resources for local wireless communication. In such embodiments, field asset 102-1 may communicate with hand held device 130 through the use of wireless adapter (not shown in FIG. 1).

Field assets 102 and 103 are exemplified by vending machines in which transactions likely include the sale of consumer goods stocked in the vending machine. In some embodiments, field asset 102 or 103 is an MDB compliant vending machine that includes a vending machine controller (VMC) as the master of an industry standard MDB bus to which one or more peripheral devices are connected. In addition to conventional peripheral devices such as bill validators and coin mechanisms, a field asset may include hardware, firmware, and/or software that implements a platform for providing value added functionality to the vending machine or other field asset. This collection of hardware, software, and/or firmware is referred to herein as an extended function adapter (EFA).

The EFA supports one or more beneficial capabilities that facilitate automated vending machine management. The EFA may, for example, include a audit agent that includes the capacity to perform DEX polling and to store and time stamp the captured DEX data structures.

Referring now to the drawings, FIG. 1 is a block diagram of selected elements of one embodiment of an M2M network 100 including one or more field assets, examples of which are depicted as field assets 102-1 and 102-2 (generically or collectively referred to herein as field asset(s) 102) and field assets 103-1 and 103-2. Field assets 102 are depicted in FIG. 1 as being operable to communicate with a transaction server 110. Field assets 102 may be any set of machines or devices, typically having similar functionality, that are remotely distributed and capable of engaging in some form of transaction. Examples of field assets include oil rigs, cellular phone system base stations, ATM machines, and weather monitors.

Although many different types of field assets exist, embodiments are described herein in the context of a vending machine class of field assets. Vending machines are ubiquitous machines historically used as an unmanned source of perishable and nonperishable consumer products including canned and bottled drink products, snack foods, and so forth. Details of one embodiment of a field asset are described below with respect to FIG. 3.

In the embodiment depicted in FIG. 1, field assets 102 and 103 may communicate with transaction server 110 wirelessly via alternative communication paths. Field asset 102-2 is depicted as connecting “directly” to transaction server 110 via a wireless medium and wireless network 120. Wireless network 120 may employ wireless cellular technology including the well known use of multiple base stations positioned in specified locations to communicate wireless signals across a wide geographic area.

Field asset 102-1 is depicted as being capable of communicating wirelessly with a hand held device 130 via a local wireless network 140 or directly with transaction processing server 110 via wireless net 120. Field asset 102-1 may include integrated wireless functionality, i.e., wireless hardware, firmware, and/or software to for communicating wirelessly with hand held device 130. Alternatively, field asset 102-1 may communicate wirelessly with hand held device 130 through an intervening adapter such as a wireless adapter that plugs into a DEX port of field asset 102-1. Field assets 103 as depicted in FIG. 1 communicate locally with field asset 102-1 and use field asset 102-1 to act as a relay station for information from devices 103-1 and 103-2.

The hand held device 130 is shown as connecting to transaction server 110 using wireless network 120, sometimes referred to herein as global wireless network to distinguish local wireless network 140. Local wireless network 140 may be implemented using any of a variety of short range wireless technologies including as perhaps the most prominent examples, Bluetooth and WiFi (e.g., IEEE 802.11b, IEEE 802.11g, and their derivatives).

In the case of local wireless communication, an operator conveys hand held device 130 to a location that is in close proximity to a field asset 102. The field asset 102 and hand held 130 establish a local wireless signal enabling communication between the two. After establishing a local wireless communication channel, field asset 102 and hand held 130 exchange data or information. Field asset 102 may, as an example, transmit sales transaction information to hand held 130.

Transfer of information from field asset 102-1 to transaction server 110 could be achieved by transferring the data from field asset 102-1 to hand held 130 using local wireless network 140, transporting hand held 130 to a location in proximity to transaction server 110, and transmitting the information in hand held 130 to interaction server 110 via another local wireless (not depicted) transfer. In still another alternative, information may be passed from field asset 102-1 to hand held 130 and/or from hand held 130 to transaction server 110 using a cable or other wired connection, possibly to enhance the security of confidential information.

Transaction server 110 may be implemented as a set of one or more server class computers operable to process many transactions. Transaction server 110 may include, as an example, a database management application (e.g., Oracle, DB2, etc.)

A desktop data processing system 170 is depicted in FIG. 1 as being coupled to transaction server 110 via the Internet or intranet represented by reference numeral 160. Desktop 170 includes a processor, memory, and I/O peripherals according to any of various well known desktop designs. Desktop 170 includes an operating system (OS) and a conventional web browsing application represented by reference numeral 175.

As depicted in FIG. 1, M2M network 100 includes various components that facilitate high volume transaction processing in a remotely distributed architecture that includes wireless communication elements, which may be characterized by relatively unreliable or unstable communication paths to all or some of the remote assets. The elements of M2M network 100 include (1) remote communication facilities to communicate with remote assets over multiple forms of wireless networks, (2) hand held technology suitable for mobile access to the field assets and to a transaction server, (3) server software for processing volumes of transactions, and (4) browser based access to useful information provided by transaction server 110. Although not depicted explicitly in FIG. 1, value added facilities in field assets 102 and 103 include an expandable, PC industry standard communication interface to legacy equipment. The EFA serves this last function and is described in greater detail below. In the preferred embodiment, the EFA provides a platform for interfacing to archaic or otherwise unique protocols such as Data Exchange (DEX) and Multi-Drop Bus (MDB) commonly encountered in remote field asset applications and especially in the vending machine industry.

The type of information conveyed or otherwise exchanged between field assets 102 and interaction server 110 varies depending upon the manner in which and the purpose for which field asset 102 is implemented, but the information most likely includes information about transactions that occur or have occurred using field assets 102. The transaction information referred to can include, as examples, information about when a transaction occurs and other transaction details, for example, what product or combination of products were purchased, what consumer or customer purchased the product (if known), the dollar amount of the purchase, the amount of time required to complete the purchase, the manner of payment, and other information that may be useful to vending machine operators and/or the providers of goods sold through field assets 102.

Referring now to FIG. 2, selected elements of a conventional MDB-compliant vending machine 20 according to well known prior art is shown. Vending machine 20 includes a vending machine controller 13 and various peripherals devices all connected to a multi drop bus 11. The peripheral devices consist of a coin mechanism 14, a bill validator 16, and a card reader 18. As depicted in FIG. 2, MDB provides a standardized interface for connecting vending machine peripheral devices to a VMC. Although the provision of an interface to which various manufacturers of vending machine peripheral equipment can all comply is highly beneficial, the embodiment of vending machine 20 depicted in FIG. 2 does little in terms of altering the data collection and analysis paradigm of pre-existing DEX machines and does not encompass wireless communication of stored data from the vending machine to a transaction server or other networked resource. Because peripheral devices 14, 16, and 18 are essentially “dumb” devices, all of the available data resides in VMC 13 in the form of traditional DEX data structures.

Referring now to FIG. 3, an embodiment of a field asset 102 emphasizing rich content management and display capabilities is shown. While the elements of FIG. 3 are equally applicable to field assets having reference numeral 103 in FIG. 1, the remainder of the discussion will use reference numeral 102 exclusively for the sake of simplicity.

In the depicted embodiment, field asset 102 is an MDB compliant machine or device that includes a VMC 210 connected to an MDB 211, to which a plurality of standard peripheral devices are connected. As shown in FIG. 3, field asset 102 includes a coin mechanism 214, a bill validator 216, and a card reader 212. These peripheral devices are well known devices in the field of vending machines generally and MDB compliant vending machines in particular. As implemented in FIG. 3, coin mechanism 214 and bill validator 216 connect directly to MDB 211 while card reader 212 is shown as connecting to MDB 211 using extended function adapter (EFA) 200 as an intermediary. In the depicted embodiment, card reader 212 connects to EFA 200 via a Universal Serial Bus (USB) connection 305. Card reader 212 is shown as including a magnetic strip reader 310, a Liquid Crystal Display (LCD) display 320, and a USB Interface 308, providing access to USB connection 308.

MDB 211 is compliant with the Multi-Drop Bus/Internal Communication Protocol (the MDB protocol) maintained by the National Automatic Marketing Association (NAMA). The MDB protocol is an Interface Standard that allows the various components of a vending machine to communicate to the VMC. The MDB protocol determines the way in which the VMC learns what coins were accepted by the Coin Mechanism, what bills were accepted by the Bill Validator, and how much credit is available through the Card Reader. It is a way for the VMC to “tell” the Coin Mechanism how much change to pay out or to “tell” the card reader how much credit to return to the card.

Unlike many shared bus protocols, the MDB protocol defines the VMC as the one and only master of the MDB and all other peripherals as slaves. The VMC can address packets to any of the peripheral devices, but peripheral devices cannot communicate with each other and only transmit packets to the VMC in response to receiving a packet from the VMC. Also, as suggested previously, MDB is a polling-based protocol. A significant percentage of MDB traffic consists of polling packets issued by the VMC and acknowledge packets from the peripheral devices. In most shared bus architectures, e.g., Ethernet and PCI, devices can act as masters or slaves and polling is not an inherent feature of the architecture.

EFA 200, as its name suggests, includes application extensions that enhance the features of field asset 102. In conjunction with VMC 210, EFA 200 may include, as examples, an Audit Agent 302 suitable for periodically retrieving DEX data 220 from VMC 210 to create a dynamic view of DEX data, a cashless agent 330 suitable for facilitating cashless transactions, and a rich content agent (RCA) 340 for managing and displaying rich content messages to consumers. EFA 200 may also include wireless communication functionality 360 including wireless communication hardware, firmware, and/or software for wireless communication via wireless network 120 (FIG. 1) and/or local wireless network 140.

RCA 340 operates in conjunction with a rich content display 350 connected to EFA 200 to present rich content messages to consumers and potential consumers. Rich content display 350 is preferably any analog or digital display device having QVGA resolution or better and capable of displaying still and moving images including movies and movie clips. Although rich content display 350 is preferably a liquid crystal display (LCD) device desirable for its relatively small dimensional requirements, display 350 may also be a cathode ray tube (CRT) device, a plasma display panel (PDP) device, a surface conduction electron emitter display (SED), and the like.

RCA 340 preferably coordinates the presentation of rich content messages to consumers and potential consumers based on the state of the field asset. The field asset state may include a procedural state indicative of, for example, the current stage in a sequence of transaction stages, an environmental state, indicative of, for example, time and geographical information, and a product state indicative of, for example, the current inventory of products and products prices contained in the field asset. RCA 340 may receive input from one or more other agents on EFA 200. Input from the other EFA agents may partially or completely indicate all or a portion of the state of the field asset.

As indicated above, RCA 340 encompasses content presentation management based, at least under some circumstances, on the state of a vending machine or other field asset. For purpose of the following discussion, a field asset's state is divided roughly into two components referred to herein as its procedural state and its substantive state. The procedural state of a field asset such as a vending machine that engages in consumer transactions may refer to the current stage in a sequence of transaction stages. From this perspective, a field asset may be thought of as a state machine and represented by a conventional state diagram. A simplified state diagram showing selected states of a field asset such as the vending machine depicted in FIG. 3 is presented. In the depicted representation, field asset 102 is shown as being operable to transition from an idle stage 402, in which no transaction has been initiated, to of multiple transaction sequences depending upon the form of payment presented.

If, for example, a consumer inserts coins into a coin mechanism, field asset 102 is depicted as transitioning from idle stage 402 to a coin detected stage 404, which may represent the first in a sequence (not depicted) of transaction stages applicable to coin-based transactions. The coin-based transaction sequence may include, just as examples, a coin detection stage, a coin verification stage, a coin summation stage, a transaction pending stage, a product delivered stage, and a change return stage. Similarly, field asset 102 may include transition to a bill accepted stage 406 representing the first stage in a sequence of stages (not depicted) applicable to bill-based transactions when or one or more dollar bills (or other denominations) are received by a bill acceptor/validator.

As depicted in FIG. 4, field asset 102 may also transition to a sequence of transaction stages applicable to a cashless transaction. As suggested by its name, a cashless transaction represents any transaction initiated without the use of coins or bills. Cashless transactions include credit card, debit card, and smart card transactions as well as other forms of cashless purchasing including, as examples, radio frequency ID cards, cellular phone and PDA initiated transactions, and others that will be familiar to those in the field of vending and cashless transaction processing.

As depicted in FIG. 4, field asset 102 is shown as transitioning from idle stage 402 to a card swiped stage 410 in response to a consumer swiping a credit card, debit card, etc., through a card reader of field asset 102. Card swipe may be the first action detected by the field asset in a cashless transaction and it may be desirable to present rich content to the consumer at that point. As an example, field asset 102 may detect the name of the card holder from information embedded in the card's magnetic stripe or other form of storage and use the detected name in conjunction with a welcome or other form of introductory message. If the field asset has a local database of frequent users or loyal consumers, it may be desirable to provide other forms of recognition to the consumer and possible to present the loyal consumer with a richer set of options, discounts, incentives, etc. Regardless of what type of content is desired for presentation to a consumer, field asset 102 through rich content agent 430 is enabled to permit the field asset owner or manager a great deal of flexibility.

Returning to the simplified transaction state diagram of FIG. 4, additional representative stages of a cashless transaction sequence are illustrated. In the illustrated example, the cashless transaction sequence is shown as including card swiped stage 410, authorizing stage 412, during which time the consumer's form of payment is verified for authenticity and sufficient credit, a selecting stage 414, during which time a purchase has been authorized, but the consumer has not yet selected a product to purchase, and a vending stage 416, which follows selection and delivery of the selected produce. In other implementations, the transaction stage diagram is substantially more complex than that shown in FIG. 4, with stages including transition paths back to previous stages and the addition of many other stages not shown in FIG. 4. Thus, FIG. 4, although it likely does not include detail sufficient to support an actual implementation, illustrates the concept of a field asset having a transaction state characteristic that is indicative of a current stage of the machine in a transaction stage sequence. In one aspect, RCA 340 is enabled to detect a transaction stage and to manage the presentation of rich media content based at least in part on the detected transaction stage.

The substantive state of field asset 102 may encompass parameters or characteristics that are independent of an asset's procedural state. A field asset's physical location, for example, is a characteristic that does not dependent on a transaction stage sequence, but which may nevertheless be desirable to know for purposes of presenting meaningful or targeted rich media messages to a consumer or potential consumer. For example, while it might be desirable to promote field asset products using by conveying an association between the products and a particular athletic team, conveying the correct association is dramatically dependent upon the location of the field asset. Imagine, for example, the efficacy of a University of Texas Longhorn based promotion presented on a field asset in College Station, Tex. or Norman, Okla. or a New York Yankees promotion playing on a vending machine in South Boston. Thus, one aspect of a field asset's location or geography state is the political or regional division in which the field asset is located. Another aspect to the location state of a field asset could have to do with the function of the building in which the field asset is located. Thus, for example, a vending machine owner or manager may sell third party ads for display on the display device of a field asset. The potential purchases of this third party advertising time may dependent on where the field asset is located. A field asset located in or near the show room of a new car dealership for example might beneficially display advertisements or other rich media messages for the types of automobiles sold by the dealership.

In addition to geographical state, a field asset generally and a vending machine in particular has other state attributes including its inventory state, its pricing state, and an environmental state. A field asset's inventory state refers to the quantity and selection of the products remaining in the field asset at any given point in time. Inventory state may be useful in managing rich media content to avoid, for example, displaying a promotion for a product that is currently out of stock.

Pricing state refers to the prices that each item of inventory is currently being offered at. Pricing state may be useful in managing rich media presentation by enabling, as an example, a field asset to determine a discount level to use when initiating a promotion or inventive program. If, for example, it is desired to promote an item as being temporarily sold at a specified discount, the pricing state may facilitate the use of discount percentages that are easily incorporated into the pricing structure of the machine. It would not, for example, make sense to promote a 75 cent can of soda at a 50% discount.

A field asset's environmental state may include the date and time, the external temperature and humidity, the proximity to the nearest other field asset, and essentially any other condition or characteristic that might be detectable by the field asset and potentially useful in managing rich media content presentation. Field assets may wish, for example, to promote a different mix of products at night than during the day time, or to shut down completely during one or the other. Similarly, weather conditions may be monitored and used to control rich content messages so that ice cream bars and popsicles are emphasized during hot weather while chicken soup and hot chocolate are emphasized during a blizzard.

Turning to FIG. 5, a conceptual depiction of representative information indicative of at least a portion of a field asset's state is illustrated. In the illustrated example, an aspect of machine state referred to as substantive machine state 500 is shown as including an inventory state 502, a pricing state 504, and an environmental state 506. More generally, the substantive state of a field asset may include any characteristic or parameter that is independent of its procedural state and potentially useful as a basis for managing presentation of rich media content.

In the preferred embodiment, rich content agent 410 encompasses the ability to detect a procedural and a substantive state of the field asset and to use the detected state as control inputs for managing the presentation of rich content to consumers and potential consumers. In the preferred embodiment, RCA 340 controls media presentation using a predefined, but extensible set of procedural and substantive characteristics. The developer of RCA 340 may, for example, define an interface or structure for controlling rich media presentation and make the structure or interface publicly available so that third party developers can develop the rich media content itself as well as a set of rules indicating how to manage and display the rich media content with the context of the defined procedural and substantive state of the field asset.

In some embodiments, rich media content management and presentation may be implemented as a set or sequence of computer executable instructions (software) stored on a computer readable medium. The medium may be a nonvolatile medium such as a hard disk, optical disk, or the like. During execution, all or portions of the software may be stored in a volatile storage medium such as a system memory (SRAM), cache memory (DRAM), etc. When executed by a suitable general purpose or application specific microprocessor, the software instructions produce a computer implemented method such as the content management method 600 conceptually represented in the flow diagram of FIG. 6.

Method 600 as depicted in FIG. 6 includes detecting (block 602) data indicative of a procedural state of a vending machine or other transaction-based field asset. In the context of field asset 102, for example, RCA 340 may receive a procedural state indication from cashless agent 330, another agent executing on EFA 200, or from another peripheral device entirely such as by snooping packet traversing MDB 211. Method 600 further includes detecting (block 604) data indicative of a substantive state of field asset 102. Again, substantive state may be detected from an analytical agent (see FIG. 7 below) on EFA 200.

In block 606, method 600 depicts determining a content management action based at least in part on the procedural state data 602 and the substantive state data 604. In some embodiments, the content management action includes a determination of which, if any, rich media files (i.e., rich media content) are to be presented to the consumer via rich media display device 350. Following the determination of a media content action in block 606, method 600 includes managing by taking the content action determined in block 606 and displaying the rich content on the rich content display 350.

Encompassed within method 600 is the concept of managing the presentation of rich media content via the field asset based on any of a set of characteristics and/or parameters that are detectable by the field asset and useful or potentially useful in controlling the presentation of rich media content to a consumer. For example, encompassed within the concept of detecting procedural state is the information that is known at each stage in a procedural state. Thus, the actions that may be taken at any point in a procedural state may be influenced by or otherwise managed based on any of all information that is available to the field asset at that point.

In the context of cashless transactions, for example, the cashless form of payment generally conveys a greater degree of consumer identity than other forms of payment and this identity information may be suitable for use in employing targeted rich content messaging. If a cashless user's identity is known to a particular field asset, perhaps based upon a transaction cache or other form of database that field asset 102 may retain, rich content presentation may be targeted based in part on the consumer's past purchasing activity.

Consumer identity information enables a wealth of promotional programs that integrate well with the ability to provide rich media content. Loyalty programs can be implemented once a consumer's identity is known. Loyalty program could include traditional “frequent consumer” type of rewards in the form of points that may later be redeemed for discounted or free products. In addition, loyalty programs could be implemented using “perks” in the form of interactive content that is not provided to “unregistered” consumers. For example, a loyal consumer with a demonstrated preference for a particular brand of soft drink may be invited to participate in an election or other survey associated with a television program or other event. Talent search programs that rely on viewer voting, for example, are often sponsored by the producers of consumable products. A loyal purchaser could be invited to participate in a talent search vote at the end of a transaction while the rich content display 350 is utilized to display rich media samples of the various contestants.

Identification of consumer also enables expansion of the ability to implement sweepstakes or contents through vending machine transactions. For example, the ability to identify a consumer enables a program in which winners of a contest or sweepstakes are awarded with a prize that is delivered via the web such as a music or video download. In this manner, for example, a recording artist could release a new song through a channel of field assets simultaneously with or even before a conventional web or record store release.

Even if a consumer is not located in a transaction database that is available to the field asset, the cashless agent or other application running on EFA 200 may be able to detect, or inquire about, demographic data such as the consumers gender and age, that might be used to influence presentation of messaging.

Similarly, substantive state information may be detected and used to implement various promotional efforts. Time and date information, for example, may be used to control the timing of promotional programs, new product introductions, incentive programs, and sweepstakes or contests. Moreover, as indicated previously, the graphical advertising that is presented to a user may be influenced by the substantive state so that “internal” advertisements, which are advertisements for products sold in the vending machine, and external advertisements are timely.

As suggested by the preceding paragraphs, the ability to manage rich media content meaningfully in a field asset environment to present targeted rich media messages to consumers and the ability to present rich media content using rich media hardware installed in the field assets are the cornerstones that enable a wide range of marketing and customer relation opportunities.

Referring now to FIG. 7, selected elements of an exemplary implementation of RCA 340 are depicted. In the depicted embodiment, RCA 340 includes a content management agent (CMA) 702, an XML Manifest 704, and a media player 710. Functional agents are shown as providing directives to CMA 702 while an analytic agent 720 provides the substantive state to CMA 702. In this implementation, the functional agents may include, for example, the cashless agent 330 and the directives may include the procedural state information described above. In this manner, FIG. 7 depicts CMA 702 receiving information including substantive and procedural status information from a field asset 102.

RCA 340 as shown in FIG. 7 includes an XML Manifest 704 that is accessible to CMA 702. XML Manifest 702 provides a set of content management rules that are used by CMA 702 in controlling and presenting media to a consumer. In the preferred embodiment, XML Manifest 704 is written in compliance with a predetermined structure or format. More specifically, the elements, keys, and attributes of XML Manifest 704 are specified and used by the functional agents and analytical agent 720. As an example, XML Manifest 704 preferably reflects the procedural stages that a field asset may transition through while servicing a transaction. Each procedural stage may be identified by a specified text tag. The functional agents such as cashless agents 330 may be written in conformance with the specified text tags and procedural states so that functional agents indicate the current procedural state to CMA 702 using nomenclature that is reflected in the XML Manifest 704 so that CMA 702 can easily determine the appropriate content management action to take. When, for example, a cashless transaction is in an “idle” stage, cashless agent 330 or another functional agent may send a directive in the form of a two character string such as “ID” to CMA 702. CMA 702 may then consult XML manifest 704 to determine the content management action to take. A listing of a portion of an exemplary XML Manifest is provided in an Appendix “A” located at the end of this disclosure.

Thus, XML Manifest provides a mapping between procedural or operational directives and rules for managing the media. In the exemplary XML file listed in Appendix “A” for example, the XML file maps the procedural directive “ID” to a media rule that informs CMA 702 which movie clip to play and which text messages, if any, to overlay on the movie clip. CMA 702 retrieves the “rule” indicated in XML Manifest 704 and uses the rule to send a message to rich content player 710. Rich content player 710 in turn responds to receipt of a message from CMA 702 by retrieving and executing, i.e., playing, the movie clip or other rich media content file stored in rich media content files 712.

In this manner, XML Manifest 704 specifies the manner in which CMA 702 responds to directives and other information to control the messages it sends to rich content player 710 and thereby controls the content that is played. FIG. 7 depicts an XML wizard 706 and a graphical user interface (GUI) 707 that facilitate the creation of XML Manifest 704. A developer having adequate knowledge of the rich media content or files that are available and having further knowledge regarding the manner in which rich content is to be provided to consumers, may use invoke XML Wizard 706 via GUI 707. In one embodiment, XML Wizard presents the developer with a series of questions and receives the responses. Some or all of the responses such as file names, for example, may be verified by XML Wizard 706. When XML Wizard has acquired sufficient information via the consumer responses, it generates XML Manifest 704 automatically thereby saving the developer from having to learn the nuances of the XML structure being used and ensures that the manifest has proper formatting.

Media player 710 may include elements of commercially distributed rich content players including, as examples, Adobe's Flash® player, Apple's Quicktime® player, and the like. RCA 340 as depicted in FIG. 7 illustrates a script file 714 in conjunction with rich content player 710. Some commercially pervasive rich content players such as the Adobe Flash® player employ a script file to enhance the interactivity of the player application and to extend its features to include for example presentation of text and functional buttons overlying a rich content image or movie. In one aspect, RCA 340 may facilitates consumer interactivity by enabling the solicitation of a responses from the consumer and providing features such as soft keys for receiving response from the consumer. FIG. 5, for example, illustrates script file 714 sending a “notification” to CMA 702. The illustrated notification may represent consumer input that is captured via the rich content display in conjunction with the rich content player application.

Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alternations can be made herein without departing from the spirit and scope of the disclosure as defined by the following claims.

APPENDIX “A”

<!--The Movie Loop defines Rich Content Movies (e.g., SWF) that will play in succession. The loop will run continuously until interrupted with a consumer event, i.e. a card swipe. Movies will run to completion and then move onto the next movie unless that movie's rule prevents it from running. If a consumer event prompt an interrupt, the loop will start at the beginning based on the “restart” rule. If “restart” is true, then the movie loop will start at the beginning each time the loop replays following a consumer event. If “restart is false, then the movie loop will continue playing where it left off.

Movies to be played in the movie loop are defined within the MovieLoop tag. Key “loopnode” defines the attributes of a movie to play, starting with the movie's filename. Also note that the Rich Content file extension is not included and no file paths are provided as the content manager will use discrete path for the movies (within the /movies directory). A specific movie can be listed within the loop more then one time and in any order

Within a movie node, there are additional attributes to the movie title (filename). These attributes are not required to play a movie and are only used if advanced content management features are desired.

“startdate” earliest date a movie will start to play (start at midnight). If no start date is provided, it will play immediately.

“enddate” last date a movie will paly (to midnight).

-->

<loopnode movie=“movie_1” startdate=“09-01-2006” enddate=

“09-29-2006”></loopnode>

<loopnode movie=“movie_2”></loopnode>

<loopnode movie=“movie_3”></loopnode>

</MovieLoop>

<!--The Skin element allows a skin movie to be shown on the display. Skins can be enabled/disabled on the fly as each specific stage is shown, but this element drives the skin setting at startup and during the movie loop. It is the “master setting” for the content. Skins have three attributes:

“setting” this is the setting at content start. “on”/“off” are the two allowed settings. The system defaults to on.

“textfield1” skins have maximum of two optional text variable fields. These fields are set as attributes. “textfield1” is the first text field

“textfield2” this is the second optional text field

If textfields attributes are not to be used, they need not be included as an element attribute or can be set as ““, which would place them as blank text.

-->

<!--Fade Speed Element is used to drive transitions between movies and stages. From movie to movie the transition is driven through a Rich Content fade. Fade speeds (framerate) can be set using two element attributes. Note that setting these two values is not required, as they do have default settings.

“stageFadeSpeed” sets the fade speed between stage transitions. Default: 10

“movieFadeSpeed sets the fade speed between stage transitions. Default: 5

The higher the value, the higher the speed, and thus the higher the frame rate. These values must be a divisor of 100.

-->

<FadeSpeed stageFadeSpeed=“10” movieadeSpeed=“10”></FadeSpeed>

<Rules>

<Cashless>

<Promotions loopall=“yes”>

<!--Promotions define lists of promotions, in the form of movie overlays, that are presented during the consumer's “make selection” stage. This can be in the form of featured products, which are different movies (promotions) that are shown to the consumer while the “make selection” stage (MS, see below) is being presented. While the MS stage has its own corresponding movie that plays during the stage, the featured products movie is a semi-transparent overlay to the stage movie. An example of this might be to present a specific featured brand for the month, or a new product rollout. As the content manager is tied into the entire device system, rule can be applied. For example if a product is out-of-stock, why bother featuring it to the consumer.

The “loopall” attribute directs the content manager to loop through all featured products in the list (with each consumer selection), provided their ruleset is valid.
Each promotion is defined with an attribute called “promo”

Attribute
Description

order
the order in which a promo is played or the ruleset

applied. No two orders should be the same, and they

should increment (1, 2, 3, . . . )

movie
name of the movie for the stage. Do not include

extension, swf assumed

productsku
DEX-programmed SKU for the product. Enables DEX

monitoring for out-of-stock (optional if not tied to DEX)

description
Friendly description for the featured product (or promo)

displayifOOS
Present the movie even if the SKU is out-of-stock in the

vendor (per DEX). (optional)

startdate
earliest date a movie will start to play (start at

midnight). If no start date is provided, it will

play immediatly. (optional)

enddate
last date a movie will play (to midnight). If no end date

is provided (optional)

Note that promo can be shown without it being mapped to a specific product. For example, you might want a promo that presents Mycoke.Com information (see example below). In this case, the product-based attributes do not apply.

-->

<promo orders=“1” movie=“promo_BottledWater” productsku=“1001”

description=“20oz Bottled Water” displayifOOS=“no” ></promo>

<promo order=“2” movie=“promo_Soda” productsku=“1000” description=“12oz

Can Soda” displayifOOS=“no” startdate=“09-01-2006” enddate=“09-29-2006” ></promo>

<promo order=“3” movie=“promo_BottledWater2” description=“MyWater Logo”

></promo>

</Promotions>

<StageDirectives>

<!--Stage Directives are used to map cashless stages to a movies. Cashless stages are mapped to movies via directives, which are used by the internal systems to direct the content manager to move to a next stage (and what the stage might be).

Note: Directives themselves are for internal use, and should not be edited.

Attribute
Description

name
descriptive name for the stage

directive
mapping directive for the stage. Do Not Edit

movie
name of the movie for the stage. Do not include

extension, swf assumed

skin
turn on/off the skin (optional)

time
time in the stage. Minimum number of seconds for a stage

to play (if 0, then continguous, won't stop until stage

change). note that this is minimum time as some stages

require more time to process, like remote authorization,

for example

tf1-tf4
text field 1 through text field 4, maps to variable text

fields in the movie

If a text field (defined by attribute “tfn, in which n is 1 through 4), is wrapped with an underscore, _underscore_, then it is a variable rather then fixed text. The following text field variables exist:

variable
Description

_cardtype_—
American Express, Visa, Mastercard, Discover

_cardholder_—
Consumer's name on the credit card

_totalamount_—
amount of the completed transaction set (all vends)

_vendamount_—
amount of a single vend

_diagnosticsitem_—
Internal Use Only

_diagnosticsdata_—
Internal Use Only

_movieloop_—
Please the movie loop as the stage, using the skin

for text output

_purchasestate_—
cash-only or credit, with tf2 and tf3 the credit text or

cash only text

A stage can also support questions, if appropriate. Example: Multivend change, which provides the use a chance to make another purchase without swiping their credit card. In the case of a question, the stage information is the same, except the attributes are well defined:

Attribute
Description

tf1
Primary Question to ask question

tf2
secondary question/comment (not required)

tf3
button 1 test

tf4
button 2 test

-->

<stage name=“Startup” directive=“SU” movie=“stage_normal”

skin=“on” time=“0” tf1=“_diagnosticsitem_” tf2=“Isochron, Inc.” tf3=“Austin, TX”

tf4−“www.isochron.com”></stage>

<stage name=“Idle” directive=“ID” movie=“_movieloop_” skin=“on”

time =0” tf1=“_purchasestate_” tf2=”Swipe Credit Card to Begin” tf3=“Cash Only” tf4=“Thank

You”></stage>

<stage name=“Validation Failure” directive=“VF”

movie=“stage_normal” skin=“off” time=“1” tf1=“Invalid Card” tf2=“Please Trey Again” tf3=““

tf4=””></stage>

<stage name=“Read Failure” directive=“RF” movie=“stage_normal”

skin=“off” time=“1” tf1=“Read Failure” tf2=“Please Try Again” tf3=“” tf4=“”></stage>

<stage name=“Local Authorization” directive=“LA”

movie=“stage_normal” skin=“off” time=“1” tf1=“Processing Card...” tf2=“Please Wait” tf3=“”

tf4=“”></stage>

<stage name=“Remote Authorization” directive=“RA”

movie=“stage_normal” skin=“off” time=“1” tf1=“Authorizing...” tf2=“Please Wait” tf3=“”

tf4=“”></stage>

<stage name =“Authorization Denied” directive=“AD”

movie=“stage_normal” skin=“off” time=“1” tf1=“Authorization Denied” tf2=“” tf3=“”

tf4=“”></stage>

<stage name=“Selection” directive=“MS” movie=“stage_normal”

skin=“off” time=“1” tf1=“Make Selection” tf2=““ tf3=”” tf4=“”></stage>

<stage name=“Transaction Canceled” directive=“TC”

movie=“stage_normal” skin=“off” time=“1” tf1=“Transaction Canceled” tf2=“” tf3=“”

tf4=“”></stage>

<stage name=“Vending” directive=“VG” movie=“stage_normal”

tf1=“Vending...” skin=“off” time=“1” tf2=“”></stage>

<stage name=“Multi Vend” directive=“MV” movie=“stage_button”

skin=“off” time=“0” tf1=“Make another Purchase?” tf2=“” tf3=“Yes” tf4=“No”></stage>

<stage name=“No sale” directive=“NS” movie=“stage _normal”

skin=“off” time=“1” tf1=“No Sale” tf2=“” tf3=“” tf4=“”></stage>

<stage name=“Total Sale” directive=“TS” movie=“stage_normal”

skin=“off” time=“1” tf1=“Total Sale:” tf2=“_totalamount_” tf3=“” tf4=“”></stage>

<stage name=“Thank You” directive=“TY” movie=“stage_normal”

skin=“off” time=“1” tf1=“Thank You” tf2=“_cardholder_” tf3=“For Your Purchase” tf4=“”></stage>

<stage name=“Diagnostic” directive=“DI” movie=“stage_normal”

skin=“off” time=“0” tf1=“ diagnosticsitem_” tf2=“_diagnosticsdata_ tf3=“” tf4=“”></stage>

</StageDirectives>

</Cashless>

</Rules>

</ContentManifest>

RICH CONTENT MANAGEMENT AND DISPLAY FOR USE IN REMOTE FIELD ASSETS

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

RELATED APPLICATION

Provisional Applications (1)