Ex Parte Abraham et al

Patent Trial and Appeal Board

Jun 22, 2018

14089147 (P.T.A.B. Jun. 22, 2018)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
14/089,147 11125/2013 Sunil George Abraham
54698 7590 06/26/2018
MOSER TABOADA
1030 BROAD STREET
SUITE 203
SHREWSBURY, NJ 07702
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www .uspto.gov
ATTORNEY DOCKET NO. CONFIRMATION NO.
IFR1016 6981
EXAMINER
KLICOS, NICHOLAS GEORGE
ART UNIT PAPER NUMBER
2142
NOTIFICATION DATE DELIVERY MODE
06/26/2018 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
docketing@mtiplaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte SUNIL GEORGE ABRAHAM, J. AMBROSE LITTLE,
SANTIAGO AGUIAR, NICOLAS CASTAGNET,
DIEGO RIVERO, and MARTIN SILVA 1
Appeal 2017-011460
Application 14/089, 14 7
Technology Center 2100
Before ROBERT E. NAPPI, ST. JOHN COURTENAY III, and CARLL.
SILVERMAN, Administrative Patent Judges.
NAPPI, Administrative Patent Judge.
DECISION ON APPEAL
This is a decision on appeal under 35 U.S.C. § 134(a) from the
Examiner's final rejection of claims 1 through 20. We have jurisdiction over
the pending claims under 35 U.S.C. § 6(b ).
We AFFIRM-IN-PART.
1 According to Appellants, the real party in interest is Infragistics, Inc. App.
Br. 4.
Appeal 2017-011460
Application 14/089,147
INVENTION
Appellants' disclosed invention is directed to generating a user
interface prototype and generating a visual depiction of the interaction
hierarchy of the user interface prototype. Abstract. Claim 1 is
representative of the invention and reproduced below.
1. A method for generating an interactions explorer for a
user interface prototype comprising:
defining and displaying on a display, for a user interface
(UI) in a user interface prototype, a screen flow comprising one
or more screens, the flow representing branches in the UI
prototype;
detecting one or more prototyping actions while a user
creates the user interface prototype, wherein the one or more
prototyping actions are related to screen flow in the user
interface prototype;
adding the one or more prototyping actions to an
interaction hierarchy that outlines the screen flow of the U I
prototype; and
automatically generating and displaying in a portion of
the display, in response to adding the one or more prototyping
actions to the interaction hierarchy, an interactive visual
depiction of the interaction hierarchy.
REJECTIONS AT ISSUE2
The Examiner has rejected claims 1 through 10 and 12 through 20
under 35 U.S.C. § 103(a) as being unpatentable over Sawahata (US
6,055,369, issued April 25, 2000) and Faithe Wempen ("Microsoft
2 Throughout this Decision we refer to the Appeal Brief ("App. Br.") filed
May 1, 2017, ReplyBrief("ReplyBr.") filed September 13, 2017, Final
Office Action ("Final Act.") mailed December 1, 2016, and the Examiner's
Answer ("Answer") mailed July 13, 2017.
2
Appeal 2017-011460
Application 14/089,147
PowerPoint 2010 Bible," Wiley Publishing, Inc., 2010). Answer 2, Final
Act. 5-13.
The Examiner has rejected claim 11under35 U.S.C. § 103(a) as
being unpatentable over Sawahata, Wempen, and Rabin (US 2015/0148138
Al, published May 28, 2015). Answer 2, Final Act. 13.
ISSUES
With respect to the Examiner's rejection of independent claim 1,
Appellants' arguments on pages 8 through 13, 20, and 21 of the Appeal
Brief present us with the following issues:
a) Did the Examiner err in finding the combination of
Sawahata and W empen teaches generating and displaying
an interactive visual depiction of the interaction hierarchy?
b) Did the Examiner err in finding that a skilled artisan would
combine teachings of Sawahata and Wempen?
c) Did the Examiner err in finding the combination of
Sawahata and Wempen teaches a screen flow?
d) Did the Examiner err in interpreting the claim term
"prototype" as including a visual component of an
interactive display screen which has includes the
implementation of the programing behind the interactions?
With respect to the Examiner's rejections of claims 2, 5, 7, 10, and 11,
Appellants' arguments present us with additional issues, which we address
in the analysis section.
3
Appeal 2017-011460
Application 14/089,147
ANALYSIS
We have reviewed Appellants' arguments in the Appeal Brief, the
Examiner's rejections, and the Examiner's response to Appellants'
arguments. Appellants' arguments have not persuaded us of error in the
Examiner's rejections of claims 1through6, 8 through 10, 12 through 18,
and 20 under 35 U.S.C. § 103, however, we are persuaded of error in the
Examiner's rejection of claims 7, 11, and 19 under 35 U.S.C. § 103.
Claim 1
Appellants' arguments directed to the first issue on pages 9 through
11 of the Appeal Brief, assert that Sawahata combined with Wempen does
not teach automatically generating an interactive visual depiction of a
interaction hierarchy which represents branches in a user interface prototype.
Appellants argue the Examiner admits that Sawahata does not teach this
feature and that W empen, which the Examiner relies upon to teach this
feature does not. App. Br. 9--10. Specifically, Appellants argue that
W empen teaches using PowerPoint® to prepare simple presentations of
sequential slides where, when a slide is updated, a smaller slide in a display
of the slides in order is updated. App. Br. 10. Appellants argue this
teaching of W empen is not a visual depiction of an interaction hierarchy
which represents branches in the UI prototype and that this teaching does not
make obvious such a visual depiction. App. Br. 10-11.
The Examiner responds to Appellants' arguments stating:
Sawahata was cited to show the hierarchy itself as well as the
creating and editing of screenflows when prototyping a user
interface. See Sawahata Figs. 4-8 and cols. 6:38-58 and 8:37-
48. Wempen was solely cited to show that screens are
automatically added. In Wempen, or POWERPOINT®, a user
4
Appeal 2017-011460
Application 14/089,147
creates a slide and that creation automatically adds the slide to
the outline. See Wempen pp. 89-90 and Fig. 4-1.
Answer 3.
We are not persuaded of error by the Appellants' arguments
directed to the first issue. Appellants' arguments are premised upon
W empen not teaching an interaction hierarchy which represents
branching. However, the Examiner finds and we concur that this is
taught in Sawahata's Figures 4---6. The Examiner's reliance upon
W empen is merely to show that it is known to automatically update a
display depicting a progression of screens/slides. See Answer 3, Final
Act. 6. Thus, Appellants' arguments directed to the first issue do not
address the findings upon which the Examiner's rejection is based.
Accordingly, the arguments directed to the first issue have not
persuaded us of error in the Examiner's rejection of claim 1.
Appellants' arguments directed to the second issue on pages 11
through 12 of the Appeal Brief, assert that the Examiner's rationale to
combine Sawahata and Wempen is insufficient. Appellants argue that
since Wempen only discusses how to manipulate PowerPoint® slides
and applying the teaching to modeling a UI prototype would be an
"exercise in complete frustration, as the inputs and outputs from
screens in UI prototypes are consistently branching." App. Br. 11.
In response, the Examiner states
the user is prototyping and creating the screen flow in
Sawahata, and W empen is simply used to show that screens can
be automatically added to the screenflow of Wempen.
Additionally, nothing in Wempen would discourage the
combination and Examiner clearly stated how the references are
5
Appeal 2017-011460
Application 14/089,147
similar and would thus be combinable, as well as to show an
improvement that Wempen brings to Sawahata.
Furthermore, a standalone slideshow of Wempen can be
considered an application itself, and the creation of slides is the
creation of screens for that application. Therefore, both
Sawahata and W empen both describe the creation of
applications based on interactions and visually depicting the
interactions. The smaller slide preview of Wempen can also be
construed as a hierarchy because it shows which slide follows,
or is a child of, another slide.
Answer4.
We concur with the Examiner. As with the first issue discussed
above, Appellants' arguments are premised upon the assertion that the
Examiner is relying upon W empen to teach an interaction hierarchy,
when the Examiner is relying upon Sawahata to teach the interaction
hierarchy. Thus, Appellants' arguments directed to the second issue
have not persuaded us of error in the Examiner's rejection of claim 1.
Appellants' arguments directed to the third issue on pages 12
through 13 of the Appeal Brief, assert that the combination of
Sawahata and Wempen do not teach a screen flow. Appellants argue
in Sawahata, the visual program is incomplete without the source code
portion, and that the program is only displayed once all of the portions
of the visual program are complete. App. Br. 12. Appellants argue:
However, the innovative aspect of Appellants' claim 1 is that
the UI prototype can be created without any code generation or
manual code insertion for each screen, thus allowing for quick
creation and review of the screen flow prior to writing any code
to avoid lost time spent exploring unintuitive designs.
App. Br. 12. Further, Appellants argue that Figure 4 of Sawahata is
showing complete code and not a UI prototype. App. Br. 13.
6
Appeal 2017-011460
Application 14/089,147
The Examiner provides a comprehensive response to
Appellants' arguments on pages 4 and 5 of the Answer. We have
reviewed the Examiner's response and concur. Appellants' arguments
are based upon an asserted difference between the level of
completeness of the screens in the flow of the generated interface of
Sawahata and in Appellants' claimed prototypes. As discussed infra,
with respect to the fourth issue, we do not find the claim to define a
distinction. Accordingly, Appellants' arguments directed to the third
issue have not persuaded us of error in the Examiner's rejection of
claim 1.
Appellants' arguments directed to the fourth issue on pages 20
through 21 of the Appeal Brief, assert the Examiner erred in
interpreting the claim term "prototype" as including a visual
component of an interactive display screen which includes the
implementation of the programing behind the interactions. Appellants
assert that in light of the Specification it is clear that "no
implementation of the programming behind each interaction is
contained in the prototype." App. Br. 21 (citing para. 16 of
Appellants' Specification). Appellants assert this is different from the
art applied in Sawahata, Wempen, and Rabin. App. Br. 21.
The Examiner, in response to Appellants' arguments states that
the Specification does not define the term "prototype" and that the
discussion of prototypes merely provide examples. Answer 9.
Further, the Examiner finds that even though Sawahata involves
programing, the reference does not identify the programming is final
and as such is reasonably interpreted as a prototype for making code.
7
Appeal 2017-011460
Application 14/089,147
Answer 9. Additionally, the Examiner finds that Wempen allows for
users to outline the slides, which is also a prototype. Answer 10.
We concur with the Examiner and consider the Appellants'
proffered interpretation as incorporating limitations from the
Specification. Paragraph 16 of Appellants' Specification discusses a
prototype which allows a user to navigate branches and the flow from
screen without implementing the programming behind the interaction.
Paragraph 16 of Appellants' Specification, also identifies that the
prototype can include screens, with buttons, images, and video
streams; further the user adds objects, interactions between objects.
Additionally, paragraph 18, discusses the prototype as a rough draft of
the software application in terms of layout and interactions. Thus, we
concur with the Examiner that the Specification does not define the
term "prototype" and is not limited to "no implementation of the
programming behind each interaction is contained in the prototype" as
argued by Appellants. Further, to interpret the limitation in this
manner is contrary to Appellants' Specification which discusses the
"prototype" includes the interactions of the objects which is a form of
programming. (Paragraph 16 of Appellants'). As such, Appellants'
arguments directed to the fourth issue have not persuaded us of error
in the Examiner's rejection of claim 1.
We note that Appellants, on pages 2 through 6 of the Reply
Brief, additionally assert the Examiner's rational for combining the
references is improper as the references are non-analogous art. We
have not considered this arguments as it is waived. Appellants have
not shown good cause as to why these arguments could not have be
8
Appeal 2017-011460
Application 14/089,147
presented earlier. 3 As such, these arguments have not been
considered, and are waived. 37 C.F.R. § 41.41(b)(2).
For the above reasons, the Appellants' arguments have not
persuaded us of error in the rejection of claim 1. Appellants have not
separately argued claims 3, 4, 6, 8, 9, 12 through 18, and 20.
Accordingly, we sustain the Examiner's rejection of claims 1, 3, 4, 6,
8, 9, 12 through 18, and 20.
Claim 2
Appellants argue the Examiner's rejection of claim 2 is in error
as the combination of Sawahata and Wempen does not teach
generating in the interactive visual depiction, a flow for each path
through the user interface. App. Br. 13. Appellants argue the cited
portions of "Sawahata fail to disclose [] that a flow is generated for
each path through the user interface prototype in the interactive visual
depiction and not within the screen editing window 41." App. Br. 13,
see also Reply Br. 6.
The Examiner finds that claim 2, recites the "flow" is claimed
broadly, and in Sawahata, the visual depiction is a screenflow, which
meets the claimed flow. Answer 5.
We are not persuaded of error by Appellants' arguments.
Claim 2 does not recite a screen-editing window and does not identify
that display of flow representing branches in the UI prototype is in a
different display from the underactive visual depiction. Thus,
3 Appellants state on page 3 of the Reply Brief, that is was presented on page
10 of the Appeal Brief, however, no such argument was made on page 10 of
the Appeal Brief.
9
Appeal 2017-011460
Application 14/089,147
Appellants' arguments are not in commensurate with the scope of
claim 2 and, as such, are not persuasive. Accordingly, we sustain the
Examiner's rejection of claim 2.
Claim 5
Appellants argue the Examiner's rejection of claim 5 is in error
as the combination of Sawahata and Wempen does not teach depicting
screens which have already been depicted in other flows as labels.
App. Br. 13; Reply Br. 6-7. Appellants' arguments make a
comparison of Appellants' Figure 6, which depicts that repeated
screens which are merely displayed as with labels and Sawahata's
Figure 4 where the entire process for screens already depicted is
displayed. App. Br. 15.
The Examiner, in response to Appellants' arguments, finds that
the claims do not recite removing previous displayed items, just that
labels are introduced. Answer 6. Further, the Examiner finds that
Sawahata teaches using labels where portions of screen flow can be
reused and different labels being used for different screen flow.
Answer 6 (citing Sawahata Figs. 4--8, and col. 7, 11. 26-45, col. 8, 11.
64--67, col. 9, 11. 1-9, and col. 12, 11. 56-65), see also Final. Act. 7.
We concur with the Examiner that claim 5 only discusses
introducing labels and does not discuss removing previously displayed
items. Thus, Appellants' arguments, which imply that the claim is
limited to showing only labels for previously displayed items, are not
in commensurate with the scope of the claims. The cited passages in
cols. 7, 8, and 9, discuss links between nodes and nodes being
identified labels such as "PROCESS 1" when creating the links.
10
Appeal 2017-011460
Application 14/089,147
Further, the cited passage in column 12 discusses copying and pasting
portions of the screen flow shown in Figure 7. The cited passage in
column 12, does not identify the labels as being used to depict
screens, Figure 7 depicts an entire portion of the screen flow being
copied including labels (e.g. "PROCESS 2") of links between screens.
As such, Figure 7 of Sawahata does depict screens, including their
linking nodes, which have already been used are depicted in other
flows as labels. Thus, Appellants' arguments have not persuaded us
of error in the Examiner's rejection, and we sustain the Examiner's
rejection of dependent claim 5 and claim 17, which recites similar
limitations.
Claims 7 and 19
Appellants argue the Examiner's rejection of claim 7 is in error
as the combination of Sawahata and Wempen does not teach that
when a change is made in a screen of the UI prototype, that change is
propagated to any screens which flow from that changed screen. App.
Br. 16. Appellants argue that in Sawahata, the source and copied
screen have no interaction with each other, as such the changes are not
propagated to the other screen.
The Examiner responds, stating the claim does not recite
automatically propagating the changes. Answer 7. Further, the
Examiner finds that "Saw[ a ]hata allows for changes to be made to
screen flow which update the table that controls the screens, which is
equivalent to propagating said changes. See Sawahata cols. 12:66-67
to 13:1-16." Answer 7.
11
Appeal 2017-011460
Application 14/089,147
Appellants' arguments have persuaded us of error in the
Examiner's rejection. While we concur with the Examiner that the
claim does not recite that the propagation is automatic, we nonetheless
do not find that the Examiner has presented sufficient evidence that
the changes in one screen are propagated to another which flows from
the screen selected to be edited. The teaching of changes to the screen
flow resulting in changes in the table that controls the screens does not
show that other screens have the changes propagated to them, rather it
just shows that the table which controls the flow is updated. See col.
4, 11. 3-5, col. 12, 11. 5-7. Accordingly, we do not sustain the
Examiner's rejection of dependent claim 7 and claim 19, which recites
a similar limitation.
Claim 10
Appellants argue the Examiner's rejection of claim 10 is in
error as the combination of Sawahata and W empen does not teach that
exporting the interactive visual depiction. Appellants argue that
exporting as disclosed by Wempen would print the slides sequentially
as not in the form of a branching flow. App. Br. 17.
The Examiner in response to Appellants' arguments states:
The claim language does not specify where the storyboard is
exported to. Printing, such as discussed in Wempen, is a very
obvious way to share the story board for exemplary use. A PDF
file, which is certainly an exported document, can show the
entire flow of the slideshow, or, as the combination suggests,
can simply print the screenflows of Sawahata.
Answer 7-8. We concur with the Examiner. Appellants' arguments
are premised upon Wempen's display showing sequential screens and
12
Appeal 2017-011460
Application 14/089,147
not the combination with Sawahata which depicts the branching
screens which the Examiner finds can be printed. Accordingly, we
are not persuaded of error in the Examiner's rejection of claim 10 and
sustain the Examiner's rejection.
Claim 11
Appellants argue the Examiner's rejection of claim 11 is in
error as the combination of Sawahata, W empen, and Rabin does not
teach arranging the interactive visual depiction depending upon time
of creation. App. Br. 18-19. Appellants argue that Rabin is directed
to generating a code execution timeline, and that merely identifying
that sorting chronologically does not teach depiction of screens
chronologically based upon time of creation. App. Br. 18.
The Examiner responds stating that Rabin enhances the user
experience by providing additional ways to view the data and that
Rabin shows that hierarchies can be sorted based on time of creation.
Answer 9 (see also Final Act. 13 (citing Rabin paras 21 and 26) ).
Appellants' arguments have persuaded us of error in the
Examiner's rejection. Dependent claim 11, recites arranging screens
in the interactive depiction depending upon their time of creation. As
Appellants point out, paragraphs 21 and 26 of Rabin, which are relied
upon by the Examiner, discuss sorting chronologically by execution of
the program instructions, (not when based upon creation). App. Br.
18; Reply Br. 8-9. Further, the Examiner has not identified that time
of creation of screens is data that is to be tracked or sorted by in
Sawahata or Wempen. Thus, Appellants have persuaded us of error,
as the Examiner has not identified sufficient evidence to demonstrate
13
Appeal 2017-011460
Application 14/089,147
that claim 11 feature is obvious over the cited art. Accordingly, we do
not sustain the Examiner's rejection of claim 11.
DECISION
We affirm the Examiner's rejections of claims 1 through 6, 8 through
10, 12 through 18, and 20 under 35 U.S.C. § 103.
We reverse the Examiner's rejections of claims 7, 11, and 19 under
35 U.S.C. § 103.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l )(iv).
AFFIRM-IN-PART
14