`NATIONAL BOARD OF PATENTS AN.D REGISTRATION
`
`Helsinki 13.10.2000
`
`•
`
`101070055
`PCT/FI 0 0 1 0 0 7 if 7
`~
`~d
`r-------------D~ol~~~
`I R!:C'O 3 • i OCT 2DOD
`
`Hakija
`Applicant
`
`Patenttihakemus nro
`Patent application no
`
`Tekemispaiva
`Filing date
`
`Nokia Oyj
`Espoo
`
`19991865
`
`01.09.1999
`
`Kansainvalinen luokka
`International class
`
`H04M
`
`Keksinnon nimitys
`Title of invention
`
`•
`
`j
`
`'llr
`
`"Method and arrangement for providing customized audio characteristics
`to cellular terminals"
`(Menete1ma ja jarjestelma raataloityjen audio-ominaisuuksien
`toimittamiseksi solukkojarjestelmien paatelaitteisiin)
`
`Taten todistetaan, etta oheiset asiakirjat ovat tarkkoja jaljennoksia
`patentti- ja rekisterihallitukselle alkuaan annetuista selityksesta,
`patenttivaatimuksista, tiivistelmasta ja piirustuksista.
`This is to certify that the annexed documents are true copies of the
`description, claims, abstract and drawings originally filed with the
`Finnish Patent Office.
`
`Ill.
`!
`
`Marketta Tehikoski
`Apulaistarkastaja
`
`PRIORITY
`DOCUMENT
`SUBMITTED OR TRANSMITTED IN f
`COMPLIANCE WITH RULE 17.l(a) OR (b)
`
`Maksu
`Fee
`
`300,-
`300,-
`
`mk
`FIM
`
`Osoite:
`
`Arkadiankatu 6 A
`Puhelin:
`09 6939 500
`P.O.Box 1160
`Telephone: + 358 9 6939 500
`FIN-00101 Helsinki, FINLAND
`
`Telefax:
`09 6939 5328
`Telefax: + 358 9 6939 5328
`
`Verizon Wireless
`Exhibit 1013-0001
`
`
`
`•
`
`2 •
`
`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
`5 with a specifically formatted SMS message that contains· machine-readable
`instructions which the portable terminal can use to reproduce the ringing tone in
`question.
`
`•
`
`10
`
`15
`
`20
`
`25
`
`30
`
`.• :
`
`.
`
`;_
`
`. .
`.
`. . .
`.
`. . .
`.
`
`- ...... ,
`
`35
`
`Although
`the selectability and downloading services described above has
`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 tenninal 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.
`
`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
`memory when stored. This is far too much regarding the limited amount of memory
`allocatable to ringing tones in known portable terminals. The downloading qf 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
`
`-
`
`Verizon Wireless
`Exhibit 1013-0002
`
`
`
`•
`
`•
`
`3
`
`cost. Decoding an MP3 encoded bitstream into a for suitable for playback requires
`quite intensive processing ..
`
`At the priority date of this patent application there is one portable terminal on the
`5 market, known by the registered trademark "Nokia 9110 Communicator" of Nokia
`Corporation, that supports the playback of arbitrary audio tones encoded by Pulse
`Code Modulation or PCM. A typical 8-bit PCM encoded wave file that represents
`ten seconds of entitted 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`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 transntission 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
`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 instru~ent information part. The instrument
`information part contains synthesis parameters that define the timbre, or the
`synthesized sound or sequence of sounds. The score information part contains
`instructions that define 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,
`- providing an
`instrument
`information part describing
`the parameters for
`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
`
`..
`....
`
`'.'.' ..
`. . .
`. . .
`-·.. .
`....
`. . .
`
`Verizon Wireless
`Exhibit 1013-0003
`
`
`
`•
`
`4 •
`
`to
`
`- as a response to a selection command, downloading said score information part
`and said
`instrument
`information part
`terminal equipment
`through a
`communication network.
`
`'\
`
`5 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,
`-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.
`
`10
`
`15
`
`.
`
`,,..,
`
`'
`
`. . . . . . .
`. . .
`. .
`
`~ : :
`. . .
`. . .
`. . .
`. . .
`
`20
`
`25
`
`30
`
`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
`instrument information part to
`terminal equipment through a
`communication network.
`
`According to the invention a service provider or a similarly acting other body
`35 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
`
`Verizon Wireless
`Exhibit 1 013-0004
`
`
`
`r
`
`5
`
`•
`
`•
`
`5
`
`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
`certain terminal equipment of known type only those sound packets are made
`available that do not exceed the terminal's capabilities.
`
`10 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.
`
`15
`
`20
`
`Fig. 1
`
`illustrates the structure of a sound packet according to an advantageous
`embodiment of the invention,
`
`Fig. 2a
`
`illustrates an advantageous database arrangement,
`
`Fig. 2b
`
`illustrates another advantageous database arrangement,
`
`Fig. 3
`
`illustrates an alternative database arrangement,
`
`25
`
`Fig. 4
`
`is a flow diagram of a method according to the invention,
`
`Fig. Sa
`
`illustrates a software tool for applying the invention,
`
`Fig. Sb
`
`illustrates further software tools for applying the invention,
`
`30
`
`35
`
`Fig. 6
`
`Fig. 7
`
`illustrates some communication connections that can be used for
`applying the invention,
`
`illustrates some p1eces of hardware m a terminal according to the
`invention and
`
`Fig. 8
`
`illustrates a broadcasting-based embodiment of the invention.
`
`. '
`
`~ .l
`
`•
`
`•
`
`-· .
`
`...
`. . .
`. . .
`
`Verizon Wireless
`Exhibit 1013-0005
`
`
`
`•
`
`6 •
`
`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.
`
`5 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 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.
`
`10
`
`15
`
`20 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.
`
`25
`
`30
`
`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
`known as Downloadable Sounds
`level 1 (DLS-1 ). Recently
`these sound
`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
`MPEG-4 multimedia standard. Commercial implementations of DLS-2 do not exist
`at the priority date of this patent application .
`
`•:
`
`: : :
`" .
`-. .
`
`. . .
`.
`. . .
`.
`
`... ,.,_.
`
`35
`
`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
`
`Verizon Wireless
`Exhibit 1013-0006
`
`
`
`•
`
`•
`
`7
`
`convert a SynthScriptDLA text file into playing music. The processing engine also
`supports the GM, XG and DLS-1 synthesis mechanisms referredto above.
`
`5
`
`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.
`
`10 Although the above-described methods and arrangements for representing audio
`sequences are known to the public at the priority date of the present patent
`application,
`they are not directly applicable
`to ringtone and other audio
`characteristics download services for portable terminal. In the following we describe.
`the method and apparatus according to the invention, making use of the above-
`IS mentioned known concepts at appropriate points.
`
`. . . .;
`
`: ; :
`. .. ;
`·- .
`
`.
`. . .
`. .
`. . .
`.
`. . .
`.
`.
`
`•• ~ r. ·, -.
`
`20
`
`25
`
`30
`
`35
`
`Fig.l illustrates the conceptual composition of a sound packet according to an
`advantageous embodiment of the invention. The sound packet 1 00 comprises a
`score information part 101 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 101. These parameters are most advantageously organized into
`instrument data subparts 105, 1.06 so that each instrument data subpart defines a
`single instrument that may be used to play one or more of the voices defined 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 terminal
`equipment is able to generate a certain UI sound. Because the UI sounds are usually
`
`Verizon Wireless
`Exhibit 1013-0007
`
`
`
`5
`
`10
`
`20
`
`25
`
`30
`
`;
`
`;
`
`e:
`. .
`. . . .
`' .. . .
`- . . .
`
`.
`.
`. . .
`
`..
`
`·' ..
`
`35
`
`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 101 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" defined 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. If the invention is applied only to distribute and download
`ringing tones, the UI sounds part 107 and its subparts 108, 109 are not needed.
`15 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.
`
`•
`
`8 •
`
`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 .
`
`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.
`
`Verizon Wireless
`Exhibit 1013-0008
`
`
`
`•
`
`•
`
`9
`
`5
`
`10
`
`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 defines 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 infinite. It is impossible to
`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
`15 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 define the instruments are transmitted concerning only
`those instruments that are actually needed to perform the chosen pieces of music.
`
`20
`
`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
`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 .
`
`25
`
`30
`
`.
`. '. e.:
`
`'.
`;
`
`;
`
`< .
`
`'
`
`.
`. . .
`.
`. . .
`.
`
`.P ,. -:. ~.
`
`35
`
`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
`
`Verizon Wireless
`Exhibit 1013-0009
`
`
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`e
`
`:
`
`. .
`. : :
`. ,.
`
`" •A " :
`
`35
`
`•
`
`10 •
`
`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
`
`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 information 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
`for the instruments. 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 terminal 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
`
`Verizon Wireless
`Exhibit 1013-0010
`
`
`
`•
`
`•
`
`11
`
`limit the number of sound packets or terminal type blocks in the database, or the
`number of pointer connections between a terminal type block and sound packets.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`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.
`
`Other arrangements 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. I. 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 Ul 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.
`
`Verizon Wireless
`Exhibit 1013-0011
`
`tl
`
`. '
`
`' ' I t •• ~-J
`.
`... . .
`. ..
`...
`... . . ,
`. . .
`., .. . . .
`. . .
`.
`
`·-
`
`t
`
`,
`
`. •;:.·:·
`
`
`
`•
`
`12 •
`
`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 subblocks 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.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`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
`compatibility wizard and sound packet generator block 313 is arranged to
`communicate with a user to find 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 arranged to compose one or more
`sound packets by selecting the appropriate score information part(s) from the score
`information library 301, the appropriate instrument information part(s) from the
`instrument information library 304 and possibly the appropriate UI sounds part(s)
`and/or the appropriate generic audio parts from the corresponding libraries 307 and
`310 respectively. Additionally the compatibility wizard and sound packet generator
`block 313 is arranged to check from the resource requirements analyzer block 315
`that the resource requirements of the sound packet to be assembled do not exceed
`the capabilities of the terminal for which the sound packet is assembled. If the sound
`packet ordered by the user seems to become too complex for the available resources,
`the compatibility wizard and sound packet generator block 313 may be arranged to
`simplify it by e.g. reducing the degree of polyphony, changing wavetable resolution
`from 16 to 8 bits ar adjusting a sampling frequency. Such simplifying may take
`place with the explicit consent of the ordering user or automatically. The
`compatibility wizard and sound packet generator block 313 is also arranged to equip
`the sound packet with a suitable identifier, copyright information and other header
`constituents with the help of blocks 314 and 316.
`Previously we have noted that a score information part corresponds roughly to a
`song book, a score data subpart corresponds to a song in the song book and a score
`data sub-subpart corresponds to the notes of a single voice in the song. In a very
`versatile embodiment following the database architecture of Fig. 3 there could be a
`score data subpart library or "song li~rary" where the score data subparts are stored,
`and a score information part library where the score information parts would only
`consist of links to predetermined score data subparts in the library. The
`compatibility wizard and sound packet generator block 313 would then be arranged
`
`Verizon Wireless
`Exhibit 1 013-0012
`
`..
`· · · ·
`
`• . '.
`
`' ..
`' . '
`
`. ''
`•
`
`>
`
`~ . ..
`. . .
`... . . .
`. . .
`
`
`
`r
`
`•
`
`•
`
`13
`
`to either pick among the already made score information parts or to compose
`customized score information parts on the fly according to an order from a user.
`
`Within the embodiment of Fig. 3 it would be advantageous to include a separate
`header field with e.g. copyright information into each score information part,
`instrument information part, UI sounds part and/or generic audio part, or even to
`every subpart and/or sub-subpart, because otherwise such part-related information
`would be rather difficult to manage.
`
`Fig. 4 illustrates an exemplary method for downloading a sound packet from a
`database according to Fig. 2a or 2b. At step 401 the user initiates the procedure by
`e.g. starting a network browser application in his terminal and asking for a
`connection to a certain network address which he knows to lead to the homepage of
`the sound packet downloading service. At step 402 the terminal performs the
`corresponding action, which in the above-mentioned case means contacting the
`given network address in a way known as such. In Fig. 4 we have assumed that