Peer-to-Patent Australia

Home > Archived Applications > 2005218001 > Discussion

Patent Application Number: 2005218001

Binary representation of number based on processor word size

This discussion forum is available to allow the community of reviewers to collaborate and discuss this patent application.

Discussion that is posted on this page will not be forwarded to IP Australia. If you wish to make comment on a prior art reference and wish that comment to be considered by the patent examiner, please do so by clicking on the relevant prior art reference.

Here are some tips to facilitate discussion.

Flagging a post as an 'action item' signals that further research is required.
Flagging SPAM and ABUSE helps to manage discussion
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original, for example: [[claim 1]] and [[prior art 2]].

Discussion (16)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

Paul Leopardi (over 2 years ago)

Can someone please compare both instances of prior art with the claims and description of the patent application?

I believe that the patent application is identical (or at least sufficiently close) to what is done by GNU GMP 2.0.2, and differs from Densely Packed Decimal Encoding.

Specifically, the description in the patent application talks about doing the usual binary computer arithmetic directly on the stored words, possibly with an extra carry (as per GNU GMP 2.0.2). I don't think that Densely Packed Decimal Encoding allows this. It would either need new hardware (or microcode) for arithmetic, or would need software to convert the packed numbers to a format to allow the usual binary computer arithmetic to be performed. I don't think that this matches the claims, description or inferred intent of the HP patent application.

Jimmy Ti (over 2 years ago)

I agree with Paul on the relevance of GNU GMP 2.0.2 Prior Art Reference 3 which is dated May 1996. GMP uses the term "limb" which is essentially the same as "section" defined in the application. Have a look at the const struct __mp_bases defined in gmp-2.0.2/mpn/mp_bases.c, it is essentially a lookup table for suitable limb size to represent numbers of various bases on both 32-bit and 64-bit processors.

Mik Clarke (over 2 years ago)

With regard to the DPD prior art (which is summarized on Wikipedia: http://en.wikipedia.org/wiki/Densely_packed_decimal ) you could argue that the filing is about selecting an appropriate length of DPD based upon the wordsize of the target CPU - useful if your on a server building binary data to be sent to hetrogeneous CPUs. Does seem a bit obvious though - Encode the data for the 8 bit CPU using an 8bit encoding, for the 16 bit using a 16 bit encoding etc... This is basically Claim 1, although they present it as a static choice. Essentially wrapping DPD in a select (wordsize)...

Paul Leopardi (over 2 years ago)

I don't think the patent application is about DPD. See my further comments on this.

Paul Leopardi (over 2 years ago)

I tried uploading prior art and found the following problems.
1: Text loses formatting, specifically line breaks, making it very hard to read.
2. HTML formatting does not work.
3. File upload is required and this is not appropriate for a Tar/Gz source code archive on a public FTP server.
4. File upload does not allow upload of a Tar/Gz source code archive.
5. File upload of source code assumes that source code is a single text file, PS file, etc. This is just not true for a Tar/Gz source code archive.

Jimmy Ti (over 2 years ago)

Hi Paul, sorry to hear about your frustrations. We really appreciate your active participation and feedbacks. Let me provide some clarifications on some of the issues.

1. The code does strip away whitespace and escape non-alphabet characters at the moment, we will look into this issue and keep you updated.

2. As with above, HTML tag characters are escaped and ignored by the page renderer. We will also look into this but this will be of lower priority than the first issue.

3. I think uploading the entire code base could be overwhelming for the reviewer at IP Australia (patent office), and if possible just upload the few relevant source code files with additional comments highlighting the relevant sections in the code. With that said, please do include the link to the entire code base in the URL field so that other people can also examine the software as a whole.

5 and 6. A fix for this is on the way. Changes will be made to the site at the next maintenance reboot.

Jimmy Ti (over 2 years ago)

Hi Paul,

Update on first issue: line breaks should now be preserved and automatically be honored as br tag when viewed. I have also cleaned up the HTML tags in the prior art metadata.

Please post any further suggestions / feedbacks to our blog at www.peertopatentaus.wordpress.com or contact@peertopatent.org.au. We want the discussion board to focus on the patent applications itself. I have also taken down the annotation you posted for the application for similar reasons.

Thank you for your feedback.

Paul Leopardi (over 2 years ago)

Hi Jimmy,
Thanks for all your prompt fixes. I've updated my prier art now.

Jimmy Ti (over 2 years ago)

Is the output of the encoding mentioned in Prior Art Reference 1 limited to only 10-bit or multiple of 10-bit? The reason I ask is because the algorithm specified in the application doesn't seem to have such limitation.

Paul Leopardi (over 2 years ago)

I believe that this whole patent was preempted by GNU GMP 2.0 in 1996. I will contact Paul Zimmermann of Inria to ask him to comment.

Jimmy Ti (over 2 years ago)

Would you be able to elaborate more about the technique employed by GNU GMP? If this is true, this would preempt the technique mentioned in the prior art submitted.

Paul Leopardi (over 2 years ago)

From what I see in the source code of GMP 2.0.2 from 1996, GMP was doing
everything claimed in the patent application, for 32 and 64 bit word sizes
- it fits chunks of digits into words ("limbs"), according to word length.
See http://ftp.download-by.net/gnu/gnu/gmp/gmp-2.0.2.tar.gz
See specifically, gmp-2.0.2/gmp-impl.h , gmp-2.0.2/mpn/mp_bases.c , gmp-2.0.2/mpn/generic/get_str.c and
gmp-2.0.2/mpn/generic/set_str.c .

Rick Regan (over 2 years ago)

But in this patent application, they segment based on decimal digits. GMP segments by bits, right? (The application refers to "multi-word binary value", which to me describes GMP's implementation).

Ben McEniery (over 2 years ago)

Hi Rick
I'm not sure I understand what you mean by this. On my reading, this application segments by bits according to word size. So if the word size is 4 bits, that is the segment size. Does that make sense?

Rick Regan (over 2 years ago)

This application describes a BCD-like encoding. Like BCD, it breaks decimal numbers into binary encoded decimal digits, except that it's not limited to 4 bits. GMP does not break numbers into decimal digits -- it treats them as binary numbers, which may broken into segments.

I don't know if this application is original or not -- I was just trying to point out that if differs from GMP, at least relative to the comments about GMP above.

(Disclaimer: I have not read every word of the application and I'm not a GMP or BCD expert!)

Paul Leopardi (over 2 years ago)

Rick, I've just read set_str.c again, and I think that your description of GMP is not correct. GMP treats numbers as a sequence of limbs, and converts between strings and sequences of limbs using the "big" number base. The "big" number base is the base used for limbs. It is a whole number power of the "small" number base, the base used for individual digits in the string. Read set_str.c again and look specifically at the special case where base==10 to understand this better.

0 days left