Virtual communication service for mobile devices

One example method of operation may include identifying a failed call connection via a notification identifying a calling device and a called device stored in a carrier network, and responsive to identifying the notification, transmitting an invocation request to a virtual computing network comprising a plurality of virtual machines, selecting a virtual machine corresponding to the called device, selecting a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine, initiating a virtual mobile device application associated with the virtual mobile device, and responsive to initiating the virtual mobile device application, transmitting one or more of a first message to the called device and a second message to the calling device.

TECHNICAL FIELD OF THE APPLICATION

This application relates to providing an alternative communication platform for mobile device, and more specifically to a virtual communication service for mobile devices.

BACKGROUND OF THE APPLICATION

Conventionally, mobile devices operate on mobile device carrier networks which provide cellular and/or data services to mobile devices which can communicate with the carrier networks. When a mobile device is outside of its carrier network communication range, the device may appear out of service and may not provide call, text, data messaging, GPS, and other services which are commonly available when the mobile device is operational and in communication with a service providing network. Mobile devices are computers which can communicate with other data networks, such as WIFI hotspots and other data networks other than just a more commonly relied upon carrier network. Advanced software tools, such as DOCKER ‘CONTAINERS’ or virtual machines may be setup in advance to process missed calls and alternative communication strategies via call management applications.

SUMMARY OF THE APPLICATION

Example embodiments of the present application provide at least a method that includes one or more of identifying a call communication intended for a called device, determining the call communication resulted in a failed call connection, responsive to identifying the failed call connection, invoking a virtual mobile device application operating on a virtual machine, executing a master file stored in the virtual machine, and responsive to executing the master file, transmitting a communication message to the called device.

Another example embodiment may include an apparatus that includes a processor configured to identify a call communication intended for a called device, determine the call communication resulted in a failed call connection, responsive to the failed call connection, invoke a virtual mobile device application operating on a virtual machine, execute a master file stored in the virtual machine, and a transmitter configured to transmit a communication message to the called device responsive to execution of the master file.

Still another example embodiment may include a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform identifying a call communication intended for a called device, determining the call communication resulted in a failed call connection, responsive to identifying the failed call connection, invoking a virtual mobile device application operating on a virtual machine, executing a master file stored in the virtual machine, and responsive to executing the master file, transmitting a communication message to the called device.

Yet another example embodiment may include a method configured to perform one or more of identifying a failed call connection via a notification identifying a calling device and a called device stored in a carrier network, and responsive to identifying the notification, transmitting an invocation request to a virtual computing network comprising a plurality of virtual machines, selecting a virtual machine corresponding to the called device, selecting a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine, initiating a virtual mobile device application associated with the virtual mobile device, and responsive to initiating the virtual mobile device application, transmitting one or more of a first message to the called device and a second message to the calling device.

Yet another example embodiment may include an apparatus having a processor configured to perform one or more of identify a failed call connection via a notification identifying a calling device and a called device stored in a carrier network, and a transmitter configured to, responsive to the notification being identified, transmit an invocation request to a virtual computing network comprising a plurality of virtual machines, and the processor is further configured to select a virtual machine corresponding to the called device, select a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine, initiate a virtual mobile device application associated with the virtual mobile device, and responsive to the virtual mobile device application being initiated, the transmitter is further configured to transmit one or more of a first message to the called device and a second message to the calling device.

Yet another example embodiment may include a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform one or more of identifying a failed call connection via a notification identifying a calling device and a called device stored in a carrier network, and responsive to identifying the notification, transmitting an invocation request to a virtual computing network comprising a plurality of virtual machines, selecting a virtual machine corresponding to the called device, selecting a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine, initiating a virtual mobile device application associated with the virtual mobile device, and responsive to initiating the virtual mobile device application, transmitting one or more of a first message to the called device and a second message to the calling device.

DETAILED DESCRIPTION OF THE APPLICATION

In addition, while the term “message” has been used in the description of embodiments of the present application, the application may be applied to many types of network data, such as, packet, frame, datagram, etc. For purposes of this application, the term “message” also includes packet, frame, datagram, and any equivalents thereof. Furthermore, while certain types of messages and signaling are depicted in exemplary embodiments of the application, the application is not limited to a certain type of message, and the application is not limited to a certain type of signaling.

Example embodiments provide for methods, processes, devices, systems and non-transitory computer readable mediums which execute instructions to provide communication support for mobile devices operating outside of a carrier network. For example, when a call fails to connect a calling device with a called device (i.e., ‘A’ caller device, ‘B’ callee device), the carrier may not provide an alternative form of communication between the two devices. When a called device is overseas and/or is out of range of a mobile cellular network provided by its carrier network, alternative communication scenarios may be necessary to establish a communication trail of messages, transfers, calls, etc., between two communication devices. In general, when the carrier network cannot provide a call connection service that actively connects two endpoints, there are indicators which are created to identify when the alternative communication approach is appropriate. Such indicators can be used to trigger an alternative communication service/application.

FIG. 1illustrates an example network configuration for managing mobile device communications and alternative communications to a carrier network according to example embodiments. Referring toFIG. 1, the configuration100provides three networks which are required to communicate in order for the alternative communication scenario to operate effectively. In the first network, the carrier network110includes mobile services, such as base stations and cellular network components (not shown), and a server, such as a home location register (HLR) that identifies the subscribers by their respective mobile device information and related hardware identifiers. For example, when a call is placed by a subscriber102that is attempting to call132another subscriber104, which is not currently located in a communication range of the carrier network110, then carrier server112will still attempt to connect the call by identifying the caller102, the callee104, determining the device104is unavailable134based on a database entry114of active subscribers vs. inactive subscribers, or other information stored in the database used to identify whether the callee104is available, unavailable, subscribed, unsubscribed, etc.

In the event that a call connection cannot be maintained between the calling device102and the called device104, a log file and/or failed call parameter may be stored in the database114by the carrier server112to log the event failure. When the called device is off or is not identifiable by the carrier network via other carrier networks or other communication platforms, which are integrated with the carrier network110, then the call will be identified as a failed call due to an inability to create a connection between the end devices. The result of a failed call will be logged via a failed call parameter stored in the database114. The virtual computing network (cloud network120), will audit the carrier call network for failed calls to identify whether a virtual mobile device can be identified and used to create a virtual call communication outside the carrier network in an attempt to provide communications between the two endpoint devices.

Once the virtual cloud network120is triggered136to identify a virtual mobile device that corresponds to the called device, the cloud management server124may process the trigger message communication sent from the carrier network110to the cloud network120. The trigger/invocation message may include various parameters, such as a date/time of the failed call, the calling party, the called party, hardware information of the mobile devices, SIM card information, last known location, last known communication with the mobile network, whether the device is subscribed to out-of-carrier communication services, etc. The trigger/invocation message may include an identifier of the virtual machine122, virtual device, and corresponding virtual mobile device assigned to the called mobile device. Once the correct virtual mobile device is identified, the virtual mobile device application may be executed, which will invoke certain actions to be performed, such as creating a message according to pre-stored communication medium preferences (e.g., SMS, e-mail, application specific communication preferences, etc.), pre-stored/default communication messages, etc., and sending the message to the mobile called device and/or the mobile calling device depending on the preferences stored in the virtual mobile device. Then, any notifications which are created can be sent created and sent138to a remote data network188where the mobile device is identified as being online.

FIG. 2illustrates a detailed example of the virtual network and virtual machines providing alternative communication scenarios according to example embodiments. Referring toFIG. 2, the configuration200provides additional details of the cloud computing network. The example provides that when the cloud management server124receives the invocation message136, the various virtual machines222-226, managed by the server124, are audited to identify whether any of the virtual machines is hosting a virtual mobile device application, which may be operating inside a ‘container’, such as on a DOCKER platform. Each virtual machine222-226may have a corresponding master file231-251. The master files may include information that identifies each of the virtual mobile devices231-234,241-244, and251-254. The virtual mobile devices may each correspond to one actual mobile device, such as the called device. When the cloud management server124receives the invocation message including a mobile device identifier of a called device which did not connect to the calling device, the virtual mobile device corresponding to the mobile device identifier may be matched246by identifying the mobile device identifier included in the invocation message with the identifier stored in the virtual mobile device. After the correct virtual mobile device244is identified, mobile device preferences may be identified to create a message/notification248, which can be forwarded249to the specified communication medium included in the preferences, such as an e-mail message, a SMS message, a specific chat application message, etc. The message may also have preferences, such as informing the called party of the missed call with certain parameters, such as the calling party, the time, date and other information regarding when the call was missed. A notification may be sent back to the calling party by default to specify that the virtual mobile device was initiated. This would include creating and sending notification to both the called party and the calling party devices.

FIG. 3Aillustrates an example user interface of a calling device using an alternative communication application according to example embodiments. Referring toFIG. 3A, the example300includes graphical user interfaces of the calling device310when the calling device is attempting to call the called device312and when the call fails to connect. The calling device may be notified by the virtual machine and virtual mobile device that the alternative communication options are being utilized314. The display may also include details of the call log messages316, such as when and what content was sent and received, to and from the mobile devices, once the call connection has failed. As may be observed, message notifications were sent to the called device and were received by the calling device.

FIG. 3Billustrates an example user interface of a called device using an alternative communication application according to example embodiments. Referring toFIG. 3B, the configuration350provides an example where the called device has received a notification regarding a missed call352. The second display interface354includes details of the call, such as when and who attempted to call, message status information is also provided in another window with an option to communicate with the calling device356.

FIG. 4Aillustrates an example logic flow diagram of an alternative communication scenario according to example embodiments. Referring toFIG. 4A, the process400provides identifying a call communication initiated by a calling device and intended for a called device412, the call may be identified at a carrier network server. If the call can be connected, then the call is connected414by the carrier network between the two devices. When the connection fails to connect416, a virtual mobile device application is invoked418on a virtual machine operating in a cloud network. Once the virtual machine is identified that includes the identifier of the called device422, then the master file of the virtual machine may be invoked424and used to identify the virtual mobile device application, which will cause a notification to be created and sent426to the called device.

In another example, the process may include creating the communication message via the virtual machine based on instructions in the master file, and the instructions include a communication message format and a communication message content to include in the communication message. Examples may include a default response or a response that indicates certain dynamic parameters, such as date, time, location, etc. In one example, the message may include a date a time that the called party associates with a response period, for example, the called party may engage in a WIFI connection each morning at 9 AM EST and may have that information sent to the calling party so the calling party knows when a response is likely to be sent and/or when the chat session may be live so the parties can exchange real time communications. The process may also include identifying one or more communication preferences in the master file, such that the one or more communication preferences are associated with a user profile of the called device. The one or more communication preferences may include one or more of a communication application to use when creating the communication message to the failed call connection, a communication message format to use for the communication message, and content to include in the communication message. The communication message format may include one or more of an electronic mail (e-mail) message, a short message service (SMS) message, and a chat communication application message format.

The process may also include selecting the virtual machine corresponding to the called device from among a plurality of virtual machines operating in a virtual computing network, and initiating the virtual mobile device application on the selected virtual machine, and selecting a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine, and the virtual mobile device is selected based on an identifier stored in the master file which matches an identifier stored on the called device.

FIG. 4Billustrates another example logic flow diagram of an alternative communication scenario according to example embodiments. Referring toFIG. 4B, the process450may include identifying a call connection attempt via a notification identifying a calling device and a called device stored in a carrier network452, and responsive to identifying the notification, the carrier network server may attempt to connect the call454. When there is a failed connection attempt456, an invocation request may be created and sent to a virtual computing network having a plurality of virtual machines458. The determination is then made as to whether a virtual machine has an identifier of a called device, if there is a match462between the mobile device and the virtual machine, and if so464, then the correct virtual mobile device is accessed. The preferences are then identified and referenced to determine how to proceed with managing the alternative communication session. For example, the preferences466may dictate notifications be created and sent to the called device468, the calling device472or both.

The process may also include creating the first message to notify the called device that a call attempt, sent from the calling device and destined for the called device, has failed to establish a call connection, and the first message includes a calling device identifier, a date and time of the call attempt and an option to send a notification to the calling device. The process may also include creating the second message to notify the calling device that a call attempt, sent from the calling device and destined for the called device, has failed to establish a call connection, and the second message may include a called device identifier, a date and time of the call attempt and an option to transmit a notification to the called device. The virtual mobile device is selected based on a called device identifier, corresponding to the called device, which is stored in the invocation request. Also, when initiating the virtual mobile device application associated with the virtual mobile device, a communication session is initiated between the calling device and the called device. The communication session includes a data network session to be established between the calling device and the called device based on an internet protocol address of the calling device and the called device. The process may also include forwarding a confirmation message to the virtual machine that the called device is available via a data communication network, and responsive to the virtual machine receiving the confirmation message, forwarding the first message to the called device.

FIG. 5Aillustrates an example flow diagram of an alternative communication scenario according to example embodiments. Referring toFIG. 5A, the process500includes identifying a call communication initiated by a calling device and intended for a called device512, determining the call communication resulted in a failed call connection514, responsive to identifying the failed call connection, invoking a virtual mobile device application operating on a virtual machine516, executing a master file stored in the virtual machine518, responsive to executing the master file, transmitting a communication message to the called device522.

FIG. 5Billustrates an example flow diagram of another alternative communication scenario according to example embodiments. Referring toFIG. 5B, the process550includes identifying a failed call connection via a notification identifying a calling device and a called device stored in a carrier network552, responsive to identifying the notification, transmitting an invocation request to a virtual computing network comprising a plurality of virtual machines554, selecting a virtual machine corresponding to the called device556, selecting a virtual mobile device from among a plurality of virtual mobile devices operating on the virtual machine558, initiating a virtual mobile device application associated with the virtual mobile device562, and responsive to initiating the virtual mobile device application, transmitting one or more of a first message to the called device and a second message to the calling device564.

FIG. 6illustrates an example logic process diagram of input and output parameters which are processed during an alternative communication scenario according to example embodiments. Referring toFIG. 6, the example configuration600provides the logic processor650receiving various input parameters, such as calling parties610which are attempting to call certain call recipient parties via various call events620. The carrier network630may be identifying failed call connections632and notifications634which occur from certain call attempts and logging such information. The outputs which are processed based on the various input parameters may include notifications612, preferences614, virtual devices616, virtual mobile devices618and communication sessions622.

As illustrated inFIG. 7, a memory710and a processor720may be discrete components of the network entity700that are used to execute an application or set of operations. The application may be coded in software in a computer language understood by the processor720, and stored in a computer readable medium, such as, the memory710. The computer readable medium may be a non-transitory computer readable medium that includes tangible hardware components in addition to software stored in memory. Furthermore, a software module730may be another discrete entity that is part of the network entity700, and which contains software instructions that may be executed by the processor720. In addition to the above noted components of the network entity700, the network entity700may also have a transmitter and receiver pair configured to receive and transmit communication signals (not shown).

One having ordinary skill in the art will readily understand that the application as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations that are different than those which are disclosed. Therefore, although the application has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the application. In order to determine the metes and bounds of the application, therefore, reference should be made to the appended claims.