PCT
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`International Bureau
`
`
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`
`
` WO 00/59594
`
`(11) International Publication Number:
`_
`(51) International Patent Classification 7 :
`A63F 13/06, G06F 3/033
`
`
`(43) International Publication Date:
`12 October 2000 (12.10.00)
`
`(74) Agents: HAYES, Daniel, L. et al.; Suite 500, 421 W. Riverside
`(21) International Application Number:
`PCT/USOO/08848
`
`
`Avenue, Spokane, WA 99201 (US).
`
`
`
`
`
`
`
`(81) Designated States: AE, AL, AM, AT, AU, AZ, BA, BB, BG,
`BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE,
`ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP,
`KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA,
`MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT. RO, RU,
`SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG,
`UZ, VN, YU, ZA, ZW, ARIPO patent (GH, GM, KE, LS,
`MW, SD, SL, SZ, TZ, UG, ZW), Eurasian patent (AM, AZ,
`BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE,
`CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC,
`NL, PT, SE), OAPI patent (BF, BJ, CF, CG, CI, CM, GA,
`GN, GW, ML, MR, NE, SN, TD, TG).
`
`Published
`With international search report.
`Before the expiration of the time limit for amending the
`claims and to be republished in the event of the receipt of
`amendments.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(22) International Filing Date:
`
`3 April 2000 (03.04.00)
`
`(30) Priority Data:
`60/127,972
`09/483,113
`09/497,914
`
`6 April 1999 (0604.99)
`14 January 2000 (14.01.00)
`4 February 2000 (04.02.00)
`
`US
`US
`US
`
`(71) Applicant: MICROSOFT CORPORATION [US/US]; One
`Microsoft Way, Redmond, WA 98052 (US).
`
`(72) Inventors: ANDREWS, Marcus, J.; 9206 162nd Place NE,
`Redmond, WA 98052 (US).
`FIRDOSH, Bhesania, K.;
`Apartment H—202, 10820 113th Court NE, Kirkland, WA
`98033 (US). HOLAN, Doron, J.; 1266 NE 87th, Kirkland,
`WA 98033 (US).
`INGMAN, Robert; 1121 37th Avenue,
`Seattle, WA 98122 (US). LEATHAM, Scott, R.; 13029
`326th Avenue NE, Duvall, WA 98019 (US). PERETZ,
`Ervin; 3649 E. Ames Lake Lane, Redmond, WA 98053
`(US). RAY, Kenneth, D.; 8127 149th Place NE #D320,
`Redmond, WA 98052 (US). SHARMA, Om, K.; 10933
`127th Place NE, Kirkland, WA 98033 (US). VERES, James,
`E.; 14029 17lst Lane NE, Woodinville, WA 98072 (US).
`
`(54) Title: GAME CONTROL DEVICE HAVING GENRE DATA
`
`
`
`
`
`
`
`
`
`Application
`
`0/8 and
`System
`Services
`
`USB Driver/
`Port
`
`Control Logic
`
`HID
`Descriptors
`
`Non—HID
`Descriptors
`
`‘ USB Port
`
`
`
`(57) Abstract
`
`A computer peripheral has a processor, non—volatile memory, and a plurality of controls. The non—volatile memory holds control
`mappings corresponding to a plurality of application program genres. The control mappings indicate actions to be performed in application
`programs of particular genres in response to actuation of particular controls. The control mappings indicate controls by unique string indexes
`that are also used in HID control descriptors associated with the computer peripheral.
`
`
`SCEA EX. 1004 Page 1
`
`SCEA Ex. 1004 Page 1
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`
`Albania
`Armenia
`Austria
`Australia
`Azerbaijan
`Bosnia and Herzegovina
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`C6te d‘Ivoire
`Cameroon
`China
`Cuba
`Czech Republic
`Germany
`Denmark
`Estonia
`
`ES
`FI
`FR
`GA
`GB
`GE
`GH
`GN
`GR
`HU
`IE
`IL
`IS
`IT
`JP
`KE
`KG
`KP
`
`KR
`KZ
`LC
`LI
`LK
`LR
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People‘s
`Republic of Korea
`Republic of Korea
`Kazakstan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`LS
`LT
`LU
`LV
`MC
`MD
`MG
`M K
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`PT
`R0
`RU
`SD
`SE
`SG
`
`Lesotho
`Lithuania
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`The former Yugoslav
`Republic of Macedonia
`Mali
`Mongolia
`Mauritania
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Singapore
`
`SI
`SK
`SN
`SZ
`TD
`TG
`TJ
`TM
`TR
`TT
`UA
`UG
`US
`UZ
`VN
`YU
`ZW
`
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tajikistan
`Turkmenistan
`Turkey
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`Viet Nam
`Yugoslavia
`Zimbabwe
`
`
`
` AL
`
`AM
`AT
`AU
`AZ
`BA
`BB
`BE
`BF
`BG
`BJ
`BR
`BY
`CA
`CF
`CG
`CH
`CI
`CM
`CN
`CU
`CZ
`DE
`DK
`EE
`
`SCEA EX. 1004 Page 2
`
`SCEA Ex. 1004 Page 2
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`GAME CONTROL DEVICE HAVING GENRE DATA
`
`RELATED APPLICATIONS
`
`This is a continuation-in—part application of a prior US Patent Application
`
`filed January 10, 2000,
`
`titled “Mapping Input—Device Functions to Software
`
`Application Input Commands,” serial number 09/483,113.
`
`Priority is hereby
`
`claimed to this earlier application.
`
`10
`
`TECHNICAL FIELD
`
`This invention relates generally to the use of peripheral input devices with
`
`software applications and more specifically to the use of genres in conjunction with
`
`such input devices and software applications.
`
`15
`
`BACKGROUND OF THE INVENTION
`
`Various
`
`input devices are available that permit a computer user
`
`to
`
`communicate with a computer. A typical personal computer offers input devices
`
`such as a keyboard and a mouse. Numerous other devices are available, such as
`
`drawing pads, joysticks, and steering wheels (for use with driving games). These
`
`20
`
`devices can be connected to a computer, and they permit the user to communicate
`
`information to the computer;
`
`the information communicated instructs software
`
`applications running on the computer to perform specified actions.
`
`Ideally,
`
`a computer user
`
`loads
`
`a software application,
`
`connects an
`
`appropriate device to the computer, and the device and software work together
`
`25
`
`Without further configuration by the user. This ideal, however, has not been
`
`realized in prior systems.
`
`SCEA Ex. 1004 Page 3
`
`SCEA Ex. 1004 Page 3
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`2
`
`In order for a device to work with a given software application, there must
`
`be a defined relationship between the controls on the device and actions that the
`
`software application performs. However, there are few standards governing the
`
`way in which this relationship is defined. Traditionally, software developers design
`
`software applications to support the most common devices and to provide a device
`
`mapping control panel for those users who own other devices. This approach,
`
`however, has drawbacks: A software developer who wants to design an application
`
`to work well with many devices must know what controls are available on each
`
`device (e.g., buttons, levers, etc.) and how the device notifies the computer system
`
`of operational events (e.g., an input of 1001 signifies the pressing of a button).
`
`Additionally,
`
`the software developer must make design decisions as to which
`
`devices the software will support, and, on those devices that will be supported, how
`
`the controls will map to the actions that the software performs. This is a labor-
`
`intensive process for the software developer. Moreover,
`
`if a user owns an
`
`unsupported device,
`
`the user must generally resort to mapping the unsupported
`
`device manually by referring to generic pictures and tables in an application’s
`
`manual and using the device mapping control panel provided with the application.
`
`This is a notoriously difficult process.
`
`Some input device manufacturers address the problem of ensuring that
`
`specific applications work well with the device by supplying a software component
`
`with the device that dynamically reconfigures the device based on guesses as to
`
`what actions the application expects the device to support. Some manufacturers of
`
`devices with newer features provide filters to accommodate existing applications;
`
`frequently, these filters simulate keyboard presses or mouse movements for games
`
`that do not recognize enhanced features of the new device. Alternatively, some
`
`devices are supplied with mapping software that detects the presence of certain
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 4
`
`SCEA Ex. 1004 Page 4
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`3
`
`applications on the system and configures the device to work better with those
`
`
`applications. However, these ad hoc approaches are error prone, may result in a
`
`relationship between device controls and software actions that feels unnatural to the
`
`user, and can only provide support for applications the device manufacturer knows
`
`about and chooses to support.
`
`The Human Interface Device (HID) standard, defined in conjunction with
`
`the Universal Serial Bus (USB) standard, addresses problems such as these. Using
`
`HID, an input device can store information about its controls. This information can
`
`be obtained by a requesting application program.
`
`10
`
`HID data generally describes the characteristics of device controls and the
`
`format of data generated by the controls.
`
`In addition, HID allows different labels or
`
`“usages” to be assigned to the controls of an input device. For example, a button
`
`might be designated as a “fire” button, as “buttonl”, “button2,” etc.
`
`In addition,
`
`HID can include “aliases” for a control. A given control might have a plurality of
`7) LC
`
`15
`
`aliases such as “buttonl,” “fire,
`
`torpedo,” etc.
`
`Usages and aliases, if used in a uniform and agreed upon way, provide useful
`
`hints about how to use a certain control on an input device.
`
`In some cases, for
`
`instance,
`
`the “fire” button will have an obviously corresponding action in an
`
`application program.
`
`In other cases, however, the usages and aliases might not
`
`correspond directly to any terminology known by the application program.
`
`A further complicating factor is that there is no agreed upon standard for
`
`naming HID controls. Even if there were such a standard, it would remain—in may
`
`cases—a very difficult task for an application program to determine an optimum set
`
`of mappings between numerous input device controls and the actions available in
`
`the application program. A determination such as this would require a complex
`
`20
`
`25
`
`algorithm, tailored specifically for the application program.
`
`SCEA EX. 1004 Page 5
`
`SCEA Ex. 1004 Page 5
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`4
`
`The difficulty lies not in finding a workable control for a particular action,
`
`but in assigning a combination of controls to a combination of desired actions. For
`
`example, any number of controls might work for a “drop bomb” action: a
`
`“buttonl,” a “button2,” a “fire” button,” a “trigger” button, etc. However, assigning
`
`the combination of these controls to a combination of different actions, such as
`
`“drop bomb,” “start engine,” “lower flaps,” and “zoom” can be much more
`
`difficult. The task is actually made more difficult by the use of numerous aliases
`
`for each control—each control might duplicate the same aliases.
`
`Accordingly, even with HID devices it is difficult for an application program
`
`to determine desirable control/action mappings for unanticipated input devices—
`
`input devices for which the application program does not have a pre-defined
`
`assignment of controls. The system described below solves this problem.
`
`SUMMARY OF THE INVENTION
`
`Described below is a game control device or other computer peripheral that
`
`stores information relating to genres.
`
`This information can be retrieved by
`
`programs running on a host computer. The information includes sets of control-to—
`
`action mappings for thc controls of the control device. There is a set for every
`
`supported genre.
`
`To establish a desirable combination of control-to—action
`
`mappings, the host computer simply requests the control mappings of the correct
`
`genre from the control device.
`
`The described embodiment is implemented in a USB control device, which
`
`includes HID report descriptors. However, the genre data is maintained within the
`
`control device in a non-HID format. The genre data is correlated with the HID
`
`report descriptors by the use of unique string indexes within the HID report
`
`descriptors. More specifically, each control is given a unique string index within
`
`l0
`
`15
`
`20
`
`25
`
`SCEA Ex. 1004 Page 6
`
`SCEA Ex. 1004 Page 6
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`the HID data. The actions specified in the non-HID data use these same string
`
`5
`
`indexes to specify controls.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Fig. l is a block diagram representing a computer system in which aspects of
`
`the invention may be incorporated;
`
`Fig. 2 is a block diagram showing the use of an input device mapper with
`
`input devices and software applications;
`
`Fig. 3 is a block diagram showing a sample control—semantic correlation and
`
`10
`
`its structure;
`
`Fig. 4 is a block diagram showing a sample action-semantic correlation and
`
`its structure;
`
`Fig. 5 is a block diagram showing a sample mapping created by an input
`
`device mapper;
`
`Fig. 6 is an image of an input device with action labels;
`
`Fig. 7 is a flowchart illustrating a process by which an input device mapper
`
`is used;
`
`Fig. 8 is a block diagram showing the use of a mapping created by an input
`
`device mapping;
`
`Fig. 9 is a block diagram of an exemplary computer and game control
`
`device;
`
`Fig. 10 is a block diagram of a non—HID data descriptor;
`
`Fig. 11 is a flowchart showing methodological aspects of the described
`
`embodiment.
`
`Figs. 12 and 13 are flowcharts showing methodological aspects of a USB
`
`implementation.
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 7
`
`SCEA Ex. 1004 Page 7
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
`
`6
`
`Computer Environment
`
`Figure 1 and the following discussion are intended to provide a brief general
`
`description of a suitable computing environment in which the invention may be
`
`implemented. Although not required, the invention will be described in the general
`
`context of computer-executable instructions, such as program modules, being
`
`executed by a computer, such as a client workstation or a server. Generally,
`
`program modules include routines, programs, objects, components, data structures
`
`and the like that perform particular tasks or implement particular abstract data
`
`types. Moreover, those skilled in the art will appreciate that the invention may be
`
`practiced with other computer system configurations, including hand-held devices,
`
`multi-processor
`
`systems, microprocessor-based
`
`or programmable
`
`consumer
`
`electronics, home game machines, network PCs, minicomputers, mainframe
`
`computers and the like.
`
`The invention may also be practiced in distributed
`
`computing environments where tasks are performed by remote processing devices
`
`that are linked through a communications network. In a distributed computing
`
`environment, program modules may be located in both local and remote memory
`
`storage devices.
`
`As shown in Fig. 1, an exemplary system for implementing the invention
`
`includes a general purpose computing device in the form of a conventional personal
`
`computer 20 or the like, including a processing unit 21, a system memory 22, and a
`
`system bus 23 that couples various system components including the system
`
`memory to the processing unit 21. The system bus 23 may be any of several types
`
`of bus structures including a memory bus or memory controller, a peripheral bus,
`
`and a local bus using any of a variety of bus architectures. The system memory
`
`includes read-only memory (ROM) 24 and random access memory (RAM) 25. A
`
`10
`
`15
`
`20
`
`25
`
`SCEA Ex. 1004 Page 8
`
`SCEA Ex. 1004 Page 8
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`7
`
`basic input/output system 26 (BIOS), containing the basic routines that help to
`
`transfer information between elements within the personal computer 20, such as
`
`during start—up,
`
`is stored in ROM 24. The personal computer 20 may further
`
`include a hard disk drive 27 for reading from and writing to a hard disk, not shown,
`
`a magnetic disk drive 28 for reading from or writing to a removable magnetic disk
`
`29, and an optical disk drive 30 for reading from or writing to a removable optical
`
`disk 3l such as a CD-ROM or other optical media. The hard disk drive 27,
`
`magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23
`
`by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical
`
`drive interface 34, respectively. The drives and their associated computer—readable
`
`media provide non-volatile storage of computer
`
`readable instructions, data
`
`structures, program modules and other data for the personal computer 20. Although
`
`the exemplary environment described herein employs a hard disk, a removable
`
`magnetic disk 29 and a removable optical disk 31, it should be appreciated by those
`
`skilled in the art that other types of computer readable media which can store data
`
`that is accessible by a computer, such as magnetic cassettes, flash memory cards,
`
`digital video disks, Bernoulli cartridges,
`
`random access memories (RAMS),
`
`read-only memories (ROMS) and the like may also be used in the exemplary
`
`operating environment.
`
`A number of program modules may be stored on the hard disk, magnetic disk
`
`29, optical disk 3], ROM 24 or RAM 25, including an operating system 35, one or
`
`more application programs 36, other program modules 37, program data 38, and an
`
`input device mapper 39. A user may enter commands and information into the
`
`personal computer 20 through input devices such as a keyboard 40, a pointing
`
`device 42, a drawing pad 65, or a game controller such as driving game controller
`
`66. Other input devices (not shown) may include a microphone, joystick, game pad,
`
`10
`
`15
`
`20
`
`25
`
`SCEA Ex. 1004 Page 9
`
`SCEA Ex. 1004 Page 9
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`8
`
`satellite disk, scanner or. the like. These and other input devices are often connected
`
`to the processing unit 21 through a serial port interface 46 that is coupled to the
`
`system bus, but may be connected by other interfaces, such as a parallel port, game
`
`port, universal serial bus (USB), or a 1394 high-speed serial port. A monitor 47 or
`
`other type of display device is also connected to the system bus 23 via an interface,
`
`such as a video adapter 48. In addition to the monitor 47, personal computers
`
`typically include other peripheral output devices (not shown), such as speakers and
`
`printers.
`
`10
`
`15
`
`20
`
`25
`
`The personal computer 20 may operate in a networked environment using
`
`logical connections to one or more remote computers, such as a remote computer
`
`49. The remote computer 49 may be another personal computer, a server, a router,
`
`a network PC, a peer device or other common network node, and typically includes
`
`many or all of the elements described above relative to the personal computer 20,
`
`although only a memory storage device 50 has been illustrated in Fig.
`
`l. The
`
`logical connections depicted in Fig.
`
`1 include a local area network (LAN) 51 and a
`
`wide area network (WAN) 52. Such networking environments are commonplace in
`
`offices, enterprise-wide computer networks, Intranets and the Internet.
`
`When used in a LAN networking environment, the personal computer 20 is
`
`connected to the local network 51 through a network interface or adapter 53. When
`
`used in a WAN networking environment,
`
`the personal computer 20 typically
`
`includes a modem 54 or other means for establishing communications over the Wide
`
`area network 52, such as the Internet. The modem 54, which may be internal or
`
`external,
`
`is connected to the system bus 23 via the serial port interface 46. In a
`
`networked environment, program modules depicted relative to the personal
`
`computer 20, or portions thereof, may be stored in the remote memory storage
`
`device.
`
`It will be appreciated that the network connections shown are exemplary
`
`SCEA EX. 1004 Page 10
`
`SCEA Ex. 1004 Page 10
`
`

`

`WO 00/59594
`
`PCT/U800/08848
`
`and other means of establishing a communications link between the computers may
`
`9
`
`be used.
`
`Input Device Mapper
`
`Figure 2 depicts the use of an input device manager. Input device mapper 39
`
`is a software module that provides an interface between application programs 36
`
`and input devices, such as devices 42, 65, 66, and 67.
`
`Input device mapper 39
`
`could be a system services component of an operating system running on computer
`
`20, such as operating system 35, or a stand-alone software module, as shown in Fig.
`
`10
`
`2.
`
`Input device mapper 39 is associated with one or more genre descriptions,
`
`such as genre descriptions 211-213. An application program genre is a collection
`
`of games having similarities in operation and input device usage. A genre
`
`description for a specific genre defines mappings between input device controls and
`
`actions to be performed in a game of the genre. These actions are defined in terms
`
`semantics or labels.
`
`In the system described below, agreed upon genre semantics or labels are
`
`preferably publicized so that input device manufacturers and software developers
`
`can use input device mapper 39 in the manner described below to allow devices and
`
`software to work together. Specifically, a plurality of genres are defined and a set
`
`of possible actions is defined for each genre. This will be explained in more detail
`
`below.
`
`In Fig. 2, genre description 211 corresponds to a “driving game” genre
`
`(corresponding to example genre 1
`
`in the Examples section below). Genre
`
`description 212 corresponds to a “role playing” genre (corresponding to example
`
`genre 3 in the Examples section below). Genre description 213 corresponds to a
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 11
`
`SCEA Ex. 1004 Page 11
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`10
`
`“computer-aided design” (CAD) genre (corresponding to example genre 8 in the
`
`Examples section below).
`
`Input devices 65, 66, 67, and 42 provide input device mapper 39 with
`
`correlations or control mappings between their controls and the semantics of genre
`
`descriptions 211-213, called “control-semantic” correlations 221-225 (abbreviated
`
`“C-S correlation”).
`
`C-S correlation 221, which is shown in detail
`
`in Fig. 3,
`
`correlates the controls on driving game controller 66 with semantics chosen from
`
`the driving simulation genre.
`
`Joystick 67 is appropriate for use with both driving
`
`simulation applications and role-playing applications.
`
`Therefore,
`
`joystick 67
`
`provides two different C-S correlations: C-S correlation 222 provides a link to the
`
`controls on joystick 67 with the driving simulation genre, and C-S correlation 223
`
`provides a link to the controls on joystick 67 with the role playing genre. Mouse 42
`
`and drawing pad 65 provide C—S correlations 224 and 225, respectively, between
`
`their controls and the CAD genre.
`
`A device may provide additional C-S correlations for specific purposes. For
`
`example,
`
`the manufacturer of driving game controller 66 may provide C-S
`
`correlation 221 which is appropriate for the driving simulation genre generally, but
`
`may also provide additional C—S correlations (not shown), which refine C—S
`
`correlation 221 for use with particular driving games. Each C-S correlation may
`
`specify the applications (e.g., the “XYZ” driving game) or classes of application
`
`(e. g., all applications in a driving simulation genre) with which it may be used.
`
`Applications 36a and 36b provide input device mapper 39 with correlations
`
`between actions that they perform and available or predefined genres. These
`
`correlations are called “action-semantic” correlations (“A-S correlations”), and are
`
`referenced in Fig. 3 by numerals 231-233. Driving game application 36a provides
`
`A—S correlation 231, which is shown in detail in Fig. 4, between its actions and
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 12
`
`SCEA Ex. 1004 Page 12
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`11
`
`semantics selected from the defined semantics of the driving simulation genre.
`
`Architectural design application 36b provides an A-S correlation between its
`
`actions and the defined semantics of the CAD genre.
`
`In addition to A-S correlation
`
`231, driving game application 36a also provides A-S correlation 232 between its
`
`actions and the defined semantics of the role-playing genre.
`
`Providing two
`
`different A-S correlations
`
`for a single application is appropriate when the
`
`application has two different phases that require different usage of the controls. For
`
`example, in driving game application 36a, the character begins by driving a car; this
`
`phase of the game is in driving simulation genre 211. Later, the character gets out
`
`of the car and explores on foot; this phase is in the role-playing genre 212.
`
`Input device mapper 39 receives C-S correlations 221-225 and A-S
`
`correlations 231-233.
`
`Input device mapper 39 creates a mapping for each
`
`application program 36a, 36b, on computer 20. For example, in order to create
`
`mapping 220 for driving game application 36a, input device mapper 39 first selects
`
`an appropriate device for the driving game genre, by determining which devices
`
`have a C—S correlation for the driving simulation genre.
`
`If there is more than one
`
`device having a C-S correlation for driving simulation genre 211, such as driving
`
`game controller 66 and joystick 67, then input device mapper 39 selects one of
`
`these devices. The selection may be made in various ways, for example by
`
`selecting the first appropriate connected device that input device mapper 39 locates,
`
`or by consulting a database of preferred devices for each genre. For example, input
`
`device mapper 39 selects game controller 66 because it is the first device that it
`
`locates which supports driving simulation genre 211. Once the device is selected,
`
`input device mapper 39 uses C-S correlation 221 and A-S correlation 231 to map
`
`controls on game controller 66 into actions that driving game application 36a
`
`performs. Input device mapper 39 may create the mapping by performing a simple
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 13
`
`SCEA Ex. 1004 Page 13
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`12
`
`matching (i.e., by referring to C-S correlation 221 and A—S correlation 231 and
`
`linking each control with an action that is correlated with the same semantic), or it
`
`may take into account user preferences or overrides, as discussed below in the text
`
`accompanying Fig. 6.
`
`Input device mapper may create a second mapping (not shown) for a
`
`different phase of an application that requires controls to be used in a different
`
`context, such as the role-playing phase of driving simulation game 36a. That
`
`mapping is created by selecting an appropriate device for the role-playing genre,
`
`such as joystick 67, and using 08 correlation 223 and A—S correlation 232 to map
`
`the controls on joystick 67 into the actions for the role-playing phase of game
`
`application 36a. Some applications change context frequently, such as a baseball
`
`game application, where the context of the controls is different for pitching than it
`
`is for batting. Preferably, these different contexts may be supported by a single
`
`genre; for example,
`
`the baseball genre shown below (example genre 6 in the
`
`Examples section) has different semantics for batting, pitching, and fielding.
`
`Figure 3 depicts the detail of sample C—S correlation 221. Controls 301
`
`represent controls on driving game controller 66. Semantics 302 are semantics
`
`chosen from the driving simulation genre. C—S correlation 221 links controls 301
`
`with semantics 302‘ In the example depicted by Fig. 3, “Trigger 1” on game
`
`controller 66 is associated with the semantic “FIRE”, “Button 1” is associated with
`
`the semantic “SHIFT UP”, etc.
`
`Figure 4 depicts the detail of sample A-S correlation 231. Actions 401
`
`represent actions that driving game application program 236 can perform at the
`
`user’s request. Semantics 402 are semantics chosen from driving simulation genre
`
`211.
`
`In the example depicted by Fig. 4, the action performed by the driving game
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 14
`
`SCEA Ex. 1004 Page 14
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`13
`
`described as “turn left or right” is associated with the semantic “STEER”, “speed
`
`up” is associated with the semantic “ACCELERATE”, etc.
`
`Figure 5 depicts a sample mapping 220 created by input device mapper 39,
`
`which links the controls on game controller 66 with actions performed by driving
`
`game application 36a. Controls 301 are correlated with semantics, as defined in C-
`
`S correlation 221. The semantics are correlated with software actions 401, as
`
`defined in A-S correlation 231. In the example, “trigger 1” 502 on game controller
`66 is correlated with the semantic “FIRE” 503, which, in turn, is correlated with the
`
`software action “fire machine guns” 504.
`
`The detail of an entry in the mapping is shown in items 511-513. Each entry
`
`contains a controller code 511, an application code 512, and a label 513. The
`
`controller code 511 is the data that an input device generates when a particular
`
`control has been operated. For example,
`
`the game controller could signify that
`
`trigger 1 has been pressed by generating the number “1002.” The application code
`
`512 is the item of input that an application expects to receive as an instruction to
`
`perform a particular action. For example, the input “64379” could instruct driving
`
`game application 36a to fire machine guns. Label 513 is a text string provided by
`
`application program 36a, which is a plain language description of the action that
`
`application program 36a will perform upon receiving application code 512 as its
`
`input. For example, “fire machine guns” is a label describing the action that will be
`
`performed by driving game application 36a when trigger 1 is depressed. The labels
`
`are helpful for displaying a graphic representation of the mapping, as described
`
`below in the text accompanying Fig. 6.
`
`A mapping can be bi—directional. For example,
`
`it will be observed that
`
`mapping 220 shows a software action “feedback” 509 mapped into the “vibrate”
`
`control 511 on game controller 66 through the semantic “RUMBLE” 510. A genre,
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 15
`
`SCEA Ex. 1004 Page 15
`
`

`

`WO 00/59594
`
`PCT/USOO/08848
`
`14
`
`such as driving simulation genre 211, may contain semantics such as “RUMBLE,”
`
`which represent functions that the device is able to perform at the request of an
`
`application. The direction of the arrows indicates that “feedback” is a command
`
`that driving game application 36a issues to game controller 66. For example, game
`
`controller 66 may be equipped with a mechanical device that vibrates the game
`
`controller, and driving game application 36a may wish to provide feedback to the
`
`game player in response to certain events, such as a car crash.
`
`In this case, driving
`
`game application 36a includes a feedback—RUMBLE link in A-S correlation 231.
`
`Similarly, driving game controller 66 includes a vibrate—RUMBLE link in C-S
`
`correlation 221. Input device mapper 39 links “feedback” to “vibrate” in mapping
`
`220.
`
`Figure 5 also shows a control labeled “button 2” 505 on game controller 66,
`
`which is correlated with the semantic “TALK” 506, which might be appropriate for
`
`the action of operating a two-way radio to talk with other drivers. This correlation
`
`means that button 2 is mapped to an action correlated with the “TALK” semantic in
`
`an application that has such an action. Driving game application 36a, however,
`
`does not have an action correlated with the “TALK” semantic; therefore, button 2
`
`on game controller 66 does not map to any action in driving game application 36a.
`
`It will also be observed in Fig. 5 that mapping 220 uses a semantic
`
`“DASHBOARD” 507, which is correlated with the action in driving game
`
`application 36a of changing the dash display, and it will also be observed that game
`
`controller 66 does not have a control correlated with the “DASHBOARD”
`
`semantic. A feature of input device mapper 39 is that it provides an application
`
`with the model that all of the defined semantics in a genre are supported in any
`
`computer system on which the application may be running, such as computer 20.
`
`For example, even though game controller 66 does not have a control correlated
`
`10
`
`15
`
`20
`
`25
`
`SCEA EX. 1004 Page 16
`
`SCEA Ex. 1004 Page 16
`
`

`

`WO 00/59594
`
`PCT/U800/08848
`
`13
`
`with the “DASHBOARD” semantic, driving game 36a may still correlate its
`
`“change dash display” action with the semantic “DASHBOARD,” and input device
`
`mapper 39 will locate an appropriate auxiliary input for that action.
`
`In mapping
`
`220, auxiliary input 501 is selected by input device mapper 39 to implement the
`
`“DASHBOARD” semantic. Auxiliary input 501 may be a key on keyboard 40, an
`
`unused control on game controller 66 such as control 505, a pop-up menu that the
`
`user can control with pointing device 42, or any other mechanism by which the user
`
`can communicate with computer 20.
`
`The genres may be defined such that some semantics must be mapped to the
`
`primary input device selected by input device mapper 39 and may not be mapped to
`
`an auxiliary input outside of t