OSDM

Overview

OpenSpeech™ DialogModules™ (OSDMs) are building blocks for voice applications, which accelerate the development process by packaging application functionality for applications based on VoiceXML. They provide all prompts, grammars, dialog flow, and other parameters required to address frequent speech application tasks, like obtaining alphanumeric strings, dates, phone numbers, etc.

The following table lists all thirteen OSDM types available within the VoiceObjects platform together with short descriptions and alias names by which the types are referred to in the OSDM handbook.

Icon	Type	Alias	Description
	Alphanumeric	Alphanum	Collects a string of connected numbers and letters (i.e. the caller is not required to pause after each digit or letter). Since distinguishing individual letters is especially difficult, it is usually necessary to constrain the task by specifying a list of valid alphanumeric strings (e.g. 1000 possible account IDs).
	Credit Card Expiration	CCExpDate	Collects the expiration date for a credit card, usually a month and a year. The OSDM recognizes the last day of a given month as well.
	Credit Card Number	CreditCard	Collects a credit card number. Can understand card numbers for Visa, MasterCard, American Express, Discover, Diners Club, and many private label cards provided by retailers.
	Currency	Currency	Collects currency amounts in dollars and cents. You can constrain the range of currency amounts, specify the granularity, and specify a disambiguation mode.
	Custom Context	CustomContext	Allows you to create your own vocabulary and grammar to implement new functions not provided by the other OSDMs.
	Date	Date	Collects dates in several formats (e.g. “June fourth” or “6/4/70”). You can specify an entry format and constrain the range of dates accepted by the DialogModule.
	Digits	Digits	Fundamentally identical to the Alphanum DialogModule, except that it collects a string of connected digits only. To constrain the recognition task, you can specify a minimum and maximum number of digits to listen for (e.g. at least seven digits, but not more than ten). In most cases, this DialogModule is more accurate than Alphanum for digits-only collections.
	Number	NaturalNumbers	Collects any numerical amount. Callers can say “fifty four hundred” or “fifty point twenty five” instead of digits only.
	Phone Number	Phone	Collects a phone number in the North American Numbering Plan consisting of ten digits (long distance) with optional “1,” seven digits (local) or three digits (411, 911, etc.) as configured. Phone numbers must be spoken digit-by-digit; one-eighthundred is supported as a special case. Certain illegal strings for area codes and exchanges are not allowed (e.g., 000-000-xxxx).
	Postal Code	ZipCode	Recognizes a five-digit or nine-digit US ZIP Code.
	Social Security Number	SocialSecurity	Collects a 9-digit US social security number. Illegal numbers, such as those beginning with three zeroes, are screened out.
	Time	Time	Collects a time of day. Callers can use 12-hour or 24-hour times, as well as prefix words such as “about” and “around” To constrain the recognition task, you can specify a range of valid times, granularity, and a disambiguation mode for determining whether to listen for times in the past or in the future.
	Yes/No	YesNo	Collects either an affirmative or negative response from the caller.

An OSDM dialog flow is comprised of a collection phase and a confirmation phase. During the collection phase a specific item type (e.g. a date or a string of digits) is collected from the caller. The subsequent confirmation phase is entered only if recognition confidence during the collection phase is in the midrange between the confidence level and the high confidence threshold, or if the confirmation mode is explicitly set to confirm ALWAYS.

For more information on OSDMs in general, refer to the OSDM handbook and the OSDM Website.

The OSDM object is only designed for the voice channel; in all other channels it will not be processed. For further information on channels refer to Chapter 10 – How to Support Multiple Phone Channels in the Design Guide.

The Object Definition below covers the configuration of the OSDM object with VoiceObjects Desktop. For information on how to define this object type using VoiceObjectsXML refer to the VoiceObjectsXML Definition paragraph.

The thirteen different OSDM object types belong to the object category OSDMs.

Dialog Flow Scenario

The following dialog flow example is based on the OSDM type Date, which asks the caller for the date of departure and return in a flight information service scenario.

Object – Caller	Dialog Flow
	Please tell me the date of your departure.
Caller	The twenty-second of November.
	(confidence is high enough, proceeding to next OSDM) And when do you want to return?
Caller	That’s the first of December, please.
	(confidence is above the confidence level but below the high confidence threshold) Not sure I got you correctly. Was that the first of December?
Caller	Yes.
	(checking available flights)
	I’m sorry, there are no flights available any more for the given dates.

In this example, the first utterance receives a confidence value that is high enough to simply proceed in the dialog, skipping the confirmation phase. In the second OSDM, the utterance needs to be confirmed.

The second example describes a simple dialog requesting the name of a person to call in an auto-attendant application scenario. The OSDM type used is Custom Context.

Object – Caller	Dialog Flow
	Thank you for calling. Please say the name of the person or department you’d like to reach.
Caller	(doesn’t say anything)
	Sorry, I didn’t hear you. Please tell me with whom you would like to speak.
Caller	Well, I’d sure like to talk to Mark if he’s around. Is he?
	Sorry, I didn’t understand. Please say just the first and last name of the person you want to speak with.
Caller	Mark Levinson.
	(not entirely sure) Was that “Mark Levinson?”
Caller	Yes.
	Thanks for being patient. Please hold while I check to see if he’s available.

Note that all interaction is taking place within one and the same OSDM object before proceeding with the dialog flow holding more OSDMs or other objects.

Object Definition

All thirteen OSDM types share the same editor layout. The Definition of each OSDM object type provides the following sections:

· Parameterization
To specify the list of parameters to be passed to the OSDM.

· Result Handling
To specify where to store the result coming from the OSDM processing.

· Options
To configure processing options.

The OSDM editor provides individual event handling, navigation, and tuning which is described in Additional Object Configuration below.

For further details regarding the additional object configuration, refer to Pre-/Postprocessing, Event Handling, Navigation, Tuning, and Properties in this Object Reference.

Parameterization

Within the Parameterization section, one or more Parameter Set items can be defined.

An OSDM object may contain any number of individual parameter set items. Each parameter set item can hold one or more parameters.

You can use the items to group parameters of the same kind (e.g. prompts, logging settings), or to group parameters to be active for different languages, input modes, custom layers etc.

i8 Note: In case more than one parameter set item is active, i.e. remains after filtering of language, input mode, custom layer, and occurrence level, all items are rendered, instead of picking one item randomly. This is different from the behavior found in Output objects, e.g., where random prompting makes sure to pick only one item at a time, with exhaustive randomization when revisiting the object.

OSDM parameters can also be set in Module objects. This allows you to define general properties that are to be valid across all OSDM objects (such as default directories) at the module level, and use inheritance to propagate these parameters down to the OSDM object level.

In the Parameter Set section, the following properties can be specified for each parameter set item:

Property	Description
Label	Optional parameter to identify the parameter set in a list.
Layer	Optional parameter to indicate the custom layer that the parameter set item belongs to. For more information on layers, see the Layer object in this Object Reference or Chapter 7 – How to Use Layers in the Design Guide.
Language	To identify the language in which the respective parameter set item is provided. If an item is appropriate in all relevant languages, the default language layer setting Default should be used. For languages that are used in multiple countries, both the specific language options (e.g. English (SG), English (US)) and the generic option (English) are provided. i8 Note: OSDM objects currently only support the following languages: Cantonese Chinese (Hong Kong), German (Germany), English (Australia), English (United Kingdom), English (Singapore), English (US and Canada), Spanish (Mexico), Spanish (US), French (Canada), French (France), Japanese (Japan), and Mandarin Chinese (Taiwan).
Occurrence	Enables you to use different parameter sets depending on how often the OSDM object has already been visited. Always means that regardless of the number of previous visits the respective parameter set item is always active. Only once means that the parameter set item is active only the first time the OSDM object is visited. And If >= N means that the item is active only if this is at least the N^th time that the OSDM object has been visited.
Input mode	To associate the item with an input mode, so that different parameters can be passed to the OSDM depending on the currently active input mode. This is typically used for applications that are designed to be controlled with both input modes: Voice and/or DTMF. Using this setting, you can, for example, define one prompt that is played when the input mode is set to Voice (Please say yes or no), and a different one for input mode DTMF (Please press 1 for yes and 0 for no), both in the same OSDM object. You can set the input mode either to Voice, DTMF, or Voice+DTMF. If you do not want to distinguish your parameter set items with regard to input mode, leave the setting at Default. Default indicates that the input mode is defined within the corresponding service. For more details, refer to Configuring a Service in Chapter 2 – Configuring Servers and Services in the Deployment Guide.

Additionally, one or more parameters can be defined in the Parameters section within the Parameter Set section by specifying the following properties:

Key
Holds the parameter name itself. You can either select an entry from the available drop-down list, or enter a custom value. Instead of entering custom values from scratch, you would typically want to select an entry first and then modify it, i.e. change the index of one of the entries providing a default index of 1 (like collection_grammar1). For further information on how to do this, refer to the description of list fields in Chapter 6 – Object Editors either in the Desktop for Eclipse Guide or in the Desktop for Web Guide. For details on the meaning of each individual parameter, refer to the OSDM handbook.

i8 Note: The set of entries in this list depends on the type of OSDM selected, i.e. you won’t find all of the OSDM parameters in each OSDM editor.

Value
Enter the value for the parameter selected in the Key field. This can be an arbitrary string or a combination of strings and references to existing objects. The type of object to be linked into the Value field depends on the parameter selected. For a prompt-related parameter like collection_initialprompt, you can e.g. link an Output or Audio object. For a resource-related parameter like applicationgrammarsdirectory, you can link a Resource Locator object, etc.

Existing objects can be inserted by typing in their names using a shortcut notation. For more information on how to do this, refer to Chapter 6 – Object Editors in the Desktop for Eclipse Guide and Desktop for Web Guide, respectively.

The following table lists all possible categories of OSDM parameters, together with example parameters and the types of objects that can (and should only) be used for the corresponding category. Note that technically all linked objects will be rendered to a string value, so, for a given parameter, referencing an object that is not among the following list might lead to invalid parameters.

Parameter Category	Example Parameters	Possible Objects
Data	entries	Variable Expression Script Collection Layer
Directory	applicationpromptsdirectory, baselinegrammarsdirectory	Resource Locator Variable Expression Script Collection Layer
Grammar	dtmfyes, collection_grammar	Grammar Variable Expression Script Collection Layer
Limit	maxinvalidanswers, maxhelpcount	Variable Expression Script Collection Layer
Logging	debuglevel, eventsLogFile	Variable Expression Script Collection Layer
Option	length, dtmfdateformat, maxextension	Variable Expression Script Collection Layer
Prompt	collection_initialprompt, invalidanswerprompts	Output Audio Silence Variable Expression Script Collection Layer
Property	property_collection	Variable Expression Script Collection Layer
Recognition	avoidsamemistake, highconfidencelevel	Variable Expression Script Collection Layer
Rendering	lang, vxmlspec	Variable Expression Script Collection Layer
Setup	recognizer, waveformcapture	Variable Expression Script Collection Layer

i8 Note: If an Output object is linked into the Value field that supports random prompting, only one variation is taken and passed into the OSDM object.
If a Grammar object is linked into the Value field and more than one Grammar item is active while processing the OSDM object, i.e. more than one Grammar item remains after filtering by language and custom layers, only the first item (according to the order of the definition in the corresponding Grammar editor) is passed to the OSDM object. This is because OSDMs currently allow defining only one grammar for grammar-related parameters. Note that if you use Grammar objects for hyperlinks through the Navigation definition, there is no such restriction; all Grammar items remaining after filtering are passed to the OSDM.

The OSDM parameters follow a given formatting convention, which allows to combine audio file references with alternative TTS text, and to provide more than one value for a prompt-related parameter at the same time. A list of audio file URLs can be defined by using the pipe symbol (“|”) to separate the individual files, and by using the semicolon (“;”) to add alternative text to be read out by TTS in case the audio file is missing or corrupt. Note that when linking existing Output or Audio objects into the Value field, the server takes care of producing the correct syntax for the OSDM parameters. In case you need to add additional values, make sure to use the symbols required for the corresponding parameter correctly. Furthermore, if you link Variable, Expression, Script, Collection or Layer objects, you also need to make sure that their value has the correct syntax.

The following example shows the definition of the parameter collection_initialprompt, which consists of a reference to an existing Output object, followed by another audio file URL with alternative text:

i8 Note: Variable, Expression, Script, Collection, and Layer objects have (embedded or autonomous) Format objects associated with them. This formatting has effect on the way their respective values are rendered for playback. When linking any of these objects into the Value field of a Parameters section, any formatting is ignored. If you want to make use of formatting, you need to wrap the corresponding object in an Output object and link this Output object instead.

Comment
Enter a comment describing the parameter, if required. This field is optional.

Result Handling

The Result Handling section defines one or more result handling items that assigns return values from the OSDM to Variable or Layer objects.

The Slot field allows to either type in a custom slot name, or to select one of a set of predefined slots from a drop-down list.

i8 Note: The set of entries in this list depends on the type of OSDM selected, i.e. you won’t find all of the slot names in each OSDM editor.

Typical return values are the result itself (the semantic interpretation), statistical information on the number of No Input or No Match events that occurred within the OSDM, the raw utterance of the caller, confidence values etc. For a full list of possible slot names, refer to the OSDM handbook.

The following example shows the definition of the Result Handling of an OSDM object of type Date, which returns day, month, and year, as well as the confidence score of the collection phase.

You can also retrieve ASR-related information regarding confidence values, utterances and more using the system function LASTRESULT within an Expression object. Event-related information can be retrieved using EVENTCOUNT and EVENTLIST. For a description of these functions, refer to the Expression object in this Object Reference.

Options

The Options section of the OSDM object specifies four processing options:

Enable auto-advance on No Input (Global) enables auto-advance in case no response from the caller is detected in the collection or confirmation phase. If the check box is selected, a No Input event in either the collection or confirmation phase finishes the processing of the OSDM object and proceeds to the next object in the dialog flow instead of processing the event handling specifications. By default, the check box is clear.

Enable auto-advance on No Match (Global) enables auto-advance in case the caller says something that cannot be matched with the grammar in the collection or confirmation phase. If the check box is selected, a No Match event in either the collection or confirmation phase finishes the processing of the OSDM object and proceeds to the next object in the dialog flow instead of processing the event handling specifications. By default, the check box is clear.

i8 Note: The options are for your convenience only. The same effect can be achieved by specifying a No Input or No Match event handling for level 1 and continuation set to Proceed. Use the options described above if you want to proceed on the first No Input or No Match event. If you want to proceed at a later event occurrence level, specify the appropriate event handlers. Using a dedicated event handler also allows you to process any object before proceeding, e.g. play a prompt through an Output object.
Also note that the options described above affect both the collection and the confirmation phase. If you want different auto-advance behavior for the two phases, don’t use these options but define corresponding event handlers for the two phases instead and set continuation to Proceed.

Mask caller input for System DB logging encrypts the caller input before writing it to the system database via Infostore, the logging component of VoiceObjects Server. This is useful for sensitive data, like PINs, which mustn’t be stored as plain text for security reasons.
The default setting False indicating that the data is not encrypted. True indicates that data is encrypted in such a way that while the original value cannot be recovered, different input values still produce different encrypted values so that subsequent analyses are possible. Complete indicates that the values are completely masked by a single static string. (By default the string “***MASKED***” is used; it can be configured in components_VOServer.xml using the <maskUserInputComplete> element.)

The Standby Timout field specifies the maximum time for which the dialog session is kept alive while the OSDM is processed. By default this timeout is set to Default, which indicates that the value is taken from the dialog context. For more details, refer to Chapter 2 – Configuring Servers and Services in the Deployment Guide. When using a Variable, Expression, Script, or Layer object to define the standby timeout dynamically at call time, or when typing in a custom value instead of selecting one of the values from the drop-down list, the corresponding value needs to be a positive number and will be applied as seconds, e.g. for a custom timeout of 5.5 minutes, type in 330.

i8 Note: If a caller spends time in the OSDM longer than the standby timeout, a return to the VoiceObjects session is not possible. Thus the developer needs to make sure that the standby timeout is at least as long as the maximum duration of the OSDM.

Additional Object Configuration

The Event Handling, Navigation, and Tuning sections of the OSDM editor each provide a global section which applies both to the collection and the confirmation phase, as well as separate definitions for the collection and the confirmation phase.

If you do not want to define separate event handling, navigation, or tuning for the different phases of the OSDM, leave the corresponding sections empty and just define the Global section.

All event handlers that are inherited from parent objects are taken as if they were defined in the Global section, i.e. they are active both for the collection and the confirmation phase. If you want different event handling in one of the two phases, you can define it in the corresponding section and thus overwrite the inherited settings. If you define event handlers or tuning parameters both in the Global and in any of the other two sections, the more specific sections take precedence over the settings in the Global section. As for navigation, embedded hyperlinks defined in the Global section and those defined in the Collection or Confirmation section will all be active at the same time.

For further details regarding the additional object configuration, refer to Pre-/Postprocessing, Event Handling, Navigation, Tuning, and Properties in this Object Reference.

Event handling is usually defined in OSDMs by setting the relevant parameters for event types, prompts to be played, etc. This could be done by providing the corresponding parameters in the Key field within the Parameter section of a parameter set in the Definition section, although these parameters are not part of the available list of keys for each OSDM. When defining event handling, it is strongly recommended to use the Event Handling section instead, which leverages all important VoiceObjects concepts such as random prompting or inheritance. Note, that if event handlers are defined both through parameters and in the Event Handling section, the parameters take precedence over any settings made in the Event Handling section.
The same holds true for navigation and tuning.

i8 Note: Grammars for hyperlinks usually don’t require setting a slot, and some platforms even reject hyperlink grammars containing slot assignments. In OSDM objects, however, the grammar associated with a hyperlink always needs to set a slot with the predefined slot name dm_command. This is necessary, in order to tell the server which hyperlink to activate when returning from the OSDM processing, since all communication between the OSDMs and VoiceObjects Server takes place through the slots.
If you want to use a Hyperlink object through the Navigation section, you can either use TTG, embedded, or external grammars. In case of TTG, you don’t have to deal with slot assignments, since the server does this automatically when generating the final grammar at call time. In case of embedded grammars, you have to define a label for this hyperlink in its Label field and use this label as the slot value for the slot dm_command. Alternatively, you can use the shortcut notation @HYPERLINK@, which will be resolved at call time. In case of external grammars, setting the Label field on the Hyperlink object is required, and the slot dm_command must be set to this label. Note, that when using autonomous Hyperlink objects, the object name must be taken instead of the label.

Since the activation of the hyperlink might need to be confirmed, you have to provide an additional slot dm_confirm_string in the hyperlink grammar that defines the utterance that will be used within the confirmation prompt to repeat what the caller has said. The value of this slot is typically the same as the utterances defined in the grammar. Note again that setting this slot is not necessary for TTG grammars.

i8 Note: For technical reasons, the two phases of OSDM objects, collection and confirmation, are hidden from the server, i.e. they are treated as one dialog step. This has effects on standard and custom navigation. For the standard navigation commands Backward and Forward this means that an OSDM is always entered in the collection phase, never in the confirmation phase. Thus, going backward on the object immediately following an OSDM object in the dialog flow always leads to the collection phase, even if the confirmation phase was the last step. Going backward within the confirmation phase leads to the input state prior to the OSDM object.
The same holds true for custom hyperlinks activated within the confirmation phase, and event handlers that process a Goto object.

VoiceObjectsXML Definition

The OSDM object types are represented by the VoiceObjectsXML element <osdm>. It has four attributes and fourteen groups of children.

In addition, the element has the standard attributes described in the XDK Guide.

The <osdm> element uses the embedded <osdmItems> element.

OSDM

Attributes

· type
Defines the type of the OSDM object. Possible values are alphanumeric, creditCardNumber, creditCardExpiration, currency, customContext, date, digits, number, phoneNumber, postalCode, socialSecurityNumber, time, yesNo.
If not specified, defaults to customContext.

· autoAdvanceNoInput
Defines whether the dialog should automatically advance in case of a No Input event. Either true or false. If not specified, defaults to false.

· autoAdvanceNoMatch
Defines whether the dialog should automatically advance in case of a No Match event. Either true or false. If not specified, defaults to false.

· maskCallerInput
Defines whether the input made by the caller should be masked when writing it to Infostore. This is recommended for sensitive data such as e.g. banking account numbers or PINs.
One of true, false, or complete. If not specified, defaults to false.

Children

· <expression usage=”precondition”> or
<variable usage=”precondition”> or
<collection usage=”precondition”> or

· <script usage=”precondition”>
Defines the precondition for the OSDM object.

· <sequence usage=”preprocessing”>
Defines the preprocessing sequence for the OSDM object.

· <osdmItems>
Defines the parameterization for the OSDM object.

· <resultHandling>
Defines the result handling for the OSDM object.

· <eventHandling usage=”global”>
Defines the event handling for both phases of the OSDM object.

· <eventHandling usage=”collection”>
Defines the event handling for the collection phase of the OSDM object.

· <eventHandling usage=”confirmation”>
Defines the event handling for the confirmation phase of the OSDM object.

· <customNavigation usage=”global”>
Defines the navigation settings for both phases of the OSDM object.

· <customNavigation usage=”collection”>
Defines the navigation settings for the collection phase of the OSDM object.

· <customNavigation usage=”confirmation”>
Defines the navigation settings for the confirmation phase of the OSDM object.

· <tuning usage=”global”>
Defines the tuning settings for both phases of the OSDM object.

· <tuning usage=”collection”>
Defines the tuning settings for the collection phase of the OSDM object.

· <tuning usage=”confirmation”>
Defines the tuning settings for the confirmation phase of the OSDM object.

· <sequence usage=”postprocessing”>
Defines the postprocessing sequence for the OSDM object.

Example

</osdmParameter>

</osdmParameter>

</osdmItem>

</osdmParameter>

</osdmItem>

</osdmItems>

</resultHandling>

</osdm>

OSDMItems

Attributes

· inheritance
Defines whether OSDM parameter settings inherited from parents objects are used (true, the default) or not (false). This is only relevant for an <osdmItems> element used within a <module> element.

Children

· +<osdmItem>
Defines the list of OSDM items.

Example

</osdmParameter>

</osdmParameter>

</osdmItem>

</osdmParameter>

</osdmItem>

</osdmItems>

OSDMItem

Attributes

· label
A text string providing a name for the OSDM item.

· language
Defines the language for which this OSDM item is valid. Can be default or a valid language code (e.g. de-DE, en-US, etc.). If not specified, defaults to default.
Appendix A – Language Codes contains a list of all language codes available in VoiceObjects together with the respective language they represent.

· occurrence
Defines the occurrence level for which this OSDM item is valid. Can be always, once, or an integer between 1 and 10. If not specified, defaults to always.

· inputMode
Defines the input mode for which this OSDM item is valid. Can be default, voice, dtmf, or voicedtmf. If not specified, defaults to default.

· layer
Defines the layer for the OSDM item. Can either be a reference to a Collection, Expression, Script, or Variable object; or a layer state reference of the form “Layer=State” or “Layer!=State” where “State” is the label of a state for the layer “Layer”.

Children

· +<osdmParameter>
Defines the list of parameters in this item.

Example

</osdmParameter>

</osdmParameter>

</osdmItem>

OSDMParameter

Attributes

· key [required]
A text string providing the parameter key.

· comment
A text string providing a comment describing the parameter.

Children

· Any number of the following:
<variable>, <expression>, <script>, <layer>, <text>, <resourceLocator>, <audio>, <output>, <silence>, <grammar>
Defines the value to be passed to the OSDM for the respective parameter key.

Example

</osdmParameter>

Object Interoperability

The following table contains all object types that can reference an OSDM object:

Icon	Object Name	Use Case Example
	Module	An OSDM object can be used within the embedded sequence of a Module object.
	Sequence	Most commonly, an OSDM object is used within a sequence in a dialog flow.
	Menu	An OSDM object can be used as the destination object within a Menu item.
	Confirmation	An OSDM object is frequently used as the destination object within a correction item inside a Confirmation object.
	If	An OSDM object can be used in either the THEN item or the ELSE item of an If object.
	Case	An OSDM object can be used in any WHEN item and the ELSE item of a Case object.
	Loop	An OSDM object can be used within the embedded sequence of a Loop object.
	Goto	An OSDM object can be referenced via a Goto object.
	Hyperlink	An OSDM object can be the destination of a hyperlink object.

Object Naming Conventions

In order to leverage the capabilities of the integrated documentation of VoiceObjects it is important to provide intuitive and self-explanatory object names and descriptions.

The name of an OSDM object should indicate which type of input is requested from the caller. The short description should contain a brief explanation of the parameters defined for the OSDM. The table below lists three examples:

Name	Description
Ask for phone number	Requests a phone number from the caller and places it in the variable Phone Number.
Confirm transaction	Replays the transaction to be performed and asks for an explicit yes/no confirmation. The response is stored in the variable Yes/No Answer as yes or no.
Ask for car make	Asks for the car manufacturer. Results are stored in variable Car make.