We have already had a good response to yesterday's prior art request, and we will continue to accumulate and post the results. However, today we want to provide some guidance and tools that will help focus your search for prior art.

Why do we care so much about Lodsys? If this were just one software giant going after another and it had no impact on free and open source software, we probably wouldn't care as much. But the tactics that Lodsys is using, going after small developers and effectively trying to extract multiple royalty streams from the same infringement strike us as particularly pernicious. This sort of practice needs to be discouraged, and the best way to do it is to stop the asserting party cold. So we are going to do our part in that effort.

What constitutes prior art?

Prior art can be any printed (hard copy or electronic) matter, including, but not limited to: journal articles, advertisements, documentation, scholarly papers, etc. Prior art can be patent applications or issued patents that predate the claimed priority date. Prior art can also be a physical device or item that embodies the claim elements and which existed prior to the claimed priority date. To constitute prior art, it must have been publicly available prior to the priority date claimed in the patent application, typically the filing date of the application.

What patents are at issue?

We have reprinted the claims of each of the subject patents near the end of the article below.

What is a priority date, and what is the earliest priority date for each of these patents?

U.S. Patent No.	Earliest Priority Date
5,999,908	08/06/1992
7,133,834	08/06/1992
7,222,078	08/06/1992
7,620,565	08/06/1992

All of these patents are continuations from an application (07/926,333) originally filed on August 6, 1992. That original application, which was ultimately abandoned, is on file with the USPTO, but it is not available electronically. If anyone has or is willing to buy a copy of that file wrapper (the prosecution history), we would be happy to post it so everyone can see what Mr. Abelow was claiming when he first filed his application. In any case, here is a look at the early prosecution history from Patrick Igoe.

In any case, you should focus on prior art that was available prior to August 6, 1992. Does that mean you should ignore prior art from 1993 or 1994? No, send that as well. It may still be relevant.

What should I be looking for? Reading the claims.

We are not going to pretend to be experts on reading patents or prior art searching. Patent professionals know these things backwards and forwards. But as the saying goes, we know what we know. So the first place to start is by parsing the independent claims in each patent. The independent claims are the ones that don't reference another claim (those are called dependent claims). For our purposes, dependent claims are not of great interest as they primarily serve to provide narrower versions of the independent (broadest) claims.

Fortunately, at least someone else does know a bit about parsing claims (breaking them down into the individual elements that all must exist for the claim to be infringed). Here is a claim chart presented by the blog IP Target on the '078 patent (probably the key patent being asserted by Lodsys):

• Patent No. 7,222,078

This should give you an idea about how to read the claims. IP Target has also started compiling a list of possible prior art that has been identified:

• Non-patent literature prior art
• Patent prior art
• Additional patent prior art and commentary

If you want an even shorter synopsis of what to look for, here is quick summary of what we need:

The most useful art will be 1992 or earlier. Since any hardware device that communicates with a server will have memory and communications components, and since nearly any UI could be considered to provide two-way interaction, the key things to look for are:

• a device with a user interface that elicits information about the user's perception of the device itself, and
• a centralized server for collecting the results of the users' interactions with the devices.

For instance, if the Xerox Docutech of 1990 had a UI for collecting user feedback about the Docutech itself and each Docutech sent that feedback to Xerox servers over a modem, a manual describing that function could be great prior art.

What information should I provide?

Be as detailed as you can. If the document (either electronic or hardcopy) is available on the Internet, provide a link to it. If there is a publication date, be sure to note it. Provide the title of the article and the volume in which it was published if it is a part of a larger publication. If ithe prior art is a patent or patent application, provide the patent number or publication number for it. If you have time, explain why you think the prior art is relevant.

What other sites are seeking prior art?

In addition to IP Target, Article One Partners, a commercial prior art search entity, has placed a call for prior art. If you want to monetize your prior art search efforts, this may be the path for you. Keep in mind that AOP does not necessarily make the prior art identified to them publicly available, so if you want it to be made public, send it to us or to IP Target.

Where can I learn more about Lodsys and the law suits, both by and against them?

We have put together a Lodsys page where we are publishing information about these cases. We will continue to update that page as these cases progress.

**********

UPDATED

What prior art has been submitted so far?

• Online Now
  From March 1990: a computer bulletin board (BBS) called Online Now. It was accessible via dial-up modem. A few years later, we connected our BBS to the Internet via a product called an IPAD from eSoft, and folks could telnet to our BBS. Basically - bring up a web page on our Internet web server, and connect to us. Then, they could telnet to the BBS. I created a program that allowed folks to sign up to my BBS using a credit card. Basically - telnet to my BBS, play 20 questions, enter your name and address, credit card info, and you were a member.
  My credit card signup program still works, and I can run it - but - I lost the source code. Its a compiled application. The system used TBBS software, and runs under DOS. It has its own built-in multitasking, and was able to handle up to 32 modems on a single '386 or better class machine. It will not run under Windows XP, but I can run it under DOS, and take pictures with a camera. Consider this a long-winded way of saying - screen shots can be done with a camera - not direct from the machine.
  One of the things we had available for download to new prospective users was a bunch of help files. It explained how to use the BBS, rates, what we offered, etc. I included a ZIP file of the package. GMail won't let me attach a ZIP file, so I renamed the extension. The intent was - unzip the files, and from a DOS command prompt, type GO. It would then display and navigate the help files from the keyboard (this was the pre-mouse days). Anyway - once you were ready, you would log on, and run my credit card application. It would collect your name, address, phone #, password, along with credit card info. It would be saved into a database, and manually processed later. Or - you could print out the application form and mail it in along with a cheque.
  We were incorporated as SLEEPING GIANT ONLINE SYSTEMS in either November or December, 1989, and the system went live in March of 1990, complete with the ability to take credit card signups (our preferred method). In 1992 or 1993, eSoft (the makers of the TBBS software we were using) created a box called an IPAD - short for Internet Protocol Adapter. It was a web server, SMTP, telnet interface as well as doing modem handling for dial-up access to the Internet. Basically everything we needed in one box, and ran under MS-DOS. Pretty amazing stuff back them :-) We even had a CD-ROM jukebox hooked up, and it would copy files off a CD that folks could download. Offering downloads was the primary attraction, along with a variety of message boards. System went under in March of 2000.
  When were getting started in 1989, there were MANY pay systems around, along with many free systems. We did not come up with the idea of handling credit card transactions - other system were also doing the same thing. Interesting that this may be one of the last surviving systems!
• Showing BBS rates, and how one could telnet to the BBS via yourweb browser. Once you were on the BBS, you could then sign up for access.
• Subject: eService Online New Member Information
  Message-ID: [0e2b510561005a0CPTRSMTP01@smtpout.expedia.com]
  Date: 5 Oct 2000 03:56:10 -0700
  X-UIDL: f70db25021d5760f6e0002a19ceea819
  Status: RO
  
  Welcome to Continental Airlines On-Line Reservations.
  
  Below is your new membership information. Please keep this confirmation e-mail as a record of your Member ID.
  
  Your Member ID is: jdaley
  
  The Continental Airlines Internet address is: http://www.continental.com/
  
  Whether for business or pleasure, Continental Airlines makes it easy for you to plan and purchase travel arrangements that best meet your budget and personal preferences. Continental Airlines is on the job 24 hours a day, 7 days a week. With a click of your mouse, you can:
  
  * Reserve and purchase airline tickets
  * Reserve hotel rooms
  * Reserve rental cars
  * Research over 300 destinations in the World Guide
  * Chart your course with over 200 city maps
  * Catch up on the latest travel news, weather and more
  
  We look forward to fulfilling all of your travel needs.
• VMS Crash Dumps:
  * a device with a user interface that elicits information about the user's perception of the device itself, and
  * a centralized server for collecting the results of the users' interactions with the devices.
  A VMS crash dump was the embodiment of the user's perception of how well (or otherwise) the operating system was working. This feedback was used by Digital Equipment Corporation to find and eliminate the cause of that particular crash, thus improving the reliability of VMS over time.
  In the early days, crash dumps were sent to DEC on magtape, but later, there was a centralised server (or servers) set up using client-server software called AES (Advanced Electronic Support), which could automate or at least assist the process of retrieving crash dumps, amongst other things.
  I don't have exact dates for when AES came into being, but here's a reference dated July, 1992.
• ACARS - Aircraft Communications Addressing and Reporting System
  It is the data link, communications, telemetry, and centralized upload/download, including comments from pilots/engineers, built into airliners as a subsystem and integrated into the whole avionics/cockpit system.
  It looks to date back to 1980 or as early as 1978.
  ARINC are the developers of the system, and possibly hold patents on this.
  Definitely there should be lots of older documentation printed with dates, related to the equipment and system, gathering dust in the maintenance facilities of airlines, or pilots' garages. Maybe check forums like the Airline Pilots Association?
  Some of the documents are available for purchase from ARINC's web site, although most of it tends to be current system rather than historical system.
• VMS and Other Manuals
  • In the back of all the PRINTED VMS Manuals (and probably other DEC Manuals as well) there was a feedback page. This was used to provide feedback to DEC on the content etc. I can't recall anyone ever using them but we had to put them into every manual. If anyone has access to VMS or Ultrix Manuals in Hardcopy that predate the August 1992 dates (VMS 4.7 & V5.0) would easily fit then as the old Amex Advert said, 'that will do nicely'...
    and from another reader:
    I have some of those manuals at work. I've kept them mostly out of curiosity since they are really old and my use of VMS where I work has become minimal. I even have one from 1982 "VAX/VMS Internals and Data Structures".
    I wonder if DSNlink would also be usable prior art. I only have a vague idea about it because by the time I got heavy into using VMS DSNLink was being phased out so don't know much about it. What I remember is you could submit service requests to it, is that a type of feedback?
  • Feed back forms appears fairly common in manuals of that time period. On my shelf:

    VMS User's Manual AA-LA98B-TE (c) Copyright Digital Equipment Corporation 1989. Has 2 copies of a post-paid "Reader's Comments" page, with a questionnaire about the manual ("I rate this manual's: accuracy, completeness, clarity, etc.", "I would like to see more/less", "What I like best about this manual is", ditto with "least", "I found errors in this manual") and 1 copy of a post-paid "New Manual Survey" open answer questionnaire ("Do you like this manual's binding", "Does this manual describe...", "Are the descriptions...useful", "Which books do you refer to most often").

    Cyber Interactive Debug Version 1 Guide for Users of FORTRAN Version 5 60484100 (c) Copyright Control Data Corporation 1980. Has a post-paid "Comment Sheet". Rather than a questionnaire just has fields for name, company, etc, and a blank area to write comments. "This form is not intended to be used as an order blank. Control Data Corporation welcomes your evaluation of this manual. Please indicate any errors, suggested additions or deletions, or general comments below (please include page number references)".

    Microsoft Windows Resource Kit For Operating System Version 3.1 (c) 1992 Microsoft Corporation. Document Number 0030-31645 Has a (not postpaid) page titled "Windows Resource Kit Feedback Sheet" with a short questionnaire ("My priorities for more information", "I found the following information ... most valuable","I would like access to more utilities, such as:", "I would find the information in this Kit more helpful if").

    XL Fortran for AIX Language Reference Version 3 Release 2 Publication No. SC09-1611-01 (c) Copyright International Business Machines 1990, 1994 Has 2 copies of a short "Readers' Comment" page with a short questionnaire (headings "Overall, how satisfied are you with the information in this book?", "How satisfied are you that the information in this book is:") and half the page open for "Please tell us how we can improve this book".

  • Many government publications include a feedback page. An example is MIL-HDBK-1012/1, MILITARY HANDBOOK: ELECTRONIC FACILITIES ENGINEERING (15 MAY 1989), pages 126 and 127. You will note that the feedpack form is addressed to the document maintainer, and is business reply mail.

    This document can be found at this link http://www.wbdg.org/ccb /NAVFAC/DMMHNAV/1012_1.pdf.

    A second example is MO-913 Historic Structures Preservation Manual, Naval Facilities Engineering Command, SEPTEMBER 1991. The feedback form is the last 2 pages of the manual http://www.wbdg.org/ccb/NAV FAC/OPER/mo913.pdf.

• Videotex
  What about Videotex interactive services from the 1980's
  Volume 8 #7 of the Byte Magazine from july 1983 on a slow ftp server (details at the end of the post) and re-uploaded it on Rapidshare, here:

  https://rapidshare.com/files/3829628979/198307_Byte_Magazine_July_1983.pdf

  WARNING: it is a direct scan from paper so the pdf file size is HUGE, 535 MEGABYTES (562.033.073 bytes).
  Warning #2: if 30 days pass and nobody downloads the file then rapidshare will delete the file. I'll try to re-upload it if that happens but the url will be different.
  The original pdf file was posted by Marcus Bennett on the Atari Age forums: http://www.atariage.com/forums/topic/167235-byte-magazine/ Please do not link directly to the files on their servers as they do not have too much bandwidth but do credit them for their work for scanning the Byte collection

• I don't have any documentation of it, but I'm pretty sure CompuServ in the had help & feedback forums, on CompuServ itself.
  So did America Online. But I didn't keep any documentation of that; someone may have.
  Also, Lucasfilm Habitat would be something to look into.
• Internet Coke Machine
  The final piece of the puzzle was needed to let people check Coke status when they were logged in on some other machine than CMUA. CMUA's Finger server was modified to run the Coke status program whenever someone fingered the nonexistent user "coke". (For the uninitiated, Finger normally reports whether a specified user is logged in, and if so where.) Since Finger requests are part of standard ARPANET (now Internet) protocols, people could check the Coke machine from any CMU computer by saying "finger coke@cmua". In fact, you could discover the Coke machine's status from any machine anywhere on the Internet! Not that it would do you much good if you were a few thousand miles away...
  

  - CMU Coke Machine; The "Only" Coke Machine on the Internet.

  Beginning with the CMU coke machine, a number of people have connected pop and coffee machines to the Internet.

  The Internet Coke Machine is not a myth, but it is a legend. The first pop machine was connected to the Internet in 1982 at Carnegie Mellon University's School of Computer Science by four exercise challenged but ingenious graduate students, Mike Kazar, David Nichols, John Zsarnay, and Ivor Durham, so they could check from their desks if the machine was loaded with cold coke. More information can be found at the CME SCS Coke Machine Home Page.

  Resources. In other news from the surprisingly rich field of beverage machine virtual connections:

  * The University of Cambridge took the next step by connecting the Trojan Room Coffee Machine to the Internet in 1992.
  * RFC 2324 provides a specification for a Hyper Text Coffee Pot Control Protocol, published 1 April 1998.
  * Yahoo also maintains a list of soda machines connected to the Internet, a subset of a larger category devices connected to the Internet.

• Minitel
  The entire Minitel system in France worked this way, allowing electronic purchases via credit card directly from home. The system was also used in Canada and even in USA for a while.
  http://en.wikipedia.org/wiki/Minitel - It was announced in 1980 and launched in 1982
  http://en.wikipedia.o rg/wiki/Videotex#North_America
  http://www.rfi.fr/ actuen/articles/110/article_2851.asp - The minitel is a French video-text technology introduced in 1982. It could be used to book tickets, check stock prices and look up phone numbers and addresses.
  Around the years 1993-1995 the french Minitel network had almost 7 MILLION terminals in operation, the highest they would ever have.
  Additional links, background history on Minitel. (in french)
  Le Minitel - Plus de vingt ans de succès: http://www.bertrandlemaire.com/creations/monographies/minitel.pdf (The Minitel - more than twenty years of success)
  Minitel : histoire du réseau télématique français http://olegk.free.fr/flux/Flux47/pdffl47/08HdC84-89.pdf (Minitel: the history of the french telematic network)
  http://www.univ-paris1.fr/fileadmin/diplome_droit_internet/tabord200204-2.pdf quote from chapter 3: "Les ventes à distance au travers du Minitel auraient significativement baissé en 2001 : elles représentaient de l’ordre de 7% (500 millions €) du chiffre d’affaires total des adhérents de la Fédération des entreprises de vente à distance (Fevad) en 2000, et elles seraient désormais plus proches des 5-6%, soit au même niveau que l’internet, dont la part monte rapidement."
  short translation: By 2001, total yearly sales through the Minitel system had significantly decreased to only 7% (500 million euros) out of the total distance sales by vendors associated in the Federation of Distance sales Companies.
  Other facts about the Minitel system can be found by using the following Google search: http://www.google.com/search?q=minitel+achats+filetype%3Apdf
  Here's a paper from 1988 in English explaining the french Minitel system and how it was implemented in the USA The Teletel/Minitel System in France
  Jeffrey A. Hart http://www.indiana.edu/~globalm/pdf/minitel.pdf
  Telematics and Informatics
  vol. 5, no. 1, pp. 21-28, 1988
  Copyright (c) 1988 Pergamon Press plc,
  Printed in the USA
• Hewlett Packard LIMS (Lab Information Management Systems) systems of the early 1980s.
  Those ran over the HPIB which later became GPIB. See http://en.wikipedia.org/wiki/IEEE-488 for some details.
  It seems that HP has sold that instrument division to Agilent.
  See http://www.hp9825.com for some history of one of the machines used to control lab instruments of that time. And some googling finds http://www.taltech.com/products/Appnot2.htm
  Basically, the lab instruments themselves are the "devices" in this picture. These lab instruments are things like gas chromatographs, mass spectrometers, etc. Those instruments had their own keyboards and printers to control the instrument, but they were also connected via HPIB to the LIMS system which is the centralized server in this picture.
  "information about the user's perception of the device itself" seems to include a wide range - perhaps including the device configuration settings entered by the user on the keyboard attached to the instrument.
  
• It seems to me that service bureau computing in the 1970's has many of the attributes noted in these patents. There were terminals connected via modem in many locations feeding information to central servers where processing took place. I was in a shop in the 70's where engineering design work (finite element analysis) was being done this way. I believe that the service bureaus collected user input from the sessions. This was certainly used for billing purposes and I believe as well for notifications. I suspect some of the more "packrat" oriented of those on Groklaw may find old manuals on the subject.
• PTSS, MUMPS, PICK
  Lawrence Berkeley Laboratory had an online time-share system with PTSS (People's Time Sharing System) for doing text editing on computer. This was back around 1980. And there were others, earlier. And they weren't cheap (except compared to renting a computer).
  Also around that time there were remote batch systems, where you fed your program into the input queue and could get results printed back (eventually). These were cheaper.
  In all these systems the site would dial up the computer and log in, and then the user of the site would log in, to identify the specific account that the job would be charged against. There were connect charges for both the site and for the user. Some had card readers, some had paper tape. A very few had mag-tapes.
  Going back to around 1960 Lockheed had a remote computer link between Sunnyvale, CA and Van Nuys, CA. Both ends were run by the same company, but they probably had accounting of computer use. (That one ran over a microwave line, if I recall correctly.)
  Somewhere in there MIT had MUMPS, and wrote the CMS OS for doing time-share on IBM computers. (MUMPS was, I believe, one of the ancestors of UNIX...but I don't have any certainty there.) I don't have any direct knowledge of just what was happening around MIT as I was on the west coast.
  However, if I take those claims literally, any time-sharing system would be in conflict with them. (At least unless it was offered for free.)

  MUMPS stands for MUMPS (Massachusetts General Hospital Utility Multi-Programming System). I remember it well from using on a PDP-11 in the late 1970's.
  Is it hierarchical? It's closely related to (but distinct from) Pick, which most definitely is not hierarchical as I understand hierarchical.
  The best-known version of Mumps is now called Cache - as I understand it, Cache actually is the direct evolution of the original Mumps - just as the original Pick is now called D3. There are definitely a lot of Pick clones, I suspect but don't know that there are a fair few Mumps clones too.

• From the late 1970's on there were workstation/terminal server systems, often with 'remote access' modems for technician access to review core dumps, system problems, etc. IBM System 36 systems, Wang Word processing and Document Image/Scanning processing systems, Lanier word processing systems, Honeywell, Computervision, MAI Basic Four, Xerox, DEC, PDP, Apollo, Prime, Burroughs (Unisys), CDC, DEC...so many examples to consider active in the decade prior to 1992. Many of these could be multiplexed with racks of modems for dial-up capabilities and remote access. Today's cell phone CPUs and GPUs or MPT3/4 players could out compute any of those mini-computers. For instance a Wang server had a single Z80 processor, 32K RAM, and would provide near instantaneous interactive support for 32 workstations for typists working 70 to 110 wpm, with fast macro scripting with computations, and still could keep several daisy-wheel printers sputtering, as well as those new-fangled laser printers busy burning reams of paper...sometimes literally.

  Wikipedia - Minicomputer"

  The 1980s Xerox Labs LISP systems had so many capabilities, including networking, that eventually were rolled into personal computers and operating systems and GUIs decades later...sadly, minus the LISP language. (No, I'm not really counting EMACS.) If Bill Gates had pushed LISP on PCs...it'd be quite a different world. The old unix 'uucp' store and forward method of distributing Usenet news and mail via dial-up connections, with it's forums and postings, might also be looked at.
  The ICL systems in the UK and elsewhere. The 1900 series was in use from the 1960 onwards.

• the "Prancing Pony" at the old Stanford AI Lab - it was a small room with a vending machine, etc. The timesharing system at the Lab had a command that allowed you to purchase food from the machine and kept track of how much you owed.

  According to this page by Stanford University's Les Earnest, the Prancing Pony dates back around 1972.

  I saw this machine around 1978. Since it had on-line accounting instead of a coin box, it could do some rather unusual things for a vending machine:
  1. It knew how old you were from your account, so it knew if it could legally sell you beer.
  2. You could have it randomly flip a virtual coin and pay double or nothing.
  

• From the early 90's-- http://tony.aiu.to/jokes/techie.html#8
• Knight-Ridder service called Viewtron started in Miami in 1982/3. It certainly had the capability to produce surveys, but the survey questions would have had to come from the server, with the home device merely capable of formatting the server's data, and sending typed responses back to the server. At $600, it was just too expensive in 1983 to catch on.

  Here is an article on the service from 1983: http://www.time.com/time/magazine/article/0,9171,952268,00.html

  The article also talks about Chemical Bank's Pronto service launched at the same time, and it seems even more on point. However, both systems would be difficult to determine from these articles whether the device was considered to be asking the questions.

• Telephone PBX Systems
  Here is is: ,a href="http://books.google.com/books?id=Lg0EAAAAMBAJ&lpg=PA61&ots=4NydWe4Fx0&dq=at%26t%20pbx%20support%20call%20automatically&pg=PA1#v=onepage&q=at&t%20pbx%20support%20call%20automatically&f=false">Read the article on the bottom right, "AT&T unifies Definity line via software". The part about the PBX talking to other PBXs about call load. It appears and operator had the ability to report as well. 1991 and well before.
• Gopher
  The Gopher protocol was used in the early days of the Internet, with myself working at NASA at the time I used it quite a bit. Using a Gopher enabled application one could connect to another's Gopher server, and if the user had problems they could select an X.500 link to contact the system administrator via SMTP. That would ensue a two way correspondence of data collection and remediation of the users problem at hand. The data collection was obviously a manual effort on the users part, but the other steps IMHO seem to be parallel to the 5,999,908 patent. Adding in the automated session initiation and error data collection process would simply be an evolutionary step, and quite obvious to anyone writing software for a living.

  Gopher protocol https://secure.wikimedia.org/wikipedia/en/wiki/Gopher_%28protocol%2 9 ftp://ftp.ietf.org/rfc/rfc1436.txt

• PLATO
  The PLATO (Programmed Logic for Automated Teaching Operations) system was the first generalized computer assisted instruction system. It started in the 1960s, and by the late 1970s, there wer thousands of terminals. I recall that many of its courses had a number of different kinds of feedback mechanisms. I suspect there is a lot of prior art there.
• U.S. Patent 5101267
  There is nothing in this patent that says the 'unit of commodity' is a computer system. So, I have prior art where the 'unit of commodity' is a television system supporting audience response to the programming on the screen. If we now define the programming part of the system, then the audience response is the feedback. Patent number of such a system is 5101267.
  March 31, 1992 it issued. Filed 1989:
  Inventors: Morales-Garza; Fernando (Monterrey, MX)
  Assignee: TV Answer, Inc. (Reston, VA)
  Appl. No.: 07/390,073
  Filed: August 7, 1989
• DEC Field Service
  In the mid to late 80's (well prior to '92), Digital Equipment Corporation had a field service offering designed to improve system reliability. For a fee, you could have them install an 'error log analyser' that examine the records of hardware errors in error log files and automatically send trouble reports to a central server so that flaky equipment could be replaced before it actually failed. Originally the reports were sent using dial-up but would very likely have been upgraded to usenet and then internet connections.
  I believe systems with this option installed qualifies. The user interface was provided by a request to the 'operator' for a reason why the system had been shut down that was recorded in the error logs that were then sent to field service. It has been too long for me to remember all the details, but there may also have been an option to manually initiate the log transfers along with summarizing the errors that might also qualify as a qualifying User Interface.
  Details should be available from Hewlet Packard. They own what is left of DEC. IIRC there were some patents on making the error logs more complete, and there may even have been one on the service itself. They would all have expired some time ago.
  ISTR that that was part of RAMP (Reliability, Availability and Maintainability Program) and it also applied somewhat to the hardware, where VAXsim (?) would analyze the VMS Error Logs for hardware-ish errors (I say "hardware-ish", because as more data was accumulated and reviewed by humans, the search/analysis thresholds/parameters were adjusted to point specifically to various actual hardware problems as opposed to their software drivers or other issues), and alert Field Service to send out a Field Service engineer with appropriate parts and tools to rectify the problem before the system went down hard. (With the advantage that the service could be scheduled for a time of relative convenience to the customer, either by allowing migration of tasks to another system or simply taking the system down in the middle of the night, etc.)
  In fact, they started to expand that to the UNIX space, but by that time, the economic sands had shifted and the very VMS-based tools were decidedly non-portable. However, this concept was really, really useful for the VAX 8600 series in particular, but was used heavily in the VAX 8500/8700/8800s as well, and the concepts were brought forward to the bigger Alphaservers that came along after that.
  Their 'Software Performance Report' system was originally a paper based system, but may have evolved to the point were it also qualifies. (The mail-ins from the backs of manuals were turned into SPRs, and I think I saw a few in the SPR activity summaries I read. Again IIRC the mail-ins could be used to rate the entire software packages as well as the individual manuals. That would make the LODSYS stuff a sub-set of the DEC (and others) offerings.)
  Yes, RAMP is what it was called overall and it did not just apply to VMS or just to VAX. A lot of this stuff got developed on the PDP/10, PDP/20 and larger PDP/11 systems so it goes back quite a long way. Also look at the TOPS, RSX and RSTS software lines. Some of it went to Microsoft when Dave Cutler went over and developed NT for them. Some of the OEMs like Dell may have picked up the remaining pieces, so they might also be a place to look for similar art.
  Umm, it could be quite portable in fact. The problem is that Unix-like systems do not have as strong a tradition of logging hardware error details. Everything gets thrown into one huge log file that gets rotated frequently. This discourages device drivers from adding to the clutter. The diversity in reporting styles, common in Unix, also causes difficulties that more homogeneous systems would not have.
  The hardware error logs were fairly small and compact by comparison and often went back for several years. To get something equivalent out of Unix, you'd have to filter the conglomerated log files and save the extracts.
  (Although I do not have more than minimal experience from the process, I believe DEC had strong standards for diagnostic programs and those programs were developed in parallel with the hardware. They were built by the hardware developers as part of the hardware development process. The summary sections of those diagnostic programs got incorporated into the drivers as standard practice, and the release criteria for new hardware included a review item specifically on the point.)
  Sounds like Stratus. I can date it pretty precisely to 84/5, when I saw the computer in their London office, which received automated fault calls from customers' equipment.
  They would despatch an engineer, based on these fault calls, to fix the kit and often the first the customer would know would be when the engineer arrived.

**********

Here are each of the patents and their claims in full text:

U.S. Patent 5,999,908

What is claimed is:

1. A system for use with units of a computer product that are in use respectively by different users, comprising:

• a user interface which is part of each of the units of the computer product and provides a medium for two-way local interaction between the user and the unit of the product,
• interaction scripts that mediate two-way interaction between each of the users and the corresponding unit of the product via the user interface, each of the interaction scripts causing information and questions about use of the unit of the product to be conveyed to the user from the unit of the product and enabling information and questions about use of the unit of the product to be conveyed from the user to the product, different ones of the interaction scripts being suitable for users who are at different levels of experience or functionality in using the product,
• a triggering element arranged to trigger appropriate ones of the interaction scripts between the user and the unit of the product based on usage information accumulated at the unit of the product about use of the unit of the product by the user,
• a communication element that carries the interaction scripts and results of triggered interactions between the units of the products and one or more remote third parties, and
• a generation element that enables generation of new interaction scripts based on the results of previously triggered interactions occurring at more than one of the units of the product.

2. The system of claim 1 further comprising: an authoring system for use by one or more of the remote parties for managing the content of the product information and questions.

3. The system of claim 1 further comprising:

• an analyzer of results of triggered interaction scripts received at one or more of the remote parties, and
• means for controlling the taking of action with respect to the product or the user interface in response to the analyzer.

4. The system of claim 3 wherein the analyzer analyzes results of triggered interaction scripts received at the remote party from multiple users with respect to multiple products.

5. The system of claim 1 wherein the product information and questions include new interface elements and are communicated from one or more of the remote parties to the product.

6. The system of claim 1 wherein the user interface comprises a product module which may be disabled and enabled selectively.

7. The system of claim 1 wherein the triggering element is initiated locally at the product.

8. The system of claim 1 wherein the triggering element is initiated by one or more of the remote parties.

9. The system of claim 1 wherein the user interface comprises one or more of a display screen, a keyboard, a microphone, and a speaker.

10. The system of claim 1 wherein the communication element comprises one or more of broadcast transmission, wire, or a removable memory device.

11. The system of claim 1 wherein the user interface includes a natural language component.

12. The system of claim 11 wherein the user interface includes multiple natural languages, selectable by the user.

13. The system of claim 1 wherein the interaction scripts are controlled by the user.

14. The system of claim 13 further comprising an element with which a user may terminate an interaction script with the product at will.

15. The system of claim 1 wherein the user interface includes a user control for selectively enabling or disabling the user interface.

16. The system of claim 1 in which the computer comprises software.

17. A method for aiding design of a product comprising:

• creating a first version of the product,
• including with the first version an interactive user feedback element that permits two-way communication between a user of the product and a designer of the product and which accumulates information on use of the product by a user, the user feedback element including a user control for selectively enabling or disabling the user feedback element,
• engaging in a two-way communication between the user and the designer, under control of the user, including recovering the information from the user feedback element,
• the two-way communication being initiated by the product based on usage information accumulated at the product about use of the product by the user,
• analyzing the information, and
• redesigning the product in accordance with the results of the analyzing step.

18. The method of claim 17 wherein the information includes information provided by the user with respect to problems in use of the product.

19. The method of claim 17 wherein the information includes information provided by the user with respect to solutions to problems in use of the product.

20. The method of claim 17 wherein the information includes information provided by the user with respect to usability of the product.

21. The method of claim 17 wherein the information includes demographic marketing information about the user of the product.

22. The method of claim 17 wherein the information includes information about the user's use patterns for the product.

23. The method of claim 17 wherein the information includes information about business processes using the product.

24. The method of claim 17 wherein the information includes analysis of tasks performed by the user with the product.

25. The method of claim 17 wherein the information includes analysis of the performance of the user with the product.

26. The method of claim 17 wherein the information includes business transactions performed by the user with the product.

27. The method of claim 17 wherein the information includes user-suggested expansion of business relationships.

28. The method of claim 17 wherein the information includes user-suggested improvements of processes.

29. The method of claim 17 further comprising enabling the user to set a priority for response to information entered by the user.

30. The method of claim 17 wherein the information recovered from the user feedback element comprises information developed in the course of interactive learning by the user.

31. The method of claim 17 further comprising, prior to redesigning the product,

• delivering to the user via the feedback element, proposed redesigns of the product, and
• recovering information about the proposed redesigns via the feedback element.

32. The method of claim 17 further comprising electronically sharing the information from the user feedback element with a third party.

33. The method of claim 17 further comprising providing a mechanism for compensating a user for information accumulated in the feedback element.

34. The method of claim 17 further comprising providing a mechanism for buying and selling results of the analyzing step.

35. The method of claim 17 further comprising giving access to the feeback element to a third party.

36. A system for use with units of a computer product that are in use respectively by different users, the system comprising:

• a user interface which is part of each of the units of the computer product and provides a medium for two-way local interaction between the user and the unit of the product, the user interface including a user control for selectively enabling or disabling the user interface,
• interaction scripts that are controlled by the user and mediate two-way interaction between each of the users and the corresponding unit of the product via the user interface, each of the interaction scripts causing product information and questions about use of the unit of the product to be conveyed to the user from the unit of the product and causing information and questions about usage of the unit of the product to be conveyed from the user to the product, different ones of the interaction scripts being suitable for users who are at different levels of experience or functionality in using the product,
• a triggering element arranged to trigger appropriate ones of the interaction scripts between the user and the unit of the product based on usage information accumulated at the product about use of the unit of the product by the user,
• an electronic communication element that carries the interaction scripts and results of triggered interaction scripts between the units of the products and one or more remote third parties,
• an element that enables generation of new interaction elements based on the results of previously triggered interaction scripts occurring at more than one of the units of the product,
• an authoring system for use by one or more of the remote parties for managing the content of the interaction scripts, and
• an analyzer of results of triggered interaction scripts received at one or more of the remote parties from multiple users with respect to multiple products.

37. A system for managing information about a value to users of units of a computer product that are in use by the users, the system comprising:

• in each of the units of the computer product, a user interface which provides a medium for two-way local interaction between the user and the unit of the product,
• interaction scripts that mediate two-way interaction between each of the users and the corresponding unit of the product via the user interface, each of the interaction scripts carrying information about the value to users of using the product,
• a value information server accessible via a public communication network from each of the units of the computer product and by a vendor of the computer product, the value information server storing interaction scripts and the value information that results from the interaction scripts, and
• a communication element that carries the interaction scripts and the information that results from the interaction scripts between the units of the products and the value information server, and between the value information server and the vendor.

What is claimed is:

1. A system comprising a server that is electronically accessible to multiple client systems having products, services, software or information; the server comprising: (i) means for storing information indicative of problems and solutions for using respective products, services, software, or information in the client systems as determined by users of the products, services, software, or information, and (ii) means for executing software configured to: receive solution information electronically from the client systems regarding what would make a product, service, software, or information operate more effectively, store the received solution information in the storing means, and in response to a trigger from one of the client systems, distribute the stored solution information for the product, service, software, or information electronically to the one of the client systems, wherein the trigger is received from the one of the client systems in response to exception arising from the use of the respective product, service, software, or information.

2. A method in which: a user records information on a client device about a problem with use of the client device, the client device sends the information to a server for storage, the client device receives from the server solution information recorded by other users, the solution information being received in response to a problem arising from the user's interaction with the client device, and the client device presents the received solution information to the user.

3. The method of claim 2 in which the device stores a script for probing a user for information about a problem with use of the client device.

4. The method of claim 3 in which the device receives the script from the server.

5. The method of claim 2 in which the solution information guides the user's interaction with the client device.

6. The method of claim 2 in which the solution information is received from the server in response to a request of the user of the client device.

7. The method of claim 2 in which the solution information is received from the server in response to an exception resulting from use of the client device.

8. The method of claim 2 in which the information received by the client device comprises navigational pointers.

9. The method of claim 2 in which the information received by the client device comprises hypertext.

10. A system comprising a server that is electronically accessible to multiple client systems having products, services, software or information; the server comprising: (i) a memory for storing information that provides solutions for use of respective products, services, software, or information in the client systems as determined by users of the products, services, software, or information, and (ii) a processor configured to execute software configured to: receive solution information electronically from the client systems regarding what would make a product, service, software, or information valuable, store the received solution information in the memory, and in response to a trigger from one of the client systems, distribute the stored solution information for the product, service, software, or information electronically to the one of the client systems, wherein the trigger is received from the one of the client systems in response to an exception arising from the use of the respective product, service, software, or information.

11. The system of claim 10 in which the solution information obtained from the client system is obtained from passive evaluation.

12. A system comprising a server that is electronically accessible to multiple handheld client telephones; the server comprising: (i) a memory for storing problem and solution information indicative of the problems and solutions of handheld client telephones as determined by users of the handheld client telephones, and (ii) a processor configured to execute software configured to: receive problem information electronically from the handheld client telephones regarding what would make users more successful in using handheld client telephones, store the received problem information in the memory, and in response to a trigger from one of the handheld client telephones, distribute corresponding stored solution information for a problem electronically to the one handheld client telephone, wherein the trigger is received from the one handheld client telephone in response to an exception arising from the use of the handheld client telephone.

13. A method in which: a user records value information about using a client handheld telephone on the client handheld telephone; the client handheld telephone sends the value information to a server for storage, the client handheld telephone receives from the server additional value information recorded by other users, in response to an exception triggered by the user's interaction with the client handheld telephone, and the client handheld telephone presents the user with the additional value information.

14. The method of claim 13 in which the additional value information received by the handheld client telephone guides the user's interaction with the handheld client telephone.

15. The method of claim 13 in which the additional value information received by the handheld client telephone comprises hypertext.

16. A method in which a user records, on a client handheld telephone, information about a problem associated with using the client handheld telephone; the client handheld telephone sends the problem information to a server for storage, the client handheld telephone receives, from the server, solution information, the solution information being received in response to an exception triggered by the user's interaction with the client handheld telephone, and the client handheld telephone presents the solution information to the user.

17. The method of claim 16 in which the solution information comprises navigational pointers.

18. The method of claim 16 in which the exception comprises failure to complete a task.

19. The method of claim 18 in which the solution information received by the handheld client telephone comprises instructions to complete a task that the exception indicated the user failed to complete.

20. The method of claim 16 in which the exception comprises an error during use of the client handheld telephone.

21. The method of claim 16 in which the solution information comprises training information.

22. The method of claim 16 further comprising requesting information about improved operation or product design from the user.

What is claimed is:

1. A system comprising: units of a commodity that can be used by respective users in different locations, a user interface, which is part of each of the units of the commodity, configured to provide a medium for two-way local interaction between one of the users and the corresponding unit of the commodity, and further configured to elicit, from a user, information about the user's perception of the commodity, a memory within each of the units of the commodity capable of storing results of the two-way local interaction, the results including elicited information about user perception of the commodity, a communication element associated with each of the units of the commodity capable of carrying results of the two-way local interaction from each of the units of the commodity to a central location, and a component capable of managing the interactions of the users in different locations and collecting the results of the interactions at the central location.

2. The system of claim 1 in which the user interface is triggered based on user behaviors to generate two-way interactions with each of the users, each of the interactions relating to a corresponding specific one of the behaviors.

3. The system of claim 1 in which the interactions are triggered to occur repetitively for each of the users based on repeated uses of a feature of a unit of the commodity by the user.

4. The system of claim 1 in which the user interface comprises part of a functional user interface of the unit of the commodity that can be used to control features of the commodity.

5. The system of claim 1 in which the communication element also carries information from a passive probe that monitors the user's use of the commodity.

6. The system of claim 1 in which the units of the commodity comprise telephone extension equipment and the central location comprises a private branch exchange or other central telephone network facility.

7. The system of claim 1 in which the results of the interactions are forwarded from the central location to a remote server for analysis.

8. The system of claim 1 in which the units of the commodity comprise facsimile equipment and the user interface triggers the two-way interaction to occur on-line between the unit of the facsimile equipment and a vendor of the facsimile equipment.

9. The system of claim 8 in which the on-line interaction occurs by voice spoken through the facsimile machine's handset, transmitted by telephone line to a computer of the vendor, and stored at the vendor's computer.

10. The system of claim 1 in which the two-way interaction provides instructions on how to use the commodity.

11. The system of claim 1 in which the units of the commodity comprise consumer television equipment.

12. The system of claim 11 in which the two-way interaction comprises posing questions to a user on a television screen concerning use of the commodity and receiving answers from the user expressed through a keypad or a handheld remote.

13. The system of claim 12 in which the answers are forwarded to a vendor of the commodity.

14. The system of claim 12 in which the keypad or hand-held remote comprises numeric keys.

15. The system of claim 1 in which the two-way interaction is mediated by a publicly or privately accessible on-line computerized information service.

16. The system of claim 1 in which the user interface presents information in one or more of the following styles: text, lists, charts, views, arrangements, hierarchies, graphical maps, sample extracts, abstracts, summary descriptions, or hypertext.

17. The system of claim 16 in which the user interface triggers two-way interactions that comprise training based on two-way interactions with all or some other users, the interactions being arranged to present actions that the user could take to increase performance or satisfaction to a level achieved by other users.

18. The system of claim 16 in which the style is hypertext.

19. The system of claim 1 wherein the user interface can be triggered based on user comprehension or performance with respect to the user's use of the commodity.

20. The system of claim 1 wherein the user interface can be triggered by premature termination of use of the commodity.

21. The system of claim 1 wherein the user interface can be triggered by an exception resulting from use of the commodity.

22. The system of claim 1 wherein the elicited information is information about the user's needs with respect to use of the commodity.

23. The system of claim 1 wherein the elicited information is information about the user's perception of competing commodities.

24. The system of claim 1 wherein the two-way local interactions comprise a transaction for sale of a product or a service contract for the commodity.

25. The system of claim 1 wherein the two-way local interactions comprise a request for servicing of the commodity by the user.

26. The system of claim 1 wherein the user interface includes a sound recorder.

27. The system of claim 1 wherein the units of commodity are configured to store voice or sound information.

28. The system of claim 1 wherein the units of commodity are configured to digitize voice or sound information.

29. The system of claim 1 wherein the two-way interaction comprises voice communication.

30. The system of claim 1 wherein the user interface includes a console displaying text or graphics.

31. The system of claim 30 wherein the console comprises a display of a computer, phone, or handheld device.

32. The system of claim 1 wherein the component is configured to provide access to the collection of results to vendors of the commodity.

33. The system of claim 1 wherein the component is configured to provide access to the collection of results to the users of the commodity.

34. The system of claim 33 wherein the component distributes results of the interactions to the users as a function of when the interactions occurred.

35. The system of claim 33 wherein the component further manages collection of information for each interaction about usefulness of the interaction to other users.

36. The system of claim 33 wherein the component is further configured to allow each user to filter information in the collection of the results according to a user's own needs, or desires.

37. The system of claim 1 wherein the component is configured to provide access to the collection of results to third parties.

38. The system of claim 1 in which the units of commodity store one or more probes that elicit specific information from the respective users through the user interfaces.

39. The system of claim 38 in which the component that manages the interactions of the users sends the probes to each of the units of the commodity.

40. The system of claim 1 in which the information about the commodity comprises value information.

41. The system of claim 40 in which the value information comprises usage logs.

42. The system of claim 40 in which the value information comprises information about user comprehension.

43. The system of claim 40 in which the value information comprises information about user performance.

44. The system of claim 40 in which the value information guides a user's interaction with the commodity.

45. The system of claim 40 in which the value information comprises marketing information or information about future product design.

46. The system of claim 1 in which the two way local interaction enables the user to request help or support.

47. The system of claim 1 in which the information relates to perception of a problem relating to use of the commodity.

48. The system of claim 47 in which the two-way local interaction includes suggestions of the user to solve the problem.

49. The system of claim 47 in which the two-way local interaction includes suggestions of another user to solve the problem.

50. The system of claim 1 wherein the commodity is a demonstration unit.

51. The system of claim 1 wherein the communication element also carries objective information about the user's use of the commodity.

52. The system of claim 1 wherein the two-way local interactions occur while the user is using the commodity.

53. The system of claim 1 wherein the component further manages collection of the results of the interactions along with information about a trigger event that initiated each respective interaction.

54. A system comprising: units of a facsimile equipment that can be used by respective users in different locations, a user interface which is part of each of the units and is configured to trigger a two-way interaction to occur on-line between the unit of the facsimile equipment and a vendor of the facsimile equipment, the user interface being configured to generate information about use of the unit by the user, a communication element associated with each of the units capable of carrying results of the two-way local interaction from each of the units to a central location, and a component capable of managing the interactions of the users in different locations and collecting the results of the interactions at the central location.

55. The system of claim 54 in which the user interface can be electronically triggered based on user behaviors to generate two-way interactions with each of the users, each of the interactions relating to a corresponding specific one of the behaviors.

56. The system of claim 54 wherein the component is configured to provide access to the collection of results to the users of the commodity.

57. The system of claim 54 wherein the component is configured to provide access to the collection of results to vendors of the commodity.

58. The system of claim 54 wherein the component is configured to provide access to the collection of results to third parties.

59. The system of claim 54 in which the on-line interaction occurs by voice spoken through the facsimile machine's handset, transmitted by telephone line to a computer of the vendor, and stored at the vendor's computer.

60. A system comprising: units of a commodity that can be used by respective users in different locations, a user interface which is part of each of the units of the commodity and is configured to provide a medium for two-way local interaction between one of the users and the corresponding unit of the commodity for generating information about use of the unit of the commodity by the user, the user interface being configured to elicit information about (i) steps that a vendor of the commodity could take to improve the user's satisfaction or (ii) training or support provided for users of the commodity; a communication element associated with each of the units of the commodity capable of carrying results of the two-way local interaction from each of the units of the commodity to a central location, and a component capable of managing the interactions of the users in different locations and collection of the results of the interactions at the central location and provides access to the collection of results to a third party.

61. The system of claim 60 in which the results of the interactions are forwarded from the central location to the third party.

62. The system of claim 60 in which the results of the interactions are forwarded from the central location to a remote server for analysis.

63. The system of claim 60 in which the third party is a vendor of the commodity.

64. The system of claim 60 in which the third party is a designer of the commodity.

65. The system of claim 60 wherein the user interface presents user information in a style that comprises hypertext.

66. The system of claim 60 in which the user interface can be electronically triggered based on user behaviors to generate two-way interactions with each of the users, each of the interactions relating to a corresponding specific one of the behaviors.

67. The system of claim 60 in which the interactions are triggered based on repeated use of a feature of a unit of the commodity by the user.

68. The system of claim 60 in which the component is further configured to provide access to the collection of results to the users of the commodity.

69. A method for gathering information from units of a commodity in different locations, each unit of the commodity being coupled to a remote database on a network, the method comprising: eliciting user perceptions of respective units of the commodity through interactions at a user-interface of the respective unit; generating perception information based on inputs of the users at the respective user-interfaces; transmitting the perception information to the remote database; receiving the transmitted perception information from different units of the commodity; and collecting and storing the received information at the remote database.

70. The method of claim 69 further comprising enabling users of the commodities to access the received information.

71. The method of claim 69 further comprising enabling third parties to access the received information.

72. The method of claim 71 in which the third parties include vendors or designers of the commodities.

73. The method of claim 69 further comprising making a design change using the received information, or marketing the commodity using the received information.

74. The method of claim 69 wherein said eliciting step includes interacting with the users through the respective user-interfaces of units of commodity to elicit perception information about (i) steps that a vendor of the commodity could take to improve user satisfaction or (ii) training or support provided for users of the commodity.

What is claimed is:

1. A unit, comprising: a memory; a transmitter; and a processor, coupled to the memory and to the transmitter, configured to: monitor a product for an occurrence in the product of a trigger event of a predefined plurality of trigger events, increment a counter corresponding to the trigger event upon detection of the occurrence of the trigger event, cause the display of a user interface, configured to probe for information regarding a use of the product, if the counter exceeds a threshold, cause the memory to store an input received from the user interface, and cause the transmitter to transmit the input to a server.

2. The unit of claim 1, wherein the input reflects a request to schedule maintenance.

3. The unit of claim 1, wherein the input reflects a submission of a purchase order.

4. The unit of claim 1, wherein the input reflects a request for interactive assistance.

5. The unit of claim 1, wherein the processor is further configured to: monitor the product for an occurrence in the product of a second trigger event of the predefined plurality of trigger events, and increment a second counter corresponding to the second trigger event upon detection of the occurrence of the second trigger event in the product.

6. The unit of claim 5, wherein the processor is further configured to: cause the memory to store the second counter; and cause the transmitter to transmit a value of the second counter.

7. The unit of claim 1, wherein one trigger event of the predefined plurality of trigger events is an exiting of a feature of the product without a use of the feature.

8. The unit of claim 1, wherein one of the predefined plurality of trigger events is a problem associated with the product.

9. The method of claim 8, wherein the problem is an equipment problem.

10. The unit of claim 1, wherein a trigger event of the predefined plurality of trigger events is a use of at least one product feature.

11. The method of claim 10, wherein the at least one product feature is "undo."

12. The unit of claim 1, wherein the product is a medical instrument.

13. The unit of claim 1, wherein the product is a cellular telephone.

14. The unit of claim 1, wherein the processor is further configured to increment the counter corresponding to the trigger event upon detection of a second occurrence of the trigger event.

15. A method, comprising: monitoring a product for an occurrence in the product of a trigger event of a predefined plurality of trigger events; incrementing a counter corresponding to the trigger event upon detection of the occurrence of the trigger event in the product; displaying a user interface, configured to probe for information regarding a use of the product, if the counter exceeds a threshold; storing an input received from the user interface on a device; and transmitting the input to a server.

16. The method of claim 15, further comprising: forwarding the input based on a priority code associated with the input.

17. The method of claim 15, further comprising: monitoring the product for an occurrence in the product of a second trigger event of the predefined plurality of trigger events; incrementing a value of a second counter corresponding to the second trigger event upon detection of the second trigger event in the product.

18. The method of claim 17, further comprising: storing the second counter on the device; and transmitting a value of the second counter to the server.

19. The method of claim 15, wherein one of the predefined plurality of trigger events is a problem associated with the product.

20. The method of claim 15, wherein one of the predefined plurality of trigger events is an exiting of a feature of the product without a use of the feature.

21. The method of claim 19, wherein the problem is an equipment problem.

22. The method of claim 15, wherein one of the predefined plurality of trigger events is a use of at least one product feature.

23. The method of claim 22, wherein the at least one product feature is "undo."

24. The method of claim 15, wherein the product is a medical instrument.

25. The method of claim 15, wherein the product is a cellular telephone.

26. The method of claim 15, further comprising: incrementing the counter corresponding to the trigger event upon detection of a second occurrence of the trigger event in the product.

27. A tangible computer readable medium having stored thereon, computer executable instructions that, if executed by a computing device, cause the computing device to perform a method comprising: monitoring a product for an occurrence in the product of a trigger event of a predefined plurality of trigger events, incrementing a counter corresponding to the trigger event upon detection of the occurrence of the trigger event in the product; displaying a user interface, configured to probe for information regarding a use of the product, if the counter exceeds a threshold; storing an input received from the user interface on a device; and transmitting the input to a server.

28. The tangible computer readable medium of claim 27, wherein the monitoring further includes: monitoring the product for an occurrence in the product of a second trigger event of the predefined plurality of trigger events; and incrementing a value of a second counter corresponding to the second trigger event upon detection of the occurrence of the second trigger event in the product.

29. The tangible computer readable medium of claim 27, wherein the method further includes: storing the second counter on the device; and transmitting the value of the second counter to the server.

30. A physical unit, comprising: means for monitoring a product for an occurrence in the product of a trigger event of a predefined plurality of trigger events; means for incrementing a counter corresponding to the trigger event upon detection of the occurrence of the trigger event; means for probing for information regarding a use of the product if the counter exceeds a threshold; means for storing an input received from the means for probing; and means for transmitting the input to a server.

31. The unit of claim 30, further comprising: means for monitoring the product for an occurrence in the product of a second trigger event of the predefined plurality of trigger events; and means for incrementing a value of a second counter corresponding to the second trigger event upon detection of the occurrence of the second trigger event in the product.

32. The unit of claim 30, further comprising: means for storing the second counter on the device; and means for transmitting the value of the second counter to the server.