US 8,639,267 B2
`
`224
`either by multiple send threads for FIG. 75A processing, FIG.
`75A loop processing on a channellist, and/or passing channel
`information to send processing feeding from queue 24. If
`FIG. 75A does not transmit directly over the channel(s) (i.e.
`relies on send processing feeding from queue 24), an embodi-
`ment may provide means for communicating the channel for
`broadcast/send processing wheninterfacing to queue 24(e.g.
`incorporate a channel qualifier field with send packet inserted
`to queue 24).
`In any case, see detailed explanations of FIGS. 13A
`through 13C,as well as long range exemplifications shown in
`FIGS. 50A through 50C, respectively. Processing begins at
`block 7502, continues to block 7504 wherethe caller param-
`eter(s) passed to FIG. 75A processing (e.g. action for remote
`execution, or command for remote execution) are used for
`sending at least one data packet containing properly format-
`ted data for sending, and for being properly received and
`interpreted. Block 7504 may reformat parametersinto a suit-
`able data packet(s) format so the receiving MS can process
`appropriately (see FIG. 75B). Depending onthe present dis-
`closure embodiment, any reasonable supported identity (ID/
`IDType) is a valid target (e.g. as derived from a recipient or
`system parameter). Thereafter, block 7506 waits for an
`acknowledgement from the receiving MSif the communica-
`tion embodiment in use utilizes that methodology. In one
`embodiment, the send data packet is an unreliable datagram
`that will mostlikely be received by the target MS. In another
`embodiment, the send data packet1s reliably transported data
`which requires an acknowledgementthat it was received in
`goodorder.In any case, block 7506 continues to block 7508.
`Block 7504 formats the data for sending in accordance
`with the specified delivery method, along with necessary
`packet information (e.g. source identity, wrapper data, etc),
`and sends data appropriately. For a broadcast send, block
`7504 broadcasts the information (using a sendinterface like
`interface 1906) by inserting to queue 24so that send process-
`ing broadcasts data 1302 (e.g. on all available communica-
`tions interface(s) 70), for example as far as radius 1306, and
`processing continues to block 7506. The broadcast is for
`reception by data processing systems (e.g. MSs)in the vicin-
`ity of FIGS. 13A through 13C,as further explained by FIGS.
`50A through 50C whichincludes potentially any distance.
`The targeted MS should recognizethatthe data is meantforit
`and receives it. For a targeted send, block 7504 formats the
`data intended for recognition by the receiving target. In an
`embodiment wherein usual MS communications data 1302 of
`
`223
`6154 ensures each parameteris in a ready to use form to be
`processed with the command and operand. Each parameter
`results in embodimentsofa data value, a data value resulting
`from an expression, a data reference (e.g. pointer), or other
`embodiments well known in the art of passing parameters
`(arguments)to a function, procedure,or script for processing.
`Thereafter, ifblock 6156 determines the REMOTEvariable is
`set to No (i.c. “No” equals a value distinguishable from any
`Host specification for having the meaning of “No Host Speci-
`fication”), then processing continuesto block 6158 where the
`ExecuteAction procedure of FIG. 62 is invoked with the
`command, operand and parameters of the action in process.
`Upon return from the procedure of FIG. 62, processing con-
`tinues back to block 6126 for any remaining charteractions.
`If block 6156 determines the REMOTEvariable is set to a
`Host for running the action, then processing continues to
`block 6160 for preparing send data procedure parameters for
`performing a remote action (of the command, operand and
`parameters), and then invoking the send data procedure of
`FIG. 75A for performingthe action at the remote MS(also see
`FIG. 75B). Processing then continues back to block 6126. An
`alternate embodiment will loop on multiple BNF grammar
`Host specifications for multiple invocations of the send data
`procedure (1.e. when multiple Host specifications are sup-
`ported). Another embodimentto FIG. 61 processing permits
`multiple actions with a single Host specification.
`Referring back to block 6128, if it is determinedall current
`charter actions are processed, then processing continues to
`block 6104 for any next charter to process. Referring back to
`block 6106, if it is determined all charters have been pro-
`cessed, processing terminates at block 6164.
`Depending on various embodiments, there may be obvious
`error handling in FIG. 61 charter parsing. Preferably, the
`charters were reasonably validated prior to being configured
`and/or previously processed/parsed(e.g. FIG. 57 processing).
`Also, TimeSpec and/or MSRelevance information may be
`used in FIG. 61 so that charter part processing occurs only in
`oneplace (i.e. FIG. 61 rather than FIG. 57) to achieve better
`MS performance by preventing more than one scan over
`charter data. Some embodiments of FIG. 61 maybethe single
`place where charters are eliminated based on privileges,
`TimeSpecs, MSRelevance, or any other criteria discussed
`with FIG. 57 for charter elimination to improve performance
`(i.e.a single charter parse when needed). Third party MSs (1.e.
`those that are not represented by the in-process WDRandthe
`MSof FIG. 57 processing) can be affected by charter actions
`the MSis altered to contain CK 1304 forlistening MSs in the
`(e.g. via Host specification, privileged action, privileged fea-
`vicinity, send processing feeding from queue 24, caused by
`ture, etc).
`block 7504 processing, will place information as CK 1304
`Preferably, statistics are maintained throughout FIG. 61
`embedded in usual data 1302 at the next opportune time of
`processing for how charters were processed, which charters
`sending usual data 1302. As the MS conducts its normal
`becameeffective, why they becameeffective, which com-
`communications, transmitted data 1302 contains new data
`mands were processed(e.g. invocation of FIG. 62), etc.
`CK 1304 to be ignored by receiving MS other character 32
`With reference now to FIG. 75A,depictedis a flowchart for
`processing, but to be foundby listening MSs within thevicin-
`describing a preferred embodiment of a procedure for send-
`ity which anticipate presence of CK 1304. Otherwise, when
`ing data to a remote MS, for example to perform a remote
`LN-Expanse deployments have not introduced CK 1304 to
`action as invoked from block 6162. FIG. 75Ais preferably of
`
`linkable PIP code 6. The purposeis for the MS of FIG. 75A usual data 1302 communicated onareceivable signal by MSs
`processing (e.g. a first, or sending, MS) to transmit data to
`in the vicinity, FIG. 75A sends/broadcasts new data 1302.
`other MSs (e.g. at least a second, or receiving, MS), for
`Block 7506 waits for a synchronous acknowledgementif
`example an action (command, operand, and any para-
`applicable to the send ofblock 7504 until either receiving one
`meter(s)), or specific processing for a particular command
`or timing out. Block 7506 will not wait if no ack/responseis
`(e.g. Send atomic command). Multiple channels for sending,
`anticipated, in which case block 7506 sets status for block
`or broadcasting should be isolated to modular send process-
`7508 to “got it”. If a broadcast was made, one (1) acknowl-
`ing (feeding from a queue 24). In an alternative embodiment
`edgement may beall that is necessary for validation, or all
`having multiple transmission channels visible to processing
`anticipated targets can be accounted for before deeming a
`of FIG. 75A (e.g. block 6162), there can be intelligence to
`successful ack. Thereafter, ifblock 7508 determines an appli-
`drive each channel for broadcasting on multiple channels,
`cable ack/response wasreceived (1.e. data successfully sent/
`
`55
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0376
`EXHIBIT 1001 - PAGE 0376
`
`20
`
`40
`
`45
`
`

`

`US 8,639,267 B2
`
`225
`received), or none wasanticipated (i.e. assume gotit), then
`processing continues to block 7510 tor potentially processing
`the response. Block 7510 will process the responseif it was
`anticipated for being received as determined by data sentat
`block 7504. Thereafter, block 7512 performs logging for
`success (e.g. to LBX History 30). Ifblock 7508 determines an
`anticipated ack was not received, then block 7512 logs the
`attempt(c.g. to LBX history 30). An alternate embodimentto
`block 7514 will log an error and may require a user action to
`continue processing so a user is confirmed to have seen the
`error. Both blocks 7512 and 7514 continue to block 7516
`where the caller (invoker) is returned to for continued pro-
`cessing (e.g. back to block 6162).
`With reference now to FIG. 75B, depictedis a flowchart for
`describing a preferred embodimentof processing for receiv-
`ing execution data from another MS,for example action data
`for execution, or processing ofa particular atomic command
`for execution. FIG. 75B processing describes a Receive
`Execution Data (RxED) process workerthread, and is of PIP
`code 6. There may be many workerthreads for the RxED
`process, just as described for a 19xx process. The receive
`execution data (RxED) process is to fit identically into the
`frameworkofarchitecture 1900 as other 19x processes, with
`specific similarity to process 1942 in that there is data
`received from receive queue 26, the RxED thread(s) stay
`blocked on the receive queue until data is received, and a
`RxED worker thread sends data as described (e.g. using send
`queue 24). Blocks 1220 through 1240, blocks 1436 through
`1456 (and applicable invocation of FIG. 18), block 1516,
`block 1536, blocks 2804 through 2818, FIG. 29A, FIG. 29B,
`and any other applicable architecture 1900 process/thread
`frameworkprocessing is to adapt for the new RxED process.
`For example, the RxED process is initialized as part of the
`enumerated set at blocks 1226 (e.g. preferably next to last
`memberofset) and 2806 (e.g. preferably second member of
`set) for similar architecture 1900 processing. Receive pro-
`cessing identifies targeted/broadcasted data destined for the
`MSof FIG. 75B processing. An appropriate data formatis
`used, for example using X.409 encoding of FIGS. 33A
`through 33C for some subset of data packet(s) received
`wherein RxEDthread(s) purpose is for the MS of FIG. 75B
`processing to respond to incoming data. It is recommended
`that validity criteria set at block 1444 for RKED-Maxbeset as
`high aspossible (e.g. 10) relative performance considerations
`of architecture 1900,
`to service multiple data receptions
`simultaneously. Multiple channels for receiving data fed to
`queue 26 are preferably isolated to modular receive process-
`ing.
`In an alternative embodiment having multiple receiving
`transmission channels visible to the RxED process, there can
`be a RxED workerthread per channelto handle receiving on
`multiple channels simultaneously. If RkED thread(s) do not
`receive directly from the channel, the preferred embodiment
`of FIG. 75B would not need to convey channel information to
`RxEDthread(s) waiting on queue 24 anyway. Embodiments
`could allow specification/configuration of many RxED
`thread(s) per channel.
`ARXEDthread processing beginsat block 7552, continues
`to block 7554 where the process worker thread count RxED-
`Ct is accessed and incrementedby 1 (using appropriate sema-
`phore access (e.g. RKED-Sem)), and continues to block 7556
`for retrieving from queue 26 sent data (using interface like
`interface 1948), perhaps a special termination request entry,
`and only continues to block 7558 whena record of data(e.g.
`action for remote execution, particular atomic command, or
`termination record) is retrieved. In one embodiment, receive
`processing deposits data as record(s) to queue 26. In another
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`226
`embodiment, XMLis received and deposited to queue 26, or
`some other suitable syntax is received as derived from the
`BNF grammar. In another embodiment, receive processing
`receives data in one format and deposits a more suitable
`format for FIG. 75B processing.
`Block 7556 stays blocked onretrieving from queue 26 until
`data is retrieved, in which case processing continues to block
`7558. If block 7558 determines a special entry indicating to
`terminate was not found in queue 26, processing continues to
`block 7560. There are various embodiments for RxED
`
`thread(s), RxCD thread(s), thread(s) 1912 and thread(s) 1942
`to feed off a queue 26 for different record types, for example,
`separate queues 26A, 26B, 26C and 26D,or a thread target
`field with different record types found at queue 26 (e.g. like
`field 2400a). In another embodiment,
`there are separate
`queues 26D and 26E for separate processing of incoming
`remote action and send commanddata. In another embodi-
`
`thread(s) 1912 are modified with logic of RxED
`ment,
`thread(s) to handle remote actions and send commanddata
`requests, since thread(s) 1912 are listening for queue 26 data
`anyway.In yet another embodiment,there are distinct threads
`and/or distinct queues for processing each kind of an atomic
`commandto FIG. 75B processing(i.e. as processed by blocks
`7578 through 7584).
`Block 7560 validates incoming data for this targeted MS
`before continuing to block 7562. A preferred embodimentof
`receive processing already validated the data is intended for
`this MS by having listened specifically for the data, or by
`having already validatedit is at the intended MSdestination
`(e.g. block 7558 can continuedirectly to block 7564 (no block
`7560 and block 7562 required)). Ifblock 7562 determines the
`data is valid for processing, then block 7564 checksthe data
`for its purpose (remote action or particular command). If
`block 7564 determines the data received is for processing a
`remote action, then block 7566 accesses source information,
`the command, the operand, and parameters from the data
`received. Thereafter, block 7568 accessesprivileges for each
`ofthe remote action parts (command,operand, parameters) to
`ensure the source has properprivileges for running the action
`at the MS of FIG. 75B processing. Depending on embodi-
`ments, block 7568 may include evaluating the action for
`elaborating special terms and/or expressionsas described for
`FIG.61 (blocks 6140 through 6154), although the preferred
`embodimentpreferably already did that prior to transmitting
`the remote action for execution (e.g. remote action already
`underwentdetailed privilege assessment). However, in some
`embodiments where privileges are only maintained locally,
`the action processing of FIG. 61 processing would be
`required at block 7568 to check privileges where appropriate
`in processing the action. In such embodiments, FIG. 61 would
`process local actions as disclosed, but would not process
`actions known to be for remote execution (i.e. Host specifi-
`cation) since a FIG. 75B embodiment would include FIG.61
`processing for performing privilege check processing to
`determine that
`sufficient privileges are granted. Thus,
`dependingonthe present disclosure embodiment, block 7568
`mayincludelittle privilege verification, no privilege verifica-
`tion, or may include all applicable action privilege verifica-
`tion discussed already in FIG. 61.
`In yet another embodiment, special terms processing of
`FIG.61 can be delayed until FIG. 75B processing (e.g. block
`7566 continues to a new block 7567 which continuesto block
`7568). It may be advantageousto have new block 7567 elabo-
`rate/evaluate special terms at the MS of FIG. 75B processing
`in some embodiments. In a further embodiment, a syntax or
`qualifier can be usedto differentiate where to perform special
`term elaboration/evaluation.
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0377
`EXHIBIT 1001 - PAGE 0377
`
`

`

`US 8,639,267 B2
`
`227
`Thereafter, if block 7570 determines the action for execu-
`tion is acceptable (and perhapsprivileged, or privileged per
`source, or there was no check necessary), then block 7572
`invokes the execute action procedure of FIG. 62 with the
`action (command,operand, and any parameter(s)), completes
`at block 7574 an acknowledgementto the originating MS of
`the data received at block 7556, and block 7576 sends/broad-
`casts the acknowledgement(ack), before continuing back to
`block 7556 for the next incoming execution request data.
`Block 7576 sends/broadcasts the ack (using a sendinterface
`like interface 1946) by inserting to queue 24 so that send
`processing transmits data 1302, for example as far as radius
`1306. Embodiments will use the different correlation meth-
`ods already discussed above, to associate an ack with a send.
`If block 7570 determines the data is not acceptable/privi-
`leged, then processing continues directly back to block 7556.
`For security reasons, it is best not to respond with an error.It
`is best to ignore the data entirely. In another embodiment, an
`error may be returned to the sender for appropriate error
`processing andreporting.
`Referring back to block 7564, if it is determined that the
`execution data is for processing a particular atomic com-
`mand, then processing continues to block 7578. Block 7578
`accesses the command(e.g. send), the operand, and param-
`eters from the data received. Thereafter, block 7580 accesses
`privileges for each of the parts (command, operand, param-
`eters) to ensure the source has properprivileges for running
`the atomic command at the MS of FIG. 75B processing.
`Depending on embodiments, block 7580 may include evalu-
`ating the command for elaborating special
`terms and/or
`expressions as described for FIG. 61 (blocks 6140 through
`6154), although the preferred embodimentpreferably already
`did that prior to transmitting the command for execution.
`However, in some embodiments where privileges are only
`maintainedlocally, the privilege processing of FIG. 61 would
`be required at block 7580 to check privileges where appro-
`priate in processing the command. In such embodiments,
`FIG. 61 would process local actions as disclosed, but would
`not process actions known to be for remote execution (i.e.
`Host specification) since a FIG. 75B embodiment would
`include FIG. 61 processing for performing privilege check
`processing to determinethatsufficientprivileges are granted.
`Thus, depending on the present disclosure embodiment,
`block 7580 may includelittle privilege verification, no privi-
`lege verification, or may includeall applicable action privi-
`lege verification discussed already in FIG. 61.
`In yet another embodiment, special terms processing of
`FIG. 61 can be delayed until FIG. 75B processing(e.g. block
`7566 continues to anew block 7567 which continuesto block
`
`7568). It may be advantageousto have new block 7567 elabo-
`rate/evaluate special terms at the MS of FIG. 75B processing
`in some embodiments. In a further embodiment, a syntax or
`qualifier can be usedto differentiate where to perform special
`term elaboration/evaluation.
`
`Thereafter, if block 7582 determines the command (Com-
`mand, Operand, Parameters) for execution is acceptable (and
`perhaps privileged, or privileged per source, or there was no
`check necessary), then block 7584 performs the command
`locally at the MS of FIG. 75A processing. Thereafter, block
`7586 checks if a response is needed as a result of command
`(e.g. Find command)processing at block 7584. If block 7586
`determines a responseis to be sentbackto the originating MS,
`7574 completes a response to the originating MSofthe data
`received at block 7556, and block 7576 sends/broadcasts the
`response, before continuing back to block 7556 for the next
`incoming execution request data. Block 7576 sends/broad-
`casts the response containing appropriate commandresults
`
`20
`
`40
`
`45
`
`55
`
`228
`(using a send interface like interface 1946) by inserting to
`queue 24 so that send processing transmits data 1302, for
`example as far as radius 1306. Embodiments will use the
`different correlation methods already discussed above,
`to
`associate a response with a send.
`If block 7586 determines a responseis not to be sent back
`to the originating MS, then processing continues directly
`back to block 7556. If block 7582 determines the data is not
`
`then processing continues back to
`acceptable/privileged,
`block 7556. For security reasons,it is best not to respond with
`an error. It is best to ignore inappropriate (e.g. unprivileged,
`unwarranted) data entirely. In another embodiment, an error
`may be returnedto the senderfor appropriateerror processing
`and reporting.
`Blocks 7578 through 7584 are presented generically so that
`specific atomic commanddescriptions below provide appro-
`priate interpretation and processing. The actual implementa-
`tion may replace blocks 7578 through 7584 with program-
`ming case statement conditional execution for each atomic
`command supported.
`Referring back to block 7562, if it is determined that the
`data is not valid for the MS of FIG.75 processing, processing
`continues back to block 7556. Referring back to block 7558,
`if a worker thread termination request was found at queue 26,
`then block 7586 decrements the RxED worker thread count
`
`by 1 (using appropriate semaphore access (e.g. RkKED-Sem)),
`and RxEDthread processing terminates at block 7588. Block
`7586 may also check the RxED-Ct value, and signal the
`RxEDprocess parent thread that all worker threadsare ter-
`minated when RxED-Ct equals zero (0).
`Block 7576 causes sending/broadcasting data 1302 con-
`taining CK 1304, depending on the type of MS, wherein CK
`1304 contains ack/response information prepared. In the
`embodimentwherein usual MS communications data 1302 of
`
`the MSis altered to contain CK 1304 forlistening MSs in the
`vicinity, send processing feeding from queue 24, caused by
`block 7576 processing, will place ack/response information
`as CK 1304 embeddedin usual data 1302 at the next oppor-
`tune time of sending usual data 1302. As the MS conducts its
`normal communications, transmitted data 1302 contains new
`data CK 1304to be ignored by receiving MSother character
`32 processing, but to be found by listening MSs within the
`vicinity which anticipate presence of CK 1304. Otherwise,
`when LN-Expanse deployments have not introduced CK
`1304 to usual data 1302 communicated ona receivable signal
`by MSs in the vicinity, FIG. 75B sends/broadcasts new ack/
`response data 1302.
`In an alternate embodiment, remote action and/or atomic
`commanddata records contain a sent date/time stamp field of
`when the data was sent by a remote MS, and a received
`date/time stampfield (like field 2490c) is processed at the MS
`in FIG. 75B processing. This would enable calculating a
`TDOA measurement while receiving data (e.g. actions or
`atomic command) that can then be usedfor location determi-
`nation processing as described above.
`For other acceptable receive processing, methodsare well
`known to those skilled in the art for “hooking” customized
`processing into application processing of sought data
`received, just as discussed with FIG. 44B above (e.g. mail
`application, callback function API, etc). Thus, there are well
`known methodsfor processing data in context of this disclo-
`sure for receiving remote actions and/or atomic command
`data from an originating MSto a receiving MS, for example
`when using email. Similarly, as described above, SMS mes-
`sages can be used to communicate data, albeit at smaller data
`exchangesizes. The sending MS maybreak uplarger portions
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0378
`EXHIBIT 1001 - PAGE 0378
`
`

`

`US 8,639,267 B2
`
`229
`of data which can be sent as parse-able textto the receiving
`MS. It may take multiple SMS messages to communicate the
`data in its entirety.
`those
`Regardless of the type of receiving application,
`skilled in the art recognize many clever methodsfor receiving
`data in context of a MS application which communicatesin a
`peer
`to peer
`fashion with another MS (e.g. callback
`function(s), API interfaces in an appropriate loop which can
`remain blocked until sought data is received for processing,
`polling knownstorage destinations of data received, or other
`applicable processing). FIGS. 75A and 75B are an embodi-
`ment of MS to MS communications, referred to with the
`acronym MS2MS.
`FIG. 62 depicts a flowchart for describing a preferred
`embodimentof a procedure for performing an action corre-
`sponding to a configured command, namely an ExecuteAc-
`tion procedure. Only a small number of commandsareillus-
`trated. The procedure starts at block 6202 and continues to
`block 6204 where parameters ofthe Command, Operand, and
`Parameters are accessed (see BNF grammar), depending on
`an embodiment (e.g. parameters passed by reference or by
`value). Preferably, FIG. 62 procedure processing is passed
`parameters by reference(i.e. by address) so they are accessed
`as needed by FIG. 62 processing. Block 6204 continues to
`block 6206.
`If it is determined at block 6206 that the action atomic
`
`command is a send command,then processing continues to
`block 6208 where the send command action procedure of
`FIG. 63A is invoked. The send commandaction procedure is
`invoked with parameters including the passed parameters of
`Operand and Parameters discussed for block 6204. Upon
`return from the send commandaction procedure, block 6208
`continues to block 6256. Block 6256 returns to the calling
`block of processing (e.g. block 6158) that invoked FIG. 62
`processing. If block 6206 determines the action atomic com-
`mandis not a send command, then processing continues to
`block 6210. If it is determined at block 6210 that the action
`atomic commandis a notify command,then processing con-
`tinues to block 6212 where the notify commandaction pro-
`cedure of FIG. 64A is invoked. The notify command action
`procedure is invoked with parameters including the passed
`parameters of Operand and Parameters discussed for block
`6204. Upon return from the notify command action proce-
`dure, block 6212 continues to block 6256. If block 6210
`determines the action atomic commandis not a notify com-
`mand, then processing continues to block 6214. If it is deter-
`mined at block 6214 that the action atomic command is a
`
`compose command, then processing continues to block 6216
`where the compose commandaction procedure of FIG. 654
`is invoked. The compose command action procedure is
`invoked with parameters including the passed parameters of
`Operand and Parameters discussed for block 6204. Upon
`return from the compose commandaction procedure, block
`6216 continues to block 6256. If block 6214 determines the
`
`action atomic command is not a compose command, then
`processing continues to block 6218. If it is determined at
`block 6218 that the action atomic command is a connect
`
`command,then processing continuesto block 6220 where the
`connect commandaction procedure of FIG. 66A is invoked.
`The connect command action procedure is invoked with
`parameters including the passed parameters of Operand and
`Parameters discussed for block 6204. Upon return from the
`connect commandaction procedure, block 6220 continues to
`block 6256. If block 6218 determines the action atomic com-
`
`mandis nota connect command,then processing continues to
`block 6222. If it is determined at block 6222 that the action
`
`atomic commandis a find command,then processing contin-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`230
`ues to block 6224 where the find commandaction procedure
`of FIG. 67A is invoked.‘The find command action procedure
`is invoked with parameters including the passed parameters
`of Operand and Parameters discussed for block 6204. Upon
`return from the find commandaction procedure, block 6224
`continues to block 6256. If block 6222 determines the action
`atomic command is not a find command, then processing
`continuesto block 6226. Ifit is determined at block 6226 that
`the action atomic command is an invoke command, then
`processing continues to block 6228 where the invoke com-
`mandaction procedure of FIG. 68A is invoked. The invoke
`command action procedure is invoked with parameters
`including the passed parameters of Operand and Parameters
`discussed for block 6204. Upon return from the invoke com-
`mandaction procedure, block 6228 continues to block 6256.
`Ifblock 6226 determinesthe action atomic commandis not an
`
`invoke command,then processing continues to block 6230. If
`itis determined at block 6230 that the action atomic command
`is a copy command,then processing continues to block 6232
`where the copy command action procedure of FIG. 69A is
`invoked. The copy command action procedure is invoked
`with parameters including the passed parameters of Operand
`and Parameters discussed for block 6204. Upon return from
`the copy commandaction procedure, block 6232 continues to
`block 6256. If block 6230 determines the action atomic com-
`mandis not a copy command, then processing continues to
`block 6234. If it is determined at block 6234 that the action
`
`atomic command is a discard command, then processing
`continues to block 6236 where the discard commandaction
`procedure of FIG. 70A is invoked. The discard command
`action procedure is invoked with parameters including the
`passed parameters of Operand and Parameters discussed for
`block 6204. Upon return from the discard commandaction
`procedure, block 6236 continues to block 6256. Ifblock 6234
`determines the action atomic command is not a discard com-
`
`mand, then processing continues to block 6238. If it is deter-
`mined at block 6238 that the action atomic commandis a
`move command, then processing continues to block 6240
`where the move commandaction procedure of FIG. 71A is
`invoked. The move command action procedure is invoked
`with parameters including the passed parameters of Operand
`and Parameters discussed for block 6204. Upon return from
`the move commandaction procedure, block 6240 continues
`to block 6256. If block 6238 determines the action atomic
`commandis not amove command,then processing continues
`to block 6242. Ifit is determinedat block 6242 that the action
`
`atomic commandis a store command, then processing con-
`tinues to block 6244 where the store commandaction proce-
`dure of FIG. 72A is invoked. The store command action
`
`procedure is invoked with parameters including the passed
`parameters of Operand and Parameters discussed for block
`6204. Upon return from the store commandaction procedure,
`block 6244 continuesto block 6256. Ifblock 6242 determines
`the action atomic command is not a store command, then
`processing continues to block 6246. If it is determined at
`block 6246 that the action atomic command is an administrate
`
`command,then processing continuesto block 6248 wherethe
`administrate command action procedure of FIG. 73A is
`invoked. The administrate command action procedure is
`invoked with parameters including the passed parameters of
`Operand and Parameters discussed for block 6204. Upon
`return from the administrate command action procedure,
`block 6248 continuesto block 6256. Ifblock 6246 determines
`the action atomic commandis not an administrate command,
`then processing continues to block 6250. If it is determinedat
`block 6250 that the action atomic command is a change
`command,then processing continuesto block 6252 where the
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0379
`EXHIBIT 1001 - PAGE 0379
`
`

`

`US 8,639,267 B2
`
`231
`change command action procedure of FIG. 74A is invoked.
`‘The change command action procedure is invoked with
`parameters including the passed parameters of Operand and
`Parameters discussed for block 6204. Upon return from the
`change commandaction procedure, block 6252 continues to
`block 6256. If block 6250 determines the action atomic com-
`mandis not a change command,then processing continues to
`block 6254 for handling other supported action atomic com-
`mands on the MS. There are many commandsthat can be
`implemented on a MS. Block 6254 continues to block 6256
`for processing as already described. FIGS. 60 through 62
`describe action processing for recognized events to process
`WDRs.
`
`FIGS. 63A through 74C document a MStoolbox of useful
`actions. FIGS. 63A through 74C are in no way intended to
`limit LBX functionality with a limited set of actions, but
`rather to demonstrate a starting list of tools. New atomic
`commandsand operands can be implemented with contextual
`“plug-in” processing code, API plug-in processing code,
`commandline invoked plug-in processing code, local data
`processing system (e.g. MS) processing code, MS2MSplug-
`in processing code, or other processing, all of which are
`described below. The “know how” of atomic commandsis
`
`preferably isolated for a variety of “plug-in” processing. The
`charter and privilege platform is designed for isolating the
`complexities of privileged actions to “plug-in” methods of
`newcode (e.g. for commands and/or operands) wherever
`possible.
`Together with processing disclosed above, provided is a
`userfriendly developmentplatform for quickly building LBX
`applications wherein the platform enables conveniently
`enabled LBX application interoperability and proce