EP1145526A2 - Service d'authentification de medecins a distance - Google Patents

Service d'authentification de medecins a distance

Info

Publication number
EP1145526A2
EP1145526A2 EP99954660A EP99954660A EP1145526A2 EP 1145526 A2 EP1145526 A2 EP 1145526A2 EP 99954660 A EP99954660 A EP 99954660A EP 99954660 A EP99954660 A EP 99954660A EP 1145526 A2 EP1145526 A2 EP 1145526A2
Authority
EP
European Patent Office
Prior art keywords
user
information
subscribing
verification
site
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.)
Withdrawn
Application number
EP99954660A
Other languages
German (de)
English (en)
Inventor
Douglas K. Mccormick
Robert J. Dubner
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.)
DUBNER Robert
Physician Verification Services Inc
Original Assignee
DUBNER Robert
Physician Verification Services Inc
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 DUBNER Robert, Physician Verification Services Inc filed Critical DUBNER Robert
Publication of EP1145526A2 publication Critical patent/EP1145526A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden

Definitions

  • the present application relates to authentication of computer users requesting controlled information in distributed environments, and more particularly to remote authentication of physicians requesting controlled information across the Internet.
  • Health care professionals are constrained in their ability to discuss and release patient confidential information. Such information is usually protected by doctor patient confidentiali- ty because of its extremely sensitive nature. In many jurisdictions a health care professional may be held liable to the patient if the health care professional allows such information to escape. Nevertheless, such sensitive information is often relevant to discussions of the cases faced by physicians. Even without the patient's name attached, the complete set of patient data may be such as to indicate the identity of the patient and thus permit the escape of sensitive information to a careful snooper. Thus the physician ' s legal environment is constrained both by the need to obtain new information which may relate to the existing cases, and by the severe legal dangers to the physician in openly transmitting such information.
  • direct mail can still result in a per physician cost of $10-$30 each.
  • direct mail is the least reliable of the current strategies. It cannot be determined who is actually reached with direct mail advertising. This uncertainty is particularly true if the provider has appointed a staff member to read and sort mail. Even if the mail does reach its intended target, the amount of time that the doctor actually spends with the information and the impact of the information on the doctor's decision making cannot be accurately determined.
  • the Internet is expected to play a significant part in helping to reduce these marketing costs.
  • the ten leading pharmaceuticals companies have had sites on the world Wide Web since 1996. In 1997, a study by Find/SVP found that approximately 35% of all American physicians had access to the Internet. This figure exceeded that of the general population which was then at 20%. Internet use among Americans continues to increase at a rate of about 80% per year. These figures suggest that connectivity will be the rule, especially among medical professionals, by the year 2000. Despite the exhibited trend, no pharmaceuti- cal or medical device manufacturer yet uses its World Wide Web site as an important marketing tool for reaching physicians.
  • POL Physician's Online
  • POL operates a market-sponsored Web site accessible by password.
  • POL uses an advertising business model, producing mini-sites within its own Web site for each subscribing company. The result is high maintenance fees coupled with an absence of hands-on control of their information.
  • the Internet which started in the late 1960's, is a vast computer network consisting of many smaller networks that span the entire globe.
  • the Internet has grown exponentially, and millions of users ranging from individuals to corporations now use permanent and dial-up connections to use the Internet on a daily basis worldwide.
  • the computers or networks of computers connected within the Internet known as "hosts", allow public access to databases featuring information in nearly every field of expertise and are supported by entities ranging from universities and government to many commercial organizations, including pharmaceutical companies.
  • the Internet maintains an open structure in which exchanges of information are made cost-free without restriction.
  • the free access format inherent to the Internet presents difficulties for those information providers requiring control over their Internet servers.
  • the server makes responses without ever knowing exactly who the client is or what its IP address is. While the server may be programmed to trace its clients, the task of tracing is often difficult, if not impossible.
  • system administrators implement various data flow control mechanisms, such as Internet "firewalls", within their networks.
  • An Internet firewall is a software structure which allows a user to reach the Internet while preventing intruders of the outside world from accessing the user's LAN.
  • An intranet is a smaller version of the internet that is limited to connections within an organization. Access is limited to the members of the organization, usually by means of a firewall. A firewall acts as a gateway that stems the flow of data into and out of the intranet.
  • An extranet is an intranet that extends access to specific users beyond the firewall.
  • a company's intranet may be accessible from remote locations that are not physically on the company premises.
  • a company's catalog and product information, but no other company data, may be accessible to customers.
  • Access to extranets often requires passing a gatekeeper of some sort that only allows access to users with specific information
  • users can interact on both intranets and extranets by means of the same user-friendly browsers that allow internet access.
  • Two-way authentication schemes generally involve hand-shaking techniques so that each party may verify he or she is in communication with the desired party regardless of each party's location or the types of devices in use.
  • the problem to be solved is one in which a user communicates with a service that wishes to learn and authenticate the user's identity and vice versa.
  • network security there are three aspects of network security that may be distinguished.
  • Identification the way in which a user or service is referenced.
  • Authentication the way in which a user may prove his or her identity.
  • Authorization a method for determining what a given user may do. The latter two aspects apply to service providers as well as to users.
  • a user's identity usually consists of a user name and a realm name.
  • a realm is a universe of identities.
  • CompuServe Information Serve (CIS) and America Online (AOL) screen names are two examples of realms. The combination of user name and realm, typically shown as name@realm, identifies a user. Any given service recognizes some particular set of identities.
  • a realm does not have to be large either in number of users or size of service. For example, a single WWW server may have its own realm of users.
  • Authentication provides the ability to prove identity.
  • the user may be asked for his or her identity.
  • the service then usually requires the user to prove that identity.
  • most services use a separate character string as a password.
  • the password is intended to be kept confidential. If the password given for a particular identity is correct, the user is authenticated.
  • a password system is generally reliable for communications in which a medium level of trustworthy authentication is tolerable.
  • Authorization refers to the process of determining whether a given user is allowed to do something. For example, may the user post a message, or use a confidential service? It is important to realize that authentication and authorization are distinct processes.
  • One relates to proving an identity and the other relates to the properties of an identity.
  • a service that wishes to authenticate a user requires the user to identify himself or herself and to prove that he or she knows the pass-phrase. Generally, the service prompts the user for the pass-phrase.
  • transmitting the plain text pass-phrases through a network compromises security because an eavesdropper may learn the pass-phrase as it travels through the network.
  • X.25 networks have been compromised, and LANs, modem pools, and "The Internet" likewise are not suitable for plain text pass-phrases due to the eavesdropper problem. Prompting for the pass-phrase, while sufficient in the past, no longer works for extensive world-wide networks.
  • the present application discloses methods and systems for remote verification of an end user of web page with controlled access. Users are issued a user name and password which can be used to access any site which subscribes to the described verification system.
  • a user connects to a web site which contains desired information. When the user attempts to enter an area (or page) of the site with controlled access the pre-issued user name and password are requested. Once this information is entered, the subscribing website sends a secure (encrypted) query to a remote password database server. The supplied information is checked against a verification database. A yes or no verification is sent back to the subscriber site. The verification can also include anonymized demographic information such as specialty, location, and type of practice. The subscriber site then acts upon the verification received.
  • the information entered by the user, while sent by the subscribing site is not accessible by the subscribing site. Thus, the site cannot create its own database of pre-verified users and the healthcare professional remains in control of his or her information.
  • the presently preferred embodiment also contemplates a gateway site that allows users to login at the gateway, and thereby gain access to direct links to limited access areas of subscribing sites.
  • the present application also discloses a method and architecture wherein computer users who visit a marketing-related Web site may be informed about salespersons in the their area without exposing themselves to solicitations. Users are often required to enter personal information in order to access certain areas of Internet Web sites.
  • the disclosed inventions allow users to enter enough personal data for a marketing Web site to later target that user with solicitations, but prevent the Web site owner from accessing most of that data, thus preventing the solicitations.
  • Users who are registered with the privacy broker (“PVS" in the presently preferred embodiment) are issued passwords and usernames. PVS also keeps other personal data on the user in their database.
  • the PVS server can draw data from its information already on file about the registered user and send selected parts of that data (e.g., zip code, area of specialty) to the subscribing Web site. This information will be enough for the subscribing site to select the correct field sales representative to show the user on their" * screen, along with contact information relevant to that sales representative.
  • data e.g., zip code, area of specialty
  • the disclosed inventions can also be implemented to work for users not registered with PVS.
  • the user is prompted for entry of personal data which is relayed from the marketing-related Web site server to another server (the PVS server).
  • This second server filters the data, returning only enough information to the marketing-related Web site server for that site to select a sales representative who is likely to be encountered by the user, depending on the user's geographic location and area of interest or specialization.
  • the sales representative's face, along with other relevant contact information, is displayed for the user.
  • the user enters only enough data for the marketing- related Web site to determine the sales representative that would be most likely to deal with the user. That salesperson's image appears on the user's screen, along with information necessary for the user to contact the salesperson, if desired.
  • the user need not enter a full address, name, or telephone number, and thus is not exposed to direct solicitation from the salesperson or their company. Only general location information (e.g., zip code, area code, or partial phone number) is entered, possibly along with information about areas of specialization or other interests relevant to the selection of a sales representative.
  • the subscribing Web site sees it all; there simply isn't enough of it to identify the user for direct solicitations.
  • the disclosed inventions also make sales representative information more accessible to remote, vacant, or hard to reach territories. Some areas encounter field sales representatives infrequently or not at all because the area may be on the fringes of territories, sparsely populated, or long distances away. Users who desire information about the easiest sales representative to reach can find that information.
  • the basic password verification process requires that the user be pre-registered with the verification service. Registration allows the user to be entered into a database and assigned an identification and password. These identifiers, when supplied by the user, are matched on the PVS server for verification. However, a more flexible method of verification that does not require pre-registration can also be used, as disclosed in the present application.
  • a U.S. physician who has not received a PVS username and password can complete the Rapid Registration Form, which prompts the physician for personal data. This personal data is matched against the masterfile of all U.S. physicians held by the American Medical Association. Correct entry of the requested personal data achieves verification.
  • the Rapid Registration also allows the physician to request a PVS username and password so that the usual verification process, i.e., comparison with the username and password on the PVS password server, can be used on later visits to PVS subscribing Web sites.
  • the disclosed business method offers health care marketers confidence that they are in complete compliance with rules that restrict or prohibit promoting prescription drugs to the general public. Patient confidentiality is maintained and the health care professional may research specific protocols, drugs, and treatments. Malpractice liability under learned-intermediary tort law is reduced.
  • the disclosed business method also opens direct-to-physician communication on the Web without transgressing legal limits on direct consumer communication.
  • the disclosed methods also provide a verification service to device marketers at a price substantially lower than the cost of creating such a utility in-house. Registration screens, discouraging to much potential Web site traffic, can be minimized or avoided. Also, a storehouse of physician information can be established, and publishers and health care communicators can gauge their audiences more carefully. Clinical trials managers can communicate with potential physician investigators with the speed and cost-effectiveness of the internet and the confidence of the telephone or post. Also, medical educators can use this on-line medium for Continuing Medical Education.
  • Figure 1 depicts a block diagram of the architecture of the Remote Verification System.
  • Figure 2 depicts a flowchart of the method of remote verification.
  • Figure 3 shows a block diagram of a computer system according to the presently preferred embodiment.
  • FIG. 4 shows the IS API Application Extension Process flowchart.
  • FIG. 5 shows the IS API Filter Process flowchart.
  • Figure 6 shows a flowchart of the Rapid Registration Process, both with and without a PVS registered user.
  • Figure 7 depicts an example "welcome" page as seen on the user's browser when they enter the PVS Internet site.
  • Figure 8 shows an example "sign in” page for PVS users.
  • Figure 9 shows a sample "pop-up" sales representative page, where the user's data allows the subscribing Web site to display the sales representative most likely to be encountered by the user.
  • FIGS 10 and 11 show the how verification over the Internet can make ordering restricted access products easier.
  • Firewall A security feature of Internet sites which is aimed at control of data flow.
  • HTML Hypertext Markup Language. A format for information transfer made up of standard text as well as formatting codes which indicate how the page should be displayed in a browser.
  • HTTP Hypertext Transfer Protocol. Designed to run primarily over TCP/IP using an
  • Hypertext A method of linking certain text, pictures or sounds by connections, known as “hypertext links” ("links"), to other pages within the same server or even on other computers within the Internet.
  • SSL Secure Sockets Layer. A protocol for secure and authenticated transactions over the
  • URL Uniform Resource Locator. URL's enable a Web browser to go directly to any file held on any Web server.
  • Web The World-Wide Web (Web) is a method of accessing information on the Internet which allows a user to navigate the Internet resources intuitively, without IP addresses or other technical knowledge.
  • X.25 A packet switching network protocol in which many connections are made over the same physical link.
  • the remote authentication system consists of three components.
  • Figure 1 depicts a block diagram of the architecture of the Remote
  • the Remote Verification System acts as an Internet notary. Its function is to attest to the identity of incoming users to Web servers which control access to their information and can be positioned anywhere on the Internet.
  • the system is designed to verify the passwords of health care professionals who seek entry into controlled access sites on the Internet.
  • health care professionals includes not only physicians, but persons in other regulated or licensed occupations that rely on information concerning pharmaceuticals and medical devices. Such occupations include, for example, dentists, doctors of osteopathy, pharmacists, certain nurses, and other specialist occupations which may exist within the laws of the U.S. or other countries.
  • Such sites can be provided by pharmaceutical companies as a marketing tool for new products and other information, and by medical societies as a service to members of their organizations.
  • a user name and password combination is distributed in advance to verified health care professionals.
  • Such information can be distributed via Internet, by mail, and/or by the sales force for a subscribing health care marketing organization. Typically this information comes from the American Medical Association's database of all U.S. physicians and other public record and professional society databases.
  • the health care professional uses a computer 102 to enter the Web site 104 of a health care marketer or professional education provider across a first channel of communications.
  • a Web site of this sort will typically contain more than just health care professionals-only information.
  • the site may contain employee rosters, human resource information, etc.
  • the system consists of several interlocking software elements, supported by routines running on the password verification server.
  • routines running on the password verification server.
  • the routines Common Gateway Interface (or CGI) scripts, are installed on the subscriber ' s server to handle password and user-name submission transactions and mediate the interaction with the password verification server.
  • CGI Common Gateway Interface
  • the user name and password are not needed until the user requests entry to a "health care professionals-only" segment of the site 104. At this point, the subscriber's Web site 104 requests the user's user name and password.
  • the Customer Representative function 108 (an executable dwelling on the subscriber's site) is responsible for collecting the user's identifiers.
  • the subscriber's Web site 104 Upon receipt of the user's information, the subscriber's Web site 104 sends a secure query to a password verification server 106 via the Internet (or other telecommunications link) across a second channel of communications.
  • the query is secured via a proprietary encryption algorithm. Additionally, an SSL connection can be established to enhance security.
  • the Password Client 110 (a communications program dwelling on the subscriber ' s site) is a TCP/IP communications routine which sends the query. It establishes contact with the Password Verification Server 106.
  • the query is an encrypted message containing the subscriber's identity (for billing and verification purposes), a reply IP address, username and password.
  • the password verification server 106 contains a communications and database interface. It will receive the Password Client's encrypted message. Then a password database will be searched in order to verify the username/password pair. An encrypted go/no-go ("thumbs up'V'thumbs down") reply is returned to the Password Client 110 across the second communications channel. This reply can include anonymous demographic information such as specialty, location, and type of practice.
  • the Password Client 1 10 at the subscriber's site 104 receives the secure go/no-go signal back from the password verification server 106.
  • the subscriber's Web site 104 admits or rejects the user's request for access to restricted content based on the verification signal received.
  • FIG. 2 depicts a flowchart of the method of remote verification.
  • the flow of information of the remote verification system will be explained in relation to the software elements comprising the system.
  • a health care professional or "user”
  • a computer makes contact with a subscribing pharmaceutical or medical device manufacturer's Web site (or "subscribing site") (step 202) across a first communications channel.
  • a subscribing pharmaceutical or medical device manufacturer's Web site or "subscribing site”
  • an HTML script requests and collects user name and password information from the user (step 206).
  • a routine, "PVSClien” prepares a message to send to a password verification server (step 208) across a second communications channel.
  • the message comprises the collected user name and password, as well as an identifier to the calling site (subscribing site) for billing, the particular calling page, and a time stamp.
  • the message is prepared, it is encrypted using the proprietary algorithm described below and sent to a password verification server (step 210). Additionally, an SSL connection can be established to enhance security.
  • a t t h e password verification server, a routine, "PVServer” decrypts the message and verifies the user name and password received (step 212).
  • the routine In order to decrypt the information, the routine matches the encryption key with the calling site. Once decrypted, the routine looks up the user's record in a verification database.
  • the user record in the presently preferred embodiment, includes: user name, password, specialty code, zip code, type of practice code, and medical education number.
  • PVServer prepares a response to send to the subscribing site (step 214) across the second communications channel.
  • This message includes: user name, password, specialty code, zip code, type of practice, and an indication of whether the user is accepted or rejected.
  • the message can also include a short text communication, for example, contact information for users having password problems. Such messages can be tailored to specialty or geography.
  • PVServer then encrypts and sends the response to the subscribing site in a secure manner (step 216). The response is secured via a proprietary encryption algorithm. Additionally, an SSL connection can be established to enhance security.
  • PVSClien receives the response and decrypts it (step 218).
  • Another routine, "drugs 1", executing at the subscribing site is responsible for: welcoming or rejecting the user based on the indication and passing demographic information such as specialty, zip, type of practice and ME number to subscribing site (step 220).
  • Figure 7 shows an example of a "Welcome” page.
  • This page welcomes the user and states what PVS has listed as the user's zip code and specialty. There are several links provided to the user. The user may update the PVS files kept on the user, visit the American Medical Association's site, or connect directly to several pharmaceutical company sites.
  • Figure 8 is a sample "Sign-in” page. Users who are already registered with PVS and have a password and username may use this page to sign in and gain access to limited access areas of pharmaceutical Web sites, and to other PVS "physician only” services. In this example, a demonstration username “mccormickdkOl" has been entered in the "username” field.
  • the "password” field shows that a password has been entered as well (represented by asterisks). The user then clicks the "submit” button shown below these two fields, and the username and password will undergo verification. If the identifiers entered match those on the PVS server list of registered users, the user is verified.
  • Figure 9 shows an example of the "pop-up" sales representative page.
  • the user sees the SmithKline Beecham products and services page, which gives information about pediatric pharmaceutical products.
  • the image of a person is shown, along with contact information. In actual practice, this would be a real SmithKline Beecham field representative whom the user could contact.
  • the user wishes to enter the secured area of a subscribing Web site.
  • the user may enter the PVS password and username if the user is registered with PVS.
  • some health professionals are not registered with PVS, and will consequently not be able to enter the required identifiers. In this case, the user will be required to complete the Rapid Registration Form which is reached through a hyperlink.
  • the Rapid Registration Form requests the users first name, last name, middle initial, year of graduation from medical school, state or country of medical school, date of birth (two digit day, two digit month, four digit year), current zip code for main mailing address, and email address.
  • the user will also have the option of registering with Physician Verification Services, and having a username and password sent to the user. This will allow the user to register by entering only these identifiers, rather than the above mentioned information.
  • FIG. 6 shows a flowchart of the verification process.
  • the user enters a Web site that has limited access areas which require verification of the user's status in order for the user to enter.
  • the user sees both a rapid registration and a registered user option. If the user has preregistered with PVS and already has a PVS password and username, the user enters these identifiers (step 604).
  • the Web site server sends this data to the PVS server (step 606), which checks the data for a match on the PVS registered user lists (step 608).
  • the PVS server then returns a verification of the user's status to the Web site (step 610). If the identifiers match, PVS returns a "yes" verification and the user is admitted to the limited access area (step 612).
  • PVS returns a "no" to the Web site (step 614). If a "no" verification is returned, or if the user otherwise is not registered with PVS, the user may use Rapid Registration (step 618). At this time, the user will also be given the option to register with PVS to obtain a username and password for future use (step 620).
  • the Rapid Registration Form page the user is prompted to enter identifying data, including name, year of graduation from medical school, name of the medical school where the user graduated, date of birth, zip code, and email address (step 622). The Web site server sends this data to the PVS server for verification (step 624).
  • the PVS server checks the requested identifiers against the American Medical Association ' s (AMA's) masterfile (step 626), which is updated periodically on the PVS server. PVS returns a "yes” or “no” verification (step 628). If the data matches that in the AMA masterfile, PVS returns a "yes" verification and the user is admitted to the limited access area (step 612). If the data does not match, PVS returns a "no" verification and the user is not admitted to the limited access area (step 630).
  • AMA's American Medical Association 's
  • values of P and N are selected to be in the range of 31 to 32 bits in length.
  • Encryption of a message comprises taking three bytes of clear text and appending a fourth byte of random number. A third 32-bit value, A is added to that result and then the entire result is multiplied by N. The result of the multiplication step is then divided by P. The remainder of the division constitutes the encrypted message which will be transmitted over the Internet.
  • the encrypted number is multiplied by 1/N and then divided by P. The value. A, is then subtracted from the remainder. The randomly-generated portions of the result are discarded. The result is the original clear text.
  • the above method of encryption offers both speed and efficiency.
  • the encryption sends four bytes of encrypted data for every three bytes of plain text. Therefore, there is a relatively smaller (33%) increase in communication volume. Further, encryption and decryption utilize simple mathematical operations allowing for quick processing times.
  • ISA Internet Server Applications
  • Filters provided by an Internet Server Application Programming Interface.
  • An ISA is a dynamic-link library (DLL), that is, one or more functions that are compiled, linked, and stored separately from the processes that utilize them. Filters sit between the client and a server and allow special actions to take place. While both CGI scripts and ISAs (and Filters) can perform many of the same services (and all of the same services for the purpose of this application), ISAs and Filters offer certain advantages. The biggest advantage is that an ISA can execute in the same address space as the process that utilizes it.
  • DLL dynamic-link library
  • CGI scripts execute as separate processes and therefore require environmental variables to be passed between processes in order for communication to take place. Additionally, since the calling process is aware of the ISA in memory it can purge the ISA if it is no longer needed (or has not been called recently) and can preload it for faster execution when called. Any operating systems which supports loadable shared images, such as Windows NTTM for example, can utilize ISAs and Filters.
  • PVS1 ISAPI Application Extension is the first element in the verification chain offered by Physician Verification Services (PVS) on Web servers utilizing Microsoft Windows
  • NT NT
  • IIS Microsoft Internet Information Server
  • PVS 1 DLL file. Because it is an executable, it is found in a folder that must be flagged as executable by the IIS. This executable code is fired off when, for example, a doctor seeking protected information arrives at the gateway HTML page and fills in the UserName and
  • the gateway HTML page is found at
  • the PVS1 ISAPI is invoked after the PVS gateway password HTML page is shown to a person browsing for protected information. The person first enters his or her UserName and Password in the appropriate fields. When the Submit button is pressed, the PVS 1. DLL ISAPI Application Extension is fired off, and the user-supplied data is passed to the
  • the Application Extension displays either an error or a welcome message. Both of those are derived from HTML templates, which will be described below. Appropriate entries are made in a log file, also to be described below.
  • the PVS-issued cookie is valid for four hours. HTML requests for protected information from that computer will be honored during that time period. Any subsequent requests will result in the user's browser being directed once again to the password page.
  • the server's behavior when a user attempts to access a protected site is governed by the other part of the PVSl.
  • DLL program The PVSl ISAPI Filter.
  • the filter portion of the software is a part of the PVSl . DLL which gets loaded at the same time as Internet Information Server.
  • the PVSl ISAPI Filter examines every HTML request that passes through the IIS WWW server. If any URL maps to a folder that has the string " ⁇ PRI" in its path name, the PVSl ISAPI Filter regards the information contained in that folder to be protected. If the URL mapping doesn't contain that string, the filter takes no action at all.
  • the filter checks to see if there is a valid PVS-issued cookie in the HTML request headers. If not, then the user's browser is shown an HTML file named NotYet.htm in the folder immediately above the " ⁇ PRI" folder in the directory tree.
  • the filter next checks to see if the user's Authorization Bits (which came from the server and were stored in the cookie) match the authorization bits of the protected folder.
  • a folder's authorization bits are appended to the folder's name in a hexadecimal scheme. The hexadecimal decoding starts immediately after the " ⁇ PRI". Hyphens are ignored and can be used to make the code more readable; any other character terminates the string.
  • a folder with no authorization bit code string can be accessed by any verified user. If the user's Authorization Bits do not match the string appended to the folder name, the user is presented with the HTML page NotAuthorized.htm in the folder immediately above the " ⁇ PRI" folder in the directory tree.
  • the cookie jar maintains a list of the most recent UserNames to access protected files, and how many hits there were. Periodically the filter empties the cookie jar, sending a notification off to the PVS server that it did so. Password verification requests, the responses from the PVS server, and cookie jar dump are all logged in a PVS log file on the client server. The log file is described below.
  • the PVSl ISAPI Application Extension and the PVSl ISAPI Filter need some site-dependent information in order to function. Rather than build such information into the software, it is kept in an initialization file.
  • TemplateRoot "c : ⁇ inetpub ⁇ wwwroot ⁇ pvs 1 ⁇ cgi-bin"
  • TemplateRoot There are a number of different possible responses that the PVSl. DLL program can generate. Those responses are derived from HTML templates and the template root tells the PVSl. DLL program where to find those templates. You will probably alter this to match your own Web page directory structure. This can be altered to match a particular web page directory structure.
  • ServerTimeout the number of milliseconds the program waits for a response from the server before resending the request. After four resends it gives up and tells the browser that there was no response. Setting the timeout to 5000 means that the browser will get an error response after twenty seconds.
  • the log files are maintained in the folder c-log.txt in the folder specified by the LogRoot entry of the c: ⁇ pvsclient ⁇ pvsl.ini file.
  • the c-log.txt file is only allowed to grow to be 1,000,000 bytes in length, at which point it is renamed c-logl.txt.
  • any file already named c-logl.txt replaces any file already named c-log2.txt. In this fashion, between two and three million bytes of history are maintained, but in a way that doesn't just keep growing forever.
  • the information in the log files is kept for two reasons. First, it will help in tracking down problems, should there be any. Second, the information is available to the site administrators for review and analysis.
  • the log file contains a handful of different possible entries. Each line contains a number of different fields, which are identified by number and separated by ⁇ tab> characters.
  • TIMESTAMP YYYYMMDDHHMMSS.SSS UTC
  • PHARM_SITE Site code from the PVSl.
  • INI file 8 SERVER_NAME: Computer name of the client server
  • TIMEOUT Indicates that the server didn't respond to a password request
  • PVS provides interpretive tables where required.
  • PVS server is not responding, the response will be repeated three additional times, and will then be followed by
  • the PASSWORD.HTM file This file doesn ' t have to have any particular name. It can be found in any number of places in a Web site's structure (provided that they are not " ⁇ PRI" locations), and, indeed, doesn't have to have any particular form except that the data form must match the one on the PVS sample. Its purpose is to invoke the PVSl ISAPI Application Extension and generate a request to the PVS Password Server.
  • ⁇ TemplateRoot ⁇ needpw.htm As its name suggests, this file must be found in the TemplateRoot specified in the C: ⁇ PVSCLIENT ⁇ PVS1.INI file. This page gets displayed by the PVSl ISAPI Application Extension when either the UserlD or the UserID2 fields from the PASSWORD.HTM page are empty when the Submit button is clicked.
  • ⁇ TemplateRoot ⁇ timeout.htm This page is displayed to the user when the HTML server is unable to get a response from the PVS Password Server. The PVSl ISAPI Application Extension will try four times at intervals specified by the ServerTimeout parameter in the PVSl. INI file.
  • ⁇ TemplateRoot ⁇ pwnogood.htm This page is displayed to the user when the PVS Password Server sends back a "Not Verified" response.
  • ⁇ path ⁇ NotYet. htm There can be any number of NotYet.htm files; there must be one in each folder that has a subfolder named " ⁇ PRI".
  • the ⁇ path ⁇ NotYet.htm file is displayed when an unverified user attempts to access a Web page stored in a folder below ⁇ path ⁇ pri ⁇ .
  • ⁇ path ⁇ Not Author ized . htm Similar to the ⁇ path ⁇ NotYet.htm file, this one is displayed when a verified user attempts to access a " ⁇ PRI-xx" folder when the user doesn't have an Authorization Bit which matches the hexadecimal "-xx" code of the folder. There must be one such NotAuthorized.htm file in each folder immediately above each ⁇ path ⁇ pri-xx ⁇ folder.
  • Each site can put whatever HTML information might be desired into the various template HTML files.
  • the PVS template files can be modified slightly based on the information that comes back from the PVS Password Server.
  • the pwokay.htm file might contain the following HTML text string:
  • the PVSl ISAPI Filter is checking every URL request that the server receives, as shown in Figure 5.
  • Figure 4 begins with the user submitting a username and a password (step 402).
  • the application extension checks for missing identifiers (step 404). Missing identifiers prompt an error message display (step 406). Otherwise, the request is sent to the PVS Server (step 408). If a response is not returned in the allotted time (step 410) then the timeout is logged (step 412) and displayed (step 414). If the response is timely, it is checked for a match in the database (step 416). A non-match will return a "no good" display (steps 418 and 420). If the response is OK'd, a PVS cookie is issued to the user (step 422) and an acceptance message is displayed (step 424).
  • FIG. 5 shows the PVSl ISAPI Filter Process.
  • First the URL request is checked (step 502). If it is time to dump the cookie jar (step 504) then a new process to send a cookie jar to the PVS Server is spawned (step 506). If it is not time to dump the cookie jar, the URL is checked for a " ⁇ PRI" string (step 508). If not, then the Web page is processed normally (step 510). If so, the user is checked for a valid cookie (step 512). If the user has no valid cookie, the filter displays the ⁇ Path ⁇ NotYet.html (step 514). If the user still has a valid cookie, then the filter checks the ⁇ Pri for -xx authorization suffix (step 516).
  • the user ' s cookie bits are checked against the ⁇ Pri-xx bits (step 518). If they do not match, then a non-authorization page is displayed (step 520). If they do match, then the username is accumulated in the cookie jar (step 522). The Web server is then allowed to process the requested page (step 524).
  • Figure 3 shows a block diagram of a computer system 300 which can be used for implementation of a client or server used in the presently preferred embodiment.
  • the computer system includes: user input devices (e.g. keyboard 335 and mouse 340); at least one microprocessor 325 which is operatively connected to receive inputs from said input device, through an interface manager chip 330 (which also provides an interface to the various ports); a power supply 305 which is connected to draw power from AC mains and provide DC voltage to the computer system 300 components; a memory (e.g. flash or non-volatile memory 355 and RAM 360), which is accessible by the microprocessor; a data output device (e.g.
  • a data output device e.g.
  • the computer may also include a CD-ROM drive 380 and floppy disk drive (“FDD") 375 which may interface to the disk interface controller 365.
  • FDD floppy disk drive
  • L2 cache 385 may be added to speed data access from the disk drives to the microprocessor, and a PCMCIA 390 slot accommodates peripheral enhancements.
  • Password Client 110 can be configured to be in constant communication. Such communication will allow messages other than short text messages to be displayed to health care professionals. For instance, the system can operate as a rapid-notification service for users, passing messages of particular importance to a particular user once it is known that the user is connected with a particular subscribing site.
  • the function of the verification services described can be extended to digital signature-like verifications.
  • prescription orders can be delivered on-line to mail order or local pharmacies.
  • the use of such a verification and delivery service would help to eliminate the need for both a paper prescription, which can be forged or lost, and faxing between a physician's office and a pharmacy.
  • the time for a delivery of a mail-order prescription can be reduced due to the immediate delivery of the prescription authorization to the mail-order pharmacy via the Internet.
  • Figures 10 depict the present process of physician-initiated sampling.
  • the physician requests a sample requiring verification of the physicians identity and status as a licensed physician (step 1002).
  • the sample is to be sent to the physician (step 1004) or to a patient (step 1006). If sent to the physician, it is to be sent either by the physician's field sales representative (step 1008) or by courier (step 1010). Patient deliveries are by courier (step 1012) in this model.
  • an automated business reply card (BRC) is used (step 1014). This is a system that produces an electronic form with fields for the physician's information needed by the pharmacy.
  • the BRC is returned to the pharmaceutical company for action by the field sales force representative (step 1020), who does the actual distribution of the sample.
  • an online form with faxed signature is used.
  • An online form with the relevant physician's information (step 1016) or with the physician ' s and the patient's information (step 1018) is sent directly to a sample fulfillment house (a pharmaceutical company or an agent of one), who distributes the samples to the doctor (step 1022) or the patient (step 1024).
  • the online form has fields for the physician ' s (or the physician ' s and patient's) information like the BRC, but also generates a form for the doctor ' s signature to be returned to the pharmacy by fax.
  • the physician fills in the relevant fields of the electronic form, which creates a suspense file at the fulfillment house, awaiting a faxed signature by the doctor. Once complete with signature, the samples are sent. In many jurisdictions, an actual signature is required for the legal ordering of prescription drugs.
  • the presently disclosed embodiment of the invention creates an alternative to this method of verification by substituting an "e-signature" for the online form and faxed signature.
  • Figure 11 shows the same process for physician-initiated sampling, but steps 1016 and 1018 are replaced by steps 1102 and 1104—using e-signatures instead of faxed signatures.
  • the presently disclosed embodiment of the invention by verifying the identity and status of a computer user as a physician, obviates the need for a faxed signature.
  • Non-repudiation meaning a user cannot deny having sent the message
  • authentication means the origin of the data
  • the present disclosed embodiment coupled with an SSL fulfills the three criteria of the proposed e-signature standards.
  • the user first visits the PVS Web site and enters the
  • PVS username and password From there, the user can link directly to the controlled access areas of physician only Web sites with hyperlinks on the PVS site.
  • the hyperlinks to limited access areas from the PVS site may be reached after logging in at the PVS site with the PVS username and password. These hyperlinks will then take the user directly to the limited access areas, without having to go through the PVS verification again.
  • subscribing Web site servers may retain passwords and usernames locally in their storage. This allows faster verification, eliminating the need to directly access PVS for every verification. Frequent or recent visitors to a Web site may be verified with the local memory of their usernames and passwords. The subscribing Web sites are prevented from seeing the personal data of the users either by contract or by PVS software stored locally designed to prevent access.
  • secure locking relationships can be used to completely prevent vendors from cracking the PVS front-end software and gaining access to the secure data.
  • the professionals accessing a vendor site can be allowed to simply click on a button to give the vendor their complete identification data.
  • the hardware which comprises the system can be any combination of available processors and operating systems.
  • Such systems can include, for example, Unix boxes, IBM PC compatible, and Macintosh computer systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé et un système permettant de vérifier à distance l'utilisateur final d'une page Web avec accès contrôlé. Les utilisateurs reçoivent un nom d'utilisateur et un mot de passe qu'ils peuvent utiliser pour accéder à tous les sites abonnés audit système de vérification. L'utilisateur se connecte au site Web qui contient les informations désirées. Lorsqu'il tente d'accéder à une zone (ou une page) du site pourvu d'un accès contrôlé, le nom d'utilisateur et le mot de passe délivrés lui sont demandés. Une fois ces informations introduites, le site Web abonné envoie une interrogation sécurisée (codée) à un serveur de base de données de mot de passe à distance. Les informations fournies sont vérifiées par rapport à la base de données de vérification. Une vérification sécurisée par oui ou par non est renvoyée au site abonné. Cette vérification peut renfermer des informations démographiques à caractère anonyme, telles que la spécialité, le lieu et le type de pratique. Le site abonné agit ensuite en fonction de la vérification reçue. Les informations entrées par l'utilisateur, bien qu'envoyées par le site abonné, ne sont pas accessibles audit site. Ainsi, le site abonné ne peut pas créer sa propre base de données d'utilisateurs prévérifiés. De préférence, les utilisateurs ne doivent pas se préenregistrer et peuvent avoir accès en introduisant des indicatifs qui sont vérifiés par rapport à des registres officiels d'associations médicales. De préférence, chaque fois qu'un utilisateur accède à un site Web et fournit des données démographiques de base, l'image du représentant des ventes qui traitera très probablement avec lui (en fonction du lieu, du code zip, du domaine d'intérêt, etc.) s'affichera sur son écran. Le site Web, qui reçoit assez de données entrées par l'utilisateur, choisit le représentant des ventes approprié, mais pas suffisamment pour cibler ledit utilisateur avec des sollicitations.
EP99954660A 1998-11-03 1999-09-24 Service d'authentification de medecins a distance Withdrawn EP1145526A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10683898P 1998-11-03 1998-11-03
US106838P 1998-11-03
US24830899A 1999-02-11 1999-02-11
US248308 1999-02-11
PCT/US1999/022253 WO2000027088A2 (fr) 1998-11-03 1999-09-24 Service d'authentification de medecins a distance

Publications (1)

Publication Number Publication Date
EP1145526A2 true EP1145526A2 (fr) 2001-10-17

Family

ID=26804081

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99954660A Withdrawn EP1145526A2 (fr) 1998-11-03 1999-09-24 Service d'authentification de medecins a distance

Country Status (5)

Country Link
EP (1) EP1145526A2 (fr)
JP (1) JP2002529839A (fr)
AU (1) AU1095800A (fr)
CA (1) CA2346709A1 (fr)
WO (1) WO2000027088A2 (fr)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9026133B2 (en) 2011-11-28 2015-05-05 At&T Mobility Ii Llc Handset agent calibration for timing based locating systems
US9046592B2 (en) 2012-06-13 2015-06-02 At&T Mobility Ii Llc Timed fingerprint locating at user equipment
US9053513B2 (en) 2010-02-25 2015-06-09 At&T Mobility Ii Llc Fraud analysis for a location aware transaction
US9094929B2 (en) 2012-06-12 2015-07-28 At&T Mobility Ii Llc Event tagging for mobile networks
US9103690B2 (en) 2011-10-28 2015-08-11 At&T Mobility Ii Llc Automatic travel time and routing determinations in a wireless network
US9191821B2 (en) 2011-10-28 2015-11-17 At&T Mobility Ii Llc Sharing timed fingerprint location information
US9196157B2 (en) 2010-02-25 2015-11-24 AT&T Mobolity II LLC Transportation analytics employing timed fingerprint location information
US9232525B2 (en) 2011-07-21 2016-01-05 At&T Mobility Ii Llc Selection of a radio access technology resource based on radio access technology resource historical information
US9232399B2 (en) 2011-11-08 2016-01-05 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US9247441B2 (en) 2012-07-17 2016-01-26 At&T Mobility Ii Llc Facilitation of delay error correction in timing-based location systems
US9326263B2 (en) 2012-06-13 2016-04-26 At&T Mobility Ii Llc Site location determination using crowd sourced propagation delay and location data
US9351111B1 (en) 2015-03-06 2016-05-24 At&T Mobility Ii Llc Access to mobile location related information
US9351223B2 (en) 2012-07-25 2016-05-24 At&T Mobility Ii Llc Assignment of hierarchical cell structures employing geolocation techniques
US9398556B2 (en) 2012-06-15 2016-07-19 At&T Intellectual Property I, L.P. Geographic redundancy determination for time based location information in a wireless radio network
US9408174B2 (en) 2012-06-19 2016-08-02 At&T Mobility Ii Llc Facilitation of timed fingerprint mobile device locating
US9462497B2 (en) 2011-07-01 2016-10-04 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US9473897B2 (en) 2012-06-14 2016-10-18 At&T Mobility Ii Llc Reference based location information for a wireless network
US9519043B2 (en) 2011-07-21 2016-12-13 At&T Mobility Ii Llc Estimating network based locating error in wireless networks
US9563784B2 (en) 2012-04-13 2017-02-07 At&T Mobility Ii Llc Event driven permissive sharing of information
US9810765B2 (en) 2011-11-28 2017-11-07 At&T Mobility Ii Llc Femtocell calibration for timing based locating systems
US9813900B2 (en) 2010-12-01 2017-11-07 At&T Mobility Ii Llc Motion-based user interface feature subsets
US10516972B1 (en) 2018-06-01 2019-12-24 At&T Intellectual Property I, L.P. Employing an alternate identifier for subscription access to mobile location information

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002024390A (ja) * 2000-07-06 2002-01-25 Kobayashi Pharmaceut Co Ltd オンラインショッピングシステム
US7373524B2 (en) 2004-02-24 2008-05-13 Covelight Systems, Inc. Methods, systems and computer program products for monitoring user behavior for a server application
US8737617B2 (en) * 2009-09-29 2014-05-27 Panasonic Corporation Encryption apparatus, decryption apparatus, encryption method, decryption method, and encryption/decryption system
CN112437066B (zh) * 2020-11-12 2023-02-03 四川省肿瘤医院 一种身份识别和数字认证的敏感数据处理系统和方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0027088A3 *

Cited By (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9196157B2 (en) 2010-02-25 2015-11-24 AT&T Mobolity II LLC Transportation analytics employing timed fingerprint location information
US9053513B2 (en) 2010-02-25 2015-06-09 At&T Mobility Ii Llc Fraud analysis for a location aware transaction
US9813900B2 (en) 2010-12-01 2017-11-07 At&T Mobility Ii Llc Motion-based user interface feature subsets
US10972928B2 (en) 2011-07-01 2021-04-06 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US11483727B2 (en) 2011-07-01 2022-10-25 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US10091678B2 (en) 2011-07-01 2018-10-02 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US9462497B2 (en) 2011-07-01 2016-10-04 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US10701577B2 (en) 2011-07-01 2020-06-30 At&T Mobility Ii Llc Subscriber data analysis and graphical rendering
US10085270B2 (en) 2011-07-21 2018-09-25 At&T Mobility Ii Llc Selection of a radio access technology resource based on radio access technology resource historical information
US9519043B2 (en) 2011-07-21 2016-12-13 At&T Mobility Ii Llc Estimating network based locating error in wireless networks
US9232525B2 (en) 2011-07-21 2016-01-05 At&T Mobility Ii Llc Selection of a radio access technology resource based on radio access technology resource historical information
US9510355B2 (en) 2011-07-21 2016-11-29 At&T Mobility Ii Llc Selection of a radio access technology resource based on radio access technology resource historical information
US10229411B2 (en) 2011-08-05 2019-03-12 At&T Mobility Ii Llc Fraud analysis for a location aware transaction
US10448195B2 (en) 2011-10-20 2019-10-15 At&T Mobility Ii Llc Transportation analytics employing timed fingerprint location information
US9681300B2 (en) 2011-10-28 2017-06-13 At&T Mobility Ii Llc Sharing timed fingerprint location information
US10206113B2 (en) 2011-10-28 2019-02-12 At&T Mobility Ii Llc Sharing timed fingerprint location information
US9103690B2 (en) 2011-10-28 2015-08-11 At&T Mobility Ii Llc Automatic travel time and routing determinations in a wireless network
US9191821B2 (en) 2011-10-28 2015-11-17 At&T Mobility Ii Llc Sharing timed fingerprint location information
US10084824B2 (en) 2011-11-08 2018-09-25 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US11212320B2 (en) 2011-11-08 2021-12-28 At&T Mobility Ii Llc Location based sharing of a network access credential
US10594739B2 (en) 2011-11-08 2020-03-17 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US10362066B2 (en) 2011-11-08 2019-07-23 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US9667660B2 (en) 2011-11-08 2017-05-30 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US9232399B2 (en) 2011-11-08 2016-01-05 At&T Intellectual Property I, L.P. Location based sharing of a network access credential
US9026133B2 (en) 2011-11-28 2015-05-05 At&T Mobility Ii Llc Handset agent calibration for timing based locating systems
US9743369B2 (en) 2011-11-28 2017-08-22 At&T Mobility Ii Llc Handset agent calibration for timing based locating systems
US9810765B2 (en) 2011-11-28 2017-11-07 At&T Mobility Ii Llc Femtocell calibration for timing based locating systems
US9563784B2 (en) 2012-04-13 2017-02-07 At&T Mobility Ii Llc Event driven permissive sharing of information
US9864875B2 (en) 2012-04-13 2018-01-09 At&T Mobility Ii Llc Event driven permissive sharing of information
US9094929B2 (en) 2012-06-12 2015-07-28 At&T Mobility Ii Llc Event tagging for mobile networks
US9955451B2 (en) 2012-06-12 2018-04-24 At&T Mobility Ii Llc Event tagging for mobile networks
US10687302B2 (en) 2012-06-12 2020-06-16 At&T Mobility Ii Llc Event tagging for mobile networks
US9596671B2 (en) 2012-06-12 2017-03-14 At&T Mobility Ii Llc Event tagging for mobile networks
US9326263B2 (en) 2012-06-13 2016-04-26 At&T Mobility Ii Llc Site location determination using crowd sourced propagation delay and location data
US9046592B2 (en) 2012-06-13 2015-06-02 At&T Mobility Ii Llc Timed fingerprint locating at user equipment
US9723446B2 (en) 2012-06-13 2017-08-01 At&T Mobility Ii Llc Site location determination using crowd sourced propagation delay and location data
US9521647B2 (en) 2012-06-13 2016-12-13 At&T Mobility Ii Llc Site location determination using crowd sourced propagation delay and location data
US10477347B2 (en) 2012-06-13 2019-11-12 At&T Mobility Ii Llc Site location determination using crowd sourced propagation delay and location data
US9473897B2 (en) 2012-06-14 2016-10-18 At&T Mobility Ii Llc Reference based location information for a wireless network
US9769623B2 (en) 2012-06-14 2017-09-19 At&T Mobility Ii Llc Reference based location information for a wireless network
US9398556B2 (en) 2012-06-15 2016-07-19 At&T Intellectual Property I, L.P. Geographic redundancy determination for time based location information in a wireless radio network
US9615349B2 (en) 2012-06-15 2017-04-04 At&T Intellectual Property I, L.P. Geographic redundancy determination for time based location information in a wireless radio network
US9769615B2 (en) 2012-06-15 2017-09-19 At&T Intellectual Property I, L.P. Geographic redundancy determination for time based location information in a wireless radio network
US9408174B2 (en) 2012-06-19 2016-08-02 At&T Mobility Ii Llc Facilitation of timed fingerprint mobile device locating
US10225816B2 (en) 2012-06-19 2019-03-05 At&T Mobility Ii Llc Facilitation of timed fingerprint mobile device locating
US9591495B2 (en) 2012-07-17 2017-03-07 At&T Mobility Ii Llc Facilitation of delay error correction in timing-based location systems
US9247441B2 (en) 2012-07-17 2016-01-26 At&T Mobility Ii Llc Facilitation of delay error correction in timing-based location systems
US10039111B2 (en) 2012-07-25 2018-07-31 At&T Mobility Ii Llc Assignment of hierarchical cell structures employing geolocation techniques
US9351223B2 (en) 2012-07-25 2016-05-24 At&T Mobility Ii Llc Assignment of hierarchical cell structures employing geolocation techniques
US10206056B2 (en) 2015-03-06 2019-02-12 At&T Mobility Ii Llc Access to mobile location related information
US9351111B1 (en) 2015-03-06 2016-05-24 At&T Mobility Ii Llc Access to mobile location related information
US10516972B1 (en) 2018-06-01 2019-12-24 At&T Intellectual Property I, L.P. Employing an alternate identifier for subscription access to mobile location information

Also Published As

Publication number Publication date
JP2002529839A (ja) 2002-09-10
WO2000027088A2 (fr) 2000-05-11
AU1095800A (en) 2000-05-22
CA2346709A1 (fr) 2000-05-11
WO2000027088A3 (fr) 2000-08-31

Similar Documents

Publication Publication Date Title
US20020120573A1 (en) Secure extranet operation with open access for qualified medical professional
WO2000027088A2 (fr) Service d'authentification de medecins a distance
US8296341B2 (en) Privacy and security method and system for a world-wide-web site
US8612543B2 (en) Personal criteria verification using fractional information
Rose et al. Current technological impediments to business-to-consumer electronic commerce
US6314425B1 (en) Apparatus and methods for use of access tokens in an internet document management system
US20090113518A1 (en) Method for Establishing a Person as a User in a System
Halamka et al. A WWW implementation of national recommendations for protecting electronic health information
WO2001065380A1 (fr) Exploration anonyme et privee de sites web a travers des portails prives
JP2006134319A (ja) インターネットサーバーのアクセス管理およびモニタシステム
US20030163740A1 (en) User interface system
KR20170135332A (ko) 공인기관에 의한 의료기록 관리 및 전송 시스템 및 방법
US20040078312A1 (en) Method and apparatus for providing comprehensive educational and financial services
WO2003030002A1 (fr) Systemes et procedes pour realiser une messagerie electronique securisee
JP2001306521A (ja) 属性別アクセス制御方法及びシステム並びに認証用プログラム又はアクセス制御用データを記憶した記憶媒体
JP2001222645A (ja) オンライン情報登録・格付・認証・仲介システム
US6996619B2 (en) Network service
Schroeder Wired for business
JP2002099773A (ja) 遺伝子情報データベースを用いた情報格付・認証・仲介システム
JP2004334433A (ja) オンラインサービスにおける匿名化方法、ユーザの識別子の管理方法、匿名化装置、匿名化プログラム、及びプログラム記憶媒体
US20020184100A1 (en) Casual access application with context sensitive pin authentication
Knorr et al. Towards a secure web-based healthcare application
KR20020033891A (ko) 통합웹페이지억세스시스템 및 방법
JP2003515226A (ja) 法律情報配付システムおよび方法
Olson Technology Infrastructures

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010720

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20040401