(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(1 9) World Intellectual Property Organization
`International Bureau
`
`11111111111111111111111111111111111111111111111111111111111111111111111111111111
`
`(43) International Publication Date
`8 March 2001 (08.03.2001)
`
`PCT
`
`(10) International Publication Number
`WO 01/16931 A1
`
`(51) International Patent Classification 7:
`H04H 1100
`
`GlOH 1/00,
`
`(21) International Application Number:
`
`PCT/FI00/00737
`
`(22) International Filing Date: 31 August 2000 (31.08.2000)
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`HAMALAINEN, Matti [FIIFI]; Kanavatie 3, FIN-37500
`Lempaala (FI). WILLIAMS, David, P. [GB/GB]; 2 New
`Barn Lane, Alton, Hampshire GU34 2RU (GB). AAL(cid:173)
`TONF:N, Janne [FI/FI]; HirvikoirankatlJ 15, FIN-20900
`Turku
`IKONEN, Ari
`[FIIFI]; Kaivokuja 12,
`(FI).
`FIN-21280 Raisio (Fl).
`
`(74) Agent: BERGGREN OY AB; P.O. Box 16, FIN-00101
`Helsinki (FJ).
`
`(81) Designated States (national): CN, JP, US.
`
`(30) Priority Data:
`19991865
`
`1 September 1999 (01.09.1999) Fl
`
`(84) Designated States (regional): European patent (AT, BE,
`CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC,
`NL, PT, SE).
`
`(71) Applicant (for all designated States except US): NOKIA
`OYJ [FIIFI]; Nokia-talo, Keilalahdentie 4, FIN-02150 Es-
`poo (FI).
`
`Published:
`With international search report.
`
`;;;;;;;;;;;;
`;;;;;;;;;;;;
`;;;;;;;;;;;;
`
`(72) Invenlors; and
`(75) Inventors/Applicants (for US only): HOLM, .Jukka
`[FIIFI]; Niemikatu 7 B 7, FIN-33230 Tampere (FI).
`
`For two-letter c:odes und other abbreviations, refor to the "Guid(cid:173)
`ance Notes on Codes and Abbreviations" appearing at the begin(cid:173)
`ning of each regular issue of the PCT Gazette.
`
`---------------------------------------------------------------------------------------
`(54) Title: METHOD AND ARRANGEMENT FOR PROVIDING CUSTOMIZED AUDIO CHARACTERISTICS TO CELLU(cid:173)
`LAR TERMINALS
`
`-;;;;;;;;;;;; -
`iiiiiii -;;;;;;;;;;;;
`
`;;;;;;;;;;;;
`
`!!!!!!!!!!
`
`~
`~
`~
`~ (57) Abstract: A method is provided for downloading audio characteristics to terminal equipment. A score information part (101,
`-... 302, 303) is provided describing the presentation instructions of an audible signal. An instrument information part (104, 305, 306)
`~ is also provided describing the parameters for synthesizing an audible signal the presentation instructions of which is described by
`said score information part. Additionally some compatibility information (123, 210, 211, 212, 220, 315) is provided describing
`0 the compatibility of said score information part and said instrument information part with certain processing and storing capacity.
`:;;;;.,.. As a response to a selection command (411, 418), (412, 419) said score infom1ation part and said instrument information part are
`~ downloaded to terminal equipment through a communication network.
`
`Verizon Wireless
`Exhibit 1021-0001
`
`

`
`wo 01116931
`
`PCT /FI00/00737
`
`1
`
`Method and arrangement for providing customized audio characteristics to
`cellular terminals
`
`5
`
`The invention concerns generally the technological field of furnishing terminal
`equipment of communication systems with selectable audio characteristics.
`Especially the invention concerns a method and arrangement for providing a large
`degree of selectability to individual users concerning ringing tones and other sounds
`emitted by their terminal equipment.
`
`15
`
`10
`
`Portable terminals of cellular radio systems have conventionally been mobile
`telephones, but the development trend at the priority date of this patent application
`is towards more versatile terminal equipment with features from e.g. palmtop
`computers, telephones, positioning devices and personal digital assistants (PDAs ).
`The conventional way of producing a ringing tone in a portable terminal is to use a
`buzzer which is optimized for efficiency in producing a high output sound pressure
`level. The buzzers that are most commonly used only accept a single square wave as
`an input waveform. A square input wave on a constant frequency gives rise to a
`monophonic output buzz with constant pitch. It is possible to play simple
`monophonic melodies with the buzzer by composing the input signal as a sequence
`of relatively short square wave trains. It is possible to use the loudspeaker of the
`20 mobile terminal to emit more versatile sounds, but in practice it may be difficult to
`obtain a reasonably high output sound pressure level without sacrificing compact
`size, efficiency in energy consumption and usability in the telephone mode.
`
`25
`
`30
`
`Manufacturers have conventionally provided their mobile terminals with a selection
`of alternative ringing tones by storing a number of different buzzer input sequences
`into the terminal's memory. A user can select one of these preprogrammed tones by
`performing a simple programming step. Practical experience has shown that
`consumers are eager to personalize their mobile terminals according to their own
`taste, which has led to a phenomenal success of services that sell downloadable
`ringing tones. The known method of downloading a ringing tone from a network
`requires the user to send an SMS message (Short Messaging Services) to a certain
`ringing tone server coupled to the fixed parts of the cellular network, said message
`indicating the user's willingness to download a new ringing tone and preferably also
`identifying a particular melody which the user is interested in. The server responds
`with a specifically formatted SMS message that contains machine-readable
`
`Verizon Wireless
`Exhibit 1021-0002
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`2
`
`instructions which the portable terminal can use to reproduce the ringing tone in
`question.
`
`the selectability and downloading services described above has
`Although
`concentrated on ringing tones, it would be possible to use similar methods and
`arrangements to select personal tones or melodies for all occasions when the
`portable terminal emits an indicatory audio signal. Such occasions comprise but are
`not limited to indicator tones for key depressing, alarm sounds for battery depletion
`and other threatening events as well as amusing sounds for games.
`
`The drawbacks of the prior art arrangements for providing selectability to portable
`terminals' audio characteristics are related to the limited sound reproduction
`capability on one hand and to the shortage of various resources on the other. With
`resources we mean the memory space and allocatable processing capability of the
`portable terminal itself as well as the allocatable transmission resources between the
`terminal and the fixed parts of the cellular radio network We will illustrate the
`resource question with some examples.
`
`5
`
`10
`
`15
`
`20
`
`At the priority date of this patent application one of the most popular ways of
`distributing arbitrary high quality audio sequences in electronic form is MP3 or
`MPEG-2 Layer 3 coded audio, where MPEG originally comes from Motion Picture
`Experts Group. The MP3 audio encoding is based on a method where an original
`audio sequence is recorded, digitized and compressed by performing a number of
`mathematical transformations on short consecutive frames of the digitized signal.
`One minute of MP3 encoded audio signal results in approximately 8 Mbits of data
`depending on the used compression rate. If we set the minimum temporal length of a
`ringing tone at ten seconds, a single melody would require over 1.3 Mbits of
`25 memory when stored. This is far too much regarding the limited amount of memory
`allocatable to ringing tones in known portable terminals. The downloading of such a
`ten-second audio sequence over the known GSM (Global System for Mobile
`telecommunications) digital cellular network at 9.6 kbit/s would take well over two
`minutes, which is unacceptable in terms of network loading and communication
`cost. Decoding an MP3 encoded bitstream into a for suitable for playback requires
`quite intensive processing.
`
`30
`
`At the priority date of this patent application there is one portable terminal on the
`market, known by the registered trademark "Nokia 9110 Communicator" of Nokia
`Corporation, that supports the playback of arbitrary audio tones encoded by Pulse
`35 Code Modulation or PCM. A typical 8-bit PCM encoded wave file that represents
`
`Verizon Wireless
`Exhibit 1021-0003
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`3
`
`ten seconds of emitted signal with relatively low audio quality has the size of 640
`kbits. Although this is considerably less than what is required by the MP3 encoded
`sequence, it is still too much for large-scale downloading.
`
`5
`
`It is an object of the present invention to provide a method and an arrangement for
`offering a wide variety of selectable audio characteristics to the users of terminal
`equipment with reasonable requirements concerning memory space, processing
`capability and transmission resources. It is a further object of the invention to
`provide compatibility of the method and arrangement with a large selection of
`terminal types and operating software. An additional object of the invention is to
`10 make it easy for the user to tailor the audio characteristics of terminal equipment
`according to personal taste.
`
`The objects of the invention are achieved by presenting audio sequences in a form
`with a score information part and an instrument information part. The instrument
`information part contains synthesis parameters that defme the timbre, or the
`synthesized sound or sequence of sounds. The score information part contains
`instructions that defme the usage of the instrument information. Additionally there
`is provided compatibility information describing the compatibility of such audio
`sequences with known terminal capabilities.
`
`The method according to the first embodiment of the invention is characterized in
`that it comprises the steps of
`- providing a score information part describing the presentation instructions of an
`audible signal,
`for
`the parameters
`information part describing
`instrument
`- providing an
`synthesizing an audible signal the presentation instructions of which is described by
`said score information part,
`- providing compatibility information describing the compatibility of said score
`information part and said instrument information part with certain processing and
`storing capacity and
`- as a response to a selection command, downloading said score information part
`and said
`instrument
`information part
`to
`terminal equipment
`through a
`communication network.
`
`15
`
`20
`
`25
`
`30
`
`The method according to the second embodiment of the invention is characterized in
`that it comprises the steps of
`- indicating the type of terminal equipment to a network,
`
`Verizon Wireless
`Exhibit 1021-0004
`
`

`
`WOOl/16931
`
`PCT/FI00/00737
`
`4
`
`5
`
`10
`
`15
`
`20
`
`- receiving from the network information concerning available score information
`parts, each of them describing the presentation instructions of an audible signal, and
`instrument information parts, each of them describing the parameters for
`synthesizing an audible signal the presentation instructions of which is described by
`a score information part,
`- indicating at least one score information part and at least one instrument
`information part from said available score information parts and instrument
`information parts as selected, and
`- receiving the score information part and the instrument information part indicated
`as selected from the network
`
`The invention also applies to an apparatus which comprises a network device. It is
`characterized in that the network device comprises
`- a database of score information parts, each score information part describing the
`presentation instructions of an audible signal,
`- a database of instrument information parts, each instrument information part
`describing the parameters for synthesizing an audible signal the presentation
`instructions of which is described by a score information part,
`- compatibility information associated with said score information parts and
`instrument information parts, describing the compatibility of said score information
`parts and said instrument information parts with certain processing and storing
`capacity and
`- means for responding to a selection command by downloading a score information
`part and a instmment information part to
`temlinal equipment through a
`communication network.
`
`30
`
`25 According to the invention a service provider or a similarly acting other body
`maintains a database that comprises a plurality of sound packets. A sound packet is
`understood in this context as an entity that comprises a piece of musical score
`information and a set of parameters that relate to the "instruments" or synthesized
`sound sources which should be used to play the score. A sound packet is preferably
`self-contained in the sense that once it has been loaded into terminal equipment with
`appropriate processing and audio outputting capabilities, it enables the terminal to
`output a certain passage of audio signal where the synthesized sounds described by
`the parameters perform the presentation written into the score information. Said
`database contains also information about the compatibility of the stored sound
`packets with the capabilities of known terminal types. For downloading into a
`
`35
`
`Verizon Wireless
`Exhibit 1021-0005
`
`

`
`wo 01116931
`
`PCT/FI00/00737
`
`5
`
`certain terminal equipment of known type only those sound packets are made
`available that do not exceed the terminal's capabilities.
`
`5
`
`The novel features which are considered as characteristic of the invention are set
`forth in particular in the appended Claims. The invention itself, however, both as to
`its construction and its method of operation, together with additional objects and
`advantages thereof, will be best understood from the following description of
`specific embodiments when read in connection with the accompanying drawings.
`
`Fig. 1
`
`illustrates the structure of a sound packet according to an advantageous
`embodiment of the invention,
`
`10
`
`Fig. 2a
`
`illustrates an advantageous database arrangement,
`
`Fig. 2b
`
`illustrates another advantageous database arrangement,
`
`Fig. 3
`
`illustrates an alternative database arrangement,
`
`Fig. 4
`
`is a flow diagram of a method according to the invention,
`
`Fig. Sa
`
`illustrates a software tool for applying the invention,
`
`15
`
`Fig. 5b
`
`illustrates further software tools for applying the invention,
`
`Fig. 6
`
`Fig. 7
`
`illustrates some communication connections that can be used for
`applying the invention,
`
`illustrates some pteces of hardware m a terminal according to the
`invention and
`
`20
`
`Fig. 8
`
`illustrates a broadcasting-based embodiment of the invention.
`
`The idea of organizing a piece of music electronically into a score information part
`and a parameter or instrument information part is known as such. In the following
`we will first describe some known solutions of this kind.
`
`25
`
`Within the field of musical synthesizers there are known the concepts of patches
`and patch maps. Each stored synthesized instrument sound is designated with an
`associated patch number, and the table that correlates patch numbers with
`instruments is known as the patch map. One of the major standards controlling
`musical synthesizing and exchange of information related thereto between
`electronic devices is MIDI (Musical Instrument Digital Interface). It is possible to
`
`Verizon Wireless
`Exhibit 1021-0006
`
`

`
`WOOl/16931
`
`PCT/FI00/00737
`
`6
`
`compose a piece of synthesized music with one synthesizer and transfer it in digital
`form into another synthesizer. The digital representation of the piece of music
`contains information about e.g. which patch number(s) should be associated with
`each individual "channel" or voice in a musical score. If a receiving synthesizer uses
`the same patch map as the one with which the piece was composed, it is able to
`playback the piece exactly as it was at the composing stage. Within MIDI the most
`commonly used standard for instrument mapping is known as the GM or General
`MIDI. Known extensions to it are known as XG, GS and GM 2.0.
`
`5
`
`10
`
`None of these instrument mapping standards actually describes how the actual
`instrument voice should be produced. Known sound synthesis technologies are e.g.
`FM (Frequency Modulation), wavetable synthesis and physical modelling.
`
`15
`
`For downloading sounds that can be associated to patch numbers in a patch map a
`SoundFont® file format has been introduced by Creative Labs Corporation where a
`collection of 16-bit digital samples is associated with synthesis information required
`to articulate the digital signal in the audio domain. The MIDI Manufacturers
`Association or MMA has also introduced a sound sample downloading format
`level 1 (DLS-1). Recently
`these sound
`known as Downloadable Sounds
`downloading formats have been merged into a new standard known as DLS-2. It is
`also known as SASBF or Structured Audio Sample Bank Format within the
`20 MPEG-4 multimedia standard. Commercial implementations of DLS-2 do not exist
`at the priority date of this patent application.
`
`25
`
`30
`
`Staccato Systems Inc. has introduced an audio technology known as SynthScript®
`Down Loadable Algorithms or DLA, which is based on physical modelling of
`instrument voices. A processing engine known as the SynthCore® is required to
`convert a SynthScriptDLA text file into playing music. The processing engine also
`supports the GM, XG and DLS-1 synthesis mechanisms referred to above.
`
`Additionally there is known a musical data file format known as the Rich Music
`Format or RMF. It determines how a single file format can be used to incorporate
`all sample, performance and copyright information of a piece of music. The
`performance portion is based on the MIDI file model with some extended control
`functions.
`
`Although the above-described methods and arrangements for representing audio
`sequences are known to the public at the priority date of the present patent
`to ringtone and other audio
`they are not directly applicable
`application,
`
`Verizon Wireless
`Exhibit 1021-0007
`
`

`
`WOOl/16931
`
`PCT/FI00/00737
`
`7
`
`characteristics download services for portable tenninal. ln the following we describe
`the method and apparatus according to the invention, making use of the above(cid:173)
`mentioned known concepts at appropriate points.
`
`Fig.1 illustrates the conceptual composition of a sound packet according to an
`advantageous embodiment of the invention. The sound packet 100 comprises a
`score information part 10 1 which may be regarded as a song book or music case that
`contains the notes which should be played and relate synthesis instructions. The
`score information part may consist of score data subparts 102, 103 each of which
`comprises the score of a single song. Each score data subpart may further comprise
`sub-subparts each of which comprises the score of a single voice in that song.
`Additionally the sound packet comprises a instrument information part 104 which
`contains the instrument data, i.e. the parameters that a musical synthesizer needs to
`set up the "band" that should be used to play the score(s) contained in the score
`information part 10 1. These parameters are most advantageously organized into
`instrument data subparts 105, 106 so that each instrument data subpart defmes a
`single instrument that may be used to play one or more of the voices defmed by the
`score information subparts 102, 103.
`
`Previously we have noted that the invention does not concern only the generation of
`ringing tones but it can be applied to the generation of other indicative audio signal
`as well. We may designate the latter class of voices generally as User Interface or
`UI sounds. In the embodiment of Fig. 1 the sound packet may comprise a UI sounds
`part 107 which again may consist of one or more UI sound data subparts 108, 109.
`Each UI sound data subpart 108, 109 is an entity based on which the tenninal
`equipment is able to generate a certain UI sound. Because the UI sounds are usually
`simple tones or very short melodies, the UI sound data subparts may be represented
`in very simple form that is different from score information. Naturally they can also
`be complete score data subparts like those 102, 103 shown under the score
`information part 10 1 so that an arbitrary piece of music can be performed as a UI
`sound by associating the score information contained in the UI sound data
`subpart(s) with corresponding instrument data subpart(s). It is also possible to have
`alternative instrument data subparts as UI sound data subparts so that the scores
`presented in the score information part produce either a ringing tone or some UI
`sound( s) depending on whether they are played with the "band" defmed in the
`instrument information part 104 or the UI sounds part 107 respectively. An even
`further alternative is to have both score data subparts and instrument data subparts
`within the UI sounds part 107. lf the invention is applied only to distribute and
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Verizon Wireless
`Exhibit 1021-0008
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`8
`
`download ringing tones, the UI sounds part 107 and its subparts 108, 109 arc not
`needed.
`
`Additionally Fig. 1 shows an optional generic audio part 110 as a part of the sound
`packet. The generic audio part 110 may consists of generic audio subparts 111, 112
`etc., each of which comprises a generic audio signal. The generic audio part 110 is
`included in the sound packet model to provide a possibility to transmit an arbitrary
`audio sequence or a number of such sequences as a part of the sound packet. The
`form of the generic audio part 110 or its subparts is not limited by the invention, but
`it can be e.g. MP3 or speech encoded with one of the speech encoding methods
`known in the field of speech processing. If the invention is applied only to distribute
`and download melodical ringing tones, the generic audio part 110 is not needed.
`
`In order to facilitate the handling of sound packets it is advantageous to include into
`the sound packet structure a header part 121 which comprises general information
`like an identifier 122 of the sound packet, compatibility information 123 describing
`the compatibility of the sound packet with different known terminal types or just
`laying out some minimum allocatable resources (like processing capacity in MIPS
`and allocatable memory in kbits) required to use the sound packet, and copyright
`information 124 concerning the sound packet if applicable. The invention does not
`limit the contents of the header part 121.
`
`5
`
`10
`
`15
`
`20 A separate header part could also be included in each score information part 101,
`instrument information part 104, UI sounds part 107 and/or generic audio part 110,
`or even to every subpart and/or sub-subpart. Such header part could comprise e.g.
`specified copyright information and/or resource requirement information concerning
`only that part of the sound packet.
`
`25
`
`30
`
`35
`
`The sound packet approach illustrated in Fig. 1 differs from the known MIDI
`principle of downloading a piece of music mainly in that the instrument information
`part 104 that defmes the "band" used to play the transmitted piece of music is
`contained within the same data struture 100 that in another part describes the actual
`music itself. In order to convey a MIDI music performance in its original form, the
`same patch map and the same set of instrument data has to be used for the synthesis
`of the music. Taken the considerable versatility and size of the patch maps of e.g.
`GM 2.0, a large number of the instrument descriptions would probably never be
`needed (a classical music enthusiast would probably never download a ringing tone
`that requires the instrument descriptions of heavy rock guitars). Furthermore, the
`number of different sounds needed for creative music is infmite. It is impossible to
`
`Verizon Wireless
`Exhibit 1021-0009
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`9
`
`create a fixed collection of sounds that could satisfy the requirements of all
`musicians and content providers of the priority date of this patent application, not to
`mention the ever-expanding future requirements. The invention obviates the need
`for storing a large number of instrument descriptions in the limited memory space of
`a portable terminal. According to the preferable embodiment of the invention the
`parameter data parts that defme the instruments are transmitted concerning only
`those instruments that are actually needed to perform the chosen pieces of music.
`
`5
`
`10
`
`The size of a sound packet 100 in bits, as well as the processing capability required
`to playback the piece of music described therein in intended tempo, will depend
`heavily on the used synthesis technology, the accuracy and quality of the
`synthesized sounds, the diversity of the band or number of different instrument
`sounds, and the number of simultaneous voices, i.e. polyphony. It is possible to
`compose e.g. a very simple sound packet where only a single coarsely encoded
`instrument voice plays one or few notes, or an immensely complex sound packet
`15 where a doubled symphony orchestra with high-quality instrument voices performs
`a Wagner ouverture backwards in quadrupled tempo. The processing capacity
`required to decode and playback a sound packet is mostly determined by the degree
`of polyphony associated with the song to be played, i.e.
`the number of
`simultaneously playing voices.
`
`20 A part of the invention is that it is somehow indicated, what are the resource
`requirements of a certain sound packet and/or which known terminal equipment
`types it is compatible with. Compatibility with a certain terminal equipment type
`means in this context that it is known that a normal terminal equipment of that type
`has enough allocatable memory and processing capability to download, store and
`playback that sound packet. Above we have noted that one way of indicating
`compatibility is to provide within the sound packet a header part where
`compatibility with known terminal types or the minimum amount of allocatable
`resources is explicitly recited. However, the compatibility information need not be
`an explicit part of the sound packet at all.
`
`25
`
`30
`
`35
`
`The invention does not limit the form of the score information part and the
`instrument information part, although it is regarded as advantageous to use a form
`taken from the above-mentioned existing standards. A score information part of a
`sound packet may be quite compact relative to the instrument information part. In
`practice, score infonnation parts and instrument information parts are represented in
`differrent forms. It is possible e.g. to use the known SMS format, SAOL format or
`Csound score data format for scores, and a wavetable or physical modelling method
`
`Verizon Wireless
`Exhibit 1021-0010
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`10
`
`for the instmments. It is also possible to use a common RMF or Rich Music Format
`file that encompasses both the score information part and the instrument information
`part.
`
`Fig. 2a illustrates a structure of sound packets stored in a database schematically
`shown as 200. Said database is most advantageously maintained in a service
`provider's computer with fixed connections to a cellular radio network. The sound
`packets themselves 201, 202, 203, 204, 205 and 206 are most advantageously stored
`only once, i.e. only one copy (except for a potential back-up copy) of each sound
`packet appears in the database. In order to make only those sound packets available
`to a particular terminal type that are compatible with the allocatable resources in
`that terminal type the database or its associated handling functions comprises a
`terminal type selector block 213 as well as a number of terminal type blocks 211,
`212 and 213. Each terminal type block is a collection of pointers where each pointer
`points to one sound packet which is known to be compatible with the terminal type
`in question. The idea behind this arrangement is that when a query is made to the
`database, it is first checked by the functions of block 213 whether the query
`comprises an indication of a particular tenninal type. If such an indication is found,
`the appropriate terminal type block 211, 212 or 213 is called and the pointers in the
`called terminal type block are noted so that only those sound packets are made
`available for querying that are compatible with the terminal type in question. It is
`left to the discretion of eventual implementers to decide, whether a query with no
`terminal type indication is answered by making no sound packets available, by
`making all sound packets available or in some other way. The invention does not
`limit the number of sound packets or terminal type blocks in the database, or the
`number of pointer com1ections between a terminal type block and sound packets.
`
`Fig. 2b illustrates an alternative database arrangement where a database 200' again
`comprises a number of sound packets 201, 202, 203, 204, 205 and 206. Instead of a
`terminal type based selection arrangement the database or its associated handling
`functions comprise a compatibility wizard 220. When a query is made to the
`database, the compatibility wizard 220 checks whether the query comprises an
`indication of allocatable memory space and processing capability. If such
`indications exist, the compatibility wizard 220 checks from the known capacity
`requirements of the sound packets 201, 202, 203, 204, 205 and 206 which of them
`are within the limits set by the indicated allocatable memory space and processing
`capability. The compatibility wizard 220 then makes only those sound packets
`available for querying that are compatible with the indicated allocatable resources.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Verizon Wireless
`Exhibit 1021-0011
`
`

`
`wo 01/16931
`
`PCT/FI00/00737
`
`11
`
`Other anangements than those in Figs. 2a and 2b are easily presented by persons
`skilled in the art for making a limited number of database entries available for
`querying when a query comprises an indication of limitations concerning the
`characteristics of the objects to be queried.
`
`Fig. 3 illustrates an alternative, more versatile approach to implementing the
`database of sound packets with associated information about compatibility with
`terminal types or otherwise determined availability of resources. The database 300
`does not consist of complete sound packets; instead, the sound packet components
`are separately stored in appropriate libraries, and sound packets are only assembled
`for delivery according to order. The score information library 301 comprises a
`number of score information parts 302, 303 each of which is analogous to the score
`information part 101 in Fig. 1. In other words each score information part in Fig. 3
`may further comprise an arbitrary number of score data subparts and sub-subparts.
`In order to maintain graphical clarity these are not separately shown in Fig. 3.
`Similarly an instrument information library 304 comprises a number of instrument
`information parts 305, 306, each of which may further comprise an arbitrary number
`of instrument data subparts (not separately shown in Fig. 3), and a UI sounds library
`307 comprises a number of UI sounds parts 308, 309, each of which may further
`comprise an arbitrary number of UI sound data subparts (not separately shown in
`Fig. 3). For completeness also a generic audio library 310 is shown. It may further
`comprise an arbitrary number of generic audio files 311, 312.
`
`The operation of the database 300 in Fig. 3 is coordinated by a compatibility wizard
`and sound packet generator block 313 which may have a number of general
`information sub blocks at its disposal. A sound packet ID and header generator block
`314, a resource requirements analyzer block 315 and a copyrights database 316 are
`specifically shown in Fig. 3.
`
`The database and function structure shown in Fig. 3 can be used for tailoring sound
`packets to the need and taste of individual users in a very versatile way. The
`is arranged to
`compatibility wizard and sound packet generator block 313
`communicate with a user to fmd out the user's terminal type (or otherwise specified
`limitations concerning available resources), the selection of desired score(s) and the
`selection of desired instrumentation. Based on this information the compatibility
`wizard and sound packet generator block 313 is arr