Telecommunications device and method
Claim Score by NHIP
Abstract
A control system for a telecommunications portal includes a modular chassis including an Ethernet backplane and a platform management bus which houses at least one application module, at least one functional module, and a portal executive. The modules are connected to the backplane and the management bus. At least one sensor detects operational parameters of at least one of the modules and transmits sensor data representative of the operational parameters over the management bus. The portal executive includes receives the sensor data from the management bus, compares the sensor data to pre-established baseline values for the operational parameters, and performs a control action in response to a deviation of the sensor data from the baseline values.

Term
Term ended
Projected expiry passed 27 October 2024, 1.9 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
21 claims: 2 independent, 19 dependent
- 1A control system for a telecommunications portal, comprising:a modular chassis including an Ethernet backplane and a platform management bus;at least one application module mounted in said chassis and connected to said backplane and said management bus, said application module performing at least one audio, visual, or data function and transmitting or receiving data related to said function over said backplane;at least one functional module mounted in said chassis which supports the operation of said application module;at least one sensor operable to detect operational parameters of at least one of said modules and transmit sensor data representative of said operational parameters over said management bus;a portal executive connected to said backplane and said management bus;wherein said portal executive includes means for receiving said sensor data from said management bus, comparing said sensor data to pre-established baseline values for said operational parameters, and performing a control action in response to a deviation of said sensor data from said baseline values.
- 12Broadest claimClaim Score 63, broad(NHIP)A method for controlling a telecommunications portal, comprising:providing a modular chassis including an Ethernet backplane and a platform management bus;providing a portal executive which is connected to said backplane and said management bus;providing at least one application module operable to perform at least one audio, visual, or data function, which is mounted in said chassis and connected to said backplane and said management bus;providing at least one functional module mounted in said chassis which supports the operation of said application module;detecting operational parameters of at least one of said modules and transmitting sensor data corresponding to said operational parameters through said management bus;establishing predetermined baseline values for said operational parameters;receiving said sensor data and comparing said sensor data to said baseline values;and performing a control action whenever said sensor data deviates from said baseline values.
Independent claims2
76 paragraphs in 5 sections, as filed
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of U.S. Provisional Application No. 60/514,657, filed Oct. 27, 2003.
BACKGROUND OF THE INVENTION
This invention relates generally to telecommunications technology and more particularly to an integrated electronic telecommunications device and system. Many systems are available which depend on electronic information exchange. Examples include the Internet, local area networks (LAN), wide area networks (WAN), broadcast video, broadcast audio, close-d-circuit television, video on demand, voice over Internet protocol (VoIP) and videoconferencing, among many others. These information exchange systems require some means of physical distribution, such as cabling, optical fibers, or wireless transmission must be used to transfer and route the information. Furthermore, some of these systems required a central server or office which transfers information to a remote client or customer location. Typically, each individual information exchange system has its own architecture and hardware requirements. For example, a LAN connected to the internet connection requires a workstation, possibly a proxy server computer, and a router or switch to distribute information to an in-building network. If, for example, a videoconferencing system is provided at the same physical location, it requires a video camera, microphone, TV monitor, distribution hardware and wiring. This situation results in the use of redundant and expensive hardware systems which are difficult to upgrade.
Systems have been provided which attempt to combine multiple units performing these functions in a single unit or “hub”. However, these hubs have many components which are subject to degradation and failure. Prior art hubs can fail or go “off-line” without warning. Although the capability exists to determine if a unit has failed, this information is only provided after the fact. Thus results in system downtime, which may be unacceptable in certain circumstances, for example financial or medical systems.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the present invention to provide an integrated telecommunications system which supplies multiple information exchange requirements.
It is another object of the invention to provide a telecommunications portal which is modular and easily upgradeable.
It is another object of the invention to provide a telecommunications portal which is able to proactively-monitor-the health of its components.
These and other objects of the present invention are achieved in one embodiment of the invention by providing control system for a telecommunications portal which includes a modular chassis including an Ethernet backplane and a platform management bus. At least one application module is mounted in the chassis and connected to the backplane and the management bus. The application module performs at least one audio, visual, or data function and transmits or receives data related to the function over the backplane. At least one functional module is mounted in the chassis which supports the operation of the application module. At least one sensor is operable to detect operational parameters of at least one of the modules and transmit sensor data representative of the operational parameters over the management bus, and a portal executive is connected to the backplane and the management bus. The portal executive includes means for receiving the sensor data from the management bus, comparing the sensor data to pre-established baseline values for the operational parameters, and performing a control action in response to a deviation of the sensor data from the baseline values.
According to another embodiment of the invention, the control action is chosen from the group consisting of: sending an alarm message to a predetermined email address, sending an alert signal to a preselected pager, generating an audible alarm, generating a visual alarm, shutting down an affected module, resetting an affected module, powering-up a backup module, and combinations thereof.
According to another embodiment of the invention, the portal executive is operable to selectively power-up or power-down the module.
According to another embodiment of the invention, the portal executive is operable to selectively reset the module.
According to another embodiment of the invention, the sensor data is categorized into at least two categories depending upon the degree of deviation of the sensor data from the baseline values, and the control action is selected based upon which category the sensor data falls into.
According to another embodiment of the invention, the sensor data is characterized into at least minor, major, critical, and non-functional categories, each of the categories representing progressively greater deviation from the baseline values.
According to another embodiment of the invention, the module includes a cooling fan driven by an electric motor, and a sensor for detecting the speed of the motor.
According to another embodiment of the invention, the application module includes a plurality of operational components mounted on a circuit board, and the application module includes a sensor which detects the temperature of the circuit board.
According to another embodiment of the invention, the application module includes a plurality of operational components mounted on a circuit board, and the application module includes a sensor which detects the current flow through the circuit board.
According to another embodiment of the invention, the chassis includes a plurality of slots for receiving modules, and the slots are continuously polled by the portal executive to determine at least one of: the presence of a module in a specific slot of the chassis; the specific model of each module present; and a unique identification of each module.
According to another embodiment of the invention, the portal includes means for updating a software program of at least one of the modules.
According to another embodiment of the invention, a method for controlling a telecommunications portal includes: providing a modular chassis including an Ethernet backplane and a platform management bus; providing a portaL executive which is connected to the backplane and the management bus; providing at least one application module operable to perform at least one audio, visual, or data function, which is mounted in the chassis and connected to the backplane and the management bus; providing at least one functional module mounted in the chassis which supports the operation of the application module; Operational parameters of at least one of the modules are detected and sensor data corresponding to the operational parameters is transmitted through the management bus. Predetermined baseline values are established for the operational parameters. The sensor data is received and compared to the baseline values. A control action is performed whenever the sensor data deviates from the baseline values.
BRIEF DESCRIPTION OF THE DRAWINGS
The subject matter that is regarded as the invention may be best understood by reference to the following description taken in conjunction with the accompanying drawing figures in which:
<figref idref="DRAWINGS">FIG. 1</figref> is a schematic view of a telecommunications system constructed in accordance with the present invention;
<figref idref="DRAWINGS">FIG. 2</figref> is a schematic view of a network central office server connected to a remote client network;
<figref idref="DRAWINGS">FIG. 3</figref> is a schematic view of a remote client network constructed in accordance with the present invention;
<figref idref="DRAWINGS">FIG. 4</figref> is a schematic perspective front view of a hardware chassis for use with the present invention;
<figref idref="DRAWINGS">FIG. 5</figref> is a schematic perspective rear view of the chassis of <figref idref="DRAWINGS">FIG. 4</figref>;
<figref idref="DRAWINGS">FIG. 6</figref> is a schematic view of the functional arrangement of a telecommunications portal constructed in accordance with the present invention.
<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram depicting the information flow in the configuration software of a control module constructed according to the present invention;
<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram depicting the configuration of system settings in the configuration software;
<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram depicting the server configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 10</figref> is a block diagram depicting the data flow configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram depicting layer <b>2</b> data configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 12</figref> is a block diagram depicting layer <b>3</b> data configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 13</figref> is another block diagram depicting layer <b>3</b> data configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 14</figref> is another block diagram depicting layer <b>3</b> data configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 15</figref> is a block diagram depicting class-of-service configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 16</figref> is a block diagram depicting high availability configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 17</figref> is a block diagram depicting wide area network configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 18</figref> is a block diagram depicting wireless device configuration in the configuration software;
<figref idref="DRAWINGS">FIG. 19</figref> is a block diagram depicting software configuration of a voice-over-internet-protocol module; and
<figref idref="DRAWINGS">FIG. 20</figref> is a block diagram depicting software configuration of a video module.
DETAILED DESCRIPTION OF THE INVENTION
Referring to the drawings wherein identical reference numerals denote the same elements throughout the various views, <figref idref="DRAWINGS">FIG. 1</figref> shows a schematic view of an exemplary telecommunications system <b>10</b> constructed in accordance with the present invention. The telecommunications system <b>10</b> includes a network operating center (NOC) <b>12</b> located at a central office or server location, and one or more remote client networks (RCN) <b>14</b> located at remote facilities. Each remote client network <b>14</b> comprises a portal <b>16</b>, described in more detail below, and one or more end user units <b>18</b>. The network operating center <b>12</b> is connected to the remote client networks <b>14</b> by a packet switched network over data lines <b>20</b>. A variety of known network standards may be used to transmit packets over the data lines, for example optical (860 nm, 1310 nm, 1550 nm, 1550 CWDM, 1550 DWDM), or 10/100/1000 BaseT Ethernet. In the illustrated example the data lines <b>20</b> are 128 Kbps T-1 lines.
<figref idref="DRAWINGS">FIG. 2</figref> illustrates the basic functions of the network operating center <b>12</b> and the portal <b>16</b>. The construction and operating principles of the network operation center <b>12</b> and the portal <b>16</b> are substantially identical. The distinguishing factor between the two devices is their location and function. For example, the same chassis may be located at a central monitoring office, or at a remote site, and reconfigured as needed. Each unit is constructed with a modular chassis and includes a controlling CPU <b>22</b>, a file server <b>24</b>, a network interconnect <b>26</b>, a VoIP processor or gateway <b>28</b>, a network router switch <b>30</b>, and a video processing module <b>32</b>. The network operating center <b>12</b> receives a number of different types of multimedia content which may be digital or analog. It then coverts this content to packetized information and transmits it over the data line <b>20</b> to the portal <b>16</b>. The portal <b>16</b> routes the incoming packets to the proper internal processing module, where they are reconverted to the appropriate format as needed (for example, MPEG video data may be converted to PAL or NTSC video output). The information is then sent out to the end user units (depicted generally at <b>18</b>.)
<figref idref="DRAWINGS">FIG. 3</figref> illustrates the layout of a remote client network <b>14</b>. As noted above, the remote client network <b>14</b> includes a portal <b>16</b>, and one or more end user units. The end user units can include any type of information exchange technology, whether it be analog or digital. <figref idref="DRAWINGS">FIG. 3</figref> shows examples of several different types of end user units. A first computer workstation <b>34</b> is connected to the portal <b>16</b> over a hardwired local area network <b>36</b>. The first workstation <b>34</b> sends and receive data packets to and from the portal <b>16</b>. A second computer workstation <b>38</b> is connected to the portal <b>16</b> over a wireless signal path <b>40</b> using a transceiver <b>42</b>. The second workstation <b>38</b> sends and receives data packets to and from the portal <b>16</b>. A security camera <b>44</b> transmits analog or digital video signals over a line <b>46</b> to the portal <b>16</b>. Analog video signals (such as PAL or NTSC) are transmitted over lines <b>48</b> from the portal <b>16</b> to a television monitor <b>50</b>. Audio and video is transmitted bidirectionally over a line <b>52</b> between the portal <b>16</b> and videoconferencing equipment <b>54</b> which includes a camera <b>56</b>, a microphone <b>58</b>, and a monitor <b>60</b>. A security device <b>62</b>, such as a palm reader, transmits data to and from the portal <b>16</b> over a data line <b>64</b>. Video on demand signals are sent from the portal <b>16</b> over a line <b>66</b> to a set-top-box <b>68</b> connected to a television monitor <b>70</b>. Telephone equipment <b>72</b> is connected to the portal <b>16</b> by a data line <b>74</b>. Finally, a process device <b>75</b> such as the illustrated electric motor, a valve actuator, thermostat, pressure sensor or other related portion of an industrial process may be connected to the portal <b>16</b> by a data line <b>77</b>. Sensor and control data may be transmitted to and from the portal <b>16</b>, which can analyze and report the data as well as sending control signals to the process <b>77</b>.
The information streams for all of the end user functions described above are routed through the portal <b>16</b>. The portal <b>16</b> thus replaces a number of other types of telecommunications hardware. The portal <b>16</b>, which is described in detail below, is modular in design and may be easily reconfigured to perform the needed combination of telecommunications functions.
<figref idref="DRAWINGS">FIGS. 4 and 5</figref> illustrate the physical construction of the portal <b>16</b>. As noted above, the network operating center <b>12</b> is substantially identical in construction to the portal <b>16</b>, and thus the following description applies to both units. The portal <b>16</b> comprises a rack-mountable chassis <b>76</b> of a known type. The chassis <b>76</b> includes one or more power supplies <b>78</b> which receive line power, condition it as necessary, and supply it to the individual modules. The chassis <b>76</b> can support several redundant load sharing hot-swappable power supplies, and includes redundant hot-swappable cooling fans <b>80</b>. Any one of the power supplies <b>78</b> or the cooling fans <b>80</b> can be removed and replaced without interrupting the operation of the portal <b>16</b>. The chassis <b>76</b> includes a front card bay <b>82</b> and a rear card bay <b>84</b>, which receive individual modules <b>86</b> (described below), mounted on removable cards having a standard form factor. The illustrated example is sized for standard <b>6</b>U width cards. The number of card slots and the chassis width may be varied to suit a particular application. The chassis <b>76</b> may also include additional input/output (I/O) devices such as an optical drive <b>88</b> (e.g., CD-ROM or DVD) and a magnetic data drive <b>90</b> (e.g. 3.5″ floppy disk drive). These input/output devices may be used for storage or for software updating purposes. The chassis <b>76</b> includes a packet switching backplane <b>92</b>, to which the individual modules <b>86</b> are connected.
The backplane <b>92</b> is preferably Gigabit Ethernet (1000 BaseT). The backplane <b>92</b> provides a packet-switched network, wherein each of the connected modules acts as a individual node on a network, in contrast to an ordinary hardware bus. This architecture provides redundancy and upgradeability. Any of the individual modules may be replaced in case of failure or when more advanced capabilities are available. Furthermore, the entire system will not be disabled by a single faulted module. Examples of known suitable Ethernet backplane standards include PCI Industrial Computers Manufacturers Group (PICMG) standards 2.16, 2.19, 2.20, 2.10 R3.0, and Compact PCI (cPCI).
Referring now to <figref idref="DRAWINGS">FIG. 6</figref>, a system switch module <b>94</b>, is installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The switch module <b>94</b> serves to control and coordinate the functions of the other modules in the chassis <b>76</b> (which are generally referred to herein as application modules) and is responsible for all Ethernet connections into and out of the portal <b>16</b>. The switch module <b>94</b> is a single board computer, or in other words a complete computer contained on a single <b>6</b>U card. Because of the modular construction, the switch module <b>94</b> can be easily upgraded as improved hardware becomes available, or replaced if faulty. The specifications of the switch module <b>94</b> may be varied to suit a particular application. In the illustrated example, the switch module <b>94</b> includes a PENTIUM-class or PowerPC central processor of 500 MHz to 2.4 GHz clock speed, 256 Mb to 4 Gb of random access memory (RAM), a flash memory card, a 40 Gb hard drive, and an Ethernet to Gigabit network interface. The switch module <b>94</b> may include slots for known types of daughter cards <b>96</b>, capable of supporting functions such as Ethernet optics (short & long haul), asynchronous transfer mode communications (ATM), wide area networking (WAN), and wireless networking (for example WIFI or 802.11a/b/g). The switch module <b>94</b> supports multiple Ethernet connections, for example <b>24</b> separate connections, via the backplane <b>92</b> or an integral rear interface module.
A configuration program running on the switch module <b>94</b> serves as the central control to the portal <b>16</b>, and all of the modules in the portal <b>16</b> are configured via the switch module <b>94</b>. The following processes will run on the switch module <b>94</b>: packet forwarding to and from the individual modules in the portal <b>16</b>, packet routing protocols, filtering, high availability networking (switch redundancy), domain name server (DNS), dynamic host configuration protocol server & client (DHCP), network time protocol client (NTP), simple network management protocol agent (SNMP), statefull firewall, and web server (HTTP) for configuration and management of the portal <b>16</b>. This gives the end user a single point of contact for all application modules in the portal <b>16</b>. The configuration program also receives intelligent platform management interface (IPMI) information via an alarm and monitoring module <b>97</b> (described below). The configuration program may be based on the LINUX operating system and may include C and C++ on WINDOWS, and/or THREADX OS.
As noted above, each of the application modules (described below) operate independently of one another. If there is inter-module communication, it is accomplished through the Ethernet connections to the switch module <b>94</b>. Each application module in the portal <b>16</b> is dependent on the switch module <b>94</b> for outside communication.
A file server module <b>98</b> may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The file server module <b>98</b> is a single board computer, which may be similar in architecture to the switch module <b>94</b>. The file server module <b>98</b> performs the same functions of a stand-alone filer server unit, such as storage and retrieval of data files. Its exact architecture and specifications will depend upon the particular end user's needs.
A network module <b>81</b> may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The network module <b>81</b> may be a known type of switch or router working on TCP/IP layer <b>2</b>, <b>3</b>, or <b>4</b> switching as required.
A voice over Internet protocol (VoIP) module <b>83</b> may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The function of the VoIP module <b>83</b> is to route voice data between the portal <b>16</b> and a telephone network. Examples of known types of VoIP modules include soft switches, private branch exchange (PBX) interfaces, Class 5 switch interfaces, DS3 output, or DS1 output.
A video encoder module <b>85</b> of a known type may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The video encoder module <b>85</b> receives video signals from end user units (for example, surveillance cameras) in a variety of formats and converts them into data packets which can then be routed over the backplane <b>92</b>. Exemplary input formats include PAL and NTSC. Exemplary output formats include baseband video, S-video, composite video, broadcast television systems committee (BTSC) stereo, balanced audio, secondary audio program (SAP) audio, closed caption, motion picture experts group (MPEG) 2, 3, or 4, quality of service (QOS) encapsulated, IP encapsulated, Ethernet encapsulated, streaming video, video server, video on demand, video conferencing, video telephone, HD security, surveillance.
A video decoder module <b>87</b> of a known type may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The video decoder module <b>87</b> receives data packets routed over the backplane <b>92</b> and convert them into video signals in a variety of formats, which can then be transferred over lines to end user units (for example, television monitors). Examples of video input formats include Ethernet streaming video, MPEG 2, 3, or 4. Examples of video output formats include baseband video, S-video, composite video, BTSC stereo, balanced audio, SAP audio, closed caption, MPEG 2, 3, or 4, video on demand, video conferencing, video telephone, HD security video, surveillance video, PAL, and NTSC.
A wireless network interface module <b>89</b> of a known type may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The wireless network interface module <b>89</b> transfers data to and from the backplane <b>92</b> to user units (such as wireless transceivers). Examples of suitable wireless network protocols include Ethernet IP, 802.11b, and 802.11g.
A storage module <b>91</b> may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. The storage module <b>91</b> includes multiple hard drives or other types of data storage, and may be used for video storage, data file storage, or database storage.
A multi-function module <b>93</b> may be installed in the chassis <b>76</b> and connected to the backplane <b>92</b>. It can be used as a central point for the connection of PCI mezzanine cards (PMC), PTMC cards, or PCI boards for functions such as wireless network interfacing, shown in <figref idref="DRAWINGS">FIG. 6</figref> at <b>95</b>.
An alarm and monitoring module <b>97</b> is installed in the chassis <b>76</b> and connected to the switch module <b>94</b> through the backplane <b>92</b>. The alarm and monitoring module <b>97</b> has its own unique slot in the chassis <b>76</b>. The alarm and monitoring module <b>97</b> will not fit in any other slot, and no other module will fit in the slot dedicated to the alarm and monitoring module <b>97</b>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the alarm and monitoring module <b>97</b> has connections to all the modules in the chassis <b>76</b> via an IPMI management bus <b>99</b>. The alarm and monitoring module <b>97</b> will also have an Ethernet connection to the backplane <b>92</b>. The alarm and monitoring module <b>97</b> runs embedded LINUX-based software that works in concert with the switch module <b>94</b> to provide intelligent product management interface (IPMI) baseboard management controller (BMC) information, which it obtains by polling all of the individual modules in the chassis <b>76</b>, in conformance with IPMI specification 1.5. This information includes data about the chassis <b>76</b> and individual modules, such as power consumption, board temperature, and cooling fan speed.
A portal executive enables the operation of the portal <b>16</b>. The portal executive may be embodied in various physical forms. For example, the portal executive could be implemented in the configuration program running on the switch module <b>94</b>. Alternatively, the portal executive could be implemented within the embedded software running on the alarm and monitoring module <b>97</b>, which in turn would issue commands to the switch module <b>94</b>. In any event, all of the modular slots in the chassis <b>76</b> are continuously monitored via the backplane <b>92</b>. This monitoring function includes the chassis <b>76</b>, application modules, fans <b>80</b>, power supplies <b>78</b>, and other operating components. The portal executive determines the presence, slot location, type, specific model number, operational status, and global unique identifier number (GUID) of each module. At least one operational parameter of each module is monitored by sensor data from one or more sensors of a known type (not shown). Examples of such operational parameters include board temperatures, cooling fan RPM, power consumption, and chassis position. The portal executive can detect hundreds of parameters within seconds. The portal executive is designed not only to monitor devices, but to set specific parameters on each individual device to pro-actively monitor when the module is registering specific levels of performance relative to a baseline value. The degree of deviation from baseline performance may be divided into categories such as minor performance, major performance, critical performance, and non-functional performance. These categories are predetermined based on criteria such as empirical operating experience or theoretical models of a component's performance.
Baseline categorical values for each operational parameter are provided to the control software. As a specific example which is representative of the other operational parameters, one of the cooling fans <b>80</b> may operate at a certain rated speed or a relatively narrow rated range of speeds in normal operation. This speed or speed range is stored as a baseline data value accessible to the portal executive. If the cooling fan <b>80</b> begins to fail, the fan speed may decrease before it completely stops. At some degree of speed reduction, the cooling fan <b>80</b> may provide degraded performance, e.g. insufficient airflow volume or velocity, even though it has not completely failed. The degree of deviation is categorized as minor performance, major performance, critical performance, and non-functional performance, or similar categories, as noted above. The more severe the degradation, the more likely an imminent failure will occur and/or the less time available to take corrective action without interrupting the operation of the portal <b>16</b>.
Whenever the sensor data deviates from the baseline values, the portal executive performs a control action. Generally stated, a control action is an action having the purpose of ensuring continued operation of the portal <b>16</b>. For example, the portal executive can provide to a user or administrator status information through the GUI (described below), or it can send such information to a designated email address or pager number. Visual and/or audible alarm alerts such as warning lights or warning tones may also be provided. The portal executive is designed for remote accessibility so it can start and restart the system from a local and/or remote location.
For example, if a module is starting to fail based on the comparison of the sensor data to the baseline values, the portal executive may activate a backup module, switch system workload to a redundant module, shut down the failing module, and send an email alert to maintenance personnel that the module requires replacement. The defective module may then be replaced without interruption to the portal <b>16</b>. The control actions may be staged depending upon the deviation category. For example, if a minor performance condition occurs, then an email message may be sent to an operator indicating that maintenance is required sometime in the future. However, if a critical performance condition occurs, an immediate pager alert may be transmitted. Thus, the portal executive is able to maintain continuous operation of the portal <b>16</b>.
A software utility management tool may be provided to retrieve information about the modules and chassis <b>76</b> from the alarm and monitor module via an Ethernet connection to the portal <b>16</b>. This information can be retrieved by request from the end user.
An example of the operation of the telecommunications system <b>10</b> is as follows: an end user at a workstation <b>34</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) sends a network request for a data file. The file request is routed over the LAN <b>36</b> to the portal <b>16</b>, arriving through the network module <b>81</b> (see <figref idref="DRAWINGS">FIG. 6</figref>). Internally, the switch module <b>94</b> receives the file request from the network module <b>81</b> and sends it to the file server module <b>98</b> over the backplane <b>92</b>. The file server module <b>98</b> then accesses the required file content. Depending on the construction chosen, the file server module <b>98</b> may retrieve the file from its internal storage, or from a storage module <b>91</b> over the backplane <b>92</b>. The requested file is then routed back out through the switch module <b>94</b>, the network module <b>81</b>, and the LAN <b>36</b> to the workstation <b>34</b>.
Simultaneously, a security camera <b>44</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) may be sending an analog video signal (for example PAL or NTSC) to the portal <b>16</b> over a line <b>46</b>. This video signal is received by the video encoder module <b>85</b> (see <figref idref="DRAWINGS">FIG. 6</figref>) where it is converted to a stream of packetized data. This data is then routed to the switch module <b>94</b>. The video packets are transmitted to various destinations depending on the user's preference. For example, the video packets may be transmitted over an external network to the network operating center <b>12</b> (see <figref idref="DRAWINGS">FIG. 1</figref>) at a central monitoring station. Alternatively, the packets could be routed over the backplane <b>92</b> to a storage module <b>91</b> for later review.
An example of the operation of the configuration program running on the switch module <b>94</b> will now be described with reference to <figref idref="DRAWINGS">FIGS. 7-20</figref>. It is noted that the term “RFC” used below refers to specified Requests For Comments, which are published documents used by the Internet Engineering Task Force (IETF) describing the specifications for a recommended technology. <figref idref="DRAWINGS">FIG. 7</figref> is a flow diagram of a software-implemented initialization and recovery procedure for the switch module <b>94</b> of the portal <b>16</b>. The control software may take any known form, but is preferably implemented with an interface that may be accessed using a standard web browser, such as Microsoft Internet Explorer or Netscape Navigator. The initialization begins with a start step <b>100</b>. The user points their web browser to a visual depiction of the control module <b>16</b> and a logon prompt will be displayed. Once the user is authenticated a graphical user interface (GUI) home page <b>102</b> will be displayed. The home page <b>102</b> will show a graphical picture of the chassis <b>76</b> and all modules that are installed in the chassis <b>76</b>. The user will be able make a request at block <b>104</b>, to select any modules and the program will initiate the appropriate configuration section. In a keep-alive standby request decisional mode step <b>104</b>, if the user selects the system type a new menu is displayed. The system <b>106</b> is the default or system home page. This information is obtained from the Alarm and monitoring module <b>97</b>. In <figref idref="DRAWINGS">FIG. 8</figref>, at the administration level <b>108</b>, this allows the user to set the system settings <b>110</b>, including the system name, domain name, contact name, date, time, system location, and system contact. Once a change is made and applied (for example by clicking an “apply” button in the software interface), the program will write the changes to the necessary locations on the system. At the users level <b>112</b>, the user configuration <b>114</b> initiates the system users and passwords which can be added or deleted in the system. At the logs level <b>116</b> is the logs display <b>118</b>, where all of the various system logs can be viewed. At the servers level <b>120</b>, access to the server configuration <b>122</b> is where a list of available servers or services can be selected for configuration. If no selections are executed the information level <b>124</b> displays the switch information home page for system default or back to request <b>126</b>, and returns to block <b>104</b> (see <figref idref="DRAWINGS">FIG. 7</figref>).
<figref idref="DRAWINGS">FIG. 9</figref> depicts the servers <b>122</b> information flow, continued from <figref idref="DRAWINGS">FIG. 7</figref>. A selection from the servers <b>122</b> is where the system wide server configuration is done. When a selection of the domain name server (DNS) level <b>128</b> accesses the DNS configuration <b>130</b>, a selection of internet domain name server can be completed. At the dynamic host configuration protocol (DHCP) level <b>132</b>, access to the DHCP configuration <b>134</b>, a selection of DHCP server, DHCP client, and/or DHCP relay can be made. The firewall level <b>140</b> accesses the firewall installer <b>142</b>, which lets the user upload the firewall configuration script for Network Address Translation-NAT (RFC1631), which is implemented on CPU NTP Client (RFC 1305) and/or Packet filtering (stateless or statefull)—firewall simple network management protocol (SNMP). In accessing the SNMP agent <b>144</b>, the user can Choose SNMP agent configuration <b>146</b>, simple network management protocol, to configure either; SNMP V1 (RFC 1157), SNMP V2 (RFC 1907), SNMP V3 (RFC 2271), MIB II (RFC 1213), MIB II Interface updates (RFC 2863), Defining Traps for SNMP (RFC2863), RIPv2 MIB (RFC 1724), OSPFv2 MIB (RFC 1850), BGPv3 MIB (RFC 1269), SMUX MIB (RFC 1227), VLAN Extensions MIB (RFC 2674), Bridge MIB (RFC 1493), VRRP MIB (RFC 2787), Remote Network Monitoring MIB (RFC 2819), IPv4 Multicast Routing MIB (RFC 2932), IP Forwarding Table MIB (RFC 2096), Textual Conventions for SMIv2 (RFC 2579), Ethernet-Like MIB (RFC 2665), and/or Differentiated Service MIB (IETF Draft). If no selections are executed the display shows the switch information home page for system default or back to request <b>148</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
<figref idref="DRAWINGS">FIG. 10</figref> depicts is the data flow from block <b>200</b> of <figref idref="DRAWINGS">FIG. 7</figref>. This again is the default or system home page. This will show a graphical picture of the data portions in the chassis <b>76</b>. The user will be able to select the modules and the program and will direct them to the appropriate configuration section. The information is obtained from the alarm and monitoring module <b>97</b>. If layer <b>2</b>, <b>202</b> is selected it will direct user to Layer <b>2</b> configuration <b>204</b> which allows the user to set Layer <b>2</b> (open system interconnection or OSI model) configuration settings. As shown in <figref idref="DRAWINGS">FIG. 11</figref>, the layer <b>2</b> ports <b>228</b>, direct the user to L<b>2</b> ports <b>230</b> to set individual port settings. These settings include: administration state of the port, duplex (half or full), and speed (10 or 100). If layer <b>2</b> trunks <b>232</b> is selected it will move the user to L<b>2</b> trunks <b>234</b>, which allow the user to create, modify, and delete port trunking or bonding. If layer <b>2</b> VLAN <b>236</b> is selected it directs the user to L<b>2</b> VLAN <b>238</b>, and will allow the user to create, modify, and delete a virtual LAN in the chassis. If layer <b>2</b> mirroring <b>240</b> is selected it will direct the user to L<b>2</b> mirroring <b>242</b>, and will allow the user to define port mirroring. This is used for a network monitoring device. If layer <b>2</b> spanning tree <b>244</b> is selected it will direct the user to L<b>2</b> spanning tree <b>246</b>, which is where the user can configure IEEE 802.1d spanning tree. Once a change is made and applied, the program will write the changes to the switch chip in the system. If no selections are executed the display shows the switch information home page for system default or back to request <b>248</b>, and returns to block <b>104</b> (see <figref idref="DRAWINGS">FIG. 7</figref>).
Referring again to <figref idref="DRAWINGS">FIG. 10</figref>, if the selection is layer <b>3</b> at <b>206</b>, it will direct the user to layer <b>3</b> configuration <b>208</b>. As seen in <figref idref="DRAWINGS">FIG. 12</figref>, the user is allowed to set layer <b>3</b> (OSI Model) configuration settings, IP address, subnet mask, and default gateway information. If layer <b>3</b> address <b>250</b> is selected the user is directed to L<b>3</b> address <b>252</b>. At layer <b>3</b> routing <b>254</b> the user is directed to L<b>3</b> routing <b>256</b>. Referring to <figref idref="DRAWINGS">FIG. 13</figref>, the user is allowed from block <b>256</b> to set Layer <b>3</b> (OSI Model) configuration and routing information. At layer <b>3</b> multipath <b>264</b> the user is directed to L<b>3</b> multipath routing <b>266</b> static routes. At layer <b>3</b> routing information protocol (RIP) <b>268</b> the user is directed to L<b>3</b> routing information protocol in block <b>270</b> which may include version <b>1</b> & <b>2</b> (RIP), RIPv1 (RFC 1058), or RIPv2 (RFC 1723). At Layer <b>3</b> OSPF <b>272</b> the user is directed to L<b>3</b> open shortest path first (OSPF) <b>274</b>. Suitable standards for OSPF include OSPFv1 (RFC 1850), OSPFv2 (RFC 2328), OSPF NSSA (RFC 1587), and OSPF-BGP Interaction—(RFC 1745). At Layer <b>3</b> border gateway protocol (BGP) <b>276</b> the user is directed to L<b>3</b> BGP <b>278</b>, such as EGP (RFC 904), BGP-<b>3</b> (RFC 1267), default route advertisement (RFC 1397), BGP route reflection (RFC 1966), or BGP-OSPF interaction (RFC 1745). If no selections are executed the display shows the switch information home page for system default or back to request <b>280</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
As seen in <figref idref="DRAWINGS">FIG. 12</figref>, the user at Layer <b>3</b> multicast <b>258</b> is directed to L<b>3</b> multicast <b>260</b>. Here the user is allowed to configure multicast settings. Referring to <figref idref="DRAWINGS">FIG. 14</figref>, from block <b>260</b> if the user selects Layer <b>3</b> information <b>282</b> the user is directed to L<b>3</b> information <b>284</b> where the multicast settings are listed. At Layer <b>3</b> filtering <b>286</b>, the user can configure filtering, IGMP Snooping, IGMPv2 (RFC 2236), and DVMRPv3 (IETF Draft). If no selections are executed the display shows the switch information home page for system default or back to request <b>290</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
At <figref idref="DRAWINGS">FIG. 10</figref> selecting class of service <b>210</b> directs the user to COS configuration, which is depicted in <figref idref="DRAWINGS">FIG. 15</figref>. At <b>212</b> the user can prioritize traffic through the switch module <b>94</b> . The chassis <b>76</b> will support 1, 2, or 4 queues per egress port. Packets are assigned to queues to their IEEE 802.1p tags, TOS—Types of Service (RFC 1349), Architecture for Differentiated Services (RFC 2475), and DS Field (RFC 2475). At <b>292</b> FIFO directs the user to First In-First Out Scheduling <b>294</b>. Here traffic is serviced in the order in which it arrives. At strict priority <b>296</b> the user is directed to strict priority <b>298</b> where the highest priority queue is always serviced first. As long as there is traffic in the high priority queue, the lower priority queues are not services. At weight round robin <b>300</b> the user is directed to WRR Schedule <b>302</b> where each queue is assigned a weight. Each queue will be serviced based on its weight. If no selections are executed the display shows the switch information home page for system default or back to request <b>304</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
At <figref idref="DRAWINGS">FIG. 10</figref> high availability <b>214</b> directs user to HA configuration <b>216</b>. Referring to <figref idref="DRAWINGS">FIG. 16</figref>, at HA Configuration <b>216</b> the user selects Virtual Router Redundancy Protocol (VRRP) <b>306</b> which directs the user to VRRP Configuration <b>308</b>. This allows the user to configure VRRP (for example VRRP RFC 2338). This protocol will provide transparent failover of the default router address to another switch in the chassis <b>76</b> or network. If no selections are executed the display shows the switch information home page for system default or back to request <b>310</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
Referring again to <figref idref="DRAWINGS">FIG. 10</figref>, selecting wide area network (WAN) <b>218</b> directs the user to WAN configuration <b>220</b> where the user will configure all WAN modules in the chassis. As shown in <figref idref="DRAWINGS">FIG. 17</figref>, at WAN information <b>312</b> the user is directed to WAN information <b>314</b>. The WAN information screen will display all the configured WAN interfaces in the system. This will include information by port and channel, for example: port number, port framing, port line build out, channel number, channel timeslots, channel framing, and channel protocol. At WAN port <b>316</b> the user is directed to port configuration <b>318</b> where the user configures T1/E1 including port settings, (T1_SF) for T1 Superframe/D4 (B8ZS), (T1_ESF) for T1 Extended Superframe (B8ZS), (T1_SF_AMI) for T1 Superframe (AMI), (T1_ESF_AMI) for T1 Extended Superframe (AMI), (E1_CRC) for E1 in CRC Multiframe Format (HDB3), (E1_CRCCAS) for E1 in CRC Multiframe Format with CAS (HDB3), (E1_CRC_AMI) for E1 in CRC Multiframe Format (AMI), and (E1_CRCCAS_AMI) for E1 in CRC Multiframe Format with CAS (AMI). The user configures Line Build Out (T1 Only), (T1 “Long Haul” in db): LHO=0 db, LH7<sub>—</sub>5=7.5 db, LH15=15 db, LH22<sub>—</sub>5=22.5 db. (T1 “Short Haul” in feet ): SH110=110 ft., SH220=220 ft., SH330=330 ft., SH440=440 ft., SH550=550 ft., SH660=660 ft. E1 requires only one fixed setting, E75=75 ohm interface (BNC connectors), E120=120 ohm interface (RJ48 Twisted Pair). Loopback Mode; off=Normal operation (default), Loopback disabled, payid=Payload Loopback. Frames received from the remote device are passed through the T1/E1 receive framer, looped back to the transmit side, reframed and returned to the remote device, line=Line Loopback. Frames received from the remote device are returned to the transmit side with the original framing intact, ddigi=Diagnostic digital loopback. Frames from the host passed through the transmit framer, looped back into the receive framer and returned to the host. At channel <b>320</b> the user is directed to channel configuration <b>322</b>. These commands create, configure, and delete channels consisting of one or more DSOs; HDLC Channel enable/disable; OFF=Channel disable, RX=Enabled for receive only (transmitter disabled), TX=Enabled for transmit only (receiver disabled), RXTX=Enabled for transmit and receive. HDLC FCS mode; selects between 16 or 32 bit Frame Check Sum (FCS), or ISLP; HDLC_FCS16=16 bit HDLC FCS, HDLC_FCS32=32 bit HDLC FCS, ISLP=Intersystem Link Protocol, No FCS calculated on transmit, any received FCS is passed up along with message, TRANS=Transparent mode; on transmit no HDLC framing is performed; on receive, a bit stream is accepted with no ISO layer <b>2</b> framing recognized. If no selections are executed the display shows the switch information home page for system default or back to request <b>324</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
Referring again to <figref idref="DRAWINGS">FIG. 10</figref>, selecting wireless <b>224</b> directs the user to wireless information <b>326</b> (see <figref idref="DRAWINGS">FIG. 18</figref>). The user can select information <b>328</b> which will display all wireless configurations. At configuration <b>330</b> the user is directed to wireless configuration <b>332</b>. The configuration will allow the user to select several wireless adapters. The chassis can support the multiple wireless standards including the following examples: IEEE 802.1a, IEEE 802.1b, and 802.1g. If no selections are executed the display shows the switch information home page for system default or back to request <b>334</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
Referring again to <figref idref="DRAWINGS">FIG. 7</figref>, the user may select VoIP <b>400</b> (see <figref idref="DRAWINGS">FIG. 19</figref>). This moves to user to VoIP information <b>402</b> which directs the user to information <b>404</b>. This displays the information settings for the VoIP module <b>83</b> (see <figref idref="DRAWINGS">FIG. 6</figref>). At ILS server configuration <b>406</b> the user is allowed to configure the server at <b>408</b>. Internet Locator Server (ILS) is a server which allows the user to solve a name during an H323 standard calling. When a VoIP application is started the user first registers to the ILS server a name, then everyone will be able to see the user using that name (if all users are using same server ILS). At gatekeeper <b>410</b> the user is directed to gatekeeper configuration <b>412</b> where the user can configure the gatekeeper. The user can test gatekeeper features. Terminal H323 A, Terminal H323 B, and Terminal H323 C, or hosts A, B, and C have gatekeeper setting to point to D. At a start time the host tells D own address and own name (also with aliases) which could be used by a caller to reach it. When a terminal asks D for a host, D answers with right IP address, it could not join hosts that are not reachable each other (at IP level), in other words it could not act as a network address translation (NAT) router. At gateway <b>414</b> the user is directed to gateway configuration <b>416</b> which allows the user to configure the gateway. The gateway is an entity that-can join VoIP to public switched telephone network (PSTN) lines allowing them to make calls from the Internet to a standard telephone. If no selections are executed the display shows the switch information home page for system default or back to request <b>418</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
Referring again to <figref idref="DRAWINGS">FIG. 7</figref>, the user may select video <b>500</b> (see <figref idref="DRAWINGS">FIG. 20</figref>). If the user selects video <b>500</b> the user can then select video information <b>502</b>. This directs the user to information streams <b>504</b>. This is where the user can view the configuration display. At <b>506</b> server configuration the user is directed to server configuration <b>508</b>. Here the user is allowed to configure frame rate (Mbps), multicast address, and multicast port. The user can also configure channel server address and port, UDP or RTP (by choice), enable audio (Yes/No), enable video (Yes/No), video encoding (for example MPEG 1, 2, or 4), and audio encoding (MPEG choice). If no selections are executed the display shows the switch information home page for system default or back to request <b>510</b>, and returns to block <b>104</b> at <figref idref="DRAWINGS">FIG. 7</figref>.
The foregoing has described a telecommunications system including a modular, integrated upgradeable portal which performs multiple information exchange functions. While specific embodiments of the present invention have been described, it will be apparent to those skilled in the art that various modifications thereto can be made without departing from the spirit and scope of the invention. Accordingly, the foregoing description of the preferred embodiment of the invention and the best mode for practicing the invention are provided for the purpose of illustration only and not for the purpose of limitation.
Contents5
20 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2015288708A1 | Cited by | United States of America | Pre-grant |
| US2006030260A1 | Cited by | United States of America | Pre-grant |
| US9501345B1 | Cited by | United States of America | Applicant |
| US2006045085A1 | Cited by | United States of America | Pre-grant |
| US9330263B2 | Cited by | United States of America | Applicant |
| US7596715B2 | Cited by | United States of America | Search report |
| US8427489B2 | Cited by | United States of America | Search report |
| US9742794B2 | Cited by | United States of America | Applicant |
| US8009173B2 | Cited by | United States of America | Search report |
| US9313281B1 | Cited by | United States of America | Applicant |
| FR3004305A1 | Cited by | France | Search report |
| US2016112447A1 | Cited by | United States of America | Pre-grant |
| US2006224251A1 | Cited by | United States of America | Pre-grant |
| US9276945B2 | Cited by | United States of America | Search report |
| US11294700B2 | Cited by | United States of America | Applicant |
| US2008082705A1 | Cited by | United States of America | Pre-grant |
| US9596251B2 | Cited by | United States of America | Search report |
| US8363555B2 | Cited by | United States of America | Search report |
| US9245117B2 | Cited by | United States of America | Applicant |
| US8725923B1 | Cited by | United States of America | Search report |
| US2008052442A1 | Cited by | United States of America | Pre-grant |
| US9323926B2 | Cited by | United States of America | Applicant |
| US9923909B2 | Cited by | United States of America | Applicant |
| US9900322B2 | Cited by | United States of America | Applicant |
| US10050997B2 | Cited by | United States of America | Applicant |
| US9065669B2 | Cited by | United States of America | Search report |
| US9325726B2 | Cited by | United States of America | Applicant |
| US2011072151A1 | Cited by | United States of America | Pre-grant |
| US8457017B2 | Cited by | United States of America | Search report |
| US9473481B2 | Cited by | United States of America | Applicant |
| US2013148292A1 | Cited by | United States of America | Pre-grant |
| US8189599B2 | Cited by | United States of America | Applicant |
| US2007061435A1 | Cited by | United States of America | Pre-grant |
| US9686301B2 | Cited by | United States of America | Applicant |
| US10757133B2 | Cited by | United States of America | Applicant |
| WO2008021052A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7912075B1 | Cited by | United States of America | Applicant |
| US9374389B2 | Cited by | United States of America | Applicant |
| WO2008021052A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2015249580A1 | Cited by | United States of America | Search report |
| US9246935B2 | Cited by | United States of America | Applicant |
| US2011058341A1 | Cited by | United States of America | Pre-grant |
| US10055247B2 | Cited by | United States of America | Applicant |
| US2008101247A1 | Cited by | United States of America | Pre-grant |
| US9866581B2 | Cited by | United States of America | Applicant |
| US2007291004A1 | Cited by | United States of America | Pre-grant |
| US10102082B2 | Cited by | United States of America | Applicant |
| US10360062B2 | Cited by | United States of America | Applicant |
| AU2015244114B2 | Cited by | Australia | Search report |
| US9319415B2 | Cited by | United States of America | Applicant |
| US9459987B2 | Cited by | United States of America | Applicant |
| US9599784B2 | Cited by | United States of America | Search report |
| US2007005968A1 | Cited by | United States of America | Pre-grant |
| US8345440B2 | Cited by | United States of America | Applicant |
| US2008040522A1 | Cited by | United States of America | Pre-grant |
| US9516064B2 | Cited by | United States of America | Applicant |
| US2016154196A1 | Cited by | United States of America | Search report |
| US11411984B2 | Cited by | United States of America | Applicant |
| US2009080419A1 | Cited by | United States of America | Pre-grant |
| US2002054477A1 | Cites | United States of America | Pre-grant |
| US2002078290A1 | Cites | United States of America | Pre-grant |
| US2002146014A1 | Cites | United States of America | Pre-grant |
| US2003012485A1 | Cites | United States of America | Pre-grant |
| US2003105903A1 | Cites | United States of America | Pre-grant |
| US2003142664A1 | Cites | United States of America | Pre-grant |
| US2004186603A1 | Cites | United States of America | Pre-grant |
| US2004221084A1 | Cites | United States of America | Pre-grant |
| US2005071689A1 | Cites | United States of America | Pre-grant |
| US5499341A | Cites | United States of America | Pre-grant |
| US5515511A | Cites | United States of America | Pre-grant |
| US6011548A | Cites | United States of America | Pre-grant |
| US6018765A | Cites | United States of America | Pre-grant |
| US6049823A | Cites | United States of America | Pre-grant |
| US6108345A | Cites | United States of America | Pre-grant |
| US6240486B1 | Cites | United States of America | Pre-grant |
| US6304576B1 | Cites | United States of America | Pre-grant |
| US6337856B1 | Cites | United States of America | Pre-grant |
| US6347345B1 | Cites | United States of America | Pre-grant |
| US6347963B1 | Cites | United States of America | Pre-grant |
| US6442758B1 | Cites | United States of America | Pre-grant |
| US6522646B1 | Cites | United States of America | Pre-grant |
| US6542997B1 | Cites | United States of America | Pre-grant |
| US6577631B1 | Cites | United States of America | Pre-grant |
| US6792550B2 | Cites | United States of America | Pre-grant |
| US6986076B1 | Cites | United States of America | Pre-grant |
3 members in 2 offices
Priority claims6
| Document | Office | Kind | Date |
|---|---|---|---|
| 51465703 | United States of America | P | |
| 51465703 | United States of America | P | |
| 97442404 | United States of America | A | |
| 60514657 | – | – | – |
| US20030514657P | – | – | – |
| US20040974424 | – | – | – |
Members3
| Document | Office | Kind | |
|---|---|---|---|
| US2005091304A1 | United States of America | A1 | |
| WO2005044887A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2005044887A9 | World Intellectual Property Organization (WIPO) | A9 |
37 transactions on the USPTO file
Abandoned after 2 non-final rejections, 1 final rejection and 1 RCE.
- Non-final rejections
- 2
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Mail Abandonment for Failure to Respond to Office ActionAbandonedMABN2 | MABN2 | |
| Aband. for Failure to Respond to O. A.AbandonedABN2 | ABN2 | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Correspondence Address ChangeC.AD | C.AD | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Transfer Inquiry to GAUTI1050 | TI1050 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Reference capture on IDSRCAP | RCAP | |
| Application Is Now CompleteCOMP | COMP | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Request for RefundIRFND | IRFND | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
2 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Information on status: application discontinuationABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTIONSTCB | STCB | |
| AssignmentAS | AS |
Numbers
- Publication
- 20050091304
- Publication, DOCDB
- 2005091304
- Publication, EPODOC
- US2005091304
- Application
- 10974424
- Application, DOCDB
- 97442404
- Application, EPODOC
- US20040974424
Titles
- English
- Telecommunications device and method
Classification
- CPC, 3
- H04L41/24
- H04L41/0213
- H04L41/00
- IPC, 7
- C08G18 10
- C08G18 28
- C08G18 48
- C09D175 04
- C09J175 04
- G06F15 16
- H04L12 24
- USPC, 1
- 709200000