Ex Parte Moffat et al

Patent Trial and Appeal Board

May 24, 2016

12780204 (P.T.A.B. May. 24, 2016)

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
In re application of:
Group Art Unit: 2435
DARREN J. MOFFATT
Examiner: PALIW AL, YOGESH
Serial No.: 12/780204
Filed: May 14, 2010
For: METHOD AND SYSTEMFORENCRYPTINGDATA
Attorney Docket No.: SUNM 100130 PUS
REQUEST FOR REHEARING
Mail Stop Appeal Brief - Patents
Commissioner for Patents
U.S. Patent and Trademark Office
P.O. Box 1450
Alexandria, VA 22313-1450
Commissioner:
In response to the Decision on Appeal mailed February 26, 2016, Appellants respectfully
request reconsideration in view of the following:
Serial No. 12/780204 Atty. Dkt. No. SUNM 100130 PUS
Response to Decision On Appeal of February 26, 2016
Remarks
The board has concluded that "[w]e do not find Appellants' arguments persuasive
because the Specification does not support Appellants' assertion that the transaction identifiers
are time based entries." Decision on Appeal, p. 4. To support this position, the board notes that
"a claim is given its broadest reasonable construction 'in light of the specification as it would be
interpreted by one of ordinary skill in the art."' Id. Appellants, however, have explained that
their use of the phrase "transaction identifiers" is consistent with that which is known in the art, 1
and that the examiner's interpretation, in essence, is not reasonable because it is broader than that
which is known in the art:
Although Maheshwari may be a transaction based file system and chunks may be
logical units of access to untrusted store, this does not make Maheshwari's chunks
a set of transaction identifiers. Transaction identifiers are time based entries
indicating when particular data was written as known in the art. In contrast,
Maheshwari's chunk IDs indicate where-not when-particular data was written.
Appeal Brief, pp. 3-4.
The MPEP explains that
[t]he legal concept of prima facie obviousness is a procedural tool of examination
which applies broadly to all arts. It allocates who has the burden of going forward
with production of evidence in each step of the examination process . . . . The
examiner bears the initial burden of factually supporting any prima facie
conclusion of obviousness. If the examiner does not produce a prima facie case,
the applicant is under no obligation to submit secondary evidence to show
nonobviousness.
MPEP 2142 (emphasis added).
As such, the examiner bears the initial burden of providing evidence that his interpretation of
"transaction identifiers" is reasonable. Citing case law for the proposition that claims are entitled
to their broadest reasonable construction, however, is not such evidence as it does not explain
why one of ordinary skill would have interpreted the disputed phrase in the manner suggested by
1 Terms of art need not be defined in a specification as those of ordinary skill understand their recognized meaning.
And, Appellants have not used "transaction identifiers" in a manner inconsistent with its recognized meaning: no
special definition need be included in the Specification.
2
Serial No. 12/780204 Atty. Dkt. No. SUNM 100130 PUS
Response to Decision On Appeal of February 26, 2016
the examiner.2 Moreover, the board appears to have impermissibly shifted the examiner's initial
burden onto the Appellants by suggesting that the Specification is somehow lacking. See,
Decision on Appeal, p. 4, ("[T]he Specification does not support Appellants' assertion that the
transaction identifiers are time based entries.") That is, the Board improperly looks first to
Appellants-instead of the examiner-for evidence.
Attached hereto is an article entitled "ZFS fundamentals: transaction groups" dated
December 13, 2012. Under the sub-heading "ZFS Transaction Groups," the article notes that
"[e]ach successive transaction group (txg) is assigned a 64-bit consecutive identifier[, i.e., a
transaction identifier] . . . . At any given time, there may be an active txg associated with each
state .... " This means that a uniquely identifiable transaction exists in a given state at a point in
time. Thus, Appellants' use of the phrase "transaction identifiers" is consistent with that which
is known in the art. Chunks indicating where particular data was written, however, cannot be
transaction identifiers because the same location can be written to multiple times during the
lifetime of a file system.
2 Nothing in the Specification suggests that the phrase "transaction identifiers" is being used in a manner
inconsistent with its ordinary meaning in the art. As such, the Specification is not a source of evidence to somehow
show that the phrase "transaction identifiers" has the meaning suggested by the examiner.
3
Serial No. 12/780204 Atty. Dkt. No. SUNM 100130 PUS
Response to Decision On Appeal of February 26, 2016
Please charge any fees or credit any overpayments as a result of the filing of this or any
other paper to our Deposit Account No. 02-3978.
Date: April 26, 2016
BROOKS KUSHMAN P.C.
1000 Town Center, 22nd Floor
Southfield, MI 48075-1238
Phone: 248-358-4400
Fax: 248-358-3351
Respectfully submitted,
DARREN JAMES MOFFATT
By: /Benjamin C. Stasa/
Benjamin C. Stasa
Reg. No. 55,644
Attorney for Appellants
4
ZFS fundamentals: transaction groups - Adam Leventhal Page I of 6
ZFS fundamentals: transaction groups
Posted by Adam Leventhal on 13th December, 2012 in ZFS (http://blog.delphix.com/ahl/category/zfs/)
.~'''''''''''''\
t.J~e < 0 l T'-~'f:~~t
:..~~~~~~)
I've continued (http://dtrace.org/blogs/ahl/2012/11 /08/zfs-trivia-metaslabs/) to explore ZFS as I try to understand
performance pathologies, and improve performance. A particular point of interest has been the ZFS write throttle,
the mechanism ZFS uses to avoid filling all of system memory with modified data. I'm eager to write about the
strides we're making in that regard at Delphix, but it's hard to appreciate without an understanding of how ZFS
batches data. Unfortunately that explanation is literally nowhere to be found. Back in 2001 I had not yet started
working on DTrace, and was talking to Matt and Jeff, the authors of ZFS, about joining them. They had only been
at it for a few months; I was fortunate to be in a conference with them as the ideas around transaction groups
formulated. Transaction groups are how ZFS batches up chunks of data to be written to disk ("groups" of
"transactions"). Jeff stood at the whiteboard and drew the progression of states for transaction groups, from
open, accepting new transactions, to quiescing, allowing transactions to complete, to syncing, writing data out to
disk. As far as I can tell, that was both the first time that picture had been drawn and the last. If you search for
information on ZFS transaction groups you'll find mention of those states ... and not much else. The header
comment in usr/src/uts/common/fs/zfs/txg.c (http://src.illumos.org/source/xref/illumos-
gate/usr/src/uts/common/fs/zfs/txg.c?r=ce636f8b38e8c9ff484e880d9abb27251 a882860) isn't particularly helpful:
!*
* Pool-wide transaction groups.
*!
I set out to write a proper description of ZFS transaction groups. I'm posting it here first, and I'll be offering it as a
submission to illumos. Many thanks to Matt Ahrens (https://twitter.com/mahrens1), George Wilson
(hiips://iwiiier.com/zfsdude), and Max Bruning (hiips://iwiiier.com/mrbruning) for iheir feedback.
ZFS Transaction Groups
ZFS transaction groups are, as the name implies, groups of transactions that act on persistent state. ZFS asserts
consistency at the granularity of these transaction groups. Each successive transaction group (txg) is assigned a
64-bit consecutive identifier. There are three active transaction group states: open, quiescing, or syncing. At any
given time, there may be an active txg associated with each state; each active txg may either be processing, or
blocked waiting to enter the next state. There may be up to three active txgs, and there is always a txg in the
open state (though it may be blocked waiting to enter the quiescing state). In broad strokes, transactions -
operations that change in-memory structures - are accepted into the txg in the open state, and are completed
while the txg is in the open or quiescing states. The accumulated changes are written to disk in the syncing state.
Open
When a new txg becomes active, it first enters the open state. New transactions - updates to in-memory
structures - are assigned to the currently open txg. There is always a txg in the open state so that ZFS can
accept new changes (though the txg may refuse new changes if it has hit some limit). ZFS advances the open
txg to the next state for a variety of reasons such as it hitting a time or size threshold, or the execution of an
administrative action that must be completed in the syncing state.
Quiescing
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/ 4/20/2016
ZFS fundamentals: transaction groups - Adam Leventhal Page 2of6
After a txg exits the open state, it enters the quiescing state. The quiescing state is intended to provide a buffer
between accepting new transactions in the open state and writing them out to stable storage in the syncing state.
\/Vhile quiescing, transactions can continue their operation vvithout delaying either of the other states. Typically, a
txg is in the quiescing state very briefly since the operations are bounded by software latencies rather than, say,
slower 1/0 latencies. After all transactions complete, the txg is ready to enter the next state.
Syncing
In the syncing state, the in-memory state built up during the open and (to a lesser degree) the quiescing states is
written to stable storage. The process of writing out modified data can, in turn modify more data. For example
when we write new blocks, we need to allocate space for them; those allocations modify metadata (space maps)
... which themselves must be written to stable storage. During the sync state, ZFS iterates, writing out data until
it converges and all in-memory changes have been written out. The first such pass is the largest as it
encompasses all the modified user data (as opposed to filesystem metadata). Subsequent passes typically have
far less data to write as they consist exclusively of filesystem metadata.
To ensure convergence, after a certain number of passes ZFS begins overwriting locations on stable storage
that had been allocated earlier in the syncing state (and subsequently freed). ZFS usually allocates new blocks
to optimize for large, continuous, writes. For the syncing state to converge however it must complete a pass
where no new blocks are allocated since each allocation requires a modification of persistent metadata. Further,
to hasten convergence, after a prescribed number of passes, ZFS also defers frees, and stops compressing.
In addition to writing out user data, we must also execute synctasks during the syncing context. A synctask is the
mechanism by which some administrative activities work such as creating and destroying snapshots or datasets.
Note that when a synctask is initiated it enters the open txg, and ZFS then pushes that txg as quickly as possible
to completion of the syncing state in order to reduce the latency of the administrative activity. To complete the
syncing state, ZFS writes out a new uberblock, the root of the tree of blocks that comprise all state stored on the
ZFS pool. Finally, ifthere is a quiesced txg waiting, we signal that it can now transition to the syncing state.
\tVhat else?
Please let me know if you have suggestions for how to improve the descriptions above. There's more to be
written on the specifics of the implementation, transactions, the DMU, and, well, ZFS in general. One thing that
I'd note is that Matt mentioned to me recently that were he starting from scratch, he might eliminate the quiescing
state. I didn't understand fully until I researched the subsystem. Typically transactions take a very brief amount of
time to "complete", time measured by CPU latency as opposed, say, to 1/0 latency. Had the quiescing phase
been merged into the syncing phase, the design would be slightly simpler, and it would eliminate the mostly idle
intermediate phase where a bunch of dirty data can sit in memory relatively idle.
Next I'll write about the ZFS write throttle, it's various brokenness, and our ideas for how to fix it.
Tags: GeorgeWilson (http://blog.delphix.com/ahl/tag/georgewilson/), MattAhrens
(http://blog.delphix.com/ahl/tag/mattahrens/), MaxBruning (http://blog.delphix.com/ahl/tag/maxbruning/), txg
(http ://blog .delph ix.com/ah l/tag/txg/)
Feedback
Comments: 2
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/ 4/20/2016
ZFS fundamentals: transaction groups - Adam Leventhal Page 3of6
Vedant Kumar
June 27, 2013 at 8:43 pm (http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-
groups/#comment-18209)
Thanks for the write-up.
I had a question about how dirty blocks are accessed. Suppose a transaction in the open transaction
group reads and then dirties block 16. Now, an older transaction in a quiescing transaction group attempts
to read and dirty block 16. What happens next?
If the second write goes through, when the currently open transaction group syncs, it will clobber the
currently quiescing transaction group's write. To solve the problem, would you pull the offending
transaction out of the quiescing group and defer it?
Perhaps you would not have this problem ifthe quiescing state were eliminated.
P2Q
r~?h:k~1
Aaron T oponce
July 9, 2013 at 1 :04 pm (http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-
groups/#comment-18211)
Good writeup. So from what I'm gathering, only one TXG can be in the open state at a time. A TXG is
opened, clusters the transactions, is assigned a unique 64-bit identifier, then moves to quiescing. I would
think many TXGs can remain in the quiescing state, but it seems they are synchronized to disk one at a
time. In order to maintain consistency, the TXGs must be written in the same order they were created. So,
I'm guessing the 64-bit identifier is not random, but incremented by one, and each TXG is flushed in order.
Is this also true for sync=disabled?
Comment
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/ 4/20/2016
ZFS fundamentals: transaction groups - Adam Leventhal
Website
Comments
Recent Posts
Delph ix Technology Scholarship for Women
(http:! /blog .delph ix.com/ah 1/2015/delphix-tech nology-
scholarship-women/)
Posted by Adam Leventhal on 5th November 2015
Delph ix Sync
(http:! /blog .delph ix.com/ah 1/2015/delphix-sync/)
Posted by Adam Leventhal on 4th November 2015
I am not a resource
(http:! /blog .delph ix.com/ah 1/2015/i-am-not-a-
resource/)
Posted by Adam Leventhal on 24th September 2015
First Rust Program Pain (So you can avoid it. .. )
(http:! /blog .delph ix.com/ah 1/2015/first-rust-program-
pain/)
Posted by Adam Leventhal on 22nd June 2015
On Slogging (Briefly)
(http:! /blog .delph ix.com/ah 1/2015/on-blogging/)
Posted by Adam Leventhal on 4th March 2015
Categories
Company
(http:! /blog .de lph ix.com/ah I/category/company/)
DTrace (http://blog.delphix.com/ahl/category/dtrace/)
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/
Page 4of6
4/20/2016
ZFS fundamentals: transaction groups - Adam Leventhal Page 5of6
Engineering
(http:! /blog .de lph ix.com/ah I/cat ego ry/eng inee ring/)
flash (http://blog.delphix.com/ahl/category/flash/)
Hardware
(http:! /blog .de lph ix.com/ah I/cat ego ry/hardwa re/)
illumos (http://blog.delphix.com/ahl/category/illumos/)
Open Source
(http:! /blog .de lph ix.com/ah I/category/open-sou reel)
OpenSolaris
(http:! /blog .de lph ix.com/ah I/category/ope nso laris/) ---·--···-··-··-----·--···-··-·----·--···-··-·----·
Software
(http:! /blog .de lph ix.com/ah I/cat ego ry/softwa re-2/)
ZFS (http://blog.delphix.com/ahl/category/zfs/)
Archives
November 2015 (http://blog.delphix.com/ahl/2015/11/)
September 2015
(http:! /blog .delph ix.com/ah 1/2015/09/)
June 2015 (http://blog.delphix.com/ahl/2015/06/)
March 2015 (http://blog.delphix.com/ahl/2015/03/)
December 2014 (http://blog.delphix.com/ahl/2014/12/)
August 2014 (http://blog.delphix.com/ahl/2014/08/)
June 2014 (http://blog.delphix.com/ahl/2014/06/)
February 2014 (http://blog.delphix.com/ahl/2014/02/)
December 2013 (http://blog.delphix.com/ahl/2013/12/)
September 2013
(http:! /blog .delph ix.com/ah 1/2013/09/)
August 2013 (http://blog.delphix.com/ahl/2013/08/)
May 2013 (http:! /blog .delphix.com/ah 1/2013/05/)
February 2013 (http://blog.delphix.com/ahl/2013/02/)
December 2012 (http://blog.delphix.com/ahl/2012/12/)
November 2012 (http://blog.delphix.com/ahl/2012/11 /)
October 2012 (http://blog.delphix.com/ahl/2012/1 Of)
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/ 4/20/2016
ZFS fundamentals: transaction groups - Adam Leventhal
September 2012
(http://blog.delphix.com/ahl/2012/09/)
July 2012 (http://blog.delphix.com/ahl/2012/07 /)
April 2012 (http://blog.delphix.com/ahl/2012/04/)
February 2012 (http://blog.delphix.com/ahl/2012/02/)
January 2012 (http://blog.delphix.com/ahl/2012/01 /)
December 2011 (http://blog.delphix.com/ahl/2011/12/)
October 2011 (http://blog.delphix.com/ahl/2011 /1 Of)
September 2011
(http://blog.delphix.com/ahl/2011 /09/)
June 2011 (http://blog.delphix.com/ahl/2011/06/)
May 2011 (http://blog.delphix.com/ahl/2011/05/)
Delphix for DevOps
LEARN MORE
(HTTP://VWVW.DELPHIX.COM/SOLUTIONS/DEVOPS/)
Delphix for ERP Upgrades
LEARN MORE
(HTTP://iiviNvV.DELPHiX.COivi/SOLUTiONS/ERP-
UPGRADES/)
Delphix for Cloud Migration
LEARN MORE
(HTTP://VWVW.DELPH IX.COM/SOLUTIONS/CLOUD-
MIGRATION/)
© 2015 Delph ix Corp.(/) All rights reserved. 275 Middlefield Road, Suite 210, Menlo Park, CA 94025
STAY CONNECTED rm Facebook (https://www.facebook.com/DelphixCorp) rm Twitter
Page 6of6
(https://twitter.com/delphix) ii Linkedln (https://www.linkedin.com/company/236924) ii Google Plus
(https://plus.google.com/u/O/b/100331808380763597764/100331808380763597764)
Contact Sales (http://www.delphix.com/p/contact-sales/) I Blog (http://blog.delphix.com/) I Support
(https://support.delphix.com/hc/en-us) I Community (https://community.delphix.com/delphix) I Legal
(http://www.delphix.com/p/delphix-legal/) I Privacy Policy (http://www.delphix.com/p/privacy-policy/)
http://blog.delphix.com/ahl/2012/zfs-fundamentals-transaction-groups/ 4/20/2016