|Publication number||US8054958 B2|
|Application number||US 11/297,556|
|Publication date||Nov 8, 2011|
|Priority date||Dec 15, 2004|
|Also published as||US9332130, US20060140371, US20120114110, US20150043723|
|Publication number||11297556, 297556, US 8054958 B2, US 8054958B2, US-B2-8054958, US8054958 B2, US8054958B2|
|Inventors||David Y. Schlossman, John F. Doehner|
|Original Assignee||At Comm Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Non-Patent Citations (3), Classifications (12), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a non-provisional application of provisional application Ser. No. 60/636,505 that was filed Dec. 15, 2004. Priority of application 60/636,505 is hereby claimed and the entire content of application 60/636,505 is hereby incorporated herein by reference.
The present invention relates to telephone systems and more particularly to systems and methods for handling Station Message Detail Recordings (SMDRs).
A Private Branch Exchange (usually abbreviated PBX) is a telephone switch that serves a selected group of users and that usually provides access to the public switched network. Many early PBX systems provided a record of the calls that originated in the PBX or that where received by the PBX by printing this information concerning such calls on a paper tape. The information about calls made and received by the PBX where called Station Message Detail Recordings. The name Station Message Detail Recording is generally abbreviated SMDR and such records are often referred to as SMDR messages.
Modern PBX systems are generally electronic computerized systems that can provide wide array of services. With the advent of Voice over Internet Protocol (VoIP) technology, modern PBX systems allow voice to be routed as data packets over the Internet or over private networks.
For a variety of reasons, modern PBX systems, including VoIP systems, produce SMDR messages. Today, there are many different types of PBX systems that produce SMDR messages and furthermore some PBX systems produce the SMDR messages in accordance with proprietary and different protocols.
There is a need for a universal system for recording interpreting and providing access to SMDR messages.
The present invention provides a highly flexible system that can receive SMDR messages in many different formats and process these messages to produce useful reports and control information.
Several preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that various other embodiments of the invention are also possible and practical. This invention may be embodied in many different forms and the invention should not be construed as being limited to the embodiments set forth herein.
The figures listed above illustrate a preferred embodiment of the invention and the operation of such an embodiment. In the figures, the size of the boxes is not intended to represent the size of the various physical components. Where the same element appears in multiple figures, the same reference numeral is used to denote the element in all of the figures where it appears.
Only those parts of the various units are shown and described which are necessary to convey an understanding of the embodiment to those skilled in the art. Those parts and elements not shown are conventional and known in the art.
A PC/Server 102 is connected to the legacy PBX 101 by a conventional RS-232 connection. The PC 102 includes a software buffer application that retrieves and stores SMDR records. The PC 102 can also connect to the web hosted application service provider (ASP) 104. An example of a software buffer application and of a web hosted application service provider is provided below.
The IP PBXs 105 and 106 are connected to the Ethernet LAN/WAN 109. A PC 108 that includes a program 108P is also connected to the Ethernet LAN/WAN 109. The operation of program 108P will be explained with reference to
The three PBXs 101, 105 and 106 shown in
For example, legacy PBX 101 could be a Nortel Meridian1, Option 11 PBX that has been a popular business PBX for twenty years. It is noted in the literature for the Nortel meridian PBX, SMDR records are referred to as Call Detail Records (abbreviated CDR records). The terms SMDR and CDR as used herein are synonymous.
The IP PBX 105 could for example be a Nortel BCM50 PBX. The Nortel BCM50 PBX can write CDR (i.e. SMDR) records to a pre-determined shared hard drive that is connected to a LAN. The system shown in
The IP PBX 106 could for example also be a Nortel BCM50 PBX, where the shared drive that stores data is in the PC 108.
The PC 102 could for example be a Microsoft Windows 2000 Server or a Microsoft Windows 2003 Server hosting a software buffer such as that marketed by AtComm Corporation of San Mateo, Calif. Alternatively PC 102 could be connected to a hardware buffer such as the buffer marketed by AtComm Corporation, under the name “Xiox Solutions Intelligent Buffer”. That is, either a hardware or a software buffer could be used to collect SMDR records from PBX 101 via a RS 123 protocol and to deliver these records to an application running on PC 102. It is noted that the buffer may be connected directly to the PC 102, it may be a part of PC 102 or it may be remotely accessed by the PC 102. The PC 102 can send SMDR records to ASP 104 via FTP or it can send SMDR records to program 108 in PC 108 via a TCP/IP protocol.
The Internet web Hosted ASP service 104 could for example be call accounting and productivity reporting service marketed by AtComm Corporation under the trademark CommView. The CommView ASP is a one hundred percent web-based host subscription service that provides business and IT managers with PBX call usage analysis reports.
The combination of the legacy PBX 101, the PC/Server hosting software hosting software buffer application and the Internet web hosted ASP service 104 forms a prior art type of SMDR analysis and reporting system. With the present invention a prior art reporting system (which may for example include units 101, 102 and 104) can be integrated into a universal type of system that is provided by the present invention.
With the present invention each of the units 105, 106 and 102 are connected to the Ethernet LAN/WAN 109. LAN/WAN 109 is in turn connected to the personal computer 108. Personal computer 108 can for example be a conventional personal computer operating under the Microsoft Windows operating system. The conventional parts of PC 108 are not shown or described herein. The part of PC 108 of particular relevance to the present invention is the program 108P that runs on PC 108. Program 108P is described later with reference to
As explained below, PC 108 can receive data on LAN/WAN 109 using a variety of protocols. For example, the data may be transmitted using a File Transfer Protocol (FTP) or using an Open DataBase Connectivity Protocol (ODBC). ODBC is a standard database access protocol.
As indicated by block 205, there is a conventional user set up and configuration facility or program that identifies the source and destination of information and the various operations that need be performed.
As indicated by block 201, data is collected from the data base 105DB on a specified schedule. This could for example be an hourly or a daily occurrence depending on the amount of traffic and the size of the database.
As indicated by block 202, the program can respond to real time events that are provided via a RS-232 or TCP/IP steam oriented data input. It is noted that in the system shown in
As indicated by blocks 204, 207 and 208 the scheduler and control 206 causes data to be provided under various situations. Block 204 indicates that data can be pushed to an FTP server (not shown in
First as indicated by block 304, a check is made to determine if there is a telnet input. If there is, blocks 305 and 306 indicate that a listen thread begins. The operation of this thread is shown in
As indicated by blocks, 307, 308, 309, and 310 the existence of various types of TCP/IP is checked. If one of the three types of ODBC inputs begins, block 312 begins the transfer thread. The ODBC transfer thread is shown in
Similarly block 313, 314 and 315 indicate if various other types of input threads exist. There are two possible FTP trades that can be initiated by bold 313. Block 314 related to an RSP Avaya IP Protocol and block 315 relates to a serial transfer thread. The details of these other threads are shown in
As indicated by blocks 311 and 316, sockets are opened to collect data as appropriate in a conventional manner and as indicated by block 316 a time loop is started. The details of this lop is shown in
Blocks 317, 318, 319 and 320 relate to a conventional process to determine if there is a quit request, determine if it is allowed, exit the various threads and finally exit the program as indicated by block 321.
The details of how the Telnet thread is handled are shown in
Block 407 and 411 determine if the listen thread should be terminated as indicated by block 413 or, if as indicated by block 411, the loop shown end and go back to block 402.
If data is received, the timer alarm is reset as indicated by block 506 and 507. If data is not received as determined by block 507, the alarm timer is incremented as indicated by block 508 and a check is made to determine if the alarm has expired as indicated by block 510. The alarm thread (which is also shown in
The alarm thread shown in
The details of the FTP upload thread are shown in
The ODBC data transfer thread and the File Transfer thread are shown in
The file transfer thread has a loop as indicated between block 722 and 727. The interval is set as indicated by block 721 and a check to see if the interval has expired is performed as indicated by block 723. The source is queried for new files and the files are transported and stored as indicated by block 724 and 725. A check is made to see if the loop should be terminated as indicated by block 726 and if appropriate the thread is terminated as indicated by block 728.
The serial transfer thread includes a loop between blocks 822 and 829. After the serial port is opened as indicated by block 821, the data is received as indicated by block 823. A timer check is made as indicated by blocks 824 and 825. The data is copied to a flat file as indicated by block 826. The event ends and the port is closed as indicated by block 827 and 828. The serial thread is terminated as indicated by block 830.
The flow diagrams in
The actual analysis of the data and the manner that reports are generated can be conventional. For example the data analysis and reporting can be similar to that performed by the commerciality available data analysis product marketed by AtComm Corporation.
It is noted that the particular embodiment shown here is merely exemplary of the various embodiment, which are possible with the present invention.
It is also noted that as used herein, the terms SMDR records, SMDR messages, synonymously to mean the same thing. Namely, these terms refer to information records or messages produced by a PBX to provide information concerning calls handled by the PBX. Likewise as used herein the terms SMDR records and SMDR messages include messages and records sometimes referred to as Call Detail Records or CDR records and by other similar terms that refer to information records or messages produced by a PBX to provide information concerning calls handled by the PBX.
That is, while the invention has been shown and described with respect to preferred embodiments thereof, it should be understood that a wide variety of other embodiments are possible without departing from the scope and sprit of the invention. The scope of the invention is only limited by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5159698 *||Sep 4, 1991||Oct 27, 1992||Intellicall, Inc.||SMDR translator|
|US5333183 *||Mar 13, 1992||Jul 26, 1994||Moscom Corporation||Universal MDR data record collection and reporting system|
|US6178453 *||Apr 4, 1997||Jan 23, 2001||Netspeak Corporation||Virtual circuit switching architecture|
|US6760420 *||Jul 17, 2001||Jul 6, 2004||Securelogix Corporation||Telephony security system|
|US20010019605 *||Jan 12, 2001||Sep 6, 2001||North Coast Logic, Inc.||Telemanagement system with modular features and database synchronization|
|US20020094070 *||Nov 29, 2000||Jul 18, 2002||Mott Charles J.||Telephone use-monitoring system and method|
|1||*||Xiox Corporation, Telecommunication management system 24 pages.|
|2||Xiox Intelligent Buffer Installation Guide Jul. 1998, Xiox Corporation, Burlingame, California.|
|3||Xiox Intelligent BufferTechnical Specification, Xiox Corporation, Issued Jun. 26, 1998 Burlingame, California.|
|U.S. Classification||379/126, 379/117, 379/88.17, 379/115.01|
|Cooperative Classification||H04M15/34, H04L67/06, H04L69/169, H04M2215/0164, H04M15/41|
|European Classification||H04M15/34, H04M15/41|
|Nov 9, 2006||AS||Assignment|
Owner name: AT COMM CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHLOSSMAN, DAVID Y.;DOEHNER, JOHN F.;REEL/FRAME:018503/0822
Effective date: 20051207
|Jun 19, 2015||REMI||Maintenance fee reminder mailed|
|Aug 6, 2015||FPAY||Fee payment|
Year of fee payment: 4
|Aug 6, 2015||SULP||Surcharge for late payment|