Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
patenting assistance requested
158 views
Skip to first unread message
Jules_Gilbert
Aug 12, 2012, 9:53:07 PM8/12/12
to hou...@free.fr
Yes, I've decided to patent.
I was at the USPTO site and,wow, I'm wondering if I should go back to card sorters and 407 punch machines...
(A joke, the rest of this is serious. And no, I've never used either.)
I need some help here, my objective is to file two patents. For each I supply theory as to the operation, and a working C program as source code.
I desire to patent, separately, the "derad" program that, given a buffer or stream containing random data, produces non-random equivalent output. MY technical basis for claiming that derad is non-random is very simple, (see the discussion wrt to change in power spectra coefficients.)
The process is efficient and reversible.
Another program, "rerad", given output from derad, produces a buffer/stream identical to the original content given to derad.
While random data produces power spectra coefficients near zero (10E-5, typical for 256 byte buffers,) after derad processing, auto-correlation returns coefficient values on the order of 10E+2, a substantial change.
I don't want to patent, I hate doing this. But as conflicted as I am, I am asking for help to do this. I'd prefer to do this electronically without resorting to the PTO's PDF publications. (That approach I can execute myself, no help needed.)
I wasn't sure from the site, but does it support the Apple?, I'm running 10.4.11.
I was at the USPTO site and,wow, I'm wondering if I should go back to card sorters and 407 punch machines...
(A joke, the rest of this is serious. And no, I've never used either.)
I need some help here, my objective is to file two patents. For each I supply theory as to the operation, and a working C program as source code.
I desire to patent, separately, the "derad" program that, given a buffer or stream containing random data, produces non-random equivalent output. MY technical basis for claiming that derad is non-random is very simple, (see the discussion wrt to change in power spectra coefficients.)
The process is efficient and reversible.
Another program, "rerad", given output from derad, produces a buffer/stream identical to the original content given to derad.
While random data produces power spectra coefficients near zero (10E-5, typical for 256 byte buffers,) after derad processing, auto-correlation returns coefficient values on the order of 10E+2, a substantial change.
I don't want to patent, I hate doing this. But as conflicted as I am, I am asking for help to do this. I'd prefer to do this electronically without resorting to the PTO's PDF publications. (That approach I can execute myself, no help needed.)
I wasn't sure from the site, but does it support the Apple?, I'm running 10.4.11.
James Dow Allen
Aug 18, 2012, 2:53:07 AM8/18/12
to
On Aug 13, 8:53 am, Jules_Gilbert <jules_gilb...@mail.com> wrote:
> I need some help here, my objective is to file two patents. For each I supply theory as to the operation, and a working C program as source code.
Since no one else has responded, I'll comment on my own
> I need some help here, my objective is to file two patents. For each I supply theory as to the operation, and a working C program as source code.
patenting experience from 15 years ago.
First, you "can't patent an algorithm." Mathematical facts
are considered to be the Work of God, not of Man.
Since you CAN patent an apparatus, the solution was simple:
Replace the patent claim
"I claim the algorithm which ..."
with
"I claim a digital computing apparatus which implements the
algorithm which ..."
Six simple words to change an unpatentable algorithm
into a patentable apparatus (though your attorney will
charge you $139 for each of the words).
But that was then. IIRC, rules have since changed and it
is now harder to patent algorithms.
James
peter
Aug 18, 2012, 9:41:54 PM8/18/12
to
Hi,
why don't you do an electronic card and go to some investors ?
If you publish something, in a few days a similar algorithm will be
written by big companies, but with different mathematical tools, so your
invention will be useless
Bye
Peter
why don't you do an electronic card and go to some investors ?
If you publish something, in a few days a similar algorithm will be
written by big companies, but with different mathematical tools, so your
invention will be useless
Bye
Peter
pked...@gmail.com
Aug 20, 2012, 8:54:56 PM8/20/12
to hou...@free.fr
Ernst
Aug 26, 2012, 7:02:51 PM8/26/12
to hou...@free.fr
I may not be so swift but; this persona is so "fricken lame" and has no consistency in over 10 years that I have been involved with the million digit challenge that I present the perspective that this persona is false and some sort of manipulation on the behalf of some group or a projection of some alter ego of some realm.
Jules_Gilbert is not a real person. It is a dramatization on a conceptual persona.
Prove me wrong!
Repeatable Compression is real and available today
Sep 9, 2012, 1:30:08 PM9/9/12
to
Drat!, and I was so sure I was a real person. I'm sorry Ernst doesn't think I'm real. I just renewed my drivers license, at least they think I'm real.
As to whether or not my work is real, well, I've been interviewing patent firms, and in my cover letter I provide two attachments, a C source file and an output file showing the 'coefficient' values derived from auto-correlating the original buffer, the BEFORE, and the AFTER values. The after values are higher, as my program reduces the degree of randomness and autocorrelation measures the alikeness (or the inverse,) of one cell to it's neighbors.
I don't show the C function that does this, but I do show everything else. The method is efficient and reversible.
Email me if you'd like a copy of those two attachment files I've been providing to others.
About patenting; I have this program, I invented it, and, if I can actually make the system work for me (which I see as doubtful,) I will patent. But look at Samsung, they weren't paying Apple royalties, but should have been. And Apple isn't a good citizen either, they recently got sued by a company that claims Apple offered them a paltry $50k for an important idea they have incorporated into their iPhone. And I've read the plaintiff's patent, as far as infringement goes, I think they have a strong case.
I've spent the past three weeks trying to find a path that works, and, at least in the US, I think it's clear that our nation's patent laws favor the infringers. (Apple is claiming that a fair price for the Samsung infringement wasn't $1B, but $3B. And folks, that may seem like a lot but I don't think so, I think it might be about right.)
I'm simply saying that unless 'you' are a large company with $75M to spend (how much Apple believes it spent obtaining justice,) inventing something that changes the rules simply doesn't pay. Better invent a can-opener or even a framistan that runs cooler. That might get you a royalty deal.
This week I expect to walk into a patent firm with two lap-tops. One guess as to why...
As to whether or not my work is real, well, I've been interviewing patent firms, and in my cover letter I provide two attachments, a C source file and an output file showing the 'coefficient' values derived from auto-correlating the original buffer, the BEFORE, and the AFTER values. The after values are higher, as my program reduces the degree of randomness and autocorrelation measures the alikeness (or the inverse,) of one cell to it's neighbors.
I don't show the C function that does this, but I do show everything else. The method is efficient and reversible.
Email me if you'd like a copy of those two attachment files I've been providing to others.
About patenting; I have this program, I invented it, and, if I can actually make the system work for me (which I see as doubtful,) I will patent. But look at Samsung, they weren't paying Apple royalties, but should have been. And Apple isn't a good citizen either, they recently got sued by a company that claims Apple offered them a paltry $50k for an important idea they have incorporated into their iPhone. And I've read the plaintiff's patent, as far as infringement goes, I think they have a strong case.
I've spent the past three weeks trying to find a path that works, and, at least in the US, I think it's clear that our nation's patent laws favor the infringers. (Apple is claiming that a fair price for the Samsung infringement wasn't $1B, but $3B. And folks, that may seem like a lot but I don't think so, I think it might be about right.)
I'm simply saying that unless 'you' are a large company with $75M to spend (how much Apple believes it spent obtaining justice,) inventing something that changes the rules simply doesn't pay. Better invent a can-opener or even a framistan that runs cooler. That might get you a royalty deal.
This week I expect to walk into a patent firm with two lap-tops. One guess as to why...
Industrial One
Sep 9, 2012, 1:57:53 PM9/9/12
to
On Sunday, September 9, 2012 5:30:08 PM UTC, Repeatable Compression is real and available today wrote:
>And Apple isn't a good _citizen_ either, _they_ recently got sued
2 months shy of being a senior citizen and still illiterate in his own language I see.
If Apple is one citizen, "they" can't be sued. Only "he" can be sued. Is Apple a he or a she? I've always wondered...
I always wanted to marry Hallie Burton cuz shes like so rich n stuff, but she's like 90 years old, gross.
>And Apple isn't a good _citizen_ either, _they_ recently got sued
2 months shy of being a senior citizen and still illiterate in his own language I see.
If Apple is one citizen, "they" can't be sued. Only "he" can be sued. Is Apple a he or a she? I've always wondered...
I always wanted to marry Hallie Burton cuz shes like so rich n stuff, but she's like 90 years old, gross.
Jules Gilbert
Sep 11, 2012, 5:52:00 AM9/11/12
to
I don't know what I'm going to do. It's a good thing I have my day job (predicting the future, or at least, the next-day market,) because, when I talk to patent attorneys, well, what they say scares me.
They refer to the reasons I haven't moved on other versions of repeatable compressors as if those reasons are good -- I repeat, they scare me. And I'm having these conversations because I'm looking for a patent attorney.
Oh, and to those of you who think I don't have what I have, I'm distributing a simple demo program and an output; This material is exactly as the job was run, I haven't changed so much as a character. (I did delete the critical function, but nothing else was changed. Contact me if you want a copy.)
Right now, having focused on this project for the past few weeks, I don't see a solution. I had intended to license the program in America, and give it to (licensing it for free,) to countries in which less than 5% of the population are Christians so long as their are no restrictions on witnessing and Bible groups, etc. But as things stand, I don't see any likelihood of actually profiting from my work.
Some explanation:
Today, almost all files and messages are sent compressed. This is true whether the message is a TV signal, one side of a telephone conversation or a movie stored on a CDROM. Compressors are programs which only work once. After one stage of compression, conventional compressors are unable to re-compress the result of the prior stage because the output of all compressors is random-appearing and no compressor can further compress random data.
I have invented a process that changes this, and I believe it qualifies for patent protection. My method decreases the degree of randomness of a client buffer (a portion of a file, possibly produced by a compressor.)
This is quite a claim, it's also true. And to help you believe me I've supplied two files, which I discuss below.
Randomness is measured using the coefficient-like values derived from the process of auto-correlation. An autocor routine measures how alike (or unlike,) each cell is to it's neighbors. Using auto-correlation, a buffer that is random produces coefficient values that are numerically lower than results produced by examining buffers containing non-random values. (In the DSP world, autocorrelation is the standard by which randomness is measured.)
So, a measured buffer which produces high coefficient-like values is less random than measured buffer that produced lower values.
Without exception my process, applied to buffers containing data that is random-appearing converts such buffers to less random data. Also the process has an inverse, so the data can be converted back, making decompression practical.
Now, my method won't turn a compressed file of raucous music into a symphony by Beethoven or Liszt, but it will produce a buffer that is consistently less random than the original input buffer. This process can be cascaded many times using 'helper' routines I supply.
Again, output results produced this way are reversible. This is important if the program is to be commercially useful.
Compression and cell phone related sub-systems are the two most heavily litigated patent areas in the US. Compression has been number one or two for longer than a decade. I don't want to become a party to this statistic.
I am supplying an two attachments to demonstrate the claims I make in this letter. I show C source code used in a simple experimental setup which demonstrates my claim by applying auto-correlatiion before and after reading a random-appearing buffer.
That C program produced the attached output file is complete but for my proprietary functionality.
In my lab I have 10,000 files, each orginally ordinary text documents that were compressed with gzip, a popular compressor of medium quality. I don't get to choose which files get compressed in experiments, a random value is used to make that choice. Also, all data used as input is first XOR'ed with the output of a pseudo-random number generator (a PRNG,) thus insuring that very little context exists in the input when my program processes it.
In the attached program, these files are processed in 256 byte blocks. And this setup is fairly arbitrary, my method can as easily handle large movie files. Really, since I XOR everything against a PRNG, any type of file can be compressed. And then compressed many more times.
Notice I am not patenting anything directly related to compression itself, eg., I don't have a method for doing Huffman or arithmetic coding better than they are already being done. Instead I have a method, so far the only method, for making compression happen the second time, and many more times after that. (The minimum file size is not determined by me, my program makes use of some conventional compressor, which can be chosen by the client. That program, not my program, by it's characteristics determines the minimum practical size. Most files and messages can be made smaller than 5kb. Two thousand bytes is a typical minimum size.)
Whatever kind of compressor someone uses, if they want to compress their file more than once they need to make use of my method. It's that atomic. I don't see anyone building a work-around; I'm pretty sure my method is so basic that a work-around isn't possible. Simple point, easy to understand and verify: The 'coefficients' obtained from autocor are bigger after the 'demo' function is applied.
They refer to the reasons I haven't moved on other versions of repeatable compressors as if those reasons are good -- I repeat, they scare me. And I'm having these conversations because I'm looking for a patent attorney.
Oh, and to those of you who think I don't have what I have, I'm distributing a simple demo program and an output; This material is exactly as the job was run, I haven't changed so much as a character. (I did delete the critical function, but nothing else was changed. Contact me if you want a copy.)
Right now, having focused on this project for the past few weeks, I don't see a solution. I had intended to license the program in America, and give it to (licensing it for free,) to countries in which less than 5% of the population are Christians so long as their are no restrictions on witnessing and Bible groups, etc. But as things stand, I don't see any likelihood of actually profiting from my work.
Some explanation:
Today, almost all files and messages are sent compressed. This is true whether the message is a TV signal, one side of a telephone conversation or a movie stored on a CDROM. Compressors are programs which only work once. After one stage of compression, conventional compressors are unable to re-compress the result of the prior stage because the output of all compressors is random-appearing and no compressor can further compress random data.
I have invented a process that changes this, and I believe it qualifies for patent protection. My method decreases the degree of randomness of a client buffer (a portion of a file, possibly produced by a compressor.)
This is quite a claim, it's also true. And to help you believe me I've supplied two files, which I discuss below.
Randomness is measured using the coefficient-like values derived from the process of auto-correlation. An autocor routine measures how alike (or unlike,) each cell is to it's neighbors. Using auto-correlation, a buffer that is random produces coefficient values that are numerically lower than results produced by examining buffers containing non-random values. (In the DSP world, autocorrelation is the standard by which randomness is measured.)
So, a measured buffer which produces high coefficient-like values is less random than measured buffer that produced lower values.
Without exception my process, applied to buffers containing data that is random-appearing converts such buffers to less random data. Also the process has an inverse, so the data can be converted back, making decompression practical.
Now, my method won't turn a compressed file of raucous music into a symphony by Beethoven or Liszt, but it will produce a buffer that is consistently less random than the original input buffer. This process can be cascaded many times using 'helper' routines I supply.
Again, output results produced this way are reversible. This is important if the program is to be commercially useful.
Compression and cell phone related sub-systems are the two most heavily litigated patent areas in the US. Compression has been number one or two for longer than a decade. I don't want to become a party to this statistic.
I am supplying an two attachments to demonstrate the claims I make in this letter. I show C source code used in a simple experimental setup which demonstrates my claim by applying auto-correlatiion before and after reading a random-appearing buffer.
That C program produced the attached output file is complete but for my proprietary functionality.
In my lab I have 10,000 files, each orginally ordinary text documents that were compressed with gzip, a popular compressor of medium quality. I don't get to choose which files get compressed in experiments, a random value is used to make that choice. Also, all data used as input is first XOR'ed with the output of a pseudo-random number generator (a PRNG,) thus insuring that very little context exists in the input when my program processes it.
In the attached program, these files are processed in 256 byte blocks. And this setup is fairly arbitrary, my method can as easily handle large movie files. Really, since I XOR everything against a PRNG, any type of file can be compressed. And then compressed many more times.
Notice I am not patenting anything directly related to compression itself, eg., I don't have a method for doing Huffman or arithmetic coding better than they are already being done. Instead I have a method, so far the only method, for making compression happen the second time, and many more times after that. (The minimum file size is not determined by me, my program makes use of some conventional compressor, which can be chosen by the client. That program, not my program, by it's characteristics determines the minimum practical size. Most files and messages can be made smaller than 5kb. Two thousand bytes is a typical minimum size.)
Whatever kind of compressor someone uses, if they want to compress their file more than once they need to make use of my method. It's that atomic. I don't see anyone building a work-around; I'm pretty sure my method is so basic that a work-around isn't possible. Simple point, easy to understand and verify: The 'coefficients' obtained from autocor are bigger after the 'demo' function is applied.
0 new messages