WO2018100477A1

WO2018100477A1 - Enterprise domain based caller verification

Info

Publication number: WO2018100477A1
Application number: PCT/IB2017/057404
Authority: WO
Inventors: Vishal Gupta; Sumeet Singh
Original assignee: Individual
Current assignee: Individual
Priority date: 2016-11-29
Filing date: 2017-11-27
Publication date: 2018-06-07
Anticipated expiration: 2019-05-29

Abstract

Aspects of the present disclosure relate to systems and methods that enable enterprise level verification of a caller based on domain name to which the caller pertains so as to enable the called party to view that the caller is a verified caller and pertains to the enterprise that corresponds to the domain name. The system enables a recipient to automatically receive in real-time authentic details of a caller calling on the receiver's mobile device, the details indicating enterprise to which the caller belongs, his/her designation therein, his/her social media handle and the like. The system helps prevent fraudulent calls, and automatically updates itself.

Description

ENTERPRISE DOMAIN BASED CALLER VERIFICATION

FIELD OF DISCLOSURE

[0001] The present disclosure relates to caller identification systems and methods, and more particularly, to systems that enable enterprise level verification of a caller, wherein the enterprise is the organization/entity that the caller belongs to.

BACKGROUND

[0002] The background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

[0003] Currently applications such as Truecaller assist recipients/called parties in viewing the name of the caller to help them in filtering out calls that they wish to pick up. However, accuracy and reliability of such applications are limited, wherein it is very easy for a second user to clone the phone number of a first user, and call a third user intending to be the first user, which misrepresentation cannot be detected by the third user. Also, although Truecaller would indicate the name of a caller (say from a bank), it would never indicate whether the caller is actually authorized to represent make the call, or if the caller is actually even employed by the bank/enterprise he/she is representing.

[0004] There is therefore, a need in the art for an efficient system and method that enables enterprise level verification of a caller based on domain name to which the caller pertains so as to enable the called party to view that the caller is a verified caller and pertains to the enterprise that corresponds to the domain name.

[0005] All publications herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.

[0006] In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term "about." Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

[0007] As used in the description herein and throughout the claims that follow, the meaning of "a," "an," and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

[0008] The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value failing within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. "such as") provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[0009] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all groups used in the appended claims.

OBJECTS OF THE INVENTION

[00010] It is an object of the present disclosure to provide for a system that enables enterprise level verification of a caller based on domain name to which the caller pertains.

[00011] It is another object of the present disclosure to provide for a system that provides to a recipient in real-time the enterprise level verification of a caller.

[00012] It is yet another object of the present disclosure to provide for a system that provides to a recipient in real-time authentic profile of a caller.

[00013] It is an object of the present disclosure to provide for a system that automatically updates itself to provide latest enterprise level verification of a caller.

[00014] It is another object of the present disclosure to provide for a system that is available all the time to its users.

SUMMARY

[00015] The present disclosure relates to caller identification systems and methods that enable enterprise level verification of a caller based on domain name to which the caller pertains so as to enable the called party to view that the caller is a verified caller and pertains/belongs to the enterprise that corresponds to the domain name.

[00016] This summary is provided to introduce simplified concepts of the proposed systems and methods that are further described below in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended for use in determining/limiting the scope of the claimed subject matter.

[00017] In an aspect, present disclosure elaborates upon a system for enterprise domain based caller verification, the system including: a non-transitory storage device having embodied therein one or more routines operable to facilitate the enterprise domain based caller verification; and one or more processors coupled to the non-transitory storage device and operable to execute the one or more routines, wherein the one or more routines include: a caller verification module, which when executed by the one or more processors, can verify a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the caller verification module by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information; and a caller information intimation module, which when executed by the one or more processors, can intimate caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory .

[00018] In another aspect, the contact information can include any or a combination of first name, last name, email address, phone number, URL, physical address, fax number, and social media handle.

[00019] In yet another aspect, the authorized person can be authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain.

[00020] In an aspect, the caller verification status can be intimated to the recipient using any or a combination of an insignia, symbol, a badge, or a colored graphical representation.

[00021] In another aspect, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

[00022] In yet another aspect, the caller information intimation module can intimate the caller verification status upon receiving a request from the recipient.

[00023] In an aspect, the caller verification module and/or the information intimation module (this aspect can be implemented in any of these or a third module) can check if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory.

[00024] In another aspect, the system can receive one or more authenticated enterprise contact directories from respective enterprises, and during verification of the caller, can search for a match between phone number of the caller and phone numbers associated with contacts that form part of the received authenticated enterprise contact directories. [00025] In yet another aspect, if the caller is associated with multiple domains or authenticated enterprise contact directories, the caller can be enabled to pre-select which domain/directory to be used while giving the caller verification status to the recipient.

[00026] In an aspect, the authenticated enterprise contact directory can be updated by the enterprise or the authorized person, and can be sent to the system upon such updation.

[00027] In another aspect, the caller verification status can be accompanied with any or a combination of a contact information attribute of the caller, designation of the caller, address of the caller, web or social links pertaining to the caller, and company name of the caller.

[00028] In yet another aspect, an administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

[00029] In an aspect, the system can further include a call initiation confirmation module, which when executed by the one or more processors, can check, in real-time, based on a call log received from the caller, if the caller initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient.

[00030] In another aspect, the call log can be sent from caller device of the callersooner the caller initiates the call to the recipient, the call log comprising the phone number of the recipient and timestamp associated with the initiated call.

[00031] In yet another aspect, an administrator of the domain can discover all call logs associated with callers of the domain.

[00032] In an aspect, if the check is negative, the recipient can be informed that the caller has not initiated the call.

[00033] In another aspect, the authenticated enterprise contact directory can include only the authorized person as the contact.

[00034] In yet another aspect, the authenticated enterprise contact directory can be a shared contact directory (CD), and each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD. [00035] In an aspect, present disclosure elaborates upon a method for enterprise domain based caller verification, the method including: verifying, at a computing device, a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the computing device by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information; and intimating, from the computing device, caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory .

[00036] In another aspect of the method, the authorized person can be authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain. Further, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

[00037] In yet another aspect of the method, the computing device can check if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory. Further, the authenticated enterprise contact directory can be updated by the enterprise or the authorized person, and can be sent to the system upon such updation.

[00038] In an aspect of the method, an administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

[00039] In another aspect, the method can further include the step of checking, in realtime, based on a call log received from the caller, if the caller initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient. The call log can be sent from caller device of the caller sooner the caller initiates the call to the recipient, the call log comprising the phone number of the recipient and timestamp associated with the initiated call. On the other hand, if the check is negative, the recipient can be informed that the caller has not initiated the call.

[00040] In another aspect, the authenticated enterprise contact directory can include only the authorized person as the contact. The authenticated enterprise contact directory can also be a shared contact directory (CD), wherein each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.

[00041] Various objects, features, aspects and advantages of the present disclosure will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like features.

BRIEF DESCRIPTION OF THE DRAWINGS

[00042] FIGs. 1A and IB illustrate high-level architecture diagrams elaborating upon overall working of the proposed system in accordance with an embodiment of the present disclosure.

[00043] FIG. 2 illustrates exemplary functional modules that enable domain based caller verification in accordance with an embodiment of the present disclosure.

[00044] FIGs. 3A to 3C elaborate upon functioning of the proposed system, in accordance with an exemplary embodiment of the present disclosure.

[00045] FIG.3D illustrates how an authorized person can authorize other persons to create a plurality of authorized enterprise contact directories in accordance with an exemplary embodiment of the present disclosure.

[00046] FIG. 4 illustrates a method of working of system proposed, in accordance with an exemplary embodiment of the present disclosure.

DETAILED DESCRD7TION

[00047] The following is a detailed description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are in such detail as to clearly communicate the disclosure. However, the amount of detail offered is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.

[00048] In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details.

[00049] Embodiments of the present invention include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special- purpose processor programmed with the instructions to perform the steps. Alternatively, steps may be performed by a combination of hardware, software, and firmware and/or by human operators.

[00050] Embodiments of the present invention may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program a computer (or other electronic devices) toperform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).

[00051] Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product. [00052] If the specification states a component or feature "may", "can", "could", or "might" be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

[00053] As used in the description herein and throughout the claims that follow, the meaning of "a," "an," and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

[00054] Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. These exemplary embodiments are provided only for illustrative purposes and so that this disclosure will be thorough and complete and will fully convey the scope of the invention to those of ordinary skill in the art. The invention disclosed may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Various modifications will be readily apparent to persons skilled in the art. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, all statements herein reciting embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure). Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

[00055] Each of the appended claims defines a separate invention, which for infringement purposes is recognized as including equivalents to the various elements or limitations specified in the claims. Depending on the context, all references below to the "invention" may in some cases refer to certain specific embodiments only. In other cases it will be recognized that references to the "invention" will refer to subject matter recited in one or more, but not necessarily all, of the claims.

[00056] All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "such as") provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[00057] Various terms as used herein are shown below. To the extent a term used in a claim is not defined below, it should be given the broadest definition persons in the pertinent art have given that term as reflected in printed publications and issued patents at the time of filing.

[00058] The present disclosure relates to caller identification systems and methods that enable enterprise level verification of a caller based on domain name to which the caller pertains so as to enable the called party to view that the caller is a verified caller and pertains/belongs to the enterprise that corresponds to the domain name.

[00059] In an aspect, present disclosure elaborates upon a system for enterprise domain based caller verification, the system including: a non-transitory storage device having embodied therein one or more routines operable to facilitate the enterprise domain based caller verification; and one or more processors coupled to the non-transitory storage device and operable to execute the one or more routines, wherein the one or more routines include: a caller verification module, which when executed by the one or more processors, can verify a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the caller verification module by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information; anda caller information intimation module, which when executed by the one or more processors, can intimate caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory . [00060] In another aspect, the contact information can include any or a combination of first name, last name, email address, phone number, URL, physical address, fax number, and social media handle.

[00061] In yet another aspect, the authorized person can be authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain.

[00062] In an aspect, the caller verification status can be intimated to the recipient using any or a combination of an insignia, symbol, a badge, or a colored graphical representation.

[00063] In another aspect, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

[00064] In yet another aspect, the caller information intimation module can intimate the caller verification status upon receiving a request from the recipient.

[00065] In an aspect, the caller verification module (or any other configured module)can check if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory.

[00066] In another aspect, the system can receive one or more authenticated enterprise contact directories from respective enterprises, and during verification of the caller, can search for a match between phone number of the caller and phone numbers associated with contacts that form part of the received authenticated enterprise contact directories.

[00067] In yet another aspect, if the caller is associated with multiple domains or authenticated enterprise contact directories, the caller can be enabled to pre-select which domain/directory to be used while giving the caller verification status to the recipient.

[00068] In an aspect, the authenticated enterprise contact directory can be updated by the enterprise or the authorized person, and can be sent to the system upon such updation.

[00069] In another aspect, the caller verification status can be accompanied with any or a combination of a contact information attribute of the caller, designation of the caller, address of the caller, web or social links pertaining to the caller, and company name of the caller.

[00070] In yet another aspect, an administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

[00071] In an aspect, the system can further include a call initiation confirmation module, which when executed by the one or more processors, can check, in real-time, based on a call log received from the caller, if the caller initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient.

[00072] In another aspect, the call log can be sent from caller device of the caller sooner the caller initiates the call to the recipient, the call log comprising the phone number of the recipient and timestamp associated with the initiated call.

[00073] In yet another aspect, an administrator of the domain can discover all call logs associated with callers of the domain.

[00074] In an aspect, if the check is negative, the recipient can be informed that the caller has not initiated the call.

[00075] In another aspect, the authenticated enterprise contact directory can include only the authorized person as the contact.

[00076] In yet another aspect, the authenticated enterprise contact directory can be a shared contact directory (CD), and each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.

[00077] In an aspect, present disclosure elaborates upon a method for enterprise domain based caller verification, the method including: verifying, at a computing device, a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the computing device by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information; and intimating, from the computing device, caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory . [00078] In another aspect of the method, the authorized person can be authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain. Further, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

[00079] In yet another aspect of the method, the computing device can check if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory. Further, the authenticated enterprise contact directory can be updated by the enterprise or the authorized person, and can be sent to the system upon such updation.

[00080] In an aspect of the method, an administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

[00081] In another aspect, the method can further include the step of checking, in realtime, based on a call log received from the caller, if the caller initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient. The call log can be sent from caller device of the caller sooner the caller initiates the call to the recipient, the call log comprising the phone number of the recipient and timestamp associated with the initiated call. On the other hand, if the check is negative, the recipient can be informed that the caller has not initiated the call.

[00082] In another aspect, the authenticated enterprise contact directory can include only the authorized person as the contact. The authenticated enterprise contact directory can also be a shared contact directory (CD), wherein each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.

[00083] Aspects of the present disclosure relate to systems and methods that enable enterprise level verification of a caller based on domain name to which the caller pertains so as to enable the called party to view that the caller is a verified caller and pertains/belongs to the enterprise that corresponds to the domain name.

[00084] In an exemplary implementation, system of the present disclosure can enable a caller to register himself and receive, either during or after the registration process, his/her enterprise level email address (such as David@xyz-corp.com, where xyz-corp.com is the domain name of the enterprise), based on which the system can then verify the email and the caller by sending a verification email to the enterprise level email address (ELEA) provided by the caller, which verification email can be acknowledged by the caller to confirm that the caller actually pertains to the enterprise. Post such confirmation, whenever the caller initiates a call to a recipient (also referred to as called party or callee), the recipient can view that the caller is verified and pertains to the enterprise. The recipient can get various information pertaining to the caller either automatically or upon generating a corresponding request for the proposed system.

[00085] In another implementation, when the caller leaves/quits/resigns from the enterprise, as the ELEA would be disassociated with the caller (by the enterprise), the system can detect such disassociation and automatically remove the corresponding ELEA when the disassociation is detected. This can enable the caller to start the registration process afresh when the caller joins a new organization and provides a new ELEA without causing erroneous results.

[00086] In yet another implementation, system of the present disclosure can be configured to receive, from a user (such as a network administrator) authenticated by the enterprise, one or more contacts that form part of an authenticated enterprise contact directory (ECD), each of the one or more contacts having the phone number of the respective contact and mapped email address, based on which receipt, the system can verify multiple contacts in a single go so that when any of the one or more contacts make a call to a third-party (called party/recipient), the recipient is able to see the verified status of the contacts. As mentioned above, disassociation too can take place in a similar manner when a contact is, for instance, removed/deleted from the contact directory. Similarly, addition of a new contact in the ECD can trigger the action of automatically verifying the new contact and user associated with the contact.

[00087] In an aspect, apart from verifying only that the caller is associated with a particular domain name, system of the present disclosure can also be configured to verify that the designation, address, and company name of the caller is correct, for which the system can also trigger a separate email to the network administrator (or any other person authorized by the enterprise to authenticate/verify such information) of the enterprise so as to confirm that the official details entered by the caller are correct.

[00088] In yet another aspect, before enabling a user to submit a verification input to initiate verification by the proposed system that he/she pertains to a domain name / associated enterprise, the system can, during registration or afterwards, verify the phone number/mobile number of the caller by sending a one-time password (OTP) to the number being used for registration and then upon entry of the OTP, confirming that the phone number being used is correct.

[00089] In another aspect, system of the present disclosure can further automate the complete process of receiving enterprise level verification inputs, sending verification emails to respective ELEAs, receiving verification confirmations from the authentic callers, and then enabling called parties to view (say by means of a badge or any appropriate insignia) that the caller is verified and part of the concerned domain name/enterprise.

[00090] In an aspect, it would be appreciated that one exemplary implementation of the present system can be in a client-server architecture, wherein client modules can be configured in both the caller devices as well as called/recipient devices, and server module can be a central module that is configured to receive enterprise level verification inputs from one or more callers, send verification emails to respective ELEAs of the one or more callers, receive verification confirmations from the authentic callers, and then enable called parties to view that the caller is verified and is part of the concerned domain name/enterprise. Using such an implementation, the called party/recipient can be intimated that the caller is verified by means of the client module of the proposed system that is configured/installed in the recipient's device. Such client module that is configured on the recipient can therefore confirm that the phone number is correctly mapped to the domain name.

[00091] Client module/side that is configured on the caller device (such as caller mobile phone or an IP enabled phone or any other telephony device) can, on the other hand, be configured to authenticate if the caller identifier is authentic by checking if the call was made from the device having the calling identifier number that is recognized/authenticated by the system. Client module configured on the caller device may further be able to provide other updates including but not limited to status, call properties, time, location, or other situation related information. The client module can further provide details of a data channel to enable syncing of data that may be used by the receiver module when the call is in progress. The data channel may also contain executable code that gets executed on the receiver device automatically or when requested by the receiver.

[00092] In an exemplary embodiment, proposed system can enable a caller, using caller mobile device (CMD) to provide his/her enterprise level email address (ELEA) to the system. The ELEA can be one that has been officially provided to the caller and maps to domain name of enterprise/company/organization (the terms being used interchangeably herein) the caller is working for/belongs to. For instance, if domain name of caller's organization is xyz.com, ELEA allotted to the caller could be cailer@x z. com. As is well known, any person in an organization is allotted an ELEA that usually carries his/her name followed by the symbol '@'and then the organization's domain name, as mail servers of the organization are also mapped to the same domain name. However, this is not a limitation and the caller can provide any ELEA allotted by his organization to him, as long as organization's domain name is provided in the ELEA's suffix (the domain name also including its extension such as .org, .in , .com and the like ).

[00093] In another aspect, proposed system can also enable the caller to provide his/her mobile device number (that is, phone number of caller mobile device CMD) to the proposed system. In an exemplary embodiment, proposed system can automatically detect the mobile number associated with the CMD. In yet another aspect, proposed system can enable the caller to provide any phone number he/she wants associated with his/her ELEA. It can be appreciated that it is not necessary for the caller to use any telephony device and indeed he/she can provide his/her ELEA and a phone number (that can be a landline phone number, for instance) to proposed system using a computing device in operative communication with the proposed system. Such combination of a phone number and ELEA provided by the caller can constitute a 'verification input' that can initiate the verification process described herein.

[00094] In yet another aspect, proposed system can verify the phone number/mobile number of the caller by sending a one-time password (OTP) to the mobile number being used by the caller and then upon entry of the OTP, confirming that the phone number being used is correct. Such verification can be performed the first time the caller registers with the proposed system, such registration showing the intent of the caller to seek verification by the proposed system that he/she pertains to the enterprise to whom the domain name of his/her ELEA belongs for further use as elaborated hereunder. In another aspect, such verification of the phone number/mobile number of the caller by sending an OTP can be performed anytime after registration as well.

[00095] In yet another aspect, proposed system can enable the caller to initiate verification as elaborated herein On the fly' as well, that is without any registration process. However, if the caller decides to register, various information provided by him/her can be stored by the proposed system for future reuse as required. In latter case, after one verification process as described herein has been completed, for next calls thereafter proposed system can instead provide information from that stored by it (for instance, in a general/universal contact directory) thereby decreasing substantially the response time of the proposed system.

[00096] As already elaborated, phone number and ELEA as provided by the caller can constitute the 'verification input' upon which basis verification can proceed as elaborated hereunder.

[00097] In another aspect, upon receipt of the verification input containing ELEA therein, proposed system can start a verification/authentication process and send an email (interchangeably termed as verification email) to the ELEA. Proposed system can enable various verification means. For instance, proposed system can wait for a pre-determined time and if the email doesn't bounce back, can consider the ELEA as genuine. In another exemplary embodiment, the email sent can carry an authentication link that when clicked can verify the ELEA. In yet another exemplary embodiment, the email can carry a code that may need to be entered in a form provided at a website operatively configured with the proposed system to verify the ELEA. In yet another exemplary embodiment, proposed system can verify that the ELEA provided by the caller indeed belongs to him/her by confirming from an administrator or from an authorized person of the enterprise domain name to which the ELEA pertains as to whether the ELEA is genuine that is, the ELEA exists and is associated with/belongs to the caller having phone number associated with his/her CMD. All such and any other means that enable the ELEA to be properly authenticated are completely within the present disclosure.

[00098] It can readily be appreciated that since usually only properly authenticated email owners can access emails addressed to their respective email IDs, using procedures well known in the art, the ELEA can be considered genuine only when appropriate verifying actions are taken by the caller. [00099] Once the ELEA has been successfully verified, proposed system can associate the ELEA with the mobile number (phone number) of the CMD and further at least the phone number and enterprise information based upon enterprise domain as indicated in ELEA associated with the phone number. All this information can be termed as a verification tag.

[000100] In another aspect, after generation of the verification tag as elaborate above, when the caller next calls, using his/her CMD a recipient (interchangeably termed as called party or callee herein) on recipient mobile device (RMD), proposed system can enable the recipient to generate, using the RMD a verification request that can carry phone number of the CMD.

[000101] In an aspect, the verification request can be generated automatically by proposed system (using, for instance, appropriately configured modules downloaded on the RMD, such modules forming part of mobile application of the proposed system) or manually by the recipient using the RMD by means of appropriate user interfaces provided on the RMD by the proposed system.

[000102] In yet another aspect, based upon phone number of the CMD, proposed system can retrieve the associated verification tag and provide information in the verification tag as caller verification status to the RMD and accordingly, the RMD can display the caller verification status on its display for further use by the recipient as appropriate.

[000103] In an aspect, the caller verification status can include any or a combination of an insignia, symbol, a badge, or a colored graphical representation. Such insignia, symbol, a badge, or a colored graphical representation can for instance, readily and graphically identify the enterprise associated with the verified ELEA.

[000104] As already elaborated, the caller verification status can carry results of ELEA verification and if successful, at least the phone number and company information based upon organization domain as indicated in ELEA associated with the phone number. In this manner, the recipient can establish whether the caller is genuinely associated with the enterprise/organization/company he/she maybe claiming he/she is calling from. As can be appreciated, this can help in preventing fraudulent calls.

[000105] In an exemplary embodiment, the proposed system can be configured to operatively communicate with an enterprise contact management system (ECMS) that can store detailed information associated with any ELEAs generated by corresponding enterprise, associating with each ELEA profile information viz. name, department, and designation etc. of the corresponding person. Upon receipt of verification request from an RMD as elaborated above, proposed system can retrieve the corresponding ELEA, and, based upon the ELEA retrieve from the ECMS profile information of the corresponding caller. Proposed system can accordingly send enterprise information as well as profile information of the caller to the RMD that can display the enterprise information as well as profile information of the caller on its display for further use by the recipient as appropriate

[000106] In yet another aspect, proposed system can determine activation status of an ELEA provided by a caller at periodic or random intervals such that if the ELEA is determined to be inactive or incorrect, verification tag of the caller (and associated CMD) can be updated to indicate that the caller/ associated CMD is not associated with the enterprise domain name. For the purpose, for instance, proposed system can periodically or randomly send verification mail as elaborated above.

[000107] As can be readily understood, if a caller leaves/quits/resigns from the enterprise, the enterprise will delete/disassociate the corresponding ELEA. Hence, upon the next periodic/random check as elaborated above, verification information would indicate a failure of ELEA verification. Based upon such detection, proposed system can automatically remove the corresponding ELEA/ associated phone number/verification tag. This can enable the caller to start the registration process afresh when, for instance, he/she joins a new enterprise and provides a new ELEA and same phone number as before, without causing erroneous results.

[000108] In another aspect, the proposed system can automate the complete process of receiving enterprise level verification inputs ( such inputs being received from different callers to initiate the verification process, as elaborated above) , sending verification emails to respective ELEAs, receiving verification information from the authentic callers, and then enabling called parties to view (say by means of a badge or any appropriate insignia) that the caller is verified and part of the concerned domain name/enterprise.

[000109] Yet another implementation of the proposed system can be implemented by means of one or more authenticated enterprise contact directories that can be provided by an authorized person / domain administrator, such authenticated enterprise contact directories being further used to verify a caller. Since such an implementation can find wide use, it is further elaborated as under. [000110] Various implementations such as web-based implementations, those using a mobile application, a LAN based implementations and the like of the proposed system are well within the scope of the present disclosure.

[000111] FIGs. lAand IB illustrate high-level architecture diagrams elaborating upon overall working of the proposed system in accordance with an embodiment of the present disclosure.

[000112] Proposed system can be configured as a mobile application relevant modules of which can be downloaded on different users' mobile devices to enable functioning as under. Proposed system can as well be configured in the cloud to be in operative communication with various devices as elaborated herein. In this manner, proposed system can be available at all times to its users.

[000113] In an aspect, proposed system can verify a callerby virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the proposed system by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory (AECD) comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information. Thereafter, proposed system can intimate caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory.

[000114] For instance, an administrator or a person authorized by a company/enterprise can share a AECD pertaining to the company with the proposed system, based on which whenever a caller that forms part of the AECD calls a recipient/callee, the recipient can be informed and confirmed whether the caller is actually associated with the company by searching for a match for the caller phone number in the AECD such that if a match is found, it can be confirmed that the caller is genuinely a part of the enterprise. It would be appreciated that each contact that forms part of the AECD can also be verified independently by the proposed system to confirm if the contact actually is associated with the company, such verification, in an instance, being performed by sending an email to the enterprise/company domain based email address of the contact and expected a defined response to said email. [000115] FIG. 1A elaborates how the proposed system can authenticate a person (also interchangeably referred to as a user or a caller or a contact of a contact directory) to become an authorized person/domain administrator in accordance with an exemplary embodiment of the present disclosure. In an aspect, proposed system requires an authenticated enterprise contact directory (AECD) to be made accessible to it by an authorized person (such as administrator or director) pertaining to an enterprise, the AECD comprising a plurality of contacts (also referred to as member or users of the AECD) that form part of the enterprise, each contact of said plurality of contacts being associated with respective contact information. As elaborated above, the AECD has to be provided to the proposed system by a person properly authorized. Proposed system can automatically authenticate a person to thereafter designate him/her as the authorized person, as elaborated in FIG. 1A.

[000116] As elaborated in FIG. 1A, a person 108 intending to become an authorized person can send, from his/her computing device 104, an authentication request to proposed system 102 Based upon system configuration, the authentication request can follow a pre- determined format. For instance, the proposed system can have on its interface, a form that person 108 can fill using his/her computing device 104 (say as part of the registration process), the form asking for pertinent information such as designation, name, phone number and domain based email address of person 108. The domain based email address provided by person 108 has to be derived from the website domain of the enterprise/organization/company etc. that person 108 wants to provide an AECD to the proposed system. For instance if an enterprise has a website domain abc.com, the domain based email address can be xyz@abc.com. It can be appreciated that mail servers of a domain are configured accordingly, as is well known in the art. Besides, the form can provide for further identifying information. For instance, if person 108 is domain administrator (that is administrator of the website domain of the enterprise), the form can ask for such information wherein the system can match the information provided by the person 108 to such information publicly available, including email address of the domain administrator, as a step in the authentication.

[000117] Upon relevant information being provided by person 108, proposed system 102 can enable computing device 104 to generate an authentication request that system 102 can receive. Upon receipt of the authentication request, system 102 can send an authentication email to the domain based email address 108. The authentication email can carry various means of authentication. In an exemplary embodiment, the authentication email can carry a verification link. Upon receipt of this email in email box mapped to domain based email address 106 person 108 can click on the link to reconfirm that he/she owns that domain based email address. This reconfirmation can be sent as an authentication response to the proposed system basedupon which system 102 can grant an authorized person status to person 108.

[000118] Various other authentication means, as elaborated further, can be deployed to enable system 102 give status of an authorized person to someone after proper authentication. In an exemplary embodiment domain administrator of the website of enterprise whose AECD is to be provided to the proposed system can be given authorized person status, using means as elaborated above. It should be appreciated that although examples are being explained with reference to AECD implementation, it is very much possible that each contact/member/user that forms part of the AECD authenticated/verifies himself/herself based on his/her enterprise domain based email address that is provided to the proposed system, based on which the system can verify whether the user is genuinely associated with (or employed with) the enterprise.

[000119] As can be readily understood, an enterprise as used in the proposed system can be any group of people that with their email addresses mapped to a common domain. For instance, a club can have a website domain club.com and can have several members all having email addresses with suffix as @club.com. All such members can be made part of the AECD being created by the authorized person 108 for further verification as elaborated in FIG. IB.

[000120] In an aspect, all data in the proposed system can be maintained in an encrypted form using appropriate techniques (such as PKI - public key infrastructure) so that it is held secure from any unauthorized retrieval efforts such as hacking and the like. In another aspect, each verified user can also be associated with a private key, wherein public keys can be shared with members of the AECD(s) that he/she forms part of.

[000121] FIG. IB elaborates upon an overall working of the proposed enterprisedomain based caller level verification system, in accordance with an exemplary embodiment of the present disclosure.

[000122] As illustrated in FIG. IB, an authorized person/domain administrator (AP) 130of an enterprise (for instance enterprise XYZ Ltd.) can provide, using his/her computing device 110, an authorized enterprise contact directory (AECD) to the proposed system 102, as illustrated at 120. The AECD can include one or more contacts that form part of the enterprise, each of the one or more contact having respective contact information such as their names, designations, phone numbers, URLs, addresses, social media handle, and enterprise domain based email addresses (ELEAs). In an exemplary embodiment, one such person can be the caller 116 as illustrated.

[000123] In an exemplary embodiment, caller 116 can, using his/her caller mobile device (CMD)118 (whose mobile number is already associated with caller 116 contact information in the AECD), call a recipient 112 on recipient mobile device (RMD) 114, as illustrated at 122. Upon receipt of the call by RMD 114, system 102 can enable RMD 114 to generate either automatically or manually upon an appropriate action by recipient 112, a caller verification request that system 102 can receive, as illustrated at 122. For instance, the RMD 114 can be configured with a client-side implementation of the proposed system, which client-side implementation can detect each incoming call to the RMD 114 and send the caller phone number to the system 102 to verify the verification status of the caller with respect to the enterprise with which the caller says he's from and the enterprise indicated in the AECDs stored in the system 102 (if at all the phone number is present in any AECD that the system 102 has access to). The caller verification request 122can carry mobile number of the CMD 118. This mobile number can be, for instance, one displayed on display of RMD 114.

[000124] In another aspect, upon receipt of caller verification request, system 102 can check if mobile number of CMD 118 matches any of the phone numbers in the AECD(s) provided to it by AP(s) 108, and accordingly send a caller verification status as illustrated at 124 to recipient mobile device 114 for information and use of recipient 112.

[000125] In an exemplary embodiment, if mobile number of CMD 118 matches a phone number in the AECD, the caller verification status 124 can include contact information associated with the mobile number as available in the AECD. The contact information can include any or a combination of first/last name, designation, company name, address, office phone number, ELEA, location, social media handle etc. of the caller 116. Upon receipt of such information, recipient 112 can handle the call appropriately or take a decision on whether or not to continue the call. It would be appreciated that the caller 116 can, during his/her registration with the system 102, indicate the contact information that he/she would like to be sent to the recipients of his/her call. For instance, the caller may configured that he/she wants only the company name and email address to be sent to the recipient as part of the caller verification status.

[000126] On the other hand, if there is no match found, system 102 can provide a caller verification status of 'unverified' thereby appropriately warning the recipient 112. It is to be appreciated that the system 102 can search for the caller phone number across multiple AECDs that it has access to.

[000127] In another aspect, system 102 can determine if caller 116 is attempting to 'spoof his/her mobile device number, and warn recipient 112 accordingly. Spoofing allows a caller to display a phone number on the recipient's mobile device different from the caller's actual phone number, thereby enabling the caller to fake his/her identify and make fraudulent calls. To prevent spoofing, system 102 of the present disclosure can enable the caller mobile device 118 to generate a call log 132 when a call is placed, the call log 132 carrying the actual/real mobile number of caller mobile device 112 and of the recipient mobile device 114 alongwith the timestamp of the call initiation, which call log 132 can be received by the proposed system 102. Further, from the caller verification request 122 received from the RMD 114,the system 102 can extract the apparent mobile number of CMD 118, and compare/match the two numbers (one received from call log and one received from the RMD 114) so as to generate a call initiation confirmation message/status 126 that can be sent to RMD 114 for use/information of recipient 112. This helps confirm that the mobile device 118 making the call to the recipient 112 is same as the one that generated/initiated the call as well and help prevent spoofing. It would be appreciated that in order for the CMD 118 to send the call log 132, the CMD 118 may need to be configured with a client side version/executable/application of the proposed system 102, which helps send call logs in real-time from the CMD 118 to the system 102, wherein the call logs 132 can not only include the numbers of the caller and the recipient, but can also indicate the time when such a call is initiated so that the matching can be effectively. For instance, if a call log 132 came at 1442 Hrs from the CMD 118, and at 1443, the caller verification request 122 was received, a match can be done between the caller/recipient phone numbers present in the log 132 with the request 122 so that if a match is found, message 126 can be sent to the recipient confirming that the call/caller is verified.

[000128] In an exemplary embodiment, in case the two numbers match, the call initiation confirmation message/status 126 can inform recipient 112 that the CMD 118's mobile number is genuine. On the other hand, if the two numbers do not match, caller information status 128 can accordingly inform recipient 112 that the CMD 118/caller 116 is attempting a spoofed call so that recipient 112 is appropriately alerted.

[000129] FIG. 2 illustrates exemplary functional modules that enable domain based caller verification in accordance with an embodiment of the present disclosure.

[000130] In an aspect, relevant modules of the proposed system can be configured to be operatively connected to a website, or be part of a mobile application that can be downloaded on one/more mobile devices that can connect to Internet. In such fashion, the proposed system can be available 24*7 to its users. Any other manner of implementation of the proposed system or a part thereof is well within the scope of the present disclosure/invention.

[000131] In an exemplary embodiment, proposed system can have a caller verification module 202, a caller information intimation module 204, and a call initiation confirmation module 206.

[000132] In an aspect, caller verification module 202 can verify a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory (AECD) being made accessible to the caller verification module 202 by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information.

[000133] In another aspect, the contact information for a contact can include any or a combination of first name, last name, email address, phone number, URL, office address, home address, fax number, social media handle, among any other information shared by the contact. In an exemplary embodiment, a contact can choose what information he/she wants included in his/her contact information. For instance, a contact may like to give out his social media handle while another may not like so. Proposed system can enable any contact to provide any such combination that can be included in their respective contact information. In this manner, a contact can maintain as much privacy as he/she wishes.

[000134] In an exemplary embodiment, proposed system can enable contact information to include some essential information such as the contact's email address that can be his/her enterprise domain level email address (ELEA), thereby assuring a recipient (being called by the caller)that the caller genuinely belongs to the enterprise/domain he she claims to be working for. Likewise, phone number can be made an essential information to enable determination

[000135] In an aspect, when requested by the recipient (through a caller verification request sent by the call recipient to the system), the proposed caller verification module 202 can check if the caller is a contact that forms part of the AECD by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of the AECD. As elaborated further, module 202 can pass results of such check/verification to module 204 that can provide such results to the recipient.

[000136] Since authentication requires the contact to be present in an authenticated enterprise contact directory being made accessible to the caller verification module 202 by an authorized person pertaining to an enterprise, it can be readily understood that proper authentication of the authorized person prior to granting him/her such an authority is critical.

[000137] As already elaborated (FIG. lA),an authorized person (AP) can be determined by sending an authentication email to the domain based email address of a person. The email can ask for specific actions to be performed by its recipient, such actions serving to authenticate the authorized person. For instance, the email can carry a verification link that can be time bound. Or the email can carry an encrypted key as part of a URL. Clicking on the URL can take the recipient to a website configured to verify the key (using, for example, PKI -public key infrastructure - based techniques). Forwarding the email to another can corrupt the verification link therein making it unusable. Or the link can take the recipient to a system configured with biometric recognition (such as fingerprint or facial recognition) that can enable the recipient to prove that he/she is authorized to create/manage the authenticated ECDs of the enterprise/ domain or administrator of the domain. Authentication can also take the form of a cookie sent on the recipient's computing device (that can be a mobile device/smartphone as well), thereby binding/associating the computing device as well to the authorized person upon completion of the authentication process whereby the authorized person can make accessible the authenticated ECD to the proposed system using only the associated/bound computing device. All such and any other suitable authenticating techniques are well within the scope of the present disclosure. Authentication email can as well be sent to administrator of the domain, asking the administrator to authenticate the authorized person (that can be the administrator himself/herself as well). [000138] In an aspect, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain. In this manner, a plurality of authenticated enterprise contact directories (AECDs) can be made accessible to the proposed system, and further used to verify various callers as elaborated herein. The authorized persons can be in principle-agent relationship with each other, wherein the principle is responsible for actions of the agents and so, implicitly responsible for the ECDs (enterprise contact directories) created by the various agents.

[000139] In an aspect, module 202 can receive/ be operatively connected to one or more authenticated enterprise contact directories from respective enterprises, and during verification of the caller, can search for a match between phone number of the caller and phone numbers associated with contacts that form part of the received authenticated enterprise contact directories.

[000140] In another aspect, if the caller is associated with multiple domains or authenticated enterprise contact directories, module 202 can enable the caller to pre-select domain/directory to be used while giving the caller verification status to the recipient, such caller verification status being provided by module 204, as elaborated further.

[000141] It is to be appreciated that each contact that forms part of an AECD may also be independently verified for their association with the enterprise in context through their respective enterprise domain based email address, such verification being done by sending an email to their respective enterprise domain based email address or to a known administrator of the enterprise asking them to confirm whether the contact is genuinely employed/part/affiliate of the enterprise.

[000142] In an aspect, module 202 can enable the enterprise or the authorized person to update the AECD, and can receive the updated AECD and use that thereafter. In this manner, proposed system can always have access to latest updated and authentic data.

[000143] In an aspect, the administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts. [000144] In an aspect, caller information intimation module 204 can intimate caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory.

[000145] In another aspect, the caller verification status can be intimated to the recipient using any or a combination of an insignia, symbol, a badge, or a colored graphical representation. The insignia etc. can be, for instance, logo of the enterprise the caller belongs to.

[000146] In an exemplary embodiment, the caller verification status can be appended to contact information of the contact thus conveying to the recipient upon completion of caller verification comprehensive data regarding the caller, including an insignia/graphical representation and the like of the enterprise/organization he/she is working for.

[000147] In an aspect, module 204 can intimate the caller verification status of a call being received by the recipient upon receiving a request from the recipient. As can be readily understood, there can be circumstances wherein the recipient may not need to make this request, for instance, when the caller is already well known to the recipient / in the phone book of the recipient's mobile device. In this manner, the system can avoid unnecessary data processing, making it more responsive when required. Module 204 can as well generate this request automatically interchangeably termed as caller verification request herein.

[000148] In an aspect, upon receipt of a call and a caller verification request, module 204 can pass phone number of the incoming call to module 202. Module202 can, upon receipt of the phone number, check if there is a match with any of the phone numbers associated with the plurality of contacts that form part of authenticated enterprise contact directory. If so, module 204 can proceed further as elaborated above. However, if match is not found, module 204 can instead inform the recipient that caller verification status is 'unverified' or a similar suitable message so as to alert the recipient.

[000149] In another aspect, module 204 can append to the caller verification status any or a combination of a contact information attribute of the caller, designation of the caller, address of the caller, web or social links pertaining to the caller, and company name of the caller. In this manner, caller verification status can convey to the recipient comprehensive information about the caller [000150] As can be readily understood, features such as above can prevent fraudulent calls, and can alert a recipient as soon as the recipient receives a suspicious call.

[000151] In an aspect, module 206 can check, in real-time, based on a call log received from the caller, if the caller actually initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient. The call log can be sent from the caller device as soon as the caller initiates the call to the recipient, and can include the phone number of the recipient and timestamp associated with the initiated call. In case the check is negative, module 206 can inform the recipient accordingly that he caller has not initiated the call.

[000152] For the purpose, module 206 can generate on a caller mobile device a call log when a call is placed, the call log carrying the actual/real mobile number of the caller mobile device. Further, from the caller verification request (as elaborated above) module 206 can extract the apparent mobile number of caller device. Module 206 can compare/match the two numbers to generate a caller information status that it can send to recipient device for use/information of the recipient.

[000153] In an exemplary embodiment, in case the two numbers match, the caller information status can inform the recipient that the calling device's mobile number is genuine. On the other hand, if the two numbers do not match, caller information status can accordingly inform the recipient that the caller mobile device/caller is attempting a spoofed call so that the recipient is appropriately alerted.

[000154] In this manner, module 206 can determine if a caller is attempting to 'spoof his/her mobile device number and warn recipients accordingly.

[000155] In an aspect, module 206 can append all call logs to the corresponding contact information in the corresponding authenticated enterprise contact directory (AECD). This can enable authorized person that made available the AECD to the proposed system and/or administrator of the domain to which the AECD belongs to discover all call logs associated with callers of the domain (that is, all calls made by any contact in the AECD as all contacts pertain to one domain only).

[000156] In an exemplary embodiment, the AECD can include only the authorized person as the contact. The authorized enterprise contact directory can as well be a shared contact directory (CD), wherein each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD. [000157] FIGs. 3A to 3C elaborate upon functioning of the proposed system, in accordance with an exemplary embodiment of the present disclosure.

[000158] As illustrated in FIG. 3A, a caller 302 can, using caller mobile device (CMD) 304 call a recipient 306 on recipient mobile device (RMD) 308, as shown at 310.

[000159] Upon receipt of the call, proposed system can start verifying the caller as elaborated above. In case of a successful verification, as illustrated in FIG. 3B, proposed system can display on recipient mobile device 308 that the mobile number is verified, as shown at 322. Further, profile of the caller such as caller name (324), caller company (326) and caller designation (328) can also be displayed on RMD 308. For instance, if the system receives a caller verification request for caller having number 9810617XXX, and there is no call log received in the last pre-defined time of say 5 minutes from 9810617XXX, the system can intimate to the recipient that the call initiation is not from 9810617XXX, and hence the call is not verified.

[000160] However, in case verification fails, proposed system can display a message on RMD 308 as shown at 342 in FIG. 3C. The message can indicate that the mobile number of CMD 304 is unverified. Accordingly, recipient 306 can proceed with caution regarding identity of caller 302 and take appropriate actions as relevant.

[000161] FIG.3D illustrates how an authorized person can authorize other persons to create a plurality of authorized enterprise contact directories in accordance with an exemplary embodiment of the present disclosure.

[000162] As illustrated, the proposed system can initially authorize a person as elaborated above, thereby creating a first authorized person shown as 362. The first authorized person 362 can create an authorized enterprise contact directory (AECD 364).

[000163] In an aspect, proposed system can be configured to get a person authorized from an existing authorized person whereby, in an exemplary embodiment, the system can provide a form on a website operatively connected to the system to get from a person relevant authentication details that the system can send to the first authorized person 362. In case the first authorized person 362 authenticates/confirms the authentication details of the person, the person can be granted the status of an authorized person, as indicated at second authorized person 366. Likewise, second authorized person 366 can create a third authorized person 370 that can create AECD 372. [000164] In this manner, a plurality of authenticated enterprise contact directories (AECDs) can be made accessible to the proposed system, and further used to verify various callers as elaborated herein. The authorized persons can be in principle-agent relationship with each other wherein the principle is responsible for actions of the agents and so, implicitly responsible for the AECDs (authorized enterprise contact directories) created by the various agents.

[000165] FIG. 4 illustrates a method of working of system proposed, in accordance with an exemplary embodiment of the present disclosure.

[000166] In an aspect, a method for enterprise domain based caller verification can include, at step 402, verifying, at a computing device, a caller by virtue of the caller being present in an authenticated enterprise contact directory, the authenticated enterprise contact directory being made accessible to the computing device by an authorized person pertaining to an enterprise, the authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of the plurality of contacts being associated with respective contact information. The method can further include, at step 404, intimating, from the computing device, caller verification status to a recipient based on the verification associated with the caller when the recipient receives a call from the caller, the caller verification status indicating if the caller forms part of the authenticated enterprise contact directory.

[000167] In another aspect of the method, the authorized person can be authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain. Further, the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

[000168] In yet another aspect of the method, the computing device can check if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory. Further, the authenticated enterprise contact directory can be updated by the enterprise or the authorized person, and can be sent to the computing device upon such updation.

[000169] In an aspect of the method, an administrator of the domain can discover all authenticated contact directories and contacts that pertain to the domain, and can be enabled to administrate such discovered authenticated contact directors and contacts, the administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

[000170] In another aspect, the method can further include the step of checking, in realtime, based on a call log received from the caller, if the caller initiated the call to the recipient such that if the check is affirmative, a call confirmation status is sent to the recipient. The call log can be sent from caller device of the caller sooner the caller initiates the call to the recipient, the call log comprising the phone number of the recipient and timestamp associated with the initiated call. On the other hand, if the check is negative, the recipient can be informed that the caller has not initiated the call.

[000171] In another aspect, the authenticated enterprise contact directory can include only the authorized person as the contact. The authenticated enterprise contact directory can also be a shared contact directory (CD), wherein each shared CD can be crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.

[000172] In existing mobile/smart phones/devices, each device can be configured to store one or more contact directories such as one directory of office colleagues, another of family members, and yet another of social friends, each of which may have contact information of one or more common people/members as well. Such contact directories may also be crowd-sourced, i.e., apart from being stored/developed on the local mobile device, contact directories shared by different users can also be stored on say a common global contact directory database(s) to enable users of the system to retrieve such shared contact directories of which they form part. For instance, user A can have 3 contact directories (family, office, social), each of which can be shared by the user A such that they are accessible/stored at the common global contact directory database such that if one of the 3 contact directories has a user B as a member, user B can automatically/manually retrieve the respective contact directory from the common global contact directory database so as to be able to view the contact directory(ies) that he/she forms a part of. Likewise, user A can also view all contact directories of user B that store users' A contact information.

[000173] In an aspect, the crowd sourced shared contact directory can be stored at a centralized server that can be accessible to all contacts that form part of the at least one crowd sourced shared contact directory. In exemplary implementations of shared CDs, a user (David Musk) can have one or more contact directories (CDs), one or more of which may be private CDs while other may be shared CDs, wherein the private CDs can be accessible/viewable only to the owner of the CD and therefore stored only on the mobile phone/smart phone of the respective owner/creator. Similarly, user (Adam Jones) can also have one or more CDs. Shared CDs (also referred to as shared phone books) can be configured such that they are stored on a common/centralized server/cloud so that all contacts that form part of the respective CD can view the corresponding shared CD, and can also add new contacts, which can be then be seen/viewed by other contacts of the CD in which the new contact is added.

[000174] As shown, user has three private CDs, and one shared CD, which shared CD is also stored on cloud along with other shared CDs. As the shared CD also has user (Adam Jones) as a contact, user (Adam Jones) also has access to the shared CD, which shows the contact information of user (David Musk). It would be appreciated that users can either view copies of the shared CDs on their mobile devices by accessing the copies stored on cloud or can, along with having copies on the cloud/server, also store local copies of the shared CD, wherein any change (such as addition of new contacts, or change in contact information of one or more contacts) performed to a shared CD can be synchronized across all copies/instance of the shared CD. Therefore, any manner/mode/mechanism using which shared CDs are stored, created, modified, updated, and synchronized is completely within the scope of the present disclosure.

[000175] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

ADVANTAGES OF THE INVENTION

[000176] Present disclosure provides for a system that enables enterprise level verification of a caller based on domain name to which the caller pertains.

[000177] Present disclosure provides for a system that provides to a recipient in real-time the enterprise level verification of a caller. [000178] Present disclosure provides for a system that provides to a recipient in real-time authentic profile of a caller.

[000179] Present disclosure provides for a system that automatically updates itself to provide latest enterprise level verification of a caller.

[000180] Present disclosure provides for a system that is available all the time to its users.

Claims

We Claim:

1. A system for enterprise domain based caller verification, said system comprising:

a non-transitory storage device having embodied therein one or more routines operable to facilitate the enterprise domain based caller verification; and

one or more processors coupled to the non-transitory storage device and operable to execute the one or more routines, wherein the one or more routines include:

a caller verification module, which when executed by the one or more processors, verifies a caller by virtue of the caller being present in an authenticated enterprise contact directory, said authenticated enterprise contact directory being made accessible to the caller verification module by an authorized person pertaining to an enterprise, said authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of said plurality of contacts being associated with respective contact information; and

a caller information intimation module, which when executed by the one or more processors, intimates caller verification status to a recipient based on the verification associated with the caller when said recipient receives a call from the caller, said caller verification status indicating if said caller forms part of the authenticated enterprise contact directory .

2. The system of claim 1 , wherein the contact information comprises any or a combination of first name, last name, email address, phone number, URL, physical address, fax number, and social media handle.

3. The system of claim 1, wherein the authorized person is authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain.

4. The system of claim 1, wherein the caller verification status is intimated to the recipient using any or a combination of an insignia, symbol, a badge, or a colored graphical representation.

5. The system of claim 1, wherein the authorized person authorizes at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

6. The system of claim 1, wherein the caller information intimation module intimates the caller verification status upon receiving a request from the recipient.

7. The system of claim 1, wherein the system checks if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory.

8. The system of claim 1, wherein the system receives one or more authenticated enterprise contact directories from respective enterprises, and during verification of the caller, searches for a match between phone number of the caller and phone numbers associated with contacts that form part of the received authenticated enterprise contact directories.

9. The system of claim 1, wherein if the caller is associated with multiple domains or authenticated enterprise contact directories, said caller is enabled to pre-select which domain/directory to be used while giving the caller verification status to the recipient.

10. The system of claim 1, wherein the authenticated enterprise contact directory is updated by the enterprise or the authorized person, and sent to the system upon such updation.

11. The system of claim 1, wherein the caller verification status is accompanied with any or a combination of a contact information attribute of the caller, designation of the caller, address of the caller, web or social links pertaining to the caller, and company name of the caller.

12. The system of claim 1, wherein an administrator of the domain discovers all authenticated contact directories and contacts that pertain to the domain, and is enabled to administrate such discovered authenticated contact directors and contacts, said administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

13. The system of claim 1, further comprising a call initiation confirmation module, which when executed by the one or more processors, checks, in real-time, based on a call log received from the caller, if said caller initiated the call to the recipient such that if said check is affirmative, a call confirmation status is sent to the recipient.

14. The system of claim 13, wherein the call log is sent from caller device of the caller sooner the caller initiates the call to the recipient, said call log comprising the phone number of the recipient and timestamp associated with the initiated call.

15. The system of claim 13, wherein an administrator of the domain discovers all call logs associated with callers of the domain.

16. The system of claim 13, wherein if the check is negative, the recipient is informed that the caller has not initiated the call.

17. The system of claim 1, wherein the authenticated enterprise contact directory comprises only the authorized person as the contact.

18. The system of claim 1, wherein the authenticated enterprise contact directory is a shared contact directory (CD), and wherein each shared CD is crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.

19. A method for enterprise domain based caller verification, said method comprising:

verifying, at a computing device, a caller by virtue of the caller being present in an authenticated enterprise contact directory, said authenticated enterprise contact directory being made accessible to the computing deviceby an authorized person pertaining to an enterprise, said authenticated enterprise contact directory comprising a plurality of contacts that form part of the enterprise, each contact of said plurality of contacts being associated with respective contact information; and

intimating, from the computing device, caller verification status to a recipient based on the verification associated with the caller when said recipient receives a call from the caller, said caller verification status indicating if said caller forms part of the authenticated enterprise contact directory.

20. The method of claim 19, wherein the authorized person is authorized by sending an authentication email to the domain based email address of the authorized person or administrator of the domain.

21. The method of claim 19, wherein the authorized person authorizes at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.

22. The method of claim 19, wherein the computing device checks if the caller is a contact that forms part of the authenticated enterprise contact directory by searching for a match between the phone number of the caller and the phone number associated with the plurality of contacts that form part of authenticated enterprise contact directory.

23. The method of claim 19, wherein the authenticated enterprise contact directory is updated by the enterprise or the authorized person, and sent to the computing device upon such updation.

24. The method of claim 19, wherein an administrator of the domain discovers all authenticated contact directories and contacts that pertain to the domain, and is enabled to administrate such discovered authenticated contact directors and contacts, said administration comprising any or a combination of addition, removal, and updation of contact information and verification status of the authenticated contact directories, members of the authenticated contact directories, and the contacts.

25. The method of claim 19, further comprising the step of checking, in real-time, based on a call log received from the caller, if said caller initiated the call to the recipient such that if said check is affirmative, a call confirmation status is sent to the recipient.

26. The method of claim 25, wherein the call log is sent from caller device of the caller sooner the caller initiates the call to the recipient, said call log comprising the phone number of the recipient and timestamp associated with the initiated call.

27. The method of claim 25, wherein if the check is negative, the recipient is informed that the caller has not initiated the call.

28. The method of claim 19, wherein the authenticated enterprise contact directory comprises only the authorized person as the contact.

29. The method of claim 19, wherein the authenticated enterprise contact directory is a shared contact directory (CD), and wherein each shared CD is crowd sourced so as to discover new contacts automatically based on actions of multiple contacts that are already a part of the shared CD.