UNITED STATES PATENT AND TRADEMARK OFFICE
`
`APPLICATION NO.
`
`FILING DATE
`
`FIRST NAMED INVENTOR
`
`95/000,660
`
`03/02/2012
`
`7590
`
`35600
`
`os/142013
`MEYERTONS, HOOD, KIVLIN, KOWERT & GOETZEL, P.C.
`P.O. BOX 398
`AUSTIN, TX 78767-0398
`
`UNITED STATES DEPARTMENT OF COMMERCE
`States Patent and Trademark
`United
`Office
`COMMISSIONER FOR PATENTS
`Address:
`P.O. Box 1450
`Alexandria, Virginia
`www.uspto.gov
`
`22313-1450
`
`ATTORNEY DOCKET NO. | CONFIRMATION NO.
`
`159291-0025(857)
`
`3313
`
`SRAMINNR
`
`WHITTINGTON,
`
`KENNETH
`
`ART UNIT
`
`3092
`
`MAIL DATE
`
`05/14/2013
`
`|
`
`|
`
`PAPER NUMBER
`
`DELIVERY MODE
`
`PAPER
`
`|
`
`|
`
`|
`
`|
`
`|
`
`|
`
`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.
`
`PTOL-90A
`
`(Rev. 04/07)
`
`JNPR-IMPL_30024_
`
`Page 1 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Transmittal of Communication to
`Third Party Requester
`Inter Partes Reexamination
`
`Control No.
`
`Patent Under
`
`Reexamination
`
`95/000,660
`Examiner
`
`7711857
`Art Unit
`
`KENNETH J. WHITTINGTON | 3992
`
`-- The MAILING DATE of this communication appears on the cover sheet with the correspondence address.
`
`[7 THIRD PARTY REQUESTER'S
`
`CORRESPONDENCE
`
`ADDRESS)
`
`--
`
`IRELL & MANELLA, LLP
`Attn: David McPhie
`840 Newport Center Dr., Ste. 400
`Newport Beach, CA 92660
`
`Enclosed is a copy of the latest communication from the United States Patent and Trademark Office
`in the above-identified reexamination prceeding. 37 CFR 1.903.
`
`Prior to the filing of a Notice of Appeal, each time the patent owner responds to this
`communication,
`the third party requester of the inter partes reexamination may once file written comments within a
`period of 30 days from the date of service of the patent owner's response. This 30-day time period is
`it cannot be extended. See also 37 CFR 1.947.
`statutory (35 U.S.C. 314(b)(2)), and, as such,
`
`lf an ex parte reexamination has been merged with the inter partes reexamination, no responsive
`submission by any ex parte third party requester is permitted.
`
`All correspondence relating to this inter partes reexamination proceeding should be directed to the
`Central Reexamination Unit at the mail, FAX, or hand-carry addresses given at the end of the
`enclosed with this transmittal.
`communication
`
`U.S. Patent and Trademark Office
`PTOL-2070
`(Rev. 07-04)
`
`Paper No. 20130409
`
`JNPR-IMPL_30024_
`
`1
`
`Page 2 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Control No.
`
`Patent Under
`
`Reexamination
`
`Right of Appeal Notice
`(37 CFR 1.953)
`
`95/000,660
`Examiner
`
`7711857
`Art Unit
`
`KENNETH J. WHITTINGTON | 3992
`
`-- The MAILING DATE of this communication appears on the cover sheet with the correspondence address.
`
`--
`
`to the communication(s)
`Responsive
`Patent Owner on 21 February, 2013
`Third Party(ies) on 25 March,
`2013
`
`filed by:
`
`Patent owner and/or third party requester(s) may file a notice of appeal with respect to any adverse decision
`with payment of the fee set forth in 37 CFR 41.20(b)(1) within one-month or thirty-days (whichever is
`longer). See MPEP 2671.
`In addition, a party may file a notice of cross appeal and pay the 37 CFR
`fee within fourteen days of service of an opposing party's timely filed notice of appeal. See
`41.20(b)(1)
`MPEP 2672.
`
`All correspondence relating to this inter partes reexamination proceeding should be directed to the Central
`Reexamination Unit at the mail, FAX, or hand-carry addresses given at the end of this Office action.
`
`lf no party timely files a notice of appeal, prosecution on the merits of this reexamination proceeding will be
`concluded, and the Director of the USPTO will proceed to issue and publish a certificate under 37 CFR 1.997 in
`accordance with this Office action.
`
`The proposed amendment filed
`
`willbe entered
`
`will not be entered*
`
`“Reasons for non-entry are given in the body of this notice.
`
`reexamination.
`
`1a. X] Claims 1,4 and 10 are subject to
`reexamination.
`1b. X] Claims 2,3 and 5-9 are not subject to
`Claims
`have been cancelled.
`2.
`3. [] Claims
`are confirmed.
`[Unamended patent claims].
`Claims
`are patentable. [Amended or new claims].
`Claims 1,4 and 10 are rejected.
`6. [] Claims
`are objected to.
`[_] are not acceptable.
`are acceptable.
`The drawings filed on
`is [] approved.
`The drawing correction request filed on
`disapproved.
`[_] Acknowledgment is made of the claim for priority under 35 U.S.C. 119 (a)-(d) or (f). The certified copy
`has:
`
`4.
`
`5.
`
`7.
`
`8.
`
`9.
`
`been received.
`
`not been received.
`
`[_] been filed in Application/Control No.
`
`Other
`
`Attachments
`Notice of References Cited by Examiner, PTO-892
`Information Disclosure Citation, PTO/SB/08
`
`1.
`2.
`3.
`
`U.S. Patent and Trademark Office
`PTOL-2066
`(08-06)
`
`Right of Appeal Notice (37 CFR 1.953)
`
`Part of Paper No.
`
`20130409
`
`JNPR-IMPL_30024_
`
`Page 3 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 2
`
`RIGHT OF APPEAL NOTICE
`
`This is a Right of Appeal Notice ("RAN") in the reexamination of U.S. Patent No.
`
`7,711,857, entitled METHOD AND SYSTEM FOR DATA DEMULTIPLEXING
`
`(hereinafter the “857 Patent"). Claims 1, 4 and 10 under
`
`reexamination are pending
`
`herein and the rejections thereof are maintained as outlined below. Appeal can be
`
`taken from this RAN under 37 CFR §1.953.
`
`I.
`
`THE REFERENCE CITED HEREIN
`
`(1)
`
`(2)
`
`(3)
`
`DECASPER et al., Router Plugins A Software Architecture of Next Generation
`Routers, Proceedings of ACM SIGCOMM '98, Sept. 10, 1998, Vancouver B.C.,
`Exhibit 25 to the Request (referred to as “Decasper98’).
`
`IBM Raleigh Center, Local Area Network Concepts and Products: Routers and
`Gateways, 1st Ed., May 1996, Research Triangle Park, NC, Exhibit 19 to the
`Request (hereinafter referred to as “IBM96’).
`
`NELSON et al., The Data Compression Book, 2nd Edition, Nov. 6, 1995, M&T
`Books, New York, NY, Exhibit 5 to the Request
`referred to as
`(hereinafter
`“Nelson’).
`
`ll.
`
`ACKNOWLEDGEMENT OF PAPERS
`
`Receipt
`
`is acknowledged herein of the papers filed by Patent Owner on February
`
`21, 2013,
`
`including remarks and a Declaration by Dr. Tze Sing Eugene Ng (hereinafter
`
`the “2.21.13 Remarks” and the “2013 Ng Declaration”,
`
`respectively). Receipt is also
`
`acknowledged
`
`herein of the papers filed by the third party Requester on March 25,
`
`2013,
`
`including comments after the Patent Owner's response, a Declaration by R.
`
`Bernhard Plattner and various Appendices (hereinafter the "3.25.13 Comments",
`
`the
`
`JNPR-IMPL_30024_
`
`Page 4 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 3
`
`"2013 Plattner Declaration" and the "Appendices",
`
`respectively). These papers are
`
`entered under 37 C.F.R. 1.951. This action is made in full consideration of all these
`
`papers.
`
`Requester has asserted that the Remarks and the 2013 Ng Declaration should
`
`not be entered because they raise new issues not raise prior to the Action Closing
`
`Prosecution mailed December 21, 2012 (hereinafter the "12.21.12 ACP").
`
`However,
`
`Examiners find the 2.21.13 Remarks and the 2013 Ng Declaration do not raise new
`
`issues because they are directed to the Decasper89 rejections outlined in the ACP as
`
`well as the responses to arguments provided by both the Patent Owner and the
`
`Requester (See ACP in general).
`
`Furthermore, as noted by Patent Owner in pages 30-
`
`31 in the 2.21.13 Remarks and agreed herein, the 2.21.13 Remarks and 2013 Ng
`
`Declaration are in response to issues raised by the Requester in the Declaration by R.
`
`Bernhard Plattner filed August 13, 2012. Thus, Examiners find good and sufficient
`
`reasons to enter and consider the 2.21.13 Remarks and the 2013 Ng Declaration
`
`herein.
`
`lil,
`
`STATUTORY BASIS FOR THE REJECTIONS
`
`Claim Rejections - 35 USC § 102
`
`The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that
`
`form the basis for the rejections under this section made in this Office action:
`
`A person shall be entitled to a patent unless —
`
`(a) the invention was known or used by others in this country, or patented or described in a printed
`publication in this or a foreign country, before the invention thereof by the applicant for a patent.
`
`JNPR-IMPL_30024_
`
`Page 5 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 4
`
`(b) the invention was patented or described in a printed publication in this or a foreign country or in
`public use or on sale in this country, more than one year prior to the date of application for patent in
`the United States.
`
`(e) the invention was described in (1) an application for patent, published under section 122(b), by
`filed in the United States before the invention by the applicant for patent or (2) a patent
`another
`granted on an application for patent by another filed in the United States before the invention by the
`for patent, except that an international application filed under the treaty defined in section
`applicant
`shall have the effects for purposes of this subsection of an application filed in the United States
`only if the international application designated the United States and was published under Article
`of such treaty in the English language.
`
`Claim Rejections - 35 USC § 103
`
`The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all
`
`obviousness
`
`rejections set forth in this Office action:
`
`identically disclosed or described as set
`(a) A patent may not be obtained though the invention is not
`forth in section 102 of this title,
`if the differences between the subject matter sought to be patented and
`the prior art are such that the subject matter as a whole would have been obvious at the time the
`invention was made to a person having ordinary skill
`in the art to which said subject matter pertains.
`Patentability shall not be negatived by the manner in which the invention was made.
`
`IV.
`
`REJECTIONS
`
`The rejections applying Decasper98 and combinations thereof outlined in the
`
`12.21.12 ACP are maintained herein and are reprinted below.
`
`issue 1
`
`Claims 1, 4 and 10 are rejected under 35 U.S.C. 102(b) as being anticipated by
`
`Decasperg8.
`
`Regarding claim 1, Decasper98 discloses a method in a computer system for
`
`processing packets of a message (See Decasper98 at page 1, Abstract, note system
`
`is software based and thus would be useable in a computer system, embodied in a
`
`router. Note also Part 3 that the flows processed in the router correspond to the
`
`JNPR-IMPL_30024_
`
`Page 6 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 5
`
`message and thus the packets thereof correspond to such packets of a message), the
`
`method
`
`comprising:
`
`receiving a packet of the message and a data type of the message (See part
`
`5.1 thereof, note packet has data and a six-tuple for filter matching to create a flow
`
`path);
`
`analyzing the data type of a first packet of the message to dynamically
`
`identify a sequence of components for processing a plurality of packets of the
`
`message such that the output format of the components of the sequence match
`
`the input format of the next component in the sequence (See Parts 3.2 and 5.1. and
`
`FIG. 3 reprinted below for reference. Note packet six-tuples are analyzed to provide the
`
`data type of the packet that is used to identify the proper instance for each of the
`
`components/plug-ins
`
`using filter tables. Once the plug-ins are identified, the particular
`
`flow through the components/plug-ins is stored in a flow table. This process is done
`
`dynamically, because either the flow path is already provided in the flow table or a new
`
`flow path is created based on the data type of the incoming packet. Thus, a new path is
`
`creatable during run time on the fly. Finally, the output format of the
`
`components/plug-
`
`ins of the sequence would necessarily or inherently match the input format of the next
`
`component/plugin--otherwise
`
`the later plug-ins would not be able to perform its
`
`processing),
`
`JNPR-IMPL_30024_
`
`Page 7 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 6
`
`ce
`
`SEL
`Sarnat
`
`Figure 3.
`
`: System Architecture and Data Path
`
`Decasper FIG. 3
`
`wherein analyzing the data type of the first packet of the message to
`
`dynamically identify the sequence of components includes selecting individual
`
`components to form the sequence of components after the first packet of the
`
`message is received (See above discussion. Note particularly first sentence of page 6
`
`in Part 3.2 which states the process of creating a flow path “is executed only for the first
`
`packet arriving on the uncached flow. Subsequent packages follow a faster path
`
`because of the cached entry in the flow table”);
`
`storing an indication of each of the identified components so that the
`
`sequence does not need to be re-identified for subsequent packets of the
`
`message (See pages 5-6, Part 3.2, note that once the entry in the flow table for the new
`
`flow is created for the first packet, all subsequent packets from that flow uses the same
`
`JNPR-IMPL_30024_
`
`Page 8 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 7
`
`flow entry which contains the pointers to the appropriate plug-ins for all the gates,
`
`the
`
`pointers are not
`
`re-identified);
`
`for each of a plurality of components in the identified sequence:
`
`performing the processing of each packet by the identified component
`
`(See
`
`Part 3.2, first paragraph, note each plug-in implements processing of the packet); and
`
`storing state information relating to the processing of the component with
`
`the packet for use when processing the next packet of the message (See Part 5.2,
`
`note flow record 1, which states in each flow record recorded in the hash table has
`
`space for a plug-in instance bound to the flow and “private data for that plug-in instance
`
`... used by the plugins to store per-flow soft state.” Thus,
`
`there is data, i.e., state
`
`information, used by the plug-ins generated from the data of the first packet that is
`
`stored in the hash table used to store a pointer to a queue of packets for each flow).
`
`Regarding claim 4, Decasper98 discloses a method in a computer system for
`
`processing a message, the message having a plurality of headers (See
`
`Decasper98 at page 1, Abstract, note system is software based and thus would be
`
`useable in a computer system, embodied in a router. Note also Part 3 that the flows
`
`processed in the router correspond to a message and thus the packets thereof
`
`correspond to such packets of the message. Note also the packets for the flow have a
`
`plurality of headers or six-tuples for processing thereof), the method comprising:
`
`analyzing the plurality of headers of a first packet of the message to
`
`dynamically identify a sequence of components for processing a plurality of
`
`packets of the message such that the output format of the components of the
`
`JNPR-IMPL_30024_
`
`Page 9 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 8
`
`sequence match the input format of the next component in the sequence (See
`
`Parts 3.2 and 5.1 and see FIG. 3 reprinted above for reference. Note packet six-tuples
`
`are analyzed to provide the data type of the packet that is used to identify the proper
`
`instance for each of the components/plug-ins using filter tables. Once the plug-ins are
`
`identified,
`
`the particular flow through the components/plug-ins is stored in a flow table.
`
`This process is done dynamically, because either the flow path is already provided in
`
`the flow table or a new flow path is created based on the data type of the incoming
`
`packet. Thus, a new path is creatable during run time on the fly. Finally, the output
`
`format of the components/plug-ins of the sequence would necessarily or
`
`inherently
`
`match the input format of the next
`
`component/plugin--otherwise
`
`the later plug-ins would
`
`not be able to perform its processing),
`
`wherein analyzing the plurality of headers of the first packet of the
`
`message to dynamically identify the sequence of components includes selecting
`
`individual components to form the sequence of components after the first packet
`
`of the message is received (See above discussion. Note particularly first sentence of
`
`page 6 in Part 3.2 which states the process of creating a flow path “is executed only for
`
`the first packet arriving on the uncached flow. Subsequent packages follow a faster
`
`path because of the cached entry in the flow table”);
`
`storing an indication of each of the identified components so that the
`
`sequence does not need to be re-identified for subsequent packets of the
`
`message (See pages 5-6, Part 3.2, note that once the entry in the flow table for the new
`
`flow is created for the first packet, all subsequent packets from that flow uses the same
`
`JNPR-IMPL_30024_
`
`Page 10 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 9
`
`flow entry which contains the pointers to the appropriate plug-ins for all the gates,
`
`the
`
`pointers are not
`
`re-identified);
`
`for each of a plurality of components in the identified sequence:
`
`performing the processing of each packet by the identified component
`
`(See Part
`
`3.2, first paragraph, note each plug-in implements processing of the packet); and
`
`storing state information relating to the processing of the component with
`
`the packet for use when processing the next packet of the message (See Part 5.2,
`
`note flow record 1, which states in each flow record recorded in the hash table has
`
`space for a plug-in instance bound to the flow and “private data for that plug-in instance
`
`... used by the plugins to store per-flow soft state.” Thus,
`
`there is data, i.e., state
`
`information, used by the plug-ins generated from the data of the first packet that is
`
`stored in the hash table used to store a pointer to a queue of packets for each flow).
`
`Regarding claim 10, Decasper98 discloses a computer readable storage
`
`medium, other than a data transmission medium, containing instructions for
`
`processing packets of a message (See Decasper98 at page 1, Abstract, note system
`
`is software based and thus would be useable in a computer system, embodied in a
`
`router. Since it is software based,
`
`it would be located on a storage medium for use
`
`thereof. Note also Part 3 that the flows processed in the router correspond to the
`
`message and thus the packets thereof correspond to such packets of a message), the
`
`instructions comprising at least one computer-executable module configured to
`
`perform the steps of the method as recited in claim 1
`
`(See discussion above with
`
`respect
`
`to claim 1 since the remaining recitations of claim 10 match those of claim 1).
`
`JNPR-IMPL_30024_
`
`Page 11 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 10
`
`issue 2
`
`Claims 1, 4 and 10, are alternatively rejected under 35 U.S.C. 103(a) as being
`
`unpatentable over Decasper98 (See MPEP §21 12 (ill) expressly authorizing alternative
`
`§102/§103 rejections when the question of
`
`inherency is present in the anticipation
`
`rejection).
`
`As noted above,
`
`it is the principle position that each of claims 1, 4 and 10 are
`
`anticipated because Decasper98 discloses each and every feature of these claims.
`
`This position includes a determination that the sequence is determined such that “the
`
`output
`
`format of the components/plug-ins of the sequence match the input format of the
`
`next component
`
`in the sequence” would be necessary or inherent to the operation of the
`
`router of Decasper98.
`
`However,
`
`if this feature is not inherent,
`
`it would have nonetheless been obvious
`
`to a person having ordinary skill
`
`in the art at the time the invention was made to modify
`
`the router components/plug-ins of Decasper98 such that for each sequence of
`
`components/plug-ins,
`
`the output format of each component/plug-in would match the
`
`input format of the next component/plug-in in the sequence. One having ordinary skill
`
`in
`
`the art would do so to allow each component/plug-in in a sequence to be able to accept
`
`the data packet in a format that it can process,
`
`i.e., compatible formats between
`
`components/plug-ins.
`
`Particularly, such compatibility among components would allow
`
`for the packets to move along the flow paths in the router of Decasper98 for processing
`
`JNPR-IMPL_30024_
`
`Page 12 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 11
`
`at each component/plug-in stage therein. Otherwise,
`
`the components/plug-ins may not
`
`be able to perform their processing as desired.
`
`issue 7
`
`Claims 1, 4 and 10 are rejected under 35 U.S.C. 103(a) as being unpatentable
`
`over Deccasper98 in view of
`
`IBM96.
`
`Regarding each of these claims, Decaspser98 discloses or teaches the features
`
`of each of these claims as noted above in Issue 1. Decasper98 further teaches that its
`
`router plug-ins can comprises plug-ins implementing various algorithms, but does
`
`not provide the particular details of each possible algorithm thereof.
`
`IBM96 teaches a
`
`router platform having an aigorithm therein for compression or decompression of
`
`data passing through the router, the compression algorithm being an LZ based
`
`compression algorithm, particularly LZ77 (See IBM96 pages 84 and 95-96).
`
`It would
`
`have been obvious to provide the compression algorithm taught by IBM96 as one of the
`
`plug-ins in the router of Decasper98. One having ordinary skill
`
`in the art would do so
`
`because as noted in Decasper98, it contemplates that additional plug-ins (router
`
`algorithms) can be added as its router plug-ins in its router architecture (See
`
`Decasper98 at pages 2, 3, 6 and 11) and furthermore,
`
`the compression algorithms
`
`allows for decompression and/or compression of data to and from the router.
`
`It being
`
`well known in the art to compress data for faster data transmission and processing.
`
`As
`
`a result of this combination,
`
`the particular router plug-in for compression as taught in the
`
`combination would store additional state information comprising a dictionary or table for
`
`JNPR-IMPL_30024_
`
`Page 13 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 12
`
`compressing or decompressing the data (See Request at page 73 citing Nelson for
`
`details of this compression algorithm). Thus, Nelson is merely cited herein in a minor
`
`capacity to illustrate features of the compression algorithm of
`
`IBM96.
`
`issue 8
`
`Claims 1, 4 and 10 are rejected under 35 U.S.C. 103(a) as being unpatentable
`
`over Deccasper98 in view of IBM96 and Nelson.
`
`Regarding each of these claims, Decaspser98 discloses or teaches the features
`
`of each of these claims as noted above in Part Ai. Decasper98 further teaches that its
`
`router plug-ins can comprises plug-ins implementing various algorithms, but does
`
`not provide the particular details of each possible algorithm thereof.
`
`IBM96 teaches a
`
`router platform having an algorithm therein for compression or decompression of
`
`data passing through the router, the compression algorithm being an LZ based
`
`compression algorithm, particularly LZ77 (See IBM96 pages 84 and 95-96). Nelson
`
`outlines the detail of these LZ compression algorithms and also teaches or
`
`suggests the use of other compression algorithms (See Request at pages 75-76
`
`citing Nelson for compression algorithms in each of chapters 2-9).
`
`It would have been
`
`obvious to provide the compression algorithm taught by IBM96 or one of the
`
`compression
`
`algorithms of Nelson as one of the plug-ins in the router of Decasper98.
`
`One having ordinary skill
`
`in the art would do so because as noted in Decasper98, it
`
`contemplates
`
`that additional plug-ins (router algorithms) can be added as its router
`
`plug-ins in its router architecture (See Decasper98 at pages 2, 3, 6 and 11) and
`
`JNPR-IMPL_30024_
`
`Page 14 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 13
`
`furthermore,
`
`the compression algorithms allows for decompression and/or
`
`compression
`
`of data to and from the router.
`
`It being well known in the art to compress data for faster
`
`data transmission and processing. As
`
`result of this combination,
`
`the particular router
`
`plug-in for compression as taught in the combination would store additional state
`
`information comprising a dictionary or table for compressing or decompressing the data
`
`as needed passing through the router (See Nelson pages 18-22 for details of these
`
`compression/decompression
`
`algorithms using adaptive algorithms which store data in
`
`table/dictionary
`
`form that is updated after each data packet is received for use in later
`
`processing of data packets).
`
`V.
`
`RESPONSES TO ARGUMENTS
`
`Below are responses to arguments asserted by Patent Owner in Parts |,
`
`Il and III
`
`of the 2.21.13 Remarks and Requester in the 3.25.13 Comments.
`
`A.
`
`Claim Construction
`
`During patent examination and reexamination,
`
`the pending claims must be given
`
`their broadest
`
`reasonable interpretation consistent with the specification since patentee
`
`has an opportunity to amend claims. See MPEP §2111, MPEP §2111.01 and /n re
`
`Yamamoto et al., 222 USPQ 934 (Fed. Cir. 1984). Under a broadest
`
`reasonable
`
`interpretation, words of the claim must be given their plain meaning, unless such
`
`meaning is inconsistent with the specification. See MPEP
`
`It is further noted
`
`it
`
`is improper to import claim limitations from the specification,
`
`i.e., a particular
`
`JNPR-IMPL_30024_
`
`Page 15 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 14
`
`embodiment
`
`appearing in the written description may not be read into a claim when the
`
`claim language is broader than the embodiment. See MPEP
`
`An applicant is entitled to be his or her own lexicographer and may rebut the
`
`presumption that claim terms are to be given their ordinary and customary meaning by
`
`clearly setting forth a definition of the term that is different from its ordinary and
`
`customary meaning, but must do so with reasonable clarity, deliberateness,
`
`and
`
`precision in the specification. See MPEP 2111.01(IV).
`
`1.
`
`“message” versus “flow”
`
`Patent Owner in the 2.21.13 Remarks argues that the system of the '857 Patent
`
`is directed to a message based system while Decasper98 is directed to packet based
`
`system (See 2.21.13 Remarks at pages 1-2, Part A). Patent Owner bases this
`
`distinction on the assertion that Decasper98 is “concerned with handling individual
`
`packets at the network layer” (See 2.21.13 Remarks at page 2, 1st full
`
`Examiners
`
`do not find this argument
`
`persuasive.
`
`As noted by the inventor of the '857 Patent,
`
`"flow-based
`
`processing would refer to using the first packet of a message to
`
`identify a sequence of components that is use to process packets of
`
`that
`
`message.
`
`In that context, a message can be considered a flow" [See Appendix
`
`R10 filed August 13, 2012, Deposition of Edward Balassanian, page 14]
`
`Later in the deposition, Mr. Balassanian further states:
`
`“tilIn the context of the '163 Patent, a flow is captured by packets that are related
`
`in some way. We use the word message to be synonymous with flow” [See
`
`JNPR-IMPL_30024_
`
`Page 16 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 15
`
`Appendix R10 filed August 13, 2012, Deposition of Edward Balassanian, page
`
`15]
`
`Examiners find the ‘857 Patent and the ‘163 Patent (U.S. Patent 6,629,163) have
`
`a common disclosure since one is a continuation application of the other. Thus,
`
`the
`
`inventor of the '857 recognizes that message based packet systems can be considered
`
`and are synonymous with flow based packet systems.
`
`Furthermore,
`
`the’857 Patent and
`
`Patent Owner state/define that a message is a collection of data that is related in some
`
`way (See ‘857 Patent at col. 2, lines 46-48 and see Remarks at page 1, 3rd full
`
`Thus, Examiners find no clear distinction in Patent Owner’s arguments between flow-
`
`based or message-based systems that usea first packet of such flow or message to
`
`process later packets of such flow or message. Accordingly, Examiners will
`
`interpret
`
`message and flow synonymously for purposes of examination herein.
`
`2.
`
`“data type”
`
`Patent Owner's argues that “analyzing the data type” in claims 1 and 10 means
`
`“identifying the protocols in the multiple layers that are used in the first packet's
`
`headers” (See .2.21.13 Remarks at page 8, Part 1, 1st 4). Examiners do not find this
`
`definition persuasive or required in the claims.
`
`First, Patent Owner has not provided any special definition of “data type” in the
`
`disclosure of the ‘857 Patent with any clarity, precision or deliberateness. This term
`
`only shows up in the Abstract and the claims. Thus, Examiners will give this term its
`
`broadest
`
`reasonable interpretation, which means data type will be given its plain
`
`meaning consistent with the specification.
`
`JNPR-IMPL_30024_
`
`Page 17 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 16
`
`Patent Owner asserts the basis of its definition for “data type” comes from the
`
`Abstract,
`
`the background of the invention and various other places in the disclosure of
`
`the ‘857 Patent (See 2.21.13 Remarks at pages 8-10). However, while the claims are
`
`read in light of the specification,
`
`limitations from the specification will not be read into
`
`the claims. A particular embodiment
`
`in the disclosure will not be read into the claims
`
`when the claim language is broader than the embodiment.
`
`For example, as noted by Requester and agreed upon herein by Examiners,
`
`“data type” is singular and should be interpreted as such (See 3.25.13 Comments at
`
`pages 14-15 which are incorporated herein). The Abstract to which the Patent Owner
`
`relies for its asserted definition identifies two “data types”,
`
`an initial data type and a
`
`target data type (See
`
`Patent, Abstract). Thus, the claim which identifies only one
`
`data type is thus broader than the embodiment
`
`identified by Patent Owner and
`
`Examiners will not import the multiple protocols/layers interpretation of this phrase from
`
`the disclosure of the ‘857 Patent.
`
`Patent Owner argues that the “claimed ‘data type’ cannot refer to only one
`
`protocol or one layer, since this would ignore both the Abstract (which associates ‘data
`
`type’ with a plurality of types) and the remainder of the specification, which explains the
`
`need to process at multiple layers in the protocol stack for the first packet of the
`
`message (See 2.21.13 Remarks at page 10). However, Examiner's interpretation that
`
`the claim only requires analyzing a data type does not ignore these portions of the
`
`specification, but is simply an interpretation read in light of them. The plain meaning of
`
`JNPR-IMPL_30024_
`
`Page 18 of 43
`
`Implicit Exhibit 2007
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 17
`
`the claim language requires only "a data type.
`
`It is further noted that the claim does not
`
`require or imply any specific layer or protocol, much less multiple layers or protocols.
`
`Patent Owner further argues that the "sequence of components" feature of the
`
`claim somehow requires "a data type" to be plural to imply “multiple protocols” (See
`
`2.21.13 Remarks at page 10). Examiners do not find this argument persuasive. As
`
`noted by Requester and agreed upon by Examiners,
`
`there is nothing in the claims that
`
`would require a "one-to-one correspondence between protocols and components" (See
`
`3.25.13 Comments at page 15 2nd 4). The claims only require the analysis of the "data
`
`type ... to dynamically identify a sequence of components”. Examiners find there is
`
`nothing about this plain language relating to a “data type” that requires multiple data
`
`type/protocols
`
`to correspond to the multiple components.
`
`Finally, Patent Owner argues that its construction for “data type” that is
`
`consistent with the claim context and the specification is "protocols in multiple layers”
`
`(See 3.25.13 Remarks at bottom of page 10). Examiners do not disagree. This is one
`
`reasonable interpretation. However,
`
`it is not the only or the broadest
`
`reasonable
`
`interpretation of “data type” in view of the plain language of claims as interpreted in light
`
`of the specification.
`
`Based on the above, Examiners will
`
`interpret “data type” according to its plain
`
`meaning in view of the specification. As noted above, “data type” only appears in the
`
`Abstract and claims. However, a review of the specification of the '857 Patent
`
`incorporates U.S. Patent 7,730,211, which notes that "fo