GB2524769A

GB2524769A - Method for broadcasting the status of a smartphone user to other smartphones and using the sent message to disable/re-enable communication between the users

Info

Publication number: GB2524769A
Application number: GB1405876.2A
Authority: GB
Inventors: Paul Tembo
Original assignee: SASYNC D Ltd
Current assignee: SASYNC D Ltd
Priority date: 2014-04-01
Filing date: 2014-04-01
Publication date: 2015-10-07
Also published as: GB201405876D0

Abstract

A method of informing third parties of a users status via a mobile communication device whereby the user sends a status message that informs one or more contacts from their phone book that regularly contact them, of their status/availability. The message may also contain actions that block the receiver from phoning the person who sent the status message on the mobile communication device that received the message and also unblock the mobile communication device when the status of the sender changes. The messages may be communicated via usual network operator SMS and data services and a central server that may manage the communication and track the events, their duration, and monitor users statuses and send reminders of ongoing call blocking statuses. The communication may be in the form of or a combination of Voice-Calls/SMS/MMS/VOIP for example. The method may also utilise the diary function of the mobile communication device and automatically a status message corresponding to events booked in the diary.

Description

I

Method for Broadcasting the Status of a Smartphone User to other Smartphones and using the sent message to Disable/Re-enable communication between the Users.

Description.

Field of the Invention.

The present invention relates to Mobile Telephony Mobile Communication Devices namely Mobile Phones(All Variants especially Smartphones), PDAs, Tablets and any other devices that have a Standard VOICE/VOIP/text(SMS)/data(MMS) capability as a way of conveying information or making contact with another Mobile Communication Device.

Background of Invention.

The advent of mobile phones(legacy and smart phones), PDAs and Tablets has not only made calls and text messaging just a click or a couple of clicks of a button away. That has brought with it problems of unwanted disturbances when users are at work, in meetings, at funerals, on holidays an when sleeping, relaxing at home on a weekend among other activities during which incoming calls/texts/multi media content and the leasy welcome. This is more so due to fact that these devices are always in our pockets.

At the moment(March 20 4) a user's mobile device status is just a descriptive word/term with no limiting capabilities. Respect of another's status is then subject to the other mobile device user's willingness to honor the said status until such a time it changes that is if at all it changes.Among most instant messaging software applications I have seen status terms like "At the Gym", "In Class", etc in the middle of the night or other times when that status is no longer true but has been forgotten about. The tendency to forget updating one's status to reflect a true state like active/available has ed to user's ignoring the status or respecting such and that is what has inspired this invention. There is currently no method and implementation to my knowledge and experience (being one mobile device user) to block unwanted calls based on the users status and also doing it at the possible source of the calls based on contacts directory listing of the people who would frequently call.

Summary of the invention.

The invention pertains to to a method and the implementation as a Mobile Device Software Application(SASync'd) to allow a Mobile Device user to Broadcast their Status(Busy, Sleeeping, In a meeting, On holiday, etc) to contacts(all or some(in a group or chosen individually)) in their directory listing. The Device to Devices communication is done through each device's respective service provider and via a SASync'd Central Server(Database/Software Management System).

When the Contact's device(running exactly the same SASync'd Software Application) receives the Broadcast Status message, the message is passed on to the Application(SASync'd) to process. The processing involves executing an Action for the Broadcasting User as stipulated in the received status message. The Action may be to disable the receiving mobile device from accessing the Broadcasting user's directory Entry in that device or enabling a previously disabled Entry.

Blocking/Unblocking at the point of origin by not allowing or allowing the call to take place in the first instance. Once the Blocking/Unblocking has been effected at the Receiving Mobile Device, all the contacts to whom the broadcast was sent are correspondingly blocked/Unblocked in the Broadcasting Device. Thus all parties, Status Message Broadcasters and Receivers are blocked from being able to call each other until the Block. Status Message Broadcaster initiates the unblocking process by restoring their status to Available/Active. The process will progress same way as before via the Central Sever to all Target Devices and lastly each successful unblocking will return corresponding message to the Server and that is relayed to the Broadcaster to unblock the respective Entry in the Broadcasting device. With that, the process terminates for each contact.

Brief Description of The Drawings.

(To be provided)

Detailed Description of The Invention.

I. In the description that follows, all stages involved in the method and implementation of this solution will be explained in greater detail to such an extent that anyone with knowledge in the field that this issue relates will understand the ayout and configuration of the method.

This method is implemented as a Software Application/Program that runs in any kind of Mobile Communication Device(lPhone, Tablet, PDA, etc) using any Mobile Software Platform available for and on any such device, The software implementations consists of building blocks that can be used to fulfill this method in part or its entirety can be accomplished in a variety of ways but the combination of these building bocks to achieve the functionality explained here make the implementation unique in performance and usefulness.

2. This method is made up of 2 primary systems components mainly the a) Software Application running in a Mobile Device/s and is capable of dual funtionality i.e. as Status Broadcast Transmitter and/or Status Broadcast Receiver.

b) Central Database/Software Management System, 3. The Software Application within the Mobile Device is made up of multiple sub components which carry out the following functions: User Status selection and new status creation, Contact grouping and new group creation, Status settings and Contact group settings, Diary function for ftiture and known events presets, message reception and analysis, retrieval of the Broadcast user details, Status and Action and implementation of the required deactivation/reactivation of Broadcasting Contact number in the Receiving device directory listing, passing of mission accomplished message back to the initiating Status Broadcast Mobile device Sub-System and unknown inward call interception.

4. The Database/Software Management System Sub-System has a User and Status Message Database and some software to manage services and user activity, 5. The SASync'd mobile Application receive Status inputs in either of 2 ways.

a) Manually selecting their settings, group or contacts to broadcast and initiating the Broadcasting, b) Automatically triggered by diary events long before entered in the diary and having known contacts to broadcast to and action preset and duration determined by the diary entries.

6. In either of the ways specified in 5(above) the Mobile Device(Software Application) on receiving a Request to Broadcast New Status command from user or diary event trigger will initiate contact with the Central Server(Database/Software Management System) via the Mobile Operator Text/Data network by sending a User Status Broadcast Message(USBM).

The progress of the broadcast is set to a default of Red.

7. When the Server receives the Status Broadcast Message, it returns a Status Message Received At Server(SMRAS) ACKnowledgement back to the broadcasting mobile device.

8. A progress bar for the contacts group to whom a status broadcast has been despatched is updated to Amber on receipt of the SMIRAS ACK message.

9. The sewer relays the message to all the contacts listed in the USBM message. In the meantime the sewer checks the message recipients for availabilit on the network, 10. If Recipients are available, the messages are then forwarded if not, a periodic check is continuously carried out until all pending messages are sent through.

1 On receipt of the USBM message at each of the Receiving Devices by the locally running or the just awakened Software Application the Software Application returns an USBM Received ACKnowledgement message. The App sets to work and responds by blocking or unblocking the respective services as per Status/Action criteria which forms part of the received USBM message. On successfi.il implementation of the requested action, a Request Actioned Message(RAM message) is returned to the Broadcasting Device via the Sewer by each of the Receiving Devices, 12. The sewer updates itself and relays both returned messages: the USBMR ACK and the RA.1VI messages to the Status Broadcasting Device.

3. Both messages in 11 (above) are used to further update the progress for each contact aiid initiate a corresponding blocking or unblocking of all contacts returning RAJ\4 messages in the Broadcasting device.

14. All successful blockings or unblockings at both the remote device/s and the Broadcasting device update the progress bars to Red or Green respectively while all pending Status/Action retain the orange progress stage.

15. Status/Actions that are indefinite will trigger reminders that will pop-up when user is active on the device to alert them of these perpetual blockings so that they can be undone both locally and at the remote devices.

Claims

Claims 1. The invention claimed is for a method for transmitting(Broadcasting) one's Status(availability) to the people(Contacts) who would normally get in touch at any time regardless of one's status(Sleeping/Work/Meeting/Gym/Library etc) and one's availability to carry out some conversation(voice/SMS/MMS/VOIP), Communication referred to in this claim is by the use of any Mobile Communication Device(Mobile Phone, Tablet, PDA, NetBook, Laptop etc) running any kind of Operating System. A Software Application/Program running within the Mobile Communication Device/s(MCD/s) and in constant communication with a Central Database and Management Server provides a user interface for message formatting, contacts selection, status and action selection, creation of new groups, new action settings and diary entry registration or formatting. The Software Application/Program also communicates with other resident Software Applications and the physical device(hardware) in order to handle the dispatch and reception and implementation of the Status/Actions that are part of Status Messages, to monitor the Network Availability/Status and responds as prescribed. Monitoring network status or availability allows the Application/Program to initiate contact with the Central server after a network loss has been resolved in case there are pending messages in the server that could not be communicated through when the device was not on the network. The user of any such Mobile Communication Device(MCD) sends out a Status Message from any such device(MCD) to a Central Database and Management Server(CDMS). The Server then relays or Broadcasts the Status Message to a contact or contacts as listed in the Status Message. Target Remote Mobile Communication Device/s(RTVICD/s) receive the Status Message and the status settings(Status + Actions) contained within the message are used to disable or re-enable the Sender's/Broadcaster's Entry/Number in the Contacts Directory Listing(Phone Book). The Status Broadcaster becomes unavailable/available for the types of conversations(voice/SMS/MMS) set within the received Status Message. At the same time all contacts targeted for the Status Broadcast will correspondingly become available/unavailable to the Broadcaster when the Requested Actions have been effected in target device/s. Thus the call blocking is two way and will stay so until the state is revoked by the Initiator. The method claimed here is implemented in software on any current and future Mobile Communication Device Software Platform. The Software implementation of this method is the same in both the Broadcasting and Receiving MCD.
2. The method of claim 1 wherein the user of an MCD(Mobile Phone, Tablet, PDA, NetBook, Laptop) selects from preconfigured user statuses, a status most appropriate to their situation or configures additional ones.
3, The method of claim I wherein the user in claim 2 sets the time duration for which their status in 2 is valid.
4. The method of claim 1 wherein the user in claim 2 selects from preconfigured Actions or configures additional Actions, actions to be implemented in Target RMCDs and same will be implemented in the Broadcasting Device to complete the process.
5. The method of claim 1 wherein the user in claim 4 sets the duration over which an Action is carried out both in local and remote devices.
6. The method of claim 1 wherein the claims in 2 and 4 make up a Status/Action pair with time periods for which they are valid.
7. The method of claim I wherein the user selects contacts from the phone book and classify them into groups as per user choice or user relationship/links to particular contacts in the phone book.
8. The method of claim 1 wherein the user in claim 7 assigns a contact or groups for the Status/Action broadcast.
9. The method of claim 1 wherein the user in claims 2, 4 and 7 formats a Status Message for Broadcast to some or all of the contacts from Phone Book
10. The method of claim 1 wherein a Diary Function of the Software Application with Events, Start and End times or another Diary application running within the same device are used by a Software Application to automatically format Status Messages.
11. The method of claim 1 wherein the devise user initiates a Status Broadcast using the Network Operator's SMS/Data service.
12. The method of claim 1 wherein the Software Application in claim 10 initiates Broadcasts in readiness for the impending Status change, shortly before the events are due.3. The method of claim I wherein the broadcast in 11 and 12 initiates a progress bar for each of the target devices(Contacts) and updates at each stage of the process.N. The method of claim I wherein the progress bar in claim 3 transitions from Green through Orange to Red for a Disabling Status Message.15. The method of claim 1 wherein the progress bar in claim 13 transitions from Red through Orange to Green for a Re-enabling Status Message.6. The method of claim I wherein the Broadcast Status Message comprising a Broadcaster ID(mobile number), Status, Action, Status and/or Action duration, Input Type(Manual or Diary Event trigger) Message Recipient/s ID/s among other basic message items in the form of Text etc is dispatched to the Central Sewer.17. The method of claim 1 wherein the Central Server recieves the Status Message from the Broadcaster and sends back a Status Message Received at Server acknowledgement(SMR(S ACK) message to update each progress bar for Target Contacts in the Broadcasting Device.18. The method of claim 1 wherein the Central Server in claim 17 checks for Network Availability(SMS/DATA) of the target devices.19. The method of claim 1 wherein the Central Sever in claim 17 relays/Broadcasts the message/s to all available target devices.20. The method of claim I wherein the Target RMCD on receipt of the Broadcast Status Message returns a Status Message Received at TRMCD to the Central Server.21. The method of claim 1 wherein the Server in claim 17 relays the message in 20 to the Broadcasting device for progress notification via the progress bar update and the bar transitions to Orange from either Green or Red depending on the Action to be implemented.22. The method of claim 1 wherein the Software application in the device in claim 20, running in the Remote Mobile Communication Device(RMCD) extracts the various bits(Broadcaster ID, Status, Action, Start and End Times, Prompts and any other messages items) of information in the Status Message.23. The method of claim 1 wherein the Software Application/Program in claim 20 implements the Requested Actions and informs Device User with a prompt in the Events Bar/popup window and Sound Alert, 24. The method of claim I wherein the Software Application in claim 20 on successful implementation of the Requested Actions, returns Request Actioned Message to the Central Sewer.25. The method of claim 1 wherein the Central Server in claim 17 on receipt of the Request Actioned Message forwards all such messages to the Status Broadcaster.26. The method of claim I wherein the Software Application in the Broadcasting device will implement same action in the Broadcaster's phonebook for each Request Actioned Message received from the Remote Communication Devices.27. The method of claim 1 wherein the progress bar in claim 9 trasitions from Orange to either Red or Green depending on the Action implemented.28. The method of claim 1 wherein the Software Application also intercepts calls from all phone book unregistered numbers, unknown numbers while the Device user is active or Inactive depending on User Settings.29. The method of claim I wherein the Software Application in claim 29 will detect all incoming calls/SMS/MMS/VOIP and process the Caller ID information before the Device! announces the call to the caller, If according to User Settings, such calls are not to be announced(are muted) or are to be terminated if voice/voip then the application will end the call/s before the call/s causes any nuisance.