00870-prosecution history

8/14/2019 00870-prosecution history

http://slidepdf.com/reader/full/00870-prosecution-history 1/199

~Q~~ ~ ~

N~N

~

U _

•

LL

V 1N stn cn

%p-0

r o uC0

Ui

8199046

6199048

PATENT NUMBER,

SECTOR CLASS SUBCLASS ART UNIT EXAMINER7

FILED WITH : UISK (CRF) "FICHE

i ~ .~ (Attached in pocket on right inside f lap)

I PREPARED AND APPROVED FOR ISSUE,!

ISSUING CLASSIFICATION1

ORIGINAL CROSS R IRENCE(S)

CLASS SUBCLASS CLASS SUBCLAS , ONE SUBCLASS PER BLOCK)

INTERNATIONAL CLASSIFICATION 3J ~~Z, of % r J Z , U

6 1 1 - 0-

6 (e

q C ont inued on Issue S l ip Inside Fi le Jacket

TERMINAL DRAWINGS CLAIMS ALLOWED

DISCLAIMERSheets Drwgr Figs .DrW§'. min i[`g . Total Claims ti>° Print ClaiKfor O .G .

q a) The term of th is patent NOTICE OF ALLOWANCE MAILED

subsequen t to (date) -__-as been d isc la imed . (Assis tant Examiner) (D ate) ^

q b) The term of th is patent shal lDANIEL H. PM

not extend beyond the ex pirat ion date,PRIMARY uePefS INER

of U .S Patent . N o .fjR ()p

ISSUE FEE

Amount Dille Date Paid

xaminer) (bate)

q c) The terminal months ofISSU&BATCH NUMBER

th is patent have been d isc la imed .(Legal Inst ruments Examiner) (Date)

WARNING:

The information disclosed herein may be restricted . Unauthorized disclosure may be prohibited by the United States Code Title 35, Sections 122, 18 1 and 3 68.Possession outside the U .S . Patent & Trademark O ffice Is restricted to authorized employees and contractors only .

Form PTO-436A(RIk s/98)

v + r o .zl I f " ' r..n,exol~erew ~(LABEL AREA)

' ~ . .,__(FACE)

NQ1wVFVIFS e



jan . S PT6

~ 1 I N I T I A L S

..,PATENT APP OCAtIONN 01/15/ 99

CONTEWS09232908 ~ e c e i v e d D a t e r e c e i v e d.

( I n c l . C. o f M .)o r

D a t e M a i le d D a t e M a i le d

1. Appl icat ion papers 41

2 . 4 3 .

3. 4 4 .

2 rn d5 (1 G ~~ 4 5 .

cOd5 . 2ev 1 6 .C w *4

6'

—

5"6b . 4 2 ) 4 7 ..

7. 4 8./

8. 4

0 .

O y . cyo 5 1 .

050460 5 2 .

5 3 .2 .

M 3 5 4 .

~~~~~?ds°~1~iII - F 5 5 .

1 5 .

-6 .

16.— 5 7 .

17.— 5 8 .

18.— 5 9 .

19. 6 0 .

20. 61-

2 1. 6 2 .

2 2 . 6 3 .

i 2 3 . 6 4 .

62 4 . 6 5 .

6 6 .2 5 .26. 6 7 .

27. 6 8 .2 8.

-

6 9 .

2 9. 7 0 .

30.7 1 .

3 1 7 2 .

3 2 . 7 3 .

' i 3 3 . 7 4 .

I W 7 5 .

3 5 .— 7 6 .

3 6 . 7 7 .

3 7 . 7 8 .

3 0 7 9 .3 0 . 8 0 .

4 0 . - 8 1 .

4 1 . 8 2 .

( L E F T O U T S I D E )



ISSUE SLIP STAPLE AREA (for addidenal cross reference j

POSITION INITIALS i lk ' ~ d l ~ . DATE

FEE DETERM INATION

O .I .P .E . CLASSIFIER

FORMALITY REVIEW

.1

Claim Date

r, I • ciL

~

i l m lI IMJ

v

V

i G

1

V

2

-

I

3

4

1

1

1 I 1

A J

W

.

1

1

1

1 , 1 1 1 9 1

0

1

2

3 111 1

2

20 1 1 111

1 1 2 V I

A2P 1 J _

H _ ~

Alh 1 .11

3

f 3 I , —Z

3411 -- I3 3 5

3 6

G 37 1 1 1

r 383 9 \.

40

41

JO 4 2

1143

T2 _ 44> 45

x - 46

47

48

1 4 9 .\

~ ' 5 0

INDEX OF CLAIMS

Claim Date

rnit O ~.

Ip 5 1 ~~

C ) 5 2

1 5 3

2 2 5 4 .\3 5 5

2 ,4 1 5 6 — \

Z ~ 5 7

Z 58

` 7 5 9

'Z,T 6 0 1 11

Z 61 ~\. 13 0 6 2 \

s 6 3

.3 1 6 43 6 5

3f ~ 66

37 6 9

3 70 ~.

71 \\41 72

Yz 73 -(Pte 74

16wool

6 6

C la im Date

4(j 75

401764S 77

J 78,4 , 77911

65 BO -'

41 81

• 8211 1 — , I

f 8 3

S Z 8 4

S3 8 5

8 6 ~.

8 7

- 6 8 8 ~ .8 9

s 90

S " 9 1

6 1 ) 9 2

ii O

1 0 1.'1

qI2 X04

O f i 10 5

'1 ,4 1 0 6 1

1 07 `

1 06 ~; -f :t 1 0 9 _

i) ^ 1 0s i ~ 1 1 1 ~ _

y o 11 2 _

11 3

1 1 41151 1

11 6

Yfll17

~6 116 ~ .~

a' 1 19

2 0 ,

12 1

% 112211

91 1 41Z 12 4

_ ~ 12 5

9~1 27

128

.

29

3 0

. 1 3 1 1 1

3

3131 1

131 1

131 1

1311

1 3 8 1 11 3 9 1 140

14 1 _

14

14

1 4 A I I

45

46

4

4

14

_11 5 0 1

ejected Non-elected

_l lowed Interference

(Through numeral) . . . Canceled Appeal

-estricted 0bjected

If more than 150 claims or 10 actions

staple additional sheet here

(LEFT INSIDE)



SEARCHED

C l a s s S u b . r D a t e E x m r .

~ t ~ 0 ~ Z L ~ O ,

1 - 74

INTERFERENCE SEARCHED

(loss S 6 b . D a t e E x m r .

vr-

----------- - --------

(R IGHT O UTSIDE)lk



PATENT APPLICATION SERIAL NO.

U .S . DEPARTMENT OF COMMERCE

PATENT AND TRADEMARK OFFICE

FEE' RECORD SHEET

0 1 / 2 6 /1 9 9 9 H V I L L A R I 0 0 0 0 0 0 4 5 0 9 2 3 2 9 0 9

01 M201 3 8 0 . 0 0 O P

PTO-1556

(5/87)

*U .S . G P O : 1998-433.214/80404



S E R I A L N U M B E R F I L I N G D A T E CLASS G R O U P A R T U N I T A T T O R N E Y D O C K E T N O .

09/232,908 01/15/99 395 2756 150–061A

FRANK C . HUDETZ, LISLE,,IL ; PETER . R . HUDETZ, PLAINFIELD, I L ,

rL- a .Q

**CONTINUING DOMESTIC DATA*********************/

VERIFIED THIS APPLN IS A DIV OF 08538,365 10/03/95

PROVISIONAL APPLIQAfiION NO . 60/000,442 06/20/95

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

VERIFIED

o e I

**FOREIGN APPLICATIONS*******~+***

I

! VERIF

I

I

,

ElD ~f

f

FOREIGN FILING LICENSE GRANTED 02/08/ . 9 9 ***** SMALL ENTITY *****

F o r e i g n P r io r i ty c l a im e d q y e s n o 10.1 1

35 USC 119 (a-d) conditions met [ dy e s [ g4 S o q MeWfter AllowanceS T A T E O RC O U N T R Y

S H E E T SD R A W I N G

T O T A L ~ I. I ( g D E P E N D E N TC L A I M S i CLAIMS

V e y ified and Acknowledged gi" ' y IL 3 11 1

ANTHONY R B KUME f ~ ~ (V 1 4 E

ILj

14 SOUTH IN STREETGZee.4E SUITE 2 0 f4~ I '

SAYVI E NY 11782 CA*Qi+ ~U t t~ iq ~

Ja'tiV ~r' c ~ f ' ♦ {P.. Y o m / t l

YSTEM & M E T H O D FO R y ~ " - A

u a R , i ;MOTE COMPUTER e r r a ,rL i ) r3 '"

F=_

F I L IN G F E E ,R E C E I V E D E] Al l Fees

FEES : Au thor i ty has bee n g iven in Paper ~~ .1 .18 Fees (F i .r; ~ )No . t o cha rge/c red it DEPO SIT ACC O UNT

q1 . 17 Fees ;Process ing ext . of time)

$380 NO . for the following : q 1 .18 Fees ( Issue )q O the rq Cred i t



P T O / S B / 05 ( 4 /9 8 )A p p r o v e d f o r u s e t h r o u g h 0 9 / 3 0 /2 0 0 0 . O M B 0 6 5 1 - 0 0 3 2

P a t e n t a n d T r a d e m a r k O f f ic e : U . S . D E P A R T M E N T O F C O M M E R C Ee d t o r e o d t o a c o l le c t i o n o f i n fo r m a t i o n u n le s s i t d i s la s a v a l id O M B c o n t r o l n u m b e r .

Attorney Docket No . 150-061AFirst Inventor or Application Identifle Frank C . H u d e t z

i-Title See 1 in Add endum

b)) Express Mail Label No .EG131043525US m

APPLICATION ELEMENTS 7Assistant C ommissioner for Patents

ADDRESS TO : Box P atent Appl icationS e e M P E P c h a p t e r 6 0 0 c o n c e rn i n g u t i l it y p a t e n t app l i ca t ion c o n t e n t s . fmn nr- gr i g ni

*Fee Transmittal Form (e .g . , PTO/SB/17) 5 .qicrofiche C omputer Program (Appendix) U' ( S u b m i t a n or ig ina l and a d u p l i ca t e fo r f ee p rocess ing) r,

6 . Nucleotide and/or Amino Acid Sequence Submission2 .~pecification [ T o t a l P a g e s ]( p re fer red a r rangem en t se t f o r th be low) 24 (if applicable, all necessary)

- Descript ive t it le of the Invention a . ~ Computer Readable Copy

- C ross References to Related Applications b . F Paper C opy (identical to computer copy)- Statement Regarding Fed spon sored R & D

- Reference to Microfiche Appendix C .0

tatement veri fying identi ty of above cop ies

- Background of the Invention ACCOMPANYING APPLICATION PARTS- Brief Summ ary of the Invention

7 . ~ Ass ignment Papers (cover sheet & document (s) )- Brief Description of the Drawings (if filed)

- Detai led D escr ipt ion B ~ 37 C.F . R .§3 .73(b) Sta tem ent Power o f(when there is an assignee) Attorney

- C laim(s)9 .F--] Engl ish Translat ion Docu ment (if applicable)

- Abst ract of the D isc losure

3 . Drawing(s) (35 U .S . C . 113 ) [ T o ta l S h e e t sInformation Disclosure C opies of IDS

X 3 '' 1 1 0 • 1 :1 Statement ( IDS) /PTO-1449 OCitations

4 . O ath or Declaration [ T o ta l P a g e s ] 1 1 . F K ] Preliminary Amendment

a . F1Newly executed (original or copy)

12 ® Return Rece ip t Postcard (MPEP 503)(Should be specifically i t e m i z e d )

b X C opy from a prior appl ication (37 C .F .R . § 1 .63(d)) • Small Entity prior

q( for cont inua t iorVdlvis ional w i t h B o x 16 completed) Statement fi led i application

1 3 . ~ Statement(s) ~r

desiredtatus still proper and desiredi qE L E T IO N O F IN V E N T O R ( S ) (PTO/SB/09-12)Signed statement attached deleting qerti f ied C opy of Priori ty Document(s)

4 'nventor(s) named in the prior application, (i f foreign priority is claimed)

see 37 C .F .R . §§ 1 .63(d)(2) and 1 .33(b) . 5 .

qOther :

:T E :FOR :I. EMS:1 :&:1af ORD R:TOB £NTT O : O .A .'L: N r- . ::P'. :FEES,iA : MAELENTT:L V . ..TAT EI4IENTLS~REL3UJR EOi ( 37GFi Ri ,§1: ~7f i : EXCEPT : :i.. . . . . . .iF N

.,FL:E . :1 .A :p L G I6 . If a CO NTINUING APPLICATIO N, check approp r iate box, and supply the requis i te informat ion below and in a prel iminary amendment:

C on t in u a t io n D iv is io n a l ElContinuation-in-part (CIP) o f p r i o r a p p l i c a t io n N o : 08/538,365

Pr io r app l i ca tion in f o rma t ion : E x a m i n e r D . P a n Group/Art U n i t : 2 7 8 3

F o r C O N T I N U A T I O N o r D I V IS I O N A L A P P S o n l y : T h e e n t ir e d i s c lo s u r e of t h e p r i o r a p p l i c a t io n , f r o m w h i c h a n o a t h o r d e c l a r a t io n is s u p p l i e dunder Box 4 b , is considered a part of the disclosure of the accompanying continuation o r divisional application and is hereby incorporated byreference. The incorporation can only be relied upon when a p ortion has been inadvertently omitted from the submitted application parts.

1 7 . CORRESPONDENCE ADDRESS

0 C ustomer Number or Bar Code Labe I ; or 0or respondence address b e l o w

: (in s e r t C u s t o m e r N o : o r A t t a c h 'b a r c o d e l a b e l h e r e

Anthony R . BarkumeN a m e

lAnthony R . Barkum e, P .C .

14 South Main_Stre et Suite 200A d d r e s s

city S a ll e S t a t e NY Zi p C o d e 11782

C o u n t r y T e l e p h o n e (516) 244-3503 Fa x (516)244-7645

N a m e ( P r in H T y p e ) An o . Barkume Registrat ion No .(Aitorney/Agent) 33,831

Ls i g natu re D a t e 1 — S — ,IB u r d e n H o u r S t a te m e n t : is o s st im ate d t o la ke 0 . 2 h o u r s t o c o m p l e t e . T im e w i ll v a r y d e p e n d i n g u p o n t h e n e e d s o f t h e i n d iv id u a l c a s e . Anyc o m m e n t s o n th e a m o u n t o f i t u a r e r e q u i r e d t o c o m p l e t e t h i s fo r m s h o u l d b e s e n t to t h e C h i e f I n fo r m a t i o n O f fi ce r , P a t e n t a n d T r a d e m a r k O f fi ce ,W a s h i n g to n , D C 2 0 2 3 1 . D O N O T S E N D F E E S O R . C O M P L E T E D F O R M S T O T H I S A D D R E S S . S E N D T O : A s s i s t a n t C o m m i s s io n e r f o r P a t e n t s ,B o x P a t e n t A p p l ic a t io n , W a s h i n g to n , D C 2 0 2 3 1 .

P l e a s e t y p e a p l u s s i g n ( + ) i n s id e t h i s b o x - ~ -

OtO V n d e r t h e P a e r w o r k R e d u c t i o A c t o f 1 9 9 5 n o e r s o n s a r e

1•-~ =TT

=_[ UTILITY

PATENT APPLICATION

TRANSMITTALOnly f o r new nonprov is iona l app l i ca t ions u nd er37 C .F .R . §



PTO/SB/17 (2/98)App- . r use through 9/301 200 0 . OMB 0651-003 2

Patent and Traderrrd iK office : U .S . DEPARTMENT OF C OMMERC EUnderthe Paperwork Reduction Act of 1995, no persons are requ ired to respond to a collection of information unless it displays a valid O MB control number.

FEE TRANSMITTALPatent fees are subject to annu a l rev i s ion on October 1 .

T h e s e a r e t h e f e e s effective O c t o b e r 1 , 1 9 9 7 .Sma l l En t i t y paymen t s must be s u p p o r t e d by a sm e l l en t it y statement,otherwise large enti ty fees must be p a i d . See Forms PT O/ SB / 0 9-12 .

S e e 3 7 C.F.R

. §§ 1 . 2 7 a n d 1 .2 8 .

Complete if Known

Application Number

Flung Da te January 15, 1999

Firs t Named Inven tor Frank C . Hudetz

Examiner Name D . Pan

Grou p / Art Uni t 2302

T O T A L A M O UNT O F PA Y M ENT ( $ ) 380 .00 AttomeyDocketNo . 150-061A

METHOD OF PAYMENT (check one) FEE CALCULATION (continued)

The Commissioner is hereby authorized to charge1 ~indicated tees and credit any over paymen ts to:

DepositAccountNumber

L ADDITIONAL FEESL a r g e . E n t i t y S m a l l E n t i t yF e e F e e F e e F e e Fee Descript ion

C o d e ($ ) C o d e ($ )

1 0 5 1 3 0 2 0 5 6 5 Surcharge - late filing fee or oath

1 2 7 5 0 2 2 7 2 5 Surcharge - late provisional f iling fee orcover sheet.

1 3 9 1 3 0 1 3 9 1 3 0 Non-English spe cif ication

1 4 7 2 , 5 2 0 1 4 7 2 , 5 2 0 For filing a request for reexamination

1 1 2 9 2 0 '1122 0 ' E x a m m e ~ r a d i o n li c a t io n o f S I R p r i o r t op

1 1 3 1 , 8 4 0 ' 1 1 3 1 , 8 4 0 * Requesting publication of SIR afterExaminer action

1 1 5 1 1 0 _ 2 1 5 55 Extension for reply within first month

1 1 6 4 0 0 2 1 6 2 0 0 Extension for reply within second month

1 1 7 9 5 0 2 1 7 4 7 5 Extension for reply within third month

1 1 8 1 , 5 1 0 2 1 8 7 5 5 Extension for reply within fourth month

1 2 8 2 , 0 6 0 22 8 1 , 0 3 0 Extension for reply within fifth month

1 1 9 3 1 0 2 1 9 1 5 5 Notice of Appeal

1 2 0 3 1 0 2 2 0 1 5 5 Filing a brief in support of an appeal

1 2 1 2 7 0 2 2 1 1 3 5 R e q u e s t fo r o r a l h e a r in g

1 3 8 1 , 5 1 0 1 3 8 1 , 5 1 0 Petition to institute a public use proceeding

1 4 0 1 1 0 2 4 0 5 5 Petition to revive - unavoidable

1 4 1 1 , 3 2 0 2 4 1 6 6 0 Petition to revive - unintentional

1 4 2 1 , 3 2 0 2 4 2 6 6 0 Utility issue fee (or reissue)

1 4 3 4 5 0 2 4 3 2 2 5 Design issue fee1 4 4 6 7 0 2 4 4 3 3 5 Plant issue fee

1 2 2 1 3 0 1 2 2 1 3 0 Petitions to the C ommissioner

1 2 3 50 1 2 3 50 Petitions related to provisional applications

1 2 6 2 4 0 1 2 6 2 4 0 Submission of Information Disclosure Stmt

5 8 1 40 5 8 1 40 Recording each patent assignment per

property (times number of properties)

1 4 6 7 9 0 2 4 6 3 9 5 Filing a su bmission after final rejection( 3 7 C F R 1 . 1 2 9 ( a ) )

1 4 9 7 9 0 2 4 9 3 9 5 For each additional invention to beexamined (37 CF R 1 .129(b))

Other fee (specify)

O ther fee (specify)

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

Fee Paid

0 .00

DepositA c c o u n tName

C h a r g e A n y A d d i t io n a l FJ C h a r g e t h e I s s u e F e e S e t i nFee Required Under 3 7 C .F .R . § 1 . 1 8 a t t h e . M a i l i n g3 7 C .F .R . § § 1 . 1 6 a n d 1 .1 7 o f t h e N o t i c e o f A l lo w a n c e

0 .00

0 .00

0 .0

0 .002

MPayment Enclosed :

Money qCheck Order Other 0 .00

0 .0 0FEE CALCULATION 0 .00

1 . BASIC FILING FEE

Large Entity Small EntityF e e F e e F e e F e e F e e D e s c r i p t io n Fee PaidC o d e ($ ) C o d e ($ )

1 0 1 7 9 0 2 0 1 3 9 5 U t i l it y f i l in g f e e 38 0 .0 0

1 0 6 3 3 0 2 0 6 1 6 5 D e s i g n f il in g f e e

1 0 7 5 4 0 2 0 7 2 7 0 P l a n t f i l in g fe e

1 0 8 7 9 0 2 0 8 3 9 5 Reissue fling fee

1 1 4 1 5 0 2 1 4 75 P r o v i s i o n a l f il in g f e e

SUBTOTAL (1) ( $ ) 380 .00

0 .00

0 .00

0 .00

0 .0 0

0 .00

0 .00

0 .0 0

2 . EXTRA CLAIM FEESF e e f r o m

Extra Claims below Fee PaidTotal C la ims 11 -2 0 *' = 0= X0--=I n d e p e n d e n t _ 3 * * = F_ _ _ J X 39 =0~C l a i m s -ultiple Dependent =0

or number previously paid, if greater; F o r Re issu es, see be low

L a r g e Entity Small E n t i t yF e e F e e F e e Fee Fee Descrip tionCode ($ ) Code ($ )

1 0 3 22 2 0 3 1 1 C l a i m s i n e x c e s s o f 2 0

1 0 2 82 2 0 2 4 1 I n de p e n d e n t c la i m s in e x c e s s o f 3

1 0 4 2 7 0 2 0 4 1 3 5 Multiple dependent claim, if not paid

1 0 9 82 2 0 9 4 1 ** Reissue independent claimsover original patent

1 1 0 22 2 1 0 1 1 * * R e i s s u e c l a im s i n e x c e s s o f 2 0a n d o v e r o r i g in a l p a t e n t

SUBTOTAL (2) ($ ) 0 .00

0 .0 0

0 .0 00

0 .0 0

0 .00

0 ' 00

0 .0 0

0 .00

0 .00

0 . 0 0

0 .00

SUBMITTED BY C omplete (i f appl icable)

TypedorPrinted Name Anthori R. Barkume

Re g . Number33,831

Signature Da teDepos i t Accoun tUser ID

Burden Hour Statement : T is luonV is estima ted to ta ke 0 .2 hours to complete . Time wi ll vary depending up on the needs of the individual case . Anycomments on the amount of t ime you are requ ired to complete this form should be sent to the C hief Information Off icer, Patent and Trademark O ff ice,W ash ing ton , DC 2 0231 . DO NO T SEND FEES OR CO MPLETED FORMS TO THIS ADDRESS . SEND TO : Assistant Commissioner for Patents,Washington, DC 2023 1.



PatentAttorney-Docket-

/5 -0 - 0 6 1 A

5

SYSTEM. AND METH OD FOR USING; AN ORDINARY.

ARTICLE OF' COMMERCE TO ACCESS A . REMOTE COXPUTER.

Related Applicati on Data

1 0 T hi s a ppli ca t io n i s

/ Application Serial Number 60\000,442, . fi led on:June 20,.

1995, and entitled . "Meth od and .Appar~Ltus for Interfacing.

with .Remote Computers" (hereinafter, "our copending

appli cation"), the di sclosure of which i s hereby

15 incorporated.by reference in its-entiret y . .

Field of the Invention

; a This invention relat es to computer communications

generally, and more specifically t o techniques for. givingF_

r ' 20 users convenient access to informat ion locat ed 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 c an be vi ewed as a set of nodes or

"sites", with each.computer on the network being home for

one or more nodes . Generally speaking, each hos t . i s

assigned a numeric address, which . t he n et wo rk us es t o ro ut e

30 information to that particular host . To f a ci li t at e h uma n

use of networks, . addresses are often given alphanumeric

codes (or "mnemonics"), which ar e easier for people.t o

remember . . . For example, the numeric .address 200 .98 . . 3 2 2 .56

may be assigned the mnemonic "sample .com . . "

35 At the present . time, t he 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 pr ot o co ls k no wn



Y

as TCP/IP . Many sites on the Internet c an 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 t o users'

computers (or "clients") in accorda nce with a particularformat or protocol . The client system (often a n

individual's personal computer) must ha ve the necessary

software to ha ndle the server's particular protocol.

For example, sites set up in accordance with HTTP ar e

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

with the HTTP protocol . Such software is often called a

"browser," because it allows users to browse (or, in theparlance of the enthusiasts, "surf") from Web site to Web

site, much the way one might browse through a library . This

process is facilita ted by the fact tha t most Web sites have

hypertext links to ot her Web sites, which the user can

act ivate by clicking a mouse on a highlighted portion of t he

20 screen.

Typical.browser software also maintains a list of sites

the user has visited, which the user can reca ll using

commands such as "back" a nd "forward ." These commands,coupled with the hypertext links between Web sites, give

users the sensat ion of "navigating" through a seemingly

infinite realm of information, which is popularly referred

to a s "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").

The URL specifies the precise location of a pa rticular

resource, and has t hree fields:

<resource type> <domain name> <path>Domain name, as explained above, is the alphanumeric network

address of the hos t on whi ch a particular resource resi des.

3 5 ,. The "path" i s the speci fic directory and file on the host -

2

J

5

1 0

15

25

3 . 0



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



5

10

15

20

25

30

35

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 . . Th e problem i s

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.

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

locations without having to manually enter the published

address . In accordance with one embodiment of the

invention, the mnemonic address or verbal description of a

network location is published along with the location's

numeric address in bar code format . The user's computer is

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

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

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

format) requires manufacturers to redesign products,

packaging and/or advertisements, and many manufacturers may

4



a

r t

be reluctant to do this . Third, pervious pr oposa l, if t he

network address is changed, the . .package needs to be

redesigned, and packages alrea dy in the ma r ke tpla c e wi ll

have incorrect address information.

5

Summary of the Invention

The present invention offers a bett er way for consumers

and others t o access resources on remote comp~eSrps~~

particularly Web sites . In accordance with the invention,

10 the dissemination a nd entry of net work addresses is

accomplished by means of existing identificat ion standa rds

( 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 t he invention is a system in which a

bar code or other indicia is associat ed with a product or

other ar ticle of commerce . The indicia encodes (in human

and/or machine readable form) a UPC or other identification

number, which is associated with the art icle in accordance

20 with an extrinsic standard . A computer da t a ba se is p rovided

that relates standard UPC codes to Internet URLs or other

network a ddresses . To access a network resource relating to

a particular product, the user swipes, a ba r c ode r ea de racross the product's UPC symbol . . The data base then ret rieves

25 the URL corresponding to the UPC product dat a . This

location information is then used to access the desired

5 ~---,resource on the network . -

The i nventi on offers a number of important advantages.

Firs t, because product identi ficati on informati on is already

30 wi dely dis seminat ed using st andardized and pre-assig ned

codes, the invention eliminates the need for separately

disseminating domain names or other network locati on data.Further, the invention can be-implemented without - requiring

manufactures to redesign packaging or other articles, or to

35^ develop speci al bar code i ndici a . Thi s overcomes a Catch-2 2

often facing new technologi es : manufacturers will not



5

10

15

20

25

30

participa te until t here is widespread consumer interest;

consumers are not interest ed until there is widespread

manufacturer par ticipation . With the invention, mass

participation by manufacturers in the technology is

automatic.

Second, the invention a llows practica l use of bar codes

and other machine reada ble media for entry of network

location data . As-we realized, encoding URL data in bar

code format is not pra ctica l 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 co mparable technology for

entering network location data . Thus, the necessity of

manually entering the a ddress is eliminated . Users can

access a desired site by simply using a bar code reader . .

The UPC c a n a lso be print ed on remov a ble st ic ke rs o r

detachable cards, allowing users to readily clip the

stickers and cards for future reference . This is

part icularly useful when the user reads a bo ut t he lo ca t io n

at a t ime when he does not have a c ce ss t o a c omput er .

Third, the invention o ver co mes t he 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 t o unilat erally change a company's

address . Finally, unforeseen trademark conflicts ( involving

for example Internet domain names) may require adoption of

new addresses . With t he invention, a new address assignment

requires only that the database of addresses be updated.

Products, packaging, advertisements and the like bearing the

standar d identificat ion codes need not be redesigned.

6



Brief Description of the Dra wings .

FIG . 1 is a block diagram of a computerized system for

interfacing with a computer network in accordance with the5 invention.

FIG . 2 i s a perspective vi ew of the local host computer

shown in FIG . 1.

FIG . 3 i s an enlarged view of the arti cle of commerce

shown in FIG . .1, illustrati ng i n detail the UPC symbol

10 thereupon.

FIG . 4 i s a tabular view of the database shown i n FIG.

1 .

FIG . 5 is a flow chart illustra ting the operation ofthe system of FIG . 1 in accordance with t he invention.

1 5 FIG . 6 is an idealized view of the CRT screen of t he

T uclient system of FIG . 1 displaying information in accorda nce

with the invention.a ?

JFIG. 7 is a perspective view of articles of commerce

i - i which can be used in accordance with t he invention to acc ess

1 7 remote computers .~

3 Deta iled Description of the Preferred Embodiment

1 . Overview

FIG. 1 is a block diagram illustrating one applicationp !

2 5 of t he invention, na mely t he use of an or dina ry a rt icle of

commerce to access sites on t he Internet's World Wide Web.

As explained below, this embodiment of the inven t ion a llows

a person who .desires Internet resources concerning a

particular product to access t ho se r es our ce s using the

30 p roduct 's UPC symbol . The data encoded on the UPC symbol

can be entered manually or (for great er convenience) using abar code reader . .

Referring to FIG . 1, the Internet 20, illust ra t ed here

in generalized format, includes a service provider 22 a nd

35 two remote nodes 24 and 26 . In this case, service provider



a z .

"f

22 is a local Internet a ccess . provider . Service provider

could also be an online service provider, such as America,

OnLine® , Compuserve e , Microsoft O Network a nd Prodigys . In

such cases, local host 28 need not be on Internet 20 -- that

5 is, need not have a net work address.

An end-user (not shown) accesses Internet 20 using

local host 28, which in this case is an IBM compatible

personal computer including a CPU 30, a random access memory

32 and an address/data bus 34 by operatively connecting CPU

10 30 and memory 32 . Unless otherwise specified, the term

"memory" herein includes any storage device, including RAM,-

ROM, t a p e o r disk d rives (o r c ollect ions o r ne t wo rks o f

ta pe or disk drives), and any other device for storing

information . A modem 36 and I/O port 38 are at ta ched to

15 bus 34 by a suitable interfaces 40 a nd 42, respectively . An

input device 44 is connected to bus 34 vi a I/O po rt 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 a rticle of commerce . 4 8 .

20 Alternatively, input device 44 could be a ca rd reader,

optical chara cter or voice recognition system, touch screen,.

scanner, pen, keyboard or ot her known input device.

Local host computer 28 need not be a personal computer,

and could for example be a mainfra me or minicomputer having

25 a t erminal by which the user could enter a nd receive data . .

In that arrangement, input device .44 would be att ached to

the terminal.

Modem 36 is a d op t ed fo r elect r onic c ommunica t ion via a

suitable telephone link 50 with service provider 22.

30 Computer 28 functions as an Inter net host because it is

connected to--service provider 22 using Point to Point

Protocol ( "PPP") via t elephone link 50 . Other

telecommunications channels ma y be used, such as ISDN or a

connection which incorporates a third party intermediary

35 network such as TymNet,sm- Alternati vely, local host 28

could be connected di rectly to Internet 20, as i s li kely to



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

as mainframe . FIG . 2 offers a perspective view of local

host 28 and art icle of commerce 48 and also illustra tes a

CRT monitor 52 a nd keyboard 54 suitably coupled to bus 34.

5 In this illustration, loca l host 28 is used to access

Internet resources (or "Web sites") on remote nodes 24 and

26, which are a vailable using the HTTP protocol . HTTP uses

a client-server ar chitecture, with remote nodes 24 and 26

act ing as servers, and local host 28 act ing as a client.

10 Local host is equipped with Net sca p e Na viga t o r b ra nd Web

browser software which enables it t o function as an HT TP

client.

Remote notes 24 a nd 26 have pre-assigned network

locations ( or "domain names"), and desired resources (such

15 as a part icular Web site) a re locat ed in specific

directories and files (or "paths") r esident on a r emote.

nodes 26 and 28 . . The precise locat ions of those resources

are specified using URL, which, as explained above, includes

three fields : <resource type> <domain name> <path> . To

20 access resources of a pa r t ic ula r r e mo t e n ode 24 or 26, local

host 28 requests those resources from Int ernet 20 using the

appropriate URL . Thus, the URL functions as a more precise

kind of network address than a domain name.

The URL required is often supplied by the user . Users

25 learn about the e xi st en ce o f a desired resource (a nd it s

corresponding ULR) through a variety of mea ns, including

publi ca t io n i n a p r in te d a dve rt i se me nt . In current

practice, the URL acquired from a printed source must be

entered usi ng a k ey bo a rd . As explained a bove, this can be

30 tedious . Moreover, in many ca ses, users may have trouble

finding references to desired Web pages.

2 . Article of Commerce

In accordance with t he invent ion, a ccess t o desired

resources on remote nodes 24 and 26 is a chieved using an

35 : a r t icle of comme rce 48 . The term "article of commerce"



5

10

1 5

20

25

30

35

includes ta ngible things tha t a re sold or moved throughY

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 48in any suita ble manner, including printing directly on the

art icle or its packaging, or applied to labels or ta gs

att ached or otherwise affixed to t he article . In accordance

with UPC sta ndards, symbol . 46 encodes as ten-digit number

(the "product identification number") . As shown in FIG . 3,

the product identifica tion number encoded in UPC symbol 46

consists of t wo five-digit fields, A and B . Field A is a

unique, pre-a ssigned number signifying a part icular

manufacturer . Field B is a number ident ifying one of t he

manufacturer's products . In the United Sta tes, 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 t he reta il point-of-sale,

where purchase of a part icular item is recorded by scanning

the item's ba r code, symbol.

There are numerous other formats and systems for

assigning product identification numbers to articles of

commerce . For exa mple, the International Article Numbering

Association ("E AN") a ssigns its own number to products

outside of the U .S . and Canada, and uses a different

symbology tha n used with the UPC . Product identification

codes for books are provided by t he International Standard

Book Numbering System ("ISBN") and are encoded using a

symbology specified by that organization . Likewise,

magazines and serial publications a re assigned product

Identification codes by t he International Standard Serial

Numbering System ("ISSN") .



r t

These numbering systems share at least t hree

characteristics . First, for purposes of this invention, the

identificat ion numbers may be assigned in accordance with a n

"extrinsic" standard . By extrinsic, it i s meant that the

assignment of numbers is made a by group or associat ion forthe purpose of identifying art icles of commerce . It is

likely that new types of identifica tion numbers will arise

in the future, as will new organizations for a ssigning and

administering those numbers, and the present invention

contemplates use of both existing a nd future extrinsic

identification numbers and formats.

Second, the identificat ion numbers may ha ve r ec ogn ized

significance as numbers identifying art icles of commerce.

The level of recognition may be among the general public, ora defined subset, . such as a particular industry or

occupation.

Third, the identificat ion numbers may be encoded in a

standar d, machine readable format -- namely, bar codes.

Other machine readable formats ma y also be used for this

20 purpose, including magneti c stri pes or opti cal character

recognit i on ("OCR"), and the present inventi on could be

practiced wi th product i denti fication numbers encoded in

th ose formats as well.

3 . URL/UPC Database

2 5 In accordance with the inventi on, service provider 22

i ncludes a relational database 60, whi ch i s shown i n more

detail in FIG . 4 . Dat abase 60 i ncludes records 62-68, whi ch

are accessi ble using a sui table database management .system

software . . Each record 62-68 of database 60 contai ns four

30 fields 70-76 . Fi elds 70 and 72 contai n a UPC product

identification number, as explained below . Fi eld 74 holds a

URL suitable for locati ng a .resource on the Internet.Depending on the application, other network addresses --

eit her numeric or mnemonic, physi cal or virt ual -- may be

35 used . Fi eld 76 holds a narrati ve descript ion of the

11

5

10

15



5

1 0

15

20

25

30

35

resource addressed i n field 74 . This particular arrangement

of fields is . but one illustrat ion of how the invention may

be practiced . For example, additiona l fields could be

provided, or the UPC product ident ificat ion number could be

held in a single field.

Each record 62-68 of database 60 associates a UPC

product identificat ion number (conta ined in fields 70 and

72) with a particular Internet URL and narrative description

(contained in fields 74 and 76, respectively) . The

associat ion is based on selected criteria . In this case,

the criteria .is the existence of a Web resource sponsored by

the manufacturer o f 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 criter ia ca n be used . For example, the

associat ion could be based on the existence of a Web site

simply referring to or relat ing to the product.

As stat ed, fields 70 and 72 conta in a UPC product

identificat ion number . Field 70 contains the first five

digits of the product identificat ion number (field A of FIG.

3 ) . As explained a bove, these digits uniquely identify t he

product's manufacturer . Field 72 cont ains t he second five

digits of the product identificat ion number (field B of FIG.

3 ) . These digits identify the manufact urer's particular

product . In some cases, a manufacturer may have many

products and only one Web sit e or ot her Int ernet resource.

In that ca se, 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 indicat ed in field 74 with a ny

product ident ifica t ion numbe r whose first five digits match

the manufac turer number specified in field 70.

Database 60 itself is accessible via service provider

22, which i s -equ i pped wi t h Web server software such as

provided by Netscape .Communicat ions , Inc . The s erver

software provides access to an HTML document (the "Query-

Page") resident on service provider 22 at a predetermined



1

URL . The Query Pa ge, when displayed on CRT 52 by loca l host

28 using a forms-capable browser allows the user to ent er a

query in the form of a .UPC product identification number.

Alternatively, dat abase 60 could be resident on loca l host

28 or anot her remote computer 24 or 26 . The Web server at

service provider 22 may have a predetermined URL locat ion.

Browser software resident in local host computer 28 may be

configured to a u t om a t ic a ll y request t h a t predetermined URL

location when the browser software is initially loaded.

Database 60 may be incorporated wit h a database or

search engi ne of Web si tes or oth er Internet resources (such

as th e Yahoo or Lycos databases) . In that case, the Q uery

Pag e may g i ve th e user the opti on of enteri ng a UPC number

or an alternative search term, such as a portion of the URLor the topic t o which the desired resource pertains.

Also, database 60 may be divided into one or more

tables, which may be distributed over more t h an one

computer . For example, a first table may contai n records

associ ati ng UPC numbers wi th names of products or

manufacturers . A second table associates products and/ . o r

manufacturer names wit h Internet addresses . Thus, the

process of using the UPC number to locate a network address

may i nvolve one or more steps . For example, database 60mi ght determine th e name of a product corresponding to a UPC

25 number usi ng a first t able, and then determine network

addresses corresponding t o that product name using a second

table . Even though multi ple steps are involved, the UPC

number is st ill "associ ated" in computer memory with the

network address for purposes of the i nventi on.

30

4 . o p eration of the Invention

Suppose-a user is i nterested i n Internet resources

concerni ng a parti cular type of product . In accordance wit h

the invention, the user can access those resources by taking

35 an ordinary s pecimen of th e product -- a can of soup for

1 13

f d

5

1 0

1 5

20



5

1 0

1 5

20

25

30

35

•r

example —and entering all or part of t he product's UPC

product .identification number 46 . Database 60 uses the

entered product identifica tion number to look-up the

associat ed URL, which is returned to the user in the form of

a HTML document.

This operation is illustrat ed in FIG . 5 . . At ablock

80, the user loads his browser software ont o 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 ca se is a human, but

a l t erna t ively a p rogr a m (o r "process") running on local host

28 could be the "user" in the sense that it is t he process

which is requesting information from the Int ernet a nd

supplying t he UPC number.

At a block 82, t he Query Page is transmitted to local

host computer 28 in the form of a n 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 t he UPC product

identificat ion number encoded by symbol 46 . Because t he UPC

product identificat ion number is printed in both machine-

and human-readable format (See FIG . 3), this may be done by

manual entry using keyboard, voice recognition system or

o t he r 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 tra nsmitted to t he 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 r etrieves a ll r ec or ds 62- 68

having UPC fields 70 and 72 that ma t c h t he pr oduc t

identificat ion number entered by the user . The records a re

conveyed to the user in t he form of an HTML document . The



5

10

15

20

25

3 0

35

criteri a 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 i denti ficati on number . It i s assumed

in t hi s case that th e user is i nterested i n any record 62-68havi ng a field 70 that mat ches th e entered manufacturer

portion . (Recall that t he database 60 s tores the UPC number

i n two fields -- field 70 for the first fi ve di gi ts

(corresponding to manufacturer) and field 72 for the second

five digi ts (corresponding t o manufacturer's product)) . .

Thus, at block 88, records 61, 64 and 65 are ret urned to the

user, because field 70 i n each of those records contai ns

"31251 . "

If the user entered all ten dig i ts of a UPC productidenti fication number(e . a ., "31251-00302"), then only

records whose fields 70 and .72 matched 1 1 31251" and "00302,"

respectively, would be retrieved . (In thi s case, that would

be record 64) . If all ten UPC digits are entered, and no

exact match i s found, database 60 may be programmed to

retrieve records (if any) where at least the manufacturer

porti on (that is , first five digi ts) matches field 70.

At block 90, browser software on local host computer 28

dis plays records retrieved at block 8 ,8 on CRT 5 2 . Therecords are returned i n an HTML document, which i s di splayed

by . the browser in a screen format 94, as illustrated in FIG.

6 . In t hi s example, records 62, 64 and 66 have been.

retrieved. Screen format 94 dis plays data from each record

i n a separate rows 96, 98 and .100, respectively . If no

matchi ng records are found at block 88, a messag e such as

"no records found" may be returned i nstead.

Text from descripti on field .76 of each of records 62,

64 and 66 is dis played as hypertext li nks 102, 104 and 106,respectively . . Link 102 i s associ ated wit h th e URL of record

62, link 104 wit h t he URL of record 64, and li nk 106 wit h

th e URL of record 66 . . When the user s elects one of links

1 5



~1 4

F L

k

ri

V

Y

102-106 (by mouse click or ot herwise), the browser software

loads the URL associated with the selected link to access

the resource at the locat ion specified by that URL.

5 . Alternative Embodiments

5The foregoing embodiment .is just one example of the

present invention . Many alternatives are possible . .

Other Networks and Protocols . . While t he present

inven t ion is illust ra t e d wit h respect t o a syst em for

10 accessing the Internet's World Wide Web, it could.be

practiced using other Internet . protocols (such as Gopher) or

other t ypes of wide area networks and systems, including

those offered by "on-line service" providers such as America

OnLine* of Fa irfax, Virginia or CompuServe* of Columbus,15 Ohio or t he Microsoft* Network of Redmond, Washington.

In those cases, dat abase 60 could be resident on t he

on-line service provider's computer . The network address ,

information contained in dat aba se 60 could be either

Internet URLs, or locat ions within the on-line service

20 provider's environment . In this case, t he p ro t oc ol used t o

communicate between local host 28 a nd 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 t he Internet can

25 be .made usi ng a URL retri eved from database 60.

Controlled Access . D atabase 60 need not be publi cly

accessible . Access t o database 60 can be limi ted eit her by

placing database 60 on a proprietary network, or, if placed

on an open network, using a password or digital signature

30 system t o permit access only to auth orized persons .. Also,

records 62-68 may be selecti vely accessi ble . For example,.

each record can contain an additi onal field i ndicati ngwhether th e URL contained in field 74 points t o network

location containing material inappropriate for children . In

35 that case, database 60 can be programmed to return URL at

block 88 only if t he user has supplied a proper password .



5

10

15

20

25

30

35

Automatic Jump ing to Desired Location . In the

disclosed embodiment, the URL a ssociated with a selected UPC

product identificat ion code is returned to the end .user in

an HTML document at -block 88 of FIG . 5 . The user ca n then

hypertext link to the site corresponding to the URL.

Alternat ively, instea d of displaying query results at step

90 (of FIG . 5), browser software in local host can

a u t om a t ic a ll y lo a d t he ret r ieved URL a nd poin t t he user t o

the site corresponding to that URL . An additiona l field in

database 60 can provide a.code indica ting whether this

feature should be enabled or disabled for a par ticular URL.

Identification Numbers and Svmbologies . The invention

can be pract iced using sta ndard identificat ion numbers-and

symbologies other tha n UPC numbers and forma ts . For

exa mple, E AN, ISBN a nd 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 a ll types of it ems, such as a consumer product

102, newspaper 104 or book 106, as well as coupons, fliers,

cards and advertisements (not illustra ted) . For example, by

placing a product's UPC code on an a dvertisement for the

product, the advertiser could, in accordance with the

i n v e n t i o n , facilitate access to Internet resources

concerning the product.

Machine Reading Technolo gy . In lieu of a ba r coding,

the invention could be pract iced with product identification

information t hat is encoded using other technologies . For

example, product identificat ion informat ion could be encoded

on a m a gnet ic st r ip a ffixed t o a product, ca rd or ot her

article . In place of. wand, local host computer could use a

magnetic card .reader . Alternat ively, the number could.

simply be p rint ed in human-readable format, and . an optional

optica l charac ter recognit ion system could be used to

facilitate entry .



Direct Coding of Address . In pla ce of a st anda rd UPC

symbol, bar code technology could be used to encode the

act ual mnemonic or numeric (IP) network a ddress in machine-

readable format . While this ar rangement does not ac hieve al

5 the advanta ges of the invention, it . allows the user to

easily enter desired address information using a bar-code

reader instea d of manually typing the address

3 r,

V JF3I~,



We claim:

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

remote computer, comp ising:

(a) a machine-rea able indicia associated with the

article of commerce, s id indicia encoding at least one of a

5 plurality of identifica ion numbers, said encoded

identification number c rresponding-to the article in

accordance with an extr.' sic standard;

(b) input means for generating a query signal

corresponding to said en oded identification number;

10 (c) a database con aining a plurality of network

addresses and said plural i ty of identification numbers, each.

of said identification n ers being associated with at

least one of said.plurali y of network addresses ; said

database being responsive to said query signal for providing

15 one of said network addre ses which is associated with said

encoded identification.n ; • ~

(d) a local host ada ted or network communication;

and .

(e) a first network ontai in a plurality of nodes,

20 each having an assigned net ork ress ; said network being

operatively coupled-to said datab se for allowing

communication between said ocal host and that one of said

nodes whose assigned networ address corresponds to the

network address provided by aid database.

2. The system of clai 1 where said machine-readable

indicia is a bar code, and w erein said input means includes

a bar code reader.

3. The system of claim 2 where said. identification

number is at least a portion f a Uniform Product Code.

4. The system of claim wherein said indicia is both

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

19



K

includes a keyboard f

identificat ion number

5 .. The system

single-user computer.

6. The system o+

multi-user c omputer wil

l

7. The system o:

computer is a node on

8. The system o:

network, wherein said . :

said second network, si

provider computer tha t

9. The . system o:

resident on said seconi

manually entering sai d

claim l wherein sai d local host is a

E claim 1 wherein said local host is a

:h a plurality of user terminals.

.claim 1 wherein said loca l host

aid network havi ng a network address.

cTa 1 further comprising a second

oc ost computer is connected to

id fno d network including a service

j is a on said first network.

claim 8 wherein said database is

network.

1 0. T he sy st e m o cla i m 1 wh er e in sa i d 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 ar ti a of commerce to

generate t he network address of a comp er on a network,

comprising : .

(a) reader means for en a g an output si gnal

5 corresponding to an article de ification number which is

used to identi fy the arti a commerce in accordance with

a standard;

(b) a database hav n pl alit identificationnumbers including sai d icle i denti fication number, and a

10 plurality of network ddresses, and associating each of said

identification n r s with at least one of said network

addresses ; and

20



1 5

(c) cont rol, means responsive to said o

operatively coupled to said data base for re

said data base at . least .one of those of said

addresses which correspond .to said art icle

number .

13. The apparat us of claim 12

identification numbers are Uniform

14. The apparatus of claim .12

addresses are Uniform Resource Loca

ut t signal and

gving from .

etwork

dentification

said

Codes.

said network

5

5

10

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

16. A databa ercompris g:

first comput r memory ntain g a plurality

identification n ers bo a by arti cl erce, sai d

i dent i fi cat i on n ers u d to i denti fy articles of

commerce;

second,computer me ory contai ning a pluralit y of

network addresses corr sponding to remote i nformati onresources relati ng to arti cles of commerce, sai d resources

being accessible via a network ; and

means for assn iat i ng each of sai d pluralit y of

identification .n ers in .sai d fi rst memory w i th at least

one of sai d netwq k addresses i n sai d second memory.

17. The t abase of claim 15 wherein sai d database is

a relational . tabase, and said fi rst memory is a first

field withi n 2tid .relati onal database, and second memory i s

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

further comprising a

adapted-for network

means i s resident on said

si dent on sai d remote

21



19 . . The data base of claim 15 wherein s id first a nd

second memories are secondary stora ge.

20. The data base of claim 15 wher .ei said.

identificati on numbers a re Uniform Produ Codes . .

21. The database of claim 15 wher in said network.

addresses are Uniform Resource Locato r

22. A method for generating th#_ address of anode on a

network, comprising the steps of:

( a ) a sso ci at in g in comput er emor y a t lea st a por tio n

of an identification number with network a ddress;\node's

5 said identification number ha grecognized significance a s

a. number identifying an art'cl of commerce.

(b) providing an a rt i cle o commerce bearing an indician

r u on which said identific ion n er i s enc oded;

( c ) reading at 1 ast p rtion of said identification

_ : - 1 0 number fro m said ind ia ; n .

( d ) retrievin from s i computer memory the network

address associated ere n wi sai d product id i tification

number.

23 . The me od c ording t o claim 22 wherei n said3=

S

identification n e s a Uniform Product . Code.

2 4 . . The metho according to claim 22 wh ere said

network addressis a . Uniform . Resource Locator .

25 . The method according to claim 22 wh erein said

indicia is encocYed in machine-readable format.

26 . . The eth od according to claim 22 where sai d

i ndici a is en oded in human-readable format .

27 . T method according to claim 22. wherein sai d stepof reading i s , performed usi ng a bar code reader . ,

22



28. The method according to cla im 2 wherein said step

of reading is performed by a human readi q sa id .indicia, .and

entering said identifica tion number usi q a keyboa rd . _

29. The method according to, cl m 22 wherein.said5 computer memory includes a database having one or more

ta bles containing said identifica on number and said

network address : . .

3 0 . . The method acc rdi to claim : 29 wherein said

tables are distribute over plurality of computers . .

1 0 3 1 . . The method acco in to claim .2 wherein said

t ables a re resident on a single pu er . .

3 2 . . A .method.fo disseminat ing network addresses using

articles of commerce . comprising the steps.of.

( a ) g e n ' p_~ti a .number corresponding t o a net work

15 address ;

(b) enc ing the addres4es on.a machine readable

indicia ; : a n d

(b) pl cing sai d.indicia .on.th e e3Merior surface of an

arti cle of ommerce . .

2 3



Ti_Ei'1'sLiL; V!= UfII- i 21 L OG1 C . "

A, system and method for usi nq identi ficati on Oadees

found on ordinary'artioies :-'of commerce to access remote

Computers on a network . I.h aaoardanco with one embodimentS of the invention # a computer i s 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 : . H I P C s ol, or vial other sui table input

means, . . .The datsbase . ' r e R t r i :ev+as the URL -dorro ponding to . - t h e

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

'f

Pssa I of 1

McBride Baker & Calm, /~~~~

McBr

O ur Rderence: 75353-00006

U N P T E D S T A T E S P A T E N T A N D T R A D E M A R K O F F I C ED E C L A R A T I O N , A N D P O W E R O F A T T O R N E Y

As a be low nam ed inventor , I hmb y dec lare t h a t

My res idence , post o$cs sddrw an d c idrensh ip are as dated be low nod to s ty m ute .

I baliams I am the original, first and sole inve ntor (if only one na me is l isted balsa) or an original, first and

joint invento r (if plural names a rc listed below) of the subject m atter which i s c laimed sad for w hich a pa ten t i ssought on the invention enti t led:

Svetsm and Method for Usln:a la E i m Article of Com m e rce to Accts a Remote Camnuter

( ' ~ T tba specification of which (check o nly one i tem b elow):

[ : ] i s attached hereto .

] ;~ (]was Sled as United States app l ication Seria l No . on and was amended on or3 _ . thmIIgh if applicab le).i

a a[ ] w as filed as PCT international application Number on and was amended

u n d e r P C T A r t ic c ia 1 9 a n lifa P P a 1

~ . I h a a r e b y s t a t e t h a t I have re v iewed and und as taad the con t en t s of the sbow idea t iSed goW les t icm,including the c laims, as am amdad b y any am endm ent refa=ed to above . I Acknowledge t he duty to disclose

infotmat ica which is mate rial to the mm m instion of this app lication in award=@ with Tit le 37, Code of Federal

Reputations, 41 . 5 6 (& ) .9F

c

I hereby claim facaip priori ty b enedt s under Tit le 35, United States Code , 4119 of any Ersigtr

T spplicad*s) f i3r patent or inventor's cert if icate a of nayPCT lntermdortat appl iead*$) de s igdadnt at I" oneoomo y o ther to the f ished St i t es of America l is t ed be low sad have a l so ident i fi ed be low aw Aga 4011ca t i onf or pa t e n t c r inventoes aatii loato or any PCTin trsaa t iond appHw ions) deal gnadag a t l east am country other than

t he Un i t e d aw n o f Am e r ia f il e d by m e an t he amsuhnjed m atter having a filing daft betters that o[the

application oa w ench priority is claimed:

Priority Chimed : [ ] Ya H N4o .

Prior Fandgp lPCT Appl ieaticn(a) and aw Priori ty Claims Under 35 U . S .C . 4119:

( P l u m b e r ) ( C o u a t r ' y ) (DayftANTr Filed)

l hereby cla im this bsaaSt tmd w Theesa 3S, United States Code, 4110 of an y United Sta tes app9c t ion(s) ccPCT iatemadoa el nol iadon(s) designating the United States of America t ided below and, lnsa6r es the lowed

mater of each of the c ldm d of this appl ioation i s not disc losed in tea prior &ppl icadoo(s) i s the mam sr provided bythe first paragraph of TiW 33, United States Cod e, 4112, I ubww iedp the duty to d isclose m 1a ur i a l kh en s t i o a a sdefined in T itle 37, Code of Fedanl Regulations, 41 . 3 6 ( & ) w h i ch F , 9 9 r e 1 betwee n the filing date of The prior

appl ication a nd the aad oesl or PCT International f il itg d ate of this appl ication :

350- 17089835773 ;# 2



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

-T

nVia2

p r ior U. S . Awl i ca t ion (x ) o r PCT Iu t cu t ioaW APP l Icadon(s) WWI00 U . B . 1br Budh Under 35 U S01120 ,

60!000.442 dune 20.144' Pendinw

(Appl i c a t ion S .N .) (Filig o Data) ( S t a t u s : pa t W 4 pen d iu& ab uW avad )

POWER OF ArrORNZY:

I hereby appo int Andrew P- Basi le , Jr . O W & N o . 33A32) as m y attorney, w ith fi ll powe r of substi tution.t o p n o w u t h i s a p p l ic a t io n a n d to t racmd a l l business is On Uni t ed 31tas Pabst =0 Mcnark Cok e 000m new atedt harnv i th .

Md all cormqa4wce to A n d r e w IL B a s i l e

M c B r i d e B a w 0 Cdu

S W W. M W E V A S u i t * 4000

C b k m % m 1 w il 6 0 6 6 1

Tielaphout inquiries may b e d i re c ted to Andr ew R . B e s iW a t ( 312) 7 15 - 57 43 o r b u i le o n b c - o o m ( e m a i l ).

DECLURRANTENOON.-

I bu t , d e c l are t ha t a l l dw aze n t s t radar be au o f my ow n k w M W V am t aw and *a all statuawAs

m a d e a n i m a c m a t io n a n d N d d w e b a b r a d t o b e t ru e ; a n d 1 0 1 h o w t h a t tivm sWomente we made with th eknow ledge that wi l l fhl Ddle shoments and t o l ike so m ade am p unishab le by due at SpriammneW4 or bod : 6 u n d e r

11001 of 7% 18 of the United S tate s Q4 and tha t such =Rd fWas donnouts m ay jeopudw o the val id i ty of tbaa p p l i c a t io n n o r s a y p a t e a l b l o o m e d t h e r e o n .

Sols or First Inven tor

F a l l N a m * : F rank C . Hudft

Citizenship : U S AR a W w o r 22 41 34da4m Drive , LAW . Mats 6 0 5 3 2P u tt Coke Mdrw 2241 Edgebroolm Drive, U" Wwhi 60532

I a v e m t o e ! s 8i v a d M r egt

Xa2 -— a tc

S a w c o v i d T h v e n t a r

Ful l No n a P d w L H u d e t zCitizenship USAR A M A M M U C 34903 Pine Cag y IAWN Plaw Add, I l l inois 60514

P a s t O d k e A d c h a v c 24 9 0 5 P Q Cam lAw;PWWBWQ laNds 60344



Practitioner's Docket No . 75353-00-006 PATENT

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE

In re application of Hudetz, Frank C . ; Hudetz, Peter R.

Application No . : 08/538,365 Group No . : 2302

Filed: 10/03/95 Examiner : D . Pan

For: SYSTEM AND METHOD FOR USING AN ORDINARY ARTICLE OF

COMMERCE TO ACCESS A REMOTE COMPUTER

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

B y :

Robert T . " Durst, Jr.

Executive Vice President and Chief Technology . Off icer

D a t e

Q

S0-1

L El"I

Tu

01

5 3 1

_0

r7 -

0.

(Power of Attorney by Assignee of Entire Interest—page 2 of 3)



Addendum

S yst e m S & Method for Using an Ordinary Article of Commerce to Access a Remote

Computer



F I G . 1So

6o DATA-CE REMOTE

~ R o v l D r ~ NODE2,6

I L O C A L 3 2

HOST r ~6MODEM RAM

I ~ S

3 ~4o I ARTICLE

~ ~ I I I I I I ~ 1DATA/ADDRESS BUS I

I I

,

qb

C PU 3a I/p PO INPUTDEVICE

d N ^} REMOTE

I N OD E

V

yy~SOUY y~

y6 u ~'

S7

~ au u n u m n u m i.;

S N

F IG . 2

S . o



P RLV T OF DRAWING.

AS ORIGINAL LYFII.

F I G . 3

73 59

d l l l l ~ I I I I d I I ~ I N p l 2 4Y

A

F IL S

LOAD BROWSER

8p SOFTWARE

LOAD Q UERRY~S PAGE

ENTER UPC PRODUCT84 ID NUMBER

LOOK UPS 6 UPC CODE

'RETURN MATCHINGg~ RECORDS

DISPLAY RESULTS9v

LOAD DESIRED

Q

9a ADDRESS

F I G . 4 àr ~o e- 7a r-714

UPC-A UPC-8 URL DESC

31251 00301 s e . s *up .com/subflle/Ind4x.htfnl so

31251 00302 sa mp le .soup . com /p romot ion /ma in .h tml 9iveawoy

31251 00400 tes t .milk,oir9 fnIlk

4205 cors .com/testdrive/main .html - T con

1 7 9

(-76



PRLNT OF DRAW1W

AS ORIGINALLY FU

-1

NAVIGATE > « KX~ELP EXIT

CLICK O N DESIRED SITE:-~ U2

31251 ' -003PGIVEAW1251-

12 a106 x z ~

1

SZ

FIG. . 7

Soup

1 1 1 0 ,

I k 0



Application.o r . Docket Numb er

PATENT AP PLICATION FEE DETERMINATION RECORD n nEffective 'November 10, 1958 pC3G Q

CLAIMS AS FILED P ART I SMALL E OTHER THANCo lumn 1 Co lumn 2 TYPE OR SMALL ENTITY

FOR NUMBER FILED NUMBER EXTRA RATE FEE RATE FEE

BASIC FEE

TOTAL CLAIMS minus 2 0 =

INDEPENDENT CLAIMS -minus 3 =

MULTIPLE DEPENDENT CLAIM PRESENT

* If the d i f ference in column 1 is less than zero, enter 0 0 " in c o lu m n 2

CLAIMS AS AMENDED - PART 11

3 80 .00 OR 76 0 .00

X$ 9= OR X$18=

X3 9= OR X78--

+130-- OR +260=

TOTAL OR TOTAL

OTHER THAN1 SMALL ENTITY OR SMALL ENTITY

Q I I REMAINING I I NUMBER I PRESENT

zAFT03 PREVIOUSLY EXTRA

Z AMENDMENT PAID FOR

O T o t a l * Minus . 5zW Independent * Minus .« =yam.---

Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

M REMAINING NUMBER PRESENTAFTER PREVIOUSLY EXTRA

Z AMENDMENT PAID FO R

p Total * Minus ..z

W Independent * Minus .« -2 -

Q FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

ADDI-RATE TIONAL

FEE

OR X$18=

OR X78=

OR +260=

TOTAL TOTALADDFEEOR

ADDrT. FEE

ADDI -RATE . TIONAL

FEE

OR X$18=

OR X78=

OR +260=

TOTAL TOTALADDiT. FEE

ORADDIT . FEE

RATEADDI-

TIONALFEE

X$ 9=

X39--

+ 1 3 0 =

V REMAINING NUMBER PRESENT

zAFTER PREVIOUSLY EXTRA

= AMENDMENT PAID FO R

p Total . MinusZ

W Independent * M inu s .«

FIRST PRESENTATION OF MULTIPLE DEPENDENT CLAIM

• I f the ent ry in column 1 is less than the ent ry in column 2 wr i te '0 ' in column 3

RATEADDI-

TIONAL

FEE

X$ 9=

X39=

+130=

ADDI-RATE TIONAL

FEE

OR X$18=

OR X78=

OR +260=TOAOTALI f the 'H ighest Num ber Previous ly Paid For' IN THIS SPACE is less than 20, enter '20.' ADDrr FEE OR

ADDIT FEE" I f the 'Highest Numb er Previously Paid For' IN THIS SPACE is les s th an 3 , enter'3 .'The 'H ighest Numb er Previously Paid For' (Total or Independent) is the high est num ber found in the a pp ropriate box In colum n 1.

Rev . 6491

RATE

ADDI-

TIONAL

FEE

X$ 9--

X39--

+130--.

r a im n a r ,p , r a a e r n a r " L M I C e . U.b . U E Y A H 1 M E N T O F COMMERC



Docket Number : 150-061A

IN THE UNITED STATES PATENT AND T RADEMARK OFFICE

Applicant : Hudetz et al.

Serial No . : Unknown Examiner : D . Pan

Filing Dat e : Ja nua ry 15, 1999 Group Art Unit : 2783

Title : SYSTEM AND METHOD FOR USING AN ORDINARY.ARTICLE OF COMMERCE T O ACCESS A REMOTECOMPUTER

Hon . Commissioner of Patents

and TrademarksWashington, D . C . 20231

SIR :

PRELIMINARY AMENDM ENT

This Preliminary Amendment is submitt ed

contemporaneous with the above-identified applicat ion, 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, nz'i e 10, delete "continuat ion of" and insert

divisional a pplication of co-pending application serial

number 08/538,365, filed on October 3 1995 which claims

priority of provisional7'I S ~ i

1~ , ~ ~ ~f J~1

IN THE CLAIMS : .

Cancel claims 12-32 .



REMARKS

Claims 12-32 have been cancelled, leaving for

prosecution cla ims 1-11, which have been classified as

belonging to G roup I by the E xaminer in the copending

parent application.

Prompt consideration of the a pplication is

respectfully requested.

Date : I — " S — I I Respectfully submitted,

A n t h ' o A l Q R -.' BarkumeRe . No . 33,831At 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

P m c it io n e r ' s D o c k t t N o . ~srD''vbl A- ?AnWTJUN (J 1919

Group ?_700

]T(TSa Y nTtD STATES PATENT AND TUDIXAM OFFICE

in re ap p l i ca t ionOf xudg nat e l .

Ser ia l No . : 09/`132,908C p r o u p N o ., 2756Filed : unua ry 15 , 1999

E M ► OJYlur"

Fo r : S Y S T E M A N b M T H O D F O R U S IN G A N O R D I N A R Y A R T I C L E O F

COMMCE T O A C C E S S A R E M A T E C O ) D U 'l 'E R

Ass i s tant Com m is s ioner fvr Pat en t sWashing ton , D, C . 20231

POWML TO INSPECT AND MAKE ; COPIES

A p p l ic a n t b e r e b y g m n t a t h e b e l o w n a m e d p r a c t it io n e r t h e p o w e r t o in s p e c t a n d m a k e c o p i e s of

t h e dw v o - r e fe r e nc e d a p p l ic a t io n .

Nam e o fprae t i ti on er : Ro dg e r P l a g gAddre s s : a 101 Cry s tal Plana A r o . #270

Ar b ngton V A 22202

Rag, No. 29,149

Tel . No. (703) 658-2100

Dated ~ar i

R BarkumeA t t o r n e y f or A p p l i ca n tR a g_ N o . 33,831

Anthony R Bukutae, P. C .

1 4 S o u t h M a i o S M e S u it e 2 0 0 0Sayvi l l e . NY 11782T e l e ph o n e N o . : (516) 2442644



~4*-'VOF CO

3~ fit, UNITED ATES DEPARTMENT OF COMMERC EPatent and Tradem ark Of f iceAddress : COMMISSIONER OF PATENTS AND TRADEMARKS

*rATES 0* Washington, D .C . 20231

APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO.

09/232.900 011599 HUMETZ F ISU— 061 P,

FL M 0 2 11 & ~ - - ' j

PAN . D

EXAMINER

lel !'Hd1e 1 (- - -" 11"---1 ART UNIT PAPER NUMBER

SUTEMD

SAYVLLENY1170i!

DATE MAILED :

11/2991

Please f ind be low and/or a t tached an Of f ice com m unica t ion concern ing th is ap p l ica t ion orproceed ing .

Commissioner of Patents and Trademarks

PTO-90C (Rev. 2/95) 0 RN Copy



Application No.

09/232,908

Office Action Summary Examiner

Pan 2783

K R es p o n s iv e to c omm u n ic a t io n( s ) f il ed o n J u n 3 Q 1999

q This ac t ion is FINAL.

q Since this application is in condition for allowance except for formal matters, prosecution as to the merits is closed

in accordance with the practice under Ex parte Qu,?yV935 C . D . 1 1 ; 4 5 3 O .G . 2 1 3 .

A shor tened s ta tu tory per iod fo r respon se to th is ac t ion is se t to exp i re three month(s ) , o r th i r ty days, wh icheve r is

longer, f rom the mai l ing date o f th is comm unica t ion . Failure to respond within the period for response will cause the

app l i ca tion to become aban doned . (35 U .S .C . § 1 3 3 ). Extensions of time may be obtained under the provisions of

37 CFR 1 . 136 (a ) .

Disp osi t ion of Claim

KCla im(s ) 1-11 is/are pending in the applicat

Applicant(s)

Hudetz e t a l .

O f the above, c la im(s)

q Cla im(s )

K Claim(s) 11=4

is/are withdrawn from consideration

i s /are a l lowed.

is /are re jec ted .

X C l a i m ( s ) 5-11 i s / a r e ob j e c te d t o .

q Caimsaresubect to restriction or eection requirement.

App l i ca t ion Papers

X j S e e t h e a t ta c h e d N o t i c e o f D r a f ts p e r s o n ' s P a t e n t D r a w i n g R e v i e w , P T O - 9 4 8.

q The drawing(s) filed on

q The proposed drawing correction, filed on

is /a re ob jec ted to by the Examiner .

is q .approved disapproved.

q The spec i f ica t ion is ob jec ted to by the Examine r .

q The oa th o r de c la ra tion i s ob j ec ted to by the Exam ine r .

Pr ior ity und er 35 U .S .C. § 119

q Acknowledgement is made of a claim for foreign priority under 35 U .S .C . § 11 9(a )- (d ).

q All q3ome* None of the CERTIFIED copies of the priority documents have been

q received.

q rece ived in App l i ca tion No . (Se r ies Code /Se r ia l Number )

q received in this national stage application from the International Bureau (PCT Rule 17 . 2 (a) ) .

*C e r t if ied co p ies no t rece ived :

q Acknowledgement is made of a claim for domestic priority under 35 U .S .C . § 11 9(e ) .

A t t a c h m e n t ( s )

PQ Not ice o f Re fe rences C i ted , PTO-892

q I n fo rma t ion D isc losu re S ta temen t (s ) , PTO -144 9 , Pape r No (s ) .

q I n te rv iew Summary , PTO -413

Pg Notice of Draftsperson's Patent Drawing Review, PTO-948

q Notice of Informal Patent Application, PTO-152

1 --- SEE OFFICE ACTION ON THE FOLLOWING PAGES -- -

U . S . Patent and Trademark Office

PTO-326 (Rev . 9 -95 ) Office Action Summary Part o f Paper No . 4



Application/Control Number: 0 , x / 2 3 2 , 9 0 8 Page 2

A r t U n i t : 2 7 83

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, 1 1 F .3d 1046, 29

USPQ2d 2010 (Fed . Cir . 1 9 9 3 ) ; In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed . Cir . 1985) ; Inre 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

d i s c l a i m e r . 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 P a g e 3

Art Unit : 2 7 83

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

s ec t i o n 1 0 2 o f t h i s t i t le , i f t h e d i f f e r e n c es b e t w een t h e s u b j ec t m a t t e r s o u gh t t o b e p a t en t ed a n d t h e p r i o r a r t a r e

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 . o v e r B e l l e r e t a l .

( 5 , 6 0 2 , 3 7 7 ) i n v i e w o f D o l i n , Jr . ( 5 , 5 1 9 , 8 7 8 ) .

5 . As to claims 1-4, Beller disclosed a system using an article of commerce [product 140]

( f i gs . 1 , 4 ,5 ) c o m p r ising a t l e a s t :

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,

co l . 6 , l in e s 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 Page 4

Art Unit : 2 7 83

c)a database for storing the bar code information (e. g . see col . 6 , l ine s 3 9 - 4 6 ; col . 8 , l in es 4 9-5 5 ;

co l . 1 2 , l ine s 1 0 - 1 7 ) .

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

i n t e r v e n i ng c l a i m s .

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

Art Unit : 2 7 83

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

Notice of References Cited

A p p l ic a t i o n N o .

2310

~

A p p l i c a n t ( s ) >

E x a m i n e r G r o u p A r t U n i tP a g e,f~

U .S . P A T E N T D O C U M E N T S

* D O C U M E N T

n

N O . D A T E N A M C L A S S S U B C L A S S .

A

~ /~B-T

KZ

IDI

E

F

G

H

I

K

L

M

F O R E I G N P A T E N T D O C U M E N T S

* D O C U M E N T N O . D A T E C O U N T R Y N A M E C L A S S S U B C L A S S

N

0

P

Q

R

S

I T I

N O N - P A T E N T D O C U M E N T S

* D O C U M E N T ( I n c l u d in g A u t h o r , T it le , S o u r c e , a n d P e r t in e n t P a g e s ) D A T E

U

v

W

X

* A c o p y o f t h is r e f e r e n c e I s n o t b e i n g fu n i s h e d w i th t h i s O f f ic e a c t io n .( S e e M a n u a l o f P a t e n t E x a m in in g P r o c e d u r e , S e c t io n 7 0 7 . 0 5 ( a ) .)

U .S . Pa ten t and Trademark O f f ice P a r t o f P a p e r N o .P T O - 8 9 2 ( R e v . 9 - 9 6 )

* U .S . GPO : 19 9 6 - 420 . 3 1 1 / 4 0 1 7 6



F o r m P T O 9 4 8 ( R e v . 8 - 9 8 ) U .S . DEPARTMENT OF COMMERCE - Patent and'Trademark office Application No . O8N O T IC E O F D R A F T S P ER S O N ' S

P A T EN T D R A W I N G R E V IE W

The drawing(s) filed insert date ~~ r e :

A . O approved by the Draftsperson under 37 CHR 1 .84 o r 1 . 1 52 .bjected to by the Draftsperson under 37 CFR 1 .84 o r 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 . D R A W I N G S . 3 7 C F R 1 .84(x) : Acce ptab l e ca te go r i e s o f d r awin gs : 8 . A R R A N G E M E N T O F V IE W S . 37 CFR 1 .84(i )

Black ink. Color. Words do no t a p p e a r o n a h or i z ont a l , l e f t - t o - r i g h t f a s h i on

_ Color drawings are not acceptable until petiton is granted . whe n page i s e i the r u pr ight o r tu r n e d so tha t the to p

Fig(s) b e co m e s the r ight s id e , e x ce pt fo r g r aphs . F ig ( s )Pe n c i l an d no n b l ack ink n o t pe r m i t t e d . Fig(s) 9 . S CALE . 3 7 CF R 1 .84(k)

2 . P H O T OG R A P H S . 37 CFR 1 .84 (b) _ Scale' not large enough to show mechanismwithout

_ 1 full-tone set is requited . Fig(s) crowding when drawing is reduced in size to two-thirds in

- Photographs not properly mounted (must use brystol board or reproduction.pho to gr aphic d o u b l e -we ight pape r ) . Fig(s) Fig(s)

_ Foor quality (half-tone) . F ig ( s ) 10 . CHAR ACTE R OF LI N E S , N U M BE R S , & LE TTE R S .3 . T Y P E O F P A P E R . 3 7 C FR 1 . 8 4 ( e ) 3 11 1.84(i )

Paper not flexible , strong, white , and durable . Lin e s , n um b e r s & l e t t e r s n o t u n i fo r m l y th ick an d we l l

Fig(s) d e f in e d , c l an , ble , and black (poor l ine qual i ty)._ Erasures, alterations, overwritings, interlineations, Fig(s) --

1 1 . SH ADI NG . 37t FR 1 . 8 4 ( m )o l d s , co py m achin e m ar k s no t acce pte d . F ig ( s )_ Mylar, velumpaper is not acceptable (too thin) Sol id black areas pale . ; Fig(s)

Fig(s) S o l id b l ack shad in g n o t pe r m i t t e d . F ig ( s )

4 . S IZ E OF PAP E R . 37 CFR 1 .840: Acce ptab l e s iz e s : Shade l ines, pale , rough and blurred . ' Fig(s)_ 210 c m b y 2 9 .7 cm (DIN size A4) 1 2 . N U M BE R S , LE TTE R S , & R E F E R E N CE CHAR ACTE R S .

- 216 cm by 2 7 .9 cm (8 1 /2 x 1 1 i nch e s) 37 CFR 1 .84(p)Al l d r awin g she e ts n o t the sam e s iz e . - Numbers and reference characters not plain and legible .'`h e e t (s ) Fig(s)

_ Drawings sheets not an acceptable size. Fig(s) _ Figure legends are poor . Fig(s)

5 . M A R G I N S . 3 7 CF R 1 . 84(8 ) : Acce ptab l e m ar g in s : _ Numbers and reference characters not oriented in the

sam e d i r e c t io n 'as the v i e w . 37 CFR 1 . 84(p ) (1 )

T o p 2 . 5 c m L e f t 2 . 5 cm R i g h t 1 . 5 c m B o t t o m 1 .0 cm Fig( s)

SIZE : A4 S iz e Engl ish alphabet not used . 37 CFR 1 .84(p)(2)

T o p 2 . 5 c m L e f t 2 . 5 e m R i g h t 1 . 5 cm B o t t o m 1 .0 cm

SIZE : 8 1 / 2 x I 1j r

FigsN u m b e r s , l e t t e r s an d r e fe r e n ce char ac te r s m u st b e a t l e as t

Margins not acceptab Fi ) _ 4. 32 c m (1 /8 i nc h ) i n h e i g h t . 3 7 CF R 1 . 84(p ) (3)

To p (T) L e f t (L ) Fig(s)

R i g h t ( R ) B o t t o m ( B ) 13 . L EAD L I NES . 3 7 CF R 1 .84(q)

6 . VIEWS. 37 C FR 1 . 84(h ) Le ad l in e s c r o ss e ach o the r . Fig(s)

REMINDER : S pe c i f ica t io n m ay r e q u i r e r e v is io n to L e a d l i ne s m i s si ng . Fig(s)

co r r e spo n d to d r awin g chan ge s . 14 . N U M BE R I N G OF S HE E TS OF DR AW I N GS . 37 CFR 1 .84(1)

P a r t i a l v i e w s . 3 7 CF R 1 . 84(h ) (2 ) S he e ts n o t n u m b e r e d co n se cut ive l y , an d in Ar ab ic n um e r a l s

B ra cke t s ne e de d t o sh o w f ig ur e a s o ne e nt i ty . be g inning with num be r 1 . S h e e t ( s )Fig(s) 15 . N U M B E R I NG O F V IE W S . 3 7 C F R 1 .84(u)

_ Views not labeled separately or properly . - Views not numbered consecutively, and in Arabic numerals,

Fig(s) b e gin n ing wi th n u m b e r 1 . F ig ( s )

_ Enlarged view not labeled separetely or properly . 16 . C ORREC T I ONS . 37 CFR 1 .84(w)

Fig(s) Co r r e c t io n s n o t m ad e f r o m pr io r PTO-9 4 8

7 . S E CTI ON AL VI E W S . 37 C FR 1 .84 (h)(3) da t e d

_ Hatching not indicated for sectional portions of an object . 17 . D ES I G N D R A W I N G S . 3 7 C F R 1 . 1 52

Fig(s) _ Surface shading shown not appropriate . Fig(s)

_ Sectional designation should be noted with Arabic or _ Solid black shading not used for color contrast.

R o m a n n um b e r s. Fig(s) Fig(s)

COMMENTS

r1h

REVIEWER DATE TELEPHONE NO.

ATTACHMENT TO PAPER NO.



Change Of Attorney Or Agent's Address In Application Docket No.

(37 CFR 1 .8(a)) 150-061A

In Re Application Of : Hudetz et al .

RECEIVED

Serial No . Filing Date Examiner (M o iola n

09/232,908 01/15/99 Pan , D . 2783

Invention : S Y S TE M A N D M E TH O D F OR A U TO M A TIC A CCE S S O F A R E M O TE CO M PU TE R O V E R A

N ET WO R K =̀//"

TO THE ASSISTANT COMMISSIONER FOR PATENTS cs / ' f id

P

Please send all correspondence for this application to :

M A YA Y0 3 2000 '-

o - - A n t h o n y R . Bark u me , E sq . M

G r e e n b e r g T r a u r igMet Life Bui lding s

DEM 4A P .200 Park Avenue

New York, NY 10166

Please direct all telephone calls to:

(212) 801-9294

~– Dated : May 1, 200 0Si aiure of Attorney or Agent of Record

Anthony R. Barkum, Esq.

R e g . No . 33,831 1 certify that this document is being deposited on

G r e e n b e r g T r a u r i g0 5 / 0 1 / 2 0 0 0 with the U .S . Postal Service as first

class mail under 37 C .F .R . 1 .8 and is addressed to the

Met Life Bui lding Assistant Commissioner fo r Patents, Washington, D .C .

200 Park A venue2 0 2 3 1 .

N e w Y o r k , N Y 1 0 1 6 6

Signature of Pers n ailing Correspondence

Registration Number & Address ofAttorney or Agent of Record

L i n d a G a r r a m o n e

Typed or Printed Name of Person Mailing Correspondence

Copyright 1997 LegalStar P2F/REV01



PETITION FOR EXTENSION OF TIME UNDER 37 CFR 1.136(a) D o c k e t N o .

(SmalifEntity) 1 5 0 - 0 6 1 A

In Re Application O f : Hudetz et al . ~KeEVE

~ M A Y 0 ~ 2 0 0 A~S e r ia l N o . Filing Date Examiner ~ CJ• a G r C * Q U p n d ^ 7 0 0

0 9 /2 3 2 .908 J a n u a r y 1 5 , 1999 P a n , D . 278 3

Invent ion : SYSTEM A N D M E T H O D FORA U T O M A T I C A C C E S S O F A REMOTE C O M P U T E R O

NETWORK O 1P

M A Y 0 3 2= Q

¢~ A EMOAII 'O THE ASSISTANT C O MMISSIO NER FOR PATENTS:

This is a request under the provisions of 37 C FR 1 .13 6(a) to extend the period for filing a response to the O ffice

Action of N o v e m b e r 2 9 , 1999 in the above- identified application.Date

The requested extension is as follows (check time period desired):

q One month ® Two months q Three months q Four months q Five months

f r o m : February 29, 2000 u n t i l : A p r i l 2 9 , 2 0 0 0

Date Date

A verified statement of small entity status as a small entity unde r 37 C FR 1 . 2 7 :

q i s e n c l o s e d .

® has already been filed in this application.

The fee for the extens ion of time is $190 and is to be paid as follows:

® A check in the amount of the fee is enclosed.

q The C ommissioner is hereby authorized to charge any fees which may be required, or credit anyoverpayment, to Deposit Account No.

A duplicate copy of this sheet is enclosed .

q If an additional extension of time is required, please conside r this a petition therefor and charge any additionalfees li h required to Deposit Account No . - A duplicate copy of this sheet is enclosed.

D a t e d : M a y 1 , 2 0 0 0Signature

/Barkume,n t h o n y R L Esq.

R e g . No . 33,831 1 certify - that this document and fee is being deposited onGreenberg Traurig 05/01/2000 with the U .S. Postal Service as first

Met Life Building class mail under 37 C.F .R . 1 .8 and is addressed to the

2 0 0 P a r k A v e n u e Assistant Commissioner for Patents, Washington, D .C .

N e w Y o r k , N Y 1 0 1 6 620231.

( 2 1 2 ) 8 0 1 - 9 2 9 4

Signature of Pe o Mailb1g Correspondence

Linda Garramonecc :

Typed or Printed Name of Person Mailing Correspondence

C opyright 1994-97 LegalStar P12SMALUREV05



0

MA Y o 3 , 1000c c )

Docket Number : 150-061A

DEMARy'

RECEIVEDIN THE UNITED STATES PATENT AND T RADEMARK OFFICE

MAY Q a 2000

Applicant : Hudetz et a l . Group. 2700

Serial No . : 09/232,908 Examiner : D . Pan

Filing Dat e : January 15, 1999 Group Art Unit : 2783

Title (a s amended) : SYSTEM AND METHOD FOR AUTOMATIC ACCESS

OF A REMOTE COMPUTER OVER A NETWORK

Hon . Commissioner of Patents

and TrademarksWashington, D . C . 20231

SIR :

AMENDMENT

This Amendment is submitt ed in response to t he

office act ion mailed on November 29, 1999 . A request t o

extend the t ime to respond by two mont hs is enclosed .

herein, which extends the time t o respond until April 29,

2000 . Since that da te is a Saturday, t his 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:

O n Pa ge li ne 9, a ft er "wi th" i nser t o ne a spec t o f . -

On Page 5, line 27, after "network" insert the!

01101HO



`— following para graphs:

- - In accordance with another a spect

of the invention, networkaddresses are directly encoded

into bar code format . In this

manner, the necessity of ma nually

entering the address i-s

eliminat ed . Users can more quickly

review published lists of Web

Sites,or other locations . The bar-

coded address can also be printed

on removable stickers or

detac hable cards, allowing users

to rea dily clip the stickers or

cards for fut ure reference.

In accordance with yet another

aspect of the invention,navigational' s commands (in addition

J to addresses) can be published

together in both human-reada ble

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 t o a ccess part icularservices, files, a nd documents on

the Internet or the proprietaryon-line services . Rather than

manually enter t hese commands, the

user selects , a desired , command by

scanning its associat ed bar code.

The , output of the bar code reader

is accepted by t he browsersoftware a s the selected command.

On page 7, line 20, after "computers" insert

the following paragraphs :



~_ -- FIG . 8 is a block iagra

computerized appara tus for

interfacing with a computer

network in accordance with a

second embodiment of theinvention.

FIG . 9 is an idea lized perspective

of the document of FIG 8 ha ving a

r 1 network a ddress in both bar code

and human readable formats.

FIG . 10 is a flow chart

illustra ting the operation of : t h e

apparatus of FIG . 8 in accordance

with the invention . --

On page 18, line 7, after "address" insert the

following paragraphs:

An example of t he direct coding of

network a ddresses is shown in the

illustrat ed FIGS . 8-10 . Referring

to FIG 8, a block diagra m of the

computerized apparat us 10 for

interfacing with a computernetwork in accordance with the

invention is illustrated.

Apparat us 113 includes a computer

114, which may be an IBM

compatible personal computer.

/3 Att ached to,computer 114 by a

r5̀

suitable input/output interfa ce

. 115 is a modem 116 . Also attached

to'computer 114 via a n -

input/output int erface 118 is a

bar code reader 120 . Bar code

--reader 120 is designed to read

conventional bar codes . Bar code

technology is described generally

in U . S . Pat No . 5,115,326 issued

May 19, 1992 and entitled "Method

of Encoding an E -Mail Address in a

Fax Message and Routing the Fax



Message to a Destination and

Net wo rk ", a nd 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 a dopted for ,

electronic communicat ion 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 electronica lly

connected by a suitable

communicati on link 126 to a remoteserver 128 . For purposes of

illustration, . we assume that

remote server's 128 numeric

network address is 200 .98 .154, and

tha t t he 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 andtelephone link 122 . Computer 114 is

also equipped with software (see

FI G . 10) such as Netscape Navigator

brand Web browser software (version

1 0) which enables it t o 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 software130 sends service provider 124 a

request for the informat ion

contained at address corresponding

to the mnemonic sample@www .com . As

explained above, t hat mnemonic

d `4



Using the address sample@www .com,

service provider 124 routes the

request t o remote server 128 via

communication link 126 . Remote

server 128 responds by sending the

desired informat ion via

communication link 126 to service

provider 124, which relays the

information t o computer 114 via

modem 116 and telephone link 122.

once the informat ion is received

by computer 114, browser software

130 displays t he information in a

useful format for the user.

In accordance with the invention,

a document 132 is provided.

Document 132 , may be a magazine

art icle, 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 r eadable

information 134 includes remote

server's 128 mnemonic address -

http ://sample@www .com . A bar-code

indicia 136 is placed near human

readable information 1 3 , 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 versionof t he mnemonic address . Under

that arrangement, the bar-coded

digits would correspond to

alphanumeric symbols of t he

mnemonic address . For example, the



T

bar coded number 1 1 97 1 1 . .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 rea der

120 . Bar code reader 120 generates

a signal on input/output interfa ce

118 corresponding to the numeric

address encoded by bar code 136

(which for purposes of

illustra tion we assume to be

257004-00220, as shown in FIG . 9).

Browser software 130 on computer114 reads the numeric address via

input/output interface 118, a nd

forwards it t o service provider

124, along with a r equest for

information contained at the

~ (Jlocation corresponding to tha taddress . Service provider 124

determines that the numeric

address is that of r emote 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 . tea d 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

att empts 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 tra nsmits the input

read at block 138 to service



provider 124 . There are other ways

to ha ndle input from bar code

reader 120, and more sophisticatedtechniques maybe used in act ual

commercial embodiments of t heinvention.

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

contained on remote server 128 is

received by browser softwa re 130via service provider 124 . Once

received, the data is available

for what ever,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 t he mnemonic

address sample@www .com is

eliminated . Instead, the numericaddress is obtained from the bar

code indicia 1 . 3 6 by use of bar

code reader 120 . As explained

above, bar code 136 could conta in

.the mnemonic as well as numeric

address . Browser software could

be programmed to a ccept either

format ( mnemonic or numeric) as

input from bar code reader 120,

with the default expecta tion being

that the bar coded data is a

numeric address unless the userotherwise 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

)a1

7



136,can conta in 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 alternativesare possible . For example, in lieu

of a ba r code scanning device, a

card r eader could be employed . The

card reader would read a magnetic

J stripe affixed to a card or ot herprinted matt er . The car d would

contain human-readable informationabout a net work resource, and the

magnetic strip would conta in the

resource's numeric or mnemonic

address in machine-readable

format . Alternatively, a RF data

collection scanner or CCD scan-

system could , be used . Bar code

symbol 126 could also be

associat ed with specific commands

such as "forward", or "back," orcommand sequences used to a ccess

information . - -

IN THE CLAIMS:Cancel claims /1/and add t he following new

claims:

- - 1 3 6 . A method of connecti ng a user computi ng device to

one of a pluralit y of remote computers available for

communication over a network comprising:

a ) reading a data carrier modulated with an index;

b ) accessing a dat abase with the index, the database .

comprising a plurality of records tha t link an



K

index to a pointer which identifies a remote

computer on the network;

c) extracting a pointer from the dat abase as a

function of the index ; and

d) using the pointer to est ablish communication with

the remote c omputer identified t hereby.

P D A ! The method of claim &5 wherein the step of reading a

dat a ca rrier modulated with an index comprises the step of

reading a light pat tern emanating from an object and

demodulating the light patt ern to obta in the index.

7 The method of claim 'wherein the step of reading a

light pat tern emana ting from an object and demodulating the

light pat tern t o obtain t he index comprises scanning a bar

code symbol encoded with the index.

3J3,e The method of claim .3'~ wherein the bar code symbol is

encoded in accordance with a n extrinsic standard.

I

~ Q 3 The method of claim .4 wherein t he index is at least a

porti on of a Universal Product Code.

The method of claim - )* I wherein the index is at least a

portion of a EAN Code . f

~The method of claim Jel wherein the index is at least a

portion of an ISBN code.

` . 4 4 f . 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 pat tern t o obta in the index comprises using optica l

character recognition techniques.

1 012 . The meth od of claim,2-f wherein th e step of reading a

data carrier modulated wit h an index comprises receiving a

si gnal emanati ng from an arti cle of commerce, the s ig nal

being modulated with t he i ndex.

I

The method of claim - - 1 wherein th e step of reading a

data carrier modulated with an index comprises i nputti ng

i nto the user computi ng device an audi ble signal modulated

wit h information correlated,to the index.

l a-' ( t9 4 ' . The meth od of claim A .3 wherein th e step of inputti ng

i nto the user computi ng device an audi ble signal modulated

wit h i nformation correlated to the index compris es the use

of voice recogniti on techniques.

fb I

A- ' The method of claim wherein the step of reading a

data car rier modulated with an index comprises inputting

into t he user computing device an RF signal modulated with

information correlat ed to the index.

4-1 5 *. The method of claim ~-ff wherein the step of reading a

dat a ca rrier modulated with an index comprises accessing a

magnetic card with a magnetic card reader.

)T t

4-1 The method of claim -3 wherein the steps of accessing

a dat abase and extracting a pointer therefrom are

carr ied out on t he user computing device.

1 0



Y

IhLW. The method of claim 3~ wherein the st eps of accessing

a dat abase and extracting a pointer therefrom are

carr ied out on a server computer locat ed remotely fromthe user computing device.

9 - 1 . The method of claim -e wherein the dat abase is

distributed over more than one computer.

( The method of claim 3 , T wherein the pointer c omprises a

network a ddress.

,r . The met ho d o f c la im 3 ~ 3 wherein the pointer comprises a

Uniform Resource Locat or.

a 0 ►

,f . The met ho d o f c la im 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.

3a J I

,RS . The method of claim ,i-~ wherein t he step of accessing a

data base with an index comprises the steps of using

only the first field of the index to a ccess the

database . _

a ~ a3The method of claim . 5 - 5 wherein a plurality of indexes-

having the same first field and different second

fields will result in extra ction of t he same pointer.



' F.' pqThe method of claim Z 6 " wherein the first field is a

manufact urer identificat ion number and the second field is

a product identification number.

~The method of claim .~ wherein the step of using the

pointer t o establish communicat ion with the remote computer

identified thereby is executed automatica lly by the user

computing device without user int ervention.

1~ The method of claim .54 wherein the automa tic

communicat ion by t he user computing device with the r emote

computer is executed by a web browser program r unning on

the user computing device.

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


identified thereby is executed by a user selecting

hypertext link ret urned to the user computing device by the

database.

f f l I•61 . The method of claim s3 wherein the network over which

the user computing device esta blishes communicat ion with

the remote computer is a wide area network.

~l3 6,T he me tho d o f c la im whe re in the wi de ar ea ne two rk is

the Internet.

31 '. The method of claim 6X wherein the wide area network

is a proprieta ry online service .



3(.The method of claim j g-~ wherein the dat abase is resident

on an online service provider computer with which the

user computing device has esta blished direct

communication.

~~ .The method of claim b . 4 wherein the online service

provider computer additiona lly provides a gateway t o the

Internet.

.The method of claim 3-3' wherein access to the data base

requires entry of a password.

35I

b - 1 .The method of claim3 wherein the dat abase is

associated with a search-engine.

3T6 ' . A system comprising:

a. a user computing device;

b. an input device associated with t he user computing

device, configured to read a data carrier modulated

with an index;

c.means for storing a data base comprising a plurality

of records that link an index to a point er which

identifies a remote computer;

wherein the user computing device comprises:

means for a ccessing the database to extract a

pointer from the dat abase as a function of the

index ; and

_means for using the pointer t o establish

communication wit h the remote computer identified

thereby .

r

J 1 3



3 3(P

The system of claim 6e wherein the user input device

comprises means for reading a light pat tern emana ting from

an object and demodulating the light pattern to obtain the

index.

3 O 3 ,The system of claim b ,6 wherein the means for rea ding a


light pat tern t o obta in the index comprises means for

scanning a bar code symbol encoded with the index.

34

31

The system of claim - I -f1 wherein the means for scanning

a bar code symbol is adapted t o scan a ba r code symbol

encoded in accordance with a n extrinsic standard.

r . The system of

configured to rea d

of a Universal Pro(

.~. The system of

configured to rea d

of a EAN code .

CO

claim ,wherein the input device is

an index comprising at lea st a port ion

3uct Code.

claim . 6 Q wherein the input device is


43 3 J ~ ,

. 7 4 . The system of claim 6. 6 wherein the input device is

configured to rea d an index comprising at least a port ion

of an ISBN code .

claim 4?9 wherein the input device is


3?

claim R5 wherein the means for reading a

at ing from an object and demodulating t he

The system of

configured to rea d

of an ISSN code-.

D

~6. The system of

light pat tern eman+



light pat tern t o obta in 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 emanat ing from an art icle of

commerce, the signal being modulated with the index.

K(O No'4e The syst em of claim .6-9 wherein th e input device

compris es means for i nputti ng int o the user computi ng

device an audible si gnal modulated with i nformation

correlated to th e index.

`f - 7 4 1 1 0,7.? ' . The system of claim 7 , 4 T wherein the means for inputting

into t he user computing device an a udible signal modulat ed

with information cor relat ed to the index is configured to

utilize voice recognition t echniques.

L1 $36

j i - 6 . The syst em of claim ,C9 wherein t he i nput device

comprises means for inputting an RF signal modulated with


;je . The system of claim .r8 wherein the input device

comprises means for rea ding a magnetic stripe ca rd.

S ~ •3b

The system of claim .09 wherein the means for storing a

data base is located on t he user computing device.

673 (0d a - 5 . The system of claim fry wherein the means for storing a

database is located on a server computer locat ed

remotely from t he user computing device.

1 5

J



. F ,

C

The system of claim 6Pf wherein the means for storing a

database is distributed over more than one computer.

S3 3~The system of claim 60 wherein the pointer comprises a

network address .

g ( v

,P6 . The system of claim 64 wherein the pointer comprises a

Uniform Resource Locat or.

~ $ T he sy st em o f c la im r p B wherein the pointer comprises

the name of a remote computer.

. 8 - 9 . T he sy st em o f c la im b o t wherein the pointer comprises

an IP address.

7 3 6~ J . The system of claim ~ wherein t he index is comprised

Vie of a first field a nd a second field.

The system of claim &l wherein the means for accessing

a dat abase with an index comprises means for using

only the first field of the index to a ccess the

database .

gJr . The system of claim ,S9 wherein a pluralit y of indexes

having the same , first field and different second

fields will result in extra ction of t he same pointer.

6 0 j7~The system of cla im SK wherein the first field-is a

manufacturer ident ificat ion number and the second field is

a product identificat ion number.

1 6



3 6 ,~o6 . The system of claim wherein the means for using the

pointer t o esta blish communicat ion with the remote computer

identified thereby executes aut omat ically by the user

computing device without user intervention.

, 1 ~ 4 . The syst em of claim .9-S wherein the automati c

communicati on by the user computi ng device wit h the remote

computer is executed by a web browser program running on

the user computing device.

y + 5 . The syst em of claim .19 wherein t he means for using t he

pointer to establish communicati on with t he remote computer

identified thereby executes by a user selecting hypertext.

link returned to th e .user computi ng device by the database.

! o ~{ 36

9 ' r .The system of claim Erb wherein .the network over which

the user computing device esta blishes communicat ion with

the remote computer is a wide area network.

901 .The sys tem of claim 961wherein t he wi de area network is

th e Internet .

Ilele

.The system of claim . Y 6 wherein the wide area network is

a proprietary online service.

0 66

AX.The system .of claim OT wherein the data base is resident

on an online service provider computer with which the

user computing device has esta blished direct

communication .

1 7



(0 7 C 7-3-z~ . The system of claim k9 wherein the online service

provider computer additionally .provides a gateway to the

Internet.

69 36,02 . The syst em of claim r8 wherein access to the database

requires entry of a password.

7d. The system of claim j&6 wherein the database is

associated with a search engine.

X6' 3 . A user computing device comprising:

a . an input device configured to read a data carrier

modulat ed with an index ; and

b. computer processing means for executing a soft ware

program adapted to:

utilize the index to access a dat abase

n n ~ ~ comprising a plurality of records tha t link an

W index to a pointer which identifies a remote

computer;

retrieve from the databa se a pointer as a

function of the index ; and

use the pointer to esta blish communicat ion

with the remote computer identified thereby . .

' 7 yt6 The user computing device of claim 1. @ 3 wherein the

user input device comprises means for rea ding a light

pat tern emana ting from an object a nd demodulating the light

pattern to obtain the index.

* 7 3 - 9z19~ . T he user comput ing device of cla im wher ein t he

means for reading a light pat tern emana ting from an object

and demodulat ing the light patt ern to obta in the index



comprises means for scanning a bar c ode symbol encoded with

the index.

'/-~ ' 73

1 .9-' . The user computing device of claim wherein themeans for scanning a ba r code symbol is .adapted to scan a

bar code symbol encoded in accorda nce with an extrinsic

standard . '

'7G 7(The user computing device of claim k63 wherein the

input device is configured to read a n index comprising at

least a port ion of a Universal Product Code.

77 7(

`. ,9-e . The user computing device of claim .1' wherein the

t ~ input device is configured to read an index comprising at

Y~

least

7$

a portion of a E AN code .

71

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

input device is configured to read an index comprising at

least a portion of a n ISBN code .

179.

11k 1 R ~ . The user computing device of claim 2 . 9 13 wherein the

input device is configured to read a n index comprising at

least a portion of a n ISSN code.

7s1 - The user computing device of

means for reading-a light pattern

and demodulating the light pat ter

comprises means for using optica l

techniques .

7yclaim L.9t wherein the

emanating from a n object

a to obta in the index

character recognition

112 . The user computing device of claim J ,0 , 13 wherein th e

i nput devi ce is adapted to receive a sig nal emanating from



an a rtic le of commerce, the signal being modulated with t he

index.

a/ I/17~. The user computing device of claim I Q - 3 wherein the

input device comprises means for inputting into t he user

computing device a n a udible signal modulat ed with


, 1 4 - 4 . The user computing device of claim ;,if wherein the

means for inputting into t he user computing device an

audible signal modulated with information corr elat ed to the

index is configured to utilize voice recognit ion

techniques .

71]X~ . The user computing devi ce of claim I - 9 ' 3 wherein th e

input device compris es means for inputti ng an RF si gnal

modulated with information correlated to the index.

~~ 7lJ-rg . The user computing device of claim X93 wherein the

input device comprises means for reading a ma gnetic stripe

card.

Bi' '1(, k 1 - 1 . The user computing device of claim 7-0'3 wherein the

software progra m is ada pted to utilize the index to

access a da ta base located on t he user computing device.

7(,yl~ . The user computing device of claim ) .91 wherein the

software progra m is ada pted to utilize the index ' to

access a dat abase located on a server computer remote

from the user computing device.

1 . 2 0



4 P I ! - 9 . The user computing devi ce of claim ; o @ n wherein the

software program is adapted to uti lize the i ndex to

access a database dist ributed over more than one

computer.

. The user computing

index is comprised

field, and wherein

access a database

index .

? (device of claim ke3 wherein the

of a first field and a second

the software program is adapted to

with only the first field of the

y2'r The user computing device of claim 1,2-a wherein apluralit y of indexes havi ng the same first field and

different second fields will result i n extraction of

the same pointer.

go ra ~ 4 - 2 2 . The user computing device of claim 1 . 8 ' 3 wherein the

software progra m is ada pted to use the pointer to esta blish

communicat ion with the remote computer identified thereby

automatically without user intervention.

e / goThe user computing device of claim ]~ wherein the

automa tic co mmunicat ion by the user computing device with

the remote c omputer is executed by a web browser program

running on the user c omputing device.

G1 2 r !1. 2 < . The user ' computing device of claim . 6 0 3 wherein th e

software progra m is ada pted to use the pointer t o establish

communication wit h . the remote computer identified thereby

by using a user-selected hypertext link ret urned to the

user computing device by the dat abase.

2 1



q3 ' 7 I

. 1 .2~ The user computing device of . claim further

ada pted to esta blish communicat ion with the remote

computer over a wide area network.

C 7 4 . Q3The user computing device of claim .14?5 further adapted

►~ to est ablish communication with t he remote computer over

the Internet.

Rs - 173The user computing device of claim .1- ' further adapted

to esta blish communication with the r emote computer over

a proprieta ry online service .--

REMARKS

The specification ha s been amended to include mat erial

from parent applicat ion serial number 08/538,365, which was

obta ined from provisional applicat ion serial number

60/000,442, filed on June 20, 1995, and entitled "Method of

an Apparat us 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 t he provisional a pplicat ion.

Applicant has also submitted herewith two new sheets

of drawings containing FIGS . 8-10, which correspond - to

FIGS . 1-3 of the provisional application . To avoid

duplicat e reference numerals, refer ences 10 through 144 of

in FIGS . 1-3 of the provisional application have been

changed to 113 , through 144, respectively .



T

The textual mater ial inserted into the present

applicat ion by virtue of these a mendments may be found on

pages 4-8 of the provisional applicat ion . Minor editorial

changes were made for purposes of rea dability a nd

conforming references to t he drawings to the revised figure

and reference numerals.

The amendments add no new mat ter t o the specification.

The Examiner is invited .to contact Applicant's att orney

Anthony R . Barkume directly at (212) 801-9294 should he or

she have any questions.

In the office act ion, the Examiner rejected pending

claims 1-4 as being unpatenta ble 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 indicat ed that claims 5-11 would be-allowable

if rewritten t o include all the limitations of t he base

claims from which they depend . Applicant r espectfully

disagrees with the Examiner's rejection o f the claims, but

has ca ncelled claims 1-11 and a dded new claims 33-127 to

more clearly define the applicant s' invention over the

prior ar t of r ecord 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 a rt of

:record . Independent claim 33 recites a method of

connecting a user computing device to one of a plurality of

remote computers availa ble for communicat ion over a network

comprising the steps of (a) rea ding a dat a ca rrier



modulat ed with an index ; (b) accessing a databa se with the

index, the dat abase comprising a . .plurality of r ecords that

link an index to a pointer which identifies a remote

computer on the network ; (c) extracting a pointer from the

database as a function of the index ; and (d) using the


identified thereby.

New claims 34-67 depend from claim 33 and a dd

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 specificat ion (see, for example, Figure 3 a nd Figure

8 ) . Claims 36-40 describe by way of example the va rious

sta ndards that may be used (see specificat ion page 10, line

19 thro ugh page 11, line 11) . Claim 41 recites the use of

OCR technology, as explained in the specificat ion for

example at page 11, lines 19-23 . Claim 42 relies on the

use of an art icle of commerce ., which is explained for

example at pa ge 9, line 32 et seq . Claims 43 and 44 relate

to a nother way (a udible, voice recognition) of inputting

the required information t o the user computer, as explained

for example at page 8, lines 20-22 . Claim 45 relates to

the use of RF dat a t ransfer, as disclosed in the textual

mater ial added by way o f : t h i s Amendment . Claim 46 relat es

to t he use of a magnetic str ipe card, as also disclosed in

the t extual materia l added by this Amendment.

Claims 47-49 recite the var ious locations of the

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

2 4~ ~



various embodiments of the pointer t hat is ret urned by the

dat aba se table, as described in the background section, and

throughout the description of t he invention.

Claims 54-57, which recite various . limitations on the

construct ion of the index used to access the data base, are

disclosed in the specification a t pa ge 11, line 25 through

page 12, line 31.

Claims 58-59 describes the automa tic connect ion to t he

remote co mputer, for example by a web browser, as described

on page 17, lines 1-11 . Claim 60 describes t he embodimentwherein the user selects t he desired hyperlink to t he

resource, as described in the sa me section and shown in

Figure 5.

Claims 61-65 describe the va rious network

configurations that are congruous with the invention, as

described in the specification a t pa ge 16, lines 8-25.

Claim 66 covers the use of a password for using the system,which is set fo rth a t page 16, lines 26-36 . Claim 67

describes the integrat ion of the invention with a searc h

engine, as set forth a t page 13, lines 10-15.

Claims 68-102

New claims 68-102 describe t he present invention in

the format of , a system, wherein independent cla im 68

recites system comprising a user computing device ; an input

device associated wit h the user computing device,

configured to read a dat a ca rrier. modulated with an index;

means for storing a dat abase comprising a plurality of

records tha t link an index to a point er which identifies a



remote computer ; wherein the user computing device

comprises means for accessing the data base to extract a

pointer from the data base as a function of the index ; and

means for using the pointer to establish communicat ion with

the remote computer identified thereby . Claims 69-102

depend from claim 68 and recite limitat ions similar t o the

independent claims 34-67 as discussed above.

Claims 103-127

New claims 103-127 describe the user computing device

of t he present invention, wherein independent claim 103

recites a user computing device comprising an input device

configured to rea d a data carr ier 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 r ecords that link an index to a

pointer which identifies a remot e computer, ret rieve from

the dat aba se a pointer as a function of the index, and use

the pointer t o establish communication with the remote

computer identified thereby . Claims 104-127 depend from

claim 103 and recite limitat ions similar t o the independent

claims 34-67 a s discussed above.

2 6



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.

Da t e : v ~'bd0 Respectfully submitted,

AAthon*y R . Barkume

Reg . No . 33,831

Attorney for Applicant

(212) 801-9294

27



R E M O T E SERVICE

S E R V E R P R O V I D E R 204

22 S ZZIo Z/D

222

234236

2//o M O D E M l

Z/Z C O M P U T E R

D O C U M E N T

i

~ Z321

B A RC O D E

R E A D E R

220Z/8



232

Fj1p : I I s a m p l e c .ww. eeM

39

2,36

0

FIG 9

238

READ

SCANNER

-INPUT ' ' ,

NO

INPUT?

240 T,>

r---30

YES

-TRANSMIT

ADDRESS 24Z

L--~RECEIVE~Z4*

D A T A

FIG - 10



AMENDMENT TRANSMITTAL LETTER (Small Entity) D o c k e t N o .

Applicant(s) : H u d e t z e t a l ./C

15 REEIV E

S e r ia l N o . F i l in g D a t e Examiner G r o rt&A 2 0 0 0

0 9 /232,9 0 8 Ja n ua ry 15 , 19 9 9 D . P a n 7 56drou2700

I nvent ion : SYSTEM AND METHOD FOR AUTOMATIC ACCESS OF A REMOTE COMPUTER O R A NETWORK

01P ~

o,

TO THE ASSISTANT COMMISSIONER FOR PATENTS:

T r a n s m i t te d h e r e w i t h is an amendment in the above-identified application.

® Small Entity status of this application has been established under 37 C FR 1 .27 by a verified statement

p r e v i o u s l y s u b m i t te d .q A verified statement to estab lish Small Entity status u nder 37 FR 1 . 2 7 is e n c l o s e d .

The fee has been calculated and is transmitted as shown below.

C L A I M S A S A M E N D E D

C LAIMS REMAINING HIGHEST # NUMBER EXTRA ADDITIO NALRATE

AFTER AMENDMENT PREV . PAID FO R C LAIMS PRESENT FEE

TOTAL CLAIMS 9 5 - 2 0 = 7 5 x $ 9 . 0 0 $675 . 0 0

INDEP. CLAIMS 3 3 = 0 x $ 3 9 . 0 0 $ 0 . 0 0

Multiple Dependent C laims (check if applicable) q $ 0 . 0 0

TOTAL ADD ITIONAL FEE FO R THIS AMENDMENT $ 6 7 5 . 0 0

q N o a d d i t io n a l fe e i s r e q u i r e d f o r a m e n d m e n t .q Please charge Deposit Accoun t No. in the amount of

A duplicate copy of this sheet is enclosed.

® A check in the amount of $ 6 7 5 . 0 0 to cover the filing fee is e n c l o s e d .q The Commissioner is hereby authorized to cha rge payment of the following fees associated w ith this

communication or credit any overpayment to Depos it Account No.A d u p l ic a t e copy of this sheet is enclosed.q Any additional filing fees required under 37 C . F . R . 1 . 1 6 .

q application processing fees under 37 CFR 1 . 1 7 .ytent

D a t e d : M a y 1 , 2000Signature

A n t h o n y . B a r k u m eR cg . N o . 33,831 1 c e r t i fy t h a t t h i s d o c u m en t a n d fee i s b e i n g ', d ep o s i t ed

Attorney for Applicant am Ma y 1 , 200 0 with the U .S . Pos tal :Service as

2 0 0 P a r k A v e n u e f i rs t c lass mai l under 37 C .F.R . 1 .8 and is addressedito the

NewYork, ; N Y 1 0 1 6 6 . Assistant Comm issioner for Patents, Was hington, D .C.

( 2 1 2 ) 8 0 1 - 9 2 9 420231 . `

Signature ofPerso~ ing Correspondence

cc :Linda Garramone

T y p e d or Printed Name ofPerson Mailing Correspondence

P11 SMALUREV06 ,

I



CERTIFICATE OF MAILING BY~FIRST CLASS MAIL. (37 CFR 1.8) D o c k e t N o .

Applicant(s) : Hudetz et a l . 150 - 0 61AF4 F= Prp n I P V— on

Serial No . Filing Date Examiner MEP

091232,908 J a n ua ry 15 , 19 9 9 P a n , D . MAr 1 9 8 2000

In v en t i o n : S Y S T E M A N D M E T H O D F O R A U T O M A T I C AC C E S S O F A R E M O T E C O M P U T E R CWJP 2700NETWORK

v

M A Y 0 3 2000 -0w

~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 , 200 0(Date)

L i n d a G a r ra m o n e(Typed or Printed Name of Person Mailing Correspondence)

(Signa ure of Person g Correspondence)

Note : Each paper must have i ts own cer t i f icate of mai l ing .



Q

I

0 5 A

0 1 F

TR, .NSMITTAL OF INFORMA T JON DISCLOSURE STATEMENT D o c k e t N o .

(Under 37 CFR 1.97(b) or 1.97(c)) 150-061A1

In Re Application O f : Hudetz et al .

C ..' r

S e r ia l N o . Filing Date Examiner G r o u p Arpinit n09/232,908 J a n u a r y 15, 1999 P a n , D. 2788 .9 1 4 1%

Tit le : SYSTEM AND METHOD FORAUTOMATIC ACCESS OF A REMOTE COMPUTER OVER A NETWORK

1P

Address to:

M A Y 0 5A s s i s t a n t C o m m i s s i o n er fo r P a t en t s

Was hington, D.C . 2023 1

) ~ ' $ADEM37 CFR19 7 ( b ) .1 . q The Information Disclosure Statement su bmitted he rewith is being fi led w ithin three mon ths of the

filing of a national application ; within three months of the date of entry of the national stage as set forthin 37 CFR 1 .491 in an international application ; or before the mailing date o f a first O ffice Action onthe merits, whichever event occu rs last .

3 7 C F R 1 . 9 7 ( c )

2 . ® The Information D isclosure Statement su bmitted herewith is being filed after three months of the filingof a national app lication, or the date o f entry of the national stage as se t forth in 37 C FR 1 .491 in aninternational ap plication ; or after the mailing date of a first O ffice Action on the me rits, which everoccurred last but before the mailing date of either:

1 . a Final Action under 37 CFR 1 .113, or

2 . a Notice of Allowance under 37 C FR 1 . 3 1 1 ,

whichever occurs first.

Also submitted herewith is:

L ) a certification as specified in 37 C FR 1 . 9 7 ( e ) ;

O R

2 9 the fee s et forth in 37 CFR 1 . 1 7 ( p ) fo r s u b m i s s i o n o f a n In f o r m a t io n D i s c lo s u r e S t a t e m e n tu n d e r 3 7 C F R 1 . 9 7 ( c ) .

/ 2 0 0 0 H L U A N G 0 0 0 0 0 0 0 6 0 9 2 3 2 9 0 8

• 1 2 6 2 4 0 . 0 0 O P

Copyr igh t 1996 Lega lso f t P10AIREV01



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

(Under 37 CFR 1.97(b) or 1 .97(c)) 150-061A

In Re Application Of : H u d e t z e t a l . o 3C

C w

Serial No . Filing Date Examiner Group ArrQnit

0 9 /2 3 2 , 9 0 8 January 15, 1999 P a n , D . 27830 c° a

Title : SYSTEM AND M E T H O D FOR AUTOMATIC A C C E S S OF A R E M O T E C O M P U T E R O V E R A NETWORK

O p

M A Y 0 5 2 0 0

2~ Payment of Fe ek

7ItApFMPe~ (Only complete if Applicant e lec ts t o pay the f ee set forth in 37 C FR 1 .17(p))

® A check in the amount of $ 2 4 0 .0 0 is attached.

q The Assistant Commissioner is hereby authorized to charge and credit Deposit Account No.

as described below . A duplicate copy of this sheet is enclosed.

q Charge the amount of

q Credit any overpayment.

q Charge any additional fee required.

Certificate of T r a n s m i s si o n b y F a c s i m i l e * Cert i f i ca te of Ma i l ing b y First Class Mail

I cer t ify that th is docume nt and au thor izat ion to charge de pos i tI cer t ify that th is docume nt and fee is being dep os i ted on

account is being facsimile transmitted to the United States05 /02 /2000 wi th the U .S . Postal Service as firstclass mail under 37 C.F .R . 1 .8 and is addressed to the

Patent and Trademark Off ice (Fax . N o . ) o nAssistant Commiss ioner fo r Patents, Washington, D .C .

(Date) 2 0 2 3 1 .

Signature Signature of Pers ailing Correspondence

Linda Garramone

Typed orPrinted Name of Person Signing Certificate Typed or Printed Name ofPerson Mailing Correspondence

*This certificate may o n ly be u s e d if p a y i n g b yunt .

Dated : May 2 , 2 0 0 0

ABarku

deo

Signature

m e , E sq .

R e g . No . 33,831

Greenberg Traurig

Met Life Bui l d ing200 Park A v e n u e

N e w Y o r k , N Y 10166

( 2 1 2 ) 8 0 1 - 9 2 9 4

cc :

Copyright 1996 Legalsoft P10A/i2EV0i

MMnC

D



r

0P SUPPLEMENTAI.

INFORM ION DISCLOSURE % .,iTATION

MAY O 5 2000"1s e v e r a l s h e e t s if n e c e s s a r y ) #

A T T Y D O C K E T N O . S E R I A L N O .1 5 0 -0 6 1 A . 0 9 /2 3 2 , 9 0 8

A P P L I C A N T ( S )Hudetzetal.

F I L I N G D A T EJanuary 15, 1999

G R O U P ..~3

T R A D E M P Q U .S . P A T E N T D O C U M E N T S V0

'EXAMINER

I N I T I A L

DOCUMENT NUMBER D A T E NAME CLASS SUBCLASS F I L I A T E C

IF APPROPRI

5 , 9 0 5 , 2 5 1 0 5 / 1 8 / 9 9 K n o w l e s Z, b

5 ,9 1 3,2 1 0 0 6 /1 5 /9 9 Call

~L 5 , 9 1 8 , 2 1 4 0 6 /29 /99 Perkowski

5 , 9 3 2 , 8 6 3 0 8 / 0 3 / 9 9 Rathus et al.

5 ,9 38 ,72 6 0 8 /1 7/9 9 Reber et al.

r,

f̂ ~ 5 , 9 4 0 , 5 9 5 0 8 / 1 7 / 9 9 Reber et al .O

Z/

5 ,9 5 0 ,1 73 0 9 /0 7/9 9 Perkowski

5 ,9 71 ,2 77 1 0 /2 6 /9 9 Cragun et al. ~6~ t c j

~– 5 , 9 9 5 , 1 0 5 1 1 /3 0 /9 9 Reber et al.

6 ,0 1 2 ,1 0 2 0 1 /0 4/ 2 0 0 0 Shachar

6, 0 2 7, 0 2 4 0 2 /2 2 /2 0 0 0 K n o w l e s D f

F O R E I G N P A T E N T D O C U M E N T S

DOCUMENT NUMBER DATE C O UNTRY C LASS SUBC LASS TRANSLATION

YES N O

O T H E R D O C U M E N T S (Including Author, Title, Date, Pertinent Pages, Etc .)

F a c h h o c h s c h u l e B i e l e fe l d , U n iv e r s it y o f A V p l i e d S c i e n c e s , H o c h s c h u l b ib l i o t h e k ~ ,

Pages 1-27

Fac hochschule Bielefeld= _U n iv e r s i t y A p p l i e d S c i e n c e s , o c h s c h u l b ib l i o t e k G- ~ A V A "O'

E X A M IN E R D A T E C O N S I D E R E D

' E X A M I N E R : Initial if reference co nsidere d, /

W It

h e r o r n o t c i ta t i o n is i n c o n fo r m a n c e w i t h M P E P 6 0 9 ; D r a w l in e . th r o u g h c i t a t io n I f n o t in c o n f o rm a n c e a n d n o tc o n s i d e r e d . I nc lude copy o f th is fommu nica t ion to a pp l i can t .

F o r m P T O - A S 2 0 P09C/REV03 Patent an d Trademark Office' U .S . DEPARTMENT OF COMMERCE

( a ls o f o r m P T O - 1 4 4 9 ) ( ( ( ~ ~ ~PAGE 1 OF 1

i

JI



HTML Version from RFC Dr ment Page 1 of 27 I

Fachhochschule- BielefeldUniversity of Applied Sciences

Network Working Group

Request for Comments : 882

P . Mockap

November

DOMAIN NAMES - CONCEPTS and FACILITIESThis RFC introduces domain style names, their use

for ARPA Internet mail and host address support,

and the protocols and servers used to implementdomain 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.

rINTRODUCTION

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 ; i t 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 registewith-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 .li z

database.

The problem for computer mail is more severe . While mail sys

implementers long ago recognized the impossibility of central

Mockapetris [Pa

ht t p ://www-bib . f l l -bi e l e fe l d . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5 1 1 1 0 0



HTML Version from RFC Df ment P a g e 2 o f 2 7

~FC 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, andconsequently force the mail user to know multiple address for

the capabilities of various forwarders, and ad hoc tricks for

passing address specifications through intermediaries.

These problems have common characteristics that suggest the n

of any solution:

The basic need is for a consistent name space which will b

used for referring to resources . In order to avoid the

problems caused by ad hoc encodings, names should not cont

addresses, routes, or similar information as part of the n

The sheer size of the database and frequency of updates su

that it must be maintained in a distributed manner, with 1

caching to improve performance . Approaches that attempt t

collect a consistent copy of the entire database will beco

more and more expensive and difficult, and hence should be

avoided. The same principle holds for the structure of th

name space, and in particular mechanisms for creating and

deleting names ; these should also be distributed.

The costs of implementing such a facility dictate that it

generally useful, and not restricted to a single applic , a tiWe 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 i s structuring information for t

name space itself, and resources that are described using

domain names and no nonstandard data.

We also want the name server transactions to be independen

the communications system that carries them . Some systems

wish to use datagrams for simple queries and responses, an

only establish virtual circuits for transactions that need

reliability (e .g . database updates, long transactions) ; of

systems will use virtual circuits exclusively.

Mockapetris [Pa

RFC 882 November


Elements of the solution

The proposed solution has three major components:

The DOMAIN NAME SPACE, which is a specification for a tree

structured name space . Conceptually, each node and leaf o.

ht t p: / /w w w - b ib .fh-blelefeld .de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



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 ' [ P a. _ - :

RFC 882 November


but the resolver views each of these databases as essentia

static.

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

of separate sets of local information called zones . The n

server has local copies of some of the zones .' The name.se

must periodically refresh its zones from master copies in

--files or foreign name servers . The name server must

concurrently process queries that arrive from resolvers 'us

the local zones.

In the interests of performance, these layers blur a bit . `Fo

example, resolvers on the same machine as a name server may s

a database and may also introduce foreign information for use

later queries . This cached information is treated differentl

from the authoritative data in zones.

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



HTML Version from RFC D , lment P a g e 4 o f 2 7

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 hor other hosts that the organization arranges to use.

Clients of the domain system should be able to identify tr

name servers they prefer to use before accepting referrals

name servers outside of this "trusted" set.

Access to information is more critical than instantaneous

Mockapetris [Pa_:RFC 882 November


updates or guarantees of consistency . Hence the update prallows 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

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



HTML Version from RFC D , ~ m e n t P a g e 5 o f 2 7

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 . Masfiles are text files that are read by a local name server, an

hence become available to users of the domain system . A stanformat 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 . '

_ [ _ P a .

November


Each host ' s name servers and resolvers are configured by a tosystem 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 frforeign 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

h t t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882.h tml~ 5 / 1 / 0 0

Mockapetris

RFC 882



HTML Version from RFC Dr ment Page 6 of 27

to be unique, with the exception of the root node, which has

null label . The domain name of a node or leaf is the path fr

the root of the tree to the node or leaf . By convention, the

labels that compose a domain name are read left to right, fro

most specific (lowest) to the least specific (highest).

Internally, programs that manipulate domain names represent t

as sequences of labels, where each label is a length octet

followed by an octet string . Because all domain names end at

root, which has a null string for a label, these internal

Mockapetris [Pa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _RFC 882 November


representations can use a length byte of zero to terminate a

domain name . When domain names are printed, labels in a path

separated by dots The root label and its associated dare 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 . Thilabel is the asterisk or "*" . An asterisk matches a single 1

Thus * .ARPA matches FOO .ARPA, but does not match FOO .BAR .ARPAThe 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, eachor 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.

+ O L O R S LAVORS TRUTH

+I I I NATURAL

RED BLUE GREEN

+I ICHOCOLATE VANILLA STRAWBERRY

In this example, the root domain has three immediate subdomai

COLORS, FLAVORS, and TRUTH . The FLAVORS domain has one immed

subdomain named NATURAL .FLAVORS . All of the leaves are also',

h t t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882.html 511100



HTML Version from RFC D , i m e n t Page 7 of 27

Mockapetris [Pa

RFC 88 2 November


domains . This domain tree has the names 1 1 "(the root), COLORRED .COLORS, BLUE .COLORS, GREEN .COLORS, FLAVORS, NATURAL .FLAVOCHOCOLATE .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 .FLAVOwould 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 o r 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 differentprotocol 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 cfield is two octets long and uses an encoding, that is stan

throughout the domain name system.

Mockapetris [Pa

RFC 882 November


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

data can be determined given the type and class fieldsi bu

always starts with a two octet length field that allows a

server or resolver to determine the boundaries of the reso

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882.html 511100



HTML Version from RFC D( ~ment P a g e 8 o f 2 7

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 length65535 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 accordto class, services can span class boundaries if they use

compatible resource data formats . For example, the domain na

system uses compatible formats for structure information, and

mail data decouples mail agent identification from details of

to contact the agent (e .g . host addresses).

This memo uses the following types in its examples:

A - the host address associated with the domain name

MF - identifies a mail forwarder for the domain

MD - identifies a mail destination for the domain

NS - the authoritative name server for the domain

SOA - identifies the start of a zone of authority

CNAME - identifies the canonical name of an alias.

This memo uses the following classes in its examples:

IN - the ARPA Internet system

CS - the CSNET system

The first type of resource record holds a host name to host

address binding . Its fields are:

+/<owner>

IA

I<class>I <class specific address>information

+/Mockapetris [Pa_RFC 882 November


The content of the class specific information varies accordin

the value in the CLASS field ; for the ARPA Internet, it i s t hbit ARPA Internet address of the host, for the CSNET it might

the phone number of the host . For example, F .ISI .ARPA might

two A records of the form:

+I F - .ISI .ARPAI A I IN I 1 0 .2. 0 . 5 2 I+-+ànd

+IF .ISI .ARPAI A I CS I 213-822-2112 I

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

h t t p : / / w w w - b i b . f h - b i e l e f e l d . d e / e p u b / d o c / i d o c / r f c / r f e - 0 8 0 0 - 0 8 9 9 / r f c 8 8 2 . h t m l l/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 I < class > I . <domain name>

+The <domain name> field is a domain name of the host that wilhandle mail ; note that this domain name may be . completely

different from the - domain name which names the resource recor

For example, F .ISI .ARPA might have two records of the form:

+IF .ISI .ARPAI MD I IN I F .IS I .ARPA Ia nd

+IF .ISI .ARPAI MF I IN I B .ISI .ARPA I

These records.mean that mail for F .ISI .ARPA can either bedelivered 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 ( P a g _ ,

RFC 88 2 November


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

record is the start of a zone ; the domain name given by the o

field of a NS record identifies a point in the name spaceiwhe

authority has been delegated, and hence marks the zone bounda

Except in the case where a name server delegates authority to

itself, the SOA identifies the top limit of authority, and NS

records define the first name outside of a zone . These resou

records have a standard format for all of the name space:

+I <owner> I SOA I <class>I <domain name, etc> I++

I <owner> I NS I <class>I <domain name> IThe-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

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



HTML Version from RFC Df ment P a g e 1 0 o f 2 7

never cached (otherwise they would create false zones) ; they

only be created in special name server maintenance operations

The NS record says that a name server which is authoritative

records of the given CLASS can be found at <domain name>.

Queries

Queries to a name server must include a domain name which

identifies the target resource set (QNAME), and the type and

of desired resource records . The type and class fields in a

can include any of the corresponding type and class fields th

are defined for resource records ; in addition, the query type

(QTYPE) and query class (QCLASS) fields may contain special v

that match more than one of the corresponding fields in RRs.

For example, the QTYPE field may contain:

MAILA - matches all mail agent RRs (e .g . MD and MF).

* - matches any RR type.

Mockapetris [Pag

RFC 88 2 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 ;thadoesn't have the requested information may know a name server

does ; a name server that returns a domain name in a relevantmay also return the RR that binds that domain name to an addr

Note that the QCLASS=* construct requires special interpretat

regarding authority. Since a name server may not know all of

classes available in the domain system, it can never know if

authoritative for all classes . Hence responses to QCLASS=*

queries can never be authoritative.

Example space

For purposes of exposition, the following name space is used

.the remainder of this memo:

+DDN ARPA CSNET

++----=+JCS ARMY NAVY UDEL UC I

+DTI MIT ISI UDEL NBS

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoe/rfe/rfe-0800-0899/r fc882.html 511100



HTML Version from RFC Dc --i . m e n t Page 11 of 27

+---+---+MS AI A B F

Mockapetris [Pag__-.

RFC 882 November


NAME SERVERS

Introduction

Name servers store a distributed database consisting of the

structure of the domain name space, the resource sets associawith 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

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 . h t m l 5 / 1 / 0 0




ways, the .normal method is to store the information acquired

Mockapetris [Pag

RFC 882 November


resolver when the resolver consults other name servers . In asophisticated 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 wsuch 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 tdiscretion of parent name servers, the following criteria ;are

by the root, and are recommended to all name servers because

are responsible for their children's actions:

1. It must register with the parent administrator of doma

2. It must identify a responsible person.

3. In must provide redundant name servers.

The domain name must be registered with the administrator to

name conflicts and to make the domain related information;

available to other domains . The central administrator may ha

further requirements, and a domain is not registered until th

central administrator agrees that all requirements are met.

There must be a responsible person associated with each domai

Mockapetris [Pag

RFC 882 November


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

update the domain related information, and to resolve any pro

ht t p: / /w w w - b ib .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 domaso 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 assthat the name server stores its RRs in sets where each set ha

of the RRs for a particular domain . Note that this databasestructure 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 . Forexample, relevant(MAILA,MF) is true and

relevant(MAILA,NS) is false.

right(NAME,NUMBER) returns a domain name that is the rightm

NUMBER labels in the string NAME.

Mockapetris [Pag

RFC 882 November


copy(RR) copies the resource record specifiediby

into the response.

The name server code could be represented as the following

sequence of steps:

{ find out whether the database makes this server

authoritative for the domain name specified by QNAME

for is=0 to ord(QNAME) { sequence through all nodes in QNAME }

do begin

ptr :=findset(right(QNAME,i));

if ptr<>NULL

h t t p : / / ww w - b ib .fh-bielef6ld .de/epub/doe/idoe/rfc/rfc-0800-0899/rfc882 . h t m l 5 / 1 / 0 0



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 :=ptrend;


do if type(RR)=SOA and class(RR)=QCLASS

then auth :=trueend

end ; i

end;

{ copy out authority search results }

if auth

then { if authority check for domain found }

if ptr=null

then return(Name error)

else

else { if not authority, copy NS RRs }

for all RRs in set(nsptr)do if (type(RR)=NS and class(RR)=QCLASS)

or(QCLASS=*)

then copy(RR);

{ Copy all RRs that answer the question }


do if class(RR)=QCLASS and relevant(QTYPE,type(RR))

then copy(RR);

The first section of the code (delimited by the for loop over .

Mockapetris [Pag. . . . . . . . . . . .

RFC 882 November


of the subnodes of QNAME) discovers whether the name server i

authoritative for the domain specified by QNAME . It sequence

through all containing domains of QNAME, starting at the 'root

it encounters a SOA it knows that the name server is authorit

unless it finds a lower NS RR which delegates authority . If

name server is authoritative, it sets auth=true ; if the name

server . is not authoritative, it sets NSptr to point to the se

which contains the NS RR closest to the domain specified by Q

The second section of the code reflects the result of the

authority search into the response . If the name server is

authoritative, the code checks to see that the domain specifiQNAME 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 arei

h t t p : / /w w w - b ib .fli-bielefeld .de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882.html 511100



's ;


discussed in [14].

Additional information

When a resolver returns information to a user program, the

returned information will often lead to a second query . For

example, if a mailer asks a resolver for the appropriate mailagent 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 thresolver 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 - 8 2 November


consists of host to address bindings for domain names in retu

RRs.

Aliases and canonical names

In existing systems, hosts and , other resources often have sevnames that identify the same resource . For example, under cu

ARPA Internet naming support, USC-ISIF and ISIF both identify

same host . Similarly, in the case of mailboxes, many

organizations provide many names that actually go to the same

mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc.

go to the same mailbox (although the mechanism behind this is

somewhat complicated).

Most of these systems have a notion that one of the equivalen

of names is the canonical name and all others are aliases:

The domain system provides a similar feature using the canoni

name ' (CNAME) RR. When a name server fails to find a desired

a set associated with some domain name, it checks to see if t

resource set contains a CNAME record with a matching class.

so, the name server includes the CNAME record in the response

continues the query at the domain name specified in the data

of the CNAME record.

Suppose a name server was processing a query with QNAME=ISIF:

QTYPE=A, and QCLASS=IN, and had the following resource-record

ISIF .ARPA CNAME IN F .ISI .ARPAF .IS I .ARPA A IN 10 .2 . 0 .52

Both of these RRs would be returned in the response

In the above example, because ISIF .ARPA has no RRs other than

CNAME RR, the resources associated with ISIF .ARPA will appear

ht t p : / /w w w - b ib . f l7-bie lefe ld . 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 .IS I .ARPA A IN 10 . 2 .0 .52F .IS I .ARPA MD IN F . IS I .ARPA

XXXX.ARPA CNAME IN F .ISI .ARPAXXXX .ARPA MF IN A .ISI .ARPA

Using this database, type A queries for XXXX.ARPA would retur

XXXX.ARPA CNAME RR and the F .ISI .ARPA A RR, but MAILA or MFqueries to XXXX .ARPA would return the XXXX.ARPA MF RR without

information from F . - I S I .ARPA . This structure might be used to

Mockapetris [Pag_.

RFC 882 November


mail addressed to XXXX .ARPA to A .ISI .ARPA and to direct TELNE

XXXX.ARPA to F .ISI .ARPA.

Wildcards

In certain cases, an administrator may wish to associate defa

resource information for all or part of a domain . For exampl

the CSNET domain administrator may wish to establish IN class

forwarding for all hosts in the CSNET domain without IN

capability . In such a case, the domain system provides a spe

label "*" that matches any other label . Note that "*" matche

only a single label, and not zero or more than one label . No

also that the "*" is distinct from the "*" values for QCLASS

QTYPE.

The semantics of "*" depend upon whether it appears in a quer

domain name (QNAME) or in a RR in a database.

When an "*" is used in a QNAME, it can only match a "*" in

resource record.

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

an existing exact match . For example, if a name server

received a query for the domain UDEL .CSNET, and had approp

RRs for both UDEL .CSNET and * .CSNET, the UDEL .CSNET RRs wo

be used and the * .CSNET RRs would be ignored . If a query

the same database specified FOO .CSNET, the * .CSNET RR woul

used, but"the corresponding labels from the QNAME would re

the "*" . Thus the FOO .CSNET query would match the * .CSNET

and return a RR for FOO .CSNET rather than * .CSNET.

RRs containing "*" labels are copied exactly when zones ar

transfered via name server maintenance operations.

These semantics are easily implemented by having the name ser

first search for an exact match for a query,-and then replaci

the leftmost label with a "*" and trying again, repeating the

process until all labels became "*" or the search succeeded.

TYPE=* in RRs is prohibited . If it were to be allowed, the

requestor would have no way of interpreting the data in the R

because this data is type dependent.

CLASS=* is also prohibited . Similar effects can be achieved

QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to

complexities without apparent benefit.

h t t p : / / ww w - b ib . f h - b ie l e f e ld . de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882 .html 511100



's ,

HTML Version from RFC Dc -mehi Page 17 of 27

ockapetris [Pa~g

RFC 882 November


A scenario

In our sample domain space, suppose we wanted separate

administrative control for-the root, DDN, ARPA, CSNET, MIT an

domains . we might allocate name servers as follows:

I

( B .ISI .ARPA)

(U DEL .CS NET)+

D DN ARPA CSNET

I(JCS .DDN) ( F .ISI .ARPA) I(UDEL .ARPA)

+(A .ISI .ARPA)+I I I I IJCS ARMY NAVY UDEL UCI

+DTI MIT ISI UDEL NBS

I(AI .MIT .ARPA) I( F .ISI .ARPA)+---+---+MS AI A B F

In this example the authoritative name server is shown in,

parentheses at the point in the domain tree at which is assum

control.

Thus the root name servers are on B .ISI .ARPA and UDEL .CSNET,

DDN name server is on JCS .DDN, the CSNET domain server isjon

UDEL .ARPA, etc.

In an actual system, all domains should have redundant name

servers, but in this example only the ARPA domain has redunda

servers A .ISI .ARPA and F .ISI .ARPA . (The B .ISI .ARPA and UbEL.name servers happen to be not redundant because they handle

different classes .) The F .ISI .ARPA name server has authority

the ARPA domain, but delegates authority over the MIT .ARPA doto 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.

ht t p: / /w w w - b ib . f lz - b ie l e f e ld .de/epub/doe/idoe/rfc/rfc-0800-0899/rfc882.html 511100




B .ISI .ARPA Name server for

B .I SI .ARPA has the root name server for the IN class . Itsdatabase might contain : %

Domain Resource Record

" " SOA IN A .ISI .ARPADDN NS IN JCS .DDNARPA NS IN F .ISI .ARPACSNET NS IN UDEL .ARPA" " NS IN B .ISI .ARPA" NS CS UDEL .CSNET

JCS .DDN A IN 9 . 0 . 0 . 1

F .IS I .ARPA A IN 10 . 2 . 0 .52UDEL .CSNET A CS 302-555-0000

UDEL .ARPA A IN 10 .0 . 0 .96

The SOA record for the root is necessary so that the name ser

knows that it is authoritative for the root domain for class

The contents of-the SOA resource record point back to A .ISI .A

and denote that the master data for the zone of authority is

originally from this host . The first three NS records denote

delegation of authority. The NS root entry for the B .ISI .ARPname 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 entrclass 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 (usingprevious algorithm) by determining that it was not an authori

for F .ISI .ARPA . The test would note that it had authoritylat

but would also note that the authority was delegated at ARPA

never reestablished via another SOA . Thus the response would

return the NS record for the domain ARPA.

Any queries presented to this server with QCLASS=CS would 'res

in the UDEL .CSNET NS record being returned in the response.

Mockapetris [Pag

RFC 882 November


F .ISI .ARPA Name server for ARPA and ISI .ARPA

In the same domain space, the F .ISI .ARPA database for the dom

ARPA and ISI .ARPA might be:

Domain Resource Record

NS IN B .ISI .ARPA

NS CS CSNET .UDELARPA SOA IN B .ISI .ARPAARPA NS IN A .ISI .ARPA

h t t p ://www-bib . f l i -bi e l e fe l d . de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5 1 1 1 0 0




ARPA NS IN F .IS I .ARPAMIT .ARPA NS IN AI .MIT .ARPAISI .ARPA SOA IN F .ISI .ARPA

ISI .ARPA NS IN F .ISI .ARPA

A .ISI .ARPA MD IN A .ISI .ARPA

ISI .ARPA MD IN F .IS I .ARPAA .ISI .ARPA MF IN F .ISI .ARPAB . ISI .ARPA MD IN B .IS I .ARPA

B . ISI .ARPA MF IN F . IS I .ARPAF .ISI .ARPA MD IN F .IS I .ARPAF .ISI .ARPA MF IN A .ISI .ARPAD T I . AR PA MD IN DTI .ARPA

NBS .ARPA MD IN N BS . AR PAUDEL .ARPA MD IN UDEL .ARPA

A .ISI .ARPA A IN 10 .1 . 0 .32F .ISI .ARPA A IN 10 . 2 . 0 .52

B . ISI .ARPA A IN 10 . 3 . 0 .52DTI .ARPA A IN 10 .0 . 0 .12AI .MIT .ARPA A IN 10 . 2 . 0 . 6DMS .MIT .ARPA A IN 10 .1 . 0 .6

NBS .ARPA A IN 10 .0 . 0 .19UDEL .ARPA A IN 10 .0 . 0 .96

For the IN class, the SOA RR for ARPA denotes that this name

server is authoritative .for the domain ARPA, and that the mas

file for this authority is stored on B .ISI .ARPA . This zoneextends to ISI .ARPA, where the database delegates authority b

to this name server in another zone, and doesn't include the

domain MIT.ARPA, which is served by a name server on AI .MIT .A

This name server is not authoritative for any data in the CS

class . It has a pointer to the root server for CS data which

could be use to resolve CS class queries.

Suppose this name server received a query of the form

QNAME=A .ISI .ARPA, QTYPE=A, and QCLASS=IN . The authority sear

Mockapetris [Pa_ . . . 9 _ . .

RFC 882 NovemberDomain Names - Concepts and Facil

would notice the NS record for " 1 1 , its SOA at ARPA, a delega

a t ISI .ARPA, and the reassumption of authority at ISI .ARPA.it would know that it was an authority for this query . It wo

then find the A record for A .ISI .ARPA, and return a datagram

containing this record.

Another query might be QNAME=B .ISI .ARPA, QTYPE=MAILA, QCLASS=

In this case the name server would know that it scannot be

authoritative because of the "*" value of QCLASS, and would 1

for records for domain B .ISI .ARPA that match . Assuming that.name server performs the additional record inclusion mentione

the--name server algorithm, the returned datagram would includ

ISI .ARPA NS IN F .ISI .ARPA

" If NS CS UDEL .CSNETB .ISI .ARPA MD IN B .ISI .ARPAB .ISI .ARPA MF IN F . I S I - .ARPAB .ISI .ARPA A IN 10 .3 . 0 .52

F .IS I .ARPA A IN 10 .2 . 0 .52

If the query were QNAME=DMS .MIT .ARPA, QTYPE=MAILA, QCLASS=IN,

name server would discover tha t AI .MIT .ARPA was the authorita

ht t p : / /w w w - b ib .fh-blelefeld .de/epub/doo/idoc/rfc/rfc-0800-0899/rfc882.html 511100



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

name server and return the following:

MIT .ARPA NS IN AI .MIT .ARPAAI .MIT .ARPA A IN 10 . 2 . 0 . 6

In this case, the requestor is directed to seek information f

the MIT.ARPA domain name server residing on AI .MIT .ARPA.

Mockapetris [Pa—_. . . . ... . . . . . .. . . . . . . . . . ... .. . .... . . .. . . .. . .. ..

RFC 882 November


UDEL .ARPA and UDEL .CSNET name server

In the previous discussion of the sample domain, we stated th

UDEL .CSNET and UDEL .ARPA might be the same name server . ;In t

example, we assume that this is the case . As such, the name

server is an authority for the root for class CS, and an ' auth

for the CSNET domain for class IN.

This name server deals with mail forwarding between the ARPA

Internet and CSNET systems . Its RRs illustrate one approach

solving this problem . The name server has the following ;reso

records:

" SOA CS UDEL .CSNET" NS CS UDEL .CSNET

NS IN B .ISI .ARPA

CSNET SOA IN UDEL .ARPACSNET NS IN UDEL .ARPA

ARPA NS IN A .ISI .ARPA

* .CSNET MF IN UDEL .ARPAUDEL .CSNET MD CS UDEL .CSNET

U CI .CS NE T MD CS U CI .CS NE TUDEL .ARPA MD IN UDEL .ARPA

B .ISI .ARPA A IN 10 . 3 . 0 .52

UDEL .ARPA A IN 10 . 0 . 0 .96UDEL .CSNET A CS 302-555-0000

U CI .CS NE T A CS 714-555-0000

Suppose this name server received a query of the form

QNAME=UCI .CSNET, QTYPE=MAILA, and QCLASS=IN . The name _ .serverwould discover it was authoritative for the CSNET domain unde

h t t p : / /w w w - b ib . f h - b ie l e f e ld .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.

H owe ve r , .usin g t h e * .CSNET record, it would construct a reply

UCI .CSNET MF IN UDEL .ARPAUDEL .ARPA A IN 10 . 0 .0 .96

If this name server received a query of the form QNAME=UCI .CSQTYPE=MAILA, and QCLASS=CS, the name server would return:

UCI .CSNET MD CS U CI .CS NE T

UCI .CSNET A CS 714-555-0000

Note that although this scheme allows for forwarding of all m

addressed as <anything> .CSNET, it doesn't help with names tha

have more than two components, e .g . A . B .CSNET . Although thisproblem could be "fixed" by a series of MF entries for * . * .CS

[Pag

November


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

cleverer pattern matching algorithm in the CSNET name server.

Summary of requirements for name servers

The requirements for a name server are as follows:

1. It must be recognized by its parent.

2. It must have complete resource information for all doma

names for which it is the authority.

3. It must periodically refresh authoritative information

a master file or name server which holds the master.

4. If it caches information it must also handle TTL manage

for that information.

5. It must answer simple queries.

Inverse queries

Name servers may also support inverse queries that map &

particular resource to a domain name or domain names that hav

that resource . For example, while a query might map a domain

to a host address, the corresponding inverse query might map

address back to the domain name.

Implementation of this service is optional in a name server,

all name servers must at least be able to understand an'inver

query message and return an error response.

The domain system cannot guarantee the completeness or unique

of inverse queries because the domain system is organized by

domain name rather than by host address or any other resource

type . In general, a resolver or other program that wishes toguarantee that an inverse query will work must use a name ser

that is known to have the appropriate data, or ask all name

servers in a domain of interest.

For example, if a resolver wishes to perform an inverse ;query

an arbitrary host on the ARPA Internet, it must consult~a set

name servers sufficient to know that all IN data was consider

In practice, a single inverse query tp a name server that has

ht t p : / /w w w - b ib .fll-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882 .html 5 / 1 / 0 0

Mockapetris

RFC 882





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 i n 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 ;retinformation that is useful to its clients . If the resolve

serves a client that has multiple protocol capabilities, i

should be able to support the preferences of the client.

The resolver for a multiple protocol client can either col

information for all classes using the * class value, or it

on the classes supported by the client . Note that in eith

case, the resolver must understand the preferences of the

For example, the host that supports both CSNET and ARPA

Mockapetris [Pag__. _,

RFC 882 November


Internet protocols might prefer mail delivery (MD) to mail

forwarding (MF), regardless of protocol, or might prefer o

protocol regardless of whether MD or MF is required : Care

required to prevent loops.

3. The resolver must be capable of chaining through multiple

servers to get to an authoritative name server for any . que

The resolver should guard against loops in referrals ; a sipolicy is to discard referrals that don't match more of th

http : / /w w w - b ib .fh-bielefeld . de/epub/doe/idoc/rfc/rfc-0800-0899/rfc882 .html 5 1 1 1 0 0



HTML Version from RFC Do- -rent P a g e 2 4 o f 2 7

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 ' teliminated without eliminating caching, it can be reduced to

infrequent problem through the use of timeouts.

When name servers return resource records, each record has an

associated time-to-live (TTL) field . This field is expressed

seconds, and has 16 bits of significance.

When a resolver caches a returned resource record it must als

remember the TTL field . The resolver must discard the record

the equivalent amount of time has passed . If the resolver . sh

a database with a name server, it must decrement the TTL fiel

imported records periodically rather than simply deleting the.

record . This strategy is necessary to avoid exporting a reso

record whose TTL field doesn't reflect the amount of time tha

resource record has been cached . Of course, the resolver sho

Mockapetris [Pag..FC 882 November


not decrement the TTL fields of records for which the associa

name server is an authority.

h t t p : / / ww w - b ib . f h - b ie l e f e ld. de/epub/doe/idoc/rfe/rfc-0800-0899/rfc882 .html 5 / 1 / 0 0




Mockapetris [Pag


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 wmany applications that use domain names (e .g ., mail, TELNET) : Nthat some applications described in [141 use domain names contai

binary information and hence do not follow this syntax.

<domain> <subdomain> "

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

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

<ldh-str> <let-dig-hyp> <let-dig-hyp> <ldh-str>

<let-dig-hyp> <let-dig> "- "

<let-dig> <letter> <digit>

<letter> any one of the 52 alphabetic characters A throug

in-upper case and a through z in lower case -

<digit> any one of the ten digits 0 through 9

Note that while upper and lower case letters are allowed in doma

names no significance is attached to the case . That is, two!nam

with the same spelling but different case are to be treated as i

identical.

The labels must follow the rules for ARPANET host names . They m

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



HTML Version from RFC Dc ,rent P a g e 2 6 o f 2 7

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 .IS I .ARPA LINKABIT-DCN5 .ARPA UCL-TAC .ARPA

Mockapetris [Pag


REFERENCES and BIBLIOGRAPHY

[1] E . Feinler, K . Harrenstien, Z . Su, and V . White, "DOD Inter

Host Table Specification", RFC 810, Network Information Cen

SRI International, March 1982.

[2] J . Postel, "Computer Mail Meeting Notes", RFC 805,USC/Information Sciences Institute, February 1982.

[3] Z . Su, and J . Postel, "The Domain Naming Convention for, Int

User Applications", RFC 819, Network Information Center,, SR

International, August 1982.

[4] Z . Su, "A Distributed System'for Internet Name Service",

RFC 830, Network Information Center, SRI International,

October 1982.

[5] K. Harrenstien, and V . White, "NICNAME/WHOIS", RFC 812, ;Net

Information Center, SRI International, March 1982.

[6] M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Name

Server", Computer Networks, vol 6, nr 3, July 1982.

[7] K . Harrenstien, "NAME/FINGER", RFC 742, Network Information. Center, SRI International, December 1977.

[8] J . Postel, "Internet Name Server", IEN 116,'USC/Information

' Sciences Institute, August 1979.

[9] K . Harrenstien, V . White, and E . Feinler, "Hostnames Server


March 1982.

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

USC/Information Sciences Institute, September 1981.

[11] J . Postel, "User Datagram Protocol", RFC 768, USC/Informati_-Sciences Institute, August 1980.

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

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



HTML Version from RFC Dr ment P a g e 2 7 o f 2 7

(13]-J . Reynolds, and J . Postel, "Assigned Numbers", RFC . 8 _ 7 0 ,

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-amMonMay 122 :05:54 2000 durch Webmaster

Wiischenswertes and Anregungen bitte an : W ebmaster_@ivw w-bib .fh-bielefeld .d e

i

ht t p : / /www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc-0800-0899/rfc882.html 5 / 1 / 0 0



HTML Version•from RFC D~ ment

Fachhochschule BielefeldUniversity of Applied Sciences

Network Working Group P . MockapRequest for Comments : 883

[Note : See also RFC 973 CSNET CIC] November

DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION

+This memo discusses the implementation of domain

name servers and resolvers, specifies the format of

transactions, and discusses the use of domain names

in the context of existing mail systems and other

network software.

This memo assumes that the reader is familiar with

RFC 882, "Domain Names - Concepts and Facilities"

which discusses the"basic principles of domain

names and their use.

The algorithms and internal data structures used in

this memo are offered as suggestions rather than

requirements ; implementers are free to design their

own structures so long as the same external

behavior is achieved.

++

***** WARNING *****This RFC contains format specifications which

are preliminary and are included for purposes

of explanation only . Do not attempt to use

this information for actual implementations.

+Mockapetris [Pa

Page 1 of 64

~ a

ht t p: / /w w w - b ib .fli-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 5 / 1 / 0 0




RFC 883 NovemberDomain Names - Implementation and Specific

Table of ContentsINTRODUCTIONverviewmplementation componentsonventionsesign philosophy . . . .AME SERVER TRANSACTIONSntroductionuery and response transportverall message formathe contents of standard queries and responses

tandard query and response examplehe contents of inverse queries and responsesnverse query and response exampleompletion queries and responsesompletion query and response exampleecursive Name Serviceeader section formatuestion section formatesource record formatomain name representation and compressionrganization of the Shared databaseuery processingnverse query processingompletion query processingAME SERVER MAINTENANCEntroductiononceptual model of maintenance operationsame server data structures and top level logicame server file loadingame server file loading exampleame server remote zone transfer

ESOLVER ALGORITHMS

perationsOMAIN SUPPORT FOR MAILntroductiongent bindingailbox bindingppendix 1 - Domain Name Syntax Specificationppendix 2 - Field formats and encodingsYPE valuesTYPE values . . ...LASS values

CLASS valuestandard resource record formats

ppendix 3 - Internet specific field formats and operationsEFERENCES and BIBLIOGRAPHYNDEX

Mockapetris [Pag. . . . _ _FC 88 3 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

h t t p : / / ww w - b ib .fll-bielefeld.de/epub/doc/idoe/rfc/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC Dr ment P a g e 3 o f 6 4

f i

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 withparticular 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 updomain 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 retthe 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 isolathe database update and refresh problems in the name servers.

Mockapetris [PaFC 88 3 November


Implementation components

'A host can participate in the domain name system in a number

ways ; depending on whether the host runs programs that retrie

information from the domain system, name servers that answer

queries from other hosts, or various combinations of both,

functions . The simplest, and perhaps most typical, configura

is shown below:

Local Host I Foreign

++user queries queries

Userrogram Resolver

<ser responses responses

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 511100



HTML Version from RFC D r ~ m e n t Page 4 of 64

+++A

ache additionsreferences

V

+database

+User programs interact with the domain name space through

resolvers ; the format of user queries and user responses is

specific to the host and its operating system . User queries

typically be operating system calls, and the resolver and its

database will be part of the host operating system . Less cap

hosts may choose to implement the resolver as a subroutine to

linked in with every program that needs its services.

Resolvers answer user queries with information they acquire v

queries to foreign name servers, and may also cache or refere

domain information in the local database.

Note that the resolver may have to make several queries to se

different foreign name servers to answer a particular user qu

and hence the resolution of a user query may involve several

network accesses and an arbitrary amount of time . The querie

foreign name servers and the corresponding responses have astandard format described in this memo, and may be datagrams.

Mockapetris [Pa

RFC 883 November


Depending on its capabilities,'a name server could be a standalone program on a dedicated machine or a process or processe

a large timeshared host . A simple configuration might be:

Local Host Foreign;I

// IMaster

Ifiles=+responsesNameerver

queries

++-> ForeignResolver

----------

He re the name server acquires information about one or more zby -reading master files from its local file system, and answequeries 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

+Foreignht t p: / /w w w - b ib .fli-bielefeld.de/epub/doe/idoe/rfe/rfc883 .html 5 / 1 / 0 0




MasterresponsesNameerver

----------

- >I

Foreign

Resolver

+I

files I <I/ queries +

+maintenance +\queries Foreign

Nameervermaintenance responses ,n this configuration, the name server periodically establishvirtual circuit to a foreign name server to acquire a copy of

zone or to check that an existing copy has not changed . Themessages sent for these maintenance activities follow the sam

form as queries and responses, but the message sequences are

somewhat different.

Mockapetris [PaFC 883 November


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

domain name system is shown below:

Local Host I Foreign

++user queries queries

Userrogram Resolver

<ser responses responses

++Acache additions I references

vShareddatabase

-----------

A

+refreshes references

V++

responses

Nameaster

: Serverfiles <queries++A maintenance

\ueries +-> Foreign

Name ~

-- Server

----------

- - - - - - - - - -

-> Foreign

- Resolver

----------

Foreign

N a m e ' .

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

ht t p ://www-bib .fh-blelefeld .de/epub/doc/idoc/rfe/rfc883 .html 511100



HTML Version from RFC D ment Page 6 of 64

periodic refresh operations of the name server and cached dat

from previous resolver requests . The structure of the domain

and the necessity for synchronization between name servers an

resolvers imply the general characteristics of this database,

the actual format is up to the local implementer . This memo

suggests a multiple tree format.

Mockapetris [Pa

RFC 883 November


This memo divides the implementation discussion into sections

NAME SERVER TRANSACTIONS, which discusses the formats for

servers queries and the corresponding responses.

NAME SERVER MAINTENANCE, which discusses strategies,

algorithms, and formats for maintaining the data residingname 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.

ht t p ://www-bib .fh-bielefbld.de/epub/doc/idoc/rfe/rfc883 .html 511100 i

i




Mockapetris [ . P a _

RFC 883 November


Conventions

The domain system has several conventions dealing with low-le

but fundamental, issues . While the implementer is free to vi

these conventions WITHIN HIS OWN SYSTEM, he must observe thes

conventions in ALL behavior observed from other hosts.

********** Data Transmission Order **********

The order of transmission of the header and data described in

document is resolved to the octet level . Whenever a diagram

a group of octets, the order of transmission of those octets

the normal order in which they are read in English . For exam

in the following diagram the octets are transmitted in the or

they are numbered.

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

2 i

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

i 3 i 4 i

i 5 i 6 i

Transmission Order of Bytes

Whenever an octet represents a numeric quantity the left most

in the diagram is the high order or most significant bit . This, 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 (P a

RFC 883 November


********** Character Case **********

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

names, etc .) are! done in a case-insensitive manner.

ht t p ://www-bib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0

I

I



"s:

HTML Version from RFC D~ ment Page 8 of 64f i

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 eninto 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 definestructure 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, o r b . X .

general, this prevents the first component of a domain name f

loss of case information.

Systems administrators who enter data into the domain databas

should take care to represent the data they supply to the dom

system in a case-consistent manner if their system is

case-sensitive . The data distribution system in the domain s

will ensure that consistent representations are preserved.

Mockapetris [Pa

RFC 883 November


Design philosophy

The design presented in this memo attempts to provide a base

will be suitable for several existing networks . An equally

important goal is to provide these services within a framewor

that is capable of adjustment to fit the evolution of service

early clients as well as to accommodate new networks . -

Since it is impossible to predict the course of these

developments, the domain system attempts to provide for evolu

in the form of an extensible framework . This section describ

the areas in which we expect to see immediate evolution.

DEFINING THE DATABASE

http: / /w w w - b ib .fh-bielefeld .de/epub/doe/idoe/rfe/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D, m C n t 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, classeet c ., 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 [ P a _

RFC 883 November


network addresses vary in format, and it is unreasonable t

expect to enforce consistent conventions.

2. Connectivity may require intermediaries . For example, it

frequent occurence that mail is sent between hosts that sh

no common protocol.

The domain system acknowledges that these are very difficult

problems, and attempts to deal with both problems through its

CLASS mechanism:

1.The CLASS field in RRs .allows data to be tagged so that al

programs in the domain system can identify the format in u

2. The CLASS field allows the requestor to identify the forma

data which can be understood by the requestor.

3. The CLASS field guides the search for the requested data.

The last point is central to our approach . When a query cros

protocol boundaries, it must be guided though agents capable

performing whatever translation is required . For example, wh

mailer wants to identify the location of a mailbox in a porti

the domain system that doesn't have a compatible protocol, th

query must be guided to a name server that can cross the boun

itself or form one link in a chain that can span the differen

http: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfe/rfc883 .html 5 / 1 4 0 0



HTML Version from RFC D ment P a & e 1 0 o f 6 4

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 [PaRFC 883 November


the problem, we realize that the approach of using resource d

that transcends class may be appropriate in future designs or

applications . By not defining class to be directly related t

protocol, network, etc ., we feel that such services could be

by defining a new "universal" class, while the present use of .

class will provide immediate service.

This problem requires more thought and experience before solu

can be discovered . The concepts of CLASS, recursive servers

other mechanisms are intended as tools for acquiring experienand not as final solutions.

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .h t tnl

~

5 / 1 / 0 0



HTML Version from RFC D ; : W e n t Page 11 of 64

Mockapetris [ . _ P a g . _ . .

RFC 883 November


NAME SERVER TRANSACTIONS

Introduction

The primary purpose of name servers is to receive queries froresolvers 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 querypart 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

h t t p : / / ww w - b ib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0



. F ,


message of up to 512 octets.

Mockapetris [Pag

RFC 883 November

. Domain Names - Implementation and Specific

Hence datagram messages are limited to 512 octets . Ifdatagram 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 queryperform 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 formesboundary detection or limits transmission size to less

65535 octets, then messages are prefaced with an unsign

bit length field and broken up into separate transmissi

as required . The length field is only prefaced on the

message . This technique is used for TCP virtual circui

3. Multiple messages may be-sent over a virtual circuit'.

4. A method for closing a virtual circuit.

5. A method for detecting that the other party has request

that the virtual circuit be closed.

The main implications for programs accessing name servers via

virtual circuits are:

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

there is no activity in progress . The other end should

comply.

Mockapetris [Pag

RFC 88 3 November


The decision to initiate a close is a matter of individ

site policy; some name servers may leave a virtual circ

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 11 /0 0




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 receivvirtual circuit close while a query is in progress shou

close the virtual circuit and resubmit the query on a n

virtual circuit.

All messages may use a compression scheme to reduce the space

consumed by repetitive domain names . The use of the compress

scheme is optional for the sender of a message, but all recei

must be capable of decoding compressed domain names.

overall message format

All messages sent by the domain system are divided into 5 sec

(some of which are empty in certain cases) shown below:

+I Header I

+I Question I the question for the name server

+Answer I answering resource records (RRs)

+I Authority I RRs pointing toward an authority

+I Additional I RRs holding pertinent information

+The header section is always present . The header includes fi

that specify which of the remaining sections are present, and

specify whether the message is a query, inverse query, comple

query, or response.

The question section contains fields that describe a questionname server . These fields are ' a query type (QTYPE), a query

(QCLASS), and a query domain name (QNAME).

The last three sections have the same format : a possibly empt

list of concatenated resource records (RRs) . The answer sect

contains RRs that answer the question ; the authority section

Mockapetris [Pag

RFC 883 November


contains RRs that point toward an authoritative name server;

additional records section contains RRs which relate to the qbut 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.

ht t p: / /w w w - b ib .fli-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 5 / 1 / 0 0



. s ,

HTML Version from RFC D- ment P a g e 1 4 o f 6 4

Mockapetris [Pag

RFC 883 November


The contents of standard queries and responses

When a name server processes a standard query, it first deter

whether it is an authority for the domain name specified in t

query.

If the name server is an authority, it returns either:

1. the specified resource information

2. an indication that the specified name does'not exist

3. an indication that the requested resource information d

not exist

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

returns whatever relevaht resource information it has along w

resource records that the requesting resolver can use to loca

authoritative name server.

Standard query and response example

The overall structure of a query for retrieving information f

Internet mail for domain F .ISI .ARPA is shown below:

h t t p : / / ww w - b ib .fh-bielefeld.de/epub/doe/idoc/rfe/rfc883.html 511100



HTML Version from RFC D, •ment Page 15 of 64

+eader OPCODE=QUERY, ID=2304

+uestion IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA

+Answer I <empty>

+uthority I <empty>

+dditional <empty>

+he header includes an opcode field that specifies that thisdatagram 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 .IS I .AR P

The remaining sections are empty, and would not use any octet

a real query.

Mockapetris 1Pa g

RFC 883 November


one possible response to this query might be:

--

Header OPCODE=RESPONSE, ID=2304

+- - -

Question IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA

+---Answer <empty>--

Authority ARPA NS IN A .ISI .ARPA

ARPA NS - IN - F .ISI .ARPA

+dditional F .ISI .ARPA A IN 10 . 2 . 0 .52

A .ISI .ARPA A IN 10 .1 . 0 .22

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

h t t p : / /w w w - b ib .fll-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 511100



HTML Version from RFC D c - m e n t 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, withnew ID of 2305.

Mockapetris [Pag

RFC 883 November


The name server on A .ISI .ARPA might return a response:

+eader I OPCODE=RESPONSE, ID=2305

+uestion IQTYPE=MAILA, QCLASS=IN, QNAME=F .ISI .ARPA

+nswer F .IS I .ARPA MD IN F .ISI .ARPA

F .IS I .ARPA MF IN A .ISI .ARPA

+uthority I <empty>+

dditional I F .ISI .ARPA A IN 10 . 2 . 0 .52

A .ISI .ARPA A IN 10 .1 . 0 .22

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

the response includes an answer but no authority records . In

case, the answer section specifies that mail for F .ISI .ARPA ceither 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

ht t p: / /w w w - b ib .fli-blelefeld.de/epub/doe/idoc/rfc/rfc883 .html 5 1 1 1 0 0



HTML Version from RFC D , m e n t 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 [ P a g _ _FC 883 November


When a name server processes an inverse query, it either retu

1. zero, one, or multiple domain names for the specified

resource

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

support inverse mapping of the specified resource type.

Inverse query and response example

The overall structure of an inverse query for retrieving the

domain name that corresponds to Internet address 10 .2 . 0 .52 is

shown below :

+Header I OPCODE=IQUERY, ID=997

+

Question <empty>

+Answer <anyname> A IN 10 . 2 . 0 .52

+

Authority I <empty>+

Additional I <empty>

+---This query asks for a question whose answer is the Internet s

address 10 . 2 . 0 .52 . Since the owner name is not known, any do

name can be used as a placeholder (and is ignored) . The r,espto this query might be:

+---Header I OPCODE=RESPONSE, ID=997

+uestion I QTYPE=A, QCLASS=IN, QNAME=F .ISI .ARPA

+

Answer I F .ISI .ARPA A IN 10 . 2 . 0 .52+

Authority <empty>+

Additional I <empty>

+

Note that the QTYPE in a response to an inverse query is the

as the TYPE field in the answer section of the inverse query.Responses to inverse queries may contain multiple questions w

the-inverse is not unique.

Mockapetris [Pag


ht t p : / /w w w - b ib .fh-blelefeld.de/epub/doe/idoc/rfe/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D , ment P a g e 1 8 o f 6 4

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 inname 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 completedAll returned RRs will begin with the partial string . Thesearch 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 npreference to Smithsonian@ISI .ARPA.

The partial name is supplied by the user through the user

program that is using domain services . For example, if , th

user program is a mail handler, the string might be "Mocka

which the user intends as a shorthand for the mailbox

Mockapetris@ISI .ARPA ; if the user program is TELNET, the u

might specify "F" for F .ISI,ARPA.

In order to make parsing of messages consistent, the parti

name is supplied in domain name format (i .e . a sequence of

labels terminated with a zero length octet) . However, ',the

trailing root label is ignored during matching.

4. A target domain name which specifies the domain which is t

examined for matches . This name is specified in the addit

Mockapetris [Pag. . . .. . . . .


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 ;endISI .ARPA ; user programs running at MIT might restrictcompletion 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

h t t p : / / ww w - b ib .fli-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0



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 . Userprograms 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 asksall RRs which could complete the specified input, and

"Completion Query - Unique" ; or CQUERYU, which asks for th

"best" completion.

CQUERYM is used by user programs which want to know if

ambiguities exist or wants to do its own determinations as

the best choice of the available candidates.

CQUERYU is used by user programs which either do not wish

deal with multiple choices or are willing to use the close

criteria used by CQUERYU to select the best match.

When a name server receives either completion query, it first

looks for RRs that begin (on the left) with the same labels a

found in QNAME (with the root deleted), and which match the Q

and QCLASS . This search is called "whole label" matching. I

or more hits are found the name server either returns all of

hits (CQUERYM) or uses the closeness criteria described below

eliminate all but one of the matches (CQUERYU).

If the whole label match fails to find any candidates, then t

name server assumes that the rightmost label of QNAME (after

deletion) is not a complete label, and looks for candidates t

would match if characters were added (on the right) to the

rightmost label of QNAME . If one or more hits are found the

server either returns all of the hits (CQUERYM) or uses the

closeness criteria described below to eliminate all but one o

matches (CQUERYU).

Mockapetris [Pag„. . .


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

h t t p : / / ww w - b ib .fli-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5 1 1 1 0 0




configured to direct completion queries to a name server whic

known to have the desired information.

When a name server processes a completion query, it either

returns:

1. An answer giving zero, one, or more possible completion

2. an error response with Not Implemented (NI) set.

Mockapetris [Pag_

RFC 88 3 November


Completion query and response example

Suppose that the completion service was used by a TELNET prog

to allow a user to specify a partial domain name for the desi

host . Thus a user might ask to be connected to "B" . Assuminthat the query originated from an ISI machine, the query migh

look like :

+eader I OPCODE=CQUERYU, ID=409

+uestion I QTYPE=A, QCLASS=IN, QNAME=B

+nswer I <empty>

+uthority I <empty>

+dditional I ISI .ARPA NULL IN

+he 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 I OPCODE=RESPONSE, ID=409

+uestion I QTYPE=A, QCLASS=IN, QNAME=B

+ht t p : / /w w w - b ib .fli-bielefeld.de/epub/doe/idoe/rfc/rfc883 . h t m l 5 1 1 1 0 0



HTML Version from RFC D , ~ m e n t P a g e 2 1 o f 6 4

Answer B .I SI .ARPA A IN 10 . 3 . 0 .52

+uthority <empty>

+--=dditional I ISI .ARPA NULL IN

+his response has completed B to mean B .ISI .ARPA.

Mockapetris [Pag

RFC 88 3 November


Another query might be:

+eader I OPCODE=CQUERYM, ID=410

+ues.tion I QTYPE=A, QCLASS=IN, QNAME=B

+nswer <empty>+uthority I <empty>

+dditional I ARPA NULL IN

+"

This query is similar to the previous one, but specifies a to

of ARPA rather than ISI .ARPA . It also allows multiple matche

In this case the same name server might return:

+eader I OPCODE=RESPONSE, ID=410

-----------------------------------------

Question I QTYPE=A, QCLASS=IN, QNAME=B

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

+uthority I <empty>

+dditional I ARPA NULL IN 1

+his response contains three answers, B .ISI .ARPA, B .BBN .ARPA,

B .BBNCC .ARPA .

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 . h t m l 5 1 1 1 0 0




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 requestoreturns the eventual result back to the original requestor.

A name server that supports recursive service sets the Recurs

Available (RA) bit in all responses it generates . A requesto

asks for recursive service by setting the Recursion Desired (

bit in queries . In some situations where recursive service i

only path to the desired information (see below), the name se

may go recursive even if RD is zero.

If a query requests recursion (RD set), but the name server d

not support recursion, and the query needs recursive service

an answer, the name server returns a "Not Implemented" (NI) e

code . If the query can be answered without recursion since t

name server is authoritative for the query, it ignores the RD

Because of the difficulty in selecting appropriate timeouts a

error handling, recursive service is best suited to virtual

circuits, although it is allowed for datagrams.

Recursive service is valuable in several special situations:

In a system of small personal computers clustered around o

more large hosts supporting name servers, the recursive

approach minimizes the amount of code in the resolvers in

personal computers . Such a design moves complexity out of

resolver into the name server, and may be appropriate for

systems.

Name servers on the boundaries of different networks may w

to offer recursive service to create connectivity between

different networks . Such name servers may wish to provide

recursive service regardless of the setting of RD.

Name servers that translate between domain name service an

some other name service may wish to adopt the recursive st

Implicit recursion may be valuable here as well.

Mockapetris [Pag

RFC 883 November


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







HTML Version from RFC D- - . m e n t Page 25 of 64

-t

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

is copied into the response . If RD is set

directs the name server to pursue the quer

recursively . Recursive'query support is

optional.

RA - Recursion Available - this be is set or cleared in

response, and denotes whether recursive qusupport is available in the name server.

RCODE - Response code - this 4 bit field is set as part of

responses . The values have the following

interpretation:

0 No error condition

1 Format error - The name server was una

to interpret the query.

2 Server failure - The name server was uto process this query due to a problem

the name server.

3 Name Error - Meaningful only for respofrom an authoritative name server, thi

code signifies that the domain name

referenced in the query does not exist

Mockapetris[ .Pa_..

RFC 883 November


4 Not Implemented - The name server does

support the requested kind of query.

5 Refused - The name server refuses to

perform the specified operation for po

reasons . For example, a name server m

not wish to provide the information to

particular requestor, or a name server

not wish to perform a particular opera

( e .g . zone transfer) for particular da

6-15 Reserved for future use.

QDCOUNT - an unsigned 16 bit integer specifying the number of

entries in the question section.

ANCOUNT - an unsigned 16 bit integer specifying the number of

resource records in the answer section.

NSCOUNT - an unsigned 16 bit integer specifying the number of

server resource records in the authority records

section.

ARCOUNT - an unsigned 16 bit integer specifying the number of

resource records in the additional records section.

h t t p : // w w , ,v-bib .fh-bielefeld.de/epub/doe/idoc/rfe/rfc883 .html

5 1 1 1 0 0



HTML Version from RFC D- iment P a g e 2 6 o f 6 4

Mockapetris J P a . . 9 - . . .

RFC 88 3 November


Question section format

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

inverse queries . In responses to inverse queries, this secti

may contain multiple entries ; for all other responses it cont

a single entry . Each entry has the following format:

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

QNAME

QTYPE

QCLASS

where:

QNAME - a variable number of octets that specify a domain n

This field uses the compressed domain name format

described in the next section of this memo . This f

can be used to derive a text string for the domain

Note that this field may be an odd number of octets

padding is used.

QTYPE - a two octet code which specifies the type of the qu

The values for this field include all codes valid f

TYPE field, together with some more general codes w

can match more than one type of RR. For example, Qmight 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.

h t t p : / / ww w - b ib .fll-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0




I

ockapetris _ [ _ R a g .

RFC 883 November


Resource record format

The answer, authority, and additional sections all share the

format : a variable number of resource records, where the numb

records is specified in the corresponding count field in the

header . Each resource record has the following format:

1 1 1 1 1 1

0 1 23 4 567890 23 4 5

/ NAME /

TYPE

CLASS

TTL

RDLENGTH

/ RDATA /

where:

NAME - a compressed domain name to which this resource rec

pertains.

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

in Appendix 2 . This field specifies the meaning of

data in the RDATA field.

CLASS - two octets which specify the class of the data in t

RDATA field.

TTL - a 16 bit unsigned integer that specifies the time

interval (in seconds) that the resource record may

cached before it should be discarded . Zero values

interpreted to mean that the RR can only be used fotransaction 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 _ [ P a g . .

1 - i t t p : / /w w w - b ib .fll-blelefeld .de/epub/doe/idoc/rfc/rfc883 .html 511100




RFC 883 November


RDLENGTH- an unsigned 16 bit integer that specifies the lengt

octets of the RDATA field.

RDATA - a variable length string of octets that describes tresource . 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 isterminated 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, ahence 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 givdata 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

Mockapetrisl _ p a .g . . .

RFC 883 November


specifies is appended to the already specified label string.

Exact duplication of a previous label string can be done with

single pointer . Multiple levels are allowed.

Pointers can only be used in positions in the message where t

format is not class specific . If this were not the case, a n

server that was handling a RR for another class could make

h t t p : / / ww w - b ib .fh-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 511100



HTML Version from RFC D 'ment Page 29 of 64

erroneous copies of RRs . As yet, there are no such cases, bu

they may occur in future RDATA formats.

If a domain name is contained in a part of the message subjec

a length field (such as the RDATA section of an RR), and

compression is used, the length of the compressed name is use

the length calculation, rather than the length of the expande

name.

Pointers are represented as a two octet field in which the hi

order 2 bits are ones, and the low order 14 bits specify an o

from the start of the message . The 01 and 10 values of the h

order bits are reserved for future use and should not be used

Programs are free to avoid using pointers in datagrams they

generate, although this will reduce datagram capacity . Howev

all programs are required to understand arriving messages tha

contain pointers.

For example, a datagram might need to use the domain names

F .ISI .ARPA, FOO .F .ISI .ARPA, ARPA, and the root . Ignoring the

other fields of the message, these domain names might be

represented as:

Mockapetris [ -Pag. .

RFC 883 November


20 1 F

22 3 1

24 I S I

26 4 A+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

_ 28 I R P

30 A 0

40 3 F

42 I O O

ht t p: / /w w w - b ib . f l - i -blelefeld .de/epub/doc/idoc/rfc/rfc883 . h t m l 511100



HTML Version f r om RFCD- -anent Page 30 of 64

44 1 1 1 1 20 1

64 1 1 1 1 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 ; nthat 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 consistsseveral separate trees . Each tree has structure correspondin

the domain name space, with RRs attached to nodes and leaves.

Each zone of authoritative data has a separate tree, and one

holds all non-authoritative data . All of the trees correspon

to zones are managed identically, but the non-authoritative o

cache tree has different management procedures.

Mockapetris [ P a 9 . . . .


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

convenient for the name server, so long as it can be transforback 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

ht t p ://www-bib .fll-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D ,' ment P a g e 3 1 o f 6 4

they are of different classes.

other than the abutting and separate class cases, trees are a

expected to be disjoint . overlapping zones are regarded as a

non-fatal error . The scheme described in this memo avoids th

overlap issue by maintaining separate trees ; other designs mu

take the appropriate measures to defend against possible over

Non-authoritative data is maintained in a separate tree . Thi

tree is unlike the zone trees in that it may have "holes" . ERR in the cache tree has its own TTL that is separately manag

The data in this tree is never used if authoritative data isavailable from a zone tree ; this avoids potential problems du

cached data that conflicts with authoritative data.

The shared database will also contain data structures to supp

the processing of inverse queries and completion queries if t

local system supports these optional features . Although many

schemes are possible, this memo describes a scheme that is ba

on tables of pointers that invert the database according to k

Mockapetris [Pag

RFC 883 November


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

table per zone . When a zone is updated, these tables must al

updated . The contents of these tables are discussed in the

"Inverse query processing" and "Completion query processing"

sections of this memo.

The database implementation described here includes two locks

are used to control concurrent access and modification of the

database by name server query processing, name server mainten

operations, and resolver access:

The first lock ("main lock") controls access to all of the

t r ees . Multiple concurrent reads are allowed, but write a

can only be acquired by a single process . Read and writeaccess 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 . Thname 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, andallows 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

h t t p : / / ww w - b ib .fll-bielefeld.de/epub/doe/idoe/rfc/rfc883 . h t m l 5 / 1 / 0 0



HTML Version from RFC D- ~iment Page 32 of 64

domain name of interest.- r

Since updates to a zone must be atomic with respect to

searches, maintenance operations can simply acquire the ma

lock, insert a new copy of a particular zone without distu

other zones, and then release the storage used by the old

Assuming a central table pointing to valid zone trees, thi

operation can be a simple pointer swap.

Mockapetris [Pag. .

RFC 883 November


TTL management of zones can be performed using the SOA rec

for the zone . This avoids potential difficulties if indiv

RRs in a zone could be timed out separately . This issue i

discussed further in the maintenance section.

Query processing

The following algorithm outlines processing that takes place

name server when a query arrives:

1. Search the list of zones to find zones which have the same

class as the QCLASS field in the query and have a top doma

name that matches the right end of the QNAME field . If th

are none, go to step 2 . If there are more than one, pick

zone that has the longest match and go to step 3.

2. Since the zone search failed, the only possible RRs are

contained in the non-authoritative tree . Search the cache

for the NS record that has the same class as the QCLASS fi

and the largest right end match for domain name . Add the

record or records to the authority section of the response

the cache tree has RRs that are pertinent to the question

(domain names match, classes agree, not timed-out, and the

field is relevant to the QTYPE), copy these RRs into the a

section of the response . The name server may also search

cache queue . Go to step 4 . '

3. Since this zone is the best match, the zone in which QNAME

resides is either this zone or a zone to which this zone w

directly or indirectly delegate authority . Search down th

tree looking for a NS RR or the node specified by QNAME.

If the node exists and has no NS record, copy the relev

RRs to the answer section of the response and go to ste

If a NS RR is found, either matching a part or all of Q

then QNAME is in a delegated zone outside of this zone.

so, copy the NS record or records into the authority se

of the response, and search the remainder of the zone f

A type record corresponding to the NS reference . If th

record is found, add it to the additional section . Go

step 2.

If the node is not found and a NS is not found, there i

such name ; set the Name error bit in the response and e

4. When this step is reached, the answer and authority sectio

are complete . What remains is to complete the additional

section . This procedure is only possible if the name sery

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 . h t m l 5 / 1 / 0 0



HTML Version from RFC D- ~ment Page 33 of 64

Mockapetris ' J . P a g

RFC 883November


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 labeor 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 883November


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

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 . h t m l 511100



HTML Version from RFC D ment P a g e 3 4 o f 6 4

version.

Completion query processing

Completion query processing shares many of the same problems

data structure design as are found in inverse queries, but is

different due to the expected high rate of use of top level 1

(ie ., ARPA, CSNET) . A name server that wishes to be efficien

its use of memory may well choose to invert only occurrencesARPA, etc . that are below the top level, and use a search for

rare case that top level labels are used to constrain a

completion.

Mockapetris [Pag

RFC 883 November


NAME SERVER MAINTENANCE

Introduction

Name servers perform maintenance operations on their database

insure that the data they distribute is accurate and timely.

amount and complexity of the maintenance operations that a na

server must perform are related to the size, change rate, and

complexity of the database that the name server manages.

Maintenance operations are fundamentally different for

authoritative and non-authoritative data . A name server acti

attempts to insure the accuracy and timeliness of authoritati

data by refreshing the data from master copies . Non-authorit

data is merely purged when its time-to-live expires ; the name

server does not attempt to refresh it.

1 - i t t p : / /w w w - b ib .fli-bielefeld .de/epub/doe/idoc/rfe/rfc883 .html 5 1 1 1 0 0



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 nservers 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 theaddress of AI .MIT .ARPA.

Mockapetris [ P a g _ . . .

RFC 883 November


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

zone of authority to be copied-with the zone . While these rewon'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,

ht t p : / /w w w - b ib . f l - i -bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 5 1 1 1 0 0




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 changthe 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 Pa g

RFC 883 November


unable to establish communications with a master or is unable

complete the refresh transaction, it must retry the refresh

operation at the rate specified by the retry interval . This

interval will usually be substantially shorter than the refre

interval . Retries continue until the maximum holding time is

reached . At that time the copy name server must assume that

copy of the data for the zone in question is no longer

authoritative.

Queries must be processed while maintenance operations are in

progress because a zone transfer can take a long time . Howev

to avoid problems caused by access to partial databases, themaintenance 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 theassumption 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

h t t p : / / ww w - bi b .fli-bielefeld.de/epub/doc/idoc/rfc/rfc883.html 5 / 1 / 0 0




•Y

files which the name server should load and the zones t

the name server should attempt to load from foreign nam

servers . This file establishes the initial contents of

status table.

2. Domain data files that contain master and boot data to

loaded.

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

Each entry in this table describes a source of data . Eentry has a zone number . The zone number is zero for

Mockapetris [Pag_.FC 883 November


non-authoritative sources ; authoritative sources are

assigned separate non-zero numbers.

4. The shared database that holds the domain data . This

database is assumed to be organized in some sort of trestructure 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 arraycontains 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

h t t p : / / ww w - b ib .fll-bielefeld.de/epub/doc/idoc/rfc/rfc883 .html 5 1 1 1 0 0



HTML Version from RFC D(- -ment P a g e 3 8 o f 6 4

Mockapetris [Pag. . . _-

FC 883 November


loading" . The refresh interval is reset to that specified

the SOA record if the file is a master file.

If the entry is for a remote master file, the maintenance

process checks for a new version using the procedure descr

in "Names server remote zone transfer".

Name server file loading

Master files are kept in text form for ease of editing by sys

maintainers . These files are not exchanged by name servers;

servers use the standard message format when transferring zon

organizations that want to have a domain, but do not want to

name server, can use these files to supply a domain definitio

another organization that will run a name server for them . F

example, if organization X wants a domain but not a name seryit 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 andcharacters . 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, ithe owner . If a RR line starts with a blank, it is loaded in

the location specified by the most recent location specifier.

The location specifiers are assumed to be relative to some or

that is provided by the user of a file unless the location

specifier contains the root label . This provides a convenien

shorthand notation, and can also be used to prevent errors in

master files from propagating into other zones . This feature

particularly useful for master files imported from other site

An include line begins with $INCLUDE, starting at the first 1

position, and is followed by a local file name and an optiona

offset modifier . The filename follows the appropriate local

conventions . The offset is one or more labels that are added

the offset in use for the file that contained the $INCLUDE.

the offset is omitted, the included file is loaded using the

Mockapetris [Pag. . . . . . . . . . .

RFC 88 3 November


offset of the file that contained the $INCLUDE command . Forexample, a file being loaded at offset ARPA might contain the

following lines:

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0




$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 binterpreted as a request to load data at offset ARPA.

Note that $INCLUDE commands do not cause data to be loaded indifferent 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 . (Nthat this order is different from the order used in examples

the order used in the actual RRs ; the given order allows easi

parsing and defaulting . )

The owner name is derived from the location specifier.

The TTL field is optional, and is expressed as a decimal

number . If omitted TTL defaults to zero.

The CLASS field is also optional ; if omitted the CLASS def

to the most recent . value of the CLASS field in a previous

The RDATA fields depend on the CLASS and TYPE of the RR.

general, the fields that make up RDATA are expressed as de

numbers or as domain names . Some exceptions exist, and ar

documented in the RDATA definitions in Appendicies 2 and 3

this memo.

Because CLASS and TYPE fields don't contain any common

identifiers, and because CLASS and TYPE fields are never deci

numbers, the parse is always unique.

Because these files are text files several special encodings

necessary to allow arbitrary data to be loaded . In particula

A free standing dot is ' used to refer to the current d

name.

A free standing @ is used to denote the current origi

Mockapetris LPag

RFC 883 November


Two free standing dots represent the null domain name

the root.

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

to quote that character so that its special meaning d

not apply . For example, "\ ." can be used to place a

character in a label.

\DDD where each D is a digit is the octet corresponding to

decimal number described by DDD . The resulting octet

assumed to be text and is not checked for special mea

( ) Parentheses are used to group data that crosses a lin

boundary . In effect, line terminations are not recog

h t t p : / / ww w - b ib . f l - l -b i e l e fe l d.de/epub/doc/idoc/rfc/rfc883 .html 5 1 1 1 0 0




within parentheses.

Semicolon is used to start a comment ; the remainder o

line is ignored.

Name server file loading example

A name server for F .ISI .ARPA , serving as an authority for thARPA and ISI .ARPA domains, might use a boot file and two mast

files . The boot file initializes some non-authoritative data

would be loaded without an origin:

9999999 IN NS B .ISI .ARPA9999999 CS NS UDEL .CSNET

B .IS . I .ARPA 9999999 IN A 10 . 3 . 0 .52UDEL .CSNET 9999999 CS A 302-555-0000

This file loads non-authoritative data which provides the

identities and addresses of root name servers . The first lin

contains a NS RR which is loaded at the root ; the second line

starts with a blank, and is loaded at the most recent locatio

specifier, in this case the root ; the third and fourth lines

RRs at B .ISI .ARPA and UDEL .CSNET, respectively . The timeouts

set to high values (9999999) to prevent this data from being

discarded due to timeout.

The first master file loads authoritative data for the ARPA

domain . This file is designed to be loaded with an origin of

ARPA, which allows the location specifiers to omit the traili

.ARPA labels.

Mockapetris [Pag„.FC 883 November


IN SOA F .ISI .ARPA Action .E .ISI .ARPA20 SERIAL

3600 REFRESH

600 RETRY

3600000 ; EXPIRE

60) ; MINIMUM

NS F .ISI .ARPA F .ISI :ARPA is a name server for AR

NS A .ISI .ARPA A .ISI .ARPA is a name server for AR

MIT NS AI .MIT .ARPA ; delegation to MIT name server

ISI NS F .ISI .ARPA ; delegation to ISI name server

UDEL MD UDEL .ARPAA 10 .0 . 0 .96

NBS MD NBS .ARPA

A 10 .0 . 0 .19D TI MD DT I .ARPA

A 10 .0 . 0 .12

AI .MIT A 10 . 2 . 0 .6

F .ISI A 10 .2 . 0 .52

The first group of lines contains the SOA record and its

parameters, and identifies name servers for this zone and for

delegated zones . The Action .E .ISI .ARPA field is a mailboxspecification for the responsible person for the zone, and is

h t t p : / /w w w - b ib .fh-bielefeld .de/epub/doe/idoc/rfe/rfc883 . h t m l 5 / 1 / 0 0





HTML Version from RFC D ;m e nt P a g e 42 o f 6 4

If the open attempt succeeds, the name server sends a query t

foreign name server in which QTYPE=SOA, QCLASS i .s set accordithe 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 [ _ P a .g . . .


field in the new SOA record with the SERIAL field in the SOA

record of the existing zone copy . If these values match, the

has not been updated since the last copy and hence there is n

reason to recopy the zone . In this case the name server rese

the times in the existing SOA record and closes the virtual

circuit to complete the operation.

If this is initial load, or the SERIAL fields were different,

name server requests a copy of the zone by sending the foreig

name server an AXFR query which specifies the zone by its QCL

and QNAME fields.

When the foreign name server receives the AXFR request, it se

each node from the zone to the requestor in a separate messag

It begins with the node that contains the SOA record, walks t

tree in breadth-first order, and completes the transfer by

resending the node containing the SOA record.

Several error conditions are possible:

If the AXFR request cannot be matched to a SOA, the foreig

name server will return a single message in response that

not contain the AXFR request . (The normal SOA query prece

the AXFR is designed to avoid this condition, but it is st

possible . )

The foreign name server can detect an internal error or de

some other condition (e .g . system going down, out of resou

et c .) 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 theoperation for policy reasons (i .e . the system administratewishes 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

ht t p : / /w w w - b ib .fll-bielefeld.de/epub/doc/idoe/rfe/rfc883 . h t m l 5 / 1 / 0 0



HTML Version from RFC r i m e n t Page 43 of 64

in progress . In this case the requestor repeats the AXFR req

to acquire the newer version.

Mockapetris [ _ P a .g . . . _

RFC 883 November


If the AXFR transfer eventually succeeds, the name server clo

the virtual circuit and and creates new versions of inversion

structures for this zone . when this operation is complete, t

name server acquires the main lock in write mode and then rep

any old copy of the zone and inversion data structures with n

ones . The name server then releases the main lock, and can

reclaim the storage used by the old copy.

If an error occurs during the AXFR transfer, the name server

copy any partial information into its cache tree if it wishes

although it will not normally do so if the zone transfer was

refresh rather than an initial load.

Mockapetris [ . P a g _

RFC 883 November


RESOLVER ALGORITHMS

h t t p : / / ww w - b ib .fh-bielefeld.de/epub/doe/idoc/rfc/rfc883 .html 5 / 1 / 0 0



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

In any case, the resolver will transform the user query into

number of shared database accesses and queries to remote name

servers . When a user requests a resource associated with a

particular domain name, the resolver will execute the followi

steps:

1. The resolver first checks the local shared database, if an

for the desired information . If found, it checks the

applicable timeout . If the timeout check succeeds, the

information is used to satisfy the user request . If not,

resolver goes to step 2.

2. In this step, the resolver consults the shared database fo

name server that most closely matches the domain name in t

user query . Multiple redundant name servers may be found.

resolver goes to step 3.

3. In this step the resolver chooses one of the available nam

servers and sends off a query . If the query fails, it tri

another name server . If all fail, an error indication is

returned to the user . If a reply is received the resolver

the returned RRs to its database and goes to step 4.

4. In this step, the resolver interprets the reply . If the r

contains the desired information, the resolver returns the

information to the user . The the reply indicates that the

domain name in the user query doesn't exist, then the reso

returns an error to the user . If the reply contains a

transient name server failure, the resolver can either wai

retry the query or go back to step 3 and try a different n

server . If the reply doesn't contain the desired informat

but does contain a pointer to a closer name server, the

resolver returns to step 2, where the closer name servers

be queried.

Several modifications to this algorithm are possible . A reso

may not support a local cache and instead only cache informat

during the course of a single user request, discarding it upo

Mockapetris [Pag

RFC 883 November


completion . The resolver may also find that a datagram reply

truncated, and open a virtual circuit so that - the complete re

can be recovered.

Inverse and completion queries must be treated in an

environment-sensitive manner, because the domain system doesn

provide a method for guaranteeing that it can locate the Corr

information. The typical choice will be to configure a resol

to use a particular set of known name servers for inverse que

h t t p : / /w w w - b ib . f la - b ie l e f e ld .de/epub/doc/idoe/rfc/rfc883.html 511100



HTML Version from RFC D- iment Page 45 of 64

t

Mockapetris L P a g . . .

RFC 883 November


DOMAIN SUPPORT FOR MAIL

Introduction

Mail service is a particularly sensitive issue for users of t

domain system because of the lack of a consistent system for

naming mailboxes and even hosts, and the need to support cont

operation of existing services . This section discusses an

evolutionary approach for adding consistent domain name suppo

for mail.

The crucial issue is deciding on the types of binding to besupported . 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

par t.

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

ht t p ://www-bib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D iment Page 46 of 64

- i

For example, mail addressed to Mockapetris@ISIF is deliver

host USC-ISIF (USC-ISIF is the official name for the host

specified by nickname ISIF).

More sophisticated mail systems use both the local and global

parts, i . e . both X and Y to determine which host should recei

the mail . These more sophisticated systems usually separate

binding of the destination to the host from the actual delive

This allows the global part to .be a generic name rather than

constraining it to a single host . We refer to this type of

binding as "mailbox binding".

For example, mail addressed to Mockapetris@ISI might be bo

to host F .ISI .ARPA, and subsequently delivered to that hoswhile mail for Cohen@ISI might be bound to host B .ISI .ARPA

The domain support for mail consists of two levels of support

corresponding to these two binding models.

The first level, agent binding, is compatible with existin

ARPA Internet mail procedures and uses maps a global part

one or more hosts that will accept the mail . This type of

binding uses the MAILA QTYPE.

The second level, mailbox binding, offers extended service

Mockapetris [Pag_FC 883 November


that map a local part and a global part onto one or more s

of data via the MAILB QTYPE . The sets of data include hos

that will accept the mail, mailing list members (mail gro

and mailboxes for reporting errors or requests to change a

group.

The domain system encodes the'global part of a mail destinati

a domain name and uses dots in the global part to separate la

in the encoded domain name . The domain system encodes the to

part of a mail destination as a single label, and any dots in

part are simply copied into the label . The domain system for

complete mail destination as the local label concatenated to

domain string for the global part . We call this a mailbox.

For example, the mailbox Mockapetris@F .ISI .ARPA has a glob

domain name of three labels, F .ISI .ARPA . The domain nameencoding 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 laits merely used to denote the "quoted" dot) .,

It is anticipated that the Internet system will adopt agentbinding 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

h t t p ://www-bib . f lz - b ie l e f e ld .de/epub/doe/idoc/rfc/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D lm .y nt 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 inquery with QTYPE=MAILA and QNAME=F .ISI .ARPA, which might retu

two RRs:

Mockapetris P a g . . . .

RFC 883 November


F .IS I .ARPA MD IN F .ISI .ARPAF .IS I .ARPA MF IN A .ISI .ARPA

The mailer would interpret these to mean that the mail agent

F .IS I .ARPA should be able to deliver the mail directly, but t

A . IS I .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 destinatispecification 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.

ht t p : / /w w w - b ib .fh-bielefeld.de/epub/doe/idoe/rfe/rfc883 .html 5 / 1 / 0 0



HTML Version from RFC D! ment P a g e 4 8 o f 6 4

This condition means that the mailbox was actually a maili

list or mail group, rather than a single mailbox . Each MG

has a RDATA field that identifies a mailbox that is a memb

Mockapetris

P _ a J . _ .

RFC 88 3 November


the group . The mailer should deliver a copy of the messag

each member.

5 . The query can return a MB RR as well as one or more MG RRs

This condition means the the mailbox was actually a mailin

list . The mailer can either deliver the message to the ho

specified by the MB RR, which will in turn do the delivery

all members, or the mailer can use the MG RRs to do the

expansion itself.

In any of these cases, the response may include a Mail Inform

(MINFO) RR . This RR is usually associated with a mail group,

is legal with a MB . The MINFO RR identifies two mailboxes.

of these identifies a responsible person for the original mai

name . This mailbox should be used for requests to be added t

mail group, etc . The second mailbox name in the MINFO RR

identifies a mailbox that should receive error messages for m

failures . This is particularly appropriate for mailing,lists

errors in member names should be reported to a person other t

the one who sends a message to the list . New fields may be a

to this RR in the future.

Mockapetris ( P a g

RFC 883 November

Domain Names - Implementation and Specific .

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 1 1 1 0 0



' 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> <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> <let-dig-hyp> <let-dig-hyp> <ldh-str>

<let-dig-hyp> : .= <let-dig> 1 1 1 1

<let-dig> <letter> I <digit>

<letter> any one of the 52 alphabetic characters A throug

in upper case and a through z in lower case

<digit> : .= any one of the ten digits 0 through 9

Note that while upper and lower case letters are allowed in doma

names no significance is attached to the case . That is, two nam

with the same spelling but different case are to be treated as i

identical.

The labels must follow the rules for ARPANET host names . They mstart with a letter, end with a letter or digit, and have as int

characters only letters, digits, and hyphen . There are also som

restrictions on the length . Labels must be 63 characters or les

For example, the following strings identify hosts in the ARPA

Internet:

F .ISI .ARPA LINKABIT-DCNS .ARPA UCL-TAC .ARPA

Mockapetris [Pag

RFC 883 November


Appendix 2 - Field formats and encodings

+***** WARNING *****

The following formats are preliminary and

are included for purposes of explanation only.

In particular, new RR types will be added,

and the size, position, and encoding of

h t t p ://www-bib.fh-blelefeld .de/epub/doc/

` ido c / r f c / i - f c 883 .html 5 / 1 / 0 0



HTML Version from RFC D- - !ment Page 50 of 64

fields are subject to change.

-------------------------------------------

TYPE values

TYPE fields are used in resource records . Note that these tyare not the same as the QTYPE fields used in queries, althoug

functions are often similar.

TYPE value meaning

A 1 a host address

NS 2 an authoritative name server

MD 3 a mail destination

MF 4 a mail forwarder

CNAME 5 the canonical name for an alias

SOA 6 marks the start of a zone of authority

MB 7 a mailbox domain name

MG 8 a mail group member

MR 9 a mail rename domain name

NULL 10 a null RR

WKS 11 a well known service description

PTR 12 a domain name pointer

HINFO 13 host information

MINFO 14 mailbox or mail list information

Mockapetris [Pag_. . .

RFC 883 November


QTYPE values

QTYPE fields appear in the question part of a query . They in

the values of TYPE with the following additions:

AXFR 252 A request for a transfer of an entire zone of auth

MAILB 253 A request for mailbox-related records (MB, MG or M

MAILA 254 A request for mail agent RRs (MD and MF)

* 255 A request for all records

CLASS values

CLASS fields appear in resource records

CLASS value meaning

IN 1 the ARPA Internet

h t t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfe/rfc883 . h t m l 511100




CS 2 . the computer science network (CSNET)

QCLASS values

QCLASS fields appear in the question section of a query . Theinclude the values of CLASS with the following additions:

* 255 any class

Mockapetris (Pag

RFC 883 November


Standard resource record formats

All RRs have the same top level format shown below:

1 1 1 1 1 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

/ NAME /

TYPE

CLASS

T TL

RDLENGTH

/ RDATA /

where:

NAME - a compressed domain name to which this resource

record pertains.

TYPE - two octets containing one of the RR type codes

defined in Appendix 2 . This field specifies the

meaning of the data in the RDATA field.

http: / /w w w - b ib .fn-blelefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 / 1 / 0 0




LASStwo octets which specifies the class of the datathe RDATA field.

TTL - a 16 bit signed integer that specifies the time

interval that the resource record may be cached

before the source of the information should agai

consulted . Zero values are interpreted to meanthe RR can only be used for the transaction in

progress, and should not be cached . For examplerecords are always distributed with a zero TTL t

prohibit caching . Zero values can also be used

extremely volatile data.

RDLENGTH- an unsigned 16 bit integer that specifies the le

in octets of the RDATA field.

Mockapetris L P a . g . . . _


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 . TheRDATA section of a CNAME line in a master file is a standa

printed domain name.

HINFO RDATA format

/ CPU /

/ OS /

where:

CPU - A character string which specifies the CPU type.

character string is represented as a single octe

length followed by that number of characters.

following standard strings are defined : .

PDP-11/70 C/30 C/70 VAX-11/780

ht t p ://www-bib.fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 511100



HTML Version from RFC D , i m e n t P a g e 5 3 o f 6 4

-Y

H-316 H-516 DEC-2060 DEC-1090T

ALTO IBM-PC IBM-PC/XT PERQIBM-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 [ Pa g . .

RFC 883 November


length followed by that number of characters . The follo

standard types are defined : .

ASP AUGUST BKY CCP

DOS/360 ELF EPOS EXEC-8

GCOS GPOS ITS INTERCOM

KRONOS MCP MOS MPX-RT

MULTICS MVT NOS NOS/BE

OS/MVS OS/MVT RIG RSX11

RSX11M RT11 SCOPE SIGNAL

SINTRAN TENEX TOPS10 TOPS20

TSS UNIX VM/370 VM/CMS

VMS WAITS

HINFO records cause no additional section processing.

HINFO records are used to acquire general information abou

host . The main use is for protocols such as FTP that can

special procedures when talking between machines or operat

systems of the same type.

MB RDATA format

/ MADNAME /

where:

MADNAME - A compressed domain name which specifies a host

has the specified mailbox.

MB records cause additional section processing which looks

an A type record corresponding to MADNAME . The RDATA sect

of a MB line in a master file is a standard printed domain

name.

MD RDATA format

/ MADNAME /

where:


Mockapetris [Pag

RFC 88 3 November

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/ldoc/rfe/rfe883.html 5 / 1 / 0 0




r Domain Names - Implementation and Specific

has a mail agent for the domain which should be

to deliver mail for the domain.

MD records cause additional section processing which looks


of a MD line in a master file is a standard printed domainname.

MF RDATA format

/ MADNAME /

where:


has a mail agent for the domain which will accep

mail for forwarding to the domain.

MF records cause additional section processing which looks


of a MF line in a master file is a standard printed domain

name.

MG RDATA format

/ MGMNAME /

where:

MGMNAME - A compressed domain name which specifies a mailb

which is a member of the mail group specified by

domain name.

MF records cause no additional section processing . The RD

section of a MF line in a master file is a standard printe

domain name.

Mockapetris [Pag

RFC 88 3 November


MINFO RDATA format

/ RMAILBX /

/ EMAILBX /

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 511100




where:

RMAILBX - A compressed domain name which specifies a mailb

which is responsible for the mailing list or mai

If this domain name names the root, the owner of

MINFO RR is responsible for itself . Note that m

existing mailing lists use a mailbox X-request f

the RMAILBX field of mailing list X, e .g.Msgroup-request for Msgroup . This field provide

more general mechanism.

EMAILBX - A compressed domain name which specifies a mailb

which is to receive error messages related to th

mailing list o r 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 . Altthese records can be associated with a simple mailbox, the

usually used with a mailing list . The MINFO section of a

line in a master file is a standard printed domain name.

MR RDATA format

/ NEWNAME /

where:

NEWNAME - A compressed domain name which specifies a mailb

which is the proper rename of the specified mail

MR records cause no additional section processing . The RD

section of a MR line in a master file is a standard printe

domain name.

Mockapetris [Pag

RFC 883 November


NULL RDATA format

/ <anything> /

Anything at all may be in the RDATA field so long as it is

65535 octets or less.

NULL records cause no additional section processing . NULL

are not allowed in master files.

NS RDATA format

/ NSDNAME /

ht t p : / /w w w - b ib .fh-bielefeld .de/epub/doe/idoe/rfe/rfc883 .html 5 / 1 / 0 0




where:

NSDNAME - A compressed domain name which specifies a host

has a name server for the domain.

NS records cause both the usual additional section process

to locate a type A record, and a special search of the zon

which they reside . The RDATA section of a NS line in a ma

file is a standard printed domain name.

PTR RDATA format

/ PTRDNAME /

where:

PTRDNAME - A compressed domain name which points to some

location in the domain name space.

PTR records cause no additional section processing . These

are used in special domains to point to some other locatiothe domain space . These records are simple data, and don'

imply any special processing similar to that performed by

CNAME, which identifies aliases . Appendix 3 discusses the

of these records in the ARPA Internet address domain.

Mockapetris [PagFC 883 November


SOA RDATA format

/ MNAME /

/ RNAME /

SERIAL

REFRESH

RETRY

EXPIRE

MINIMUM

where:

MNAME - The domain name of the name server that was the

original source of data for this zone.

RNAME - A domain name which specifies the mailbox . of the

person responsible for this zone.

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doc/idoe/rfc/rfc883 .html 5 1 1 1 0 0



' F :

't


SERIAL - The unsigned 16 bit version number of the of the

original copy of the zone . This value wraps and

should be compared using sequence space arithmet

REFRESH - The unsigned 32 bit time interval before the zonshould be refreshed.

RETRY - The unsigned 32 bit time interval that should el

before a failed refresh should be retried.

EXPIRE - A 32 bit time value that specifies the upper lim

the time interval that can elapse before the zon

no longer authoritative.

MINIMUM - The unsigned 16 bit minimum TTL field that shoul

exported with any RR from this zone (other than

SOA itself).

SOA records cause no additional section processing . The R

Mockapetris [Pag_

RFC 883 November


section of a SOA line in a master file is a standard print

domain name for MNAME, a standard X@Y mailbox specificatio

RNAME, and decimal numbers for the remaining parameters.

All times are in units of seconds.

Most of these fields are pertinent only for name server

maintenance operations . However, MINIMUM is used in all q

operations that retrieve RRs from a zone . Whenever a RR i

sent in a response to a query, the TTL field is set to themaximum 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.

h t t p : / /w w w - b ib .fh-bielefeld .de/epub/doe/idoc/rfc/rfc883 .html 511100



HTML Version from RFC D , a n e n t P a g e 5 8 o f 6 4

Mockapetris [ _ P a.g . . . _

RFC 883 November


Appendix 3 - Internet specific field formats and operations

Message transport

The Internet supports name server access using TCP [10] on se

port 53 (decimal) as well as datagram access using UDP [11] o

port 53 (decimal) . Messages sent over TCP virtual circuits a

preceded by an unsigned 16 bit length field which describes t

length of the message, excluding the length field itself.

***** WARNING *****

The following formats are preliminary and

are included for purposes of explanation only.

In particular, new RR types will be added,

and the size, position, and encoding of

fields are subject to change.

*A RDATA format

ADDRESS

where:

ADDRESS - A 32 bit ARPA internet address

Hosts that have multiple ARPA Internet addresses will have

multiple A records.

A records cause no additional section processing . The RDATA

section of an A line in a master file is an Internet address

expressed as four decimal numbers separated by dots without a

imbedded spaces (e .g . , 1 1 10 . 2 . 0 .52" or 1 1 192 .0 . 5 .6 1 1 ) .

Mockapetris [Pag

h t t p : / / ww w - b ib .fh-bielefeld .de/epub/doe/idoe/rfc/rfc883 . h t m l 5 / 1 / 0 0



HTML Version from RFC r ument Page 59 of 64


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 arespecified 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 belistening on TCP port 25 ; if zero, SMTP service is not supporon the specified address.

The anticipated use of WKS RRs is to provide availabilityinformation for servers for TCP and UDP . If a server support

both TCP and UDP, or has multiple Internet addresses, then

multiple WKS RRs are used.

WKS RRs cause no additional section processing . The RDATA se

of a WKS record consists of a decimal protocol number followe

mnemonic identifiers which specify bits to be set to 1.

IN-ADDR special domain

The ARPA internet uses a special domain to support gateway

location and ARPA Internet address to host mapping . The inte

this domain is to allow queries to locate all gateways on a

Mockapetris [Pag

RFC 883 November


particular network in the ARPA Internet, and also to provide

guaranteed method to perform host address to host name mappin

Note that both of these services are similar to functions tha

could be performed by inverse queries ; the difference is that

part of the domain name space is structured according to addr

h t t p : / / ww w - bi b .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 acharacter 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 aseparate zone for MILNET . Address nodes are used to hold poi

to primary host names in the normal domain space.

Network addresses correspond to some of the non-terminal node

the IN-ADDR tree, since ARPA Internet network numbers are eit

1, 2, or 3 octets . Network nodes are used to hold pointers t

primary host names (which happen to be gateways) in the norma

domain space . Since a gateway is, by definition, on more tha

network, it will typically have two or more network nodes tha

point at the gateway. Gateways will also have host level poi

at their fully qualified addresses.

Both the gateway pointers at network nodes and the normal hos

pointers at full address nodes use the PTR RR to point back t

primary domain names of the corresponding hosts.

For example, part of the IN-ADDR domain will contain informat

about the ISI to MILNET and MIT gateways, and hosts F .ISI .ARP

MULTICS .MIT .kRPA . Assuming that ISI gateway has addresses

Mockapetris [Pag

RFC 883 November


10 . 2 . 0 .22 and 26 . 0 . 0 .103, and a name MILNET-GW .ISI .ARPA, and

MIT gateway has addresses 10 . 0 .0 .77 and 18 .10 .0 .4 and a name

GW .MIT .ARPA, the domain database would contain:

IO.IN-ADDR

PTR INMILNET-GW

.ISI .ARPA10 .IN-ADDR PTR IN GW .MIT .ARPA

18 .IN-AD D R PTR IN GW .MIT .ARPA26 .IN-ADDR PTR IN MILNET-GW .ISI .ARPA

22 .0 . 2 .10 .IN-ADDR PTR IN MILNET-GW .ISI .ARPA

103 . 0 . 0 .26 .IN-ADD R PTR IN MILNET-GW .ISI .ARPA

77 . 0 . 0 .10 .IN-AD DR PTR IN GW .MIT .ARPA4 .0 .10 .18 .IN-ADDR PTR IN GW .MIT .ARPA

52 . 0 . 2 .10 .IN-AD DR PTR IN F .ISI .ARPA

6 .0 . 0 .10 .IN-ADDR PTR IN MULTICS .MIT .ARPA

Thus a program which wanted to locate gateways on net 10,woul

originate a query of the form QTYPE=PTR, QCLASS=IN,

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfc/rfc883 .html 5 1 1 1 0 0



HTML Version from RFC D( -rent Page 61 of 64

QNAME=10 .IN-ADDR . It would receive two RRs in response:

IO .IN-ADDR PTR IN MILNET-GW .ISI .ARPA

IO .IN-ADDR PTR IN GW .MIT .ARPA

The program could then originate QTYPE=A, QCLASS=IN queries f

MILNET-GW .ISI .ARPA and GW .MIT .ARPA to discover the ARPA Inter

addresses of these gateways.

A resolver which wanted to find the host name corresponding t

ARPA Internet host address 10 . 0 .0 .6 might first try an invers

query on the local name server, but find that this informatio

wasn't available . It . could.then try a query of the form

QTYPE=PTR, QCLASS=IN, QNAME=6 . 0 .0 .10 .IN-ADDR, and would recei

6 . 0 . 0 .10 .IN-ADDR PTR IN MULTICS .MIT .ARPA

Several cautions apply to the use of these services:

Since the IN-ADDR special domain and the normal domain for

particular host or gateway will be in different zones, the

possibility exists that that the data may be inconsistent.

Gateways will often have two names in separate domains, onone 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 _ [ _ P a g

RFC 883 November


manner equivalent to the current HOSTS .TXT file . It doesn

replace the dynamic availability information from GGP or E

ht t p: / /w w w - b ib .fh-bielefeld .de/epub/doc/idoc/rfe/rfc883 .html 5 1 1 1 0 0



HTML Version from RFC Df nent P a g e 6 2 o f 6 4

Mockapetris [Pag

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

[2] J . Postel, "Computer Mail Meeting Notes" RFC_ 805,

USC/Information Sciences Institute, February 1982.

[3] Z . Su, and J . Postel, "The Domain Naming Convention for Int

User Applications", RFC 819, Network Information Center, SR

International, August 1982.

[4] Z . Su, "A Distributed System for Internet Name Service",


October 1982.

[5] K . Harrenstien, and V . White, "NICNAME/WHOIS", RFC 812NetInformation Center, SRI International, March 1982.

[6] M . Solomon, L . Landweber, and D . Neuhengen, "The CSNET Nam

Server", Computer Networks, vol 6, nr 3, July 1982.

[7] K . Harrenstien, "NAME/FINGER", RFC 742, Network Information

Center, SRI International, December 1977.

[ 8 ] . J . Postel, "Internet Name Server", IEN 116, USC/InformationSciences Institute, August 1979.

[9] K . Harrenstien, V . White, and E . Feinler, "Hostnames Server


March 1982.

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

USC/Information Sciences Institute, September 1981.

[11] J . Postel, "User Datagram Protocol", RFC 768, USC/Informati

Sciences Institute, August 1980.

http: / /w w w - b ib .fh-bielefeld.de/epub/doc/idoc/rfe/rfc883 .html 5 1 1 1 0 0



HTML Version from RFC D( rent Page 63 of 64

[12] J . Postel, "Simple Mail Transfer Protocol", RFC 821,

USC/Information Sciences Institute, August 1980.

[13] J. Reynolds, and J . Postel, "Assigned Numbers", RF_C870,

USC/Information Sciences Institute, October 1983

[14] P . Mockapetris, "Domain names - Concepts and Facilities,"

RFC 882, USC/Information Sciences Institute, November 1983.

Mockapetris [Pa

RFC 883 November


INDEX

* usage. . . . . . . . . . . . . . . . . . . . . . .

A RDATA formatyte order

ache queuecharacter caseLASSompletionompressionNAME RReader formatINFO RRnclude filesnverse queriesailbox namesaster filesB RRD RRessage formatF RRG RRINFO RRR RRULL RRS RRTR RR

QCLASSTYPEueries (standard)ecursive serviceR formatOA RRpecial domainsYPEKS type RR

ht t p : / /w w w - b ib .fh-bielefeld.de/epub/doc/idoe/rfc/rfc883.html 5 / 1 / 0 0



HTML Version from RFC D~ nent Page 64 of 64

Mockapetris [Pag

Converted to HTML with rfc2html from RFC 883 at Mon May 123 :0 7 :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 _WebmasterWiischenswertes andAnregungen bitte an : webmaster(a)wW ib.fli-bielefeld.de

ht t p ://www-bib.fh-bielefeld.de/epub/doe/idoe/rfc/rfc883 .html 5 / 1 / 0 0





NOTICE OF ALLOWANCE AND ISSUE FEE DUE

( ~ l • , 1 i ~ f j ( : ~ I ' f ' v

. t ( 1 F • ~ { ~ : 1 _ I Y r i l i ~ : : . li : i a i i l :!

f • ~ N : :~ . !~ . I 'Y f :ff tl : P '.I`f :f . E i a , t- :r':

APPLIC ATIO N NO . FIL ING D ATE TO TAL C LAIMS EXAMINER AND GRO UP ART UNIT DATE MAILED

Fi rst NamedAppl icant . E a } ; : i . l . ., i . + a :f • t. { .— , is i:'+°fi + i r ! ; 1 : „ 1 . 4 (+r :1 ;'ic., ;.

TITLE OF?Y .} I f : ; : . , ' 1 '! ! ' , { F : : I f°If;lt :+ f' f . _ I F , h 1 i _ L .I!_!IYff-1 f :f . k . : < ' l f . : :l : :F :: .•i9`: l.p F F Y I ' 1 1 :: ; 1_ f . .fMI"1 . . ,11 : :Fi C I V 1 , 1 " < A

tINVENTION

:: :• . .~1 IC : ;

. .i . . l a f f t

ATTY 'S DOC KET NO . C LA SS- SUB C LA SS BATCH NO . APPLN . TYPE SMALL ENTITY FEE DUE DATE DUE

4 c ;la . . . . rl ;: , a . :' S t+ :• >t ;'= ,, iitiU f~ 1 :1 . UT:[i. . 1"i0(1 !:I ;j to t111!

T H E A P P L I C A T I O N I D E N T I FIE D A B O V E H A S B E E N E X A M I N ED A N D I S A L L O W E D F O R IS S U A N C E A S A P A T E N T ,

P RO SE CUT I O N O N T HE M E RI T S I S CLO SE D .z

T HE I SSUE F E E M UST BE P A I D W I T HI N T HRE E M O NT HS F RO M T HE M A I LING D A T E O F T HI S NO T ICE O R T HI SA P P L IC A T I O N S H A L L B E RE G A R D E D A S A B A N D O N E D . T H IS S T A T U T O R Y P E R IO D C A N N @ T B E E X T E N D E D .

HOW TO RESPOND TO THIS NOTICE:

1 . Review the SMALL ENTITY sta tus shown ab ove .

Y

I f the SMALL ENTITY is show n as Y ES, ver ify your I f t he SMALL ENTITY is shown as NO :cur rent SMALL ENTITY status:

A. I f the sta tus is chang ed, pay twics the amou nt o f theFEE DUE show n above and no t if y the Paten t and A . Pay FEE DUE shown above , o r

Trademark O f f ice o f the change in sta tus, orB. I f the status is the same, pay the FEE D UE show n

above . B . F i le ver i f ied stateme nt of Smal l Ent i ty Status before, or w i th,paymen t o f 1 /2 the FEE DUE shown above .

1 1 . Par t B-Issue Fe e Transmi t ta l shou ld be completed and re turne d to the Patent and Tradema rk O f f ice (PTO ) wi th yourISSUE FEE . Even i f the ISSUE FEE has a l ready been pa id by charge to deposi t accou nt , Par t B,Issu e Fee Trans mi t ta lshou ld be com ple ted and re t u rned . If y o u are charg ing the ISSUE FEE to you r deposi t accou nt , sect ion "4b" o f Par tB-Issue Fee Transmi t ta l shou ld be completed and an ext ra copy o f the form shou ld be submi t ted .

1 1 1 . All commun icat ions regarding th is appl icat ion must g ive appl icat ion numbe r and batch num ber .Please d irect a l l comm unicat ions pr ior to issua nce to Box ISSUE FEE unless adv ised to the cont rary .

I M P O RT A NT RE M I ND E R : . U t il it y p a t e n t s i s s u i ng o n a p pl ic a t i o n s f i le d o n o r a f t e r D e c . 1 2 , 19 80 m a y r e q u i r e p a y m e n t o fm a i nt e n a n c e f e e s . It i s p a t e n t e e ' s r e s p o n s i b i li t y to e n s u r e t i m e l y p a y m e n t o f m a i n t e n a n c ef e e s w h e n d u e .

PATENT AND TRADEMARK OFFICE . COPYPTOL-85 (REV. 10 -96) Approved fo r use th rough 06 /30 /99 . ( 0651-00 33) * U .S . G P O : 1 9 9 9 .45441F/24601



s,

PART B—ISSUE FEE; TRANSMITTAL

- - comp le te and m a i l th i s fo rm , tog e th e r w ith ap p l ic a i d , . jes ; t o : Box ISSUE FEEAss is tan t Comm iss ioner fo r Pa ten ts •,Was h ington , D .C . 20231

MAILING INSTRUCTIONS: This form should be used for t ransmitt ing the ISSUE FEE . Blocks' 1 N o t e : T h e c e r t if ic a t e o f m a i l in g b e l o w c a n only b e u s e d f o r d o m e s t i ct h r o u g h 4 s h o u l d b e c o m p l e te d w h e r e a p p r o p r ia t e . All further correspondence including the Issue Fee m a i li n g s o f t h e I s s u e F e e T r a n s m i tt a l . T h i s c e r t if ic a t e c a n n o t b e u s e dReceipt, the Patent, advance orders and notification of maintenance fees will be mailed to the current f o r a n y o th e r a c c o m p a n y i n g p a p e r s : E a c h a d d i ti o n a l p a p e r , s u c h a s a ncorrespondence address as indicated unless corrected below or directed otherwise in Block 1, by (a) a s s i g n m e n t o r f o r m a l d ra w i n g , m u s t h a v e I t s o w n c e r t i fi ca t e o f m a i li n g .specifying a new correspondence address ; and/or (b) indicating a separate "FEE ADDRESS" formaintenance fee notifications . Certificate of Mailing

1 h e r e b y c e r t i fy t h a t th i s Is s u e F e e T r a n s m i tt a l is b e i n g d e p o s i t e d w i t hU R R E N T C O R R E S P O N D E N C E A D D R E S S ( N o t e : L e g ib l y m a r k - u p w i th a n y c or r e c ti on s o r u s e B l o ck 1)

t h e U n i te d S t a t e s P o s t a l S e r v i c e w i th s u f f i ci e n t p o s t a g e f o r f ir s t c la s s! ! - • -1

:1m a t l in a n e n v e l o p e a d d r e s s e d t o t he B o x I s s u e F e e a d d r e s s a b o v e o nt h e d a t e I n d ic a t e d b e l o w .. ..

I ~ ~ ! I ' .i.

1f. . .i!

.. .!I{ i~ I" ' ..'IFr•11"' .1 • :, I„IiY 1l : :: . ; , I : : : . :' :% ! ;i aQ

too

I ' . .. . l I :' : i ..1L . .J ; : a : l`•i!: iN 2 1

` 4a l~ rLinda Ga r r amo n e ( D e p o s i t o r ' s )a m e

!̀%1'trt :ji:

;'i• . 1•~1y 1 . !- ! J . ( S i g n a t u r e )

Jtane 20 ; 2000 ( D a t e )

A P P L IC A T I O N N O . F I L IN G D A T E T O T_WMS E X A M I N E R A N D G R O U P A R T U N I T D A T E M A I L E D

F i r s t N a m e dA p p l i c a n t

r c : ' i:• r : :' l .. ', . ., "

T I T L E O F ! . . . . . . ! !I N V E N T I O N

; : :r ( ! 1 : :{ F :: t l I. .{ . . ! : . 1 {r l ! .1 .! . . ;

.. :! .1 _ :- ! . , I - tj I : : I ' ' f l .: :t

..l . !. , :! _ E f t ` I I ' . .J

. .I € : : :Iti AVER..f''t I ' ' • . I€ : : : :

.. ..f% : :I., J

A T T Y ' S D O C K E T N O . C L A S S - S U B C L A S S B A T C H N O . A P P L N . T Y P E S M A L L E N T I T Y F E E D U E D A T E D U E

i1:: , I, ! . . . . I . . ! .{ . (?" :? _ I . 1 ! ` • { .1 . . 2 i . • (

. .{ . ..{ . { .. _ .{ . 'i 'Y{: . r "0!?

1 . C h a n g e o f co r r e s p o n d e n c e a d d r e s s o r I n d ic a t io n o f " F e e A d d r e s s " ( 3 7 C F R 1 . 3 6 3 ) . 2 . F o r p r i n ti n g o n t h e p a t e n t f r o n t p a g e , l i s tU s e o f P T O f o rm ( s ) a n d C u s t o m e r N u m b e r a r e r e c o m m e n d e d , b u t n o t re q u i re d . ( 1 ) t h e n a m e s o f u p t o 3 r e g i s t e r e d p a t e n t 1 Greenberg Traurig, LLP

a t t o r n e y s o r a g e n t s O R , a l t e r n a t iv e l y , (2 )

q C h a n g e o f co r r e s p o n d e n c e a d d r e s s ( o r C h a n g e o f C o r r e s p o n d e n c e A d d r e s s f o r m t h e n a m e o f a single firm (having as aa g e n t ) Anthony R. Bar]wtx=

P T O / S B / 1 2 2 ) a t ta c h e d . member a registered attorney or 2a n d t h e n a m e s o f u p t o 2 re g i s t e r e d p a t e n t

q " F e e A d d r e s s " I n d i ca t io n ( o r " F e e A d d r e s s " I n d ic a t io n f o r m P T O / S B / 4 7 ) a t t a c h e d . a t t o r n e y s o r a g e n t s . If n o n a m e i s l i s t e d , n on a m e w i ll b e p r in t e d . 3

3 . A S S IG N E E N A M E A N D R E S I D E N C E D A T A T O B E P R I N T E D O N T H E P A T E N T ( p r in t o r ty p e ) 4 a . T h e f o ll o w in g f e e s a r e e n c lo s e d ( m a k e c h e c k p a y a b l e t o C o m m i s s io n e rP L E A S E N O T E : U n l e s s a n a s s i g n e e i s i d e n t i fi e d b e l o w , n o a s s i g n e e d a t a w i ll a p p e a r o n t h e p a t e n t . o f P a t e n t s a n d T r a d e m a r k s ) :I n cl u s io n o f a s s i g n e e d a t a i s o n l y a p p r o p la t e w h e n a n a s s i g n m e n t h a s b e e n p r e v i ou s l y s u b m i tt e d t o ®Issue Feet h e P T O o r is b e i ng s u b m i tt e d u n d e r s e p a r a t e c o v e r . C o m p l e t i o n of th i s fo r m i s N O T a s u b s i ti tu e f o rf il in g a n a s s i g n m e n t . q A d v a n c e O r d e r - # o f C o p i e s

( A ) N A M E O F A S S I G N E E NeoMed.ia Technologies, .Inc .4 b . T h e f o l lo w i n g fe e s o r d e f i c ie n c y i n t h e s e f e e s s h o u l d b e c h a r g e d t o :

( B ) R E S I D E N C E : ( C IT Y & S T A T E O R C O U N T R Y ) D E P O S I T A C C O U N T N U M B E R

category Indicated below b e th el e a s e c h e c k t h e a p p r o p r ia t e a s s i g n e e ( w i l l n o t p r i n te d o n p a t e n t )( E N C L O S E A N E X T R A C O P Y O F T H IS F O R M )

q I s s u e F e eq Individual M corporation or other private grou p entity q g o v e r n m e n t q A d v a n c e O r d e r - # o f C o p i e s

T h e C O M M I S _ q I O N E W F P A T E N T S A N D T R A D E M A R K S IS r e q u e s t e d t o a p p ly t h e I s s u e F e e t o t h e a p p l ic a t i on I de n t if i e d a b o v e . c

N O T E ; IY e s u e F e e W i ll n o t b e a c c e p t e d f r o m a n y o n e o t h e r t h a n t h e a p p l ic a n t ; a r e g i s t e r e d a t t o r n e yo r a g e n t ; o r h e a s s i g n e e o r o t h e r p a r t y In i n te r e s t a s s h o w n b y t h e r e c o r d s o f t h e P a t e n t a n dT r a d e m a r k O f fic e .

Burden Hour Statement: T h i s f o r m i s e s t i m a t e d t o t a k e 0 . 2 h o u r s t o c o m p l e te : T i m e w i ll v e r yd e p e n d i n g o n t h e n e e d s o f th e i n d i v id u a l c a s e . A n y c o m m e n t s o n t h e a m o u n t o f t im e r e q u i re dt o c o m p l e t e th i s f o rm s h o u l d b e s e n t t o th e C h i e f I n f o r m a t i o n O f fi c e r , P a t e n t a n d T r a d e m a r kO f f ic e , W a s h i n g t o n , D .C . 2 0 2 3 1 . DO NOT SEND FEES OR COMPLETED FORMS TO THISA D D R E S S . SEND FEES AND THIS FORM TO : B o x I s s u e F e e , A s s i s t an t C o m m i s s io n e r f o rP a t e n t s , W a s h in g t o n D .C . 2 0 2 3 1

Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collectionof information unless it displays a valid OMB control number .

TRANSMIT THIS FO RM W ITH FEE

P T O L - 8 5 B ( R E V . 1 0 - 9 6 ) A p p r o v e d f o r u s e t h r o u g h 0 6 / 3 0 / 9 9 . O M B 0 6 5 1 - 0 0 3 3

rri r i

G dP a t e n t a n d T r a d e m a r k O f f ic e ; U .S . D E P A R T M E N T O F C O M M E R C E

I•4I

I



UNITED STATES .D! ;ARTMENT OF COMMERCEPatent and Tradem ark Of f iceAddress : COMMISSIONER OF PATENTS AND TRADEMARKS

6 1ArE8 Washington, D .C 20231

APPLICATION NO . FILING D ATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO.

1017 EXAMINER

i = ` i I ' .L.L'I II1I~ . I ' ' ~ ' 1 = { X : { F 1 U ' t i I : 1 _ 1 1 ' ' ' 1 [ : :• :ai;( ~.. .

C iP" t I:- ., 1\Ih ;I : :IR .. L . f i A L A - Z I f l ° i

MET I _ .1 f: 'E;: U .1 L .. .1'! 7 : 1 ' ` • I l :i A R T U N I T PAPER NUMBER

I\1E., 14 Y (-I F K Ny :1 . Cl :I ,

DATE MAILED :C l IpQf~

Please f ind be low and/or a t tached a n Of fice com m unica t ion concern ing th is ap p l ica t ion orp roceed ing .


PTO-90C (Rev. 2/95) - 1 - File Copy

U .S . G .P . 0 . 2 0 0 0 ; 48 5 -1 8B/ 2 5288

I



~ I

1 1 F~ c e o f A /l o w a b i li f v

Al l cla ims be ing a l lowab le , PRO SEC UTIO N O N THE MERITS IS (O R REMAINS) C LO SED in th i s app l i ca tion . If not included

herewith (or previously mailed), a Notice of Allowance and Issue Fee Due or other appropriate communication will be mailed

i n due cou rse .

K T h is c o m m u n ic a t io n i s re s p o n s iv e t o t h e a me n d m e n t f il e d o n 0 5 1 3 1 0 0 a n d th e No ti ce o f Al lo w o n 0 5 1 3 1 1 0 0

K The a l lowe d c la im(s) is /a re

q Thedrawngsfiledon areacceptabe

q Acknowledgement is made of a claim for foreign priority under 35 U .S .C . § 119(a ) - (d ).

q Al l q Some" [gone of the CERTIFIED copies of the priority documents have been

q received.

q rece ived in App l i ca tion No . (Se r ies Code /Se r ia l Number )

q received in this national stage application from the International Bureau (PCT Rule 17 . 2 (a) ) .

`C er t i f ied cop ies not rece ived:q Acknowledgement is made of a claim for domestic priority under 35 U .S .C . § 11 9 (e ) .

A SHO RTENED STATUTO RY PERIOD FO R RESPO NSE to comp ly w i th the requ i remen ts no ted be low i s se t to EXPIRETHREE MO NTHERO M THE "DATE MAILED" o f th is O f f ice ac t ion . Failure to timely comply will result in

ABANDO NMENT of th is app l ica t ion . Extensions of time maybe obtained under the provisions of 37 CFR 1 . 136 (a ) .

q Note the a t tached EXAMINER'S AMENDMENT o r NOTIC E O F INFORMAL APPLICATIO N, PTO -152 , wh ich d isc loses tha tthe oath or declaration is deficient . A SUBSTITUTE O ATH OR D EC LARATION IS REQ UIRED.

App l ican t MUST subm i t NEW FO RMAL DRAW INGS

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 toPaper No . 4 .

including changes required by the proposed drawing correction filed on May 3 . 2000 which has beenapproved by the examiner .

q i n c lud ing changes requ i red by the a t tached Examine r ' s Amendmen t /Comme n t .

Identifying indicia such as the application number (see 37 CFR 1 .84(c)) should be written on the reverse side: o fthe drawings . The drawings should be filed as a separate paper with a transmittal lettter addressed to the OfficialDraftsperson.

q Note the a ttached Examine r ' s commen t rega rd ing REQUIREMENT FO R THE DEPO SIT OF BIO LO GIC AL MATERIAL .

Any respons e to th is le t te r shou ld inc lude, in the up per r igh t hand corner , the APPLICATIO N NUMBER (SERIESC O DE/SERIAL NUMBER) . If applicant has received a Notice of Allowance and Issue Fee Due, the ISSUE BATCH NUMBERa n d D AT E o f th e NO T IC E O F ALLO W ANC E s h o u l d a l so be i n c lu d e d .

Attachment(s)

q Notice of References Cted, PTO-892 ̂

q I n fo rma t ion D isc losu re S ta temen t (s ) ; PTO-14 49 , Paper No(s ).

q Not ice o f D ra f tspe rson 's Pa ten t D raw ing Rev iew, PTO-948

q Notice of Informal Patent Application, PTO-152

q I n te rv iew Summary , PTO-41 3

q Examine r ' s Amendmen t /Commen t

q Examine r ' s C ommen t Rega rd ing Requ i remen t fo r De pos i t o f B io log ica l Ma te r ia l

~C ] Exam ine r' s S ta temen t o f Reasons fo r A l lowance

U . S . Patent and Trademark Off ice

PTO-37 (Rev . 9-95) Notice of Allowability Part o f Paper No . ~ 10

Appl i ca t ion No.

091232,908

Applicant(s)

Hud ez et al.

Group Art U

2183an



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

s e e c l a i m 3 3 ) .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 pluralityof 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

( se e c l a i m 6 8 ) .

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

P R IMAWINER

I



TRANSMITTAL OF INFORMA0 UR E STATEMENT Docket No.

MUn d e r 37 Q W 1997L9 or 197 ( 150-061A

In Re Application Of : Hudetz et aLiW

Serial No . Filing Date Examiner Group Art Unit

09n32,908 January 15 , 1 9 9 9 Pan, D . 2 78 3

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

Match & Retur"

A d d r q 6 1 1 9 F(EGENkUAssi s tan t Commiss ioner fo r Patents %

Wash ing ton , D .C . 20231MAY 3 12000

37 CFR 117(b) OROUP 2700

1 . Ll The Information Disclosure Statement submitted herewith is being filed within three months of the

filing of a national application; within three months of the date of entry of the national stage as set forth

in 37 CFR 1 A91 in an international application ; or before the mailing date of a first Office Action on

the merits, whichever event occurs last .

37 CFR I 11c)

2 . Z The Information Disclosure Statement submitted herewith is being filed after three months of the filing

of a national application, or the date of entry of the national stage as set forth in 37 CFR 1 .491 in an

international application ; or after the mailing date of a first Office Action on the merits, whichever

occurred last but before the mailing date of either:

1 . a Final Action under 37 . CFR 1.113, or

2 . a Notice of Allowance under 37 CFR 1 . 3 1 1 ,

whichever occurs first.

Also submitted herewith is:

0 a certification as specified in 37 CFR 1 .97(e) ;

OR

29 the fee set forth in 37 CFR 1 .17(p) for submission of an Information Disclosure Statement

/ 2 0 0 0 B l iA B T E W 0 01 .97(c)`

:122 2 4 0 . 00 OR

Copyright 1996 Legalsoft P 1 0 A / R E V 0 1



TRANSMITTAL OF INFORMAT40N DISCLOSURE STATEMENT Docket. No.

(Under 37 CFR 1.97(b) or 1 .97 c 1 5 0 - 0 6 1 A

In Re Application Of : Hudetz et al . u~

,W ar z 5 t i

Serial No . Filing Date . Examiner Group Art Unit09/232,908 January 15, 1999 P a n , D . 2783

Title : S Y S T E M A N D M ET H O D F OR A U T OM A T IC A C CE SS O F A RE M OT E C OM P UT E R OVE R A N E TWO R K

Payment of Fee

if Applicant to the fee forth in 37 CFR 1 .17(p)) MAY 3 t ? Q 0 0Only complete elects pay set

® A check in the amount of $ 2 4 0 . 0 0 is attached . U. , ._ .- E 217,00q The Assistant Commissioner is hereby authorized to charge and credit Deposit Account No.

as described below. A duplicate copy of this sheet is enclosed.

q Charge the amount of

q Credit any overpayment.

q Charge any additional fee required.

Certificate of Transm iss ion by Facsimile* C e rt ific a te o f M a il in g b y Fir st C la s s M a il

I certify that this document and authorization to charge depositI certify that this document and fee is being deposited on

account is being facsimile transmitted to the United States 0 5 / 2 2 / 2 0 0 0 With the U .S. Postal Service as first

class mail under 37 C .F .R . 1 .8 and is addressed to thePatent and Trademark Office (Fax. No . ) o n

Assistant Commissioner for Patents, Washington, D .C .

(Date)20231.

S igna tu r e S igna tu r e a o n M a i l i n g Co r r e s p o n d e n c e

L i n d a G a r r a m o n e

T y p e d o r P r i n t e d N a m e ofP erso n S i g ni n g C e r t i f i c a t e T y p e d o r P r i n t e d N a m e o f P e r s o n M a i l i n g C o r r e s p o n d e n c e

*This ce r t i f i ca t e m a y only be use d i f paying bydeposi t accou t .

Dated : May 22, 2000Signature

Anthony Barkume , Esq .G ree n berg Trau r i g , L L P

Met Li fe Building2 0 0 P a r k AvenueNew York, NY 10 166212-801-9294

I .

cc :

Copyright 1996 Legalsoft



a

INFORMATION DISCLOSURE CITATION

(Use several sheets if necessary)

ATTY DO C KET NO . SERIAL NO .

150-061A 09/232,908

APPLICANT(S)Hudetz et al.

FILING DATE

01/15/99

GRO UP

J'$

U .S . PATENT DOCUMENTS

*EXAMINER

I N I T I A LDO CUMENT NUMBER DATE NAME . C LASS SUBC LASS FILING DATE

IF APPROPRIATE

5,841,978 11/24/98 Rhoads

" M A Y?~k`` M AY 31 2000

GROU 2?0

FOREIGN PATENT DOCUMENTS

DO C UMENT NUMBER DATE C O UNTRY C LASS SUBC LASSTRANSLATION

YE S N O

OTHER DOCUMENTS (Including . Author, Title, Date, Pertinent Pag es, Etc .)

EXAMINER DATE CONSIDERE

ÈXAMINER : In it ia l i f r e fe r ence consi dere e ther o r not c it a ti o n is i n con fo rmance w ith MPEP 609 ; Draw Ii rough ci tation i f not in conformance and not

considered . Include copy of th is form wi ext commun ication to appl icant .

Form PTO-A820 P09C/REV03 Patent and Tradem ark Office • U .S . DEP ARTMENT OF COMMERCE

(also form PTO-1449)PAGE 1 OF 1



Q



's -

twF CO

*

. UNI TED " S TA TES D EPA RTMENT OF COMMERCEPatent and Trademark Office

Address : CO MMISS IONER OF PATENTS AND TRADEMARKS~~~ res eF W ashington, D . C . 2 0 23 1

APPLICATION NO . FILING DATE FIRST NAMED INVENTORy; TT . . D OC K E T N O .

I_'_i ,., .. _W

f lY l :" c: :l . / 1 .! 9 . :{. 1 )EXAMINER

Al 1011Y FR B()R[*" UIY IE ESfA

GREE::NBER1:7 "rRf-11_ R I G'i

ME : 1 - LIFE IL{I_! I I_DT I K'i ) R I T U N I T PAPER NUMBER

201:1 FAF K AVENUE

NE M Y01-ti NY 1r_1166C ! :LI1/f11~

D A T E M A IL ED :

Please find below and/or attached an Office communication concerning this application or

proceeding .


PTO-90C (Rev . 2/95)

U .S . G.P .O. 2 0 0 0 ; 4 6 5 - 1 8 8 / 2 5 2 6 8



's,

A p p l ic a t i o n N o . Applicant(s)

Interview Summary091232,908 Hud etz et al .

Examiner G r o u p A r t U n it

Pa n 2183

Al l par t ic ipants (app l icant , app l icant 's representa t ive, PTO person ne l) :

(1 ) Pa n (3 )

(2) B a r k u m e (4 )

Date of Interview Jan 16. 2 0 0 1

Type : nelephonic personal (copy is given to a4licant a Vicant's representative).

Exh ib i t shown o r demons t ra t ion conduc ted : [D3s Im o . If yes, br ie f descr ip t ion:

Agreement nuas reached . [Das no t r eached .

C la im(s ) d i s cussed : all claims on the record.

Ident i f ica t ion o f p r io r a r t d iscuss ed:

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. T he O f fi c e ac t i ons on 0 5 1 31 1 0 0 and 1 0 / 17 1 0 0 r e m a i n i n

ef fec t . The reasons for allowance set forth in Paper # 10 are also applicable to newly cited reference 5, 641, 978. S e e a t ta c h e d

14 4 9.

(A fuller description, if necessary, and a copy of the amendments, if available, which the examiner agreed would renderthe 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.

Un less the pa rag raph above has been checked to ind ica te to the con t ra ry , A FO RMAL W RITTEN RESPONSE TO THE . LAST

O FFICE AC TIO N IS NO T WAIVED AND MUST INC LUDE THE SUBSTANCE O F THE INTERVIEW . (See MPEP Section

71 3 . 0 4 ) . If a response to the last Office action has already been filed, APPLICANT IS GIVEN ONE MONTH FROM THISINTERVIEW DATE TO F ILE A STATEMENT OF THE SUBSTANCE O F THE INTERVIEW .

2 . q Since the Examiner's interview summary above (including any attachments) reflects a complete response toeach 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

O f f ice a c t ion . Applicant is not relieved from providing a separate record of the interview unl 1 abovei s a l so checked .

PRIY

ER

Examiner Note : You mu st sign and stamp this form unless it is an attachment to a signed O ffice action .

U . S . Patent and Trademark Offlce -

PT O-41 3 (Re v . 1 0 -95 ) Interview SummaryPaper No

. 13



. f

.e lm Y

TRANSMITTAL OF FORMAL DRAWINGS 30 /yDocket N

( In Response to Not ice of In formal Draw ings) 1 ~ y 150-061A

In Re Application Of : Hudetz et al .R~K p

Serial No . Filing Date Batch No . Examiner Art Unit

09/232,908 01/15/99 N1 8 P a n , D . 2783

Invention : S Y S T E M A N D METHO'D'FOlt AU TOMATIC ACCESS OF A REMOTE COMPUTER OVER A

N ET WO R K

Address to:

Assistant Commissioner for Patents

Washington, D .C . 2 0 2 3 1

In response to the NOTICE OF INFORMAL DRAWINGS mailed on 11/29/99 attached please find:

(date)

(a ) Five (5) sheets of formal drawing(s) for this application.

Each sheet of drawing indicates the identifying indicia suggested in 37 CFR Section 1,84(c)on the reverse side of the drawing.

(b) A copy of the NOTICE OF INFORMAL DRAWINGS.

m oi/ Dated: June 15, 2000

Signature

Z on yn I L B a r k u m e , Esq .,G r e e n b e r g T r a u r ig , L L P

Met Life Bui lding2 0 0 P a r k A v e n ue I certify that this document and attached dra wings are being

N e w Y o r k , N Y 1 0 1 6 6 deposited on 0 6 / 15 /"2 0 0 0 with the U .S . . P o s t a l

(212) 801-9294Service as first class mail under 37 C .F .R . 1 .8 and addressedto the Assistant C ommissioner for Patents, W ashington, D .C.

2 0 2 3 1 .i

Signature of Pe so n ailing Correspondence

L i n d a G a r r a m o n eT y p e d or Printed Name ofPerson Mailing Correspondence

P23A/REV01



BASE "" NLMOTE

P R O V I D E R N O D E 2 6

5 0~ --I L O C A L L 3 2( HO ST

3 6 M O D E M R A M4 8

3 4 40 'IRTICLE

DATA/ADD RESS BUS

4 6 ►

4 2 II

3 8 I i

I C P U 3 0 1 /0 PO RT INPUTDEVICE

44

5 2 F I G . 23 6 .

5 02 8

54 Illlllllllillllllll

® 4 4 4 8so up

4 6 Ih p



62- \

6 4 -

6 6 —

68-

D®tea, 90~

FIG . 5

LOAD BROWSER

8 0 SOFTWARE

4 88 2 LOAD QUERRY

PAGE

6

8 4 ENTER UPC PRODUCT

ID NUMBER

8 6LOOK UP

UPC CODE

RETURN- MATCHINGa 8

RECORDS

9 0 DISPLAY RESULTS

9 2LOAD DESIRED

FIG . 4 A D D R E S S

70> 72, ~ 60. ~74 ~76

UPC-A UPC-B URL DESC

31251 00301 samp le .soup . com/sub f i l e / Inddx .h tmi sou

31251 00302 sample,s . o u p .com/promotion/maln .h tmi giveaway

31251 00400 tes t .mllk .org milk

4205 cars . com/tes td r ive%main .h tmi cars

L-78

0 01 7 3 5 6 8 " 412541 1 1 . 2

A

B



9 6 .

98

1 0 0

F I G . 7

1 1 2

i l l l p~-10 8

%///// 1 1 0



_j

7

REMOTE SERVICE .

SERVER PROVIDER 224

ZZ 8 2210 Z/o

222

234236

2/Io MODEM

2~¢ DOCUMENT

212 COMPUTER ~

~232

BAR

CODE

READER

Z/B

~220





F o r m P T O 9 v . U .S . DEPARTMENT OF COMMERCE -Patent and Trademark Office Application No.~.

NOVICE OF 4 DRAFTSPERSON'S ,

M G N

%

1 $ PA T 'EI4T DRAWING RI~Vf Wh

The drawing ' sert date) re :

A . O approved by the Draftsperson under 37 CFR 1 . 84 o r 1 . 1 52 .B ; .J~!objected to by the Draftsperson under 37 CFR 1 . 84 o r 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 . D R A W I N G S . 37 CFR 1 .84(a) : Acce ptab l e d a te io r iP s o f d r awin gs:Black ink . C olo r .

Co l o r d r awin gs a r e n o t acce ptab le u n t i l pe t i to n i s , granted.Fig(s)Pe n c i l an d no n b l ack in k no t pe r m i t t e d . F ig (s)

2 . P H O T O G R A P H S . 3 7 CF R 1 .84 (b)

_ 1 full-tone set is required . F ig ( s )— P h o t o g r a p h s n o t p r o pe r l y m o u n t e d ( m u s t u s e b r y s t o l b o a r d o r

pho to gr aphic d o u b l e -we ight pape r ) . Fig(s)

_ Poor quality (half-tone) . F ig ( s )3 . T Y P E O F P A P E R . 37 C FR 1 .84(e)

_ Paper not flexible, strong, white ; and durable.

Fig(s)E r asu r e s , a l t e r a t io n s , o ve r wr i l in gs, in te r l in e a t io n s ,fo l d s , co py m achin e m ar k s no t acce pte d . Fig ($)

_ Mylar, velumpaper is not acceptable (too thin).

Fig(s)

4 . S I Z E OF PAP E R . 37 C FR 1 .84(0: Acce ptab l e s iz e s:

2 1 . 0 c m b y 2 9 . 7 c m (D IN s i z e A 4)

2 1 . 6 cm b y 2 7 .9 cm (8 1 / 2 x I I in che s)— All drawing sheets not the same size.

— Sheet(s)

Dr awin gs she e ts n o t an acce ptab l e s iz e . Fig(s)

5 . M A R G I N S . 37 C FR 1 . 84(8 ) : Acce ptab l e m ar g in s:

Top 2 . 5 e m L e f t 2 . 5 cm R i g h t 1 . 5 c m B o t t o m 1 .0 emS I Z E : A4 S iz e

Top 2 . 5 c m L e f t 2 .5 cm~ Right 1 . 5 c m B o t t o m 1 , 0 c mSIZE: 8 1 /2 x 1 1 ,

1Margins not acceptabl Fig ) ( f

To p (T)7^ —

ft L) "]

R ig h t (R ) B o t to m (B )6 . VIEWS . 37 C FR 1 . 84(h )

R E M I N DE R : S pe c i f ica t io n m ay r e q u i r e r e v is io n toco r r e spo n d to d r awin g chan ge s.

Par t i a l v i e ws . 37 CFR 1 . 84(h ) (2 )_Brackets needed to show figure as one entity.

Fig(s)_ Views not labeled separately or properly.

Fig(s)E n lar ge d v ie w n o t l ab e l e d se par e t e l y o r pr o pe r l y .Fig(s)

7. S E CTI ON AL VI E W S . 3 7 CF R 1 . 84 (h ) (3)Hatchin g n o t in d ica te d fo r se c t io n a l po r t io n s o f an o b je c t .Fig(s)S e c t io n a l d e s ign a t io n sho u l d b e n o te d wi th Ar ab ic o r

— Roman numbers . Fig(s)

` 8 . ' A RI2 A N GEM EN T ' OF VIEWS . 3 7 CF R 1 . 8 4 ( 1 ) `

Word's do nbttappear on . a h or i z ont a l ; l e f t ; to, right ,fashion

when page is e i ther, upright o r t u rne d so t h a t t h e t o p

be c om e § t h e r i g h t s i de , e xc e p t f o r g ra p h s . F ig ( s )9 . S C A L E. 3 7 CF R 1 .84(k)

_ Scale not large enough to show mechanism without

crowding when drawing is reduced in size to two-thirds inr e p roduc t i on.Fig(s) ' .

1 0 . CHA R ACTE R OF LI N E S , N U M BE R S , & LE TTE R S .37 SFR 1 .84(1)

~" Lines ;,. n um b e r s &l e t t e r s n o tu n i fo r m iy th ick an d we l ldefined, cl an, dut Je , an d b l ack (po o r l in e q u a l i ty ) .Fig(s)

1 1 . SH A D IN G . 37 FR 1.8 (m) t

Sol id black areas pale . Fig(s)

S o l id b l ack shad in g n o t pe r m i t t e d . F i g s )_ Shade lines ; pale , rbugh d and'blurr6d . F i g ( s )

1 2 . N U M BE R S , LE TTE R S , & R E F E R E N CE CHAR ACTE R S .37 CFR 1 .84(p)_ Numbers and reference characters not plain'and legible:

Fig(s)Fi g ure l e g e nds a re p oor . F ig ( s )

— Numbers and reference characters not oriented in th es a m e , d i re c t i on .as . t h e , view .• 37 CFR . 1 . 8 4 (p) (1)Fig(s)Engl ish alphabet not used . 37 C FR 1 .84(p)(2)

—Figs— Numbers, letters and reference characters must be at least

. 32 c m (1 /8 i nc h ) in he ight . 3 7 CF R 1 . 94(p ) (3)Fig(s)

1 3. LEAD LINES . 37 CFR 1 .84(q)

_ Lead lines cross each other. Fig(s)

— Lead lines missing . F ig ( s )14 . N U M B E R IN G O F S H E ET S O F DR A W I N G S . 3 7 C FR 1 . 8 4 ( t)

Sh e e t s no t num be re d c ons e c ut i v e l y , a nd i n A ra bi c num e ra l sb e gin n ing wi th n u m b e r 1 . S h e e t ( s )

1 5 . N U M B ERIN G O F V IEW S . 37 C FR 1 .84(u)_ Views not numbered consecutively, and in Arabic numerals,

be g i nni ng w i t h num be r 1 . Fig(s)

1 6 . C O RREC T IO N S. 37 CFR 1.84(w)— Corrections not made fromprior PTO-948

dated

1 7. D E SI G N D R A W I N G S . 3 7 CF R 1 . 1 52_ Surface shading shown aot-appropriate . Fig(s)

Solid black shading not used for color contrast.Fig(s)

COMMENTS

REVIEWER

ATTACHMENT TO PAPER NO

DATE Q TELEPHONE NO .



't .

UNITED STATES`,WPARTMENT OF COMMERCE

Patent and Tradb?nark Office

ASSISTANT SECRETARY-AND COMMISSIONEROF PATIENTS AND TRADEMARKS

Washington, D .C . 20231

CHANGE OF ADDRESS/POWER OF ATTORNEY

FILE LOCATION 9200 SERIAL NUMBER 09164215 PATENT NUMBER 6199049

Documents

00870-prosecution history