Patent Description:
It has become desirable to permit consumer premises equipment (CPEs), such as set-up boxes, voice-over IP devices, laptops, modems, routers, gateways, etc., to be remotely configured via a network by using an auto configuration server. The communication between the auto configuration server (ACS) and the consumer premises equipment typically use a predefined protocol. There exist several protocols to do remote management, such as for example a Technical Report <NUM> protocol (TR-<NUM> protocol).

The TR-<NUM> protocol is The Broadband Forum technical specification entitled CPE WAN Management Protocol (CWMP) vl. l (Issue <NUM>, Amendment <NUM>, November <NUM>). The TR-<NUM> protocol defines the communication between a CPE and an ACS by defining an application layer protocol for remote management of end user devices. TR-<NUM> includes both auto configuration and control of other CPE management functions within an integrated framework. The TR-<NUM> protocol consists of an object model in which remote procedure calls (RPC's) are invoked for bidirectional communication between a CPE device and an ACS.

In the TR-<NUM> protocol a session or transaction session is defined as a contiguous sequence of transactions between a CPE and an ACS, where a session may span multiple TCP connections. A transaction is defined as a message exchange between a CPE and an ACS consisting of a single request followed by a single response, initiated either by the CPE or by the ACS. However, the transaction between the CPE and the ACS may result in excessive data and complexity, which is prone to errors.

The present invention is defined in the appended independent claim <NUM> to which reference should be made.

The foregoing and other objectives, features, and advantages of the invention will be more readily understood upon consideration of the following detailed description of the invention, taken in conjunction with the accompanying drawings.

US patent application publication <CIT> discloses a method and apparatus for configuring and managing customer premises equipment.

Referring to <FIG>, a communication system with an auto configuration server (ACS) <NUM>, communicates across a network <NUM> and is adapted to manage respective consumer premises equipment (CPEs) <NUM>. Respective consumer premises equipment (CPEs) <NUM> may be coupled to the network <NUM> over a respective home network <NUM>, such as a respective wireless network. When the consumer premises equipment (CPEs) <NUM> wants to communicate with the ACS <NUM> or the ACS <NUM> wants to communicate with the consumer premises equipment (CPEs) <NUM>, a TR-<NUM> session is initiated between the two.

Referring to <FIG>, an exemplary set of remote procedure calls (RPC's) is illustrated. The communication between the auto configuration server <NUM> and the consumer premises equipment (CPEs) <NUM> may be set up with a RPC Inform <NUM> method from the CPE <NUM> to initiate a transaction sequence, a RPC InformResponse <NUM> method from the ACS <NUM> to indicate the ACS wishes to allow the initiation of the session, and a RPC empty HTTP POST <NUM> method from the CPE <NUM>.

The ACS <NUM> may seek to obtain information from the CPE <NUM> by a GetParameterValues <NUM> method. The GetParameterValues method requests the value of one or more CPE parameters. The GetParameterValues may include an argument ParameterNames that has an associated type that is an array of strings, each representing the name of a requested parameter. If a parameter name argument is given as a partial path name, the request is to be interpreted as a request to return all of the parameters in the branch of the naming hierarchy that shares the same prefix as the argument. A partial path name ends with a ". " (dot) after the last node name in the hierarchy. An empty string indicates the top of the name hierarchy. If OPTIONAL instance wildcards are used in a parameter name the request is interpreted as to return all the parameters of all existing instances, which match the requested parameter name. An instance wildcard may be combined with a partial path name. A full parameter name may be, for example, "Device. DeviceInfo. SerialNumber". A partial parameter name may be, for example, "Device. DeviceInfo.

The CPE <NUM> may respond with a GetParameterValuesResponse <NUM> method. The GetParameterValuesResponse method provdes the value of one or more CPE parameters. The GetParameterValuesResponse method may include an argument ParameterList that has an associated type that is an array of name-value pairs containing the name and value for each requested parameter. If multiple entries in the array in the GetParameterValues request overlap such that there are multiple requests for the same Parameter value, it is at the discretion of the CPE whether or not to duplicate that Parameter in the response array. That is, the CPE may either include that Parameter value only once in its response, or it may include that Parameter value once for each instance that it was requested. If the argument in the request was a partial path name, and if there are no parameters within the object represented by that partial path name (at any level below), the response is empty, and does not cause an error response.

The ACS <NUM> may respond with a SetParameterValues <NUM> method. The SetParameterValues method requests modification of the value of one or more CPE parameters. The SetParameterValues may include a pair of arguments, namely, ParameterList that is an array of name-value pairs where for each name-value pair the CPE is instructed to set the parameter specified by the name argument to the corresponding value and if length of the array is zero then the CPE sets the a ParameterKey to the value sepecified by a ParameterKey argument.

The CPE <NUM> may respond with a SetParameterValuesResponse <NUM> method. The SetParameterValuesResponse <NUM> method indicates that all parameter changes have been (<NUM>) validated and (<NUM>) either applied or committed.

A RPC empty HTTP response <NUM> method from the ACS <NUM> may be followed by a Close connection <NUM> by the CPE <NUM>.

The association between the CPE and the ACS tends to be complicated. In particular, setting some of the parameters tend to be complicated. In particular, often a data model is used to define the functionality of particular consumer premises equipment. One exemplary data mode is a TR-<NUM> protocol is entitled an Internet Gateway Device Data Model for TR-<NUM> (November <NUM>). An exemplary EDGE ACS script to call SetParameterValues RPC, which is ACS dependent, using a TR-<NUM> protocol communication using a TR-<NUM> data model for an internet gateway device may be as follows, where the ACS translates the script into TR-<NUM> transaction similar to that shown in <FIG>:
<IMG>.

Other ACS may use a different format as desired.

The variable "conversation" is set to create a TR69 connection.

The "try {" statement executed code allows the definition of a block of code to be tested for errors while it is being executed.

The "finally {" statement executed code, after a try and catch, executes the code regardless of the result. It is noted that the syntax above does not include a "catch" statement. In this case, after the "try {" statement block of code, the TR69 connection is closed by "conversation.

The variable "resp" is set to conversation. setParameterValues by "var resp = conversation. setParameterValues". In this manner, the variable "resp" is set to a creation of a TR69 connection and institution of a setParameterValues method. The setParameterValues method includes a set of name value pairs separated by commas.

The setParameterValues method includes pairs of arguments, namely, an array of name-value pairs where for each name-value pair the CPE is instructed to set the parameter specified by the name argument to the corresponding value.

The first name-value pair is
'Device. ManagementServer. PeriodicInformEnable': "<NUM>".

The "Device" (or InternetGatewayDevice) identifies the particular consumer premises equipment.

The ManagementServer identifies the ACS management server.

Accordingly, "Device. ManagementServer" contains parameters relating to a particular CPE's association with a particulr ACS.

PeriodicInformEnable has a Boolean type that indicates whether or not the CPE (e.g., Device) must periodically send CPE information to the ACS (e.g., ManagementServer) using the Inform method call. A type of TR69. Bool(true) (e.g., 'Device. ManagementServer. PeriodicInformEnable': TR69. Bool(true)) or TR69. Bool(false) (e.g., 'Device. ManagementServer. PeriodicInformEnable': TR69. Bool(false)) may be used together with PeriodicInformEnable, but such a syntax tends to be complex in nature and prone to error. Rather than using the Bool(true) or the Bool(false) data type, it is preferable to include a string of '<NUM>' to indicate true and to include a string of '<NUM>' to indicate false.

ManagementServer. PeriodicInformInterval' has an unsignedInt[<NUM>:] type, namely an unsigned integer with a defined minimum and no maximum limit, that indicates a duration in seconds of the interval for which the CPE must attempt to connect with the ACS and call the Inform method if PeriodicInformEnable is true. A type of TR69. UInt(<NUM>) (e.g., 'Device. ManagementServer. PeriodicInformInterval': TR69. UInt(<NUM>)) may be used, with <NUM> being any suitable unsigned integer, but such a syntax tends to be complex in nature and prone to error. Rather than using the unsignedInt[<NUM>:] (e.g., UInt) data type, it is preferable to include a string of '<NUM>' to indicate the minimum duration with no limit on the maximum duration, where '<NUM>' may be replaced with a different numerical unsigned integer number.

ManagementServer. ConnectionRequestUsername': 'NewUserName' has a string type that includes a username used to authenticate the ACS making a connection request to the CPE.

For example, the GetParameterValues method may be used to determine the parameter types for the setParameterValues method. Then the setParameterValues method may be subsequently used based upon such parameter types, which may be cached by the ACS.

In the case of the ACS using GetParametersValues method on the root object "Device. " for the CPE, the CPE should return all the device's parameters to the ACS in its response, namely, GetParameterValuesResponse method. The GetParameterValuesResponse method may respond with a very substantial number of parameters from the CPE, such as in excess of <NUM>,<NUM> parameters for particular CPEs. To provide the GetParameterValuesResponse method, the CPE initially gathers up all the parameters on its CPE. In many cases it may take the CPE well in excess of <NUM> seconds and in some cases well in excess of <NUM> seconds, especially for GetParametersValues method on the root object, to gather together all the parameters on the CPE. After gathering together the parameters, the CPE provides them in the GetParameterValuesResponse method to the ACS. Unfortunately, in many cases the ACS will time out prior to the response method being provided when the response method is sufficiently temporally delayed, thereby the ACS will not receive the results of the GetParameterValuesResponse method. Further, gathering together all, or a sufficient number, of the parameters of the CPE may exhaust the resources of the CPE causing either the GetParameterValuesResponse method to fail or otherwise the CPE itself to fail.

Referring to <FIG>, it was determined that the GetParameterValues method from the ACS should include extended syntax to request a partial set of available parameters from the CPE <NUM>. By way of example, the method may include "GetParametersValues. Partial_Root". In this manner, the CPE will also receive "Partial Root" for the root object being requested <NUM>. The CPE upon receiving the Partial_Root for the root object being requested will gather up only a partial list of all the parameters in the receiving CPE <NUM>. The number of parameters that are gathered up by the CPE is a group selected by the CPE and not selected nor controlled by the ACS. The gathering up of the partial list is sufficiently short that it will not take a sufficiently long time that will exceed the timeout time of the ACS nor will it exhaust the resources of the CPE.

After the CPE gathers up a first partial list of parameters, the CPE may provide a GetParameterValuesResponse method that includes the first partial list of parameters of the CPE, and excludes the remaining parameters of the CPE <NUM>. The GetParameterValuesResponse method also includes a Device. Partial_Root with a value of <NUM>. The Device. Partial_Root having a value of <NUM> provides a signal to the ACS that there are additional parameters that may be requested from the CPE.

The ACS receives the GetParameterValuesResponse method together with the Device. Partial_Root having a value of <NUM><NUM>. The ACS may determine if the desired parameters were returned by the CPE within the received partial list. If the ACS received the parameters that were desired, the transaction may end <NUM>. If the ACS did not receive all the parameters that were desired <NUM>, the ACS may again invoke the GetParameterValues method <NUM> to the CPE that includes the Device. Partial Root. The CPE receives the GetParameterValues method including the Partial_Root <NUM>. The CPE gathers a second partial list of parameters <NUM> that are different than the first partial list of parameters. The CPE invokes GetParameterValuesResponse method together with the Device. Partial_Root having a value of <NUM> or <NUM><NUM>. The Device. Partial_Root having a value of <NUM> provides a signal that there are additional parameters that may be requested from the CPE. The Device. Partial_Root having a value of <NUM> provides a signal that there are no additional parameters that may be requested from the CPE that have not already been provided. The ACS receives the parameters from the CPE and the value for Device. Partial_Root <NUM>. If the value for Device. Partial_Root is <NUM>, then the ACS knows that no additional parameters are available to be requested. If the value for Device. Partial_Root is <NUM>, then the ACS knows that additional parameters are available to be requested <NUM>, if desired. The process of requesting and providing a partial list of parameters may be repeated until the desired parameter has been received by the ACS or otherwise all of the parameters have been provided by the CPE to the ACS as a plurality of partial lists of parameters.

An exemplary sample for GetParameterValues for the root object is illustrated below:
Device. InterfaceStackNumberOfEntries xsd:unsignedInt <NUM>
Device. DeviceInfo. X_CISCO _COM_FirmwareName xsd:string
AR01. 063_112319 _711. <NUM>
Device. DeviceInfo. X_RDKCENTRAL-COM_ConfigureWiFi xsd:boolean false
Device. DeviceInfo. X_RDKCENTRAL-COM_CaptivePortalEnable xsd:boolean false
Device. DeviceInfo. X_DKCENTRAL-COM_CloudUICapable xsd:boolean true
Device. DeviceInfo. X_RDKCENTRAL-COM_CloudUIEnable xsd:boolean false
Device. DeviceInfo. X_RDKCENTRAL-COM_CloudUIWebURL xsd:string
Device. DeviceInfo. X_COMCAST-COM_CM_MAC xsd:string <NUM>:<NUM>:B1:DC:<NUM>:1A
Device. DeviceInfo. X_COMCAST-COM_CM_IP xsd:string <NUM>. <NUM>
Device. DeviceInfo. X_COMCAST-COM_WAN_MAC xsd:string <NUM>:<NUM>:b1:dc:<NUM>:1c
Device. DeviceInfo. X_COMCAST-COM_WAN_IP xsd:string <NUM>. <NUM>
Device. DeviceInfo. X_COMCAST-COM_WAN_IPv6 xsd:string. DeviceInfo. X_COMCAST-COM_xfinitywifiCapableCPE xsd:boolean true
Device. DeviceInfo. X_COMCAST-COM_AP_MAC xsd:string <NUM>:<NUM>:b1:dc:<NUM>:1c
Device. DeviceInfo. X_COMCAST_COM_xfinitywifiEnable xsd:boolean false
Device. DeviceInfo. X_COMCAST-COM_rdkbPlatformCapable xsd:boolean true
Device. DeviceInfo. TemperatureStatus. TemperatureSensorNumberOfEntries
xsd:unsignedInt <NUM>
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. Name xsd:string cpu
Device. Devicelnfo. TemperatureStatus. TemperatureSensor. Value xsd:int <NUM>
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. MinValue xsd:int <NUM>
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. MaxValue xsd:int <NUM>
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. Name xsd:string clr2
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. Value xsd:int <NUM>
Device. DeviceInfo. TemperatureStatus. TemperatureSensor. Min Value xsd:int <NUM>. InterfaceStack. LowerLayer xsd:string Device. <NUM>
Device. InterfaceStack. HigherAlias xsd:string Guest Network <NUM>
Device. InterfaceStack. LowerAlias xsd:string Port1
Device. InterfaceStack. HigherLayer xsd:string Device. <NUM>
Device. InterfaceStack. LowerLayer xsd:string Device. <NUM>
Device. InterfaceStack. HigherAlias xsd:string subnet <NUM>
Device. InterfaceStack. LowerAlias xsd:string Port1
Device. InterfaceStack. HigherLayer xsd:string Device. <NUM>
Device. InterfaceStack. LowerLayer xsd:string Device. NodeTabooMask xsd:string <NUM>
Device. TxBeastRate xsd:unsignedInt <NUM>
Device. TxBcastPowerReduction xsd:unsignedInt <NUM>
Device. QAM256Capable xsd:boolean true
Device. PacketAggregationCapability xsd:unsignedInt <NUM>
Device. AssociatedDeviceNumberOfEntries xsd:unsignedInt <NUM>.

Referring to <FIG> and <FIG>, a device management system <NUM> may be interconnected with a substantial number of consumer premises devices <NUM> to simply the delivery, the management, and the support of subscriber devices and services. Such a device management system <NUM> provides a unified view of the subscribers and management thereof. A database, a storage device including the database, a processor interconnected to the database, memory, and the storage device, together with a display that renders an interface <NUM> of data from the database thereon may be included with the device management system <NUM>.

Each of the consumer premises devices <NUM> has a plurality of characteristics that may be used to identify it, where such characteristics are stored in the database on the device management system <NUM> and associated with a particular consumer premises device. The characteristics stored in the database may be queried so that a particular consumer premises device may be identified. The identified consumer premises equipment may then be managed and supported in a suitable manner through the interface <NUM>. Some of the characteristics of each of the consumer premises devices <NUM> are unique while other characteristics of each of the consumer premises devices <NUM> may be shared by a plurality of such devices. For example, the characteristics may include various fields: Provisioning ID <NUM>, Vendor <NUM>, Model <NUM>, Name <NUM>, Serial # <NUM>, Product Class <NUM>, OUI <NUM>, Firmware <NUM>, IP <NUM>, MAC <NUM>, Population <NUM>, User Key <NUM>, User Key <NUM><NUM>, User Key <NUM><NUM>, User Key <NUM><NUM>, User Key <NUM><NUM>, User Key <NUM><NUM>, Filter out not Contacted <NUM>, and Device Group <NUM>. To locate a particular consumer premises equipment, an operator enters suitable information into a suitable entry, such as a serial number into the Serial # entry, then selecting Search <NUM>. In this manner, there is a one-to-one correspondence between the search field and the field in the database including such information. For example, the entry in the Vendor <NUM> field would result in a search of the corresponding vendor fields in the database to search for one or more matches. The other fields work in a similar manner with the corresponding field and field in the database. Unfortunately, if an operator enters information that is properly included in a first entry (e.g., a serial number in the Serial # box) into a different entry (e.g., a serial number in the Model box), then select Search <NUM> the interface will not locate and render information related to the desired consumer premises equipment(s).

Claim 1:
A method for remote management of a plurality of consumer premises equipment (<NUM>) via a network (<NUM>) by use of an equipment management system (<NUM>), comprising:
said equipment management system including a processor and rendering on a display a field that accepts an input for a query by an operator associated with one or more of the plurality of consumer premises equipment;
said equipment management system maintaining an associated database of characteristics of the plurality of consumer premises equipment including a serial number (<NUM>), a model (<NUM>), and a firmware (<NUM>), wherein each of the plurality of consumer premises equipment is associated with at least a first characteristic (<NUM>) of the characteristics that is unique to each of the plurality of consumer premises equipment, and wherein at least a second characteristic (<NUM>) of the characteristics is shared between two or more of the plurality of consumer premises equipment;
said equipment management system searching said database based upon said input from said query from said operator that includes said serial number, said model, and said firmware, wherein there is a one-to-one correspondence between the input and at least one characteristic of the characteristics;
said equipment management system in response to determining a match based upon said query, rendering information regarding a matching consumer premises equipment on said display.