(12) United States Patent
`Mathis
`
`USOO6269254B1
`(10) Patent No.:
`US 6,269,254 B1
`(45) Date of Patent:
`Jul. 31, 2001
`
`11/1999 Sandler et al. ....................... 455/557
`5,983,117
`4/2000 Tornquist et al. ................... 455/414
`6,055,424
`4/2000 Wieand et al. ...................... 455/557
`6,055,441
`sk - cited by examiner
`Primary Examiner William Trost
`ASSistant Examiner Tilahun Gesesse
`(74) Attorney, Agent, or Firm-Hugh C. Dunlop; Romi N.
`Bose, Hisashi D. Watanabe
`(57)
`ABSTRACT
`A radio communications device has a memory having Stored
`therein a user application program (16), a telephony program
`(21) Appl. No.: 09/161,817
`(18) and an application programming interface (API) 30
`between these. Various aspects of the API are described. In
`(22) Filed:
`Sep. 28, 1998
`(51) Int. Cl." ................................................... H04B 1/38 CEE, tI At fishing of A
`(52) U.S. Cl. ........................ 455/557; 455/553; 379/93.04
`pnony progr
`plS,
`gument of
`command for establishing the call, an array identifying
`(58) Field of Search
`0. - - - - - - - 455/556, 557,
`Several terminal objects (54–58), thereby permitting estab
`lishment of a call for multiple terminal objects. In another
`455/553,552, 84,575; 379/93.04, 93.05,
`93.06, 93.24
`aspect, groupings of events are described and an API com
`mand defines an event class from one of the groups together
`with an ID defining an event within the event class. In a
`References Cited
`further aspect, a program in the telephony program is called
`U.S. PATENT DOCUMENTS
`to create a call object (50). The call object is created
`:
`regardless of whether radio Service for the radio comunica
`5,625,678 : 4/1997 Blomfield-Brown .................. 379/93
`: 7.E. Atlal - - - - - - - - -
`- - - 25, tions device has been established.
`
`(54) RADIO COMMUNICATIONS DEVICE AND
`METHOD WITH API BETWEEN USER
`APPLICATION PROGRAMAND
`TELEPHONY PROGRAM AND METHOD
`
`(75) Inventor: James E. Mathis, Barrington, IL (US)
`(73) Assignee: Motorola, Inc., Schaumbrug, IL (US)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(56)
`
`5,852,773 - 12/1998 Hu. ... 455/557
`5,933,778 * 8/1999 Buhrmann et al. .................. 455/461
`
`12 Claims, 6 Drawing Sheets
`
`TERMINAL
`CONNECTION 1
`
`Ya
`w
`\
`
`
`
`14
`
`
`
`f
`f
`7O
`) - - -
`(CALL 2)
`Nye -
`
`
`
`
`
`
`
`
`
`I
`
`6O
`
`w
`
`LOCAL
`CONNECTION
`
`TERMINAL
`CONNECTION 2
`
`er s
`
`N
`N
`
`- - - - -
`
`f
`f
`/
`M
`M
`
`- cree WJENA, 1.
`C- --
`\'l-
`\CONNECTION 3/
`REMOTEY
`\CONNECTIO)( N-- ---
`- - - 1 \,
`( TC2
`58
`N - 1
`- 1
`xics, 66
`
`Ex.1016
`APPLE INC. / Page 1 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet 1 of 6
`
`US 6,269,254 B1
`
`16
`
`17
`
`
`
`
`
`OTHER
`CASS TAPI
`
`
`
`15
`
`14
`
`1O
`
`24
`
`TRANSCEIVER
`SOFTWARE
`
`
`
`VOICE DATA
`DATA
`R.F. HARDWARE
`
`Az7G. 7 ll
`
`13
`
`17
`
`OTHER
`APP. CLASSES JTAP
`
`VM
`
`29
`
`TRANS
`CEIVER
`S.W.
`
`16
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`24
`
`VOICE DATA
`R.F. HARDWARE
`
`3
`
`
`
`16
`
`PHONE APPLET
`
`18
`
`
`
`JTAP METHOD
`IMPLEMENTATION
`
`3O
`
`22
`
`GSM
`TRANSCEIVER
`
`A/VG.. 3
`
`Ex.1016
`APPLE INC. / Page 2 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet 2 of 6
`
`US 6,269,254 B1
`
`14
`
`JTAP
`
`4O
`GOs)
`PROVIDER
`
`42
`
`(CERMED
`(ERIED
`
`
`
`- - - - - - - s
`
`f
`?
`f
`7O
`f
`f
`---
`(CALL 2)
`\ y
`-
`
`ADDRESS
`
`5O
`
`4.
`8
`
`52
`
`46
`
`TERMINAL
`CONNECTION 1
`
`56
`
`LOCAL
`CONNECTION
`
`TERMINAL
`CONNECTION 2
`
`N
`
`f
`f
`/
`
`Y
`--- rcree YENA, -1
`C- --
`\'l-
`\CONNECTION 3/
`REMOTEY
`\CONNECTIO). SS-N-
`7--
`A/VG.. 4 Yxics
`
`6O
`
`e -
`
`N
`
`- - -
`
`er
`
`s
`
`/
`
`s a
`
`N
`
`
`
`SCAN TO FIND
`NETWORK
`
`COMMAND
`TRANSCEIVER
`TO PLACE CALL
`
`Ex.1016
`APPLE INC. / Page 3 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet 3 of 6
`
`US 6,269,254 B1
`
`JAWA
`AppleTONS
`JTAPI
`
`APPLETS
`
`JAWA RUN-TIME
`
`
`
`
`
`
`
`
`
`NETWORK COMPUTER
`
`REMOTE ACCESS MECHANISM 1
`1 (JAVA RMI OR JOE OR, A
`TELEPHONY PROTOCOL)
`
`
`
`
`
`SERVER
`OR
`"POWER DESKTOP
`
`
`
`
`
`AVG. Z.
`
`REMOTE TELEPHONY SERVER
`
`TSAPI
`
`TAPI OER
`
`
`
`
`
`IP/ISDN/ATM
`
`
`
`JAWA
`APPLETS
`APPLICATIONS
`JAVA TELEPHONY API
`
`JAVA RUN-TIME
`
`XTL
`
`OTHER
`APIs
`
`TAPI
`TSAPI
`TELEPHONY H/W
`(POTS CARD/FAX CARD)
`
`A77G. S.
`
`Ex.1016
`APPLE INC. / Page 4 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet 4 of 6
`
`US 6,269,254 B1
`
`
`
`
`
`
`
`
`
`
`
`CALL
`CONTROL
`
`CAPABILITIES
`
`PRIVATE
`DATA
`
`Ex.1016
`APPLE INC. / Page 5 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet S of 6
`
`US 6,269,254 B1
`
`PROVIDER
`
`CALL
`
`CONNECTION
`
`CONNECTION
`
`
`
`
`
`
`
`12
`56 ADDRESS
`
`
`
`1
`ADDRESS 456
`9
`0.
`
`
`
`
`
`
`
`
`
`TERMINAL
`CONNECTIONS
`
`ORIGINATION
`TERMINAL
`
`DESTINATION TERMINALS
`
`A77G. ZO
`
`Ex.1016
`APPLE INC. / Page 6 of 17
`
`

`

`U.S. Patent
`
`Jul. 31, 2001
`
`Sheet 6 of 6
`
`US 6,269,254 B1
`
`(EXCEPT FAILED
`OR DISCONNECTED)
`
`Gools
`
`(EXCEPT DROPPED)
`
`Gools
`
`(SSE)
`
`GCTIVE) AVG. Z2
`
`TERMINAL 1
`
`ADDRESS
`
`CALL
`
`ADDRESS
`
`
`
`TERMINAL 2
`TERMINAL 3
`
`2
`
`ACTIVE
`
`CONNECTED
`
`s 3.
`
`4
`
`6
`
`DROPPED
`
`INPROGRESS
`
`RINGING
`
`CONNECTED
`
`ACTIVE
`
`conscio G.
`pisconsciel G.
`
`DISCONNECTEDDISCONNECTED
`
`DROPPED
`DROPPED
`
`A77G. Z3
`
`Ex.1016
`APPLE INC. / Page 7 of 17
`
`

`

`1
`RADIO COMMUNICATIONS DEVICE AND
`METHOD WITH API BETWEEN USER
`APPLICATION PROGRAMAND
`TELEPHONY PROGRAM AND METHOD
`
`FIELD OF THE INVENTION
`
`This invention relates to the radio communications device
`having a user application program (commonly referred to as
`an application or applet) and a telephony program (e.g. an
`instance of a telephony class) and an application program
`ming interface (API) between the user application program
`and the telephony program. The invention relates to aspects
`of the API and it relates to a method invoked through the
`API, for example a method for establishing a dual mode call.
`BACKGROUND OF THE INVENTION
`Object oriented program languages Such as Java (TM) are
`increasingly popular in more and more devices on account
`of portability of programs acroSS platforms, operating Sys
`tems and devices. This means that a program developed for
`one device is more readily used on another device of
`different characteristics, for example different operating
`Systems or different microprocessors.
`This popularity of object oriented programs is extending
`into devices that are significantly Smaller in terms of
`memory size and processing power than traditional personal
`computers and other platforms on which Such languages
`have been in widespread use. Problems have emerged in
`attempting to use object orienting languages Such as Java
`(TM) on very small platforms for a number of reasons. An
`example of a problem lies in the need to Support a complete
`Set of object classes, where an object is a Self-contained
`computer program which interacts with other programs in a
`defined manner, and where a class is a generic template for
`a set of objects with Similar features. A problem is that in
`order to maintain the portability of programs acroSS different
`platforms, uniformity needs to be present in the classes that
`any given application expects to be able to invoke. For
`example, plava (TM) has a very large set of class libraries
`and efforts are in place to define a Smaller language to be
`termed “eJava” (TM) using only a subset of the complete set
`of class libraries.
`An example of a class is a telephony class that is invoked
`through a Java (TM) telephony API (JTAPI). An instance of
`such a class could be termed a “JTAPI implementation”.
`JTAPI is a portable, object oriented application program
`ming interface for JAVA (TM)-based computer-telephony
`applications described at the following universal resource
`locator on the worldwide web: www.javasoft.com/products/
`JTAPI/index.html. The JAVA (TM) Telephony API supports
`both first- and third-party telephony application domains.
`The API is designed to make programming Simple applica
`tions easy, while providing those features necessary for
`advanced telephony applications. JTAPI is a set of APIs.
`There is a “core” API providing a basic call model and
`rudimentary telephony features, Such as placing telephone
`calls and answering telephone calls. The core API is Sur
`rounded by Standard extension APIs providing functionality
`for Specific telephony domains Such as call centers and
`media Stream access. Applications written using JTAPI are
`portable acroSS Various computer platforms and telephone
`systems. Version 1.2 of JTAPI was released to the public in
`December 1997.
`An example of use of JTAPI is in a network configuration
`where the JTAPI application or JAVA (TM) applet runs on
`a remote Station, Such as a network computer with only a
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,269,254 B1
`
`2
`display, keyboard, processor and Some memory. This com
`puter accesses network resources, making use of a central
`ized Server that manages telephony resources. JTAPI com
`municates with this Server via a remote communication
`mechanism, such as the remote method invocation (RMI) of
`Java (TM) or a telephony protocol. The JAVA (TM) tele
`phony API is composed of a set of JAVA (TM) language
`packages. Each package provides a piece of functionality for
`a certain aspect of computer-telephony applications.
`Implementations of telephony Servers choose the pack
`ages they Support, depending on the capabilities of there
`underlying platform hardware. Applications may query for
`the packages Supported by the implementation they are
`currently using. Additionally, application developerS may
`concern themselves with only the Supported packages that
`applications need to accomplish a task. For example, a call
`package permits applet designers to add telephone capabili
`ties to a web page, while a number of Standard extension
`packages extend the JTAPI core package. These extension
`packages bring additional telephony functionality to the
`API, Such as: all control, call center, media, phone, private
`data and capabilities packages.
`It would be desirable to use a standard telephony API Such
`as JTAPI as a telephony API for a radio telephone or other
`radio communication device.
`A number of problems lie in the way of using JTAPI as a
`telephony API for a wireleSS communication device, and in
`particular as a telephony API for a Global System for Mobile
`(GSM) radio telephone. In general JTAPI still suffers from
`the burden of having over 63 event classes with a total class
`file size of approximately 130 k bytes. This represents a
`Substantial memory allocation for a relatively minor element
`of an overall program for a radio telephone. There is a need
`to reduce the memory requirement for programs that are
`JTAPI compatible.
`In the context of a GSM communication device, there are
`GSM functions that cannot be easily accessed using existing
`JTAPI syntax and method signatures. Moreover, there is a
`need to Support a dual-mode call (which is a term used in
`GSM for a voice and fax call or a voice and data call) and
`the concept of a dual-mode call is unknown in wireline
`telephony and in JTAPI. Simply adding to JTAPI or reducing
`JTAPI do not provide Satisfactory Solutions, because adding
`to JTAPI increases the need for finding event classes, and
`reducing JTAPI eliminates the benefit of a standard API that
`permits portability of applications acroSS platforms.
`Accordingly, there is a need for a telephony API for a
`radio communications device and associated classes that
`occupy a minimum of memory and Support features that are
`unique to radio telephony.
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows an example of a radio telephone device in
`accordence with a first embodiment of the invention.
`FIG. 2 shows an example of a radio telephone device in
`accordance with a Second embodiment of the invention.
`FIG. 3 is a Software architecture diagram illustrating the
`structure of software or either of the radio telephones of FIG.
`1 and FIG. 2.
`FIG. 4 is a program flow diagram illustrating further
`details of the JTAPI method implementation of FIG. 3.
`FIGS. 5 and 6 are flow diagrams illustrating details of the
`JTAPI method implementation of FIG. 3.
`FIGS. 7-13 are referred to in Appendix 1 which describes
`JTAPI.
`
`Ex.1016
`APPLE INC. / Page 8 of 17
`
`

`

`US 6,269,254 B1
`
`15
`
`25
`
`3
`DETAILED DESCRIPTION OF THE DRAWINGS
`Referring to FIG. 1, a radio telephone is illustrated in
`terms of different layers, with hardware at the lowest layer
`and applications Software at the highest layer. The radio
`telephone comprises a first microprocessor 10
`(microprocessor A), a second microprocessor 11
`(microprocessor B) and certain RF hardware 13. The micro
`processors A and B are connected together. The micropro
`cessor B is connected to the RF hardware 13. The RF
`hardware 13 includes at least a receiver and a transmitter.
`The RF hardware also has voice communication elements 23
`which preferably include a voice coder, by way of example,
`and data communication elements 24 which preferably
`include a data modem or fax modem, by way of example.
`The microprocessor has an operating System (OS) 14 Such as
`OS 9000 Supplied by Microware Systems Corporation of
`Des Moines, Iowa. Above the operating System is shown a
`virtual machine 15, such as a commercially available JAVA
`(TM) Virtual machine. An application program 16 and
`various other JAVA (TM) classes 17 run on the virtual
`machine 15. One of the classes 17 is a JTAPI implementa
`tion 18. The microprocessor 11 has transceiver Software 20
`which performs Such functions as call control, framing and
`generally byte level manipulation Such as block coding. The
`transceiver Software 20 communicates acroSS a common
`service provider module interface (CSPMI) 22 with the
`operating System 14.
`AS an alternative to the arrangement of FIG. 1, the
`microprocessors A and B can in effect be integrated into a
`Single integrated circuit 25 as shown in phantom outline in
`FIG. 2. In this embodiment, the microprocessor 10, the
`hardware 13, the operating System 14, the Virtual machine
`15 and the various Software elements 16-18 are the same as
`in the embodiment of FIG.1. In place of the microprocessor
`B, there is a digital signal processor (DSP) integrated with
`the microprocessor 10 in the single integrated circuit 25. The
`DSP27 has DSP code 28 which performs framing and other
`byte-level manipulations Such as block coding, while other
`transceiver Software functions Such as call control are per
`formed by transceiver software code 29 which is run on the
`microprocessor 10 using the operating System 14. A Suitable
`integrated circuit 25 is the M-core (TM) integrated micro
`processor and DSP available from Motorola, Inc., of
`Schaumburg, Ill.
`In FIG. 3, the application 16 is shown (refered to as a
`“phone applet”) and the JTAPI method implementation 18 is
`shown. A JTAPI interface 30 is shown interfacing between
`the phone applet 16 and the JTAPI method implementation
`18. The JTAPI method implementation 18 controls and
`receives input from a radio transceiver Such as a GSM
`50
`transceiver 30 Over the CSPMI 22. The GSM transceiver 30
`comprises the Second microprocessor 11, the RF hardware
`13 and the transceiver software 20 (all shown in FIG. 1).
`The JTAPI 30 is substantially as described in the JTAPI
`Specification version 1.2, which defines the Syntax or opera
`tion of high level objects, such as “Provider” and is set out
`in Appendix A. In addition, certain operations Specific to
`GSM are supported, for which the following specific seman
`tics are now defined.
`The domain of the JTAPI Provider is simply the mobile
`station (MS). The only addresses in the Provider's domain
`are those of the MS, e.g., a Single address in the domain for
`a single line phone.
`Provider.getAddresses() returns an array of addresses for
`the MS, typically with only 1 entry. If the MS Supports
`multiple lines and telephone numbers, the default or primary
`address is the first entry.
`
`4
`Provider.getAddress() accepts only the number or num
`bers assigned to the MS. By default, the primary address,
`i.e., getAddresses()0, is returned.
`Provider getTerminals( ) returns an array of Terminals
`supported by the MS. A separate terminal is defined for each
`call bearer type (see below).
`Provider getTerminals( ) takes a string specifying the
`name of the terminal. By default, the voice Terminal is
`returned. All implementations must support VOICE, DATA
`and FAX as names for the respective Terminals (see below).
`Provider.createCall() will create a call even if the Pro
`vider is OUT OF SERVICE, as long as it has not been
`shut down. The call cannot be Successfully placed until the
`Provider is IN SERVICE. This feature is a change to JTAPI
`1.2 createCall() pre-conditions and is described below in
`greater detail with reference to FIGS. 5 and 6.
`Call.connect( ) parses the destination address String for
`common SS codes and address flags. If the destination
`number String passed to Call.connect() starts with a "+”
`character, the type-of-number (TON) is set to INTERNA
`TIONAL; otherwise, the TON is UNKNOWN. If the string
`contains only numeric digits, the numbering-plan identifier
`(NPI) is ISDN, otherwise it is UNKNOWN.
`and
`Terminal Connection. join (
`)
`TerminalConnection.leave() are used to change call modes
`in a dual-mode (voice and data or voice and fax) call. There
`is always exactly one TerminalConnection that is active in a
`call; invoking join() on another TerminalConnection causes
`a Switch in call mode and calling leave() on the active
`TerminalConnection automatically activates the alternate
`OC.
`Applications can interact with the information content of
`the call using the API defined for MediaTerminalConnec
`tion. If a Terminal Connection returned from
`Connection. getTerminal Connections( ) implements
`MediaTerminalConnection, the application can use the fol
`lowing
`methods:
`MediaTerminalConnection.getMediaAvailability( ), which
`is implemented as defined in JTAPI 1.2;
`MediaTerminalConnection.getMediaState( ), which is
`implemented as defined in JTAPI 1.2;
`MediaTerminalConnection..generateDtmf(), which is used
`to generate DTMF tones on the call. All other methods in
`MediaTerminalConnection are optional.
`The Provider will not necessarily disconnect any active
`calls when it goes out of service. The Provider may keep the
`Call active and attempt to reestablish the call, assuming a
`temporary communication failure. The application can
`assume that the Provider is attempting to reestablish a call if
`the ProvOutOfServiceEv is not closely followed by Call
`InvalidEV and related ConnDisconnectedEV events (i.e. if
`these latter do not follow within a timeout time).
`Furthermore, some GSM functions cannot be easily
`accessed using the existing JTAPI Syntax and method Sig
`nature. The following new methods or methods with differ
`ent Signatures are defined.
`ProvidergetNetworkID() returns the name of the current
`network.
`Provider.getServiceLevel() returns the operating Service
`level, NONE, EMERGENCY, FULL.
`ProviderisRoaming() returns true if the MS is not on the
`home PLMN.
`These new methods allow the application to determine the
`current public land mobile network (PLMN), operating
`Service level and whether or not the unit is on the home
`PLMN.
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Ex.1016
`APPLE INC. / Page 9 of 17
`
`

`

`US 6,269,254 B1
`
`S
`In JTAPI, the Terminal object represents the physical
`end-point of the call. It is assumed that the call is carrying
`Voice. To Support the additional call bearer types defined for
`GSM, additional Terminal Subclasses are defined, one for
`each major call bearer type. The DataTerminal Subclass of
`Terminal represents the physical end-point of a GSM data
`call. The FaxTerminal subclass of Terminal represents the
`physical end-point of a GSM fax call.
`A typical GSM MS will support at least three Terminals,
`a VOICE, a DATA and a FAX Terminal. An MS may support
`additional Terminal instances or Subclasses (e.g., a Internal
`Data Terminal for internal data and a Modem Data Terminal
`for data sent to a connected PC). Applications accept incom
`ing calls of various bearer types by observing incoming call
`events on the appropriate Terminal.
`There is now described, with reference to FIG. 4, a
`particular feature that permits Supporting of a dual mode
`GSM call.
`FIG. 4 illustrates details of the JTAPI implementation 18
`of FIG. 3. Central to the method is the provider method 40.
`This provider method interfaces with the operating System
`14 in a manner that need not be described in detail. AS used
`in this context, a “method’ is a function defined inside a
`class that operates on instances of that class. The provider
`method 40 has associated with it a voice terminal object 42,
`a data terminal object 44, a fax terminal object 46, and an
`address object 48. When a call is to be set up, the provider
`method 40 creates a call object 50. The call object 50 creates
`a local connection object 52. For a simple voice connection,
`the local connection object 52 creates a terminal connection
`object 54 which references the voice terminal 42. As will be
`described in greater detail, the local connection object 52
`can also create a Second terminal connection object 56 (and
`even a third terminal connection object 58). The second
`terminal connection object 56 references the data terminal
`object 44. The third terminal object 58, if present, can
`reference the fax terminal 46. As an alternative
`configuration, the Second and third terminal connection
`objects can be generated for the purpose of creating a data
`and fax call, as will be described in greater detail.
`It may be noted that if the call is a three-way call, the call
`object 50 will create an additional remote connection object
`60 with its own associated terminal connection objects
`62-66, as necessary. It may also be noted that if there is
`another call (for example a call on hold) the provider method
`40 can create an additional second call object 70 which will
`have its own corresponding local connection and terminal
`connections. In all cases, for a given radio telephone, there
`are only three terminals: the Voice terminal, the data terminal
`and the fax terminal. So in all cases, the various terminal
`connection objects created by the local connection 52 and
`the remote connection 60 and any other local connections or
`remote connections all reference the respective voice termi
`nal object 42, data terminal object 44 and fax terminal object
`46.
`In the process about to be described, it is the aim that the
`GSM transceiver 30 sets up a call with a remote switch over
`a radio telephone communications channel and in the case
`where the call is a dual mode (e.g. Voice and data or voice
`and fax) it is the aim for the JTAPI method implementation
`18 to set up a call with dual mode capability and to inform
`the GSM transceiver over the CSPMI 22 that a dual mode
`call has been established, so that the GSM transceiver 30 can
`inform the GSM system that the call is a dual mode call, so
`that in turn the Switch of the GSM system, upon receipt of
`the request to Set up a call makes a call and reserves a
`
`5
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`modem of its interworking function to Support the data or
`fax functionality of the call. It is further the aim to establish
`this dual mode call at the instigation of the phone application
`16, using the JTAPI command call.connect().
`In JTAPI version 1.2, call.connect() expects an argument
`that is a terminal object, thereby permitting establishment of
`a Single mode call to or from that terminal. In order to
`establish a dual mode call, the preferred embodiment of the
`present invention permits call.connect() to be overridden to
`add a method that takes as a first argument a terminal array,
`instead of a single originating terminal. The terminal array
`is the argument of the command call.connect and contains an
`array of terminal objects which may be a voice terminal and
`a data terminal or a voice terminal and a fax terminal or a
`data terminal and a fax terminal or a voice terminal, a data
`terminal and a fax terminal. When the method provider 40
`is invoked with this command and an array as an argument,
`it creates the call object 50 and the local connection object
`22. The local connection object 22 creates the first and
`second terminal objects 54 and 56. The local connection
`object 52 queries the first terminal connection object 54 for
`its terminal and the first terminal object 54 replies to the
`local connection object 52 indicating that its terminal (i.e.
`the terminal that its references) is the voice terminal.
`Similarly, the Second terminal connection object 56 is que
`ried by the local connection object 52 and replies by
`indicating that its terminal is the data terminal. The local
`connection object 54 informs the call object 50 that a data
`terminal connection and a Voice terminal connection are
`established. The call object 50 informs the provider 40 that
`the dual mode call has been established. The provider 40
`informs the GSM transceiver over the CSPMI 22 (through
`the OS 14) that the dual mode call has been established.
`The provider 40 establishes the call through the trans
`ceiver 30 as follows. The provider 40 creates a buffer that
`has as its type PlaceCallReq and it adds parameters M/O/C
`from the following Table 1. These parameters describe the
`call.
`
`TABLE 1.
`
`Parameter Name
`
`Parameter Type
`
`M?OfC
`
`CallType
`CALL TYPE
`M
`CalledParty'
`PHONE NUMBER
`C
`Repeatindicator?
`REPEAT INDICATOR
`O
`CallType?
`CALL TYPE
`O
`DataPerameters
`DATA-PARAMETERS
`C
`CLIRDisposition'
`CLIR DISPOSITION
`O
`CUGInfo
`CUG INFO
`O
`"Optional for Emergency calls, Mandatory for all other call types.
`*Mandatory for Multiple Call Type Calls.
`Mandatory when any Call Type is for Fax or Data.
`May be included if client wishes to override CLIR subscription default.
`May be included if client wishes to override CUG subscription defaults.
`The contents of this buffer are sent across the serial link
`22 to the transceiver 30 and, if accepted, the transceiver
`returns the confirmation message from the following table 2.
`
`TABLE 2
`
`Parameter Name
`
`Parameter Type
`
`M?OfC
`
`CallHandle
`CALL HANDLE
`"Mandatory of the call request is successful.
`This confirmation message gives call-handle which
`allows the microprocessor 10 to identify the call in Subse
`quent commands.
`
`C
`
`Ex.1016
`APPLE INC. / Page 10 of 17
`
`

`

`US 6,269,254 B1
`
`15
`
`25
`
`35
`
`40
`
`7
`In Table 1, call type 2 indicates an alternate call type and
`indicates that the alternate call type is data or fax (the initial
`call type is always voice in GSM). In this manner, the
`provider 40 informs the transceiver 30 that there is an
`alternate call type and that it is data (alternatively fax). Thus,
`when the transceiver 30 sets up the call, the Switch is then
`informed that there an alternate call type and that this
`alternate call type requires reservation of a data modem (or
`a fax modem).
`The first terminal array entry is the initially active
`terminal, but the call is configured to handle any of the
`terminals declared in the array, that is, the terminal connec
`tions to the other terminals are placed in the call control
`terminal
`connection. bridge d State
`(or
`terminalconnection. passivestate). As discussed above,
`joined/leave is used to control the current mode of the call.
`This variant of connect () is used to support the GSM
`requirement of initially declaring dual-mode call parameters
`(thus requiring the application 16 to declare up front all of
`the terminals that might participate in the call).
`Call.connect() is overridden to add methods to explicitly
`specify the TON (type of number) and NPI (numbering plan
`identifier) of the destination address String, if these cannot be
`inferred as described above.
`Call.setFmergency( ) is defined to set the emergency
`mode flag.
`Call.setCUGInfo() is defined to specify closed user group
`information in a programmatic form rather than using SS
`(Supplementary Services) codes in the destination address
`String.
`Call.setCalleridRestricted() is defined to specify calling
`line identification restriction requests in a programmatic
`form rather than using SS codes in the destination address
`String.
`Call.offHook() is not supported.
`Applications cannot specify the transfer or conference
`controller. The set Transfer Controller ( ) and
`setConferenceController() methods throw MethodNotSup
`ported and get Conference Controller ( ) and
`getTransferController() return <NULL>
`The setConference Enable(), getConferenceEnable( ),
`setTransferEnable() and getTransferEnable() manipulate
`internal flags that control the ability to transfer or conference
`this call.
`Call.consult( ) invocations must include the destination
`address String; the unspecified variant is not Supported.
`Connection.reject(int) is defined to allow the application
`to specify a reject reason when refusing a call. This Supports
`user-determined-user-busy functionality.
`Connection.addToAddress( ) is not Supported.
`Connection.park() is not Supported.
`A Subclass of terminal connection is defined (data termi
`nal connection) representing the physical link between the
`network and the end-point data terminal. Methods are
`defined to specify and query the data call parameters, Such
`as data rate, modem type, layer to protocol etc. Similarly, a
`Sub-class of terminal connection (fax terminal connection),
`which is more accurately described as a Sub-class of media
`terminal connection) represents the physical link between
`the network and the end-point terminals. Methods are
`defined to Specify and query the fax call parameters, Such as
`data weight, group mode etc.
`FaxTerminalConnection also provided media-specific
`methods for configuring the faX media Stream, and trans
`mitting data pages and end-of-page indicators.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`A new Terminal event is defined to allow applications to
`determine if call forwarding is active for a “Term Forward
`ingActiveEv' specific Terminal. Forwarding for different
`Services (i.e., voice, fax and data) are signaling through the
`appropriate Terminal object (i.e., VOICE, DATA, FAX).
`It has been mentioned that Provider.createCall( ) will
`create a call even if the Provider is OUT OF SERVICE, as
`long as it has not been shut down and that the call cannot be
`successfully placed until the Provider is IN SERVICE. This
`feature is described now in greater detail with reference to
`FIGS. 5 and 6.
`Referring to FIG. 5, the case will be considered where, for
`whatever reason, the application 16 Seeks to place a call or
`establish a connection or a packet data Session. The appli
`cation 16 is typically the interface to the user and may Seek
`to initiate a call by, for example, the user powering up the
`radio communications device (the mobile station or MS) and
`dialing a telephone number. The application 16 initiates the
`program (or method) illustrated in FIG. 5 by calling
`(invoking) a Provider.createCall method (step 100) through
`a Provider.createCall() command across the API 30. If, in
`Step 101, the communications device is in a shut down
`mode, the program Simply returns an error in Step 102 and
`exits at step 103. If the device is not in the shut down mode,
`a Call object 50 is created in step 110, and the program of
`FIG. 5 is completed at step 111, ready for the program of
`FIG. 6 to begin.
`Immediately following creation of the Call object 50 and
`without any further events or conditions (and in the absence
`of any overriding event), the application 16 calls (invokes)
`a Call.connect method (step 150) through a Call.connect()
`command across the API 30. If, in step 151, the communi
`cations device is determined to be out of Service, the
`program (or method) waits in step 152 while other functions
`perform a Scanning operation in Step 154. A waiting period
`of about 10 Seconds is typically Sufficient to permit connec
`tion to a cellular network in a Scanning routine. If, following
`step 151 or step 156, the communications device has estab
`lished Service with a radio communications network, Step
`158 begins and a command is sent to the transceiver 30
`acroSS the Serial interface 22 to place the call. The program
`of FIG. 6 ends at step 160.
`In this manner, a user is able to begin dialing a telephone
`number to place a call even before Service has been estab
`lished. This is a particularly useful feature Since a typical
`user wishes to begin placing a call as Soon as the commu
`nications device is powered up, without regard for whether
`Service has been established.