From: Philippe Verdy (email@example.com)
Date: Fri Jan 28 2011 - 15:08:45 CST
Complete non-sense. Too many ambiguities, and full of syntaxic problems.
Even as a non-native English speaker, I can easily sea that this non-sense
is produced by some automatic translator, trying to mimic your own
non-English language, and that you absolutely don't understand English
enough to correct it and give it some meaning, even if there are no visible
typos in the words. All this looks like a concatenation of words in random
Please ask help to someone that better knows English than you and can you to
translate it. But for now, it would even be better to post directly in your
own native language.
All I can see from what you are writing is that you are trying to describe
(in a very bad formulation) a very imprecise heuristic for some wellknown
statistical compression algorithms, such as the Huffman compression, or
the arithmetic compression (IBM patented, I don't know if it's expired now).
Your description is so ambiguous that it seems you are trying a
circumvolution around all similar algorithms, just to find a hole not
covered by one of the many patents (including many that have expired), or
algorithms that are in the public domain since long in many countries.
Note that many of these algorithms will fall in the scope of the MPEG LA, so
be prepared to the fact that you may in fact breach many existing and valid
patents covered in this hot area, so you'll have to be much more precise to
describe the effective claims that you are trying to protect, and to
describe the related claims that you don't own and that you'll have to
credit if they are essential to the effective implementation of your idea.
For these reasons, all indicates in your text that your poor text will be
rejected by any patent bureau.
But once again, generic binary data compression (the subject of your
messages) has nothing to do with the Unicode and ISO/IEC 10646 standards, or
the character encoding process, or representation and processing of encoded
texts (including character properties for such processing), which are the
real purpose of this mailing list.
If you intend to develop a new compression algorithm, there are much better
suited discussion or publication areas. Try first to write an article, put
it in some PDF form, and try finding an university in your country to review
your paper and that will accept to publish it. If you can't write it
correctly in English, at least you'll be able to publish it in your own
language, and someone will help you make a correct translation of it for
republishing on wellknown international IT research
forums/groups/commitees/papers, such as the ACM or IEEE proceedings.
And if you are still trying to create a patent from your algorithm, please
consult a patent bureau in your country (you'll need money anyway to
register this patent, and probably a specialized lawyer, which will cost you
even much more than paying for a minimally qualified translator ; and if you
want to register it internationally, you'll really need such a translator
for ar least one language that each patent bureau will be able to process
for your registration).
But this mailing list is not the correct place for create a proof of
first-authorship, notably because it is completely out of topic for your
> Concatenate enumerated half the combinations of binary digits, and other
> Concatenations may comprise that of other halves and enumerations such
> that some of it may be removed. Such some of it may be which does not have
> combinations in the either of enumerations then, substitute either the
> combination furthest away from these other enumerations, or the following
> furthest combination, with opposite combination.
> The coding roughly proportional to frequency may be including other codes
> such that another code is made of combined concatenation and any other
> suitable binary digit(s) such as a concatenation. Such a concatenation may
> be removed from the coding, the following combinations include this removed
> concatenation whenever it is possible and the fewer bit codes assigned
> directly to the frequently used characters to prevent the assigning of the
> characters to the bits unexploited or recurring.
This archive was generated by hypermail 2.1.5 : Fri Jan 28 2011 - 15:11:43 CST