Patent Grant
7206384
The present invention relates to telecommunications systems and, in particular, to an improved system and method for upgrading telecommunications system software.
In both the personal computing and telecommunications environments, software upgrades traditionally have been implemented by providing media such as disks, tapes, etc., which require someone on-site (either the user or a service technician) to handle the actual installation.
Increasingly, in the personal computing environment, software upgrades are being handled via Internet download and automatic or user-directed semi-automatic installation. In contrast, in traditional telecommunications systems, even when fast downloads are available, large enterprise customers are often reluctant to permit an unattended upgrade of equipment such as PBXs, gatekeepers, communications servers, messaging systems, call centers, or other telecommunications devices that might provide critical services or even have a health or safety impact (e.g., those associated with hospital or police systems). Downloading the upgrade and having it installed automatically is seen as too risky.
Consequently, typically, the upgrade media are transported physically, such as via a freight carrier, because it is usually less expensive (in terms of technician time) than downloading via the Internet or telephone lines. A service technician is then dispatched to perform the upgrade on-site (In other cases, the technician may bring the upgrade media himself.). In either case, the actual installation can be relatively expensive (e.g., a service technician's hourly rate can be in the neighborhood of $250/hr.). This is particularly the case when a subscription business model is used. In such a system, users pay an annual licensing fee and receive in return any necessary upgrades.
Therefore, there is a need for an improved system and method for performing telecommunication software upgrades. There is a further need for a more efficient and less expensive way of performing telecommunications system software upgrades.
These and other drawbacks in the prior art are overcome in large part by a system and method according to embodiments of the present invention.
A telecommunications system according to an embodiment of the present invention includes a switch having a controller implementing software to control switching operation and a memory for storing a database of software upgrade risk factors. The software upgrade risk factors define whether a software upgrade is to be attended by an on-site technician or by a remote monitor or to occur automatically. The system further allows for downloading to the switch a software upgrade for the controller if a software upgrade risk factor for that software upgrade has a predetermined value.
A telecommunications method according to an embodiment of the present invention includes determining an upgrade risk factor for a telecommunications system software upgrade; delivering the telecommunications system software upgrade based on the risk factor; and installing the telecommunications system software upgrade based on the risk factor. The method further includes maintaining a database of customer preferred upgrade risk factors, the risk factors defining a degree of attendance for a software upgrade.
A telecommunications device according to an embodiment of the present invention includes a database for storing one or more software upgrade risk factors for telecommunications systems and allows for downloading to controllers software upgrades based on the upgrade risk factors. The upgrade risk factors defining degrees of automation and in-person attendance for the upgrade.
Broadly speaking, embodiments of the present invention relate to an improved upgrade subscription system. A risk factor is placed on a software upgrade and the customers are notified of the upgrade's availability. The customer's risk tolerance is maintained in a database and the upgrade proceeds according to that tolerance. The upgrade may, for example, be downloaded and automatically installed; or downloaded and held for a later installation; or downloaded and installed with a remote monitoring; or installed by an on-site service technician. Further, in certain embodiments, the upgrade may be deferred until its risk factor falls below the customer's threshold. Finally, differential pricing or license fees may be effected based on the customer's risk tolerance and the method of upgrade.
A better understanding of these and other specific embodiments of the invention is obtained when the following detailed description is considered in conjunction with the following drawings.
Turning now to the drawings and, with particular attention to
More particularly,
The network 104 may be a data LAN (local area network) or a LAN employing a multimedia or telephony-over-LAN technology, such as Recommendation H.323 or Session Initiation Protocol (SIP) although other packet multimedia protocols may be employed. In the embodiment illustrated, the network 104 is an H.323-based system. Thus, the network 104 includes a LAN 112, a gateway 114, a gatekeeper 116, and a plurality of telephony devices 118a–118n.
Also coupled to the PSTN 106 may be network 105. The network 105 includes a PBX 109 to which may be coupled a plurality of PBX telephony devices 117a–117n. The PBX 109 may be embodied as a Hicom PBX. Also coupled to the PBX 109 may be a telephony feature access server or device 111 which couples a LAN 113 to the PBX 109. Devices 115a–115n on the network 113 may be configured to obtain telephony services through the PBX 109 via the TFA 111. An exemplary telephony feature access server is the Hicom Feature Access server, available from Siemens Corp., and employing the Cornet protocol. In certain embodiments, the TFA 111 may be equipped with Instant Messaging, calendaring, and VolP capabilities, either as a server or a network device, which may require updating according to embodiments of the present invention. It is noted that additional ToL network devices may be provided, such as multipoint control units and network servers.
It is noted that more or fewer networks may be provided. It is further noted that networks having differing configurations may be provided. For example, one or more of the networks may be wireless or cellular networks. Further, the public telephone network 106 may be embodied as a combination of linked analog and digital networks, as is known. For example, the public telephone network may be configured as an integrated services digital network (ISDN). Thus, the figures are exemplary only.
A variety of the network devices, such as the PBXs 108, 109, the TFA 111, gateway 114, and gatekeeper 116, as well as other servers and switches (not shown) may require periodic software upgrades. According to an embodiment of the present invention, a vendor upgrade service 120 may be coupled to communicate in the network. As will be described in greater detail below, the vendor upgrade service 120 may include a database 122 of upgrade risk factors for a particular software upgrade. The database 122 may also be used to store a customer profile of risk factors or tolerances, defining whether the upgrade 101 is to be downloaded 123 all or in part via the PSTN 106 or whether on-site delivery 124 and installation is required.
A block diagram of an exemplary vendor upgrade service 120 is shown in
A block diagram of an exemplary server or switch 108 which may require software updating according to an embodiment of the invention is shown in
The PBX 108 includes a network resource feature processing module 3118 and an update module 301 according to embodiments of the present invention. The update module 301 may interact to receive updates from the update service 120 (
The feature processing module 3118 may be used to handle supplementary services 3100, such as displays, call park, call transfer, callback, and call forwarding. As noted above, the PBX 108 may be any known telecommunications server and include internal standard components such as prefix logic 3110 and digit analysis 3112 for receiving, decoding and evaluating number information, applications logic 3114 such as CTI, a local processing unit 3119 for providing user interface aspects of various supplementary services, and a routing unit 3116 for routing a call to its proper destination. External interfaces to the server may include an incoming trunk 3111, such as a primary rate interface (PRI) or Internet line, incoming local traffic 3113, such as a basic rate interface (BRI) and outgoing traffic 3115, such as interfaces for PRI, virtual public (VPN) and private networks, and the like. An API 3117 may be used to connect CTI devices (e.g., using TAPI) to the PBX 108. The outgoing traffic may be routed, among other methods, over ISDN, asynchronous transfer mode or Intra/Internet communication networks.
The incoming/outgoing traffic lines, such as the BRI 3113 and PRI 3111, interface to device/trunk handlers 3121–3123. The trunk handlers 3121–3123 interface the PBX 108 to the external interface 3111, 3113, 3115 which contain the signaling channels. In particular, the handlers 3121–3123 operate as translation devices.
As will be discussed in greater detail below, the PBX 108 may receive software upgrades, such as via the BRI 3113, or by receiving local physical media and installing through a removable media device, such as a magnetic or optical drive (not shown). The degree to which the upgrade is attended or supervised may be determined by assigning a software upgrade risk factor to a particular upgrade and accessing or storing a customer's risk tolerances. For example, turning now to
It is noted that numerical risk factors may be assigned, as well (or alternatively). For example, the risk factors may be assigned on a scale of 0 through 10. Then, the risk tolerance might be I) accept all upgrades in unattended fashion, regardless of risk; ii) accept all upgrades with a service technician present, regardless of risk; and iii) accept upgrades with a risk less than 5 unattended, but 5 and above require a service technician to be present. Another risk tolerance might be I) upgrade risk 0–5 may be accepted unattended, ii) upgrades risk factor 6–7 attended remotely; and iii) risk factors 8–10 require a service call. Another risk tolerance might be I) upgrade 0–5 unattended; ii) 6–10 upgrade denied until the risk drops to 5 before attending. The risk factor for a particular upgrade may change over time, for example, as more copies of the upgrade are installed. In this last case, a periodic reminder may be sent from the vendor. It is noted that these a exemplary risk policies and are not intended to be all-inclusive.
Turning now to
Once the risk tolerances have been accessed, the vendor upgrade service 120 determines, at step 506, whether the risk is below the customer threshold. If the risk is below a particular threshold, then in step 510, the upgrade may be downloaded and installed automatically. It the risk is above a threshold, then in step 508, the customer maybe notified and an on-site or remotely attended upgrade may be performed. It is noted that in either case, the upgrade may be downloaded and stored by the upgrade module 301 at a convenient time (e.g., when system bandwidth usage is less) for later installation. Further, a customer could be charged a differential licensing fee based on whether he is willing to take an installation automatically.
Turning now to
As noted above, one method for determining the customer's upgrade risk tolerance is through a signaling between the vendor upgrade service 120 and the customer at 605. The customer's risk tolerance can be determined or adjusted on an upgrade-by-upgrade basis, for example, based on cost or other factors.
The invention described in the above detailed description is not intended to be limited to the specific form set forth herein, but is intended to cover such alternatives, modifications and equivalents as can reasonably be included within the spirit and scope of the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5682533 | Siljestroemer | Oct 1997 | A |
| 6012130 | Beyda et al. | Jan 2000 | A |
| 6393101 | Barshefsky et al. | May 2002 | B1 |
| 6396904 | Lilley et al. | May 2002 | B1 |
| 6477703 | Smith et al. | Nov 2002 | B1 |
| 6993763 | Hayes, Jr. | Jan 2006 | B2 |
| 20030229890 | Lau et al. | Dec 2003 | A1 |
| 20030233644 | Cohen et al. | Dec 2003 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040057558 A1 | Mar 2004 | US |
