Electrical computers and digital processing systems: multicomput – Remote data accessing – Using interconnected networks
Reexamination Certificate
2003-04-08
2004-05-04
Alam, Shahid (Department: 2172)
Electrical computers and digital processing systems: multicomput
Remote data accessing
Using interconnected networks
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06732160
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates to the field of network directory services and, more particularly, to a system and method for interfacing a directory assistance system with a tree-based Lightweight Directory Access Protocol (LDAP) interface.
2. Description of the Related Art
A directory is a mechanism that clients can use to locate entries and attributes about those entries. Clients are often people (for example, someone “querying the directory”), but could also be programs (for instance, an application looking up an attribute about a user). Entries might include network resources such as printers or web pages or people (a “white pages” directory). In addition to the clients and entries, the type of query being used to access the information is also important. The query structure defines the semantics of retrieving information from the directory. Different combinations of client type, entry type, and query type result in different kinds of directory applications. In sum, directories can be thought of as databases with the important characteristic that the number of database read operations generally exceeds the number of write operations by at least an order of magnitude. In addition, directory servers can be defined as repositories of attribute/value pairs that clients can use to locate entries and attributes using structured queries.
Directory Assistance (DA) solutions incorporate directories and directory servers which can provide phone numbers stored in the directories to callers via an operator service center. Typically, a caller dials “information” (e.g. “411”) to get the phone number of a person or business. Subsequently, the DA system employs an indexed referencing mechanism to obtain the requested information. Present DA systems have a proprietary interface for accessing information contained therein.
Each DA system typically organizes data stored therein differently from other data stored in other DA systems. Yet, presently, there exists a business need for customers of DA systems, for instance telecommunications companies, to share or even sell access to the disparately organized information stored in each DA system. Notwithstanding, the problem of sharing or selling access to customer DA system data has not been solved in both a standard manner and in an open systems environment.
Currently communication mechanisms between different DA systems and different installations of the same DA system have been implemented in closed, controlled environments. For instance, a customized Internet program in combination with hypertext markup language (HTML) pages have been provided to users in order to grant Intranet access to a proprietary DA system positioned behind a firewall. However, no solution has been devised that provides for an open standard for facilitating data interchange between disparate DA systems, which does not require specially written applications or programmer support in order to implement.
Moreover, current DA systems utilize proprietary interfaces which cannot be easily externalized directly to outside applications. Specifically, providing external access to a DA system implicates security concerns as well as training issues with the interface itself. For example, exposing the proprietary interface of a DA system can require the creation of a security mechanism to control access to the system. Moreover, exposing the proprietary interface of a DA system can require the training of users in the use of the DA system. Notably, training can further implicate the creation of documentation and the assembly of a support team. The training can be required because the proprietary interface to the DA system is not always intuitive. In consequence, users of the system must understand the proprietary nature of the underlying information stored in the DA system in order to use it. Finally, providing external access to a DA system can create a migration problem for users migrating from a proprietary DA system. In particular, applications designed to interact with the proprietary interface to the DA system can be compromised when transitioning to a different DA system or a different interface to the DA system.
Unlike the proprietary interfaces of current DA systems, the lightweight directory access protocol (LDAP) is an open industry standard directory services protocol which can provide a consistent and controlled system for accessing data. LDAP represents a simple, albeit powerful directory service which is capable of performing powerful directory service queries as well as allowing clients to issue commands that add, delete or modify directory service entries. Although the underlying storage of the information between LDAP servers can be disparate, the LDAP protocol does not expose this disparity to users of an LDAP interface. In LDAP, the basic unit of information consists of an entry. Entries are stored in directories. Directory entries are arranged in a hierarchical tree-like structure that can reflect real-world boundaries, for example a location or organization. The hierarchical tree-like LDAP structure enables users of a directory service to navigate through information stored therein in a known manner. Furthermore, through standard interfaces, the schema or organization of the attributes in an LDAP directory are obtainable. Consequently, LDAP applications, for example LDAP enabled web browsers like Netscape Communicator or Microsoft Internet Explorer, can use an LDAP directory interface without requiring of its users special training or knowledge of the underlying information system.
LDAP, a simplification of the X.500 directory access protocol (DAP), is defined in the request for comment, RFC-1777, “Lightweight Directory Access Protocol”, available from the Internic HTTP server having the fully-qualified URL: ds.internic.net/rfc/rfcl777.txt and incorporated herein by reference. Specifically, LDAP defines a reasonably simple mechanism for Internet clients to query and manage an arbitrary database of hierarchical attribute/value pairs over a TCP/IP connection using port 389.
The LDAP directory service model is based on entries. An entry is a collection of filter attributes that has a name, referred to as a distinguished name (DN). The DN can be used to refer to the entry unambiguously. Each of the entry's attributes can have a type and one or more values. The types typically are mnemonic strings, for example “cn” for common name, or “mail” for e-mail address. The values can depend on the type of corresponding attribute. For example, a mail attribute may contain the value “johnd@xyz.com”. Similarly, a jpeg photo attribute may contain a photograph in binary JPEG format. An entry's DN can be constructed by taking the name of the entry itself, referred to as the relative distinguished name (RDN), and concatenating the names of the RDN's ancestor entries. For example, the entry for John Doe can have an RDN “cn=John Doe” and a DN of “cn=John Doe, o=xyz, c=US”.
In LDAP, directory entries are arranged in a hierarchical tree-like structure that reflects political, geographic, and/or organizational boundaries. Entries representing countries can appear at the top of the tree. Below the country entries are entries representing states or national organizations. Below the state or national organization entries can exist entries representing people, organizational units, printers, documents, or other categorizational sub-units. Notably, the hierarchy in LDAP is a hierarchy of entries within a database, not a hierarchy of server connections, or other network configuration information.
LDAP entries generally are typed by an objectclass attribute. For example, in order to restrict searches of a directory to entries exclusively including access control lists, the search phrase “objectclass=acl” can be specified so that only entries purporting to be access control lists are located. LDAP permits a user to control which attributes are required and allowed for a particular object class, thu
Ambrosini Martin A.
Huth Edward E.
Moore Victor S.
Nusbickel Wendi L.
Yoder Brian E.
Akerman & Senterfitt
Alam Shahid
LandOfFree
Lightweight directory access protocol interface directory... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Lightweight directory access protocol interface directory..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Lightweight directory access protocol interface directory... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3197918