Check out the new USENIX Web site. USENIX - How to Submit

Please read these guidelines carefully. They were written to help you give your formal submission its best possible chance to be accepted.

The program committee seeks papers describing application and system software that extends the reach of the use of smart cards in systems for authentication, electronic commerce, and secure personal data storage. Submissions across a broad range of smart card development phases are encouraged, from exploratory research and proof-of-concept studies to practical application and deployment of smart card technology.


The USENIX Workshop on Smartcard Technology will be held in Chicago, Illinois, May 10-11, 1999. The Workshop will consist of two days of technical sessions. The Workshop will accept extended abstracts, which will be refereed and selected for publication as full papers in the Proceedings.

Dates for refereed paper submissions:

Extended abstracts due: December 1, 1998
Notification to authors: January 12, 1999
Camera-ready full papers due: March 30, 1999


For your convenience, here is a summary of the important information in the Call For Papers as it pertains to refereed papers:
  • Authors must submit an extended abstract of their paper, about 5 pages long, representing the paper in short form, as it will appear in the final paper. Full papers, limited to 12 single-spaced pages, will also be accepted.

    • Please submit one copy electronically to

    • The alternate method of submission will be postal mail; you may mail 15 copies of your submission to:
      Smartcard '99 Submissions
      USENIX Association
      2560 Ninth St, Ste 215
      Berkeley, CA 94710

  • The authors must also submit a cover letter or email containing the following information:
    1. The title and authors of the manuscript.
    2. The name of one author who will serve as a contact and his/her:
      - electronic mail address,
      - daytime and evening telephone numbers,
      - surface mail address,
      - and a fax number (if available).
    3. An indication of which, if any, of the authors are full-time students.
    4. A short abstract of the paper (about 100-200 words).
  • The final paper should be 8-12 typeset USENIX conference pages in length.


The Program Committee would prefer to receive submissions via electronic mail, but there are occasionally problems in printing them. If you have any reason to suspect that your submission might not be easy for us to print, please submit a printed hardcopy by surface mail in addition to your electronic version.

Submissions via email can be made in several formats, such as PDF, Word, or Postscript. The simplest to read and distribute is Postscript, as long as it uses standard fonts or includes everything needed, and has not been generated in a non-portable environment. (Some PostScript generators are quite buggy and we may not be able to print their output). If you send PostScript, remember the following:

* Use only the most basic of fonts (TimesRoman, Helvetica, Courier), or include nonstandard fonts. Other fonts are often not available with every printer or previewer.

* PostScript that requires some special prolog to be loaded into the printer won't work for us. Don't send it.

* If you used a PC or Macintosh-based word processor to generate your PostScript, print it on a more generic PostScript printer before sending it, to make absolutely sure that the PostScript is portable.


The most important thought to keep in mind when deciding whether to submit a paper is "what will the audience or readers learn from my paper?" We don't expect every paper to report on a major breakthrough, but we do look for something new, potentially useful, and not entirely obvious. Think about how different your work is from previously published papers; it may be good work but if there is nothing new to learn, it isn't worth reading (or writing) a paper about it. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems? And, does your work really improve upon the previous state of the art? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often more important than positive results.

Trying to decide if something is non-obvious isn't easy (patent lawyers make lots of money arguing about this), and sometimes the best ideas seem obvious in hindsight; but if lots of people have done the same thing, and you are simply the first person to have considered writing a paper about it, perhaps it's too obvious.

Also think about whether this workshop is the right place to publish your paper. Perhaps it belongs in the USENIX annual technical conference, a more theoretical conference, or a conference with a different kind of focus. Or perhaps it doesn't belong in a conference at all; it might be more appropriate for a USENIX publication, like ";login:" or the USENIX Journal, Computing Systems. On the other hand, USENIX conferences typically cover a broad range of practical issues in open computing systems. It may be that you can take a paper that has several possible themes, and write it to concentrate on issues specifically interesting to a USENIX audience.

The program committee will also be trying to decide if papers will lead to a good 25-minute presentation. Some systems are just too complex to be presented this way (perhaps you should focus on just one aspect); other papers just don't have enough to talk about for that long. On the other hand, a few rare papers are accepted mostly because the committee expects them to produce an interesting talk, but that might not otherwise merit publication.

Again, when you are writing your paper, keep in mind "what do I intend to teach the reader?" That means keeping the paper focused on one or a few main points. Don't try to cram too many big issues into the paper, and don't fill it up with irrelevant details. But do include enough background for the reader to understand why your problem is important, how your work relates to previous work in the field, and how it might fit into a practical system. Also, provide enough detail for the reader to put your performance measurements in context. It is vitally important to provide a good bibliography, both so that you give proper credit to previous work, and so that a reader can know where to turn to find additional background information. The program committee will not look kindly on a paper if the author doesn't appear to be familiar with the current literature.


An "extended abstract" might better be thought of as a "condensed paper." Outlines, copies of presentation slides, or 1-page abstracts are very unlikely to be accepted for the refereed Proceedings. When you write an extended abstract, you are explicitly leaving

things out of the paper. Each time you do that, ask yourself, "Will it make it hard for the program committee to judge my paper?" There are no easy rules to follow here: something that might be vital in judging the value of one paper would be irrelevant detail in another case. It's best to leave out things that take a lot of explanation but are not central to the main point of the paper. You might also leave out descriptions of variations on, or extensions to, the main concepts. Don't leave out references to related work, but you can probably reduce this part to an explanation pitched to the program committee, rather than an "introduction to the field" written for the benefit of a non-expert reader. Include graphs, figures, and tables that are central to understanding the paper!

Finally, if a sample abstract would help, you can get a copy of the abstract and final paper that Matt Blaze did for the Winter 1992 USENIX conference (pp. 333-343). The abstract is probably most useful when compared with the final paper. MORE INFORMATION IS AVAILABLE:

Lots of papers and books have been written about how to write a good paper. We'd like to suggest that you read a paper called "An Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to Write a Good Systems Paper." This was written by Roy Levin and David D. Redell, the program committee co-chairs for SOSP-9, and first appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40.

Although SOSP and USENIX papers do differ somewhat, Levin and Redell give good advice for authors of any kind of systems paper.

The authors have graciously agreed to make this paper available online.

Another helpful paper is:

"The Science of Scientific Writing", George D. Gopen and Judith A. Swan, American Scientist, Vol. 78, No. 6 (Nov-Dec, 1990), pp. 550-558.

This article describes not how to write an entire paper, but how to write sentences and paragraphs that readers can understand. Unfortunately, due to copyright restrictions we cannot make this available online or send you photocopies, but almost any library should have copies of this magazine.

We also recommend that you read the proceedings of some recent USENIX conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect (or even great), but most of them are better than most of the ones that got rejected.

Finally, if you have any other questions, feel free to send mail to the program chair at

Good Luck!

?Need help? Use our Contacts page.
Last changed:nov 17, 1998 ah
Workshop index
Event calendar