IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT
`
`Frankland, Richard et al.
`
`Examiner:
`
`
`Wang
`
`Cheung, Mary Da Zhi
`
`
`
`Art Unit: 3694
`
`March 1, 2001
`
` Appellant:
`
`
`
` Serial No.:_ 09/797,488
` Filed:
`
`$/QM./€\)§I€&\}
`
`
`
`
` Our Ref: B-5746CONT 952776-6
` Date:
`
`
`
` For:
`
`”INTEGRATED CHANGE
`
`MANAGEMENT SYSTEM”
`
`August 28, 2007
`
` Re:
`
`Appeal to the Board ofAppeals
`BRIEF ON APPEAL
`
`Mail Stop Appeal-Patents
`Commissioner for Patents
`
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`Sir:
`
`This is an appeal from the Final rejection, dated February 28, 2007, for the
`
`above identified patent application. A credit card deposit in the amount of
`
`$500.00 for the fee set forth in 37 C.F.R. 1.17(c) for submitting this Brief and a
`
`credit card deposit in the amount of $120.00 for the time-extension fee set forth in
`
`37 C.F.R. 1.17(a)(1) will be electronically submitted. The Appellants submit that
`
`this Appeal Brief is being timely filed within the one-month extended time limit,
`
`since the Notice Of Appeal was received on May 29, 2007.
`
`REAL PARTY IN INTEREST
`
`The present application has been assigned to Alternative Systems, Inc. of
`
`Half Moon Bay, CA.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 2
`
`RELATED APPEALS AND INTERFERENCES
`
`There are no other appeals or interferences related to the present
`
`application.
`
`STATUS OF CLAIMS
`
`The present Application comprises claims 2, 4-9, 11-24, 26-31, 33-46, 48-52
`
`and 54-66, which all stand rejected.
`
`Claims 1, 3, 10, 25, 32, 47, 53 and 67-155 were cancelled without prejudice.
`
`Claims 2, 4-9, 11-24, 26-31, 33-46, 48-52 and 54-66 are the subject of this
`
`appeal and are reproduced in the accompanying claim appendix.
`
`STATUS OF AMENDMENTS
`
`There are no amendments pending in the present application.
`
`SUMMARY OF CLAIMED SUBJECT MATTER
`
`The invention described and claimed in the present application relates
`
`generally to the integrated management of information affected by regulatory
`
`changes as well as non-regulatory changes. Regulatory changes include changes
`
`in environmental, health and safety laws (page 1, lines 4-6; paragraph [OOO1]).
`
`A number of rules such as federal, state and local
`
`laws, statutes,
`
`ordinances and regulations control industrial and commercial activities (page 1,
`
`lines 8-10; paragraph [0002]). Some rules have overlapping jurisdiction and are
`
`not always consistent with one another. Further, the rules and related constraints
`
`are constantly changing (page 3, lines 2-9; paragraph [0OO4]). Various attempts
`
`have been made to manage regulatory compliance, but no satisfactory solution
`
`has been developed (page 12, lines 24-30; paragraph [0O25]). There is accordingly
`
`a need for a system that would, for a selected area of commercial or industrial
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 3
`
`activity: store or access all relevant available information and changes used in
`
`connection with the activity; generate and archive records of software system
`
`versions used for: data entry,
`
`reporting, processing, analysis and results
`
`presentation, and changes to these versions; generate all documents and reports
`
`required for compliance under applicable regulations, laws and statutes; and
`
`provide appropriate user
`
`interface, without requiring (re)programming of
`
`underlying software (page 13, lines16-30; paragraph [O027]).
`
`The invention meets the above needs with an integrated system that (1)
`
`provides one or more databases that contain information on operations and
`
`requirements concerning an activity or area of business;
`
`(2) monitors and
`
`evaluates the relevance of information on regulatory and non-regulatory changes
`
`that affect operations of
`
`the business and/or
`
`information management
`
`requirements; (3) converts the relevant changes into changes in work/task lists,
`
`data entry forms,
`
`reports, data processing, analysis and presentation (by
`
`printing, electronic display, network distribution and/or physical distribution) of
`
`data processing and analysis results to selected recipients without requiring the
`
`services of one or more programmers to re-program and/or recode the software
`
`items affected by the change; and (4) implements receipt of change information
`
`and dissemination of data processing and analysis results using the facilities of a
`
`network, such as the Internet (page 14, lines 2-14; paragraph [OO28]).
`
`In particular,
`
`independent claim 2 recites: ”A system for providing a
`
`dynamically generated application having one or more functions and one or more user
`
`interface elements; comprising:
`
`a server computer (for example as in a multi-tier server based model, see
`
`page 20, lines 14-15; paragraph [OO50]);
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 4
`
`one or more client computers connected to the server computer over a computer
`
`network (for example as in a multi—tier server based model, see page 20, lines 14-
`
`15; paragraph [0050]);
`
`a first layer (for example a business content layer, see page 21, lines 1-11;
`
`paragraph [OO54]) associated with the server computer containing information about
`
`the unique aspects of a particular application;
`
`a second layer (for example a metadata layer, see page 21, lines 13-20)
`
`associated with the server computer containing information about the user interface and
`
`functions common to a variety of applications, a particular application being generated
`
`based on the data in both the first and second layers;
`
`a third layer (for example a Java data management layer, see page 24, lines
`
`23-26; paragraph [OO69]) associated with the server computer that retrieves the data in
`
`the first and second layers in order to generate the functionality and user interface
`
`elements of the application; and
`
`a change management
`
`layer (page 28,
`
`lines 4-16; paragraph [OO85]) for
`
`automatically detecting (box 21 in Fig. 2) changes that afiect an application,
`
`each client computer further comprising a browser application (page 26, lines 3-
`
`6; paragraph [0075]) being executed by each client computer, wherein a user interface
`
`and functionality for the particular application is distributed to the browser application
`
`and dynamically generated when the client computer connects to the server computer
`
`(page 26, lines 19-22; paragraph [0078]).
`
`Also, independent claim 24 recites:
`
`”A method for dynamically generating an application using a server computer and one or
`
`more client computers connected to the server computer over a computer network (for
`
`example as in a multi-tier server based model, see page 20, lines 14-15; paragraph
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 5
`
`[O050]), the method comprising:
`
`providing a first layer (for example a business content layer, see page 21,
`
`lines 1-11; paragraph [0054]) containing information about the unique aspects of a
`
`particular application;
`
`providing a second layer (for example a metadata layer, see page 21, lines 13-
`
`20) containing information about the user interface and functions common to a variety of
`
`applications, wherein a particular application is generated based on the data in the first
`
`and second layers;
`
`establishing a connection between a client computer and the server computer (see
`
`page 20, lines 14-15; paragraph [O050]);
`
`providing a third layer (for example a Iava data management layer, see page
`
`24, lines 23-26; paragraph [O069]) that retrieves the data in the first and second layers
`
`in order to generate the functionality and user interface for a particular application for
`
`the client computer as the client computer connects to the server computer;
`
`automatically detecting (box 21 in Fig. 2) changes that afiect a particular
`
`application (page 28, lines 4-6; paragraph [0O85]); and
`
`distributing the user interface and functionality of the particular application to
`
`the client computer wherein the particular application and its user interface are
`
`dynamically re—generated each time a client establishes a connection with the server
`
`computer (page 26, lines 19-22; paragraph [OO78])”.
`
`Further, independent claim 46 recites:
`
`”A server for dynamically generating an application for one or more client
`
`computers connected to the server computer by a computer network (for example as in
`
`a multi-tier server based model, see page 20, lines 14-15; paragraph [O050]),
`
`comprising:
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 6
`
`a first layer (for example a business content layer, see page 21, lines 1-11;
`
`paragraph [OO54]) associated with the server containing information about the unique
`
`aspects of a particular application;
`
`a second layer (for example a metadata layer, see page 21, lines 13-20)
`
`associated with the server containing information about the user interface and functions
`
`common to a variety of applications;
`
`a third layer (for example a Java data management layer, see page 24, lines
`
`23-26; paragraph [OO69]) that retrieves the data in the first and second layers in order to
`
`generate functionality and user interface elements of the application;
`
`a change management
`
`layer (page 28,
`
`lines 4-16; paragraph [O085]) for
`
`automatically detecting (box 21 in Fig. 2) changes that afiect an application;
`
`means for dynamically generating (page 26, lines 19-22; paragraph [OO78]) a
`
`particular application based on the first and second layers each time a client computer
`
`connects to the server computer; and
`means for distributing the user interface and functionality of the particular
`
`application to a client computer (page 26, lines 3-6; paragraph [O075])”.
`
`>l->(->l-
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 7
`
`GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL
`
`Issue 1: Whether claims 2, 4-9, 11-24, 26-31, 33-46, 48-52 and 54-66 are
`
`patentable under 35 U.S.C. 102(e) over U.S. Pat. No. 5,960,200 to Eager.
`
`ARGUMENT
`
`Issue I: Whether claims 2, 4-9, 11-24, 26-31, 33-46, 48-52 and 54-66 are patentable
`
`under 35 U.S.C. 102(e) over U.S. Pat. No. 5,960,200 to Eager (hereinafter
`
`”Eager”).
`
`Rejection of claim 2
`
`In a non-final action issued on September 5, 2006, the Examiner rejected
`
`claim 2 as being anticipated by U.S. 5,960,200 to Eager, under the rationale that:
`
`-a business process layer taught by Eager reads on the first layer recited in
`
`claim 2;
`
`-a functionality layer taught by Eager reads on the second layer recited in
`
`claim 2;
`
`-a presentation layer taught by Eager reads on the third layer recited in
`
`claim 2; and
`
`-a
`
`re-architecting system taught by Eager
`
`reads on the change
`
`management layer recited in claim 2.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 8
`
`In response to this previous action, the Appellants disagreed with the
`
`rationale of the Examiner, and argued that the business process layer (120) and
`
`functionality layer (130) of Eager are distinct from a data storage layer (150), so
`
`that
`
`they cannot read on the recited first and second layers ”containing
`
`information”.
`
`In the Final action issued on February 28, 2006, the Examiner opines that
`
`the arguments above are not persuasive.
`
`In particular, in response to the Appellant's arguments that Eager fails to
`
`teach the first layer containing information about the unique aspects of particular
`
`application, the Examiner opines that ”Eager teaches a business process layer
`
`that corresponds to the first layer as claimed by the applicant (column 10, lines
`
`33-41 and Fig. 1), and the business layer provides initial application menu or
`
`screen and initial objects to the interface engine (column 10, lines 38-41), in which
`
`the initial application menu or screen and initial objects correspond to the
`
`information contained in the first
`
`layer”. The Examiner also opines that
`
`”although Eager does not explicitly disclose how long the information is
`
`contained in the business layer, the information could either be stored in the
`
`business layer in short period of time or in a long period of time; and in either
`
`case, Eager’s teaching reads on the claimed language”.
`
`Also, in response to the Appellant's arguments that Eager fails to teach a
`
`second layer that contains information about the user interface and functions
`
`common to a variety of applications, the Examiner opines that ”Eager teaches a
`
`functionality layer that corresponds to the second layer (column 12, lines 12-42
`
`and Figs. 1, 8) and the information contained by the second layer is taught by
`
`Eager as the result information is generated by the functionality layer and later is
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 9
`
`transferred to the business layer or the state router (column 12, lines 18-21)”. The
`
`Examiner further opines that ”although Eager does not explicitly disclose how
`
`long the result information is contained in the functionality layer, the result
`
`information could either be stored in the functionality layer in short period of
`
`time or in a long period of time; and in either case, Eager’s teachings reads on the
`
`claimed language”.
`
`The Appellants respectfully submit that the interpretation the Examiner
`
`makes of
`
`the term ”containing” is broader than the ‘broadest reasonable
`
`interpretation‘ that one skilled in the art would make in light of the specification.
`
`Indeed, according to this interpretation, any single means through which data
`
`transit would read on means ”containing” the data. Thus, for example a data bus
`
`would be considered as means containing data. However, one skilled in the art
`
`knows well that a data bus is a means that carries data, but does not contain data.
`
`At least in View of the above, the Appellants submit that the interpretation
`
`the Examiner makes of Eager does not comply with section 2111.01(II) of the
`
`M.P.E.P, and request that the Examiner's rejection of claim 2 be overturned.
`
`The Appellants further note that, even assuming, arguendo,
`
`that
`
`the
`
`interpretation the Examiner makes of the term ”containing” were not broader
`
`than its broadest reasonable interpretation, Eager would still be very different
`
`from the invention as recited in claim 2.
`
`Eager relates (see claim 1 of Eager) to an automated system for converting,
`
`or transitioning, legacy applications operable on a legacy computing system to a
`
`distributed infrastructure on a multi-tiered computer architecture. Eager
`
`provides,
`
`in particular,
`
`for ”an automated converter
`
`to transition the legacy
`
`application to a target application operable on the multi-tiered computer architecture”.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 10
`
`However, Eager teaches automatically converting an application operable
`
`in a legacy system to an application operable in a multi—tiered system. Nowhere
`
`does Eager disclose or suggest any feature for monitoring applications and
`
`detecting changes affecting the application, and in particular a change
`
`management layer for ”automatically detecting changes that aflect an application” as
`
`recited in claim 2.
`
`In section 4 of the Final action of February 28, 2007, the Examiner opines
`
`that Eager shows ”f) a change management layer for automatically detecting
`
`changes that affect an application (column 2, lines 34-57 and column 4, lines 42-
`
`51 and Figs. 1, 16, 17, 24; specifically, ‘change management layer’ corresponding
`
`to re-architecting system in Eager’s teaching)”. The Appellants respectfully
`
`disagree.
`
`As to what is taught in column 2, lines 34-57 of Eager: the Appellants note
`
`that column 2, lines 34-57 of Eager recite that ’’For each source application, there is a
`
`range of available transition choices,
`
`including the option of translating the source
`
`application to the new target architecture without changing any of the existing
`
`functionality and the option of re-engineering the source application by changing the
`
`existing functionality. The source application may also be replaceable by a commercial
`
`product or a custom application written in—house. The source applications are then
`
`transitioned in order of priority to the new architecture”.
`
`This passage teaches that Eager allows translating source applications to
`
`the new target architecture without changing the existing functionality. It also
`
`teaches that Eager allows re-engineering the source application by changing the
`
`existing functionality.
`
`However,
`
`this passage does not relate to detecting changes in the
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 11
`
`applications, and relates even less to automatically detecting such changes.
`
`Column 2, lines 34-57 of Eager further recites, ”Specifically, a preferred
`
`system in accordance with the present invention includes the automated capability to
`
`translate existing source applications into new target applications on a multi-tiered
`
`client/server architecture. The translation of source applications to target applications
`
`includes the conversion of user interfaces, procedural languages, and data definitions.
`
`These conversions use a two—phase process where source program components written in
`
`the source languages are first translated to components in a common intermediate
`
`language. The intermediate language components are then translated to target program
`
`components in the target languages. By using a common intermediate language, only one
`
`translation module is required for each source and target language”.
`
`This passage teaches that Eager allows automatically translating sources
`
`application.
`
`This passage does not relate to detecting changes in the applications, or to
`
`automatically detecting such changes.
`
`As to what is taught in Column 4, lines 42-51 of Eager: column 4, lines 42-
`
`51 recites that ”a preferred re—architecting system 20 includes a user
`
`interface
`
`conversion utility 210, a procedural
`
`language conversion utility 220, and a data
`
`definition language conversion utility 230. The procedural language conversion utility
`
`220 is in communication with the functionality layer 130 and the data access layer 140 of
`
`the multi—tier architecture 10. The user
`
`interface conversion utility 210 is
`
`in
`
`communication with the user interface repository 152 and the data definition language
`
`conversion utility 230 is in communication with the data record repository 158".
`
`This passage discloses a preferred structure of a re—architecting system of
`
`Eager, but does not disclose or suggest any feature that would allow
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 12
`
`”automatically detecting changes that afiect an application” as recited in claim 2.
`
`Further, the Appellants note that Eager discloses in column 6, lines 50-52,
`
`that ”the re—architect option translates the existing application to the new architecture
`
`without chanin any of the existing functionality”, and thus explicitly and
`
`unambiguously discloses that the ”re—architecting” of Eager is not related to
`
`implementing (or detecting) any change that affects an application.
`
`As to what is taught in Figure 1 of Eager: Figure 1 of Eager shows a re-
`
`architecting system 20 comprising ”a user
`
`interface conversion utility 210, a
`
`procedural language conversion utility 220, and a data definition language conversion
`
`utility 230".
`
`The Appellants note that the Examiner has failed to show which of the
`
`features of system 20 would read on any feature that would allow ”automatically
`
`detecting changes that afi‘ect an application” as recited in claim 2. Further, as detailed
`
`above, Eager discloses that
`
`the system's ”re-architecting” is not related to
`
`handling changes in an application.
`
`As to what is taught in Figure 16 of Eager: Figure 16 of Eager is a block
`
`diagram of the user interface conversion utility 210 of Fig. 1, which ”converts the
`
`user ‘ interface of an existing application represented by the source user interface
`
`definitions 211 into target user interface definitions 213 using the user interface
`
`converter 212" (col. 23, lines 4-8).
`
`As detailed above, Fig. 1 of Eager relates to a re-architecting system,
`
`wherein such re-architecting is done ”without changing any of the existing
`
`functionality”. The Appellants note that the Examiner has failed to explain how a
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 13
`
`portion of a system provided for implementing an operation devoid of change
`
`would disclose or suggest means for detecting changes, and in particular means
`
`for ”automatically detecting changes that ajfect an application” as recited in claim 2.
`
`As to what is taught in Figure 17 of Eager: Figure 17 of Eager is a flow
`
`diagram wherein ”the procedural
`
`language conversion utility 220 converts the
`
`functionality and data access ‘programs of an existing application into the programming
`
`language targeted for the implementation of the functionality layer 130 (Fig. 1). This
`
`conversion process consists of two main phases. A first phase (Phase A) converts the
`
`source language 221 into an intermediary language 225. A second phase (Phase B) then
`
`transforms the intermediary language 225 into the final target language 227" (col. 24,
`
`lines 45-53).
`
`The Appellants note that Figure 17 only relates to converting a source
`
`application in a source language into a target application in a target language,
`
`and note that the Examiner has failed to show which part of the feature of figure
`
`17 would read on means for ”automatically detecting changes
`
`that afiect an
`
`application” as recited in claim 2.
`
`As to what is taught in Figure 24 of Eager: Figure 24 of Eager is a block
`
`diagram of the data definition language conversion utility 230 of Fig. 1 that is
`
`”used to convert a source database language 231 into a target database language 237
`
`using a database converter 234" (col. 28, lines 11-14).
`
`The Appellants note that Figure 24 only relates to converting a source
`
`language into a target language, and note that the Examiner has failed to show
`
`which part of the feature of figure 24 would read on means for ”automatically
`
`detecting changes that aflect an application” as recited in claim 2.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 14
`
`In addition to the above remarks,
`
`the Appellants note that the only
`
`mention of a change in an application is made in relation to GUI files 248, that
`
`are ”used by application developers and maintenance personnel to midzfy application
`
`screens and messages as part of the re—engineering system 30" (col. 23, line 66 — col. 24,
`
`line 1).
`
`The Appellants note that Eager teaches modifying applications in relation
`
`to Eager’s re—engineering system, and not Eager’s re-architecting system as
`
`opined by the Examiner.
`
`Further, the Appellants note that Eager explicitly teaches that in the re-
`
`engineering system, it is ”application developers and maintenance personnel” that
`
`”modzfy application screens and messages”, thus teaching away from any means that
`
`would operate ’’automatically’’, and in particular that would allow ”aatomatically
`
`detecting changes that afiect an application” as recited in claim 2.
`
`In conclusion,
`
`the Appellants note that Eager relates to means for
`
`automatically converting a source system into a target system, wherein:
`
`-a re-architecting option allows translating applications in the source
`
`system ”withoat changing any of the existing functionality” ; and
`
`-a re—engineering option allows ”application developers and maintenance
`
`personnel” to ’’modify application screens and messages”, as seen above in relation to
`
`Figure 16.
`
`Contrary to the Examiner's assertion, no part of Eager seems to disclose or
`
`suggest any such thing as means ”for automatically detecting changes that aflect an
`
`application” or ”a change management layer for automatically detecting changes that
`
`aflect an application” as recited in claim 2.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 15
`
`The Appellants note that when converting a source application into a
`
`target application, the converter of Eager parses (with parser 243) the language of
`
`the source application to convert
`
`it
`
`in a target application.
`
`If the source
`
`application has changed, one can assume that such change will be introduced in
`
`the target application. However, the Appellants note that there is no suggestion
`
`in Eager that the parsing of a source application having non-changed instruction
`
`as well as changed instructions would distinguish in any way the changed
`
`instructions from the non-changed instructions. Accordingly, parsing the source
`
`applications cannot be deemed to disclose or suggest ”detecting” changes that
`
`affect an application. For this reason also, Eager cannot be argued to disclose or
`
`suggest ”a change management layer for automatically detecting changes that aflect an
`
`application” as recited in claim 2.
`
`The Appellants respectfully submit that at least in View of the above,
`
`claim 2 is patentable over Eager, and respectfully request that the Examiner's
`
`rejection of claim 2 be properly overturned.
`
`Rejection of claims 24 and 46
`
`The Appellants respectfully submit that the arguments used above for
`
`showing that claim 2 is patentable over Eager can also be used to show that
`
`Eager does not disclose or suggest a method as recited in claim 24, and in
`
`particular comprising: ”automatically detecting changes
`
`that affect a particular
`
`application” or a server as recited in claim 46, and in particular comprising ”a
`
`change management layer for automatically detecting changes that aflect an application”.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 16
`
`The Appellants respectfully submit that at least in view of the above,
`
`claims 24 and 46 are patentable over Eager, and respectfully request that the
`
`Examiner's rejection of claims 24 and 46 be properly overturned.
`
`Rejection of claims 4-9, 11-23, 26-31, 33-45, 48-52 and 54-66
`
`Claims 4-9 and 11-23 depend directly or indirectly on claim 2; claims 26-31
`
`and 33-45 depend directly or indirectly on claim 2; and claims 48-52 and 54-66
`
`depend directly or indirectly on claim 46.
`
`Appellants note that ”if an independent claim is nonobvious under 35
`
`U.S.C. 103, then any claim depending therefrom is nonobvious.” In re Fine, 837
`
`F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988).
`
`The Appellants respectfully submit that at least in light of the above
`
`discussion, dependent claims 4-9, 11-23, 26-31, 33-45, 48-52 and 54-66 are also
`
`allowable.
`
`Further, as developed hereafter, the Appellants disagree with the specific
`
`rationale developed by the Examiner for rejecting the dependent claims.
`
`Rejection of claim 4
`
`In section 4 of the Final action of February 28, 2007, the Examiner opines
`
`that ”as to claim 4, Eager teaches the third layer further comprises a Java data
`
`management layer having means for distributing one or more ]AVA applets to
`
`the client computer wherein the JAVA applets dynamically generate and present
`
`the user interface and functionality to the user based on the first and second
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 17
`
`layers (column 8,
`
`lines 3-22 and column 10,
`
`lines 7-26)”. The Appellants
`
`respectfully disagree with the Examiner.
`
`Column 8, lines 3-22 of Eager recites that ”an Open Systems Integration
`
`(OSI) process 469 is a manual
`
`implementation process that focuses on integrating
`
`applications that are purchased, newly custom developed, re—architected, or re—engineered
`
`to share data and screens. This process includes the definition of business goals and
`
`objectives,
`
`the definition of applicable business processes,
`
`the study of application
`
`interactions and data relationships, and the planning of hardware and software
`
`infrastructures. The OSI process 469 also includes the implementation of the integration,
`
`including detailed implementation plan and schedule and detailed requirements and
`
`design documentation, user acceptance testing, comprehensive technical documentation,
`
`and empowerment of support stafi‘for the maintenance phase. One powerful example of
`
`integration at the user interface layer using the OSI process 469 is the creation of a
`
`corporate intranet using internet Hyper—Text Manipulation Language (HTML) or a
`
`highly—level language generating HTML, such as ]ava from Sun Microsystems to provide
`
`a user-friendly, platform independent, common user interface to corporate application”.
`
`The Appellants note that the above excerpt does not recite the words
`
`”]AVA applet”, and that the Examiner has failed to explain where the above
`
`excerpt would suggest using IAVA applets. It follows that the Examiner has also
`
`failed to explain where the above excerpt would suggest JAVA applets that
`
`”dynamically generate and present” ”user interface and functionality” to a user” based
`
`on first and second layers.
`
`Column 10, lines 7-26 of Eager recites that ”PIG. 5 is a schematic diagram of a
`
`sample mapping between application user interface representation structures 116 and
`
`display platform user interface representation structures 118. In the figure,
`
`the user
`
`interface display platform 115 is exemplified as Microsoft Windows 3.x and the display
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 18
`
`platform user interface representation structures 117 are thus the internal Windows 3.x
`
`management structures. However, other user interface display platforms 115 using
`
`similar internal structures to manage windows are supported by the exact same user
`
`interface engine 117. Notably, the Internet’s world-wide web, based on the HTML or
`
`Iava user interface languages, is another example of user interface display platform 115.
`
`Indeed, in a preferred embodiment of the present invention, the user interface engine 117
`
`is written using Microsoft Visual C++ and based on the industry—standard Microsoft
`
`Foundations Classes (MPC) class library, which allows cross—platform development for
`
`Windows 3.x, Windows 95, Windows NT, MacOS, and LINIX—based user interface
`
`display platforms 115, including internet web servers”.
`
`The Appellants note that the above excerpt does not recite the words
`
`”]AVA applet”, and that the Examiner has failed to explain where the above
`
`excerpt would suggest using JAVA applets. It follows that the Examiner has also
`
`failed to explain where the above excerpt would suggest JAVA applets that
`
`”dynamically generate and present” ”user interface and functionality” to a user” based
`
`on first and second layers.
`
`At least in view of the above, the Appellants respectfully submit that the
`
`Examiner has failed to show that Eager discloses or suggest the features recited
`
`in claim 4, and in particular ”data management
`
`layer having means for
`
`distributing one or more JAVA applets to the client computer wherein the JAVA
`
`applets dynamically generate and present the user interface and functionality to
`
`the user based on the first and second layers”.
`
`The Appellants respectfully submit that, for this reason also, claim 4 is
`
`patentable over Eager.
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 19
`
`Rejection of claims 26 and 48
`
`Claim 26 depends on claim 24 and recites features corresponding to the
`
`features of claim 4. Claim 48 depends on claim 46 and recites features
`
`corresponding to the features of claim 4.
`
`The Appellants note that the arguments used above to show that claim4 is
`
`patentable over Eager at least because Eager does not disclose or suggest ”]AVA
`
`applets” as recited in claim 4 can also be used to show that claims 26 and 48 are
`
`patentable over Eager.
`
`Rejection of claim 11
`
`In section 4 of the Final action of February 28, 2007, the Examiner opines
`
`that ”as to claims 11-12, Eager teaches the server computer further comprises the
`
`change management layer further comprises one or more intelligent agents that
`
`detects changes that affect an application (column 2, lines 34-57 and column 4,
`
`lines 42-51 and Figs. 1, 16, 17, 24; specifically, ‘change management layer’
`
`corresponding to re-architecting system in Eager’s teaching)”. The Appellants
`
`respectfully disagree.
`
`As detailed above, column 2, lines 34-57 of Eager recites that "For each
`
`source application, there is a range of available transition choices, including the option of
`
`translating the source application to the new target architecture without changing any of
`
`the existing functionality and the option of re—engineering the source application by
`
`changing the existing functionality. The source application may also be replaceable by a
`
`commercial product or a custom application written in-house. The source applications are
`
`then transitioned in order of priority to the new architecture".
`
`

`
`Application Serial No. 09/ 797,488
`Appeal brief
`Page 20
`
`This passage teaches that Eager allows translating sources application to
`
`the new target architecture without changing the existing functionality. It also
`
`teaches that Eager allows re-engineering the source application by changing the
`
`existing functionality.
`
`However,
`
`this passage does not