Patent Grant
7720206
1. Field of the Invention
The present invention relates generally to invoices and, more particularly, to telecommunications invoices.
2. Related Art
Interconnection arrangements in the telecommunications industry have a long history. Interconnection first became a contractual issue in 1894 when Alexander Graham Bell's initial patents expired. Beginning in 1894, the Bell System had to enter into interconnecting contracts with independent telephone companies, and the independent telephone companies similarly signed contracts with each other that governed the terms of interconnection.
Telecommunications legislation and regulatory actions in the past few decades in the United States has led to creation of a large number of incumbent local exchange carriers (ILECs), intra exchange carriers (IXCs), and competitive local exchange carriers (CLECs). Through a complex system of regulation, telephone calls are placed through these multi-vendor networks using the vast networks of cooperating companies.
In 1984, AT&T was broken up by antitrust regulators in the U.S., forming a network of local phone companies (the ILECs), and long distance companies (the IXCs). Following the breakup, initially each local loop was monopolized and run by a LEC, typically a Regional Bell Operating Company (RBOC) or an independent telephone company such as GTE. Excluding cellular phones, the local loop was a required input in the production of long distance services, and typically long distance companies did not have their own comparable local loop. In telecommunications, the use of a local exchange incurred charges to originate calls (access origination) or to terminate calls (access termination).
Passage of the Telecommunications Act of 1996, authorizing competition in the local phone service market, has permitted CLECs to compete with ILECs in providing local exchange services. This competition has created even more companies which may charge for origination or termination.
When a customer places a telephone call, the call may often originate onto an ILEC, may be transported over a network of the ILEC, and/or an IXC's network, and then may be terminated on an ILECs' facilities. If a call originates at an ILEC, is terminated onto a CLEC's facilities, and then is terminated, e.g., at an Internet Service Provider (ISP), then the ILEC owes the CLEC reciprocal compensation for the termination of the call. Thus, reciprocal compensation is basically a settlement mechanism for telephone traffic transferred between two local networks. This arrangement was pursuant to the FCC Interconnection Order. The money follows the calls. Most ISP calls are from users and terminated to ISPs. This potentially means a lot of money flowing from ILECs to CLECs who have ISPs as customers. The ISPs are considered “end users” pursuant to FCC rules, and therefore the call is considered a local call. If a call is considered a long distance transmission, then reciprocal compensation did not apply. Many ILECs may pay CLECs reciprocal compensation.
Because of the many origination and termination fees that are charged by telephone companies, an ILEC, for instance, can receive enormous numbers of often enormously sized invoices from many different individual telecommunications service providers. Individual large companies may also receive many telecommunications services invoices for their entities. The processing of telecommunications invoices which come from many different entities with largely non-uniform billing systems, can be an extremely costly process, which may be fraught with potential billing errors.
A telecommunications carrier may send and receive thousands of invoices each month. Most of these invoices between carriers may be electronic (perhaps 60-80% depending on the carrier). There are several structured industry formats for providing electronic invoices. The structured industry formats include CABS and SECAB formats which are maintained and improved by industry associations. However, many bills are not available in these formats.
Since most companies do not have the means to create separate custom tools to accept any non-standard input format, most carriers still obtain a large proportion of bills on printed paper. Indeed, many bills are still provided in printed form as a large paper document. The result is that every telecommunications carrier spends considerable manual effort to process, audit and pay thousands of manual invoices.
Processing paper invoices is extremely time-consuming and costly. The cost of creating loading programs and maintaining them for multiple carriers is also time consuming and costly. As a result, manual invoices are often paid without any automated auditing or detailed review. The lack of detailed review results in even higher costs and processing errors to telecommunications carriers.
The present invention sets forth various exemplary embodiments of systems, methods and computer program products for extracting telecommunications invoice data from an electronic data stream, modeling and mapping the telecommunications invoice data stream into a normalized data format.
According to an exemplary embodiment of the present invention, a method may include: receiving a telecommunications invoice data stream in a first data format; analyzing the telecommunications invoice data stream to determine the first data format; modeling the telecommunications invoice data stream; and mapping the modeled telecommunications invoice data stream to a normalized data format.
According to another exemplary embodiment of the present invention, the method may include: where the modeling of the telecommunications invoice data stream further may include at least one of: creating a model for the first data format; modeling the telecommunications invoice data stream according to the model; and/or modeling the telecommunications invoice data stream with an intelligent adapter.
In yet another exemplary embodiment of the present invention, the method may further include: validating the parsed data by comparing a first telecommunications invoice generated from the telecommunications invoice data stream in the first data format with a second telecommunications invoice generated from the mapped telecommunications invoice data stream.
According to an exemplary embodiment of the present invention, the method may further include: auditing the telecommunications invoice printer data stream for billing accuracy may include at least one of: comparing telecommunications invoice charges with telecommunications invoice total cost included in the telecommunications invoice data stream; confirming field integrity; confirming numerical accuracy; and/or confirming expected field lengths.
According to an exemplary embodiment of the present invention, the method may include where the received telecommunications invoice data stream may include at least one of a non-industry standard data format and/or a captured electronic print data file.
According to an exemplary embodiment of the present invention, the method may include where the captured electronic print data file is captured at a remote site.
According to an exemplary embodiment of the present invention, the method may include where the telecommunications invoice data stream may include a electronic print data file of a telecommunications invoice.
According to an exemplary embodiment of the present invention, the method may include where the telecommunications invoice data stream may include a company telecommunications invoice data stream.
According to an exemplary embodiment of the present invention, the method may include where the first data format may include at least one of a non-industry standard data file, a PDF file, a PRN file, an LPT file, and/or a TIFF file.
According to an exemplary embodiment of the present invention, the method may include where the normalized data format may include at least one of an XTrak interchange format (xif), an extensible markup language (xml) format, an industry standard format, and/or a proprietary format.
According to an exemplary embodiment of the present invention, the method may include the step of mapping the modeled invoice data further may include at least one of: mapping the modeled telecommunications invoice data stream according to mapping codes; mapping the modeled telecommunications invoice data stream with an intelligent adapter; blending a record into a record may include a superset of fields of an industry standard record and/or mapping the modeled telecommunications invoice data stream using fuzzy logic.
According to an exemplary embodiment of the present invention, the method may include where the received telecommunications invoice data stream is received at a centralized site from a remote site.
According to an exemplary embodiment of the present invention, the method may further include: transmitting the mapped telecommunications invoice data stream to a centralized site from a remote site.
According to an exemplary embodiment of the present invention, the method may include the first data format, which may include at least one of: usage records; facilities records; switched call records; dedicated facilities records; call detail records (CDRs); facility cost records (FCRs); voice over Internet Protocol (VoIP) records; packet records; content records; ringtone records; audio records; video records; broadcast records; wireless records; CATV records; satellite records; other usage records; other facility records; and/or other charge records.
According to an exemplary embodiment of the present invention, a machine-readable medium may include providing instructions, which when executed by a computing platform, may cause the computing platform to perform operations, which may include a method, which may include: receiving a telecommunications invoice data stream in a first data format; analyzing the telecommunications invoice data stream to determine the first data format; modeling the telecommunications invoice data stream; and mapping the modeled telecommunications invoice data stream to a normalized data format.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the modeling of the telecommunications invoice data stream further may include at least one of: creating a model for the first data format; modeling the telecommunications invoice data stream according to the modeling model; and/or modeling with an intelligent adapter the telecommunications invoice data stream.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the method further may include: validating the parsed data by comparing a first telecommunications invoice generated from the telecommunications invoice data stream in the first data format with a second telecommunications invoice generated from the mapped telecommunications invoice data stream.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the method further may include: auditing the telecommunications invoice printer data stream for billing accuracy may include at least one of: comparing telecommunications invoice charges with telecommunications invoice total cost included in the telecommunications invoice data stream; confirming field integrity; confirming numerical accuracy; and/or confirming expected field lengths.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the received telecommunications invoice data stream may include a captured electronic print file.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the captured electronic print file is captured at a remote site.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the telecommunications invoice data stream may include a electronic print file of a telecommunications invoice.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the telecommunications invoice data stream may include a company telecommunications invoice data stream.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the first data format may include at least one of a non-industry standard file, a PDF file, a PRN file, an LPT file, and/or a TIFF file.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the second normalized data format may include at least one of an XTrak interchange format (xif), an extensible markup language (xml) format, an industry standard format, and/or a proprietary format.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the step of mapping the parsed invoice data further may include at least one of: mapping the modeled telecommunications invoice data stream according to mapping codes; mapping the modeled telecommunications invoice data stream with an intelligent adapter; blending a record into a record may include a superset of fields of an industry standard record and/or mapping the modeled telecommunications invoice data stream using fuzzy logic.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the received telecommunications invoice data stream is received at a centralized site from a remote site.
According to another exemplary embodiment of the present invention, the machine-readable medium may include where the method further may include: transmitting the mapped telecommunications invoice data stream to a centralized site from a remote site.
According to an exemplary embodiment of the present invention, a system may include: receiving means for receiving a telecommunications invoice data stream in a first data format; analyzing means for analyzing the telecommunications invoice data stream to determine the first data format; modeling means for modeling the telecommunications invoice data stream; and mapping means for mapping the modeled telecommunications invoice data stream to a normalized data format.
According to another exemplary embodiment of the present invention, the system may include where the modeling means further may include: means for creating a modeling model for the first data format; means for modeling the telecommunications invoice data stream according to the modeling model; means for blending a record into a record may include a superset of fields of an industry standard record; and/or means for modeling the telecommunications invoice data stream with an intelligent adapter.
According to another exemplary embodiment of the present invention, the system may further include: means for validating the parsed data by comparing a first telecommunications invoice generated from the telecommunications invoice data stream in the first printer data stream format with a second telecommunications invoice generated from the mapped telecommunications invoice data stream.
According to another exemplary embodiment of the present invention, the system may further include: means for auditing the telecommunications invoice printer data stream for billing accuracy may include at least one of: means for comparing telecommunications invoice charges with telecommunications invoice total cost included in the telecommunications invoice data stream; means for confirming field integrity; means for confirming numerical accuracy; and/or means for confirming expected field lengths.
According to another exemplary embodiment of the present invention, the system may include where the received telecommunications invoice data stream may include a captured electronic print file.
According to another exemplary embodiment of the present invention, the system may include where the captured electronic print file is captured at a remote site.
According to another exemplary embodiment of the present invention, the system may include where the telecommunications invoice data stream may include a electronic print file of a telecommunications invoice.
According to another exemplary embodiment of the present invention, the system may include where the telecommunications invoice data stream may include a company telecommunications invoice data stream.
According to another exemplary embodiment of the present invention, the system may include where the first printer data stream format may include at least one of a non-industry standard format, a PDF file, a PRN file, an LPT file, and/or a TIFF file.
According to another exemplary embodiment of the present invention, the system may include where the second normalized data format may include at least one of an XTrak interchange format (xif), an extensible markup language (xml) format, an industry standard format, and/or a proprietary format.
According to another exemplary embodiment of the present invention, the system may include where the mapping means further may include at least one of: means for mapping the modeled telecommunications invoice data stream according to mapping codes; means for mapping the modeled telecommunications invoice data stream with an intelligent adapter; and/or means for mapping the modeled telecommunications invoice data stream using fuzzy logic.
According to another exemplary embodiment of the present invention, the system may include where the received telecommunications invoice data stream is received at a centralized site from a remote site.
According to another exemplary embodiment of the present invention, the system may further include: means for transmitting the mapped telecommunications invoice data stream to a centralized site from a remote site.
Various exemplary features and advantages of the invention will be apparent from the following, more particular description of exemplary embodiments of the present invention, as illustrated in the accompanying drawings wherein like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The left most digits in the corresponding reference number indicate the drawing in which an element first appears.
A preferred exemplary embodiment of the invention is discussed in detail below. While specific exemplary embodiments are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.
Overview of the Invention
An exemplary embodiment of the present invention represents a process and software adapted to convert a telecommunications invoice and/or contract information from a large number of dissimilar formats into a single, unified, proprietary format, the *.xif format. The XTrak. Interchange format (XIF) *.xif format (also, XIF™) is a proprietary format available from TEOCO Corporation of Fairfax, Va., USA.
In addition to the structured industry formats CABS and SECAB, there may be other proprietary output formats of the sending carrier's billing systems. Examples of formats which are not the structured industry formats may include, e.g., but are not limited to: PDF, XML, PRN, Text, Excel spreadsheet format, DBF, MDB, RTF, TIFF, Word and electronic data interchange (EDI) formats. These formats require the receiving carrier to spend significant resources to process these files and to write loading programs for each file received. As a result of the effort required, most carriers opt to receive the paper version of the invoice rather than invest the IT resources necessary to create the loading programs to be able to access the non-industry formats.
The XTrak system available from TEOCO Corporation, according to an exemplary embodiment of the present invention, takes the burden of converting non-standard invoice formats off the telecommunications carrier. The exemplary embodiment of the present invention processes dissimilar formats into a single proprietary format known as XIF™ (XTrak Interchange Format). From this format, licensees of XTrak need only one loading program for all dissimilar input formats.
According to an exemplary embodiment of the present invention, first, a person with a detailed understanding of the Telecommunication Industry data and formats may analyze the different input formats and may determine the appropriate mapping the different input formats into the XIF format. The mapping process, according to an exemplary embodiment may include a process incorporating human intelligence and a working knowledge of industry standards.
Second, once the mapping is complete, an intelligent adapter may be created that may parse data out of a carrier specific format, may perform field integrity validations, and may place the information into the XIF database. The modeling program can recognize and adjust to different field locations, currencies and languages. Third, once the invoice data stream is in the XIF database, then, e.g., but not limited to, invoice and contractual data can be extracted for analysis and auditing.
According to an exemplary embodiment, XTrak may reduce carrier costs and may improve analysis, by providing a more detailed analysis of information than previously accessible to a carrier. Intelligent adapters may accelerate the process of data extraction by moving from the classic way of writing line by line parsing programs, and by moving to creating data models which hunt for the appropriate data in a file. The result is a much faster development cycle to create adaptors for the wide variety of carrier files.
According to an exemplary embodiment of the present invention, XTrak may use the latest multi-processing technologies to allow for processing of large files (greater than 1 million records) in minutes.
In an exemplary embodiment, in order to audit the invoices and to review the invoices for any errors, a system such as, e.g., but not limited to, Bill Trak Pro (BTP), available from TEOCO Corporation of Fairfax, Va., USA. The BTP system may include a BTP database 424, as shown. In order to load data into the BTP system, data must be loaded into the BTP DB 424. Industry standard invoices such as, e.g., but not limited to, EDI, CABS 402 and SECAB 404, etc. formatted data may be loaded into BTP DB 424 using an appropriate data loader 422. Unfortunately, invoice standards such as, CABS 402 and SECAB 404 continually change, and sometimes, a billing system may not use the latest industry standard format, thus even industry standard invoices may not always be easily loaded into an auditing system. Unfortunately, paper invoices also may not be loaded into a billing auditing system. Non-standard electronic invoices, conventionally may also not be imported into the BTP DB 424 bill auditing system. For most non-standard invoice formats, there is no individual data loader 422 to load the invoice data. Further, for paper invoices 406, the invoices conventionally must be scanned, the data must be recognized using, e.g., but not limited to, an optical character recognition (OCR) system, and then the results of the recognition must be proofread, since OCR conventionally is only 99.8% accurate. Although 99.8% accuracy may sound very accurate, in the case of invoice data, this level of accuracy is unacceptable, and only 100% accuracy is acceptable. For example, OCR cannot distinguish between a lower case L (l), a number one (1), a capital I. Also, OCR cannot distinguish between a zero and the letter O. Telecommunications invoices are all numbers (e.g., dollar amounts), and words, so they are difficult for OCR programs to figure out. Also, telecom invoice data amounts can be large dollar values, so one wrong digit, or a misplaced decimal point can make a big difference. Thus, any scanning and OCR of an invoice requires manual intervention. Thus, conventionally, only face pages of invoices are scanned, i.e., the first page of a bill (without any detail), and then the results of scanning, OCR and proofing 408, are required to be corrected using manual data entry and correction 410. If one only scans the face page of a bill, then payment of the paper invoice may be possible, however, almost no auditing is possible with only a face page of an invoice. Unfortunately, if one scans only the face page of an invoice, much of the invoice's information is lost and the bill auditing system then is unable to fully audit the bill.
According to an exemplary embodiment of the present invention, the print data streams of the paper invoices 406 of the 400 carriers may be intercepted and stored, prior to printing. These print data stream invoices may be thought of as quasi-electronic invoices 430, in the print data stream format. Conventional printer data stream formats may include, e.g., but not limited to, TXT, PRN, PDF, XLS, DAT, Custom formats, proprietary billing system output formats, etc. Exemplary print datastream formats appear below in Table 1. The printer datastream format electronic invoices 430 may be parsed using a parser 414 to break the data into an XTrak Invoice database 416 format, according to an exemplary embodiment of the present invention. The modeling process, according to an exemplary embodiment of the present invention may include building a modeling model using a datamining tool such as, e.g., but not limited to, a DATAWATCH® MONARCH PRO product data mining tool to map the input invoice print datastream format into a proprietary XTrak database format (XIF) format. The modeling model may be created using the datamining tool, and the mapped data may be cleaned up, and validated, using software, and/or manual data entry or correction 410, as shown. Once the modeling model has been created for a given input datastream format, then the invoice data may be mapped into the XTrak invoice data model format 420. In addition, some invoices may be created using industry standard invoice database 426 format systems such as, e.g., but not limited to, MDB, DBF, etc., for such invoice databases 426, the invoice data may be converted using a converter 428 into an XTrak Invoice database 416, according to an exemplary embodiment of the present invention.
According to an exemplary embodiment, data from XTrak invoice database 416 may be exported using XIF xPorter 418 to generate an XTrak Invoice Format (XIF) normalized invoice for input into data loader 422. Normalization may include, in an exemplary embodiment, blending data records into a single record format. In an exemplary embodiment, data records may be blended into a record which may include a superset of fields of an industry standard data format. Exemplary records which may be blended, and/or mapped, according to an exemplary embodiment, may include usage records, facilities records, switched call records, dedicated facilities records, call detail records (CDRs), facility cost records (FCRs), voice over Internet Protocol (VoIP) records, packet records, content, ringtone, audio, video, broadcast, wireless, CATV, satellite and other usage, facility and/or other charges, etc. The XTrak invoice format (XIF) invoice is a proprietary invoice format which is a robust data structure including a super set of all invoice data from CABS, SECAB, non-industry standard invoice formats, proprietary invoice formats, and any custom data from customers. An exemplary XIF layout is included below in Table 3. XIF invoice format mapping is shown below in Table 4.
According to an exemplary embodiment of the present invention, the model may be fed into a database.
According to another exemplary embodiment, the modeling model, after being constructed, may be validated to check for errors. For example, if the modeling model breaks up components of a total, as well as the total, a sum of the components may be calculated and compared to the parsed total as a validation. The modeling validation process may identify billing errors. The billing auditing system may also identify billing errors.
According to another exemplary embodiment, a user may add map code to remap data for specific customer needs.
According to an exemplary embodiment, a customer may request to customize the XIF format to include additional fields of particular interest to a customer.
According to another exemplary embodiment, the XIF format may be mapped to convert data to another format such as, e.g., but not limited to, a standard billing format, a CABS format, a SECAB format, an EDI format (such as, e.g., but not limited to, an EDI 811), an extensible markup format (XML), etc.
Supported Input File Extensions
An exemplary embodiment of the present invention may accept any of the exemplary file extensions noted in Table 1, below:
In addition to the non-standard, print data file formats noted in Table 1, in an exemplary embodiment, the present invention may also accept certain standard industry formats including those noted in Table 2, below:
According to an exemplary embodiment, the present invention may support any database system including, e.g., but not limited to, those available from Microsoft Corporation of Redmond, Wash., Oracle of Redwood Shores, Calif., IBM Corporation of Armonk, N.Y., Sybase of Dublin, Calif., Foxpro available from Microsoft, and Dbase available from dataBased Intelligence, Inc. of Vestal, N.Y. Of course these are merely examples of some common databases, and the present invention is equally applicable to any other available database, database management, or the like.
An exemplary embodiment of the XIF layout according to an exemplary embodiment of the present invention appears below in Table 3:
An Example Telecommunications Environment
The present invention is described in terms of an example environment. The example environment may include a multiple carriers telecommunications environment. In an exemplary embodiment, the carriers may use any of a range of well known circuit switched and packet switched technologies, as well as telephony, video, audio, broadcast, and/or other data. The multiple telecommunications carriers may include US domestic entities (see Definitions below in Table 4) such as, e.g., ILECs, CLECs, IXCs, NGTs and Enhanced Service Providers (ESPs), as well as global entities such as PTTs and NEs, recognized by those skilled in the art. In addition, as used herein a telecommunications system may include domestic systems used by entities such as, e.g., ILECs, CLECs, IXCs and Enhanced Service Providers (ESPs), as well as global systems recognized by those skilled in the art.
The communications systems according to exemplary embodiments of the present invention may include wireless communication systems as well as wired line communications. The present invention may also be used in packetized and voice over Internet Protocol (VoIP) communications environments.
In an exemplary embodiment, many of these entities may issue invoices to their end customers. In addition, many of these entities may also issue invoices related to intercarrier charges to one another. Exemplary, but not limiting telecommunications charges, which may include, e.g., intercarrier charges may include, e.g., but without limitation, in exemplary embodiments, call detail records (CDRs), facility cost records (FCRs), voice over Internet Protocol (VoIP) records, packet records, wireless, content, ringtone, audio, video, broadcast, and other usage, facility and other charges.
In an exemplary embodiment, call usage call detail records (CDRs) may include usage information such as, e.g., but not limited to, billing access number, the phone number, call duration, etc., and/or other invoice data records, for calls purchased at wholesale, may be sent from an IXC to a LEC in, e.g., but not limited to a data format such as, e.g., but not limited to, an EDI 811 format. The invoice data records which have been sent to the LEC may then be processed by XTrak according to an exemplary embodiment of the present invention, into a format which may be imported into Bill Track Pro. The data may be processed for validation, processing, audit, and/or payment. Similarly, other types of data records may be sent from a carrier to the LEC for processing/billing, including, e.g., broadband access, data access, VoIP, wireless download, music, ringtones, audio, video, alerts, broadcasts, packets, content, etc.
In another exemplary embodiment, facilities invoice data records may be provided from an IXC or one LEC to another LEC. Such records might include, e.g., but not limited to, mileage characteristics, rate charges, throughput characteristics, etc. and might be for a T1, a T3, an OC3, a point-to-point circuit, etc. The invoice data may then be processed according to an exemplary embodiment of the present invention and may then be, e.g., but not limited to, validated, processed, audited, and/or paid.
In the exemplary embodiment, data and voice traffic may be transported over a heterogeneous network including telecommunications equipment and facilities of any of a number of the carriers or entities.
In an exemplary embodiment, invoices may be provided in electronic form to the telecommunications invoice processing entity. In one exemplary embodiment, the invoices may be provided from at least one of the telecommunications carriers in an electronic form (e.g., transmitted electronically over a network such as, e.g., but not limited to, the Internet, and/or may be provided on a computer-readable medium such as, e.g., but not limited to, a compact disc read only memory (CD-ROM), and/or digital versatile disc (DVD), or the like. In an exemplary embodiment, the invoice data may be in a form of a print data stream, which may be intercepted for storage and/or transmission, prior to, or instead of sending to a printer. Exemplary print data streams, according to an exemplary embodiment, as shown in Table 1 above, may include, e.g., but not limited to, a text (.txt) format such as, e.g., an ASCII code, or the like, character format, a print format (.prn) such as, e.g., a MICROSOFT® WINDOWS® print file format, a MICROSOFT® database format (.mdb), a Tag image bitmap file (TIFF) (.tif), Microsoft® Excel® Spreadsheet (.xls), A dBASE file, a format originated by Ashton-Tate (.dbf), a portable document file such as, e.g., but not limited to, ADOBE® ACROBAT® format (.pdf), Borland® Paradox® 7 table database (.db), and/or a Web page, and/or a hypertext or markup language such as, e.g., but not limited, a file containing Hypertext Markup Language (HTML) (.htm), etc.
Although the invention is described in terms of this example environment, it is important to note that description in these terms is provided for purposes of illustration only. It is not intended that the invention be limited to this example environment or to the precise inter-operations between the above-noted entities and devices. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.
Table 4 below defines common telecommunications terminology. These terms are used throughout the remainder of the description of the invention.
Introduction
Exemplary Telecommunications Network
Voice Network
Simple Voice Network
Network 100 also includes a common channel interactive signaling (CCIS) network for call setup and call tear down. Specifically,
Detailed Voice Network
Telecommunications network 200 includes access tandems (AT) 206 and 208. AT 206 provides connection to points of presence (POPs) 132a, 132b, 132c and 132d. IXCs 106a, 106b and 106c provide connection between POPs 132a, 132b and 132c (in the first LATA) and POPs 134a, 134b and 134c (in the second LATA). Competitive local exchange carrier (CLEC) 214 provides an alternative connection between POP 132d and POP 134d. POPs 134a, 134b, 134c and 134d, in turn, are connected to AT 208, which provides connection to egress EO 108a. Called party 110a can receive calls from EO 108a, which is its homed EO.
Alternatively, it would be apparent to a person having ordinary skill in the art that an AT 206 can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.
Network 200 also includes calling party 102c homed to CLEC switch 104c. Following the 1996 Telecommunications Act in the U.S., CLECs gained permission to compete for access within the local RBOCs territory. RBOCs are commonly referred to as incumbent local exchange carriers (ILECs).
Network 200 further may include a fixed wireless CLEC 209. Fixed wireless CLEC 209 includes a wireless transceiver/receiver radio frequency (RF) tower 210 in communication over an RF link to a subscriber transceiver RF tower 212. Subscriber RF tower 212 is depicted coupled to a CPE box, PBX 112b. PBX 112b couples calling parties 124b and 126b, fax 116b, client computer 118b and associated modem 130b, and local area network 128b having client computer 120b and server computer 122b coupled via an associated modem 130b.
Network 200 also includes called party 110a, a fax 116a, client computer 118a and associated modem 130a, and cellular communications RF tower 202 and associated cellular subscriber called party 204, all coupled to EO 108a, as shown.
EO 104a, 108a and AT 206, 208 are part of a switching hierarchy. EO 104a is known as a class 5 office and AT 208 is a class 3/4 office switch. Prior to the divestiture of the regional Bell Operating Companies (RBOCs) from AT&T following the modified final judgment, an office classification was the number assigned to offices according to their hierarchical function in the U.S. public switched network (PSTN). An office class is a functional ranking of a telephone central office switch depending on transmission requirements and hierarchical relationship to other switching centers. A class 1 office was known as a Regional Center (RC), the highest level office, or the “office of last resort” to complete a call. A class 2 office was known as a Sectional Center (SC). A class 3 office was known as a Primary Center (PC). A class 4 office was known as either a Toll Center (TC) if operators were present, or otherwise as a Toll Point (TP). A class 5 office was an End Office (EO), i.e., a local central office, the lowest level for local and long distance switching, and was the closest to the end subscriber. Any one center handles traffic from one or more centers lower in the hierarchy. Since divestiture and with more intelligent software in switching offices, these designations have become less firm. Technology has distributed functionality closer to the end user, diffusing traditional definitions of network hierarchies and the class of switches.
Exemplary arrows are depicted illustrating exemplary invoice charges that may flow between different exemplary entities. For example, but not limited to, exemplary telecommunications charges, which may include, e.g., intercarrier charges may include, e.g., but without limitation, in exemplary embodiments, call detail records (CDRs), facility cost records (FCRs), voice over Internet Protocol (VoIP) records, packet records, wireless, content, ringtone, audio, video, broadcast, and other usage, facility and other charges. Charges on invoices may relate, e.g., but not limited to, to carriers charges, Internet service provider (ISP) charges, VoIP charges, wireless charges, content provider charges, music company charges, video company charges, broadcast content charges, alert charges, packet charges, and any other fixed and/or variable fee charges which may be included in an invoice.
Connectivity to Internet Service Providers (ISPs)
In addition to providing a voice connection from calling party 102a to called party 110a, the PSTN can provide calling party 102a a data connection to an ISP (i.e. similar to client 118b).
Network 200 can also include an Internet service provider (ISP) (not shown) which could include a server computer 122 coupled to a data network 142 as will be discussed further below with reference to
To establish a connection with an ISP, client 118b can use a host computer connected to a modem (modulator/demodulator) 130b. The modem can modulate data from the host computer into a form (traditionally an analog form) for transmission to the LEC facilities. Typically, the LEC facilities convert the incoming analog signal into a digital form. In one embodiment, the data is converted into the point-to-point protocol (PPP) format. (PPP is a well-known protocol that permits a computer to establish a connection with the Internet using a standard modem. It supports high-quality, graphical user-interfaces.) As those skilled in the art will recognize, other formats are available, including, e.g., a transmission control program, internet protocol (TCP/IP) packet format, a user datagram protocol, internet protocol (UDP/IP) packet format, an asynchronous transfer mode (ATM) cell packet format, a serial line interface protocol (SLIP) protocol format, a point-to-point (PPP) protocol format, a point-to-point tunneling protocol (PPTP) format, a NETBIOS extended user interface (NETBEUI) protocol format, an Appletalk protocol format, a DECnet, BANYAN/VINES, an internet packet exchange (IPX) protocol format, and an internet control message protocol (ICMP) protocol format.
Although perhaps not shown, the exemplary embodiments of the present invention are equally applicable to any of, e.g., but not limited to, circuit switched, packet switched, wired line, wireless, cable TV (CATV), voice over power line, etc. networks, whether voice based, cell based, analog, digital, personal area, local area, and/or wide area networks, music, video, audio, movie, broadcast, digital and analog contents.
Communications Links
Note that
EO 104a and AT 206 are connected by a trunk. A trunk connects an AT to an EO. A trunk can be called an inter machine trunk (IMT). AT 208 and EO 108a are connected by a trunk which can be an IMT.
Referring to
Trunks can handle switched voice traffic and data traffic. For example, trunks can include digital signals DS1-DS4 transmitted over T1-T4 carriers. Table 5 provides typical carriers, along with their respective digital signals, number of channels, and bandwidth capacities.
Alternatively, trunks can include optical carriers (OCs), such as OC-1, OC-3, etc. Table 6 provides typical optical carriers, along with their respective synchronous transport signals (STSs), ITU designations, and bandwidth capacities.
As noted, a private line is a connection that can carry data modem traffic. A private line can be a direct channel specifically dedicated to a customer's use between two specified points. A private line can also be known as a leased line. In one embodiment, a private line is an ISDN/primary rate interface (ISDN PRI) connection. An ISDN PRI connection can include a single signal channel (called a data or D channel) on a T1, with the remaining 23 channels being used as bearer or B channels. (Bearer channels are digital channels that bear voice and data information.) If multiple ISDN PRI lines are used, the signaling for all of the lines can be carried over a single D channel, freeing up the remaining lines to carry only bearer channels.
Telecommunications Traffic
Telecommunications traffic can be sent and received from any network node of a telecommunications carrier. A telecommunications carrier can include, for example, a LEC, a CLEC, an IXC, and an Enhanced Service Provider (ESP). In an embodiment, this traffic can be received from a network node which is, for example, a class 5 switch, such as EO 104a, or from a class 3/4 switch, such as AT 206. Alternatively, the network system can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.
Voice traffic refers, for example, to a switched voice connection between calling party 102a and called party 110a. It is important to note that this is on a point-to-point dedicated path, i.e., that bandwidth is allocated whether it is being used or not. A switched voice connection is established between calling party 102a and EO 104a, then to AT 206 then over an IXC's network such as that of IXC 106a to AT 208 and then to EO 108a and over a trunk to called party 110a. In another embodiment, AT 206 or IXC 106a can also be, for example, a CLEC, or other enhanced service provider (ESP), an international gateway or global point-of-presence (GPOP), or an intelligent peripheral.
It is possible that calling party 102a is a computer with a data connection to a server over the voice network. Data traffic refers, for example, to a data connection between a calling party 102a (using a modem) and a server 122b that could be part of an ISP. A data connection can be established, e.g., between calling party 102a and EO 104a, then to AT 206, then to CLEC 214, then over a fixed wireless CLEC 209 link to PBX 112b to a modem 130b associated with server 122b.
A voice-over-Internet Protocol (VoIP) call may also be made and telephony and other data may be delivered over a data network as shown in
SS7 Signaled Call Flow
To initiate a call in an SS7 telecommunications network, a calling party using a telephone connected to an ingress EO switch, dials a telephone number of a called party. The telephone number is passed from the telephone to the SSP at the ingress EO of the calling party's local exchange carrier (LEC). First, the SSP can process triggers and internal route rules based on satisfaction of certain criteria. Second, the SSP can initiate further signaling messages to another EO or access tandem (AT), if necessary. The signaling information can be passed from the SSP to STPs, which route the signals between the ingress EO and the terminating end office, or egress EO. The egress EO has a port designated by the telephone number of the called party. The call is set up as a direct connection between the EOs through tandem switches if no direct trunking exists or if direct trunking is full. If the call is a long distance call, i.e., between a calling party and a called party located in different local access transport areas (LATAs), then the call is connected through an inter exchange carrier (IXC) switch. Such a long distance call is commonly referred to as an inter-LATA call. LECs and IXCs are collectively referred to as the public switched telephone network (PSTN).
An Exemplary Computer System
The computer system 500 may include one or more processors, such as, e.g., but not limited to, processor(s) 504. The processor(s) 504 may be connected to a communication infrastructure 506 (e.g., but not limited to, a communications bus, cross-over bar, or network, etc.). Various exemplary software embodiments may be described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
Computer system 500 may include a display interface 502 that may forward, e.g., but not limited to, graphics, text, and other data, etc., from the communication infrastructure 506 (or from a frame buffer, etc., not shown) for display on the display unit 530.
The computer system 500 may also include, e.g., but may not be limited to, a main memory 508, random access memory (RAM), and a secondary memory 510, etc. The secondary memory 510 may include, for example, (but not limited to) a hard disk drive 512 and/or a removable storage drive 514, representing a floppy diskette drive, a magnetic tape drive, an optical disk drive, a compact disk drive CD-ROM, etc. The removable storage drive 514 may, e.g., but not limited to, read from and/or write to a removable storage unit 518 in a well known manner. Removable storage unit 518, also called a program storage device or a computer program product, may represent, e.g., but not limited to, a floppy disk, magnetic tape, optical disk, compact disk, etc. which may be read from and written to by removable storage drive 514. As will be appreciated, the removable storage unit 518 may include a computer usable storage medium having stored therein computer software and/or data.
In alternative exemplary embodiments, secondary memory 510 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 500. Such devices may include, for example, a removable storage unit 522 and an interface 520. Examples of such may include a program cartridge and cartridge interface (such as, e.g., but not limited to, those found in video game devices), a removable memory chip (such as, e.g., but not limited to, an erasable programmable read only memory (EPROM), or programmable read only memory (PROM) and associated socket, and other removable storage units 522 and interfaces 520, which may allow software and data to be transferred from the removable storage unit 522 to computer system 500.
Computer 500 may also include an input device such as, e.g., (but not limited to) a mouse or other pointing device such as a digitizer, and a keyboard or other data entry device (none of which are labeled).
Computer 500 may also include output devices, such as, e.g., (but not limited to) display 530, and display interface 502. Computer 500 may include input/output (I/O) devices such as, e.g., (but not limited to) communications interface 524, cable 528 and communications path 526, etc. These devices may include, e.g., but not limited to, a network interface card, and modems (neither are labeled). Communications interface 524 may allow software and data to be transferred between computer system 500 and external devices. Examples of communications interface 524 may include, e.g., but may not be limited to, a modem, a network interface (such as, e.g., an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 524 may be in the form of signals 528 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 524. These signals 528 may be provided to communications interface 524 via, e.g., but not limited to, a communications path 526 (e.g., but not limited to a channel). This channel 526 may carry signals 528, which may include, e.g., but not limited to, propagated signals, and may be implemented using, e.g., but not limited to, wire or cable, fiber optics, a telephone line, a cellular link, an radio frequency (RF) link and other communications channels, etc.
In this document, the terms “computer program medium” and “computer readable medium” may be used to generally refer to media such as, e.g., but not limited to removable storage drive 514, a hard disk installed in hard disk drive 512, etc. These computer program products may provide software to computer system 500 The invention may be directed to such computer program products.
References to “one embodiment,” “an embodiment,” “example embodiment,” “various embodiments,” etc., may indicate that the embodiment(s) of the invention so described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase “in one embodiment,” or “in an exemplary embodiment,” do not necessarily refer to the same embodiment, although they may.
In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However, “coupled” may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
An algorithm is here, and generally, considered to be a self-consistent sequence of acts or operations leading to a desired result. These include physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be understood, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.
In a similar manner, the term “processor” may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory. A “computing platform” may comprise one or more processors.
Embodiments of the present invention may include apparatuses for performing the operations herein. An apparatus may be specially constructed for the desired purposes, or it may comprise a general purpose device selectively activated or reconfigured by a program stored in the device.
Embodiments of the invention may be implemented in one or a combination of hardware, firmware, and software. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by a computing platform to perform the operations described herein. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others.
Computer programs (also called computer control logic), may include object oriented computer programs, and may be stored in main memory 508 and/or the secondary memory 510 and/or removable storage units 514, also called computer program products. Such computer programs, when executed, may enable the computer system 500 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, may enable the processor 504 to provide a method to resolve conflicts during data synchronization according to an exemplary embodiment of the present invention. Accordingly, such computer programs may represent controllers of the computer system 500.
In another exemplary embodiment, the invention may be directed to a computer program product comprising a computer readable medium having control logic (computer software) stored therein. The control logic, when executed by the processor 504, may cause the processor 504 to perform the functions of the invention as described herein. In another exemplary embodiment where the invention may be implemented using software, the software may be stored in a computer program product and loaded into computer system 500 using, e.g., but not limited to, removable storage drive 514, hard drive 512 or communications interface 524, etc. The control logic (software), when executed by the processor 504, may cause the processor 504 to perform the functions of the invention as described herein. The computer software may run as a standalone software application program running atop an operating system, or may be integrated into the operating system.
In yet another embodiment, the invention may be implemented primarily in hardware using, for example, but not limited to, hardware components such as application specific integrated circuits (ASICs), or one or more state machines, etc. Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
In another exemplary embodiment, the invention may be implemented primarily in firmware.
In yet another exemplary embodiment, the invention may be implemented using a combination of any of, e.g., but not limited to, hardware, firmware, and software, etc.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should instead be defined only in accordance with the following claims and their equivalents.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5325290 | Cauffman et al. | Jun 1994 | A |
| 6385301 | Nolting et al. | May 2002 | B1 |
| 6411681 | Nolting et al. | Jun 2002 | B1 |
| 6721405 | Nolting et al. | Apr 2004 | B1 |
| 6731730 | Zolotov | May 2004 | B1 |
| 6891938 | Scott et al. | May 2005 | B1 |
| 6904276 | Freeman et al. | Jun 2005 | B1 |
| 7231024 | Moisey et al. | Jun 2007 | B2 |
| 7286647 | Stormon et al. | Oct 2007 | B2 |
| 7340422 | Fisher | Mar 2008 | B2 |
| 20040049738 | Thompson et al. | Mar 2004 | A1 |
| 20040153382 | Boccuzzi et al. | Aug 2004 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20070165801 A1 | Jul 2007 | US |
