Essentials:
   Home
   Definition
   Requirements
   Company
   Mission

History:
   1981 - NewsPeek
   1983 - GIN
   1989 - SmarTV
   1992 - GenMagic
   1994 - CDML
   1994 - Social Ads
   1996 - Venue OS
   1999 - Lumeria
   2001 - OpenPrivacy

* The History Behind Broadcatch

SmarTV (1989)

The following was written as an internal memo in July of 1989,
and is re-printed here unchanged except for formatting for HTML.


Overview of SmarTV operating systems

Please note that I have taken great care to minimize any use of acronyms. I am not convinced at all that acronyms enhance communication. The following is a thumbnail sketch of the SmarTV system.

SmarTV is primarily a service, which includes: data sorting and retrieval, communications, and software controller updates.

The user, however, experiences SmarTV ("mod 3") as a piece of hardware that s/he hooks to hir VCR(s) and telephone, and which controls them in an "intelligent" fashion, personalized for every user.

The backend (user) hardware is described as this is a necessary part of the whole system, essential to our being able to initially test, debug, and actually generate a market where one does not exist today.

Metaview Corporation does not, however, desire to continue to build and market hardware. We would like to see VCR manufacturers incorporate SmarTV intelligent interfaces into their systems, perhaps paying a small fee to Metaview for use of the name as a selling point (much like the Dolby trademark is used). (Future: Note that for several so-equipped VCRs to work together, they will have to be able to operate in a master/slave fashion, with some sort of standard (MIDI-style?) protocol between them.)

Remember that one of the important goals of SmarTV is simply to aid the user to program their VCR more reliably. One way SmarTV helps in this regard is, if it is doing it's job, the show is already programmed in for the user, and all the user has to do is verify (by name and channel, not channel and date/time) that the show actually will be recorded. Failing that, the user programs hir VCR in the normal fashion, and can request a check, which could be immediate (perhaps at higher cost) or within a specified time (say, 24 hours).

Questionnaire / User Profile

A questionnaire provides the initial seed to the system. It is designed to be simple, short, and effective at generating a user profile which will be translated (hopefully, by mechanical means) into the search strategy used to sort through the TV Listings database and provide a subset of programming personalized to the end user.

Note that this step could be foregone by someone who desires to start by "reading the manual" and program it entirely via the on-screen interface. This is not recommended, and in fact may be impossible on early units.

The questionnaire is a key element to our initial success, and must be designed with great care. It is intended to provide general guidelines of viewer tastes, and not expected to make serendipitous predictions. In other words, special programs outside the realm of general user viewing will have to be entered (as Exceptions) manually.

While client systems are being prepared for use, we can gain some degree of knowledge about questionnaire design by creating a task force to prepare such a beast.

Given the limits of technology in the server (release 1), some of the questions may not be useful to the system. This feedback loop can continue until we feel that we have a good starting point.

Once the Server is running, we can begin "beta" testing of the questionnaire (and server!) on the WELL. This can be accomplished by having people fill out their questionnaires, feeding this information into their separate "profiles," and sending them a weekly mailing of what they would have watched if they had a SmarTV system. (This assumes that we can contract with TV Listings to give us (last-) weekly programming updates.) This may actually work better than predicting what to watch, as people will be able to measure SmarTV's choices versus their own, unbiased choices of that week. (It might make for some very critical TV guide reading...)

Each time the SmarTV system makes a mistake in "judgement" and is corrected by the user, the profile may be updated.

Host System (Server Backend, or Blair's "AI Head-end")

Origin of data is the TV Listings, Inc. (Fort Worth, TX) database. They provide listings of all TV shows at various qualities (and prices) of data description, and virtually in any (text) format.

The SmarTV Host System maintains a copy of this information which it indexes for easy access according to a proprietary set of selection rules. (The better selection rules makes the better product.)

These database updates occur via outgoing modem connects to the TV Listings database at regular intervals. Of course, a better scheme would be to have TV Listings call the SmarTV Host when new data is available.

The SmarTV Host System has a series of auto-answer modems connected to it which receive data request calls from the client systems requesting personalized updates. (What do we call these updates? How about "SmartListings"? How about "WYWIWYG" (What You Want Is What You Get))

The SmarTV Host System maintains, for each user (actually, for each unit by hard coded unit number burned in ROM at the factory) the current search strategy (user profile), and uses this to continuously update the outgoing SmartListings file for access and download when the unit next connects.

SmarTV Communications Protocol

The SmarTV Communications Protocol is a public domain, extensible, 8-bit ASCII (looking forward here to Kanji, and other multi-byte languages) protocol. (Is this correct? Tim?)

It provides a means of transporting data and commands, which enable (among other things) security/authorization checks, time synchronization, and software distribution (to client sites).

It should be able to be extended to providing a more generalized news and information capability, though this is not essential for the first release.

Distinct parts of the on-line session

  • The User System periodically (generally, weekly) calls the Host System using a built-in modem and the SmarTV Communications Protocol, and transacts an on-line session as described below.
  • Dial and make physical connection (link).
  • Login, or "bind" (unit id and password). (How do we prevent spoofing orother forms of break-in? Ask the hackers...)
  • Time synchronization.
  • Download new software release to client unit (optional).
  • Download new (compressed format) search parameters.
  • Download SmartListings.
  • Download billing info.
  • Upload modified search parameters. Note: the SmarTV system is always a connect interval (usually a week) behind. Remember that search parameters are general sets, usually not for specific one-time events (unless planned well in advance).
  • Hangup.

User System (Client Frontend controller, "the box") Components

  • Connection to AC power (with internal battery backup).
  • Connection to a standard phone line (for communications).
  • An Infra-Red (IR) receiver for receiving commands from the hand-held SmarTV remote, as well as from other remotes.
  • 4 sets of outgoing "captive IR" lines that can feed an IR signal into a VCR, while at the same time blocking it from receiving signals from its own (or any other) remote control.
  • 4 outgoing video lines that can feed "slate" graphics to the VCRs for directory menu listings, as well as (Kansas City cassette interface?) tones for on-tape directory information.
  • Small "boot loader" kernel in ROM.
  • Battery backed up RAM to store SmarTV operating system, PIN numbers and VCR control parameters, current programming information, and the user-profile.
  • Modem.
  • Display driver, video and tone generators.

User interface concepts

Keep the SmarTV interface simple.
6 SmarTV buttons (N, S, E, W, select and menu).
It is probably a good idea to add normal VCR controls (e.g., start/stop/play/rewind/pause/slow-motion/index/0-9). What about "record"? Do we need lockout to prevent recording over already existing programming (or worse, directory info)?
Exception / Rule user interface.
At each change to the SmarTV stored state, the system asks if this is an Exception (e.g., do it just this once and don't modify the user profile) or if it is a Rule (e.g., this change indicates a new rule to be added to the user profile). In the latter case, if there are ambiguities as to the extent of the new rule, the system prompts with a list of possible interpretations that the user then chooses from. Existing rules that will be affected by the change can be viewed. Finally, the entire interaction may be un-done by answering "no" to an "Are you sure you want to do....?" prompt.
Personal Identification Numbers
PIN authorization codes give different family members different access rights (this assumes using the SmarTV controller as the only VCR controller, so that security may be maintained).
Priority levels,
What shows take "record" priority? Also, display next show to be overwritten by higher priority event.

User functions available from remote control

Turn SmarTV system and components VCR(s) on/off.
Do we want to be able to "learn" the TV remote also? I don't think so. TVs have many various features that would complicate the SmarTV remote. Let's provide a very simple remote that perhaps other (programmable) remotes could "learn".
Allow "manual" access directly to the VCR(s).
Modern VCRs have many features that users may want direct access to. Rather than attempt to build all possible functionalities into our remote unit, the base station will have the ability to "learn" a specific VCR's signals, which it will then be able to pass through directly to the VCR. Different commands could have PIN code authorization attached to them.
Check time
Check the bill
View status
current (and next planned) activity(s)
View tape(s) directory
Change password(s), other user administration
perhaps including viewing usage statistics of various users by PIN number ("check up on the kids").
Display recorded menu (by PIN/priority) and facilitate show selection.
Of course, if the VCR is currently recording, then the user must choose between interrupting the recording and viewing the pre-recorded show.
Display menu of shows in "to record" queue (by PIN/priority)
Facilitate deleting or changing priority of shows in menus.
When making such a change, the "Exception/Rule" feature is used. Include changing of which tape the shows are to be recorded upon (good for archiving).
Facilitate adding of new show (to record) info
with immediate conflict (if any) feedback and resolution tools.

With loving memories of Blair Newman, the sad/mad genius behind it all, and a surrogate father for me.

Above memo Copyright © 1989,1994,1997 by Fen Labalme All Rights Reserved.

Page Created: Wednesday, February 9, 1994
   Copyright © 1994-2007, Fen Labalme and CoMedia Consulting. All Rights Reserved.
Broadcatch is built on the OpenPrivacy Platform
I wish this
site were
Drupal Strategy and Consulting
This Site Supports Free Speech