+

WO2000051335A2 - Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable - Google Patents

Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable Download PDF

Info

Publication number
WO2000051335A2
WO2000051335A2 PCT/US2000/004817 US0004817W WO0051335A2 WO 2000051335 A2 WO2000051335 A2 WO 2000051335A2 US 0004817 W US0004817 W US 0004817W WO 0051335 A2 WO0051335 A2 WO 0051335A2
Authority
WO
WIPO (PCT)
Prior art keywords
presentation
information
document
advertiser
invoice
Prior art date
Application number
PCT/US2000/004817
Other languages
English (en)
Other versions
WO2000051335A3 (fr
Inventor
Leonard J. Fabiano, Iii
Original Assignee
Video Networks Incorporated
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 Video Networks Incorporated filed Critical Video Networks Incorporated
Priority to CA002330297A priority Critical patent/CA2330297A1/fr
Publication of WO2000051335A2 publication Critical patent/WO2000051335A2/fr
Publication of WO2000051335A3 publication Critical patent/WO2000051335A3/fr

Links

Classifications

    • 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/04—Billing or invoicing

Definitions

  • the present invention relates generally to electronic commerce and more specifically to methods and systems for providing inventory management, video distribution and billing presentment for the cable television industry.
  • Processes and systems according to the present invention are useful for electronic commerce in a number of industries and fields. They provide better ways to manage information and workflow, conduct transactions, and distribute product. They are particularly well suited to the cable television industry, which will be used as an example for purposes of discussing the background, summary and disclosure of the invention, subject to the understanding that the invention is not limited to this industry.
  • the cable television industry buying, selling, paying for and distributing commercials and advertising are activities that involve many people, considerable coordination effort and talent, and considerable workflow and financial effort. The following is a short glossary for this industry of general importance to the present
  • a promotional media consumer such as a car manufacturer, a grocery chain, or a restaurant.
  • Advertising Agency an organization that helps advertisers to promote themselves, their goods, and/or services.
  • Promotional Media Provider a group that provides access to some form of
  • promotional media such as a TV station, a radio station, a broadcast network,
  • National Media Provider - a promotional media provider that serves a national audience: Groups like the major broadcast networks (ABC, NBC, CBS %), national cable networks (CNN, ESPN, THE WEATHER CHANNEL%) and convergent media which make at least partial use of the internet are examples of national media providers.
  • Local Media Provider a media provider which serves only a local market like a local radio or TV station, a newspaper, cable system or convergent or internet presence.
  • LCMP Local Cable Media Provider
  • Agencies help advertisers use their promotional resources effectively. Agencies assist advertisers by developing campaigns, producing promotional materials, and purchasing promotional media on their behalf.
  • Agencies are compensated for their efforts in media purchase by a taking a commission off the top of the ads that they buy. This cost is not passed on directly to the advertiser. Rather, the media providers, in this case LCMPs, absorb the cost of the agency's commission. These relationships are similar to those that occur between travelers, travel agents, and airlines. The airlines absorb the cost of travel agents' commissions for buying tickets on behalf of travelers. To a traveler, like an advertiser, the cost is theoretically the same whether the buy is direct or through an agent.
  • Advertisers pass on broad-brush information to the agency, such as the products and services they aim to promote, their promotional budget, an image they're trying to portray, etc.
  • the agency transforms this information into a campaign, which normally includes plans to produce commercials, specific promotions, and media spending plans.
  • Media planners within the agency, determine where to spend the advertiser's promotional money most effectively. Many times the promotion may take place over several different media forms among which may be local, national, and syndicated broadcast TV, radio, newspapers, coupon distribution, direct mail, cable TV networks, local cable TV, and many other forms of promotional media too numerous to mention. Wise media providers and their reps try to get involved in the media planning process to insure that they are considered in the buying process.
  • media reps spend much of their time promoting the media they represent to planners.
  • Such material might include presentations of demographic, audience, product, and brand research, along with various buying proposals. If the reps are fortunate, or they succeed in convincing the planner, they are ultimately included in the media buy. Once the advertiser approves the media plan, media buyers go ahead and place orders with media providers.
  • Metro cable viewership is normally shared between several different cable providers with their signals being constrained to only their cable runs. Cable runs are confined to strict geographical boundaries dependent on their franchise area(s). In contrast, broadcast signals travel over the whole metro region through the air. Additionally, a single cable IN provider may have several signal distribution points within their franchise areas. Then at each of their signal distribution points they will carry advertising on numerous networks, at least on the ones permitting advertising (C ⁇ , ESPN, THE WEATHER CHANNEL, etc.).
  • Reps are compensated in much the same way that an agency is compensated for its media buying services. They take a commission off of the orders that they place and bill back to the agency. So by the time an LCMP accepts an order from a rep, for national spot, they are committing to absorb the cost of paying at least two commissions, one to the rep, and one to the agency.
  • a media provider Once a media provider receives a contract, it is their responsibility to confirm back to the rep as to whether they accept it or not. They normally must accept a contract by signing its signature page and faxing back to the rep. Other times they pursue further negotiation to reach a more acceptable arrangement. In any case, once both the rep and the provider agree confirmation is made via signature and fax.
  • T&B traffic and billing
  • Advertisements or commercials are often referred to as "Copy.”
  • the agency then has to distribute them to the media providers prior to their scheduled airtime. Instructions as to where the commercials are to be aired, at which times, dates, weekdays, etc., is of primary concern to. These so-called “Copy Instructions” have to be passed on to the LCMPs so that they properly schedule the commercials to air.
  • paper based copy instructions typically accompany commercial tapes, which are transported by commercial overnight shippers and carriers, all over the country.
  • One of the major potentials for efficiency according to the present invention is to shift this Copy or content delivery from shippers and carriers to online distribution.
  • LCMPs' T&B systems make records (logs) of the commercials they air for each contract through the end of the billing cycle, usually a broadcast month. They then have the task of reconciling the spots that aired versus the spots that are ordered. This can be a time consuming and error prone process for the provider. Once they are through contract reconciliation, they produce invoices. Reconciliation is a huge subject; suffice to say here that reconciliation is necessary because all of the spots don't air exactly as wished and effort is usually required to make the advertiser whole, either by discounting the bill or airing additional content.
  • the provider gathers all of the national spot invoices and forwards them to the rep, usually via a mail carrier.
  • a few of them attempt to process their national spot invoices prior to processing their much larger job of invoices for their local clientele.
  • Others produce their local invoices first due to the fact they can expect payment sooner from their local customers than they can from their national spot customers. In either case, they eventually produce all of the national spot invoices and forward them to their rep.
  • the reps organize the invoices they receive into batches and produce a billing summary for each batch.
  • Each batch is comprised of all the provider invoices pertaining to a single agency order. Of course all of the providers don't forward their national spot invoices on the same date. Given that an invoice batch must be complete before the rep can forward it to the agency, the rep is often forced to wait for straggling invoices that can hold up an entire batch. This introduces some latency into the process. However, the largest portion of the invoices will arrive within 30 days of the end of the billing cycle permitting the rep to forward most of the invoice batches and billing summaries on to the appropriate agencies.
  • a Better Way A central theme to systems and processes according to the present invention is to automate and facilitate more efficient workflow, transaction, distribution, and information management processes among the above mentioned entities, preferably using a common document model that allows everyone at every stage in the trading process to avoid replication of effort, draw on an easily accessible (but secure), readily translatable, common data source, and otherwise deal with each other more efficiently and effectively.
  • a common document model that allows everyone at every stage in the trading process to avoid replication of effort, draw on an easily accessible (but secure), readily translatable, common data source, and otherwise deal with each other more efficiently and effectively.
  • such systems and processes can generate electronic documents where no paper document, and perhaps only a verbal dialog, conventionally exists. This is due to the fact that systems and processes according to the present invention can leverage computing power and connectivity to represent trading partners.
  • An agency may respond to an avail with an order or not even respond at all.
  • An agency may originate an order to a rep without ever issuing an avail.
  • a contract, proposal, or change When a contract, proposal, or change is accepted, the document reflects all of the contract information that the provider accepts.
  • the confirmation will contain only those elements that the provider disputes and possibly their proposed changes. Proposals, contracts, and contract changes must always be wholly accepted or declined.
  • a bill issued by a provider and destined to their rep, which details all of the spots they have aired in relation to a single contract and billing cycle. In addition it will reflect information such as networks, copy, airdates, air times, commercial scripts, lengths, etc.
  • Systems and processes according to the present function in the cable television industry to automate and promote efficiency in advertising activities, including (1) advertising strategy planning and implementation; (2) advertising sales and placement; (3) advertising content creation and distribution; and (4) invoicing, billing and payment for advertising.
  • These systems and processes are therefore well-suited for the cable television industry as it exists contemporaneous with the date of this document. They will be just as well or even better suited for advertising and other content activities in electronic media of the future, including the television, internet on home server / network, computer or set top box, convergent media on home server / network, computer or set top box, wireless media such as hand phones, personal digital assistants, pagers, simple messaging systems, and future successors to any of these.
  • systems and processes according to the present invention can be adapted to be useful in any field that contains disparate parties who must transact efficiently with each other, perhaps most relevantly in a context where product is also distributed.
  • Systems and processes according to the present invention can be implemented in any or all phases of advertising in this media, including, as recited above: (1) advertising strategy planning and implementation activities, involving advertisers and ad agencies and requiring communications and interaction between them; (2) advertising sales and placement activities, including contract negotiations to buy ad inventory and other involvement by any or all of the group of advertisers and / or ad agencies, a broker such as NCC, and media owners or providers such as MSO's or cable companies; (3) advertising content creation and distribution activities involving any or all of production entities, distribution entities, brokers and media owners or operators; and (4) invoicing, billing and payment for advertising activities, involving any or all of the foregoing entities.
  • Systems and processes according to the present invention can use a common document model so that information combined with metainformation, may be used intelligently, efficiently and effectively for various purposes, by various entities running a variety of proprietary or nonproprietary systems, to accomplish communications, negotiation, content distribution, and EBPP among other tasks requisite to carrying out the present invention.
  • the following example continues the discussion relative to the media transactions discussed in the Background section, as merely one example of systems and processes according to the present invention.
  • Reps can prepare avails on their own in-house computer systems if desired, or these can be prepared, stored and processed online (as can any other transaction or task discussed in this document) on a master platform (which can take the form of a network of servers and / or other computers, memory devices and other functionality, a single server, or as otherwise desired, in one or many geographical locations) according to the common document model and forwarded to agencies over the global information infrastructure as desired.
  • the master platform can be connected by any desired transport infrastructure or capacity, including internet, private network, or otherwise, to client platforms at the agency, the rep, media providers, and other entities participating in the systems.
  • client platforms can take the form of networks, single computers, or any other functionality; the browser or its successor can present the GUI or any other interface that is desired (“GUI").
  • the master platform can correspond to the function of current NCC roles and responsibilities, if desired. Any authorized party at the rep can monitor status of the avail via client GUI. They may also request to re-send, review, and print any previously transmitted document. Once in the hands of the agency, the authorized target may review, edit, print, and export the avail to their stewardship system or otherwise operate on the avail via their GUI connected to the master platform or the agency GUI. Edits will be permitted on avails to allow the agency flexibility prior to importing them into their stewardship system and processing them as orders. If they are satisfied with the avail, they may accept it and forward it back to the rep as an order directly from the master platform without having to travel back and forth between their stewardship system.
  • the agency client applications can also read any orders exported by an agency stewardship system and forward them to the rep.
  • the rep may wish to get tentative agreement from the local providers for the purchase of spots.
  • proposals Once proposals have passed all of the rep's in-house requirements for transmission, they can automatically be forwarded to appropriate providers.
  • the forwarding process can automatically map rep values for networks, zones, and other crucial data elements to values expected by the providers.
  • Providers may review and print the proposals with using their client systems according to the present invention. They can agree with the terms and accept proposals unchanged, disagree and decline proposals outright, or edit proposals with desired changes. In each case they can receive an online confirmation with the providers' decisions and potentially their changes.
  • Contracts, like proposals, without accepting or rejecting them, may be reviewed and p ⁇ nted by the providers. However, if they wish to accept them, they may not (usually) be edited. If they choose to decline, they may edit the contract with hoped for changes. However, the provider will have to supply their customer and order numbers so that agency estimate and customer numbers can be correlated to provider order and customer numbers for future translations. And again like proposals, confirmations are automatically forwarded to the rep upon acceptance or decline. When the provider accepts a contract they may choose to export it in a format compatible with their traffic and billing system to avoid the painful and error- prone re-keying of orders. Again, this is possible through use and leveraging of the common document model in the present invention.
  • Agency contracts may be reviewed and printed at the agency as well as exported to their stewardship systems for order processing.
  • Agencies can prepare copy instructions for their orders on their client system or the master platform for use in accordance with the common document model. Once they are satisfied with the copy instructions they may opt to forward them to the providers.
  • the master platform can determine which providers require the copy instructions, based on the contracts generated by the rep, and forward them to their many destinations from a single agency command.
  • Providers once they receive the copy instructions, may translate them or, where supported by T&B vendors, export the copy instructions in a compatible format.
  • affidavits At the end of each billing cycle (normally a broadcast month) and at the end of each contract's flight, after the providers have aired the contracted spots, they produce affidavits, bills which list they aired spots, for all of their clients, both local and national spot. For the national spot clients they will produce electronic affidavits.
  • the provider client according to systems and processes of the present invention allow the providers to review, edit, and print affidavits online or at the provider prior to transmission to the rep. Within the transmission, systems and processes according to the present invention can perform value translations on selected fields of the documents including customer number, order number, network, system, etceteras, to values understood by the rep and agency systems. Once affidavits are transmitted, provisions can be made for the providers to review their payment status.
  • affidavits After affidavits are ready for forwarding, they are forwarded to the rep.
  • the rep with their in-house computer system, can perform reconciliation of the affidavits against their contracts and add a fulfillment summary section in order to generate an invoice. This section summarizes the provider's performance against their contract.
  • This new invoice is forwarded to the agency as soon as it is generated without waiting for other providers' affidavits from the same order. This will allow the agency to proceed immediately with their reconciliation without having to wait, as is the case today.
  • Reconciliation can occur online and / or automatically on the master platform, where all avail information, contract information and affidavit information is already stored according to the common document model according to the common document model.
  • invoices arrive at the agencies' clients, they will be able to review and print any or all invoices received. After exporting them to their stewardship systems, which again can occur easily because the information has been stored and processed according to the common document model, they may perform their reconciliation processes to verify that all of the ordered spots are aired. When invoices fall short of expectation, they can submit makegoods, in the form of modifications, to start the process over again.
  • the agencies When the agencies are satisfied that they are ready to collect, they bill their advertisers. When the advertisers remit payment, the agencies will remit payment, less their commission to the reps and will send remittance of the same through
  • EBPP or other payment systems which are part of systems and processes according to the present invention.
  • the rep client when the rep client receives the remittance, it can be automatically translated to a format suitable to the rep's computer system for import.
  • the rep's system should then create remittance documents to automatically forward to the provider clients.
  • the provider client can automatically reconcile the payment against the originally transmitted affidavit so that when a provider wishes to review payment status, it will show that remittance has been received.
  • the common document model according to which all relevant information can be stored, makes this task efficient and straightforward to occur in an automated way.
  • the client can also export the remittance documents as payment transactions to the provider's T&B system.
  • invention can also include the ability to distribute advertising content or copy to the providers electronically.
  • Systems and processes according to the present invention are particularly well suited to the advertising field and cable television advertising in particular. Such systems and processes are not limited to those fields, though. They are suitable for any market or field of endeavor characterized by some or all of the following features and factors, among others: (1) the inventory to be sold is highly perishable; (2) the inventory to be sold is very sensitive to the time at which it occurs and in which context; (3) buying and selling the inventory involves significant back and forth correspondence; (4) the inventory for a single effort usually must be negotiated for and bought from multiple entities; (5) content or product must be delivered to each of the multiple entities in order leverage the value of the inventory bought and sold; (6) there are usually discrepancies between what inventory is bought and what is actually delivered; (7) these discrepancies affect the amount to be paid and require additional negotiations; (8) there is efficiency to be gained by centralizing communications and information flow.
  • Fig. 1 is a functional block diagram of an exemplary electronic commerce system for use in the cable television industry.
  • Fig. 2 is a functional block diagram of a first embodiment of an information management system according to the present invention.
  • Fig. 3 is a functional block diagram of a first embodiment of a system for distributing content according to the present invention.
  • Fig. 4 is a functional block diagram of an embodiment of an electronic commerce system according to the present invention that includes an information management system and a content distribution system.
  • Fig. 5 is a functional block diagram of an embodiment of part of the back end of an electronic commerce system according to the present invention.
  • Fig. 6 is a functional block diagram of an embodiment of part of the front end of an electronic commerce system according to the present invention.
  • Fig. 7 is a functional block diagram of an embodiment of part of the front end of an electronic commerce system according to the present invention, focusing on payment issues.
  • HTN Headline News
  • Value mapping looks for values that it knows have the potential to be mapped and keeps a list of what each trading partner calls the same thing. Mapped values within inbound documents are changed to contain common values. When a document is on its way out its mapped values are changed to agree with the destination system's expectations. Auto targeting involves examining documents as they move into the system to determine based on the document contents who the intended target (destination) should be. This technique aims to reduce or eliminate manual interpretation.
  • the conventional management tool is a browser-based Java applet that allows users to see, edit, print, and control all of their documents as if they were using an e-mail system.
  • the high volume interface allows large trading partners (such as rep-firms) who have MIS staffs to directly connect their applications to the systems.
  • the first generation trading system enabled facilitation of millions of dollars in media trade electronically every month. It has put EDI at the fingertips of trading partners to whom it would normally be inaccessible.
  • FIG. 1 A functional block diagram showing the first generation system is FIG. 1. Its main strengths are:
  • ETM electronic trade management
  • a business to business tracking server implemented in the form of a business to business collaboration toolkit ("BOBCAT") interfaces with a variety of third party platforms as well as various support databases and support functionality, including XML or other common document model databases.
  • the server may be accessed using GUI interfaces such as browsers, so that access can be ubiquitous, straightforward, quick and secure.
  • the BOBCAT server may in some respects be thought of as a workflow server.
  • Attributes of workflow in media content sales and distribution include: (1) Workflow formally models the business process; (2) Depends on work being broken down into several ordered steps; (3) Work is completed by the collaboration of many individuals with specific skills (or authorities); and (4) The collaboration often involves several businesses including media outlets and agencies.
  • the BOBCAT server implements systems and application that carry out all necessary steps in the workflow process, and that allow access to documents and data at every stage of a particular workflow process in order, for example, to negotiate and buy advertising or to pay for it.
  • One advantage of solutions according to the present invention is that they can track documents and every revision of every document exchanged in their on-line archives.
  • Each document may be stored in an XML-based form that enables very efficient search engines ready access to all documents. Users may query the archives for any document they have ever traded and view it, print it, resend it or otherwise use or operate on it. This robust functionality replaces filing cabinets and saves time in searching for documents reflecting past transactions or a particular transaction.
  • Another advantage is that the common document model allows the BOBCAT platform to communicate easily and efficiently with client platforms and legacy and proprietary T&B and other systems.
  • Another advantage of solutions according to the present invention is push: operators logged into the system can have a 'To-Do' list which contains every document or pending transaction requiring their attention. These documents remain in their To-Do' list until they take an appropriate action. As soon as they act upon the document(s) they are removed from their To-Do' list, likely landing in someone else's.
  • Current trading requires that people keep track of all of their trading activities. Keeping faxes, e-mails, voice-mails, phone-calls, paper forms, napkins, and sticky- notes organized requires planning and organization. In typical trading roles, things fall through cracks, and are lost or postponed. Common document model solutions according to the present invention potentially eliminate these unpleasant issues.
  • a workflow engine can allow for configuration of the system to match each operator's needs and workflow.
  • a trading partner can indicate all of the active trading roles that are currently active, such as buyer, account executive, sales assistant, sales manager, traffic manager, etc.
  • the workflow engine is programmed to know what actions each role may perform in any trading transaction.
  • the workflow engine can be programmed to know how documents move between the different trading roles in an organization. For example, when a sales assistant submits a contract, it moves to the responsible account executive who must approve it. When the account executive approves it, a confirmation is forwarded to the buyer.
  • solutions according to the present invention allow people to trade in the natural way that they work except that electronic documents flow between trading partners (even within the same office) rather than voice mails, paper forms, pink slips, post it notes and faxes.
  • client is used herein in the "client/server” context, to refer to a software application, rather than a customer.
  • client software happens to be used by our customers, or clients, but this is irrelevant to the discussion.
  • the client software is a client, or satellite, of the server software.
  • Client software will allow users to create, edit, and perform all kinds of functions relating to electronic documents, but the documents will reside on the operations center server(s).
  • client applications are kept as lightweight, or as "thin", as possible. To maintain software in a constantly functional state on literally hundreds of computers simultaneously would be a daunting task using conventional methods.
  • systems and processes according to the present invention build this infrastructure adhering to a strict division of labor between the client and server.
  • the client software is primarily concerned with document presentation, capture, and controlling management operations (not performing management operations). This implies that much of the functional weight of the system may be borne centrally by servers, which will reside at the operations center on the master platform.
  • the only requisite support software for client applications will be applet including if desired Java or subsequent-capable web browser.
  • Client programs that the user will see will be uploaded to their web browser on demand.
  • the server can reload only applications that have been previously uploaded, if they are changed.
  • client program When a client program is changed, it can be loaded on the server and then anyone who tries to use it will receive the update automatically.
  • users will edit and invoke document operations through their client software, the documents themselves will reside on master platform server(s), where the most significant operations against them will be performed.
  • a user views, prints, or edits a document it will be uploaded at that time to their web browser. Commands issued to save or transmit a document are executed at the server.
  • the client applications permit a user to view or control operations on a document but the real work takes place on the servers.
  • the affidavits are moved into Harry's outbound mailbox, where they are held until he takes further action.
  • ⁇ Based on the data that the server has stored about Harry's electronic trading partners, it is able to assign destinations to all of the affidavits from the batch except one.
  • the server is smart enough to know that it can't have duplicate invoices from a
  • the server generates a new affidavit, with a unique document ID, for each affidavit sent by Harry to each target.
  • the server performs a value mapping operation on these new affidavits, which replaces Harry's unique values with the rep firm's unique values.
  • Harry calls Headline News Network "HDLN” and the rep firm calls it "HLN”.
  • the server performs this mapping so that the affidavits look natural when viewed by someone from the rep firm.
  • the server receives the acknowledge command for these affidavits and goes
  • the billing manager issues the "Reject" command against the affidavit from Charlie's Shoes.
  • One of the underlying themes of systems and processes according to the present invention is the fact that they center on documents, as opposed to X12 transmission batches or application file batches. Users deal better with documents than they do with batches. Group and Interchange IDs mean very little to someone who is trying send affidavits to their rep firm. They just want them to arrive.
  • the client software looks like an e-mail system. It has "In” and “Out” boxes just like an ordinary e-mail system. Users can review any documents they receive on-screen before and after sending or receiving them. They can edit some pieces of information within certain documents when they're in a non-sensitive state. In order to protect the audit trails of interactive information systems, users are not prevented from making potentially compromising edits to certain documents.
  • any operations that can be performed on a single document may be performed on groups of documents. So if Harry selects 27 affidavits from his "Out” box, he can press the "Send” button once and all 27 affidavits will be agency (or rep) bound.
  • each user can define their own document views.
  • a billing manager at a rep firm may wish to create a custom document view that shows affidavits from a specific trading partner.
  • a system administrator for an agency may wish to view all of the documents received from a certain trading partner
  • Each trading partner has at least one user that is assigned as their administrator, who can be authorized to perform administration tasks:
  • an administrator may create document views that can include
  • An authorized user may attach any number of public or private comment lines to any document. Public comments are transmitted with the document for viewing by
  • each consumer of the electronic data is
  • Systems and processes according to the present invention automatically reformat documents when they're downloaded, to a format native to the target's information system.
  • a user of the system sends documents, they upload them to the servers, in their application's native format, and the servers automatically translate from that. This way customers do not have to be involved in any translation or deal with its complexities.
  • Customers will receive documents and import them directly into their information systems and export documents directly from their information systems.
  • Susan is concerned, being the billing manager at the rep firm, because she has to lookup the agency's estimate number, from the contract that was sent three months ago, just so she can send a paper invoice to an agency that includes their estimate number.
  • Systems according to the present invention can support as many as 256 targets or more for a single document.
  • the user initiates the "Send” operation it sends a copy specifically suited and value mapped for each target.
  • the servers address the documents appropriately. They store tables of each sender's trading partners along with cross references to their keys for those trading partners, and automatically assign targets to each the documents. The user always has the option of changing or removing a target, and when they do so, it updates the server's cross references.
  • Susan uploads a batch of contracts destined to various stations around the country.
  • the system knows that Susan's information system calls Joe's Cable in Peanut, Georgia - station 17546. So when the system sees a contract from Susan destined to Station 17546, it immediately assigns Joe's Cable as a target. Susan can still add another target, or direct it to a different one altogether, before she sends it.
  • Systems according to the present invention can auto-generate a confirmation for him from the contract he received. So instead of printing and mailing, he brings up his "Received” box, on the EC@VNI Client, and highlights the contract from the rep firm. After pressing the "En Confirmation” button, he is prompted for his contract and advertiser numbers. As soon as he enters them and presses "Send", an electronic confirmation is on its way back to the rep firm. In this example, a confirmation is sent in response to a contract without touching an in-house information system directly.
  • the client software is implemented using applets or an otherwise thin architecture, such as Java applets or
  • Java's ability to run with applets uploaded to a web browser eliminating the need to distribute the client application using media such as diskettes, CD-ROMs, etc.
  • a rich graphical interface support allows creation of applets that run from a web browser but aren't limited to the scant functionality of an HTML type language. They can literally look, feel, and act like typical Windows or Mac applications, with windows overlaying windows rendering more 3D, rather than 2D, performance.
  • Java permits ready creation of reusable classes for other applications.
  • the server operating system of choice is preferably implemented in UNIX due to the following: ⁇ Existing electronic commerce applications run on the UNIX operating system.
  • Q UNIX is supported on some of the more powerful computing platforms in the world. It offers scalability, fault tolerance, and throughput that will be required of this industrial-strength application.
  • Multi-tasking is something UNIX was designed to do from its inception.
  • the core modules in the master platform server system such as the Document Manager and Value Mapper objects, are preferably rendered using C++: Q Given the potential to be connected to hundreds, if not thousands, of clients, the core objects in the server application require as much throughput as possible.
  • ⁇ C++ has excellent support for reading and writing with streams on local devices.
  • ⁇ C++ is a very object oriented language, which allows creation of readily reusable classes.
  • the database tables for the server application preferably reside on a Sybase SQL system because: ⁇ Sybase is supported by powerful UNIX systems giving much-needed performance.
  • TCP Sockets For the foreseeable future, communications between the client and the master platform servers will take place over TCP socket connections. Should it prove necessary in the future to implement load balancing and other advanced features, it may be necessary to use something that layers over TCP Sockets, such as CORBA.
  • the list of tasks necessary to move a document between trading partners can be short or long, depending upon the requirements specific to each information system (or lack thereof). In some cases almost nothing has to be done, excepting moving the document from the sender to the target(s), while in others, it may be necessary to perform extensive validation, complex translations, large batch collations, etc. It is therefore difficult to create a far-reaching and uniform structure that will efficiently handle all of these different document management and exchange scenarios. So to jump to the heart of the matter, systems and processes of the present invention don't automatically pursue that option.
  • the server system is preferably a skeleton application that provides a number of core services, like communications and document tracking, but the validations, translations, collations, and even document routing come from smaller individual applications that, in essence, put the meat on the skeleton.
  • the server provides the glue to tie these sundry applications together into a cohesive framework.
  • All documents are preferably stored persistently on the server. No documents need reside at the client except temporarily for editing and viewing purposes.
  • the server preferably performs all operations. Even when a client is editing a document, it need only be saved at the server.
  • DBMS database managers
  • the primary data object is of a global nature, in that it can't be organized systemically within a single trading partner, mailbox, and/or user.
  • An example is a document, a document ID needs to be assigned to each document globally so that one can refer uniquely to each. However, the entire contents of a document do not really need to reside in a database.
  • Another example a user needs to be defined globally because they will each have their own login ID, password, etc. Both of these data objects share a global context where as a document view, is only used within the context of a single user. One can therefore organize document views under the context of a single user and have persistent file-based storage designated exclusively per user.
  • All documents, excepting transmission batches, are preferably stored on the server in a standard format, according to a common document model.
  • Each document type that moves through server has its own standard format.
  • When an incoming transmission batch is received at the server it will immediately broken down into individual documents and stored in their format.
  • Preferably, each form document will occupy a single file, each file will hold but a single document.
  • Only document transmission batches, that have been uploaded to the server or are to be downloaded from the server, may contain more than a single document per file. Whenever a client requests a document, it is forwarded in its standard form. Standard form documents are always translated to and from.
  • any document type contains all of the data elements required by all trading partners for the same type. So the form of a document type contains a superset of the data elements required by any single trading partner.
  • the form of an affidavit for example, contains all of the data elements required by industry standards and various industry players. Therefore, from a standard form affidavit it
  • Form documents are also mappable. This is to say that they are organized
  • Standard form documents preferably contain only ASCII characters, no non-
  • record types are consistent across all types of documents. Each provides information that may be used system wide.
  • Document Type - States the type of document such as an invoice, order, confirmation, etc.
  • Trading Partner ID - Identifies the trading partner owner of the document.
  • Origination Date/Time Indicates what date and time the document was received at or created by the server.
  • a document may contain from zero to any number of Target records. These identify to whom a document will be sent. Each target will identify a single document destination.
  • Trading Partner Name - Contains the name of the targeted trading partner.
  • Send Date/Time Indicates the date/time when a document is actually forwarded to the target. This element remains blank until the document is sent.
  • Comment (03) A comment record is always created directly by a user. These are for viewing purposes only and don't constitute usable data.
  • Q Message (04) - Messages are placed in a document by the system when some event occurs where a user needs notification of some event.
  • ⁇ ID - May contain a message ID for standard messages.
  • each form document may be defined in a tabular form and stored in Document Definition Files (DDF).
  • DDF Document Definition Files
  • This structure allows document structures to evolve and still provide usability of older versions of documents.
  • a new DDF must be produced so that the system utilities can decipher its contents.
  • a case in point, a trading partner may have many order documents archived at any given instant. Older order documents may be of a different vintage than newer ones.
  • Each DDF preferably contains the following information regarding a specific version of a document type: ⁇ The types of records contained in a document.
  • DDFs reside in a special directory and will be named according to the document type and versions they represent. Their filenames can be structured as followed "T N I I TTT.VW.def where T represents the characters of the document type and 'V the digits in the version of the document type. Thus a typical document definition filename might be "order.001.ddf.
  • Systems according to the present invention thus preferably support both lightweight document storage and heavyweight ad hoc queries by identifying the key data elements for each document type and storing instances of those key elements into a database table.
  • the strategy involves defining which data elements are "Key” to each document type in a Document Keys File (DKF).
  • DKF Document Keys File
  • the key data elements are listed by name, one per line, in the DKF.
  • the names must correspond to the data element names as defined by the DDF. Since the data elements considered "Key” for a document type will transcend versions of document types; and since database storage of key elements has moderate implications, the list of key elements for each document type will be stored in separate tables (files) from the document definitions (DDFs).
  • the server can easily determine which are the key data elements for the document type and extract only those from the documents and return them to the client.
  • the server can easily determine which are the key data elements for the document type and extract only those from the documents and return them to the client.
  • Only data elements in records of the 1 st order may be defined as keys.
  • Data elements resident in records where there may be multiple instances of that record type in a document, and therefore multiple instances of a key within a document, can not constitute a distinguishing characteristic of a document.
  • a 'Network' data element in an affidavit resides in the 'Schedule Line' record.
  • 'Schedule Line' records There can be many instances of 'Schedule Line' records in an affidavit. Therefore displaying the 'Network' of a document is not only ambiguous (because there can be many of them) but also not a distinguishing feature of any affidavit.
  • Each trading partner on systems can be configured with several standard mailboxes. Each has a specific purpose and is not optional, configurable, or capable of being renamed, as far as the client is concerned (at least initially). Documents may be moved between mailboxes as various operations are performed against them.
  • the issue can be resolved through the use of time stamps.
  • any operation is invoked against a document by the server, whether it affects the document store or not, it touches the document file so that it is time stamped.
  • the server attaches an ID record at the start of each document that contains its ID, its location, and the time stamp on the document file when it was read. If any operation against the document is subsequently invoked, the client passes back the ID record, which contains the time stamp of its latest read. The server will then compare the time stamp against the document file's current time stamp. If it has changed, the server rejects the operation back to the client informing them that changes have taken place since their last read.
  • the server puts an exclusive lock on the document file so that it can't have any other operations invoked against it. As soon as the operation finishes, the server releases the lock.
  • This approach does not require locking any files for any extended periods of time (only while a transaction is in-progress). It also permits concurrent access by an unlimited number of users. No database access is required whatsoever, and touching a file is very cheap in terms of system resources. Users can retrieve a document for editing purposes and leave it open on their workstation for hours without hurting the system whatsoever. No complex scheme is required either to notify the users of updates. The users aren't inconvenienced, except in very rare circumstances when a document is changed underneath them. In the very worst case they may have to re-read the document and re-invoke their operation.
  • a " ⁇ view name>.view” file is created that stores the crucial elements of the query, that in essence, define the view.
  • a second file is created, whenever the query is executed, name " ⁇ view>.view” which contains the document ID's of each document matching the query criterion. So if, for example, a user defined a view named "affidavit", the document manager would create a file named "affidavit. query”. When the user populated the view, a second file would be created named "affidavit.docs”. Both of these files would reside in the user's home directory (EC_ROOT/ ⁇ tp_code>/ ⁇ user name>).
  • DOM Document Operations Manager
  • DOM it is necessary for DOM to insure the integrity of each transaction executed. Since all transactions are script driven and many, if not most, occur mostly outside the context of a DBMS, DOM must insure the relational integrity of the system in the event of a mid-execution failure. Given that each step of each transaction is logged in a transaction log file, DOM can tell which transactions were not properly terminated.
  • DOM Upon startup, DOM checks for any transaction log files. If any are found, it calls up the appropriate operation from the Operations table, and invokes the specified Rollback Script, if there is one. These Rollback Scripts are responsible for cleanly backing out transactions. When the script successfully returns, DOM will delete the transaction log file itself.
  • DOM will not respond to login requests, or any other messages, until it has attempted to reverse all partial transactions.
  • a DOM will receive and operated on several standard requests from a client. DOM will always return the value SUCCESS (and potentially a result set) when it succeeds. It will return FAILURE and a text error message when it fails.
  • RegisterDoc A request for DOM to register a Document (assign it a Document
  • ExecOperation Instructs DOM to execute a stored operation on the document(s) specified by the passed Document ID(s). Examples of stored operations would be commands like "Send”, “Validate”, etc. DOM depends on scripts, registered as valid operations in the Operations table in order to carry out the requested operation.
  • Request and return messages use the same format and are variable in length, with 16 bytes required, 12 in the header and 4 in the tail. All messages will use the following format: ⁇ Client ID - 4 bytes, offsets 0 - 3
  • EOT End of Transmission
  • value can be zero, or SUCCESS, a positive integer indicating a critical error, or a negative integer indicating a non-critical error. On any error return, critical or not, the
  • the Buffer would always contain ASCII data exclusively.
  • numerous data elements are included as part of a request packet (server bound), they will be pipe ('
  • result packets (client bound) data elements are also pipe delimited. But often result packets will store result sets in buffers that will include not only data elements, but whole records and documents as
  • the buffer will have newline (' ⁇ n') delimited records, and form feed (' ⁇ f ) delimited documents. EOT will always signal the end of the buffer, as well.
  • the scripts are executed by a DOM service thread, but not natively with compiled C++. It actually invokes an instance of a shell and instructs it to execute the script.
  • the DOM thread will start a transaction in the database and create a log file that will help it to determine whether a transaction, executed via a script, has successfully completed.
  • Each script program has a reversing counterpart (rollback) script that can undo a transaction that is partially completed by its associate script. No script may be registered as a valid operation without a corresponding rollback script.
  • a script is registered in the system when it is called out in an operation record (Stored under the Operations table by the DBMS).
  • Operation records are unique to each document type. In other words, one may have a "Send" operation for 20 different document types, but there may be a different script associated with each. There is no limit to the number of operations that can be assigned to a document type.
  • Each operation names a single execution and rollback script.
  • the execution script is called when the client issues an ExecOperation request naming the operation.
  • the rollback script is called exclusively DOM on startup, if there is an incomplete transaction lurking in the system.
  • Each script is responsible for updating the transaction log file so that its rollback counterpart can do its job properly.
  • the client is responsible for passing the appropriate script arguments to the server so that it can in turn pass them along to the script.
  • DOM There is no way feasible for DOM to be aware of the number and types of arguments required by a script, so it will be the client's responsibility to supply them.
  • Request messages are sent by client instances to the Document Operations Manager requesting some action be taken.
  • the first message sent by a client must be a login request that establishes a connecting socket through which the client and server (DOM) will subsequently communicate.
  • the client is responsible for terminating the connection when has completed operations using the Logout request.
  • a DOM thread that is manning the client connection, will always check to see if the current user is authorized to perform the requested task. It will reject requests a user is not authorized to perform.
  • DOM will respond with a result message indicating success or failure. Failure comes in two flavors, critical and non-critical. When a non-critical error is returned, the client should check the returned result set.
  • a client instance Before a client instance can perform any operation or view any document, it must first connect to DOM. It does so through a TCP socket at DOM's assigned primary port following these steps:
  • ⁇ DOM receives a login request from a client that is attempting to connect passes its client ID, user name, and password.
  • ⁇ DOM assigns an available port to the specified client ID and registers them both in the port registry.
  • ⁇ DOM spins a new thread assigned to a secondary port passing it the client ID, user name, and password.
  • connection thread will stay active monitoring the port for incoming requests until:
  • connection has been inactive for more than the time-out period
  • ⁇ DOM terminates the connection because the same client ID requests a new login.
  • This request is sent by the client to retrieve selected documents in their integral form.
  • Each document requested is by its document ID that is copied, pipe- delimited, into the buffer portion of the message.
  • the thread will return SUCCESS value if it succeeds in loading all requested documents. If a single document has been requested and it fails to load the document, it returns a critical error. Finally, if multiple documents are requested and at least one document is successfully loaded, it returns a non-critical error.
  • This message is used by the client when it needs to present an abbreviated view of one or more documents and it knows their document ID's.
  • the server will return a result set containing only the key element instances of the specified documents, i.e. invoice numbers, advertiser name, agency name, etc.
  • the client will populate the request buffer with pipe-delimited document ID's for all of the desired documents.
  • the server After the server receives and validates the request message and checks the user's authorization, it formulates a SQL Query that includes all key element instances for the desired documents. After invoking the query it retrieves the elements and copies them with their document ID into a memory buffer. In following conventions, it will delimit the key element instances from the document ID's with pipe symbols ('V), key rows with newlines (' ⁇ n'), and documents with form feeds (' ⁇ f ).
  • the message After populating the buffer, it builds a result message and returns it to the calling client.
  • the message will return a SUCCESS value only if it is able to load the keys from all requested documents. It will return a non-critical error on partial loads, and a critical error when it fails to load keys from any of the requested documents.
  • a client will make this request when it wishes to save one or more preexisting documents after changes have been made.
  • the client will build a request message containing the whole, delimited contents of each document it wishes to store. It must include public and private comment records because any previously existing comment records will be overwritten.
  • Each document must start with a valid ID record containing the server assigned document ID, file location, and the timestamp of the client's last read. Once it has appropriately built the request message, it will forward it to a server thread.
  • the server Once the server successfully completes the previous steps for each document, it builds and sends a return message indicating success.
  • a message a client issues when it wishes to store a single brand new document in the system The client will prepare by building an ID record containing the target mailbox and state directory. The remaining elements of the ID record should be blank. The server will populate them after it stores the document.
  • the DOM thread When the DOM thread receives the request, it takes these actions: ⁇ It inserts a new document record in the Documents table.
  • the DBMS will create a unique ID for the document. Failure to insert the document record in the table constitutes a critical error.
  • the client In this message the client must pass an ID record containing the document ID and the timestamp of when the client last read it.
  • the DOM thread that operates on the delete request will only do so if the user is authorized to delete documents from the mailbox. Once it receives the request, it attempts to place an exclusive lock on the file. If it fails it returns a critical error indicating that an operation against the document is in-progress.
  • the client uses this message to retrieve the names and data types of the key
  • the client uses this message to build custom document views for a user.
  • the server thread After receiving and validating the message, the server thread does the following: Q It builds a SQL statement filling in the portions the client didn't in order to get a result set back from the DBMS that contains all of the document ID's that meet
  • the client can also retrieve the query text and view it should they wish.
  • a client will send this request when either a view has previously been created
  • the server will return a result set that includes key element instances for all of the documents named by a view or state/doc type.
  • GetQuery Request After retrieving the key instance information, it will pack them appropriately delimited into a message buffer returning the result to the client.
  • This message allows the client to retrieve the query text associated with a
  • the client will put the view name in the buffer portion of the
  • the server Upon receiving the request, the server will attempt to gain an exclusive lock
  • the client to register a batch, once it has been uploaded.
  • the client must initialize
  • the DOM thread After receiving the request, the DOM thread will try to find the file and move it
  • a request a client makes when they are trying to present a user with a list of
  • the client must pack the buffer section. It must contain the document type being
  • the server When the server receives the message, it will either query the TPXRefs or the
  • MBDocTypes table for potential trading partners and mailboxes. It will query the TPXRefs table if the client only wants to look at trading partners it has used in the
  • a client makes this request when it needs a list of the targets assigned to a
  • the server will query the DocTargets table and respond with a complete list of
  • the client instructs DOM to add a target to the specified document.
  • the client must pack the document ID, target trading partner, and target mailbox into the buffer portion of the request.
  • DOM will attempt to insert the desired target into the DocTargets table.
  • a client may request that the server delete the target, specified in the buffer section, by its tp_code and mailbox.
  • DOM Once DOM receives and parses the message, it will attempt to delete the selected target from the DocTarget table.
  • DOM will respond to this request by querying the Operations table and returning all of the valid operations for the document type specified by the client.
  • the client will pack the buffer portion of the message with the document ID's and desired operation to be invoked.
  • the client must also pack any arguments
  • the server When the server receives the message, it will unpack the document ID's and
  • server utilities are preferably implemented as command line executables. Later, a scheme may be devised where they become daemon processes, where they always stay loaded in memory, an control their operation
  • This object is designed to move, or copy rather, documents from a source mailbox to a target mailbox. It takes arguments for document ID and state. It utilizes records stored in the DocTargets table to determine which targets a document should be routed. Once it has a list of all the targets, it performs the following steps for each: u Creates a new copy of the original document, excluding any private comments.
  • the table will assign a new document ID.
  • TPXRef instances are used to help trading partners identify with which other trading partners they actively trade.
  • Transmission batch parsers are nothing more than translation utilities that converts multiple application form documents in a single file to single VNI form documents in multiple files.
  • the value mapper utility takes arguments for a document, its source trading partner, and target trading partner. Its purpose is to change values from meaningful to the source into values meaningful to the target. It depends on the ValueXRefs table, to tie the values together, and on the DocTypeKeys table, to tell it which data elements need to be mapped.
  • the ValueXRefs table ties each trading partner's values to VNI values, which represent a central standard. This way requires maintaining fewer value relationships.
  • the ValueXRefs table is updated programmatically by various translators and parsers. It will also be updated manually by our system operators.
  • the DocTypeKeys table identifies the elements of a document type that potentially need value mapped. It can be maintained manually whenever a document type is added or updated within the system. Once invoked, the value mapper will query the DocTypeKeys table and build a list of those elements that need mapped. It will then walk through the list and for each element perform the following steps: ⁇ Retrieve the current element value from the position identified by the DocTypeKeys record.
  • This utility is charged with attempting to address, find targets for, a document based on past trades with trading partners.
  • When invoked against a document it will lookup past trading partners based on data elements that have been identified as trading partner names. It will then look, in the TPXRefs table, for a trading partner that has a matching name. After finding a match for the document, it will add a target for it.
  • This utility is used to populate the Keylnstances table. Keylnstances of documents are used for creating abbreviated views of documents and supporting ad hoc queries against them. This utility will take an argument for a document ID. With the document ID it will query the DocTypeKeys table for locations of the key elements. It will then extract the key elements and store them in the Keylnstances table.
  • Systems and processes of the present invention not only track ordering and paying for advertising and other content, or any other product; they also include systems and processes for delivering it.
  • systems and process according to the present invention can replace overnight shipment of video tape ads with fast, reliable, all-digital transport of video assets between cable ad sales offices, interconnect offices and head-ends.
  • the digital content can be transmitted to the local head-ends via a hybrid satellite/terrestrial IP data network, and imported directly into digital ad insertion equipment.
  • contend distribution systems and processes are more than just a media delivery service.
  • a preferred embodiment of a content distribution system according to the present invention contains four major sub-systems:
  • the Video Submit Station which may be located at the operations center is used to transmit the media content by way of a high speed terrestrial line to the Network Operations Center (NOC) and schedules delivery of media content to the appropriate local head-ends.
  • NOC Network Operations Center
  • the Multicast Distribution System located at the NOC transmits the encoded media content via satellite, the internet or as otherwise desired to the appropriate head-ends per the schedule established by the head-end's Traffic & Billing system.
  • the Remote Archive System also located at the VNI NOC, stores the encoded media content for future use by TTV personnel.
  • the Receive Server/Router located at the head-end notifies the Multicast Distribution System via the Internet (or other telecommunications pathway), when media content has been received successfully (or not). It also forwards the received data via LAN/WAN to local video servers and caches the locally for later recall.
  • a web-interface allows the user to establish the distribution receive servers, view the archive and schedule delivery.
  • the on-line transaction logs allow the user to track video from submission to VNI to delivery at the head-end.
  • the systems and processes provide the ability to exchange business critical data between operations and the remote head-ends. Data such as traffic schedules and play-to-air logs are commuted on a daily basis. To better manage the entire process, the head-end's spot inventories can be updated at the NOC continually.
  • the systems and processes can be remotely monitored by on a 7x24 schedule. Errors are caught and reported when any of the following events occur:
  • the Video Submit Station is the media management system. The key attributes of the Video Submit Station are described below.
  • All Video Submit tasks can be executed using the system's web Interface or the server-to-server API set called the Video Drop Box.
  • the web interface is an intuitive, easy-to-use screen, with well-organized menus, toolbars, and windows. When commercials are submitted, they are identified with a title ID, unique spot ID number, and optional description. The system provides the user the options to schedule distribution at this time, or store the media for distribution at a later date.
  • the Video Drop Box receives spots from the current popular digital insertion systems in cable (Seachange and Skyconnect) or any such systems when submitted and registers each automatically. In this manner, a spot needs only to be encoded and submitted. Then whenever that online spot is referenced in the Insertion schedules it is automatically scheduled for distribution to the headend inserters.
  • This system operates invisibly to the insertion operator.
  • the operator encodes spots and selects batches of spots for transfer to the HQ or MVL system (to name a couple) and the Video Drop Box picks up those submissions and acts automatically to distribute them to the headends.
  • the system can support several formats including MPEG 1 , MPEG 1.5 and MPEG 2 as well as JPEG, M-JPEG and any proprietary data formats used in the industry.
  • the bit-rate of the commercials (or other material) is immaterial to the transport system and spots with data rates of 500Kbps through 50 Mbps can be transported. Higher data rates will take longer to transmit in a fixed data rate scenario such as is being proposed here.
  • the user can specify the length of time the media content is to be archived.
  • the system allows the user to search for keywords in the title and description located within the inventory.
  • the user can also search by various media attributes such as format, bit-rate or date received.
  • All head-ends intended for video distribution are identified as receive servers in the system.
  • the system allows operations to combine many head-ends into groups or create ad-hoc groups dynamically for easy distribution.
  • the user can identify groups by region, client or time period. Once a group is no longer necessary it can be deleted from the list.
  • Distribution Schedule Users can access the Distribution Schedule with the web interface.
  • the user can view the spots for distribution on-line with delivery time estimates.
  • Commercials that are scheduled for distribution can be reviewed, edited, re-prioritized or deleted from distribution. Once the media has been delivered, the entry disappears from the schedule.
  • the Multicast Distribution System is based on an algorithm which calculates the distribution priorities based on the T&B schedule for when, the number of head- ends, channels and times the spot will air.
  • the user has the ability to override the computer generated schedule.
  • the system gives the user the ability to track the status of media as it is received by the head-end. Status can be queried based on date, head-end or media
  • Multicast Distribution System This interface allows the user to query the storage requirements of media elements in the archive.
  • the Multicast Distribution System is a hybrid satellite/Internet communications system incorporating a reliable transport protocol to ensure the successful delivery of content packages and other information to head-ends.
  • the key attributes of the Multicast Distribution System are described below.
  • the Multicast Distribution System employs the IP multicast technique via satellite to dynamically establish groups of head-ends and transmit media content to them.
  • the Video Submit user can designate the group(s) of head-ends to which the media is to be delivered.
  • the Multicast Distribution System employs a digital satellite uplink system for one-way transmission to the head-ends.
  • the uplink transmits a QPSK-modulated waveform in compliance with DVB standards.
  • the first is a standard Internet based return path. This consists of a dial-up connection from each receive site to the nearest ISP for local calling access. This keeps the connection costs to a minimum.
  • the second option for return path connectivity proposed here utilizes VSAT transport.
  • the Multicast Distribution System utilizes a reliable transport protocol to facilitate the delivery of media content and other information to the head-ends. This protocol enables the Multicast Distribution System to keep track of which head-ends have received transmissions successfully and which head-ends are having trouble.
  • the Receive Server Upon receipt of a transmission, the Receive Server sends a message back to the Multicast Distribution System via the return channel to confirm that the transmission was successful or to indicate which packets (portions) of the transmission were not received successfully.
  • the Multicast Distribution System re-transmits missed individual data packets as needed until all head-ends have received the transmission successfully, or until a threshold for the number of retries has been reached.
  • the Remote Archive System is located at the NOC and is available to operations for storing media content.
  • the Remote Archive System has the following key attributes:
  • Receive Server/Router located at each of the remote head-ends to receive media content.
  • the key attributes of the Receive Server are described below.
  • the Receive Server When alerted that a transmission is targeted for it, the Receive Server automatically establishes a return path connection to the Multicast Distribution System. In the Internet scenario if the local ISP's connection is unavailable, the Receive Server will automatically dial a pre-configured 800 number for access to the ISP located in the NOC. This helps ensure success of the return channel connection in the Internet scenario, even in the event of a local ISP outage.
  • the Receive Server/Router also routes data traffic from the satellite data channel to local LAN or WAN based network devices (routers, servers, etc.) using standard network protocols such as Ethernet and IP. Its on-board hard disk also acts as a cache of received content in cases where immediate routing of data to local devices is unavailable.
  • the Receive Server includes a receive-only satellite antenna and digital satellite receive card capable of processing DVB-compliant waveforms.
  • the Receive Server will receive its satellite feed from GE-1.
  • Another Distribution System provides hard interconnect functionality to a metro market without the expense and limitations imposed by traditionally implemented hard interconnects. As a bonus, it is far more affordable and can be implemented more quickly than a terrestrial fiber solution. Functionality includes the ability to distribute schedules and spots, gather verification information, handling of agency orders electronically, and simplified spot reconciliation against orders to only list a few benefits.
  • Fig. 4 shows content being submitted to operations center in two ways.
  • the first (a) is the more traditional method of air courier service. Once at operations, the content is encoded and the Spot ID is assigned, such as according to its ISCI code.
  • the other method (b) shows video submitted using a frame-relay network. With this method Agencies have fixed bit-rate encoders that automatically encode and submit video. Once at operations the spot is transcoded into the proper format and the Spot ID is added.
  • video from the agency (D&S) and order instructions from the media provider's interconnect are submitted to the Network Operations Center (NOC).
  • NOC Network Operations Center
  • systems according to the present invention preferably support any desired platforms for export including MPEG2 Program Streams, MPEG2 Transport Streams and MPEG 1.5. Maintaining customer local site profiles to ensure the correct MPEG file is delivered in the correct local system format is helpful to enabling this feature.
  • the ISCI code will also be embedded in the data stream for later use in verification. Ads will remain in inventory until a buy is associated with the ad (ISCI code).
  • a media delivery scheduler will build multicast groups.
  • the system will create these groups based upon daily interconnect buys and deliver the spots over satellite. Delivery verification and status information will be available to interconnect real-time throughout the delivery process. If for any reason video cannot be delivered within a defined set of parameters (i.e. three tries within 3-hours) the system can send the spot on tape via shipper to that site.
  • the regions identified for placement may be chosen based upon a hybrid ratings tool that compiles market demographic data and ratings information to facilitate optimized market buys.
  • This pre-buy tool can be available on-line. In turn this data can be used by agencies in conjunction with existing schedule building tools from the interconnect.
  • sites can receive their media via satellite. Once received at the ASO or even subtending headend, a utility notifies system personnel that spots have been delivered. The spots can be imported into the MVL or local video archive and matched against the scheduling data received electronically prior to video transmission. If additional subtending sites are present and connected via fiber, customers will conduct business as usual from this point. Otherwise they may wish to have delivery of the spots directly to the subtending sites.
  • the process of delivering content to subtending sites automatically based upon orders to specific ASO's / regions can be performed. If at the local level the spot is renamed, this need not effect the verification process as the ISCI code is imbedded in the playback stream. This process is suggested to eliminate problems associated with ASO's or local headends changing the spot title or ID in the T&B system.
  • a "sniffer" box can be placed on the back-end of the insertion playback device and continually search for embedded ISCI codes in the playback stream. When a code is detected, it will record the time, ISCI, length of playback and network. This data will be saved and the logs sent to the ASO, then on to operations. These uploads can be scheduled to happen at regular intervals throughout the week (i.e. once daily at 7:00 PM) and can be done over the Internet using the provided ISP account that is part of all VNI satellite receive station configurations.
  • operations can reconcile the data against the delivery instructions or contract data stored in the master platform to immediately determine if make-goods are necessary. This data is also immediately routed to the interconnect for processing where the data will go through another reconciliation against the agency order, then processed for billing.
  • Inventory Management the system manages a database of video and corresponding traffic data for every piece of interconnect spot video placed onto the interconnect. In placing ads, the system ensures that interconnect management is only aware of its reserved inventory and that all orders are cleared against the same. From the local level, summarized interconnect usage can be made available through a simple web interface.
  • the distribution systems may be capable of receiving and placing electronic
  • Schedule Optimization This feature is a predictive tool that analyses the impact of a buy order, then recommends means to accommodate the buy while providing a snapshot of the buys effects on existing and remaining buys. Using variables such as ordered dayparts, networks, and geography, spots can be shifted in the schedule to allow others to clear unless prevented by buy parameters. Used by interconnect, if this optimizer cannot clear an order as requested, an electronic change request may be forwarded to the buyer with suggestions of what can be bought that will clear. This way it becomes much easier to manager buys across the interconnect while enabling optimal usage.
  • interconnect at the NOC, interconnect, and at the local operators. Each day the local operators download orders and modifications for interconnect using the network. Since all transactions are electronic, re-keying of interconnect
  • interconnect contracts contain no reference to the advertiser or
  • Copy Instructions Copy instructions are downloaded each day using the network, and processed with the incoming interconnect contracts and modifications. These copy instructions, received electronically utilize the agency-assigned ISCI codes that uniquely identify each commercial. Physical copy and their pertaining instructions are under interconnect's control.
  • Verification/Makegoods Using data gathered by the local "sniffer" box, the system will reconcile the information against the orders placed. This can be done in a number of ways but fundamentally it will first gather (or the local system will submit) the information from the local sites and compile it regionally or by ASO. Next the regional data will be pulled into the NOC, using the master platform functionality if desired, processed, then immediately sent to the interconnect for final reconciliation and billing purposes. These log files will be sent to the interconnect on a daily basis. If in the process of gathering this data the system finds a spot did not run for whatever reason, the system will re-schedule makegoods following predetermined fulfillment measures. Included in this is notification to the sales associates so they can issue makegood requests to the buyer. With verification taking place daily, in-flight makegoods are very possible yielding much higher fulfillment than typical interconnect spot buys in cable.

Landscapes

  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention concerne des systèmes et des procédés de commerce électronique, qui sont adaptés pour gérer le déroulement des opérations, les informations et la distribution des produits au cours de transactions entre différentes parties dans une chaîne de distribution. Les systèmes et procédés peuvent dépendre d'un modèle de document commun qui permet à chaque entité de mettre à jour et d'utiliser ses propres interfaces et systèmes existants ou exclusifs, mais qui exige de communiquer et de faire des transactions entre les parties par une plate-forme maîtresse ou un système qui traite des données et des métadonnées associées, comme via un modèle de document commun, de façon que toutes les plate-formes soient dotées d'un accès aux informations communes rapide, efficace et facilement traduit ou transformé. Ces systèmes et procédés sont particulièrement bien adaptés pour l'acquisition, la distribution, le paiement et d'autres transactions dans l'industrie de la télévision par câble, y compris des transactions associées à la publicité et aux messages publicitaires.
PCT/US2000/004817 1999-02-26 2000-02-25 Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable WO2000051335A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA002330297A CA2330297A1 (fr) 1999-02-26 2000-02-25 Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12213699P 1999-02-26 1999-02-26
US60/122,136 1999-02-26

Publications (2)

Publication Number Publication Date
WO2000051335A2 true WO2000051335A2 (fr) 2000-08-31
WO2000051335A3 WO2000051335A3 (fr) 2001-01-11

Family

ID=22400873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/004817 WO2000051335A2 (fr) 1999-02-26 2000-02-25 Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable

Country Status (2)

Country Link
CA (1) CA2330297A1 (fr)
WO (1) WO2000051335A2 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU784696B2 (en) * 2000-04-06 2006-06-01 Fidelity Information Services, Llc Electronic bill presentment and payment systems and processes
US20170124589A1 (en) * 2015-11-02 2017-05-04 Turner Broadcasting System, Inc. Audience proposal creation and spot scheduling utilizing a framework for audience rating estimation
US20170289600A1 (en) * 2016-04-05 2017-10-05 Turner Broadcasting System, Inc. Allocation of under delivery units utilizing an optimization framework
US20180316957A1 (en) 2011-10-12 2018-11-01 Turner Broadcasting System, Inc. Advertisement scheduler
US20180357657A1 (en) * 2017-06-13 2018-12-13 Turner Broadcasting System, Inc. Promotion Planning for Managing Allocation of Inventory Mix Utilizing an Optimization Framework
US20180357677A1 (en) * 2017-06-13 2018-12-13 Turner Broadcasting System, Inc. Managing Allocation of Inventory Mix Utilizing an Optimization Framework
US10834451B2 (en) 2018-01-09 2020-11-10 Turner Broadcasting System, Inc. Dynamically scheduling non-programming media items in contextually relevant programming media content
US11064234B2 (en) 2015-09-01 2021-07-13 Turner Broadcasting System, Inc. Targeting and demographics scheduling utilizing a framework for audience rating estimation
US20230419369A1 (en) * 2017-09-11 2023-12-28 Turner Broadcasting System, Inc. Cross-platform proposal creation, optimization, and deal management

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2369973B (en) 2000-12-06 2002-12-04 Open Business Exchange Ltd Communication Router

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5117353A (en) * 1989-05-05 1992-05-26 Staff-Plus, Inc. System for use in a temporary help business
US5202977A (en) * 1990-07-13 1993-04-13 Premenos Corp. Edi translation system using plurality of communication processes and de-enveloping procedure corresponding to transmitted communication process
US5491325A (en) * 1992-08-25 1996-02-13 Huang; Dorge O. Method and system for payment and payment verification
US5926806A (en) * 1996-10-18 1999-07-20 Apple Computer, Inc. Method and system for displaying related information from a database

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU784696B2 (en) * 2000-04-06 2006-06-01 Fidelity Information Services, Llc Electronic bill presentment and payment systems and processes
US20180316957A1 (en) 2011-10-12 2018-11-01 Turner Broadcasting System, Inc. Advertisement scheduler
US10701423B2 (en) 2011-10-12 2020-06-30 Turner Broadcasting Systems, Inc. Advertisement scheduler
US11064234B2 (en) 2015-09-01 2021-07-13 Turner Broadcasting System, Inc. Targeting and demographics scheduling utilizing a framework for audience rating estimation
US20170124589A1 (en) * 2015-11-02 2017-05-04 Turner Broadcasting System, Inc. Audience proposal creation and spot scheduling utilizing a framework for audience rating estimation
US11669862B2 (en) 2015-11-02 2023-06-06 Turner Broadcasting System, Inc. Audience proposal creation and spot scheduling utilizing a framework for audience rating estimation
US11093968B2 (en) 2015-11-02 2021-08-17 Turner Broadcasting System, Inc. Audience proposal creation and spot scheduling utilizing a framework for audience rating estimation
US11343555B2 (en) 2016-04-05 2022-05-24 Turner Broadcasting System, Inc. Allocation of under delivery units utilizing an optimization framework
US20170289600A1 (en) * 2016-04-05 2017-10-05 Turner Broadcasting System, Inc. Allocation of under delivery units utilizing an optimization framework
US12081819B2 (en) 2016-04-05 2024-09-03 Turner Broadcasting System, Inc. Allocation of under delivery units utilizing an optimization framework
US11423431B2 (en) 2017-06-13 2022-08-23 Turner Broadcasting System, Inc. Promotion planning for managing allocation of inventory mix utilizing an optimization framework
US20180357677A1 (en) * 2017-06-13 2018-12-13 Turner Broadcasting System, Inc. Managing Allocation of Inventory Mix Utilizing an Optimization Framework
US12211060B2 (en) 2017-06-13 2025-01-28 Turner Broadcasting System, Inc. Promotion planning for managing allocation of inventory mix utilizing an optimization framework
US20220335465A1 (en) * 2017-06-13 2022-10-20 Turner Broadcasting System, Inc. Promotion planning for managing allocation of inventory mix utilizing an optimization framework
US20220391950A1 (en) * 2017-06-13 2022-12-08 Turner Broadcasting System, Inc. Managing allocation of inventory mix utilizing an optimization framework
US11615434B2 (en) 2017-06-13 2023-03-28 Turner Broadcasting System, Inc. Promotion planning for managing allocation of inventory mix utilizing an optimization framework
US11631112B2 (en) 2017-06-13 2023-04-18 Turner Broadcasting System, Inc. Managing allocation of inventory mix utilizing an optimization framework
US11282115B2 (en) 2017-06-13 2022-03-22 Turner Broadcasting System, Inc. Managing allocation of inventory mix utilizing an optimization framework
US20180357657A1 (en) * 2017-06-13 2018-12-13 Turner Broadcasting System, Inc. Promotion Planning for Managing Allocation of Inventory Mix Utilizing an Optimization Framework
US20230419369A1 (en) * 2017-09-11 2023-12-28 Turner Broadcasting System, Inc. Cross-platform proposal creation, optimization, and deal management
US12086841B2 (en) * 2017-09-11 2024-09-10 Turner Broadcasting System, Inc. Cross-platform proposal creation, optimization, and deal management
US11700406B2 (en) 2018-01-09 2023-07-11 Turner Broadcasting System, Inc. Dynamically scheduling non-programming media items in contextually relevant programming media content
US10834451B2 (en) 2018-01-09 2020-11-10 Turner Broadcasting System, Inc. Dynamically scheduling non-programming media items in contextually relevant programming media content
US12250422B2 (en) 2018-01-09 2025-03-11 Turner Broadcasting System, Inc. Dynamically scheduling non-programming media items in contextually relevant programming media content

Also Published As

Publication number Publication date
CA2330297A1 (fr) 2000-08-31
WO2000051335A3 (fr) 2001-01-11

Similar Documents

Publication Publication Date Title
CN102474658B (zh) 管理包到视频服务提供商的分发的集中式内容管理系统
US7865394B1 (en) Multimedia messaging method and system
US9384483B2 (en) Method and system for globally sharing and transacting digital contents
US7325027B2 (en) Software, method and system for data connectivity and integration having transformation and exchange infrastructure
US7590586B2 (en) Method of and system for auctioning off commercial frames for on-air content and method of and system for automatically sending on-air content
US20030158789A1 (en) Electronic merchandise distribution system, electronic merchandise distribution method, and program
US20080091846A1 (en) Creation and transaction processes of intelligent documents
US20040103026A1 (en) Method of and apparatus for designing advertisements by using digital media assets
US20060095338A1 (en) Strategies for gifting resources
US20020107752A1 (en) System and method for integrating web-originated orders with backend business systems
JP2004538547A (ja) コンピュータネットワークにおけるデータの相互運用と操作のための方法と装置
KR20050027134A (ko) 다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템
US20090076918A1 (en) Advertisement-Supported Shipping
US20060092966A1 (en) Internet portal system and method employing handheld device that connects to broadcast source
WO2000051335A2 (fr) Systemes et procedes de commerce electronique, specialement destines a l'industrie de la television par cable
US7979325B2 (en) Online merchandising system, server, estimation managing method, computer program product, and computer data signal
US20130041762A1 (en) Systems and Method for Real-Time Media Placement
US20090055479A1 (en) Method of transferring data between different types of computer systems
US20030110140A1 (en) Method for facilitating pricing, sale and distribution of fuel to a customer
US20060004761A1 (en) Integrated mail-piece tracking and on-line document viewing
KR20040009343A (ko) 멀티미디어 메시징 서비스 제공 시스템 및 그 방법
US7577622B1 (en) Method, apparatus and medium for data management collaboration in the transport of goods
JP2004094944A (ja) チケット購入システム、購入仲介システム、チケット購入画面サーバ、チケット購入管理システム、チケット購入管理方法、サプライヤ予約システム及びサプライヤ予約方法
Esichaikul et al. Selecting an EDI third-party network
EP2248047A1 (fr) Dispositif d'echange de documents entre deux parties a travers un reseau

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CA MX US

ENP Entry into the national phase

Ref document number: 2330297

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: PA/A/2000/010623

Country of ref document: MX

AK Designated states

Kind code of ref document: A3

Designated state(s): CA MX US

WWE Wipo information: entry into national phase

Ref document number: 09674221

Country of ref document: US

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载