[go: up one dir, main page]

WO2018100477A1 - Vérification d'appelant en fonction d'un domaine d'entreprise - Google Patents

Vérification d'appelant en fonction d'un domaine d'entreprise Download PDF

Info

Publication number
WO2018100477A1
WO2018100477A1 PCT/IB2017/057404 IB2017057404W WO2018100477A1 WO 2018100477 A1 WO2018100477 A1 WO 2018100477A1 IB 2017057404 W IB2017057404 W IB 2017057404W WO 2018100477 A1 WO2018100477 A1 WO 2018100477A1
Authority
WO
WIPO (PCT)
Prior art keywords
caller
contact
enterprise
authenticated
recipient
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2017/057404
Other languages
English (en)
Inventor
Vishal Gupta
Sumeet Singh
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of WO2018100477A1 publication Critical patent/WO2018100477A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management

Definitions

  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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 authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.
  • the caller information intimation module can intimate the caller verification status upon receiving a request from the recipient.
  • the caller verification module and/or the information intimation 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.
  • 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.
  • the caller can be enabled to pre-select which domain/directory to be used while giving the caller verification status to the recipient.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an administrator of the domain can discover all call logs associated with callers of the domain.
  • the recipient can be informed that the caller has not initiated the call.
  • the authenticated enterprise contact directory can include only the authorized person as the contact.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • the check is negative, the recipient can be informed that the caller has not initiated the call.
  • 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.
  • CD shared contact directory
  • 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.
  • FIG. 2 illustrates exemplary functional modules that enable domain based caller verification in accordance with an embodiment of the present disclosure.
  • FIGs. 3A to 3C elaborate upon functioning of the proposed system, in accordance with an exemplary embodiment of the present disclosure.
  • 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.
  • FIG. 4 illustrates a method of working of system proposed, in accordance with an exemplary embodiment of the present disclosure.
  • 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.
  • steps may be performed by a combination of hardware, software, and firmware and/or by human operators.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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 authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.
  • the caller information intimation module can intimate the caller verification status upon receiving a request from the recipient.
  • 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.
  • 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.
  • the caller can be enabled to pre-select which domain/directory to be used while giving the caller verification status to the recipient.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an administrator of the domain can discover all call logs associated with callers of the domain.
  • the recipient can be informed that the caller has not initiated the call.
  • the authenticated enterprise contact directory can include only the authorized person as the contact.
  • 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.
  • CD shared contact directory
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • the check is negative, the recipient can be informed that the caller has not initiated the call.
  • 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.
  • CD shared contact directory
  • 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.
  • 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.
  • enterprise level email address such as David@xyz-corp.com, where xyz-corp.com is the domain name of 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.
  • 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.
  • party/recipient third-party
  • disassociation too can take place in a similar manner when a contact is, for instance, removed/deleted from the contact directory.
  • addition of a new contact in the ECD can trigger the action of automatically verifying the new contact and user associated with the contact.
  • 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.
  • the system 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.
  • OTP one-time password
  • 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.
  • 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.
  • 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.
  • client module that is configured on the recipient can therefore confirm that the phone number is correctly mapped to the domain name.
  • Client module/side that is configured on the caller 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.
  • proposed system can enable a caller, using caller mobile device (CMD) to provide his/her enterprise level email address (ELEA) to the system.
  • CMS caller mobile device
  • ELEA enterprise level email address
  • 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.
  • 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.
  • 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 ).
  • 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.
  • proposed system can automatically detect the mobile number associated with the CMD.
  • 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.
  • 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.
  • OTP one-time password
  • 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.
  • such verification of the phone number/mobile number of the caller by sending an OTP can be performed anytime after registration as well.
  • 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.
  • phone number and ELEA as provided by the caller can constitute the 'verification input' upon which basis verification can proceed as elaborated hereunder.
  • proposed system upon receipt of the verification input containing ELEA therein, 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.
  • the email sent can carry an authentication link that when clicked can verify the ELEA.
  • 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.
  • 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.
  • the ELEA can be considered genuine only when appropriate verifying actions are taken by the caller.
  • 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.
  • proposed system can enable the recipient to generate, using the RMD a verification request that can carry phone number of the CMD.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ECMS enterprise contact management system
  • 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
  • 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.
  • proposed system can periodically or randomly send verification mail as elaborated above.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • AECD authenticated enterprise contact directory
  • 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.
  • 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.
  • 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.
  • 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.
  • AECD enterprise contact directory
  • Proposed system can automatically authenticate a person to thereafter designate him/her as the authorized person, 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.
  • 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.
  • the domain based email address can be xyz@abc.com.
  • mail servers of a domain are configured accordingly, as is well known in the art.
  • 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.
  • proposed system 102 can enable computing device 104 to generate an authentication request that system 102 can receive.
  • system 102 can send an authentication email to the domain based email address 108.
  • the authentication email can carry various means of authentication.
  • the authentication email can carry a verification link.
  • person 108 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.
  • Various other authentication means can be deployed to enable system 102 give status of an authorized person to someone after proper authentication.
  • 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.
  • an enterprise as used in the proposed system can be any group of people that with their email addresses mapped to a common domain.
  • 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.
  • 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.
  • 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.
  • 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.
  • an authorized person/domain administrator (AP) 130of an enterprise 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).
  • one such person can be the caller 116 as illustrated.
  • 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.
  • CMD caller mobile device
  • RMD recipient mobile device
  • 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.
  • 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 122 can carry mobile number of the CMD 118. This mobile number can be, for instance, one displayed on display of RMD 114.
  • 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.
  • 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.
  • recipient 112 can handle the call appropriately or take a decision on whether or not to continue the call.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the call initiation confirmation message/status 126 can inform recipient 112 that the CMD 118's mobile number is genuine.
  • 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.
  • FIG. 2 illustrates exemplary functional modules that enable domain based caller verification in accordance with an embodiment of the present disclosure.
  • 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.
  • proposed system can have a caller verification module 202, a caller information intimation module 204, and a call initiation confirmation module 206.
  • 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.
  • AECD authenticated enterprise contact directory
  • 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.
  • 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.
  • 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.
  • email address 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.
  • phone number can be made an essential information to enable determination
  • 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.
  • an authorized person 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.
  • the email can carry a verification link that can be time bound.
  • 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.
  • 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.
  • biometric recognition such as fingerprint or facial recognition
  • 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).
  • the authorized person can authorize at least one contact to create or manage a second authenticated enterprise contact directory associated with the domain.
  • a plurality of authenticated enterprise contact directories 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • module 204 upon receipt of a call and a caller verification request, 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.
  • 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.
  • caller verification status can convey to the recipient comprehensive information about the caller [000150]
  • features such as above can prevent fraudulent calls, and can alert a recipient as soon as the recipient receives a suspicious call.
  • 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.
  • module 206 can inform the recipient accordingly that he caller has not initiated the call.
  • 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.
  • the caller information status can inform the recipient that the calling device's mobile number is genuine.
  • 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.
  • module 206 can determine if a caller is attempting to 'spoof his/her mobile device number and warn recipients accordingly.
  • 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).
  • AECD authenticated enterprise contact directory
  • 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.
  • FIGs. 3A to 3C elaborate upon functioning of the proposed system, in accordance with an exemplary embodiment of the present disclosure.
  • a caller 302 can, using caller mobile device (CMD) 304 call a recipient 306 on recipient mobile device (RMD) 308, as shown at 310.
  • CMS caller mobile device
  • RMD recipient mobile device
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the person can be granted the status of an authorized person, as indicated at second authorized person 366.
  • second authorized person 366 can create a third authorized person 370 that can create AECD 372.
  • AECDs authenticated enterprise contact directories
  • 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.
  • FIG. 4 illustrates a method of working of system proposed, in accordance with an exemplary embodiment of the present disclosure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the check is negative, the recipient can be informed that the caller has not initiated the call.
  • 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.
  • CD shared contact directory
  • 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.
  • 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.
  • 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.
  • user A can also view all contact directories of user B that store users' A contact information.
  • 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.
  • a user 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.
  • user Adam Jones
  • Shared CDs 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.
  • user has three private CDs, and one shared CD, which shared CD is also stored on cloud along with other shared CDs.
  • 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).
  • 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.
  • Present disclosure provides for a system that enables enterprise level verification of a caller based on domain name to which the caller pertains.
  • Present disclosure provides for a system that provides to a recipient in real-time the enterprise level verification of a caller.
  • Present disclosure provides for a system that provides to a recipient in real-time authentic profile of a caller.
  • Present disclosure provides for a system that automatically updates itself to provide latest enterprise level verification of a caller.
  • Present disclosure provides for a system that is available all the time to its users.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Selon certains aspects, la présente invention concerne des systèmes et des procédés qui permettent de procéder à une vérification au niveau d'une entreprise d'un appelant sur la base d'un nom de domaine auquel l'appelant appartient, de façon à permettre à la partie appelée de voir que l'appelant est un appelant vérifié et qu'il appartient à l'entreprise qui correspond au nom de domaine. Le système permet à un destinataire de recevoir automatiquement en temps réel des coordonnées authentiques d'un appelant qui appelle sur le dispositif mobile du récepteur, les coordonnées indiquant l'entreprise à laquelle l'appelant appartient, son intitulé au sein de cette dernière, son pseudonyme de réseaux sociaux et similaires. Le système aide à empêcher des appels frauduleux, et se met à jour automatiquement.
PCT/IB2017/057404 2016-11-29 2017-11-27 Vérification d'appelant en fonction d'un domaine d'entreprise Ceased WO2018100477A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN201611040796 2016-11-29
IN201611040796 2016-11-29

Publications (1)

Publication Number Publication Date
WO2018100477A1 true WO2018100477A1 (fr) 2018-06-07

Family

ID=62241348

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/057404 Ceased WO2018100477A1 (fr) 2016-11-29 2017-11-27 Vérification d'appelant en fonction d'un domaine d'entreprise

Country Status (1)

Country Link
WO (1) WO2018100477A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150281451A1 (en) * 2014-03-31 2015-10-01 Avaya Inc. System and method to detect and correct ip phone mismatch in a contact center
US20160261616A1 (en) * 2015-03-06 2016-09-08 Imperva, Inc. Data access verification for enterprise resources

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150281451A1 (en) * 2014-03-31 2015-10-01 Avaya Inc. System and method to detect and correct ip phone mismatch in a contact center
US20160261616A1 (en) * 2015-03-06 2016-09-08 Imperva, Inc. Data access verification for enterprise resources

Similar Documents

Publication Publication Date Title
KR101268702B1 (ko) 음성메일 메시징 인증 수행방법
EP3219091B1 (fr) Procédé pour établir une communication entre des terminaux mobiles
JP6514721B2 (ja) デュアルチャネル識別認証
US8943561B2 (en) Text message authentication system
US10027648B2 (en) Geolocation dependent variable authentication
CN109784031B (zh) 一种账户身份验证处理方法及装置
CN108337210B (zh) 设备配置方法及装置、系统
US10572683B2 (en) Individual data unit and methods and systems for enhancing the security of user data
US20120202462A1 (en) Method for remotely and automatically erasing information stored in sim-card of a mobile phone
WO2009022322A2 (fr) Vérification de l'authenticité d'une partie appelée dans des réseaux téléphoniques
US12008128B2 (en) Image and message management and archiving for events
JP2019040557A (ja) 認証システム、認証方法、認証装置およびプログラム
CN105681047B (zh) 一种ca证书签发方法及系统
US20240236076A1 (en) Authenticating Data And Communication Sources
CN106302332A (zh) 用户数据的访问控制方法、装置及系统
US20190364030A1 (en) Two-step authentication method, device and corresponding computer program
JP6368062B1 (ja) 認証装置，認証装置の制御方法およびそのプログラム
CN108989021A (zh) 信息认证方法、装置、计算机设备及可读存储介质
CN110943960A (zh) 一种庭审笔录电子签名生成方法、装置、设备及介质
CN109067749A (zh) 一种信息处理方法、设备及计算机可读存储介质
WO2018100477A1 (fr) Vérification d'appelant en fonction d'un domaine d'entreprise
US20240340311A1 (en) System and Method for Validating Source and Authenticity of Incoming Communications Received by a User Device
WO2018157211A1 (fr) Vérification sécurisée d'une communication vocale
CN113068189A (zh) 基于区块链的认证方法和服务器
HK1221567B (zh) 身份认证方法、装置及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17875897

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17875897

Country of ref document: EP

Kind code of ref document: A1