AMENDMENT NO. 2 TO TECHNOLOGY LICENSE AGREEMENT

Exhibit 10.29

[ * ] = CERTAIN CONFIDENTIAL INFORMATION CONTAINED IN THIS DOCUMENT, MARKED BY BRACKETS, HAS BEEN OMITTED AND FILED SEPARATELY WITH THE SECURITIES AND EXCHANGE COMMISSION PURSUANT TO RULE 24B-2 OF THE SECURITIES EXCHANGE ACT OF 1934, AS AMENDED.

AMENDMENT NO. 2 TO

TECHNOLOGY LICENSE AGREEMENT

This Amendment No. 2 (“Amendment No. 2”) dated as of March 25, 2005 (the “Amendment No. 2 Effective Date”) to that certain Technology License Agreement dated January 25, 2004 (the “Original Agreement”) by and between ANOTO AB, a company incorporated under the laws of Sweden (“Anoto”), ANOTO GROUP AB, a company incorporated under the laws of Sweden (“ANOTO GROUP”), and LEAPFROG ENTERPRISES, INC., a company incorporated under the laws of Delaware (“LeapFrog”). Each of Anoto, Anoto Group, LeapFrog are referred to as a “Party”, and collectively as the “Parties”. Capitalized terms not defined in this Amendment No. 2 will have the meaning ascribed to them in the Original Agreement.

BACKGROUND

The Parties entered into the Original Agreement as of January 25, 2004.

The Parties desire to amend certain portions of the payment schedule set forth in Schedule G (Royalty and Payment Schedule) of the Original Agreement and to clarify certain delivery obligations as set forth herein.

Based on the foregoing, and in consideration of the mutual promises and covenants set forth below and other good and valuable consideration the receipt and adequacy of which is hereby acknowledged, the Parties hereby agree as follows:

AGREEMENT

1. Amendments to Payment Schedule.

1.1 Milestone I NRE. Section 5.2(c) of Schedule G of the Original Agreement is hereby replaced in its entirety with the following: “Upon execution of Amendment No. 2.”

1.2 Milestone M NRE. Section 5.2(d) of Schedule G of the Original Agreement is hereby replaced in its entirety with the following: “Upon final acceptance by LeapFrog of Milestone M (Release to Production Date (RTP)).

1.3 First Advance Royalty Payment. Section 5.5(a) of Schedule G of the Original Agreement is hereby replaced in its entirety with the following:

[*] shall be paid upon execution of Amendment No. 2.

1.4 Second Advance Royalty Payment. Section 5.5(b) of Schedule G of the Original Agreement is hereby replaced in its entirety with the following:

[*] shall be paid upon the latter of June 30, 2005 or final acceptance of Milestone M (Release to Production Date (RTP)).

1.5 Other Invoiced Amounts.

Invoice #1002820 in the amount of [*] shall be paid on or before execution of Amendment No. 2.

Invoice #1002821 in the amount of [*] shall be paid on or before execution of Amendment No. 2.

Invoice #1003710 in the amount of [*] shall be paid upon execution of Amendment No. 2.

Invoice #1003709 in the amount of [*] shall be paid upon final acceptance of [*].

Invoice #1003708 in the amount of [*] shall be paid upon final acceptance of [*].

2. Effect of Work Performed under SSoWs. Anoto acknowledges and agrees that the deliverables to be provided by Anoto to LeapFrog under Schedule A of the Technology License Agreement apply to the XY Module as modified by the work performed under SSoW#1 and SSoW#2.

3. Clarification of RTP Milestone M (RTP) deliverables. The Parties acknowledge that the Milestone M (Release to Production Date (RTP)) deliverable under Schedule A of the Original Agreement includes all items identified in Section 4 below, Exhibit A attached hereto, Attachement1 050321.xls, and Attachment2 050321.doc, excluding DP18, PPS12 and PPS13 of Attachement1 050321.xls. The Parties acknowledge that the specifications for these items are not precise at this time. The Parties agree to use good faith and commercially reasonable best effort to define and deliver these items in accordance with the guidelines set forth in Exhibit A attached hereto.

4. Amendments to Delivery Schedule. Anoto will use commercially reasonable best efforts to meet the following schedule:

FLY PPS Design Specifications – [*] (prerelease with TBDs will be done along the road)

FLY PPS Design description – Done

FLY PPS measured data – [*] after receiving pens and working [*] environment

FLY PPS Product Specification – [*] after FLY PSS measured data

Other priority 1 items in Attachement1 050321.xls and in Attachment2 050321.doc – [*]

Priority 2 items in Attachement1 050321.xls and in Attachment2 050321.doc – [*]

5. Payments. Milestone M deliveries will be delivered at no additional charge (beyond the original contracted amount plus amounts due under SSOW #1 and SSOW #2) unless additional charges are expressly identified in this Amendment No. 2 or otherwise agreed to in writing by the parties.

6. Effective of this Amendment. Except as expressly set forth herein, the Original Agreement shall remain in full force and effect in accordance with its terms.

7. Miscellaneous. This Amendment No. 2, the Original Agreement and all other duly executed, written amendments to the Original Agreement represent the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior agreements and understandings with respect to the subject matter hereof.

In witness whereof, the Parties hereto have executed this Amendment No. 2 as of the Amendment No. 2 Effective Date.


LEAPFROG ENTERPRISES, INC.		ANOTO AB

By:	/s/ ▇▇▇▇ ▇▇▇▇▇▇▇	By:	/s/ ▇▇▇▇▇▇ ▇▇▇▇▇▇
	▇▇▇▇ ▇▇▇▇▇▇▇, CTO		▇▇▇▇▇▇ ▇▇▇▇▇▇

		By:	/s/ Mats ▇▇▇▇
			Mats ▇▇▇▇, Chief Financial Officer

Address for Notices ▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇▇▇▇, ▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇ ▇▇▇ Fax: (▇▇▇) ▇▇▇-▇▇▇▇ Attention: VP, Legal Affairs		Address for Notices: ▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇ ▇ ▇▇▇ ▇▇ ▇▇▇▇, ▇▇▇▇▇▇ Fax: ▇▇▇ ▇▇ ▇▇▇ ▇▇ ▇▇ Attention: Chief Executive Officer

		ANOTO GROUP AB

		By:	/s/ ▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇
			▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇, Chairman

		Address for Notices: ▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇ ▇ ▇▇▇ ▇▇ ▇▇▇▇, ▇▇▇▇▇▇ Fax: ▇▇▇ ▇▇ ▇▇▇ ▇▇ ▇▇ Attention: Chairman

EXHIBIT A

Clarification of Certain

Milestone M (Release to Production Date (RTP)) Deliverables

FLY PPS specification process

Anoto will develop FLY PPS specifications in a three step process. First, Anoto will deliver a [*]. Second, Anoto will characterize [*] and produce a [*]. Third, Anoto will correlate [*] with [*] and produce a [*] Anoto will be responsible for a design that performs consistent with the Design Specifications Provided that pens are assembled correctly with in tolerance components. The Product Specifications may vary slightly from the Design Specification provided that such variations do not have a material adverse effect on product performance.

FLY PPS Design Specification

The goal of the Design Specification is to provide a well characterized theoretical performance specification over conditions which somewhat exceed the normal specified use conditions. The scope and format will be developed in accordance with the example set forth in Attachement3 Fly_PPS_Design_specification.doc. Four additional [*] may be added to address additional information requested by LeapFrog. Information on performance reduction due to [*] will be provided based on [*] data. [*] will be of similar accuracy and confidence as those in the [*] (reference) [*]. Anoto intends to achieve this accuracy by performing [*] analysis on the results of [*]. Design Specifications will reference the possibility of up to a [*] based on possible deviations between [*] performance. [*] will be of sufficient accuracy to have a [*] confidence that there will not be a [*] of performance.

FLY PPS [*] report

The [*] verification step will be conducted on FLY pens in lieu of the originally envisioned [*] reference verification. Quantities and details of the verification procedure will be discussed and established by mutual agreement. Goals of the verification process include establishing confidence in the theoretical performance data across the range of allowed manufacturing tolerances. LeapFrog will be responsible for providing components with mechanical dimensions well characterized. Parties will consider how to best verify performance at manufacturing tolerances. LeapFrog may request the testing of additional pens for the purpose of qualifying its manufacturing process. Testing charges will apply for the testing of pens beyond that which is reasonably appropriate to properly qualify the design performance.

Additional information

Anoto will provide additional [*] information to enable LeapFrog to set up a manufacturing test process. For example, LeapFrog may need to understand the nature of the system behavior when certain critical components are [*] or [*]. Analysis of LeapFrog manufacturing problems, if needed, will be provided to LeapFrog [*].

Design adjustment

Anoto will provide some guidance to help LeapFrog to become effective at making minor performance adjustments as may be reasonably useful to optimize for component spec variations or [*]. Examples may include [*]. The goal will be to give LeapFrog enough guidance to become productive at testing and collecting data on possible adjustments. It is understood that any adjustments must be simulated by Anoto before implementation otherwise performance results cannot be guaranteed. Additional charges would apply for the simulation of LeapFrog requested adjustments.

DotCode performance

DotCode performance will be improved with a target of [*]. Present goals are to achieve [*] performance. [*] information will be provided. Variations in performance from [*] will be documented.

Minimum dot size

Fly will target [*] dot size to be consistent with Anoto ecosystem. Performance specifications will be provided at [*] and above [*] so that LeapFrog can make decisions regarding content and system design margin. Expectations are that FLY DotPos at [*] will not be [*] than [*] reference at [*] (except for known FLY limits beyond [*])

ImageViewer

Anoto will provide Image Viewer in [*] format with certain additional features as have been discussed. Final determination of Anoto provided feature set will be determined by mutual agreement. The goal is to provide sufficient functionality up front so that [*] does not have to be upgraded to a [*] interface.

Attachment 1

Milestone M

Milestone M. [Illegible]

SSow

[Illegible]

1	[Illegible] for RTP

2	Scheduled later than critical items

Pen Positioning System (PPS)

Category

Name

Category

Description from Leapfrog

Comments and action

Delivery date

P=PS1

PPS

[*] (Mark’s)

Milestone

Describe to Leapfrog the design, simulation and verification process that results of the [*] and [*] (i.e. including SSOWs 1 and 2) having a sufficient level of [*], and [*] (including [Illegible] and characterization data to simulation) to support [*]

Need for review. Update [*] “The Leapfrog role in the PPS chain” will be followed – simulations and individual design tests in the [Illegible] system can not be described.

[*]

PPS2

PPS

[*] (PeterM’s)

Milestone

[*]pdf

• what pens were tested? [*] pens with [*]? [Illegible] end pens?

• What was the maximum [*] tested? [*] conditions?

• How many systems [Illegible] with [*]? What [*] conditions? How well did the units perform, acceptable or target? (according to [*])

as above

[*]

PPS3

[*]

PPS specs

Milestone

Should mention or reference the performance with [*] – is it the same?

Technical usage description in [*] and [*] have agreed that Leapfrog will create Leapfrog user specifications for [*].

PPS4

[*]

specs

SSoW1 (FlyPPS)

[*].pdf (Section [Illegible]/24 It includes a brief discussion on performance at [*], but needs to be greatly expanded. It only states that [*] performance at these [*] is okay. It needs to define the [*] better, the expected [*] and [*] that this causes. Differentiating [*] through this region [*] in this [*] might help too.

[*] date in [*] will not be expanded as no [*] has asked for it and we have the same type of [*] in previous specs. A [*] test with high resolution will be done on Fly pen and delivered as a test report Anoto needs [*] and [*] from Leapfrog to perform the task.

[*]

PPS5

Suggested [*] Improvements

SSoW1 (FlyPPS)

Reducing [*] in the [*] and in (illegible) the [*]. Are these related to [*] case [*] and –ve [Illegible] [*] ( as well as associated [*]) Leapfrog does not have [*] of the system to make [*] and [*] on these issues and needs more information in this area.

Update [*]

[*]

PPS7

FlyPPS [*]

SSoW1 (FlyPPS)

Identify [*] or [*] tasks that are [*] or done [*] on the [*] (vs. the reference [*]) and discuss why these differences are appropriate given the nature of the Leapfrog [*]. Was the [*] tested in [*] and [*] modes?

The complete verification is quoted by Anoto [*] due to issued [*] an [*] Product Specification will be done based on Knowledge from [*] and [*]. This process will be explained in a separate document

[*]

PPS8

FlyPPS [*]

SSoW1 (FlyPPS)

Provide [*], clearly [*] in which the [*] production [*] performance differs from the [*], including performance on [*]

Does “[*]” mean [*] or [*] [*]?

[*]

PPS9

FlyPPS [*]

SSoW1 (FlyPPS)

The [*] to [*] may be solved by [*] the [*] of the [*] – what is the predicted improvement in [*] with this changes (or [*] where did the [*] performance in [*]) again [*] does

This is a [*] to solve & [*] side step from the [*], and will only put fly back on the [*] (Fly PPS [*]). No [*] will be provided as it is [*] in accordance with the document. “The Leapfrog role in the PPS chain”

[*]

not have a basis [*] the [*] is
performance from this change (and
perhaps [Illegible] related issues of
stray light). A [*] would help with
these issues.

PPS10

FlyPPS [*] [Illegible]

SSoW1 (FlyPPS)

What is the [*] of the system and what is the [*]? The [*] has quoted [*] and [*] under all conditions [*]. Does the [*]? Does it include the [*] in [*] modes?

[*] bias for Fly will be part of Fly PPS PS. A more extended explanation is included in [[*] documentation. The [*] mode for [*] bias is calculated from the date set with Leapfrog in [*].

[*]

PPS11

[*] size

SSoW1 (FlyPPS)

LeapFrog has no documented information on [*] on the [*] and performance or [*] and performance.

Performance

[*]

2 or 3

PPS12

(illegible)

Other

(illegible)

[Illegible]

2 or 3

PPS13

(illegible)

Other

(illegible)

DotPos

Name

Category

Description from LeapFrog

Planned action

Delivery date

DP1

DotPos [*]

Milestone M

[*] to hold a [*] with [*] and [*] to review [*] discuss [*], [*], [*], and review othernew [*] requirements

Needs feedback from [*] on agenda and meeting time to be able to set up a meeting with the right people request sent on e-mail [*] and again [*] with [*]

DP2

DotPos [*]

Milestone M

[*] that was contained in DotPos design requirements documents, including [*] levels, [*] regulation and limit and [*], Request delivery of [*] requirements doc including [*] referenced in test reports, or merge of this info into [*]

[*] have been updated. Available on the [*]. All versions of the [*] have been put on the [*].

[*]

1 Plan

2 done

DP3

DotPos Life [*]

Milestone M, DBSS March

Approved [*] with pre production phase complete

[*] responsible. Draft for time schedule is first readout [*] and final readout [*]. If you like to this could be discussed during a design review as above.

DotPos (illegible) BB Verification summary rev003

DP4

Milestone M

Missing much of the [*] and [*] (how many parts, what [*] ranges, etc)

More info are available in [*] verification summary”

[*]

DP5

Milestone M

like to see [*] and [*] represented in the front of the report

[1],[2],[6],[7],[8],[9] and [14] are available on the sftp. [3], [4], [5], [10] are confidential. Non-confidential parts of [11], [12], [13] have been summarized in the document.

—

DP6

Milestone M

like to understand [*] what [*] used for [*]

What tests are retired to 7 [Illegible] more info will be available in row [Illegible] of [*] summary.

done?

DP7

Milestone M

like better description of [*]

Confidential in accordance with the documents. “The Leapfrog role in PPS chain”

—

DP8

Milestone M

which [*] are tested, which are not, in use production test ([*]. ..)

Confidential in accordance with the document. “The Leapfrog role in the PPS chain”

—

DP9

Milestone M

how is the [*] not [*] for [*]?

Confidential in accordance with the document. “The Leapfrog role in the PPS chain”

—

DP10

Milestone M

what is [*]?

See Section [*] in [*] verification summary”

—

DP11

Milestone M

would like better understanding of [*]and [*], and implications [*]

[Illegible] – The [*] with be as [*] is only used for testing. and have no implications. Image part - Confidential in accordance with the document. “The Leapfrog role in the PPS chain”

—

DP12

Milestone M

need a spec on [*]

Will be added (should not be article since Leapfrog are using a FSR switch)

18 Mar 05

DP13

Milestone M

missing [*]

The [*] is now [*] finished, and [*] are currently being received.

18 Mar 05

1 plan

2 done

DP14

Milestone M,

pass March

missing [*] testing

[*] have only been [*] [Illegible], Do you require the [*] test have to be done by [*]. II required , we should let [*] as soon as possible.

DP15

Milestone M

Missing [Illegible] tests

[*] verification summary”

done

[Illegible] production release at [*]

DP16

Milestone M

Need written approval of [*] by both Anoto and [*]

Final review of will take place this week

18/Mar/05

DP17

Milestone M

Need written confirmation from [*] that [*] is ready to [*] consistent with the [*]

18/Mar/05

1 plan

2 dellv.

DP18

[*]

other

Deliver [*] samples to LeapFrog

[Illegible]

APR

Name

Category

Description from Leapfrog

Planned action

Delivery date

Dot Codes

APR1

No [*] found covering [*]

Addressed in [*]

APR2

Writing [*]

[*]

No specification found covering [*].

All [*] supported, See [*]

APR3

Writing [*]

[*]

(UK)

[*] does not match [*]

Dotcodes are more sensitive

APR4

Printing DotCodes

No specification or specification reference found for [*].

No difference to [*]– according to [*]

APR4,5

ECC count

[*]– there should be a value that indicates [*]. This can help LF understand quality of dotcode [*].

New

Pen Tip Correction

APR6

Pen Tip Correction

[Illegible]

APR

APR7

[*] and laser printer support

[*]

• how is performance specified? what performance should LeapFrog get?

• how can LeapFrog test and [*]

Added comments [*]. This functionality [*] techniques. The functionality for [*] will be implemented at Anoto and be available to leapfrog in the future.

done

APR 6,7,13

Perspective [*]

The [*], [*] and [*] of the [*] and [*] specified. The [*] feature described in the original contract is not specified and LeapFrog cannot verify this functionality. How can Leapfrog test and accept the technology as delivered today in [*]?

How much do the [*] cost or improve [*]? How much do they improve [*]? How much do they increase [*]? How do these two parameters interact and what side-effects are there in their use?

Added comments to [*]. Information if a [*] was returned due to [*]. Anoto can release a new version of [*] where this information is returned. [*] allows for the pen updates mode to be used, see the [*] when part of the pattern is [*], …) The two do not interact. See sections 4 of the [*]

done

APR8

Specification does not state that [*] in the [*] are accepted and processed

Leapfrog can use the entire [*] for open functionality (Anoto functionality may however not be supported by Leapfrog pens as of today)

—

APR9

No indication of which [*] versions are supported.

Added to [*] Software Spec. section 1

done

APR10

Contract and [*] discussed [*] Current LF release is [*]. Is our APR module based off of the Second generation of the APR?

Yes, see section 1 of [*]

done

APR11

Measured [*] from Anoto specified in [*] match those measured by LF. Discussions are underway to understand the differences.

Being investigated. Anoto use same way of [*] same as LF. Email send to ▇▇▇▇ regarding this on [*]

[Illegible] to come back

APR12

[*] module is not [*]. It does not confirm to Industry standard [*] or the [*] in other [*] production [*].

No known [*] tested. No further actions planned.

—

APR14

Section 4 describes the [*], but there are no details into what causes these [*]. For example with [*]- what are the [*] for this condition?

Added to [*]

done

APR15

Section 4 does not describe the [*] [Illegible] formal referred to by [*]_ [Illegible] [*] function.

These are Anoto [Illegible] and will not be described further.

—

APR16

Section 6 should refer to [*] and performance specifications as [*] of the version of [*]. Some items are shown as actuals as measured with [*] of the code. Values need to be described as [*] or [*] with an additional [*] value.

Addressed in [*]

done

APR17

Section 6 shows current [*] for a specific version of [*]. [*] and does not appear to include [*]. These [*] should be specified as [*]. SOW#2 indicated a total size of [*] maximum.

Addressed in [*]

done

APR18

Section 6 shows actual [*] usage for [*] and not [*] values. It does not include [*] usage by DPCom and [*]. SOW#2 state a target of [*] and a maximum of [*], including [*] usage by [*] and [*] overhead.

Addressed in [*]

done

APR19

Section 6 states target execution times that are [*] then SOW#2 which describes target performance [*] acceptable times.

These are Anoto targets, not a product specification

—

APR20

Section 7 describes actual measured [*] for [*]. These should be stated as targets. In addition, there is no indication on how these performance targets are effected by pen angle, [*], number of dots, etc.

See appendix B1 of [*]. Execution time is only dependent on [*]. The [*] the [*] is however dependent on [*] and [*]

done

APR21

Section 8 describes various [*] that [*] must follow in order to work within the Fly system. As described they are referring to a particular version of code and not the rules that any release must follow. The specification should reflect the rules established in SOW#2

Addressed in [*]

done

APR22

[*] and [*] modules do not have specifications [*]. No [*] targets have been set for these modules.

Module description is found in [*] targets adressed in [*]

done

APR23

Specification describing [*]

[*] module from SOW#2 mods must go through [*]. Need written spec describing [*] and notice that it has gone through those specifications.

new

▇▇▇▇▇

Name

Category

Description from Leapfrog

Planned Action

Delivery date

[*] files

Milestone M

[*] (e.g. how does ▇▇▇▇▇ deal with [*]; more than one?; date based?)

There are two different kind of [*]. Anoto [*]) which is not related to LF at all and needs not to be considered. [*]. There is [*] which is valid for [*] purchased for [*]. AndyC/ Stefan/Johan phone conference [*]; Will be described briefly. [*] from LF to 3rd parties will be discussed off the Milestone deliveries.

15/Mar/05

Dot Generation

Milestone M

[*] (e.g. how is this manifested in an [*]

[*] method is confidential. Andy C/▇▇▇▇▇▇▇/Johan phone conference [*]; [*] will be documented briefly with the purpose of [*] to this format in future releases. Branching [*] version to Leapfrog was also discussed but rejected as this would mean that Leapfrog would not benefit from future updates on other [*]

15/Mar/05

[*] Merging

Milestone M

[*] Merging (e.g. how is this happening, how can we [*] the [*] we have been experiencing)

This is changed in [*] which will include the [*] file. The process will be and has [*] by Leapfrog to ensure quality and stability of the new solution.

done

Lib Support

Milestone M

Lib support (e.g. is this a standard C library? What [*] is it targeted for? Is it available on other [*]? Is this the only [*]?)

It is a standard [*]. It is currently not available for [*] but the code is [*] and it should be possible to move.

—

Runtime details

Milestone M

Runtime details (e.g. how much [*] what [*] on)

[*] depends on [*]. On a general case [▇▇▇▇▇] consumes between [*] (which is too [*] to be a relevant figure in a specification)

AndyC/Stefan/Johan phone conference [*]; Andy to give detailed request list by 11 March.

example

Supported

[*]

Milestone M

Need written confirmation from Anoto that the following [*] are supported; [*]

[*] is the agreed solution to [*].

(However need for [*] when run in [*])

—

Supported additional [*]

Milestone M

What additional [*] are supported?

see above

—

Available input and output formats

Milestone M

What is full range of input and output formats?

The specified input and output for the current LF and [*] implementation and process is [*] in and [*] out. A lot more is supported [*]

—

▇▇▇▇▇ functional Issues, see the ▇▇▇▇▇ Issue1.xls spreadsheet

All issues in this list is either targeted by ▇▇▇▇▇ 1.50 release

▇▇▇ M comments

2/18/2005

Anoto 3/21/2005

LeapFrog (TomM) 3/21/2005


Agreed need to create specification [*] the map out these requirements for both per our conversation with (▇▇▇▇▇ M).	See [*]	Improvement to spec made. [] and [] still is not accurate - (▇▇▇▇▇ M) has additional comments.

Need to document [*]	See [] In addition, Anoto will provide additional performance indications for []	Spec changes acceptable with exception of [*]

See above	See above	Discussion around acceptance of +/- degrees

This fact needs to be documented	See [*]	Spec charges okay.

Is [] solution a [] solution or does it impact []? If its [] it requires a solution before product release. ▇▇▇▇ ▇▇▇▇▇▇▇ need to clarify with Anoto an understanding of how this [*] relates to the discussions of this feature during contract negotiations.		Comments regarding ▇▇▇▇ F’s and Anoto’s discussions about laser support and [] covered under item []. Combining [] around [] issued.

Anoto states that it is [] or [] how this works. Would be valuable to get returned information about [] being activated so we can see how often it is used to ensure its [] due to other possible system issues.		[] should return when [] was used. This will help understand system performance and errors. [] helps with incomplete []. Spec describes the causes of [], but no specification for extent of (Illegible) that can be recovered from with and without []. Spec says with [] success drops if []. If this occurs what happens? Does the system need to adjust or does the [*]

This needs to be stated in writing. Second issue regarding Anoto (Illegible) is a separate issue that does not have to do with what dots will the [*].	See [*]	Spec change okay.

Current test refers to [] and previous versions needs as refer to current [] version and [*] versions.	See [*]	Spec change only states []. Should state from [] version [] through all []

Okay

▇▇▇▇ F sent code to Anoto, They have done it and (Illegible) are still different. We have a copy of their code. (Illegible) needs to (Illegible) in more detail [] to see if that explains it. If [] in this more than it will be much more extensive investigation.	Anoto is waiting for feedback.	As of [] measured [] at [] (Illegible) mode on [] (Illegible) [*].

Anoto states this is [*], but has been used for a long time.	[] should be treated as []	LF will probably be making same (Illegible) in this [*]

[] is now specified, but there are still no details on []. What information does LF need to correctly interpret these [*] and determine what is happening in the system to have caused them?	See [*].[pg8].	[] are []. If these are returned we have no information indicating what are (Illegible) causes of these [] and what can be done to [] them.

I am not concerned with the (Illegible) of the table contents, but only as it [] needs to be [] or [] in the []. Is it simply a [] or are there any [] that should be described so [*] correctly?	See [*][pg14].	Spec changes describes [] (Illegible) format that must be [] to []. This is okay. Should specify a [] so in future versions it doesn’t grew significantly.

(Illegible) now refer to targets and are independent of the []. Need to have []. Currently cannot calculate this would without knowing the [] that could be [] and [] are acceptable. These values have been verified with the latest (Illegible) of []. There is a TODO for the [*] previous version of Spec there was a value for this.	[]. Max. number of []. This equals the limit specified by the [*]

[] images are [] All values except [*] range have been verified.	ok	ok

[] are acceptable. All values, except [] range have been verified.	ok	ok

Should add in section 6 notes about perf only depending on # of [*] and not [*], [*], etc. Should add in description of a not to extend or [*] on the [*] of [*] that could possibly be seen.

What is there is correct, but there are several missing constraints, [*]:- [*] and [*]are assigned by [*] services.

• If [*] is required, in avoid [*] to other [*] users and ensure [*] corresponding [*] should be provided to us to ensure compatibility.

• Source code for generic functions such as (but not limited to) [*] that have [*] contains should be provided in LeapFrog. In case of a [*] that has proprietary [*], Anoto can provide us the [*] with [*].

• Register usage should be provided for each [*] to ensure proper [*].

See [*] resources are allocated outside of the [*] Section 8 specifies the [*] for all future releases. Each release specifies the actual resources required in the release notes.

Attachment 2

Fly Manufacturing Issues For Anoto

FLY test & manufacturing issues.

Priority 1 are production critical.

Priority 2 are important to have soon.

[*]

•

2 - We have a documentation package but do not have an easy way to determine [*]. Would like to use [*] as the test case and go over the documentation with [*] when he is at [*]. We can have [*] use the documentation for setup, calibration and [*] for the third machine. Suggest [*] arrival in [*].

•

1 - Need the pass/fail criteria for [*] on [*] and fully understand the [*] of [*] for [*].

•

We need the details of the limits set in the [*] tests of the [*] modules. What was the recent ([*]) change in Limits?

•

What is the cause of failure if the [*]? What is likely corrective action to take?

•

What is the cause of failure if the [*]? [*]? What is likely corrective action to take?

•

2 - Would like a full [*] for the [*] month

•

1 - Release [*] of the software was intended to [*]. There are still problems being addressed with a new s/w version. This needs to be tested and validated.

•

We are about to enter high volume manufacturing and the [*] test fixture is a vital part of the process, we need to have ‘final’ validated software for the [*].

[*]:

•

2 - Would like [*] month. (See also above though)

•

1 - Need to define [*] limits so LeapFrog can test with DOTPOS [*] samples.

•

We do not have enough knowledge to set useful [*] limits on the units to even pick samples that will [*].

[*]:

•

1 - Need to define [*] limits so leapfrog can run [*] testing.

•

What makes a good or a bad [*]? We have [*] specification only. (Is the system insensitive to the [*] performance of the [*])

•

Is there a sensible [*] on the [*] we can set?

Fly Manufacturing Issues For Anoto

[*]:

•

1 - Still confusion as to the ability of [*] to screen parts

•

With the recent [*], I would like to see a clear document on the [*], associated [*] measurements on [*] and [*] parts, so we don’t do this again.

•

Can we tell on an assembled pen if it has [*]?

•

2 - Need [*].

•

The vendor will no doubt have [*] on the [*], this will be mixed with [*] on the [*] module. LeapFrog doesn’t have a good way of determining the root cause of the [*] problems yet.

[*]:

•

1 - Current s/w does not accept [*] or [*] as acceptable. [*] needs to handle all conditions which can be created by ▇▇▇▇▇

•

The printing vendors will be required to test sheets of LeapFrog printed paper, we need the ability to test the entire sheet at the printer.

•

2 - Current s/w does not return [*] information

•

This lets us validate that the printed sheet reflects the content design.

Are these [*] issues?

•

The appears to be [*] in the s/w such that the time for [*] will increase as more and more [*] are made when the [*] is [*].

•

The [*] software locks up after several [*]. It has to be disconnected from the [*] and reconnected.

[*]:

•

1 - Need [*] to understand the results of [*]

•

We can measure static ‘typical case’ [*] now. We need the knowledge to either predict the [*] performance from these ‘static’ typical [*], or we need more information on the [*] so we can select more rigorous testing to do.

•

When there are failures in a [*], we do not have a way to suggest a root cause today.

Fly Manufacturing Issues For Anoto

•

What are the key variables?

•

[*], what does this cause? How do we measure (view [*] and measure [*]?)

•

Short/long [*]? What problems do these cause? Can we see with [*] dot paper on [*]? [*] dot paper?

•

Mechanical tolerance [*], leading to [*]? What does this cause?

•

Mechanical tolerance [*], pointing errors on [*]? What problems do these cause and how do we detect (large [*] offset?)

•

[*]?

•

System [*] (as measured by [*]?)

•

Excess [*] (as measured by [*]?)

•

1 - Need to define [*] limits so leapfrog can do corner testing on [*]

•

1 - In general we need to know how to debug assembled pen systems from [*] with... [*].

Pen [*]:

•

1 - Need clear definition of acceptance limits for [*]

•

There are [*] limits: the limit based on the [*] design and where the [*] system starts to fail.

1 – [*]. Need this in time for [*].

There will be a [*] for [*], I view this as one of the [*] in the production. We have started with [*] here. The two options are [*] and [*]

•

Currently [*] does no analysis and doesn’t do [*] setup.

•

Need a [*] to perform [*]

•

UI and .ini to initialize DOTPOS – probably with [*] for some [*]. What other variable(s) should we change?

•

[*]

•

Measure and display [*]

•

Test for [*] and [*]

•

Test [*], via [*] on dot paper at [*] angles

•

Test [*].

•

Test [*]?

[*] strategy has become unclear and needs clear direction.

Fly Manufacturing Issues For Anoto

[*] Testing:

•

1/2 - Want [*] Month.

•

1/2 - Need to know list of [*] and their affect on system performance. Once the parameters are adjusted for best LeapFrog Fly performance could we make adjustments in production to [*] on an [*]? [ *]– we may need to change system code to adjust.

•

1/2 - What are the best choices for [*] a complete [*] using [*]? [*], etc. Would like [*] for all parameters.

Attachment 3


[*]


Document ID	Revision	Title		Page (Pages)
DS –	UA1	Fly PPS Design Specification		1 (11)

Author		Checked by and date	Approved by and date	Date
*[]**

Fly PPS Design Specification,

Product No

The information and data contained in this document is preliminary and subject to change without prior approval. Any implementation of the concerned technology shall be tested and verified by the receiver prior to inclusion into a final product.

Summary

This Document defines the [*] of Fly PPS. Fly PPS includes a [*], a [*] with an [*] and a [*] and also [*] and [*].

Revision history


Date	Revision	Description	Author
[*]			OS


*[]**


Document ID	Revision	Title		Page (Pages)
DS –	UA1	Fly PPS Design Specification		2 (11)

Author		Checked by and date	Approved by and date	Date
[*]

Contents


	Summary			1
	Revision history			1

1	INTRODUCTION			3
	1.1	Purpose		3
	1.2	Acronyms and abbreviations		3
	1.3	Definitions		3
	1.4	Device Description		4

2	FUNCTIONALITY			5

3	DEFINITION OF PEN CONDITIONS			7

4	DEFINITION OF USAGE CONDITIONS			8

5	SENSITIVITY ANALYSIS			9
	5.1	[*]		9
	5.2	[*]		10
	5.3	[*]		10
	5.4	[*]		10
	5.5	[*]		10
	5.6	[*]		10
	5.7	[*]		10
	5.8	[*]		10
		5.8.1	[*]	10
		5.8.2	[*]	10

6	REFERENCES			10
Appendix A: Pen Orientation Relative to the Paper				11


*[]**


Document ID	Revision	Title		Page (Pages)
DS –	UA1	Fly PPS Design Specification		3 (11)

Author		Checked by and date	Approved by and date	Date
[*]

1	Introduction

1.1

Purpose

This document defines the performance of the Fly PPS design.

1.2

Acronyms and abbreviations


Term		Definition
Fly PPS		Pen Posting System developed for Fly pen

PPS 3.0		Pen Posting System 3.0

LED		Light Emitting Diode

NIR		Near-infrared

N/A		Not applicable

[*]		[*]

1.3 Definitions
Term		Definition
[*] system		System consisting of the [], [], and [] and [] that delivers [*].

[*] system		System consisting of [] (including []), [] and []

[*]		Module consisting of [*].

[*] ink		[] representation of [] ink. The [] ink is the ink [].

[*] Pen		A pen that has been used as a platform to verify [*].

[*]		A software [] is made in production to [] for [] due to [].


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		4 (11)

Author		Checked by and date	Approved by and date	Date
[*]

1.4

Device Description

The Anoto pen positioning system determines absolute positions of the Anoto pen tip by reading and decoding information encoded in a proprietary pattern printed on the paper surface.

The Pen Positioning System (FLY PPS) consists of the following modules:

•

The [*].

•

A [*], which consists of

•

An [*]

•

A [*]

•

A [*]

•

[*] software

•

[*] software for Anoto [*].

[*]

Figure 1.1. The Anoto digital pen positioning system.


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		5 (11)

Author		Checked by and date	Approved by and date	Date
[*]

2	Functionality

In this section, the functionality of the Positioning System is defined. The functionality is defined for different usage conditions according to section 4.

Table 2-1. Functionality


Name	Value	Definition	Comment
1. Pen positioning for a [] pen under [] conditions	[*]	The percentage [] in a series of [] must be [] in the [] region.	The pen positioning [] in combination with the [] determines how well pen [] are reproduced in the [].

2. Pen positioning for [] pens under [] conditions	[*]	The maximum number of [] that [] must be (Illegible). The system should be [] in a [] position.	[] indicates a region where the [] from the [] the images [] (see [] Definitions) [] and/or [] printed paper will have a [] and [] functionality. Papers printed according to the OPR has no []. As [] has been performed, an uncertainty of [] applies to the limits of the [*] regions.

3.[*] time	[] when used in [] and a maximum of [] between pen []	Time from [] to capture of first [] image.	This requirement is [] to avoid [] at the beginning of a [*]


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		6 (11)

Author		Checked by and date	Approved by and date	Date
[*]


Name	Value	Definition	Comment
4. [*]	[*]	The [] positioning []	[] is a measure of the [] between the [] ink and the [] ink. The requirement is [] for [] and [*] graphics.

	[*]	The [] positioning [] after [*].	[*]

5. [*]	[*]	The quantity is defined as [] times the standard deviation of the [] from a pen [*]	The [] expresses the deviation of the [] ink from a [], for a pen held at [] that is [] relative to the paper. The [] relates to the [] of the camera [].

6. [*] margin	[] over all supported []	Closest distance to the [] of the Anoto pattern that coordinates can be [], regardless of [*].	If the [] is placed too close to the [] of the pattern, the [] may not [] a large enough [] to be able to [].

7. [] speed [] of	[*]	The [] speed of the pen relative to the []	The [] should handle a [] of the pen and/or the pattern target


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		7 (11)

Author		Checked by and date	Approved by and date	Date
[*]


Name	Value	Definition	Comment
target			While writing. The requirement [] writing and a []. Verification is done by [*].

8. [] speed – []	[] for [] and all [*]	The [] around the [] while the [] is fixed in the []	The [] should handle a [] of the pen [] while writing. The requirement is an [] writing and a []. Verification is done by [].
3 Definition of pen conditions
Name	Definition	Comment
1. [*] pens	Pens based on [*] design yield.	By assuming [] standard deviations for the [] specified on the [], the yield of the design, for the [], becomes [] for []. This simulation has [] in Fly PPS. The production yield will of course depend on many other factors, such as [] and [*].

2. [*] pen	All [] included in the [] are [*]	This is a pen where all components are []. Examples are []…


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		8 (11)

Author		Checked by and date	Approved by and date	Date
[*]

4	Definition of usage conditions

These set of conditions define in what external usage conditions the positioning system should be used.

Those following conditions that are usage dependent refer to these sets. All conditions refer to Min and Max and typical off course refer to Typical.

Table 4-1. Usage conditions requirements


Name	Min	Max	Typical	Definition	Comment
1. [*] speed	[*]	[*]	[*]	—	The [] speed is based on []of a group of [*], see [5]

2. [*] on paper	[*]	[*]	[*]	The requirement applies for light with the spectral profile of solar radiation on Earth at sea level.	In normal room [] conditions, the [] is approximately [] Test setup is described in [4]. [] improves the functionality and is [*]

3. [*] in use	[*]	[*]	[*]	IEC ▇▇▇▇▇-▇-▇, test Bd and IEC ▇▇▇▇▇-▇-▇, test Ad	Elevated [] increases the []. No environmental tests have been performed to verify [] in use for [].

4. Printed Anoto pattern	Defined in [] [2] but with [].	Defined in [] [2] but with []	Printing guidelines	See printing guidelines in Printing Requirement where applicable	[] requirements are the same as for regular Anoto pattern – print specification according to the [] but with [*]

5. [*] compatibility	[*] designed according to [1].	[*] designed according to [1].	[*] designed according to [1].	—	For [] according to [] or in other ways approved by Anoto see ref. [3]


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		9 (11)

Author		Checked by and date	Approved by and date	Date
[*]

5	Sensitivity analysis

Sensitivity analysis shows how sensitive the system is to changes in different variables. These could be both pen variables and usage conditions.

The sensitivity is presented as [*] as function of [*]. The performance at [*] can be estimated from this data.

The diagrams will [*] but will indicated how [*] a certain variable [*] the system. [*] used in the analysis are agreed upon with Leapfrog. The method for determining [*] are described in the [*]

5.1

[*]

[*] is the [*] in relation to its nominal position. Components affecting [*] are such are [*] and other components affecting dimensions [*]. The impact on performance is similar compared to [*].

Two different [*] are defined.

•

[*] estimation: Based on [*] calculations.

•

[*] tolerances at [*]

[*]

Fig 4.1. [*]. The horizontal axis shows [*]and the vertical axis shows [*]. The yellow line describes the [*] estimation of [*] variation and the white dotted line describes the [*] for [*] angles


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		10 (11)

Author		Checked by and date	Approved by and date	Date
[*]

5.2

[*]

5.3

[*]

5.4

[*]

5.5

[*]

5.6

[*]

5.7

[*]

5.8

[*]

5.8.1

[*]

5.8.2

[*]

6	Reference

[1]

[*]

[2]

[*]

[3]

[*]

[4]

[*]

[5]

[*]


*[]**


Document ID	Revision	Title		Page (Pages)
DS	UA1	Fly PPS Design Specification		11 (11)

Author		Checked by and date	Approved by and date	Date
[*]

APPENDIX A: PEN ORIENTATION RELATIVE TO THE PAPER

The following parameters, as illustrated in 0, uniquely define the orientation of the [*] relative to the paper:

•

[*] is the angle between the [*] of the paper and the [*].

•

[*] is [*] around the [*]. [*] where the pen [*] is [*] to the paper.

•

[*] is [*] around its [*]. [*] where the [*] onto the paper [*] is aligned with [*]

A negative [*] with [*] corresponds to a positive [*] with [*]

[*]

Figure B-1. Parameters used to define the orientation of the pen relative to the paper.


Name	Value	Definition	Comment
1. Pen positioning for a [] pen under [] conditions	[*]	The percentage [] in a series of [] must be [] in the [] region.	The pen positioning [] in combination with the [] determines how well pen [] are reproduced in the [].

2. Pen positioning for [] pens under [] conditions	[*]	The maximum number of [] that [] must be (Illegible). The system should be [] in a [] position.	[] indicates a region where the [] from the [] the images [] (see [] Definitions) [] and/or [] printed paper will have a [] and [] functionality. Papers printed according to the OPR has no []. As [] has been performed, an uncertainty of [] applies to the limits of the [*] regions.

3.[*] time	[] when used in [] and a maximum of [] between pen []	Time from [] to capture of first [] image.	This requirement is [] to avoid [] at the beginning of a [*]

AMENDMENT NO. 2 TO TECHNOLOGY LICENSE AGREEMENT

Document Metadata

Document Metadata

Table of Contents