`1855-1930
`
`WK. Richardson
`1859-1951
`
`ATLANTA
`
`AUSTIN
`
`BOSTON
`
`DALLAS
`
`DELAWARE
`
`HOUSTON
`
`MUNICH
`
`NEW YORK
`
`SAN DIEGO
`
`SILICON VALLEY
`
`TWIN CITIES
`
`WASHINGTON, DC
`
`Highlight Business Towers
`Mies van-der-Rohe-Strasse 8
`D-80807 Miinchen
`Deutschland
`
`Telefon
`+49 (89) 710 410 2-0
`
`Faksimile
`+49 (89) 710 410 2-44
`
`Web Site
`www.fr.com
`
`FISH & RICHARDSON P.C.
`
`August 21, 2009
`
`Europaisches Patentamt
`
`80298 Miinchen
`
`Application No.: 96911541.9
`Applicant: Sasial Vehicle Technologies Limited
`Our Ref.: 23576-0003EP1
`
`Responsive to the Communication dated April 15, 2009:
`
`I. New documents
`
`Please find enclosed new claims 1 to 40 which replace - without prejudice -
`
`the set of claims as originally filed. Further, please find enclosed a document
`
`showing the claim amendments.
`
`It is asked to adapt the description after the Examining Division has indicated
`
`that the claims 1neel the requfrements of the EPC
`
`In order to m,ercome the objection in item 2.1 of the Communication dated
`
`April 15, 2009, claim 1 as origina!ly filed has been made dependent on claim
`
`17 as originally filed and claim 35 as originally filed has been made dependent
`
`on clajm 28 as orjginally filed.
`
`In order to overc01ne the objection in item 4 of the Communication dated
`
`April l 5, 2009, claims 24 to 27 have been deleted.
`
`Page 1 of 23
`
`GOOGLE EXHIBIT 1010
`
`
`
`Nev{ claim 1 is based on claim 17 as originally filed. It has merely been
`
`clarified that the current operating code is "'located in the mobile unit'' (see
`
`e.g. description page l, lines 5-6). Further, an obvious mistake has been
`
`co1Tected in that the '-VOrd "the'' has been deleted.
`
`New claim 8 is based on claim 1 as originally filed, v.,foch has been made
`
`dependent on one of mobile unit clajrns 1 to 7. It has merely been clarified that
`
`the patch is ''to be made to current operating code located in thejirst mobile
`
`unit'' (see e.g. description page 10, lines 4-7}
`
`Nev,1 clainl 22 is based on clainl 28 as or1ginally filed. H has merely been
`
`clarified that the step of receivjng is
`
`''through a wireless communication
`
`net:vvork'' and ''at the mobile unit" (see e.g. original claim 1). Fmiher, an
`
`obvious mistake has been corrected in that the redundant vvorcling "to create
`
`the patched operating code,. has been delete,:L
`
`New claim 29 is based on claim 35 as originally filed, \vhich has been made
`
`dependent on one of 1netbod claims 22 to 28. H has 1nerely been clarified that
`
`the step of transmitting is ''to a first mobile unit" (see e.g. description page 12,
`
`lines 11 ~ 13 ), that the patch is ·'to be made to current operating code located in
`
`the jtrst mobile unit'' (see e.g. description page 10, lines 4-7) and that the
`
`communication netvvork is "wireless'' (see e.g. description page 6, line 9).
`
`The dependent claims are originally disclosed as follows:
`
`- ne\v claims 2-7:
`
`cla1rns 18-23 as or1ginally filed, respectively;
`
`- new claims 9-20:
`
`claims 3-14 as originally filed, respectively;
`
`- Tle'vV cla1m 21:
`
`dainl 16 as originally filed;
`
`- new clajrns 23-28:
`
`claims 29-34 as originally fi!ed, respectively:
`
`- ne\v claims 30-35:
`
`claims 37-42 as originally filed, respectively;
`
`- ne\v claim 36:
`
`page 22, tines 33-35:
`
`- new claim 37:
`
`page 22, line 33 - page 23, line 9;
`
`- Tle'vV cla1rn 38:
`
`page 21, lines 1-11;
`
`- nev{ claim 39:
`
`page 10, lines 5 -- 8;
`
`- new- claim 40:
`
`page 9, lines 19-23.
`
`2
`
`Page 2 of 23
`
`
`
`Further, in ne'vv cla1rns 2 lo 7 an obvious rnislake has been corrected in thal the
`
`word ''svstem" has been chang-ed to "mobile unit".
`
`,/
`
`,;,;.,
`
`IL Nevi' prior art
`
`The Applicant has become aware of the follo\ving prior art references which
`
`are here,;vith submitted:
`
`- US 4,9 l 0,5 l O (in the following D3)
`
`- US 5,046,082 (in the folJo,-ving D4).
`
`II L Novelty and Inventive step
`
`1.
`
`The present invent.ion
`
`Ll
`
`Overview
`
`The present invention refrrs to a mobile unit according to claim l and a
`
`method of operating the same according to claim 22.
`
`The rnobj!e unit 22, 24, 26, 28, 30 cornpnses a memory operable to store
`
`current operating code and a receiver 56 operable to receive at least one
`
`discrete patch 1nessage trans1nitled through a \virekss cornnmnication nehvork
`
`12. The at least one discrete patch message defines at least one patch to be
`
`rnade to the current operating code located in lhe mobile unit 22, 24, 26, 28,
`
`30. The mobile unit further comprises a processor 64 - coupled to the memory
`
`and to the receiver 56 - operable to:
`
`- execute the current operating code,
`
`- process the at least one discrete patch message,
`
`- create patched QP.!,T~AtiX!K.rn.~t~ by xmTgJ,gg the .?..tJ~.?.,?.t..9.Xt~ .. P.-~W.h 'vVith
`
`the current operating code, and
`- switch execution to lhe .P.~Jdw\J. operating code.
`
`3
`
`Page 3 of 23
`
`
`
`1.2
`
`Terminology used in the claims
`
`The Applicant is of the opinion that certain terminology used in the claims
`
`deserves further consideration.
`
`a)
`
`The term "operating code'' refers to code executable bv a processor.
`
`"Operating code'' directs the processor to perform certain operations, as
`
`opposed to non-executable data (e.g. configuration parameters, telephone
`
`numbers), which are per se unable to trigger any operation. This is the
`
`conventional interpretation giv·en to "operating code" in cmnputer science,
`
`also consistent \vith the vvording of clajrn 1, in \vhich the processor is operable
`
`"to execute the current operating code., and "to s-i.vitch execution to the
`
`patched operating code'' .
`
`b)
`
`The term "patch" in the context of the claims has to be interpreted as a
`
`portion of operating code which is to be incorporated into the existimr
`fsmT':"2nD .. 9..P.~X.?..Uxg __ q~~k in the mo bile unit, in order to create nevv (patched)
`operating code.
`
`The specification explicitly distinguishes between the term "patching" and the
`
`term "dov,mloading". The term "patching" refers to ·'incorporatingpatches of
`
`code into existing code on the mobile units". The term "downloading" refers to
`
`"replacing the current code in the mobile unit with a new version of code"
`
`(see description page 14, lines 28-35; page 22, lines 29-32).
`
`As a portion of operating code, a patch can have a .~Jl,~t9.X!.1\1:f!c!?.!.Q .... ~.iz~:
`
`(dependent upon the bytes to be incorporated into the current operating code)
`
`and can be inserted into any location within the current operating code, thus
`
`forming a modified operating code \vhicb still needs to be executable (patched
`
`operating code). The patch as such (on its own) has no function, but is only
`
`designed to be incorporated into operating code, in order to thereby create
`
`modified operating code.
`
`4
`
`Page 4 of 23
`
`
`
`In consequence, the ''at least one discrete patch message" contains information
`
`relating to the me1nory AQS.f!J.iqn_ and menlo1y ,?.1.??,~ \vhich needs to be changed
`
`by a particular patch (see as a non-limiting example "patch messages" of Fig.
`
`4; page 15, line 6 - page 17, line 35).
`
`c)
`
`Finally, the term "merging" specifies that the patch is incorporated into
`
`existing (current) code in the mobile unit, without replacing the entire current
`
`operating code - or operating code module, in case the operating code is
`
`designed as a plurality of modules -, but rather modifying the portion(s) of
`
`operating code that need to be changed in order to create new (patched)
`
`operating code.
`
`A non-limiting example of "merging", is described v,lith respect to Fig. 6 (see
`
`page 22, lines 24-29; page 23, line 22 --- page 24, line 27).
`
`1.3
`
`The technical effects
`
`The claimed invenlion teaches patching of operating code located in mobile
`
`units through a wireless communication netv{ork. Patching allows for
`
`substantially less data transmission, since only the data '-Vhich needs to be
`
`modified is transmitted and merged, \vhicb is beneficial jn vie\\" of the typical
`
`constraints of a v-/ireless communication channels (e.g. scarce stability and
`
`limited bandwidth). Thus, the present inventjon combines patching with the
`
`practical benefit of using a wireless communication net'vVork to modify
`
`executable code in the 1nost efficient and streamlined manner,
`
`In practice, the present invention solves the problem of i1nproving the
`
`distribution of new operating code to mobile units.
`
`The inventors realized that the problem can be solved by appropriatelv
`
`transmitting to a mobile unit at least one discrete patch messas-:e defining at
`1r.~,';l.LQ1.W .. Pf:l:tr.h, using a ,;vireless cornrnunicat.ion channeL In this connection,
`
`claim l provides for a receiver operable to receive at least one discrete patch
`
`message - defining at least one patch - and tor a processor operable to process
`
`5
`
`Page 5 of 23
`
`
`
`the at least one discrete patch message. Thus, claim 1 provides for an interface
`·?.JJ!J?.l?.1.Y.. .... d.~,iign~.d. ... J-~,\L .. .th~ .... .tt?.X1,i1J!j.tw4 .... ~.'.m~tf.h:.'.
`information of the at least one discrete patch message. Then, the processor
`
`(receiver plus processor)
`
`achieves patching of operating code located in the mobile unit by merging the
`
`patch with the current operating code.
`
`Moreover, the dajrned inventjon also provides for changjng operating code
`
`(code executable by a processor) by merging. Merging operating code imposes
`
`rnuch more difficulties than simply changing non-executable data ( e.g. vvhen
`
`simply reconfiguring parameters). It is essential that, after changing the
`
`operating code in the 1nobik unit, the changed (patched) operating code is still
`
`executable by the processor. Othervvise, the 1.vhole fimctioning of the mobile
`
`unit ,vould be corrupted which \Vould render the mobile unit unusable, In
`
`contrast thereto, changing non-executable data (e.g. configuration parameters,
`
`or telephone numbers) only requires that the new data satisfies fonnat
`
`constraints in order lo still be readable by the processor executing the
`
`operating code.
`
`In the following it 'vVill be shown that none of the prior art references discloses
`
`the inventive concept of patching operating code located in mobile units
`
`through a \vireless communication net\Cvork.
`
`Noveltv and inventive §tep of claim 1
`
`The suhject~matter of claim 1 is new and involves an inventive step for at least
`
`the tolknving reasons.
`
`2. l
`
`N oveJtv in view of D 1
`
`D 1 (EP-A-0459 344) relates to dmvnloading of a software to a mobile phone.
`
`In order to fully understand the teaching of D l, one has to in particular take
`
`into account that the priority date of D l is in the year 1990, the very starting
`
`6
`
`Page 6 of 23
`
`
`
`phase of the distribution of mobile phones. Dl discusses prior ari in ·,yhich the
`
`sof-hvare is classically slored 1n a ROM of a mobile phone (vvh1ch data cannot
`
`be changed). Thus, for changing a sofr,yare it was necessary to bring the
`
`mobile phone to a company branch and to replace the components (see col. 1,
`
`lines 23-31 of D 1}
`
`D 1 discusses an article from 1988 which mentions that the 11et1.vork protocols,
`
`the services and the access capability could be dovmloaded into a mobile
`
`lelecomnmnicalion device, D 1 mentions that lhis solution is not well adapled
`
`for mobile devices which frequently traverse a frontier behveen t\vo territories
`
`in vvhich the communication protocols are di{-ferenL Each download would
`
`require a certajn delay which js unpleasant for the user (see coL 1, ljnes 32-46
`
`of D 1 ). A first object of D 1 is thus to provide a device v1hich allows to
`
`download the operating software, but which allo\Cvs also to change frequently
`
`from one operating soft\vare to another without delay (see coLL lines 47-52 of
`
`Dl),
`
`The mobile phone 9 according lo the firsl solution of D 1 (see Fig, 1)
`
`comprises a plurality of RA.Ms L 2 (which data can be changed) for storing
`
`multiple operating softvvares and means to read-select one of the RiQ,,1s 1,2
`
`fi::lr executing only one of the sofrwares (see col. 2, lines 4-15; co L 4, lines 1-7;
`
`claim l of Dl), Accordingly, the device allows to change the operating
`
`software \Cvjthout having to dmvnload each time. Upon a change of the
`
`network, simply one of the RAMs 1,2 needs to he selected, if the software has
`
`already been do,;vnloaded before (see col. 2, lines 4-25 of D 1}
`
`In particular, D 1 discloses - in the first solution - a mobile phone 9 bnked by
`
`radio to a base station 8 connected to a radjotelephone network 7 by a classic
`
`interface 5 for communication bet\veen the mo bile phone 9 and the base
`
`station 8. The classic jnterface .5
`
`is also used to dovvnload an operating
`
`sofhvare in one of the two memories 1, 2 (see col. 2, lines 4-15: col. 3, lines
`
`36-39; Fig. 1; claim 1 of DI). The mobile phone 9 further comprises a
`
`microprocessor 4 which executes a downloading software stored in a ROM 3
`
`(see coL 2, lines 4-15; col. 3, lines 44-46; Fig. 1: clainl 1 of D 1) and means 4
`
`7
`
`Page 7 of 23
`
`
`
`to write-select one of the RA.Ms 1,2 for downloading a different sofb.vare in
`
`each oflhe RAMs L2 (see col. 2, lines 4-15; col. 4, bnes 1-6; Fig, 1; claim J
`
`ofDl).
`
`Each operating software can comprises multiple modules (see coL 4, lines 32-
`
`38; coL 5, lines 9-14 of Dl). However, a "sofhvare module'' is a code entity
`
`having a predefined memory location and memory size, due to the fact that it
`
`is designed to perform a predefined function. A sofhvare module is clearly not
`
`a "patch" (having a customizable size that can be inserted into any location
`
`\vithin the current operating code, not having any function as such).
`
`The strbject-matter of claim 1 differs from the disclosure in D 1, 1.vhich is
`
`regarded as closest p1ior art document, at least in:
`
`·'a receiver (56) onerable to receive at least one discrete patch
`rnessage transmitted through a wireless comnnmication netvvork (J 2),
`'. , ... YJ d J; 0
`·•to{,, t ·,
`ti ' ·t l"·N'
`,, '
`·t 1·,,
`·•{
`•t·
`. '' .:{,. '""Of'J ,-
`U: a. ,;;,J5 Ufk u,su,., t 1)atu, nu::S.klf;,t c.t1,nmJ;, (L. .. s:fd,~, .. Q!.!J,.Pi:1:..,~.,L.L
`,i"
`be nwde to the current overating code located in the mobile unit (22,
`]4, 26, ]8. 30) ,,
`
`y
`
`.
`
`and
`
`and
`
`''the processor (64) operable[..) to process the at least one discrete
`patch rnessage ··
`
`'
`'
`.
`' I
`. ··4•
`" "
`J d
`to Q:?:P.f.f'..P.Qf.9. .. iJL .. .QP.f'.mJmg_rQJW oy
`tl1e processor ( o ) operatJie 1 . "
`r
`}
`merging the at feast one patch 1vith the current operating code, and to
`switch execution to the patched operating code."
`
`a)
`
`D 1 does not disclose rece1 vmg at !east one discrete patch message
`
`defining at least one patch to be made to current operating code.
`
`D l explicitly refors to "dovmloading'' (in French: ''t6lechargement''). A .. s
`
`explained alK)iie, there is a decisii,-e difference bet.ween "patching'' and
`
`"dmvnloading". The term ''dovmloading" refers to receiving a complete entity
`
`of code of a prefixed men10ry size for "replacing the current code in the
`
`mobi!e unit \vith a new version of code", 1.vhereas the receiver as defined in
`
`8
`
`Page 8 of 23
`
`
`
`claim l is designed for receiving a patch message, i.e. a specific type of
`
`message ,;vh1ch defines the "patch(es)" to be incorporated into existing code
`
`on the mobile units.
`
`Dl at no pojnt discloses "patching'' of current operating code. To the contrary,
`
`Dl explicitly refors to ''downloading" of a nev>/ version of operating code to
`
`replace the current operating code. For example, in col. 5, lines 14-18 ofD1 it
`
`is stated that "once dovmloading is completed, the localization procedure is
`
`finished'' and "the mobile phone is then in possess1on of all the information
`
`required to operate in the ne\v zone'' (see co L 4, lines 49~55 of D 1). This
`
`means, aJler do,;vnloading, the mobile phone is in possession of the new
`
`operating sofrware for that particular ne\v zone. Thus, a new operating
`
`software version is being dmvnloaded according to the teaching of D 1.
`
`As explained above, in D 1, each operating sofhvare can comprise multiple
`
`modules. In other -,vords, D1 provides a solution of a modular sofr\vare d1vided
`
`into a plurality of predefined
`
`functional modules. Accordingly,
`
`the
`
`dO'vvnloading can be "partial, for certain functions, or total, for all functions,
`
`except the localization and downloading'' (see col. 5, lines 5~9 of Dl). This
`
`simply means that either only certain modules or all modules of the operating
`
`sofr1vare can be do1vnloaded, except for the localization module and the
`
`downloading module (see col. 4, lines 8-13 of Dl).
`
`The "downloading'' of a certain module (''partial downloading'') of operating
`
`sof-hvare is hO'vvever not "patch1ng'' of current operating code. As explained
`
`above, a ''software module'' is a code entity having a predefined memory
`
`location and 1nemory size, due to the fact that 1s designed to perfonn a
`
`predefined fimction. /\ sofiware module is clearly not a "patch'' (having a
`
`customizable size that can be inserted into any location within the cun-ent
`
`operating cock not having any function as such).
`
`In particular, refrffing to col. 4, line 47 to coL 5, line 18, D1 teaches that when
`
`the mobile phone enters into a new zone, the mobile phone transmits data
`
`("Loe Upd Request'' message) comprising a parameter ("Classmark Update"
`
`9
`
`Page 9 of 23
`
`
`
`parameter) which indicates the mobile phone model (in French: "version
`
`d'rndiotel6phone"). This 111 turn indicates if the mobile telephone is adapted to
`
`accept partial or total download (see col. 5, lines l-9 of D 1 ). Thus, the fact if
`
`the mobile telephone is adapted to accept partial or total dov-mload is prefixed
`
`for a specific mobile phone model. Accordingly, the location and size of the
`
`memory in the mobile unit that is to be changed is prefixe,:L Consequently,
`
`"partial downloading" referred to jn DJ is not "patching" of current operating
`
`code.
`
`In the same way, also the statement in D l reforring to ''the distribution of
`
`corrections of a sofhvare, or the entire replacement of a sofhvare" (see coL 5,
`
`lines 38-40), merely refers to the ''do1vnloading" of either certain modules or
`
`all modules of the operating softvvare and cannot be read inforentially to mean
`
`"patching".
`
`b)
`
`Dl does not disclose creating patched operating code by n.wrnixtg the at
`
`least one patch 'vVith the current operating code.
`
`Contrmy to the statement in item 3.1 of the Communication dated April l 5,
`
`2009, it is not "directly and unambiguously derivable ±i-0111 D l that, in case of
`
`a
`
`''partial dmvnload", the "certain functions'' are merged \\iith current
`
`operating code.
`
`As explained above, D l merely discloses that either certain modules or all
`
`modules of the operating software can be downloaded, which is P.I':°2.fi?.<:!,~~,t and
`
`depends on the particular mobile phone model. In consequence, in the solution
`
`ofD1 there silnply .9.f:l:1.WQ.L];'.~~--fUJ.Wigi.rtg with the current operating code, since
`
`entire, predefined modules are do1vnloaded.
`
`Furthermore, it should be noted that DJ discloses a system in which operating
`
`software is dovvnloaded into RA.Jvis 1,2 (see col. 3, lines 42--43 of Dl), which
`data can be changed, but \vhich are also ygJ~Ul.~ __ nWU!9.T:ic~f;l,. This is in contrast
`
`to the prior art discussed in D 1 in which the operating sofhvare is stored in a
`
`ROM, \vhich data cannot be changed and ,vhich is a non-volatile memory. 1n
`
`10
`
`Page 10 of 23
`
`
`
`the solution of D l, only the downloading sofhvare is stored in a ROM 3 (see
`
`coL 3, lines 44-46). 1n consequence, upon each reset of the mob1le phone, the
`
`RAMs l ,2 are empty and a ne,.v operating software has to be downloaded
`
`using the dovvnloading softv>/are stored in R0I\t1 3. This is also explained in
`
`col. 4, tines 14-21 of D1, in that "vvhen no operating sofhvare js present in the
`
`RA._Ms, the ,vrite-selection is instructed by the microprocessor 4 according to
`
`the instructions of the downloading soft\vare'' and ''the downloading sothvare
`
`supplies instrnctions to allow the mobile phone to set up a radio link, then
`
`dm,vnloading a sofhvare via this link''. ln consequence, in the solut1on of Dl
`
`there simply cannot he a merging- with the current operating code, since the
`
`RAMs are ernpty upon each reset,
`
`c)
`
`D l does not disclose a receiver operable to receive at least one discrete
`
`patch message and a processor operable to process the at least one discrete
`
`patch message. Accordingly, D l does not disclose an interface suitably
`
`designed. for. transmitted .. '"patch ''. infonnation.
`
`To the contrary, Dl explicitly states that the ~J~~:?.i,~...i.D1.~!1!:l:£~. 5 1s simple and
`less costly and that there is thus no need for an additional interface (see coL 3,
`
`line 30-37; coL 5, line 28-34 of Dl\ Consequently, the classic interface of Dl
`
`is simply not an jnterface suitah!e to receive and process at least one discrete
`
`patch message, and not an interface suitably designed for transmitted "patch"
`
`inforrnatjon.
`
`2.2
`
`Novelty in vkw of D2
`
`D2 (US-A-155847) refers to a system 10 to upgrade software used in remote
`
`computer systems 12 from a central computer system 14 (see col. 3, lines 27-
`
`28; Fig. 1 ofD2).
`
`D2 has already been discussed in the background section of the present patent
`
`application (see page 1). As stated therein, D2 discloses:
`
`11
`
`Page 11 of 23
`
`
`
`''[..}a central cornputer system that can rnonitor and record change.s
`to versions cif soft11i1ire. A user having a j?xed remote system operating
`an old version o_(softvvare nwy access the central cmnputer systen1, {f
`changes are applicable to the softv,;are used by the rernote .system, the
`central computer system can provide pmches to the remote :,ystem jar
`updating the software. Hovvever, the system disclosed by US. Patent
`•• J""'n -- t· -,
`·- "·«·mn ,. -·,t /~ ,. c,,J fr·c· -·,t1·c;n ,. th ·st· c1c·c· "', ... Cl
`,v ·
`:: I 'i 'i N. '7 --fi ,·c·l'J ,. 0
`r.,,,. U.t.,, .) _ _,f1'.:°'tH>1.
`!VU ..... r-' ..
`,. ,, ~'2.,,i'~•
`,.
`!-<-,.,,. t ,,~ .. }
`,, !-<,, . ., .tAt:'.U t.,j ~(A, . . ,, , .. (,{,.
`.......... -'._.q,
`central cornputer :,ystem over an on-line communication link that
`interactive and bidirectional communication. 11ze remote
`allows
`.~ystems participate in a single. continuous cmnmw"!.ication session that
`is terminated q(ter the remote user receives the appropriate patches. ,.
`
`The subject-matter of claim l differs from the disclosure in D2, at least in:
`
`·'a mobile unit.,
`
`and
`
`and
`
`"a receiver (56) operable.to..receive.atJeast.one .. discretepatch
`message transrnitted through a wireless communication netrvork (12),
`the at least one discrete patch rnessage defining at least one patch to
`be made to the current operating code located in the nwbile unit (22,
`24) .,
`
`''the processor (64) operable [..) to process the at least one discrete
`patch message .
`
`a)
`
`D2 does not disclose a "mobile unit''. D2 refers to fixed remote
`
`computers.
`
`b)
`
`Consequently, D2 also does not disclose "a ,vireless communication
`
`netvvork'', but merely a fixed computer network.
`
`c)
`
`The re1not.e computers of D2 silnply do not have a "receiver operable
`
`to recerve at
`
`least one discrete patch message
`
`through a wireless
`
`co1rnnunication net'vvork" and a "processor operable to process the at. least one
`
`discrete patch message". To the contrary, the data transmission is achieved by
`
`"handshaking" behveen the central computer and the remote computer (see
`
`col. 2, lines 45-47 of D2).
`
`In particular, D2 does not disclose a receiver operable to receive at least one
`
`discrete patch message and a processor operable to process the at least one
`Q/iE.Ir.t~ patch message. Accordingly, D2 does not disclose an interface
`
`12
`
`Page 12 of 23
`
`
`
`(receiver and processor) suitablv desim1ed for discrete patch messag-es
`
`tI~X),~T_Y)jJ_~~~Q_JbX9..\!gh .. ?. .. lY..tr~)-~,~$. .. ~.9.Imn.~1.Dci.~~f:l:ti9.,D .. n.i;;_~:\Y.Qik-
`
`23
`
`Novelty in view of DJ
`
`D3
`
`( US 4,910,510) discloses a one-way
`
`selective call messagrng
`
`communication system (paging system), in 'vVhich the central transmission
`
`stalion is capable of using sev·eral different signaling fonnats to lransmit
`
`information to a large population of paging receivers (see col. 5, lines 41-48 of
`
`D3). The paging receiver device comprises a receiver 32 for detecting and
`
`demodulating sjgnals transmitted from a remote location over a radio
`
`frequency communication link (see coL 4, lines 62-65 of D3). The output of
`
`the receiver 32 js coupled to an microcomputer controller 36 which stores the
`
`firrmvare in a memory p01tion thereof (see col. 6, lines 11-27 of D3\ The
`
`microcomputer controller 36 controls the ov·erall decoding operation (see col.
`
`6, lines 50-53 of D3).
`
`The paging receiver device further comprises (see col. 6, lines 29-36; Fig. l of
`
`D3):
`
`- a reprogrammable non-volatile system change program memory 4(L
`
`- a reprogrammable non-volatile reserved vvord memory 42,
`
`- a permanent receiver unit jdentification memory 44,
`
`- a reprogrammable non-volatile receiver system program memory 46,
`
`- a te1nporary memory 48 and
`
`- a reprogrammable non-volatile address code mem01y 50
`
`When a system or unit change command signal is received, the microcomputer
`
`controller 36 stores the nevv data in the temporary memory 48 and then
`
`transfers the data to the appropriate non-volatile memory 40, 42 , 46 or 50.
`
`Thus, memory programming logic 52 under the control of microcomputer
`
`conlroller 36 is used for accessing the non-volatile 1nemories 40, 42, 46 and 50
`
`for the purpose of reprogramming them 'vVith data stored in tempora1y memory
`
`48 (see col, 7, lines 25-43 of D3), The memory programming logic 52 acts to
`
`13
`
`Page 13 of 23
`
`
`
`enable the programming mode of the particular mem01y 40, 42, 46 or 50, and
`
`further prepares the memory 40, 42, 46 or 50 to receive tK~\V data into a
`
`specified region of the memory map (see col. 8, lines 20-30 of D3).
`
`The subject-matter of clajrn 1 djffern from the disdosure in D3, at least in:
`
`"a receiver r56) operable to receive at feast one discrete patch
`message transmitted through a ,vireless communication network (12),
`the at least one discrete patch message defining at least one patch to
`be made WJb.?:..GP.T?:.r!LQPf!.JUing_rQ.dr:. located in the mobile unit (22,
`24) .,
`
`"the processor (64) operable[. .J to process the at feast one discrete
`patch rnessage,
`
`and
`
`and
`
`"the processor (64) operable[. . .] to create patched operating code by
`mr:.r.gfrxg the at least one patch with the current operating code. and to
`switch execution to the patched operating code. ,.
`
`a)
`
`D3 does not disclose rece1vmg at least one discrete patch message
`
`defining at least one patch to he made to current operating code.
`
`H has to be noted that D3, having a priority m the year 1987, discloses a
`
`pagmg system using several different signaling
`
`formats
`
`to
`
`transmit
`
`infonnation to paging receivers. Signaling fonnats in paging systenls are
`
`predefined, namely defined by specific parameters (such as timer values, bit
`
`rate etc.). Thus, the data stored in the regions of paging system program
`
`memory 46 (see e.g. Fjg_ 6 of DJ) is simply parameter values fbr decoding a
`
`specific signaling format. D3 discloses "reprogramming'' of paging system
`
`program me1nory 46, ,vhich is simply a "reconfiguration'' of the para1neter
`
`values stored therein.
`
`At the priority date of D3 in l 987, the term ''reprogramming" 'vVas used
`
`synonymously v-/ith the term "reconfiguration". A ''reconfiguration" (replacing
`
`parameters of prefixed size and location) is very different fonn "patching''
`
`(incorporating a patch of customizable size that can be inserted into any
`
`location 1.vithin the current operating code).
`
`14
`
`Page 14 of 23
`
`
`
`Accordingly, the rnernory !9.\~;iJjQJ!, and rnerno17 ,?.iZf that is to be changed in
`
`the memory 46 in the paging receiver device of D3 is prefixed. Thus, D3 does
`
`not disclose ''patching" of current operating code.
`
`b)
`
`In connection thereto, the data stored in memory 46 of D3 is parameter
`
`va!ues, and not "operating code'' (code directly executable by a processor, as
`
`explained above).
`
`In D3 the output of the receiver 32 is coupled to the microcomputer controller
`
`36. The finnware of the paging rece1ver device is stored in a memory portion
`
`of the microcomputer controller 36 {see coL 6, !ines 11-27 of D3 ). The
`
`microcomputer controller 36 controls the m.,erall decoding operation. In
`
`particular (see col. 6, lines 50-67 of D3):
`
`"Thejimction of the microcontroller 36 is to take the derived selective
`call message infhrmation from receiver 32 and process it according to
`tho
`//o('(i/;;,.;o
`J:(,)"">··•1,1t
`()/' tho P"'('(>//it·'O
`Don(··n,,J/o,;,-,·
`f)!"'O(·-fofpr»1;1·w1--f
`t
`.,,t>
`.,,t> ~.,.rf,-->~trc,,
`I\~.5A,1t.f.,,..,,_l-,
`.,
`r,r.t.; .• ,.
`~.'.,l~ .. ~_,(J!.,.t;,:,~.,,f, ~i;>,,_.Ur.,1.,b,
`systern, the microcomputer control/er 36 may be utilized as the main
`decoding tool. [. . .] In normal operation, the microcmnputer controller
`36 is responsive to the irifbrmation contained in .'(VSten1 program
`memmJ' 46 [. . .] ''.
`
`Thus, the "operating code'' of the device 1.n D3 1s stored rn 1nicrocomputer
`
`controller 36, not in memory 46.
`
`Even though D3 refors to ''the signaling decoding algorithm" or ''software
`
`information" contained in mem017 46 (see col. 6, line 68 - coL 7, line 4 ofD3)
`
`or ''instructions for decoding the new signaling system are programmed into
`
`the paging system program memory 46" (see col. 8, lines 4-8 of D3), it
`
`becomes clear from the overall disclosure of D3 that this simply refers to the
`
`parameter values of the signaling format stored in predefined reg10ns of
`
`men10ry46.
`
`c)
`
`D3 does not disclose creating patched operating code by ffW.Igi.-gg the at
`
`least one patch with the current operating code.
`
`15
`
`Page 15 of 23
`
`
`
`As explained above, D3 merely djscloses reconfiguration of parameter values
`
`for decoding a specific signaling format.
`
`In particular, D3 discloses that, 'vVhen the end of data is detected, the ne,.v data
`
`is decoded and 'vVritten into lhe respective region of 1nernory 46 (see coL 20,
`
`lines 22-25,
`
`ljnes 32-35,
`
`lines 43-46,
`
`lines 54-56; Fig.
`
`lOE of D3).
`
`Accordingly, the respective region of memory 46 of fixed size is completely
`
`replaced vvith the nevv data. Consequently, in the solution of D3 there is
`
`simplv no "merging" with cmTent operating code.
`
`d)
`
`Furthermore, D3 does not disclose a receiver operable to recerve at
`
`least one discrete patch 1nessage and a processor opernble __ to __ process the at
`
`least one discrete patch message. Accordingly, D3 does not disclose an
`
`interface suitably designed for transmitted "patch" infonnation.
`
`2A
`
`Novelty in view of D4
`
`D4 (US 5,046,082) discloses a syslern for aJlo,-ving re1note access to cellular
`
`telephones. Host IO is coupled to a PSTN 12 and a cellular system 16 is
`
`coupled to the PSTN 12 (see col. 5, lines 45-55; Fig. 1 of D4). Renlotely
`
`accessible cellular telephones (RACTs) 22 communicate to host 10, 1.vhere
`
`"remotely accessible"
`
`refers
`
`to
`
`remote computerized access
`
`to data
`
`programming of RA.CT (see col. 5, ljnes 59-65 of D4). The RA.CT 22
`
`comprises a non-volatile memory 82 (EEPROM) for storing operational data.
`
`This operational data is for exmnple the "nmnber assignment modules
`
`(NAMs)'', which include parameters that configure the operational features of
`
`lhe RA.CT 22 (see col. 8, lines 35- 48, clailn 1 of D4).
`
`The subject-matter of claim l differs from the disclosure in D4, at least in:
`
`·'a receiver (56) operable to receive at least one discrete patch
`message transmitted through a ,vireless communication net1vork (! 2),
`-
`-
`U: a. ,;;,J5 Ufk u,su,., t 1)atu, nu::S.klf;,t c.c1 ,nmJ;, q ____ s::_~LLQ!.!.{.Pi:1:..,~.,! .... c
`". , ... YJ d J, 0
`·•to{,, t ·,
`ti ' ·t 1···N
`y ·t 1···N
`•t·
`. ,, .:/{. -"•ot·J ,-
`•t·
`·' '
`,i"
`
`.
`
`16
`
`Page 16 of 23
`
`
`
`be rnade to the current cmeratinr' code located in the mobile unit (22,
`]4) ..
`
`"the processor (64) operable[..} to process the at least one discrete
`patch message.
`
`and
`
`and
`
`"the processor (64) operable[".] to (r.f.t~N.Pf?t(b:f.d. __ QQfti!:li.lJ.g(X!!!f by
`rnerging the at least one patch vvith the current operating code, and to
`svvitch execution to the patched operating code. "
`
`a)
`
`D4 does not disclose rece1vmg at least one discrete patch message
`
`defining at least one patch to be made to current operating code.
`
`As explained above, D4 discloses "programming" of opera