System, method, and computer readable medium for establishing communication between devices

Abstract

A system, method, and computer readable medium for establishing communication between two devices comprises connecting, by a first computer, to an open source Private Branch Exchange (PBX) platform via a port, receiving a phone number sent by a first one of the two devices at the open source PBX platform, invoking an interface module by the open source PBX platform, where the interface module resides on the open source PBX platform, and building a Calling Name request by the interface module related to the received phone number.

Claims

1. A method, comprising: receiving a phone number at an open source Private Branch Exchange (PBX) platform; and sending, via an interface module invoked by the open source PBX platform, a secure HyperText Transfer Protocol (HTTP) Calling Name request to a data repository separate from the open source PBX platform.

2. The method of claim 1, further comprising calling a function, by the interface module, based on the secure HTTP request.

3. The method of claim 2, wherein sending the secure HTTP request to a data repository comprises sending the secure HTTP request to a database.

4. The method of claim 3, further comprising receiving a response including the Calling Name to the secure HTTP request at the interface module.

5. The method of claim 4, further comprising receiving the Calling Name at the open source PBX platform.

6. The method of claim 5, further comprising sending, by the open source PBX platform, the Calling Name and the received phone number to a device.

7. The method of claim 6, further comprising displaying the Calling Name and the received phone number on the device.

8. The method of claim 7, further comprising establishing communication between the device and another device.

9. The method of claim 1, further comprising connecting, by a computer, to the open source Private Branch Exchange (PBX) platform, via a port, wherein the port comprises an IP (Internet Protocol) port.

10. The method of claim 9, further comprising monitoring the port, by the open source PBX platform, for any activity.

11. The method of claim 1, further comprising entering the phone number into a phone calling capability.

12. The method of claim 11, further comprising receiving the phone number at the open source PBX platform from the phone calling capability via the port.

13. The method of claim 1, wherein the interface module and the open source PBX platform reside on a server.

14. The method of claim 1, wherein communication is established between a plurality of devices.

15. The method of claim 1, wherein the interface module resides on the open source PBX platform.

16. The method of claim 1, further comprising building the secure HTTP request at the interface module invoked by the open source PBX platform.

17. A memory unit comprising instructions that, when executed by a machine, cause the machine to: receive data a phone number an open source PBX platform; and send, via an interface module invoked by the open source PBX platform, a secure HyperText Transfer Protocol (HTTP) Calling Name request to a data repository separate from the open source PBX platform.

18. The memory unit of claim 17, wherein the instructions further cause the machine to establish communication between at least two devices based on the received response.

19. A system, comprising: a server comprising an open source Private Branch Exchange (PBX) platform; and an interface module; wherein the open source PBX platform is configured to receive a phone number; wherein the interface module is configured to send a secure HyperText Transfer Protocol (HTTP) Calling Name request to a data repository separate from the open source PBX platform.

20. The system of claim 19 wherein the request comprises at least one of: a CNAME transaction type that returns a Calling Name; a TBNA transaction type that returns Name & Address data; a WTN transaction type that checks for a Working Telephone Number; a BNS transaction type that returns LIDB raw data; and a CC1 transaction type that returns Local Exchange Carrier (LEC) Calling Card data.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 depicts a diagram of a system in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

(2) The present invention provides the ability to establish communication between at least two devices such as between two computers, between a computer and a server, between a computer and a cellular phone or Internet Protocol (IP) enabled phone, between a computer and another IP device, between two IP devices, between two mobile devices, or between two or more devices that can receive and/or transmit information.

(3) The present invention further utilizes certain open source software in a unique manner as well as other unique information related to a caller, a phone number, or other identifier or information to assist in the establishing of such communication.

(4) Referring now to FIG. 1, a system 10 of the present invention includes a first computer 12 with phone calling software or capability 14 and a server 16 running an operating system (such as the Linux operating system) that includes a communications platform 18 (such as the Asterix software or platform) which includes an interface module 20. Asterisk is an open-source Private Branch Exchange (PBX) software application that runs on various operating systems and provides all of the features you would expect from a PBX and more. Asterisk provides Voice over IP (VoIP) in many protocols, and can interoperate with almost all standards-based telephony equipment using relatively inexpensive hardware. Asterisk provides voicemail services with Directory, Call Conferencing, Interactive Voice Response and Call Queuing. It has support for three-way calling, caller ID services, ADSI, SIP and H.323 (as both client and gateway).

(5) The system 10 further includes a data network 22 (such as the Internet), a database 24 and second computer 26 with phone calling software or capability 28. A number of different devices may be utilized instead of a computer such as a cellular phone, a laptop computer, a personal digital assistant, an email-messaging device, or any electronic device capable of sending and/or receiving information, without departing from the scope of the present invention. Further, although depicted as physical connections (such as VoIP connections), the first computer 12, the server 16, the data network 22, the database 24 and the second computer 26 may send and/or receive information wirelessly.

(6) In operation, the first computer 12 connects (1) to the Asterisk platform 18 via an IP port (not shown). The Asterisk software listens in or monitors the port for any activity. A phone number is entered into the phone calling software or capability 14 and that phone number is sent (2) to the Asterisk platform 18 via the port. In other embodiments, other data can be entered such as an email address or other identifier which may or may not be translated into a phone number without departing from the scope of the present invention. The Asterisk platform 18 then calls or invokes (3) the interface module 20 which builds (4) a request to provide a Calling Name (CNAM) related to the entered phone number. CNAM service, such as that provided by Accudata Technologies, Inc., retrieves stored names associated with a telephone number. This allows exchange carriers and wireless providers to display a name from an inbound call originating anywhere in the North American Numbering Plan area. In the present invention, utilizing Asterisk, VoIP service providers can deliver Calling Name for Caller ID devices that are IP enabled.

(7) The server 16, can accept a number of query types such as:

(8) a CNM2 or CNAME transaction type which returns a Calling Name;

(9) a TBNA transaction type which returns Name & Address data;

(10) a WTN transaction type which checks for a Working Telephone Number;

(11) a BNS transaction type which returns LIDB raw data; and

(12) a CC1 transaction type which returns Local Exchange Carrier (LEC) Calling Card data.

(13) The request is preferably an https request (but can be another type of request) and an example of such a request appears below for each of the query types:

(14) CNM2 Example:

(15) https://www.accudatatech.us/ACNM122104/servlet/query?&Cust=XXXXXXXX&OID=0000000000000000009&TransType=CNM2&BTN=9723902610

(16) TBNA Example:

(17) http://www.accudatatech.us/ACNM122104/servlet/query?&Cust=XXXXXXXX&OID=0000000000000000019&TransType=TBNA&BTN=9723902610

(18) Working Telephone Number (WTN) Example:

(19) https://www.accudatatech.us/LIDB080304/servlet/query?&Cust=XXXXXXXX&OID=0000000000000000009&TransType=WTN&BTN=9723902610

(20) LIDB Raw Data (BNS) Example:

(21) https://www.accudatatech.us/LIDB080304/servlet/query?&Cust=XXXXXXXX&OID=0000000000000000009&TransType=BNS&BTN=9723902610

(22) CC1 Example:

(23) http://www.accudatatech.us/LIDB080304/servlet/query?&Cust=XXXXXXXX&OID=0000000000000000009&TransType=CC1&BTN=97239026101234

(24) In the above requests: CUST is a customer number that is issued by the CNAM service provider to identify who the customer is; OID is a unique alphanumeric ID issued by a user of the present invention.
For example,

(25) the OID can reflect a particular query request; BTN or Bill To Number is a ten digit phone number; and ACNM122104 and LIDB080304 is an example of a folder name that the application or software of the present invention resides in.

(26) The following paragraphs describe in more detail the query (or transaction) types.

(27) WTN Transaction Type

(28) When the server receives a 10 digits phone number with type WTN, it sends the number to the LIDB to determine if the number is a working telephone number. If the LIDB returns a valid response then the sent phone number is a working number, or Active. Other LIDB responses will be determined if the number is Unknown or Inactive. The reply field contains Active, Inactive, or Unknown. The verbal field identifies any error message if any.

(29) The server returns the data in the following format for an active Telephone Number: HTTP Response Status Header: 200 OK

(30) HTTP Body Content:

(31) Response for 2149227066:

(32) Cust=XXXXXXXX&OID=0000000000000000012&Type=WTN&BTN=2149227066&Reply=Active&Verbal=

(33) Response for an unknown number, 9285566732:

(34) Cust=IN_HOUSE&OID=0000000000000000012&Type=WTN&BTN=9285566732&Reply=Unknown&Verbal=

(35) Response for an inactive number, 9721234000:

(36) Cust=IN_HOUSE&OID=0000000000000000012&Type=WTN&BTN=9721234000&Reply=Inactive&Verbal=

(37) Input Field Definitions:

(38) Cust: 8 bytes

(39) OID: 19 bytes unique id

(40) TransType: 3 bytes

(41) BTN: 10 digits phone number

(42) Output Field Definitions:

(43) Cust: 8 bytes

(44) OID: 19 bytes unique id

(45) Type: 3 bytes

(46) BTN: 10 digits phone number

(47) Reply: Active, Inactive, or Unknown

(48) Verbal: Not FoundThe LIDB where the number is supposed to be stored does not have information about the number Time OutNo response from LIDB within the millisecond threshold Link downNetwork problem, please call Accudata Not in LIDBThere is not any routing information to a LIDB. The number is not routable.

(49) CNM Transaction Type

(50) The server returns the following data in the reply field: Generic Name, Availability, Presentation.

(51) Generic Name: Calling Name

(52) The value for Availability and Presentation fields are as follow:

(53) Availability: 0Name available

(54) 1Name not available

(55) 2For Future use

(56) 3No response from CNAME database

(57) 4The phone number is not routable

(58) 5With the following values: 1. City State ex: Queens N.Y. 2. City State ex: Denver Colo. //2 spaces between City and State 3. State Call ex: Michigan Call 4. City State ex: Portland Oreg. //1 space between City and State

(59) 6With the following values: NOT PROVIDED WIRELESS PAY PHONE PAYPHONE, CELLUL, CELLULA, or CELLULR on the right most CELLULAR on the left most.

(60) Presentation: 0Allowed 1Restricted 2For Future use
Response for 2146440557:

(61) HTTP Response Status Header: 200 OK

(62) HTTP Body Content:

(63) Cust=XXXXXXXX&OID=0000000000000000009&Type=CNM&BTN=2146440577&Reply=REVNUE COMMUNI,0,0&Verbal=

(64) Response for 6167969758:

(65) Cust=XXXXXXXX&OID=0000000000000000009&Type=CNM&BTN=6167969758&Reply=MICHIGAN CALL,5,0&Verbal=

(66) Response for 5123966648:

(67) Cust=XXXXXXXX&OID=0000000000000000009&Type=CNM&BTN=5123966648&Reply=,3,0&Verbal=Not Found

(68) Input Field Definitions:

(69) Cust: 8 bytes

(70) OID: 19 bytes unique id

(71) TransType: 3 bytes

(72) BTN: 10 digits phone number

(73) Output Field Definitions:

(74) Cust: 8 bytes

(75) OID: 19 bytes unique id

(76) Type: 3 bytes

(77) BTN: 10 digits phone number

(78) Reply: Generic Name,Availability,Presentation Generic Name: 15 bytes Availability: 1 byte Presentation: 1 byte

(79) Verbal: Not FoundThe LIDB where the number is supposed to be stored does not have information about the number Time OutNo response from LIDB within the millisecond threshold Link downNetwork problem, please call Accudata Not in LIDBThere is not any routing information to a LIDB. The number is not routable.

(80) BNS Transaction Type

(81) For transaction type of BNS, the server returns the following data (comma separated) in the reply field: Account Owner, Billing Service Provider, Collect Acceptance Indicator, Intercept Indicator, OCN, RAO, Record Status Indicator, Service/Equipment Indicator, Third Number Acceptance Indicator, Treatment Indicator.

(82) Response for 2146440557:

(83) HTTP Response Status Header: 200 OK

(84) HTTP Body Content:

(85) Cust=XXXXXXXX&OID=0000000000000000009&Type=BNS&BTN=2146440577&Reply=2152,,3,1,2313,998,1,1,6,1&Verbal=

(86) Response for 6167969758:

(87) Cust=XXXXXXXX&OID=0000000000000000009&Type=BNS&BTN=6167969758&Reply=, , , , , , , , ,&Verbal=No Found

(88) Response for 6105858256:

(89) Cust=XXXXXXXX&OID=0000000000000000009&Type=BNS&BTN=6105858256&Reply=, , , , , , , , ,&Verbal=Not in LIDB

(90) Input Field Definitions:

(91) Cust: 8 bytes

(92) OID: 19 bytes unique id

(93) TransType: 3 bytes

(94) CardNum: 10 digits phone number

(95) Output Field Definitions:

(96) Cust: 8 bytes

(97) OID: 19 bytes unique id

(98) Type: 3 bytes

(99) Reply: 10 comma-separated fields. The order of the data is:

(100) TABLE-US-00001 Field Length 1. Account Owner 4 bytes (alphanumeric) 2. Billing Service Provider 3-4 bytes (alphanumeric) 3. Collect Acceptance Indicator 1-2 bytes 4. Intercept Indicator 1-2 bytes 5. OCN 4 bytes 6. RAO 3-4 bytes 7. Record Status Indicator 1-2 bytes 8. Service/Equipment Indicator 1-2 bytes 9. Third Number Acceptance Indicator 1-2 bytes 10. Treatment Indicator 1-2 bytes

(101) Verbal: Not FoundThe LIDB where the number is supposed to be stored does not have information about the number Time OutNo response from LIDB within the millisecond threshold Link downNetwork problem, please call Accudata Not in LIDBThere is not any routing information to a LIDB. The number is not routable.

(102) CC1 Transaction Type

(103) The server returns the following data in the reply field: CSDI, CCASN, PSDI, PIN Restriction Indicator, Company ID, Record Status Indicator, RAO, Account Owner, BSP.

(104) Response for Calling Card of 9723902610, pin=1234:

(105) HTTP Response Status Header: 200 OK

(106) HTTP Body Content:

(107) Cust=XXXXXXXX&OID=0000000000000000009&Type=CC1&BTN=97239026101234&Reply=, , , , , , , , , &Verbal=Not Found

(108) Response for 9036755151, pin=XXXX:

(109) Cust=XXXXXXXX&OID=0000000000000000009&Type=CC1&BTN=9036755151XXXX&Reply=2,01,1,1,0001,1,497,2084,&Verbal=

(110) Response for 9721234000, pin=1234:

(111) Cust=XXXXXXXX&OID=0000000000000000009&Type=CC1&BTN=972123400001234&Reply=, , , , , , , , , &Verbal=Not in LIDB

(112) Input Field Definitions: Cust: 8 bytes OID: 19 bytes unique id TransType: 3 bytes BTN: 10 digits phone number+4 digits pin

(113) Output Field Definitions: Cust: 8 bytes OID: 19 bytes unique id Type: 3 bytes BTN: 14 bytes Reply: 9 comma-separated fields. The order of the data is:

(114) TABLE-US-00002 Field Length 1. Calling Card Service Denial Indicator 1-2 bytes 2. Calling Card Sub-Account Number 1-20 bytes 3. Pin Service Denial Indicator 1-2 bytes 4. Pin Restriction Indicator 1-2 bytes 5. Company Id 4 bytes 6. Record Status Indicator 1-2 bytes 7. RAO 3-4 bytes (alphanumeric) 8. Account Owner 4 bytes (alphanumeric) 9. Billing Service Provider 3-4 bytes (alphanumeric)

(115) Verbal: Not FoundThe LIDB where the number is supposed to be stored, does not have information about the number Time OutNo response from LIDB within the millisecond threshold Link DownNetwork problem, please call. Not in LIDBThere is not any routing information to a LIDB. The number is not routable.

(116) Reply Fields Definitions: CSDI: indicates the reason the account number was denied: 1No Pins assigned 2No service denial 3Service denial CCANS: contains the code used on a customer's bill to distinguish the various users of an account number of a Calling Card, each associated with a different PIN: Example: 011.sup.st account PSDI: indicates the reason the PIN was denied: 1No service denial 2Service denial on PIN due to threshold exceeded 3Service denial on PIN due to nonpayment 4Service denial on PIN due to service restriction PIN Restriction Indicator: whether or not a PIN is restricted: 0Screened data 1Unrestricted PIN 2Restricted PIN 3N-Number Restriction 4Domestic Restriction 5Reserved Company ID: Identifies the telephone company with which the data is to be associated. Record Status Indicator: Provides status information regarding a particular record: 0Screened data 1stable recordBNA available 2stable recordBNA not available 3transitional recordBNA available 4transitional recordBNA not available 5default recordBNA available 6default recordBNA not available RAO: Revenue Account Office Account Owner: Specifies the identity of AO. Billing Service Provider: Specifies the identity of the Billing Service Provider. Logic to verify valid Calling Card: The fields to use and the order of checking are CSDI, PSDI, and PIN Restriction Indicator.

(117) TBNA Transaction Type

(118) The server returns the following data fields (in bold):

(119) Cust=XXXXXXXX&OID=0000000000000000001&Type=TBNA&BTN=9723902610&LastName=ACCUDATATECH&FirstName=&Address=206 McDermott Dr&City=Allen&State=TX&ZipCode=75013&Verbal=

(120) For a business address, the name of the business is in the LastName field.

(121) When the telephone number provided is not enough information to generate a complete address, a question mark is generated. An example of the most common case is: the correct street address is 131 N MAIN ST but the system can only determine that the primary address is an odd building number within the 100 block of North Main Street. In this case the returned address will be 1?? N MAIN ST, the primary address is incomplete.

Example

(122) A phone number with mailable address:

(123) Cust=XXXXXXXX&OID=0000000000000000001&Type=TBNA&BTN=4012734037&LastName=&FirstName=&Address=82 Tobey St&City=Providence&State=RI&ZipCode=02909&Verbal=

(124) For a phone number without any information, the verbal field is populated with Listing not available:

(125) HTTP Response Status Header: 200 OK

(126) Cust=XXXXXXXX&OID=0000000000000000001&Type=TBNA&BTN=2140000000&LastName=&FirstName=&Address=&City=&State=&ZipCode=&Verbal=Listing not available

(127) For a phone number with partial information, the Verbal field is populated with Not Mailable:

(128) HTTP Response Status Header: 200 OK

(129) Cust=XXXXXXXX&OID=0000000000000000001&Type=TBNA&BTN=9729798865&LastName=&FirstName=&Address=&City=Dallas&State=TX&ZipCode=75212&Verbal=Not Mailable

(130) Input Field Definitions:

(131) Cust: 8 bytes

(132) OID: 19 bytes unique id (alphanumeric)

(133) TransType: 3 bytes

(134) BTN: 10 digits phone number

(135) Output Field Definitions:

(136) Cust: 8 bytes

(137) OID: 19 bytes unique id

(138) Type: 3 bytes

(139) BTN: 10 digits phone number

(140) LastName: max len of 20 bytes, for business name the max len is 55 bytes

(141) FirstName: max length of 20 bytes

(142) Address: max length of 42 bytes

(143) City: max length of 28 bytes

(144) State: max length of 2 bytes

(145) ZipCode: max length of 5 bytes

(146) Verbal: Listing not availableAddress information is not available Not mailableNot enough address data for mailing or question mark in address data. Time OutNo response from vendor within the millisecond threshold Link downNetwork problem, please call Accudata

(147) Error Messages

(148) The following is a list of error messages that can be returned by the server:

(149) Output Field Definitions:

(150) Cust: 8 bytes

(151) OID: 19 bytes unique id

(152) Type: 3 bytes

(153) BTN: 10 digits phone number

(154) Reply: Error

(155) Verbal: Invalid Customer number Invalid phone number Invalid Pin number Invalid Transaction Type NoCustomerID MissingOrBadOID InternalErrorproblem with software, please call MissingOrInvalidBtn InvalidTransType

Example

(156) Response for Invalid Customer number: HTTP Response Status Header: 200 OK HTTP Body Content: Cust=12&OID=0000000000000000009&Type=CNM&BTN=XXXXXXXXXX&Reply=Error&Verbal=Invalid Customer Number Response for Invalid phone number: HTTP Response Status Header: 200 OK HTTP Body Content: Cust=XXXXXXXX&OID=0000000000000000009&Type=CNM&BTN=XXXXXXXXXXX&Reply=Error&Verbal=MissingOrInvalidBtn

(157) Referring again to FIG. 1, the interface module 20 calls (5) a Linux function based on the HTTP request being sent to a particular server, potentially over the Internet 22. The Linux function then sends (6) out the HTTP request to the database or other repository 24 (which may be stored on a server (not shown) and accessed, for example, by inputting a URL as depicted above). The server may be a Line Information Database (LIDB) server, an Accuname server (which offers similar information as a LIDB server to provide CNAM data and LIDB data but is typically less expensive to access), or another server that builds an HTTP response and sends (7) the response to the interface module 20. The response is preferably an https response (but can be another type of response) and examples of such a response were described above.

(158) The caller name is then sent (8) to the Asterisk platform 18 which sends (9) the name and the phone number to the second computer 26 where they are displayed via the phone calling software or capability 28. At this point, a connection (10) to allow voice, data, and/or multimedia data is established between the phone calling software or capability 14 and the phone calling software or capability 28 via the Asterisk platform 18.

(159) Although an exemplary embodiment of the system and method of the present invention has been illustrated in the accompanied drawings and described in the foregoing detailed description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the spirit of the invention as set forth and defined by the following claims. For example, although the Asterisk platform was described herein, any other open source platform could be utilized without departing from the scope of the present invention. Further, a greater or lesser numbers of elements can be used in the request, different elements can be used in the request (for example, instead of an AsteriskCNM or CNAM, an Accuname request, which is a lower cost IP based alternative to CNAM, can be sent), the length of the elements can be altered (for example, a seven digit phone number can be used), the sources of the information that comprise the elements can differ, and the location of the elements can differ (for example, the interface module can be located partially in or apart from the Asterisk platform without departing from the scope of the present invention. Also, the information sent between various modules (including the originating source and the end office), can be sent between the modules via at least one of a data network, the Internet, an Internet Protocol network, a wireless source, and a wired source and via plurality of protocols.