N~ N

PATENT NUMBER,
U_
LL

~ Q ~ 0~ V1

N stn
%p i U

~~

~

8199046
6199048

cn

-' '0

ro

u
C0

SECTOR

CLASS

7

SUBCLASS

ART UNIT

EXAMINER

FILED WITH : U DISK (CRF) "FICHE i
~ .~ (Attached in pocket on right inside flap)

I

PREPARED AND APPROVED FOR ISSUE, ! ISSUING CLASSIFICATION
ORIGINAL CLASS SUBCLASS CLASS
1

CROSS R IRENCE(S) SUBCLAS , ONE SUBCLASS PER BLOCK)

INTERNATIONAL CLASSIFICATION

3J

~~Z, of %rJZ, U

6116 (e

0-

q Continued on Issue Slip Inside File Jacket

TERMINAL

DRAWINGS
Sheets Drwgr Figs.DrW§' .

CLAIMS ALLOWED

DISCLAIMER

min i[`g.

Total Claims

ti>°-

Print ClaiKfor O .G.

q a) The term of this patent subsequent to has been disclaimed.

NOTICE OF ALLOWANCE MAILED (date) - ___-
(Date) ^ (Assistant Examiner)

q b) The term of this patent shall not extend beyond the expiration date, of U .S Patent. No.

DANIEL H . PM

PRIMARY uePefS INER s fjR () p

ISSUE FEE
Amount Dille Date Paid
O(Primay

Examiner)

(bate)

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 ..,PATENT INITIALS 01/15/ 99

APPOCAtIONN
~eceived C. Date Mailed

CONTEWS
09232908
Date received (Incl. C. of M.) or Date Mailed

1.Application

papers

2. 3.
2 rn d5. (1 G ~~

41 43. 44. 45.
16.

5. 6. 7. 8. Oy.

cOd 2ev
5"6b

Cw*4

'.42) 47.

12. M3 ~~~~~?ds°l~1~iII 15. 16.— 17.— 18.— 19. 20. 21. 22. it 23. 6 24. 25. 26. 27. 28. 29. 30. 31 32. 'i 33. I W 35. — 36. 37 . 30 30. 40. 41 .

48./ — 4 0. cyo 51. 52. 050460 53. 54. 55. 56. 57. 58. 59. 60. 6162. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82.
F

(LEFT OUTSIDE)

ISSUE SLIP STAPLE AREA (for addidenal cross reference j

POSITION
FEE DETERMINATION O .I .P .E . CLASSIFIER FORMALITY REVIEW

INITIALS

ilk' ~dl ~ .

DATE

INDEX OF CLAIMS
Rejected Allowed (Through numeral) . . . Canceled Restricted - _
Claim
~

N I A 0
Date
Claim

Non-elected Interference Appeal Objected
Date

Date

Claim rn
O ~.

iL r,

~I •

c

I IM 'J

ilml
v V
G

it
Ip

i
.1

1 V 2

31 I AJ 4 - 1I 1 11 W
1

.

51 ~~ 52 1 53 22 54 .\ 3 55 —\ 2,4156 Z~ 57 Z 58 `7 59 'Z,T 601 11 Z 61 ~\ .1 62 \ 30 s 63 .31 64 3 65 3f~ 66
C)

ii O 101 .' 1 qI
2 X04

Ofi 105 '1,4 1061
f:
107 106 y ` ~ ; -

t

109 i)^ 10 s i~ 111 yo 112
113

_ ~ _ _

114
1151 1

116
Yfll17 ~6 116 ~..~

1
1 1, 1 1 1 9 1

0
1

37 69 3 70
71
111 1

~. \\

a' 119 20,
121

2 3 2
201
1

1 111

1 2VI
1

A2P

J_

H_~
Alh
1 .11

41 72 Yz 73 (Pte 74 4(j 75 40176 4S 77 J 78, 4,77911
65 BO 41 81 • 8211 1 —, I -'

% 112211
91 1 41 Z 124

_~ 125
9 ~ 127 128

29 . 30
. 1311 3 3
131 131 131 131 1381 1391 1

f
Z

3 3 35 36

I, —

3
G

3411 --

I
1

3711

r 38 39 40
41 JO 42
T2_

\.

f 83 S Z 84 S3 85 86 87 -6 88 89 s 90 S" 91 61) 92

1

1
1 1 1 1

~. ~.

40
141

_

1143 44 > 45 x - 46 47 48 49 1 ~' 50

14 14
14AII

45 46 4
66

4

.\
16wool

14 _11 501

If more than 150 claims or 10 actions staple additional sheet here (LEFT INSIDE)

SEARCHED
Class ~ t~ ~

0

ZL~O,

Sub.

r Date

Exmr.

1-7

4

INTERFERENCE SEARCHED Exmr. S6b. Date (loss
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 09/232,908

FILING DATE 01/15/99

CLASS 395

GROUP ART UNIT 2756

ATTORNEY DOCKET NO. 150–061A

FRANK C . HUDETZ, LISLE,,IL ; PETER. R . HUDETZ, PLAINFIELD, IL,
rL

-a. Q

**CONTINUING DOMESTIC DATA*********************/ 08538,365 10/03/95 VERIFIED THIS APPLN IS A DIV OF PROVISIONAL APPLIQAfiION NO . 60/000,442 06/20/95

**371 (NAT'L STAGE) DAT~ifi********************* VERIFIED
oeI

! I

**FOREIGN APPLICATIONS*******~+*** VERIF I E D ~ I, l
f

f

FOREIGN FILING LICENSE GRANTED 02/08/ .99 Foreign Priority claimed q yes no 10 35 USC 119 (a-d) conditions met [dyes [g4So q MeWfter Allowance Vey ified and Acknowledged
.11

gi"'

y

***** SMALL ENTITY ***** STATE OR SHEETS TOTAL COUNTRY CLAIMS DRAWING IL 3 11 E,

~ I.I(gDEPENDENT i CLAIMS 1

I Lj ` I

E

ANTHONY R B KUME 14 SOUTH IN STREET SUITE 2 0 SAYVI E NY 11782

f~ ~(
G

V 14

t

Zee.4

I' CA*Qi+ ~U t t~ i
{P..

f4~ I

q~ a'tiV ua
= F -

~r' c ~f' ♦

J
tl

YSTEM & METHOD FOR R,i;MOTE COMPUTER

y~" err
_

a, ~ Li)
r

-

Yom/ .C1
r3'"

S A

FILING FEE, RECEIVED $380

FEES : Authority has been given in Paper No . to charge/credit DEPOSIT ACCOUNT NO . for the following :

E] All Fees

q 1 .18 Fees (Fi .r. ;~) 1 .17 Fees ;Processing q 1 .18 Fees (Issue) q Other q Credit
~~.

ext .

of time)

Please type a plus sign (+) inside this box -~
O

-

1•-~ =

tO cTT

V nder the Pa erwork Reductio Act of 1995 no ersons are

PTO/SB/05 (4/98) Approved for use through 09/30/2000 . OMB 0651-0032 . DEPARTMENT OF COMMERCE Patent and Trademark Office : U .S ed to re o d to a collection of information unless it dis la s a valid OMB control number.
Attorney Docket No.

=_ [

UTILITY PATENT APPLICATION TRANSMITTAL
Only for new nonprovisional applications under37 C .F.R . §

150-061A
Frank C . Hudetz im

First Inventor or Application Identifle Title

See 1 in Addendum b)) Express Mail Label No . EG131043525US

utility patent application contents. *Fee Transmittal Form (e.g ., PTO/SB/17) 1' (Submit an original and a duplicate for fee processing) [Total Pages 2 . ~ Specification 24 (preferred arrangement set forth below) - Descriptive title of the Invention - Cross References to Related Applications - Statement Regarding Fed sponsored R & D - Reference to Microfiche Appendix - Background of the Invention - Brief Summary of the Invention - Brief Description of the Drawings (if filed) - Detailed Description - Claim(s) - Abstract of the Disclosure 3 . X Drawing(s) (35 U .S .C. 113) [Total Sheets 3 ''
See MPEP chapter 600 concerning

APPLICATION ELEMENTS

7
]

Assistant Commissioner for Patents ADDRESS TO : Box Patent Application fmn nr- gri gni 5. q Microfiche Computer Program
(Appendix)

U r,

6 . Nucleotide and/or Amino Acid Sequence Submission (if applicable, all necessary) a . ~ Computer Readable Copy b.
C.

F
0

Paper Copy (identical to computer copy) Statement verifying identity of above copies

ACCOMPANYING APPLICATION PARTS

1 ]

7 .~ Assignment Papers (cover sheet & document(s)) Power of B ~ 37 C .F .R .§3.73(b) Statement (when there is an assignee) Attorney 9 .F--] English Translation Document (if applicable) Copies of IDS Information Disclosure 10 Statement (IDS)/PTO-1449 OCitations

•1:1

4 . Oath or Declaration

[Total Pages

11 .

FK] Preliminary Amendment

12 ® Return Receipt Postcard (MPEP 503) a . F1 Newly executed (original or copy) q (Should be specifically itemized) Copy from a prior application (37 C .F .R . § 1 .63(d)) • Small Entity b X Statement filed i r prior application (for continuatiorVdlvisional with Box 16 completed) 13 . ~ Statement(s) ~ Status still proper and desired desired i q DELETION OF INVENTOR(S) (PTO/SB/09-12) 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 ORD R :TOB £NTT O : O .A .' LL: N: r- .:: P
FEES,iA : MAEL.ENTT:LV STATEI4IENTLS~REL3UJREOi(37GFiRi,§1:~7fi :EXCEPT: . .. . . . .. . .,FL:E . . .. :1 .A :p 'iF N L GI

:i

16 . If a CONTINUING APPLICATION, check appropriate box, and supply the requisite information below and in a preliminary amendment: of prior application No : 08/538,365 Continuation Divisional ElContinuation-in-part (CIP) D . Pan Prior application information : Examiner 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
Name

;

or

0

Correspondence address below

:(insert Customer No : or Attach'bar code label here

Address city

Anthony R. Barkume lAnthony R. Barkume, P .C. 14 South Main_Street Suite 200 Sa lle An o . Barkume
State Telephone NY
(516) Zip Code

11782
(516)244-7645

Country Name (PrinHType)

244-3503

Fax

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

FEE TRANSMITTAL
Patent fees are subject to annual revision on October 1. These are the fees effective October 1, 1997. Small Entity payments must be supported by a smell entity statement, otherwise large entity fees must be paid. See Forms PTO/SB/09-12.
See 37 C.F.R. §§ 1.27 and 1.28.

Application Number Flung Date First Named Inventor Examiner Name Group / Art Unit AttomeyDocketNo .

January 15, 1999
Frank C . Hudetz

D . Pan
2302 150-061A

TOTAL AMOUNT OF PAYMENT

($) 380 .00

METHOD OF PAYMENT (check one)

FEE CALCULATION (continued)

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

Fee Paid 0 .00 0 .00 0 .00 0 .0 0 .00 0 .00 0 .00 0 .00 0 .00 0 .00

0 .00 0 .00 0 .00 0 .00 0 .00

2 . EXTRA CLAIM FEES Fee from Extra Claims below Fee Paid Total Claims 11 -20 *' = 0= X --= Independent _ 3** =F_ __J X 39 = 0~ Claims Multiple Dependent

0

or number previously paid, if greater; For Reissues, see below

=0

0 .00 0 .00 0 0 .00 0 .00
0 ' 00

Large Fee Code 103 102 104 109 110

Entity Small Fee Fee ($) Code 22 203 82 202 270 204 82 209 22

Entity Fee Fee Description ($) 11 Claims in excess of 20 41 Independent claims in excess of 3 135 Multiple dependent claim, if not paid 41 ** Reissue independent claims over original patent 210 11 ** Reissue claims in excess of 20 and over original patent SUBTOTAL (2)

0 .00
0 .00 0 .00 0 .00 0 .00

Other fee (specify) Other fee (specify) * Reduced by Basic Filing Fee Paid SUBTOTAL (3) ($) 0 . 00

($) 0 .00

SUBMITTED BY Typedor Printed Name Anthori Signature

Complete (if applicable)

R. Barkume
Date

Reg . Number Deposit Account User ID

33,831

Burden Hour Statement : T is lu onVis 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 This invention relates to computer communications generally, and more specifically to techniques for. giving 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

/

;a r'
(
F_

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 parlance of the enthusiasts, "surf") from Web site to Web 15 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 -

2

J

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 5 particularly acute for persons with a visual or physical 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. 10 Accordingly, Web site sponsors publish their Web site URLs 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 20 numeric address in bar code format . The user's computer is 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

4

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 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

a

5

10

15

20

25

30

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 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 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 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 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 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 requires only that the database of addresses be updated. Products, packaging, advertisements and the like bearing the standard identification codes need not be redesigned.

6

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 15

Tu
a ? J .

i-i

17

the system of FIG . 1 in accordance with the invention. FIG . 6 is an idealized view of the CRT screen of the client system of FIG . 1 displaying information in accordance with the invention. FIG . 7 is a perspective view of articles of commerce which can be used in accordance with the invention to access remote computers .~ 7 Detailed Description of the Preferred Embodiment Overview FIG . 1 is a block diagram illustrating one application 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 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 two remote nodes 24 and 26 . In this case, service provider 1.

3

p!

25

30

35

"f

5

10

15

20

az.

25

30

35

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 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 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 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. 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 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. 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 sm- Alternatively, local host 28 network such as TymNet, could be connected directly to Internet 20, as is likely to

5

10

15

20

25

30

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. 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. 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 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 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 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 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 article of commerce 48 . The term "article of commerce"

35 :

5

10

15

20

25

30

35

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 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 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 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 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 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 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 Numbering System ("ISSN") .

5

10

15

20

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 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 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 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 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

5

10

15

20

25

30

35

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 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 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 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 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 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 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 software provides access to an HTML document (the "QueryPage") resident on service provider 22 at a predetermined

1

5

10

15

20

25

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 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. 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 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 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 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
f d

13

•r

5

10

15

20

25

30

35

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 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 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. 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 identification number encoded by symbol 46 . Because the UPC product identification number is printed in both machineand 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 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 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 identification number entered by the user . The records are conveyed to the user in the form of an HTML document . The

5

10

15

20

25

30

35

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. "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 (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 ." 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 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 , 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 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 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. In those cases, database 60 could be resident on the on-line service provider's computer . The network address , 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 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 .

~14

FL
k ri

V

5

10

15

20

25

30

35

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 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 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 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 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 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 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 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 machinereadable 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) and . (e) a first network ontai in a plurality of nodes, ress ; said network being 20 each having an assigned net ork ;•~ a local host ada ted or network communication;

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. The system of clai 1 where said machine-readable 2. 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. The system of claim wherein said indicia is both machine- and human-readable, a Ad wherein said input means , 4.

19

K

includes a keyboard f identification number 5 .. The system single-user computer.

manually entering said

claim l wherein said local host is a

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: resident on said seconi claim 8 wherein said database is 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; identification (b) a database hav n pl alit icle identification number, and a numbers including said plurality of network ddresses, and associating each of said 10 identification n rs with at least one of said network addresses ; and

20

15

(c) control, means responsive to said o ut t signal and operatively coupled to said database for re i g ving from . said database at . least.one of those of said etwork addresses which correspond .to said article dentification number . 13. The apparatus of claim 12 identification numbers are Uniform 14. The apparatus of claim .12 addresses are Uniform Resource Loca 15. The apparatus of claim local host and a remote host , a communication, wherein sa d rea local host, and .said d abase i host . i said Codes. said network

further comprising a adapted-for network means is resident on said sident on said remote

5

5

10

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 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 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; said identification number ha g recognized significance as a. number identifying an art'cl of commerce. (b) providing an art i cle o commerce bearing an indicia on which said identific ion n er is encoded; (c) reading at 1 ast p rtion of said identification 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 identification n od e c ording to claim 22 wherein said s a Uniform Product. Code.

5

n

ru

_ :-

10

3= 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;

V !=

UfII- i

21 L OG1

C."

A, system and method for usinq identification Oadees found on ordinary'artioies :-'of commerce to access remote Computer on a network . I.h aaoardanco with one embodiment 's 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 ol, or vial other suitable input

s

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.

] ;~
3

_.

(] was Sled as United States application Serial No thmIIgh if applicable).

.

on on

and was amended on or and was amended

i
aa

was filed as PCT international application Number 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(&). I hereby claim facaip priority benedts under Title 35, United States Code, 4119 of any Ersigtr 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

9F
c

T

Prior FandgplPCT Applieaticn(a) and aw Priority Claims Under 35 U .S.C. 4119: (Plumber) (Couatr'y) (DayftANTr Filed)

resa l hereby claim this bsaaSt tmdw The 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 aurial khenstioa as 1 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*: Citizenship : Frank C. Hudft 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 Citizenship Pdw L Hudetz 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 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE In re application of Application No . : Filed: For:

PATENT

Hudetz, Frank C . ; Hudetz, Peter R. 08/538,365 Group No . : 2302 10/03/95 Examiner : D . Pan SYSTEM AND METHOD FOR USING AN ORDINARY ARTICLE OF COMMERCE TO ACCESS A REMOTE COMPUTER

Assistant Commissioner for Patents 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: Anthony R .-Barkume, Esq. Anthony R . Barkume, P . C. 14 South Main Street Suite 200 Sayville, NY 11782

DIRECT TELEPHONE CALLS TO: Anthony R . Barkume (516) 244-3503

(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 01 .-

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
6o

S ao
REMOTE

FIG .1

DATA-

CE

~RovlDr~
I LOCAL
HOST
32

NODE

2,6

36

MODEM
4o

RAM

r~
I
~S ARTICLE

3~ ~

I
~

DATA/ADDRESS BUS

I

I I

IIIIII~1
, qb

CPU

3a

I/p PO

INPUT DEVICE

S7 V

FIG . 2
S.o

~a
SN

uunumnumi .;
yy~ SOUY

y~

y6

u~'

P RLV T OF DRAWING.

AS ORIGINALLY FII.

FIL S FIG. 3
8p

LOAD BROWSER SOFTWARE LOAD QUERRY PAGE

dllll ~IIIIdII~IN p
73 59

l2

~S

4Y

84

ENTER UPC PRODUCT ID NUMBER

S6

LOOK UP UPC CODE 'RETURN MATCHING RECORDS

A

Q
g~

DISPLAY RESULTS 9v LOAD DESIRED

r ~o UPC-A 31251 31251 31251 4205

FIG. 4
e- 7a

9a

ADDRESS (-76

`a
r-714

UPC-8 00301 00302 00400 s

URL e. s*up.com/subflle/Ind4x.htfnl

DESC so 9iveawoy fnIlk con

sample .soup.com/promotion/main .html test.milk,oir9 cors.com/testdrive/main .html -

T

1

79

PRLNT OF DRAW1W AS ORIGINALLY FU

1

SZ
-1

NAVIGATE > « KX~ELP EXIT CLICK ON DESIRED P 31251 ' -003
3125112 iGIVEAW

-

SITE:
~ U2

a
106

xz~

FIG . .7

Sou p

1110, I k

0

Application.or . Docket Number

PATENT APPLICATION FEE DETERMINATION RECORD Effective 'November 10, 1958 CLAIMS AS FILED PART I
FOR BASIC FEE
TOTAL CLAIMS INDEPENDENT CLAIMS

nn pC3 G
SMALL E TYPE RATE FEE 380.00 OR

Q

Column 1 NUMBER FILED

Column 2 NUMBER EXTRA

OTHER THAN OR SMALL ENTITY RATE FEE 760.00 X$18= X78-+260=

minus 20= -minus 3 =

X$ 9= X39= +130--

OR OR OR

MULTIPLE DEPENDENT CLAIM PRESENT

* If the difference in column 1 is less than zero, enter 00" in column 2

TOTAL

OR TOTAL OR OTHER THAN SMALL ENTITY ADDIRATE TIONAL FEE OR X$18= OR X78= OR
+260=

CLAIMS AS AMENDED - PART 11 1 QI
z W Z

SMALL ENTITY
RATE ADDITIONAL FEE

I
Total *

REMAINING AFT03 AMENDMENT

I
Minus Minus

I

NUMBER PREVIOUSLY PAID FOR .. .«

I

PRESENT EXTRA

z
W

O

5
=yam.---

X$ 9-X39-+130--.

Independent *

Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

TOTAL ADDIT. FEE

TOTAL OR ADDrT. FEE

M W Z p z W 2 Total *

REMAINING AFTER AMENDMENT Minus Minus

NUMBER PREVIOUSLY PAID FOR .. .«

PRESENT EXTRA

RATE X$ 9=

ADDITIONAL FEE

ADDIRATE . TIONAL FEE OR X$18= OR X78=
OR +260= OR ADDIT . FEE
TOTAL

Independent *

-

X39-+130=
TOTAL ADDiT. FEE

Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

V z W = p Total Z W Independent . *

REMAINING AFTER AMENDMENT Minus Minus

NUMBER PREVIOUSLY PAID FOR

PRESENT EXTRA

RATE X$ 9=

ADDITIONAL FEE

ADDIRATE TIONAL FEE OR X$18= OR X78= OR
+260=

FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

X39= +130=

• If the entry in column 1 is less than the entry in column 2 write '0' in column 3 TOTAL TOTAL If the 'Highest Number Previously Paid For' IN THIS SPACE is less than 20, enter'20 OR ADDIT FEE "If the 'Highest Number Previously Paid For' IN THIS SPACE is less than 3, enter'3 .' .' ADDrr 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 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE

Applicant : Serial No . : Filing Date : Title :

Hudetz et al. Unknown January 15, 1999 Examiner : D . Pan Group Art Unit : 2783

SYSTEM AND METHOD FOR USING AN ORDINARY .ARTICLE OF COMMERCE TO ACCESS A REMOTE COMPUTER

Hon . Commissioner of Patents and Trademarks Washington, D .C . 20231 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

2

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 D''vbl Ar
JUN (J 1919

?AnWT
Group ?_700

]T(TSa Y nTtD STATES PATENT AND TUDIXAM OFFICE in re application
Of

xudg n at el.

Serial No . : Cproup No., Filed:
EM►OJYlur"

09/`132,908 2756 unuary 15, 1999 SYSTEM ANb MTHOD FOR USING AN ORDINARY ARTICLE OF
COMMCE TO ACCESS A REMATE CO)DU'l'ER

For:

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 : Address:
Rag, No. Tel . No . Dated; 29,149 (703) 658-2100
~ar i

Rodger Plagg a 101 Crystal Plana Aro . #270 Ar bngton VA 22202

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,
*rATES 0*

UNITED ATES DEPARTMENT OF COMMERCE Patent and Trademark Office
Address : COMMISSIONER OF PATENTS AND TRADEMARKS Washington, D .C. 20231

APPLICATION NO.

FILING DATE 01/15/99

FIRST NAMED INVENTOR

ATTORNEY DOCKET NO.

09/232 .900

HUMETZ

F

ISU

061 P,

F
lel
!'Hd 1 %e

EXAMINER L M 0 2 11 &~--'j

PAN . D
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

Office Action Summary
K

Application No. 09/232,908 Examiner Pan

Applicant(s) Hudetz et al. 2783

Responsive to communication(s) filed on

Jun 3Q 1999

q This action is FINAL. prosecution as to the merits is closed q Since this application is in condition for allowance except for formal matters, 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 Of the above, claim(s)

is/are pending in the applicat is/are withdrawn from consideration is/are allowed. is/are rejected. is/are objected to.

q Claim(s)

K

Claim(s) 11=4

X Claim(s) 5-11

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 q The proposed drawing correction, filed on 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 is/are objected to by the Examiner. is q .approved disapproved.

1
U . S . Patent and Trademark Office

---

SEE OFFICE ACTION ON THE FOLLOWING PAGES ---

PTO-326 (Rev . 9-95)

Office Action Summary

Part of Paper No .

4

Application/Control Number : 0,x/232,908 Art Unit : 2783

Page 2

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 Art Unit : 2783

Page 3

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 3 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)) ;

Application/Control Number : 09/232,908 Art Unit : 2783

Page 4

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

Application/Control Number : 09/232,908 Art Unit : 2783

Page 5

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

> Group Art Unit Page , of~

Notice of References Cited

23
Examiner

~

U .S . PATENT DOCUMENTS * A B IDI E F G H I K L M FOREIGN PATENT DOCUMENTS * N 0 P Q R S DOCUMENT NO . DATE COUNTRY NAME CLASS SUBCLASS DOCUMENT NO . n DATE NAM CLASS SUBCLASS.

-T

K Z ~/~

ITI
NON-PATENT DOCUMENTS * U DOCUMENT (Including Author, Title, Source, and Pertinent Pages) DATE

v

W

X *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.
*U .S. GPO: 1996-420 . 311/40176

PTO-892 (Rev . 9-96)

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 : Black ink. Color. _ Color drawings are not acceptable until petiton is granted. Fig(s) Pencil and non black ink not permitted . Fig(s) 2. PHOTOGRAPHS . 37 CFR 1 .84 (b) _ 1 full-tone set is requited. Fig(s) - Photographs not properly mounted (must use brystol board or photographic double-weight paper). Fig(s) _ Foor quality (half-tone) . Fig(s) 3 . TYPE OF PAPER. 37 CFR 1 .84(e) Paper not flexible, strong, white, and durable . Fig(s) _ Erasures, alterations, overwritings, interlineations, folds, copy machine marks not accepted . Fig(s) _ Mylar, velum paper is not acceptable (too thin). Fig(s) 4 . SIZE OF PAPER . 37 CFR 1 .840: Acceptable sizes : _ 21 .0 cm by 29 .7 cm (DIN size A4) - 21 .6 cm by 27 .9 cm (8 1/2 x 11 inches) All drawing sheets not the same size. ` Sheet(s) _ Drawings sheets not an acceptable size. Fig(s) 5 . MARGINS . 37 CFR 1 .84(8) : Acceptable margins : Top 2 .5 cm Left 2 .5cm Right 1 .5 cm Bottom 1 .0 cm SIZE : A4 Size Top 2 .5 cm Left 2 .5 em Right 1 .5 cm Bottom 1 .0 cm SIZE : 8 1/2 x I1 j r Margins not acceptab Fi ) Top (T) Left (L) Right (R) Bottom (B) 6. VIEWS. 37 CFR 1 .84(h) REMINDER : Specification may require revision to correspond to drawing changes . Partial views . 37 CFR 1 .84(h)(2) _ Brackets needed to show figure as one entity. Fig(s) _ Views not labeled separately or properly . Fig(s) _ Enlarged view not labeled separetely or properly . Fig(s) 7 . SECTIONAL VIEWS . 37 CFR 1 .84 (h)(3) _ Hatching not indicated for sectional portions of an object. Fig(s) _ Sectional designation should be noted with Arabic or Roman numbers. Fig(s)

_

4

8 . ARRANGEMENT OF VIEWS . 37 CFR 1 .84(i) Words do not appear on a horizontal, left-to-right fashion when page is either upright or turned so that the top becomes the right side, except for graphs . Fig(s) 9. SCALE. 37 CFR 1 .84(k) _ Scale' not large enough to show mechanism without crowding when drawing is reduced in size to two-thirds in reproduction. Fig(s) 10. CHARACTER OF LINES, NUMBERS, & LETTERS. 3 11 1 .84(i) Lines, numbers & letters not uniformly thick and well defined, cl an, ble, and black (poor line quality). Fig(s) -11 . SHADING . 37t FR 1 .84(m) Solid black areas pale . ; Fig(s) Solid black shading not permitted . Fig(s) Shade lines, pale, rough and blurred .' Fig(s) 12. NUMBERS, LETTERS, & REFERENCE CHARACTERS. 37 CFR 1 .84(p) - Numbers and reference characters not plain and legible .' Fig(s) _ Figure legends are poor. Fig(s) _ Numbers and reference characters not oriented in the same direction'as the view. 37 CFR 1 .84(p)(1) Fig(s) English alphabet not used . 37 CFR 1 .84(p)(2) Figs Numbers, letters and reference characters must be at least .32 cm (1/8 inch) in height . 37 CFR 1 .84(p)(3) Fig(s) 13. LEAD LINES . 37 CFR 1 .84(q) Lead lines cross each other. Fig(s) Lead lines missing . Fig(s) 14 . NUMBERING OF SHEETS OF DRAWINGS . 37 CFR 1 .84(1) Sheets not numbered consecutively, and in Arabic numerals beginning with number 1 . Sheet (s ) 15. NUMBERING OF VIEWS . 37 CFR 1 .84(u) - Views not numbered consecutively, and in Arabic numerals, beginning with number 1 . Fig(s) 16 . CORRECTIONS. 37 CFR 1 .84(w) Corrections not made from prior PTO-948 dated 17 . DESIGN DRAWINGS . 37 CFR 1 .152 _ Surface shading shown not appropriate . Fig(s) _ Solid black shading not used for color contrast. Fig(s)

COMMENTS

r1h

REVIEWER

DATE

TELEPHONE NO.

ATTACHMENT TO PAPER NO.

Change Of Attorney Or Agent's Address In Application (37 CFR 1 .8(a))
In Re Application Of:

Docket No.

150-061A

Hudetz et al.

RECEIVED
Serial No . Filing Date Examiner
(Mo

iola
2783

n

09/232,908

01/15/99

Pan, D.

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 :

o--Anthony R . Barkume, Esq. Greenberg Traurig Met Life Building 200 Park Avenue New York, NY 10166

M

MAY MAY 0 3 2000 '-

s DEMAP.4

Please direct all telephone calls to:

(212) 801-9294

~–
Si aiure of Attorney or Agent of Record

Dated :

May 1, 2000

Anthony R. Barkum, Esq. Reg. No . 33,831 Greenberg Traurig Met Life Building 200 Park Avenue New York, NY 10166
Registration Number & Address ofAttorney or Agent of Record

1 certify that this document is being deposited on 05/01/2000 with the U .S . Postal Service as first class mail under 37 C .F .R . 1 .8 and is addressed to the Assistant Commissioner for Patents, Washington, D .C.

20231.

Signature of Pers n

ailing Correspondence

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

Copyright 1997 LegalStar

PETITION FOR EXTENSION OF TIME UNDER 37 CFR 1.136(a) (SmalifEntity)

Docket No.
150-061A

In Re Application Of : Hudetz et al. Serial No .
09/232 .908

~j

KeE I VE

~
Filing Date
January 15, 1999

~
~. C J•

MAY0~200A
a
GrC*QUpnd^700
2783

Examiner
Pan, D.

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 from :
February 29, 2000
Date

q Four months
April 29, 2000
Date

q Five months

until:

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 Greenberg Traurig Met Life Building 200 Park Avenue New York, NY 10166 (212) 801-9294

1 certify - that this document and fee is being deposited on 05/01/2000 with the U .S. Postal Service as first class mail under 37 C .F .R . 1 .8 and is addressed to the Assistant Commissioner for Patents, Washington, D .C. 20231.

Signature of Pe o Mailb1g Correspondence

cc :
Copyright 1994-97 LegalStar

Linda Garramone
Typed or Printed Name of Person Mailing Correspondence P12SMALUREV05

0 1

MAY

o

3, 1000

cc)

Docket Number : 150-061A
DEMARy'

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE Applicant : Serial No . : Filing Date : Hudetz et al .

RECEIVED
MAY Q a
2000

Group. 2700
09/232,908 January 15, 1999 Examiner : D . Pan
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 Washington, D .C . 20231 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 barcoded 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 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.

J

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 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 . --

r

1

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. Attached to,computer 114 by a suitable input/output interface . 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

3 /7
r5`

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

T

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 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

~(J

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

)

1 a

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 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 scansystem 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 .--

J

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) b) reading a data carrier modulated with an index; accessing a database with the index, the database . comprising a plurality of records that link an

K

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. The method of claim wherein the step of reading a

PDA!

&5

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. J3,e 3 The method of claim .3'~ wherein the bar code symbol is

encoded in accordance with an extrinsic standard. I The method of claim .4 wherein the index is at least a ~Q3 portion of a Universal Product Code. The method of claim -.)*I wherein the index is at least a portion of a EAN Code .
~' .

f
Jel

The method of claim

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 emanating from an object and demodulating the 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-'

94'.

(t The method of claim A .3 wherein the step of inputting

into the user computing device an audible signal modulated 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. The method of claim ~-ff wherein the step of reading a

4-15*.

data carrier modulated with an index comprises accessing a magnetic card with a magnetic card reader.
)T

4-1

t 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

Y

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.
a-0
,f .

The method of claim 3~3 wherein the pointer comprises a Uniform Resource Locator.


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 , RS . The method of claim ,i-~ wherein the step of accessing a

3

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 indexeshaving 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 the user computing device.
.1

A
.0

,
The method of claim ;i,-1 wherein the step of using the

pointer to establish communication with the remote computer identified thereby is executed by a user selecting hypertext link returned to the user computing device by the database. ffl •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.

I

3 6 , The
31 ' .

~l
method of claim wherein the wide area network is

the Internet.

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 -3' wherein access to the database

3 1

requires entry of a password.

35

b-1 .The method of claim3 wherein the database is associated with a search-engine. 3T . r6'
A

I

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 .

r

J

13

3

3 (P

The system of claim

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 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.
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 configured to read an index comprising at least a portion of a EAN code .
43

3 J~, .74 . The system of claim 6.6 wherein the input device is configured to read an index comprising at least a portion of an ISBN code . The system of claim 4?9 wherein the input device is configured to read an index comprising at least a portion 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 '4e

No

. 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 ,7.?' .

The system of claim 7,4T wherein the means for inputting

4110

into the user computing device an audible signal modulated with information correlated to the index is configured to utilize voice recognition techniques.
L1$ 36

ji-6 .

The system of claim ,C9 wherein the input device

comprises means for inputting an RF signal modulated with information correlated to the index.

;je .

The system of claim .r8 wherein the input device

comprises means for reading a magnetic stripe card.

S~
67
da-5 .

•3b

The system of claim .09 wherein the means for storing a database is located on the user computing device. 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.
3 (0

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 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 ~J . 36 The system of claim ~ wherein the index is comprised 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 . 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.

,P6 .

Vie

gJr .

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

pointer to establish communication with the remote computer 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 the user computing device. y+5 . The system of claim .19 wherein the means for using the

pointer to establish communication with the remote computer identified thereby executes by a user selecting hypertext. link returned to the .user computing device by the database.
!o ~{ 36
Erb

9'r.The system of claim

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
-3-z~ .

C7
The system of claim k9 wherein the online service

provider computer additionally .provides a gateway to the Internet.

69

36
requires entry of a password.

,02 . The system of claim r8 wherein access to the database

7d

.

The system of claim j&6 wherein the database is

associated with a search engine. X6' . A user computing device comprising: .3 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~~
W

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 ..

, y '7

6 The user computing device of claim 1.@3 wherein the

?t

user input device comprises means for reading a light pattern emanating from an object and demodulating the light pattern to obtain the index. *73 19~ . The user computing device of claim

9z
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.

'/-~ ' 1.9-' . The user computing device of claim

73

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.

t~ Y~

`

77 7( .,9-e . The user computing device of claim .1' wherein the
input device is configured to read an index comprising at least a portion of a EAN code .

7$

1 .4e. The user computing device of claim 10

71

wherein the

input device is configured to read an index comprising at least a portion of an ISBN code .
17

9

.

k1R~ . The user computing device of claim 2.9 1 wherein the 3 input device is configured to read an index comprising at least a portion of an ISSN code. 1-

11

7s

7y
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. 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 information correlated to the index. ,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 .

a/

I/

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.
~~
J-r g . -

7l
The user computing device of claim X93 wherein the

input device comprises means for reading a magnetic stripe card. '1( Bi' ,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.

,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.

7(

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.

a~

go

r

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. e/ l The user computing device of claim ]~ wherein the

go

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
.1.2~ The user computing device of . claim computer over a wide area network.

'7I
further adapted to establish communication with the remote

C74
► ~

. Q3
The user computing device of claim the Internet.
.14?5

further adapted

to establish communication with the remote computer over

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 . FIGS . 8-10,

which correspond - to

1-3 of the provisional application . To avoid 1-3 of the provisional application have been

duplicate reference numerals, references 10 through 144 of in
FIGS .

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 pointer to establish communication with the remote computer 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 SERVER

SERVICE PROVIDER

204 Z/D
222

22 S

ZZIo

236
234 2//o MODEM l DOCUMENT

Z/Z

i COMPUTER ~ 1 BAR CODE READER

Z32

Z/8 220

232

Fj1p:II sample c .w

w.

eeM

2,36

39

0

FIG 9
238
READ SCANNER -INPUT ' ',

NO INPUT?

240

r--T,>

230

YES -TRANSMIT ADDRESS

24Z

L---~

RECEIVE ~ DATA

Z4*

FIG - 10

AMENDMENT TRANSMITTAL LETTER (Small Entity) Applicant(s) : Hudetz et al.

Docket No. /C 15REEIV E Gro rt&A 2000
756 drou 2700 R A NETWORK

Serial No .
09/232,908 Invention :

Filing Date
January 15, 1999

Examiner
D . Pan

SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER O

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 AFTER AMENDMENT
TOTAL CLAIMS

HIGHEST # PREV . PAID FOR

NUMBER EXTRA CLAIMS PRESENT

RATE

ADDITIONAL FEE

95 20 INDEP . CLAIMS 3 3 Multiple Dependent Claims (check if applicable)

= = q

75 x 0 x

$9.00 $39.00

$675 .00 $0 .00 $0 .00 $675 .00

TOTAL ADDITIONAL FEE FOR THIS AMENDMENT q q ® q No additional fee is required for amendment. Please charge Deposit Account No . in the amount of A duplicate copy of this sheet is enclosed. A check in the amount of $675.00 to cover the filing fee is enclosed. The Commissioner is hereby authorized to charge payment of the following fees associated with this communication or credit any overpayment to Deposit Account No. A duplicate copy of this sheet is enclosed. q Any additional filing fees required under 37 C .F.R. 1 .16. qM nytent application processing fees under 37 CFR 1 .17. Dated:
Signature

May 1, 2000

Anthony . Barkume Rcg . No . 33,831 Attorney for Applicant 200 Park Avenue

NewYork, ;NY10166.
(212) 801-9294

1 certify that this document and fee is being ',deposited with the U .S . Postal :Service as first class mail under 37 C .F.R . 1 .8 and is addressedito the Assistant Commissioner for Patents, Washington, D .C. 20231 . `

am May 1, 2000

Signature ofPerso~

ing Correspondence

cc :

Linda Garramone
Typed or Printed Name ofPerson Mailing Correspondence P11 SMALUREV06, I

CERTIFICATE OF MAILING BY.~FIRST CLASS MAIL. (37 CFR 1 .8)
Applicant(s) :

Docket No. 150-061A

Hudetz et al .
Filing Date Examiner

Serial No .

F4 F= Prpn I P V— on h ME Pt
MAr 19 8 2000

091232,908

January 15, 1999

Pan, D .

Invention : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER CWJP 2700 NETWORK

v 3 2000 0 MAY 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(Under 37 CFR 1.97(b) or 1 .97(c))

Docket No.
150-061A

1

In Re Application Of : Hudetz et al. Serial No .
09/232,908 Title :

Filing Date January 15, 1999

Examiner Pan, D.

C ..' Group Arpinit
2788

.9

nI
141
%

rQ

SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK

1P
Address to:

MAY 0 5

Assistant Commissioner for Patents Washington, D.C . 20231

1. q

MADEM37 CFR 1 .97(b). )~'$ 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. 2. a Final Action under 37 CFR 1 .113, or 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). 00000006 09232908 240.00 OP

05A /2000 HLUANG 01F •126

Copyright 1996 Legalsoft

P10AIREV01

TR~-i,NSMITTAL OF INFORMATION DISCLOSURE STATEMENT (Under 37 CFR 1.97(b) or 1 .97(c))
In Re Application Of:

Docket No. 150-061A

Hudetz et al .

o
C
Examiner Group ArrQnit

3C

w
c°a

M M

Serial No .

Filing Date

n
C D

09/232,908

January 15, 1999

Pan, D .

27830

Title : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK

O

p

MAY 0 5 200 2~`
k 7ItApFMPe~ i ® q

Payment of Fee
(Only complete if Applicant elects to pay the fee set forth in 37 CFR 1 .17(p))

A check in the amount of is attached. $240 .00 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 q q Charge the amount of Credit any overpayment. Charge any additional fee required.

Certificate of Transmission by Facsimile*
I certify that this document and authorization to charge deposit account is being facsimile transmitted to the United States Patent and Trademark Office (Fax . No . ) on (Date)

Certificate of Mailing by First Class Mail
I certify that this document and fee is being deposited on 05/02/2000 with the U .S . Postal Service as first class mail under 37 C .F .R . 1 .8 and is addressed to the Assistant Commissioner for Patents, Washington, D .C. 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 :
Signature

May 2 , 2000

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

r

0

1P
INFORM

SUPPLEMENTAI.
ION DISCLOSURE %.,iTATION

MAY O 5 2000"1

several sheets if necessary) #

ATTY DOCKET NO . 150-061A. APPLICANT(S) Hudetzetal. FILING DATE January 15, 1999 U .S . PATENT DOCUMENTS

SERIAL NO. 09/232,908 GROUP 3 V
CLASS SUBCLASS FILI
0

..~

TRADEMPQ
'EXAMINER INITIAL DOCUMENT NUMBER DATE

NAME

ATE C IF APPROPRI

5,905,251 5,913,210
~L

05/18/99 06/15/99 06/29/99 08/03/99 08/17/99 08/17/99 09/07/99 10/26/99 11/30/99 01/04/2000 02/22/2000

Knowles Call Perkowski Rathus et al. Reber et al. Reber et al . Perkowski Cragun et al. Reber et al. Shachar Knowles
O

Z, b

i

5,918,214 5,932,863

f^~

r

,

5,938,726 5,940,595 5,950,173 5,971,277

Z /

~6~t

cj

~–

5,995,105 6,012,102 6,027,024

D

f

FOREIGN PATENT DOCUMENTS
DOCUMENT NUMBER DATE COUNTRY CLASS SUBCLASS TRANSLATION YES NO

OTHER DOCUMENTS
Pages 1-27

(Including Author, Title, Date, Pertinent Pages, Etc .)

Fachhochschule Bielefeld, University of AVplied Sciences, Hochschulbibliothek~,

J I

Fac hochschule Bielefeld= _ niversity U

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 P09C/REV03 Patent and Trademark Office' U .S. DEPARTMENT OF COMMERCE Form PTO-AS20 (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 Request for Comments : 882 DOMAIN NAMES - CONCEPTS and FACILITIES

P . Mockap November

~ 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 used for referring to problems caused by ad addresses, routes, or a consistent name space which will b resources . In order to avoid the hoc encodings, names should not cont 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 RFC 882

[Pa November Domain Names - Concepts and Facil

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 RFC 882

_

_._

'[Pa

-:

November Domain Names - Concepts and Facil 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 RFC 882 [Pa

_

_

:::.

November Domain Names - Concepts and Facil 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 RFC 882

_[_Pa.
November Domain Names - Concepts and Facil

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 ............................ . .......... .................................. ... ..... ...... ....... ...................... ........... .................. .................. ......................... ...................... ............... _ RFC 882 [Pa

_

November Domain Names - Concepts and Facil

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

RED BLUE GREEN

I

I
+

I

NATURAL

CHOCOLATE

I

VANILLA

I

STRAWBERRY

I

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 RFC 882

[Pa November Domain Names - Concepts and Facil

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 RFC 882 [Pa November Domain Names - Concepts and Facil 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 MF MD NS SOA - the host address associated with the domain name - identifies a mail forwarder for the domain - identifies a mail destination for the domain - the authoritative name server for the domain - 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

+ // <class>I <class specific address>information + + //
I

Mockapetris _ RFC 882

_

[Pa _ November Domain Names - Concepts and Facil

The the bit the two

content of the class specific information varies accordin value in the CLASS field ; for the ARPA Internet, it is th ARPA Internet address of the host, for the CSNET it might phone number of the host . For example, F .ISI .ARPA might A records of the form: + A + IN + and + CS
I

+ + IF-.ISI .ARPAI + + + + IF .ISI .ARPAI + +

+

I
+ +

I

10 .2.0 .52

=-+` +

I

A

I

213-822-2112

I

+

+

+'

Note that the data formats for the A type are class dependent

http ://www-bib .fh-bielefeld.de/epub/doc/idoc/rfc/rfe-0800-0899/rfc882 .html l 5/1/00

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 + + + + + <domain name> + + +

I < class >I .

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 + + + IF .ISI .ARPAI MF + + + IN + F .ISI .ARPA + + B .ISI .ARPA +

I
+ +

I
+ and +

+

I I

I
+

IN

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 RFC 882 (Pag_ , November Domain Names - Concepts and Facil

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 + + + + I <class>I
+ +

<domain name, etc>

+ I + + I
+

+ I <owner> I
+ +

NS

<domain name>

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 RFC 882

_

[Pag

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 + UDEL + ISI + UDEL + CSNET +----=+ UCI + NBS

JCS ARMY NAVY + DTI + MIT

http ://www-bib .fh-bielefeld.de/epub/doc/idoe/rfe/rfe-0800-0899/r-fc882.html

511100

HTML Version from RFC Dc --i .ment +---+---+
DMS AI A B F

Page 11 of 27

Mockapetris
_ _- .

[Pag_ November Domain Names - Concepts and Facil

RFC 882

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

HTML Version from RFC Dc ment

Page 12 of 27

ways, the .normal method is to store the information acquired Mockapetris RFC 882 [Pag November Domain Names - Concepts and Facil

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. 2. 3. It must register with the parent administrator of doma It must identify a responsible person. 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 RFC 882 [Pag November Domain Names - Concepts and Facil

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 RFC 882

[Pag November Domain Names - Concepts and Facil copies the resource record specifiediby into the response.

copy(RR)

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; for all RRs in set(ptr) 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 }

for all RRs in set(ptr) 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 RFC 882 [Pag

...... ......

November Domain Names - Concepts and Facil

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;

HTML Version from RFC Dr ment
discussed in [14]. Additional information

Page 15 of 27

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 Domain Names - Concepts and Facil

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 F .ISI .ARPA CNAME A IN IN F .ISI .ARPA 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 F .ISI .ARPA XXXX .ARPA XXXX .ARPA A IN MD IN CNAME IN MF IN 10 .2 .0 .52 F .ISI .ARPA F .ISI .ARPA 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 . RFC 882 November Domain Names - Concepts and Facil [Pag_

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 RFC 882

[P a~g

November Domain Names - Concepts and Facil

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) + ARPA (F .ISI .ARPA) (A .ISI .ARPA)+

+ DDN I(JCS .DDN) + +

+ CSNET I(UDEL .ARPA) + + UCI + UDEL + NBS

+

I
+ DTI

I
+

JCS ARMY NAVY +

I

I
UDEL

I

MIT I(AI .MIT .ARPA) +---+---+ DMS AI A

ISI I(F .ISI .ARPA)

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

HTML Version from RFC Dc ment
B .ISI .ARPA Name server for

Page 18 of 27

B .ISI .ARPA has the root name server for the IN class . Its % database might contain : Domain " " DDN ARPA CSNET " " " JCS .DDN F .ISI .ARPA UDEL .CSNET UDEL .ARPA Resource Record SOA NS NS NS NS NS A A A A IN IN IN IN IN CS IN IN CS IN A .ISI .ARPA JCS .DDN F .ISI .ARPA UDEL .ARPA B .ISI .ARPA UDEL .CSNET 9 .0 .0 .1 10 .2 .0 .52 302-555-0000 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 RFC 882

[Pag November Domain Names - Concepts and Facil

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 NS SOA NS IN CS IN IN B .ISI .ARPA CSNET .UDEL B .ISI .ARPA A .ISI .ARPA

ARPA ARPA

http://www-bib . fli-bielefeld . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html

511100

HTML Version from RFC Dr ment
ARPA MIT .ARPA ISI .ARPA ISI .ARPA A .ISI .ARPA ISI .ARPA A .ISI .ARPA B .ISI .ARPA B .ISI .ARPA F .ISI .ARPA F .ISI .ARPA DTI .ARPA NBS .ARPA UDEL .ARPA A .ISI .ARPA F .ISI .ARPA B .ISI .ARPA DTI .ARPA AI .MIT .ARPA DMS .MIT .ARPA NBS .ARPA UDEL .ARPA NS NS SOA NS MD MD MF MD MF MD MF MD MD MD A A A A A A A A IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN F .ISI .ARPA AI .MIT .ARPA F .ISI .ARPA F .ISI .ARPA A .ISI .ARPA F .ISI .ARPA F .ISI .ARPA B .ISI .ARPA F .ISI .ARPA F .ISI .ARPA A .ISI .ARPA DTI .ARPA NBS .ARPA UDEL .ARPA 10 10 10 10 10 10 10 10 .1 .2 .3 .0 .2 .1 .0 .0 .0 .0 .0 .0 .0 .0 .0 .0 .32 .52 .52 .12 .6 .6 .19 .96

Page 19 of 27

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 RFC 882 [Pa...9_ .. _ November Domain Names - Concepts and Facil

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 " B .ISI .ARPA B .ISI .ARPA B .ISI .ARPA F .ISI .ARPA
If

NS NS MD MF A A

IN CS IN IN IN IN

F .ISI .ARPA UDEL .CSNET B .ISI .ARPA F .ISI- .ARPA 10 .3 .0 .52 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
K

Page 20 of 27

name server and return the following: MIT .ARPA AI .MIT .ARPA NS A IN IN AI .MIT .ARPA 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 Domain Names - Concepts and Facil

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: " " CSNET CSNET ARPA * .CSNET UDEL .CSNET UCI .CSNET UDEL .ARPA B .ISI .ARPA UDEL .ARPA UDEL .CSNET UCI .CSNET SOA NS NS SOA NS NS MF MD MD MD A A A A CS CS IN IN IN IN IN CS CS IN IN IN CS CS UDEL .CSNET UDEL .CSNET B .ISI .ARPA UDEL .ARPA UDEL .ARPA A .ISI .ARPA UDEL .ARPA UDEL .CSNET UCI .CSNET UDEL .ARPA 10 .3 .0 .52 10 .0 .0 .96 302-555-0000 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 UDEL .ARPA MF A IN IN UDEL .ARPA 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 UCI .CSNET MD A CS CS UCI .CSNET 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 RFC 882 [Pag November Domain Names - Concepts and Facil

* .* .* .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, an arbitrary name servers In practice, if a resolver wishes to perform an inverse ;query host on the ARPA Internet, it must consult~a set sufficient to know that all IN data was consider 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 fi

Page 22 of 27

fairly comprehensive database should satisfy the vast majorit inverse queries. A detailed discussion of inverse queries is contained in [14]

Mockapetris
RFC 882

[Pag
November Domain Names - Concepts and Facil

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 RFC 882 [Pag_ November Domain Names - Concepts and Facil

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 RFC 882 [Pag_ _,

_ _

._

November Domain Names - Concepts and Facil 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 RFC 882

,

- .

-

.

_

[Pag

November Domain Names - Concepts and Facil

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

HTML Version from RFC Dc ment

Page 25 of 27

Mockapetris RFC 882

[Pag November Domain Names - Concepts and Facil

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> <let-dig-hyp> <let-dig> <letter> <let-dig-hyp> <ldh-str> "-"

<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 - RFC 882

-

[Pag November Domain Names - Concepts and Facil

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. J . Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. Z . Su, and J . Postel, "The Domain Naming Convention for, Int User Applications", RFC 819, Network Information Center,, SR International, August 1982. Z . Su, "A Distributed System'for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. K . Harrenstien, and V . White, "NICNAME/WHOIS", RFC 812, ;Net Information Center, SRI International, March 1982. M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. K . Harrenstien, "NAME/FINGER", RFC 742, Network Information . Center, SRI International, December 1977. J . Postel, "Internet Name Server", IEN 116,'USC/Information Sciences Institute, August 1979. K . Harrenstien, V . White, and E . Feinler, "Hostnames Server RFC 611, Network Information Center, SRI International, March 1982.

[2] [3]

[4]

[5] [6] [7] [8] ' [9]

[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

HTML Version from RFC Dr ment

Page 27 of 27

(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 Request for Comments : 883 [Note : See also RFC 973 CSNET CIC]

P . Mockap 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

HTML Version from RFC Dr ment

Page 2 of 64

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 1 - Domain Name Syntax Specification 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 REFERENCES and BIBLIOGRAPHY INDEX

:

Mockapetris RFC 883

.... __

[Pag

November Domain Names - Implementation and Specific

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

HTML Version from RFC Dr ment fi

Page 3 of 64

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 RFC 883

[Pa

November Domain Names - Implementation and Specific

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 + User Program < user responses + user queries > Resolver < responses + + queries

I

Foreign

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

511100

HTML Version from RFC Dr
+

~ment
+ + A + +

Page 4 of 64
+

cache

additions V +

I

references +

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 RFC 883

[Pa November Domain Names - Implementation and Specific

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

+ /
Master files = +

+ +/

I
+ > Name Server queries + + + responses

Foreign;

I

+ -> Foreign Resolver

+

I

----------

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

HTML Version from RFC Dr ment +
Master files +

Page 5 of 64 +
> / + A
\

+ responses Name Server < queries maintenance
>

----------

->
I +
+

Foreign

I

I

I

I Resolver
I +
+

queries

maintenance responses ,

Foreign Name Server

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 RFC 883

[Pa November Domain Names - Implementation and Specific

The information flow in a host that supports all aspects of t domain name system is shown below: Local Host + User Program < user responses + + + A cache additions + + user queries > Resolver < responses + + queries -> Foreign Name ~ -- Server ----------

I

Foreign + +

v
+

I

references

+ + Master files / + + +

+

+ Shared database ----------A refreshes references V + + ---------responses -> Foreign Name > : Server - Resolver < 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 RFC 883

[Pa November Domain Names - Implementation and Specific

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

HTML Version from RFC D ment

Page 7 of 64

Mockapetris RFC 883

[.Pa _
November Domain Names - Implementation and Specific

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 i 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 i i 3 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 RFC 883

(Pa November Domain Names - Implementation and Specific ********** 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

I

I

"s:

HTML Version from RFC D~ ment fi

Page 8 of 64

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 RFC 883

[Pa November Domain Names - Implementation and Specific

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 RFC 883 [Pa_ November Domain Names - Implementation and Specific 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 RFC 883 [Pa

.

November Domain Names - Implementation and Specific

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 RFC 883

[._Pag._.
November Domain Names - Implementation and Specific

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

,

HTML Version from RFC D ment
message of up to 512 octets. Mockapetris RFC 883

Page 12 of 64

[Pag 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 RFC 883 [Pag November Domain Names - Implementation and Specific 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

HTML Version from RFC D ment

Page 13 of 64

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 + I
+ +

Header Question Answer

+ I + I the question for the name server
+
I

answering resource records (RRs)

+ Authority Additional

I
+

I RRs pointing toward an authority
+

I
+

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 RFC 883 [Pag November Domain Names - Implementation and Specific

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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 Question Answer Authority Additional OPCODE=QUERY, ID=2304 + IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA = + <empty> I + <empty> I + <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 RFC 883

1Pa g
November Domain Names - Implementation and Specific

one possible response to this query might be: -Header Question Answer Authority OPCODE=RESPONSE, ID=2304 j--+ IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA '--+ = <empty> -ARPA NS IN A .ISI .ARPA ARPA NS - IN - F .ISI .ARPA + Additional + 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. F .ISI .ARPA A IN 10 .2 .0 .52 A .ISI .ARPA A IN 10 .1 .0 .22

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 RFC 883

[Pag November Domain Names - Implementation and Specific

The name server on A .ISI .ARPA might return a response: + Header Question Answer

I OPCODE=RESPONSE, ID=2305 + IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA + = F .ISI .ARPA MD IN F .ISI .ARPA
F .ISI .ARPA MF IN A .ISI .ARPA +

Authority Additional

I

<empty> F .ISI .ARPA A IN 10 .2 .0 .52 A .ISI .ARPA A IN 10 .1 .0 .22 '----

+

I

+

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 RFC 883 [Pag__

November Domain Names - Implementation and Specific

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 Question

+ <empty> + Answer + Authority Additional
I

I

OPCODE=IQUERY, ID=997

<anyname> A IN 10 .2 .0 .52 <empty> <empty> .--+ +

I

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: + Header Question Answer Authority + Additional
I

.--OPCODE=RESPONSE, ID=997 QTYPE=A, QCLASS=IN, QNAME=F .ISI .ARPA F .ISI .ARPA A IN 10 .2 .0 .52 <empty> <empty>

+
I

I

+ +

I

+ 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 RFC 883

[Pag November Domain Names - Implementation and Specific

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

5/1/00

HTML Version from RFC D ,

ment

Page 18 of 64

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 RFC 883 [Pag ........ November Domain Names - Implementation and Specific 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 RFC 883 [Pag

„ -,

_...

November Domain Names - Implementation and Specific

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 RFC 883

[Pag_ November Domain Names - Implementation and Specific

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 Question Answer Authority Additional
I

OPCODE=CQUERYU, ID=409 QTYPE=A, QCLASS=IN, QNAME=B <empty> <empty> ISI .ARPA NULL IN

+
I

,

+
I

+
I

+
I

+ 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: Header Question OPCODE=RESPONSE, ID=409 QTYPE=A, QCLASS=IN, QNAME=B

+
I

I

+

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

511100

HTML Version from RFC D ,

~ment
Answer + Authority +--= Additional
I

Page 21 of 64
B .ISI .ARPA A IN 10 .3 .0 .52 <empty> ISI .ARPA NULL IN +

This response has completed B to mean B .ISI .ARPA.

Mockapetris RFC 883

[Pag November Domain Names - Implementation and Specific

Another query might be: + Header Ques.tion Answer + Authority Additional
I I

OPCODE=CQUERYM,

ID=410

+
I

QTYPE=A, QCLASS=IN, QNAME=B <empty> <empty> ARPA NULL IN
."

+

+
I
+

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: + Header Question Answer
I OPCODE=RESPONSE, ID=410 ----------------------------------------I QTYPE=A, QCLASS=IN, QNAME=B + 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 Additional
I

<empty> ARPA NULL IN1 B .ISI .ARPA, B .BBN .ARPA,

+
I

+ This response contains three answers, B .BBNCC .ARPA .

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

511100

RFC 883

November Domain Names - Implementation and Specific

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 RFC 883 [Pag November Domain Names - Implementation and Specific

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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
-r

Page 24 of 64

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 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. - A one bit field that specifies whether this message query (0), or a response (1). RCODE +

QR

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 RFC 883

[Pag ....... ....... November Domain Names - Implementation and Specific 1 2 2 an inverse query (IQUERY) an completion query allowing multiple answers (CQUERYM) 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
-t

Page 25 of 64
- 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. - Recursion Available - this be is set or cleared in response, and denotes whether recursive qu support is available in the name server.

RD

RA

RCODE - Response code - this 4 bit field is set as part of responses . The values have the following interpretation: 0 1 No error condition 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 RFC 883

[.

P g
a

_..

November Domain Names - Implementation and Specific 4 5 Not Implemented - The name server does support the requested kind of query. 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 RFC 883

JP a..9-... November Domain Names - Implementation and Specific

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

HTML Version from RFC Dr ment
I

Page 27 of 64

Mockapetris RFC 883

_[_Rag...
November Domain Names - Implementation and Specific

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 This field specifies the meaning of in Appendix 2 . 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

HTML Version from RFC Dr ment
RFC 883

Page 28 of 64
November Domain Names - Implementation and Specific

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 RFC 883

l_pa .g....

November Domain Names - Implementation and Specific

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 RFC 883

[-Pag. .
November Domain Names - Implementation and Specific

20 22 24

1 3

F 1 I

I

S

4 A 26 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ _ 28 I R P 30 A 0

40 42

3

F O

I

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 RFC 883 [ P a9.... November Domain Names - Implementation and Specific

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
they are of different classes.

Page 31 of 64

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 RFC 883 [Pag November Domain Names - Implementation and Specific

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 RFC 883

.

.

[Pag

November Domain Names - Implementation and Specific 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
Mockapetris '
RFC 883

Page 33 of 64 J.Pa g
November Domain Names - Implementation and Specific

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 Domain Names - Implementation and Specific

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

HTML Version from RFC D ment
version. Completion query processing

Page 34 of 64

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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 RFC 883 [ P ag _... November Domain Names - Implementation and Specific

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

HTML Version from RFC Dr ment

Page 36 of 64

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 RFC 883

Pag
November Domain Names - Implementation and Specific

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

HTML Version from RFC D ,

ment
•Y

Page 37 of 64

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 _ RFC 883 [Pag

_

.

November Domain Names - Implementation and Specific 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 ... _ RFC 883

,

_

_

-

[Pag

November Domain Names - Implementation and Specific 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 RFC 883 [Pag

...........

November Domain Names - Implementation and Specific

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

HTML Version from RFC Dr ment

Page 39 of 64

$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 RFC 883

LPag November Domain Names - Implementation and Specific 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

HTML Version from RFC Dr ment
within parentheses.

Page 40 of 64

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 9999999 9999999 9999999 IN CS IN CS NS NS A A B .ISI .ARPA UDEL .CSNET 10 .3 .0 .52 302-555-0000

B .IS .I .ARPA UDEL .CSNET

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 RFC 883

- „

_

.

[Pag

November Domain Names - Implementation and Specific IN SOA Action .E .ISI .ARPA 20 SERIAL 3600 REFRESH 600 RETRY 3600000 ; EXPIRE 60) ; MINIMUM F .ISI .ARPA F .ISI :ARPA is a name server for AR A .ISI .ARPA A .ISI .ARPA is a name server for AR AI .MIT .ARPA ; delegation to MIT name server F .ISI .ARPA ; delegation to ISI name server UDEL .ARPA 10 .0 .0 .96 NBS .ARPA 10 .0 .0 .19 DTI .ARPA 10 .0 .0 .12 10 .2 .0 .6 10 .2 .0 .52 and its zone and for a mailbox zone, and is F .ISI .ARPA

MIT ISI UDEL NBS DTI AI .MIT F .ISI

NS NS NS NS MD A MD A MD A A A

The first group of lines contains the SOA record parameters, and identifies name servers for this delegated zones . The Action .E .ISI .ARPA field is specification for the responsible person for the

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 is a name server

F .ISI .ARPA 10 .1 .0 .32 A .ISI .ARPA F .ISI .ARPA 10 .3 .0 .52 B .ISI .ARPA Mockapetris RFC 883

(Pag November Domain Names - Implementation and Specific

MF F .ISI .ARPA A 10 .2 .0 .52 MD F .ISI .ARPA MF A .ISI .ARPA $INCLUDE <SUBSYS>ISI-MAILBOXES .TXT F Where the file <SUBSYS>ISI-MAILBOXES .TXT is: MOE LARRY CURLEY STOOGES MB MB MB MB MG MG MG F .ISI .ARPA A .ISI .ARPA B .ISI .ARPA B .ISI .ARPA MOE .ISI .ARPA LARRY .ISI .ARPA 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 RFC 883

[_Pa.g...
November Domain Names - Implementation and Specific

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 name server not contain the AXFR is possible .) request cannot be matched to a SOA, the foreig will return a single message in response that the AXFR request . (The normal SOA query prece designed to avoid this condition, but it is st

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 RFC 883

[_Pa .g...._
November Domain Names - Implementation and Specific

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 RFC 883

[. Pag_
November Domain Names - Implementation and Specific

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 RFC 883 [Pag November Domain Names - Implementation and Specific

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
t

Page 45 of 64

Mockapetris RFC 883

LPag.. .
November Domain Names - Implementation and Specific

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 -i

Page 46 of 64

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 RFC 883 [Pag_ ,

November Domain Names - Implementation and Specific 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 RFC 883

P ag .... November Domain Names - Implementation and Specific F .ISI .ARPA MD IN F .ISI .ARPA F .ISI .ARPA MF IN A .ISI .ARPA

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 RFC 883

P_a J._.
November Domain Names - Implementation and Specific

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 RFC 883

(Pag
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

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 use domain names containing binary inform and hence do not follow this syntax. <domain> <subdomain>

1 " "
<subdomain> " ." <label>

<subdomain> : .= <label> <label> <ldh-str> <let-dig-hyp> <let-dig>

<letter> [ [ <ldh-str> ] <let-dig> ] <let-dig-hyp> : .= <let-dig> <letter> <let-dig-hyp> <ldh-str> 1111

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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
fields are subject to change. ------------------------------------------TYPE values

Page 50 of 64

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 NS MD MF 1 a host address 2 3 4 an authoritative name server a mail destination a mail forwarder the canonical name for an alias

CNAME 5 SOA MB MG MR

6 marks the start of a zone of authority 7 a mailbox domain name 8 a mail group member 9 a mail rename domain name

NULL 10 a null RR WKS 11 a well known service description a domain name pointer host information mailbox or mail list information [Pag
_ .. .

PTR 12 HINFO 13 MINFO 14 Mockapetris RFC 883

November Domain Names - Implementation and Specific

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

HTML Version from RFC Dr ment
CS 2. the computer science network (CSNET)

Page 51 of 64

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 RFC 883

(Pag November Domain Names - Implementation and Specific

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 TYPE - a compressed domain name to which this resource record pertains. - 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

HTML Version from RFC D ment

Page 52 of 64

CLASS TTL

- two octets which specifies the class of the data the RDATA field. - 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 RFC 883

L Pa.g. ._
November Domain Names - Implementation and Specific

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 / / 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 CPU OS / /

http://www-bib .fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html

511100

HTML Version from RFC D ,

iment
-Y

Page 53 of 64

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 RFC 883 [ Pag.. . November Domain Names - Implementation and Specific length followed by that number of characters . standard types are defined :. ASP DOS/360 GCOS KRONOS MULTICS OS/MVS RSX11M SINTRAN TSS VMS AUGUST ELF GPOS MCP MVT OS/MVT RT11 TENEX UNIX WAITS BKY EPOS ITS MOS NOS RIG SCOPE TOPS10 VM/370 CCP EXEC-8 INTERCOM MPX-RT NOS/BE RSX11 SIGNAL TOPS20 VM/CMS The follo

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: MADNAME - A compressed domain name which specifies a host

Mockapetris RFC 883

[Pag November

http ://www-bib .fh-bielefeld.de/epub/doc/ldoc/rfe/rfe883 .html

5/1/00

HTML Version from RFC D ment
r

Page 54 of 64
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 an A type record corresponding to MADNAME . The RDATA sect of a MD line in a master file is a standard printed domain name. MF RDATA format / MADNAME /

where: MADNAME - A compressed domain name which specifies a host has a mail agent for the domain which will accep mail for forwarding to the domain. MF records cause additional section processing which looks an A type record corresponding to MADNAME . The RDATA sect 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 RFC 883

[Pag November Domain Names - Implementation and Specific

MINFO RDATA format / / RMAILBX EMAILBX / /

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

511100

HTML Version from RFC D ment
where:

Page 55 of 64

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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

HTML Version from RFC D ment

Page 56 of 64

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 / 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. PTRDNAME /

Mockapetris RFC 883

[Pag

November Domain Names - Implementation and Specific

SOA RDATA format / / MNAME RNAME SERIAL REFRESH RETRY EXPIRE MINIMUM where: MNAME RNAME - The domain name of the name server that was the original source of data for this zone. - 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

HTML Version from RFC D ment

Page 57 of 64

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 RFC 883 [Pag_ November Domain Names - Implementation and Specific 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 RFC 883

[_P a.g..._
November Domain Names - Implementation and Specific

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 Domain Names - Implementation and Specific

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 RFC 883 [Pag ., November Domain Names - Implementation and Specific

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 RFC 883 [Pag November Domain Names - Implementation and Specific

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 10 .IN-ADDR 18 .IN-ADDR 26 .IN-ADDR 22 .0 .2 .10 .IN-ADDR 103 .0 .0 .26 .IN-ADDR 77 .0 .0 .10 .IN-ADDR 4 .0 .10 .18 .IN-ADDR 52 .0 .2 .10 .IN-ADDR 6 .0 .0 .10 .IN-ADDR PTR PTR PTR PTR PTR PTR PTR PTR PTR PTR IN IN IN IN IN IN IN IN IN IN MILNET-GW .ISI .ARPA GW .MIT .ARPA GW .MIT .ARPA MILNET-GW .ISI .ARPA MILNET-GW .ISI .ARPA MILNET-GW .ISI .ARPA GW .MIT .ARPA GW .MIT .ARPA F .ISI .ARPA 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 IO .IN-ADDR PTR IN MILNET-GW .ISI .ARPA 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 RFC 883

_[_Pag November Domain Names - Implementation and Specific

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 RFC 883

[Pag November Domain Names - Implementation and Specific

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. J . Postel, "Computer Mail Meeting Notes" RFC 805, __ USC/Information Sciences Institute, February 1982. Z . Su, and J . Postel, "The Domain Naming Convention for Int User Applications", RFC 819, Network Information Center, SR International, August 1982. Z . Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. K . Harrenstien, and V . White, "NICNAME/WHOIS", RFC 81. 2Net Information Center, SRI International, March 1982. M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Nam Server", Computer Networks, vol 6, nr 3, July 1982. K . Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. J . Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. K . Harrenstien, V . White, and E . Feinler, "Hostnames Server RFC 811, Network Information Center, SRI International, March 1982.

[2] [3]

[4]

[5] [6] [7] [8] . [9]

[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.

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 RFC 883

[Pa November Domain Names - Implementation and Specific

INDEX * usage A RDATA format byte order cache queue 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 QCLASS QTYPE queries (standard) recursive service RR format SOA RR Special domains TYPE WKS type RR : 6 : 3 . . . . . . . . . . . . . . . . . . . . . . .. 3

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. 091232,908
Examiner

Applic . : ;<<s) Hudetz et al.
GrouD Art Unit

Notice of Allowability

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
Qq The allowed claim(s) is/are 33-127

the amendment filed

on

05/03/00

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. 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). 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 approved by the examiner.
May 3. 2000

which has been

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) . q Notice of Draftsperson's Patent Drawing Review, PTO-948 q Notice of Informal Patent Application, PTO-152 q Interview Summary, PTO-413 q Examiner's Amendment/Comment q Examiner's Comment Regarding Requirement for Deposit of Biological Material q Examiner's Statement of Reasons for Allowance 8

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 i.t(1F•~{~ :1_IYrili~: :. j( :~I'f'v

li :iaiil :!

f•~N::~.:!~.I

'Yf :ff tl :

P'.I`f

:f. Ei a, t.- :r':
FILING DATE TOTAL CLAIMS EXAMINER AND GROUP ART UNIT DATE MAILED

APPLICATION NO.

First Named Applicant TITLE OF INVENTION :::• . .~ 1 ?Y .} I f: ;:.,'1

. i

Ea };:i .l..,

i . +a:f• t. {.—, l.pF FY

is i:'+°ffi I ' 11::;

+ir! ; 1: „

1 .4

(+r :1 ;'ic., ;.

'!

!',{F :: I f°If;lt :+

f' f._IF ,

h1i_L I!_!IYff-1 f :f. k.:

.

t
1_f..fMI"1..,11: :Fi CIV1, 1"< A IC: ;

<'lf. ::l::F::.•i9`:

..i. .laff

t

ATTY'S DOCKET NO .
4

CLASS-SUBCLASS
t+ :•

BATCH NO.
>t ;'= ,, iitiU f~1 :1 .

APPLN . TYPE
UT :[i.. ..

SMALL ENTITY

FEE DUE

DATE DUE
!:I ;j

c;la .... rl ;:, a. :'S

1"i0(1

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:
1 . Review the SMALL ENTITY status shown above . If the SMALL ENTITY is shown as YES, verify your 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 Trademark Office of the change in status, or B. If the status is the same, pay the FEE DUE shown above . If the SMALL ENTITY is shown as NO:

Y

A . Pay FEE DUE shown above, or 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•, Washington, D .C . 20231

This form should be used for transmitting the ISSUE FEE . Blocks' 1 through 4 should be completed where appropriate . All further correspondence including the Issue Fee Receipt, the Patent, advance orders and notification of maintenance fees will be mailed to the current correspondence address as indicated unless corrected below or directed otherwise in Block 1, by (a) specifying a new correspondence address ; and/or (b) indicating a separate "FEE ADDRESS" for maintenance fee notifications . CURRENT CORRESPONDENCE ADDRESS (Note : Legibly mark-up with any corrections or use Block 1)
MAILING INSTRUCTIONS:

Note : The certificate of mailing below can only be used for domestic mailings of the Issue Fee Transmittal . This certificate cannot be used for any other accompanying papers : Each additional paper, such as an assignment orformal drawing, must have Its own certificate of mailing.
Certificate of Mailing

! !-• -1 I~~!I'.i
..
1 f...i! ...!I{ i~ I"'..

.. '

:1

I:Fr•11"'.1• :, I„IiY1l::: . ;,

1 hereby certify that this Issue Fee Transmittal is being deposited with the United States Postal Service with sufficient postage for first class matl in an envelope addressed to the Box Issue Fee address above on the date Indicated below.

I :::. :':%! ;i

a

Q

to , o
I ' ... .

l:

I :':

i..1L ..J;:
1•~1y

a : l`•i!: i

al~N

2 1

`4 r

Linda Ga r r amo n e Jtane 20 ; 2000

(Depositor's name) (Signature)

!`%1'':trt :ji::;'i• .

1. !-! J.

APPLICATION NO .

FILING DATE

TOT _WMS

EXAMINER AND GROUP ART UNIT

(Date) DATE MAILED

First Named Applicant
! INVENTION

r !. .. . ;::r( ! 1 ::{ F::tl I ..{. . !:. 1 {rl ! .1 .!....;

c:'

i::•

r:
'!., Itj
I

:' . ::I''fl .::t .l
.

l.. .. !.,:!._Eft`II !'. .J I €:: :Iti

', .., "
.. . I''•.I€: ::: .f%: :I.,J

TITLE OF

!..:! .1_ :

AVER. 't .f:'

!

ATTY'S DOCKET NO. Y 0 1 . :: , I,! .. .. I..! .{. (? i

CLASS-SUBCLASS

BATCH NO .

APPLN. TYPE !`•{ .1. . 2 . i.• ( ..{ . .{. { .._ .{. 'i'

SMALL ENTITY ::.

FEE DUE r. " :?

DATE DUE

":? { I.1 ! _

1 . Change of correspondence address or Indication of " Fee Address" (37 CFR 1 .363) . Use of PTO form(s) and Customer Number are recommended, but not required . q Change of correspondence address (or Change of Correspondence Address form PTO/SB/122) attached . q "Fee Address" Indication (or "Fee Address" Indication form PTO/SB/47) attached .

2 . For printing on the patent front page, list (1) the names of up to 3 registered patent attorneys or agents OR, alternatively, (2) the name of a single firm (having as a member a registered attorney or agent) and the names of up to 2 registered patent attorneys or agents . If no name is listed, no name will be printed .

1 Greenberg Traurig, LLP 2 Anthony R . Bar]wtx= 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 q Advance Order - # of Copies filing an assignment . (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 assignee category 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 PTOL-85B (REV . 10-96) Approved for use through 06/30/99 . OMB 0651-0033 G d Patent and Trademark Office; U .S. DEPARTMENT OF COMMERCE I• 4 I I

UNITED STATES .D! ;ARTMENT OF COMMERCE Patent and Trademark Office
6 1ArE8 APPLICATION NO . FILING DATE Address : COMMISSIONER OF PATENTS AND TRADEMARKS Washington, D .C. 20231 FIRST NAMED INVENTOR ATTORNEY DOCKET NO.

1017 i=`i I'.L.L'I II1I~.I''~'
C iP"tI:-

1={

X :{F1U'tiI :1_11'''1[ : ..L. fiALA-Z I fl°i U .1 L ...1'! 7: 1'`•Il :i :1 . Cl :I,

:•:ai;(

~:

.. .

EXAMINER

., 1\Ih;I ::IR

MET I ._.1 f: 'E;:

ART UNIT

PAPER NUMBER

I\1E., 14 Y ('-'I F K N y

DATE MAILED :

Cl IpQf~

Please find below and/or attached an Office communication concerning this application or proceeding .
Commissioner of Patents and Trademarks

PTO-90C (Rev. 2/95) U .S. G .P .0 .2000 ;485-18B/25288

-

1- File Copy

I

~I

Application No. 091232,908

Applicant(s)

Hudez et al.
Group Art U 2183

11F~ce of A/lowabilifv
Pan

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 K

This communication is responsive to The allowed claim(s) is/are

the amendment filed on 0513100 and the Notice of Allow on 05131100

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. 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). 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 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 Notice of Informal Patent Application, PTO-152 q Interview Summary, PTO-413 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

May 3. 2000

which has been

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

I

TRANSMITTAL OF INFORMA0 URE STATEMENT (Under 37 QW 1997L9 M9 or 197(
In Re Application Of : Hudetz et aL
W i

Docket No. 150-061A

Serial No . 09n32,908

Filing Date January 15, 1999

Examiner Pan, D .

Group Art Unit 2783

Title :

SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK

Match & Retur"
Assistant Commissioner for Patents Washington, D .C . 20231

Addrq6119

F(EGENkU %
MAY 3 12000

37 CFR 117(b) 1 . Ll

OROUP

2700

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. 2. a Final Action under 37 . CFR 1 .113, or 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 the fee set forth in 37 CFR 1 .17(p) for submission of an Information Disclosure Statement 1 .97(c)` /2000 BliABTEW 00 29 :122 240 .00 OR

Copyright 1996 Legalsoft

P1 0A/REV01

TRANSMITTAL OF INFORMAT40N DISCLOSURE STATEMENT (Under 37 CFR 1.97(b) or 1 .97 c
In Re Application Of :

Docket. No.

150-061A

Hudetz et al.
,War

u~ z5 ti
Examiner Group Art Unit

Serial No .

Filing Date .

09/232,908

January 15, 1999

Pan, D.

2783

Title : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK

Payment of Fee
(Only complete if Applicant elects to pay the fee set forth in 37 CFR 1 .17(p))

MAY 3

t ?Q00 217,00

® q

A check in the amount of $240 .00 is attached . U . , ._ .- E 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 q q Charge the amount of Credit any overpayment. Charge any additional fee required.

Certificate of Transmission by Facsimile*
I certify that this document and authorization to charge deposit account is being facsimile transmitted to the United States Patent and Trademark Office (Fax. No . ) on (Date)

Certificate of Mailing by First Class Mail
I certify that this document and fee is being deposited on With the U .S . Postal Service as first 05/22/2000 class mail under 37 C .F .R. 1 .8 and is addressed to the Assistant Commissioner for Patents, Washington, D .C. 20231.

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 :
Signature

May

22,

2000

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 INFORMATION DISCLOSURE CITATION
(Use several sheets if necessary)

ATTY DOCKET NO . 150-061A APPLICANT(S) Hudetz et al. FILING DATE 01/15/99 U.S . PATENT DOCUMENTS

SERIAL NO. 09/232,908

GROUP J' 7$

*EXAMINER INITIAL

DOCUMENT NUMBER

DATE

NAME .

CLASS

SUBCLASS

FILING DATE IF APPROPRIATE

5,841,978

11/24/98

Rhoads

"MAY ?~

k``

MAY 3 1 GROU

2000
2?0

FOREIGN PATENT DOCUMENTS
DOCUMENT NUMBER DATE COUNTRY CLASS SUBCLASS TRANSLATION YES NO

OTHER DOCUMENTS

(Including . Author, Title, Date, Pertinent Pages, Etc .)

EXAMINER `EXAMINER : Initial if reference considere considered . Include copy of this form wi Form PTO-A820 (also form PTO-1449)

DATE CONSIDERE

ether or not citation is in conformance with MPEP 609 ; Draw Ii ext communication to applicant .
P09C/REV03

rough citation if not in conformance and not

Patent and Trademark Office • U .S. DEPARTMENT OF COMMERCE

PAGE 1

OF 1

Q

's

-

* tw OF CO .

UNITED "STATES DEPARTMENT OF COMMERCE
Patent and Trademark Office
Address: COMMISSIONER OF PATENTS AND TRADEMARKS Washington, D.C . 20231

~~~res eF APPLICATION NO .
I_'_i ,., ..

FILING DATE
_.

FIRST NAMED INVENTOR

W

y; TT

.. DOCKET NO.

f lYl :"c: :l. / 1.! 9 . :{. 1) Al ME: 11011Y FR B(.)R[*" UIYIE ESfA GREE::NBER1:7 "rRf-11_ R I G.'i LIFE IL{I_! I I_DT I K'i

EXAMINER

)RI T UNIT

PAPER NUMBER

201:1 FAF K AVENUE NE M Y01-ti NY 1r_1166

C! :LI1/f11~
DATE MAILED:

Please find below and/or attached an Office communication concerning this application or proceeding .
Commissioner of Patents and Trademarks

PTO-90C (Rev. 2/95) U .S. G .P.O. 2000 ; 465-188/25268

's,

Interview Summary

Application No. 091232,908 Examiner Pan

Applicant(s) Hudetz et al. Group Art Unit 2183

All participants (applicant, applicant's representative, PTO personnel): (1) Pan
(2) Barkume

(3) (4) Jan 16. 2001 personal (copy is given to [D3s a4licant a Vicant's representative).

Date of Interview Type : nelephonic

Exhibit shown or demonstration conducted :

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 .
PRI Y ER

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
TRANSMITTAL OF FORMAL DRAWINGS
(In Response to Notice of Informal Drawings) In Re Application Of :

lm Y

3 0/y
1 ~y

Docket N

150-061A

Hudetz et al.
Filing Date Batch No .

~ eKp
R
Examiner Art Unit

Serial No .

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:

Assistant Commissioner for Patents Washington, D.C. 20231

In response to the NOTICE OF INFORMAL DRAWINGS mailed on (a)

11/29/99
(date)

attached please find:

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/
Signature

Dated : June

15,

2000

AnZony IL Barkume, Esq., Greenberg Traurig, LLP Met Life Building 200 Park Avenue New York, NY 10166 (212) 801-9294

certify that this document and attached drawings are being 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 to the Assistant Commissioner for Patents, Washington, D .C. 20231 . i
I

Signature of Pe son

ailing Correspondence

Linda Garramone
Typed or Printed Name ofPerson Mailing Correspondence
P23A/REV01

BASE

PROVIDER 50 32 36 MODEM
40'

""

NLMOTE

NODE

26

~-I LOCAL L ( HOST

RAM

48 ARTICLE 46

I

34

DATA/ADDRESS BUS 42 38

I
I

► I

i

I

CPU

30

1/0 PORT

INPUT DEVICE 44

52 36. 28 54 Illlllllllillllllll ® 44 46
soup
Ihp

FIG. 2
50

48

D®tea, 90~ FIG. 5
80 48 82 6
01 73568 " 41254 1111 . 2

LOAD BROWSER SOFTWARE

LOAD QUERRY PAGE

84

0

ENTER UPC PRODUCT ID NUMBER

86 A B

LOOK UP UPC CODE

a8

RETURN- MATCHING RECORDS

90

DISPLAY RESULTS

92

FIG. 4
70> 72, ~ 60. ~74 URL

LOAD DESIRED ADDRESS ~76

UPC-A 62-\ 31251 64 66 — 6831251 31251 4205

UPC-B 00301 00302 00400 L-78

DESC sou giveaway milk cars

sample .soup.com/subfile/Inddx .htmi sample,s .oup .com/promotion/maln .htmi test.mllk .org cars.com/testdrive%main .htmi

96. 98 100

FIG. 7
112

~

illl p

108

-%///// 110

_j

7

REMOTE SERVER

SERVICE . PROVIDER

224

ZZ 8

2210

Z/o

222 234
2/Io

236

MODEM

2~¢

DOCUMENT

212

COMPUTER

~

232

~

BAR CODE READER
Z/B ~220

h

Sample c wtivy~, co

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 .~

..

MGN 1 $

NOVICE OF 4DRAFTSPERSON'S, % PAT'EI4T DRAWING RI~Vf Wh

' sert date) re: The drawing 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: Black ink . Color. Color drawings are not acceptable until petiton is , granted. Fig(s) Pencil and non black ink not permitted. Fig(s) 2. PHOTOGRAPHS . 37 CFR 1 .84 (b) _ 1 full-tone set is required . Fig(s) — Photographs not properly mounted (must use brystol board or photographic double-weight paper). Fig(s) _ Poor quality (half-tone) . Fig(s) 3. TYPE OF PAPER . 37 CFR 1 .84(e) _ Paper not flexible, strong, white ; and durable. Fig(s) Erasures, alterations, overwrilings, interlineations, folds, copy machine marks not accepted . Fig($) _ Mylar, velum paper is not acceptable (too thin). Fig(s) 4. SIZE OF PAPER. 37 CFR 1 .84(0: Acceptable sizes: 21 .0 cm by 29 .7 cm (DIN size A4) 21 .6 cm by 27 .9 cm (8 1/2 x I I inches) — All drawing sheets not the same size. — Sheet(s) Drawings sheets not an acceptable size . Fig(s) 5. MARGINS . 37 CFR 1.84(8) : Acceptable margins: Top 2 .5 em Left 2 .5cm Right 1 .5 cm Bottom 1 .0 em SIZE : A4 Size Top 2 .5 cm Left 2 .5 cm~ Right 1 .5 cm Bottom 1,0 cm SIZE: 8 1/2 x 11, 1 Margins not acceptabl Fig ) ( Top (T) ft L) "] — Right (R) 7^ Bottom (B) 6. VIEWS. 37 CFR 1 .84(h) REMINDER : Specification may require revision to correspond to drawing changes. Partial views . 37 CFR 1 .84(h)(2) _Brackets needed to show figure as one entity. Fig(s) _ Views not labeled separately or properly. Fig(s) Enlarged view not labeled separetely or properly. Fig(s) 7. SECTIONAL VIEWS . 37 CFR 1 .84 (h)(3) Hatching not indicated for sectional portions of an object. Fig(s) Sectional designation should be noted with Arabic or — Roman numbers . Fig(s)

` 8. ' ARI2ANGEMENT' OF VIEWS . 37 CFR 1 .84(1)`
Word's do nbttappear on.a horizontal ; left; to, right ,fashion when page is either, upright or turned so that the top . become§ the right side, except for graphs . Fig(s) 9. SCALE. 37 CFR 1 .84(k) _ Scale not large enough to show mechanism without crowding when drawing is reduced in size to two-thirds in reproduction. Fig(s) ' . 10. CHARACTER OF LINES, NUMBERS, & LETTERS. 37 SFR 1 .84(1) ~" Lines ;,. numbers &letters notuniformiy thick and well defined, cl an, dut Je, and black (poor line quality).

Fig(s)
11. SHADING . 37 FR 1 .8 (m) t Solid black areas pale . Fig(s) Solid black shading not permitted . Figs) _ Shade lines ; pale, rbugh d and'blurr6d. Fig(s) 12. NUMBERS, LETTERS, & REFERENCE CHARACTERS. 37 CFR 1 .84(p) _ Numbers and reference characters not plain'and legible: Fig(s) Figure legends are poor . Fig(s) — Numbers and reference characters not oriented in the same,direction .as .the , view..• 37 CFR . 1.84(p)(1) Fig(s) English alphabet not used . 37 CFR 1 .84(p)(2) — Figs — Numbers, letters and reference characters must be at least .32 cm (1/8 inch) in height. 37 CFR 1 .94(p)(3) Fig(s) 13. LEAD LINES . 37 CFR 1 .84(q) _ Lead lines cross each other. Fig(s) — Lead lines missing. Fig(s) 14. NUMBERING OF SHEETS OF DRAWINGS . 37 CFR 1 .84(t) Sheets not numbered consecutively, and in Arabic numerals beginning with number 1 . Sheet(s) 15. NUMBERING OF VIEWS . 37 CFR 1 .84(u) _ Views not numbered consecutively, and in Arabic numerals, beginning with number 1 . Fig(s) 16. CORRECTIONS. 37 CFR 1 .84(w) — Corrections not made from prior PTO-948 dated 17. DESIGN DRAWINGS . 37 CFR 1 .152 _ Surface shading shown aot-appropriate . Fig(s) Solid black shading not used for color contrast. Fig(s)

f

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 Washington, D .C . 20231

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