Ex Parte Huang et al

Patent Trial and Appeal Board

Mar 28, 2016

13466517 (P.T.A.B. Mar. 28, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
13/466,517 05/08/2012
35525 7590 03/30/2016
IBM CORP (YA)
C/O YEE & AS SOCIA TES PC
P.O. BOX 802333
DALLAS, TX 75380
FIRST NAMED INVENTOR
Shiling Huang
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.
AUS920070806US2 5882
EXAMINER
SHIN, KYUNG H
ART UNIT PAPER NUMBER
2443
NOTIFICATION DATE DELIVERY MODE
03/30/2016 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):
ptonotifs@yeeiplaw.com
mgamez@yeeiplaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte SHILING HUANG and SEAN MICHAEL SUNDBERG
Appeal2014-005673
Application 13/466,517
Technology Center 2400
Before JOHN A. JEFFERY, BRADLEY W. BAUMEISTER, and
DENISE M. POTHIER, Administrative Patent Judges.
BAUMEISTER, Administrative Patent Judge.
DECISION ON APPEAL
Appeal2014-005673
Application 13/466,517
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner's
rejection of claims 1-20: 1
Claims 1-20 stand rejected under 35 U.S.C. § 103(a) as unpatentable
over Silky (US 2006/0136593 Al; published June 22, 2006), Stienhans
(US 7,860,974 B2; patented Dec. 28, 2010) and Vishwanath
(US 2005/0149759 Al; published July 7, 2005). Ans. 3-11.
We have jurisdiction under 35 U.S.C. § 6(b). We review the appealed
rejections for error based upon the issues identified by Appellants, and in
light of the arguments and evidence produced thereon. Ex parte Frye,
94 USPQ2d 1072, 1075 (BPAI 2010) (precedential).
We affirm.
SUMMARY OF THE INVENTION
Appellants' invention manages Hypertext Transfer Protocol (HTTP)
session data. Spec. i-f 1. The World Wide Web uses HTTP to exchange web
pages. Id. i-f 3. HTTP is a stateless communication protocol. Id. As a
result, user-selected items on one web page could be lost if the user
navigates to another. Id. Session data, however, can be used to keep track
of related requests and responses between clients and web servers. Id. i-f 4.
Appellants' invention creates, stores, and retrieves this session data. Id. i-f 9.
1 Throughout this Opinion, we refer to (1) the Appeal Brief filed November
19, 2013 ("Br.") and (2) the Examiner's Answer mailed February 6, 2014
("Ans.").
2
Appeal2014-005673
Application 13/466,517
Independent claim 1 is illustrative:
1. A computer implemented method of managing sess10n
data, the computer implemented method comprising:
responsive to receiving a request for content, determining
whether preexisting session data associated with the request is
present;
responsive to the preexisting session data not being
present, generating session data associated with the request,
wherein the session data generated is in de-serialized format;
storing the session data associated with the request in a
session object;
generating a response page having a set of forms including
a set of hidden fields, wherein the set of hidden fields comprise
the session data serialized and security data; and
sending the response page to a client browser.
Appellants challenge the Examiner's rejection in relation to each
limitation of claim 1. We address each of these arguments separately.
ISSUE #1
Contentions
Claim 1 recites, in part, "responsive to receiving a request for content,
determining whether preexisting session data associated with the request is
present."
As noted above, the Examiner concludes that claim 1 would have
been obvious over Silky, Stienhans, and Vishwanath. Ans. 3-5. In the
proposed combination, the Examiner finds that Silky determines whether
preexisting session data is present. Id. at 3--4. According to the Examiner,
Silky's user interface (UI) version of the configuration and other session
information corresponds to the recited session data. Id. at 4, 12.
3
Appeal2014-005673
Application 13/466,517
In Appellants' view, Silky presumes the client sends all current
session data. Br. 15. Accordingly, Appellants argue that Silky has no need
to determine whether preexisting session data is present. Id.
Issue
Has the Examiner established by a preponderance of the evidence that
Silky teaches or suggest "responsive to receiving a request for content,
determining whether preexisting session data associated with the request is
present," as recited in claim 1?
Analysis
We are not persuaded that the Examiner erred in finding that Silky
teaches the limitation at issue (Ans. 3--4). Appellants' arguments apply to
Silky's session information in its entirety. See Br. 14--15. But the Examiner
interprets the recited session data as a subset of the entire session data-
Silky' s UI version. Ans. 12.
The Examiner's interpretation of "preexisting session data" (id.) is
reasonable in light of Appellants' Specification. In one of Appellants'
examples, "preexisting session data" is data generated in response to a user's
content request. See, e.g., Spec. i-f 59. This session data can have multiple
parts. See id. i-f 39 (describing that "set" means one or more and that session
data is stored in a "set of hidden fields"). So the Specification does not
preclude interpreting the recited "preexisting session data" as one of these
parts, or in other words, a subset of the entire session data.
Moreover, the claim does not state "all session data" or "session data
in its entirety." Instead, claim 1 broadly recites "preexisting session data."
4
Appeal2014-005673
Application 13/466,517
In light of the Specification and the term's context in the claim, the
recited "session data" can broadly, but reasonably, be construed as only a
subset of session data that is generated in response to a request.
Given this interpretation, we agree that Silky's UI version reasonably
can be interpreted as constituting "session data." Ans. 12. In particular,
Silky's user receives web pages from the server. Silky i-f 32. The user can
enter information into the page's fields. Id. i-f 35. The user sends the field
data as "post information" in a request to the server. Id. i-fi-132, 35; see also
id. Fig. 2, step 210. Optionally, the UI version is part of this post
information. See id. i-f 3 5. If the UI version is not, the server sets the UI
version to a default value. Id. i-f 35. Silky stores this default UI value in
hidden form fields throughout the session. Id. By storing this new default
value in hidden form fields, we agree that Silky generates new session data.
Accord Ans. 13. So like the disclosed session data (see, e.g., Spec. i-f 59),
Silky's UI version is generated (Silky i-f 35) in response to a prior request
(step 210) and maintained throughout the session (id. i-f 35).
Silky's UI version can be "preexisting" as recited. Specifically, in
response to receiving this post information, Silky's server sends the next
page including information in hidden form fields. Id. i-f 36 (engine 124
generates hidden form fields based on user picks). This hidden form field
includes the previously specified UI version. Id. i-f 35. And the entire
process repeats when the user enters information and sends another request.
Id. i-f 34; see also id. Fig. 2, step 208. So the hidden form information may
contain a UI version from the method's previous iteration-i.e., "preexisting
session data." See id. i-f 3 5.
5
Appeal2014-005673
Application 13/466,517
We also agree with the Examiner's finding (Ans. 13) that Silky makes
the recited determination. Specifically, Silky determines whether the UI
version is present in the request. See Silky i135. As discussed above, the UI
version can persist from a prior iteration of the process-i.e., preexist. See
id. i134. For example, the UI version may have been set to default in a
previous iteration. Id. i135. If so, this preexisting UI version is maintained
in the hidden form fields, then posted in subsequent iterations. Id. If not,
the UI version would be missing from the request's post information. Id.
Either way, Silky determines whether a preexisting UI version is in the
request's post information before proceeding. Id.
Accordingly, we are not convinced that the Examiner erred in finding
that Silky discloses the recited determining step.
ISSUE #2
Contentions
Claim 1 recites, in part, "responsive to the preexisting session data not
being present, generating session data associated with the request, wherein
the session data generated is in de-serialized format."
In the proposed combination under§ 103, the Examiner finds that
Silky generates session data associated with the request if the UI version is
not present, but does not do so in de-serialized format, as recited. Ans. 3-5.
In concluding the claim would have been obvious, the Examiner finds that
Stienhans in combination with Silky generates session data in de-serialized
format. Id. at 5 (citing Stienhaus 2:58---63, 7:52-56).
Appellants first argue that even if Silky' s UI version is missing, the
remainder of the post information contains session information in its
6
Appeal2014-005673
Application 13/466,517
entirety. Br. 15. So in Appellants' view, Silky lacks generating session data
responsive to preexisting data not being present. Id.
Appellants also argue that the combination lacks generating de-
serialized data. Id. at 16. According to Appellants, claim 1 calls for
generating data in de-serialized form, not de-serializing serialized data, as in
Stienhans. Id.
Issue
Has the Examiner established by a preponderance of the evidence that
Silky and Stienhans collectively taught or suggested "responsive to the
preexisting session data not being present, generating session data associated
with the request, wherein the session data generated is in de-serialized
format," as recited in claim 1?
Analysis
We are unpersuaded by Appellants' first argument against Silky
(Br. 15) because the other post information, apart from Silky's UI version, is
not germane to the Examiner's rationale (Ans. 3-5, 12). Specifically, the
Examiner maps only the UI version to the recited session data-a subset of
the total session data sent. Id. at 12. As discussed previously, nothing in the
claim precludes mapping a subset of session data to the recited session data.
Also, it is the absence of the UI version in the post information that
causes Silky to generate the default UI version. See Silky i-f 35. As
discussed above, Silky's server stores a default UI version in hidden form
fields if previous version does not exist. Id. By storing this new default
value in hidden form fields, Silky generates new session data generally.
See Ans. 13. The Examiner cites Stienhans as support for the conclusion
7
Appeal2014-005673
Application 13/466,517
that it would have been obvious to generate this data, specifically in
serialized format. Id. at 5.
Appellants' argument against Stienhans (Br. 16), however, amounts to
an individual attack that does not squarely address the Examiner's
combination (Ans. 3-5). Specifically, the Examiner finds that Silky
generates data when the UI version is not present. Id. at 4, 13. So the
Examiner cannot be proposing de-serializing a preexisting, serialized UI
version as argued. Therefore, Appellants' second argument (Br. 16)
amounts to an individual attack on Stienhans rather than considering the
collective teachings, as used by the Examiner.
Accordingly, we are not convinced that the Examiner erred in finding
that Silky generates session data, as recited.
ISSUE #3
Contentions
Claim 1 recites, in part, "storing the session data associated with the
request in a session object."
In the proposed combination under§ 103, the Examiner finds that
Silky stores session data in hidden form files in the web page's hidden
fields. Ans. 4. According to the Examiner, the web page's code storing the
hidden field corresponds to the recited session object. Id.
Appellants argue that Silky lacks the recited session object. Br. 16.
According to Appellants, the recited session object is a server object, not a
hidden field. Id. at 16-17.
8
Appeal2014-005673
Application 13/466,517
Issue
Has the Examiner established by a preponderance of the evidence that
Silky teaches or suggests "storing the session data associated with the
request in a session object," as recited in claim 1?
Analysis
We begin our analysis of this issue by construing the term "session
object." Appellants point to Figure 4 to show the session object is a server
object. Br. 16-17. But Figure 4 and its accompanying description do not
express a clear intent to deviate from the term's plain meaning. See Thorner
v. Sony Computer Ent. Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012) ("It
is not enough for a patentee to simply disclose a single embodiment or use a
word in the same manner in all embodiments, the patentee must clearly
express an intent to redefine the term.") (citations omitted) (internal
quotation marks omitted).
Specifically, Appellants' Specification states in this "illustrative
example in Figure 4," a session object is stored in an object that "is an object
defined in an object oriented programing language, such as JAVA®."
Spec. i-f 53 (emphasis added). But Appellants' invention may be
implemented in other programming languages (see, e.g., id. i-f 108), and this
"example" is intended to be non-limiting (see, e.g., id. i-f 115). Accordingly,
the Specification fails to define the limitation in a manner that would rebut
the presumption that "a session object" should be given its plain and
ordinary meaning.
One plain and ordinary meaning of the term "object" is data or a data
structure. Ellen Thro, THE ARTIFICIAL INTELLIGENCE DICTIONARY 227
(1991). So under a broad, but reasonable, interpretation consistent with both
9
Appeal2014-005673
Application 13/466,517
the disclosure (see, e.g., Spec. ilil 53, 108) and the claim as a whole, the
recited "a session object" broadly reads on data or structured data
representing session information.
Given this interpretation, the Examiner's position (Ans. 4) is
reasonable. In particular, Silky's server stores the generated UI data in the
web page's hidden form fields. Silky i-f 35. And consistent with the plain
meaning of "object," the Examiner finds that Silky's web page is a data
structure that represents session information. Ans. 4.
Notably, the claim does not specify where the session object is stored.
As discussed previously, the Specification, in particular Figure 4, is only an
illustrative, but non-limiting example, of where a session object may be
stored. See, e.g., Spec. i-fi-153, 108. Furthermore, Appellants have not shown
that the claims or the Specification precludes the session object from being
stored somewhere other than a server. See Br. 16-17. So even if Silky' s
web page code is not stored at the server, we are unconvinced that session
object cannot be stored elsewhere. Accordingly, Appellants' argument that
session objects must be stored on the server (id.) is not commensurate with
the scope of the claim.
Nevertheless, Appellants have not shown that Silky's web page is not
stored at the server, at least temporarily, before being sent to the client. See
id. To the contrary, Silky's host 112, including a server (Silky i-f 23),
generates and sends the page to the user. See id. i-f 3 6. Silky states that once
the page has been sent to the user, the host "no longer has a record of the
session information." Id. (emphasis added). The language "no longer" (id.)
implies that Silky's host records the session information and web page, at
10
Appeal2014-005673
Application 13/466,517
least temporarily. See id. On this record, the weight of the evidence tends to
support the Examiner's position that the session data is stored (Ans. 4).
Accordingly, we are not convinced that the Examiner erred in finding
that Silky stores session data as recited.
ISSUE #4
Contentions
Claim 1 recites, in part, "generating a response page having a set of
forms including a set of hidden fields, wherein the set of hidden fields
comprise the session data serialized and security data."
In the proposed combination under § 103, the Examiner finds that
Silky discloses generating a response page, but lacks serialized session data
and security data. Ans. 4--5. In concluding the claim would have been
obvious, the Examiner cites Stienhans and Vishwanath. Id. at 5. In
particular, the Examiner cites Stienhans as also disclosing serialization and
concludes that it would have been obvious to serialize Silky's data. Id.
(citing Stienhaus 2:58---63, 8:61-63). Furthermore, the Examiner finds that
Vishwanath discloses security data and concludes that it would have been
obvious to include this data in Silky's method. Id.
Appellants contend that Stienhans lacks serialized session data
because (1) Stienhans' serialization is optional and (2) Stienhans serializes
reduced-state information, not session data. Br. 17.
Appellants further argue that Vishwanath lacks generating the
response as recited because the recited response is not stored in a database,
as Vishwanath stores the security data. Id.
11
Appeal2014-005673
Application 13/466,517
Issues
Has the Examiner established by a preponderance of the
evidence that Silky, Stienhans, and Vishwanath collectively teach or
suggest a set of hidden fields that comprise
I. the session data serialized, as recited in claim 1?
II. security data, as recited in claim 1?
Analysis
I.
Regarding the recited "session data serialized," Appellants' argument
against Stienhans (Br. 17) is unpersuasive. Although Stienhans presents
only an option to serialize (Stienhans, col. 8, 11. 61---63), the Examiner's
rejection is based on this specific option. Ans. 4--5. That is, the Examiner
concludes that it would have been obvious to apply Stienhans' serialization
to Silky's session data. Id. Accordingly, Stienhans' option not to serialize
(Stienhans, col. 8, 11. 61---63) is not germane to this conclusion.
And here, the Examiner's obviousness conclusion (Ans. 4--5) is
reasonable. Specifically, Silky encodes data but lacks encoding to the
serialized format, as recited. See Silky i-f 42. Stienhans, however, serializes
data. Ans. 5 (citing Stienhans, col. 8, 11. 61-63). We see nothing that would
suggest that the Examiner is proposing to incorporate Stienhans' strategy to
extract mandatory information from session-state saves bandwidth and
memory, as suggested by Appellants. See Br. 18. Instead, the Examiner
merely relies on Stienhans for the limited purpose of serializing Silky's data.
See Ans. 5.
In response, Appellants have provided no evidence that applying
Stienhans' serialization would have been beyond the capabilities of one of
12
Appeal2014-005673
Application 13/466,517
ordinary skill. See Br. 17. For example, Appellants have not shown that
Stienhans' serialization requires a particular data type or that Silky' s data
could not be serialized. See id. To the contrary, Stienhans' serialization
merely transforms data from one format to another. See, e.g., Stienhans,
col. 4, 11. 4--5. On this record, the Examiner's conclusion (Ans. 5) is
reasonable.
II.
Regarding the recited "security data," Appellants' argument against
Vishwanath (Br. 17) also fails to address the Examiner's combination
(Ans. 5). Appellants' argument assumes that Vishwanath's security data
could not be used outside a database. Br. 17. However, apart from citing
how the security data is used in Vishwanath, Appellants have provided no
evidence that the security data could not be used in other settings. See id.
Even so, the test for obviousness does not require bodily incorporation of
Vishwanath's data into Silky's method. In re Keller, 642 F.2d 413, 425
( CCP A 19 81). Rather, the test is what the combined teachings would have
suggested. Id. Here, the Examiner's conclusion that it would have been
obvious to incorporate Vishwanath's data in Silky (Ans. 5) has not been
rebutted persuasively.
Accordingly, we are not convinced that the Examiner erred in finding
that the recited generating a response page would have been obvious over
Silky, Stienhans, and Vishwanath.
13
Appeal2014-005673
Application 13/466,517
ISSUE #5
Contentions
Claim 1 recites, in part, "sending the response page to a client
browser."
As discussed previously, the Examiner finds that Silky, Stienhans, and
Vishwanath collectively teach generating a response page. Ans. 3-5.
Specifically, the Examiner cites Stienhans for serialization and Vishwanath
to show security data. Id. at 5. And in combination with these teachings, the
Examiner finds that Silky sends a response page. Id. at 4.
Appellants argue that Silky cannot teach sending the response page
because Silky lacks the serialized session data and security data. Br. 18.
According to Appellants, one of ordinary skill in the art would not have
combined Silky and Stienhans because they contradict one another. Id.
Issue
Has the Examiner established by a preponderance of the
evidence that Silky, Stienhans, and Vishwanath collectively teach or
suggest "sending the response page to a client browser," as recited in
claim 1?
Analysis
The Examiner does not find that Silky discloses serialization or
security data. See Ans. 3-5. Accordingly, we are unpersuaded by
Appellants' argument that Silky's response page differs from the claimed
response page in this way (Br. 18). In other words, Appellants' argument
(id.) amounts to an individual attack. But we are not convinced that the
Examiner erred here because one cannot show nonobviousness by attacking
14
Appeal2014-005673
Application 13/466,517
references individually where the rejections are based on combinations of
references. See Keller, 642 F .2d at 426.
As best understood, Appellants argue that Silky and Stienhans could
not be combined. Br. 18. In particular, Appellants contrast Silky's use of
hidden fields to store session data with Stienhans' reduced session state. Id.
But Appellants fail to substantiate this claim with any further explanation.
See id. So for the same reasons discussed in connection with the recited
generating session data, we are not convinced by Appellants' arguments
against the combinability of Stienhans and Silky (Br. 18). For example,
Appellants have not shown that Stienhans' serialization requires particular
data or that Silky's data cannot be serialized. See id. Accordingly, we are
not convinced that the Examiner erred in combining Stienhans and Silky
(Ans. 3-5).
For the foregoing reasons, Appellants have not convinced us of error
in the Examiner's obviousness rejection of claim 1 (id.). Accordingly, we
sustain the Examiner's rejection of claim 1 (id.), as well as the rejection of
claims 2-20 (id. at 3-11), which are not argued separately (see Br. 18).
DECISION
The Examiner's decision rejecting claims 1-20 is affirmed.
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). See 37 C.F.R.
§ 1.136(a)(l )(iv).
AFFIRMED
15