SYSTEM AND METHOD FOR MAINTAINING AND UPDATING DATA OBJECTS ASSOCIATED WITH MOBILE ELECTRONIC DEVICES

Abstract

A system and method for maintaining and updating data objects associated with mobile electronic devices is provided. In an embodiment, a data object manager engine receives data representing a first electronic device and a second electronic device. The data object manager engine is configured to update a data object associated with the second electronic device that links to a data object associated with the first electronic device. Usage metrics adjustments in one data object used to make usage metric adjustments in the second data object.

Description

FIELD

The present specification relates generally to communication networks and more particularly relates to a system and method for maintaining and updating data objects associated with mobile electronic devices.

BACKGROUND

It is known for telecommunication infrastructure to maintain data objects associated with mobile electronic devices that are provisioned to communicate via that telecommunication infrastructure. Each data object for each device is typically, though not always, maintained in relative isolation to the other data objects for the other devices. In one context it is known to link data objects for a pool of devices that have a relation to each other, so that the devices in the pool can be administered together for purposes of tracking and allocating a block of air-time (or other usage parameter) that is to be split between each device in the pool, so as to track an aggregate usage for the pool of devices. However, there are further technical efficiencies and improvements to be gained in the maintenance and updating of these data objects.

SUMMARY

An aspect of the specification provides a method for updating data objects associated with electronic devices comprising:

receiving instructions to adjust a first data object; said first data object maintained an association with a first electronic device; said first data object comprising a reference to a second data object associated with a second electronic device; said first data object further comprising at least one usage metric associated with said first electronic device; said instructions comprising an adjustment to said at least one usage metric;

accessing said first data object;

performing a first adjustment to said at least one usage metric in said first data object in accordance with said instructions;

accessing said second data object identified within said first data object; said second data object further comprising at least one usage metric associated with said second electronic device;

performing a second adjustment to at least one usage metric associated with said second data object; said second adjustment based on said first adjustment.

The at least one usage metric associated with said first electronic device or the at least one usage metric associated with said second electronic device can be a usage limit. The second adjustment can be an increase to the usage limit associated with said second data object. The increase can be based on a percentage of an increase to said usage limit associated with said first adjustment.

The at least one usage metric associated with said first electronic device or said at least one usage metric associated with said second electronic device can be an actual usage.

The second adjustment can be a decrease to said actual usage associated with said second data object.

The decrease can be based on a percentage of an increase to said actual usage associated with said first adjustment.

The at least one usage metric associated with said first electronic device or said at least one usage metric associated with said first electronic device can be associated with a particular service that is available from either said first electronic device or said second electronic device. The service can comprises at least one of voice, messaging and data services. The data service can comprise one or more of web browsing, emails, streaming audio or video media, SMS messages, multi-media messages, or chat service. The units for the usage metric can be expressed in terms of one or more of minutes, seconds, currency, bytes, data sessions, data blocks, or the like. The data blocks or data sessions can comprise a song, a ring tone, or movie, or some other multi-media event or service.

The first data object can be associated with said first electronic device by means of an absolute identifier. The second data object can also be associated with said second data object by means of an absolute identifier. The absolute identifier can be a International Mobile Equipment Identity (IMEI).

The first data object can be associated with said first electronic device by means of a relative identifier. The second data object can also be associated with said second data object by means of a relative identifier. The relative identifier can be at least one of an International Mobile Subscriber Identity (IMSI) and Mobile Systems International Subscriber Identity Number (MSISDN).

Another aspect of the specification comprises a data object management engine for updating data objects associated with electronic devices comprising a processor configured to receive instructions to adjust a first data object. The first data object is maintained in a data server connected to said processor. The first data object is associated with a first electronic device. The first data object comprises a reference to a second data object associated with a second electronic device. The first data object is maintained in said data server. The first data object further comprises at least one usage metric associated with said first electronic device. The instructions comprise an adjustment to said at least one usage metric. The processor is further configured to access said first data object and to perform a first adjustment to said at least one usage metric in said first data object in accordance with said instructions. The processor is further configured to access the second data object identified within said first data object. The second data object further comprises at least one usage metric associated with said second electronic device. The processor is further configured to perform a second adjustment to at least one usage metric associated with said second data object, the second adjustment being based on said first adjustment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic representation of a system for maintaining and updating data objects associated with mobile electronic devices.

FIG. 2 shows a schematic representation of the data object manager engine of FIG. 1.

FIG. 3 shows an example structure and contents of data objects maintained in the system of FIG. 1.

FIG. 4 shows a flow-chart depicting a method of maintaining and updating data objects associated with electronic devices.

FIG. 5 shows further exemplary structure and contents of data objects maintained in the system of FIG. 1 in conjunction with the method of FIG. 4.

FIG. 6 shows a flow-chart depicting another method of maintaining and updating data objects associated with electronic devices.

FIG. 7 shows further exemplary structure and contents of data objects maintained in the system of FIG. 1 in conjunction with the method of FIG. 4.

FIG. 8 shows further exemplary structure and contents of data objects maintained in the system of FIG. 1 in conjunction with the method of FIG. 4.

FIG. 9 shows further exemplary structure and contents of data objects maintained in the system of FIG. 1 in conjunction with the method of FIG. 4.

FIG. 10 shows another exemplary structure and contents of an enhanced data object that can be maintained in the system of FIG. 1.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Referring now to FIG. 1, a system for maintaining and updating data objects associated with mobile electronic devices is indicated generally at 50. System 50 comprises a plurality of electronic devices 54-1, 54-2 . . . 54-n (generically, electronic device 54, and collectively, electronic devices 54. This nomenclature is used elsewhere herein) that are connectable to a core network 62 via a one or more respective base stations 66-1, 66-2, . . . 66-n (generically, base station 66, and collectively, base stations 66. This nomenclature is used elsewhere herein). In a present embodiment each electronic device 54 is mobile and is configured to employ a wireless link 70 between each respective electronic device 54 and each base station 66-1, 66-2 and 66-n, specifically as shown in FIG. 1 or according to any other connections based on the location and structure of a particular base station 66 and device 54. Any known appropriate backhaul links 74-1, 74-2, 74-n can be used between base station 66 and core network 62. Collectively, links 70, base stations 66 and backhauls 74 comprise a mobile network 68.

Core network 62 generally comprises network infrastructure (including gateways) that is compatible with the protocols supported by base stations 66 and links 74, and can, if desired, additionally support other protocols such as those normally supported by the public switched telephone network (PSTN), the Internet, and/or any other types of circuit or packet switched networks.

A data object manager engine 82 is connected to core network 62 by one or more appropriate gateways 80. Data object manager engine 82 also connects to a data object server 86, which can be directly incorporated into data object manager engine 82 or can be a stand-alone server. Data object server 86 is configured to maintain and update a plurality of data objects 108-1, 108-2 . . . 108-n, which are respective to each device 54-1, 54-2 . . . 54-n. Data objects 108 can be implemented using any now-known, future-conceived or otherwise desirable data structures, including data records, data files, eXtended Markup Language (XML) files etc.

Core network 62 also includes business support systems and operational support systems that are complementary to the management, rating, billing, operations, maintenance, and provisioning of services provided to subscriber S via electronic device 54, base stations 66, and links 74. Such business support system (BSS) and operational support systems (OSS) are discussed further below as OSS BSS servers 96. Collectively, links 70, base stations 66, and backhaul links 74, and core network 62 comprise a mobile network 68. The hashed-boxes in FIG. 1 labelled with reference character 68 represent that the components within those hashed-boxes are all components within mobile network 68.

Engine 82 also connects to one or more OSS BSS servers 96-1, 96-2, . . . 96-n (generically, OSS BSS server 96, and collectively, OSS BSS servers 96). OSS BSS server 96 can be based on a service control point (SCP) or the like in the prepaid context, or it can be based on a billing server utilizing customer detail records (CDR), or the like in the post-paid context, or OSS BSS server 96 can be based on combinations or enhancements thereof. In general, OSS BSS 96 are configured to maintain and process rating, billing, and usage information relative to subscriber S or device 54. Engine 82 can connect to OSS BSS servers 96 directly via a number of interfaces and protocols including application programming interfaces (API's) or the receipt of event records (e.g. call detail records) in a manner that is native to each of those servers, so that no modification to those OSS BSS servers is required.

System 50 also comprises a provisioning engine 90 which can be based on known or future-conceived automated or manual provisioning technologies. Provisioning engine 90 is thus configured to undertake steps to actually provision each device 54 for operation on network 68. Such provisioning includes obtaining absolute identifiers such as International Mobile Equipment Identity (IMEI) for each device 54, and associating or assigning relative identifiers such as an International Mobile Subscriber Identity (IMSI) or a Mobile Systems International Subscriber Identity Number (MSISDN) to each device 54. Such provisioning can also include establishing usage limits and the like, as discussed further below in relation to object 108.

If desired, data object server 86 can be implemented as part of a profile server 84 (or in a generic sense, a data server). Thus, in addition to, or as part of objects 108, such a profile server 84 can contain other device 54 data (e.g. subscriber associations, language preferences, subscribed features or applications, capabilities and features of the device 54), usage data (e.g. usage records pertaining to services used by the subscriber S or device 54), or contextual data (e.g. state of the subscriber in a given application (e.g. current progress information in a given game, location information in various geodetic formats, generic presence and state information (e.g. on-line, off-line, available, busy, do-not-disturb, happy, sad). Those skilled in the art will understand that a subset of the information contained in profile server 84 can be applicable to or directly linked to the information contained in a profile, respective to each data object 108 and each device 54. Engine 82 can access and modify data respective to each device 54 (including data respective to a subscriber associated with each device) that is resident in profile server 84 in order to correct or modify the provisioned state of a given device 54 (including a state respective to a subscriber associated with each device 54) via a variety of protocols and interfaces including lightweight directory access protocol (LDAP) as well as application programming interfaces (APIs) based on based on Common Object Request Broker Architecture (CORBA) or Simple Object Access Protocol/Extensible Markup Language (SOAP/XML).

Referring briefly to FIG. 2, an exemplary structure for engine 82 is shown in greater detail. Engine 82 in a present embodiment is based on the computing environment of a computing server. Engine 82 thus includes a hardware configuration that comprises one or more input devices in the form of a keyboard 200, microphone 204 and the like; and one or more output devices in the form of a display 208, a speaker 212 and the like.

Engine 82 also includes at least one interface 216, which can be used to connect to gateway(s) 82 and a data object server 86. The foregoing components are interconnected by a microcomputer comprised of one or more central processing units 220 connected to volatile memory 224 (e.g. random access memory) and non-volatile memory 228 (e.g. FLASH memory).

While not shown herein, it will understood by those skilled in the art that each electronic device 54 in FIG. 1 includes its own computing environment consisting of a microcomputer connected to various input and output devices, and can be based on any type of mobile computing device such as cellular telephone, a wireless personal digital assistant, or the like. In other embodiments, electronic device 54 can include the computing environment of a desktop computer, a workstation, a thin-client or the like, that is configured to utilize network 68 includes a hardware configuration that may comprise one or more input devices in the form of a keyboard, a mouse and the like; one more output devices in the form of a display, and the like; and a network interface for conducting network communications; all of which are interconnected by a microcomputer comprised of one or more central processing units that itself is connected to volatile memory and non-volatile memory. Thus, the computing environment shown in FIG. 2 presents a schematically analogous environment to the computing environment of each device 54.

Referring now to FIG. 3, an exemplary structure and contents for each data object 108 is shown. In a present embodiment, each data object 108 includes a number of fields which are each provided with a number. Field 1 of each data object 108 includes a device identifier. Thus, field 1 of data object 108-1 includes device identifier 54-1, thereby indicating that data object 108-1 is respective to device 54-1. Likewise, field 1 of data object 108-2 includes device identifier 54-2, thereby indicating that data object 108-2 is respective to device 54-2. Likewise, field 3 of data object 108-n includes device identifier 54-n, thereby indicating that data object 108-n is respective to device 54-n. It should be understood that in variations of the embodiments shown herein, that each data object 108 can have multiple device identifier fields where more than one device 54 so that each data object 108 is associated with multiple devices. Typically, however, each object 108 would includes a unique list of device identifiers, and device identifiers would not overlap between objects 108. Such device identifiers can be dynamically changeable, using appropriate/desired provisioning methodologies. The device identifier can be any unique identifier for a given device, for example, an absolute identifier such as an International Mobile Equipment Identity (IMEI) or it can be a relative identifier for one or more devices such as an International Mobile Subscriber Identity (IMSI) or a Mobile Systems International Subscriber Identity Number (MSISDN).

Field 2 of each data object 108 includes a usage limit. Such a usage limit can be a metric applied to any of the services that are available from a given device 54. Also, each data object 108 can include a plurality of usage limits respective to each service for a given device 54. In a present embodiment, the usage limit relates to voice services, indicating a maximum number of minutes that are available for use by a particular device 54. While not shown herein, using known provisioning and prepaid or postpaid billing techniques, the usage limit can be adjusted. Such adjustment can involve the increasing or decreasing of the usage limit as particular criteria are satisfied. The particular units for a given usage limit is also not particularly limited, and can be expressed in terms of, for example, minutes, seconds, currency, bytes, data sessions, data blocks, or the like. Data blocks or sessions can also encompass, for example, an entire song, ring tone or movie that may have a variable length in actual data size. Data blocks or sessions can also be associated with other multi-media services or services with concurrent and/or asynchronous events that each have a variable length in actual data size. Other services can include data services, which in turn can be specifically defined to include web browsing, emails, streaming media downloads, SMS messages, multi-media message service messages, chat services.

Field 3 of each data object 108 includes a usage meter. Such a usage meter corresponds to the usage limit of Field 2, and indicates how much of the limit of Field 3 has been used. It will now be understood that a plurality of usage meters can correspond to any plurality of usage limit fields that are provided in a given data object 108. The units for a given usage meter will typically correspond to the units for the given usage limit. The contents of field 3 can be increased as the respective device 54 actually uses the particular service, either in real-time or during a post-processing technique. Likewise, the contents of field 3 can be reset or decreased as certain criteria are satisfied for performing such reset or decreasing, again either in real-time or during a post-processing technique.

Fields 2 and 3 are generically referred to herein as containing usage metrics.

Fields 4 of each data object 108 indicates a linked data object. In a present embodiment, only one linked data object is provided for each data object 108, but in other embodiments a plurality of linked data objects can be included in each data object 108. In a present embodiment, data object 108-1 has no linked data object in Field 4; data object 108-2 refers to data object 108-1 in Field 4, while data object 108-n also refers to object 108-1 in Field 4.

The means by which field 4 of each data object is populated and, if needed, updated, is not particularly limited. One example of how field 4 can be populated is shown in FIG. 4. Referring now to FIG. 4, a flowchart depicting a method for identifying a linked device is indicated generally at 300. Method 300 can be implemented using system 50, or a variant thereof.

To assist with understanding method 300, it will be discussed according to a possible implementation of method 300 using system 50. To further assist with understanding method 300, the following assumptions will be made about system 50. It will be assumed that:

a) device 54-1 is already provisioned in network 68, and therefore data object 108-1 in FIG. 3 already exists in profile server 84;

b) device 54-2 has not been provisioned in network 68, and therefore data object 108-2 in FIG. 3 does NOT yet exist (or that it is empty) in profile server 84; and,

c) device 54-n has not been provisioned in network 68 and therefore data object 108-n in FIG. 3 does NOT yet exist (or that it is empty) in profile server 84.

FIG. 5 shows data objects 108 as they are stored in profile server 84 in accordance with the above example.

Referring again to FIG. 4, block 305 comprises receiving a device identifier. In the present example, the device identifier is respective to device 54-1. The device identifier received at block 305 can, in certain embodiments, be received by engine 82 via gateway 80 and network 68. In certain embodiments, the device identifier received at block 305 can be received by engine 82 via OSS BSS servers 96 (for example, upon the activation or provisioning of a device within the OSS or BSS systems of mobile network 68.) In certain embodiments, the device identifier received at block 305 can be received by engine via provisioning engine 90 (for example, upon the activation or provisioning of a device within mobile network 68). Block 310 comprises receiving linking information for another device other than the device associated with the device identifier from block 305. The linking information can be also be received by engine 82 via gateway 80 and network 68. One way of implementing blocks 305 and blocks 310 is for a message to be created at device 54-1 that identifies another device 54 within that message. The message format can be, for example, a short message service (SMS) message, an Unstructured Supplementary Service Data (USSD) message, a multimedia message service (MMS) message, an e-mail message. Those skilled in the art will recognize that gateway 80 may interface to messaging elements within the core network 62 (e.g. a short message service center (SMSC), a multimedia message service center (MMSC), a USSD Gateway, or an e-mail server.) The gateway 80 can be configured to include appropriate interfaces and protocol converters to communicate with network elements in core network 62 in a manner that is native to each of those network elements, so that no modification to those network elements is required. Those skilled in the art will also recognize that gateway 80 may contain functionality that emulates or otherwise incorporates the functionality of messaging elements within core network 62. Other means of generating such a message at device 54-1 include Dual Tone Multi-Frequency (DTMF) via an Interactive Voice Response (IVR) system hosted by gateway 82. Thus, the originating identifier of the message (i.e. device 54-1) can satisfy block 305, while the contents of the message can satisfy block 310. Another means of generating such a message at device 54-1 is where another device 54 is identified via a web based service (which may be hosted by gateway 82). For example, the identifier of device 54 can be determined the selection of a Uniform Resource Locator (URL) link or by explicitly populating the identifier of another device 54 in an appropriate field).

Note that the contents of the message for satisfying block 310 can be either in absolute form (i.e. an explicit unambiguous reference to the IMEI or equivalent for the device 54) or a relative identifier that can be related to device 54, such as an IMSI or MSISDN or the like. It should be understood that blocks 305 and 310 can be effected in other ways as well. For example, via a web browser interface from any device or client that is connectable to engine 82.

Block 315 comprises a determination as to whether or not to provision the device identified at block 310. As part of block 315, typically additional provisioning information will also be received (the reception of which is not shown in method 300 as it is optional) which is used in the determination and actual provisioning of the device identified at block 310. The determination can be based on any usual (or otherwise desired) criteria that is used when determining whether or not to provision a particular device on a given network. Such criteria can therefore include, obtaining a specific request to provision the device and information that reflects a profile for that device. Such other information can include, for example, the usage limit referenced in Field 2 of the data objects 108 shown in FIG. 3. Such information can also include the various types of services which are to be provisioned for a given device 54. Other provisioning information will now occur to those skilled in the art.

The determination at block 315 can be “no”, for example, if sufficient identifying information is not provided, or if for some particular reason the information indicates that a particular device is not eligible for provisioning. In this case, method 300 ends.

If the determination at block 315 is “yes” then block 325 comprises the actual provisioning of the device referenced at block 310 in accordance with the provisioning criteria used at block 315. Thus, assuming the device identified at block 310 is device 54-2, then device 54-2 is actually activated on network 68 so that device 54-2 can now access network 68 in the usual manner. Block 330 comprises creating a data object for the device identified at block 310. Block 335 comprises adding a linkage in the data object created at block 330 to the device identified at block 305. Block 330, in a present example, can comprise the creation of Fields 1-3 of data object 108-2, while block 335 can comprise the creation of Field 4 in data object 108-2. Note that in this example, the identification of device 54-1 is made indirectly, via an identification of data object 108-1 which in turn points to device 54-1.

Block 340, which is optional, comprises sending a message of the linkage. Such a message can be sent to either or both of the devices identified in block 305 and block 310. Such a message can be sent via any medium which can be received on the relevant device 54.

Those skilled in the art will recognize that method 300 can be modified to remove linkages between devices and data objects. For example in the case that a device is deprovisioned from the network 68 or where a given attribute associated with a device is removed or reduced in connection with the deactivation of a service or feature. In a modified embodiment of method 300, block 310 would be modified to receive de-linking information for another device other than the device associated with the device identifier from block 305. At a modified embodiment of block 305, if sufficient identifying information is not provided, or if for some particular reason the information indicates that a particular device is not eligible for de-provisioning, then in this case, the modified embodiment of method 300 ends. If the determination at block 315 is “yes” (sufficient de-linking or de-provisioning information is received) then a modified embodiment of block 325 comprises the actual de-provisioning of the device referenced at a modified embodiment of block 310 in accordance with the de-provisioning criteria used at a modified embodiment of block 315. A modified embodiment of block 330 comprises optionally removing a data object for the device identified at the modified embodiment of block 310. A modified embodiment of block 335, comprises the removal of linkages in a previously created data object to the device identified at block modified 305. A modified embodiment of block 330, in a present example, can comprise the removal of Fields 1-3 of data object 108-2, while a modified embodiment of block 335 can comprise the removal of Field 4 in data object 108-2. Note that in this example, the identification of device 54-1 is made indirectly, via an identification of data object 108-1 which in turn points to device 54-1. A modified embodiment of block 340, which is optional, comprises sending a message of the removal of the linkage. Such a message can be sent to either or both of the devices identified in the modified embodiments of block 305 and block 310. Such a message can be sent via any medium which can be received on the relevant device 54.

Referring now to FIG. 6, a flowchart depicting a method for updating a data record associated with an electronic device is indicated generally at 400. Method 400 can be implemented using system 50, or a variant thereof. Method 400 is typically performed subsequent to, or as part of performance of method 300. Method 400 is typically performed by engine 82 interacting with the other components of system 50 as the context requires.

For example, block 405 comprises receiving instructions to adjust a data object associated with a device identifier. Thus, for example, block 335 comprises the step of adding a linkage to the data object created at block 330. The invocation of block 335 can satisfy the receipt of instructions contemplated at block 405. As another example, OSS BSS servers 96 can provide usage data (e.g. in connection with a voice, messaging, or data based service or application) with respect to device 54. The receipt of usage information in connection of a device 54 from OSS BSS servers 96 can satisfy the receipt of instructions contemplated at block 405. As another example, provisioning engine 90 can provide incremental provisioning data (e.g. the activation of a feature or service (e.g. activation of voice mail, MMS messaging, a mobile TV package), the invocation of a price plan or bundle of services (the selection of voice and messaging plan with a greater allocation of voice minutes and sms messages per month), the activation of a rate plan for one for more services (e.g. the activation of a data rate plan of 1 GB per day for $1)). The receipt of incremental provisioning data in connection of a device 54 from provisioning engine 90 can satisfy the receipt of instructions contemplated at block 405. Those skilled in the art will recognize that the instructions to adjust a data object associated with a device identifier can be negative in value as well as positive (for example in the case that a given attribute associated with device is removed or reduced in connection with the deactivation of a service or feature).

Block 410 comprises adjusting the data object referenced at block 405 based on the instructions received at block 405. Thus, in accordance with the current example, assume that block 335 is being performed in relation to data object 108-2. Thus, at block 410 data object 108-2 is updated in accordance with the previously-described performance of block 335.

Block 415 comprises determining whether to adjust the linked data object referenced in data object identified at block 405. Recall in the present example data object 108-2 was referenced at block 405, and therefore the determination at block 415 involves determining whether or not to adjust data object 108-1, which is the data object referenced in field 4 of data object 108-2.

The determination as block 415 can be based on any predefined criteria. Such criteria can be based on, for example, the modification of any of the fields 2-4 in the relevant data object 108. For example, the actual populating of field 4 itself, or the incrementing the usage limit in field 2, or the incrementing of the usage in field 3 can be collective or individual criteria that is used to satisfy the arrival at a “yes” determination at block 415. Conversely, the decrementing of the usage limit data in field 2 of data object 108-2, or the decrementing of the usage amount in field 3 can be criteria that is used to satisfy the arrival at a “no” determination at block 415. Despite these specific examples, it should be understood that the criteria at block 415 is not particularly limited and can be structured to correspond with the varying structures of the data objects that may be referenced at block 405.

In the present example, assume that the actual populating of field 4 of data object 108-2 is sufficient in and of itself to generate a “yes” determination at block 415, then the method 400 will advance to block 425. At block 425 the linked data object is accessed. In this example, engine 82 will access data object 108-1, since it is data object 108-1 that is referenced in field 4 of data object 108-2.

At block 430, the linked data object is adjusted based on predefined adjustment criteria. Any desired adjustment criteria can be used. For example, the adjustment criteria can involve incrementing the usage limit in field 2 of data object 108-1 by a predefined amount. An exemplary predefined amount is the addition of 20 minutes to the usage limit currently maintained in field 2 of data object 108-1. To provide further illustration of this example, FIG. 7 shows an example of the status of data objects 108-1 and 108-2 subsequent to the performance of methods 300 and 400, based on the earlier assumption that data objects 108 had the status shown in FIG. 5 prior to the performance of methods 300 and 400. Note that in FIG. 7, in field 2 of data object 108-1, the usage limit has been increased to 120 minutes, and that data object 108-2 has now been created. Those skilled in the art will recognize that in the event that an attribute in a linked data object is reduced (e.g. the number of minutes are reduced by 100 minutes), then in field 2 of data object 108-1, the usage limit would correspondingly be decreased to 80 minutes.

It should now be understood that methods 300 and 400 can be repeated again for the provisioning of device 54-n and which involves the linkage of device 54-n to device 54-1. FIG. 8 shows the results of performing method 300 and 400 this second time, and accordingly field 2 of data object 108-1 has been increased to 140 minutes, and that data object 108-n has now been created.

As previously indicated, the performance of method 400 need not be linked to the performance of method 300. For example, assume that data objects 108 are structured and contain the data in accordance with that shown in FIG. 8. Assume also that during performance of method 400, at block 405 instructions are received at engine 82 to increase the usage limit in field 2 of data object 108-n to 200 minutes from 100 minutes. Thus, at block 410, field 2 of data object 108-n can actually be increased to 200 minutes. At block 415, assume that a “yes” determination is made if the instructions at block 405 involve the increase of field 2 of data object 108-n. At block 425, data object 108-1 is accessed by engine 82 and at block 430, data object 108-1 is adjusted based on adjustment criteria. Assume, in this example, that the adjustment criteria is to increase field 2 of data object 108-n by ten percent of the amount that field 2 of data object 108-n was adjusted, then as a result of block 430 field 2 of data object 108-1 will be increased by an additional 20 minutes. FIG. 9 shows the state of data objects 108 after performance of method 400 in accordance with this example, assuming that FIG. 8 reflects the state of data objects 108 prior to this exemplary performance of method 400. In FIG. 9, field 2 of data object 108-1 has been increased an additional 20 minutes to a total of 160 minutes (reflecting performance of block 430), while field 2 of data object 108-n has been increased to 200 minutes from 100 minutes.

It is to be reemphasized that the structure and contents of data objects 108 in FIGS. 3, 5, 7, 8 and 9 are exemplary for the purposes of explanation. Variations of structures for data objects 108 are contemplated, and the contents of those data objects 108 will accord with the actual performance of system 50 in actual operation. Likewise it will be understood that the various components in system 50, and the various implementations of methods 300 and 400 can also vary.

As an example of a variation, it can be desired to configure engine 82 so that the usage limit in field 2 of a first data object 108 identified in field 4 of a second data object 108 is increased based on an increase in the usage indicated in field 3 of the second data object 108. As another example of a variation, it can be desired to configure engine 82 so that the usage in field 3 of a first data object 108 identified in field 4 of a second data object is decreased based on an increase in the usage indicated in field 3 of the second data object 108 or an increase in the usage limit in field 2 of the second data object 108.

In more general terms, the amount of the adjustment to the usage metric (e.g. an increase the usage limit in field 2 and/or a decrease in the usage in field 3) of a first data object 108 that is identified in field 4 of a second data object 108 can be based on a percentage of an increase (or other change) in the usage metric (e.g. field 2 or field 3) of the second data object 108.

Referring now to FIG. 10, an enhanced data object 108a is shown to illustrate at least one of the contemplated variations to the teachings herein. Enhanced data object 108a is based on enhanced data object 108 and includes the same first four fields as object 108, but also includes additional fields. Field 5 is labeled “Child Linked Data Objects” and includes the contents 108-2, 108-n to indicate that data object 108-2 and data object 108-n are linked to data object 108a-1 as per the examples given above. (Field 4 thus has the same meaning and contents as data object 108-1 above, but is labeled “Parent Linked Data Objects” to distinguish from Field 5). Field 6 is labeled “Privacy Restrictions”, which have the contents in the example of FIG. 10 as “None”, but could be configured to be set to “Parent Linked Data Objects only”, to indicate that for example, a message generated at block 340 could only be sent to parent linked data objects, but could not be sent to any other entity. Other types and settings for Privacy Restrictions will now occur to those of skill in the art. Other extensions and variations of data object 108 and data objects 108a will now occur to those skilled in the art.

As a still further variation involving data object 108a, it is contemplated that engine 82 could be configured to receive a request from a given device 54 querying as to the contents of the other data objects 108 that are identified as parent linked data objects in Field 4 or child linked data objects in Field 5. Whether or not a response to such a query is provided by engine 82 can be based on Privacy Restrictions identified in Field 8. In this manner, device 54-1 associated with data object 108a-1 could view the contents of, for example, field 2 or field 3 of data objects 108-2 and 108-n.

As a still further variation involving data object 108a, it is contemplated that engine 82 could be configured to receive a request from a given device 54 querying as to an identification of all devices that are associated with parent linked data objects in Field 4 or child linked data objects in Field 5. Again, whether or not a response to such a query is provided by engine 82 can be based on Privacy Restrictions identified in Field 8.

Claims

1-17. (canceled)

18. A method for updating data objects associated with electronic devices comprising: receiving instructions to adjust a first data object, said first data object maintained in association with a first electronic device, said first data object comprising a reference to a second data object associated with a second electronic device, said first data object further comprising at least one usage metric associated with said first electronic device, said instructions comprising an adjustment to said at least one usage metric;accessing said first data object;performing a first adjustment to said at least one usage metric in said first data object in accordance with said instructions;accessing said second data object identified within said first data object, said second data object further comprising at least one usage metric associated with said second electronic device; andperforming a second adjustment to at least one usage metric associated with said second data object, said second adjustment based on said first adjustment.

19. The method of claim 18, wherein said at least one usage metric associated with said first electronic device or said at least one usage metric associated with said second electronic device is a usage limit.

20. The method of claim 19, wherein said second adjustment is an increase to said usage limit associated with said second data object.

21. The method of claim 20, wherein said increase is based on a percentage of an increase to said usage limit associated with said first adjustment.

22. The method of claim 18, said at least one usage metric associated with said first electronic device or said at least one usage metric associated with said second electronic device is an actual usage.

23. The method of claim 22, wherein said second adjustment is a decrease to said actual usage associated with said second data object.

24. The method of claim 20, wherein said decrease is based on a percentage of an increase to said actual usage associated with said first adjustment.

25. The method of claim 18, wherein said at least one usage metric associated with said first electronic device or said at least one usage metric associated with said first electronic device is associated with a particular service that is available from either said first electronic device or said second electronic device.

26. The method of claim 25, wherein said service comprises at least one of voice and data services.

27. The method of claim 26, wherein said data service comprises one or more of web browsing, emails, streaming audio or video media, SMS messages, multi-media message service messages, or chat service.

28. The method of claim 18, wherein units for said usage metric is expressed in terms of one or more of minutes, seconds, currency, bytes, data sessions, and data blocks.

29. The method of claim 28, wherein data blocks or data sessions comprise a song, a ring tone or movie.

30. The method of claim 18, wherein said first data object is associated with said first electronic device or said second data object is associated with said second data object by means of an absolute identifier.

31. The method of claim 30, wherein said absolute identifier is a International Mobile Equipment Identity (IMEI).

32. The method of claim 18, wherein said first data object is associated with said first electronic device or said second data object is associated with said second data object by means of a relative identifier.

33. The method of claim 32, wherein said relative identifier is at least one of an International Mobile Subscriber Identity (IMSI) and Mobile Systems International Subscriber Identity Number (MSISDN).

34. A data object management engine for updating data objects associated with electronic devices comprising: a processor configured to receive instructions to adjust a first data object, said first data object maintained in a data server connected to said processor, said first data object associated with a first electronic device, said first data object comprising a reference to a second data object associated with a second electronic device, said data object maintained in said data server, said first data object further comprising at least one usage metric associated with said first electronic device, said instructions comprising an adjustment to said at least one usage metric;said processor further configured to access said first data object and perform a first adjustment to said at least one usage metric in said first data object in accordance with said instructions;said processor further configured to access said second data object identified within said first data object, said second data object further comprising at least one usage metric associated with said second electronic device; andsaid processor further configured to perform a second adjustment to at least one usage metric associated with said second data object, said second adjustment based on said first adjustment.