Abstract:
In the context of tracking systems, it is difficult to ensure that an organization has a complete, accurate database of contacts stored in its tracking system. When tracking systems users are required to manage exporting and importing of contacts from their desktop mail clients and handheld devices, it is almost certain that contact information will not be kept up-to-date and that confidence in the accuracy of the contact information will not be high. By enabling a remote directory access portal in the tracking system, all users can be assured that they have available the latest contact information for the organizations&#39; contacts. In addition to providing directory access, the tracking system can authenticate users and, based on the users&#39; entitlements, authorize users&#39; access to specific contacts.

Description:
RELATED APPLICATION 
       [0001]    This application is a continuation of U.S. application Ser. No. 12/894,767, filed on Sep. 30, 2010. The entire teachings of the above application are incorporated herein by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    Customer Relationship Management (CRM) refers to processes implemented by a company to handle its interactions with its contacts (e.g., customers). Generally, information can be accessed and entered into a CRM system by employees of the company. An Applicant Tracking System (ATS) is a software application that enables the electronic handling of corporate recruitment needs. If hosted and accessed over the Internet, these systems may be known as Software-as-a-Service (SaaS). As used herein, the terms “CRM,” “ATS,” “tracking application,” and “tracking system” refer to any of these types of systems. 
         [0003]    The business value of a tracking system is to enable a firm to improve its client interactions. This is done by collecting customer data and analyzing and measuring the data to understand customer needs and improve satisfaction, which leads to increased sales/placement opportunities. To effectively use the tracking system, all contact details, such as, for example, a contact&#39;s name, email, phone number, address, and other metadata about the contact is stored in the tracking system. When a user needs to call or send a message to a particular contact, the user typically looks up the contact&#39;s information in the tracking system. By using the tracking system as the organization&#39;s system of record, anyone needing to communicate with a contact can be assured that the information is the most up-to-date and accurate information. When the data changes (and is updated in the tracking system), such as, for example, a user&#39;s email address, phone number, or address, the next time any user with entitlement (e.g., permission) views the contact, that user will have the most accurate information. This ensures timely interactions with the organization&#39;s contacts to maximize business opportunities. 
       SUMMARY OF THE INVENTION 
       [0004]    One problem with tracking systems today is that existing systems or methods require the user to log into the tracking system from a remote location using an application on the user&#39;s device to lookup contact details. The application used to log into the tracking application is separate from the user&#39; client email application (e.g., Microsoft Outlook); thus, when the user looks up the contact information, the user must still either (1) copy-and-paste the email address from the tracking system into the remote client email application or (2) re-type the contact&#39;s email address from the information displayed by the tracking system application into the remote client email application. Many users find these extra steps to be a hassle. Because the steps needed to lookup a contact via tracking application login are viewed as being too time consuming, a user may elect to store all of his contact information locally. Many users perceive local storage of contact information as being better because searching and finding detailed contact information then becomes easier. This alternative to looking up the contact information via tracking application login involves exporting a list of contacts and associated details from the tracking system, and importing the information into the user&#39;s personal address book of his remote client email application. With this local storage method, the user is then responsible for ensuring that the contact information remains up-to-date when any changes are made to the contact information in the tracking system. When a user is required to manage the information between two applications in such a configuration, there is a high probability that the contact information will not be maintained consistently across the entire organization. 
         [0005]    Various existing tracking systems have the ability to somewhat reduce the steps of the manual cut-and-paste method. Some systems require end users to install synchronization software and to manually tag contacts to download or store to their desktop mail client. With these systems, however, while the contact information is available locally on a user&#39;s desktop mail client, the contact information is not available to the user via a web-based mail client, and is also not available on the user&#39;s wireless handheld device. 
         [0006]    Example methods and systems are disclosed herein to solve these problems. One example is a system for providing a remote client application with access to a tracking system directory. The system includes a data service that interfaces with the tracking system, and a Lightweight Directory Access Protocol (LDAP) server that interfaces with the remote client application. The system also includes a partition disposed between the data service and the LDAP server that processes a request from the remote client application. The partition formulates a command that is accepted by the data service based on the request. The partition then receives results from the data service in response to the command and translates the results into a format that is accepted by the remote client application. 
         [0007]    In some embodiments, the request from the remote client application is a search query for contact information stored in the tracking system directory, and the results from the data service include contact information that matches the search query. The data service may generate the results by searching unstructured data in the tracking system directory. The data service can also validate credentials of a user of the remote client application before executing the command, and the results returned by the data service may be based on those credentials. For example, the data service can deny access to the tracking system directory based on the credentials, or filter the results passed back to the partition. In addition, the partition can construct a virtual directory structure from the results received from the data service, and may forward the results to the remote client application via the LDAP server. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
           [0009]      FIG. 1  is a block diagram illustrating the components of an example system for providing a remote client application with access to a tracking system directory, and illustrating submitting a search query to the tracking system. 
           [0010]      FIG. 2  is a block diagram illustrating the components of an example system for providing a remote client application with access to a tracking system directory, and illustrating receiving results of a search query. 
           [0011]      FIG. 3  is a flow chart illustrating an example embodiment&#39;s process for providing a remote client application with access to a tracking system directory. 
           [0012]      FIG. 4  is a detailed flow chart illustrating an example embodiment&#39;s process for searching for contact information stored in an tracking system and receiving records as a result of the search. 
           [0013]      FIG. 5  is a detailed flow chart illustrating an example embodiment&#39;s process for requesting details for a particular contact stored in the tracking system and receiving detailed information as a result of the request. 
           [0014]      FIG. 6  is a schematic view of a computer network in which the example embodiments disclosed herein may operate. 
           [0015]      FIG. 7  is a block diagram of a computer node/device in the network of  FIG. 6 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0016]    A description of example embodiments of the invention follows. 
         [0017]    The embodiments disclosed herein allow tracking system users to connect a remote mail application on a desktop or wireless handheld device to lookup and retrieve contact information directly from the tracking system. In many embodiments, when connected, a user can enter the name of a contact (or partial name), for example, and the email application sends a lookup query using the Lightweight Directory Access Protocol (LDAP) to the tracking system via a LDAP server. The contact name entered by the user may include “wildcard” symbols. Before the query is executed, the system may check the user&#39;s credentials for access to the tracking system, also known as “entitlements.” Entitlement enforcement by the tracking system can allow or prevent the user from accessing certain contact information. Once the user is authenticated and entitlements are checked, the query is executed and the contact, or contacts if the query matches multiple contacts, is returned to the user&#39;s email application. The embodiments disclosed herein enable such remote access by installing a partition between a data service that interfaces with the tracking system and a LDAP server that interfaces with the remote client application, since the data service and LDAP server are likely not compatible. 
         [0018]      FIG. 1  is a block diagram illustrating the components of an example system  100  for providing a remote client application  105  with access to a tracking system directory, and illustrating submitting a search query to the tracking system  200 . The example system  100  includes a data service  120  that interfaces with the tracking system  200 , and a LDAP server  110  that interfaces with the remote client application  105 . The system  100  also includes a partition  115  disposed between the data service  120  and the LDAP server  110  that processes a request  125  from the remote client application  105 . As shown, the request  125  may, for example, be or include a search query for contact information stored in the tracking system directory. Based on the request  125 , the partition  115  formulates a command  130  that can be accepted by the data service  120 . 
         [0019]      FIG. 2  is a block diagram illustrating the components of the example system  100  of  FIG. 1  and illustrating receiving results of a search query. The data service  120  may, upon receiving the command  130  ( FIG. 1 ), generate results  135  by searching unstructured data in the tracking system directory, and the results  135  may include contact information that matches the search query. The partition  115  then receives results  135  from the data service  120  in response to the command  130  ( FIGS. 1 ) and translates the results  135  into a format that can be accepted by the remote client application  105 . In doing so, the partition  115  may construct a virtual directory structure from the results  135 , and may forward the translated results  140  to the remote client application  105  via the LDAP server  110 . In some embodiments, before retuning results  135  to the partition  115 , the data service  120  can validate the credentials of a user of the remote client application  105  before executing the command, and the results  130  returned by the data service  120  may be based on those credentials. For example, the data service  120  can deny access to the tracking system directory based on the credentials, or filter the results  135  passed back to the partition  115 . 
         [0020]      FIG. 3  is a flow chart illustrating an example embodiment&#39;s process  300  for providing a remote client application with access to a tracking system directory. Upon receiving ( 305 ) a request  125  from the remote client application  105  via a LDAP server  110 , a command  130  is formulated ( 310 ) based on the request  125 . The request  125  may include, for example, a search query for contact information stored in the tracking system directory. The command  130  is of a format that can be accepted by a data service  120  that interfaces with the tracking system  200 . The command  130  is then submitted ( 315 ) to the data service  120 . If the request  125  included a search query, results  135  for the search may be generated by searching unstructured data in the tracking system directory, and may include contact information that matches the search query. In some embodiments, the credentials of a user of the remote client application  105  may be validated before executing the command  130 , which can affect the generation of the results  135 . For example, a user may be denied access to the tracking system directory, or the results  135  may be filtered based on the user&#39;s credentials. Upon receiving ( 320 ) results  135  from the data service  120  in response to the command  130 , the results are translated ( 325 ) into a format accepted by the remote client application  105 , which may include, for example, constructing a virtual directory structure from the results  135 . The results  135  may then be forwarded to the remote client application  105  via the LDAP server  110 . 
         [0021]      FIG. 4  is a detailed flow chart illustrating an example embodiment&#39;s process  400  for searching for contact information stored in an tracking system  200  and receiving records as a result of the search. According to the example process  400 , a remote email client  405  submits ( 420 ) a search for a contact&#39;s name to an LDAP server  410  (e.g., a user of the email client  405  enters a search term and clicks search). In the example embodiment of  FIG. 4 , the partition  115  described above is incorporated into the LDAP server  410 . The partition of the server  410  receives the search request, formulates ( 425 ) a search command, and submits the command to a data service  415 . 
         [0022]    When the data service  415  receives the command, it can validate ( 430 ) the credentials (e.g., username and password) of the email client user. If the credentials are invalid, the data service  415  generates ( 440 ) an authentication error and passes ( 445 ,  450 ) it back to the email client  405  via the LDAP server  410 . Otherwise, the data service  415  performs ( 435 ) a search of the data stored in the tracking system  200 , which can take into consideration the user&#39;s credentials (also called “entitlements”). If the search takes into consideration the user&#39;s entitlements, the user will only see records that they are entitled to access. After the search is performed, the data service  415  returns ( 455 ) records (e.g., contact information) that match the search command. 
         [0023]    If no records are returned as a result of the search ( 460 ), the LDAP server  410  returns ( 465 ) a “records not found” message to email client  405 . If, however, records are returned, the partition of the LDAP server  410  begins ( 470 ) the process of obtaining the details of the records. The partition first checks ( 475 ) a cache to determine whether the details of the particular records are in the cache. If all records are found ( 480 ) in the cache, the partition formats and returns ( 485 ) the record details to the email client  405 , where the records are presented ( 490 ) to the user. If fewer than all of the records are found in the cache, the partition requests ( 481 ) from the data service  415  the details for the missing records. The data service  415  then obtains ( 482 ) the requested information and returns ( 483 ) the detailed information to the LDAP server  410 . When received by the server  410 , the partition handles ( 484 ) the returned information by adding ( 486 ,  487 ) the information to the appropriate caches, and formatting and returning ( 485 ) the record details to the email client  405 . Upon receipt of the records, the email client  405  presents ( 490 ) the returned records to the user. 
         [0024]      FIG. 5  is a detailed flow chart illustrating an example embodiment&#39;s process  500  for requesting details for a particular contact stored in the tracking system  200  and receiving detailed information as a result of the request. According to the example process  500 , the email client  405  requests ( 505 ) details for a given record (e.g., the user of the email client  405  clicks on a record to obtain its associated details). The request is sent ( 507 ) to the LDAP server  410 , where the partition first checks ( 510 ) whether the requested information exists in a cache. If found ( 512 ) in the cache, the information is formatted and retuned ( 515 ) to the email client  405 . However, if not found, the partition generates and sends ( 520 ) a command to the data service  415  to obtain the requested information. 
         [0025]    As described above, the data service  415  can validate ( 522 ) the credentials of the email client user, and if the credentials are invalid, the data service  415  generates ( 525 ) an authentication error and passes ( 527 ,  530 ) it back to the email client  405  via the LDAP server  410 . Otherwise, the data service  415  performs ( 532 ) a search of the data stored in the tracking system  200 . If the search takes into consideration the user&#39;s entitlements, the user will only see a record if he is entitled to access the record. After the search is performed, the data service  415  returns ( 535 ) the record (e.g., contact information) that matches the search command. 
         [0026]    The partition of the LDAP server  410  then begins ( 537 ) the process of obtaining the details of the record. The partition first checks ( 540 ) a cache to determine whether the details of the retuned record are in the cache. If the record is found ( 542 ) in the cache, the partition formats and returns ( 545 ) the record&#39;s details to the email client  405 , where the details are presented ( 547 ) to the user. If the record is not found in the cache, the partition requests ( 550 ) from the data service  415  the details for the record. The data service  415  then obtains ( 552 ) the requested information and returns ( 555 ) the detailed information to the LDAP server  410 . When received by the server  410 , the partition handles ( 557 ) the returned information by adding ( 560 ,  565 ) the information to the appropriate caches, and formatting and returning ( 545 ) the record details to the email client  405 . 
         [0027]      FIG. 6  is a schematic view of a computer network in which embodiments of the present invention may operate. Client devices  610  and server devices  620  provide processing, storage, and input/output devices executing application programs and the like. Client devices  610  can also be linked through a communications network  630  to other computing devices, including other client devices  610  and server devices  620 . The communications network  630  may be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computing devices, local area or wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are also suitable. 
         [0028]      FIG. 7  is a block diagram of a computer node/device  610 ,  620  in the network of  FIG. 6 . Each device  610 ,  620  contains a system bus  730 , where a bus is a set of hardware lines used for data transfer among the components of a device or processing system. The bus  730  is essentially a shared conduit that connects different elements of a device (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to the system bus  730  is an I/O device interface  740  for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the device  710 ,  720 . A network interface  760  allows the device to connect to various other devices attached to a network (e.g., network  630  of  FIG. 6 ). Memory  770  provides volatile storage for computer software instructions  780  and data  790  used to implement an embodiment of the present invention (e.g., data service  120 , LDAP server  110 , and partition  115  of  FIGS. 1 and 2 , and supporting code for performing the functions and processes  300 ,  400 , and  500  detailed above in  FIGS. 3-5 ). Disk storage  775  provides non-volatile storage for computer software instructions  780  and data  790  used to implement the methods and systems disclosed herein. Central processor unit  750  is also attached to the system bus  730  and provides for the execution of computer instructions. 
         [0029]    In one embodiment, the processor routines  780  and data  790  are a computer program product (generally referenced  780 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, or a portal server medium, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product  780  can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. 
         [0030]    While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.