1 Methods and procedure in making calls direct from mobile 2 devices using alphanumeric code and returned Call number to 3 connect to the destination number. 4
This invention is an improvement of the current patented invention 6 related to the prior art of alphanumeric dialing instead of numbers 7 using SMS or USSD to trigger the call back to connect the originating 8 and the destination parties. In the prior invention, after the 9 alphanumeric code has been sent via SMS or USSD to the system, the two telephone or mobile numbers are connected by calling the two 11 lines from a voice server (Call Back) and switching the two voice ports 12 together to establish the voice connection between the two parties. 13 This call back sometimes creates confusion to the originating party 14 and sometimes result to disappointments from the caller since there is no notification to the originating party that the destination party is 16 busy. In this invention, call back is not the primary procedure, 17 instead, the calling party device will have a mobile application 18 installed in the device, to avoid the callback procedure, performs 19 negotiation with a central Gateway server, by inquiring the call number of a particular alphanumeric. The gateway server will reply a 21 Call Number that can either be a manipulated telephone or mobile 22 number or the true destination number, that the inquiring mobile 23 device can call using mobile application triggered outgoing call of the 24 mobile device itself. The decision to what Call Number to reply back that can either be a manipulated number or true destination number 26 is the technique used by the invention to hide or show the identity of 27 the true destination party number. The mobile application, upon 28 receiving this Call number from the Gateway, will trigger the standard 29 call operations of the mobile device to complete the call. The mobile application has been programmed to internally connect to the mobile 31 device's call command. Please note however, that not all Call numbers 32 returned by the database server are the converted numbers but can 33 also be a direct telephone or mobile number of the destination party a. 1 that the calling party wishes to call.
The selection of a Call Number is 2 governed by the settings of the B party, the owner of the 3 alphanumeric code, during the creation of the alphanumeric contact 4 code in the provisioning server, if that same B party wishes to hide or expose his true mobile or fixed line number identity to the calling or 6 requesting party.
If the B Party account who created the 7 alphanumeric code, sets to hide the number, the inbound port number 8 or mobile number at the Voice Server, in the case of using GSM 9 Gateway, will be used as the Call Number to be sent to the requesting mobile device.
For the Voice server to answer the call and accept the 11 call coming from the requesting mobile device application, the 12 initiating mobile device or mobile app should bear the same Caller 13 Line ID number the mobile app used to trigger the request and the 14 call must be received by the Voice server within allotted waiting time or else, the inbound port will not be answered.
Since all mobile 16 applications requesting to call an alphanumeric code have log in 17 credentials that are known by the Database Server, by pairing the 18 Caller Line ID to the alphanumeric code, the database server can check 19 the CLI to the Voice inbound Trunk Ports to authenticate the caller and continue the call process. 21
1 Methods and procedure in making calls from mobile devices 2 using alphanumeric code and returned Call number to connect to 3 the destination number 4
What is Claimed: 6 7 1. A system and methods comprising of mobile phone application, a 8 mobile device, gateway server, a database look up server, a 9 provisioning server and a voice server with PSTN and/or CMTS trunk interfaces that allows mobile device to initiate the call to a destination 11 party directly from the mobile device using alphanumeric code 12 without doing the prior art of a call back procedure from the server in 13 which the mobile device will send the alphanumeric code to the 14 gateway via data connection and the Gateway to return a call number of a defined Voice server inbound port number, to conceal the true 16 number identity of the destination party number, then the gateway 17 makes another call to the final destination party number registered in 18 the Database server to finally connect the originating mobile device 19 with mobile application to the destination number of the alphanumeric code previously provisioned in the database server 21 using the mobile application. This method allows to hide the true 22 number of the destination party without dialing the PSTN or mobile 23 number but instead using the alphanumeric code of the destination 24 party to connect via the back to back call forwarding at the Voice server to make the final call and connection. 26 27 2. A method of Claim 1 further comprising an application software 28 installed at the requesting mobile device or Originating Party device 29 that will connect to the gateway server using a proprietary protocol through public data network or internet that will allow to pass 31 information between each other such as request for Call number of 32 the alphanumeric code, the alphanumeric code, identity code of the 33 requesting mobile device, allowable wait time info, termination type,
1 privacy type, advance call status information, time and date, Gateway 2 status information and other information to fulfill the exchange of 3 communication. These information are necessary to perform the Call 4 number to use to connect the call to the destination party where privacy type determines if the true number of the destination party 6 will be hidden or exposed, where Termination type to define if the call 7 will be terminated to an internal Voice Resource content or IVR or 8 terminated by a voice call connection, where allowable wait time is 9 the time set at the Voice server to wait for the mobile device to call the
Call number, where identity code to authenticate the mobile device in 11 addition to the user name and password of the user, where call status 12 provides quick feedback if the final destination party is busy and being 13 engaged by the Voice server, and Gateway status where it provides 14 status if there are available inbound or outbound ports to accept the call and other process status that is relevant to the originating mobile 16 device to determine if call can be initiated or if the request will be 17 terminated, delayed or notified of the current status of any of the sub- 18 systems at the Gateway and/or behind Gateway side. 19 3. A method of Claim 1 further comprising a logic at the database 21 server that can return a Call number that the mobile device can call or 22 dial and the Voice gateway to make a forward call to the true 23 destination number based on the alphanumeric code privacy setting, 24 to conceal the destination party number from the requesting mobile device and connect to the destination party without revealing the true 26 destination number. This can be achieved by returning to the 27 originating mobile device, during the call request of the mobile 28 application, a Call number of the Inbound port of the Voice server and 29 pairing this Inbound port to the CLI or caller line ID of the originating mobile application of the device and to the Outbound port of the Voice 31 server for the call forwarding procedure. 32
1 4. A method of Claim 3 further comprising that the returned call 2 number or call number from the database server via the gateway 3 server used is paired to the requesting mobile device Calling Line ID 4 with a specified waiting time range, so that only the authenticated and known Calling Line ID will be answered by the system based on the 6 waiting time condition above.
Information about the Calling Line ID, 7 allowable waiting time range to call, and the reserved inbound trunk 8 port mustbe present to authenticate the call for the proper answering 9 ofthe Voice Server.
11 5. A method of Claim 3 further comprising a logic or program that 12 randomly selects available trunk port from the inbound trunk pool of 13 the Voice server to be assigned to the requesting mobile device and 14 not using the same inbound port, from the same requesting party, to any succeeding requests, to deter unwanted, and expired inbound 16 calls going to be answered by the Voice server.
Only after the inbound 17 trunk port has been reserved for the Calling Line ID (CLI) of the 18 requesting mobile device, are within the waiting time set where the 19 Voice Server answers the call else, it will not answer any other call from any other CLI number. 21 : 22 6. A method of Claim 1 further comprising a Voice Server with 23 interface voice ports, both for inbound and outbound ports, 24 connected to PSTN or CMTS trunk lines for the purpose of establishing voice connection from the requesting mobile device to the destination 26 party or to an internal IVRS or to another third party IVRS port system 27 that can play an announcement recorded previously by the owner of 28 the alphanumeric code set for IVR or voice content.
Where the IVRS 29 to be used here is any interactive voice response system that can accept voice recording from a mobile device microphone and play the 31 voice recordings, that is an integral part of the system but this 32 technology is already known with prior art disclosure.
Only the voice
1 content of the alphanumeric code, previously set as IVR terminated 2 call in the system, will be played during IVR playback. 3 4 7. A method of Claim 1 further comprising that the Voice Server with interface voice ports, both inbound and outbound ports, connected to 6 PSTN or CMTS trunk lines for the purpose of establishing voice 7 connection can also forward or redirect the incoming call, received by 8 the inbound ports of the Voice Server, to another destination number 9 which is the hidden PSTN or CMTS number of the B Party account not shown to the requesting mobile device during the placing of call of 11 that same requesting mobile device, with the purpose of concealing 12 the destination number, as configured by the same B Party number’s 13 account previously in the mobile application in that device.
For the 14 purpose of definition, B Party is the destination party or person who owns the destination number and the alphanumeric code he/she 16 assigned previously to his/her number that the requesting mobile 17 device wishes to call.
The requesting mobile device is the calling party 18 who initiated the Gateway to call a certain alphanumeric code that is 19 paired to the destination number of the B party.
21 8. A method of Claim 7 further explaining that the Voice Server is 22 coupled with two way communication protocol to the Gateway Server 23 so that passing of information about the call request, call status, call 24 management and other signaling requirement to handle and manage the call will be smoothly exchanged to properly handle the switching, 26 call forwarding, managing the «call, establishing the call and 27 completing the call.
This protocol allows to provide information to the 28 originating device the call status, call progress, call waiting 29 management, proper forwarding of call to the true number destination, attaching both inbound and outbound ports together to 31 the CLI of the originating mobile device, and other signaling needed to 32 properly supervise and handle the call connection. 33
1 9. A method of Claim 7 further comprising a logic that monitors the 2 utilization of all ports and the matching of the requesting mobile 3 device's Calling Line ID, in/out trunk port numbers and the 4 alphanumeric code in use to provide the status of the destination number to the requesting mobile device before the calling process to 6 begin so that it can provide vital information regarding the destination 7 party's line status to the originating mobile device, abort the call 8 process and/or save time in calling a “busy” or “in use” destination 9 party number.
The Gateway device can immediately send to the requesting mobile device these information, coming from the Voice 11 Server via status notification on the mobile application, on the current 12 status of the destination party number. 13 14 10. A method of Claim 7 further comprising a call forwarding switch capability at the Voice Server that allows incoming call at the inbound 16 port of the voice server to be connected and forwarded to another 17 outbound port of the same voice server, to call the true destination 18 number that was hidden to conceal the true identity of the destination 19 party number.
The call number returned by the gateway is the inbound port of the voice server and not the true destination party 21 number, to hide the true identity of the destination party.
When the 22 call comes in to an Inbound port, the Voice server will check the CLI, 23 waiting time, and the Inbound port dialed by the mobile application 24 and if all these information defines a Call forwarding call to another destination, will trigger the Voice server to switch the paired 26 outbound port, call forward to another destination number using the 27 outbound port.
When the destination party, dialed by the outbound 28 port, answers the call, the originating mobile device can now have a 29 communication channel and a voice path between the originating mobile party and the final destination party device. 31 32
1 11. A method of Claim 7 further comprising the ability of the Voice 2 Server to provide status to the requesting mobile device the 3 information of the destination party call progress when the 4 destination party is unavailable or busy instead of replying the call number to the requesting mobile device to avoid dialing a busy or 6 unavailable number at the Voice Server.
Instead of replying a call 7 number for a known busy or unavailable destination party status, a 8 status notification will be sent instead to the originating mobile device 9 and ends the call request.
11 12. A method and systems of Claim 1 further explains that the 12 returned Call number from the Gateway server can be the true and 13 final destination number that the originating mobile device can call 14 directly without passing through the Voice server.
This logic was derived from the configuration or provisioning of the privacy settings 16 during the creation of the alphanumeric code in the mobile applicaton 17 that sets this alphanumeric code and the corresponding destination 18 number to public privacy setting. 19 13. A method of Claim 5 further comprising a logic at the Voice Server 21 that will allow the system to answer the call even without the 22 presence of CLI by using the Time to wait for call settings and the 23 assigned inbound ports at that particular time.
Normally, the system 24 will match all these three information to decide to answer the call but in this case of absent CLI, the call can still be answered by just using 26 the Time to wait for call and the reserved inbound port seized by the 27 calling party.
In order to minimize error in handling the call, the 28 Time to wait will be shortened in order to avoid error of unintended 29 call from other callers.
1 Methods and procedure in making calls from mobile devices 2 using alphanumeric code and returned Call number to connect to 3 the destination number . 4
Technical Description of the Invention: 6 7 The technical part of the invention will now be described in details 8 through various representation of the block diagrams and process 9 flows shown in the succeeding pages. Each drawing has figure number title and numbers to describe the process or the sub systems 11 of the invention. 12 Figure 1. This figure is the representation of the Network Diagram 13 and the various components that make up of the invention. For 14 presentation purposes, the diagram includes all the components from the originating mobile device to the destination mobile device and the 16 network cloud in order to explain better the invention. Mobile device 17 (1) is a terminal that will store the mobile application to securely 18 connect to the Gateway server and will serve as the human interface 19 to access the services of this invention. The mobile device will have to connection to the telecom operator's data network or WiFi to connect 21 to the Gateway (4). One interface is the data connectivity (2) via 22 Internet or any other connection technology that will allow the 23 application to connect to the gateway via private or public, wireless 24 interface. Another interface is the Voice connection via telephone line or wireless voice communication cloud or network (3) that may be 26 operated by public telecom provider that can be used by the mobile 27 device to connect via voice channel to the Gateway server (4). The 28 Gateway server (4) is the main interface for all two-way information 29 signaling requirements of the mobile application to the various components at the Gateway (4) and behind it. Gateway server (4) 31 receives provisioning messages, call signaling messages, call status 32 info, and other related signaling needed to complete the functions 33 required by the user of the mobile application and the system. The
1 Provisioning server (5) is the server that maintains the information of 2 the users profile and the temporary safekeeping of the text code, 3 various status and other information of the originating device during 4 the authentication stage.
It keeps duplicate copy of the user’s profile and stores the original and final copy of any transaction and every 6 registration to the database server (6). The database server (6) is the 7 main storage of all user profiles, alphanumeric codes, destination 8 number, statistics of the user's activity, call status information, 9 systems database, inbound and outbound port status and system reports.
The Voice server (7) is a interactive voice response system 11 and a voice switching server at the same time to serve as the voice 12 content server and interface to the telephone and mobile network that 13 allows recording of voice content of the mobile device user or play 14 selected voice content to the callers of a particular account.
Part of its function also is to keep track of the voice session and recording them 16 for call status information purposes that provides quick status of the 17 destination party to minimize unnecessary voice calls to busy 18 destination party.
Voice session information are relayed constantly to 19 the database server for immediate updating for this status information tracking that might be required by the mobile application 21 for call status information and display.
The mobile device (8) is the 22 destination party device who owns the alphanumeric code that the 23 mobile device (1), the originating party and the mobile app user, who 24 initiated the call.
A normal incoming call will be displayed to the mobile device (8) screen with the calling party number appearing on 26 its incoming call CLI depicting the Voice Server outbound port CLI 27 used for the call.
If the Voice Server (7) is connected directly and 28 internally to an operator switch network, a CLI modification can 29 happen to show the original mobile device’s (1) CLI but if the Voice server (7) is connected to the a GSM Gateway, there will be no CLI 31 translation and the CLI of the outbound port of the mobile SIM who 32 initiated the call via GSM gateway, will be displayed, instead. 33
1 Figure 2. This figure is the diagram of a typical call where 2 alphanumeric code is terminated to the Interactive Voice Response of 3 the Voice Server. The process starts with a mobile device with the 4 mobile application sends a alpha numeric code to the Gateway server using internet interfaces or any available interface connectivity 201 6 and 202. The Gateway server upon receiving the request from the 7 mobile device will then inquire the Database via interface 203 to 8 determine the profile of the particular alphanumeric code. In 9 particular the equivalent number, status, call rates, privacy settings either as private or public, and termination type info either IVR or 11 Call. If the alphanumeric code requested bears an IVR terminated 12 call, the database server will instruct the Voice Server to reserve an 13 available inbound port number to a particular CLI that requested the 14 IVR content, via interface 204. Immediately, the Database server will also reserve the IVR voice content to this request in its database 16 record in the inbound port reserved. The Voice Server will then reply 17 a confirmation that the inbound port has been reserved for the CLI 18 requested via interface 205. After the Voice server confirms to these 19 information via interface 205, the Database server will reply to the
Gateway server via interface 206, the inbound port number reserved 21 for the incoming CLI number and the waiting time set for this request. 22 The Gateway server will then send the reserved inbound port number 23 via interface 207 going to the Data Network and to the mobile device. 24 When this message reach the mobile device via interface 208, the mobile application will then initiate the call to the reserved inbound 26 portitreceived via interface 208 and will use via regular cellular voice 27 channel to call and reach the inbound port of the Voice Server 209 and 28 210. When the call reached the Voice Server port via interface 210, it 29 will then decode the call identity via CLI identification process to determine what process will be executed to handle the call. If the CLI 31 and the Inbound port matched to have IVR playback, this call will be 32 treated by the Voice server as IVR terminated call. The Voice server 33 will then request the voice content to the Database server via interface
1 205 and will then play this content to the caller immediately on the 2 Inbound port assignment. Voice content is played via Interactive 3 Voice response (IVR) technology where caller can also enter DTMF 4 command to control the announcements and the voice content/s. This
IVR process will not be explained since IVRS or interactive voice 6 response system is already a prior art, and those who understand this 7 art knows how to use this process. If a particular voice content has 8 already reached the maximum number of inbound ports reqruest 9 allotted for a specific alphanumeric code and IVR content code, the system will return to requesting mobile application via interface 207 11 and 208 that the maximum number of simultaneous ports have been 12 reached for that request and the call will be terminated by the mobile 13 application as a result of the return message from the Gateway server. 14
Figure 3: This figure is the diagram of a call request with a typical 16 alphanumeric code terminated directly to a PSTN or CMTS number in 17 which the alphanumeric code is set to privacy setting as public. The 18 process start with a mobile device with the mobile application sending 19 acall command to an alphanumeric code to the Gateway server using internet interfaces or any available interface connectivity 301 to the 21 internet cloud and 302 from internet cloud to Gateway server IP 22 address. The Gateway server upon receiving the request from the 23 mobile device will then inquire the Database server via interface 303 24 to determine the profile and settings of the particular alphanumeric code. In particular, these information are the equivalent number of 26 the alphanumeric code, call status of destination number, if currently 27 being used by the system, call rates, privacy settings either as private 28 or public, and termination type info either IVR or Call. If the 29 alphanumeric code is a call terminated alphanumeric code with public account type, the database server will reply, via interface 304 to 31 the Gateway server, the Call number which is the destination party 32 number and the Gateway to reply this same information to the mobile 33 application via interface 305 and 306. The mobile application and the
1 mobile device will decode it as a call command directly from the 2 mobile phone to call the destination number.
The mobile device will 3 perform the normal calling procedure to the Call number received or 4 destination party number received via interface 306. Interface 306 is any standard mobile wireless connectivity that the device is 6 registered that is allowed to place the call to the network.
With this 7 set up, the mobile application and the originating device was able to 8 call the destination number by using this methods and procedure
9 using alphanumeric code and returned Call number.
11 Figure 4: This figure is the diagram of a typical alphanumeric code 12 terminated to a PSTN or CMTS number but with Call number 13 translation or destination party set to private number.
The process 14 start with a mobile device with the mobile application sends a call command to an alphanumeric code to the Gateway server using 16 internet interfaces or any available interface connectivity 401 to the 17 internet network and 402 from the network to the Gateway IP 18 address.
Please note that the interfaces 401 and 402 can be any public 19 or private data interface that allows the mobile device with the mobile application to establish data connection between to the Gateway 21 server.
The Gateway server upon receiving the request from the 22 mobile device will then inquire the Database server via interface 403 23 to determine the profile of the particular alphanumeric code being 24 requested.
In particular, these information are the equivalent number of the alphanumeric code, call status of destination number, if 26 currently being used by the system, call rates, privacy settings either 27 as private or public, and termination type info either IVR or Call.
If 28 the alphanumeric code is a call terminated alphanumeric code with 29 private account type setting, the database server will inquire the status of the destination number via interface 404, if the said 31 destination party is currently engaged and if there are available ports 32 at Voice server trunks.
If there is no available inbound and/or 33 outbound port, the voice server will reply this status to the Database
1 server via interface 405, for proper status notification to the 2 requesting mobile device and terminate the call. If the destination 3 party is not in the Voice server registry, has available inbound and 4 outbound trunks and not being engaged at the moment, the Voice server will reserve an available inbound port and outbound port for 6 the requesting mobile device CLI. The Voice Server will pass the 7 Inbound port number reserved and the time to call waiting time, to 8 the Database server via interface 405 and to the Gateway server via 9 interface 406. This Inbound port number is now the Call number to be sent together with the waiting time, allowed by the Gateway server, 11 to the mobile device via interface 407 and 408. After receiving this 12 information, the mobile device will decode it as a call command 13 directly from the mobile phone to dial the Call number or destination 14 number. The mobile device must perform the normal calling procedure to the Call number sent by the Gateway server within the 16 waiting time period for the call to be accepted by the Voice Server. 17 During this time, the Voice server is continuously waiting for the 18 incoming call from the requesting mobile app and device CLI. When a 19 call is received at the designated inbound port, the Voice server will answer the call, verify if the CLI and the inbound port number matches 21 and will seize another outbound port, switch it to the paired inbound 22 port and do another forwarding call to the destination party. With 23 this set up, the mobile application was able to call the hidden and 24 private destination number by using the alphanumeric code without revealing the number to the originating or calling party. If the call is 26 outside the waiting time set, the call will not be answered. If the call is 27 coming from a different CLI, the call will not be answered also by the 28 Voice Server. 29
FIGURE 5. This figure is the representation of the Provisioning 31 process of the invention. This shows the various server components 32 that make up the entire invention and processes involved. In the 33 Diagram, the Mobile device has the mobile application that will allow
1 to securely connect to the Gateway server via interface 501 to the 2 public data provider and interface 502 going to the Gateway IP 3 address. The said mobile application needs to be authenticated by the 4 Gateway before the access privileges of the mobile application is given to the user and the device. Upon the first use of the mobile 6 application, which means the application has just been uploaded to 7 the Mobile device and ready to connect to the Gateway server, the 8 first time user must sign up first to the system to be recognized. This 9 signing up process will not be discussed fully but the basic process only of sending the information to the system. This is not part of the 11 invention claim but is an integral part of the processes of the total 12 invention in order for the user of the application be recognized to the 13 right mobile device user. Upon signing up, the user of the mobile 14 application must provide information such as the mobile number, username, password, name, address, other information needed to 16 identify the user and the application identity number and to be sent 17 via the secured connection 501 and 502 to the Gateway Server. Once 18 these information are received at the Gateway server, it will be sent to 19 the Provisioning server via available interface 503 for temporary storage while it conducts the verification sequence by replying to the 21 Gateway server using an interface 504 a text code that must be 22 fulfilled by the signing mobile app. The mobile number entered 23 during signing up will be used by the Provisioning server to 24 authenticate the mobile identity and the application user. The
Gateway server will send this via SMS interface 508 to the Mobile 26 Network using any available interface standard such as SMPP, CIMD, 27 UCP or any other future technology that will do the same. When the 28 requesting device received this SMS text message and the same mobile 29 app user that requested this, the code must be entered to the mobile app in order to start the verification. If the information are correct, 31 the right text entered correctly, the Provisioning server will receive 32 this and store the user profile via local interfaces 505 and 606 to the 33 Database server in order to complete the provisioning and
1 registration of the account to the database server.
After this the 2 provisioning and registration of the mobile application and the mobile 3 device is complete.
The mobile app and mobile identity is now 4 recognized in the system and now ready to create and manage callable alphanumeric contact codes, record voice contents and make calls to 6 any alphanumeric codes registered by anyone, in the system. 7 8 Figure 6. This figure represents the provisioning of the alphanumeric 9 code via the application.
After the mobile application and user has been authenticated and recognized by the system, it can now create, 11 delete, edit, manage his contact codes and record voice contents.
To 12 create an alphanumeric contact code and associate it to a particular 13 number, the user must use the application in order to create this.
This 14 mobile application is another creative and inventive art that will be covered by a separate patent application but will not be mentioned 16 here in full details but will be used to describe the shortcut process of 17 how the information will be entered in the mobile application and 18 sent to the Gateway server.
The user of the mobile device needs to 19 log in and selects the creation of alphanumeric code page and must enter the following information such as but not limited to, 21 alphanumeric code, the mobile device to associate the alphanumeric 22 code, the registration type as either public or private, Destination Call 23 type either as IVR or number and the short description of the 24 alphanumeric code.
After the user entered these information, the mobile application is ready to send the information to the Gateway. 26 By clicking the submit button in the mobile application, these 27 information will be sent immediately to the Gateway server via 28 interface 601 to the Internet domain and via interface 602 going to the 29 Gateway server IP and/or Domain address, which this IP address was pre-installed originally to the mobile application prior to downloading 31 of the mobile app by the mobile user.
When the Gateway server 32 received these information, it will pass this information to the 33 Provisioning server via interface 603 for further processing.
It will
1 perform the authentication check if the destination type selected is a 2 number.
The system needs to know that the number associated to the 3 alphanumeric code, entered by user, is indeed owned by the user.
A 4 text message will be composed by the Provisioning server and will send to Gateway server via interface 604 and will be sent by the 6 Gateway server to the associated mobile device via interfaces 607. 7 This can either be through a GSM Gateway or direct SMS interfaces to 8 the cellular network SMS using either SMPP, UCP, or CIMD protocol. 9 This text message contains the authentication code that the mobile user must receive and entered in the mobile application to complete 11 the registration of the said alphanumeric code.
After the user entered 12 the correct SMS code to the application and received and verified by 13 the Gateway, the registration process is complete and Provisioning 14 server will store the alphanumeric code together with all the information initially presented by the user during the alphanumeric
16 code registration.