Patent Application
20190356617
Wireless communication systems have developed through various generations, including a first-generation analog wireless phone service (1G), a second-generation (2G) digital wireless phone service (including interim 2.5G and 2.75G networks) and third-generation (3G) and fourth-generation (4G) high speed data/Internet-capable wireless services. There are presently many different types of wireless communication systems in use, including Cellular and Personal Communications Service (PCS) systems. Examples of known cellular systems include the cellular Analog Advanced Mobile Phone System (AMPS), and digital cellular systems based on Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), the Global System for Mobile access (GSM) variation of TDMA, and newer hybrid digital communication systems using both TDMA and CDMA technologies.
More recently, Long Term Evolution (LTE) has been developed as a wireless communications protocol for wireless communication of high-speed data for mobile phones and other data terminals. LTE is based on GSM, and includes contributions from various GSM-related protocols such as Enhanced Data rates for GSM Evolution (EDGE), and Universal Mobile Telecommunications System (UMTS) protocols such as High-Speed Packet Access (HSPA).
Access networks using various communication protocols (e.g., 3GPP access networks such as W-CDMA, LTE, etc., or non-3GPP access networks such as WiFi, WLAN or wired LAN, etc.) can be configured to provide Internet Protocol (IP) Multimedia Subsystem (IMS) services via an IMS network managed by a mobile network operator (e.g., T-MOBILE) to users across a communications system. Users that access the IMS network to request an IMS service are assigned to one of a plurality of regional application servers or application server clusters (e.g., groups of application servers that serve the same cluster region) for supporting the requested IMS service.
One type of communication that may be supported by IMS services may be referred to as Rich Communication Services (RCS). RCS is designed to provide enhanced communications between mobile devices, including mobile devices that are supported by different operators. Among other things, RCS provides for enhanced messaging, which may include chat, file sharing, location sharing, and so forth.
The detailed description is described with reference to the accompanying figures, in which the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
Aspects of the present disclosure are directed to a rich communications services (RCS) server, computer-readable media, and processes for business chat to RCS interworking.
In one aspect, RCS combines different services defined by 3GPP and Open Mobile Alliance (OMA) with an enhanced phonebook. For example, one UE's capabilities and presence information can be discovered and displayed by another UE. RCS reuses the 3GPP-specified IMS core system as the underlying service platform taking care of issues such as authentication, authorization, registration, charging and routing.
As will be described in more detail below, an RCS server, according to aspects of the present disclosure, may be configured to provide enhanced messaging services, such as Standalone Messaging, 1-to-1 Chat, Open Group Chat, File Transfer, Content Sharing, Social Presence Information, IP Voice call, Best Effort Video call, Geolocation Exchange, Audio Messaging, Network based blacklist, and Capability Exchange, just to name a few.
Recently, some service providers (e.g., APPLE®) have begun providing business chat services to their customers. In some aspects, the service provider may maintain a business chat server that connects businesses with their customers to answer questions, schedule appointments, make payments, and more. In some examples, the business chat server makes the connection with customers possible by integrating with the business's existing customer contact center.
Through communication with the business chat server, a customer discovers a business using applications, services, and features (for example, voice-assistant, maps, web-browser, etc.), then chats with the business using a messaging app on their device.
In some aspects, the business chat server is configured to exchange messages with the business by way of a Customer Service Platform (CSP), which is a web service implemented by the business or a third party. The CSP provides an abstraction layer between the business chat server and the business's customer contact center. Using the CSP, business chat services can support any customer contact center in use by businesses.
However, the messages generated by the business chat server are often formatted according to a proprietary third-party protocol. Thus, in order to utilize the business chat services, both the customer and the business may be required to have software and/or access to software/devices that are capable of sending and receiving the proprietary messages.
For example, in some aspects, the business chat messages forwarded by a business chat server may be formatted according to the iMessage protocol developed by Apple, Inc. iMessage allows users to send texts, documents, photos, videos, contact information, and group messages to other iOS or macOS users, thus providing an alternative to standard SMS/MMS messaging for most users with devices running iOS 5 or later.
iMessage is typically accessible through a proprietary messaging application on an iPhone, iPad or iPod touch running iOS 5 or later or on a Mac running OS X Mountain Lion or later. Owners of these devices can register one or more email addresses with Apple, and, additionally, iPhone owners can register their phone numbers with Apple, provided their carrier is supported. When an iMessage is sent to a mobile number, the messaging application will check with Apple if the mobile number is set up for iMessage. If it is not, the message will seamlessly transition from iMessage to SMS.
The iMessage protocol is based on the Apple Push Notification Service (APNs)—a proprietary, binary protocol. In some aspects, a binary protocol is a protocol which is intended to be read by a machine rather than a human being, as opposed to a plain text protocol such as IRC, SMTP, or HTTP. Binary protocols have the advantage of terseness, which translates into speed of transmission and interpretation.
Accordingly, aspects of the present disclosure include an RCS server that is configured to maintain interoperability between a business chat server that generates proprietary business chat messages and one or more subscribers of a mobile network operator (MNO) that utilize RCS services. For example, the RCS server may be configured to receive a business chat message that is formatted according to a third-party proprietary protocol (e.g., iMessage, Facebook Messages, Skype for Business messages, etc.) and to convert the business chat message into an RCS message that may then be sent to the intended recipient of the business chat message. As will be described in further detail below, the RCS server may also be configured to query a profile database with at least one message attribute of the business chat message to determine an identity (ID) of the intended recipient, such that the RCS message may be sent to the correct location.
A client device, referred to herein as a user equipment (UE), may be mobile or stationary and may communicate with a radio access network (RAN) or any other appropriate network. As used herein, the term “UE” may be referred to interchangeably as an “access terminal” or “AT”, a “wireless device”, a “subscriber device”, a “subscriber terminal”, a “subscriber station”, a “user terminal” or “UT”, a “mobile terminal”, a “mobile station” and variations thereof. Generally, UEs can communicate with a core network via the RAN, and through the core network the UEs can be connected with external networks such as the Internet. Of course, other mechanisms of connecting to the core network and/or the Internet are also possible for the UEs, such as over wired access networks, WiFi networks (e.g., based on IEEE 802.11, etc.) and so on. UEs can be embodied by any of a number of types of devices including but not limited to PC cards, compact flash devices, external or internal modems, wireless or wireline phones, and so on. A communication link through which UEs can send signals to the RAN is called an uplink channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). A communication link through which the RAN can send signals to UEs is called a downlink or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.).
Referring to
The core network 140 is configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, Push-to-Talk (PTT) sessions, group communication sessions, social networking services, etc.) for UEs that can connect to the core network 140 via the RANs 120 and/or via the Internet 175, and/or to provide content (e.g., web page downloads) to the UEs.
Referring to
In some examples, the business chat server 180 is configured to provide one or more business chat services to their customers. That is, the business chat server 180 may be configured to connect businesses with their customers to answer questions, schedule appointments, make payments, and more. In some examples, business chat server 180 communicates via the Internet 175 to allow a customer to discover a business using applications, services, and features (for example, voice-assistant, maps, web-browser, etc.). The business chat server 180 then allows the customer to chat with the business using a messaging app on their device. In some aspects, the business chat server 180 is configured to send the business chat messages to the server 170 via the internet 175. In response, the server 170 may convert the business chat message into an RCS message and forward the RCS message to the business (e.g., to one or more subscribers of the MNO and/or to a Customer Service Platform (CSP) of the business).
The wireless communication network 100 may provide for multi-user to multi-device capabilities. That is, the same user may utilize multiple different devices to access the wireless communication network 100 and multiple different users may utilize the same device to access the wireless communication network 100. For example, as shown in
As mentioned above, access networks using various communication protocols (e.g., 3GPP access networks such as W-CDMA, LTE, etc., or non-3GPP access networks such as WiFi, WLAN or wired LAN, IEEE 802, IEEE 802.11, etc.) can be configured to provide Internet Protocol (IP) Multimedia Subsystem (IMS) services via an IMS network managed by a mobile network operator (MNO) to users across a communications system. Users that access the IMS network to request an IMS service are assigned to one of a plurality of regional application servers or application server clusters (e.g., groups of application servers that serve the same cluster region) for supporting the requested IMS service.
The IMS network 200 is shown as illustrating a particular set of IMS components, including a proxy call session control function (P-CSCF) 205, an interrogating CSCF (I-CSCF) 210, a serving CSCF (S-CSCF) 215 and a Home Subscriber Server (HSS) 220. The P-CSCF 205, I-CSCF 210 and S-CSCF 215 are sometimes referred to collectively as the CSCF, and the CSCF is responsible for signaling via Session Initiation Protocol (SIP) between the Transport Plane, the Control Plane, and the Application Plane of the IMS network 200.
In one aspect, P-CSCF 205 is responsible for interfacing directly with Transport Plane components and is the first point of signaling within the IMS network 200 for any end-point, such as UEs 1 . . . N. Once an end-point acquires IP connectivity, the end-point will cause a registration event to occur by first signaling to the P-CSCF 205. As the name implies, the P-CSCF 205 is a proxy for SIP messages from end-points to the rest of the IMS network 200. It is usually in a home network of the end point, but may reside in a visited network of the end point. The P-CSCF 205 will use a DNS look-up to identify a target I-CSCF 210 to send SIP messages, which could be an I-CSCF 210 in its own network or another I-CSCF across an administrative domain. The P-CSCF 205 can also be responsible for policy decisions (e.g., via an integrated or standalone Policy Decision Function (PDF) in Releases 5 or 6 of IMS, via a Policy Charging, and Resource Function (PCRF) in Release 7 of IMS, etc.).
Still referring to
The S-CSCF 215 is responsible for interfacing with the Application Servers (AS) (e.g., such as AS 1-1, 1-2 . . . 1-X in cluster region R1, or AS 2-1, 2-2 . . . 2-Y in cluster region 2, and so on) in the Application Plane. Upon receiving a registration request SIP message from an I-CSCF 210, the S-CSCF 215 will query the HSS 220 via Diameter protocol to register the terminal as being currently served by itself. Subsequent session establishment requires knowing which S-CSCF 215 is responsible for the terminal session control. As part of the registration process, the S-CSCF 215 uses credentials it obtains from the query to the HSS 220 to issue an SIP message “challenge” back to the initiating P-CSCF 205 to authenticate the terminal.
In addition to acting as a registrar, the S-CSCF 215 is also responsible for routing SIP messages to the AS allowing for the Control Plane session control to interact with the Application Plane application logic. To do this, the S-CSCF 215 uses information obtained from the HSS 220 in the form of Initial Filter Criteria (IFC) that acts as triggers against inbound session establishment requests. The IFC includes rules that define how and where SIP messages should be routed to the various application servers that may reside in the Application Plane. The S-CSCF 215 may also act on Secondary Filter Criteria (SFC) obtained from the application servers during the course of messaging with them.
In one example, a UE that requests IMS service (e.g., registration to set-up or join a VoIP session, a PTT session, a group communication session, etc.) from the IMS network 200 is assigned (or registered) to a target application server that is selected by the S-CSCF 215, as noted above. Generally, the IMS network 200 will attempt to select, as the target application server, an application server that is physically close to the UE and is also known to be capable of providing the requested IMS service.
While internal components of UEs such as the UEs 300A and 300B can be embodied with different hardware configurations, a basic high-level UE configuration for internal hardware components is shown as platform 302 in
Accordingly, an embodiment of the invention can include a UE (e.g., UE 300A, 300B, etc.) including the ability to perform the functions described herein. As will be appreciated by those skilled in the art, the various logic elements can be embodied in discrete elements, software modules executed on a processor or any combination of software and hardware to achieve the functionality disclosed herein. For example, the platform 302 is illustrated as including an RCS client module 316. In one aspect, RCS client module 316 may be configured to access an IMS network to request one or more IMS services (e.g., chat communications). With regards to chat communications, the RCS client module 316 may be configured to present a history of communications between parties. In some examples, RCS client module 316 may differentiate between outgoing messages and incoming messages, where outgoing messages are the messages sent by the user of the device and incoming messages are the messages received from other users. For example, outgoing messages may be displayed on one side of a display window and incoming messages may be displayed on the other side of the display window. In the case where multiple devices are associated with a single user, all communications originating from that user should be shown as outgoing, regardless of which of the user's devices actually sent the message and regardless of which of his or her devices the user is currently using.
Thus, in some aspects, the ASIC 308, memory 312, API 309, local database 314, and RCS client module 316 may all be used cooperatively to load, store and execute the various functions disclosed herein and thus the logic to perform these functions may be distributed over various elements. Alternatively, the functionality could be incorporated into one discrete component. Therefore, the features of the UEs 300A and 300B in
The wireless communication between the UEs 300A and/or 300B and the RAN 120 can be based on different technologies, such as CDMA, W-CDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDM), GSM, or other protocols that may be used in a wireless communications network or a data communications network. Voice transmission and/or data can be transmitted to the UEs from the RAN using a variety of networks and configurations. Accordingly, the illustrations provided herein are not intended to limit the embodiments of the invention and are merely to aid in the description of aspects of embodiments of the invention.
The RCS server 402 may include at least one communication device (represented by the communication device 404) for communicating with other nodes. For example, the communication device 404 may comprise a network interface that is configured to communicate with one or more network entities via wire-based or wireless links. In some aspects, the communication device 404 may be implemented as a transceiver configured to support wire-based or wireless signal communication. This communication may involve, for example, sending and receiving: messages, parameters, or other types of information. Accordingly, in the example of
The RCS server 402 may also include other components that may be used in conjunction with the operations as taught herein. For example, the RCS server 402 may include hardware 410, one or more processors 412, memory 414, and a user interface 426.
The hardware 410 may include additional hardware interfaces, data communications, and/or data storage hardware. For example, the hardware interfaces may include a data output device (e.g., visual display, audio speakers), and one or more data input devices. The data input devices may include, but are not limited to, combinations of one or more of keypads, keyboards, mouse devices, touch screens that accept gestures, microphones, voice or speech recognition devices, and any other suitable devices.
In addition, the RCS server 402 may include a user interface 426 for providing indications (e.g., audible and/or visual indications) to a user and/or for receiving user input (e.g., upon user actuation of a sensing device such a keypad, a touch screen, a microphone, and so on).
The memory 414 may be implemented using computer-readable media, such as computer storage media. Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media. Computer storage media includes volatile and non-volatile, removable and non-removable, and non-transitory media, implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), high-definition multimedia/data storage disks, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism.
The processor 412 of server 402 may execute instructions and perform tasks under the direction of software components that are stored in memory 414. For example, the memory 414 may store various software components that are executable or accessible by the one or more processors 412 of the server 402. The various components may include software 416, a business chat message to RCS converter 418, a RCS message to business chat converter 420, and a user ID module 422.
The software 416, business chat message to RCS converter 418, RCS message to business chat converter 420, and user ID module 422 may include routines, program instructions, objects, and/or data structures that perform particular tasks or implement particular abstract data types. For example, the business chat message to RCS converter 418 may include one or more instructions, which when executed by the one or more processors 412 direct the RCS server 402 to perform operations related to converting a business chat message 432 that is formatted according to a third-party proprietary protocol into an RCS message 434. In some aspects, the RCS message 434 generated by the business chat message to RCS converter 418 is a session initiation protocol (SIP) message or message relay protocol (MSRP) message.
In one aspect, the business chat messages 432 are formatted according to the third-party protocol to include a plurality of message attributes (e.g., content-type, content-encoding, source-id, destination-id, etc.). Thus, the business chat message to RCS converter 418 may be configured to map the message attributes to message parameters of the RCS message 434. Table 1, below, illustrates an example mapping of a business chat message (e.g., iMessage) attributes to RCS message parameters that may be utilized by the business chat message to RCS converter 418.
As shown in TABLE 1, the mapping of message attributes to message parameters may include converting a hyper-text transfer protocol (HTTP) header or a JavaScript Object Notation (JSON) value of the iMessage into at least one of a common presence and instant messaging (CPIM) header, a CPIM body, a session initiation protocol (SIP) header, a SIP uniform resource identifier (URI), or a message session relay protocol (MSRP) value of an RCS message. For example, as shown in TABLE 1, the “sourceid” attribute of an iMessage may include a JSON value which is converted into the “P-Asserted-Identity” parameter formatted in a SIP header of the RCS message 434.
In some examples, a single iMessage attribute is mapped to a plurality of RCS parameters. In another example, several iMessage attributes are mapped to a single RCS parameter. In yet another example, one or more iMessage attributes may be ignored (i.e., not mapped) as information contained in the iMessage attribute is unnecessary to generate a corresponding RCS message 434.
Still referring to
In some aspects, the RCS message 438 received by the RCS to business chat converter 420 is a session initiation protocol (SIP) message or a message relay protocol (MSRP) message.
In one aspect, the RCS to Business chat converter 420 is configured to format the generated business chat message 436 according to the third-party protocol to include a plurality of message attributes (e.g., content-type, content-encoding, source-id, destination-id, etc.). Thus, the RCS to business chat converter 420 may be configured to map the message parameters of the RCS message 438 to message attributes of the business chat message 436. Table 2, below, illustrates an example mapping of RCS message parameters to business chat message attributes (e.g., attributes of an iMessage) that may be utilized by the RCS to business chat converter 420.
As shown in TABLE 2, the mapping of message parameters to message attributes may include converting one or more of a CPIM header, a CPIM body, a SIP header, a SIP URI, or a MSRP value of RCS message 438. For example, as shown in TABLE 2, the “P-Asserted-Identity” parameter formatted in a SIP header of the RCS message 438 is converted into the “sourceid” attribute of an iMessage that includes a JSON value.
In some examples, a single RCS parameter is mapped to a plurality of iMessage attributes. In another example, several RCS parameters are mapped to a single iMessage attribute. In yet another example, one or more RCS parameters may be ignored (i.e., not mapped).
In some examples, the ID of the intended recipient is a Uniform Resource Identifier (URI) associated with a subscriber of the MNO. In another example, the ID is a Mobile Station International Subscriber Directory Number (MSISDN) associated with the subscriber. Once the ID is obtained, the RCS message 434 may then be sent to the intended recipient based on the ID. In some aspects, the RCS message 434 is transmitted to the intended recipient via any of the various interfaces illustrated in the communications network 100 of
In a process block 508, the user ID module 422 receives a message attribute 440 from the business chat server 180 and then queries the profile database 430 with the message attribute 440 to obtain an ID of the intended recipient of the business chat message 432. As discussed above, the message attribute may include the destinationID included in the business chat message 432 and the ID obtained from the profile database 430 may include a URI and/or a MSISDN of a subscriber of the MNO. In another example, the obtained ID may include an email address of the subscriber. In process block 510, the RCS server 402 sends the RCS message 434 to the intended recipient based on the obtained ID. In some situations, the intended recipient is a business and thus sending the RCS message 434 to the intended recipient may include sending/routing the RCS message 434 to a customer service platform of the business.
In one example, mapping the message parameters to message attributes may include the RCS to business chat converter 420 converting the message parameters according to TABLE 2, listed above. In a process block 608, the RCS server 402 then sends the business chat message 436 to the business chat server 180. As mentioned above, the received business chat message 432 (e.g., process block 502 of
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.
