00870-Prosecution History

N~ PATENT NUMBER,
U_
~ Q ~ 0~ ~~ ~ •
LL 8199046
V1 N stn cn
%p
ro u
-'0' C0 6199048
U i
SECTOR CLASS SUBCLASS ART UNIT EXAMINER

7
FILED WITH : U DISK (CRF) "FICHE

~ .~ (Attached in pocket on right inside flap)
i
I PREPARED AND APPROVED FOR ISSUE, !
ISSUING CLASSIFICATION 1
ORIGINAL CROSS R IRENCE(S)
CLASS SUBCLASS CLASS SUBCLAS , ONE SUBCLASS PER BLOCK)
INTERNATIONAL CLASSIFICATION 3J ~~Z, of %rJZ, U
611-- 0-
6 (e
q Continued on Issue Slip Inside File Jacket
TERMINAL DRAWINGS CLAIMS ALLOWED

DISCLAIMER Sheets Drwgr Figs.DrW§'
. min i[`g. Total Claims ti>°- Print ClaiKfor O .G.
q a) The term of this patent NOTICE OF ALLOWANCE MAILED

(date) - ___-
subsequent to
has been disclaimed. (Assistant Examiner) (Date) ^
q b) The term of this patent shall DANIEL H . PM

not extend beyond the expiration date,
PRIMARY uePefS
s INER
of U .S Patent. No. ISSUE FEE
fjR () p
Amount Dille Date Paid
Examiner) (bate) O(Primay
ISSU&BATCH NUMBER
q c) The terminal months of
this patent have been disclaimed .
(Legal Instruments Examiner) (Date)
WARNING:
The information disclosed herein may be restricted . Unauthorized disclosure may be prohibited by the United States Code Title 35, Sections 122, 181 and 368.
Possession outside the U .S . Patent & Trademark Office Is restricted to authorized employees and contractors only .
Form PTO-436A
(RIk s/98)
NQ 11w VFV I FIS, e,
v+ro .zl If"'r..n,exol~erew ~

(LABEL. AREA)
' ~ . .,__(FACE)

jan U . S PT6
~1 INITIALS
..,PATENT APPOCAtIONN 01/15/ 99
CONTEWS
09232908 ~eceived
C. Date received
(Incl. C. of M.)
or
Date Mailed Date Mailed
1.Application papers 41
2. 43.
3. 44.
2 rn d5. (1 G ~~ 45.
5. cOd 2ev Cw*4 16.
5"6b '.42) 47.
6.
7. 48./ —
8. 4
0.
Oy. cyo 51.
050460 52.
12. 53.
54.
M3
~~~~~?ds°l~1~iII - 55. -
F
15. 56.
16.— 57.
17.— 58.
18.— 59.
19. 60.
20. 61-
21. 62.
22. 63.
it 23. 64.
6 24.
65.
25. 66.
26. 67.
27. 68. -
28. 69.
29. 70.
30. 71.
31 72.
32. 73.
'i 33. 74.
I W 75.
35. — 76.
36. 77.
37 . 78.
30 79.
30. 80.
40. - 81.
41 . 82.
(LEFT OUTSIDE)

ISSUE SLIP STAPLE AREA (for addidenal cross reference j
POSITION INITIALS ilk' ~dl ~ . DATE
FEE DETERMINATION
O .I .P .E . CLASSIFIER
FORMALITY REVIEW
INDEX OF CLAIMS
Rejected N Non-elected
_ Allowed I Interference
(Through numeral) . . . Canceled A Appeal
- Restricted 0 Objected
Claim Date Claim Date Claim Date

~
~I •
iL
r,
I IM 'J
c
ilml it
Ip
rn
O
51 ~~
~. ii O
101 .'
C) 52 1
1 53 qI
v
V 22 54 .\ 2 X04
3 55 Ofi 105
i G 2,4156 —\ '1,4 1061
Z~ 57 107 `y
.1 Z 58 106 ~; -
f:
`7 59 t 109 _
'Z,T 601 11
i)^ 10
1
V Z 61 ~\ s i~ 111 ~ _
2
.130 62 \ yo 112 _
31 s 63 113
.31 114
I AJ 4 64
. 3 65 1151 1
- 1I 1 11 W
1 3f~ 66
116
1 Yfll17
1 ~6 116 ~..~
37 69 a' 119
1, 1 1 1 9 1
0 3 70 ~. 20,
1 71 \\ 121
2 41 72 % 112211
3 111 1 Yz 73 - 91 1 41
(Pte 74 Z 124
2 4(j 75 _~ 125
201 1 111 40176 9 ~
1 1 2VI 4S 77 127
A2P 1 J_ J 78, 128
4,77911 29
H_~ 65 BO -' . 30
Alh 1 .11 41 81 . 1311 1
3 • 8211 1 —, I 3
3 f 83 3
f I, — 131 1
Z
3411 -- I S Z 84
35 S3 85 131 1
3 86 ~. 131 1
36
87 131
G 3711 1 1
r 38 -6 88 ~. 1381 1
39 \. 89 1391 1
40 s 90 40
41 S" 91 141 _
61) 92 14
JO 42
14
1143
14AII
T2_ 44
> 45 45
x - 46
46
47 4
48 66 4
49 .\ 14
1
~' 50 16wool _11 501
If more than 150 claims or 10 actions

staple additional sheet here
(LEFT INSIDE)
SEARCHED
Class Sub. r Date Exmr.
0
~ t~ ~ ZL~O,
4
1-7
INTERFERENCE SEARCHED
(loss S6b. Date Exmr.
vr-
----------- - --------
(RIGHT OUTSIDE) l k

PATENT APPLICATION SERIAL NO.
U.S. DEPARTMENT OF COMMERCE

PATENT AND TRADEMARK OFFICE
FEE' RECORD SHEET
01/26/1999 HVILLARI 00000045 09232909

01 M201 380 .00 OP
PTO-1556
(5/87)
*U.S . GPO : 1998-433.214/80404

SERIAL NUMBER FILING DATE CLASS GROUP ART UNIT ATTORNEY DOCKET NO.
09/232,908 01/15/99 395 2756 150–061A
FRANK C . HUDETZ, LISLE,,IL ; PETER. R . HUDETZ, PLAINFIELD, IL,
rL
-a.
Q
**CONTINUING DOMESTIC DATA*********************/

VERIFIED THIS APPLN IS A DIV OF 08538,365 10/03/95
PROVISIONAL APPLIQAfiION NO . 60/000,442 06/20/95
**371 (NAT'L STAGE) DAT~ifi*********************

VERIFIED
oeI
**FOREIGN APPLICATIONS*******~+***
! VERIF I E D ~ f
I I, l
FOREIGN FILING LICENSE GRANTED 02/08/ .99 ***** SMALL ENTITY *****
Foreign Priority claimed q yes no 10 .11 STATE OR SHEETS TOTAL ~ I.I(gDEPENDENT
35 USC 119 (a-d) conditions met [dyes [g4So q MeWfter Allowance COUNTRY DRAWING CLAIMS i CLAIMS
Vey ified and Acknowledged gi"' y IL 3 11 1
ANTHONY R B KUME f~ ~( V 14 E,
I 14 SOUTH IN STREET
Ì
Lj
E SUITE 2 0
SAYVI E NY 11782
G t Zee.4 f4~ I I'
CA*Qi+ ~U t t~ i J
q~
a'tiV ~r' c ~f' ♦
Yom/ {P.. tl
YSTEM & METHOD FOR y~" - .C1 S A

ua R,i;MOTE COMPUTER err a, ~ Li)
r
r3'"
_
F=-
FILING FEE, E] All Fees

RECEIVED FEES : Authority has been given in Paper q 1 .18 Fees (Fi .r. ;~)
~~.
No . to charge/credit DEPOSIT ACCOUNT 1 .17 Fees ;Processing ext . of time)

$380 NO . for the following : q 1 .18 Fees (Issue)
q Other
q Credit

PTO/SB/05 (4/98)
Please type a plus sign (+) inside this box -~ - Approved for use through 09/30/2000 . OMB 0651-0032
Patent and Trademark Office : U .S . DEPARTMENT OF COMMERCE
O tO V nder the Pa erwork Reductio Act of 1995 no ersons are ed to re o d to a collection of information unless it dis la s a valid OMB control number.
1•-~ = cTT
=_ [ UTILITY Attorney Docket No. 150-061A

First Inventor or Application Identifle Frank C . Hudetz
PATENT APPLICATION i-
TitleSee 1 in Addendum
TRANSMITTAL
Only for new nonprovisional applications under37 C .F.R . § b)) Express Mail Label No . EG131043525US m
Assistant Commissioner for Patents
APPLICATION ELEMENTS
utility patent application contents.
See MPEP chapter 600 concerning
*Fee Transmittal Form (e.g ., PTO/SB/17)
7 ADDRESS TO : Box Patent Application
fmn nr- gri gni
1'
5. q Microfiche Computer Program (Appendix) Ur,
(Submit an original and a duplicate for fee processing)
6 . Nucleotide and/or Amino Acid Sequence Submission
2 . ~ Specification [Total Pages ] (if applicable, all necessary)
(preferred arrangement set forth below) 24
- Descriptive title of the Invention a . ~ Computer Readable Copy
- Cross References to Related Applications
- Statement Regarding Fed sponsored R & D
b. F Paper Copy (identical to computer copy)
- Reference to Microfiche Appendix C. Statement verifying identity of above copies

0
- Background of the Invention ACCOMPANYING APPLICATION PARTS
- Brief Summary of the Invention
7 .~ Assignment Papers (cover sheet & document(s))
- Brief Description of the Drawings (if filed)
B ~ 37 C .F .R .§3.73(b) Statement Power of
- Detailed Description (when there is an assignee) Attorney
- Claim(s)
9 .F--] English Translation Document (if applicable)
- Abstract of the Disclosure
Information Disclosure Copies of IDS
3 . X Drawing(s) (35 U .S .C. 113) [Total Sheets 3 '' 1 10 •1:1 Statement (IDS)/PTO-1449 OCitations
4 . Oath or Declaration [Total Pages ] 11 . FK] Preliminary Amendment
12 ® Return Receipt Postcard (MPEP 503)
a. q F1 Newly executed (original or copy) (Should be specifically itemized)
b X Copy from a prior application (37 C .F .R . § 1 .63(d)) • Small Entity
(for continuatiorVdlvisional with Box 16 completed) Statement filed i r prior application
13 . ~ Statement(s) ~
i q DELETION OF INVENTOR(S) (PTO/SB/09-12)
Status still proper and desired
desired
Signed statement attached deleting q Certified Copy of Priority Document(s)
inventor(s) named in the prior application, 4' q (if foreign priority is claimed)
see 37 C .F .R. §§ 1 .63(d)(2) and 1 .33(b) . 5. Other :
.'.: O :TE :FOR :I. EMS:1 :&:1af P ORD R :TOB £NTT O : O .A .' LL: N: r- .::
FEES,iA : MAEL.ENTT:LV STATEI4IENTLS~REL3UJREOi(37GFiRi,§1:~7fi
. .. . . . .. . .,FL:E . .. :EXCEPT: :i
. :1 .A :p
'iF N L GI
16 . If a CONTINUING APPLICATION, check appropriate box, and supply the requisite information below and in a preliminary amendment:
Continuation Divisional ElContinuation-in-part (CIP) of prior application No : 08/538,365
Prior application information : Examiner D . Pan Group/Art Unit: 2783
For CONTINUATION or DIVISIONAL APPS only : The entire disclosure of the prior application, from which an oath or declaration is supplied
under Box 4b, is considered a part of the disclosure of the accompanying continuation or divisional application and is hereby incorporated by
reference. The incorporation can only be relied upon when a portion has been inadvertently omitted from the submitted application parts.
17 . CORRESPONDENCE ADDRESS
0 Customer Number or Bar Code Labe I ; or 0 Correspondence address below

:(insert Customer No : or Attach'bar code label here
Name
Anthony R. Barkume
lAnthony R. Barkume, P .C.
Address
14 South Main_Street Suite 200
city Sa lle State NY Zip Code 11782

Country Telephone (516) 244-3503 Fax (516)244-7645
Name (PrinHType) An o . Barkume Registration No.(Aitorney/Agent) 33,831

Lsignature Date 1 — S —,I
Burden Hour Statement : is o s stimated to lake 0 .2 hours to complete . Time will vary depending upon the needs of the individual case . Any
comments on the amount of it u are required to complete this form should be sent to the Chief Information Officer, Patent and Trademark Office,
Washington, DC 20231 . DO NOT SEND FEES OR .COMPLETED FORMS TO THIS ADDRESS . SEND TO : Assistant Commissioner for Patents,
Box Patent Application, Washington, DC 20231.

PTO/SB/17 (2/98)
App- . r use through 9/3012000 . OMB 0651-0032
Patent and Traderrrd iK office: U .S . DEPARTMENT OF COMMERCE
Underthe Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid OMB control number.
Complete if Known
Application Number
FEE TRANSMITTAL Flung Date January 15, 1999
Patent fees are subject to annual revision on October 1.
These are the fees effective October 1, 1997. First Named Inventor Frank C . Hudetz
Small Entity payments must be supported by a smell entity statement,
otherwise large entity fees must be paid. See Forms PTO/SB/09-12. Examiner Name D . Pan
See 37 C.F.R. §§ 1.27 and 1.28. Group / Art Unit 2302
TOTAL AMOUNT OF PAYMENT ($) 380 .00 AttomeyDocketNo . 150-061A
METHOD OF PAYMENT (check one) FEE CALCULATION (continued)

L ADDITIONAL FEES
The Commissioner is hereby authorized to charge
1 ~ indicated tees and credit any over payments to: Large . Entity Small Entity
Fee
Fee Fee Fee Fee Description Fee Paid
Deposit Code ($) Code ($)
Account 105 130 205 65 Surcharge - late filing fee or oath
Number 0 .00
Deposit 127 50 227 25 Surcharge - late provisional filing fee or
Account cover sheet. 0 .00
Name
139 130 139 130 Non-English specification 0 .00
Charge Any Additional
Fee Required Under FJ Charge the Issue Fee Set in
37 C .F .R . §1 .18 atthe .Mailing 147 2,520 147 2,520 For filing a request for reexamination 0 .0
37 C.F.R. § § 1 .16 and 1 .17 of the Notice of Allowance pp
112112 920' 920' Examme~radionlication of SIR prior to
0 .00
2 Payment Enclosed :
M Money q Other 113 1,840' 113 1,840* Requesting publication of SIR after
Check Examiner action 0 .00
Order
115 110 _ 215 55 Extension for reply within first month 0 .00
FEE CALCULATION 116 400 216 200 Extension for reply within second month 0 .00
1 . BASIC FILING FEE 117 950 217 475 Extension for reply within third month 0 .00
Large Entity Small Entity 118 1,510 218 755 Extension for reply within fourth month 0 .00
Fee Fee Fee Fee Fee Description Fee Paid 128 2,060 228 1,030 Extension for reply within fifth month
Code ($) Code ($)
101 790 201 395 Utility filing fee 380.00 119 310 219 155 Notice of Appeal
106 330 206 165 Design filing fee 120 310 220 155 Filing a brief in support of an appeal 0 .00
107 540 207 270 Plant filing fee 121 270 221 135 Request for oral hearing 0 .00
108 790 208 395 Reissue fling fee 138 1,510 138 1,510 Petition to institute a public use proceeding 0 .00
114 150 214 75 Provisional filing fee 140 110 240 55 Petition to revive - unavoidable 0 .00
SUBTOTAL (1) ($) 380 .00 141 1,320 241 660 Petition to revive - unintentional 0 .00
2 . EXTRA CLAIM FEES 142 1,320 242 660 Utility issue fee (or reissue) 0 .00
Fee from 143 450 243 225 Design issue fee 0 .00
Total Claims 11
Independent
Extra Claims
-20 *' = 0= X
_ 3** =F_ __J X 39
0
below Fee Paid
--=
= 0~
144 670 244 335
122 130 122 130
Plant issue fee
Petitions to the Commissioner
0
0 .00
Claims
Multiple Dependent
-
=0
or number previously paid, if greater; For Reissues, see below
123
126
50 123
240 126
50
240
Petitions related to provisional applications
Submission of Information Disclosure Stmt
0 .00
Large Entity SmallEntity 0 ' 00
Fee Fee Fee Fee 581 40 581 40 Recording each patent assignment per
Fee Description
Code ($) Code ($) property (times number of properties) 0 .00
103 22 203 11 Claims in excess of 20 146 790 246 395 Filing a submission after final rejection
(37 CFR 1 .129(a)) 0 .00
102 82 202 41 Independent claims in excess of 3
149 790 249 395 For each additional invention to be
104 270 204 135 Multiple dependent claim, if not paid examined (37 CFR 1 .129(b)) 0 .00
109 82 209 41 ** Reissue independent claims
over original patent Other fee (specify) 0 .00
110 22 210 11 ** Reissue claims in excess of 20
and over original patent Other fee (specify) 0 .00
SUBTOTAL (2) ($) 0 .00 * Reduced by Basic Filing Fee Paid SUBTOTAL (3) ($) 0 . 00
SUBMITTED BY Complete (if applicable)

Typedor Reg . Number
Printed Name Anthori R. Barkume 33,831
Deposit Account
Signature Date User ID
Burden Hour Statement : T is luonVis estimated to take 0 .2 hours to complete . Time will vary depending upon the needs of the individual case . Any
comments on the amount of time you are required to complete this form should be sent to the Chief Information Officer, Patent and Trademark Office,
Washington, DC 20231 . DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS . SEND TO : Assistant Commissioner for Patents,
Washington, DC 20231.

Patent
Attorney-Docket-
/5-0 -061 A
5
SYSTEM. AND METHOD FOR USING; AN ORDINARY.
ARTICLE OF' COMMERCE TO ACCESS A . REMOTE COXPUTER.
Related Application Data

10 This application is
/ Application Serial Number 60\000,442, . filed on:June 20,.
1995, and entitled . "Method and .Appar~Ltus for Interfacing.
with .Remote Computers" (hereinafter, "our copending
application"), the disclosure of which is hereby
15 incorporated .by reference in its-entirety ..
Field of the Invention

;a This invention relates to computer communications
F_
generally, and more specifically to techniques for. giving
r' 20 users convenient access to information located on computer
networks such as the Internet .,
(
Background of the Invention
A computer network is. a set of computers (or "hosts")
25 which are able to communicate electronically .. In logical
terms, . the network can be viewed as a set of nodes or
"sites", with each .computer on the network being home for
one or more nodes . Generally speaking, each host. is
assigned a numeric address, which . the network uses to route
30 information to that particular host . To facilitate human
use of networks, . addresses are often given alphanumeric
codes (or "mnemonics"), which are easier for people.to
remember... For example, the numeric .address 200 .98 ..322 .56
may be assigned the mnemonic "sample .com.."
35 At the present . time, the world's most. important network
is the Internet . The Internet is a massive worldwide
collection of computer resources, connected.together in
network-fashion by a series . of communication protocols known
Y
as TCP/IP . Many sites on the Internet can be accessed in

accordance with popular standard protocols or formats such
as Gopher and Hypertext Transport Protocol ("HTTP") . These
sites act as remote servers, providing information to users'
5 computers (or "clients") in accordance with a particular
format or protocol . The client system (often an
individual's personal computer) must have the necessary
software to handle the server's particular protocol.
For example, sites set up in accordance with HTTP are
10 nicked-named "Web sites" . If a user wants to access Web
sites, she must have a. computer connected to the Internet
and equipped with software for communicating in accordance
with the HTTP protocol . Such software is often called a
"browser," because it allows users to browse (or, in the
15 parlance of the enthusiasts, "surf") from Web site to Web
site, much the way one might browse through a library . This
process is facilitated by the fact that most Web sites have
hypertext links to other Web sites, which the user can
activate by clicking a mouse on a highlighted portion of the
20 screen.
Typical.browser software also maintains a list of sites
the user has visited, which the user can recall using
commands such as "back" and "forward ." These commands,
coupled with the hypertext links between Web sites, give
25 users the sensation of "navigating" through a seemingly
infinite realm of information, which is popularly referred
to as "cyberspace" or the "World Wide Web ."
Users can also specify a Web site by manually typing in
the site's location as a Uniform Resource Locator ("URL").
3.0 The URL specifies the precise location of a particular
resource, and has three fields:
<resource type> <domain name> <path>
Domain name, as explained above, is the alphanumeric network
address of the host on which a particular resource resides.
35,. The "path" is the specific directory and file on the host -
where a resource is stored . A typical URL is

http ://bongo .cc .utexas .edu/"neural/cwsapps .html.
For example, the command "Go <URL>" would cause browser
software to request the information residing at the site
5 specified by the URL . This is called "pointing" the browser
to the desired Web site . The Web server at the designated
URL processes the browser's request by transferring a copy
of the file specified by the URL to,the user's local host
computer . The transferred file includes embedded commands
10 in the hypertext markup language ("HTML"), which cause the
client's browser software to display and handle the
transferred file in a desired manner ..
Cyberspace is not limited to the World Wide Web or the
Internet . Massive amounts of information are also available
15 on networks maintained by on-line service providers under
the service marks CompuServe, Prodigy and America Online,
for example . Users typically access these on-line services
via telephone modem connection . To the end user, these
networks appear to be :,a series of sites or locations or
20 "rooms" offering various types of information . The.
addresses for these locations are assigned by the on-line
service providers . Navigation .among these locations is
handled by proprietary client software, which runs on the
user's personal computer.
25 Many users learn of resources on the Internet or a
proprietary on-line service through magazine articles and
advertisements . These articles and advertisements include
the necessary URL or other network address to access the
desired site . Many publications compile lists of sites they
30 deem particularly worthwhile . When a user sees a listing
for a site which looks interesting, he can manually enter
the published URL or other mnemonic address into his browser
or other software, and access the site.
As explained in our copending application, we realized
35 : that published computer addresses -- whether URLs or
otherwise -- were difficult for people to use because they
have to be tediously entered into their computers . A good
example of an address which may be difficult to enter is the
University of Texas address cited above . . The problem is
particularly acute for persons with a visual or physical
5 disability.
Another problem using the Internet, we realized, is
that many users have trouble even finding URLs or other
network addresses for desired sites such as Web pages.
Accordingly, Web site sponsors publish their Web site URLs
10 in print advertising and .on packaging . The difficulty with
this approach however is that the URLs are still long, and
cumbersome to remember and enter into a computer.
In our copending application, we proposed to resolve
these problems by allowing people to access published
15 locations without having to manually enter the published
address . In accordance with one embodiment of the
invention, the mnemonic address or verbal description of a
network location is published along with the location's
numeric address in bar code format . The user's computer is
20 equipped with a bar code reader and browser software . The
bar code reader is suitably interfaced to the computer's
browser software to allow bar code input to be accepted as
address information . When the user sees an interesting
published address, he scans the associated bar code using
25 the bar code reader, thereby loading the desired numeric
address into the browser . The browser then accesses the Web
or other site corresponding to that numeric address.
We are finding several problems with this and other
approaches that have been tried . First, some URLs and other
30 network addresses contain upwards of 20-30 characters, and
therefore require very long bar code symbols, which can
clutter advertising and packages, and may not be practical
from either anesthetic or technical.perspective . - Second,
placing URLs on printed material (whether or not in bar code
35 format) requires manufacturers to redesign products,
packaging and/or advertisements, and many manufacturers may
rt
be reluctant to do this . Third, pervious proposal, if the
network address is changed, the . .package needs to be
redesigned, and packages already in the marketplace will
have incorrect address information.
5
Summary of the Invention
The present invention offers a better way for consumers
and others to access resources on remote comp~eSrs~~
p
particularly Web sites . In accordance with the invention,
10 the dissemination and entry of network addresses is
accomplished by means of existing identification standards
(e . g ., bar codes) found on ordinary products like soup or
soda, in conjunction with.a centralized database of network
locations.
15 One embodiment of the invention is a system in which a
bar code or other indicia is associated with a product or
other article of commerce . The indicia encodes (in human
and/or machine readable form) a UPC or other identification
number, which is associated with the article in accordance
20 with an extrinsic standard . A computer database is provided
that relates standard UPC codes to Internet URLs or other
network addresses . To access a network resource relating to
a particular product, the user swipes, a bar code reader
across the product's UPC symbol . . The database then retrieves
a 25 the URL corresponding to the UPC product data . This
location information is then used to access the desired
5 ~---,resource on the network . -
The invention offers a number of important advantages.
First, because product identification information is already
30 widely disseminated using standardized and pre-assigned
codes, the invention eliminates the need for separately
disseminating domain names or other network location data.
Further, the invention can be-implemented without - requiring
manufactures to redesign packaging or other articles, or to
35^ develop special bar code indicia . This overcomes a Catch-22
often facing new technologies : manufacturers will not
participate until there is widespread consumer interest;
consumers are not interested until there is widespread
manufacturer participation . With the invention, mass
participation by manufacturers in the technology is
5 automatic.
Second, the invention allows practical use of bar codes
and other machine readable media for entry of network
location data . As-we realized, encoding URL data in bar
code format is not practical because the resulting bar codes
10 are too long . By using existing UPC product codes in
combination with the database of network locations, users
have the benefit of bar code or comparable technology for
entering network location data . Thus, the necessity of
manually entering the address is eliminated . Users can
15 access a desired site by simply using a bar code reader ..
The UPC can also be printed on removable stickers or
detachable cards, allowing users to readily clip the
stickers and cards for future reference . This is
particularly useful when the user reads about the location
20 at a time when he does not have access to a computer.
Third, the invention overcomes the problems encountered
when network addresses are changed . Network addresses can
change as companies reorganize their'on-line marketing
strategies . Also, Internet addresses are assigned by an
25 independent third party -- InterNic -- which may in some
cases have the authority to unilaterally change a company's
address . Finally, unforeseen trademark conflicts (involving
for example Internet domain names) may require adoption of
new addresses . With the invention, a new address assignment
30 requires only that the database of addresses be updated.
Products, packaging, advertisements and the like bearing the
standard identification codes need not be redesigned.
Brief Description of the Drawings .
FIG . 1 is a block diagram of a computerized system for

interfacing with a computer network in accordance with the
5 invention.
FIG . 2 is a perspective view of the local host computer
shown in FIG . 1.
FIG . 3 is an enlarged view of the article of commerce
shown in FIG. .1, illustrating in detail the UPC symbol
10 thereupon.
FIG . 4 is a tabular view of the database shown in FIG.
1.
FIG . 5 is a flow chart illustrating the operation of
the system of FIG . 1 in accordance with the invention.
15 FIG . 6 is an idealized view of the CRT screen of the
Tu client system of FIG . 1 displaying information in accordance

with the invention.
a ?
FIG . 7 is a perspective view of articles of commerce
J.
i-i which can be used in accordance with the invention to access
17 remote computers .~ 7
Detailed Description of the Preferred Embodiment

3
1. Overview
FIG . 1 is a block diagram illustrating one application
p!
25 of the invention, namely the use of an ordinary article of
commerce to access sites on the Internet's World Wide Web.
As explained below, this embodiment of the invention allows
a person who .desires Internet resources concerning a
particular product to access those resources using the
30 product's UPC symbol . The data encoded on the UPC symbol
can be entered manually or (for greater convenience) using a
bar code reader ..
Referring to FIG . 1, the Internet 20, illustrated here
in generalized format, includes a service provider 22 and
35 two remote nodes 24 and 26 . In this case, service provider
"f
22 is a local Internet access . provider . Service provider

could also be an online service provider, such as America,
OnLine® , Compuservee , MicrosoftO Network and Prodigys . In
such cases, local host 28 need not be on Internet 20 -- that
5 is, need not have a network address.
An end-user (not shown) accesses Internet 20 using
local host 28, which in this case is an IBM compatible
personal computer including a CPU 30, a random access memory
32 and an address/data bus 34 by operatively connecting CPU
10 30 and memory 32 . Unless otherwise specified, the term
"memory" herein includes any storage device, including RAM,-
ROM, tape or disk drives (or collections or networks of
tape or disk drives), and any other device for storing
information . A modem 36 and I/O port 38 are attached to
15 bus 34 by a suitable interfaces 40 and 42, respectively . An
input device 44 is connected to bus 34 via I/O port 38.
Input device 44 is a commercially available wand-style bar'
code reader reads a Uniform Product Code ("UPC") bar code
symbol 46 affixed to an article of commerce .48.
20 Alternatively, input device 44 could be a card reader,
optical character or voice recognition system, touch screen,.
scanner, pen, keyboard or other known input device.
Local host computer 28 need not be a personal computer,
and could for example be a mainframe or minicomputer having
az. 25 a terminal by which the user could enter and receive data ..
In that arrangement, input device .44 would be attached to
the terminal.
Modem 36 is adopted for electronic communication via a
suitable telephone link 50 with service provider 22.
30 Computer 28 functions as an Internet host because it is
connected to--service provider 22 using Point to Point
Protocol ("PPP") via telephone link 50 . Other
telecommunications channels may, be used, such as ISDN or a
connection which incorporates a third party intermediary
35 network such as TymNet,sm- Alternatively, local host 28
could be connected directly to Internet 20, as is likely to

be the case where " local host 28 is a larger computer, such

as mainframe . FIG . 2 offers a perspective view of local
host 28 and article of commerce 48 and also illustrates a
CRT monitor 52 and keyboard 54 suitably coupled to bus 34.
5 In this illustration, local host 28 is used to access
Internet resources (or "Web sites") on remote nodes 24 and
26, which are available using the HTTP protocol . HTTP uses
a client-server architecture, with remote nodes 24 and 26
acting as servers, and local host 28 acting as a client.
10 Local host is equipped with Netscape Navigator brand Web
browser software which enables it to function as an HTTP
client.
Remote notes 24 and 26 have pre-assigned network
locations (or "domain names"), and desired resources (such
15 as a particular Web site) are located in specific
directories and files (or "paths") resident on a remote.
nodes 26 and 28 .. The precise locations of those resources
are specified using URL, which, as explained above, includes
three fields : <resource type> <domain name> <path> . To
20 access resources of a particular remote node 24 or 26, local
host 28 requests those resources from Internet 20 using the
appropriate URL . Thus, the URL functions as a more precise
kind of network address than a domain name.
The URL required is often supplied by the user . Users
25 learn about the existence of a desired resource (and its
corresponding ULR) through a variety of means, including
publication in a printed advertisement . In current
practice, the URL acquired from a printed source must be
entered using a keyboard . As explained above, this can be
30 tedious . Moreover, in many cases, users may have trouble
finding references to desired Web pages.
2 . Article of Commerce
In accordance with the invention, access to desired
resources on remote nodes 24 and 26 is achieved using an
35 : article of commerce 48 . The term "article of commerce"
includes tangible things that are sold or moved through
Y
commerce, such as consumer products, packaging, and printed
media including books, newspapers, magazines, stickers,
fliers, cards, tags and labels . Article 48 bears a standard
5 UPC bar code symbol or indicia 46 . Symbol 46 is shown in
greater detail in FIG . 3, and may be affixed to article 48
in any suitable manner, including printing directly on the
article or its packaging, or applied to labels or tags
attached or otherwise affixed to the article . In accordance
10 with UPC standards, symbol . 46 encodes as ten-digit number
(the "product identification number") . As shown in FIG . 3,
the product identification number encoded in UPC symbol 46
consists of two five-digit fields, A and B . Field A is a
unique, pre-assigned number signifying a particular
15 manufacturer . Field B is a number identifying one of the
manufacturer's products . In the United States, UPC product
identification numbers are assigned by the Uniform Code
Council, Inc.
UPC symbol 46 provides a machine-readable number that
20 uniquely identifies a particular product and its
manufacturer . This is useful at the retail point-of-sale,
where purchase of a particular item is recorded by scanning
the item's bar code, symbol.
There are numerous other formats and systems for
25 assigning product identification numbers to articles of
commerce . For example, the International Article Numbering
Association ("EAN") assigns its own number to products
outside of the U .S . and Canada, and uses a different
symbology than used with the UPC . Product identification
30 codes for books are provided by the International Standard
Book Numbering System ("ISBN") and are encoded using a
symbology specified by that organization . Likewise,
magazines and serial publications are assigned product
Identification codes by the International Standard Serial
35 Numbering System ("ISSN") .

rt
These numbering systems share at least three
characteristics . First, for purposes of this invention, the
identification numbers may be assigned in accordance with an
"extrinsic" standard . By extrinsic, it is meant that the
5 assignment of numbers is made a by group or association for
the purpose of identifying articles of commerce . It is
likely that new types of identification numbers will arise
in the future, as will new organizations for assigning and
administering those numbers, and the present invention
10 contemplates use of both existing and future extrinsic
identification numbers and formats.
Second, the identification numbers may have recognized
significance as numbers identifying articles of commerce.
The level of recognition may be among the general public, or
15 a defined subset, . such as a particular industry or
occupation.
Third, the identification numbers may be encoded in a
standard, machine readable format -- namely, bar codes.
Other machine readable formats may also be used for this
20 purpose, including magnetic stripes or optical character
recognition ("OCR"), and the present invention could be
practiced with product identification numbers encoded in
those formats as well.
3 . URL/UPC Database
25 In accordance with the invention, service provider 22
includes a relational database 60, which is shown in more
detail in FIG . 4 . Database 60 includes records 62-68, which
are accessible using a suitable database management.system
software .. Each record 62-68 of database 60 contains four
30 fields 70-76 . Fields 70 and 72 contain a UPC product
identification number, as explained below . Field 74 holds a
URL suitable for locating a .resource on the Internet.
Depending on the application, other network addresses --
either numeric or mnemonic, physical or virtual -- may be
35 used . Field 76 holds a narrative description of the
11
resource addressed in field 74 . This particular arrangement
of fields is . but one illustration of how the invention may
be practiced . For example, additional fields could be
provided, or the UPC product identification number could be
5 held in a single field.
Each record 62-68 of database 60 associates a UPC
product identification number (contained in fields 70 and
72) with a particular Internet URL and narrative description
(contained in fields 74 and 76, respectively) . The
10 association is based on selected criteria . In this case,
the criteria .is the existence of a Web resource sponsored by
the manufacturer of the product identified by the UPC number
in fields 70 and 72 . (If no such resource exists, then the
particular product identifier can be omitted from database
15 60) . Other criteria can be used . For example, the
association could be based on the existence of a Web site
simply referring to or relating to the product.
As stated, fields 70 and 72 contain a UPC product
identification number . Field 70 contains the first five
20 digits of the product identification number (field A of FIG.
3) . As explained above, these digits uniquely identify the
product's manufacturer . Field 72 contains the second five
digits of the product identification number (field B of FIG.
3) . These digits identify the manufacturer's particular
25 product . In some cases, a manufacturer may have many
products and only one Web site or other Internet resource.
In that case, field 72 may be left blank, as shown in cell
78 of record 68 . When field 72 is left blank, database 60
associates the Web resource indicated in field 74 with any
30 product identification number whose first five digits match
the manufacturer number specified in field 70.
Database 60 itself is accessible via service provider
22, which is-equipped with Web server software such as
provided by Netscape .Communications, Inc . The server
35 software provides access to an HTML document (the "Query-
Page") resident on service provider 22 at a predetermined

URL . The Query Page, when displayed on CRT 52 by local host

28 using a forms-capable browser allows the user to enter a
query in the form of a .UPC product identification number.
Alternatively, database 60 could be resident on local host
5 28 or another remote computer 24 or 26 . The Web server at
service provider 22 may have a predetermined URL location.
Browser software resident in local host computer 28 may be
configured to automatically request that predetermined URL
location when the browser software is initially loaded.
10 Database 60 may be incorporated with a database or
search engine of Web sites or other Internet resources (such
as the Yahoo or Lycos databases) . In that case, the Query
Page may give the user the option of entering a UPC number
or an alternative search term, such as a portion of the URL
15 or the topic to which the desired resource pertains.
Also, database 60 may be divided into one or more
tables, which may be distributed over more than one
computer . For example, a first table may contain records
associating UPC numbers with names of products or
20 manufacturers . A second table associates products and/ .or
manufacturer names with Internet addresses . Thus, the
process of using the UPC number to locate a network address
may involve one or more steps . For example, database 60
might determine the name of a product corresponding to a UPC
25 number using a first table, and then determine network
addresses corresponding to that product name using a second
table . Even though multiple steps are involved, the UPC
number is still "associated" in computer memory with the
network address for purposes of the invention.
30
4. op eration of the Invention
Suppose-a user is interested in Internet resources
concerning a particular type of product . In accordance with
the invention, the user can access those resources by taking
35 an ordinary specimen of the product -- a can of soup for
1 13
f d
•r
example — and entering all or part of the product's UPC

product.identification number 46 . Database 60 uses the
entered product identification number to look-up the
associated URL, which is returned to the user in the form of
5 a HTML document.
This operation is illustrated in FIG . 5 .. At ablock
80, the user loads his browser software onto local host
computer 28 . The browser software is programmed . to.
automatically load the "Query Page" which provides access to
10 database 60 . The user in this case is a human, but
alternatively a program (or "process") running on local host
28 could be the "user" in the sense that it is the process
which is requesting information from the Internet and
supplying the UPC number.
15 At a block 82, the Query Page is transmitted to local
host computer 28 in the form of an HTML document . Browser
software resident on local host 28 displays the Query Page ,
on CRT screen 52 . At block 84, the user (or process) enters
the first five or all ten digits of the UPC product
20 identification number encoded by symbol 46 . Because the UPC
product identification number is printed in both machine-
and human-readable format (See FIG . 3), this may be done by
manual entry using keyboard, voice recognition system or
other input device . More preferably, however, entry is
25 accomplished by scanning UPC symbol 46 affixed to article
48 . Input device 44 reads UPC symbol 46, and generates an
ASCII character string which is,read by CPU 30 via I/O port
38 . If the UPC number is scanned, then all 10 digits .will
generally be entered . The UPC product identification number
30 is transmitted to the Web server resident on local service
provider 22, which at a block 86 looks up the entered UPC
number in database 60 ..
At block-88, database 60 retrieves all records 62-68
having UPC fields 70 and 72 that match the product
35 identification number entered by the user . The records are
conveyed to the user in the form of an HTML document . The
criteria at block T 88 for whether UPC fields 70 and 72
"match" the product identification number may be based on•a
"query by example" approach . For _example, suppose at block
84 the user only enters the manufacturer portion (e .g.
5 "31251 " ) of a product identification number . It is assumed
in this case that the user is interested in any record 62-68
having a field 70 that matches the entered manufacturer
portion . (Recall that the database 60 stores the UPC number
in two fields -- field 70 for the first five digits
10 (corresponding to manufacturer) and field 72 for the second
five digits (corresponding to manufacturer's product)) ..
Thus, at block 88, records 61, 64 and 65 are returned to the
user, because field 70 in each of those records contains
"31251 ."
15 If the user entered all ten digits of a UPC product
identification number(e .a ., "31251-00302"), then only
records whose fields 70 and .72 matched 11 31251" and "00302,"
respectively, would be retrieved. (In this case, that would
be record 64) . If all ten UPC digits are entered, and no
20 exact match is found, database 60 may be programmed to
retrieve records (if any) where at least the manufacturer
portion (that is, first five digits) matches field 70.
At block 90, browser software on local host computer 28
displays records retrieved at block 8 8, on CRT 52 . The
25 records are returned in an HTML document, which is displayed
by . the browser in a screen format 94, as illustrated in FIG.
6 . In this example, records 62, 64 and 66 have been.
retrieved . Screen format 94 displays data from each record
in a separate rows 96, 98 and .100, respectively . If no
30 matching records are found at block 88, a message such as
"no records found" may be returned instead.
Text from description field .76 of each of records 62,
64 and 66 is displayed as hypertext links 102, 104 and 106,
respectively . . Link 102 is associated with the URL of record
35 62, link 104 with the URL of record 64, and link 106 with
the URL of record 66 .. When the user selects one of links
15
Y
102-106 (by mouse click or otherwise), the browser software

loads the URL associated with the selected link to access
the resource at the location specified by that URL.
5 . Alternative Embodiments
5
The foregoing embodiment .is just one example of the
present invention . Many alternatives are possible ..
Other Networks and Protocols . . While the present
invention is illustrated with respect to a system for
10 accessing the Internet's World Wide Web, it could.be
practiced using other Internet . protocols (such as Gopher) or
other types of wide area networks and systems, including
those offered by "on-line service" providers such as America
OnLine* of Fairfax, Virginia or CompuServe* of Columbus,
15 Ohio or the Microsoft* Network of Redmond, Washington.
~14 In those cases, database 60 could be resident on the
FL
k on-line service provider's computer . The network address ,
ri information contained in database 60 could be either
Internet URLs, or locations within the on-line service
20 provider's environment . In this case, the protocol used to
communicate between local host 28 and service provider 22
need not be HTTP or other Internet protocol . However,
service provider 22 can provide a gateway to Internet 20,
and access to a desired network location on the Internet can
V 25 be .made using a URL retrieved from database 60.
Controlled Access . Database 60 need not be publicly
accessible . Access to database 60 can be limited either by
placing database 60 on a proprietary network, or, if placed
on an open network, using a password or digital signature
30 system to permit access only to authorized persons .. Also,
records 62-68 may be selectively accessible . For example,.
each record can contain an additional field indicating
whether the URL contained in field 74 points to network
location containing material inappropriate for children . In
35 that case, database 60 can be programmed to return URL at
block 88 only if the user has supplied a proper password .
Automatic Jump ing to Desired Location . In the
disclosed embodiment, the URL associated with a selected UPC
product identification code is returned to the end .user in
an HTML document at-block 88 of FIG . 5 . The user can then
5 hypertext link to the site corresponding to the URL.
Alternatively, instead of displaying query results at step
90 (of FIG . 5), browser software in local host can
automatically load the retrieved URL and point the user to
the site corresponding to that URL . An additional field in
10 database 60 can provide a.code indicating whether this
feature should be enabled or disabled for a particular URL.
Identification Numbers and Svmbologies . The invention
can be practiced using standard identification numbers-and
symbologies other than UPC numbers and formats . For
15 example, EAN, ISBN and ISSN numbers and formats discussed
above could be used.
Articles of Commerce .. As shown in FIG . 7, product
identification numbers -- whether bar coded or otherwise
may be placed all types of items, such as a consumer product
20 102, newspaper 104 or book 106, as well as coupons, fliers,
cards and advertisements (not illustrated) . For example, by
placing a product's UPC code on an advertisement for the
product, the advertiser could, in accordance with the
invention, facilitate access to Internet resources
25 concerning the product.
Machine Reading Technology . In lieu of a bar coding,
the invention could be practiced with product identification
information that is encoded using other technologies . For
example, product identification information could be encoded
30 on a magnetic strip affixed to a product, card or other
article . In place of. wand, local host computer could use a
magnetic card .reader . Alternatively, the number could.
simply be printed in human-readable format, and. an optional
optical character recognition system could be used to
35 facilitate entry .

Direct Coding of Address . In place of a standard UPC

symbol, bar code technology could be used to encode the
actual mnemonic or numeric (IP) network address in machine-
readable format . While this arrangement does not achieve al
5 the advantages of the invention, it . allows the user to
easily enter desired address information using a bar-code
reader instead of manually typing the address
3 r,
VJ
F
3I~,

We claim:
1 . A system for usi g an article of commerce to access a

remote computer, comp ising:
(a) a machine-rea able indicia associated with the
article of commerce, s id indicia encoding at least one of a
5 plurality of identifica ion numbers, said encoded
identification number c rresponding-to the article in
accordance with an extr.' sic standard;
(b) input means for generating a query signal
corresponding to said en oded identification number;
10 (c) a database con aining a plurality of network
addresses and said plural i ty of identification numbers, each.
of said identification n ers being associated with at
least one of said .plurali y of network addresses ; said
database being responsive to said query signal for providing
15 one of said network addre ses which is associated with said
encoded identification.n ;•~
(d) a local host ada ted or network communication;
and .
(e) a first network ontai in a plurality of nodes,
20 each having an assigned net ork ress ; said network being
operatively coupled-to said datab se for allowing
communication between said ocal host and that one of said
nodes whose assigned networ address corresponds to the
network address provided by aid database.
2. The system of clai 1 where said machine-readable

indicia is a bar code, and w erein said input means includes
a bar code reader.
3. The system of claim 2 where said. identification

number is at least a portion f a Uniform Product Code.
4.The system of claim wherein said indicia is both

machine- and human-readable, a Ad wherein said input means ,
19

includes a keyboard f manually entering said

identification number
5 .. The system claim l wherein said local host is a

single-user computer.
6. The system o+ E claim 1 wherein said local host is a

l
multi-user computer wi l:h a plurality of user terminals.
7. The system o: .claim 1 wherein said local host

computer is a node on aid network having a network address.
8. The system o: cTa 1 further comprising a second

network, wherein said.: oc ost computer is connected to
said second network, si id fno d network including a service
provider computer that j is a on said first network.
9. The. system o: claim 8 wherein said database is

resident on said seconi network.
10. The system o claim 1 wherein said database is

resident on said local ost.
11. The system of claim 1 wherein said database is

resident on one of said nodes that is remote from said local
host .
12. An apparatus for using an arti a of commerce to

generate the network address of a comp er on a network,
comprising :.
(a) reader means for en a g an output signal
5 corresponding to an article de ification number which is
used to identify the arti a commerce in accordance with
a standard;
(b) a database hav n pl alit identification
numbers including said icle identification number, and a
10 plurality of network ddresses, and associating each of said
identification n rs with at least one of said network
addresses ; and
20

(c) control, means responsive to said o ut t signal and

operatively coupled to said database for re giving from .
15 said database at . least.one of those of said etwork
addresses which correspond .to said article dentification
number .
13. The apparatus of claim 12 said

identification numbers are Uniform Codes.
14. The apparatus of claim .12 said network

addresses are Uniform Resource Loca
15. The apparatus of claim further comprising a

local host and a remote host , a adapted-for network
communication, wherein sa d rea means is resident on said
local host, and .said d abase i sident on said remote
5 host . i
16. A databa ercompris g:

first comput r memory ntain g a plurality
identification n ers bo a by articl erce, said
identification n ers u d to identify articles of
5 commerce;
second,computer me ory containing a plurality of
network addresses corr sponding to remote information
resources relating to articles of commerce, said resources
being accessible via a network ; and
10 means for assn iating each of said plurality of
identification .n ers in .said first memory with at least
one of said netwq k addresses in said second memory.
17. The tabase of claim 15 wherein said database is

a relational . tabase, and said first memory is a first
field within 2tid .relational database, and second memory is
a second fi d in said relational database ..
18. a database of- claim 15 wherein said first and

second m ories are random .access memory .:
21

19 . . The database of claim 15 wherein s id first and

second memories are secondary storage.
20. The database of claim 15 wher.ei said.

identification numbers are Uniform Produ Codes ..
21. The database of claim 15 wher in said network.

addresses are Uniform Resource Locator
22. A method for generating th#_ address of anode on a

network, comprising the steps of:
(a) associating in computer emory at least a portion
of an identification number with \node's network address;
5 said identification number ha g recognized significance as
a. number identifying an art'cl of commerce.

n (b) providing an art i cle o commerce bearing an indicia
ru on which said identific ion n er is encoded;
(c) reading at 1 ast p rtion of said identification
_ :- 10 number from said ind ia ; n .
(d) retrievin from s i computer memory the network
address associated ere n wi said product id i tification
number.
23 . The me od c ording to claim 22 wherein said

3=
identification n e s a Uniform Product. Code.
S
24 .. The metho according to claim 22 where said

network addressis a. Uniform . Resource Locator .
25 . The method according to claim 22 wherein said

indicia is encocYed in machine-readable format.
26 .. The ethod according to claim 22 where said

indicia is en oded in human-readable format ...
27 . T method according to claim 22. wherein said step

of reading is , performed using a bar code reader . ,
22

28. The method according to claim 2 wherein said step

of reading is performed by a human readi q said .indicia, .and
entering said identification number usi q a keyboard._
29. The method according to, cl m 22 wherein.said

5 computer memory includes a database having one or more
tables containing said identifica on number and said
network address:..
30 .. The method acc rdi to claim : 29 wherein said

tables are distribute over plurality of computers ..
10 31.. The method acco in to claim.2 wherein said

tables are resident on a single pu er ..
32 .. A.method.fo disseminating network addresses using

articles of commerce . comprising the steps.of.
(a) gen'p_~ti a.number corresponding to a network
15 address ;
(b) enc ing the addres4es on.a machine readable

indicia ;: and
(b) pl cing said.indicia .on.the e3Merior surface of an
article of ommerce ..
23

Ti_Ei'1'sLiL; UfII- i
V !=
21 L OG1 C."
A, system and method for usinq identification Oadees

found on ordinary'artioies :-'of commerce to access remote
Computer's on a network . I.h aaoardanco with one embodiment
S of the invention # a computer is provided' having a dataabeas a
that ;ralates Unifdrm :.ProduOt Cede (' UpC*) numbers to
Internet network .addresses (or "URLs") . To acaeas an

Internet rr spilroa relating : We e Parti ular pre4ucst, a user
enters ' . the prOduot's : UFC : :sya+dbol manually, by sui .pinq a bar
10. code ra'adear over the :. HIPC s
ol, or vial other suitable input
means, . . .The datsbase .' reRtri :ev+as the URL -dorro ponding to . -the
UPC cod* . This oca ion ~hfar-motion is then : .used to -access
the de's'ired resource, .
24

SENT BY :MCBRIDE BAKER &C 9 — 29 — 95 :12 :45PM 350- 17089835773 ;# 2
'f
Pssa I of 1
y, /~~~~
McBr
McBride Baker & Calm
Our Rderence: 75353-00006
UNPTED STATES PATENT AND TRADEMARK OFFICE

DECLARATION, AND POWER OF ATTORNEY
As a below named inventor, I hmby declare that
My residence, post o$cs sddrw and cidrenship are as dated below nod to sty mute.
I baliams I am the original, first and sole inventor (if only one name is listed balsa) or an original, first and
joint inventor (if plural names arc listed below) of the subject matter which is claimed sad for which a patent is
sought on the invention entitled:
Svetsm and Method for Usln: a laE i m Article of Commerce to Accts a Remote Camnuter
('~T tba specification of which (check only one item below):
[ :] is attached hereto.
] ;~ (] was Sled as United States application Serial No . on and was amended on or

3 _. thmIIgh if applicable).
i
aa [] was filed as PCT international application Number on and was amended
under PCT Articcia 19 an lifaPP a1
~. I haareby state that I have reviewed and undastaad the contents of the sbow ideatiSed goWlesticm,
including the claims, as amamdad by any amendment refa=ed to above. I Acknowledge the duty to disclose
infotmatica which is material to the mmminstion of this application in award=@ with Title 37, Code of Federal
Reputations, 41 .56(&).
9F
c
I hereby claim facaip priority benedts under Title 35, United States Code, 4119 of any Ersigtr
T spplicad*s) fi3r patent or inventor's certificate a of nay PCT lntermdortat appliead*$) desigdadnt at I" one
oomo y other to the fished Stites of America listed below sad have also identified below aw Aga 4011cation
for patent cr inventoes aatiiloato or any PCT intrsaationd appHw ions) deal gnadag at least am country other than
the United awn of Ameria filed by me an the am suhnjed matter having a filing daft betters that o[the
application oa wench priority is claimed:
Priority Chimed: [ ] Ya H No
N4 .
Prior FandgplPCT Applieaticn(a) and aw Priority Claims Under 35 U .S.C. 4119:
(Plumber) (Couatr'y) (DayftANTr Filed)
l hereby claim this bsaaSt tmdw Theresa 3S, United States Code, 4110 of any United States app9c tion(s) cc
PCT iatemadoael noliadon(s) designating the United States of America tided below and, lnsa6r es the lowed
mater of each of the cldmd of this applioation is not disclosed in tea prior &pplicadoo(s) is the mamsr provided by
the first paragraph of TiW 33, United States Code, 4112, I ubwwiedp the duty to disclose m a1 urial khenstioa as
defined in Title 37, Code of Fedanl Regulations, 41 .36(&) which F, 9 9 re 1 between the filing date of The prior
application and the aadoesl or PCT International filitg date of this application :

SAT BY :MCBRIDE BAKER &C 9-29-95 ;12 : 48PM 350- 17089835173 ;# 3

1
-T
nVia2
prior U. S. Awlication(x) or PCT IutcutioaW APPl Icadon(s) WWI 00 U.B. 1br Budh Under 35 U S0
1120 ,
60!000.442 dune 20.144' Pendinw

(Application S .N.) (Filigo Data) (Status : patW4 pendiu& abuWavad)
POWER OF ArrORNZY:
I hereby appoint Andrew P- Basile, Jr. OW& No . 33A32) as my attorney, with fill power of substitution.
to pnowu this application and to tracmd all business is On United 31tas Pabst =0 Mcnark Coke 000mnewated
tharnvith.
Md all cormqa4wce to Andrew IL Basile

McBride Baw 0 Cdu
SW W. MWEVA Suit* 4000
Cbkm% m1wil 60661
Tielaphout inquiries may be directed to Andrew R . BesiW at (312) 715-5743 or buileonbc-oom (email).
DECLURRANTENOON.-
I but, declare that all dwazents tradarbeau of my own kwMWV am taw and *a all statuawAs
made an imacmation and Ndd we babrad to be true; and 101how that tivm sWomente we made with the
knowledge that willfhl Ddle shoments and to like so made am punishable by due at SpriammneW4 or bod:6 under
11001 of 7% 18 of the United States Q4 and that such =Rd fWas donnouts may jeopudwo the validity of tba
application n or say pateal bloomed thereon.
Sols or First Inventor

Fall Nam*: Frank C. Hudft
Citizenship : USA
RaWwor 22 41 34da4m Drive, LAW . Mats 60532
Pu tt Coke Mdrw 2241 Edgebroolm Drive, U" Wwhi 60532
X Iavemtoe!s 8ivadMre
42 gta1 - — Datc
Sawcovid Thventar
Full Nona Pdw L Hudetz
Citizenship USA
RAMAMMUC 34903 Pine Cag y IAWN PlawAdd, Illinois 60514
Past OdkeAdchavc 24905 PQ Cam lAw; PWWBWQ laNds 60344

Practitioner's Docket No . 75353-00-006 PATENT
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
In re application of Hudetz, Frank C . ; Hudetz, Peter R.

Application No . : 08/538,365 Group No . : 2302
Filed: 10/03/95 Examiner : D . Pan
For: SYSTEM AND METHOD FOR USING AN ORDINARY ARTICLE OF
COMMERCE TO ACCESS A REMOTE COMPUTER

Washington, D .C . 20231
POWER OF ATTORNEY BY ASSIGNEE OF ENTIRE INTEREST

(REVOCATION OF PRIOR POWERS)
As assignee of record of the entire interest of the above identified application,
REVOCATION OF PRIOR POWERS OF ATTORNEY
all powers of attorney previously given are hereby revoked and
NEW POWER OF ATTORNEY
the following practitioner is hereby appointed to prosecute and transact all business in the Patent and
Trademark Office connected therewith.
Anthony R . Barkzune, Registration No . 33,831
SEND CORRESPONDENCE TO: DIRECT TELEPHONE CALLS TO:
Anthony R .-Barkume, Esq. Anthony R . Barkume

Anthony R . Barkume, P . C. (516) 244-3503
14 South Main Street
Suite 200
Sayville, NY 11782
(Power of Attorney by Assignee of Entire Interest page 1 of 3)

ASSIGNEE STATEMENT
Attached to this power is a "STATEMENT UNDER 37 C .F .R. 3 .73(b) ."
Respectfully submitted;
NeoMedia Technologies, Inc

2201 Second Street
Suite 600
For rs, FL- 33901
Date By:
Robert T . " Durst, Jr.

Executive Vice President and Chief Technology. Officer
Q
S0 1-1
L El."I
Tu
0.-1
531
_0
r7-
0.
(Power of Attorney by Assignee of Entire Interest—page 2 of 3)

Addendum
System S& Method for Using an Ordinary Article of Commerce to Access a Remote
Computer

d N ^} REMOTE
I NODE FIG .1
S ao
6o DATA-
CE REMOTE
2,6
~RovlDr~ NODE
I LOCAL 32
HOST
36 MODEM RAM
r~
I ~S
4o I ARTICLE
3~
~ ~ IIIIII~1
DATA/ADDRESS BUS I ,
I I qb
CPU 3a I/p PO INPUT

DEVICE
S7 FIG . 2
V
S.o
~a
uunumnumi .;
SN
yy~ SOUY y~
y6 u~'

P RLV T OF DRAWING.
AS ORIGINALLY FII.
FIL S
FIG. 3 LOAD BROWSER
8p SOFTWARE
LOAD QUERRY
~S PAGE
dllll ~IIIIdII~IN p
73 59
l2 4Y
84
ENTER UPC PRODUCT
ID NUMBER
LOOK UP
S6 UPC CODE
Q
A 'RETURN MATCHING
g~ RECORDS
DISPLAY RESULTS
9v
LOAD DESIRED
9a ADDRESS
FIG. 4 à
r ~o e- 7a r-714 (-76
UPC-A UPC-8 URL DESC
31251 00301 s e. s*up.com/subflle/Ind4x.htfnl so
00302 sample .soup.com/promotion/main .html 9iveawoy

31251
31251 test.milk,oir9 fnIlk
00400
- T con
4205 cors.com/testdrive/main .html
1 79

PRLNT OF DRAW1W
AS ORIGINALLY FU
SZ
-1
NAVIGATE > « KX~ELP EXIT
CLICK ON DESIRED SITE:

-
~ U2
P 31251 ' -003
31251- iGIVEAW
12 a
106 xz~
FIG . .7
Sou p
1110,
I k 0

Application.or . Docket Number

PATENT APPLICATION FEE DETERMINATION RECORD nn
Effective 'November 10, 1958 pC3 G Q
CLAIMS AS FILED PART I SMALL E OTHER THAN
Column 1 Column 2 TYPE OR SMALL ENTITY
FOR NUMBER FILED NUMBER EXTRA RATE FEE RATE FEE
BASIC FEE 380.00 OR 760.00
TOTAL CLAIMS minus 20= X$ 9= X$18=

OR
INDEPENDENT CLAIMS -minus 3 = X39= OR X78--
MULTIPLE DEPENDENT CLAIM PRESENT
+130-- OR +260=
* If the difference in column 1 is less than zero, enter 00" in column 2 TOTAL OR TOTAL
CLAIMS AS AMENDED - PART 11 OTHER THAN
SMALL ENTITY OR SMALL ENTITY
1
ADDI- ADDI-
QI I REMAINING I I NUMBER I PRESENT
AFT03 PREVIOUSLY EXTRA RATE TIONAL RATE TIONAL
z
W
Z AMENDMENT PAID FOR FEE FEE
O
z
Total * Minus .. 5 X$ 9-- OR X$18=
W Independent * Minus .« =yam.---
X39-- OR X78=
Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM
+130--. OR +260=
TOTAL TOTAL
OR ADDrT. FEE
ADDIT. FEE
M REMAINING NUMBER PRESENT ADDI- ADDI-

AFTER PREVIOUSLY EXTRA RATE TIONAL RATE . TIONAL
W
Z AMENDMENT PAID FOR FEE FEE
p Total * Minus ..
z X$ 9= OR X$18=
W Independent * Minus .« --
2 X39-- OR X78=
Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM
+130= OR +260=
TOTAL TOTAL
ADDiT. FEE OR ADDIT
. FEE
V REMAINING NUMBER PRESENT ADDI- ADDI-

z AFTER PREVIOUSLY EXTRA RATE TIONAL RATE TIONAL
W
= AMENDMENT PAID FOR FEE FEE
p Total . Minus
Z X$ 9= OR X$18=
W Independent * Minus .«
X39= OR X78=
FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM
+130= OR +260=
• If the entry in column 1 is less than the entry in column 2 write '0' in column 3
T OTAL TOTAL
If the 'Highest Number Previously Paid For' IN THIS SPACE is less than 20, enter'20 OR ADDIT
"If the 'Highest Number Previously Paid For' IN THIS SPACE is less than 3, enter'3 .' .' ADDrr FEE FEE
The 'Highest Number Previously Paid For' (Total or Independent) is the highest number found in the appropriate box In column 1.
raimn ar,p , raaernar" LMICe . U.b . UEYAH 1 MENT OF COMMERC

Rev. 6491

Docket Number : 150-061A
Applicant : Hudetz et al.

Serial No . : Unknown Examiner : D . Pan
Filing Date : January 15, 1999 Group Art Unit : 2783
Title : SYSTEM AND METHOD FOR USING AN ORDINARY
.ARTICLE OF COMMERCE TO ACCESS A REMOTE
COMPUTER
Hon . Commissioner of Patents

and Trademarks
SIR :
PRELIMINARY AMENDMENT
This Preliminary Amendment is submitted

contemporaneous with the above-identified application, which
is a divisional application of co-pending application serial
number 08/538,365 . Kindly amend the application as follows:
IN THE SPECIFICATION:
- Page 1, 1inz'
e 10, delete "continuation of" and insert
divisional application of co-pending application serial
number 08/538,365, filed on October 3 1995 which claims
1 7 ' J~1
priority of provisional AIS~i ~,~~ ~f
IN THE CLAIMS : .
Cancel claims 12-32 .

REMARKS
Claims 12-32 have been cancelled, leaving for

prosecution claims 1-11, which have been classified as
belonging to Group I by the Examiner in the co-pending
parent application.
Prompt consideration of the application is

respectfully requested.
Date : I —" S—I I Respectfully submitted,
Anth'oAl QR-.' Barkume

Re . No . 33,831
At orney for Applicant
( 16) 244-3503
Received : 6/29/99 .?M ; 703 658 2102 -> Ch r S KOEBER ; Page 2
FROM EXPRESS SEARCH PHbNE NO . 703 658 21be- Jun . 30 1999 02 :03PM P2/2
Received
Pmc itioner's DockttNo. ~s
rD''vbl A- ?AnWT
JUN (J 1919
Group ?_700
]T(TSa Y nTtD STATES PATENT AND TUDIXAM OFFICE
in re application
Of xudg n at el.
Serial No . : 09/`132,908
Cproup No., 2756
Filed: unuary 15, 1999
EM►OJYlur"
For: SYSTEM ANb MTHOD FOR USING AN ORDINARY ARTICLE OF
COMMCE TO ACCESS A REMATE CO)DU'l'ER
Assistant Commissioner fvr Patents

Washington, D, C . 20231
POWML TO INSPECT AND MAKE ; COPIES
Applicant bereby gmnta the below named practitioner the power to inspect and make copies of
the dwvo-referenced application.
Name ofpraetitioner : Rodger Plagg

Address: a 101 Crystal Plana Aro . #270
Ar bngton VA 22202
Rag, No. 29,149
Tel . No . (703) 658-2100
Dated; ~ar i
R Barkume
Attorney for Applicant
Rag_ No . 33,831
Anthony R Bukutae, P. C.
14 South Maio SMe Suite 2000
Sayville. NY 11782
Telephone No. : (516) 2442644

~4*-'VOF CO
3~ fit, UNITED ATES DEPARTMENT OF COMMERCE

Patent and Trademark Office
Address : COMMISSIONER OF PATENTS AND TRADEMARKS
*rATES 0* Washington, D .C. 20231
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO.
09/232 .900 01/15/99 HUMETZ F ISU — 061 P,
EXAMINER
F
L M 0 2 11 &~--'j
PAN . D
lel !'Hd 1 %e 1(---".11"---1 ART UNIT PAPER NUMBER
SUITE M I D
SAYVILLE NY 1170;i!
DATE MAILED :
11/29/9 1
Please find below and/or attached an Office communication concerning this application or
proceeding .
Commissioner of Patents and Trademarks
PTO-90C (Rev. 2/95) 0 RN Copy

Application No. Applicant(s)

09/232,908 Hudetz et al.
Office Action Summary Examiner
Pan 2783
K Responsive to communication(s) filed on Jun 3Q 1999
q This action is FINAL.

q Since this application is in condition for allowance except for formal matters, prosecution as to the merits is closed
in accordance with the practice under Ex parte Qu,?yV935 C .D . 11 ; 453 O .G . 213.
A shortened statutory period for response to this action is set to expire three month(s), or thirty days, whichever is
longer, from the mailing date of this communication . Failure to respond within the period for response will cause the
application to become abandoned . (35 U .S .C . § 133). Extensions of time may be obtained under the provisions of
37 CFR 1 .136(a).
Disposition of Claim
K Claim(s) 1-11 is/are pending in the applicat
Of the above, claim(s) is/are withdrawn from consideration
q Claim(s) is/are allowed.

K Claim(s) 11=4 is/are rejected.
X Claim(s) 5-11 is/are objected to.
q Claims are subject to restriction or election requirement.
Application Papers
Xj See the attached Notice of Draftsperson's Patent Drawing Review, PTO-948.
q The drawing(s) filed on is/are objected to by the Examiner.
q The proposed drawing correction, filed on is q .approved disapproved.
q The specification is objected to by the Examiner.
q The oath or declaration is objected to by the Examiner.
Priority under 35 U .S .C. § 119

q Acknowledgement is made of a claim for foreign priority under 35 U .S.C. § 119(a)-(d).
q All q3ome* None of the CERTIFIED copies of the priority documents have been
q received.
q received in Application No . (Series Code/Serial Number)
q received in this national stage application from the International Bureau (PCT Rule 17 .2(a)).
*Certified copies not received:
q Acknowledgement is made of a claim for domestic priority under 35 U .S .C . § 119(e).
Attachment(s)
PQ Notice of References Cited, PTO-892
q Information Disclosure Statement(s), PTO-1449, Paper No(s).

q Interview Summary, PTO-413
Pg Notice of Draftsperson's Patent Drawing Review, PTO-948
q Notice of Informal Patent Application, PTO-152
1 --- SEE OFFICE ACTION ON THE FOLLOWING PAGES ---

U . S . Patent and Trademark Office
PTO-326 (Rev . 9-95) Office Action Summary Part of Paper No . 4

Application/Control Number : 0,x/232,908 Page 2
Art Unit : 2783
Claims 1-11 are presented for examination.
The nonstatutory double patenting rejection is based on a judicially created

doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the
unjustified or improper timewise extension of the "right to exclude" granted by a patent and to
prevent possible harassment by multiple assignees . See In re Goodman, 11 F .3d 1046, 29
USPQ2d 2010 (Fed . Cir . 1993); In re Longi, 759 F .2d 887, 225 USPQ 645 (Fed. Cir . 1985) ; In
re Van Ornum, 686 F .2d 937, 214 USPQ 761 (CCPA 1982) ; In re Vogel, 422 F .2d 438, 164
USPQ 619 (CCPA 1970) ;and, In re Thorington, 418 F .2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1 .321© may be used to
overcome an actual or provisional rejection based on a nonstatutory double patenting ground
provided the conflicting application or patent is shown to be commonly owned with this
application. See 37 CFR 1 .130(b).
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal
disclaimer . A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3 .73(b).
2. Claim 1 is rejected under the judicially created doctrine of obviousness-type double
patenting as being unpatentable over claim 1 of U .S . Patent No. 5,978,773) . Although the
conflicting claims are not identical, they are not patentably distinct from each other because claim
1 of the patented application and the claim 1 of the present application are the same except the
claim 1 of the patented application recites an input means for generating a signal corresponding to
the encoded identification while claim 1 of the present application recites an input means for
generating a query signal corresponding to The encoded identification . It would have been
obvious to one of ordinary skill in the art to use the query signal in the input means for
corresponding to the encoded identification as claimed because the generic signal of the input

.f
Application/Control Number : 09/232,908 Page 3
Art Unit : 2783
means in the patented application is applicable to any specific signal, such as query or request
signals, and the specific of the signal generated by the input means would not affect the
corresponding encoded identification number
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness
rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are
such that the subject matter as a whole would have been obvious at the time the invention was made to a person
having ordinary skill in the art to which said subject matter pertains . Patentability shall not be negatived by the
manner in which the invention was made.
4. Claims 1-4 are rejected under 35 U .S.C. 103(a) as being unpatentable . over Beller et al.
(5, 602, 377) in view of Dolin, Jr. (5, 519, 878) .
5. As to claims 1-4, Beller disclosed a system using an article of commerce [product 140]
(figs . 1, 4,5) comprising at least :
a) machine readable indicia [bar code] associated with a product of commerce, the indicia
encoding at least one identification number corresponding to the article(e .g see col .2, lines 1-8,
col.6, lines 46-47, co1 .8, lines 19-22);
b)input means for generating a query signal corresponding to the identification number (col .8,
lines 40-47)) ;

Art Unit : 2783
c)a database for storing the bar code information (e. g. see col. 6, lines 39-46 ; col. 8, lines 49-55;
col. 12, lines 10-17).
6. Beller did not specifically show the database for containing a plurality of network
addresses and the associated identification numbers as claimed . However, Dolin, Jr ("Dolin"
hereinafter) disclosed a memory for storing the configuration of network addresses with
associated identification numbers [bar code identifications] (col.6, lines 32-33, lines 40-52, lines
32-55) . It would have been obvious to one of ordinary skill in the art to use Dolin in Beller for
including the database for storing the network addresses and associated identification numbers as
claimed because the use of Dolin could enhance the storage capacity of Beller to expand the bar
code reading to a plurality of processing nodes in a network environment.
Claims 5-11 are objected to as being dependent upon a rejected base claim, but would be
allowable if rewritten in independent form including all of the limitations of the base claim and any
intervening claims.
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to d . Pan whose telephone number is (703) 305 9696 . The examiner can
normally be reached on M-F from 8 :00 to 4 :00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor,
Meng, can be reached on (703) 305 9678 . The fax phone number for the organization where this
application or proceeding is assigned is (703) 305 3718 .

'v
Art Unit : 2783
Any inquiry of a general nature or relating to the status of this application or proceeding
should be directed to the receptionist whose telephone number is (703) 305 3900 .

'k:
Application No. Applicant(s) >

10
23
Notice of References Cited
Examiner
~ Group Art Unit
Page , of~
U .S . PATENT DOCUMENTS
* DOCUMENT NO . DATE NAM CLASS SUBCLASS.
A n
B K~/~ Z
-T
IDI
E
F
G
H
I
K
L
M
FOREIGN PATENT DOCUMENTS
* DOCUMENT NO . DATE COUNTRY NAME CLASS SUBCLASS
N
0
P
Q
R
S
ITI
NON-PATENT DOCUMENTS
* DOCUMENT (Including Author, Title, Source, and Pertinent Pages) DATE
*A copy of this reference Is not being funished with this Office action.
(See Manual of Patent Examining Procedure, Section 707 .05(a) .)
U.S . Patent and Trademark Office Part of Paper No.
PTO-892 (Rev . 9-96)
*U .S. GPO: 1996-420 . 311/40176

Form PTO 948 (Rev . 8-98) U .S . DEPARTMENT OF COMMERCE - Patent and'Trademark office Application No . O8
NOTICE OF DRAFTSPERSON'S
PATENT DRAWING REVIEW
The drawing(s) filed insert date ~~ re:

A . O approved by the Draftsperson under 37 CHR 1 .84 or 1 .152.
bjected to by the Draftsperson under 37 CFR 1 .84 or 1 .152 for the reasons indicated below . The Examiner will require
su mission of new, corrected drawings when necessary . Corrected drawing must be .sumitted according to the instructions on the back of this notice.
1 . DRAWINGS. 37 CFR 1 .84(x) : Acceptable categories of drawings : 8 . ARRANGEMENT OF VIEWS . 37 CFR 1 .84(i)
Black ink. Color. Words do not appear on a horizontal, left-to-right fashion
_ Color drawings are not acceptable until petiton is granted. when page is either upright or turned so that the top
Fig(s) becomes the right side, except for graphs . Fig(s)
Pencil and non black ink not permitted . Fig(s) 9. SCALE. 37 CFR 1 .84(k)
2. PHOTOGRAPHS . 37 CFR 1 .84 (b) _ Scale' not large enough to show mechanism without
_ 1 full-tone set is requited. Fig(s) crowding when drawing is reduced in size to two-thirds in
- Photographs not properly mounted (must use brystol board or reproduction.
photographic double-weight paper). Fig(s) Fig(s)
_ Foor quality (half-tone) . Fig(s) 10. CHARACTER OF LINES, NUMBERS, & LETTERS.
3 . TYPE OF PAPER. 37 CFR 1 .84(e) 3 11 1 .84(i)
Paper not flexible, strong, white, and durable . Lines, numbers & letters not uniformly thick and well
Fig(s) defined, cl an, ble, and black (poor line quality).
_ Erasures, alterations, overwritings, interlineations, Fig(s) --
folds, copy machine marks not accepted . Fig(s) 11 . SHADING . 37t FR 1 .84(m)
_ Mylar, velum paper is not acceptable (too thin). Solid black areas pale . ; Fig(s)
Fig(s) Solid black shading not permitted . Fig(s)
4 . SIZE OF PAPER . 37 CFR 1 .840: Acceptable sizes : Shade lines, pale, rough and blurred .' Fig(s)
_ 21 .0 cm by 29 .7 cm (DIN size A4) 12. NUMBERS, LETTERS, & REFERENCE CHARACTERS.
- 21 .6 cm by 27 .9 cm (8 1/2 x 11 inches) 37 CFR 1 .84(p)
All drawing sheets not the same size. - Numbers and reference characters not plain and legible .'
` Sheet(s) Fig(s)
_ Drawings sheets not an acceptable size. Fig(s) _ Figure legends are poor. Fig(s)
5 . MARGINS . 37 CFR 1 .84(8) : Acceptable margins : _ Numbers and reference characters not oriented in the
same direction'as the view. 37 CFR 1 .84(p)(1)
Top 2 .5 cm Left 2 .5cm Right 1 .5 cm Bottom 1 .0 cm Fig(s)
SIZE : A4 Size English alphabet not used . 37 CFR 1 .84(p)(2)
Top 2 .5 cm Left 2 .5 em Right 1 .5 cm Bottom 1 .0 cm Figs
SIZE : 8 1/2 x I1 Numbers, letters and reference characters must be at least
Margins not acceptab
Top (T)
Fi ) _ Left (L)4
j r
.32 cm (1/8 inch) in height . 37 CFR 1 .84(p)(3)
Fig(s)
Right (R) Bottom (B) 13. LEAD LINES . 37 CFR 1 .84(q)
6. VIEWS. 37 CFR 1 .84(h) Lead lines cross each other. Fig(s)
REMINDER : Specification may require revision to Lead lines missing . Fig(s)
correspond to drawing changes . 14 . NUMBERING OF SHEETS OF DRAWINGS . 37 CFR 1 .84(1)
Partial views . 37 CFR 1 .84(h)(2) Sheets not numbered consecutively, and in Arabic numerals
_ Brackets needed to show figure as one entity. beginning with number 1 . Sheet (s )
Fig(s) 15. NUMBERING OF VIEWS . 37 CFR 1 .84(u)
_ Views not labeled separately or properly . - Views not numbered consecutively, and in Arabic numerals,
Fig(s) beginning with number 1 . Fig(s)
_ Enlarged view not labeled separetely or properly . 16 . CORRECTIONS. 37 CFR 1 .84(w)
Fig(s) Corrections not made from prior PTO-948
7 . SECTIONAL VIEWS . 37 CFR 1 .84 (h)(3) dated
_ Hatching not indicated for sectional portions of an object. 17 . DESIGN DRAWINGS . 37 CFR 1 .152
Fig(s) _ Surface shading shown not appropriate . Fig(s)
_ Sectional designation should be noted with Arabic or _ Solid black shading not used for color contrast.
Roman numbers. Fig(s) Fig(s)
COMMENTS
r1h
REVIEWER DATE TELEPHONE NO.
ATTACHMENT TO PAPER NO.

Change Of Attorney Or Agent's Address In Application Docket No.
(37 CFR 1 .8(a)) 150-061A
In Re Application Of: Hudetz et al.

RECEIVED
Serial No . Filing Date Examiner (Mo iola n
09/232,908 01/15/99 Pan, D. 2783
Invention : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A
NETWORK =`/ v ' " 1
/
TO THE ASSISTANT COMMISSIONER FOR PATENTS cs / 'fid

P
Please send all correspondence for this application to :

MAY
MAY 0 3 2000 '-
o--Anthony R . Barkume, Esq. M
Greenberg Traurig
Met Life Building s DEMAP.4
200 Park Avenue
New York, NY 10166
Please direct all telephone calls to:
(212) 801-9294
~– Dated : May 1, 2000

Si aiure of Attorney or Agent of Record
Anthony R. Barkum, Esq.

1 certify that this document is being deposited on
Reg. No . 33,831 05/01/2000 with the U .S . Postal Service as first
Greenberg Traurig class mail under 37 C .F .R . 1 .8 and is addressed to the
Met Life Building Assistant Commissioner for Patents, Washington, D .C.
20231.
200 Park Avenue
New York, NY 10166
Signature of Pers n ailing Correspondence
Registration Number & Address ofAttorney or Agent of Record

Linda Garramone
Typed or Printed Name of Person Mailing Correspondence
Copyright 1997 LegalStar P2F/REV01

PETITION FOR EXTENSION OF TIME UNDER 37 CFR 1.136(a) Docket No.

(SmalifEntity) 150-061A
In Re Application Of : Hudetz et al.

KeE I VE
~j
~ ~ MAY0~200A
Serial No . Filing Date Examiner ~. CJ• a GrC*QUpnd^700
09/232 .908 January 15, 1999 Pan, D. 2783
Invention : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER O

NETWORK O 1 P
MAY 0 3 2= Q
TO THE ASSISTANT COMMISSIONER FOR PATENTS: ¢~A EMOAII'
This is a request under the provisions of 37 CFR 1 .136(a) to extend the period for filing a response to the Office
Action of November 29, 1999 in the above-identified application.
Date
The requested extension is as follows (check time period desired):

q One month ® Two months q Three months q Four months q Five months
from : February 29, 2000 until: April 29, 2000
Date Date
A verified statement of small entity status as a small entity under 37 CFR 1 .27:
q is enclosed.
® has already been filed in this application.
The fee for the extension of time is $190 and is to be paid as follows:
® A check in the amount of the fee is enclosed.
q The Commissioner is hereby authorized to charge any fees which may be required, or credit any
overpayment, to Deposit Account No.
A duplicate copy of this sheet is enclosed.
q If an additional extension of time is required, please consider this a petition therefor and charge any additional
fees li h required to Deposit Account No . - A duplicate copy of this sheet is enclosed.
Dated: May 1, 2000

Signature
Anthony RL /Barkume, Esq.

Reg. No. 33,831 1 certify - that this document and fee is being deposited on
Greenberg Traurig 05/01/2000 with the U .S. Postal Service as first
Met Life Building class mail under 37 C .F .R . 1 .8 and is addressed to the
200 Park Avenue Assistant Commissioner for Patents, Washington, D .C.
20231.
New York, NY 10166
(212) 801-9294
Signature of Pe o Mailb1g Correspondence
Linda Garramone
cc :
Typed or Printed Name of Person Mailing Correspondence
Copyright 1994-97 LegalStar P12SMALUREV05

0 1
MAY o 3, 1000
cc)
Docket Number : 150-061A
DEMARy'
RECEIVED
MAY Q a 2000
Applicant : Hudetz et al .
Group. 2700
Serial No . : 09/232,908 Examiner : D . Pan
Filing Date : January 15, 1999 Group Art Unit : 2783
Title (as amended) : SYSTEM AND METHOD FOR AUTOMATIC ACCESS

OF A REMOTE COMPUTER OVER A NETWORK
Hon . Commissioner of Patents

and Trademarks
SIR :
AMENDMENT
This Amendment is submitted in response to the

office action mailed on November 29, 1999 . A request to
extend the time to respond by two months is enclosed .
herein, which extends the time to respond until April 29,
2000 . Since that date is a Saturday, this Amendment is
timely filed on .Monday, May 1, 2000 . Kindly amend the
application as follows:
IN THE TITLE:
Rewrite the title/as : SYSTEM AND METHOD FOR [USING AN
ORDINARY ARTICLE/6F COMMERCE TO] AUTOMATIC ACCESS OF A
REMOTE COMPUTER OVER A NETWORK
IN THE SPECIFICTION:
On Page line 9, after "with" insert one aspect of .-
On Page 5, line 27, after "network" insert the!

01101HO

`— following paragraphs:
-- In accordance with another aspect

of the invention, network
addresses are directly encoded
into bar code format . In this
manner, the necessity of manually
entering the address i-s
eliminated . Users can more quickly
review published lists of Web
Sites,or other locations . The bar-
coded address can also be printed
on removable stickers or
detachable cards, allowing users
to readily clip the stickers or
cards for future reference.
In accordance with yet another

aspect of the invention,
navigational's commands (in addition
to addresses) can be published
J together in both human-readable
and bar code formats . These
commands include common commands
such as 'back" and "forward," as
well as more specialized command
sequences, such as the commands
necessary to access particular
services, files, and documents on
the Internet or the proprietary
on-line services . Rather than
manually enter these commands, the
user selects , a desired ,command by
scanning its associated bar code.
The , output of the bar code reader
is accepted by the browser
software as the selected command.
On page 7, line 20, after "computers" insert
the following paragraphs :

~_ -- FIG . 8 is a block iagra

computerized apparatus for
interfacing with a computer
network in accordance with a
second embodiment of the
invention.
FIG . 9 is an idealized perspective

of the document of FIG 8 having a
r 1 network address in both bar code
and human readable formats.
FIG . 10 is a flow chart

illustrating the operation of : the
apparatus of FIG . 8 in accordance
with the invention . --
On page 18, line 7, after "address" insert the

following paragraphs:
An example of the direct coding of

network addresses is shown in the
illustrated FIGS . 8-10 . Referring
to FIG 8, a block diagram of the
computerized apparatus 10 for
interfacing with a computer
network in accordance with the
invention is illustrated.
Apparatus 113 includes a computer
114, which may be an IBM
compatible personal computer.
3
/7 Attached to,computer 114 by a
suitable input/output interface
r5` . 115 is a modem 116 . Also attached
to'computer 114 via an -
input/output interface 118 is a
bar code reader 120 . Bar code
--reader 120 is designed to read
conventional bar codes . Bar code
technology is described generally
in U .S . Pat No . 5,115,326 issued
May 19, 1992 and entitled "Method
of Encoding an E-Mail Address in a
Fax Message and Routing the Fax

Message to a Destination and

Network", and No . 5,420,943 issued
May 30, 1995 and entitled
"Universal Computer Input Device,"
the disclosures of which are both
hereby incorporated by reference.
Modem 116 is adopted for ,

electronic communication via a
suitable telephone link 122 with a
service provider 124 .-'Service
provider 124 may be an Internet
service provider or a proprietary
on-line service such as Prodigy or
America On-Line . Service provider
124 in turn is electronically
connected by a suitable
communication link 126 to a remote
server 128 . For purposes of
illustration, . we assume that
remote server's 128 numeric
network address is 200 .98 .154, and
that the assigned address mnemonic
is http ://sample@www .com .
Computer 114 is equipped with

communication software for
establishing and maintaining a
communication link with service
provider 124 via modem 116 and
telephone link 122 . Computer 114 is
also equipped with software (see
FIG . 10) such as Netscape Navigator
brand Web browser software (version
1 0) which enables it to request
and receive .information ' from remote
server 128 - via service provider
124 . .To operate software 130, a
user (not shown) enters an
alphanumeric address such as
sample@www .com . Browser software
130 sends service provider 124 a
request for the information
contained at address corresponding
to the mnemonic sample@www .com . As
explained above, that mnemonic
4
d`

Using the address sample@www .com,

service provider 124 routes the
request to remote server 128 via
communication link 126 . Remote
server 128 responds by sending the
desired information via
communication link 126 to service
provider 124, which relays the
information to computer 114 via
modem 116 and telephone link 122.
once the information is received
by computer 114, browser software
130 displays the information in a
useful format for the user.
In accordance with the invention,

a document 132 is provided.
Document 132 , may be a magazine
article, advertising or other
printed matter . As shown in FIG 9,
Document 136 contains human
readable information 134 about
resources available at a location
on a network such as the Internet,
including resources provided by
remote server 128 . In this
example, human readable
information 134 includes remote
server's 128 mnemonic address -
http ://sample@www .com . A bar-code
indicia 136 is placed near human
readable information 13,4 . Bar code
136 contains remote server's 128
numerical address (200 .98 .154) in
machine-readable form .
Alternatively , bar code 136 could

contain a machine-readable version
of the mnemonic address . Under
that arrangement, the bar-coded
digits would correspond to
alphanumeric symbols of the
mnemonic address . For example, the

bar coded number 11 97 11 ..could

correspond to the character "a " .
In that case, however, bar -code
136 may have to be exceptionally
long.
If the user wants access remote

server 128, he or she scans bar
code 136 using bar code reader
120 . Bar code reader 120 generates
a signal on input/output interface
118 corresponding to the numeric
address encoded by bar code 136
(which for purposes of
illustration we assume to be
257004-00220, as shown in FIG . 9).
Browser software 130 on computer
114 reads the numeric address via
input/output interface 118, and
forwards it to service provider
124, along with a request for
information contained at the
location corresponding to that
~(J address . Service provider 124
determines that the numeric
address is that of remote server
128, and routes to there the
request for information.
Referring to FIG . 10, the

operation of browser software 130
is shown in more detail . In an
initial step 138, browser software
attempts to . tead input from bar
code reader 120 . At a decision
block 140, browser software 130
determines whether reader 120 has
input . If no input is available,
control returns to block 138,
__where browser software 130 again
attempts to read bar code reader
120 . If input is available at
decision block 140-, then control
moves to a block 142 where browser
software 130 transmits the input
read at block 138 to service

provider 124 . There are other ways

to handle input from bar code
reader 120, and more sophisticated
techniques maybe used in actual
commercial embodiments of the
invention.
Service provider 124 interprets

the input as a numeric,network
address . In this case, we have
assumed that the address is that
of remote server 128 . Service
provider forwards a request for
data to remote server 128 . At a
block 144, the requested data
contained on remote server 128 is
received by browser software 130
via service provider 124 . Once
received, the data is available
for whatever,use required by the
user . Control then returns to
block 138 where the foregoing
process is repeated indefinitely.
N In effect, the necessity of

manually typing in the mnemonic
address sample@www .com is
eliminated . Instead, the numeric
address is obtained from the bar
code indicia 1.36 by use of bar
code reader 120 . As explained
above, bar code 136 could contain
.the mnemonic as well as numeric
address . Browser software could
be programmed to accept either
format (mnemonic or numeric) as
input from bar code reader 120,
with the default expectation being
that the bar coded data is a
numeric address unless the user
otherwise specifies.
Alternatively, the first coded
number of bar code, 136 could
indicate whether the information
that follows represents a numeric
or mnemonic address . If bar code
7
)
a
1

136,can contain either mnemonic or

numeric addresses, then browser
software should include a flag or
other indication alerting service
provider 124 as to the format of
the transmitted data.
The foregoing embodiment is just
one example . Many alternatives
are possible . For example, in lieu
of a bar code scanning device, a
card reader could be employed . The
card reader would read a magnetic
stripe affixed to a card or other
J printed matter . The card would
contain human-readable information
about a network resource, and the
magnetic strip would contain the
resource's numeric or mnemonic
address in machine-readable
format . Alternatively, a RF data
collection scanner or CCD scan-
system could , be used . Bar code
symbol 126 could also be
associated with specific commands
such as "forward", or "back," or
command sequences used to access
information .--
IN THE CLAIMS:
Cancel claims-1/and
/ add the following new
claims:
--136 . A method of connecting a user computing device to

one of a plurality of remote computers available for
communication over a network comprising:
a) reading a data carrier modulated with an index;

b) accessing a database with the index, the database .
comprising a plurality of records that link an

index to a pointer which identifies a remote

computer on the network;
c) extracting a pointer from the database as a
function of the index ; and
d) using the pointer to establish communication with
the remote computer identified thereby.
PDA! The method of claim &5 wherein the step of reading a

data carrier modulated with an index comprises the step of
reading a light pattern emanating from an object and
demodulating the light pattern to obtain the index.
7 The method of claim 'wherein the step of reading a

light pattern emanating from an object and demodulating the
light pattern to obtain the index comprises scanning a bar
code symbol encoded with the index.
3
J3,e The method of claim .3'~ wherein the bar code symbol is
encoded in accordance with an extrinsic standard.
I
~Q3 The method of claim .4 wherein the index is at least a
portion of a Universal Product Code.
The method of claim -.)*I wherein the index is at least a

portion of a EAN Code . f
~' . The method of claim Jel wherein the index is at least a
portion of an ISBN code.
` .44f . The method of claim,3o5 wherein the index is at least a

portion of an ISSN code .

The method of claim wherein the step of reading a

light pattern to obtain the index comprises using optical
character recognition techniques.
1 10
y2 . The method of claim,2-f wherein the step of reading a
data carrier modulated with an index comprises receiving a
signal emanating from an article of commerce, the signal
being modulated with the index.
I
The method of claim 4- -1 wherein the step of reading a

data carrier modulated with an index comprises inputting
into the user computing device an audible signal modulated
with information correlated,to the index.
l a-' (t
94'. The method of claim A .3 wherein the step of inputting
with information correlated to the index comprises the use
of voice recognition techniques.
fb I
A- ' . The method of claim wherein the step of reading a
data carrier modulated with an index comprises inputting
into the user computing device an RF signal modulated with
information correlated to the index.
4-15*. The method of claim ~-ff wherein the step of reading a

data carrier modulated with an index comprises accessing a
magnetic card with a magnetic card reader.
)T t
4-1 The method of claim -3 wherein the steps of accessing
a database and extracting a pointer therefrom are
carried out on the user computing device.
10

Ih
LW. The method of claim 3~ wherein the steps of accessing
a database and extracting a pointer therefrom are
carried out on a server computer located remotely from
the user computing device.
9-1 . The method of claim -e wherein the database is

distributed over more than one computer.
( The method of claim 3,T wherein the pointer comprises a

network address.
,r. The method of claim 3~3 wherein the pointer comprises a

Uniform Resource Locator.
a-0 ►
,f . The method of claim 3~3 wherein the pointer comprises
the name of a remote computer.
,5-2'. The method of claim•3-1 wherein the pointer comprises

an IP address .
a~ r
The method of claim .Ie wherein the index is comprised
of a first field and a second field.
aJI
3 ,
RS . The method of claim ,i-~ wherein the step of accessing a
database with an index comprises the steps of using
only the first field of the index to access the
database ._
a~ a3
The method of claim .5-5 wherein a plurality of indexes-
having the same first field and different second
fields will result in extraction of the same pointer.

' F.
' pq
The method of claim Z6" wherein the first field is a
manufacturer identification number and the second field is
a product identification number.
~ . The method of claim .~ wherein the step of using the

pointer to establish communication with the remote computer
identified thereby is executed automatically by the user
computing device without user intervention.
~.
1 The method of claim .54 wherein the automatic
communication by the user computing device with the remote
computer is executed by a web browser program running on
.1 A ,
.0 The method of claim ;i,-1 wherein the step of using the
identified thereby is executed by a user selecting
hypertext link returned to the user computing device by the
database.
ffl I
•61 . The method of claim s3 wherein the network over which
the user computing device establishes communication with
the remote computer is a wide area network.
3 6 , The ~l
method of claim wherein the wide area network is
the Internet.
31 '
. The method of claim 6X wherein the wide area network
is a proprietary online service .

3(
.The method of claim j -~ wherein the database is resident
g
on an online service provider computer with which the

user computing device has established direct
communication.
~~ .The method of claim b.4 wherein the online service

provider computer additionally provides a gateway to the
Internet.
.The method of claim 31 -3' wherein access to the database

requires entry of a password.
35 I
b-1 .The method of claim3 wherein the database is
associated with a search-engine.
3T
r6' . A system comprising:
a. a user computing device;
b. an input device associated with the user computing
device, configured to read a data carrier modulated
with an index;
c. means for storing a database comprising a plurality
of records that link an index to a pointer which
identifies a remote computer;
wherein the user computing device comprises:
means for accessing the database to extract a
pointer from the database as a function of the
index ; and
_means for using the pointer to establish
communication with the remote computer identified
thereby .
J 13

3 The system of claim

3 (P
6e wherein the user input device
comprises means for reading a light pattern emanating from
an object and demodulating the light pattern to obtain the
index.
3O 3,
The system of claim b,6 wherein the means for reading a
light pattern to obtain the index comprises means for
scanning a bar code symbol encoded with the index.
31
34 The system of claim -I-f1 wherein the means for scanning
a bar code symbol is adapted to scan a bar code symbol
encoded in accordance with an extrinsic standard.
CO
r . The system of claim ,wherein the input device is
configured to read an index comprising at least a portion
of a Universal Pro( 3uct Code.
.~ . The system of claim .6Q wherein the input device is

of a EAN code .
43 3 J~,
.74 . The system of claim 6.6 wherein the input device is
of an ISBN code .
The system of claim 4?9 wherein the input device is

of an ISSN code-.
D 3?
~6 . The system of claim R5 wherein the means for reading a
light pattern eman+ ating from an object and demodulating the

light pattern to obtain the index comprises means for using

optical character recognition techniques.
Its'
The system of claim ~~ wherein the input device is
adapted to receive a signal emanating from an article of
commerce, the signal being modulated with the index.
K(O No
'4e. The system of claim .6-9 wherein the input device
comprises means for inputting into the user computing
device an audible signal modulated with information
correlated to the index.
`f -7 4110
,7.?' . The system of claim 7,4T wherein the means for inputting
with information correlated to the index is configured to
utilize voice recognition techniques.
36
L1$
ji-6 . The system of claim ,C9 wherein the input device
comprises means for inputting an RF signal modulated with
;je . The system of claim .r8 wherein the input device

comprises means for reading a magnetic stripe card.
S~ •3b
The system of claim .09 wherein the means for storing a
database is located on the user computing device.
67 3 (0
da-5 . The system of claim fry wherein the means for storing a
database is located on a server computer located
remotely from the user computing device.
15
J
.F ,
C
The system of claim 6Pf wherein the means for storing a

database is distributed over more than one computer.
S3 3~
The system of claim 60 wherein the pointer comprises a
network address .
g(v
,P6 . The system of claim 64 wherein the pointer comprises a
Uniform Resource Locator.
~$ The system of claim rpB wherein the pointer comprises

the name of a remote computer.
.8-9 . The system of claim bot wherein the pointer comprises

an IP address.
7 36
~J . The system of claim ~ wherein the index is comprised
Vie of a first field and a second field.
The system of claim &l wherein the means for accessing

a database with an index comprises means for using
only the first field of the index to access the
database .
gJr . The system of claim ,S9 wherein a plurality of indexes

having the same ,first field and different second
fields will result in extraction of the same pointer.
60 j7
~ . The system of claim SK wherein the first field-is a
manufacturer identification number and the second field is
a product identification number.
16

~o6 . The system of claim

3 6, wherein the means for using the
identified thereby executes automatically by the user
computing device without user intervention.
,1~4 . The system of claim .9-S wherein the automatic

communication by the user computing device with the remote
computer is executed by a web browser program running on
y+5 . The system of claim .19 wherein the means for using the
identified thereby executes by a user selecting hypertext.
link returned to the .user computing device by the database.
!o ~{ 36
9'r.The system of claim Erb wherein.the network over which
the user computing device establishes communication with
the remote computer is a wide area network.
901 .The system of claim 961wherein the wide area network is

the Internet .
I-lele
.The system of claim .Y6 wherein the wide area network is

a proprietary online service.
0 66
AX .The system.of claim OT wherein the database is resident
on an online service provider computer with which the
user computing device has established direct
communication .
17

(07 C7
-3-z~ . The system of claim k9 wherein the online service
provider computer additionally .provides a gateway to the
Internet.
69 36
,02 . The system of claim r8 wherein access to the database
requires entry of a password.
7d
. The system of claim j&6 wherein the database is
associated with a search engine.
X6'.3 . A user computing device comprising:

a. an input device configured to read a data carrier
modulated with an index ; and
b. computer processing means for executing a software
program adapted to:
utilize the index to access a database
nn~~ comprising a plurality of records that link an

W index to a pointer which identifies a remote
computer;
retrieve from the database a pointer as a
function of the index ; and
use the pointer to establish communication
with the remote computer identified thereby ..
,'7 y ?t
6 The user computing device of claim 1.@3 wherein the
user input device comprises means for reading a light
pattern emanating from an object and demodulating the light
pattern to obtain the index.
*73 - 9z
19~ . The user computing device of claim wherein the
means for reading a light pattern emanating from an object
and demodulating the light pattern to obtain the index

comprises means for scanning a bar code symbol encoded with

the index.
'/-~ ' 73
1.9-' . The user computing device of claim wherein the
means for scanning a bar code symbol is .adapted to scan a
bar code symbol encoded in accordance with an extrinsic
standard . '
'7 G 7(
The user computing device of claim k63 wherein the
input device is configured to read an index comprising at
least a portion of a Universal Product Code.
77 7(
.,9-e . The user computing device of claim .1' wherein the
`
t~ input device is configured to read an index comprising at
least a portion of a EAN code .
Y~
7$ 71
1 .4e. The user computing device of claim 10 wherein the
least a portion of an ISBN code .
.
17 9 11
k1R~ . The user computing device of claim 2.9 13 wherein the
least a portion of an ISSN code.
7s 7y
1- The user computing device of claim L.9t wherein the
means for reading-a light pattern emanating from an object
and demodulating the light patter a to obtain the index
comprises means for using optical character recognition
techniques .
112 . The user computing device of claim J,0 ,13 wherein the
input device is adapted to receive a signal emanating from

an article of commerce, the signal being modulated with the

index.
a/ I/
17~. The user computing device of claim IQ-3 wherein the
input device comprises means for inputting into the user
computing device an audible signal modulated with
,14-4 . The user computing device of claim ;,if wherein the

means for inputting into the user computing device an
audible signal modulated with information correlated to the
index is configured to utilize voice recognition
techniques .
71
]X~ . The user computing device of claim I-9'3 wherein the
input device comprises means for inputting an RF signal
modulated with information correlated to the index.
~~ 7l
J-
-r g . The user computing device of claim X93 wherein the
input device comprises means for reading a magnetic stripe
card.
Bi' '1(
,k1-1 . The user computing device of claim 7-0'3 wherein the
software program is adapted to utilize the index to
access a database located on the user computing device.
7(
,yl~ . The user computing device of claim ).91 wherein the
software program is adapted to utilize the index ' to
access a database located on a server computer remote
from the user computing device.
1. 20

4PI!-9 . The user computing device of claim ;o@n wherein the

software program is adapted to utilize the index to
access a database distributed over more than one
computer.
?(
. The user computing device of claim ke3 wherein the
index is comprised of a first field and a second
field, and wherein the software program is adapted to
access a database with only the first field of the
index .
y2'r The user computing device of claim 1,2-a wherein a

plurality of indexes having the same first field and
different second fields will result in extraction of
the same pointer.
go r
a~ 4-22 . The user computing device of claim 1.8'3 wherein the
software program is adapted to use the pointer to establish
communication with the remote computer identified thereby
automatically without user intervention.
el / go
The user computing device of claim ]~ wherein the
automatic communication by the user computing device with
the remote computer is executed by a web browser program
running on the user computing device.
G12 r!
1.2< . The user ' computing device of claim .603 wherein the
software program is adapted to use the pointer to establish
communication with . the remote computer identified thereby
by using a user-selected hypertext link returned to the
user computing device by the database.
21

q3 '7I
.1.2~ The user computing device of . claim further
adapted to establish communication with the remote
computer over a wide area network.
C74 . Q3
The user computing device of claim .14?5 further adapted
►
~ to establish communication with the remote computer over
the Internet.
Rs - 173
The user computing device of claim .1- ' further adapted
to establish communication with the remote computer over
a proprietary online service .--
REMARKS
The specification has been amended to include material
from parent application serial number 08/538,365, which was
obtained from provisional application serial number
60/000,442, filed on June 20, 1995, and entitled "Method of
an Apparatus for Interfacing with Remote Computers".
The provisional application was originally

incorporated by reference in the first paragraph of the
present specification . In accordance with M .P .E .P . section
608 .01(p), applicants are amending the specification to
include disclosure from the provisional application.
Applicant has also submitted herewith two new sheets

of drawings containing FIGS . 8-10, which correspond - to
FIGS . 1-3 of the provisional application . To avoid
duplicate reference numerals, references 10 through 144 of
in FIGS . 1-3 of the provisional application have been
changed to 113 ,through 144, respectively .
T
The textual material inserted into the present

application by virtue of these amendments may be found on
pages 4-8 of the provisional application . Minor editorial
changes were made for purposes of readability and
conforming references to the drawings to the revised figure
and reference numerals.
The amendments add no new matter to the specification.

The Examiner is invited .to contact Applicant's attorney
Anthony R . Barkume directly at (212) 801-9294 should he or
she have any questions.
In the office action, the Examiner rejected pending

claims 1-4 as being unpatentable under 35 USC 103(a) over
Beller et al . (United States Patent No . 5,602,377 .) in view
of Dolin, Jr . (United States Patent No . 5,519,878) . The
Examiner also indicated that claims 5-11 would be-allowable
if rewritten to include all the limitations of the base
claims from which they depend . Applicant respectfully
disagrees with the Examiner's rejection of the claims, but
has cancelled claims 1-11 and added new claims 33-127 to
more clearly define the applicants' invention over the
prior art of record as explained herein.
Claims 33-67
New claims 33-67 cover a method of the present
invention that is novel and unobvious over the prior art of
:record . Independent claim 33 recites a method of
connecting a user computing device to one of a plurality of
remote computers available for communication over a network
comprising the steps of (a) reading a data carrier

modulated with an index ; (b) accessing a database with the

index, the database comprising a ..plurality of records that
link an index to a pointer which identifies a remote
computer on the network ; (c) extracting a pointer from the
database as a function of the index ; and (d) using the
identified thereby.
New claims 34-67 depend from claim 33 and add

limitations that are disclosed in the specification as
follows . Claims 34-35 cover the use of a modulated light
pattern, e .g . a bar code symbol, as disclosed throughout
the specification (see, for example, Figure 3 and Figure
8) . Claims 36-40 describe by way of example the various
standards that may be used (see specification page 10, line
19 through page 11, line 11) . Claim 41 recites the use of
OCR technology, as explained in the specification for
example at page 11, lines 19-23 . Claim 42 relies on the
use of an article of commerce., which is explained for
example at page 9, line 32 et seq . Claims 43 and 44 relate
to another way (audible, voice recognition) of inputting
the required information to the user computer, as explained
for example at page 8, lines 20-22 . Claim 45 relates to
the use of RF data transfer, as disclosed in the textual
material added by way of :this Amendment . Claim 46 relates
to the use of a magnetic stripe card, as also disclosed in
the textual material added by this Amendment.
Claims 47-49 recite the various locations of the

database used by the invention (local, remote, and
distributed), as disclosed for example at page 12, line 32
through page 13, line 29) . Claims 50-53 describe the
24
~~
various embodiments of the pointer that is returned by the
database table, as described in the background section, and
throughout the description of the invention.
Claims 54-57, which recite various . limitations on the

construction of the index used to access the database, are
disclosed in the specification at page 11, line 25 through
page 12, line 31.
Claims 58-59 describes the automatic connection to the

remote computer, for example by a web browser, as described
on page 17, lines 1-11 . Claim 60 describes the embodiment
wherein the user selects the desired hyperlink to the
resource, as described in the same section and shown in
Figure 5.
Claims 61-65 describe the various network

configurations that are congruous with the invention, as
described in the specification at page 16, lines 8-25.
Claim 66 covers the use of a password for using the system,
which is set forth at page 16, lines 26-36 . Claim 67
describes the integration of the invention with a search
engine, as set forth at page 13, lines 10-15.
Claims 68-102
New claims 68-102 describe the present invention in
the format of , a system, wherein independent claim 68
recites system comprising a user computing device ; an input
device associated with the user computing device,
configured to read a data carrier. modulated with an index;
means for storing a database comprising a plurality of
records that link an index to a pointer which identifies a
remote computer ; wherein the user computing device
comprises means for accessing the database to extract a
pointer from the database as a function of the index ; and
means for using the pointer to establish communication with
the remote computer identified thereby . Claims 69-102
depend from claim 68 and recite limitations similar to the
independent claims 34-67 as discussed above.
Claims 103-127
New claims 103-127 describe the user computing device
of the present invention, wherein independent claim 103
recites a user computing device comprising an input device
configured to read a data carrier modulated with an index;
and computer processing means for executing a software
program adapted to utilize the index to access a database
comprising a plurality of records that link an index to a
pointer which identifies a remote computer, retrieve from
the database a pointer as a function of the index, and use
the pointer to establish communication with the remote
computer identified thereby . Claims 104-127 depend from
claim 103 and recite limitations similar to the independent
claims 34-67 as discussed above.
26

Thus, no new matter has been added in the newly

presented claims, and all claims are allowable over the
prior art of record . It is respectfully requested that
these claims be allowed and pass to issue.
Date : v ~'bd0 Respectfully submitted,
AAthon*y R . Barkume
Reg . No . 33,831
Attorney for Applicant
(212) 801-9294
27

REMOTE SERVICE
SERVER PROVIDER 204
22 S ZZIo Z/D
222
236
234
2//o MODEM l
DOCUMENT
i
Z/Z COMPUTER
~ Z32
1
BAR
CODE
READER
Z/8
220

232
Fj1p:II sample c .w w. eeM
2,36
39 0
FIG 9
238
READ
SCANNER
-INPUT ' ',
NO
INPUT?
r--- 230
240 T,>
YES
-TRANSMIT
ADDRESS 24Z
RECEIVE ~ Z4*
L---~ DATA
FIG - 10

AMENDMENT TRANSMITTAL LETTER (Small Entity) Docket No.

/C
Applicant(s) : Hudetz et al. 15REEIV E
Serial No . Filing Date Examiner Gro rt&A 2000

09/232,908 January 15, 1999 D . Pan 756
drou 2700
Invention : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER O R A NETWORK
0 1P ~
o,
TO THE ASSISTANT COMMISSIONER FOR PATENTS:
Transmitted herewith is an amendment in the above-identified application.

® Small Entity status of this application has been established under 37 CFR 1 .27 by a verified statement
previously submitted.
q A verified statement to establish Small Entity status under 37 FR 1 .27 is enclosed.
The fee has been calculated and is transmitted as shown below.
CLAIMS AS AMENDED
CLAIMS REMAINING HIGHEST # NUMBER EXTRA ADDITIONAL
RATE
AFTER AMENDMENT PREV . PAID FOR CLAIMS PRESENT FEE
TOTAL CLAIMS 95 - 20 = 75 x $9.00 $675 .00
INDEP . CLAIMS 3 3 = 0 x $39.00 $0 .00
Multiple Dependent Claims (check if applicable) q $0 .00
TOTAL ADDITIONAL FEE FOR THIS AMENDMENT $675 .00
q No additional fee is required for amendment.

q Please charge Deposit Account No . in the amount of
® A check in the amount of $675.00 to cover the filing fee is enclosed.
q The Commissioner is hereby authorized to charge payment of the following fees associated with this
communication or credit any overpayment to Deposit Account No.
q Any additional filing fees required under 37 C .F.R. 1 .16.
qM nytent application processing fees under 37 CFR 1 .17.
Dated: May 1, 2000
Signature
Anthony . Barkume
Rcg . No . 33,831 1 certify that this document and fee is being ',deposited
Attorney for Applicant am May 1, 2000 with the U .S . Postal :Service as
200 Park Avenue first class mail under 37 C .F.R . 1 .8 and is addressedito the
Assistant Commissioner for Patents, Washington, D .C.
NewYork, ;NY10166. 20231 . `
(212) 801-9294
Signature ofPerso~ ing Correspondence
cc : Linda Garramone
Typed or Printed Name ofPerson Mailing Correspondence
P11 SMALUREV06,
CERTIFICATE OF MAILING BY.~FIRST CLASS MAIL. (37 CFR 1 .8) Docket No.
Applicant(s) : Hudetz et al . 150-061A
F4 F= Prh pn I P V— on
Serial No . Filing Date Examiner ME Pt
091232,908 January 15, 1999 Pan, D . MAr 19 8 2000
Invention : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER CWJP 2700
NETWORK
v
MAY 0 3 2000 0
-4
w
~A MAO
I hereby certify that this Amendment
(Identify type of correspondence)
is being deposited with the United States Postal Service as first class mail in an envelope addressed to : The
Assistant Commissioner for Patents, Washington, D .C . 20231 on May 1, 2000

(Date)
Linda Garramone
(Typed or Printed Name of Person Mailing Correspondence)
(Signa ure of Person g Correspondence)
Note : Each paper must have its own certificate of mailing.

TR, .NSMITTAL OF INFORMA T JON DISCLOSURE STATEMENT- Docket No.

(Under 37 CFR 1.97(b) or 1 .97(c)) 150-061A
1
In Re Application Of : Hudetz et al.
C ..' rQ
Serial No . Filing Date Examiner Group Arpinit nI
09/232,908 January 15, 1999 Pan, D. 2788 .9 141
%
Title : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK
1P
Address to:
MAY 0 5
Washington, D.C . 20231
MADEM37
)~'$ CFR 1 .97(b).
1. q The Information Disclosure Statement submitted herewith is being filed within three months of the
filing of a national application ; within three months of the date of entry of the national stage as set forth
in 37 CFR 1 .491 in an international application ; or before the mailing date of a first Office Action on
the merits, whichever event occurs last .
37 CFR 1 .97(c)
2. ® The Information Disclosure Statement submitted herewith is being filed after three months of the filing
of a national application, or the date of entry of the national stage as set forth in 37 CFR 1 .491 in an
international application ; or after the mailing date of a first Office Action on the merits, whichever
occurred last but before the mailing date of either:
1. a Final Action under 37 CFR 1 .113, or
2. a Notice of Allowance under 37 CFR 1 .311,
whichever occurs first.
Also submitted herewith is:
L) a certification as specified in 37 CFR 1 .97(e);
OR
29 the fee set forth in 37 CFR 1 .17(p) for submission of an Information Disclosure Statement
under 37 CFR 1 .97(c).
05A /2000 HLUANG 00000006 09232908

01F •126 240.00 OP
Copyright 1996 Legalsoft P10AIREV01

TR~-i,NSMITTAL OF INFORMATION DISCLOSURE STATEMENT - Docket No.

(Under 37 CFR 1.97(b) or 1 .97(c)) 150-061A
In Re Application Of: Hudetz et al . o 3C

M
C w M
n
Serial No . Filing Date Examiner Group ArrQnit
09/232,908 January 15, 1999 Pan, D . 27830 c°a C
D
O p
MAY 0 5 200
2~` Payment of Fee

k 7ItiApFMPe~ (Only complete if Applicant elects to pay the fee set forth in 37 CFR 1 .17(p))
® A check in the amount of $240 .00 is attached.

q The Assistant Commissioner is hereby authorized to charge and credit Deposit Account No.
as described below . A duplicate copy of this sheet is enclosed.
q Charge the amount of
q Credit any overpayment.
q Charge any additional fee required.
Certificate of Transmission by Facsimile* Certificate of Mailing by First Class Mail

I certify that this document and fee is being deposited on
I certify that this document and authorization to charge deposit
05/02/2000 with the U .S . Postal Service as first
account is being facsimile transmitted to the United States class mail under 37 C .F .R . 1 .8 and is addressed to the
Patent and Trademark Office (Fax . No . ) on
(Date) 20231.
Signature Signature of Pers ailing Correspondence
Linda Garramone
Typed or Printed Name of Person Signing Certificate Typed or Printed Name ofPerson Mailing Correspondence
*This certificate may only be used if paying by

deo unt .
Dated : May 2 , 2000

Signature
ABarku me, Esq.

Reg. No . 33,831
Greenberg Traurig
Met Life Building
200 Park Avenue
New York, NY 10166
(212) 801-9294
cc :
Copyright 1996 Legalsoft P10A/i2EV0i

ATTY DOCKET NO . SERIAL NO.

0 1P SUPPLEMENTAI. 150-061A. 09/232,908
INFORM ION DISCLOSURE %.,iTATION APPLICANT(S)
several sheets if necessary) # Hudetzetal.
MAY O 5 2000"1
FILING DATE GROUP ..~
January 15, 1999 3
TRADEMPQ U .S . PATENT DOCUMENTS V 0
'EXAMINER DOCUMENT NUMBER DATE NAME CLASS SUBCLASS FILI ATE C

INITIAL IF APPROPRI
5,905,251 05/18/99 Knowles Z, b i
5,913,210 06/15/99 Call
~L 5,918,214 06/29/99 Perkowski
5,932,863 08/03/99 Rathus et al.
5,938,726 08/17/99 Reber et al.

,
r O
f^~ 5,940,595 08/17/99 Reber et al . Z /
5,950,173 09/07/99 Perkowski
5,971,277 10/26/99 Cragun et al. ~6~t cj
~– 5,995,105 11/30/99 Reber et al.
6,012,102 01/04/2000 Shachar
6,027,024 02/22/2000 Knowles D f

COUNTRY CLASS SUBCLASS TRANSLATION

DOCUMENT NUMBER DATE
YES NO
OTHER DOCUMENTS (Including Author, Title, Date, Pertinent Pages, Etc .)

Fachhochschule Bielefeld, University of AVplied Sciences, Hochschulbibliothek~, J
I
Pages 1-27
Fac hochschule Bielefeld= _University Applied Sciences, ochschulbibliot ek G

-~AVA"O'
EXAMINER DATE CONSIDERED
'EXAMINER : Initial if reference considered, / he r or not citation is in conformance with MPEP 609 ; Draw line .through citation If not in conformance and not
considered. Include copy of this fommunication to applicant .
WIt
Form PTO-AS20 P09C/REV03 Patent and Trademark Office' U .S. DEPARTMENT OF COMMERCE
(also form PTO-1449) (((~~~
PAGE 1 OF 1

HTML Version from RFC Dr ment Page 1 of 27 I
Fachhochschule- Bielefeld
University of Applied Sciences
Network Working Group P . Mockap

Request for Comments : 882
November
DOMAIN NAMES - CONCEPTS and FACILITIES
This RFC introduces domain style names, their use

for ARPA Internet mail and host address support,
and the protocols and servers used to implement
domain name facilities.
This memo describes .the conceptual framework of the

domain system and some uses, but it omits many
uses, fields, and implementation details . A
complete specification of formats, timeouts, etc.
is presented in RFC 883, "Domain Names -
Implementation and Specification" . That RFC
assumes that the reader is familiar with the
concepts discussed in this memo.
r t
INTRODUCTION
The need for domain names
As applications grow to span multiple hosts, then networks!, a

finally internets, these applications must also span multiple
administrative boundaries and related methods of operation!
(protocols, data formats, etc) . The number of resources (for
example mailboxes), the number of locations for resources,!an
diversity of such an environment cause formidable problems wh
wish to create consistent methods for referencing particular
resources that are similar but scattered throughout the
environment.
The ARPA Internet illustrates the size-related problems ; it i

large system and is likely to grow much larger . The need to
a mapping between host names (e .g ., USC-ISIF) and ARPA Intern
addresses (e .g ., 10 .2 .0 .52) is beginning to stress the existi
mechanisms . Currently hosts in the ARPA Internet are registe
with-the Network Information Center (NIC) and listed in a glo
table (available as the file <NETINFO>HOSTS .TXT on the SRI-NI
host) [1] . The size of this table, and especially the freque
of updates to the table are near the limit of manageability.
is needed is a distributed database that performs the same'
function, and hence avoids the problems caused by a centra .liz
database.
The problem for computer mail is more severe . While mail sys
implementers long ago recognized the impossibility of central
Mockapetris [Pa
http://www-bib . fll-bielefeld . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC Df ment Page 2 of 27
RFC 882 November

Domain Names - Concepts and Facil
mailbox names, they have also created an increasingly large a

irregular set of methods for identifying the location of a
mailbox . Some of these methods involve the use of routes and
forwarding hosts as part of the mail destination address, and
consequently force the mail user to know multiple address for
the capabilities of various forwarders, and ad hoc tricks for
passing address specifications through intermediaries.
These problems have common characteristics that suggest the n

of any solution:
The basic need is for a consistent name space which will b

used for referring to resources . In order to avoid the
problems caused by ad hoc encodings, names should not cont
addresses, routes, or similar information as part of the n
The sheer size of the database and frequency of updates su

that it must be maintained in a distributed manner, with 1
caching to improve performance . Approaches that attempt t
collect a consistent copy of the entire database will beco
more and more expensive and difficult, and hence should be
avoided . The same principle holds for the structure of th
name space, and in particular mechanisms for creating and
deleting names ; these should also be distributed.
The costs of implementing such a facility dictate that it

generally useful, and not restricted to a single applic , ati
We should be able to use names to retrieve host addresses,
mailbox data, and other as yet undetermined information.
Because we want the name space to be useful in dissimilar

networks, it is unlikely that all users of domain names' wi
able to agree on the set of resources or resource informat
that names will be used to retrieve . Hence names refer to
set of resources, and queries contain resource identifiers
The only standard types of information that we expect to s
throughout the name space is structuring information for t
name space itself, and resources that are described using
domain names and no nonstandard data.
We also want the name server transactions to be independen

the communications system that carries them . Some systems
wish to use datagrams for simple queries and responses, an
only establish virtual circuits for transactions that need
reliability (e .g . database updates, long transactions) ; of
systems will use virtual circuits exclusively.
Mockapetris [Pa
RFC 882 November

Elements of the solution
The proposed solution has three major components:
The DOMAIN NAME SPACE, which is a specification for a tree

structured name space . Conceptually, each node and leaf o.
http://www-bib .fh-blelefeld .de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC Dc ment Page 3 of 27
domain name space tree names a set of information, , and que

operations are attempts to extract specific types of
information from a particular set . A query names the doma
name of interest and describes the type of resource inform
that is desired . For example, the ARPA Internet uses some
its domain names to identify hosts ; queries for address
resources return ARPA Internet host addresses . However, t
preserve the generality of the domain mechanism, domain na
are not required to have a one-to-one correspondence with
names, host addresses, or any other type of information.
NAME SERVERS are server programs which hold information ab

the domain tree's structure and set information . A name s
may cache structure or set information about any part of t
domain tree, but in general a particular name server has
complete information about a subset of the domain space, a
pointers to other name servers that can be used to lead to
information from any part of the domain tree . Name server
know the parts of the domain tree for which they have comp
information ; these parts are called ZONES ; a name server i
AUTHORITY for these parts of the name space.
RESOLVERS are programs that extract information from name

servers in response to user requests . Resolvers must be a
to access-at least one name server and use that name serve
information to answer a query directly, or pursue the quer
using referrals to other name servers . A resolver will
typically be a system routine that is directly accessible
user programs ; hence no protocol is necessary between the
resolver and the user program.
These three components roughly correspond to the three layers

views of the domain system:
From the user's point of view, the domain system is access

through simple procedure or OS calls to resolvers . The do
space consists of a single tree and the user can request
information from any section of the tree.
From the resolver's point of view, the domain system is;

composed of an unknown number of name servers . Each name
server has one or more pieces of the whole domain tree 's d
Mockapetris '[Pa
_ _._ -:
RFC 882 November
but the resolver views each of these databases as essentia

static.
From a name server's point of view, the domain system cons.

of separate sets of local information called zones . The n
server has local copies of some of the zones .' The name .se
must periodically refresh its zones from master copies in
--files or foreign name servers . The name server must
concurrently process queries that arrive from resolvers 'us
the local zones.
In the interests of performance, these layers blur a bit . `Fo

example, resolvers on the same machine as a name server may s
a database and may also introduce foreign information for use
later queries . This cached information is treated differentl
from the authoritative data in zones.
http ://www-bib .fli-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC D , lment Page 4 of 27
Database model
The organization of the domain system derives from some

assumptions about the needs and usage patterns of its user
community and is designed to avoid many of the the complicate
problems found in general purpose . database systems.
The assumptions are:
The size of the total database will initially be proportio

to the number of hosts using the system, but will eventual
grow to be proportional to the number of users on those ho
as mailboxes and other information are added to the domain
system.
Most of the data in the system will change very slowly (e.
mailbox bindings, host addresses), but that the system sho
be able to deal with subsets that change more rapidly (on
order of minutes).
The administrative boundaries used to distribute responsib

for the database will usually correspond to organizations
have one or more hosts . Each organization that has
responsibility for a particular set of domains will provid
redundant name servers, either on the organization - s,own h
or other hosts that the organization arranges to use.
Clients of the domain system should be able to identify tr

name servers they prefer to use before accepting referrals
name servers outside of this "trusted" set.
Access to information is more critical than instantaneous
Mockapetris [Pa
_ _ :::.
RFC 882 November
updates or guarantees of consistency . Hence the update pr

allows updates to percolate out though the users of the do
system rather than guaranteeing that all copies are
simultaneously updated . When updates are unavailable due
network or host failure, the usual course is to believe of
information while continuing efforts to update it . The ge
model is that copies are distributed with timeouts fors
refreshing . The distributor sets the timeout value and th
recipient of the distribution is responsible for performin
refresh . In special situations, very short intervals can
specified, or the owner can prohibit copies.
Some users will wish to access the database via datagrams;

others will prefer virtual circuits . The domain system is
designed so that simple queries and responses can use eith
style, although refreshing operations need the reliability
virtual circuits . The same overall message format is used
all communication . The domain system does not assume any
,special properties of the communications system, and hence
could be used with any datagram or virtual circuit protoco
In any system that has a distributed database, a particula

name server may be presented with a query that can only be
answered by some other server . The two general approaches
dealing with this problem are "recursive", in which the fi
server pursues the query for the client at another server;
"iterative", in which the server refers the client to anot
server and lets the client pursue the query . Both approac
http ://www-bib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC D , ~ment Page 5 of 27
have advantages and disadvantages, but the iterative appro

is 'preferred for the datagram style of access . The domain
system requires-implementation of the iterative approach,
allows the recursive approach as an option . The optional
recursive style is discussed in [141, and omitted from fur
discussion in this memo .,
The domain system assumes that all data originates in master

scattered through the hosts that use the domain system . Thes
master files are updated by local system administrators . Mas
files are text files that are read by a local name server, an
hence become available to users of the domain system . A stan
format for these files is given in [141.
The standard format allows these files to be exchanged betwee

hosts (via FTP, mail, . or some other mechanism) ; this facility
useful when an organization wants a domain, but doesn't want
support a name server . The organization can maintain the mas
files locally using a text editor, transfer them to a foreign
which runs a name server, and then arrange with the system
administrator of the name server to get the files loaded .'
Mockapetris _[_Pa.
RFC 882 November
Each host ' s name servers and resolvers are configured by a to

system administrator . For a name server, this configuration
includes the identity of local master files and instructions
which non-local master files are to be loaded from foreign
servers . The name server uses the master files or copies . to
its zones . For resolvers, the configuration data identifies
name servers which should be the primary sources of informati
The domain system defines procedures for accessing the data a

for referrals to other name servers . The domain system also
defines procedures for caching retrieved data and for periodi
refreshing of data defined by the system administrator.
The system administrators provide:
The definition of zone boundaries
Master files of data
Updates to master files
Statements of the refresh policies desired
The domain system provides:
Standard formats for resource data
Standard methods for querying the database
Standard methods for name servers to refresh local data fr

foreign name servers
DOMAIN NAME SPACE
Name space specifications and terminology
The domain name space is a tree structure . Each node and'lea

the tree corresponds to a resource set (which may be empty) .:
node and leaf has an associated label . Labels are NOT guaran
http ://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html~ 5/1/00

HTML Version from RFC Dr ment Page 6 of 27
to be unique, with the exception of the root node, which has

null label . The domain name of a node or leaf is the path fr
the root of the tree to the node or leaf . By convention, the
labels that compose a domain name are read left to right, fro
most specific (lowest) to the least specific (highest).
Internally, programs that manipulate domain names represent t

as sequences of labels, where each label is a length octet
followed by an octet string . Because all domain names end at
root, which has a null string for a label, these internal
Mockapetris [Pa
............................ . .......... .................................. ... ..... ...... ....... ...................... ........... .................. .................. ......................... ...................... ............... _ _
RFC 882 November
representations can use a length byte of zero to terminate a

domain name . When domain names are printed, labels in a path
separated by dots The root label and its associated d
are omitted from printed domain names, but the root can be na
by a null domain name in this memo).
To simplify implementations, the total number of octets that

represent label octets and label lengths is limited to 255.
a printed domain name can be up to 254 characters.
A special label is defined that matches any other label . Thi

label is the asterisk or "*" . An asterisk matches a single 1
Thus * .ARPA matches FOO .ARPA, but does not match FOO .BAR .ARPA
The asterisk is mainly used to create default resource record
the boundary between protocol families, and requires prudence
its use.
A domain is identified by a domain name, and consists of that

of the domain name space that is at or below the domain name
specifies the domain . A domain is a subdomain of another dom
if it is contained within that domain . This relationship can
tested by seeing if the subdomain's name has the containing
domain's name as the right part of its name . For example,] A.
is a subdomain of B .C .D, C .D, D, and " ".
This tree structure is intended to parallel the administrativ

organization and delegation of authority . Potentially, each
or leaf on the tree can create new subdomains ad infinitum.
practice, this delegation can be limited by the administrator
the name servers that manage the domain space and .resource' da
The following figure shows an example of a domain name space.
+ + +
COLORS FLAVORS TRUTH
+ +
I I I NATURAL
RED BLUE GREEN
+
I I I
CHOCOLATE VANILLA STRAWBERRY
In this example, the root domain has three immediate subdomai

COLORS, FLAVORS, and TRUTH . The FLAVORS domain has one immed
subdomain named NATURAL .FLAVORS . All of the leaves are also',
http ://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC D, iment Page 7 of 27
Mockapetris [Pa
RFC 882 November

domains . This domain tree has the names 11 "(the root), COLOR
RED .COLORS, BLUE .COLORS, GREEN .COLORS, FLAVORS, NATURAL .FLAVO
CHOCOLATE .NATURAL .FLAVORS, VANILLA .NATURAL .FLAVORS,
STRAWBERRY .NATURAL .FLAVORS, and TRUTH . If we wished to add a
domain of ARTIFICIAL under FLAVORS, FLAVORS would typically b
administrative entity that would decide ; if we wished to crea
CHIP and MOCHA names under CHOCOLATE, CHOCOLATE .NATURAL .FLAVO
would typically be the appropriate administrative entity.
Resource set information
A domain name identifies a set of resource information . The

of resource information associated with a particular name is
composed of separate resource records (RRs).
Each resource record has the following major components:
The domain name which identifies resource set that holds t

record, and hence the "owner" of the information . For exa
a RR that specifies a host address has a domain name the
specifies the host having that address . Thus F .ISI .ARPA m
be the owner of a RR which specified an address field of
10 .2 .0 .52 . Since name servers typically store their resou
information in tree structures paralleling the organizatio
the domain space, this information can usually be stored
implicitly in the database ; however it is always included
each resource record carried in a message.
Other information used to manage the RR, such as length fi

timeouts, etc . This information is omitted in much of'thi
memo, but is discussed in [14].
A resource type field that specifies the type of the resou

in this resource record . Types refer to abstract resource
such as host addresses or mail delivery agents . The type
is two octets long and uses an encoding that is standard
throughout the domain name system.
A class field identifies the format of the resource data,

as the ARPA Internet format (IN) or the Computer Science
Network format (CSNET), for certain RR types (such as addr
data) . Note.that while the class may separate different
protocol families, networks, etc . it does not do so in,'all
cases . For example, the IN class uses 32 bit IP- addresses
exclusively, but the CSNET class uses 32 bit IP addresses,
addresses, and phone numbers . Thus the class field should
used as a guide for interpreting the resource data . The c
field is two octets long and uses an encoding, that is stan
throughout the domain name system.
Mockapetris [Pa
RFC 882 November

Resource data that describes the resource . The format,of'

data can be determined given the type and class fieldsi bu
always starts with a two octet length field that allows a
server or resolver to determine the boundaries of the reso
http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC D( ~ment Page 8 of 27
data in any transaction, even if it cannot "understand" th

res'burce data itself . Thus name servers and resolvers can
and pass on records which they cannot interpret . The form
the internal data is restricted only by the maximum length
65535 octets ; for example the host address record might sp
a fixed 32 bit number for one class, and a variable length
of addresses in another class.
While the class field in effect partitions the resource data

the domain name system into separate parallel sections accord
to class, services can span class boundaries if they use
compatible resource data formats . For example, the domain na
system uses compatible formats for structure information, and
mail data decouples mail agent identification from details of
to contact the agent (e .g . host addresses).
This memo uses the following types in its examples:
A - the host address associated with the domain name
MF - identifies a mail forwarder for the domain
MD - identifies a mail destination for the domain
NS - the authoritative name server for the domain
SOA - identifies the start of a zone of authority
CNAME - identifies the canonical name of an alias.
This memo uses the following classes in its examples:
IN - the ARPA Internet system
CS - the CSNET system
The first type of resource record holds a host name to host

address binding . Its fields are:
+ + + + //
I<owner> I A I <class>I <class specific address>information
+ + + + //
Mockapetris [Pa
_
_ _
RFC 882 November
The content of the class specific information varies accordin

the value in the CLASS field ; for the ARPA Internet, it is th
bit ARPA Internet address of the host, for the CSNET it might
the phone number of the host . For example, F .ISI .ARPA might
two A records of the form:
+ + + + +
IF-.ISI .ARPAI A I IN I 10 .2.0 .52 I
+ + + + =-+`
and
+ + + + +
IF .ISI .ARPAI A I CS I 213-822-2112 I
+ + + + +'
Note that the data formats for the A type are class dependent
5http ://www-bib
/1/00 .fh-bielefeld.de/epub/doc/idoc/rfc/rfe-0800-0899/rfc882 .html l

HTML Version from RFC D- ~iment Page 9 of 27
the Internet address and phone number formats shown above are
purposes of illustration only . The actual data formats are
specified in [14) . For example, CS class data for type A rec
might actually be a list of Internet addresses, phone numbers
TELENET addresses.
The mail forwarder (MF) and mail delivery (MD) records have t
following format:
+ + + + +
I<owner> I MD/MF I < class >I . <domain name>
+ + + + +
The <domain name> field is a domain name of the host that wil
handle mail ; note that this domain name may be . completely
different from the - domain name which names the resource recor
For example, F .ISI .ARPA might have two records of the form:
+ + + + +
IF .ISI .ARPAI MD I IN I F .ISI .ARPA I
+ + + + +
and
+ + + + +
IF .ISI .ARPAI MF I IN I B .ISI .ARPA I
+ + + + +
These records .mean that mail for F .ISI .ARPA can either be
delivered to the host F .ISI .ARPA or forwarded to B .ISI .ARPA,
will accept responsibility for its eventual delivery . In
principle, an additional name lookup is required to map the d
name of the host ' to the appropriate address, in practice this
information is usually returned in the response to the mail q
The SOA and NS types of resource records are used to define 1
Mockapetris (Pag_ ,
RFC 882 November

of authority . The domain name given by the owner field of a

record is the start of a zone ; the domain name given by the o
field of a NS record identifies a point in the name spaceiwhe
authority has been delegated, and hence marks the zone bounda
Except in the case where a name server delegates authority to
itself, the SOA identifies the top limit of authority, and NS
records define the first name outside of a zone . These resou
records have a standard format for all of the name space:
+ . + + + +
I <owner> I SOA I <class>I <domain name, etc> I
+ + + + +
+ + + +
I <owner> I NS I <class>I <domain name> I
+ + + + +
The-SOA record marks the start of a zone when - it is present i

database ; the NS record both marks the end of a zone started
SOA (if a higher SOA is,present) and also points to a name se
that has a copy of the zone specified by the <owner . field of
NS record.
The <domain name, etc> in the SOA record specifies the origin
source of the information in the zone and other information u
by name servers to organize their activities . SOA records ar
http ://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC Df ment Page 10 of 27
never cached (otherwise they would create false zones) ; they

only be created in special name server maintenance operations
The NS record says that a name server which is authoritative

records of the given CLASS can be found at <domain name>.
Queries
Queries to a name server must include a domain name which

identifies the target resource set (QNAME), and the type and
of desired resource records . The type and class fields in a
can include any of the corresponding type and class fields th
are defined for resource records ; in addition, the query type
(QTYPE) and query class (QCLASS) fields may contain special v
that match more than one of the corresponding fields in RRs.
For example, the QTYPE field may contain:
MAILA - matches all mail agent RRs (e .g . MD and MF).
* - matches any RR type.
Mockapetris [Pag
_
RFC 882 November
Domain Names - .Concepts and Facil
The QCLASS field may contain:
* - matches any RR class.
Using the query domain name, QTYPE, and QCLASS, the name sery
looks for matching RRs . In addition to relevant records, the
server may return RRs that point toward a name server that ha
desired information or.,RRs that are expected to be usefullin
interpreting the relevant RRs . . For example a name server ;tha
doesn't have the requested information may know a name server
does ; a name server that returns a domain name in a relevant
may also return the RR that binds that domain name to an addr
Note that the QCLASS=* construct requires special interpretat

regarding authority . Since a name server may not know all of
classes available in the domain system, it can never know if
authoritative for all classes . Hence responses to QCLASS=*
queries can never be authoritative.
Example space
For purposes of exposition, the following name space is used

.the remainder of this memo:
+ + +
DDN ARPA CSNET
+ + + + +----=+
JCS ARMY NAVY UDEL UCI
+ + + + +
DTI MIT ISI UDEL NBS
http ://www-bib .fh-bielefeld.de/epub/doc/idoe/rfe/rfe-0800-0899/r-fc882.html 511100

HTML Version from RFC Dc --i .ment Page 11 of 27
+---+---+
DMS AI A B F
Mockapetris [Pag_
_ _- - .
RFC 882 November

NAME SERVERS
Introduction
Name servers store a distributed database consisting of the

structure of the domain name space, the resource sets associa
with domain names, and other information used to coordinate
actions between name servers.
In general, a name server will be an authority for all or par

a particular domain . The region covered by this authority is
called a zone . Name servers may be responsible for no
authoritative data, and hence have no zones, or may have seve
zones . when a name server has multiple zones, the zones may
no common borders or zones may be contiguous.
While administrators should not construct overlapping zones,
name servers must defend against overlapping zones, overlappi
regarded as a non-fatal flaw in the database . Hence the meas
taken to protect against it are omitted for the remainder of
memo . A detailed discussion can be found in [14].
when presented with a query for a domain name over which it h

authority, a name server returns the desired resource informa
or an indication that the query refers to a domain name or
resource that does not exist . If a name server is presented
a query for a domain name that is not within its authority, i
have the desired information, but it will also return a respo
that points toward an authoritative name server . If a name s
is not an authority for a query, it can never return a negati
response.
There is no requirement that a name server for a domain resid

a host which has a name in the same domain, although this wil
usually be the case . There is also no restriction on the num
of name servers that can have authority over a particular'dom
most domains will have redundant authoritative name servers.
assumption is that different authoritative copies are identic
even though inconsistencies are possible as updates are made.
Name server functions are designed to allow for very simple

implementations of name servers . The simplest name server ha
static set of information and uses datagrams to receive queri
and return responses.
More sophisticated name server implementations can improve th

performance of their clients by caching information from othe
domains . Although this information can be acquired in a numb
http ://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

ways, the .normal method is to store the information acquired
Mockapetris [Pag
RFC 882 November

resolver when the resolver consults other name servers . In a

sophisticated host, the resolver and name server will coordin
their actions and use a shared database . This cooperation
requires the incorporation of a time-to-live (TTL) field in a
cached resource records . Caching is discussed , in the resolve
section of this memo ; this section is devoted to the actions
name servers that don't cache.
In order to free simple name servers of the requirement of

managing these timeouts, simple name servers should only cont
resource records that are expected to remain constant over ve
long periods or resource records for which the name server is
authority . In the following discussion, the TTL field is ass
to be stored in the resource record but is omitted in descrip
of databases and responses in the interest of clarity.
Authority and administrative control of domains
Although we want to have the potential of delegating the

privileges of name space management at every node, we don ' t w
such delegation to be required.
Hence we introduce the concept of authority . Authority is've

in name servers . A name server has authority over all of its
domain until it delegates authority for a subdomain to some o
name server.
Any administrative entity that wishes to establish its own , do

must provide a name server, and have that server accepted,by
parent name server (i .e . the name server that has authority o
the place in the domain name space that will hold the new!dom
while the principles of authority allow acceptance to be at t
discretion of parent name servers, the following criteria ;are
by the root, and are recommended to all name servers because
are responsible for their children's actions:
1. It must register with the parent administrator of doma
2. It must identify a responsible person.
3. In must provide redundant name servers.
The domain name must be registered with the administrator to

name conflicts and to make the domain related information;
available to other domains . The central administrator may ha
further requirements, and a domain is not registered until th
central administrator agrees that all requirements are met.
There must be a responsible person associated with each domai
Mockapetris [Pag
RFC 882 November

be a contact point for questions about the domain, to verify ;.

update the domain related information, and to resolve any pro
http://www-bib .fh-bielefeld .de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882 .html 51110 0

HTML Version from RFC D- mment Page 13 of 27
(e .g ., protocol violations) with hosts in the domain.

The domain must provide redundant (i .e ., two or more) name se
to provide the name to address resolution service . These nam
servers must be accessible from outside the domain (as well a
inside) and must resolve names for at least all the hosts in
domain.
Once the central administrator is satisfied, he will communic

the existence to the appropriate administrators of other doma
so that they can incorporate NS records for the new name sery
into their databases.
Name server logic
The processing steps that a name server performs in respondin

a , query are conceptually simple, although implementations may
internal databases that are quite complex.
For purposes of explanation, we assume that the query consist

a type QTYPE, a class QCLASS, and a domain name QNAME ; we ass
that the name server stores its RRs in sets where each set ha
of the RRs for a particular domain . Note that this database
structure and .the following algorithms are meant to illustrat
possible implementation, rather than a specification .of how a
servers must be implemented.
The following notation is used:
ord(DOMAIN-NAME) returns the number of labels in DOMAIN-N
findset(DOMAIN-NAME) returns a pointer to the set of stored R

for DOMAIN-NAME, or NULL if there is no
information.
set(POINTER) refers to a set located previously by

findset, where POINTER is the value retu
by findset.
relevant(QTYPE,TYPE) returns true if a RR of the specified TY

relevant to the specified QTYPE . For
example, relevant(MAILA,MF) is true and
relevant(MAILA,NS) is false.
right(NAME,NUMBER) returns a domain name that is the rightm

NUMBER labels in the string NAME.
Mockapetris [Pag
RFC 882 November

copy(RR) copies the resource record specifiediby

into the response.
The name server code could be represented as the following

sequence of steps:
{ find out whether the database makes this server

authoritative for the domain name specified by QNAME
for is=0 to ord(QNAME) { sequence through all nodes in QNAME }

do begin
ptr :=findset(right(QNAME,i));
if ptr<>NULL
http ://www-bib .fh-bielef6ld.de/epub/doe/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC D- ment Page 14 of 27
then { there is domain data for this domain name }

begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr :=ptr
end;
do if type(RR)=SOA and class(RR)=QCLASS
then auth :=true
end
end ; i
end;
{ copy out authority search results }
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
{ Copy all RRs that answer the question }

do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);
The first section of the code (delimited by the for loop over .
Mockapetris [Pag
...... ......
RFC 882 November
of the subnodes of QNAME) discovers whether the name server i

authoritative for the domain specified by QNAME . It sequence
through all containing domains of QNAME, starting at the 'root
it encounters a SOA it knows that the name server is authorit
unless it finds a lower NS RR which delegates authority . If
name server is authoritative, it sets auth=true ; if the name
server . is not authoritative, it sets NSptr to point to the se
which contains the NS RR closest to the domain specified by Q
The second section of the code reflects the result of the

authority search into the response . If the name server is
authoritative, the code checks to see that the domain specifi
QNAME exists ; if not, a name error is returned . If the name
server is not authoritative, the code copies the RRs for a cl
name server into the response.
The last section of the code copies all relevant RRs into•the
response.
Note that this code is not meant as an actual implementation'.

is incomplete in several aspects . For example, it doesn't de
with providing additional information, wildcards, QCLASS=*, o
with overlapping zones . The first two of these issues are de
with in the following discussions, the remaining issues are
i
http ://www-bib .fli-bielefeld.de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

's;
discussed in [14].
Additional information
When a resolver returns information to a user program, the

returned information will often lead to a second query . For
example, if a mailer asks a resolver for the appropriate mail
agent for a particular domain name, the name server queried b
resolver returns a domain name-that identifies the agent . In
general, we would expect that the mailer would then request t
domain name to address binding for the mail agent, and a new
server query would result.
To avoid this duplication of effort, name servers return

additional information with a response which satisfies the
anticipated query . This information is kept in a separate se
of the response . Name servers .are required to complete the
appropriate additional information if such information is
available, but the requestor should not depend on the presenc
the information since the name server may not have it . If th
resolver caches the additional information, it can respond to
second query without an additional network transaction.
The appropriate information is defined in [14], but generally
Mockapetris
RFC 8-82 November

consists of host to address bindings for domain names in retu

RRs.
Aliases and canonical names
In existing systems, hosts and , other resources often have sev

names that identify the same resource . For example, under cu
ARPA Internet naming support, USC-ISIF and ISIF both identify
same host . Similarly, in the case of mailboxes, many
organizations provide many names that actually go to the same
mailbox ; for example Mockapetris@ISIF, Mockapetris@ISIB, etc.
go to the same mailbox (although the mechanism behind this is
somewhat complicated).
Most of these systems have a notion that one of the equivalen

of names is the canonical name and all others are aliases:
The domain system provides a similar feature using the canoni

name ' (CNAME) RR . When a name server fails to find a desired
a set associated with some domain name, it checks to see if t
resource set contains a CNAME record with a matching class.
so, the name server includes the CNAME record in the response
continues the query at the domain name specified in the data
of the CNAME record.
Suppose a name server was processing a query with QNAME=ISIF:

QTYPE=A, and QCLASS=IN, and had the following resource-record
ISIF .ARPA CNAME IN F .ISI .ARPA

F .ISI .ARPA A IN 10 .2 .0 .52
Both of these RRs would be returned in the response
In the above example, because ISIF .ARPA has no RRs other than
CNAME RR, the resources associated with ISIF .ARPA will appear
http ://www-bib . fl7-bielefeld . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5/ 1 /00

.F,
HTML Version from RFC Dc -ment Page 16 of 27
be exactly those associated with F .ISI .ARPA for the IN CLASS.

Since the CNAME is effective only when the search fails, a CN
can also be used to construct defaults . For example, suppose
name server had the following set of RRs:
F .ISI .ARPA A IN 10 .2 .0 .52

F .ISI .ARPA MD IN F .ISI .ARPA
XXXX .ARPA CNAME IN F .ISI .ARPA
XXXX .ARPA MF IN A .ISI .ARPA
Using this database, type A queries for XXXX .ARPA would retur
XXXX .ARPA CNAME RR and the F .ISI .ARPA A RR, but MAILA or MF
queries to XXXX .ARPA would return the XXXX .ARPA MF RR without
information from F .-ISI .ARPA . This structure might be used to
Mockapetris [Pag_
.
RFC 882 November
mail addressed to XXXX .ARPA to A .ISI .ARPA and to direct TELNE

XXXX .ARPA to F .ISI .ARPA.
Wildcards
In certain cases, an administrator may wish to associate defa

resource information for all or part of a domain . For exampl
the CSNET domain administrator may wish to establish IN class
forwarding for all hosts in the CSNET domain without IN
capability . In such a case, the domain system provides a spe
label "*" that matches any other label . Note that "*" matche
only a single label, and not zero or more than one label . No
also that the "*" is distinct from the "*" values for QCLASS
QTYPE.
The semantics of "*" depend upon whether it appears in a quer

domain name (QNAME) or in a RR in a database.
When an "*" is used in a QNAME, it can only match a "*" in

resource record.
When "*" appears in a RR in a database, it can never overr

an existing exact match . For example, if a name server
received a query for the domain UDEL .CSNET, and had approp
RRs for both UDEL .CSNET and * .CSNET, the UDEL .CSNET RRs wo
be used and the * .CSNET RRs would be ignored . If a query
the same database specified FOO .CSNET, the * .CSNET RR woul
used, but"the corresponding labels from the QNAME would re
the "*" . Thus the FOO .CSNET query would match the * .CSNET
and return a RR for FOO .CSNET rather than * .CSNET.
RRs containing "*" labels are copied exactly when zones ar

transfered via name server maintenance operations.
These semantics are easily implemented by having the name ser

first search for an exact match for a query,-and then replaci
the leftmost label with a "*" and trying again, repeating the
process until all labels became "*" or the search succeeded.
TYPE=* in RRs is prohibited . If it were to be allowed, the

requestor would have no way of interpreting the data in the R
because this data is type dependent.
CLASS=* is also prohibited . Similar effects can be achieved

QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
complexities without apparent benefit.
http ://www-bib . fh-bielefeld . de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 511100

's,
HTML Version from RFC Dc -mehi Page 17 of 27
Mockapetris [P a~g
RFC 882 November

A scenario
In our sample domain space, suppose we wanted separate

administrative control for-the root, DDN, ARPA, CSNET, MIT an
domains . we might allocate name servers as follows:
(B .ISI .ARPA)
I (UDEL .CSNET)
+ + +
DDN ARPA CSNET

I(JCS .DDN) (F .ISI .ARPA) I(UDEL .ARPA)
+ + + (A .ISI .ARPA)+ + +
I I I I I
JCS ARMY NAVY UDEL UCI
+ + + + +
DTI MIT ISI UDEL NBS

I(AI .MIT .ARPA) I(F .ISI .ARPA)
+---+---+
DMS AI A B F
In this example the authoritative name server is shown in,

parentheses at the point in the domain tree at which is assum
control.
Thus the root name servers are on B .ISI .ARPA and UDEL .CSNET,
DDN name server is on JCS .DDN, the CSNET domain server isjon
UDEL .ARPA, etc.
In an actual system, all domains should have redundant name

servers, but in this example only the ARPA domain has redunda
servers A .ISI .ARPA and F .ISI .ARPA . (The B .ISI .ARPA and UbEL.
name servers happen to be not redundant because they handle
different classes .) The F .ISI .ARPA name server has authority
the ARPA domain, but delegates authority over the MIT .ARPA do
to the name server on AI .MIT .ARPA . The A .ISI .ARPA name serve
also has authority over the ARPA domain, but delegates both t
ISI .ARPA and MIT .ARPA domains to other name servers.
http://www-bib .flz-bielefeld .de/epub/doe/idoe/rfc/rfc-0800-0899/rfc882 .html 511100

B .ISI .ARPA Name server for
B .ISI .ARPA has the root name server for the IN class . Its
database might contain : %
Domain Resource Record
" " SOA IN A .ISI .ARPA

DDN NS IN JCS .DDN
ARPA NS IN F .ISI .ARPA
CSNET NS IN UDEL .ARPA
" " NS IN B .ISI .ARPA
" NS CS UDEL .CSNET
JCS .DDN A IN 9 .0 .0 .1
F .ISI .ARPA A IN 10 .2 .0 .52
UDEL .CSNET A CS 302-555-0000
UDEL .ARPA A IN 10 .0 .0 .96
The SOA record for the root is necessary so that the name ser
knows that it is authoritative for the root domain for class
The contents of-the SOA resource record point back to A .ISI .A
and denote that the master data for the zone of authority is
originally from this host . The first three NS records denote
delegation of authority . The NS root entry for the B .ISI .ARP
name server is necessary so that this name server knows about
itself, and can respond correctly to a query for NS informati
about the root (for which it is an authority) . The root entr
class CS denotes that UDEL .CSNET is the authoritative name se
for the CS class root . UDEL .CSNET and UDEL .ARPA may or may n
refer to the same name server ; from this information it is
impossible to tell.
If this name server was sent a query specifying QTYPE=MAILA,

QCLASS=IN, QNAME=F .ISI .ARPA, it would begin processing (using
previous algorithm) by determining that it was not an authori
for F .ISI .ARPA . The test would note that it had authoritylat
but would also note that the authority was delegated at ARPA
never reestablished via another SOA . Thus the response would
return the NS record for the domain ARPA.
Any queries presented to this server with QCLASS=CS would 'res

in the UDEL .CSNET NS record being returned in the response.
Mockapetris [Pag
RFC 882 November

F .ISI .ARPA Name server for ARPA and ISI .ARPA
In the same domain space, the F .ISI .ARPA database for the dom
ARPA and ISI .ARPA might be:
Domain Resource Record
NS IN B .ISI .ARPA
NS CS CSNET .UDEL
ARPA SOA IN B .ISI .ARPA
ARPA NS IN A .ISI .ARPA
http://www-bib . fli-bielefeld . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

ARPA NS IN F .ISI .ARPA

MIT .ARPA NS IN AI .MIT .ARPA
ISI .ARPA SOA IN F .ISI .ARPA
ISI .ARPA NS IN F .ISI .ARPA
A .ISI .ARPA MD IN A .ISI .ARPA

ISI .ARPA MD IN F .ISI .ARPA
A .ISI .ARPA MF IN F .ISI .ARPA
B .ISI .ARPA MD IN B .ISI .ARPA
B .ISI .ARPA MF IN F .ISI .ARPA
F .ISI .ARPA MF IN A .ISI .ARPA
DTI .ARPA MD IN DTI .ARPA
NBS .ARPA MD IN NBS .ARPA
UDEL .ARPA MD IN UDEL .ARPA
A .ISI .ARPA A IN 10 .1 .0 .32

F .ISI .ARPA A IN 10 .2 .0 .52
B .ISI .ARPA A IN 10 .3 .0 .52
DTI .ARPA A IN 10 .0 .0 .12
AI .MIT .ARPA A IN 10 .2 .0 .6
DMS .MIT .ARPA A IN 10 .1 .0 .6
NBS .ARPA A IN 10 .0 .0 .19
UDEL .ARPA A IN 10 .0 .0 .96
For the IN class, the SOA RR for ARPA denotes that this name
server is authoritative .for the domain ARPA, and that the mas
file for this authority is stored on B .ISI .ARPA . This zone
extends to ISI .ARPA, where the database delegates authority b
to this name server in another zone, and doesn't include the
domain MIT .ARPA, which is served by a name server on AI .MIT .A
This name server is not authoritative for any data in the CS

class . It has a pointer to the root server for CS data which
could be use to resolve CS class queries.
Suppose this name server received a query of the form

QNAME=A .ISI .ARPA, QTYPE=A, and QCLASS=IN . The authority sear
Mockapetris [Pa
_ ...9_ ..
RFC 882 November

would notice the NS record for " 11 , its SOA at ARPA, a delega
at ISI .ARPA, and the reassumption of authority at ISI .ARPA.
it would know that it was an authority for this query . It wo
then find the A record for A .ISI .ARPA, and return a datagram
containing this record.
Another query might be QNAME=B .ISI .ARPA, QTYPE=MAILA, QCLASS=

In this case the name server would know that it scannot be
authoritative because of the "*" value of QCLASS, and would 1
for records for domain B .ISI .ARPA that match . Assuming that.
name server performs the additional record inclusion mentione
the--name server algorithm, the returned datagram would includ
ISI .ARPA NS IN F .ISI .ARPA

" If
NS CS UDEL .CSNET
B .ISI .ARPA MD IN B .ISI .ARPA
B .ISI .ARPA MF IN F .ISI- .ARPA
B .ISI .ARPA A IN 10 .3 .0 .52
F .ISI .ARPA A IN 10 .2 .0 .52
If the query were QNAME=DMS .MIT .ARPA, QTYPE=MAILA, QCLASS=IN,

name server would discover that AI .MIT .ARPA was the authorita
http://www-bib .fh-blelefeld .de/epub/doo/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC D~ -ment Page 20 of 27

K
name server and return the following:
MIT .ARPA NS IN AI .MIT .ARPA

AI .MIT .ARPA A IN 10 .2 .0 .6
In this case, the requestor is directed to seek information f

the MIT .ARPA domain name server residing on AI .MIT .ARPA.
Mockapetris [Pa 9_
. ............. ............... . .... .................... —
RFC 882 November

UDEL .ARPA and UDEL .CSNET name server
In the previous discussion of the sample domain, we stated th

UDEL .CSNET and UDEL .ARPA might be the same name server . ;In t
example, we assume that this is the case . As such, the name
server is an authority for the root for class CS, and an ' auth
for the CSNET domain for class IN.
This name server deals with mail forwarding between the ARPA
Internet and CSNET systems . Its RRs illustrate one approach
solving this problem . The name server has the following ;reso
records:
" SOA CS UDEL .CSNET

" NS CS UDEL .CSNET
NS IN B .ISI .ARPA
CSNET SOA IN UDEL .ARPA
CSNET NS IN UDEL .ARPA
ARPA NS IN A .ISI .ARPA
* .CSNET MF IN UDEL .ARPA

UDEL .CSNET MD CS UDEL .CSNET
UCI .CSNET MD CS UCI .CSNET
UDEL .ARPA MD IN UDEL .ARPA
B .ISI .ARPA A IN 10 .3 .0 .52

UDEL .ARPA A IN 10 .0 .0 .96
UDEL .CSNET A CS 302-555-0000
UCI .CSNET A CS 714-555-0000
Suppose this name server received a query of the form

QNAME=UCI .CSNET, QTYPE=MAILA, and QCLASS=IN . The name _ .server
would discover it was authoritative for the CSNET domain unde
http ://www-bib . fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC D- ~ment Page 21 of 27
class IN, but would find no explicit mail data for UCI .CSNET.
However, .using the * .CSNET record, it would construct a reply
UCI .CSNET MF IN UDEL .ARPA

UDEL .ARPA A IN 10 .0 .0 .96
If this name server received a query of the form QNAME=UCI .CS

QTYPE=MAILA, and QCLASS=CS, the name server would return:
UCI .CSNET MD CS UCI .CSNET

UCI .CSNET A CS 714-555-0000
Note that although this scheme allows for forwarding of all m

addressed as <anything> .CSNET, it doesn't help with names tha
have more than two components, e .g . A .B .CSNET . Although this
problem could be "fixed" by a series of MF entries for * .* .CS
Mockapetris [Pag
RFC 882 November

* .* .* .CSNET, etc, a more tasteful solution would be to introd

cleverer pattern matching algorithm in the CSNET name server.
Summary of requirements for name servers
The requirements for a name server are as follows:
1. It must be recognized by its parent.
2. It must have complete resource information for all doma

names for which it is the authority.
3. It must periodically refresh authoritative information

a master file or name server which holds the master.
4. If it caches information it must also handle TTL manage

for that information.
5. It must answer simple queries.
Inverse queries
Name servers may also support inverse queries that map &
particular resource to a domain name or domain names that hav
that resource . For example, while a query might map a domain
to a host address, the corresponding inverse query might map
address back to the domain name.
Implementation of this service is optional in a name server,

all name servers must at least be able to understand an'inver
query message and return an error response.
The domain system cannot guarantee the completeness or unique

of inverse queries because the domain system is organized by
domain name rather than by host address or any other resource
type . In general, a resolver or other program that wishes to
guarantee that an inverse query will work must use a name ser
that is known to have the appropriate data, or ask all name
servers in a domain of interest.
For example, if a resolver wishes to perform an inverse ;query

an arbitrary host on the ARPA Internet, it must consult~a set
name servers sufficient to know that all IN data was consider
In practice, a single inverse query tp a name server that has
http://www-bib .fll-bielefeld.de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC D- -iment Page 22 of 27

fi
fairly comprehensive database should satisfy the vast majorit

inverse queries.
A detailed discussion of inverse queries is contained in [14]
Mockapetris [Pag
RFC 882 November

Completion services
Some existing systems provide the ability to complete partial

specifications of arguments . The general principle is that t
user types the first few characters of the argument and then
an escape character to prompt the system to complete the rest
Some completion systems require that the user type enough of
argument to be unique ; others do not.
Other systems allow the user to specify one argument and ask
system to fill in other arguments . For example, many mail sy
allow the user to specify a username without a host for local
delivery.
The domain system defines name server completion transactions

perform the analogous service for the domain system.
Implementation of this service is optional in a name server,
all name servers must at least be able to understand a comple
request and return an error response.
when a resolver wishes to request a completion, it sends a na

server a message that sets QNAME to the partial string, QTYPE
the type of resource desired, and QCLASS to the desired class
The completion request also includes a RR for the target doma
The target domain RR identifies the preferred location of, the
resource . In completion requests, QNAME must still have ;a nu
label to terminate the name, but its presence is ignored . ', No
that a completion request is not a query, but shares some of
same field formats.
For example, a completion request might contain QTYPE=A, .QNAM

QCLASS=IN and a RR for ISI .ARPA . This request asks for compl
for a resource whose name begins with "B" and is "close"Ito
ISI .ARPA . This might be a typical shorthand used in theilSI
community which uses "B" as a way of referring to B .ISI .ARPA.
The first step in processing a completion request is to look

"whole label" match . When the name server receives the reque
mentioned above, it looks at all records that are of type A,
IN, and whose domain name starts (on the left) with the label
QNAME, in this case, "B" . If multiple records match, the nam
server selects those whose domain names match (from the right
most labels of the preferred domain name . If there are still
multiple candidates, the name server selects-the records that
the shortest (in terms of octets in the name) domain name . I
several records remain, then the name server returns them all
If no records are found in the previous algorithm, the name s

assumes that the rightmost label in QNAME is not complete, an
Mockapetris [Pag_
RFC 882 November

http: //www-bib . fli-bielefeld . de/epub/doe/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC D , -iment Page 23 of 27
looks for records that match but require addition of characte

the rightmost label of. QNAME . For example, the previous sear
would not match BB .ARPA to B, but this search would . If mult
hits are found, the same discarding strategy is followed.
A detailed discussion of completion can . be found in (14].
RESOLVERS
Introduction
Resolvers are programs that interface user programs to domain

servers . In the simplest Case, a resolver receives a request
a user program (e .g . mail programs, TELNET, FTP) in the form
subroutine call, system call etc ., and returns the desired
information in a form compatible with the local host's data
formats.
Because a resolver may need to consult several name servers,

amount of time that a resolver will take to complete can vary
This variance is part of the justification for the split betw
name servers and resolvers ; name servers may use datagrams an
have a response time that is essentially equal to network del
plus a short service time, while resolvers may take an essent
indeterminate amount of time.
We expect to see two types of resolvers : simple resolvers tha

chain through multiple name servers when required, and more
complicated resolvers that cache resource records for use in
future queries.
Simple resolvers
A simple resolver needs the following capabilities:
1. It must know how to access a name server, and should know

authoritative name server for the host that it services.
2. It must know the protocol capabilities for its clients :so

it can set the class fields of the queries it sends to ;ret
information that is useful to its clients . If the resolve
serves a client that has multiple protocol capabilities, i
should be able to support the preferences of the client.
The resolver for a multiple protocol client can either col

information for all classes using the * class value, or it
on the classes supported by the client . Note that in eith
case, the resolver must understand the preferences of the
For example, the host that supports both CSNET and ARPA
Mockapetris [Pag_
_ _ ._ _,
RFC 882 November
Internet protocols might prefer mail delivery (MD) to mail

forwarding (MF), regardless of protocol, or might prefer o
protocol regardless of whether MD or MF is required : Care
required to prevent loops.
3. The resolver must be capable of chaining through multiple

servers to get to an authoritative name server for any . que
The resolver should guard against loops in referrals ; a si
policy is to discard referrals that don't match more of th
http://www-bib .fh-bielefeld . de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882 .html 511100

HTML Version from RFC Do- -rent Page 24 of 27
query name than the referring name server, and also to avo
querying the same name server twice (This test should be d
using addresses of name servers instead of domain names to
avoid problems when a name server has multiple domain name
errors are present in aliases).
4. The resolver must be able to try alternate name servers wh

name server doesn't respond.
5. The resolver must be able to communicate different failure

conditions to its client . These failure conditions includ
unknown domain name, unknown resource for a know domain na
and inability to access any of the authoritative name sery
for a domain.
6. If the resolver uses datagrams for queries, it must recove

from lost and duplicate datagrams.
Resolvers with cache management
Caching provides a tool for improving the performance of name

service, but also is a potential source of incorrect results.
example, a database might cache information that is later cha
in the authoritative name servers . While this problem can ' t
eliminated without eliminating caching, it can be reduced to
infrequent problem through the use of timeouts.
When name servers return resource records, each record has an

associated time-to-live (TTL) field . This field is expressed
seconds, and has 16 bits of significance.
When a resolver caches a returned resource record it must als

remember the TTL field . The resolver must discard the record
the equivalent amount of time has passed . If the resolver. sh
a database with a name server, it must decrement the TTL fiel
imported records periodically rather than simply deleting the.
record . This strategy is necessary to avoid exporting a reso
record whose TTL field doesn't reflect the amount of time tha
resource record has been cached . Of course, the resolver sho
Mockapetris [Pag
, - . - . _
RFC 882 November
not decrement the TTL fields of records for which the associa
name server is an authority.
http ://www-bib . fh-bielefeld . de/epub/doe/idoc/rfe/rfc-0800-0899/rfc882 .html 5/1/00

Mockapetris [Pag
RFC 882 November

Appendix 1 - Domain Name Syntax Specification
The preferred syntax of domain names is given by the following B

rules . Adherence to this syntax will result in fewer problems w
many applications that use domain names (e .g ., mail, TELNET) : N
that some applications described in [141 use domain names contai
binary information and hence do not follow this syntax.
<domain> <subdomain> "
<subdomain> <label> <subdomain> 11 . 11 <label>
<label> : .= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> <let-dig-hyp> <let-dig-hyp> <ldh-str>
<let-dig-hyp> <let-dig> "-"
<let-dig> <letter> <digit>
<letter> any one of the 52 alphabetic characters A throug

in-upper case and a through z in lower case -
<digit> any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in doma
names no significance is attached to the case . That is, two!nam
with the same spelling but different case are to be treated as i
identical.
The labels must follow the rules for ARPANET host names . They m
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version from RFC Dc ,rent Page 26 of 27
start with a letter, end with a letter or digit, and have as int
characters only letters, digits, and hyphen . There are also som
restrictions on the length . Labels must be 63 characters or les
For example, the following strings identify hosts in the ARPA

Internet:
F .ISI .ARPA LINKABIT-DCN5 .ARPA UCL-TAC .ARPA
Mockapetris [Pag
- -
RFC 882 November
REFERENCES and BIBLIOGRAPHY
[1] E . Feinler, K . Harrenstien, Z . Su, and V . White, "DOD Inter

Host Table Specification", RFC 810, Network Information Cen
SRI International, March 1982.
[2] J . Postel, "Computer Mail Meeting Notes", RFC 805,

USC/Information Sciences Institute, February 1982.
[3] Z . Su, and J . Postel, "The Domain Naming Convention for, Int
User Applications", RFC 819, Network Information Center,, SR
International, August 1982.
[4] Z . Su, "A Distributed System'for Internet Name Service",

RFC 830, Network Information Center, SRI International,
October 1982.
[5] K . Harrenstien, and V . White, "NICNAME/WHOIS", RFC 812, ;Net

Information Center, SRI International, March 1982.
[6] M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Name

Server", Computer Networks, vol 6, nr 3, July 1982.
[7] K . Harrenstien, "NAME/FINGER", RFC 742, Network Information

. Center, SRI International, December 1977.
[8] J . Postel, "Internet Name Server", IEN 116,'USC/Information

' Sciences Institute, August 1979.
[9] K . Harrenstien, V . White, and E . Feinler, "Hostnames Server

March 1982.
[10] J . Postel, "Transmission Control Protocol", RFC 793,-

USC/Information Sciences Institute, September 1981.
[11] J . Postel, "User Datagram Protocol", RFC

_ -- 768, USC/Informati
Sciences Institute, August 1980.
[12] J . Postel, "Simple Mail Transfer Protocol", RFC 821,

USC/Information Sciences Institute, August 1980.
http ://www-bib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 5/1/00

(13]-J . Reynolds, and J . Postel, "Assigned Numbers", RFC .8_70,

USC/Information Sciences Institute, October 1983
[14] P . Mockapetris, "Domain Names - Implementation and

Specification", RFC 88.3, USC/Information Sciences Institute
November 1983.
Mockapetris (Pag
_ - .
Converted to HTML with rfc2html from RFC 882 at Mon May 123 :05 :56 2000
rfc2html © 1997 by Marcus Niemann, Fachhochschule Bielefeld
Haben Sie noch Fragen? Webmaster .

01997-2000 Bibliothek,
- -- _. Fachhochschule
----------- Bielefeld
-- .
Letzte ,ilderung am_Mon _ May 122 :05 :54 2000 durch Webmaster
Wiischenswertes and Anregungen bitte an : Webmaster_@ivww-bib .fh-bielefeld .de
i
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5/1/00

HTML Version•from RFC D~ ment Page 1 of 64
~a
Fachhochschule Bielefeld
University of Applied Sciences
Network Working Group P . Mockap

Request for Comments : 883
[Note : See also RFC 973 CSNET CIC] November
DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION
+ +
This memo discusses the implementation of domain

name servers and resolvers, specifies the format of
transactions, and discusses the use of domain names
in the context of existing mail systems and other
network software.
This memo assumes that the reader is familiar with

RFC 882, "Domain Names - Concepts and Facilities"
which discusses the"basic principles of domain
names and their use.
The algorithms and internal data structures used in

this memo are offered as suggestions rather than
requirements ; implementers are free to design their
own structures so long as the same external
behavior is achieved.
+ +
+ +
***** WARNING *****
This RFC contains format specifications which

are preliminary and are included for purposes
of explanation only . Do not attempt to use
this information for actual implementations.
+ +
Mockapetris [Pa
http://www-bib .fli-bielefeld .de/epub/doc/idoc/rfe/rfc883 .html 5/1/00

RFC 883 November

Domain Names - Implementation and Specific
Table of Contents
INTRODUCTION
Overview
Implementation components
Conventions
Design philosophy . . . .
NAME SERVER TRANSACTIONS
Introduction
Query and response transport
Overall message format
The contents of standard queries and responses
Standard query and response example
The contents of inverse queries and responses
Inverse query and response example
Completion queries and responses
Completion query and response example
Recursive Name Service
Header section format
Question section format
Resource record format
Domain name representation and compression
Organization of the Shared database
Query processing
Inverse query processing
Completion query processing
NAME SERVER MAINTENANCE
Introduction
Conceptual model of maintenance operations
Name server data structures and top level logic
Name server file loading
Name server file loading example
Name server remote zone transfer
RESOLVER ALGORITHMS
Operations
DOMAIN SUPPORT FOR MAIL
Introduction :
Agent binding
Mailbox binding
Appendix 2 - Field formats and encodings
TYPE values
.
QTYPE values . . ..
CLASS values
QCLASS values
Standard resource record formats
Appendix 3 - Internet specific field formats and operations
INDEX
Mockapetris [Pag
.... __
RFC 883 November
INTRODUCTION
Overview
The goal of domain names is to provide a mechanism for naming

resources in such a way that the names are usable in differen
http ://www-bib .fll-bielefeld.de/epub/doc/idoe/rfc/rfc883 .html 5/1/00


fi
hosts, networks, protocol families, internets, and administra
organizations.
From the user's point of view, domain names are useful as

arguments to a local agent, called a resolver, which retrieve
information associated with the domain name . Thus a user mig
ask for the host address or mail information associated with
particular domain name . To enable the user to request a
particular type of information, an appropriate query type is
passed to the resolver with the domain name . To the user, th
domain tree is a single information space.
From the resolver - s point of-view, the database that makes up

domain space is distributed among various name servers . Diff
parts of the domain space are stored in different name server
although a particular data item will usually be stored redund
in two or more name servers . . The resolver starts with knowle
of at least one name server . When the resolver processes a u
query it asks a known name server for the information ; in ret
the resolver either receives the desired information or a ref
to another name server . Using these referrals, resolvers lea
the identities and contents of other name servers . Resolvers
responsible for dealing with the distribution of the domain s
and dealing with the effects of name server failure by consul
redundant databases in other servers.
Name servers manage two kinds of data . The first kind of dat
held in sets called zones ; each zone is the complete database
a particular subtree of the domain space . This data is calle
authoritative . A name server periodically checks to make sur
that its zones are up to date, and if not obtains a new copy
updated zones from master files stored locally or in another
server . The second kind of data is cached data which was acq
by a local resolver . This data may be incomplete but improve
performance of the retrieval process when non-local data is
repeatedly accessed . Cached data is eventually discarded by
timeout mechanism.
This functional structure isolates the problems of user inter

failure recovery, and distribution in the resolvers and isola
the database update and refresh problems in the name servers.
Mockapetris [Pa

RFC 883 November
Implementation components
'A host can participate in the domain name system in a number

ways ; depending on whether the host runs programs that retrie
information from the domain system, name servers that answer
queries from other hosts, or various combinations of both,
functions . The simplest, and perhaps most typical, configura
is shown below:
Local Host I Foreign
+ + + +
user queries queries
User >
Program Resolver
< <
user responses responses
http://www-bib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc883 .html 511100

HTML Version from RFC Dr ~ment Page 4 of 64
+ + + + + +
A
cache additions I references
V
+ +
database
+ +
User programs interact with the domain name space through

resolvers ; the format of user queries and user responses is
specific to the host and its operating system . User queries
typically be operating system calls, and the resolver and its
database will be part of the host operating system . Less cap
hosts may choose to implement the resolver as a subroutine to
linked in with every program that needs its services.
Resolvers answer user queries with information they acquire v

queries to foreign name servers, and may also cache or refere
domain information in the local database.
Note that the resolver may have to make several queries to se

different foreign name servers to answer a particular user qu
and hence the resolution of a user query may involve several
network accesses and an arbitrary amount of time . The querie
foreign name servers and the corresponding responses have a
standard format described in this memo, and may be datagrams.
Mockapetris [Pa
RFC 883 November

Depending on its capabilities,'a name server could be a stand

alone program on a dedicated machine or a process or processe
a large timeshared host . A simple configuration might be:
+ +
Local Host
I Foreign;
/ +/ I + +
responses
+ +
Name -> Foreign

Master > Server Resolver
files
I queries ----------
= + + +
He re the name server acquires information about one or more z

by -reading master files from its local file system, and answe
queries about those zones that arrive from foreign resolvers:
A more sophisticated name server might acquire zones fr-omifor

name servers as well as local master files . This configurati
shown below :
Local Host Foreign
+ +
http://www-bib .fli-bielefeld .de/epub/doe/idoe/rfe/rfc883 .html 5/1/00

+ + + ----------
responses
Name -> Foreign
I Resolver
Master
files I >
I
Server
< I I
I / queries + +
+ +
A maintenance + +
>
\
queries Foreign
Name
Server
maintenance responses ,
In this configuration, the name server periodically establish

virtual circuit to a foreign name server to acquire a copy of
zone or to check that an existing copy has not changed . The
messages sent for these maintenance activities follow the sam
form as queries and responses, but the message sequences are
somewhat different.
Mockapetris [Pa

RFC 883 November
The information flow in a host that supports all aspects of t

domain name system is shown below:
Local Host I Foreign
+ + + + + +
user queries queries
User > -> Foreign
Program Resolver Name ~
< < -- Server
user responses responses
+ + + + ----------
A
cache additions I references
v
+ +
Shared
database
-----------
A
+ + refreshes references
V
+ + + + ----------
responses
Name -> Foreign
Master > : Server - Resolver
files <
/ queries
+ + + +
A maintenance ----------
\
queries Foreign
Name'.
\ Server
maintenance responses -1 + +
The shared database holds domain space data for the local nam
server and resolver . The contents of the shared database'wil
typically be a mixture of authoritative ; data maintained by th
http://www-bib .fh-blelefeld .de/epub/doc/idoc/rfe/rfc883 .html 511100

HTML Version from RFC D ment Page 6 of 64
periodic refresh operations of the name server and cached dat

from previous resolver requests . The structure of the domain
and the necessity for synchronization between name servers an
resolvers imply the general characteristics of this database,
the actual format is up to the local implementer . This memo
suggests a multiple tree format.
Mockapetris [Pa
RFC 883 November

This memo divides the implementation discussion into sections
NAME SERVER TRANSACTIONS, which discusses the formats for

servers queries and the corresponding responses.
NAME SERVER MAINTENANCE, which discusses strategies,

algorithms, and formats for maintaining the data residing
name servers . These services periodically refresh the loc
copies of zones that originate in other hosts.
RESOLVER ALGORITHMS, which discusses the internal structur

resolvers . This section also discusses data base sharing
between a name server and a resolver on the same host .',
DOMAIN SUPPORT FOR MAIL, which discusses the use of the do

system to support mail transfer.
http://www-bib .fh-bielefbld.de/epub/doc/idoc/rfe/rfc883 .html 511100 i

i

Mockapetris [.Pa _
RFC 883 November
Conventions
The domain system has several conventions dealing with low-le

but fundamental, issues . While the implementer is free to vi
these conventions WITHIN HIS OWN SYSTEM, he must observe thes
conventions in ALL behavior observed from other hosts.
********** Data Transmission Order **********
The order of transmission of the header and data described in

document is resolved to the octet level . Whenever a diagram
a group of octets, the order of transmission of those octets
the normal order in which they are read in English . For exam
in the following diagram the octets are transmitted in the or
they are numbered.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2 i
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
i 3 i 4 i
i 5 i 6 i
Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most

in the diagram is the high order or most significant bit . Th
is, the bit labeled 0 is the most significant bit . For examp
the following diagram represents the value 170 (decimal).
0 1 2. 3 4 5 6 7
it 0 1 0 1 0 1 Oi
Significance of Bits
similarly, whenever a multi-octet field represents a numeric

quantity the left most bit of the whole field is the most
significant bit . When a multi-octet quantity is transmitted
most significant octet is transmitted first.
Mockapetris (Pa
RFC 883 November

********** Character Case **********
All comparisons between character strings (e .g . labels, domai

names, etc .) are! done in a case-insensitive manner.
http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00
"s:
HTML Version from RFC D~ ment Page 8 of 64

fi
When data enters the domain system, its original case should
preserved whenever possible . In certain circumstances this c
be done . For example, if two domain names x .y and X .Y are en
into the domain database, they are interpreted as the same na
and hence may have a single representation . The basic rule i
that case can be discarded only when data is used to define
structure in a database, and two names are identical when com
in a case insensitive manner.
Loss of case sensitive data must be minimized . Thus while da

for x .y and X .Y may both be,stored under x .y, data for a .x an
can be stored as a .x and B .x, but not A .x, A .X ; b .x, or b .X.
general, this prevents the first component of a domain name f
loss of case information.
Systems administrators who enter data into the domain databas

should take care to represent the data they supply to the dom
system in a case-consistent manner if their system is
case-sensitive . The data distribution system in the domain s
will ensure that consistent representations are preserved.
Mockapetris [Pa
RFC 883 November

Design philosophy
The design presented in this memo attempts to provide a base

will be suitable for several existing networks . An equally
important goal is to provide these services within a framewor
that is capable of adjustment to fit the evolution of service
early clients as well as to accommodate new networks . -
Since it is impossible to predict the course of these

developments, the domain system attempts to provide for evolu
in the form of an extensible framework . This section describ
the areas in which we expect to see immediate evolution.
DEFINING THE DATABASE
http://www-bib .fh-bielefeld.de/epub/doe/idoe/rfe/rfc883 .html 5/1/00

HTML Version from RFC D, mCnt Page 9 of 64
This memo defines methods for partitioning the database and d

for host names, host addresses, gateway information, and mail
support . Experience with this system will provide guidance f
future additions.
while the present system allows for many new RR types, classe
etc ., we feel that it is more important to get the basic sery
in operation than to cover an exhaustive set of information.
Hence we have limited the data types to those we felt were
essential, and would caution designers to avoid implementatio
which are based on the number of existing types and classes.
Extensibility in this area is very important . '
while the domain system provides techniques for partitioning

database, policies for administrating the orderly connection
separate domains and guidelines for constructing the data tha
makes up a particular domain will be equally important to the
success of the system . Unfortunately, we feel that experien
with prototype systems will be necessary before this question
be properly addressed . Thus while this memo has minimal
discussion of these issues, it is a critical area for develop
TYING TOGETHER INTERNETS
Although it is very difficult to characterize the types of

networks, protocols, and applications that will be clients of
domain system, it is very obvious that some of these applicat
will cross the boundaries of network and protocol . At the ve
least, mail is such a service.
Attempts to unify two such systems must deal with two major
problems:
1. Differing formats for environment sensitive data . For .exa
Mockapetris [Pa_
RFC 883 November

network addresses vary in format, and it is unreasonable t

expect to enforce consistent conventions.
2. Connectivity may require intermediaries . For example, it

frequent occurence that mail is sent between hosts that sh
no common protocol.
The domain system acknowledges that these are very difficult

problems, and attempts to deal with both problems through its
CLASS mechanism:
1. The CLASS field in RRs .allows data to be tagged so that al

programs in the domain system can identify the format in u
2. The CLASS field allows the requestor to identify the forma

data which can be understood by the requestor.
3. The CLASS field guides the search for the requested data.
The last point is central to our approach . When a query cros

protocol boundaries, it must be guided though agents capable
performing whatever translation is required . For example, wh
mailer wants to identify the location of a mailbox in a porti
the domain system that doesn't have a compatible protocol, th
query must be guided to a name server that can cross the boun
itself or form one link in a chain that can span the differen
http://www-bib .fh-bielefeld .de/epub/doc/idoc/rfe/rfc883 .html 5/1400

HTML Version from RFC D ment Pa&e 10 of 64
If query and response transport were the only problem, then t

sort of problem could be dealt with in the name servers
themselves . However, the applications that will use domain
service have similar problems . For example, mail may need to
directed through mail gateways, and the characteristics of on
the environments may not permit frequent connectivity between
servers in all environments.
These problems suggest that connectivity will be achieved thr

a variety of measures:
Translation name servers that act as relays between differ

protocols.
Translation application servers that translate application

level transactions.
Default database entries that route traffic through applic

level forwarders in ways that depend on the class of the
requestor.
While this approach seems best given our current understandin
Mockapetris [Pa
.
RFC 883 November
the problem, we realize that the approach of using resource d

that transcends class may be appropriate in future designs or
applications . By not defining class to be directly related t
protocol, network, etc ., we feel that such services could be
by defining a new "universal" class, while the present use of .
class will provide immediate service.
This problem requires more thought and experience before solu

can be discovered . The concepts of CLASS, recursive servers
other mechanisms are intended as tools for acquiring experien
and not as final solutions.
http ://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .httnl 5/1/00
~I

HTML Version from RFC D; :Went Page 11 of 64
Mockapetris [._Pag._.
RFC 883 November
NAME SERVER TRANSACTIONS
Introduction
The primary purpose of name servers is to receive queries fro

resolvers and return responses . The overall model of this se
is that a program (typically a resolver) asks the name server
questions (queries) and gets responses that either answer the
question or refer the questioner to another name server . Oth
functions related to name server database maintenance use sim
procedures and formats and are discussed in a section later i
this memo.
There are three kinds of queries presently defined:
1. Standard queries that ask for a specified resource atta•

to a given domain name.
2. Inverse queries that specify a resource and ask for a d

name that possesses that resource.
3. Completion queries that specify a partial domain name a

target domain and ask that the partial domain name be
completed with a domain name close to the target domain
This memo uses an unqualified reference to queries to refer t

either all queries or standard queries when the context is cl
Query and response transport
Name servers and resolvers use a single message format for al

communications . The message format consists of a variable-le
octet string which includes binary values.
The messages used in the domain system are designed so that t

can be carried using either datagrams or virtual circuitsi T
accommodate the datagram style, all responses carry the query
part of the response.
While the specification allows datagrams to be used in any

context, some activities are ill suited to datagram use . ;For
example, maintenance transactions and recursive queries typic
require the error control of virtual circuits . Thus datagram
should be restricted to simple queries.
The domain system assumes that a datagram service provides:
1 . A non-reliable (i .e . best effort) method of transportin
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

.F ,
message of up to 512 octets.
Mockapetris [Pag
RFC 883 November

. Domain Names - Implementation and Specific
Hence datagram messages are limited to 512 octets . If

datagram message would exceed 512 octets, it is truncat
and a truncation flag .is set in its header.
2 . A message size that gives the number of octets in the

datagram.
The main implications for programs accessing name servers via

datagrams are:
1. Datagrams should not be used for maintenance transactio

and recursive queries.
2. Since datagrams may be lost, the originator of a query

perform error recovery (such as retransmissions) as
appropriate.
3. Since network or host delay may cause retransmission wh

datagram has not been lost, the originator of a query m
be ready to deal with duplicate responses.
The domain system assumes that a virtual circuit service prov
1. A reliable method of transmitting a message of up to 65

octets.
2. A message size that gives the number of octets in the

message.
If the virtual circuit service does not provide formes

boundary detection or limits transmission size to less
65535 octets, then messages are prefaced with an unsign
bit length field and broken up into separate transmissi
as required . The length field is only prefaced on the
message . This technique is used for TCP virtual circui
3. Multiple messages may be-sent over a virtual circuit'.
4. A method for closing a virtual circuit.
5. A method for detecting that the other party has request

that the virtual circuit be closed.
The main implications for programs accessing name servers via

virtual circuits are:
. 1 . Either end of a virtual circuit may initiate a close wh

there is no activity in progress . The other end should
comply.
Mockapetris [Pag
RFC 883 November

The decision to initiate a close is a matter of individ

site policy ; some name servers may leave a virtual circ
http://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 511 /00

open for an indeterminate period following a query to a

for subsequent queries ; other name servers may choose t
initiate a close following the completion of the first
on a virtual circuit . Of course, name servers should n
close the virtual circuit in the midst of a multiple me
stream used for zone transfer.
2 . Since network delay may cause one end to erroneously be

that no activity is in progress, a program which receiv
virtual circuit close while a query is in progress shou
close the virtual circuit and resubmit the query on a n
virtual circuit.
All messages may use a compression scheme to reduce the space

consumed by repetitive domain names . The use of the compress
scheme is optional for the sender of a message, but all recei
must be capable of decoding compressed domain names.
overall message format
All messages sent by the domain system are divided into 5 sec
(some of which are empty in certain cases) shown below:
+ +
I Header I
+ +
I Question I the question for the name server
+ +
Answer I answering resource records (RRs)
+ +
I Authority I RRs pointing toward an authority
+ +
I Additional I RRs holding pertinent information
+ +
The header section is always present . The header includes fi

that specify which of the remaining sections are present, and
specify whether the message is a query, inverse query, comple
query, or response.
The question section contains fields that describe a question

name server . These fields are ' a query type (QTYPE), a query
(QCLASS), and a query domain name (QNAME).
The last three sections have the same format : a possibly empt
list of concatenated resource records (RRs) . The answer sect
contains RRs that answer the question ; the authority section
Mockapetris [Pag
RFC 883 November

contains RRs that point toward an authoritative name server;

additional records section contains RRs which relate to the q
but are not strictly answers for the question.
The next two sections of this memo illustrate the use of thes
message sections through examples ; a detailed discussion of d
formats follows the examples.
http://www-bib .fli-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 5/1/00

.s ,
HTML Version from RFC D- ment Page 14 of 64
Mockapetris [Pag
RFC 883 November

The contents of standard queries and responses
When a name server processes a standard query, it first deter

whether it is an authority for the domain name specified in t
query.
If the name server is an authority, it returns either:
1. the specified resource information
2. an indication that the specified name does'not exist
3. an indication that the requested resource information d

not exist
If the name server is not an authority for the specified name

returns whatever relevaht resource information it has along w
resource records that the requesting resolver can use to loca
authoritative name server.
Standard query and response example
The overall structure of a query for retrieving information f

Internet mail for domain F .ISI .ARPA is shown below:
http ://www-bib .fh-bielefeld .de/epub/doe/idoc/rfe/rfc883 .html 511100

HTML Version from RFC D, •ment Page 15 of 64
+
Header OPCODE=QUERY, ID=2304
+
Question IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA
+ =
Answer I <empty>
+
Authority I <empty>
+
Additional <empty>
+
The header includes an opcode field that specifies that this

datagram is a query, and an ID field that will be used to
associate replies with the original query . (Some additional
header fields have been omitted for clarity .) The question
section specifies that the type of the query is for mail agen
information, that only ARPA Internet information is to be
considered, and that the domain name of interest is F .ISI .ARP
The remaining sections are empty, and would not use any octet
a real query.
Mockapetris 1Pa g
RFC 883 November

one possible response to this query might be:

--
Header OPCODE=RESPONSE, ID=2304
+ j---
+ = '---
Answer <empty>
--
Authority ARPA NS IN A .ISI .ARPA
ARPA NS - IN - F .ISI .ARPA

+
Additional F .ISI .ARPA A IN 10 .2 .0 .52
A .ISI .ARPA A IN 10 .1 .0 .22

+
This type of response would be returned by a name server that

not an authority for the domain name F .ISI .ARPA . The header
specifies that the datagram is a response to a query with an
2304 . The question section is copied from the question secti
the query datagram.
The-answer section is empty because the name server did not h

any information that would answer the query . (Name servers m
happen to have cached information even if they are not -
authoritative for the query .)
The best that this name server could do was to pass back
information for the domain ARPA . The authority section speci
two name servers for the domain ARPA using the Internet famil
A .ISI .ARPA and F .ISI .ARPA . Note that it is merely a coincide
that F .ISI .ARPA is a name server for ARPA as well as the_ .subj
of the query.
http://www-bib .fll-bielefeld .de/epub/doe/idoc/rfc/rfc883 .html 51110,0

HTML Version from RFC D c -ment Page 16 of 64
In this case, the name server included in the additional reco

section the Internet addresses for the two hosts specified in
authority section . Such additional data is almost always
available.
Given this response, the process that originally sent the que
might resend the query to the name server on A .ISI .ARPA, with
new ID of 2305.
Mockapetris [Pag
RFC 883 November

The name server on A .ISI .ARPA might return a response:
+
Header I OPCODE=RESPONSE, ID=2305
+
+ =
Answer F .ISI .ARPA MD IN F .ISI .ARPA

+
Authority I <empty>
+
Additional I F .ISI .ARPA A IN 10 .2 .0 .52
A .ISI .ARPA A IN 10 .1 .0 .22

+ '----
This query was directed to an authoritative name server, and

the response includes an answer but no authority records . In
case, the answer section specifies that mail for F .ISI .ARPA c
either be delivered to F .ISI .ARPA or forwarded to A .ISI .ARPA.
additional records section specifies the Internet addresses o
these hosts.
The contents of inverse queries and responses
Inverse queries reverse the mappings performed by standard qu

operations ; while a standard query maps a domain name to a
resource, an inverse query maps a resource to a domain name.
example, a standard query might bind a domain . name to a host
address ; the corresponding inverse query binds the host addre
a domain name.
Inverse query mappings are not guaranteed to be unique or!com

because the domain system does not have any internal mechanis
determining authority from resource records that parallels th
capability for determining authority as a function of domain
In general, resolvers will be configured to direct inverse qu
to a name server which is known to have the desired informati
Name servers are not required to support any form of inverse

queries ; it is anticipated that most name servers will suppor
address to domain name conversions, but no other inverse mapp
If a name server receives an inverse query that it does not
support, it returns an error response with the "Not Implement
http://www-bib .fli-blelefeld.de/epub/doe/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D , ment Page 17 of 64
error set in the header . While inverse query support is opti

all name servers must be at least able to return the error
response.
Mockapetris [Pag__

RFC 883 November
When a name server processes an inverse query, it either retu
1. zero, one, or multiple domain names for the specified

resource
2. an error code indicating that the name server doesn't

support inverse mapping of the specified resource type.
Inverse query and response example
The overall structure of an inverse query for retrieving the

domain name that corresponds to Internet address 10 .2 .0 .52 is
shown below :
+ .
Header I OPCODE=IQUERY, ID=997

+
Question <empty>
+
Answer <anyname> A IN 10 .2 .0 .52
+
Authority I <empty>
+
Additional I <empty>
+ .---
This query asks for a question whose answer is the Internet s

address 10 .2 .0 .52 . Since the owner name is not known, any do
name can be used as a placeholder (and is ignored) . The r,esp
to this query might be:
+ .---
+
Question I QTYPE=A, QCLASS=IN, QNAME=F .ISI .ARPA
+
Answer I F .ISI .ARPA A IN 10 .2 .0 .52
+
Authority <empty>
+
Additional I <empty>
+
Note that the QTYPE in a response to an inverse query is the

as the TYPE field in the answer section of the inverse query.
Responses to inverse queries may contain multiple questions w
the-inverse is not unique.
Mockapetris [Pag
RFC 883 November

http ://www-bib .fh-blelefeld .de/epub/doe/idoc/rfe/rfc883 .html 5/1/00

Completion queries and responses
completion queries ask a name server to complete a partial do

name and return a set of RRs whose domain names meet a specif
set of criteria for "closeness" to the partial input . This t
of query can provide a local shorthand for domain names or cc
completion similar to that in TOPS-20.
Implementation of, completion query processing is optional in

name server . However, a name server must return a "Not
Implemented" (NI) error response if it does not support
completion.
The arguments in a completion query specify:
1. A type in QTYPE that specifies the type of the desired nam

The type is used to restrict the type of RRs which will ma
the partial input so that completion queries can be used f
mailbox names, host names, or any other type of RR in the
domain system without concern for matches to the wrong typ
resource.
2. A class in QCLASS which specifies the desired class of the
3. A partial domain name that gives the input to be completed

All returned RRs will begin with the partial string . The
search process first looks for names which qualify under t
assumption that the partial string ends with a full label
("whole label match") ; if this search fails, the search
continues under the assumption that the last label in the
partial sting may be an incomplete label ("partial label
match") . For example, if the partial string "Smith" was u
in a mailbox completion, it would match Smith@ISI .ARPA J n
preference to Smithsonian@ISI .ARPA.
The partial name is supplied by the user through the user

program that is using domain services . For example, if, th
user program is a mail handler, the string might be "Mocka
which the user intends as a shorthand for the mailbox
Mockapetris@ISI .ARPA ; if the user program is TELNET, the u
might specify "F" for F .ISI,ARPA.
In order to make parsing of messages consistent, the parti

name is supplied in domain name format (i .e . a sequence of
labels terminated with a zero length octet) . However, ',the
trailing root label is ignored during matching.
4. A target domain name which specifies the domain which is t

examined for matches . This name is specified in the addit
Mockapetris [Pag
... . „ ........
RFC 883 November
section using a NULL RR . All returned names will end with

_target name.
The user program which constructs the query uses the targe
name to restrict the search . For example, user programs
running at ISI might restrict completion to names that ;end
ISI .ARPA ; user programs running at MIT might restrict
completion to the domain MIT .ARPA.
The target domain name is also used by the resolver to

determine the name server which should be used to process
http ://www-bib .fli-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

HTML Version from RFC D, ment Page 19 of 64
- que.~ry . In general, queries should be directed to a name s

that is authoritative for the target domain name . User
programs which wish to provide completion for a more than
target can issue multiple completion queries, each directe
a different target .--Selection of the target name and the
number of searches will depend on the goals of the user
program.
5 . An opcode for the query . The two types of completion quer

are "Completion Query - Multiple", or CQUERYM, which asks
all RRs which could complete the specified input, and
"Completion Query - Unique" ; or CQUERYU, which asks for th
"best" completion.
CQUERYM is used by user programs which want to know if

ambiguities exist or wants to do its own determinations as
the best choice of the available candidates.
CQUERYU is used by user programs which either do not wish

deal with multiple choices or are willing to use the close
criteria used by CQUERYU to select the best match.
When a name server receives either completion query, it first

looks for RRs that begin (on the left) with the same labels a
found in QNAME (with the root deleted), and which match the Q
and QCLASS . This search is called "whole label" matching . I
or more hits are found the name server either returns all of
hits (CQUERYM) or uses the closeness criteria described below
eliminate all but one of the matches (CQUERYU).
If the whole label match fails to find any candidates, then t

name server assumes that the rightmost label of QNAME (after
deletion) is not a complete label, and looks for candidates t
would match if characters were added (on the right) to the
rightmost label of QNAME . If one or more hits are found the
server either returns all of the hits (CQUERYM) or uses the
closeness criteria described below to eliminate all but one o
matches (CQUERYU).
Mockapetris [Pag
„ -, _...
RFC 883 November
If a CQUERYU query encounters multiple hits, it uses the foll

sequence of rules to discard multiple hits:
1. Discard candidates that have more labels than others . Sin

all candidates start with the partial name and end with th
target name, this means that we select those entries that
require the fewest number of added labels . For example, a
search with a target of "ISI .ARPA" and a partial name of "
will select A .ISI .ARPA in preference to A .IBM-PCS .ISI .ARPA
2. If partial label matching was used, discard those labels w

required more characters to be added . For example, a mail
search for partial "X" and target "ISI .ARPA" would prefer
XX@ISI .ARPA to XYZZYQISI .ARPA.
If multiple hits are still present, return all hits.
Completion query mappings are not guaranteed to be unique or

complete because the domain system does not have any internal
mechanism for determining authority from a partial domain!nam
that parallels the capability for determining authority as a
function of a complete domain name . In general, resolvers wi
http ://www-bib .fli-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D, ment Page 20 of 64
configured to direct completion queries to a name server whic

known to have the desired information.
When a name server processes a completion query, it either

returns:
1. An answer giving zero, one, or more possible completion
2. an error response with Not Implemented (NI) set.
Mockapetris [Pag_
RFC 883 November

Completion query and response example
Suppose that the completion service was used by a TELNET prog

to allow a user to specify a partial domain name for the desi
host . Thus a user might ask to be connected to "B" . Assumin
that the query originated from an ISI machine, the query migh
look like :
+
Header I OPCODE=CQUERYU, ID=409
+ ,
Question I QTYPE=A, QCLASS=IN, QNAME=B
+
Answer I <empty>
+
Authority I <empty>
+
Additional I ISI .ARPA NULL IN
+
The partial name in the query is "B", the mappings of interes

ARPA Internet address records, and the target domain is ISI .A
Note that NULL is a special type of NULL resource record that
used as a placeholder and has no significance ; NULL RRs obey
standard format but have no other function.
The response to this completion query might be:

+
+
http ://www-bib .fli-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 511100

HTML Version from RFC D , ~ment Page 21 of 64
Answer B .ISI .ARPA A IN 10 .3 .0 .52

+
Authority <empty>
+--=
Additional I ISI .ARPA NULL IN
+
This response has completed B to mean B .ISI .ARPA.
Mockapetris [Pag
RFC 883 November

Another query might be:
+
Header I OPCODE=CQUERYM, ID=410
+
Ques.tion I QTYPE=A, QCLASS=IN, QNAME=B
+
Answer <empty>
+
Authority I <empty>
+
Additional I ARPA NULL IN ."
+
This query is similar to the previous one, but specifies a to

of ARPA rather than ISI .ARPA . It also allows multiple matche
In this case the same name server might return:
+
-----------------------------------------
+
Answer B .ISI .ARPA A IN 10 .3 .0 .52
B .BBN .ARPA A IN 10 .0 .0 .49
B .BBNCC .ARPA A IN 8 .1 .0 .2
+
Authority I <empty>
+
Additional I ARPA NULL IN1
+
This response contains three answers, B .ISI .ARPA, B .BBN .ARPA,

B .BBNCC .ARPA .
http://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 511100

RFC 883 November

Recursive Name Service
Recursive service is an optional feature of name servers.
When a name server receives a query regarding a part of the n

space which is not in one of the name server's zones, the sta
response is a message that refers the requestor to another na
server . By iterating on these referrals, the requestor event
is directed to a name server that has the required informatio
Name servers may also implement recursive service . In this t

of service, a name server either answers immediately based on
local zone information, or pursues the query for the requesto
returns the eventual result back to the original requestor.
A name server that supports recursive service sets the Recurs

Available (RA) bit in all responses it generates . A requesto
asks for recursive service by setting the Recursion Desired (
bit in queries . In some situations where recursive service i
only path to the desired information (see below), the name se
may go recursive even if RD is zero.
If a query requests recursion (RD set), but the name server d

not support recursion, and the query needs recursive service
an answer, the name server returns a "Not Implemented" (NI) e
code . If the query can be answered without recursion since t
name server is authoritative for the query, it ignores the RD
Because of the difficulty in selecting appropriate timeouts a

error handling, recursive service is best suited to virtual
circuits, although it is allowed for datagrams.
Recursive service is valuable in several special situations:
In a system of small personal computers clustered around o

more large hosts supporting name servers, the recursive
approach minimizes the amount of code in the resolvers in
personal computers . Such a design moves complexity out of
resolver into the name server, and may be appropriate for
systems.
Name servers on the boundaries of different networks may w

to offer recursive service to create connectivity between
different networks . Such name servers may wish to provide
recursive service regardless of the setting of RD.
Name servers that translate between domain name service an

some other name service may wish to adopt the recursive st
Implicit recursion may be valuable here as well.
Mockapetris [Pag
RFC 883 November

http ://www-bib .fli-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D' ment Page 23 of 64
These concepts are still under development.
Mockapetris [Pag
RFC 883 November

Header section format
+ +
***** WARNING *****
The following format is preliminary and is

included for purposes of explanation only . In
particular, the size and position of the
http://www-bib .fh-bielefeld.de/epub/doc/idoc/i-fc/rfc883 .html 5/1/00

HTML Version from RFC D( •ment Page 24 of 64

-r
OPCODE, RCODE fields and the number and

meaning of the single bit fields are subject
to change.
+ +
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
ID
JQRJ Opcode JAAITCIRDJRAI RCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT
where:
ID - A 16 bit identifier assigned by the program that

generates any kind of query . This identifier is co
into all replies and can be used by the requestor t
relate replies to outstanding questions.
QR - A one bit field that specifies whether this message

query (0), or a response (1).
OPCODE - A four bit field that specifies kind of query in th

message . This value is set by the originator of a
and copied into the response . The values are:
0 a standard query (QUERY)
Mockapetris [Pag
....... .......
RFC 883 November
1 an inverse query (IQUERY)
2 an completion query allowing multiple

answers (CQUERYM)
2 an completion query requesting a single

answer (CQUERYU)
4-15 reserved for future use
AA - Authoritative Answer - this bit is valid in respons

and specifies that the responding name ser
is an authority for the domain name in the
corresponding query.
TC - Truncation - specifies that this message was trunca

due to length greater than 512 characters.
This bit is valid in datagram messages but
in messages sent over virtual circuits.
http ://www-bib .fli-bielefeld.de/epub/doc/ldoc/rfc/rfc883 .html 511100

HTML Version from RFC D- - .ment Page 25 of 64

-t
RD - Recursion Desired - this bit may be set in a query

is copied into the response . If RD is set
directs the name server to pursue the quer
recursively . Recursive'query support is
optional.
RA - Recursion Available - this be is set or cleared in

response, and denotes whether recursive qu
support is available in the name server.
RCODE - Response code - this 4 bit field is set as part of

responses . The values have the following
interpretation:
0 No error condition
1 Format error - The name server was una

to interpret the query.
2 Server failure - The name server was u

to process this query due to a problem
the name server.
3 Name Error - Meaningful only for respo

from an authoritative name server, thi
code signifies that the domain name
referenced in the query does not exist
Mockapetris [. P g
a _..
RFC 883 November

4 Not Implemented - The name server does

support the requested kind of query.
5 Refused - The name server refuses to

perform the specified operation for po
reasons . For example, a name server m
not wish to provide the information to
particular requestor, or a name server
not wish to perform a particular opera
(e .g . zone transfer) for particular da
6-15 Reserved for future use.
QDCOUNT - an unsigned 16 bit integer specifying the number of

entries in the question section.
ANCOUNT - an unsigned 16 bit integer specifying the number of

resource records in the answer section.
NSCOUNT - an unsigned 16 bit integer specifying the number of

server resource records in the authority records
section.
ARCOUNT - an unsigned 16 bit integer specifying the number of

resource records in the additional records section.
http ://ww,,v-bib .fh-bielefeld .de/epub/doe/idoc/rfe/rfc883 .html 511100

HTML Version from RFC D- iment Page 26 of 64
Mockapetris JP a..9-...
RFC 883 November

Question section format
The question section is used in all kinds of queries other th

inverse queries . In responses to inverse queries, this secti
may contain multiple entries ; for all other responses it cont
a single entry . Each entry has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
QNAME
QTYPE
QCLASS
where:
QNAME - a variable number of octets that specify a domain n

This field uses the compressed domain name format
described in the next section of this memo . This f
can be used to derive a text string for the domain
Note that this field may be an odd number of octets
padding is used.
QTYPE - a two octet code which specifies the type of the qu

The values for this field include all codes valid f
TYPE field, together with some more general codes w
can match more than one type of RR . For example, Q
might be A and only match type A RRs, or might be M
which matches MF and MD type RRs . The values for t
field are listed in Appendix 2.
QCLASS - a two octet code that specifies the class of the qu

For example, the QCLASS field is IN for the ARPA
Internet, CS for the CSNET, etc . The numerical val
are defined in Appendix 2.
http ://www-bib .fll-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

Mockapetris _[_Rag...
RFC 883 November

Resource record format

The answer, authority, and additional sections all share the
format : a variable number of resource records, where the numb
records is specified in the corresponding count field in the
header . Each resource record has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
/ NAME /
TYPE
CLASS
TTL
RDLENGTH
/ RDATA /
where:
NAME - a compressed domain name to which this resource rec

pertains.
TYPE - two octets containing one of the RR type codes defi

in Appendix 2 . This field specifies the meaning of
data in the RDATA field.
CLASS - two octets which specify the class of the data in t

RDATA field.
TTL - a 16 bit unsigned integer that specifies the time

interval (in seconds) that the resource record may
cached before it should be discarded . Zero values
interpreted to mean that the RR can only be used fo
transaction in progress, and should not be cached.
example, SOA records are always distributed with a
TTL to prohibit caching . Zero values can also be u
for extremely volatile data.
Mockapetris _[Pag .
1-ittp ://www-bib .fll-blelefeld .de/epub/doe/idoc/rfc/rfc883 .html 511100

RFC 883 November

RDLENGTH- an unsigned 16 bit integer that specifies the lengt

octets of the RDATA field.
RDATA - a variable length string of octets that describes t

resource . The format of this information varies
according to the TYPE and CLASS of the resource rec
For example, the if the TYPE is A and the CLASS is
the RDATA field is a 4 octet ARPA Internet address.
Formats for particular resource records are shown in Appendic

and 3.
Domain name representation and compression
Domain names messages are expressed in terms of a sequence of

labels . Each label is represented as a one octet length fiel
followed by that number of octets . Since every domain name e
with the null label of the root, a compressed domain name is
terminated by a length byte of zero . The high order two bits
the length field must be zero, and the remaining six bits of
length field limit the label to 63 octets or less.
To simplify implementations, the total length of label octets

label length octets that make up a domain name is restricted
255 octets or less . Since the trailing root label and its do
not printed, printed domain names are 254 octets or less.
Although labels can contain any 8 bit values in octets that m

up a label, it is strongly recommended that labels follow the
syntax described in Appendix 1 of this memo, which is compati
with existing host naming conventions . Name servers and reso
must compare labels in a case-insensitive manner, i .e . A=a, a
hence all character strings must be ASCII with zero parity.
Non-alphabetic codes must match exactly.
Whenever possible, name servers and resolvers must preserve a

bits of domain names they process . When a name server is giv
data for the same name under two different case usages, this
preservation is not always possible . For example, if a name
server is given data for ISI .ARPA and isi .arpa, it should cre
single node, not two, and hence will preserve a single casing
the label . Systems with case sensitivity should take special
precautions to insure that the domain data for the system is
created with consistent case.
In order to reduce the amount of space used by repetitive dom

names, the sequence of octets that defines a domain name may
terminated by a pointer to the length octet of a previously
specified label string . The label string that the pointer
Mockapetris l_pa .g....
RFC 883 November

specifies is appended to the already specified label string.

Exact duplication of a previous label string can be done with
single pointer . Multiple levels are allowed.
Pointers can only be used in positions in the message where t

format is not class specific . If this were not the case, a n
server that was handling a RR for another class could make
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D 'ment Page 29 of 64
erroneous copies of RRs . As yet, there are no such cases, bu

they may occur in future RDATA formats.
If a domain name is contained in a part of the message subjec

a length field (such as the RDATA section of an RR), and
compression is used, the length of the compressed name is use
the length calculation, rather than the length of the expande
name.
Pointers are represented as a two octet field in which the hi
order 2 bits are ones, and the low order 14 bits specify an o
from the start of the message . The 01 and 10 values of the h
order bits are reserved for future use and should not be used
Programs are free to avoid using pointers in datagrams they

generate, although this will reduce datagram capacity . Howev
all programs are required to understand arriving messages tha
contain pointers.
For example, a datagram might need to use the domain names
F .ISI .ARPA, FOO .F .ISI .ARPA, ARPA, and the root . Ignoring the
other fields of the message, these domain names might be
represented as:
Mockapetris [-Pag. .
RFC 883 November

20 1 F
22 3 1
24 I S I
26 4 A
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
_ 28 I R P
30 A 0
40 3 F
42 I O O
http://www-bib .fl-i-blelefeld .de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D- -anent Page 30 of 64
44 1 1 11 20 1
64 1 1 11 26 1
92 1 0 1 1
The domain name for F .ISI .ARPA is shown at offset 20 . The do

name FOO .F .ISI .ARPA is shown at offset 40 ; this definition us
pointer to concatenate a label for FOO to the previously defi
F .ISI .ARPA . The domain name ARPA is defined at offset 64 usi
pointer to the ARPA component of the name F .ISI .ARPA at 20 ; n
that this reference relies on ARPA being the last label in th
string at 20 . The root domain name is defined by a single oc
of zeros at 92 ; the root domain name has no labels.
Organization of the Shared database
While name server implementations are free , to use any interna

data structures they choose, the suggested structure consists
several separate trees . Each tree has structure correspondin
the domain name space, with RRs attached to nodes and leaves.
Each zone of authoritative data has a separate tree, and one
holds all non-authoritative data . All of the trees correspon
to zones are managed identically, but the non-authoritative o
cache tree has different management procedures.
Mockapetris [ P a9....
RFC 883 November

Data stored in the database can be kept in whatever form is

convenient for the name server, so long as it can be transfor
back into the format needed for messages . In particular, the
database will probably use structure in place of expanded dom
names, and will also .convert many of the time intervals used
the domain systems to absolute local times.
Each tree corresponding to a zone has complete information fo

"pruned" subtree of the domain space . The top node of a zone
a SOA record that marks the start of the zone . The bottom ed
the zone is delimited by nodes containing NS records signifyi
delegation of authority to other zones, or by leaves of the d
tree . When a name server contains abutting zones, one tree w
have .a bottom node containing a NS record, and the other tree
begin with a tree location containing a SOA record.
Note that there is one special case that requires considerati

when a name server is implemented . A node that contains a SO
denoting a start of zone will also have NS records that ident
the name servers that are expected to have a-copy of the zone
Thus a name server will usually find itself (and possibly oth
redundant name servers) referred to in NS records occupying t
same position in the tree as SOA records . The solution to th
problem is to never interpret a NS record as delimiting a zon
started by a SOA at the same point in the tree . (The sample
programs in this memo deal with this problem by processing SO
records only after NS records have been processed .)
Zones may also overlap a particular part of the name space wh
http://www-bib .fll-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 5/1/00

HTML Version from RFC D ,' ment Page 31 of 64
they are of different classes.
other than the abutting and separate class cases, trees are a
expected to be disjoint . overlapping zones are regarded as a
non-fatal error . The scheme described in this memo avoids th
overlap issue by maintaining separate trees ; other designs mu
take the appropriate measures to defend against possible over
Non-authoritative data is maintained in a separate tree . Thi

tree is unlike the zone trees in that it may have "holes" . E
RR in the cache tree has its own TTL that is separately manag
The data in this tree is never used if authoritative data is
available from a zone tree ; this avoids potential problems du
cached data that conflicts with authoritative data.
The shared database will also contain data structures to supp

the processing of inverse queries and completion queries if t
local system supports these optional features . Although many
schemes are possible, this memo describes a scheme that is ba
on tables of pointers that invert the database according to k
Mockapetris [Pag
RFC 883 November

Each kind of retrieval has a separate set of tables, with one

table per zone . When a zone is updated, these tables must al
updated . The contents of these tables are discussed in the
"Inverse query processing" and "Completion query processing"
sections of this memo.
The database implementation described here includes two locks

are used to control concurrent access and modification of the
database by name server query processing, name server mainten
operations, and resolver access:
The first lock ("main lock") controls access to all of the

trees . Multiple concurrent reads are allowed, but write a
can only be acquired by a single process . Read and write
access are mutually exclusive . Resolvers and name server
processes that answer queries acquire this lock in read mo
and unlock upon completion of the current message . This 1
is acquired in write mode by a name server maintenance pro
when it is about to change data in the shared database . T
actual update procedures are described under "NAME SERVER
MAINTENANCE" but are designed to be brief.
The second lock ("cache queue lock") controls access to th

cache queue . This queue is used by a resolver that wishes
add information to the cache tree . The resolver acquires
lock, then places the RRs to be cached into the queue . Th
name server maintenance procedure periodically acquires th
lock and adds the queue information to the cache . The
rationale for this procedure is that it allows the resolve
operate with read-only access to the shared database, and
allows the update process to batch cache additions and the
associated costs for inversion calculations . The name ser
maintenance procedure must take appropriate precautions to
avoid problems with data already in the cache, inversions,
This organization solves several difficulties:
When searching the domain space for the answer to a query,

name server can restrict its search for authoritative data
that tree that matches the most labels on the right side o
http ://www-bib .fll-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 5/1/00

HTML Version from RFC D- ~iment Page 32 of 64
domain name of interest.

-r
Since updates to a zone must be atomic with respect to
searches, maintenance operations can simply acquire the ma
lock, insert a new copy of a particular zone without distu
other zones, and then release the storage used by the old
Assuming a central table pointing to valid zone trees, thi
operation can be a simple pointer swap.
Mockapetris [Pag
. .
RFC 883 November
TTL management of zones can be performed using the SOA rec

for the zone . This avoids potential difficulties if indiv
RRs in a zone could be timed out separately . This issue i
discussed further in the maintenance section.
Query processing
The following algorithm outlines processing that takes place

name server when a query arrives:
1. Search the list of zones to find zones which have the same
class as the QCLASS field in the query and have a top doma
name that matches the right end of the QNAME field . If th
are none, go to step 2 . If there are more than one, pick
zone that has the longest match and go to step 3.
2. Since the zone search failed, the only possible RRs are
contained in the non-authoritative tree . Search the cache
for the NS record that has the same class as the QCLASS fi
and the largest right end match for domain name . Add the
record or records to the authority section of the response
the cache tree has RRs that are pertinent to the question
(domain names match, classes agree, not timed-out, and the
field is relevant to the QTYPE), copy these RRs into the a
section of the response . The name server may also search
cache queue . Go to step 4 .'
3. Since this zone is the best match, the zone in which QNAME
resides is either this zone or a zone to which this zone w
directly or indirectly delegate authority . Search down th
tree looking for a NS RR or the node specified by QNAME.
If the node exists and has no NS record, copy the relev

RRs to the answer section of the response and go to ste
If a NS RR is found, either matching a part or all of Q

then QNAME is in a delegated zone outside of this zone.
so, copy the NS record or records into the authority se
of the response, and search the remainder of the zone f
A type record corresponding to the NS reference . If th
record is found, add it to the additional section . Go
step 2.
If the node is not found and a NS is not found, there i

such name ; set the Name error bit in the response and e
4. When this step is reached, the answer and authority sectio

are complete . What remains is to complete the additional
section . This procedure is only possible if the name sery
http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

HTML Version from RFC D- ~ment Page 33 of 64
Mockapetris ' J.Pa g
RFC 883 November

knows the data formats implied by the class of records in

answer and authority sections . Hence this procedure is cl
dependent . Appendix 3 discusses this procedure for Intern
class data.
While this algorithm deals with typical queries and databases
several additions are required that will depend on the databa
supported by the name server ::
QCLASS=*
Special procedures are required when the QCLASS of the que
"*" . If the database contains several classes of data, th
query processing steps above are performed separately for
CLASS, and the results are merged into a single response.
name error condition is not meaningful for a QCLASS=* quer
If the requestor wants this information, it must test each
class independently.
If the database is limited to data of a particular class,

operation can be performed by simply reseting the authorit
bit in the response, and performing the query as if QCLASS
the class used in the database.
* labels in database RRs
Some zones will contain default RRs that use * to match in

cases where the search fails for a particular domain name.
the database contains these records then a failure must be
retried using * in place of one or more labels of the sear
key . The procedure is to replace labels from the left wit
"*"s looking for a match until either all labels have been
replaced, or a match is found . Note that these records ca
never be the result of caching, so a name server can omit
processing for zones that don - t contain RRs with * in labe
or can omit this processing entirely if * never appears in
local authoritative data.
Inverse query processing
Name servers that support inverse queries can support these

operations through exhaustive searches of their databases, bu
this becomes impractical as the size of the database increase
An alternative .approach is to invert the database according t
search key.
For name servers that support multiple zones and a large amou
data, the recommended approach is separate inversions for eac
Mockapetris
RFC 883 November

zone . When a particular zone is changed during a refresh, on

its inversions need to be redone.
Support for transfer of this type of inversion may be include

future versions of the domain system, but is not supported in
http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

version.
Completion query processing
Completion query processing shares many of the same problems

data structure design as are found in inverse queries, but is
different due to the expected high rate of use of top level 1
(ie ., ARPA, CSNET) . A name server that wishes to be efficien
its use of memory may well choose to invert only occurrences
ARPA, etc . that are below the top level, and use a search for
rare case that top level labels are used to constrain a
completion.
Mockapetris [Pag
RFC 883 November

NAME SERVER MAINTENANCE
Introduction
Name servers perform maintenance operations on their database

insure that the data they distribute is accurate and timely.
amount and complexity of the maintenance operations that a na
server must perform are related to the size, change rate, and
complexity of the database that the name server manages.
Maintenance operations are fundamentally different for

authoritative and non-authoritative data . A name server acti
attempts to insure the accuracy and timeliness of authoritati
data by refreshing the data from master copies . Non-authorit
data is merely purged when its time-to-live expires ; the name
server does not attempt to refresh it.
1-ittp ://www-bib .fli-bielefeld .de/epub/doe/idoc/rfe/rfc883 .html 511100

HTML Version from RFC Dr -ment Page 35 of 64
Although the refreshing scheme is fairly simple to implement,

is somewhat less powerful than schemes used in other distribu
database systems . In particular, an update to the master doe
immediately update copies, and should be viewed as gradually
percolating though the distributed database . This is adequat
the vast majority of applications . In situations where timli
is critical, the master name server can prohibit caching of c
or assign short timeouts to copies.
Conceptual model of maintenance operations
The vast majority of information in the domain system is deri

from master files scattered among hosts that implement name
servers ; some name servers will have no master files, other n
servers will have one or more master files . Each master file
contains the master data for a single zone of authority rathe
than data for the whole domain name space . The administrator
particular zone controls that zone by updating its master fil
Master files and zone copies from remote servers may include
that are outside of the zone of authority when a NS record
delegates authority to a domain name that is a descendant of
domain name at which authority is delegated . These forward
references are a problem because there is no reasonable metho
guarantee that the A type records for the delegatee are avail
unless they can somehow be attached to the NS records.
For example, suppose the ARPA zone delegates authority at

MIT .ARPA, and states that the name server is on AI .MIT .ARPA.
resolver gets the NS record but not the A type record for
AI .MIT .ARPA, it might try to ask the MIT name server for the
address of AI .MIT .ARPA.
Mockapetris [ P ag _...
RFC 883 November

The solution is to allow type A records that are outside of t

zone of authority to be copied-with the zone . While these re
won't be found in a search for the A type record itself, they
be protected by the zone refreshing system, and will be passe
back whenever the name server passes back a referral to the
corresponding NS record . If a query is received for the A re
the name server will pass back a referral to the name server
the A record in the additional section, rather than answer
section.
The only exception to the use of master files is a small amou

data stored in boot files . Boot file data is used by name se
to provide enough resource records to allow zones to be impor
from foreign servers (e .g . the address of the server), and to
establish the name and address of root servers . Boot file re
establish the initial contents of the cache tree, and hence c
overridden by later loads of authoritative data . `
The data in a master file first becomes available to users of

domain name system when it is loaded by the corresponding nam
server . By definition, data from a master file is authoritat
Other name servers which wish to be authoritative for a parti

zone do so by transferring a copy of the zone from the name s
which holds the master copy using a virtual circuit . These c
include parameters which specify the conditions under which t
data in the copy is authoritative . In the most common case,
http ://www-bib .fl-i-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 511100

conditions specify a refresh interval and policies to be foil

when the refresh operation cannot be performed.
A name server may acquire multiple zones from different name

servers and master files, but the name server must maintain e
zone separately from others and from non-authoritative data.
When the refresh interval for a particular zone copy expires,

name server holding the copy must consult the name server tha
holds the master copy . If the data in the zone has not chang
the master name server instructs the copy name server to rese
refresh interval . If the data has changed, the master passes
new copy of the zone and its associated conditions to the cop
name server . Following either of these transactions, the cop
name server begins a new refresh interval.
Copy name servers must also deal with error conditions under
they are unable to communicate with the name server that hold
master copy of a particular zone . The policies that a copy n
server uses are determined by other parameters in the conditi
distributed with every copy . The conditions include a retry
interval and a maximum holding time . When a copy name server
Mockapetris Pag
RFC 883 November
unable to establish communications with a master or is unable

complete the refresh transaction, it must retry the refresh
operation at the rate specified by the retry interval . This
interval will usually be substantially shorter than the refre
interval . Retries continue until the maximum holding time is
reached . At that time the copy name server must assume that
copy of the data for the zone in question is no longer
authoritative.
Queries must be processed while maintenance operations are in

progress because a zone transfer can take a long time . Howev
to avoid problems caused by access to partial databases, the
maintenance operations create new copies of data rather than
directly modifying the old copies . When the new copy is comp
the maintenance process locks out queries for a short time us
the main lock, and switches pointers to replace the old data
the new . After the pointers are swapped, the maintenance pro
unlocks the main lock and reclaims the storage used by the of
copy.
Name server data structures and top level logic
The name server must multiplex its attention between multiple

activities . For example, a name server should be able to ans
queries while it is also performing refresh activities for a
particular zone . While it is possible to design a name serve
that devotes a separate process to each query and refresh act
in progress, the model described in this memo is based on the
assumption that there is a single process performing all
maintenance operations, and one or more processes devoted to
handling queries . The model also assumes the existence of sh
memory for several control structures, the domain database, 1
etc.
The model name server uses the following files and shared dat
structures:
1 . A configuration file that describes the master and boot
http ://www-bib .fli-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00


•Y
files which the name server should load and the zones t
the name server should attempt to load from foreign nam
servers . This file establishes the initial contents of
status table.
2. Domain data files that contain master and boot data to

loaded.
3. A status table that is derived from the configuration f

Each entry in this table describes a source of data . E
entry has a zone number . The zone number is zero for
Mockapetris [Pag
_ _ .
RFC 883 November
non-authoritative sources ; authoritative sources are

assigned separate non-zero numbers.
4. The shared database that holds the domain data . This

database is assumed to be organized in some sort of tre
structure paralleling the domain name space, with a lis
resource records attached to each node and leaf in the
The elements of the resource record list need not conta
the exact data present in the corresponding output form
but must contain data sufficient to create the output
format ; for example, these records need not contain the
domain name that is associated with the resource becaus
that name can be derived from the tree structure . Each
resource record also internal data that the name server
to organize its data.
5. Inversion data structures that allow the name server to

process inverse queries and completion queries . Althou
many structures could be used, the implementation descr
in this memo supposes that there is one array for every
inversion that the name server can handle . Each array
contains a list of pointers to resource records such th
the order of the inverted quantities is sorted.
6. The main and cache queue locks
7. The cache queue
The maintenance process begins by loading the status table fr

the configuration file . It then periodically checks each ent
to see if its refresh interval has elapsed . If not, it goes
the next entry . If so, it performs different operations depe
on the entry:
If the entry is for zone 0, or the cache tree, the mainten

process checks to see if additions or deletions are requir
Additions are acquired from the cache queue using the cach
queue lock . Deletions are detected using TTL checks . If
changes are required, the maintenance process recalculates
inversion data structures and then alters the cache tree u
the protection of the main lock . Whenever the maintenance
process modifies the cache tree, it resets the refresh int
to the minimum of the contained TTLs and the desired time
interval for cache additions.
If the entry is not zone 0, and the entry refers to a loca

file, the maintenance process checks to see if the file ha
been modified since its last load . If so the file is relo
using the procedures specified under "Name server file
http ://www-bib .fll-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D(- -ment Page 38 of 64
Mockapetris [Pag
... _ , _ _ -
RFC 883 November
loading" . The refresh interval is reset to that specified

the SOA record if the file is a master file.
If the entry is for a remote master file, the maintenance

process checks for a new version using the procedure descr
in "Names server remote zone transfer".
Name server file loading
Master files are kept in text form for ease of editing by sys
maintainers . These files are not exchanged by name servers;
servers use the standard message format when transferring zon
organizations that want to have a domain, but do not want to

name server, can use these files to supply a domain definitio
another organization that will run a name server for them . F
example, if organization X wants a domain but not a name sery
it can find another organization, Y, that has a name server a
willing to provide service for X . Organization X defines dom
via the master file format and ships a copy of the master fil
organization Y via mail, FTP, or some other method . A system
administrator at'Y configures Y - s name server to read in X's
and hence support the X domain . X can maintain the master fi
using a text editor and send new versions to Y for installati
These files have a simple line-oriented format, with one RR p

line . Fields are separated by any combination of blanks and
characters . Tabs are treated the same as spaces ; in the foll
discussion the term "blank" means either a tab or a blank . A
can be either blank (and ignored), a RR, or a $INCLUDE line.
If a RR line starts with a domain name, that domain name is u

to specify the location in the .domain space for the record, i
the owner . If a RR line starts with a blank, it is loaded in
the location specified by the most recent location specifier.
The location specifiers are assumed to be relative to some or

that is provided by the user of a file unless the location
specifier contains the root label . This provides a convenien
shorthand notation, and can also be used to prevent errors in
master files from propagating into other zones . This feature
particularly useful for master files imported from other site
An include line begins with $INCLUDE, starting at the first 1

position, and is followed by a local file name and an optiona
offset modifier . The filename follows the appropriate local
conventions . The offset is one or more labels that are added
the offset in use for the file that contained the $INCLUDE.
the offset is omitted, the included file is loaded using the
Mockapetris [Pag
...........
RFC 883 November
offset of the file that contained the $INCLUDE command . For

example, a file being loaded at offset ARPA might contain the
following lines:
http://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

$INCLUDE <subsys>isi .data ISI

$INCLUDE <subsys>addresses .data
The first line would be interpreted to direct loading of the

<subsys>isi .data at offset ISI .ARPA . The second line would b
interpreted as a request to load data at offset ARPA.
Note that $INCLUDE commands do not cause data to be loaded in

different zone or tree ; they are simply ways to allow data fo
given zone to be organized in separate files . For example,
mailbox data might be kept separately from host data using th
mechanism.
Resource records are entered as a sequence of fields correspo

to the owner name, TTL, CLASS, TYPE and RDATA components . (N
that this order is different from the order used in examples
the order used in the actual RRs ; the given order allows easi
parsing and defaulting .)
The owner name is derived from the location specifier.
The TTL field is optional, and is expressed as a decimal

number . If omitted TTL defaults to zero.
The CLASS field is also optional ; if omitted the CLASS def

to the most recent . value of the CLASS field in a previous
The RDATA fields depend on the CLASS and TYPE of the RR.
general, the fields that make up RDATA are expressed as de
numbers or as domain names . Some exceptions exist, and ar
documented in the RDATA definitions in Appendicies 2 and 3
this memo.
Because CLASS and TYPE fields don't contain any common

identifiers, and because CLASS and TYPE fields are never deci
numbers, the parse is always unique.
Because these files are text files several special encodings

necessary to allow arbitrary data to be loaded . In particula
A free standing dot is ' used to refer to the current d

name.
A free standing @ is used to denote the current origi
Mockapetris LPag
RFC 883 November

Two free standing dots represent the null domain name

the root.
\X where X is any character other than a digit (0-9), is

to quote that character so that its special meaning d
not apply . For example, "\ ." can be used to place a
character in a label.
\DDD where each D is a digit is the octet corresponding to

decimal number described by DDD . The resulting octet
assumed to be text and is not checked for special mea
( ) Parentheses are used to group data that crosses a lin

boundary . In effect, line terminations are not recog
http ://www-bib .fl-l-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

within parentheses.
Semicolon is used to start a comment ; the remainder o

line is ignored.
Name server file loading example
A name server for F .ISI .ARPA , serving as an authority for th

ARPA and ISI .ARPA domains, might use a boot file and two mast
files . The boot file initializes some non-authoritative data
would be loaded without an origin:
9999999 IN NS B .ISI .ARPA

9999999 CS NS UDEL .CSNET
B .IS .I .ARPA 9999999 IN A 10 .3 .0 .52
UDEL .CSNET 9999999 CS A 302-555-0000
This file loads non-authoritative data which provides the

identities and addresses of root name servers . The first lin
contains a NS RR which is loaded at the root ; the second line
starts with a blank, and is loaded at the most recent locatio
specifier, in this case the root ; the third and fourth lines
RRs at B .ISI .ARPA and UDEL .CSNET, respectively . The timeouts
set to high values (9999999) to prevent this data from being
discarded due to timeout.
The first master file loads authoritative data for the ARPA
domain . This file is designed to be loaded with an origin of
ARPA, which allows the location specifiers to omit the traili
.ARPA labels.
Mockapetris [Pag
- „ _ .
RFC 883 November
IN SOA F .ISI .ARPA Action .E .ISI .ARPA

20 SERIAL
3600 REFRESH
600 RETRY
3600000 ; EXPIRE
60) ; MINIMUM
NS F .ISI .ARPA F .ISI :ARPA is a name server for AR
NS A .ISI .ARPA A .ISI .ARPA is a name server for AR
MIT NS AI .MIT .ARPA ; delegation to MIT name server
ISI NS F .ISI .ARPA ; delegation to ISI name server
UDEL MD UDEL .ARPA

A 10 .0 .0 .96
NBS MD NBS .ARPA
A 10 .0 .0 .19
DTI MD DTI .ARPA
A 10 .0 .0 .12
AI .MIT A 10 .2 .0 .6
F .ISI A 10 .2 .0 .52
The first group of lines contains the SOA record and its
parameters, and identifies name servers for this zone and for
delegated zones . The Action .E .ISI .ARPA field is a mailbox
specification for the responsible person for the zone, and is
http ://www-bib .fh-bielefeld.de/epub/doe/idoc/rfe/rfc883 .html 5/1/00

HTML Version from RFC Dc -rent Page 41 of 64
domain name encoding of the mail destination Action@E .ISI .ARP

The second group specifies data for domain names within this
The last group has forward references for name server address
resolution for AI .MIT .ARPA and F .ISI .ARPA . This data is not
technically within the zone, and will only be used for additi
record resolution for NS records used in referrals . However,
data is protected by the zone timeouts in the SOA, so it will
persist as long as the NS references persist.
The second master file defines the ISI .ARPA environment, and
loaded with an origin of ISI .ARPA:
@ IN SOA F .ISI .ARPA Action\ .ISI .E .ISI .ARPA

20 SERIAL
7200 REFRESH
600 RETRY
3600000 ; EXPIRE
60) ; MINIMUM
F .ISI .ARPA F .ISI .ARPA is a name server
10 .1 .0 .32
A .ISI .ARPA
F .ISI .ARPA
10 .3 .0 .52
B .ISI .ARPA
Mockapetris (Pag
RFC 883 November

MF F .ISI .ARPA
F A 10 .2 .0 .52
MD F .ISI .ARPA
MF A .ISI .ARPA
$INCLUDE <SUBSYS>ISI-MAILBOXES .TXT
Where the file <SUBSYS>ISI-MAILBOXES .TXT is:
MOE MB F .ISI .ARPA

LARRY MB A .ISI .ARPA
CURLEY MB B .ISI .ARPA
STOOGES MB B .ISI .ARPA
MG MOE .ISI .ARPA
MG LARRY .ISI .ARPA
MG CURLEY .ISI .ARPA
Note the use of the \ character in the SOA RR to specify the

responsible person mailbox "Action .ISI@E .ISI .ARPA".
Name server remote zone transfer
When a name server needs to make an initial copy of a zone or

to see if a existing zone copy should be refreshed, it begins
attempting to open a virtual circuit to the foreign name sery
If this open attempt fails, and this was an initial load atte
it schedules a retry and exits . If this was a refresh operat
the name server tests the status table to see if the maximum
holding time derived from the SOA EXPIRE field has elapsed.
not, the name server schedules a retry . If the maximum holdi
time has expired, the name server invalidates the zone in the
status table, and scans all resource records tagged with this
number . For each record it decrements TTL fields by the leng
time since the data was last refreshed . If the new TTL value
negative, the record is deleted . If the TTL value is still
positive, it moves the RR to the cache tree and schedules a r
http ://www-bib .fla-bielefeld .de/epub/doc/idoe/rfe/rfc883 .html 5/1/00

HTML Version from RFC D ;ment Page 42 of 64
If the open attempt succeeds, the name server sends a query t

foreign name server in which QTYPE=SOA, QCLASS i .s set accordi
the status table information from the configuration file, and
QNAME is set to the domain name of the zone of interest.
The foreign name server will return either a SOA record indic
that it has the zone or an error . If an error is detected, t
virtual circuit is closed, and the failure is treated in the
way as if the open attempt failed.
If the SOA record is returned and this was a refresh, rather

an initial load of the zone, the name server compares the SER
Mockapetris [_Pa.g...
RFC 883 November
field in the new SOA record with the SERIAL field in the SOA
record of the existing zone copy . If these values match, the
has not been updated since the last copy and hence there is n
reason to recopy the zone . In this case the name server rese
the times in the existing SOA record and closes the virtual
circuit to complete the operation.
If this is initial load, or the SERIAL fields were different,

name server requests a copy of the zone by sending the foreig
name server an AXFR query which specifies the zone by its QCL
and QNAME fields.
When the foreign name server receives the AXFR request, it se

each node from the zone to the requestor in a separate messag
It begins with the node that contains the SOA record, walks t
tree in breadth-first order, and completes the transfer by
resending the node containing the SOA record.
Several error conditions are possible:
If the AXFR request cannot be matched to a SOA, the foreig

name server will return a single message in response that
not contain the AXFR request . (The normal SOA query prece
the AXFR is designed to avoid this condition, but it is st
possible .)
The foreign name server can detect an internal error or de

some other condition (e .g . system going down, out of resou
etc .) that forces the transfer to be aborted . If so, it s
a message with the "Server failure" condition set . If the
can be immediately retried with some chance of success, it
leaves the virtual open ; otherwise it initiates a close.
If the foreign name server doesn't wish to perform the

operation for policy reasons (i .e . the system administrate
wishes to forbid zone copies), the foreign server returns
"Refused" condition.
The requestor receives these records and builds a new tree.

tree is not yet in the status table, so its data are not used
process queries . The old copy of the zone, if any, may be us
satisfy request while the transfer is in progress.
When the requestor receives the second copy of the SOA node,
compares the SERIAL field in the first copy of the SOA agains
SERIAL field in the last copy of the SOA record . If these do
match, the foreign server updated its zone while the transfer
http://www-bib .fll-bielefeld.de/epub/doc/idoe/rfe/rfc883 .html 5/1/00

HTML Version from RFC r iment Page 43 of 64
in progress . In this case the requestor repeats the AXFR req

to acquire the newer version.
Mockapetris [_Pa .g...._

RFC 883 November
If the AXFR transfer eventually succeeds, the name server clo

the virtual circuit and and creates new versions of inversion
structures for this zone . when this operation is complete, t
name server acquires the main lock in write mode and then rep
any old copy of the zone and inversion data structures with n
ones . The name server then releases the main lock, and can
reclaim the storage used by the old copy.
If an error occurs during the AXFR transfer, the name server

copy any partial information into its cache tree if it wishes
although it will not normally do so if the zone transfer was
refresh rather than an initial load.
Mockapetris [. Pag_
RFC 883 November

RESOLVER ALGORITHMS
http ://www-bib .fh-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 5/1/00

HTML Version from RFC L` -iment Page 44 of 64
Operations
Resolvers have a great deal of latitude in the semantics they

allow in user calls . For example, a resolver might support
different user calls that specify whether the returned inform
must be from and authoritative name server or not . . Resolvers
also responsible for enforcement of any local restrictions on
access, etc.
In any case, the resolver will transform the user query into
number of shared database accesses and queries to remote name
servers . When a user requests a resource associated with a
particular domain name, the resolver will execute the followi
steps:
1. The resolver first checks the local shared database, if an

for the desired information . If found, it checks the
applicable timeout . If the timeout check succeeds, the
information is used to satisfy the user request . If not,
resolver goes to step 2.
2. In this step, the resolver consults the shared database fo

name server that most closely matches the domain name in t
user query . Multiple redundant name servers may be found.
resolver goes to step 3.
3. In this step the resolver chooses one of the available nam

servers and sends off a query . If the query fails, it tri
another name server . If all fail, an error indication is
returned to the user . If a reply is received the resolver
the returned RRs to its database and goes to step 4.
4. In this step, the resolver interprets the reply . If the r

contains the desired information, the resolver returns the
information to the user . The the reply indicates that the
domain name in the user query doesn't exist, then the reso
returns an error to the user . If the reply contains a
transient name server failure, the resolver can either wai
retry the query or go back to step 3 and try a different n
server . If the reply doesn't contain the desired informat
but does contain a pointer to a closer name server, the
resolver returns to step 2, where the closer name servers
be queried.
Several modifications to this algorithm are possible . A reso

may not support a local cache and instead only cache informat
during the course of a single user request, discarding it upo
Mockapetris [Pag
RFC 883 November

completion . The resolver may also find that a datagram reply

truncated, and open a virtual circuit so that - the complete re
can be recovered.
Inverse and completion queries must be treated in an

environment-sensitive manner, because the domain system doesn
provide a method for guaranteeing that it can locate the Corr
information . The typical choice will be to configure a resol
to use a particular set of known name servers for inverse que
http ://www-bib .fla-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 511100

HTML Version from RFC D- iment Page 45 of 64
Mockapetris LPag.. .
RFC 883 November

DOMAIN SUPPORT FOR MAIL
Introduction
Mail service is a particularly sensitive issue for users of t

domain system because of the lack of a consistent system for
naming mailboxes and even hosts, and the need to support cont
operation of existing services . This section discusses an
evolutionary approach for adding consistent domain name suppo
for mail.
The crucial issue is deciding on the types of binding to be

supported . Most mail systems specify a mail destination with
two-part construct such as X@Y . The left hand side, X, is an
string, often a user or account, and Y is a string, often a h
This section refers to the part on the left, i .e . X, as .the 1
part, and refers to the part on the right, i .e . Y, as the glo
part.
Most existing mail systems route mail based on the global par
mailer with mail to deliver to X@Y will decide on the host to
contacted using only Y . We refer to this type of binding as
"agent binding".
http://www-bib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc883 .html 5/1/00

HTML Version from RFC D iment Page 46 of 64

-i
For example, mail addressed to Mockapetris@ISIF is deliver

host USC-ISIF (USC-ISIF is the official name for the host
specified by nickname ISIF).
More sophisticated mail systems use both the local and global
parts, i .e . both X and Y to determine which host should recei
the mail . These more sophisticated systems usually separate
binding of the destination to the host from the actual delive
This allows the global part to .be a generic name rather than
constraining it to a single host . We refer to this type of
binding as "mailbox binding".
For example, mail addressed to Mockapetris@ISI might be bo

to host F .ISI .ARPA, and subsequently delivered to that hos
while mail for Cohen@ISI might be bound to host B .ISI .ARPA
The domain support for mail consists of two levels of support

corresponding to these two binding models.
The first level, agent binding, is compatible with existin

ARPA Internet mail procedures and uses maps a global part
one or more hosts that will accept the mail . This type of
binding uses the MAILA QTYPE.
The second level, mailbox binding, offers extended service
Mockapetris [Pag_
,
RFC 883 November
that map a local part and a global part onto one or more s
of data via the MAILB QTYPE . The sets of data include hos
that will accept the mail, mailing list members (mail gro
and mailboxes for reporting errors or requests to change a
group.
The domain system encodes the'global part of a mail destinati

a domain name and uses dots in the global part to separate la
in the encoded domain name . The domain system encodes the to
part of a mail destination as a single label, and any dots in
part are simply copied into the label . The domain system for
complete mail destination as the local label concatenated to
domain string for the global part . We call this a mailbox.
For example, the mailbox Mockapetris@F .ISI .ARPA has a glob

domain name of three labels, F .ISI .ARPA . The domain name
encoding for the whole mailbox is Mockapetris .F .ISI .ARPA.
mailbox Mockapetris .cad@F .ISI .ARPA has the same domain nam
the global part and a 4 label domain name for the mailbox
Mockapetris\ .cad .F .ISI .ARPA (the \ is not stored in . the la
its merely used to denote the "quoted" dot) .,
It is anticipated that the Internet system will adopt agent

binding as part of the initial implementation of the domain
system, and that mailbox binding will eventually become the
preferred style as organizations convert their mail systems t
new style . To facilitate this approach, the domain informati
for these two binding styles is organized to allow a requesto
determine which types of support are available, and the
information is kept in two disjoint classes.
Agent binding
In agent binding, a mail system uses the global part of the m
http://www-bib .flz-bielefeld .de/epub/doe/idoc/rfc/rfc883 .html 5/1/00

HTML Version from RFC D lm .ynt Page 47 of 64
destination as a domain name, with dots denoting structure.

domain name is resolved using a MAILA query which return MF a
RRs to specify the domain name of the appropriate host to rec
the mail . MD (Mail delivery) RRs specify hosts that are expe
to have the mailbox in question ; MF (Mail forwarding) RRs spe
hosts that are expected to be intermediaries willing to accep
mail for eventual forwarding . The hosts are hints, rather th
definite answers, since the query is made without the full ma
destination specification.
For example, mail for MOCKAPETRIS@F .ISI .ARPA would result in

query with QTYPE=MAILA and QNAME=F .ISI .ARPA, which might retu
two RRs:
Mockapetris P ag ....
RFC 883 November


The mailer would interpret these to mean that the mail agent
F .ISI .ARPA should be able to deliver the mail directly, but t
A .ISI .ARPA is willing to accept the mail for probable forward
Using this system, an organization could implement a system t

uses organization names for global parts, rather than the usu
host names, but all mail for the organization would be routed
same, regardless of its local part . Hence and organization w
many hosts would expect to see many forwarding operations.
Mailbox binding
In mailbox binding, the mailer uses the entire mail destinati

specification to construct a domain name . The encoded domain
for the mailbox is used as the QNAME field in a QTYPE=MAILB q
Several outcomes are possible for this query:
1. The query can return a name error indicating that the mail
does not exist as a domain name.
In the long term this would indicate that the specified ma

doesn't exist . However, until the use of mailbox binding
universal, this error condition should be interpreted to m
that the organization identified by the global part does n
support mailbox binding . The appropriate procedure is to
revert to agent binding at this point.
2. The query can return a Mail Rename (MR) RR.
The MR RR carries new mailbox specification in its RDATA f

The mailer should replace the old mailbox with the new one
retry the operation.
3. The query can return a MB RR.
The MB RR carries a domain name for a host in its RDATA fi

The mailer should deliver the message to that host via wha
protocol is applicable, e .g . SMTP.
4. The query can return one or more Mail Group (MG) RRs.
http ://www-bib .fh-bielefeld .de/epub/doe/idoe/rfe/rfc883 .html 5/1/00

HTML Version from RFC D! ment Page 48 of 64
This condition means that the mailbox was actually a maili

list or mail group, rather than a single mailbox . Each MG
has a RDATA field that identifies a mailbox that is a memb
Mockapetris P_a J._.

RFC 883 November
the group . The mailer should deliver a copy of the messag

each member.
5 . The query can return a MB RR as well as one or more MG RRs
This condition means the the mailbox was actually a mailin

list . The mailer can either deliver the message to the ho
specified by the MB RR, which will in turn do the delivery
all members, or the mailer can use the MG RRs to do the
expansion itself.
In any of these cases, the response may include a Mail Inform

(MINFO) RR . This RR is usually associated with a mail group,
is legal with a MB . The MINFO RR identifies two mailboxes.
of these identifies a responsible person for the original mai
name . This mailbox should be used for requests to be added t
mail group, etc . The second mailbox name in the MINFO RR
identifies a mailbox that should receive error messages for m
failures . This is particularly appropriate for mailing,lists
errors in member names should be reported to a person other t
the one who sends a message to the list . New fields may be a
to this RR in the future.
Mockapetris (Pag
RFC 883 November

Domain Names - Implementation and Specific .
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

' F.
HTML Version from RFC D- =ment Page 49 of 64
The preferred syntax of domain names is given by the following B

rules . Adherence to this syntax will result in fewer problems w
many applications that use domain names (e .g ., mail, TELNET) . N
that some applications use domain names containing binary inform
and hence do not follow this syntax.
<domain> <subdomain> 1 " "

<subdomain> : .= <label> <subdomain> " ." <label>
<label> <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> <let-dig-hyp> <let-dig-hyp> <ldh-str>
<let-dig-hyp> : .= <let-dig> 1111

<let-dig> <letter> I <digit>
<letter> any one of the 52 alphabetic characters A throug
in upper case and a through z in lower case
<digit> : .= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in doma
names no significance is attached to the case . That is, two nam
with the same spelling but different case are to be treated as i
identical.
The labels must follow the rules for ARPANET host names . They m
start with a letter, end with a letter or digit, and have as int
characters only letters, digits, and hyphen . There are also som
restrictions on the length . Labels must be 63 characters or les
For example, the following strings identify hosts in the ARPA

Internet:
F .ISI .ARPA LINKABIT-DCNS .ARPA UCL-TAC .ARPA
Mockapetris [Pag
RFC 883 November

Appendix 2 - Field formats and encodings
+ +
***** WARNING *****
The following formats are preliminary and

are included for purposes of explanation only.
In particular, new RR types will be added,
and the size, position, and encoding of
http ://www-bib .fh-blelefeld.de/epub/doc/idoc/rfc/i-fc883 .html 5/1/00

`

HTML Version from RFC D- - !ment Page 50 of 64
fields are subject to change.
-------------------------------------------
TYPE values
TYPE fields are used in resource records . Note that these ty

are not the same as the QTYPE fields used in queries, althoug
functions are often similar.
TYPE value meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination
MF 4 a mail forwarder
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name
MG 8 a mail group member
MR 9 a mail rename domain name
NULL 10 a null RR
WKS 11 a well known service description
PTR 12 a domain name pointer
HINFO 13 host information
MINFO 14 mailbox or mail list information
Mockapetris [Pag
_ .. .
RFC 883 November

QTYPE values
QTYPE fields appear in the question part of a query . They in

the values of TYPE with the following additions:
AXFR 252 A request for a transfer of an entire zone of auth
MAILB 253 A request for mailbox-related records (MB, MG or M
MAILA 254 A request for mail agent RRs (MD and MF)
* 255 A request for all records
CLASS values
CLASS fields appear in resource records
CLASS value meaning
IN 1 the ARPA Internet
http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 511100

CS 2. the computer science network (CSNET)
QCLASS values
QCLASS fields appear in the question section of a query . The

include the values of CLASS with the following additions:
* 255 any class
Mockapetris (Pag
RFC 883 November

Standard resource record formats
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
/ NAME /
TYPE
CLASS
TTL
RDLENGTH
/ RDATA /
where:
NAME - a compressed domain name to which this resource

record pertains.
TYPE - two octets containing one of the RR type codes

defined in Appendix 2 . This field specifies the
meaning of the data in the RDATA field.
http://www-bib .fn-blelefeld.de/epub/doc/idoc/rfc/rfc883 .html 5/1/00

CLASS - two octets which specifies the class of the data

the RDATA field.
TTL - a 16 bit signed integer that specifies the time

interval that the resource record may be cached
before the source of the information should agai
consulted . Zero values are interpreted to mean
the RR can only be used for the transaction in
progress, and should not be cached . For example
records are always distributed with a zero TTL t
prohibit caching . Zero values can also be used
extremely volatile data.
RDLENGTH- an unsigned 16 bit integer that specifies the le

in octets of the RDATA field.
Mockapetris L Pa.g. ._
RFC 883 November
RDATA - a variable length string of octets that describes

resource . The format of this information varies
according to the TYPE and CLASS of the resource
record.
The format of the RDATA field is standard for all classes for
RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINF
NULL . These formats are shown below together with the approp
additional section RR processing.
CNAME RDATA format
/ CNAME /
where:
CNAME - A compressed domain name which specifies that th

domain name of the RR is an alias for a canonica
name specified by CNAME.
CNAME records cause no additional section processing . The

RDATA section of a CNAME line in a master file is a standa
printed domain name.
HINFO RDATA format
/ CPU /
/ OS /
where:
CPU - A character string which specifies the CPU type.

character string is represented as a single octe
length followed by that number of characters.
following standard strings are defined :.
PDP-11/70 C/30 C/70 VAX-11/780
http://www-bib .fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 511100

HTML Version from RFC D , iment Page 53 of 64

-Y
H-316 H-516 DEC-2060 DEC-1090T

ALTO IBM-PC IBM-PC/XT PERQ
IBM-360/67 IBM-370/145
OS - A character string which specifies the operating sy

type . The character string is represented as a single oct
Mockapetris [ Pag.. .
RFC 883 November

length followed by that number of characters . The follo

standard types are defined :.
ASP AUGUST BKY CCP

DOS/360 ELF EPOS EXEC-8
GCOS GPOS ITS INTERCOM
KRONOS MCP MOS MPX-RT
MULTICS MVT NOS NOS/BE
OS/MVS OS/MVT RIG RSX11
RSX11M RT11 SCOPE SIGNAL
SINTRAN TENEX TOPS10 TOPS20
TSS UNIX VM/370 VM/CMS
VMS WAITS
HINFO records cause no additional section processing.
HINFO records are used to acquire general information abou

host . The main use is for protocols such as FTP that can
special procedures when talking between machines or operat
systems of the same type.
MB RDATA format
/ MADNAME /
where:
MADNAME - A compressed domain name which specifies a host

has the specified mailbox.
MB records cause additional section processing which looks

an A type record corresponding to MADNAME . The RDATA sect
of a MB line in a master file is a standard printed domain
name.
MD RDATA format
/ MADNAME /
where:
Mockapetris [Pag
RFC 883 November
http ://www-bib .fh-bielefeld.de/epub/doc/ldoc/rfe/rfe883 .html 5/1/00

r Domain Names - Implementation and Specific
has a mail agent for the domain which should be

to deliver mail for the domain.
MD records cause additional section processing which looks

of a MD line in a master file is a standard printed domain
name.
MF RDATA format
/ MADNAME /
where:

has a mail agent for the domain which will accep
mail for forwarding to the domain.
MF records cause additional section processing which looks

of a MF line in a master file is a standard printed domain
name.
MG RDATA format
/ MGMNAME /
where:
MGMNAME - A compressed domain name which specifies a mailb

which is a member of the mail group specified by
domain name.
MF records cause no additional section processing . The RD

section of a MF line in a master file is a standard printe
domain name.
Mockapetris [Pag
RFC 883 November

MINFO RDATA format
/ RMAILBX /
/ EMAILBX /
http ://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 511100

where:
RMAILBX - A compressed domain name which specifies a mailb

which is responsible for the mailing list or mai
If this domain name names the root, the owner of
MINFO RR is responsible for itself . Note that m
existing mailing lists use a mailbox X-request f
the RMAILBX field of mailing list X, e .g.
Msgroup-request for Msgroup . This field provide
more general mechanism.
EMAILBX - A compressed domain name which specifies a mailb

which is to receive error messages related to th
mailing list or mailbox specified by the owner o
MINFO RR (similar to the ERRORS-TO : field which
been proposed) . If this domain name names the r
errors should be returned to the sender of the
message.
MINFO records cause no additional section processing . Alt

these records can be associated with a simple mailbox, the
usually used with a mailing list . The MINFO section of a
line in a master file is a standard printed domain name.
MR RDATA format
/ NEWNAME /
where:
NEWNAME - A compressed domain name which specifies a mailb

which is the proper rename of the specified mail
MR records cause no additional section processing . The RD

section of a MR line in a master file is a standard printe
domain name.
Mockapetris [Pag
RFC 883 November

NULL RDATA format
/ <anything> /
Anything at all may be in the RDATA field so long as it is

65535 octets or less.
NULL records cause no additional section processing . NULL

are not allowed in master files.
NS RDATA format
/ NSDNAME /
http ://www-bib .fh-bielefeld .de/epub/doe/idoe/rfe/rfc883 .html 5/1/00

where:
NSDNAME - A compressed domain name which specifies a host

has a name server for the domain.
NS records cause both the usual additional section process

to locate a type A record, and a special search of the zon
which they reside . The RDATA section of a NS line in a ma
file is a standard printed domain name.
PTR RDATA format
/ PTRDNAME /
where:
PTRDNAME - A compressed domain name which points to some

location in the domain name space.
PTR records cause no additional section processing . These

are used in special domains to point to some other locatio
the domain space . These records are simple data, and don'
imply any special processing similar to that performed by
CNAME, which identifies aliases . Appendix 3 discusses the
of these records in the ARPA Internet address domain.
Mockapetris [Pag

RFC 883 November
SOA RDATA format
/ MNAME /
/ RNAME /
SERIAL
REFRESH
RETRY
EXPIRE
MINIMUM
where:
MNAME - The domain name of the name server that was the
original source of data for this zone.
RNAME - A domain name which specifies the mailbox . of the

person responsible for this zone.
http ://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 511100

' F:
't
SERIAL - The unsigned 16 bit version number of the of the

original copy of the zone . This value wraps and
should be compared using sequence space arithmet
REFRESH - The unsigned 32 bit time interval before the zon

should be refreshed.
RETRY - The unsigned 32 bit time interval that should el

before a failed refresh should be retried.
EXPIRE - A 32 bit time value that specifies the upper lim

the time interval that can elapse before the zon
no longer authoritative.
MINIMUM - The unsigned 16 bit minimum TTL field that shoul

exported with any RR from this zone (other than
SOA itself).
SOA records cause no additional section processing . The R
Mockapetris [Pag_
RFC 883 November

section of a SOA line in a master file is a standard print

domain name for MNAME, a standard X@Y mailbox specificatio
RNAME, and decimal numbers for the remaining parameters.
All times are in units of seconds.
Most of these fields are pertinent only for name server

maintenance operations . However, MINIMUM is used in all q
operations that retrieve RRs from a zone . Whenever a RR i
sent in a response to a query, the TTL field is set to the
maximum of the TTL field from the RR and the MINIMUM field
the appropriate SOA . Thus MINIMUM is a lower bound on the
field for all RRs in a zone . RRs in a zone are never disc
due to timeout unless the whole zone is deleted . This pre
partial copies of zones.
http ://www-bib .fh-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D , anent Page 58 of 64
Mockapetris [_P a.g..._

RFC 883 November
Appendix 3 - Internet specific field formats and operations
Message transport
The Internet supports name server access using TCP [10] on se

port 53 (decimal) as well as datagram access using UDP [11] o
port 53 (decimal) . Messages sent over TCP virtual circuits a
preceded by an unsigned 16 bit length field which describes t
length of the message, excluding the length field itself.
***** WARNING *****
The following formats are preliminary and

are included for purposes of explanation only.
In particular, new RR types will be added,
and the size, position, and encoding of
fields are subject to change.
* +
A RDATA format
ADDRESS
where:
ADDRESS - A 32 bit ARPA internet address
Hosts that have multiple ARPA Internet addresses will have

multiple A records.
A records cause no additional section processing . The RDATA

section of an A line in a master file is an Internet address
expressed as four decimal numbers separated by dots without a
imbedded spaces (e .g ., 11 10 .2 .0 .52" or 11 192 .0 .5 .6 11 ).
Mockapetris [Pag
http ://www-bib .fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 5/1/00

HTML Version from RFC r ument Page 59 of 64
RFC 883 November

WKS RDATA format
ADDRESS
PROTOCOL
/ <BIT MAP> /
where:
ADDRESS - An 32 bit ARPA Internet address
PROTOCOL - An 8 bit IP protocol number
<BIT MAP> - A variable length bit map . The bit map must be a
multiple of 8 bits long.
The WKS record is used to describe the well known services

supported by a particular protocol on a particular internet
address . The PROTOCOL field specifies an IP protocol number,
the bit map has one bit per port of the specified protocol.
first .bit corresponds to port o, the second to port 1, etc.
less than 256 bits are present, the remainder are assumed to
zero . The appropriate values for ports and protocols are
specified in (131.
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to

port 25 (SMTP) . If this bit is set, a SMTP server should be
listening on TCP port 25 ; if zero, SMTP service is not suppor
on the specified address.
The anticipated use of WKS RRs is to provide availability

information for servers for TCP and UDP . If a server support
both TCP and UDP, or has multiple Internet addresses, then
multiple WKS RRs are used.
WKS RRs cause no additional section processing . The RDATA se

of a WKS record consists of a decimal protocol number followe
mnemonic identifiers which specify bits to be set to 1.
IN-ADDR special domain
The ARPA internet uses a special domain to support gateway

location and ARPA Internet address to host mapping . The inte
this domain is to allow queries to locate all gateways on a
Mockapetris [Pag .,
RFC 883 November

particular network in the ARPA Internet, and also to provide

guaranteed method to perform host address to host name mappin
Note that both of these services are similar to functions tha

could be performed by inverse queries ; the difference is that
part of the domain name space is structured according to addr
http ://www-bib .fh-bielefeld .de/epub/doe/idoc/rfe/rfc883 .html 5/1 /on

HTML Version from RFC Dr -rent Page 60 of 64
and hence can guarantee that the appropriate data can be loca
without an exhaustive search of the domain space . It is
anticipated that the special tree will be used by ARPA Intern
resolvers for all gateway location services, but that address
name resolution will be performed by first trying the inverse
query on the local name server database followed by a query i
special space if the inverse query fails.
The domain is a top level domain called IN-ADDR whose substru

follows the ARPA Internet addressing structure.
Domain names in the IN-ADDR domain are defined to have up to

labels in addition to the IN .-ADDR label . Each label is a
character string which expresses a decimal value in the range
0-255 (with leading zeros omitted except in the case of a zer
octet which is represented by a single zero) . These labels
correspond to the 4 octets of an ARPA Internet address.
Host addresses are represented by domain names that have all

labels specified . Thus data for ARPA Internet address 10 .2 .0
is located at domain name 52 .0 .2 .10 .IN-ADDR . The reversal, t
awkward to read, allows zones to follow the natural grouping
hosts within networks . For example, 10 .IN-ADDR can be a zone
containing data for the ARPANET, while 26 .IN-ADDR can be a
separate zone for MILNET . Address nodes are used to hold poi
to primary host names in the normal domain space.
Network addresses correspond to some of the non-terminal node

the IN-ADDR tree, since ARPA Internet network numbers are eit
1, 2, or 3 octets . Network nodes are used to hold pointers t
primary host names (which happen to be gateways) in the norma
domain space . Since a gateway is, by definition, on more tha
network, it will typically have two or more network nodes tha
point at the gateway . Gateways will also have host level poi
at their fully qualified addresses.
Both the gateway pointers at network nodes and the normal hos
pointers at full address nodes use the PTR RR to point back t
primary domain names of the corresponding hosts.
For example, part of the IN-ADDR domain will contain informat

about the ISI to MILNET and MIT gateways, and hosts F .ISI .ARP
MULTICS .MIT .kRPA . Assuming that ISI gateway has addresses
Mockapetris [Pag
RFC 883 November

10 .2 .0 .22 and 26 .0 .0 .103, and a name MILNET-GW .ISI .ARPA, and

MIT gateway has addresses 10 .0 .0 .77 and 18 .10 .0 .4 and a name
GW .MIT .ARPA, the domain database would contain:
IO .IN-ADDR PTR IN MILNET-GW .ISI .ARPA

10 .IN-ADDR PTR IN GW .MIT .ARPA
18 .IN-ADDR PTR IN GW .MIT .ARPA
26 .IN-ADDR PTR IN MILNET-GW .ISI .ARPA
22 .0 .2 .10 .IN-ADDR PTR IN MILNET-GW .ISI .ARPA
103 .0 .0 .26 .IN-ADDR PTR IN MILNET-GW .ISI .ARPA
77 .0 .0 .10 .IN-ADDR PTR IN GW .MIT .ARPA
4 .0 .10 .18 .IN-ADDR PTR IN GW .MIT .ARPA
52 .0 .2 .10 .IN-ADDR PTR IN F .ISI .ARPA
6 .0 .0 .10 .IN-ADDR PTR IN MULTICS .MIT .ARPA
Thus a program which wanted to locate gateways on net 10 woul

,
originate a query of the form QTYPE=PTR, QCLASS=IN,
http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100

HTML Version from RFC D( -rent Page 61 of 64
QNAME=10 .IN-ADDR . It would receive two RRs in response:
IO .IN-ADDR PTR IN MILNET-GW .ISI .ARPA

IO .IN-ADDR PTR IN GW .MIT .ARPA
The program could then originate QTYPE=A, QCLASS=IN queries f

MILNET-GW .ISI .ARPA and GW .MIT .ARPA to discover the ARPA Inter
addresses of these gateways.
A resolver which wanted to find the host name corresponding t

ARPA Internet host address 10 .0 .0 .6 might first try an invers
query on the local name server, but find that this informatio
wasn't available . It. could .then try a query of the form
QTYPE=PTR, QCLASS=IN, QNAME=6 .0 .0 .10 .IN-ADDR, and would recei
6 .0 .0 .10 .IN-ADDR PTR IN MULTICS .MIT .ARPA
Several cautions apply to the use of these services:
Since the IN-ADDR special domain and the normal domain for
particular host or gateway will be in different zones, the
possibility exists that that the data may be inconsistent.
Gateways will often have two names in separate domains, on

one of which can be primary.
Systems that use the domain database to initialize their

routing tables must start with enough gateway information
guarantee that they can access the appropriate name server
The gateway data only reflects the existence of a gateway
Mockapetris _[_Pag
RFC 883 November

manner equivalent to the current HOSTS .TXT file . It doesn

replace the dynamic availability information from GGP or E
http://www-bib .fh-bielefeld .de/epub/doc/idoc/rfe/rfc883 .html 511100

HTML Version from RFC Df nent Page 62 of 64
Mockapetris [Pag
RFC 883 November

[1] E . Feinler, K . Harrenstien, Z . Su, and V . White, "DOD Inter

Host Table Specification", RFC 810, Network Information Cen
SRI International, March 1982.
[2] J . Postel, "Computer Mail Meeting Notes" RFC__ 805,

USC/Information Sciences Institute, February 1982.
[3] Z . Su, and J . Postel, "The Domain Naming Convention for Int
User Applications", RFC 819, Network Information Center, SR
International, August 1982.
[4] Z . Su, "A Distributed System for Internet Name Service",

October 1982.
[5] K . Harrenstien, and V . White, "NICNAME/WHOIS", RFC 81. 2Net

Information Center, SRI International, March 1982.
[6] M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Nam

Server", Computer Networks, vol 6, nr 3, July 1982.
[7] K . Harrenstien, "NAME/FINGER", RFC 742, Network Information

Center, SRI International, December 1977.
[8] . J . Postel, "Internet Name Server", IEN 116, USC/Information

[9] K . Harrenstien, V . White, and E . Feinler, "Hostnames Server

March 1982.
[10] J . Postel, "Transmission Control Protocol", RFC 793,

USC/Information Sciences Institute, September 1981.
[11] J . Postel, "User Datagram Protocol", RFC 768, USC/Informati

http://www-bib .fh-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 511100

HTML Version from RFC D( rent Page 63 of 64
[12] J . Postel, "Simple Mail Transfer Protocol", RFC 821,

USC/Information Sciences Institute, August 1980.
[13] J . Reynolds, and J . Postel, "Assigned Numbers", RF_C870,

USC/Information Sciences Institute, October 1983
[14] P . Mockapetris, "Domain names - Concepts and Facilities,"

RFC 882, USC/Information Sciences Institute, November 1983.
Mockapetris [Pa
RFC 883 November

INDEX
* usage . . . . . . . . . . . . . . . . . . . . . . .. 3
A RDATA format
byte order :
cache queue 3
character case
CLASS
completion
compression
CNAME RR
header format
HINFO RR
include files
inverse queries
mailbox names
master files
MB RR
MD RR
message format
MF RR
MG RR
MINFO RR
MR RR
NULL RR
NS RR
PTR RR : 6
QCLASS
QTYPE
queries (standard)
recursive service
RR format
SOA RR
Special domains
TYPE
WKS type RR
http ://www-bib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc883 .html 5/1/00

HTML Version from RFC D~ nent Page 64 of 64
Mockapetris [Pag
Converted to HTML with rfc2html from RFC 883 at Mon May 123 :07:17 2000
rfc2html (9 1997 by Marcus Niemann, Fachhochschule Bielefeld
Haben Sie noch Fragen? Webmaster

01997-2000 Bibliothek Fachhochschule Bielefeld
Letzte 4derung am Mon May 122 :07:13 2000 durch _Webmaster
Wiischenswertes andAnregungen bitte an : webmaster(a)wW ib.fli-bielefeld.de
http://www-bib .fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 5/1/00

r Application No. Applic . : ;<<s)

091232,908 Hudetz et al.
Notice of Allowability Examiner GrouD Art Unit
Pan 1 2783
All claims being allowable, PROSECUTION ON THE MERITS IS (OR REMAINS) CLOSED in this application . If not included
herewith (or previously mailed), a Notice of Allowance and Issue Fee Due or other appropriate communication will be mailed
in due course.
Z] This communication is responsive to the amendment filed on 05/03/00

Qq The allowed claim(s) is/are 33-127
q The drawings filed on are acceptable,
q Acknowledgement is made of a claim for foreign priority under 35 U .S .C . § 119(a)-(d).

q All q Some* [gone of the CERTIFIED copies of the priority documents have been
q received.
*Certified copies not received:
A SHORTENED STATUTORY PERIOD FOR RESPONSE to comply with the requirements noted below is set to EXPIRE
THREE MONTHISROM THE "DATE MAILED" of this Office action . Failure to timely comply will result in
ABANDONMENT of this application . Extensions of time maybe obtained under the provisions of 37 CFR 1 .136(a).
q Note the attached EXAMINER'S AMENDMENT or NOTICE OF INFORMAL APPLICATION, PTO-152, which discloses that
the oath or declaration is deficient . A SUBSTITUTE OATH OR DECLARATION IS REQUIRED.
Applicant MUST submit NEW FORMAL DRAWINGS

q because the originally filed drawings were declared by applicant to be informal.
~C] including changes required by the Notice of Draftsperson's Patent Drawing Review, PTO-948, attached hereto or to
Paper No . 4.
including changes required by the proposed drawing correction filed on May 3. 2000 which has been
approved by the examiner.
q including changes required by the attached Examiner's Amendment/Comment.
Identifying indicia such as the application number (see 37 CFR 1 .84(c)) should be written on the reverse side of
the drawings . The drawings should be filed as a separate paper with a transmittal lettter addressed to the Official
Draftsperson.
q Note the attached Examiner's comment regarding REQUIREMENT FOR THE DEPOSIT OF BIOLOGICAL MATERIAL.
Any response to this letter should include, in the upper right hand corner, the APPLICATION NUMBER (SERIES
CODE/SERIAL NUMBER) . If applicant has received a Notice of Allowance and Issue Fee Due, the ISSUE BATCH NUMBER
and DATE of the NOTICE OF ALLOWANCE should also be included.
Attachment(s)
q Notice of References Cited, PTO=892
Information Disclosure Statement(§), PTO-1449, Paper No(s) . 8
q Notice of Draftsperson's Patent Drawing Review, PTO-948
q Examiner's Amendment/Comment
q Examiner's Comment Regarding Requirement for Deposit of Biological Material
q Examiner's Statement of Reasons for Allowance
PTO-37 (Rev . 9-95) Notice of Allowability Part of Paper No. 9

NOTICE OF ALLOWANCE AND ISSUE FEE DUE
I (~l•,1 i~f i
j( :~I'f'v i.t(1F•~{~ :1_IYrili~: :. li :iaiil :!
f•~N::~.:!~.I 'Yf :ff tl : P'.I`f :f. Ei a, t.- :r':
APPLICATION NO. FILING DATE TOTAL CLAIMS EXAMINER AND GROUP ART UNIT DATE MAILED
First Named
Applicant . i Ea };:i .l.., i . +a:f• t. {.—, is i:'+°ffi +ir! ; 1: „ 1 .4 (+r :1 ;'ic., ;.
TITLE OF . .~ . t ..i. .laff t

:::•?Y 1 l.pF
INVENTION .} I f: ;:.,'1 '! !',{F :: I f°If;lt :+ f' f._IF , h1i_L I!_!IYff-1 f :f. k.: <'lf. ::l::F::.•i9`: FY I ' 11::; 1_f..fMI"1..,11: :Fi CIV1, 1"< A IC: ;
ATTY'S DOCKET NO . CLASS-SUBCLASS BATCH NO. APPLN . TYPE SMALL ENTITY FEE DUE DATE DUE
4 c;la .... rl ;:, a. :'S t+ :• >t ;'= ,, iitiU f~1 :1 . UT :[i.. .. 1"i0(1 !:I ;j to t111!
THE APPLICATION IDENTIFIED ABOVE HAS BEEN EXAMINED AND IS ALLOWED FOR ISSUANCE AS A PATENT,
PROSECUTION ON THE MERITS IS CLOSED.
z
THE ISSUE FEE MUST BE PAID WITHIN THREE MONTHS FROM THE MAILING DATE OF THIS NOTICE OR THIS
APPLICATION SHALL BEREGARDED AS ABANDONED . THIS STATUTORY PERIOD CANN@T BE EXTENDED.
HOW TO RESPOND TO THIS NOTICE: Y

1 . Review the SMALL ENTITY status shown above .
If the SMALL ENTITY is shown as YES, verify your If the SMALL ENTITY is shown as NO:
current SMALL ENTITY status:
A. If the status is changed, pay twics the amount of the

FEE DUE shown above and notify the Patent and A . Pay FEE DUE shown above, or
Trademark Office of the change in status, or
B. If the status is the same, pay the FEE DUE shown
above . B . File verified statement of Small Entity Status before, or with,
payment of 1/2 the FEE DUE shown above.
11 . Part B-Issue Fee Transmittal should be completed and returned to the Patent and Trademark Office (PTO) with your
ISSUE FEE . Even if the ISSUE FEE has already been paid by charge to deposit account, Part B,Issue Fee Transmittal
should be completed and returned . If you are charging the ISSUE FEE to your deposit account, section "4b" of Part
B-Issue Fee Transmittal should be completed and an extra copy of the form should be submitted.
111 . All communications regarding this application must give application number and batch number.
Please direct all communications prior to issuance to Box ISSUE FEE unless advised to the contrary.
IMPORTANT REMINDER : . Utility patents issuing on applications filed on or after Dec. 12, 1980 may require payment of
maintenance fees. It is patentee's responsibility to ensure timely payment of maintenance
fees when due.
PATENT AND TRADEMARK OFFICE . COPY
PTOL-85 (REV. 10-96) Approved for use through 06/30/99 . (0651-0033) *U.S. GPO : 1999 .45441F/24601

,
s.
PART B—ISSUE FEE; TRANSMITTAL
--complete and mail this form, together with applicai d, .jes ; to : Box ISSUE FEE
Assistant Commissioner for Patents•,
MAILING INSTRUCTIONS: This form should be used for transmitting the ISSUE FEE . Blocks' 1 Note : The certificate of mailing below can only be used for domestic
through 4 should be completed where appropriate . All further correspondence including the Issue Fee mailings of the Issue Fee Transmittal . This certificate cannot be used
Receipt, the Patent, advance orders and notification of maintenance fees will be mailed to the current for any other accompanying papers : Each additional paper, such as an
correspondence address as indicated unless corrected below or directed otherwise in Block 1, by (a) assignment orformal drawing, must have Its own certificate of mailing.
specifying a new correspondence address ; and/or (b) indicating a separate "FEE ADDRESS" for
maintenance fee notifications . Certificate of Mailing
CURRENT CORRESPONDENCE ADDRESS (Note : Legibly mark-up with any corrections or use Block 1) 1 hereby certify that this Issue Fee Transmittal is being deposited with
the United States Postal Service with sufficient postage for first class
! !-• -1 matl in an envelope addressed to the Box Issue Fee address above on
:1 the date Indicated below.
.. .. '
I~~!I'.i 1 f...i! ...!I{ i~ I"'.. I:Fr•11"'.1• :, I„IiY1l::: . ;, I :::. :':%! ;i a
Q
o,
to
I ' ... . l: I :': i..1L ..J;: a : l`•i!: i al~N 2 1 `r4 Linda Ga r r amo n e (Depositor's name)
!`%1'':trt :ji::;'i• . 1•~1y 1. !-! J.

(Signature)
Jtane 20 ; 2000 (Date)
APPLICATION NO . FILING DATE TOT
_WMS EXAMINER AND GROUP ART UNIT DATE MAILED
First Named r c:' r:

Applicant i::• :' l.. ', .., "
TITLE OF !. .. . ;::r( ! 1 ::{ F::tl I ..{. . !:. 1 {rl ! .1 .!....; . .. .. .

!
INVENTION
! !..:! .1_ : '- !., I- tj I ::I''fl .::t .l . !.,:!._EftÌI !'. .J I €:: :Iti AVER.
.f:''t I''•.I€: ::: .f%: :I.,J
ATTY'S DOCKET NO. CLASS-SUBCLASS BATCH NO . APPLN. TYPE SMALL ENTITY FEE DUE DATE DUE
":? .
Y
1
0
i . :: , I,! .. .. I..! .{. (? !{ _ I.1 !`•{ .1. . 2 i.• ( ..{ . .{. { .._ .{. 'i' ::. r. " :?
1 . Change of correspondence address or Indication of " Fee Address" (37 CFR 1 .363) . 2 . For printing on the patent front page, list
Use of PTO form(s) and Customer Number are recommended, but not required . (1) the names of up to 3 registered patent 1 Greenberg Traurig, LLP
attorneys or agents OR, alternatively, (2)
q Change of correspondence address (or Change of Correspondence Address form the name of a single firm (having as a
PTO/SB/122) attached . member a registered attorney or agent) 2 Anthony R . Bar]wtx=
and the names of up to 2 registered patent
q "Fee Address" Indication (or "Fee Address" Indication form PTO/SB/47) attached . attorneys or agents . If no name is listed, no
name will be printed . 3
3. ASSIGNEE NAME AND RESIDENCE DATA TO BE PRINTED ON THE PATENT (print or type) 4a . The following fees are enclosed (make check payable to Commissioner
PLEASE NOTE : Unless an assignee is identified below, no assignee data will appear on the patent. of Patents and Trademarks):
Inclusion of assignee data is only approplate when an assignment has been previously submitted to ®Issue Fee
the PTO or is being submitted under separate cover . Completion of this form is NOT a subsititue for
filing an assignment . q Advance Order - # of Copies
(A) NAME OF ASSIGNEE NeoMed.ia Technologies, .Inc .
4b . The following fees or deficiency in these fees should be charged to:
(B) RESIDENCE : (CITY & STATE OR COUNTRY) DEPOSIT ACCOUNT NUMBER
(ENCLOSE AN EXTRA COPY OF THIS FORM)
Please check the appropriate assigneecategory Indicated below (will not be printed on the patent) q Issue Fee
q Individual M corporation or other private group entity q government q Advance Order - # of Copies
The COMMIS_qIONEWF PATENTS AND TRADEMARKS IS requested to apply the Issue Fee to the application Identified above . c
NOTE ; IYe sue FeeWill not be accepted from anyone other than the applicant ; a registered attorney
or agent; or he assignee or other party In interest as shown by the records of the Patent and
Trademark Office.
Burden Hour Statement: This form is estimated to take 0 .2 hours to complete : Time will very
depending on the needs of the individual case . Any comments on the amount of time required
to complete this form should be sent to the Chief Information Officer, Patent and Trademark
Office, Washington, D .C . 20231 . DO NOT SEND FEES OR COMPLETED FORMS TO THIS
ADDRESS . SEND FEES AND THIS FORM TO : Box Issue Fee, Assistant Commissioner for
Patents, Washington D .C. 20231
Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection
of information unless it displays a valid OMB control number .
rri r i
TRANSMIT THIS FORM WITH FEE G d
PTOL-85B (REV . 10-96) Approved for use through 06/30/99 . OMB 0651-0033 Patent and Trademark Office; U .S. DEPARTMENT OF COMMERCE
I•
4
I
I

UNITED STATES .D! ;ARTMENT OF COMMERCE

Address : COMMISSIONER OF PATENTS AND TRADEMARKS
6 1ArE8 Washington, D .C. 20231
APPLICATION NO . FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO.
1017 EXAMINER
~: .. .
i=ì I'.L.L'I II1I~.I''~' 1={ X :{F1U'tiI :1_11'''1[ : :•:ai;(
C iP"tI:- ., 1\Ih;I ::IR ..L. fiALA-Z I fl°i
MET I ._.1 f: 'E;: U .1 L ...1'! 7: 1'`•Il :i ART UNIT PAPER NUMBER
I\1E., 14 Y ('-'I F K N y :1 . Cl :I,

Cl IpQf~
DATE MAILED :
proceeding .
PTO-90C (Rev. 2/95) - 1- File Copy
U .S. G .P .0 .2000 ;485-18B/25288
~I

091232,908 Hudez et al.
11F~ce of A/lowabilifv Group Art U
Pan 2183
All claims being allowable, PROSECUTION ON THE MERITS IS (OR REMAINS) CLOSED in this application . If not included
herewith (or previously mailed), a Notice of Allowance and Issue Fee Due or other appropriate communication will be mailed
in due course.
K This communication is responsive to the amendment filed on 0513100 and the Notice of Allow on 05131100
K The allowed claim(s) is/are
q The drawings filed on are acceptable.
q Acknowledgement is made of a claim for foreign priority under 35 U .S .C. § 119(a)-(d).

q All q Some" [gone of the CERTIFIED copies of the priority documents have been
q received.
`Certified copies not received:
A SHORTENED STATUTORY PERIOD FOR RESPONSE to comply with the requirements noted below is set to EXPIRE
THREE MONTHEROM THE "DATE MAILED" of this Office action . Failure to timely comply will result in
ABANDONMENT of this application . Extensions of time maybe obtained under the provisions of 37 CFR 1 .136(a).
q Note the attached EXAMINER'S AMENDMENT or NOTICE OF INFORMAL APPLICATION, PTO-152, which discloses that
the oath or declaration is deficient . A SUBSTITUTE OATH OR DECLARATION IS REQUIRED.
Applicant MUST submit NEW FORMAL DRAWINGS

q because the originally filed drawings were declared by applicant to be informal.
including changes required by the Notice of Draftsperson's Patent Drawing Review, PTO-948, attached hereto or to
Paper No . 4.
including changes required by the proposed drawing correction filed on May 3. 2000 which has been
approved by the examiner.
q including changes required by the attached Examiner's Amendment/Comment.
Identifying indicia such as the application number (see 37 CFR 1 .84(c)) should be written on the reverse side: of
the drawings . The drawings should be filed as a separate paper with a transmittal lettter addressed to the Official
Draftsperson.
q Note the attached Examiner's comment regarding REQUIREMENT FOR THE DEPOSIT OF BIOLOGICAL MATERIAL.
Any response to this letter should include, in the upper right hand corner, the APPLICATION NUMBER (SERIES
CODE/SERIAL NUMBER) . If applicant has received a Notice of Allowance and Issue Fee Due, the ISSUE BATCH NUMBER
and DATE of the NOTICE OF ALLOWANCE should also be included.
Attachment(s)
q Notice of References Cited, PTO-892 ^
q Information Disclosure Statement(s) ; PTO-1449, Paper No(s).
q Notice of Draftsperson's Patent Drawing Review, PTO-948
q Examiner's Amendment/Comment
q Examiner's Comment Regarding Requirement for Deposit of Biological Material
~C] Examiner's Statement of Reasons for Allowance
U . S. Patent and Trademark Office

PTO-37 (Rev . 9-95) Notice of Allowability Part of Paper No . ~ 10

'F,
Serial Number : 09/232,908

Art Unit : 2183
Reasons for allowance
None of the prior art of record teaches the combined features of

a)reading a data carrier modulated with an index;
b)accessing a database with the index, the database comprising a plurality of records that link an
index to a pointer which identifies a remote computer on ithe network;
c)extracting a pointer from the database as a function of the index ; and
d)using the pointer to establish communication with the remote computer identified thereby (e .g.
see claim 33).
None of the prior art of record teaches the combined features of
a) a user computing device;
b) an input device associated with the user computing device, configured to read a data carrier
modulated with an index;
c)means for storing a database comprising a plurality of records that link an index to a pointer
which identifies a remote computer ; wherein the user computing device comprising :1)means for
accessing the database to extract a pointer from the database as a function of the index ; and
2)means for using the pointer to establish communication with the identified remote computer
(see claim 68).
None of the prior art of record teaches the combined features of :
a)an input device configured to read a data carrier modulated with an index ; and
b)computer processing means for executing a software program adapted to utilize the index to
access a database comprising a plurality of records that link an index to a pointer which identifies
the remote computer, and to retrieve from the database a pointer as a function of the index, and to
use the pointer to establish communication with the remote computer (see claim 103).
Beller et al . (6,602,377) was cited for teaching the features of machine readable indicia
(the bar code) associated with a product of commerce, the indicia encoding including at least one
identification number corresponding to record in the database . Beller was already cited to
applicant on 11/29/99, therefore copy of this reference is not included in this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to
D . Pan whose telephone number is (703) 305 9696 . The examiner can normally be reached on M-F from 8 :00 AM to
4 :30 PM .
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chan, can be
reached on (703) . The fax phone number for the organization where this application or proceeding is assigned is (703)
308 6306 . Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to
the receptionist whose telephone number is (703) 305 3900 .

DAN
PRIMA
u WINER
TRANSMITTAL OF INFORMA0 URE STATEMENT Docket No.

(Under 37 QW 1997L9
- M
or 197(
9 150-061A
iW
In Re Application Of : Hudetz et aL
Serial No . Filing Date Examiner Group Art Unit

09n32,908 January 15, 1999 Pan, D . 2783
Match & Retur"

Addrq6119 F(EGENkU
Assistant Commissioner for Patents %
MAY 3 12000
37 CFR 117(b) OROUP 2700

1 . Ll The Information Disclosure Statement submitted herewith is being filed within three months of the
filing of a national application ; within three months of the date of entry of the national stage as set forth
in 37 CFR 1 A91 in an international application ; or before the mailing date of a first Office Action on
the merits, whichever event occurs last .
37 CFR I 11c)
2. Z The Information Disclosure Statement submitted herewith is being filed after three months of the filing
of a national application, or the date of entry of the national stage as set forth in 37 CFR 1 .491 in an
international application ; or after the mailing date of a first Office Action on the merits, whichever
occurred last but before the mailing date of either:
1. a Final Action under 37 . CFR 1 .113, or
2. a Notice of Allowance under 37 CFR 1 .311,
whichever occurs first.
Also submitted herewith is:
0 a certification as specified in 37 CFR 1 .97(e);
OR
29 the fee set forth in 37 CFR 1 .17(p) for submission of an Information Disclosure Statement
/2000 BliABTEW 00 1 .97(c)`
:122 240 .00 OR
Copyright 1996 Legalsoft P1 0A/REV01

TRANSMITTAL OF INFORMAT40N DISCLOSURE STATEMENT Docket. No.

(Under 37 CFR 1.97(b) or 1 .97 c 150-061A
In Re Application Of : Hudetz et al. u~

,War z5 ti
Serial No . Filing Date . Examiner Group Art Unit
09/232,908 January 15, 1999 Pan, D. 2783
Payment of Fee
(Only complete if Applicant elects to pay the fee set forth in 37 CFR 1 .17(p)) MAY 3 t ?Q00
® A check in the amount of $240 .00 is attached . U . , ._ .- E 217,00

q The Assistant Commissioner is hereby authorized to charge and credit Deposit Account No.
as described below. A duplicate copy of this sheet is enclosed.
q Charge the amount of
q Credit any overpayment.
q Charge any additional fee required.
Certificate of Transmission by Facsimile* Certificate of Mailing by First Class Mail

I certify that this document and fee is being deposited on
I certify that this document and authorization to charge deposit
05/22/2000 With the U .S . Postal Service as first
account is being facsimile transmitted to the United States
class mail under 37 C .F .R. 1 .8 and is addressed to the
Patent and Trademark Office (Fax. No . ) on
20231.
(Date)
Signature Signature a on Mailing Correspondence
Linda Garramone
Typed or Printed Name ofPerson Signing Certificate Typed or Printed Name ofPerson Mailing Correspondence
*This certificate may only be used if paying by

deposit accou t.
Dated : May 22, 2000

Signature
Anthony Barkume, Esq.

Greenberg Traurig, LLP
Met Life Building
200 Park Avenue
New York, NY 10 166
212-801-9294
I.
cc:
Copyright 1996 Legalsoft

a
ATTY DOCKET NO . SERIAL NO.
150-061A 09/232,908
INFORMATION DISCLOSURE CITATION APPLICANT(S)
(Use several sheets if necessary) Hudetz et al.
FILING DATE GROUP
01/15/99 J'7$
U.S . PATENT DOCUMENTS
*EXAMINER DOCUMENT NUMBER DATE NAME . CLASS SUBCLASS FILING DATE

INITIAL IF APPROPRIATE
5,841,978 11/24/98 Rhoads
"MAY ?~
k`` MAY 3 1 2000
GROU 2?0
TRANSLATION
DOCUMENT NUMBER DATE COUNTRY CLASS SUBCLASS
YES NO
OTHER DOCUMENTS (Including . Author, Title, Date, Pertinent Pages, Etc .)
EXAMINER DATE CONSIDERE
ÈXAMINER : Initial if reference considere ether or not citation is in conformance with MPEP 609 ; Draw Ii rough citation if not in conformance and not
considered . Include copy of this form wi ext communication to applicant .
Form PTO-A820 P09C/REV03 Patent and Trademark Office • U .S. DEPARTMENT OF COMMERCE
(also form PTO-1449)
PAGE 1 OF 1
Q

's -
tw OF CO
. UNITED "STATES DEPARTMENT OF COMMERCE
Address: COMMISSIONER OF PATENTS AND TRADEMARKS
~~~res eF Washington, D.C . 20231
APPLICATION NO . FILING DATE FIRST NAMED INVENTOR

I_'_i _.
W y; TT .. DOCKET NO.
,., ..
f lYl :"c: :l. / 1.! 9 . :{. 1)

EXAMINER
Al 1011Y FR B(.)R[*" UIYIE ESfA
GREE::NBER1:7 "rRf-11_ R I G.'i
ME: 1- LIFE IL{I_! I I_DT I K'i )RI T UNIT PAPER NUMBER
201:1 FAF K AVENUE
NE M Y01-ti NY 1r_1166
C! :LI1/f11~
DATE MAILED:
proceeding .
PTO-90C (Rev. 2/95)
U .S. G .P.O. 2000 ; 465-188/25268

's,

091232,908 Hudetz et al.
Interview Summary Examiner Group Art Unit
Pan 2183
All participants (applicant, applicant's representative, PTO personnel):
(1) Pan (3)
(2) Barkume (4)
Date of Interview Jan 16. 2001
Type : nelephonic personal (copy is given to a4licant a Vicant's representative).
Exhibit shown or demonstration conducted : [D3s Imo . If yes, brief description:
Agreement nuas reached . [Das not reached.
Claim(s) discussed : all claims on the record.
Identification of prior art discussed:

5,841,978
Description of the general nature of what was agreed to if an agreement was reached, or any other comments:
The IDS filed on MAy 25,2000 has been entered and considered. The Office actions on 05131100 and 10/17100 remain in
effect. The reasons for allowance set forth in Paper # 10 are also applicable to newly cited reference 5, 641, 978. See attached
1449.
(A fuller description, if necessary, and a copy of the amendments, if available, which the examiner agreed would render
the claims allowable must be attached . Also, where no copy of the amendents which would render the claims allowable
is available, a summary thereof must be attached .)
1. 0 It is not necessary for applicant to provide a separate record of the substance of the interview.
Unless the paragraph above has been checked to indicate to the contrary, A FORMAL WRITTEN RESPONSE TO THE . LAST
OFFICE ACTION IS NOT WAIVED AND MUST INCLUDE THE SUBSTANCE OF THE INTERVIEW . (See MPEP Section
713 .04). If a response to the last Office action has already been filed, APPLICANT IS GIVEN ONE MONTH FROM THIS
INTERVIEW DATE TO FILE A STATEMENT OF THE SUBSTANCE OF THE INTERVIEW.
2. q Since the Examiner's interview summary above (including any attachments) reflects a complete response to
each of the objections, rejections and requirements that may be present in the last Office action, and sincerthe
claims are now allowable, this completed form is considered to fulfill the response requirements of the last
Office action . Applicant is not relieved from providing a separate record of the interview unl 1 above
is also checked .
ER
Y
PRI
Examiner Note: You must sign and stamp this form unless it is an attachment to a signed Office action .
U . S . Patent and Trademark Offlce -
PTO-413 (Rev. 10-95) Interview Summary Paper No . 13

.f
.e lm Y
Docket N
TRANSMITTAL OF FORMAL DRAWINGS 30/y
(In Response to Notice of Informal Drawings) 1 ~y 150-061A
Hudetz et al.
In Re Application Of :
~
eKp
R
Serial No . Filing Date Batch No . Examiner Art Unit
09/232,908 01/15/99 N18 Pan, D. 2783
Invention : SYSTEM AND METHO'D'FOlt AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A

NETWORK
Address to:
Washington, D.C. 20231
In response to the NOTICE OF INFORMAL DRAWINGS mailed on 11/29/99 attached please find:
(date)
(a) Five (5) sheets of formal drawing(s) for this application.
Each sheet of drawing indicates the identifying indicia suggested in 37 CFR Section 1,84(c)
on the reverse side of the drawing.
(b) A copy of the NOTICE OF INFORMAL DRAWINGS.
moi/ Dated : June 15, 2000

Signature
AnZony IL Barkume, Esq.,
Greenberg Traurig, LLP
Met Life Building
200 Park Avenue I certify that this document and attached drawings are being
New York, NY 10166 deposited on 0 6 / 15 /"2 0 0 0 with the U .S . .Postal
Service as first class mail under 37 C .F .R . 1 .8 and addressed
(212) 801-9294 to the Assistant Commissioner for Patents, Washington, D .C.
20231 .
i
Signature of Pe son ailing Correspondence
Linda Garramone
Typed or Printed Name ofPerson Mailing Correspondence
P23A/REV01

BASE "" NLMOTE

PROVIDER NODE 26
50
~--
I LOCAL L 32
( HOST
36 MODEM RAM
48
I 34 40' ARTICLE
DATA/ADDRESS BUS
46 ►
42 I I
38 I i
I CPU 30 1/0 PORT INPUT
DEVICE
44
52 FIG. 2
36.
50
28
54 Illlllllllillllllll
® 44 48
soup
46 Ihp

D®tea, 90~
FIG. 5
LOAD BROWSER
80 SOFTWARE
48
82 LOAD QUERRY
PAGE
6
84 ENTER UPC PRODUCT

0 01 73568 " 41254 1111 . 2 ID NUMBER
LOOK UP
86
B UPC CODE
A
RETURN- MATCHING
a8 RECORDS
90 DISPLAY RESULTS
92 LOAD DESIRED
FIG. 4 ADDRESS
70> 72, ~ 60. ~74 ~76
UPC-A UPC-B URL DESC

62-\
31251 00301 sample .soup.com/subfile/Inddx .htmi sou
64 - 31251 00302 sample,s .oup .com/promotion/maln .htmi giveaway
66 — 31251 00400 test.mllk .org milk
68- 4205 cars.com/testdrive%main .htmi cars
L-78

96.
98
100
FIG. 7
112
~ illl p --
108
%///// 110

_j
REMOTE SERVICE .
SERVER PROVIDER 224
ZZ 8 2210 Z/o
222
236
234
2/Io MODEM
2~¢ DOCUMENT
212 COMPUTER ~ ~
232
BAR
CODE
READER
Z/B
~220
Sample c wtivy~, co
h M.
34
FIG-. 9
238
,,--= 230
242
24¢
FIG -10

Form PTO 9 v. U .S . DEPARTMENT OF COMMERCE -Patent and Trademark Office Application No .~ ..
NOVICE OF 4DRAFTSPERSON'S, %
MGN 1 $ PAT'EI4T DRAWING RI~Vf Wh
The drawing ' sert date) re:

A . O approved by the Draftsperson under 37 CFR 1 .84 or 1 .152.
B; .J~!objected to by the Draftsperson under 37 CFR 1 .84 or 1 .152 for the reasons indicated below. The Examiner will require
sutll ission of new, corrected drawings when necessary . Cofrected drawing must be sumilted according to the ipstructions qn the back of this notice.
1. DRAWINGS . 37 CFR 1 .84(a) : Acceptable dateioriPs of drawings: ` 8. ' ARI2ANGEMENT' OF VIEWS . 37 CFR 1 .84(1)`
Black ink . Color. Word's do nbttappear on.a horizontal ; left; to, right ,fashion
Color drawings are not acceptable until petiton is , granted. when page is either, upright. or turned so that the top
Fig(s) become§ the right side, except for graphs . Fig(s)
Pencil and non black ink not permitted. Fig(s) 9. SCALE. 37 CFR 1 .84(k)
2. PHOTOGRAPHS . 37 CFR 1 .84 (b) _ Scale not large enough to show mechanism without
_ 1 full-tone set is required . Fig(s) crowding when drawing is reduced in size to two-thirds in
— Photographs not properly mounted (must use brystol board or reproduction.
photographic double-weight paper). Fig(s) Fig(s) ' .
_ Poor quality (half-tone) . Fig(s) 10. CHARACTER OF LINES, NUMBERS, & LETTERS.
3. TYPE OF PAPER . 37 CFR 1 .84(e) 37 SFR 1 .84(1)
_ Paper not flexible, strong, white ; and durable. ~" Lines ;,. numbers &letters notuniformiy thick and well
Fig(s) defined, cl an, dut Je, and black (poor line quality).
Erasures, alterations, overwrilings, interlineations, Fig(s)
folds, copy machine marks not accepted . Fig($) 11. SHADING . 37 FR 1 .8 (m) t
_ Mylar, velum paper is not acceptable (too thin). Solid black areas pale . Fig(s)
Fig(s) Solid black shading not permitted . Figs)
4. SIZE OF PAPER. 37 CFR 1 .84(0: Acceptable sizes: _ Shade lines ; pale, rbugh d and'blurr6d. Fig(s)
21 .0 cm by 29 .7 cm (DIN size A4) 12. NUMBERS, LETTERS, & REFERENCE CHARACTERS.
21 .6 cm by 27 .9 cm (8 1/2 x I I inches) 37 CFR 1 .84(p)
— All drawing sheets not the same size. _ Numbers and reference characters not plain'and legible:
— Sheet(s) Fig(s)
Drawings sheets not an acceptable size . Fig(s) Figure legends are poor . Fig(s)
5. MARGINS . 37 CFR 1.84(8) : Acceptable margins: — Numbers and reference characters not oriented in the
same,direction .as .the , view..• 37 CFR . 1.84(p)(1)
Top 2 .5 em Left 2 .5cm Right 1 .5 cm Bottom 1 .0 em Fig(s)
SIZE : A4 Size English alphabet not used . 37 CFR 1 .84(p)(2)
Top 2 .5 cm Left 2 .5 cm~ Right 1 .5 cm Bottom 1,0 cm — Figs
SIZE: 8 1/2 x 11,
Margins not acceptabl Fig )
Top (T)
1
ft L) "]
( f — Numbers, letters and reference characters must be at least
.32 cm (1/8 inch) in height. 37 CFR 1 .94(p)(3)
Fig(s)
Right (R) 7^ Bottom (B)
—
13. LEAD LINES . 37 CFR 1 .84(q)
6. VIEWS. 37 CFR 1 .84(h) _ Lead lines cross each other. Fig(s)
REMINDER : Specification may require revision to — Lead lines missing. Fig(s)
correspond to drawing changes. 14. NUMBERING OF SHEETS OF DRAWINGS . 37 CFR 1 .84(t)
Partial views . 37 CFR 1 .84(h)(2) Sheets not numbered consecutively, and in Arabic numerals
_Brackets needed to show figure as one entity. beginning with number 1 . Sheet(s)
Fig(s) 15. NUMBERING OF VIEWS . 37 CFR 1 .84(u)
_ Views not labeled separately or properly. _ Views not numbered consecutively, and in Arabic numerals,
Fig(s) beginning with number 1 . Fig(s)
Enlarged view not labeled separetely or properly. 16. CORRECTIONS. 37 CFR 1 .84(w)
Fig(s) — Corrections not made from prior PTO-948
7. SECTIONAL VIEWS . 37 CFR 1 .84 (h)(3) dated
Hatching not indicated for sectional portions of an object. 17. DESIGN DRAWINGS . 37 CFR 1 .152
Fig(s) _ Surface shading shown aot-appropriate . Fig(s)
Sectional designation should be noted with Arabic or Solid black shading not used for color contrast.
— Roman numbers . Fig(s) Fig(s)
COMMENTS
REVIEWER DATE Q TELEPHONE NO .
ATTACHMENT TO PAPER NO

't .
UNITED STATES`,WPARTMENT OF COMMERCE

Patent and Tradb?nark Office
ASSISTANT SECRETARY -AND COMMISSIONER
OF PATIENTS AND TRADEMARKS
CHANGE OF ADDRESS/POWER OF ATTORNEY
FILE LOCATION 9200 SERIAL NUMBER 09164215 PATENT NUMBER 6199049
THE CORRESPONDENCE ADDRESS-HAS BEEN CHANGED TO CUSTOMER # 25299
THE PRACTITIONERS OF RECORD HAVE BEEN CHANGED TO CUSTOMER # 25299
THE FEE ADDRESS HAS BEEN CHANGED TO CUSTOMER # 25299
ON 04/10/01 THE ADDRESS OF RECORD FOR CUSTOMER NUMBER 25299 IS:
IBM CORPORATION
PO BOX 12195
DEPT 9CCA,,BLDG 002
RESEARCH TRIANGLE PARK NC 27709
AND THE PRACTITIONERS OF RECORD FOR CUSTOMER NUMBER 25299 ARE:
25629 30329 31782 35137 43901
PTO INSTRUCTIONS : PLEASE TAKE THE FOLLOWING ACTION WHEN THE

CORRESPONDENCE ADDRESS HAS BEEN CHANGED TO CUSTOMER NUMBER:
RECORD, ON THE NEXT AVAILABLE CONTENTS LINE OF THE FILE JACKET-,
'ADDRESS CHANGE TO CUSTOMER NUMBER' . LINE THROUGH THE OLD
ADDRESS ON THE FILE JACKET LABEL AND ENTER ONLY THE 'CUSTOMER
NUMBER' AS THE NEW ADDRESS . FILE THIS LETTER IN THE FILE JACKET.
WHEN ABOVE CHANGES ARE ONLY TO FEE ADDRESS AND/OR PRACTITIONERS
OF RECORD, FILE LETTER IN THE FILE JACKET.
THIS FILE IS ASSIGNED TO GAU 2764.
PTO-FMD
TALBOT-1/97

00870-Prosecution History

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

00870-Prosecution History

Enviado por

Direitos autorais:

Formatos disponíveis

N~ PATENT NUMBER,

SECTOR CLASS SUBCLASS ART UNIT EXAMINER

FILED WITH : U DISK (CRF) "FICHE

I PREPARED AND APPROVED FOR ISSUE, !

ORIGINAL CROSS R IRENCE(S)

CLASS SUBCLASS CLASS SUBCLAS , ONE SUBCLASS PER BLOCK)

INTERNATIONAL CLASSIFICATION 3J ~~Z, of %rJZ, U

q Continued on Issue Slip Inside File Jacket

TERMINAL DRAWINGS CLAIMS ALLOWED

q a) The term of this patent NOTICE OF ALLOWANCE MAILED

q b) The term of this patent shall DANIEL H . PM

Examiner) (bate) O(Primay

NQ 11w VFV I FIS, e,

v+ro .zl If"'r..n,exol~erew ~

ISSUE SLIP STAPLE AREA (for addidenal cross reference j

POSITION INITIALS ilk' ~dl ~ . DATE

Claim Date Claim Date Claim Date

If more than 150 claims or 10 actions

PATENT APPLICATION SERIAL NO.

U.S. DEPARTMENT OF COMMERCE

01/26/1999 HVILLARI 00000045 09232909

FRANK C . HUDETZ, LISLE,,IL ; PETER. R . HUDETZ, PLAINFIELD, IL,

**CONTINUING DOMESTIC DATA*********************/

**371 (NAT'L STAGE) DAT~ifi*********************

YSTEM & METHOD FOR y~" - .C1 S A

FILING FEE, E] All Fees

No . to charge/credit DEPOSIT ACCOUNT 1 .17 Fees ;Processing ext . of time)

=_ [ UTILITY Attorney Docket No. 150-061A

- Reference to Microfiche Appendix C. Statement verifying identity of above copies

0 Customer Number or Bar Code Labe I ; or 0 Correspondence address below

city Sa lle State NY Zip Code 11782

Name (PrinHType) An o . Barkume Registration No.(Aitorney/Agent) 33,831

METHOD OF PAYMENT (check one) FEE CALCULATION (continued)

SUBMITTED BY Complete (if applicable)

Related Application Data

Field of the Invention

as TCP/IP . Many sites on the Internet can be accessed in

where a resource is stored . A typical URL is

Brief Description of the Drawings .

FIG . 1 is a block diagram of a computerized system for

Tu client system of FIG . 1 displaying information in accordance

Detailed Description of the Preferred Embodiment

22 is a local Internet access . provider . Service provider

be the case where " local host 28 is a larger computer, such

URL . The Query Page, when displayed on CRT 52 by local host

example — and entering all or part of the product's UPC

102-106 (by mouse click or otherwise), the browser software

Direct Coding of Address . In place of a standard UPC

1 . A system for usi g an article of commerce to access a

2. The system of clai 1 where said machine-readable

3. The system of claim 2 where said. identification

4.The system of claim wherein said indicia is both

includes a keyboard f manually entering said

5 .. The system claim l wherein said local host is a

6. The system o+ E claim 1 wherein said local host is a

7. The system o: .claim 1 wherein said local host

8. The system o: cTa 1 further comprising a second

9. The. system o: claim 8 wherein said database is

10. The system o claim 1 wherein said database is

11. The system of claim 1 wherein said database is

12. An apparatus for using an arti a of commerce to

(c) control, means responsive to said o ut t signal and

13. The apparatus of claim 12 said

CONTINUING DOMESTIC DATA*******************/

371 (NAT'L STAGE) DAT~ifi*******************