US 9,088,868 B2
`
`173
`If block 4672 determines the user selected to exit block
`4510 processing, then block 4674 cleans up processing thus
`far accomplished(e.g. issue a stop using database command),
`and block 4676 completes block 4510 processing. If block
`4672 determines the user did not selectto exit, then process-
`ing continues to block 4678 where all other user actions
`detected at block 4616 are appropriately handled, and pro-
`cessing continues back to block 4616 by wayoff off-page
`connector 4696.
`
`FIGS. 47A through 47B depict flowcharts for describing a
`preferred embodiment of MS userinterface processing for
`actions configuration of block 4514. With reference now to
`FIG. 47A,processingstarts at block 4702, continues to block
`4704 for initialization(e.g. a start using database command),
`and then to block 4706 where groupsthe user is a memberof
`are accessed. Block 4706 retrieves all GRPDRs 3540 joined
`to GADRs3520 suchthat the descendanttype field 3520c and
`descendant ID field 3520d match the user information, and
`the ascendanttypefield 3520ais set to Group and the ascen-
`dant ID field 3520 matches the group ID field 3540a. While
`there may bedifferent types of groups as defined for the BNF
`grammar,
`the GRPDR 3540 is a derivative embodiment
`which happens to not distinguish. Alternate embodiments
`may carry a group typefield to select appropriate records by
`group type. Yet another embodiment may not have a block
`4706 with processing at block 4708 for gathering data addi-
`tionally by groups the user is a member of. Block 4706
`continues to block 4708.
`
`Block 4708 accesses all ADRs(e.g. all rows from aADR
`SQL table) for the user of FIG. 47A matching the owner
`information of the ADRs(e.g. user information matchesfield
`37505) to the user and to groups the user is a memberof(e.g.
`group information matches
`field 37505 (e.g. owner
`type=group, owner id=group ID field 3540a from block
`4706). The ADRsare additionally joined (e.g. SQL join) with
`DDRs 3600 and TDRs 3640 (e.g.
`fields 36005 and
`36405=Action and by matching ID fields 3600a and 3640a
`with field 3750a). Description field 3600c can provide a use-
`ful description last saved by theuserforthe action data. Block
`4708 mayalsoretrieve system predefined data records for use
`and/or management. Thereafter, eachjoined entry returned at
`block 4708 is associated at block 4710 with the correspond-
`ing data IDs(at least fields 3750a and 3540a) for easy unique
`record accesses when the user acts on the data. Block 4710
`also initializes a list cursor to pointto the first action item to
`be presented to the user in the list. Thereafter, block 4712 sets
`user interface indication for wherethe list cursor is currently
`set (e.g. set to highlight the entry) and any list scrolling
`settingsare set(thelist is initially not set for being scrolled on
`first FIG. 47A processing encounterto block 4712 from block
`4710. Block 4712 continues to block 4714 wherethe entry list
`is presented to the user in accordance with thelist cursor and
`list scroll settings managed for presentation at block 4712.
`Thereafter, block 4716 waits for user action to the presented
`list of action data and will continue to block 4718 when a user
`action has been detected. Presentation of the scrollable list
`
`preferably presents in an entry format reference-able by the
`list cursor. An action entry presented preferably contains
`ADRfields including owner information; GRPDR owner
`information and group nameif applicable; TDR time spec
`information; and DDR information. Alternate embodiments
`will present less information, or more information(e.g. join
`ADR(s) to PARMDR(s) viafield(s) 3750g).
`If block 4718 determines the user selected to set the list
`
`cursorto a different action entry, then block 4720 sets the list
`cursor accordingly and processing continues back to block
`4712. Block 4712 alwayssets for indicating where the list
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`174
`cursor is currently pointed andsets for appropriately scrolling
`the list if necessary when subsequently presenting the list at
`block 4714. Ifblock 4718 determinesthe user did notselect to
`
`set the list cursor, then processing continues to block 4722. If
`block 4722 determinesthe user selected to add an action, then
`block 4724 accesses a maximum numberofactions allowed
`(perhaps multiple maximum values accessed), and block
`4726 checks the maximum(s) with the number of current
`actions defined. There are many embodiments for what
`deems a maximum(for this user, fora group, for this MS, etc).
`If block 4726 determines a maximum number of actions
`allowed already exists, then block 4728 provides an error to
`the user and processing continues back to block 4712. Block
`4728 preferably requires the user to acknowledge the error
`before continuing back to block 4712. If block 4726 deter-
`mines a maximum wasnot exceeded, then block 4730 inter-
`faces with the user for entering validated action data and
`block 4732 addsthe data record, appropriately updates thelist
`with the new entry, andsets the list cursor appropriately for
`the next list presentation refresh, before continuing back to
`block 4712. If block 4722 determines the user did not wantto
`
`add an action, processing continues to block 4734. Block
`4732 will add anADR, HDR3620(to set creator information)
`and TDR 3640. The DDR and TDRare optionally added by
`the user. Additionally, at block 4730 the user may add new
`PARMDR(s)for theaction.
`If block 4734 determines the user selected to modify an
`action, then block 4736 interfaces with the user to modify
`action data of the entry pointed to by the list cursor. The user
`may change information of the ADR and any associated
`records (e.g. DDR, TDR). The user mayalso add the associ-
`ated records at block 4736. Block 4736 waits for a user action
`indicating completion. Block 4736 will continue to block
`4738 whenthe action is detected at block 4736. If block 4738
`determinesthe user exited, then processing continues back to
`block 4712. Ifblock 4738 determinesthe user selected to save
`
`changes madeat block 4736, then block 4740 updatesthe data
`and the list is appropriately updated before continuing back to
`block 4712. Block 4740 may update the ADR and/or any
`associated records (e.g. DDR and/or TDR)using the action id
`field 3750a (associated to the action item at block 4710).
`Block 4740 will update an associated HDR as well. Block
`4736 may add a new a DDRand/or TDRaspart of the action
`change. If block 4734 determines the user did not select to
`modify an action, then processing continues to block 4752 by
`way of off-page connector 4750.
`With reference now to FIG. 47B, if block 4752 determines
`the user selected to get more details ofthe action (e.g. show all
`joinable data to the ADRthatis not alreadypresented with the
`entry), then block 4754 gets additional details (may involve
`database queries in an SQL embodiment) for the action
`pointed to by the list cursor, and block 4756 appropriately
`presents the informationto the user. Block 4756 then waits for
`a user action that the user is complete reviewing details, in
`which case processing continues back to block 4712 by way
`ofoff-page connector 4798. Ifblock 4752 determinesthe user
`did notselect to get more detail, then processing continues to
`block 4758.
`If block 4758 determines the user selected to delete an
`
`action, then block 4760 determines any data records (e.g.
`CDR(s)) that reference the action data record to be deleted.
`Preferably, no referencing data records (e.g. CDRs) are join-
`able (e.g. field 37004) to the action data record being deleted,
`otherwise the user may improperly delete an action from a
`configured charter. The user should remove ascending refer-
`ences to an action for deletion first. Block 4760 continues to
`block 4762. If block 4762 determines there wasat least one
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0351
`EXHIBIT 1001 - PAGE 0351
`
`

`

`US 9,088,868 B2
`
`175
`CDR reference, block 4764 provides an appropriate error
`with the reference(s) found so the user can subsequently
`reconcile. Block 4764 preferably requires the user to
`acknowledgethe error before continuing back to block 4712.
`If no references were found as determined by block 4762,
`then processing continues to block 4766 for deleting the data
`record currently pointed to by the list cursor. Block 4766 also
`modifiesthe list for the discarded entry, and sets the list cursor
`appropriately for the next list presentation refresh, before
`continuing back to block 4712. Block 4766 will usethe action
`ID field 3750a (associated with the entry at block 4710) to
`delete an action. Associated records (e.g. DDR 3600, HDR
`3620, and TDR 3640)are also deleted (e.g. preferably with a
`cascade delete in a SQL embodiment). If block 4758 deter-
`minesthe user did not select to delete an action, then process-
`ing continues to block 4768.
`If block 4768 determines the user selected to exit block
`
`4514 processing, then block 4770 cleans up processing thus
`far accomplished(e.g. issue a stop using database command),
`and block 4772 completes block 4514 processing. If block
`4768 determines the user did not select to exit, then process-
`ing continues to block 4774 where all other user actions
`detected at block 4716 are appropriately handled, and pro-
`cessing continues back to block 4716 by wayoff off-page
`connector 4796.
`
`FIGS. 48A through 48B depict flowcharts for describing a
`preferred embodiment of MSuser interface processing for
`parameter information configuration ofblock 4518. Withref-
`erence now to FIG. 48A, processing starts at block 4802,
`continues to block 4804 for initialization (e.g. a start using
`database command), and then to block 4806 where groups the
`user is a memberof are accessed. Block 4806 retrieves all
`GRPDRs3540 joined to GADRs 3520 such that the descen-
`dant type field 3520c and descendant ID field 3520d match
`the user information, and the ascendanttypefield 3520ais set
`to Group andthe ascendantID field 3520 matches the group
`ID field 3540a. While there maybe different types of groups
`as defined for the BNF grammar, the GRPDR 3540 is a
`derivative embodiment which happens to not distinguish.
`Alternate embodiments may carry a group typefield to select
`appropriate records by group type. Yet another embodiment
`may not have a block 4806 with processing at block 4808 for
`gathering data additionally by groups the user is amemberof.
`Block 4806 continues to block 4808.
`Block 4808 accesses all PARMDRs(e.g. all rows from a
`PARMDRSQLtable) for the user of FIG. 48A matching the
`owner information of the PARMDRs(e.g. user information
`matches field 37755) to the user and to groups the useris a
`memberof(e.g. group information matchesfield 3775(e.g.
`owner type=group, owner id=group ID field 3540a@ from
`block 4806). The PARMDRsare additionally joined (e.g.
`SQLjoin) with DDRs 3600 (e.g. field 36005=Parameter and
`by matching ID field 3600a with field 3775a). Description
`field 3600c can provide a useful description last saved by the
`user for the parameter data. Block 4808 mayalso retrieve
`system predefined data records for use and/or management.
`Thereafter, each joined entry returned at block 4808 is asso-
`ciated at block 4810 with the correspondingdata IDs(at least
`fields 3775a and 3540a) for easy unique record accesses
`whenthe user acts on the data. Block 4810 also initializes a
`list cursorto point to the first parameter entry to be presented
`to the user in the list. Thereafter, block 4812 sets user inter-
`face indication for where the list cursor is currently set (e.g.
`set to highlight the entry) and anylist scrolling settingsare set
`(the list is initially not set for being scrolled onfirst FIG. 48A
`processing encounter to block 4812 from block 4810). Block
`4812 continues to block 4814 wheretheentry list is presented
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`176
`to the user in accordance with the list cursor and list scroll
`settings managed for presentation at block 4812. ‘Thereafter,
`block 4816 waits for user action to the presented list ofparam-
`eter data and will continue to block 4818 whena useraction
`has been detected. Presentation of the scrollable list prefer-
`ably presents in an entry format reference-able by the list
`cursor. A parameter entry presented preferably containsfields
`for: PARMDRficld 3775c; GRPDR ownerinformation; own-
`ing GRPDRownerinformation and group nameifapplicable;
`and DDR information. Alternate embodiments will present
`less information, or more information (e.g. commands and
`operands parameters may be used with, parameter descrip-
`tions, etc).
`If block 4818 determines the user selected to set the list
`cursorto a different parameterentry, then block 4820 sets the
`list cursor accordingly and processing continues back to
`block 4812. Block 4812 alwayssets for indicating where the
`list cursor is currently pointed and sets for appropriately
`scrolling the list if necessary when subsequently presenting
`the list at block 4814. If block 4818 determines the user did
`not select to set the list cursor, then processing continues to
`block 4822. If block 4822 determinesthe user selected to add
`a parameter, then block 4824 accesses a maximum numberof
`parameter entries allowed (perhaps multiple maximum val-
`ues accessed), and block 4826 checks the maximum(s) with
`the number of current parameter entries defined. There are
`many embodiments for what deems a maximum(forthis user,
`for a group, for this MS, etc). If block 4826 determines a
`maximum number of parameter entries allowed already
`exists, then block 4828 provides an error to the user and
`processing continues back to block 4812. Block 4828prefer-
`ably requires the user to acknowledgethe error before con-
`tinuing back to block 4812. Ifblock 4826 determines a maxi-
`mum was not exceeded, then block 4830 interfaces with the
`user for entering validated parameter data, and block 4832
`adds the data record, appropriately updates the list with the
`new entry, and sets the list cursor appropriately for the next
`list presentation refresh, before continuing back to block
`4812. If block 4822 determinesthe user did not wantto adda
`parameter entry, processing continues to block 4834. Block
`4832 will add a PARMDR, DDR 3600 and HDR3620 (to set
`creator information). The DDR is optionally added by the
`user.
`
`If block 4834 determines the user selected to modify a
`parameter entry, then block 4836 interfaces with the user to
`modify parameter data of the entry pointed to by the list
`cursor. The user may change information of the PARMDR
`and anyassociated records (e.g. DDR). The user may also add
`the associated records at block 4836. Block 4836 waits fora
`
`user action indicating completion. Block 4836 will continue
`to block 4838 when the complete action is detected at block
`4836. If block 4838 determinesthe user exited, then process-
`ing continues back to block 4812. If block 4838 determines
`the user selected to save changes made at block 4836, then
`block 4840 updates the data and the list is appropriately
`updated before continuing back to block 4812. Block 4840
`may update the PARMDRand/or any associated DDR using
`the parameter id field 3775a (associated to the parameter
`entry at block 4810). Block 4840 will update an associated
`HDRaswell. Block 4836 may add a new DDRaspart of the
`parameter entry change. Ifblock 4834 determinesthe user did
`not select to modify a parameter, then processing continues to
`block 4852 by wayof off-page connector 4850.
`With reference now to FIG. 48B, if block 4852 determines
`the user selected to get more details of the parameter entry,
`then block 4854 gets additional details (may involve database
`queries in an SQL embodiment) for the parameter entry
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0352
`EXHIBIT 1001 - PAGE 0352
`
`

`

`US 9,088,868 B2
`
`177
`pointed to by the list cursor, and block 4856 appropriately
`presents the information to the user. Block 4856 then waits for
`a user action that the user is complete reviewing details, in
`which case processing continues back to block 4812 by way
`ofoff-page connector 4898. Ifblock 4852 determinesthe user
`did not select to get more detail, then processing continues to
`block 4858.
`If block 4858 determines the user selected to delete a
`
`parameter entry, then block 4860 determines any data records
`(e.g. ADR(s)) that reference the parameter data record to be
`deleted. Preferably, no referencing data records (e.g. ADRs)
`are joinable (e.g. field 3750g) to the parameter data record
`being deleted, otherwise the user may improperly delete a
`parameter from a configured action. The user should remove
`references to a parameter entry for deletionfirst. Block 4860
`continues to block 4862. If block 4862 determines there was
`
`at least one reference, block 4864 provides an appropriate
`error with the reference(s) foundso the user can subsequently
`reconcile. Block 4864 preferably requires the user to
`acknowledgethe error before continuing back to block 4812.
`If no references were found as determined by block 4862,
`then processing continues to block 4866 for deleting the data
`record currently pointed to bythe list cursor, along with any
`other related records that can be deleted. Block 4866 also
`
`modifies the list for the discarded entry(s), and sets the list
`cursor appropriately for the next list presentation refresh,
`before continuing back to block 4812. Block 4866 will use the
`parameter ID field 3775a (associated with the entry at block
`4810) to delete the parameter entry. Associated records(e.g.
`DDR 3600, and HDR 3620) are also deleted (e.g. preferably
`with a cascade delete in a SQL embodiment). If block 4858
`determinesthe userdid not select to delete a parameter entry,
`then processing continues to block 4868.
`If block 4868 determines the user selected to exit block
`4518 processing, then block 4870 cleans up processing thus
`far accomplished(e.g. issue a stop using database command),
`and block 4872 completes block 4518 processing. If block
`4868 determines the user did not selectto exit, then process-
`ing continues to block 4874 where all other user actions
`detected at block 4816 are appropriately handled, and pro-
`cessing continues back to block 4816 by wayoff off-page
`connector 4896.
`FIGS. 39A, 40A, 41A, 46A, 47A and 48A assume a known
`identity of the user for retrieving data records. Alternate
`embodiments may provide a user interface option (e.g. at
`block 3904/4004/41 04/4604/4704/4804) for whether the user
`wants to use his own identity, or a different identity (e.g.
`impersonate anotheruser, a group, etc). In this embodiment,
`processing (e.g. block 3904/4004/4104/4604/4704/4804)
`would check permissions/privileges for the user (of FIGS.
`39A, 40A, 41A,46A, 47A and/or 48A) for whetheror not an
`impersonation privilege was granted by the identity the user
`wants to act on behalfof. Ifno such privilege was granted, an
`error would be presented to the user. If an impersonation
`privilege was granted to the user, then applicable processing
`(FIGS. 39A&B, FIGS. 40A&B, FIGS. 41A&B, FIGS.
`46A&B, FIGS. 47A&B and/or FIGS. 48A&B) would con-
`tinue in context of the permitted impersonated identity. In
`another embodiment, an impersonation privilege could exist
`from a group to anotheridentity for enforcing who manages
`grants for the group (e.g. 3904/4004/4104/4604/4704/4804
`considers this privilege for which group identity data can, and
`cannot, be managedbythe user). One privilege could govern
`who can manageparticular record data for the group. Another
`privilege can manage who can be maintainedto a particular
`group. Yet another embodiment could have a specific imper-
`sonation privilege for each of FIGS. 39A&B, FIGS. 40A&B,
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`ana
`
`178
`FIGS. 41A&B, FIGS. 46A&B, FIGS. 47A&B and/or FIGS.
`48A&B. Yet another embodiment uses Grantorfield informa-
`
`tion (e.g. fields 3500c and 3500¢) for matching to the user’s
`identity(s) (user and/or group(s)) for processing when the
`choice is available (e.g. in a GDR for permissions and/or
`charters).
`FIGS. 39A, 40A, 414A, 46A, 47A and 48A mayalsoutilize
`VDRs3660 if referenced in any data recordfields ofprocess-
`ing for elaboration to constructs or values that are required at
`a processing block. Appropriate variable name referencing
`syntax, or variable namesreferenced in data record fields, will
`be used to access VDR information for elaboration to the
`
`value(s) that are actually needed in data record information
`when accessed.
`FIG. 49A depicts an illustration for preferred permission
`data 10 processing in the present disclosure LBX architec-
`ture, for example when WDRsare in-process of being main-
`tained to queue 22, or being inbound to a MS(referred to
`generally as “incoming” in FIG. 49A). Table 4920 depicts
`considerations for privilege data (i.e. permission data 10)
`resident at the MSofa first identity ID, (grammar ID/ID-
`Type), depending on privileges granted in the following sce-
`narios:
`
`1) Thefirst identity ID, (Grantor) granting a privilege to a
`second identity ID, (Grantee; grammar ID/IDType), as
`shownin cell 4924: Privilege data is maintained by ID,
`at the ID, MSasis used to govern actions, functionality,
`features, and/or behavior for the benefit of ID,, by a)
`processing ID, WDRinformation at the ID, MS(pref-
`erably, privileges are communicated to ID, MS for
`enforcing and/or cloningthere), b) processing ID, WDR
`information at the ID, MS(privileges locally maintained
`to ID,), and c) processing ID, WDRinformation at the
`ID, MS(privileges locally maintained to ID, );
`2) The first identity ID, (Grantor) granting a privilege to
`himself (Grantee), as shown in cell 4922: Preferably,
`privilege data in this case is not necessary, no configu-
`ration interface is required for this scenario, and an iden-
`tity implicitly has all conceivable privileges assigned to
`himself by default; however, alternatively privileges
`may be appropriate for activating/deactivating function-
`ality;
`3) The secondidentity ID, (Grantor) granting a privilege to
`the first identity (Grantee), as shown in cell 4926: Privi-
`lege data is used for informing ID, (or enabling ID, to
`clone pera privilege) and to govern actions, functional-
`ity, features, and/or behavior for the benefit of ID,, by a)
`processing ID, WDRinformation at the ID, MS (pref-
`erably, privileges are communicated to ID, MS for
`enforcing and/or cloningthere), b) processing ID, WDR
`information at the ID, MS(privileges locally maintained
`to ID,); and c) processing ID, WDRinformation at the
`ID, MS(privileges locally maintained to ID,); and/or
`4) The secondidentity granting a privilege to himself, as
`shownin cell 4928: Preferably,privilege data in this case
`is not necessary, no communications
`interface is
`required for this scenario, and an identity implicitly has
`all conceivable privileges assigned to himselfby default;
`however, alternatively privileges may be appropriate for
`activating/deactivating functionality.
`Table 4940 depicts considerations for privilege data (i.e.
`permission data 10) resident at the MS ofa secondidentity
`ID, (grammar ID/IDType), depending on privileges granted
`in the following scenarios:
`5) A first identity ID, (Grantor) granting a privilege to the
`second identity ID, (Grantee; grammar ID/IDType), as
`shownin cell 4944: Privilege data is used for informing
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0353
`EXHIBIT 1001 - PAGE 0353
`
`

`

`US 9,088,868 B2
`
`179
`ID, (or enabling ID, to clone per a privilege) and to
`govern actions, functionality, features, and/or behavior
`for the benefit of ID,, by a) processing ID, WDRinfor-
`mation at the ID, MS(preferably, privileges are com-
`municated to ID, MS for enforcing and/or cloning
`there), b) processing ID, WDR information at the ID,
`MS(privileges locally maintained to ID,), and c) pro-
`cessing ID, WDRinformationat the ID, MS (privileges
`locally maintained to ID,);
`6) Thefirst identity ID, (Grantor) granting a privilege to
`himself (Grantee), as shown in cell 4942: Preferably,
`privilege data in this case is not necessary, no commu-
`nications interface is required for this scenario, and an
`identity implicitly has
`all
`conceivable privileges
`assigned to himself by default; however, alternatively
`privileges may be appropriate for activating/deactivat-
`ing functionality;
`7) The secondidentity ID, (Grantor) granting a privilege to
`the first identity (Grantee), as shown in cell 4946: Privi-
`lege data is maintained by ID, at the ID, MSasis used to
`govern actions, functionality, features, and/or behavior
`for the benefit of ID,, by a) processing ID, WDRinfor-
`mation at the ID, MS(preferably, privileges are com-
`municated to ID, MS for enforcing and/or cloning
`there), b) processing ID, WDR information at the ID,
`MS(privileges locally maintained to ID,) and c) pro-
`cessing ID, WDRinformationat the ID, MS(privileges
`locally maintained to ID,); and/or
`8) The second identity granting a privilege to himself, as
`shownin cell 4948: Preferably, privilege data in this case
`is not necessary, no configuration interface is required
`for this scenario, and an identity implicitly has all con-
`ceivable privileges assigned to himself by default; how-
`ever, alternatively privileges may be appropriate foracti-
`vating/deactivating functionality.
`FIG. 49B depicts an illustration for preferred charter data
`12 processing in the present disclosure LBX architecture, for
`example when WDRsare in-process of being maintained to
`queue 22, or being inboundto a MS(referred to generally as
`“incoming” in FIG. 49B). Table 4960 depicts considerations
`for charter data resident at the MS ofa first identity ID,
`(grammar ID/IDType), depending on privileges granted in
`the following scenarios:
`1) Thefirst identity ID, (Grantee) owning a charter for use
`at the MSof a second identity ID, (Grantor; grammar
`ID/IDType), as shownin cell 4964: Charter data is main-
`tained by ID, atthe ID, MSfor being candidate use at the
`ID, MSto causeactions, functionality, features, and/or
`behavior, in accordance with configured permission data
`10, for the benefit of either ID, or ID, by a) processing
`ID, WDRinformation at the ID, MS (preferably, char-
`ters are communicated to ID, MSfor use there), and b)
`processing ID, WDRinformation at the ID, MS(pref-
`erably, charters are communicated to ID, MS for use
`there);
`2) The first identity ID, (Grantee) owning a charter for use
`at his own MS, as shown in cell 4962: Charter data is
`maintained locally for local use to cause actions, func-
`tionality, features, and/or behavior, in accordance with
`configured permission data 10, for the benefit of either
`ID, or ID, by a) processing ID, WDRinformation atthe
`ID, MS, and b) processing ID, WDRinformation at the
`ID, MS;
`3) The second identity ID, (Grantee) owning a charter for
`use at the MSofthe first identity ID, (Grantor; grammar
`ID/IDType), as shownin cell 4966: Charter data is used
`at the ID, MSfor informing ID, and enforcing cause of
`
`20
`
`35
`
`40
`
`45
`
`50
`
`55
`
`180
`in
`features, and/or behavior,
`functionality,
`actions,
`accordance with configured permission data 10, for the
`benefit of either ID, or ID, by a) processing ID, WDR
`information at the ID, MS(preferably, charters are com-
`municated to ID, MSfor use there), and b) processing
`ID, WDRinformation at the ID, MS (preferably, char-
`ters are communicated to ID, MSforuse there); and/or
`4) The second identity ID, (Grantee) owning a charter at
`his own MS, as shownin cell 4968: Charter data may be
`communicated to the ID, MSfor informing ID,, allow-
`ing ID, to browse, or allowing ID, to use as a template
`for cloning and then making/maintaining into ID,’s own
`charter, wherein each reason for communicating to the
`ID, MS(orprocessing at the ID, MS) has a privilege
`grantable from ID, to ID,.
`Table 4980 depicts considerations for charter data residentat
`the MS of a second identity ID, (grammar ID/IDType),
`depending on privileges granted in the following scenarios:
`5) Thefirst identity ID, (Grantee) owning a charter for use
`at the MS ofthe secondidentity ID, (Grantor), as shown
`in cell 4984: Charter data is used at the ID, MS for
`informing ID, and enforcing causeofactions, function-
`ality, features, and/or behavior, in accordance with con-
`figured permission data 10, for the benefit of either ID,
`or ID, by a) processing ID, WDRinformationat the ID,
`MS(preferably, charters are communicated to ID, MS
`for use there), and b) processing ID, WDRinformation
`at the ID, MS(preferably, charters are communicatedto
`ID, MSforuse there);
`6) Thefirst identity ID, (Grantee) owning a charter for use
`at his own MS, as shownin cell 4982: Charter data may
`be communicated to the ID, MS for informing ID,,
`allowing ID, to browse, or allowing ID, to use as a
`template for cloning and then making into ID,’s own
`charter, wherein each reason for communicating to the
`ID, MS (or processing at the ID, MS) has a privilege
`grantable from ID, to ID,.
`7) The secondidentity ID, (Grantee) owning a charter for
`use at the MSofthefirst identity ID, (Grantor; grammar
`ID/IDType), as shownin cell 4986: Charterdata is main-
`tained by ID,at the ID, MSfor being candidate useat the
`ID, MSto causeactions, functionality, features, and/or
`behavior, in accordance with configured permission data
`10, for the benefit of either ID, or ID, by a) processing
`ID, WDRinformation at the ID, MS(preferably, char-
`ters are communicated to ID, MSfor use there), and b)
`processing ID, WDRinformation at the ID, MS (pref-
`erably, charters are communicated to ID, MSfor use
`there); and/or
`8) The second identity ID, (Grantee) owning a charter at
`his own MS, as shown in cell 4988: Charter data is
`maintained locally for local use to cause actions, func-
`tionality, features, and/or behavior, in accordance with
`configured permission data 10, for the benefit of either
`ID, or ID, by a) processing ID, WDR informationat the
`ID, MS, and b) processing ID, WDR informationat the
`ID, MS.
`Various embodiments will implement any reasonable sub-
`set of the considerations of FIGS. 49A and 49B, for example
`to minimize or eliminate communicating auser’s permissions
`10 and/or charters 12 to another MS, orto prevent storing the
`same permissions and/or charters data at more than one MS.
`FIGS. 49A and 49B are intended to highlight feasible
`embodiments wherein FIG. 49B terminology “incoming”is
`used generally for referring to WDRsin-process whichare a)
`being maintained (e.g. “incoming” as being maintained to
`
`APPLE
`APPLE
`EXHIBIT 1001 - PAGE 0354
`EXHIBIT 1001 - PAGE 0354
`
`

`

`US 9,088,868 B2
`
`181
`queue 22); and b) incoming to a particular MS(e.g. “incom-
`ing” as being communicated to the MS).
`In one subset embodiment, privileges and charters are only
`maintained at the MS where they are configured for driving
`LBX features and functionality. In another embodiment,
`privileges are maintained at the MS where they were config-
`ured as well as any MSs whicharerelevant for those configu-
`rations, yet charters are only maintained at the MS where they
`are configured. In yet another embodiment, privileges and
`charters are maintained at the MS where they were config-
`ured, as well as any MSs whichare relevant for those con-
`figurations. In another embodiment, a MS maynothaveall
`privileges assigned to itself (said to be assignedto the user of
`the MS) by default. Privileges may require being enabled as
`needed for any users to have the benefits of the associated
`LBX features and functionality. Thus,
`the considerations
`highlighted by FIGS. 49A and 49Bareto “cover many bases”
`with any subset embodiment within the scopeofthe present
`disclosure.
`
`Preferably, statistics are maintained by WITSfor counting
`occurrences of each variety of the FIGS. 49A and 49B pro-
`cessing scenarios. WITS processing should also keepstatis-
`tics for the count by privilege, and by charter, of each appli-
`cable WITS processing event which was affected. Other
`embodiments will maintain more detailed statistics by MS
`ID, Group ID, or other “labels” for categories of statistics.
`Still other embodiments will categorize and maintain statis-
`tics by locations, time, applications in use at time of process-
`ing scenarios, etc. Applicable statistical data can be initialized
`at internalization time to prepare for proper gathering of
`useful statistics during WITSprocessing.
`FIGS. 50A through 50C depict an illustration of data pro-
`cessing system wireless data transmissions over some wave
`spectrum for further explaining FIGS. 13A through 13C,
`respectively. Discussions above for FIGS. 13A through 13C
`are expanded in explanation for FIGS. 50A through 50C,
`respectively. It is well understood that the DLM 200a (FIGS.
`13A and 50A),
`ILM 1000k (FIGS. 13B and 50B) and
`service(s) (FIGS. 13C and 50C) can be capable of communi-
`cating bidirectionally. Nevertheless, FIGS. 50A through 50C
`clarify FIGS. 13A through 13C,respectively, with a bidirec-
`tional arrow showing data flow “in the vicinity” of the DLM
`200a, ILM 10004, and ser