Title:
Printer with user ID sensor
Kind Code:
A1


Abstract:
A computer network for a plurality of users, the computer network comprising: a server; a printer; a network user identifier for a network user to carry on their person; and, a printer identifier associated with the printer; wherein during use, the network user identifier and the printer identifier interact such that any of the network user's pending printouts are sent to the printer for printing when the network user is proximate the printer.



Inventors:
Lapstun, Paul (Balmain, AU)
Silverbrook, Kia (Balmain, AU)
Application Number:
11/193479
Publication Date:
02/09/2006
Filing Date:
08/01/2005
Assignee:
Silverbrook Research Pty Ltd
Primary Class:
Other Classes:
358/1.14
International Classes:
G06K15/00; G06F3/12
View Patent Images:



Primary Examiner:
RODRIGUEZGONZALE, LENNIN R
Attorney, Agent or Firm:
SILVERBROOK RESEARCH PTY LTD (BALMAIN, AU)
Claims:
We claim:

1. A computer network for a plurality of users, the computer network comprising: a server; a printer; a network user identifier for a network user to carry on their person; and, a printer identifier associated with the printer; wherein during use, the network user identifier and the printer identifier interact such that any of the network user's pending printouts are sent to the printer for printing when the network user is proximate the printer.

2. A computer network according to claims 1 wherein the network has a plurality of said printers, each printer associated with one of the printer identifiers respectively; and a plurality of said network user identifiers, each uniquely identifying different network users.

3. A computer network according to claims 2 wherein each of the network user identifiers is a token and each of the printer identifiers has a token reader such that the user presents their token to the token reader associated with one of the printers to request actual printing of their queued printouts via that printer.

4. A computer network according to claims 3 wherein the tokens are a short-range RFID tag, a smartcard or a magnetic stripe card.

5. A computer network according to claims 4 wherein the token reader notifies the server of the user's proximity to the associated printer which in turn initiates printing.

6. A computer network according to claims 2 wherein each of the printer identifiers is a token and each of the network user identifiers has a token reader associated with the user.

7. A computer network according to claims 6 wherein the token reader is an electronic stylus with an optical sensor, and the tokens are a surface on each of the printers with coded data disposed on it, the coded data being readable by the optical sensors of each user's electronic stylus.

8. A computer network according to claims 1 wherein the pending printouts are maintained in a queue by the server and each pending printout has a priority such that higher-priority printouts are printed before earlier-queued but lower-priority printouts.

9. A computer network according to claims 3 wherein the token readers identify both the user and the printer to the server when the user presents their token to the reader.

10. A computer network according to claims 9 wherein the token identfies the user explicitly.

11. A computer network according to claims 9 wherein the token has a token identifier and the server performs a database lookup to translate the token identifier into a user identity.

12. A computer network according to claims 9 wherein the token reader identifies the printer explicitly.

13. A computer network according to claims 9 wherein the reader has a reader identifier and the server performs a database lookup to translate the reader identifier into a printer indentity.

14. A computer network according to claims 3 wherein the token reader and the printer are separate devices which have an electrical connection.

15. A computer network according to claims 3 wherein the token reader is physically built into the printer.

16. A computer network according to claims 3 wherein the token reader informs the printer that the user has presented a token and the printer then explicitly retrieves the user's pending printouts for printing.

17. A computer network according to claims 3 wherein the token is a security access or identification badge or card.

Description:

FIELD OF THE INVENTION

The present invention relates to printing systems, and in particular printing systems involving interactive paper, computer publishing, computer applications, human-computer interfaces, and information appliances.

CO-PENDING REFERENCES
NPS101USNPS108USNPS109US

CROSS-REFERENCES
10/81562110/81561210/81563010/81563710/81563810/81564010/815642
10/81564310/81564410/81561810/81563910/81563510/81564710/815634
10/81563210/81563110/81564810/81564110/81564510/81564610/815617
10/81562010/81561510/81561310/81563310/81561910/81561610/815614
10/81563610/81564911/04165011/04165111/04165211/04164911/041610
11/04160911/04162611/04162711/04162411/04162511/04155611/041580
11/04172311/04169811/04164810/81560910/81562710/81562610/815610
10/81561110/81562310/81562210/81562910/81562510/81562410/815628
10/91337510/91337310/91337410/91337210/91337710/91337810/913380
10/91337910/91337610/91338110/986402IRB013US11/17281511/172814
10/40987610/40984810/40984511/08476911/08474211/08480609/575197
09/57519509/57515909/57513209/575123682594509/57513009/575165
681303909/69341509/575118682404409/60897009/57513109/575116
681627409/57513909/57518666810456678499667942009/663599
09/607852672800009/69321909/57514509/60765668135586766942
09/69351509/66370109/575192672098509/609303692277909/609596
684788309/69364709/72189509/72189409/60784309/69369009/607605
09/60817809/60955309/60923309/60914909/60802209/57518109/722174
09/72189610/291522671806110/29152310/29147110/2914706825956
10/29148110/29150910/29182510/29151910/29157510/2915576862105
10/29155810/29158710/29181810/291576682938767146786644545
6609653665187910/29155510/29151010/29159210/29154210/291820
10/291516686788010/29148710/29152010/29152110/29155610/291821
10/29152510/29158610/29182210/29152410/29155368509316865570
684796110/68552310/68558310/68545510/68558410/75760010/804034
10/793933688989610/83123210/88488210/94387510/94393810/943874
10/94387210/94404410/94394210/94404310/94929310/94387710/965913
10/95417010/98177310/98162610/98161610/98162710/97473010/986337
10/99271311/00653611/02025611/02010611/02026011/02032111/020319
11/02604511/05969611/05103211/059674NPA19NUS11/10794411/107941
11/08294011/08281511/08282711/08282911/08295611/08301211/124256
11/12313611/15467611/159196NPA225US09/57519309/57515609/609232
09/607844645788309/69359310/74367111/03337909/92805509/927684
09/92810809/92768509/92780909/575183678919409/5751506789191
10/90012910/90012710/91332810/91335010/98297510/9830296644642
650261466229996669385682711610/93328510/9493076549935
NPN004US09/575187672799665918846439706676011909/575198
09/72214809/72214668265476290349642815567850166831682
674187109/72217109/72185809/722142684060610/20202110/291724
10/29151210/29155410/65902710/65902610/83124210/88488510/884883
10/90115410/93204410/96241210/96251010/96255210/96573310/965933
10/97474210/98297410/98301810/98637511/10781711/14823811/149160
09/693301687096668226396474888662787067243746788982
09/722141678829309/722147673759109/72217209/6935146792165
09/722088679559310/291823676882110/29136610/2915036797895
10/27481710/78289410/78289510/77805610/77805810/77806010/778059
10/77806310/77806210/77806110/77805710/84689510/91746810/917467
10/91746610/91746510/91735610/94816910/94825310/94815710/917436
10/94385610/91937910/94384310/94387810/94384910/96575111/071267
11/14484011/15555611/15555709/57515409/57512968301966832717
09/72186210/47374710/120441684342010/2917186,789,73110/291543
6766944676694510/29171510/29155910/29166010/409864NPT019USNP
10/537159NPT022US10/41048410/88488410/85337910/78663110/853782
10/89337210/89338110/89338210/89338310/89338410/97105110/971145
10/97114610/98640310/98640410/99045911/05968411/07480210/492169
10/49215210/49216810/49216110/49215410/50257510/68315110/531229
10/683040NPW009USNP10/51039110/91926010/51039210/91926110/778090
09/57518909/57516209/57517209/57517009/57517109/57516110/291716
10/29154710/291538678639710/29182710/29154810/29171410/291544
10/291541683905310/29157910/29182410/291713691459310/291546
10/91735510/91334010/94066811/02016011/03989711/074800NPX044US
11/07591711/10269811/102843659316610/42882310/84993111/144807
6454482680833065273656474773655099710/18149610/274119
10/30918510/30906610/94928810/96240010/969121UP21USUP23US
09/517539656685809/11276263319466246970644252509/517384
09/505951637435409/5176086816968675783263341906745331
09/51754110/20355910/20356010/20356410/63626310/63628310/866608
10/90288910/90283310/94065310/94285810/72718110/72716210/727163
10/72724510/72720410/72723310/72728010/72715710/72717810/727210
10/72725710/72723810/72725110/72715910/72718010/72717910/727192
10/72727410/72716410/72716110/72719810/72715810/75453610/754938
10/72722710/72716010/93472010/296522679521510/29653509/575109
6805419685928909/6079856398332639457366229236747760
692114410/88488110/94394110/94929411/03986611/12301111/123010
11/14476911/14823710/92284610/92284510/85452110/85452210/854488
10/85448710/85450310/85450410/85450910/85451010/85449610/854497
10/85449510/85449810/85451110/85451210/85452510/85452610/854516
10/85450810/85450710/85451510/85450610/85450510/85449310/854494
10/85448910/85449010/85449210/85449110/85452810/85452310/854527
10/85452410/85452010/85451410/85451910/85451310/85449910/854501
10/85450010/85450210/85451810/85451710/93462811/00378611/003354
11/00361611/00341811/00333411/00360011/00340411/00341911/003700
11/00360111/00361811/00361511/00333711/00369811/00342011/003682
11/00369911/07147311/00346311/00370111/00368311/00361411/003702
11/00368411/00361911/00361710/76025410/76021010/76020210/760197
10/76019810/76024910/76026310/76019610/76024710/76022310/760264
10/76024410/76024510/76022210/76024810/76023610/76019210/760203
10/76020410/76020510/76020610/76026710/76027010/76025910/760271
10/76027510/76027410/76026810/76018410/76019510/76018610/760261
10/76025811/01476411/01476311/01474811/01474711/01476111/014760
11/01475711/01471411/01471311/01476211/01472411/01472311/014756
11/01473611/01475911/01475811/01472511/01473911/01473811/014737
11/01472611/01474511/01471211/01471511/01475111/01473511/014734
11/01471911/01475011/01474911/01474611/01476911/01472911/014743
11/01473311/01475411/01475511/01476511/01476611/01474011/014720
11/01475311/01475211/01474411/01474111/01476811/01476711/014718
11/01471711/01471611/01473211/01474211/09726811/09718511/097184
10/72880410/72895210/72880610/72883410/72979010/72888410/728970
10/72878410/72878310/72892510/72884210/72880310/72878010/728779
10/77318910/77320410/77319810/773199683031810/77320110/773191
10/77318310/77319510/77319610/77318610/77320010/77318510/773192
10/77319710/77320310/77318710/77320210/77318810/77319410/773193
10/77318411/00811811/06075111/060805MTB40US11/09730811/097309
11/09733511/09729911/09731011/09721311/09721210/76027210/760273
10/76018710/76018210/76018810/76021810/76021710/76021610/760233
10/76024610/76021210/76024310/76020110/76018510/76025310/760255
10/76020910/76020810/76019410/76023810/76023410/76023510/760183
10/76018910/76026210/76023210/76023110/76020010/76019010/760191
10/76022710/76020710/76018110/40721210/40720710/68306410/683041
6750901647686367883366623101640612965059166457809
6550895645781210/29643464281336746105

The disclosures of these co-pending applications are incorporated herein by cross-reference. Some applications are temporarily identified by their docket number. This will be replaced by the corresponding USSN when available.

BACKGROUND OF THE INVENTION

In office environments, documents to be printed are typically sent via local computer networks to one of a number of printers connected to the network. The nominated printer is usually the most convenient to the user but unless the user goes to collect the document immediately after sending the print job, the printed document waits in the collection tray. If the document is sensitive, there is a risk that its contents will be disclosed to others passing the printer.

SUMMARY OF THE INVENTION

According to a first aspect, the present invention provides a computer network for a plurality of users, the computer network comprising:

    • a server;
    • a printer;
    • a network user identifier for a network user to carry on their person; and, a printer identifier associated with the printer; wherein during use,
    • the network user identifier and the printer identifier interact such that any of the network user's pending printouts are sent to the printer for printing when the network user is proximate the printer.

By keeping print jobs on the network until the user is at a printer, the printed document does not sit in a collection tray until the user retrieves it. This reduces the risk of others seeing any sensitive documents. If all printers connected to the network have sensors for identifying individual users, then users will not need to select a printer (or designate a default printer). Print jobs can be collected from the most convenient printer regardless of a users current location in the office.

The Netpage system is comprehensively described in the cross referenced documents as well as the Detailed Description below. This system uses a paper- and pen-based interface to computer-based and typically network-based information and applications. The user can request print jobs by ‘clicking’ an interactive element on a Netpage document with a Netpage pen and therefore may be remote from any of the networked printers or even the office when print jobs are requested. According the invention is particularly suited to the Netpage system and will be described with particular reference to its operation within this environment. However, it will be appreciated that the invention has much broader application than Netpage and is not limited or restricted to printing Netpage documents.

Optionally, the network comprises a plurality of said printers, each printer associated with one of the printer identifiers respectively; and

    • a plurality of said network user identifiers, each uniquely identifying different network users.

Optionally, each of the network user identifiers is a token and each of the printer identifiers has a token reader such that the user presents their token to the token reader associated with one of the printers to request actual printing of their queued printouts via that printer.

Optionally, the tokens are a short-range RFID tag, a smartcard or a magnetic stripe card.

Optionally, the token reader notifies a walk-up-handling application on the server of the user's proximity to the associated printer which in turn initiates printing.

Optionally, each of the printer identifiers is a token and each of the network user identifiers has a token reader associated with the user. Optionally, the token reader is an electronic stylus with an optical sensor, and the tokens are a surface each of the printers with coded data disposed on it, the coded data being readable by the optical sensors of each users' electronic stylus.

Optionally, the pending printouts are maintained in a queue by the server and each pending printout has a priority such that higher-priority printouts are printed before earlier-queued but lower-priority printouts.

Optionally, the token readers are associated with respective printers such that when the user presents their token to the reader it reads the token and identifies both the user and the printer to the server. Optionally, the token identfies the user explicitly. Optionally, the token has a token identifier and the server performs a database lookup to translate the token identifier into a user identity. Optionally, the token reader identifies the printer explicitly.

Optionally, the reader has a reader identifier and the server performs a database lookup to translate the reader identifier into a printer indentity.

Optionally, the token reader and the printer are separate devices which have an electrical connection. Optionally, the token reader is physically built into the printer. Optionally, the reader informs the printer that the user has presented a token and the printer then explicitly retrieves the user's pending printouts for printing.

Optionally, the token is a security access or identification badge or card.

BRIEF DESCRPTION OF THE DRAWINGS

Embodiments of the invention will now be described by way of example only with reference to the accompanying drawings in which:

FIG. 1 shows the data flow between Netpage publishers and applications, Netpage services, and Netpage devices;

FIG. 2 is a diagram of the range of content type within a Netpage document;

FIG. 3 shows a Netpage document with a physical structure consisting of a sequence of numbered pages;

FIG. 4 shows a printout consisting of a series of impressions;

FIG. 5 is a diagram showing a user with a pen and default printer;

FIG. 6 shows the pen events recorded in a digital ink stream;

FIG. 7 shows the form data submitted to an application;

FIG. 8 shows a dynamic element for use as a document element;

FIG. 9 shows a dynamic object linked to an existing impression;

FIG. 10 shows the relationship between the document, printout and digital ink stores;

FIG. 11 shows the fundamental flow of data in the Netpage system in greater detail than FIG. 1;

FIG. 12 shows the data flow associated with reprinting impressions;

FIG. 13 shows the data flow associated with printing;

FIG. 14 shows a bifurcated general printing data flow;

FIG. 15 shows the data flow associated with walk-up printing;

FIG. 16 shows the data flow associated with the establishment of a printout queue;

FIG. 17 shows the different levels of network distribution and access possible within the Netpage system;

FIG. 18 shows the data flow if the user has a token read by a reader associated with the printer;

FIG. 19 shows the data flow if the user has a reader for reading the token associated with the printer;

FIG. 20 shows the data flow if the user has a reader that reads the printer token but then uses the printer reader to connect to the Netpage server;

FIG. 21 shows the data flow between a privately hosted network and a publicly hosted network;

FIG. 22 shows a PC or device hosted Netpage system;

FIG. 23 shows the structure of a complete tag;

FIG. 24 shows a symbol unit cell;

FIG. 25 shows nine symbol unit cells;

FIG. 26 shows the bit ordering in a symbol;

FIG. 27 shows a tag with all bits set;

FIG. 28 shows a tag group made up of four tag types;

FIG. 29 shows the continuous tiling of tag groups;

FIG. 30 shows the interleaving of codewords A, B, C & D with a tag;

FIG. 31 shows a codeword layout; and

FIG. 32 shows a tag and its eight immediate neighbours labelled with its corresponding bit index.

DETAILED DESCRIPTION

As discussed above, the invention is well suited for incorporation in the Assignee's Netpage system. In light of this, the invention has been described as a component of a broader Netpage architecture. However, it will be readily appreciated that the invention is also applicable to other computer networks.

Netpage Architecture

Overview

FIG. 1 shows the interaction between Netpage publishers, applications, services and devices. The Netpage document service 1 accepts a document 2 from a Netpage publisher 3 or other Netpage application 4, and produces a printout 5 via a Netpage printer 6. A printout 5 consists of a series of impressions on either or both sides of a series of paper sheets. In addition to reproducing the graphic content of the document 2 on paper, the printer 6 also lays down a coordinate grid in the form of an array of invisible millimetre-scale tags 7 (see U.S. Ser. No. 10/309,358 cross referenced above). Each tag encodes the two-dimensional coordinates of its location on the impression as well as the impression's unique identifier. When a tag is optically imaged by a Netpage pen 8 (see below and U.S. Ser. No. 10/815,636 cross referenced above) the pen is able to identify the corresponding impression as well as its own position relative to the impression. When the user of the pen 8 moves the pen relative to the coordinate grid 7, the pen generates a stream of positions. This stream is referred to as digital ink 9. A digital ink stream also records when the pen makes contact with a surface and when it loses contact with a surface, and each pair of these so-called pen down and pen up events delineates a stroke drawn by the user using the pen.

The Netpage tag pattern 7 is typically printed using an invisible infrared ink while visible graphic content is printed using colored inks which are transparent in the infrared part of the spectrum. The Netpage pen 8 incorporates a conventional marking nib which utilises an infrared-transparent ink so as not to obscure the tag pattern 7.

Because the impression identifiers (tags) manifest themselves in printed impressions, they are engineered to be unique among all Netpage systems, and therefore rely on a global allocation mechanism.

The document 2 may include an input description 11 which defines command and form data 12. The commands are instructions that may be activated by the user and the forms have designated fields that may be filled in by the user. Both commands and form fields have active zones, i.e. areas of the page where they capture user input.

The Netpage digital ink service 13 accepts digital ink 9 from a Netpage pen 8. Since the pen typically only has a short-range communications capability, it forwards the digital ink 9 to the Netpage digital ink service 13 via a Netpage relay 14 which has a longer-range communications capability. Typical relays include mobile phones, PDAs and personal computers.

The digital ink service 13 uses the impression identifier 7 in the digital ink 9 to retrieve the corresponding impression and input description 11 from the document service 1, and attempts to assign each individual digital ink stroke to a form of the input description 11. Once it detects that the user of the pen 8 has designated a form submission command, it interprets the digital ink 9 assigned to the form and submits the resultant form data 12 to the application associated with the command.

In order to allow the digital ink service to interpret pen input in relation to a particular impression, the document service 1 keeps a copy of every input description 11 it prints.

In order to allow a user to fill in a form over an arbitrarily long time, the digital ink service 13 retains a copy of all digital ink 9 it receives, at least until the digital ink is interpreted and submitted to an application 4. The digital ink service 13 optionally retains all digital ink 9 indefinitely, to allow digital ink searching of both form content and document annotations.

The Netpage pen 8, or a simpler Netpage pointer, may be incorporated directly into a hand-held device such as a mobile phone or PDA. Conversely, the pen may incorporate a long-range communications capability and not need a separate relay.

Since the relay device 14 typically incorporates an interactive display 15, the digital ink service 13 may identify the interactive display 15 to a target application 4 to allow the application to communicate directly with the interactive display, thus allowing an interaction initiated via paper and pen to lead to a richer screen-based interaction, and generally allowing the development of hybrid paper- and screen-based applications which make the most of both media.

In the presence of multiple distributed digital ink services 13 a pen 8 (or its relay 14) may use a name service to resolve the network address of a target digital ink service, based on pen identifier and possibly impression identifier. In the presence of multiple distributed document services 1, a digital ink service 13 uses a name service to resolve the network address of a document service, based on impression identifier.

Although the above description centres on a forms-based interpretation of digital ink and subsequent delivery of form data to an application, the digital ink service also supports streaming delivery of digital ink to an application. This allows an application to be more directly responsive to pen input. In streaming mode the digital ink service delivers both stroke digital ink and intervening “hover” digital ink to allow the application to provide real-time positional feedback to the user via a display.

Object Model

The object model is a logical model relating to the external interfaces of the Netpage services. It is not intended as an implementation model.

Document

FIG. 2 is a class diagram showing a document 2 comprising a visual description 16 and an input description 11. For a given document, either description may be empty. Each document 2 is uniquely identified 18.

The visual description 16 is a collection of visual elements 20 representing static 22 and dynamic elements 24. Static elements represent textflows 26, images 28, graphics 30 etc. Dynamic elements 24 are described below. The input description 11 is a collection of forms 32, each of which consists of a collection of input elements 34 representing commands 36 and fields 38. Forms 32 may overlap both physically and logically, and the same input element 34 may participate in multiple forms. Each input element 34 has a zone 40 which defines the area within which it captures input. Each form 32 is associated with a target application 42. The application 42 receives submissions of the form 32. The application 42 is identified by an address 44.

As illustrated in the class diagram in FIG. 3, a document 2 has a physical structure which consists of a sequence of numbered pages, each page 46 assigned a page number 54. The document elements 48 are each assigned a specific position 52 in the sequence of pages. Since a single document element 48 may span a number of pages 46, it may have a corresponding number of page elements 50, each defining the position 52 of a fragment of the document element 48.

Printout.

Referring to the class diagram in FIG. 4, a printout 5 consists of a series of impressions 58 assigned a printout ID 56. With “N-up” printing, multiple pages 46 may appear on a single impression 58, while with “poster” printing a single page 46 may span multiple impressions 58. A page impression 64 uses a transform 66 to represent the position, scale and rotation of a page 46 on an impression 58.

Each impression 58 is identified by a unique identifier 60 which is encoded with the impression's coordinate grid when the impression is printed.

Once actually printed (or pending printing in the ‘walk-up scenario’ described below), the impression 58 is associated with both the printer 6 on which it was printed and the user 62 who requested it, if known.

As shown in FIG. 5, a pen 8 is owned by a single user 62 but a user may own any number of pens 8. Accordingly, the user 62 is assigned a user ID and other user details 68, and likewise, each pen 8 and printer 6 has a pen ID and details 70, and printer ID and details 72. A user 62 optionally has a default printer 6.

The class diagram in FIG. 6 illustrates a single digital ink stream 74 associated with a pen 8, consisting of a sequence of pen events 76. Each pen event is timestamped 78 using a nib force sensor. Successive segments 80 within the stream 74 relate to different impressions 58. Each segment is assigned a number 82. Each sequence of pen events 76 is a series of pen position events 88 between a pen down event 84 and a pen up event 86. This defines a stroke drawn by the user of the pen. Often a succession of strokes relates to the same impression 58, and usually a segment boundary corresponds to a stroke boundary. However, a stroke may also traverse multiple impressions 58, and a stream 74 may contain “hover” pen events between strokes.

The class diagram in FIG. 7 shows form data 12 submitted to an application consists of a collection of field values 90. The form data 12 is associated with a unique form instance 92 appearing in a printout 5. An application may specify a transaction identifier when the form instance 92 is first created (as part of a printout). The transaction identifier 94 is submitted together with the form data 12, allowing the target application to use it to index a unique transaction context.

The digital ink service 13 (see FIG. 1) supports a form lifecycle wherein a form may only be submitted once, may expire, may become frozen after being signed, and may be voided. The form instance reflects the status of the form with respect to the form lifecycle.

As illustrated in the class diagram in FIG. 8, a document 2 may also include dynamic elements 24. Each dynamic element has an associated dynamic object 96, which in turn has associated object data 98 and a (typically type-specific) object application 99. A dynamic element 24 may be activated in place using a device such as a Netpage viewer (see U.S. Ser. No. 09/722,175 cross referenced above), or may be activated on an arbitrary interactive display, such as the interactive display 15 associated with the relay 14 (see FIG. 1), or may be activated via the Netpage Explorer (described below).

Examples of dynamic objects and their related applications include an audio clip and an audio player, a video clip and a video player, a photo and a photo viewer, a URL and a Web browser, an editable document and a word processor, to name just a few.

As illustrated in the class diagram in FIG. 9, a dynamic object 96 may also be dynamically linked to an arbitrary location on an existing impression, e.g. by being “pasted” onto a virtual view of the impression or onto the impression itself.

FIG. 10 shows the relationships between the three stores nominally maintained by the Netpage document service 1 and the Netpage digital ink service 13 (see FIG. 1), with navigational qualifiers.

Apart from the document store 100, the printout store 102 and the digital ink store 104, the Netpage services may have additional stores for registered users 62, pens 8 and printers 6, identifier allocation, and service address resolution (not shown).

Functions

The processes and stores described in the following sub-sections are meant to elucidate functionality rather than imply implementation.

Form Input

FIG. 11 shows the fundamental flow of data in the Netpage System in more detail than FIG. 1. The document service 1 allows an application 4 to lodge a document 2 and to separately transmit a print request 106 to print the document 2. It retains a copy of each lodged document in the document store 100, and retains a copy of the document's input description, if any, in the document store 100. When it prints a document 2 to a specified printer 6, it records the printout 5 in the printout store 102.

The digital ink service 13 accepts digital ink 9 from a pen 8 via a relay 14, and retains a copy of received digital ink in the digital ink store 104. It uses the impression identifier 60 in the digital ink 9 to retrieve the corresponding impression 58 and input description from the document service 1. It then assigns each individual digital ink stroke to an element of the input description such as a command or a form field, according to the position and extent of the stroke and the active zone of the input element. Once it detects that the user of the pen 8 has designated a form submission command, the digital ink 9 assigned to each field is interpreted 108 according to field type, and the resultant form data 12 is submitted to the application 4 associated with the command. For example, the digital ink service 13 interprets a mark in a checkbox as a check mark; it converts handwritten text in a text field into a string of text characters using intelligent character recognition; and it compares a handwritten signature in a signature field with the recorded signature of the user of the pen, and, if the signatures match, digitally signs the form data on behalf of the user.

Reprinting Impressions

The Netpage system supports reprinting of previously printed impressions, with or without any drawings or handwriting captured via those impressions. It thus supports source-independent document reproduction. FIG. 12 illustrates the flow of data in response to a reprint request 110 from an application 4. When the document service 1 reprints a set of impressions 58 it optionally includes any drawings and handwriting captured via those impressions, and retrieves the corresponding digital ink from the digital ink store 104 in the digital ink service 13 (subject to visibility and access). It records a new printout to record the impression identifiers assigned to the reprinted impressions 112.

General Printing

Netpage system acts as a virtual filing cabinet for any printed document, whether produced by a Netpage-aware application or not. A Netpage-aware application has the advantage that it can include input descriptions in its documents, while a non-Netpage-aware application benefits from its printed documents supporting searchable annotations and source-independent reprinting.

FIG. 13 illustrates the flow of data in response to a general printing request from a non-Netpage-aware application 114. A Netpage-aware printer driver 116 converts platform-specific drawing commands 118 into a Netpage-compatible document 2 which it lodges with the document service 1, and then sends a print request 106 for the document service 1 to print the document 2 via a specified printer 6.

FIG. 14 illustrates the corresponding flow of data when the printer is not accessible by the document service 1. Here the printer driver 116 still lodges the document 2 with the document service 1 and records the printout 5 in the printout store 102, but actually prints the documents 2 directly via the specified printer 6.

Walk Up Printing

When a user requests printing of a document via a conventional user interface, it is usually convenient to specify a target printer. In the Netpage system, however, printing often occurs in response to user input via a printed form, and it may be inconvenient to specify a target printer. In some environments, such as in a home containing a single printer, the desired target printer may be inferred. In other environments, such as in an office containing multiple networked printers, the desired target printer may not be so easily inferred. In such environments it is useful to allow a user to specify a target printer by walking up to it.

FIG. 15 shows the flow of data in a walk-up environment. All print (and re-print) requests 120 from the Netpage application 4 are typically deferred. In response to a deferred print request 120, the document service 1 records a printout 5 in the printout store 102 to capture impression-related information, and places the printout in a printout pending queue 122 for the requesting user.

In one possible configuration, each printer 6 has an associated token reader 124, and the user presents a token 126 to the token reader to request actual printing of queued printouts via the printer 6. The token 126 may be a short-range RFID tag, a smartcard, a magnetic stripe card, etc. The token reader 124 notifies a walk-up-handling application 128 of the user's proximity to the printer which in turn initiates printing via the document service 1.

In another possible configuration, the token reader 124 is associated with the user and the token 126 is associated with the printer 6. For example, the token reader 124 may be the user's Netpage pen 8, and the token 124 may be a tag pattern disposed on the printer.

FIG. 16 shows the class diagram of the pending printout queue 122 maintained by the document service 1. Each pending printout 128 has a priority 130, allowing higher-priority printouts to be printed before earlier-queued but lower-priority printouts.

The document service can be used to provide walk-up printing for documents which are not encoded with Netpage tags and retained.

In general, the token 126 may be any of a number of passive, semi-passive or active devices, including a surface or object bearing a Netpage tag pattern, linear barcode or two-dimensional barcode; a magnetic stripe card; a smart card or contact-less smart card; or a radio-frequency identification (RFID) tag. The reader 124 may be any reader matched to the type of the token 126, such as an optical reader utilising a scanning laser or a two-dimensional image sensor, as in conventional barcode readers or a Netpage sensing device; a magnetic stripe reader; a smart card reader; or an RFID reader.

As illustrated in FIG. 18, in a first configuration the token reader 124 is associated with the printer 6 and the user presents the token 126 to the reader. The reader 124 reads the token 126 and communicates the walk-up event to the Netpage server 1. The walk-up event identifies both the user 62 and the printer 6. The token 126 and hence the walk-up event may identify the user 62 explicitly, or the server may be required to perform a database lookup to translate the token identifier into a user identifier. The reader and hence the walk-up event may identify the printer 6 explicitly, or the server 1 may be required to perform a database lookup to translate the reader identifier into a printer identifier. Once the server 1 has identified the user 62 and the printer 6, it retrieves printouts pending for the user and sends them to the printer to be printed.

FIG. 18 shows the reader 124 and the printer 6 as separate devices which are physically associated. The reader 124 may be physically built into the printer 6. It may also be electrically connected to the printer, with the printer delivering the walk-up event to the server. Alternatively and equivalently, the printer 6 may interpret the walk-up event itself, and explicitly retrieve the user's pending printouts for printing.

The user token 126 may be attached to or built into a portable device which the user 62 carries, such as a mobile phone, pen, electronic pen (such as a Netpage pen 8), wallet, security access card or token, or identification badge or card. It may also be stand-alone and purpose-specific.

In the case of a Netpage pen 8, the printer reader 124 may provide a receptacle for receiving the pen, whereby the pen makes electrical contact and establishes a wired communication link (e.g. USB) with the reader to communicate the user identifier to the reader.

As illustrated in FIG. 19, in a second configuration the token reader 124 is associated with the user 62 and the user presents the reader to the token 126. The reader 124 reads the token 126 and communicates the walk-up event to the Netpage server 1. The walk-up event identifies both the user 62 and the printer 6. The token 126 and hence the walk-up event may identify the printer 6 explicitly, or the server 1 may be required to perform a database lookup to translate the token identifier into a printer identifier. The reader 124 and hence the walk-up event may identify the user 62 explicitly, or the server 1 may be required to perform a database lookup to translate the reader identifier into a user identifier. Once the server 1 has identified the user 62 and the printer 6, it retrieves printouts pending for the user and sends them to the printer to be printed.

The printer token 126 may be attached to or built into the printer 6 or a device co-located with the printer.

As illustrated in FIG. 20, even when the user 62 presents a token reader 125, it may be more convenient for the user reader 125 to rely on the communication link between the token reader 124 on the printer (or printer itself) and the server 1, since this communication link is guaranteed to be present. As in FIG. 19, the user 62 presents the reader 125 to the token 127. The reader 125 reads the token 127. From the token it determines a short-range communication link to the printer 6. This may be a personal-area network (PAN) wireless link such as Bluetooth, wireless USB or ZigBee, or a local-area network (LAN) wireless link such as IEEE 802.11 (WiFi). It may also be a short-range optical link such as IrDA. Where the link requires a target address (such as in the case of Bluetooth), the token supplies the target address. For example, if the token 127 on the printer 6 uses a Netpage tag pattern, then the tag pattern encodes the target address instead of an impression ID, x-y location, etc., and flags it as such. Where the link does not require a target address (such as in the case of IrDA), the token 127 merely signals the user's token reader 126 to communicate a user identifier to the printer's token reader 126. Again, if the printer token uses a Netpage tag pattern, then the tag pattern flags the command to communicate the user identifier to the printer reader 124. If a range of communication link types are supported, then the token 127 (e.g. tag pattern) can identify a particular link type. The printer reader 124 receives the user identifier from the user reader 125 and communicates the walk-up event to the Netpage server 1. Once the server has identified the user 62 and the printer 6, it retrieves printouts pending for the user and sends them to the printer to be printed.

In the absence of a user token 126 or user reader 125, the user 62 may key a user identifier or job identifier into a keypad associated with the printer 6, with an optional password. The user 62 may also use a display-based input device associated with the printer to select their identity or their pending printout(s) from a list of users or jobs.

Netpage Explorer

As discussed above, the Netpage system acts as a virtual filing cabinet for any printed document. The Netpage system therefore provides users with a screen-based browser—the Netpage Explorer—for browsing and searching collections of printouts maintained by a document service, and for viewing individual printouts on-screen, including their digital ink. The Netpage Explorer also supports real-time display of streaming digital ink, and so provides a basis for remote conferencing.

As described above, the Netpage System supports the embedding of dynamic objects in documents, and the dynamic linking of dynamic objects to locations on printed impressions. The Netpage Explorer supports viewing of, and interaction with, such objects via the virtual view it provides of printed impressions, as well as the dynamic linking of such objects.

Product Variants

This section describes three Netpage product variants, each reflecting a different level of network distribution and access. FIG. 17 shows a system using public Netpage services 134 running on a distributed set of servers on the public Internet 133, and serving applications 4 and users on the public Internet 133. FIG. 21 shows a private Netpage system with services 136 (e.g. private Netpage document and digital ink services) running on one or more servers on a private intranet 138, and serving applications 4 and users on the private intranet. FIG. 22 shows a personal Netpage system with services 142 running on a single personal computer or other personal device 140.

In each case, pre-printed Netpage content such as magazine adverts, catalogues, brochures, and product item Hyperlabels is typically hosted by public Netpage document services running on the Internet.

In private Netpage systems, security and privacy considerations may motivate the use of a private digital ink service even where the document service is public, as implied in FIGS. 21 and 22. A private document service may also act as a caching proxy for a public document service.

More generally, security and privacy considerations may motivate routing a user's digital ink to a constrained set of digital ink services, independent of the proliferation of document services. Some national governments may mandate that their citizens' digital ink be routed to national digital ink servers, even when interacting with international document services. A Netpage pen (or its relay) may therefore have knowledge of both a private and a public digital ink service, and may route digital ink pertaining to private impressions to the former and digital ink pertaining to public impressions to the latter. Even when a given pen's digital ink relates to a public impression and is nominally accessible on a public server, this need not imply that the owner of the impression or other users of the impression automatically gain access to that digital ink.

Netpage Surface Coding Security

Introduction

The Netpage system uses a surface coding to imbue otherwise passive surfaces with interactivity in conjunction with Netpage sensing devices such as the Netpage pen and the Netpage viewer. When interacting with a Netpage coded surface, a Netpage sensing device generates a digital ink stream which indicates both the identity of the surface region relative to which the sensing device is moving, and the absolute path of the sensing device within the region. This section defines optional authentication features of the Netpage surface coding, and associated authentication protocols.

Surface Coding Security

Surface Coding Background

The Netpage surface coding consists of a dense planar tiling of tags. Each tag encodes its own location in the plane. Each tag also encodes, in conjunction with adjacent tags, an identifier of the region containing the tag. This region ID is unique among all regions. In the Netpage system the region typically corresponds to the entire extent of the tagged surface, such as one side of a sheet of paper. In the Hyperlabel system the region typically corresponds to the surface of an entire product item, and the region ID corresponds to the unique item ID. For clarity in the following discussion, references to items and item IDs (or simply IDs), correspond to the region ID.

The surface coding is designed so that an acquisition field of view large enough to guarantee acquisition of an entire tag is large enough to guarantee acquisition of the ID of the region containing the tag. Acquisition of the tag itself guarantees acquisition of the tag's two-dimensional position within the region, as well as other tag-specific data. The surface coding therefore allows a sensing device to acquire a region ID and a tag position during a purely local interaction with a coded surface, e.g. during a “click” or tap on a coded surface with a pen.

Cryptography Background

Cryptography is used to protect sensitive information, both in storage and in transit, and to authenticate parties to a transaction. There are two classes of cryptography in widespread use: secret-key cryptography and public-key cryptography. The Netpage and Hyperlabel systems use both classes of cryptography.

Secret-key cryptography, also referred to as symmetric cryptography, uses the same key to encrypt and decrypt a message. Two parties wishing to exchange messages must first arrange to securely exchange the secret key.

Public-key cryptography, also referred to as asymmetric cryptography, uses two encryption keys. The two keys are mathematically related in such a way that any message encrypted using one key can only be decrypted using the other key. One of these keys is then published, while the other is kept private. They are referred to as the public and private key respectively. The public key is used to encrypt any message intended for the holder of the private key. Once encrypted using the public key, a message can only be decrypted using the private key. Thus two parties can securely exchange messages without first having to exchange a secret key. To ensure that the private key is secure, it is normal for the holder of the private key to generate the public-private key pair.

Public-key cryptography can be used to create a digital signature. If the holder of the private key creates a known hash of a message and then encrypts the hash using the private key, then anyone can verify that the encrypted hash constitutes the “signature” of the holder of the private key with respect to that particular message, simply by decrypting the encrypted hash using the public key and verifying the hash against the message. If the signature is appended to the message, then the recipient of the message can verify both that the message is genuine and that it has not been altered in transit.

Secret-key can also be used to create a digital signature, but has the disadvantage that signature verification can also be performed by a party privy to the secret key.

To make public-key cryptography work, there has to be a way to distribute public keys which prevents impersonation. This is normally done using certificates and certificate authorities. A certificate authority is a trusted third party which authenticates the association between a public key and a person's or other entity's identity.

The certificate authority verifies the identity by examining identity documents etc., and then creates and signs a digital certificate containing the identity details and public key. Anyone who trusts the certificate authority can use the public key in the certificate with a high degree of certainty that it is genuine. They just have to verify that the certificate has indeed been signed by the certificate authority, whose public key is well-known.

To achieve comparable security to secret-key cryptography, public-key cryptography utilises key lengths an order of magnitude larger, i.e. a few thousand bits compared with a few hundred bits.

For a detailed discussion of cryptographic techniques, see Schneier, B., Applied Cryptography, Second Edition, John Wiley & Sons 1996.

Security Requirements

We define item security to have two related purposes:

    • to allow authentication of an item
    • to prevent forgery of an item

The greater the difficulty of forgery, the greater the trustworthiness of authentication.

When an item is coded, Netpage surface coding security has two corresponding purposes:

    • to allow authentication of a coded item
    • to prevent forgery of a coded item with a novel item ID

If a user is able to determine the authenticity of the surface coding of an item, then the user may be able to make an informed decision about the likely authenticity of the item.

If it is intractable to forge the surface coding for a novel ID, then the only tractable way of forging an item with an authentic surface coding is to duplicate the surface coding of an existing item (and hence its ID). If the user is able to determine by other means that the ID of an item is likely to be unique, then the user may assume that the item is authentic.

Since the Netpage surface coding allows meaningful interaction between a sensing device and a coded surface during a purely local interaction, it is desirable for the surface coding to support authentication during a similarly local interaction, i.e. without requiring an increase in the size of the sensing device field of view.

Since no a priori relationship exists between creators of authentic coded items and users potentially wishing to authenticate such items, it is undesirable to require a trust relationship between creators and users. For example, it is undesirable to require that creators share secret signature keys with users.

It is reasonable for many users to rely on online access to an authenticator trusted by a creator for the purposes of authenticating items. Conversely, it is desirable to allow authentication to take place in the absence of online access.

Security Discussion

As discussed above in ‘Cryptography Background’, authentication relies on verifying the correspondence between data and a signature of that data. The greater the difficulty in forging a signature, the greater the trustworthiness of signature-based authentication.

The item ID is unique and therefore provides a basis for a signature. If online authentication access is assumed, then the signature may simply be a random number associated with the item ID in an authentication database accessible to the trusted online authenticator. The random number may be generated by any suitable method, such as via a deterministic (pseudo-random) algorithm, or via a stochastic physical process. A keyed hash or encrypted hash may be preferable to a random number since it requires no additional space in the authentication database.

In the limit case no signature is actually required, since the mere presence of the item ID in the database indicates authenticity. However, the use of a signature limits a forger to forging items he has actually sighted.

To prevent forgery of a signature for an unsighted ID, the signature must be large enough to make exhaustive search via repeated accesses to the online authenticator intractable. If generated using a key rather than randomly, then the length of the signature must also be large enough to prevent the forger from deducing the key from known ID-signature pairs. Signatures of a few hundred bits are considered secure, whether generated using private or secret keys.

Limited space within the surface coding tag structure makes it impractical to include a secure signature in a tag. We are therefore motivated to distribute fragments of a signature across multiple tags. If each fragment can be verified in isolation against the ID, then the goal of supporting authentication without increasing the sensing device field of view is achieved. The security of the signature still derives from the full length of the signature rather than from the length of a fragment, since a forger cannot predict which fragment a user will randomly choose to verify. Note that a trusted authenticator can always perform fragment verification, so fragment verification is always possible when online access to a trusted authenticator is available.

Fragment verification requires fragment identification. Fragments may be explicitly numbered, or may more economically be identified by the two-dimensional coordinate of their tag, modulo the repetition of the signature across a continuous tiling of tags.

The limited length of the ID itself introduces a further vulnerability. Ideally it should be at least a few hundred bits. In the Netpage and Hyperlabel surface coding schemes it is 96 bits or less. To overcome this, the ID may be padded. For this to be effective the padding must be variable, i.e. it must vary from one ID to the next. Ideally the padding is simply a random number, and must then be stored in the authentication database indexed by ID. If the padding is deterministically generated from the ID then it is worthless.

Offline authentication of secret-key signatures requires the use of a trusted offline authentication device. The QA chip (see U.S. Pat. No. 6,374,354, issued 16 Apr. 2002) provides the basis for such a device, although of limited capacity. The QA chip can be programmed to verify a signature using a secret key securely held in its internal memory. In this scenario, however, it is impractical to support per-ID padding, and it is impractical even to support more than a very few secret keys. Furthermore, a QA chip programmed in this manner is susceptible to a chosen-message attack. These constraints limit the applicability of a QA-chip-based trusted offline authentication device to niche applications.

In general, despite the claimed security of any particular trusted offline authentication device, creators of secure items are likely to be reluctant to entrust their secret signature keys to such devices, and this is again likely to limit the applicability of such devices to niche applications.

By contrast, offline authentication of public-key signatures (i.e. generated using the corresponding private keys) is highly practical. An offline authentication device utilising public keys can trivially hold any number of public keys, and may be designed to retrieve additional public keys on demand, via a transient online connection, when it encounters an ID for which it knows it has no corresponding public signature key. Untrusted offline authentication is likely to be attractive to most creators of secure items, since they are able to retain exclusive control of their private signature keys.

A disadvantage of offline authentication of a public-key signature is that the entire signature must be acquired from the coding, violating our desire to support authentication with a minimal field of view. A corresponding advantage of offline authentication of a public-key signature is that access to the ID padding is no longer required, since decryption of the signature using the public signature key generates both the ID and its padding, and the padding can then be ignored.

Acquisition of an entire distributed signature is not particularly onerous. Any random or linear swipe of a hand-held sensing device across a coded surface allows it to quickly acquire all of the fragments of the signature. The sensing device can easily be programmed to signal the user when it has acquired a full set of fragments and has completed authentication. A scanning laser can also easily acquire all of the fragments of the signature. Both kinds of devices may be programmed to only perform authentication when the tags indicate the presence of a signature.

Note that a public-key signature may be authenticated online via any of its fragments in the same way as any signature, whether generated randomly or using a secret key. The trusted online authenticator may generate the signature on demand using the private key and ID padding, or may store the signature explicitly in the authentication database. The latter approach obviates the need to store the ID padding.

Note also that signature-based authentication may be used in place of fragment-based authentication even when online access to a trusted authenticator is available.

Security Specification

Setup per ID range:

    • generate public-private signature key pair
    • store key pair indexed by ID range
      Setup per ID:
    • generate ID padding
    • retrieve private signature key by ID
    • generate signature by encrypting ID and padding using private key
    • store signature in database indexed by ID
    • encode signature across multiple tags in repeated fashion
      Online (fragment-based) authentication (user):
    • acquire ID from tags
    • acquire position and signature fragment from tag
    • generate fragment number from position
    • look up trusted authenticator by ID
    • transmit ID, fragment and fragment number to trusted authenticator
      Online (fragment-based) authentication (trusted authenticator):
    • receive ID, fragment and fragment number from user
    • retrieve signature from database by ID
    • compare supplied fragment with signature
    • report authentication result to user
      Offline (signature-based) authentication (user):
    • acquire ID from tags
    • acquire positions and signature fragments from tags
    • generate signature from fragments
    • retrieve public signature key by ID
    • decrypt signature using public key
    • compare acquired ID with decrypted ID
    • report authentication result to user

Netpage Surface Coding

Introduction

This section defines a surface coding used by the Netpage system (described above in ‘Netpage Architecture’) to imbue otherwise passive surfaces with interactivity in conjunction with Netpage sensing devices such as the Netpage pen and the Netpage viewer.

When interacting with a Netpage coded surface, a Netpage sensing device generates a digital ink stream which indicates both the identity of the surface region relative to which the sensing device is moving, and the absolute path of the sensing device within the region.

Surface Coding

The Netpage surface coding consists of a dense planar tiling of tags. Each tag encodes its own location in the plane. Each tag also encodes, in conjunction with adjacent tags, an identifier of the region containing the tag. In the Netpage system, the region typically corresponds to the entire extent of the tagged surface, such as one side of a sheet of paper.

Each tag is represented by a pattern which contains two kinds of elements. The first kind of element is a target.

Targets allow a tag to be located in an image of a coded surface, and allow the perspective distortion of the tag to be inferred. The second kind of element is a macrodot. Each macrodot encodes the value of a bit by its presence or absence.

The pattern is represented on the coded surface in such a way as to allow it to be acquired by an optical imaging system, and in particular by an optical system with a narrowband response in the near-infrared. The pattern is typically printed onto the surface using a narrowband near-infrared ink.

Tag Structure

FIG. 23 shows the structure of a complete tag 200. Each of the four black circles 202 is a target. The tag 200, and the overall pattern, has four-fold rotational symmetry at the physical level.

Each square region represents a symbol 204, and each symbol represents four bits of information. Each symbol 204 shown in the tag structure has a unique label 216. Each label 216 has an alphabetic prefix and a numeric suffix.

FIG. 24 shows the structure of a symbol 204. It contains four macrodots 206, each of which represents the value of one bit by its presence (one) or absence (zero).

The macrodot 206 spacing is specified by the parameter S throughout this specification. It has a nominal value of 143 μm, based on 9 dots printed at a pitch of 1600 dots per inch. However, it is allowed to vary within defined bounds according to the capabilities of the device used to produce the pattern.

FIG. 25 shows an array 208 of nine adjacent symbols 204. The macrodot 206 spacing is uniform both within and between symbols 208.

FIG. 26 shows the ordering of the bits within a symbol 204.

Bit zero 210 is the least significant within a symbol 204; bit three 212 is the most significant. Note that this ordering is relative to the orientation of the symbol 204. The orientation of a particular symbol 204 within the tag 200 is indicated by the orientation of the label 216 of the symbol in the tag diagrams (see for example FIG. 23). In general, the orientation of all symbols 204 within a particular segment of the tag 200 is the same, consistent with the bottom of the symbol being closest to the centre of the tag.

Only the macrodots 206 are part of the representation of a symbol 204 in the pattern. The square outline 214 of a symbol 204 is used in this specification to more clearly elucidate the structure of a tag 204. FIG. 27, by way of illustration, shows the actual pattern of a tag 200 with every bit 206 set. Note that, in practice, every bit 206 of a tag 200 can never be set.

A macrodot 206 is nominally circular with a nominal diameter of (5/9)s. However, it is allowed to vary in size by ±10% according to the capabilities of the device used to produce the pattern.

A target 202 is nominally circular with a nominal diameter of (17/9)s. However, it is allowed to vary in size by ±10% according to the capabilities of the device used to produce the pattern.

The tag pattern is allowed to vary in scale by up to ±10% according to the capabilities of the device used to produce the pattern. Any deviation from the nominal scale is recorded in the tag data to allow accurate generation of position samples.

Tag Groups

Tags 200 are arranged into tag groups 218. Each tag group contains four tags arranged in a square. Each tag 200 has one of four possible tag types, each of which is labelled according to its location within the tag group 218. The tag type labels 220 are 00, 10, 01 and 11, as shown in FIG. 28.

FIG. 29 shows how tag groups are repeated in a continuous tiling of tags, or tag pattern 222. The tiling guarantees the any set of four adjacent tags 200 contains one tag of each type 220.

Codewords

The tag contains four complete codewords. The layout of the four codewords is shown in FIG. 30. Each codeword is of a punctured 24-ary (8, 5) Reed-Solomon code. The codewords are labelled A, B, C and D. Fragments of each codeword are distributed throughout the tag 200.

Two of the codewords are unique to the tag 200. These are referred to as local codewords 224 and are labelled A and B. The tag 200 therefore encodes up to 40 bits of information unique to the tag.

The remaining two codewords are unique to a tag type, but common to all tags of the same type within a contiguous tiling of tags 222. These are referred to as global codewords 226 and are labelled C and D, subscripted by tag type.

A tag group 218 therefore encodes up to 160 bits of information common to all tag groups within a contiguous tiling of tags.

Reed-Solomon Encoding

Codewords are encoded using a punctured 24-ary (8, 5) Reed-Solomon code. A 24-ary (8, 5) code encodes 20 data bits (i.e. five 4-bit symbols) and 12 redundancy bits (i.e. three 4-bit symbols) in each codeword. Its error-detecting capacity is three symbols. Its error-correcting capacity is one symbol.

FIG. 31 shows a codeword 228 of eight symbols 204, with five symbols encoding data coordinates 230 and three symbols encoding redundancy coordinates 232. The codeword coordinates are indexed in coefficient order, and the data bit ordering follows the codeword bit ordering.

A punctured 24-ary (8, 5) Reed-Solomon code is a 24-ary (15, 5) Reed-Solomon code with seven redundancy coordinates removed. The removed coordinates are the most significant redundancy coordinates.

The code has the following primitive polynominal:
p(x)=x4+x+1 (EQ 1)

The code has the following generator polynominal:
g(x)=(x+a)(x+a2) . . . (x+a10) (EQ 2)

For a detailed description of Reed-Solomon codes, refer to Wicker, S. B. and V. K. Bhargava, eds., Reed-Solomon Codes and Their Applications, IEEE Press, 1994, the contents of which are incorporated herein by reference.

The Tag Coordinate Space

The tag coordinate space has two orthogonal axes labelled x and y respectively. When the positive x axis points to the right, then the positive y axis points down.

The surface coding does not specify the location of the tag coordinate space origin on a particular tagged surface, nor the orientation of the tag coordinate space with respect to the surface. This information is application-specific.

For example, if the tagged surface is a sheet of paper, then the application which prints the tags onto the paper may record the actual offset and orientation, and these can be used to normalise any digital ink subsequently captured in conjunction with the surface.

The position encoded in a tag is defined in units of tags. By convention, the position is taken to be the position of the centre of the target closest to the origin.

Tag Information Content

Table 1 defines the information fields embedded in the surface coding. Table 2 defines how these fields map to codewords.

TABLE 1
Field definitions
fieldwidthdescription
per codeword
codeword type2The type of the codeword, i.e. one of
A (b′00′), B (b′01′), C (b′10′) and D (b′11′).
per tag
tag type2The type1 of the tag, i.e. one of
00 (b′00′), 01 (b′01′), 10 (b′10′) and 11 (b′11′).
x coordinate13The unsigned x coordinate of the tag2.
y coordinate13The unsigned y coordinate of the tagb.
active area flag1A flag indicating whether the tag is a member
of an active area. b′1′ indicates membership.
active area map1A flag indicating whether an active area map
flagis present. b′1′ indicates the presence of a
map (see next field). If the map is absent then
the value of each map entry is derived from
the active area flag (see previous field).
active area map8A map3 of which of the tag's immediate eight
neighbours are members of an active area.
b′1′ indicates membership.
data fragment8A fragment of an embedded data stream.
Only present if the active area map is absent.
per tag group
encoding format8The format of the encoding.
0: the present encoding
Other values are TBA.
region flags8Flags controlling the interpretation and routing
of region-related information.
0: region ID is an EPC
1: region is linked
2: region is interactive
3: region is signed
4: region includes data
5: region relates to mobile application
Other bits are reserved and must be zero.
tag size16The difference between the actual tag size
adjustmentand the nominal tag size4, in 10 nm units, in
sign-magnitude format.
region ID96The ID of the region containing the tags.
CRC16A CRC5 of tag group data.
total320

1corresponds to the bottom two bits of the x and y coordinates of the tag

2allows a maximum coordinate value of approximately 14 m

3FIG. 29 indicates the bit ordering of the map

4the nominal tag size is 1.7145 mm (based on 1600 dpi, 9 dots per macrodot, and 12 macrodots per tag)

5CCITT CRC-16 [7]

FIG. 32 shows a tag 200 and its eight immediate neighbours, each labelled with its corresponding bit index in the active area map. An active area map indicates whether the corresponding tags are members of an active area. An active area is an area within which any captured input should be immediately forwarded to the corresponding Netpage server for interoperation. It also allows the Netpage sensing device to signal to the user that the input will have an immediate effect.

TABLE 2
Mapping of fields to codewords
codewordfield
codewordbitsfieldwidthbits
A1:0codeword type2all
(b′00′)
10:2 x coordinate912:4 
19:11y coordinate912:4 
B1:0codeword type2all
(b′01′)
 2tag type10
5:2x coordinate43:0
 6tag type11
9:6y coordinate43:0
10active area flag1all
11active area map flag1all
19:12active area map8all
19:12data fragment8all
C001:0codeword type2all
(b′10′)
9:2encoding format8all
17:10region flags8all
19:18tag size adjustment21:0
C011:0codeword type2all
(b′10′)
15:2 tag size adjustment1415:2 
19:16region ID43:0
C101:0codeword type2all
(b′10′)
19:2 region ID1821:4 
C111:0codeword type2all
(b′10′)
19:2 region ID1839:22
D001:0codeword type2all
(b′11′)
19:2 region ID1857:40
D011:0codeword type2all
(b′11′)
19:2 region ID1875:58
D101:0codeword type2all
(b′11′)
19:2 region ID1893:76
D111:0codeword type2all
(b′11′)
3:2region ID295:94
19:4 CRC16all

Note that the tag type can be moved into a global codeword to maximise local codeword utilization. This in turn can allow larger coordinates and/or 16-bit data fragments (potentially configurably in conjunction with coordinate precision). However, this reduces the independence of position decoding from region ID decoding and has not been included in the specification at this time.

Embedded Data

If the “region includes data” flag in the region flags is set then the surface coding contains embedded data. The data is encoded in multiple contiguous tags' data fragments, and is replicated in the surface coding as many times as it will fit.

The embedded data is encoded in such a way that a random and partial scan of the surface coding containing the embedded data can be sufficient to retrieve the entire data. The scanning system reassembles the data from retrieved fragments, and reports to the user when sufficient fragments have been retrieved without error.

As shown in Table 3, a 200-bit data block encodes 160 bits of data. The block data is encoded in the data fragments of A contiguous group of 25 tags arranged in a 5×5 square. A tag belongs to a block whose integer coordinate is the tag's coordinate divided by 5. Within each block the data is arranged into tags with increasing x coordinate within increasing y coordinate.

A data fragment may be missing from a block where an active area map is present. However, the missing data fragment is likely to be recoverable from another copy of the block.

Data of arbitrary size is encoded into a superblock consisting of a contiguous set of blocks arranged in a rectangle.

The size of the superblock is encoded in each block. A block belongs to a superblock whose integer coordinate is the block's coordinate divided by the superblock size. Within each superblock the data is arranged into blocks with increasing x coordinate within increasing y coordinate.

The superblock is replicated in the surface coding as many times as it will fit, including partially along the edges of the surface coding.

The data encoded in the superblock may include more precise type information, more precise size information, and more extensive error detection and/or correction data.

TABLE 3
Embedded data block
fieldwidthdescription
data type8The type of the data in the superblock.
Values include:
0: type is controlled by region flags
1: MIME
Other values are TBA.
superblock width8The width of the superblock, in blocks.
superblock height8The height of the superblock, in blocks.
data160The block data.
CRC16A CRC6 of the block data.
total200

6CCITT CRC-16 [7]

Cryptographic Signature of Region ID

If the “region is signed” flag in the region flags is set then the surface coding contains a 160-bit cryptographic signature of the region ID. The signature is encoded in a one-block superblock.

In an online environment any signature fragment can be used, in conjunction with the region ID, to validate the signature. In an offline environment the entire signature can be recovered by reading multiple tags, and can then be validated using the corresponding public signature key. This is discussed in more detail in Netpage Surface Coding Security section above.

MIME Data

If the embedded data type is “MIME” then the superblock contains Multipurpose Internet Mail Extensions (MIME) data according to RFC 2045 (see Freed, N., and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME)-Part One: Format of Internet Message Bodies”, RFC 2045, November 1996), RFC 2046 (see Freed, N., and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME)—Part Two: Media Types”, RFC 2046, November 1996) and related RFCs. The MIME data consists of a header followed by a body. The header is encoded as a variable-length text string preceded by an 8-bit string length. The body is encoded as a variable-length type-specific octet stream preceded by a 16-bit size in big-endian format.

The basic top-level media types described in RFC 2046 include text, image, audio, video and application.

RFC 2425 (see Howes, T., M. Smith and F. Dawson, “A MIME Content-Type for Directory Information”, RFC 2045, September 1998) and RFC 2426 (see Dawson, F., and T. Howes, “vCard MIME Directory Profile”, RFC 2046, September 1998) describe a text subtype for directory information suitable, for example, for encoding contact information which might appear on a business card.

Encoding and Printing Considerations

The Print Engine Controller (PEC) supports the encoding of two fixed (per-page) 24-ary (15, 5) Reed-Solomon codewords and six variable (per-tag) 24-ary (15, 5) Reed-Solomon codewords. Furthermore, PEC supports the rendering of tags via a rectangular unit cell whose layout is constant (per page) but whose variable codeword data may vary from one unit cell to the next. PEC does not allow unit cells to overlap in the direction of page movement. A unit cell compatible with PEC contains a single tag group consisting of four tags. The tag group contains a single A codeword unique to the tag group but replicated four times within the tag group, and four unique B codewords. These can be encoded using five of PEC's six supported variable codewords. The tag group also contains eight fixed C and D codewords. One of these can be encoded using the remaining one of PEC's variable codewords, two more can be encoded using PEC's two fixed codewords, and the remaining five can be encoded and pre-rendered into the Tag Format Structure (TFS) supplied to PEC.

PEC imposes a limit of 32 unique bit addresses per TFS row. The contents of the unit cell respect this limit. PEC also imposes a limit of 384 on the width of the TFS. The contents of the unit cell respect this limit.

Note that for a reasonable page size, the number of variable coordinate bits in the A codeword is modest, making encoding via a lookup table tractable. Encoding of the B codeword via a lookup table may also be possible. Note that since a Reed-Solomon code is systematic, only the redundancy data needs to appear in the lookup table.

Imaging and Decoding Considerations

The minimum imaging field of view required to guarantee acquisition of an entire tag has a diameter of 39.6s (i.e. (2×(12+2))√{square root over (2)}s), allowing for arbitrary alignment between the surface coding and the field of view. Given a macrodot spacing of 143 μm, this gives a required field of view of 5.7 mm.

Table 4 gives pitch ranges achievable for the present surface coding for different sampling rates, assuming an image sensor size of 128 pixels.

TABLE 4
Pitch ranges achievable for present surface coding
for different sampling rates; dot pitch = 1600 dpi, macrodot
pitch = 9 dots, viewing distance = 30 mm, nib-to-FOV
separation = 1 mm, image sensor size = 128 pixels
sampling
ratepitch range
2−40 to +49
2.5−27 to +36
3−10 to +18

Given the present surface coding, the corresponding decoding sequence is as follows:

    • locate targets of complete tag
    • infer perspective transform from targets
    • sample and decode any one of tag's four codewords
    • determine codeword type and hence tag orientation
    • sample and decode required local (A and B) codewords
    • codeword redundancy is only 12 bits, so only detect errors
    • on decode error flag bad position sample
    • determine tag x-y location, with reference to tag orientation
    • infer 3D tag transform from oriented targets
    • determine nib x-y location from tag x-y location and 3D transform
    • determine active area status of nib location with reference to active area map
    • generate local feedback based on nib active area status
    • determine tag type from A codeword
    • sample and decode required global (C and D) codewords (modulo window alignment, with reference to tag type)
    • although codeword redundancy is only 12 bits, correct errors;
    • subsequent CRC verification will detect erroneous error correction
    • verify tag group data CRC
    • on decode error flag bad region ID sample
    • determine encoding type, and reject unknown encoding
    • determine region flags
    • determine region ID
    • encode region ID, nib x-y location, nib active area status in digital ink
    • route digital ink based on region flags

Note that region ID decoding need not occur at the same rate as position decoding.

Note that decoding of a codeword can be avoided if the codeword is found to be identical to an already-known good codeword.

The above description is purely illustrative and the skilled worker in this field will readily recognize many variations and modifications that do not depart from the spirit and scope of the broad inventive concept.