tag:blogger.com,1999:blog-6733236595417664807.post68328926715786995..comments2024-03-05T06:00:22.338-05:00Comments on All Things Pros: BPAI interprets "length along time bar" to cover a direction transverse to time barKaren G. Hazzahhttp://www.blogger.com/profile/14864564225463528630noreply@blogger.comBlogger85125tag:blogger.com,1999:blog-6733236595417664807.post-81186181589186640892012-08-09T18:50:57.404-04:002012-08-09T18:50:57.404-04:00Anon, you're going to have a rough time of it ...Anon, you're going to have a rough time of it until you understand what BRI means. Obviously, the examiners are not as incompetent as you think. Learn from them. <br /><br />(Obviously? Oops, sorry, didn't mean to confuse you. Just to clarify, there's no need to start pontificating about Section 103.)<br /><br />First of all, new attorneys seem not to appreciate the weight that is given to an allegation of what a term means to "one skilled in the art" without citation to any evidence. If you want to see how effective such a statement is, go down to the pond, stick your finger in the water, pull it out, then consider the hole your finger left in the water.<br /><br />You want to talk about html pages? Jeez. We haven't gotten past something as simple as a password.<br /><br />This abstract give and take about passwords does not seem to be getting anywhere. So let's suppose application X was filed in 2004 and claims the step of "receiving a password." Let's further suppose that the specification does not provide a limiting definition for the word in controversy, which is true about 99.99% of the time.<br /><br />Newton's Telecom. Dictionary (2001) defines "password" as "A word or string of characters recognized by automatic means permitting a user access to a place or to protected storage, files or input or output devices." Microsoft Computer Dictionary, Fifth Ed. (2002) defines a password as "The string of characters entered by a user to verify his or her identity to the network."<br /><br />That should be the end of the matter, since you've already admitted that a string of characters (e.g., 1234) is not entitled to patentable weight. In any event, you may now provide evidence tending to show that one of ordinary skill in the art in 2004 considered a "password" to be be limited to a "FUNCTIONAL data structure."<br /><br />20 bucks says you cannot provide such evidence. Funny thing is, even if you did, guess which of our competing definitions would win? The answer is found in the "B" part of "BRI."Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-73484983096314392912012-08-08T15:34:17.670-04:002012-08-08T15:34:17.670-04:00I agree, not exactly apple to apple. I have pract...I agree, not exactly apple to apple. I have practiced, and do practice, extensively in both TC 3600 and TC 3700. They're both sh!tty, no doubt. But from my personal experience, TC 3700 wins the prize for sh!ttiest TC. TC 3600 is running a very close second, but they're less sh!tty.<br /><br />TC 1700 is the best. Orders of magnitude better than either TC 3700 or TC 3600.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-12338672804073950532012-08-08T13:02:49.204-04:002012-08-08T13:02:49.204-04:00After all the free help, Anon still does not know ...After all the free help, Anon still does not know the difference between receiving and processing?<br /><br />The phrase "read on" is a poor characterization of the law regarding anticipation? Right. You need to take that up with Giles S. Rich.<br /><br />A couple practice tips. It's called claim construction, not "claim constructions." Prior art does not "read on" claim limitations. Claims read on disclosures. Start with Kalman v. Kimberly Clark to "understand case law a little better."<br /><br />Come on. I know you can do it. "Strangers in the night, exchanging glances, strangers in the night, what were the chances. . ."Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-35183530595942224072012-08-08T11:20:11.551-04:002012-08-08T11:20:11.551-04:00"Analogous art? Talk about reading comprehens..."Analogous art? Talk about reading comprehension. Where did that come from?"<br />Your use of the word "analogous." Since "analogous," as far as I know," is only used in a single context within patent law, I assumed that is how you were using it. If you were using it in a different context, you should explain what that context was. When discussing patent law, there are certain words that you should use carefully of which "obvious," "analogous," and "inherent" are examples. They are "terms of art" in the art of patent law.<br /><br />"Your gibberish does touch on a real issue -- claim interpretation."<br />Hello???? The first post (drafted by me) in this blog was ALL ABOUT claim interpretation – that was 2 weeks ago. Try to keep up, will you!!!!<br /><br />"You described the exact opposite of BRI. Under BRI (which, by the way is not optional), details not required by the literal language of the claim are not normally read into the claim from the disclosure.'<br />You see … that is "examiner interpretation" – not the interpretation of the language of the claims by one of ordinary skill in the art, which is the basis of BRI. What I discovered a long time ago is that examiners will interpret a claim any way possible to have bad prior art read on the claim limitations (i.e., "broadest unreasonable interpretation"). The fact that you can make up a interpretation that fits a round peg into a square hole doesn't make "reasonable." FYI, "reasonable" in the middle word of BRI. Anyway, the upshot is that many examiners fail to recognize many of the nuances in the English language that distinguishes one word from another and causes one phrase to mean different things in different contexts.<br /><br /><br />"you'll see that the BRI of 'password' in the model claim I provided is data consisting of non-functional descriptive material."<br />Still confused over the difference between underlying data and a functional data structure? "1234" is the underlying data. A password is a FUNCTIONAL data structure. The difference being that a claim reciting "receiving data including '1234'" doesn't give patentable weight to the "1234" whereas a claim receiving "receiving data including a password" gives patentable weight to the "password." Of course, if you don't believe me, just walk over and talk to the examiners in TC2100, TC2400, and TC2600. Something you continue to refuse to acknowledge.<br /><br />BTW – let's work with a more complicated example of a data structure: an html page. Perhaps you can explain to me how an html page is non-functional descriptive material.<br /><br />FYI – you need to understand case law a little better. The problem with examiners is that they see some words (i.e., "read on"), latch on it, and don't understand the context in which the terminology is used. An extensive technical dictionary (or perhaps a programming guide) probably "reads on" quite a bit of claim language. However, neither would not be considered anticipatory art for much of that claim language – I'll let you figure out why on your own time. As such, the phrase "read on" is a poor characterization of the law regarding anticipation.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-22022223169697920902012-08-07T18:26:48.970-04:002012-08-07T18:26:48.970-04:00Newby Anon gibbered: "The term 'reads on&...Newby Anon gibbered: "The term 'reads on' is something out of the USPTO."<br /><br />"Assuming that a reference is properly 'prior art,' it is only necessary that the claims under attack, as construed by the court, 'read on' something disclosed in the reference, i.e., all limitations of the claim are found in the reference, or 'fully met' by it." Kalman v. Kimberly-Clark Corp.,713 F.2d 760, 772(Fed. Cir. 1983).<br /><br />It's probably best if you stop now.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-75326031628896925632012-08-07T17:59:59.837-04:002012-08-07T17:59:59.837-04:00Analogous art? Talk about reading comprehension. ...Analogous art? Talk about reading comprehension. Where did that come from?<br /><br />And yeah, the Supremes like to present analogies, hypotheticals, and parades of horribles to counsel at oral arguments. And your point is?<br /><br />Your gibberish does touch on a real issue -- claim interpretation. I knew all these concepts were new to you when you pontificated: <br /><br />"Under the BRI (you know that 'claim construction thang' you guys like to trot out all the time), 'receiving' typically means much more than simply accepting data bits." <br /><br />You described the exact opposite of BRI. Under BRI (which, by the way is not optional), details not required by the literal language of the claim are not normally read into the claim from the disclosure.<br /><br />A "password" can be lots of things but it can also be as simple as "1234." When you are taught the concept of BRI over the next few years (assuming you're cut out for this kind of work, notwithstanding the evidence to the contrary), you'll see that the BRI of "password" in the model claim I provided is data consisting of non-functional descriptive material. Oh, sorry, that's "underlying data" to you.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-6736239954954498482012-08-07T17:11:46.291-04:002012-08-07T17:11:46.291-04:00insert "of KSR" after "listen to th...insert "of KSR" after "listen to the oral arguments."Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-5155466182650307332012-08-07T17:10:50.804-04:002012-08-07T17:10:50.804-04:00First off, your reading comprehension skills STINK...First off, your reading comprehension skills STINK.<br /><br />"But a practice tip: I hesitate to let you in on this, because you can be oblivious but still put your kids through college with the shirty 'analogous' type arguments, because they work often enough on newby examiners."<br />I said "argue by analogy," not that the prior art isn't "analogous." What I was referring to is explained here: http://en.wikipedia.org/wiki/Argument_from_analogy. The issue of "analogous" prior art is discussed here: http://www.uspto.gov/web/offices/pac/mpep/documents/2100_2141_01_a.htm. Two entirely different concepts. Try to keep up …<br />Oh … if you don't think SCOTUS doesn't work with arguments by analogy, go back in listen to the oral arguments. One of the Justices trotted out an analogy for the attorneys to work through.<br /><br />OK, after blowing your intellectual wad addressing an issue that I didn't raise (if we haven't established you were an examiner before, this certainly should be evidence enough in itself), let's address your "anticipation" analysis. The term "reads on" is something out of the USPTO. The law requires "identical invention" in as much detail as recited in the claim. A claim limitation of "receiving a password" is NOT identically disclosed by either "receiving a first name of a user" or "receiving data."<br /><br />"That's because anticipation itself is quite simple."<br />It can be (in theory), but anticipation requires claim constructions, which are RARELY ever explicitly made by examiners. Also, claim constructions are hard – just ask the Federal Circuit who cannot give us a bright line test as to how to construe language. The problem you face when it comes to claim construction is that claim construction is based upon ordinary and customary meaning given to the term by those skilled in the art. This wipes out your attempt to 'reinterpret' the language to read the distinctiveness out of the limitations. In essence, that is what you are doing … reinterpreting "receiving a password" as "receiving data." As such, the real issue has little to do with anticipation and much more to do with claim construction.<br /><br />"Notice that the 'password' in the invention has nothing to do with drawing a bunch of squiggly lines, and nothing to do with the rest of the invention except being 'received.'" Nice strawman you concocted.<br /><br />"The 'password' is what you call 'underlying data' and what the rest of the world calls 'non functional descriptive material.'"<br />Wrong on all counts. The underlying data is "123456." The password is the name of the data structure. Moreover, a password is functional – try telling anybody outside that USPTO that "a computer password is nonfunctional." If you aren’t outright laughed at, a likely response will be "sure, when I forget it." Regardless, the likes of a "password" is NOT treated as non-functional descriptive material at the USPTO. I can show you hundreds/thousands of issued patents each Tuesday that show you are wrong.<br /><br />That last sentence is something you have yet to address. If your view of how patent claims should be construed were correct, then these patents would not be issuing. Moreover, if you were correct, the Federal Circuit would be upholding the invalidation of these types of patents left and right. What is happening? Why isn't the USPTO (mostly) and the Federal Circuit not acting consistent with your interpretations? What is your explanation? Inquiring minds want to know.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-25148747473475328052012-08-07T12:56:20.835-04:002012-08-07T12:56:20.835-04:00Beg pardon. I just assumed somebody pontificating...Beg pardon. I just assumed somebody pontificating on a patent blog would know what anticipation means.<br /><br />Anticipation does not mean that everything within the scope of the claim must be in the prior art. All that's required is that the claim "reads on" an embodiment in a reference, which is often the simplest embodiment. Anticipation does not care about wrappers and "millions of data packets" when the wrappers and "millions of data packets" are unclaimed. Further, anticipation just loves "simplistic" examples. That's because anticipation itself is quite simple. All you do is apply Occam's Razor. (Forget the Razor part for now. It's a little advanced.)<br /><br />Anticipation (and, for that matter, Obviousness) also does not care about anchors or baseballs or what not. I appreciate that those types of "analogy" arguments served you well in law school (hey, congrats!). But a practice tip: I hesitate to let you in on this, because you can be oblivious but still put your kids through college with the shirty "analogous" type arguments, because they work often enough on newby examiners. But if you stay in the business for any length of time, you'll find that those types of arguments rarely work in District Court or at the BPAI, and never, ever, ever, (ever), work at the Fed. Cir. or at the Supremes.<br /><br />Anyhow, now you know everything you need to know about anticipation. Look back on your admissions about passwords and "underlying data" and notice that you added a lot of steps and other dross beyond "receiving" data to make whatever point you were trying to make. You'll see that we are in complete agreement.<br /><br />Unfortunately, many patent applications where the novelty is in the software come with claims in the form of --<br /><br />"A method comprising:<br />receiving a password; and<br />drawing a bunch of squiggly lines on a display."<br /><br />Notice that the "password" in the invention has nothing to do with drawing a bunch of squiggly lines, and nothing to do with the rest of the invention except being "received." The "password" is what you call "underlying data" and what the rest of the world calls "non-functional descriptive material." And remember patentable weight and our new friend anticipation?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-5324765856421453402012-08-07T11:46:35.347-04:002012-08-07T11:46:35.347-04:00"So it seems we are in agreement. A step of &..."So it seems we are in agreement. A step of 'receiving a password' is anticipated by a reference that describes receiving data."<br /><br />No. Not all data is inherently a password and/or would be recognized by a computer as a password.<br /><br />Try again.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-61182297689552705302012-08-07T11:44:29.037-04:002012-08-07T11:44:29.037-04:00"Go look at the BPAI decisions by TC, you wil..."Go look at the BPAI decisions by TC, you will find TC 3700's reversal rate is much higher than TC 3600's."<br /><br />Not quite an apple to apple comparison. TC3600 is a hodge-podge of art units -- some of which are completely unreleated to business methods.<br /><br />Also, reversal rates merely describe the difference between what the APJs handling that TC considerable is patentable versus what the examiner's think is patentable.<br /><br />Anyway, to really know the difference, you have to practice in a variety of different TCs and discen the differences on a first hand basis. I've practiced extensively in just about every TC (save biotech and hardcore chemistry) and the examiners in TC3600 are hands down the worst.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-6627223170633869252012-08-06T20:04:04.365-04:002012-08-06T20:04:04.365-04:00So it seems we are in agreement. A step of "...So it seems we are in agreement. A step of "receiving a password" is anticipated by a reference that describes receiving data.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-71364309108366810622012-08-06T19:32:41.393-04:002012-08-06T19:32:41.393-04:00"At last you're getting it."
Dude ....."At last you're getting it."<br />Dude ... I've been saying the "underlying data" is not given any patentable weight for quite some time. See the post dated 8:17PM on July 26th. Please try to keep up.<br /><br />"You're confusing computers with baseballs, wood, cast iron, engine blocks, and anchors."<br />You do not know how to argue by analogy. It is something that they stress in law school. Apparently, you are not a lawyer.<br /><br />"It matters not one wit what the human being is thinking when he/she enters '1234' at the keyboard, the name somebody has given the 'underlying data,' or what some application software will do with the 'underlying data' in the future."<br />Wrongo. If the computer is expecting ASCII characters for a password and you give it "a random sequence of bits," then the computer is likely going say "invalid input" (or react in some manner consistent with an invalid input).<br /><br />Regardless, you are losing track of what matters. In patents, the prime question to be answered is whether or not the prior art anticipates or renders obvious the claimed invention. If I claim "receiving a password, manipulating the password in a particular manner to obtain a result, and then manipulating the result in another particular manner to obtain a second result," the relevant question becomes "is that claim anticipated by or rendered obvious by the applied prior art? If the prior art teaches "receiving a JPEG" and assuming there is no evidence in the record that a JPEG acts as a password, then without the need to look any further, we can answer the relevant question with "NO."<br /><br />Your simplistic example refers to situations in which the two different types of data could contain the same exact same "payload." However, that is the exception. Moreover, the fact that the same data structures have the same payload does not mean that they are identical. When computers talk to one another, the payload is typically "wrapped" with another structure that identifies the payload. As such, to one skilled in the art, the receipt of the password typically contains not only the payload but also the wrapper, which together constitutes the data structure of a password.<br /><br />Put differently, when a computer is receiving untold millions of data packets, it needs to know what is in each one. Otherwise, the computer doesn't know what to do with it. As such, it DOES MATTER the name (or better yet, "the identity") someone has given the underlying data because it is that identity (and how the computer recognizes a data structure with that identity) that informs the computer how to manipulate the data it receives. Why? Because that's the way digital computers operate.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-75978539082827924062012-08-06T13:21:18.875-04:002012-08-06T13:21:18.875-04:00At last you're getting it. What you call the ...At last you're getting it. What you call the "underlying data" ("the specific digits entered into the computer") is not given any patentable weight. (Admission.) Just as mere "underlying data" output to a display is given no patentable weight.<br /><br />But try not to repeat the mistake of jumping past "receiving" the "underlying data" and into the realm of using it.<br /><br />No one would try to use a JPEG as a password if an ATM has nothing more than a numeric keyboard. You're confusing computers with baseballs, wood, cast iron, engine blocks, and anchors. My fault. I neglected to ask for an explanation without reference to engine blocks or anchors.<br /><br />But suppose I enter "1234" at a numeric keyboard when my ATM password is actually "4321." The ATM application program does not recognize "1234" as a password. However, the "underlying data" is received the same way from the keyboard, even if you call one string a password and one a database entry or a random sequence of numbers. The "structure" of 1234 is no different from the "structure" of 4321, so far as the step of "receiving" is concerned. At that point, there's no difference between a "password" and a random sequence of bits. They are both received the same way. Identically.<br /><br />It matters not one wit what the human being is thinking when he/she enters "1234" at the keyboard, the name somebody has given the "underlying data," or what some application software will do with the "underlying data" in the future.<br /><br />Why? Because that's the way digital computers operate.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-64505857380915094382012-08-06T12:18:07.577-04:002012-08-06T12:18:07.577-04:00"A human being enters '1234' at the k..."A human being enters '1234' at the keyboard."<br /><br />Have you forgotten that the law says that the underlying data (i.e., the specific digits entered into the computer) isn't given any patentable weight. As such, your hypothetical fails before it even gets off the ground.<br /><br />"whether the application program intends to process the '1234' as a password or as a database entry."<br />Another bad example. A password can be a database entry (and in most instances is a database entry). As such, you have described two data structures in which one can identically disclose the other.<br /><br />Try my example. Tell me what happens when your ATM asks for your password and you attempt to enter in a JPEG of your new puppy (let's assume for sake of the example that it is possible for you to enter in a JPEG of your new puppy into the ATM). If would like, perhaps you can enter in a time bar instead. Draw on your knowledge of how digital computers operate to explain the result.<br /><br />You see, in a "digital computer" all that is being sent back and forth is a bunch of digital "0s and 1s." However, unless you a dealing with noise, these "0s and 1s" are structured in a particular manner (hence, a "data structure"). A cast iron engine block contains the same building block (i.e., cast iron) as a cast iron anchor. However, they differ because how the iron is structured.<br /><br />I imagine you could use an engine block as an anchor. However, the question of claim interpretation is viewed through the eyes of one skilled in the art – not the eyes of an examiner looking to make a silk purse out of a sow's ear. As such, while an engine block could be used as an anchor, one skilled in the relevant art would not consider an engine block to be an anchor.<br /><br />People put different names to different data structures because they are used differently consistent with their structure. Sure, they are made out of the same building blocks (i.e., "0s and 1s"). However, those skilled in the art recognize that they are different. BTW, in case you missed it, most of the USPTO does as well.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-13321196862381251962012-08-06T10:39:06.160-04:002012-08-06T10:39:06.160-04:00"I catch a baseball three ways."
Excell..."I catch a baseball three ways."<br /><br />Excellent analogy. If data were round, stitched, and made of horsehide.<br /><br />I'll simplify. An application program in the computer makes an operating system call to fetch ASCII characters entered at the keyboard. A human being enters "1234" at the keyboard. The hardware and the operating system, SOMEHOW, receives the "1234" from the keyboard in a different way depending on whether the application program intends to process the "1234" as a password or as a database entry.<br /><br />Why? Be as specific as you can be. Explain without reference to wood or baseballs. Draw on your knowledge of how digital computers operate.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-32810490131391825052012-08-06T09:03:06.877-04:002012-08-06T09:03:06.877-04:00"I can hardly believe that."
Go look at..."I can hardly believe that."<br /><br />Go look at the BPAI decisions by TC, you will find TC 3700's reversal rate is much higher than TC 3600's.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-51690297068382638082012-08-06T08:54:24.907-04:002012-08-06T08:54:24.907-04:00"Explain why the processes are not identical...."Explain why the processes are not identical. Be as specific as you can be."<br />Sorry, not playing that game anymore. I've asked a whole host of questions that have yet to be answered. Until someone on your side can answer those questions, I through playing these little games.<br /><br />However, I will share this with you. I catch a baseball three ways: with a glove, a fishing net, and with a strainer. Are the three ways identical?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-70128867607052427672012-08-06T08:49:20.820-04:002012-08-06T08:49:20.820-04:00"the examiners in TC 3700 are by far the wors..."the examiners in TC 3700 are by far the worst."<br />I can hardly believe that. Almost all the examiners in the mechanical arts are better than those in the computer arts (TC3600 includes business methods). I've practiced in both areas. They are typically more experienced and they don't have to address the issue of 35 USC 101. Put frankly, many of them have a poor understanding of English, have a poor understanding of the law, and have a poor understanding of the technology. Besides that, they are great.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-65502140627913182372012-08-03T20:54:22.859-04:002012-08-03T20:54:22.859-04:00What we've learned thus far --
When a compute...What we've learned thus far --<br /><br />When a computer receives "1234," the process of receiving "1234" -- the process before passing the string to an application program -- is not identical depending on whatever the program is that will be receiving the string. Why? Because a square peg will not fit into a round hole.<br /><br />Excellent argument. If computers were made of wood.<br /><br />Explain why the processes are not identical. Be as specific as you can be.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-54536868509407116222012-08-03T17:30:49.441-04:002012-08-03T17:30:49.441-04:00I'm enjoying you beating up 6tard and our bitt...I'm enjoying you beating up 6tard and our bitter friend who still hasn't gotten over losing Zurko IV ("It's an illegal panel decision! Whaaaaaaaa!!!!"), but you're wrong: the examiners in TC 3700 are by far the worst. Their middle (mis)management is also by far the worst. If you figure out a way to avoid those idiots, please tell me. Thanks in advance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-49591962385369582262012-08-03T15:27:42.977-04:002012-08-03T15:27:42.977-04:00"I give up. You win. You're the winner. I..."I give up. You win. You're the winner. I am not."<br /><br />No -- you haven't given up. You'll trot those tired arguments to unsuspecting applicants who were unfortunate to have their applications examined in TC3600. Because the level of attorney work is generally pretty low, you'll be able to sneak those past many of them.<br /><br />FYI -- I'm working on putting together a presentation for my clients on how to avoid having their application be examined in TC3600. After working with other TCs, when I first started working with TC2100, I thought those were the worst examiners out there. I shortly found out that they cannot hold a candle against TC3600 examiners when it comes to blatant misrepresentation of the law.<br /><br />A final word of advice as we head into the weekend -- avoid TC3600 at all costs.<br /><br />"Thought maybe you'd know the difference between receiving and processing."<br />FYI -- try putting a square peg into a round hole. The hole is doing nothing but receiving, but even in receiving, the hole can reject the peg.<br />Under the BRI (you know that "claim construction thang" you guys like to trot out all the time), "receiving" typically means much more than simply accepting data bits.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-11258619057780801112012-08-03T10:24:53.326-04:002012-08-03T10:24:53.326-04:00(sigh)
Thought maybe you'd know the differenc...(sigh)<br /><br />Thought maybe you'd know the difference between receiving and processing.<br /><br />I give up. You win. You're the winner. I am not.<br /><br />We have a saying in the real world. "Never try to teach a pig to sing. It's a waste of time, and it annoys the pig."Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-28462844942227361752012-08-03T09:36:10.697-04:002012-08-03T09:36:10.697-04:00"I've already cited 'real' case l..."I've already cited 'real' case law that explains the difference between a data structure and data."<br />Refresh my recollection. By the way, citing case law isn't just mentioning the name of a case– you need to actually cite the holding within the case. Did they teach you that in examiner school?<br /><br />"Nobody claims the data portion of a file? BS, sir or madam."<br />Got an application number you want to cite? I haven't seen it done, and I've seen thousands of sets of claims.<br /><br />"And yes, for the mere step of 'receiving' data, there's no difference between calling the data a password, an account balance, an orange, or a banana. The computer (or the person) receives the data the same way, regardless of the name you give it."<br />The question is not: "does it receive it the same way?" The question is: "is it identical?" Regardless, they do not receive the same data structure. Next time you log onto your ATM and it asks for your password, enter in a time bar. Tell me how that works out for you. Did you see any difference?<br /><br />Your arguments are the tired old cr@p I sometimes get out of TC3600 which attempts to devolve any computer related method claim into any combination of these steps:<br /> receiving data<br /> manipulating data<br /> outputting data.<br /><br />FYI – when I appeal on this, these examiners ALWAYS back down.<br /><br />Nice aspiration but sorry, it isn't the law. If it was, the Federal Circuit could easily sweep away vast swaths of patents. "Wait," you say, "the district court judges haven't figured this one out yet and that's why these issues don't go the Federal Circuit." Yeah right … so you are saying sophisticated attorneys getting paid lots of money (and who will throw any argument against the wall to see if it will stick) have for years and year and years overlooked this argument? Yeah … and a few tools over in TC3600 have figured it out but cannot get anybody to listen to them.<br /><br />It must be heart breaking … to see so many patents issued year after year after year (thousands … probably hundreds of thousands) that could easily be invalidated if people just saw things your way. I must hurt to see everybody else doing it wrong while you know the right way to do things. You and 6 must close the bars over in Alexandria drinking away your sorrows … telling one another "don't worry, somebody will eventually listen to us and we'll be vindicated … they'll carry us on their shoulders at the patent office and we'll both elevated to the BPAI – perhaps even the Federal Circuit for our intellectual brilliance."Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6733236595417664807.post-20923531560170890822012-08-03T08:19:46.877-04:002012-08-03T08:19:46.877-04:00I've already cited "real" case law t...I've already cited "real" case law that explains the difference between a data structure and data. From your basic misunderstanding of a case as simple as Lowry, I'd say don't bother reading them. Just argue.<br /><br />Nobody claims the data portion of a file? BS, sir or madam.<br /><br />And yes, for the mere step of "receiving" data, there's no difference between calling the data a password, an account balance, an orange, or a banana. The computer (or the person) receives the data the same way, regardless of the name you give it.Anonymousnoreply@blogger.com