CA2357552A1 - Interactive digital video (i-dv) software product enabling real-time interactive messaging and contextual-commerce information exchange to be accessed though traditional-type media programming - Google Patents

Abstract

The present invention is a method and system for allowing users to select "interactive" mode on their DVD movies whereupon they shall be able to make enquiries, such as price and availability, about selected items on a particular scene, to be redirected to the merchant's web site for more details on the selected item and possibly fill out an "order" form and to be able to enter a chat room related to the movie or visit the web sites about the movie. The objective is to integrate Web-style content and DVD-based multimedia. While the video stream is playing, the user can have access to information available on the Web. The goal of the invention is to create revenue through sales of the product to individual users as well as royalties collected from merchants who make sales that are initiated through our software.) Also, there shall be room for customization of certain aspects of the software, such as logos, to accommodate the corporate customers.

Description

INTERACTIVE DIGITAL VIDEO (1-DV) SOFTWARE PRODUCT ENABLING
REAL-TIME INTERACTIVE MESSAGING AND CONTEXTUAL-COMMERCE
INFORMATION EXCHANGE TO BE ACCESSED THOUGH TRADITIONAL-TYPE MEDIA PROGRAMMING.
Inventors (s): John Andrew Vasilakos Applicant(s): John Andrew Vasilakos Definition:
The present invention is a method and system for allowing users to select "interactive" mode on their DVD movies whereupon they shall be able to make enquiries, such as price and availability, about selected items on a particular scene, to be redirected to the merchant's web site for more details on the selected item and possibly fill out an "order" form and to be able to enter a chat room related to the movie or visit the web sites about the movie. The objective is to integrate Web-style content and DVD-based multimedia. While the video stream is playing, the user can have access to information available on the Web. The goal of the invention is to create revenue through sales of the product to individual users as well as royalties collected from merchants who make sales that are initiated through our software.) Also, there shall be room for customization of certain aspects of the software, such as logos, to accommodate the corporate customers.

What is claimed is:
1.1 Purpose The following claims describe the functional and performance requirements of Eye2Buy Technology's i-DV software.
These claims will:
(1) Establish the basis on what the software product must do.

(2) Serve as a basis for enhancement and product evolution.
1.2 Scope The product shall allow users to select "interactive" mode on their DVD movies whereupon they shall be able to make enquiries, such as price and availability, about selected items on a particular scene, to be redirected to the merchant's web site for more details on the selected item and possibly fill out an "order" form and to be able to enter a chat room related to the movie or visit the web sites about the movie.
The objective is to integrate Web-style content and DVD-based multimedia.
While the video stream is playing, the user can have access to information available on the Web, and to create revenue through sales of the product to individual users as well as royalties collected from merchants who make sales that are initiated through our software.) Also, there shall be room for customization of certain aspects of the software, such as logos, to accommodate the corporate customers.
1.3 Terms, Acronyms, and Abbreviations Please refer to Appendix A for definitions of terms, acronyms, and abbreviations specific to the information presented in this SRS.
1.4 References Please refer to Appendix B for list of reference sources used in the execution of this proj ect.
1.5 Overview This document provides a description of the requirements of the product.
Section 2 of the Software Requirement Specification gives the detailed descriptions of the product including the major components and product design. Section 3 provides specific functional requirements of the different components of the product and the performance criteria.
This SRS defines two categories of requirements:
(1) Functional requirements - Functional requirements are independent of the technology used to implement the system. They are defined in this SRS in terms of events to which the system must provide a response. They are actions or activities that the system must support.
(2) Non-functional requirements - Non-functional requirements limit the range of possible implementation decisions available to system developers in their efforts to meet functional requirements. They are stated as guidelines for system developers and need further specification by individual system developers prior to procurement evaluation.

2.1 Product Perspective This product will be a web-based program requiring an Internet browser (i.e.
Internet Explorer 4.0 or higher/ Netscape Communicator 4.08 or higher) and a DVD
player.
The initial version of the product shall run on Window's 9x and 2000. Future versions shall run on Unix and Apple platforms.
2.2 Operations Concept <Describe how this system will be used. Define problem domain processes in which this system will be used. Define how this system interacts with other systems from an operational perspective. >
2.3 User Characteristics The users of this product need only be familiar with using Internet and be able to operate their DVD-ROM players.
2.4 General Constraints The minimum system requirements are:
Windows 9x, Windows Me or Windows 2000 SOOMHz PC with 256 MB of RAM
20 MB of disk space for the application 800x600 monitor DVD-ROM
Graphics card with 8 MB memory Sound card Internet connection IE 5 or Netscape 4.8 and above DirectX 8.0 WinDVD
2.5 Assumptions and Dependencies State assumptions that if changed would affect the specific requirements in section 3.

3.1 Requirements This section can be viewed as having two key subdivisions: section 3.1 and its subsections, which define functional requirements and sections 3.2 through 3.6, and their subsections, which define nonfunctional requirements. The Test Plan associated with this SRS
shall define test cases for functional and non-functional requirements defined in these sections of the SRS.
This section contains the detailed statement of functional requirements for i-DV.
Each functional requirement has an introduction describing the purpose of the function and background information about the requirement. The introduction to each requirement is followed by sections describing the input/processing/output operations necessary to fulfill the requirement. Each requirement begins on a new page of this SRS to that they may be easily referenced when reading the specification.

3.1.1 Main Page Starting the application 3.1.1.1 Introduction This is the starting point of the application. When the application starts it displays a static image (see Output section.) If a DVD is present, the DVD menu items are displayed. In addition, an "Interactive" menu item is added by the application. If there is no DVD in the drive, only the static image is displayed along with the DVD
control buttons. No Menu items will be displayed until a DVD is inserted.
3.1.1.2 Inputs (What data is necessary to recognize an event? What is the valid range of each data element? Define only acceptable conditions for an operation to begin. ) User starts the application by running "i-DV.exe".
3.1.1.3 Processing If a DVD is present, the static image will be replaced by the DVD's starting scene in the Video Window created by the application. As usual, the DVD's menu items will be displayed. However, the application adds another menu item labeled "Interactive."
This is a CflatImgWnd that is laid on top of the video window. Selecting this item takes the user to the next stage.
If there is no DVD in the drive when the application starts, the static image (also a CFlatImgWnd) remains on the screen until either a DVD is inserted into the drive or the application is exited.
3.1.1.4 Outputs The user is presented with the DVD's starting scene.

3.1.2 Interactive Page Enter "Interactive Scene Selection" screen.
3.1.2.1 Introduction This function takes the user to the main screen called "Interactive Scene Selection"
screen. While in this screen, the user can select a scene to interact with, return to the main menu, or start the movie.
3.1.2.2 Inputs User clicks on the "Interactive" menu item from the DVD's main screen. This menu item is added to the DVD's own menu items by the application.
3.1.2.3 Processing The application creates a "Scene Selection" screen and lays it on top of the Video Window. The status of the Video Window is not changed to "hidden"; it is merely covered by the group of CFlatImgWnd objects, such as the three scene-windows and the buttons. A scene can be selected by clicking on its image.
3.1.2.4 Outputs ;ction" screen.
Figure 1: Interactive Scene Selection screen 3.1.3 Start Interactivity Start Interactivity 3.1.3.1 Introduction Allows the user to interact with the DVD through the scene selected in the previous step.
3.1.3.2 Inputs The user clicks on a specific scene (previous step.) 3.1.3.3 Processing DVD starts playing the selected scene. The application appends a window to the bottom of the screen. This window contains the navigation buttons, such as play, rewind, etc., a button with the movie studio's logo that will take the user to the studio's web site, two Web buttons, labeled "WWW" that will take the user to sites related to the movie, a Chat button connecting the user to a chat room dedicated to the movie and one or more buttons representing the acquirable items in the selected scene. Clicking any of the buttons sends a message to the parent window, ShowDVDDIg.
3.1.3.4 Outputs At this stage, the DVD's operations buttons (play, fast forward, pause, ...) shall always be visible. The "Menu" icon shall take the user to the DVD's main screen, not the application's main screen.
Figure 2: Main Interactivity Toolbar 3.1.4 Item selection Select Available Item For Sale EyeCon.
3.1.4.1 Introduction Present the user with the information, and navigation capability, concerning the selected item in the previous step.
3.1.4.2 Inputs User clicks on the acquirable item button (e.g. the "Flowers" button in the previous step.) 3.1.4.3 Processing Selecting an acquirable item shall send a message to the parent window to collapse all the buttons except for the selected item's button, create a window to display the product image (productWnd) and a IE Control window (ActiveX control) to display html (displaying the price and manufacturer of the item.) 3.1.4.4 Outputs The user shall be presented the URL of manufacturer, if "More Info" is required. Also added shall be two new buttons: "Eye" and "Buy."
Figure 3: Information on selected item 3.1.5 "Eye" button Select "Eye" icon.
3.1.5.1 Introduction Allows the user to get more detailed information.
3.1.5.2 Inputs The user clicks on the "Eye" button in the previous screen.
3.1.5.3 Processing At this stage the user is presented with the means to get more information about the item selected. The "Eye" button is replaced with three new buttons:
"i"nformation button, "www" button and a "price" button. The functionality of these buttons is inherent in their names! The parent window will change the content on the IE
control window (currently displaying "Demo Version") to display html.
3.1.5.4 Outputs The user is presented with the URL of the merchant carrying the item, a direct link to the merchant's web site (WWW button), a Price button and a Buy button.
Figure 4: "Eye" stage - Get more info on the item 3.1.6 "Buy"
Select "Buy" icon.
3.1.6.1 Introduction Allows the user to select the attributes of the selected item.
3.1.6.2 Inputs User clicks the "Buy" button in the previous screen.
3.1.6.3 Processing The user is at the final stage of deciding to buy the item or not. The item information buttons, along with the "Buy" button, from previous screen are replaced by OK
and Cancel buttons. The EI control window from previous stage is hidden and replaced by another window called "BuyDlg" window. This window contains Windows controls (such as selection buttons, check boxes, etc.) that allow the user to manipulate the attributes of the item such as color, quantity, etc. The user can either select the check mark button to finalize the purchase or cancel.
3.1.6.4 Outputs The user shall be presented with a set of item attributes whose values can be selected or specified. User has the option of finalizing the purchase or canceling.
Figure 5: "Buy" stage - select attributes of the item 3.2 External Interface Requirements This section provides a high-level set of interface requirements to systems outside its automation boundary.
3.2.1 User Interfaces Mouse inputs are required for navigation.
3.2.2 Hardware Interfaces At least a Pentium class PC with 256 MB RAM, 20 MB of free disk space, Mouse, DVD player and Internet connection.
3.2.3 Software Interfaces Win 9x or 2000, Internet Explorer 5 or Netscape 4.8 and above.
3.2.4 Communications Interfaces A fast connection is preferred. At least a 56.6K modem is required.
3.3 Performance Requirements The application shall be scalable which implies the number of database requests, the number of connections to the system and number of simultaneous users that can be handled shall be limited by the hardware used in a system. The response time for loading pages depends on Internet connection speed.
3.4 Design Constraints Specify detailed characteristics and definitions of items listed in section 2.5 of the SRS.
3.5 Attributes Project i-DV will conform to the following non-functional requirements.
Although they do not change the functional requirements of the i-DV, they are important in the minimization of cost over the system's life cycle.
3.5.1 Reliability Assuming the user system meets all hardware and software requirements, the product should run reliably since every resource needed for the application is downloaded directly from the server and run on the clients' web browsers.
3.5.2 Availability Provided by web server.
3.5.3 Maintainability The application is maintainable because it can easily be upgraded by adding more materials to the database. Proper commenting throughout the source code and documentation shall be maintained for the duration of the project life cycle.
The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment 3.5.4 Recoverability The software shall handle errors by outputting an appropriate error message informing the user of the occurrence of an exception. If recovery is not possible, the software shall exit gracefully.
3.5.5 Security Provided by web server.
3.5.6 Compatibility The software shall run on all new browsers and handle older browsers gracefully.
3.5.7 Extendibility The software shall be extendible, that is, more functionality and modules can be added to the application easily.

3.6 Other Requirements This section contains i-DV requirements that relate to the target environment for the system.
3.6.1 Data Base Specify the requirements of any database that is to be developed as part of the product. Include data element names and definitions, frequency of use, accessing capabilities, relationships to other data elements, records, and files, static and dynamic organization, and retention requirements.
3.6.2 Operations No changes in operation are required by the system.
3.6.3 Site Adaptation No changes need to occur at the installation site to accommodate this system.

Appendix A - Terms, Acronyms, and Abbreviations Glossary' Actor An actor represents what interacts with the system. Actors represent everything that needs to exchange information with the system. An actor represents a certain role that a user can play. [J92] Primary actors are actors who are going to use the system directly. Secondary actors are actors supervising and maintaining the system. An actor can be an external system or application that interacts with the system.
Application Program Interface (API): Defined in the DOD Generic Technical Reference Model, this layer defines the rules and protocols to invoke Application Platform Layer services. The APIs insulate the support applications from the details of the computing hardware and operating systems. In a client-server environment, the APIs are used to implement the client-side and server-side applications and facilitate communications and data interchange between clients and servers. [TAFIM]
Event: An independent occurrence outside the system, an occurrence of time, or (in a real-time system) an occurrence detected inside the system that causes activity in, or results from, the system. [K88]
Exception Handling: An exception is an event that causes suspension of normal program execution. [IEEE610.12] It is important to separate the handling of exceptions from their detection. Exceptions, when detected, can cause control to be passed to a software component that attempts to correct the fault and/or return the system to a state in which it can perform its required functions (recovery) [IEEE610.12]. Exception handling can address: abnormal cases leading to preemptive action by the hardware or operating system, abnormal cases that must lead to termination as early as possible to avoid catastrophic consequences, and software fault tolerance. Exception handlers follow two primary models: resumption model -resume operation after action of an exception handler and only terminate if a return statement at the end of the exception handler is executed; termination model -the program unit in which the fault is detected is automatically terminated following execution of the exception handler, which is viewed as replacing the remaining body of the program unit and which is either in the program unit in which the fault is detected or in the chain of program units which called the .failing program unit.
External Requirements: Constraints that are neither product nor process related (inter-operability, legislative, and cost constraints). These requirements are especially important to state in the SRS because they are often implied causing validation and verification problems after system development is complete.
Functional Requirements: Events to which the system must provide a response.
Functional requirements are also called behavioral or operational requirements. They are actions or activities that the system must support. A functional requirement will state the input or stimuli necessary to recognize that the event has occurred.
It will state the required output or response required by the system for the recognized event.
It will state WHAT the system's internal behavior must be to relate the input to the required output.
Non-functional Requirements: Requirements that limit the range of possible implementation decisions available to system developers in their efforts to meet Terms in italics are defined elsewhere in this Appendix.

functional requirements. Non-functional requirements are also called non-behavioral requirements. There are three main types of non-functional requirements:
product requirements, process requirements, and external requirements.
ODBC (Open Database Connectivity): A Windows Dynamic Link Library (DLL) that presents a single Application Program Interface (API) to any Windows application that needs to connect to a database. It is based on X/Open Co. and SQL
Access Group (SAG) standard Call Level Interface specification. [M93a]
Process: A systematic series of mechanisms, tasks, and/or procedures directed towards an end. The software engineering process documentation defines the sequence of steps used to produce a finished product. Each step is described as a task that is performed by using a software engineering methodology or an administrative procedure, and it prescribes the automated tools and techniques used. [H87] A
set of activities, methods, and practices that guide people and their software tools in the production and maintenance of software.
Reusability: The degree to which a software module or other work product can be used in more than one computer program or software system [IEEE610.12]. Prieto-Diaz [P93c] suggests the following reuse taxonomy: by-substance, by-scope, by-mode, by-technique, by-intention, by-product. Areas of reuse can be: idea reuse, artifact reuse, procedures reuse, vertical reuse (within same domain or application area), horizontal reuse (use of generic parts in different applications), planned reuse, ad-hoc reuse, compositional reuse, generative reuse (reuse at the specification level), black-box reuse (with no modifications), and white-box reuse (with expectation of modification). Reuse products can be: source code, designs, specifications, objects, text, and architectures.
Robustness: The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions.
[IEEE610.12]
Satisfaction: The system should be pleasant to use, so that users are subjectively satisfied when using it; they like it [N93]. Example metrics: objective measures of physical stress, soliciting subjective opinions via questionnaire.
Use Case: A use case is a complete course of events, seen from a user's perspective.
An actor using the system in a behaviorally related sequence of transactions in a dialogue with the system [J92].
User: The actual person who uses the system (see Actor for contrast).
Validation: "Are we building the right product?" [B81] The formal process of checking designs, code, test plans, and final software products against requirements.
Verification: "Are we building the product right?" [B81] The process of checking results of each stage of the software life cycle to see if it has the correct relationship to results from the previous stage. [D90]
Acronyms and Abbreviations TBD To Be Determined UI User Interface API The specification of a set of functions which define the interface to a piece are/library.
of softw EyeCon Eye2Bye's icons EyeBrowserEye2Buy's browser DBMS Data Base Management System ODBC Microsoft Corp.'s Open Database Connectivity API

OSI Open Systems Interconnection SAT System Acceptance Testing SQA Software Quality Assurance SRS Software Requirements Specification TCP/IP Transmission Control Protocol/Internet Protocol Appendix B - References [B81] B. BOEHM, Software Engineering Economics, Prentice Hall, New Jersey, 1981.
[D90] A. DAMS, Software Requirements: Analysis and Specification, Prentice Hall, New Jersey, 1990.
[H87] W. HUMPHREY and W. SWEET, A Method for Assessing the Software Engineering Capability of Contractors, CMU/SEI-87-TR-23, ADA187230, Software Engineering Institute.
[IEEE610.12] STANDARDS COORDINATING COMMITTEE OF THE IEEE
COMPUTER SOCIETY, IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990, IEEE, New York, Corrected Edition 1991.
[J92] I. JACOBSON, M. CHRISTERSON, P. JONSSON, and G. OVERGAARD, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, New York, 1992.
[K88] J. KOWAL, Analyzing Systems, Prentice Hall, New Jersey, 1988.
[M93a] S. MORSE, Open Database Connectivity: One Size Fits All, Network Computing, April, 1993, pp 140-142.
[N93] J. NIELSEN, Usability Engineering, Academic Press, New York, 1993.
[P93c] R. PRIETO-DIAZ, Status Report: Software Reusability, IEEE Software, (May 1993), pp 61-66.
[TAFIM] Department of Defense Technical Architecture Framework for Information Management (TAFIM), Volume 2: Technical Reference Model and Standards Profile Summary, Version 2.0, 30 June 1994.

Claims